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

Example usage and things built on top:

• Package RBF
  • Cluster size 2 package rbf bitcoin#28984
• Ephemeral Anchors
  • Ephemeral Anchors bitcoin#29001
  • Ephemeral anchors #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.

[murchandamus]

Nit: The title is longer than 44 characters

[glozow]

changed. 44 is not a lot of characters!

[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)

[glozow]

Addressed @murchandamus's comments and slightly restructured the text.

As with #1524, node policy is not a standardizable subject matter in itself - every node decides its own policy.

I really don't see how the text in this BIP can be interpreted to mean that nodes can't decide their own policy. But I've added some language to the text to make it more clear that it's optional, that there are other ways to do this, policy is not consensus, and the details can be different.

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.

This policy restriction should be opt in to avoid breaking existing use cases. Also I don't agree that the same signal should be used for 2 different things just because they have a few things in common.

[ariard]

(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)

If I can make one suggestion it would be to split this BIP in two new BIP components:

• the signaling mechanism (nversion=3)
• the set of policy rules (i.e the TRUC)

This would certainly help to navigate more efficiently this kind of situation in the future.

"Similarly, there are multiple approaches to creating a policy to minimize pinning, more may become available over time (see Related Work section), and the details of this approach can be tweaked if conditions change. For example, if loosening one of the topology restrictions enables a new use case while still providing acceptable pinning bounds, it can be changed.”

This gives flexibility to have many signaling mechanism (e.g nversion / nsequence) committing to one set of policy rules and vice-versa have one signaling mechanism committing to many policy rules (bip125, 1000 vb child limit truc, etc). This can only give us more flexibility w.r.t coordinated upgrades across bitcoin layers.

edited - to clarify the suggestion to split in 2 new BIP documents this current one.

[murchandamus]

My concerns have been addressed, I just noticed a typo you could fix in case you need to touch this again.

reACK f2d33b5

[murchandamus]

Suggested change

	Senders can signal that they want a transaction to be Topologically Restricted Until Confirmation (TRUC). Sepcifically, set <code>nVersion=3</code>.
	Senders can signal that they want a transaction to be Topologically Restricted Until Confirmation (TRUC). Specifically, set <code>nVersion=3</code>.