-
Notifications
You must be signed in to change notification settings - Fork 6k
BIP-110: Clarify P2A exemption in rule 3 requires an empty witness stack #2225
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
Changes from 2 commits
ae98a6e
2dfb201
b01048e
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -24,7 +24,7 @@ Blocks during a temporary, one-year deployment are checked with these additional | |
|
|
||
| # New output scriptPubKeys exceeding 34 bytes are invalid, unless the first opcode is OP_RETURN, in which case up to 83 bytes are valid. | ||
| # OP_PUSHDATA* payloads and [[#script-argument-witness-items|script argument witness items]] exceeding 256 bytes are invalid, except for the redeemScript push in BIP16 scriptSigs. | ||
| # Spending undefined witness (or Tapleaf) versions (ie, not Witness v0/BIP 141, Taproot/BIP 341, or P2A) is invalid. (Creating outputs with undefined witness versions is still valid.) | ||
| # Spending undefined witness (or Tapleaf) versions (ie, anything not listed under [[#defined-witness-versions|Defined witness versions]] below) is invalid. (Creating outputs with undefined witness versions is still valid.) | ||
| # Witness stacks with a Taproot annex are invalid. | ||
| # Taproot control blocks larger than 257 bytes (a merkle tree with 128 script leaves) are invalid. | ||
| # Tapscripts including OP_SUCCESS* opcodes anywhere (even unexecuted) are invalid. | ||
|
|
@@ -37,6 +37,15 @@ This grandfathering ensures that no existing coins can be frozen or rendered uns | |
| The new rules apply only to UTXOs created at or after the activation height. | ||
| Once the softfork expires, UTXOs of all heights are once again unrestricted. | ||
|
|
||
| <span id="defined-witness-versions"></span> | ||
| ===Defined witness versions=== | ||
|
|
||
| For the purposes of rule 3, these are the witness versions (and the one Tapleaf version) that are defined as of this BIP: | ||
|
|
||
| * '''Witness v0''' with a 20-byte program (P2WPKH) or a 32-byte program (P2WSH), as defined in [[bip-0141.mediawiki|BIP 141]]. Other v0 program lengths are already invalid under BIP 141 itself. | ||
| * '''Witness v1''' with a 32-byte program (Taproot/P2TR), as defined in [[bip-0341.mediawiki|BIP 341]]. In a script path spend, the only defined Tapleaf version is 0xc0 (Tapscript), as defined in [[bip-0342.mediawiki|BIP 342]]. | ||
| * '''Witness v1''' with the 2-byte program 0x4e73 (P2A), and only when spent with an empty witness stack, as defined in [[bip-0433.mediawiki#specification|BIP 433]]. | ||
|
dathonohm marked this conversation as resolved.
Outdated
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm all for appeasing the author, as long as it's a clear win for documentations spec, integrity, and a win for implementers of this bip. But the author is stating here, as written, that bip433 states a p2a must be spent with an empty witness, which is incorrect. All attempts around the 8th rule, point to this being a clear isolatable consensus rule imposed by bip110
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
That is indeed what it says: "P2A inputs are considered standard by Bitcoin Core for spending if no witness data is attached."
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. "Consensus meaning is unchanged"
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We've been over this; "Consensus meaning is unchanged" just means that P2A has no consensus meaning at all. That isn't relevant to BIP-110. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. P2A output type specifically states that no witness data is attached.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
The output type is defined independently of the spend. It's a template, just like P2MS or P2PKH. Spending a P2A with witness data is currently consensus valid. The current relay policy, however, restricts it to an empty witness.
Undoubtedly, as BIP 433 is unequivocal in its definition of P2A: it's the output type, not the separate policy restricting its spend. In Bitcoin Core, Edit: to address @dathonohm 's objection about "P2A has no consensus meaning at all". That's not true. The script pattern had existing consensus meaning before P2A (anyone can spend even with a non-empty witness), just like P2MS's script pattern had existing consensus meaning before BIP11 made it a standard template (and also didn't change any consensus rules).
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @delcin-raj Moreover, this PR itself also characterizes P2A by the output type, not the spending witness status.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
@dathonohm Your statement is not equivalent to the text you've quoted in BIP 433. @john-moffett is correct and proposes a minimum viable clarification on this. |
||
|
|
||
| ===GetBlockTemplate=== | ||
|
|
||
| This deployment uses the GBT deployment name "reduced_data" as defined in [[bip-0009.mediawiki#getblocktemplate_changes|BIP 9]]. During mandatory signaling, the deployment's bit is included in "vbrequired". | ||
|
|
||

Uh oh!
There was an error while loading. Please reload this page.