BIP-110: document P2A empty-witness consensus rule

[jarolrod]

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.

[jarolrod]

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]

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]

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.

[luke-jr]

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

[jarolrod]

@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]

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]

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 bitcoinknots/bitcoin@38996fb 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 bitcoinknots/bitcoin@38996fb says

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

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

[dathonohm]

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]

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]

Concept ACK

[rot13maxi]

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]

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]

Concept ACK

[instagibbs]

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]

Approach ACK, utACK d347d84

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]

@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]

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]

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]

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