BIP-110: document P2A empty-witness consensus rule - #2218
Conversation
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.
|
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
left a comment
jonatack
left a comment
There was a problem hiding this comment.
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.
No worries, I can rebase/update there. |
jonatack
added
Proposed BIP modification
|
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
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. |
|
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. |
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 Commit bitcoinknots/bitcoin@38996fb says This is a new independent rule that cannot be derived or extended from rule 3 |
|
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. |
|
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. |
|
Concept ACK |
|
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. |
|
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. |
|
Concept ACK |
|
Obviously I'm biased, but I think the text is quite clear? "Specification 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. |
|
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. 
|
|
@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. |
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'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. |
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. |
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 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. |
There was a problem hiding this comment.
Concept ACK. Assuming that the BIP110 authors are interested in enabling other implementers to be consensus compatible with their reference implementation, at least adopting the previously missing test vectors and a clarification on P2A should be an obvious improvement.
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.
It seems to me that Dathon Ohm’s explanation on Twitter highlights brilliantly where this interpretation goes awry:
The consensus change for P2A inputs is highlighted as an important change in the release from February 12th:
BIP 110 only mentions P2A as a defined native segwit output that is acceptable:
Even if we accept that Rule 3 implies that P2A inputs with a non-empty witness are consensus invalid, it would obviously improve the clarity of the specification to explicitly state how P2A inputs are to be evaluated per the proposal.
If the authors object to the characterization as an eighth rule, they could e.g. either suggest a concrete alternative phrasing here or submit their own PR that adds the clarification to Rule 3.
@dathonohm to move this forward the most quickly, could you please accept this PR, and at your convenience open a PR if you wish for 433? Let's help implementers of this BIP as best we can. |
|
@instagibbs: if "consensus meaning is unchanged" means "the BIP prescribes no new consensus meaning", then that part of BIP-433 is not applicable to this discussion. If P2A's consensus meaning were relevant, then P2A would not need to be included in BIP-110 at all. The reason BIP-110 mentions P2A is because it is a policy carveout which is elevated to consensus. This policy carveout includes a requirement that P2A spends have an empty witness, so this requirement is accordingly included in BIP-110. The more confusing meaning for "P2A" is "a policy carveout that includes some of the requirements in Bitcoin Core, but not all of them". |
@dathonohm I object to the manner that you are handling this clarification for implementers of this BIP. I have tried to be fair and neutral, but you're not being helpful. |
|
This PR claims it is a new rule or a material change. That is objectively false. |
|
@luke-jr The goal is to make it easier for developers to be compliant with BIP 110. The "new rule" part is of little importance and IMO objecting there doesn't help your cause. Being as helpful as you can to implementers helps your cause. |
|
As I suggested to Dathon on Twitter, just adding “P2A inputs with a non-empty witness stack are invalid.” to the third rule would remove the ambiguity. |
|
Concept ACK |
|
@dathonohm You are the one blocking here since the start. Your alternative PR isn't as complete as this one. I object to the game-playing you have been doing here, including accusing the PR author of trolling in #2218 (comment), which I moderated. IMO you and @luke-jr are footgunning in the way you have been handling this. |
This comment was marked as abuse.
This comment was marked as abuse.
|
@dathonohm That is where you have been footgunning. The goal isn't to discredit anything. The goal is to make it easier for developers to be compliant with BIP 110. |
|
Adding an 8th rule is incorrect and unacceptable. If your honest goal is to clarify what "P2A" means for developers, then you will accept #2225 instead, which is more than sufficient. The only reason you would merge something incorrect like this PR is to cause drama. |
@dathonohm To be clear, only the author (you) can update the BIP, so nobody will be merging this without your approval. |
|
luke-jr:
As BIPs progress through the Status stages in the workflow, they become increasingly co-owned by the Bitcoin ecosystem. At the Complete stage, BIP authors have recommended their proposal for adoption and it is in the ecosystem’s interest for the proposal to be comprehensive and unambiguous. While the authors’ input certainly has weight, I don’t think their interest to sweep issues under the carpet supersedes the ecosystem’s interest in an ambiguous Specification being clarified. via BIP3: Further, it is my understanding that both Dathon and Luke have argued that it was already intended for BIP110 to forbid P2A inputs with witness data. BIP3 says: 
Since both Dathon and Luke agree that P2A inputs with witness data were intended to be invalid, explicitly stating this in the specification does not change the meaning or conflict with the intent of the authors. I don’t think it’s necessary to insist on it being phrased as an eighth rule, but it obviously belongs in the specification. I suggest @dathonohm update his PR to add it to Rule 3 as a middleground so we can all move on. |
|
Hi Murch - this has been clarified in #2225. Please close this incorrect PR. |
Since I am referring to your latest state of #2225, where you mention the invalidity of P2A inputs with witness data only in the Rationale, clearly it has not been clarified in your alternative PR. I’m happy to close this PR when a satisfactory PR has been presented and merged. If you are not going to open one, I’m happy to propose one myself. |
|
I'm trying to better understand the current consensus behavior rather than BIP-110 itself. My understanding is that today a P2A spend with a non-empty witness is considered non-standard by Bitcoin Core, so it won't enter the mempool or be relayed. However, suppose a miner deliberately modifies their software to ignore that policy and includes such a transaction in an otherwise valid block. When that block reaches other Bitcoin Core nodes, would it be accepted or rejected during block validation? I would expect this to be determined by the current consensus rules (and likely covered by existing tests), rather than being a matter of interpretation. My confusion also comes from how I read BIP-433 itself. It is classified as Peer Services, explicitly describes standard transactions in Bitcoin Core, and also states that "Consensus meaning is unchanged." As someone trying to understand the current implementation, that naturally leads me to interpret it as describing a policy behavior rather than introducing a new consensus rule. If that is not the intended interpretation, I would appreciate some clarification on how the combination of its classification and wording should be understood. My current understanding is the following, and I'd appreciate being corrected if it's wrong:
This is precisely why I'm uncertain about BIP-433. Based on its classification, wording, and the statement "Consensus meaning is unchanged," my expectation as a reader is to interpret it as a policy-only specification. If I'm misunderstanding this, I'd really appreciate being pointed to the relevant consensus code or test that defines the current behavior. |
|
@murchandamus: #2225 is satisfactory. It hyperlinks to the P2A definition, which is the same thing we did for Rule 2. This PR is incorrect, strictly worse, and should be closed. |
see these test lines in knots: https://github.com/bitcoinknots/bitcoin/blob/29.x-knots/test/functional/mempool_accept.py#L411-L426 |
|
Just to be clear: NACK d347d84 |
|
More of a question than a comment, following on from @ishi0k 's > My understanding is that today a P2A spend with a non-empty witness is considered non-standard by Bitcoin Core, so it won't enter the mempool or be relayed. ..... When that block reaches other Bitcoin Core nodes, would it be accepted or rejected during block validation? Am I correct in my attempt to summarize things below? Before BIP-110 and before BIP-433, spends of P2A outputs with a non-empty witness were consensus valid. They may, or may not, have been standard on one or more implementations, but we're discussing consensus - not relay policy - here. Today, prior to BIP-110 activation, they are still consensus valid on the network. If they were consensus invalid today, that would imply that BIP-433 was an accidental soft fork, a soft fork that converted them from valid to invalid. So BIP-433 was not a soft fork. It didn't intend to propose a consensus change, and nor did any developer implement it as a consensus change If and when BIP-110 activates, such spends will be consensus invalid according to the implementation of the activation client. This is therefore a consensus change, and it's a consensus introduced by BIP-110's activation. It is not the case the BIP-433 was supposed to be a soft fork, and we're using BIP-110 to retrospectively fix our accidental failure to implement the "BIP-433 softfork" |
|
Concept ACK The BIP-433 sentence:
implies the existence of the following potential (and correct) sentence:
i.e. such spends (consensus valid, but non-standard according to one implementation) are definitively still P2A (as otherwise, that sentence couldn't start with "P2A") In other words, what @instagibbs said earlier:
As such spends are therefore P2A, the current BIP-110 BIP does exempt them from change, i.e. they are still consensus valid according to the current BIP. But this unambiguously contradicts the latest implementation of the BIP-110 activation client |
|
A "$foo spend" is just shorthand for saying "a spend of a $foo output"; the interpretation of bip 433 by luke and dathom that a spend of a p2a output with a (non-empty) witness is not a p2a spend is simply wrong. That said, BIP 3 states "Each BIP is primarily owned by its authors and represents the authors’ opinion or recommendation." so it ultimately doesn't matter if the authors are wrong, their bip should reflect their views, and the appropriate way to present a corrected view that they dispute is by publishing a new bip, as was done with bip 343 (vs bip 341/deployment). |
|
Concept ACK |
|
Concept NACK. |
|
Closing as it's up to @dathonohm to accept, and he has rejected. Happy to open up if bip maintainers see his PR as unacceptable, as it is my stance it is. Effort and time should be on helping people migrate their coins. |
17 participants
BIP 110 currently lists seven consensus rules. The Bitcoin Knots implementation developed before BIP 110 reached
Completestatus 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-knotson May 2, 2026; both before BIP 110 becameComplete.BIP 3 classifies an incompatible specification change as a MAJOR version increment. Therefore, this PR updates the version to
2.0.0The generator adds four 8th rule cases:
The generator was run against a local Bitcoin Knots build with
REDUCED_DATAactive at regtest height 432.