BIP-110: Clarify P2A exemption in rule 3 requires an empty witness stack #2225

dathonohm commented at 5:00 PM on July 29, 2026: contributor

No description provided.

dathonohm force-pushed on Jul 29, 2026

jonatack commented at 5:14 PM on July 29, 2026: member

@dathonohm This is less complete than #2218 that you have been obstructing.

jonatack added the label BIP Update by Owner on Jul 29, 2026

dathonohm commented at 5:16 PM on July 29, 2026: contributor

@jonatack #2218 is incorrect and thus not acceptable. I can add the test vectors here if you wish, but I don't see the reason they are urgently needed. The clarification here should suffice, though I also do not concede that Rule 3 is incorrect prior to this change.

in bip-0110.mediawiki:141 in ed0d033590 outdated

 134 | @@ -135,6 +135,16 @@ This has no use case, but would require nodes to track these UTXOs in case of po
 135 |  By making spending invalid, it is possible for nodes to store them instead in slow memory not needed until this softfork expires.
 136 |  (With proper planning, it also makes it possible for a future softfork making use of these witness versions to allow users to receive with an upgraded wallet even prior to activation of the upgrade.)
 137 |  
 138 | +<span id="p2a"></span>
 139 | +'''What is "P2A", referred to in rule 3?'''
 140 | +
 141 | +Pay to Anchor (P2A) is a policy carveout defined in [[bip-0433.mediawiki#specification|BIP 433]], with outputs of the form <code>OP_1 <0x4e73></code>, and spends with an empty witness.

john-moffett commented at 5:24 PM on July 29, 2026:

Conflates the definition of P2A with the current policy toward using them.

luke-jr commented at 5:25 PM on July 29, 2026:

P2A is nothing more than a policy, until BIP110 promotes it to a consensus rule as described.

john-moffett commented at 5:31 PM on July 29, 2026:

Referring to “P2A” in Rule 3 does not automatically import every policy rule associated with it. The definition of P2A is the output template. The empty witness is a separate requirement for standardness.

dathonohm commented at 5:42 PM on July 29, 2026:

No, P2A is a policy carveout, which includes the expected output format and the expected spend format.

john-moffett commented at 6:09 PM on July 29, 2026:

No, BIP 433 clearly defines P2A by the output script and separately describes the standard spend condition. The code also reflects that behavior by recognizing the template then separately applying the policy.

Just mentioning "P2A" doesn't automatically incorporate the policy.

And if the policy were relaxed to allow a non-empty witness, the output would still be P2A.

luke-jr commented at 5:26 PM on July 29, 2026: member

Looks fine to me

dathonohm commented at 5:27 PM on July 29, 2026: contributor

Added test vectors.

in bip-0110.mediawiki:27 in 6e55cd9cf0

  23 | @@ -24,7 +24,7 @@ Blocks during a temporary, one-year deployment are checked with these additional
  24 |  
  25 |  # New output scriptPubKeys exceeding 34 bytes are invalid, unless the first opcode is OP_RETURN, in which case up to 83 bytes are valid.
  26 |  # 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.
  27 | -# 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.)
  28 | +# Spending undefined witness (or Tapleaf) versions (ie, not Witness v0/BIP 141, Taproot/BIP 341, or [[#p2a|P2A]]) is invalid. (Creating outputs with undefined witness versions is still valid.)

murchandamus commented at 6:05 PM on July 29, 2026:

P2A inputs with witness data being consensus invalid belongs in the specification, because an implementer needs to be aware to avoid a consensus failure. Mentioning it only in the rationale makes it easier to overlook. I would suggest mentioning it here in Rule 3.

# Spending undefined witness (or Tapleaf) versions (ie, not Witness v0/BIP 141, Taproot/BIP 341, or [[#p2a|P2A]]) is invalid. P2A inputs with a non-empty witness stack are invalid. (Creating outputs with undefined witness versions is still valid.)

jarolrod commented at 6:28 PM on July 29, 2026:

My issue with this is that this is clearly a rule with two predicates; this becomes two rules in one.

murchandamus commented at 6:32 PM on July 29, 2026:

I can see that interpretation, and I can also see it being considered part of restricting to defined witnesses. I’m not hung up on it being a separate rule, but it obviously should be mentioned in the Specification.

dathonohm commented at 6:33 PM on July 29, 2026:

Hi Murch - "P2A" implies empty witnesses, just as "script argument witness items" implies an exception for witness scripts, for example. The rule is correct as stated, and the clarification section is sufficient to remove any ambiguity.

murchandamus commented at 6:41 PM on July 29, 2026:

It’s clearly ambiguous, otherwise we wouldn’t be having this discussion. Further, adding that sentence only restates explicitly what you claim to be implied already. So there shouldn’t be an issue with explicitly stating how P2A is to be treated unless there are other reasons not to include this clarification.

john-moffett commented at 6:50 PM on July 29, 2026:

"P2A" implies empty witnesses

I still disagree. That's like saying "P2MS" necessarily implies "up to 3 keys" because that's standard now. Again, BIP 433 is crystal clear in its definition of P2A.

"Script argument witness items" isn't the same thing. That term describes its own scope (items consumed as script arguments, not the script or control block), so the exception is built into the words, whereas P2A (by itself) doesn't dictate the contents of the spending witness.

dathonohm commented at 6:53 PM on July 29, 2026:

The long definition is already hyperlinked to; I fail to see why anyone reimplementing the spec would somehow miss that section. I can add "(see definition)" if that helps.

dathonohm commented at 7:03 PM on July 29, 2026:

Or, I can extract Rule 3's "ie" clause into another spec subsection that enumerates all of the defined witness versions as of BIP-110.

dathonohm commented at 7:10 PM on July 29, 2026:

@john-moffett: No, "P2MS" has a consensus meaning. "P2A" exists entirely as a policy carveout, and nothing else.

john-moffett commented at 7:25 PM on July 29, 2026:

@dathonohm: No, "P2MS" is merely a template (TxoutType::MULTISIG) added to Bitcoin after its inception just like P2A. Don't confuse OP_CHECKMULTISIG with P2MS.

murchandamus commented at 7:49 PM on July 29, 2026:

Rule 2 links to a definition of what “script argument witness items” are. It’s obviously additional information for implementers if they are unfamiliar with the the term.

Meanwhile, “P2A” is a broadly established concept, so a link titled “P2A” may be easily ignored, but the linked section actually provides part of the consensus rules intended to apply to P2A. While the link would likely be interpreted as a terminology reference, the Specification is ambiguous or incomplete without the information in Rationale. This sets knowledgeable readers (as potential implementers would be) up for thinking “I know what P2A is”, and never seeing the consensus requirement to invalidate P2A inputs with witness data.

Clearly, changes to consensus rules should be explicitly and comprehensively stated in the Specification section. I’ve now spent hours trying to explain this simple issue. This makes me think that information flow is not the issue at hand.

dathonohm commented at 8:13 PM on July 29, 2026:

@john-moffett: I disagree. P2MS is not purely a policy concept. But if it were, and spending P2MS were unconditionally restricted in policy, then it would make sense to use that policy definition in BIP-110.

dathonohm commented at 8:14 PM on July 29, 2026:

@murchandamus I will add a new subsection defining all of the defined witness versions as of BIP-110.

john-moffett commented at 8:35 PM on July 29, 2026:

@dathonohm : I'm not following the purity distinction you're making. Both P2MS and P2A outputs are spent under pre-existing consensus rules. They also have separate standardness policies applied to them.

More importantly, it's mostly beside the point. No implementer will be certain that your interpretation is the intended one from reading Rule 3 and BIP 433. Consensus-critical behavior should be unambiguous.

dathonohm commented at 8:38 PM on July 29, 2026:

Added.

murchandamus commented at 6:06 PM on July 29, 2026: member

Consensus rules should be clearly stated in the Specification section. The Rationale is not the right place for a singular mention of a consensus rule.

murchandamus commented at 7:52 PM on July 29, 2026: member

Just to be clear: NACK ed0d033590cefd109ebd8f523d747e6f3aeb4066. This does not adequately address the issue that not all proposed changes to consensus rules are explicitly and comprehensively described in the Specification.

john-moffett commented at 7:54 PM on July 29, 2026: contributor

NACK https://github.com/bitcoin/bips/commit/ed0d033590cefd109ebd8f523d747e6f3aeb4066. The description of P2A is imprecise and potentially misleading.

dathonohm commented at 8:35 PM on July 29, 2026: contributor

Split "Defined witness versions" into its own subsection. This format should be much harder to misinterpret.

murchandamus commented at 8:40 PM on July 29, 2026: member

Thanks, looks good. The first commit is now obsolete, since it only makes changes that are superseded again by the third commit, so you could drop it. Otherwise ACK 3553edb4c1de737e9f60a195733eb44a4b92832d.

BIP-110: Add Defined witness versions subsection clarifying the rule 3 P2A exemption ae98a6ed47

BIP-110: Add rule 3 test vectors for the P2A empty-witness requirement

Co-Authored-By: jarolrod <jarolrod@tutanota.com>

2dfb201b27

in bip-0110.mediawiki:47 in 3553edb4c1 outdated

  42 | +
  43 | +For the purposes of rule 3, these are the witness versions (and the one Tapleaf version) that are defined as of this BIP:
  44 | +
  45 | +* '''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.
  46 | +* '''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]].
  47 | +* '''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]].

john-moffett commented at 8:49 PM on July 29, 2026:


* '''Witness v1''' with the 2-byte program 0x4e73 (P2A, as defined in [[bip-0433.mediawiki#specification|BIP 433]]), and only when spent with an empty witness stack.

dathonohm commented at 8:53 PM on July 29, 2026:

NACK, this section is already correct.

jarolrod commented at 8:56 PM on July 29, 2026:

I'm trying to remain neutral on new rule or redo rule 3, but it does need @john-moffett suggestion here to be explicit and clear

jarolrod commented at 9:11 PM on July 29, 2026:

As this is a clear omission from the consensus spec, it seems a bump to bip 110 version 2 would be warranted

jarolrod commented at 9:12 PM on July 29, 2026:

Also the & makes this two predicates, we're still doing two rules in one to appease the author

dathonohm commented at 9:17 PM on July 29, 2026:

NACK. The spec was already correct.

jarolrod commented at 9:22 PM on July 29, 2026:

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

dathonohm commented at 9:27 PM on July 29, 2026:

But the author is stating here, as written, that bip433 states a p2a must be spent with an empty witness

That is indeed what it says:

"P2A inputs are considered standard by Bitcoin Core for spending if no witness data is attached." <img width="1019" height="346" alt="Screenshot 2026-07-29 at 15 25 06" src="https://github.com/user-attachments/assets/3ccb8abf-5bd6-46e9-9ed2-251d86595f7a" />

jarolrod commented at 9:29 PM on July 29, 2026:

"Consensus meaning is unchanged"

dathonohm commented at 4:49 AM on July 30, 2026:

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.

delcin-raj commented at 6:54 AM on July 30, 2026:

P2A output type specifically states that no witness data is attached. If witness data is attached to the above specification, can it still be considered P2A? @jarolrod

john-moffett commented at 1:25 PM on July 30, 2026:

@delcin-raj

P2A output type specifically states that no witness data is attached.

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.

If witness data is attached to the above specification, can it still be considered P2A?

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, IsPayToAnchor only looks at the scriptPubKey. It's like asking whether a 6-of-12 P2MS is still considered a P2MS despite it not relaying in Bitcoin Core due to policy. The answer is yes.

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).

john-moffett commented at 5:12 PM on July 30, 2026:

@delcin-raj Moreover, this PR itself also characterizes P2A by the output type, not the spending witness status.

"description": "Spend a PRE-activation P2A output with a non-empty witness stack (grandfathered, exempt)",

dathonohm force-pushed on Jul 29, 2026

dathonohm commented at 8:54 PM on July 29, 2026: contributor

@murchandamus replaced commit 1 with commit 3; contents are identical to before.

murchandamus commented at 9:30 PM on July 29, 2026: member

I second that the phrasing suggested by @john-moffett would be an improvement. I also agree that a version bump would be appropriate, although I could live with something less than a major bump, given the authors’ stance this is just a clarification to an already correct specification.

That said, https://github.com/bitcoin/bips/commit/2dfb201b271d4620baa3ce17cbd8f13d40009668 resolves my main concern that the consensus rules should be documented in the specification.

dathonohm commented at 9:44 PM on July 29, 2026: contributor

@murchandamus I decline to update the wording. It is correct as is. I don't think a version bump is required since the spec was only clarified, not changed, and no prior clarifications of the spec are listed in the changelog either.

john-moffett commented at 9:50 PM on July 29, 2026: contributor

NACK 2dfb201. The description of P2A continues to be imprecise and potentially misleading.

jarolrod commented at 9:52 PM on July 29, 2026: none

I don't want to necessarily get in the way of bip maintainers here as this is becoming a giant time and attention sink, but politely, it would be a disservice to bip433 to allow for the misrepresentation of its contents here.

swoopsus commented at 10:03 PM on July 29, 2026: none

On the BIP-433 attribution — the quoted sentence is one of three in that Specification paragraph, and the two that follow are the ones in dispute:

P2A inputs are considered standard by Bitcoin Core for spending if no witness data is attached. This avoids meaningless witness padding. Consensus meaning is unchanged.

Read whole, that is a standardness claim scoped explicitly to Bitcoin Core, immediately followed by a statement that consensus is unaffected. @instagibbs has confirmed in #2218 that those following sentences exist precisely to prevent the reading being applied here: "It's meant to precisely guard against a mis-reading of it to think that P2A spends cannot have witness data."

So the empty-witness requirement is BIP-110's, not BIP-433's — which is all the line needs to say: "...and only when spent with an empty witness stack. P2A is defined in BIP 433; this witness restriction is imposed by this proposal." That attributes each requirement to the document that imposes it and doesn't require conceding anything about rule numbering.

On the version: if the specification was only clarified and not changed, an implementation built from v1.0.0 alone would already pass the test vectors added in 2dfb201. If it would not, the text changed what implementers build. BIP 3 puts an incompatible specification change at MAJOR, and @murchandamus has offered to accept less. Declining any increment leaves implementers to detect this by diffing the file.

murchandamus commented at 10:44 PM on July 29, 2026: member

@murchandamus I decline to update the wording. It is correct as is. I don't think a version bump is required since the spec was only clarified, not changed, and no prior clarifications of the spec are listed in the changelog either.

It’s unclear to me why you continue to insist on making determinations about the meaning of another BIP, especially one that is so abundantly clear in its phrasing. @john-moffett’s suggestion is a neutral phrasing that sidesteps this unnecessary conflict and clarifies how BIP 110 is implemented correctly without the need to evaluate the meaning of BIP 433. I have already conceded (charitably, if I may say so) to entertain that the existing phrasing of BIP 110 implies the new proposed phrasing.

Anyway, these two PRs are becoming a huge distraction. I’m gonna take another look later this week.

dathonohm commented at 11:18 PM on July 29, 2026: contributor

@murchandamus I agree. I think the current phrasing, "Witness v1 with the 2-byte program 0x4e73 (P2A), and only when spent with an empty witness stack, as defined in BIP 433" is not incorrect or misleading in any way. BIP-433 objectively contains text about requiring an empty witness.

8144225309 commented at 2:26 AM on July 30, 2026: none

NACK 2dfb201

delcin-raj commented at 6:56 AM on July 30, 2026: none

ACK

arturkokurc1-prog commented at 10:20 PM on August 1, 2026: none

Hbvfd