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

[dathonohm]

No description provided.

[jonatack]

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

[dathonohm]

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

[luke-jr]

Looks fine to me

[dathonohm]

Added test vectors.

[murchandamus]

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]

Just to be clear: NACK ed0d033. 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]

NACK ed0d033. The description of P2A is imprecise and potentially misleading.

[dathonohm]

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

[murchandamus]

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 3553edb.

[dathonohm]

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

[jarolrod]

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]

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

[jarolrod]

"Consensus meaning is unchanged"

[dathonohm]

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]

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]

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

@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)",

[murchandamus]

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, 2dfb201 resolves my main concern that the consensus rules should be documented in the specification.

[dathonohm]

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

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

[jarolrod]

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]

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]

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

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

NACK 2dfb201

[delcin-raj]

ACK