#36466 policy: make unstructured Taproot annexes standard
| Reviewability | Reviews | Agreement | Size | ||||
|---|---|---|---|---|---|---|---|
| #36466 policy: make unstructured Taproot annexes standard | Ready | 1 | Positive | 28 + 245 tests | |||
|
|
|
| ||||
Reviewability: ReadyStalePaused Agreement: StrongPositivePositive w/ caveatsNeutralMildDisputedBlockedCrickets Reviews: current code-review ACKs, then (+stale ACKs) and -NACKs; greener = more ACKs. Size: lines added or modified outside tests, then in tests; greener = smaller. | |||||||
Goal
Updates standardness policy in IsWitnessStandard to allow Taproot transactions with annexes, provided the annex is either marker-only (0x50) or unstructured data prefixed with 0x50 0x00. All non-P2A inputs in a transaction must include an annex if any input does, while native P2A inputs are exempt from opting in. Other annex prefixes remain non-standard, and annex weight is bounded only by the standard transaction weight limit.
Problem: BIP 341 Taproot annexes are currently treated as non-standard by mempool policy, preventing nodes from relaying or accepting standard transactions that utilize annexes for arbitrary data or marker-based opt-in.
Evidence of importance:
- PR description: 'Builds on #27926 and Libre Relay' and 'This opt-in rule protects transactions that do not opt in. It does not prevent annex inflation by opted-in participants.'
- Commit aa85bd97d1: 'Permit marker-only annexes and annexes whose first byte after the 0x50 marker is 0x00, reserving other prefixes for future semantics.'
Risk of a mistake: medium (mempool_policy). Mistakes in standardness checks could permit standard relay of transactions exposed to pinning or witness inflation attacks, or lead to inconsistent relay policy across the network.
Changed since the previous assessment: Now provides the full patch including the P2A input exemption logic in IsWitnessStandard, unit tests in transaction_tests.cpp, and functional test coverage in feature_taproot.py.
Reviewability
Ready
Nothing known that would invalidate a review now.
Waiting on (from the thread read):
- reviewer: sipa to evaluate author's response on motivation and purpose 2026-10-22
Agreement
Positive
support without stated reasons, no open objection (petertodd, Rob1Ham)
Thread notes: Added Rob1Ham's ACK to support and participants list.
Objections, suggestions, and questions:
| Reviewer | Type | Harm, request, or question | Status | Must be | Author replied | Quote |
|---|---|---|---|---|---|---|
| petertodd (contributor) | objection, correctness | spends of P2A outputs cannot contain an annex and must be excluded from the annex rule | fixed · fix pushed · exempted native P2A inputs in bb6ccd0 | changed | yes | 2026-10-08: 'We should exclude spends of P2A outputs here, as they can't contain an annex.' Status from: 2026-10-08: RobinLinus: 'fixed in bb6ccd0. Native P2A inputs are exempt; their witnesses must remain empty.' |
| petertodd (contributor) | suggestion, maintenance | re-add the 'witness stuffing detected' comment to explain the line's purpose | fixed · fix pushed · addressed in b4179ad | answered | yes | 2026-10-08: 'You should re-add the "witness stuffing detected" comment here to explain what this line is doing.' Status from: 2026-10-08: RobinLinus: 'addressed in b4179ad' |
| petertodd (contributor) | suggestion, maintenance | move the comment about P2A inputs and the annex to this location | fixed · fix pushed · addressed in b4179ad | answered | yes | 2026-10-08: '...and the comment about P2A inputs and the annex probably makes more sense here.' Status from: 2026-10-08: RobinLinus: 'addressed in b4179ad' |
| petertodd (contributor) | question, correctness | why the fragment skipping further checks if scriptWitness is empty is there when it seems unrelated to annexes | answered · author explained empty-witness check moved below P2A handling in b4179ad | answered | yes | 2026-10-08: 'I'm confused by this fragment. It doesn't look like it's related to the annex stuff at all.' Status from: 2026-10-08: RobinLinus: 'The empty-witness check moved below P2A handling so anchors are counted before the early `continue`.' |
| petertodd (contributor) | suggestion, maintenance | clarify comment to state annexes must be zero-length or start with unstructured prefix 0x00 | fixed · fix pushed · addressed in b4179ad | answered | yes | 2026-10-08: 'It'd be more clear to say that "Annexes must be zero-length, or start with the unstructured data prefix, 0x00"' Status from: 2026-10-08: RobinLinus: 'addressed in b4179ad' |
| petertodd (contributor) | suggestion, maintenance | explain in comment why unstructured marker 0x00 is used and reserved for future consensus use | fixed · fix pushed · addressed in b4179ad | answered | yes | 2026-10-08: 'We should explain why the unstructured marker is being used here: 0x00 is reserved, so that future consensus-related usage of the annex can use a different prefix' Status from: 2026-10-08: RobinLinus: 'addressed in b4179ad' |
| petertodd (contributor) | suggestion, maintenance | use the term 'transaction pinning attack' in the comment | fixed · fix pushed · addressed in b4179ad | answered | yes | 2026-10-08: 'You should use the term "transaction pinning attack" here, so people have something to google.' Status from: 2026-10-08: RobinLinus: 'addressed in b4179ad' |
| sipa (member) | suggestion, usefulness | clarify the purpose and value of standardizing annexes before consensus meaning is added or active network use exists | answered · author explained motivation for data availability for metaprotocols and P2P relay | answered | yes | 2026-10-20: 'What is the purpose of this? I was imagining that annex standardness would be added at the same time consensus-relevant meaning would be given to annexes.' Status from: 2026-10-22: RobinLinus: 'The motivation is data availability for metaprotocols, including a range of shielded protocols' |
Support:
- petertodd (contributor) (ACK, 2026-10-12): (no reason given) [not substantive]
- Rob1Ham (contributor) (ACK, 2026-10-24): (no reason given) [not substantive]
Participants:
- petertodd (contributor, support, 8 statements 2026-10-08 to 2026-10-12): utACK b4179ad after earlier objection on P2A input handling and comments were addressed
- sipa (member, question, 1 statements 2026-10-20 to 2026-10-20): questioned the purpose of standardizing annexes without consensus meaning or active network use
- Rob1Ham (contributor, support, 1 statements 2026-10-24 to 2026-10-24): ACK with no rationale
Files
260 lines under test/bench/ci.
- src/test/transaction_tests.cpp +152/-0
- test/functional/feature_taproot.py +93/-15
- src/policy/policy.cpp +25/-11
- src/policy/policy.h +2/-1
- src/script/interpreter.cpp +1/-1
Card
The short text the ranking pass compares across PRs.
Relaxes mempool policy to treat Taproot annexes as standard if they consist solely of the 0x50 marker or unstructured data starting with 0x50 0x00. Under current policy, any Taproot transaction with an annex is rejected from standard mempools. To protect multi-party transactions against unilateral witness inflation or pinning, the rule requires all non-P2A inputs in a transaction to include an annex if any input does. The PR revisits the concept from closed PR 27926 and Libre Relay without citing new external user requirements.
Data
thread read through 2026-10-24 (13 statements), head b4179ad2fb
labels: TX fees and policy
Categories
Mempool and policy
P3 · new feature (assessed alone as P2; Demoted from P2: policy relaxation revisiting a closed PR with no cited downstream demand ranks below the bug fixes and the demand-backed policy change #36540.)
Permitting marker-only and unstructured Taproot annexes expands standard transaction relay policy for BIP 341 annex use cases. Policy expansions with protocol implications warrant deliberate review attention regarding DoS and third-party malleation risks.
Membership: Carries the 'TX fees and policy' label and modifies standardness rules in 'src/policy/policy.cpp' and 'src/policy/policy.h'.
Factors: security/stability 1, bug 0, performance 0, user value 2, leverage 1