Was the OP_SUCCESSx reservation in BIP-342 designed with specific opcode families in mind, or as a generic forward-compatibility mechanism?
Was the OP_SUCCESSx reservation in BIP-342 designed with specific opcode families in mind, or as a generic forward-compatibility mechanism?
Loading saved threads...
Aaron Zhang · External communityPost link
External question — Bitcoin Stack Exchange
Author: Aaron Zhang
Original post: https://bitcoin.stackexchange.com/questions/130670
License: CC BY-SA 4.0 — https://creativecommons.org/licenses/by-sa/4.0/
Adaptation: HTML converted to plain text; contact email addresses removed.
In Pieter Wuille's recent answer
[Why did BIP-342 replace CHECKMULTISIG with a new opcode]
, BIP-342's
deliberate minimization of semantic changes was attributed to the
expectation that "those could always be introduced with later softforks
that redefine OP_SUCCESSes."
I'm curious about the granularity of this reservation:
Were specific opcode candidates (e.g., CHECKSIGFROMSTACK, CAT, TXHASH)
already on the radar when OP_SUCCESS positions were allocated, or was
the allocation purely abstract — "reserve space for unknown future use"?
Was there discussion about classes of additions (introspection opcodes,
signature variants, hash operations) that would or wouldn't be appropriate
candidates for OP_SUCCESS redefinition vs. requiring a deeper softfork?
Are there design properties an opcode SHOULD have to be a clean
OP_SUCCESS redefinition (vs. requiring more invasive consensus changes)?
I ask because the activation-path mechanics matter for how community
discussions about future opcodes should be framed: is the conversation
"which opcode" or also "which opcode reservation slot."
Quote
Report
Murch · External communityPost link
External answer — Bitcoin Stack Exchange
Author: Murch
Original post: https://bitcoin.stackexchange.com/a/130859
License: CC BY-SA 4.0 — https://creativecommons.org/licenses/by-sa/4.0/
Adaptation: HTML converted to plain text; contact email addresses removed.
I don’t have an answer to which opcodes were on the mind of the Tapscript designers when they came up with
OP_SUCCESS
, but the result was that the
OP_SUCCESS
opcodes are designed as generic upgrade hooks.
Some of the issues with the previously existing
OP_NOP
opcodes are that there are few of them, and because they are "no operation", unupgraded nodes would simply pop them off the stack and do nothing before moving on to the next stack operation. This means that when an
OP_NOP
is given more restrictive meaning with a soft fork, it would break forward-compatibility if executing them would change the stack. E.g., if a redefined
OP_NOP
were to evaluate some stack elements, it cannot pop them off the stack and cannot put a result on the stack, as unupgraded nodes would not evaluate such scripts in the same manner.
OP_SUCCESS
opcodes were implemented such that the presence of any
OP_SUCCESS
opcode immediately makes a script return successfully,
regardless of whether the OP_SUCCESS opcode would be executed
. This allows future soft forks to introduce more complex behavior, because any sort of predicate evaluation, stack manipulations etc. will be more restrictive than "always succeed" and unupgraded nodes will always agree with upgraded nodes evaluating a script as valid.
Quote
Report
Post Reply
Quoted from Forex.com.bd-Editorial External answer — Bitcoin Stack Exchange Author: Murch Source score (net votes, not local likes): 1 Original post: https://bitcoin.stackexchange.com/a/130859 License: CC BY-SA 4.0 — https://creativecommons.org/licenses/by-sa/4.0/ Adaptation: HTML converted to plain text; contact email addresses removed. I don’t have an answer to which opcodes were on the mind of the Tapscript designers when they came up with OP_SUCCESS , but the result was that the OP_SUCCESS opcodes are designed as generic upgrade hooks. Some of the issues with the previously existing OP_NOP opcodes are that there are few of them, and because they are "no operation", unupgraded nodes would simply pop them off the stack and do nothing before moving on to the next stack operation. This means that when an OP_NOP is given more restrictive meaning with a soft fork, it would break forward-compatibility if executing them would change the stack. E.g., if a redefined OP_NOP were to evaluate some stack elements, it cannot pop them off the stack and cannot put a result on the stack, as unupgraded nodes would not evaluate such scripts in the same manner. OP_SUCCESS opcodes were implemented such that the presence of any OP_SUCCESS opcode immediately makes a script return successfully, regardless of whether the OP_SUCCESS opcode would be executed . This allows future soft forks to introduce more complex behavior, because any sort of predicate evaluation, stack manipulations etc. will be more restrictive than "always succeed" and unupgraded nodes will always agree with upgraded nodes evaluating a script as valid.
Checking account access…