BIP-110: document P2A empty-witness consensus rule #2218

jarolrod commented at 4:28 PM on July 26, 2026: none

BIP 110 currently lists seven consensus rules. The Bitcoin Knots implementation developed before BIP 110 reached Complete status added an eighth rule: while the deployment is active, a spend of a non-grandfathered Pay-to-Anchor (P2A) output is invalid if that input's witness stack is non-empty. This pull request brings the BIP's text and test vectors into line with that existing implementation.

The P2A rule (8th BIP110 consensus rule) was authored on Feb 12, 2026 and merged into 29.x-knots on May 2, 2026; both before BIP 110 became Complete.

BIP 3 classifies an incompatible specification change as a MAJOR version increment. Therefore, this PR updates the version to 2.0.0

The generator adds four 8th rule cases:

Vector	Expected result
Post-activation P2A output, empty witness stack	Valid
Post-activation P2A output, one empty witness element	Invalid
Post-activation P2A output, one one-byte witness element	Invalid
Pre-activation P2A output, non-empty witness stack	Valid under UTXO grandfathering

The generator was run against a local Bitcoin Knots build with REDUCED_DATA active at regtest height 432.

BIP-110: document P2A empty-witness consensus rule

BIP 110 version 1.0.0 documents seven consensus rules, but Knots, which
serves as the reference implementation client for this BIP, commit
38996fb added an eighth before the BIP reached Complete.

The 8th undocumented rule asserts that during the active deployment, a
spend of a non-grandfathered P2A output is invalid when its witness
stack is non-empty.

This adds the missing consensus rule to the BIP, explain its
relationship to BIP 433 policy and UTXO grandfathering, and links the
Knots implementation.

Additionally, we add vectors for an empty stack, a stack containing an
empty element, a one-byte element, and a grandfathered
pre-activation P2A output.

Additionally, Add the proper "Version: 2.0.0" header.

d347d84132

jarolrod commented at 4:29 PM on July 26, 2026: none

this conflicts with #2203 as I introduce the version header here

I can remove here if you want to keep it a part of that PR instead.

jonatack added the label Bug fix on Jul 26, 2026

jonatack commented at 4:50 PM on July 26, 2026: member

Concept ACK. Thanks for adding tests. My understanding is that this is an unintended discrepancy between BIP 110 and the implementation in Knots that was discovered by the PR author during a commissioned review, and it's good that such review is taking place. It seems important to align the BIP and the implementation in Knots for the case if BIP 110 were to activate with the current Knots implementation and another bitcoin client implemented the BIP. Pinging @dathonohm for feedback or sign-off.

jonatack commented at 4:52 PM on July 26, 2026: member

this conflicts with #2203 as I introduce the version header here

I can remove here if you want to keep it a part of that PR instead.

No worries, I can rebase/update there.

jonatack added the label Proposed BIP modification on Jul 26, 2026

jonatack added the label Pending acceptance on Jul 26, 2026

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

Concept NACK. There is no "8th rule", this is just the definition of P2A, as (poorly phrased but) specified in BIP 433.

jarolrod commented at 5:24 PM on July 26, 2026: none

@luke-jr

Concept NACK. There is no "8th rule", this is just the definition of P2A, as (poorly phrased but) specified in BIP 433.

The definition of P2A in BIP 433 states

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.

This states that standardness for this transaction is that it have no witness data; but it is not a consensus meaning. The authors of BIP 433 go even further to explicitly state "Consensus meaning is unchanged."

As such bitcoin core does not make the change implemented here

Implementing this is a new consensus change, that goes against BIP 433.

It's really quite clear.

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

BIP 433 only standardizes the definition of P2A. The specification includes the empty witness when spending.

BIP 110 turns it into a de facto consensus rule by way of Rule 3.

This is quite clear to any honest reading. If you want to clarify it further, idc, but it's not a material change.

jarolrod commented at 5:42 PM on July 26, 2026: none

3 only standardizes the definition of P2A. The specification includes the empty witness when spending.

BIP 110 turns it into a de facto consensus rule by way of Rule 3.

This is quite clear to any honest reading. If you want to clarify it further, idc, but it's not a material change.

the change in https://github.com/bitcoinknots/bitcoin/commit/38996fb57a695f45af44e85bba265508fc598088 explicitly goes against the consensus meaning of p2a as defined in bip 433

Additionally your logic here does not derive from rule 3

Where rule 3 says

invalid := undefined_witness_or_tapleaf_version

Commit https://github.com/bitcoinknots/bitcoin/commit/38996fb57a695f45af44e85bba265508fc598088 says

invalid := invalid || (is_p2a && !witness_stack.empty())

This is a new independent rule that cannot be derived or extended from rule 3

dathonohm commented at 7:51 PM on July 26, 2026: contributor

Agree with Luke, this appears to be based on a misreading of BIP-433, which requires an empty witness. The spec is already correct.

However, if the author would like to clarify rule 3 to prevent others from making the same misreading, I will accept that. The additional test vectors also look useful, though I would require that references to "Rule 8" be eliminated.

Rob1Ham commented at 1:36 AM on July 27, 2026: none

Concept ACK

I'm not sure why non authors of BIP 433 get to authoritatively declare a meaning that exists outside of the documentation.

I concur with @jarolrod's reading of the BIP, and 110's inconsistent integration of BIP 433 rules is a 110 issue, not 433.

cbspears commented at 1:42 AM on July 27, 2026: none

Concept ACK

rot13maxi commented at 2:18 AM on July 27, 2026: none

Thanks for adding this @jarolrod. This change is helpful to wallet and protocol developers who want to make sure their anchor outputs work on both chains.

lifofifoX commented at 2:34 AM on July 27, 2026: none

Going by this statement from @dathonohm, they seem to misunderstand the meaning of what constitutes a P2A spend.

As per BIP 433, P2A is a new standard output script, and its definition is not dependent on how it's spent. Thanks @jarolrod for addressing this.

rodpalmerhodl commented at 12:34 PM on July 27, 2026: none

Concept ACK

instagibbs commented at 1:48 PM on July 27, 2026: member

Obviously I'm biased, but I think the text is quite clear?

"Specification A P2A output is defined as one with the scriptPubKey

OP_1 <0x4e73>[1]

corresponding to the addresses bc1pfeessrawgf on Bitcoin mainnet, <tb1pfees9rn5nz on public testnets, and bcrt1pfeesnyr2tx on regtest.

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

There is only one condition to call something a P2A listed, and it explicitly calls out that padding the witness doesn't change the output template type.

I'll entertain a PR to update wording naturally if there's a solid idea to make it less confusing? I will not change the definition to mean P2A must have no witness, that is not the intention.

jonatack commented at 3:51 PM on July 27, 2026: member

Approach ACK, utACK d347d84132ea7d3efcc778323fccfa94f0a60033

I'm agnostic on the semantics discussion on whether to expand rule 3 or describe a new one as done here, modulo that this approach is more explicit and likely clearer to implementers. It was also appended separately later in Knots as well, and was one of 8 rules in the PR to bitcoin core description by the BIP author (image below). It makes sense and is helpful, so non-judgmental ACK from me.

dathonohm commented at 10:15 PM on July 27, 2026: contributor

@instagibbs: "P2A" as a concept is only a policy carveout, which includes both the expected output format, and the expected spend format. BIP-110 elevates this policy carveout to the consensus level. P2A does not exist as a consensus concept, so the note about the consensus meaning being "unchanged" is confusing; it is not clear what "consensus meaning" would even refer to here.

Anyway, I think "spends of P2A outputs that are not empty are undefined" is a completely reasonable reading of BIP-433 since, again, P2A is only defined by Bitcoin Core's unconditional policy rules. @jonatack: It made sense to put the P2A rule by itself on the PR description, since Rule 3 is not included either. The third bullet point combines Rules 3 and 6 by describing the variable names used rather than reiterating the exact rules as specified on BIP-110. This was to give reviewers more detail about the actual implementation changes, to assist them in their reviews. Of course, all of this could have been clarified if Core maintainers had left the PR open for longer than 5 seconds. Indeed, that PR with that description was submitted over 4 months ago now, so any ambiguity would have been long since resolved.

I will consider accepting this PR as is if BIP-433 is clarified first to explicitly state that P2A spends without an empty witness are still considered P2A spends; otherwise I will accept a modified version of this PR that drops Rule 8 and clarifies Rule 3 instead.

instagibbs commented at 10:36 PM on July 27, 2026: member

P2A does not exist as a consensus concept, so the note about the consensus meaning being "unchanged" is confusing;

The BIP prescribes no new consensus meaning, so it is unchanged. It's meant to precisely guarding a mis-reading of it to think that P2A spends cannot have witness data. If it helps to say something more like "continues to have no enforced consensus meaning" or similar, that could make sense.

I will consider accepting this PR as is if BIP-433 is clarified first to explicitly state that P2A spends without an empty witness are still considered P2A spends

I'm still unaware where the confusion stems from. Please just open a PR with your suggestion and I'll take a look, but the spec I copied and pasted is very short, black and white.

jonatack commented at 12:15 AM on July 28, 2026: member

otherwise I will accept a modified version of this PR that drops Rule 8 and clarifies Rule 3 instead

I did ask @jarolrod what that might look like, and from I saw it did not look preferable. I'll leave it to Jarol to fill in more details on that, if he wishes.

jarolrod commented at 12:49 AM on July 28, 2026: none

@dathonohm

Anyway, I think "spends of P2A outputs that are not empty are undefined" is a completely reasonable reading of BIP-433 since, again, P2A is only defined by Bitcoin Core's unconditional policy rules.

Here's a link to functional tests written by @instagibbs and present in the knots codebase that should have been referred to:

https://github.com/bitcoinknots/bitcoin/blob/29.x-knots/test/functional/mempool_accept.py#L411-L426

note this line in the knots codebase: https://github.com/bitcoinknots/bitcoin/blob/f41f01e1e6de7025d52a865bef97f2a67277f0f3/test/functional/mempool_accept.py#L425

Which states, after declaring a p2a anchor with witness is non-standard " # but is consensus-legal" @jonatack @dathonohm

This is a new rule, the logic sequence here shows it through logic as it is an & on top of the rule 3 text: #2218 (comment)

To put it into rule 3 is to have a rule with two predicates. Additionally rule 3 would have to be rewritten for its p2a carve out & stuff in a new predicate on empty witness stack for p2a.