BIP431: Opt In Topologically Restricted Until Confirmation Transactions For More Robust Fee-bumping

[glozow]

This is a BIP for Topologically Restricted Until Confirmation (TRUC) Transactions. It's also called "v3 transaction policy" since the marker is nVersion=3.

A specification is useful for coordination between node impls that want to implement the same policy and applications that want to use it. For those that are not interested in the details of v3 policy, this also serves as a writeup of the specific pinning problems we aim to address. There has been discussion of using this in other protocol design and multiple requests for its documentation to exist in the BIPs repository, so I'm opening a PR here.

Implementation:

• v3 transaction policy for anti-pinning bitcoin#28948
• policy: restrict all TRUC (v3) transactions to 10kvB bitcoin#29873
• policy: bump TX_MAX_STANDARD_VERSION to 3 bitcoin#29496

Example usage and things built on top:

• Package RBF
  • Cluster size 2 package rbf bitcoin#28984
• Ephemeral Anchors
  • Ephemeral Anchors bitcoin#29001
  • Ephemeral Dust #1524
• LN commitment transactions
  • https://delvingbitcoin.org/t/lightning-transactions-with-v3-and-ephemeral-anchors/418
  • https://github.com/instagibbs/bolts/commits/zero_fee_commitment
• LN-Symmetry
  • https://delvingbitcoin.org/t/ln-symmetry-project-recap/359
  • https://github.com/instagibbs/lightning/tree/eltoo_support

Discussion and history:

• https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019817.html
• https://gist.github.com/glozow/25d9662c52453bd08b4b4b1d3783b9ff
• https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020937.html
• https://delvingbitcoin.org/t/v3-transaction-policy-for-anti-pinning/340
• policy: nVersion=3 and Package RBF bitcoin#25038

[t-bast]

FWIW, concept ACK :)

[murchandamus]

ACK 4bd12d5

[glozow]

Thanks @murchandamus, took all your suggestions (4bd12d5...af8e903)

[ismaelsadeeq]

Concept ACK

[glozow]

@luke-jr this has been open for a month, would you mind taking a look?

[ariard]

I think this should document that 1000 vb child limit is experimental and it cannot be relied on by downstream projects.
This opt-in policy is not robust towards NTA pinning (cf. “The Good, The Bad, The Ugly” 2020 mail) and “loophole” pinning exposed in Core’s #28948. This can note that additional opt-in policy might be applied on top of nversion=3 see Core’s #29454.

[murchandamus]

ACK 63e8a71

[glozow]

Thanks @murchandamus! Accepted your suggestions.

[luke-jr]

As with #1524, node policy is not a standardizable subject matter in itself - every node decides its own policy. BIP 125 already defined a way for wallets to indicate they prefer RBF-like treatment of their transactions, and I don't see why the same signal can't be used for this.

[vostrnad]

Every node deciding its own policy is not mutually exclusive with it being standardizable – each node decides which (if any) standards to follow. Policy standards make just as much sense as e.g. wallet standards or P2P protocol standards.

[Roasbeef]

BIP 125 already defined a way for wallets to indicate they prefer RBF-like treatment of their transactions, and I don't see why the same signal can't be used for this.

BIP 125 defines a set of rules w.r.t transaction replacement. Some of those rules have edge cases that can lead to defects where transactions that should otherwise be replaced, can't be replaced. This class of replacement defects loosely falls under the umbrella of "transaction pinning". The TRUC rules resolve those issues, creating a replacement semantics that better serve off-chain protocols, and address some known pinning vectors. For many off-chain protocols, TRUC will supersede base RBF. As the semantics are distinct, it cannot use the existing sequence fields carved out by BIP 125 (the rules are also incompatible). Instead, it uses transaction v3 (no longer non standard) as a way to signal replacement under a distinct set of rules.

[luke-jr]

BIP 125 defines a signalling mechanism, not policy (which is again outside the scope of BIPs) even if it describes a particular policy. The intent of the signal is clear, and it can be implemented in other ways such as the one that seems to be desired here.

[Roasbeef]

BIP 125 defines a signalling mechanism, not policy

It clearly defines both:

The opt-in full Replace-by-Fee (opt-in full-RBF) signaling policy described here allows spenders to add a signal to a transaction indicating that they want to be able to replace that transaction in the future

This policy specifies two ways a transaction can signal that it is replaceable.

Inherited signaling: Transactions that don't explicitly signal replaceability are replaceable under this policy for as long as any one of their ancestors signals replaceability and remains unconfirmed.

Because descendant transactions may also be replaceable under this policy through inherited signaling, any method used to process opt-in full-RBF transactions should be inherited by any descendant transactions for as long as any ancestor opt-in full-RBF transactions remain unconfirmed.

It also defines a precise set of rules for the policy. If an implementation deviates from those rules, then it isn't BIP 125. From the OP, there's a clear need to define a new policy and signalling mechanism, which this document does.

[luke-jr]

It may be poorly worded, but that isn't the point.

[luke-jr]

(Note that BIP 125's relationship with policy was a matter of discussion back when it was submitted, and it was nearly rejected - the only reason it was accepted in the end, was as a signalling BIP. And even if you want to insist it defines policy, mistakes made in the past would not be a reason to repeat them in the future, and thus would actually work against accepting this proposal)

[carlaKC]

ACK 32e4e44

With the tiny non-blocking nitpick that a few places in the doc use markdown _ for italics (I think) where they should use '' for mediawiki italics.

[murchandamus]

This looks good to me and ready to go except for a couple nits (which I don’t think would need to hold up a merge) and a formatting issue:

1. The JEDEC standard specifies that uppercase K (kilo) refers to 1024¹ (and M (mega), G (giga) as 1024² and 1024³ respectively). However, since the numbers in your example are referring to a factor of 1000¹, they should be using lowercase k, the symbol of the metric prefix kilo referring to a factor of 1000¹. Therefore, it would be preferable if the units were updated to read "kvB" instead of "KvB", and "ksats" instead of "Ksats".

2. AFAIU, technical writing standards generally recommend a space between the numerical value and unit symbol.

E.g. using a space is recommended by the SI Standard,
^{via https://www.nist.gov/pml/special-publication-330/sp-330-section-5}

by NIST,
^{via https://physics.nist.gov/cuu/Units/checklist.html}

as well as IEEE:
^{via https://academia.stackexchange.com/q/54885/8305}

My personal preference is to separate the value and symbol with a Narrow No-Break Space (U+202F) as that provides the expected visual offset, renders as a smaller gap than a full length space, but still prevents unfortunate line breaks. My suggested changes already make use of NNBSPs.

[murchandamus]

Oops, I overlooked a couple more values

[glozow]

Thanks @carlaKC @murchandamus! I've fixed the italics, spacing, and "k".

[carlaKC]

re-ACK 04d3a06 🤩

[glozow]

(I think this is ready, please lmk if there's anything left to do on my end)

[jonatack]

ACK 04d3a06

Re-checked the RBF rules vs description headers.

[jonatack]

Updated for bitcoin/bitcoin#29873 👍

[jonatack]

With bitcoin/bitcoin#29496 on the table, note to possibly consider updating/appending to https://github.com/bitcoin/bitcoin/blob/master/doc/policy/mempool-replacements.md#current-replace-by-fee-policy with TRUC at some point (and making sure the multiple links to it in this BIP remain valid).

[petertodd]

This BIP is missing an explanation of how it is expected to work with future nVersion upgrades.

Eg if we add a third consensus critical transaction version, how should that interact with TRUC? Do we just add another version?

Obviously this is a serious drawback of mixing up mempool behavior and consensus code.

[murchandamus]

It seems to me that BIP 431 only applies to version 3 transactions. So, I’m not sure I understand your concern. If someone e.g. proposed giving meaning to version 4 in say a BIP-v4, it could propose how transactions with version 3 should interact with transactions of version 4 and then whoever implements BIP-v4 would follow those recommendations, while those that don’t implement it, would not.

[petertodd]

TRUC behavior is not desirable for all transactions; it is not a clear upgrade. Thus, the obvious question is how do we expect a future soft fork version upgrade to deal with this? For example, consider what would have happened had we tried to introduce TRUC prior to v2 transactions. This can of course be avoided by not using a version number to signal TRUC behavior. I do not see a reason why we actually need to do that, given how narrow the actual usage of TRUC is likely to be. Triggering it simply on zero fee transactions should be fine.

…

On July 8, 2024 4:58:22 PM GMT+02:00, murchandamus ***@***.***> wrote: I’m not sure I understand your concern. If someone e.g. proposed giving meaning to version 4 in say a _BIP-v4_, it could propose how transactions with version 3 should interact with transactions of version 4 and then whoever implements BIP-v4 would follow those recommendations, while those that don’t implement it, would not.

[glozow]

I'd imagine that the author of a proposal that defines a new consensus rule under version=3 would consider what usage exists on the network, particularly if the rules described in this BIP are adopted by the network when that proposal is created. They would probably also want to explain why gating it on version=3 (or any version-related marker at all) is necessary.

Of course, coordinating between all the many proposals may not be easy. Are you perhaps making an argument for why we should document proposed uses of version=3 in a central place to avoid creating and deploying conflicting uses?

[murchandamus]

TRUC behavior is not desirable for all transactions; it is not a clear upgrade. Thus, the obvious question is how do we expect a future soft fork version upgrade to deal with this? For example, consider what would have happened had we tried to introduce TRUC prior to v2 transactions.

It’s not clear to me where you see a problem. This BIP applies to transactions with version 3, not transactions signaling a version of 3 and higher.

[petertodd]

So an obvious example of where TRUC's use of v3 transactions would cause a problem is if we had a situation similar to v2 transactions, where an upgrade happened that had wide applicability. Since TRUC is so limited, we'd need to have two different versions of the consensus upgrade for TRUC and non-TRUC transactions. Obviously, that would be a mess. This gets even worse when you consider that we all know that TRUC only mitigates pinning for a very narrow use-case, and people are already discussing extensions to TRUC with new version bits.

Meanwhile, it would be quite easy for TRUC to achieve it's actual main goal of enabling empheral anchor outputs as quick fix by defining TRUC behavior as being enabled for zero-fee transactions.

Choosing V3 didn't even do "TRUC behavior" cleanly as a bit: bin(3) = 0b11, two bits set.

[ariard]

Choosing V3 didn't even do "TRUC behavior" cleanly as a bit: bin(3) = 0b11, two bits set.

Let’s say we have a hypothetical soft-fork in the future to clean all the pinning and transaction-relay jamming broken mess, nVersion is a 32-bit field, so we can still split it in two 16-bit halves: one set for truc-like policy behavior and one set for consensus validation.

Without an example, it’s quite theoretical as there are always other signaling options: the taproot annex, the input nsequence, the nlocktime field...

[ProofOfKeags]

one set for truc-like policy behavior and one set for consensus validation.

I do think that bifurcating things along consensus vs policy is likely a good idea. It would fully orthogonalize the problems. While consensus-invalid implies policy-invalid, I believe these are otherwise independent concerns and we should treat them as such in their signaling/encoding schemes.

[glozow]

My understanding was that the version field is the place for policy/application signals because it's not expected to be reinterpreted in the future for consensus things. That is why I chose it.