On Thu, Mar 06, 2025 at 09:17:41AM -0800, Greg Sanders wrote: > > Of course it depends on the specifics, but rewriting a clean interpreter > > that we can actually reason about does not strike me as a necessarily > > riskier approach than "just changing a few lines of code" in an interpreter > > that hardly anyone knows how it really behaves in all cases. > It's certainly something to consider when weighing further off Bitcoin > Script updates: From here is something like "Great Script Restoration" ever > the right choice vs a from scratch overhaul? I am less persuaded that > consensus risk is particularly high for very narrowly scoped changes, > ignoring the "fixed" costs of changing consensus, maintenance burden, MEVil > risks, etc. The risk-reward ratio may be suboptimal of course.
I think "narrowly scoped changes" is doing a lot of work there. Was tapscript a narrowly scoped change? I would have said so. However, one thing it did was remove the limit on sript size/opcodes, which necessitated a change to how OP_IF/OP_ELSE were implemented to avoid potential quadratic execution time in the length of the script. https://github.com/bitcoin/bitcoin/pull/16902 On the other hand, treating the current interpreter code as an artifact of wise ancients, whose knowledge of how to safely modify it has been lost to time doesn't really seem like a great approach to me, either. Cheers, aj -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/Z8tm6VmhtQxmc2gO%40erisian.com.au.
