Author: Gregory Maxwell 2015-12-10 08:26:04
Published on: 2015-12-10T08:26:04+00:00
In a message thread on bitcoin-dev, jl2012 expressed the consensus to implement Segregated Witness (SW) but suggested a balance between new features and deployment time frame should be maintained. jl2012 listed their priority as deployment time frame, preferring it to be as soon as possible even without implementing any new features. Another user agreed with this stance and added that SW was designed to make script changes, improvements, additions, or total rewrites no harder to do after SW than they would be to do along with it. The design of Segwit is structured in such a way that future script updates can be simplified and optimized through the use of a 'version' byte at the start of the witness program. This means that if the prefix is unrecognized it will return true, recapturing the behavior intended by OP_VER in the earliest versions of the software but avoiding hardforks. The binding of script enhancements to SW should be considered off the table, as it could delay deployment and increase complexity. Post-SW, script enhancements could be deployed quite rapidly and on their own timeframes. Operations like multiplication and division make sense with fixed with types but not over arbitrary bignums as they are a complexity nightmare. The user also expressed their desire for an OP_DUPTOALTSTACK and a stack flag on every manipulation instruction.
Updated on: 2023-05-19T22:45:01.192298+00:00