Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should we limit the depth of the evaluation stack? #11

Closed
bitjson opened this issue Feb 16, 2024 · 2 comments
Closed

Should we limit the depth of the evaluation stack? #11

bitjson opened this issue Feb 16, 2024 · 2 comments

Comments

@bitjson
Copy link
Owner

bitjson commented Feb 16, 2024

As mentioned in the CHIP, an O(1) Execution Stack isn't very hard to implement. But maybe a worthwhile research question before we essentially require implementations to think about this: is practically-unlimited "evaluation stack depth" desirable?

Would the protocol actually be made simpler by adding fixed depth limit on OP_IF and OP_NOTIF?

Or maybe evaluation stack manipulation is still so much faster than hash digest iterations that we don't need to care about this problem either way?

I'd love to hear about the worst-case performance of naively-implemented evaluation stacks in various languages and VM implementations.

@cculianu
Copy link
Contributor

Leaving note here: FWIW BCHN uses O(1) conditional stack.

@bitjson
Copy link
Owner Author

bitjson commented Aug 12, 2024

Resolved and rationale documented in Rationale: Retention of Control Stack Limit 🚀

@bitjson bitjson closed this as completed Aug 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants