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

pull glozow wants to merge 1 commits into bitcoin:master from glozow:2024-01-v3-prio changing 2 files +298 −0
  1. glozow commented at 2:01 pm on January 18, 2024: member

    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:

    Example usage and things built on top:

    Discussion and history:

  2. glozow force-pushed on Jan 18, 2024
  3. t-bast commented at 4:31 pm on January 18, 2024: contributor
    FWIW, concept ACK :)
  4. in bip-v3.mediawiki:15 in 4bd12d5698 outdated 
    10+  License: BSD-3-Clause
11+</pre>
12+
13+==Abstract==
14+
15+Users can set <code>nVersion=3</code> on a transaction (making it a "v3 transaction") to opt in to restrictions on spending unconfirmed outputs in exchange for improved fee-bumping abilities.
    murchandamus commented at 5:29 pm on January 19, 2024:

    It’s not obvious to me what you are thinking of when you mention “improved fee-bumping abilities”. Is that referring to the possibility of relaying a 0-fee transaction in a package? Otherwise, perhaps:

    0Users can set <code>nVersion=3</code> on a transaction (making it a "v3 transaction") to opt in to restrictions on spending unconfirmed outputs in exchange for improved fee-bumping reliability.
  5. in bip-v3.mediawiki:41 in 4bd12d5698 outdated 
    36+* [https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-April/002639.html "RBF Pinning with Counterparties and Competing Interest"]
37+* [https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-June/002758.html "Pinning : The Good, The Bad, The Ugly"]
38+* [https://github.com/t-bast/lightning-docs/blob/master/pinning-attacks.md "Pinning Attacks"]
39+* [https://gist.github.com/instagibbs/60264606e181451e977e439a49f69fe1 "Eltoo Pinning"]
40+</ref>.
41+When the funds available to be redeemed by each party depends on a transaction confirming within a specific time window, a malicious party may be able to steal money if the honest party cannot get their transaction confirmed. As such, the ability to fee-bump a transaction to entice miners to include it in their blocks is important to security.
    murchandamus commented at 5:33 pm on January 19, 2024: 
    0When the funds available to be redeemed by each party depend on a transaction confirming within a specific time window, a malicious party may be able to steal money if the honest party cannot get their transaction confirmed. As such, the ability to fee-bump a transaction to entice miners to include it in their blocks is important to security.
  6. in bip-v3.mediawiki:103 in 4bd12d5698 outdated 
     98+Note: A v3 transaction can spend outputs from _confirmed_ non-v3 transactions.
 99+
100+3. A v3 transaction's unconfirmed ancestors must all be v3.
101+<ref>Rationale:
102+
103+Ensure the ancestor feerate rule does not underestimate a to-be-replaced v3 mempool transaction's incentive compatibility. Imagine the original transaction, A, has a child B and co-parent C (i.e. B spends from A and C). C also has another child, D. B is one of the original transactions and thus its ancestor feerate must be lower than the package's. However, this may be an underestimation because D can bump C without B's help. This is resolved if v3 transactions can only have v3 ancestors, as then C cannot have another child.
    murchandamus commented at 5:41 pm on January 19, 2024:

    The “mempool” here throws me off:

    0Ensure the ancestor feerate rule does not underestimate a to-be-replaced v3 transaction's incentive compatibility. Imagine the original transaction, A, has a child B and co-parent C (i.e. B spends from A and C). C also has another child, D. B is one of the original transactions and thus its ancestor feerate must be lower than the package's. However, this may be an underestimation because D can bump C without B's help. This is resolved if v3 transactions can only have v3 ancestors, as then C cannot have another child.
    murchandamus commented at 6:07 pm on January 19, 2024:
    The last sentence makes use of Rule 4 which is only defined below. Perhaps the order of these two rules should be swapped?
    glozow commented at 10:34 am on January 22, 2024:
    Consolidated the rules a bit to be more understandable and not have these referencing problems.
  7. in bip-v3.mediawiki:118 in 4bd12d5698 outdated 
    113+</ref>
114+
115+5. A v3 transaction that has an unconfirmed v3 ancestor cannot have a sigop-adjusted virtual size larger than 1000vB.
116+<ref>Rationale: Limit the amount of virtual bytes (and thus fees) that may need to be replaced, while leaving a comfortable amount of space for inputs to fund the transaction.
117+<br />Q: Why not bigger?
118+<br />The larger the descendant size limit, the more vbytes may need to be replaced. With default limits, if the child is e.g. 100,000vB, that might be an additional 100,000sats (at 1sat/vbyte) or more, depending on the feerate. Restricting all children to 1000vB bounds the potential fees by a factor of 100.
    murchandamus commented at 5:47 pm on January 19, 2024:

    How about:

    0<br />The larger the descendant size limit, the more vbytes may need to be replaced. With default limits, if the child is e.g. 100,000vB, that might be an additional 100,000sats (at 1sat/vbyte) or more, depending on the feerate. Restricting all children to 1000vB reduces the upper bound of the additional fees by a factor of 100.
  8. in bip-v3.mediawiki:171 in 4bd12d5698 outdated 
    166+It changes the anchor script to be anyone can spend, allowing anybody to add fees and reducing the onchain footprint and fee costs.
167+It also allows anchor outputs to have 0 value, eliminating the need to deduct anchor output amounts from the channel balance.
168+
169+The [https://delvingbitcoin.org/t/an-overview-of-the-cluster-mempool-proposal/393/7 Cluster Mempool] proposal makes deeper changes to mempool structure and policy rules, allowing for more incentive-compatible RBF rules for all transactions (not just ones with special topology restrictions like v3), among other things.
170+
171+Cluster Mempool provides a more wholistic solution to some of the problems listed (such as adding an incentive compatibility requirement to RBF and safely enabling package RBF for more complex topologies). However, it does not help resolve RBF Pinning through Rule 3 and Rule 5. Also, since Cluster Mempool removes CPFP Carve Out<ref>https://delvingbitcoin.org/t/an-overview-of-the-cluster-mempool-proposal/393#the-cpfp-carveout-rule-can-no-longer-be-supported-12</ref>, a policy like v3 is a beneficial intermediate step for applications that rely on it.
    murchandamus commented at 5:55 pm on January 19, 2024: 
    0Cluster Mempool provides a more holistic solution to some of the problems listed (such as adding an incentive compatibility requirement to RBF and safely enabling package RBF for more complex topologies). However, it does not help resolve RBF Pinning through Rule 3 and Rule 5. Also, since Cluster Mempool removes CPFP Carve Out<ref>https://delvingbitcoin.org/t/an-overview-of-the-cluster-mempool-proposal/393#the-cpfp-carveout-rule-can-no-longer-be-supported-12</ref>, a policy like v3 is a beneficial intermediate step for applications that rely on it.
  9. murchandamus commented at 6:09 pm on January 19, 2024: contributor
    ACK 4bd12d5698404e28c70d4486316f4e1cca356896
  10. glozow force-pushed on Jan 22, 2024
  11. glozow commented at 10:34 am on January 22, 2024: member
    Thanks @murchandamus, took all your suggestions (4bd12d5…af8e903)
  12. in bip-v3.mediawiki:151 in af8e9038e6 outdated 
    144+
145+Generally, users with no interest in spending unconfirmed outputs from a transaction can use v3 for more robust RBF abilities.
146+
147+This proposal allows for a different solution to fee-bumping in LN, in which commitment transations are signed with 0 fees and include a single anchor that can later be used to add fees at broadcast time
148+<ref>Proposals for changes to LN commitment transaction format using v3 and a single anchor:
149+* [https://delvingbitcoin.org/t/lightning-transactions-with-v3-and-ephemeral-anchors/418 "Lightning transactions with v3 and ephemeral anchors"]
    ismaelsadeeq commented at 10:46 am on January 22, 2024: 
    0This proposal allows for a different solution to fee-bumping in LN, in which commitment transactions are signed with 0 fees and include a single anchor that can later be used to add fees at broadcast time
1<ref>Proposals for changes to LN commitment transaction format using v3 and a single anchor:
2* [https://delvingbitcoin.org/t/lightning-transactions-with-v3-and-ephemeral-anchors/418 "Lightning transactions with v3 and ephemeral anchors"]
  13. in bip-v3.mediawiki:225 in af8e9038e6 outdated 
    220+Since Rule 3 and 4 are for rate-limiting, replace them with a mempool-wide or per-peer rate limits on replacements by outpoint and/or bandwidth
221+<ref>Examples of such proposals and suggestions:
222+* https://gist.github.com/glozow/25d9662c52453bd08b4b4b1d3783b9ff?permalink_comment_id=4081349#gistcomment-4081349
223+* https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019820.html
224+* https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-June/017024.html
225+<br />Related proposal for changing the amount of bandwidth that replacement transations use:
    ismaelsadeeq commented at 10:53 am on January 22, 2024: 
    0<br />Related proposal for changing the amount of bandwidth that replacement transactions use:
  14. in bip-v3.mediawiki:133 in af8e9038e6 outdated 
    128+<ref>Rationale: This allows contracting protocols to create presigned transactions with 0 fees and fee-bump them using CPFP at broadcast time.
129+</ref>
130+
131+This 1-parent-1-child (aka cluster size 2) topology restriction makes v3 transactions much easier to reason about, which enables implementing additional RBF features
132+<ref>
133+For example, [https://github.com/bitcoin/bitcoin/pull/28984 this implementation] of package RBF compares the replacement and to-be-replaced transaction(s) using their ancestor scores. This score is accurate for v3 transactions due to their limited cluster size.
    ismaelsadeeq commented at 11:05 am on January 22, 2024:
    The implementation is now using the fee rate diagram for incentive compatibility check
    glozow commented at 1:25 pm on January 22, 2024:
    Made the language more ambiguous
  15. ismaelsadeeq commented at 11:45 am on January 22, 2024: member
    Concept ACK
  16. glozow force-pushed on Jan 22, 2024
  17. glozow force-pushed on Jan 22, 2024
  18. glozow force-pushed on Jan 22, 2024
  19. glozow commented at 4:12 pm on February 19, 2024: member
    @luke-jr this has been open for a month, would you mind taking a look?
  20. ariard commented at 11:56 pm on February 19, 2024: member
    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.
  21. glozow force-pushed on Mar 22, 2024
  22. glozow renamed this:
    Opt-In Policy For More Robust Fee-bumping
    Opt In Topologically Restricted Until Confirmation Transactions For More Robust Fee-bumping
    on Mar 22, 2024
  23. in bip-truc.mediawiki:15 in 63e8a7191f outdated 
    10+  License: BSD-3-Clause
11+</pre>
12+
13+==Abstract==
14+
15+Users can set <code>nVersion=3</code> on a transaction to opt in to restrictions on spending unconfirmed outputs (making them Topologically Restricted Until Confirmation or TRUC transactions) in exchange for improved fee-bumping reliability. Nodes apply a different set of mempool policies to these transactions. Namely, topological restrictions that make it easier to assess the incentive compatibility of accepting or replacing them.
    murchandamus commented at 4:58 pm on March 22, 2024:

    How about:

    0Senders can set <code>nVersion=3</code> on a transaction to opt in to restrictions on spending unconfirmed outputs (making them Topologically Restricted Until Confirmation (TRUC) transactions) to achieve improved fee-bumping reliability. Nodes apply stricter mempool policies to these transactions. The resulting topological restrictions make it easier to assess the incentive compatibility of accepting or replacing them.

    Or maybe:

    0Users can set <code>nVersion=3</code> to voluntarily declare a transaction _Topologically Restricted Until Confirmation (TRUC)_. Nodes apply stricter mempool policies to TRUC transactions in form of limits on spending of their unconfirmed outputs. These restrictions improve fee-bumping reliability by simplifying assessing the incentive compatibility of accepting or replacing TRUC transactions.
    glozow commented at 9:37 am on March 26, 2024:
    took some of this
  24. in bip-truc.mediawiki:24 in 63e8a7191f outdated 
    19+Mempools typically accept and relay transactions that spend outputs from other unconfirmed transactions, but restrict package sizes through ancestor and descendant limits
20+<ref>https://github.com/bitcoin/bitcoin/blob/632a2bb731804dffe52bd4cbd90bfee352d25ede/doc/policy/mempool-limits.md</ref>
21+to limit the computational complexity of mempool operations and mitigate Denial of Service attacks.
22+
23+Users may also create unconfirmed transactions that conflict with -- or are "double spends" of -- each other by spending the same input(s) in both.
24+Instead of always keeping the first transaction, many mempools also have some kind of Replace by Fee (RBF) policy
    murchandamus commented at 5:44 pm on March 22, 2024: 
    0Instead of always keeping the first-seen transaction, many mempools also have some kind of Replace by Fee (RBF) policy
    glozow commented at 9:36 am on March 26, 2024:
    taken
  25. in bip-truc.mediawiki:28 in 63e8a7191f outdated 
    23+Users may also create unconfirmed transactions that conflict with -- or are "double spends" of -- each other by spending the same input(s) in both.
24+Instead of always keeping the first transaction, many mempools also have some kind of Replace by Fee (RBF) policy
25+<ref>
26+[https://github.com/bitcoin/bitcoin/blob/632a2bb731804dffe52bd4cbd90bfee352d25ede/doc/policy/mempool-replacements.md Bitcoin Core's RBF policy] at the time of writing. It is slightly different from what is described in BIP 125.
27+</ref>
28+to keep the more incentive compatible transaction, i.e. one that would earn a miner more fees. As such, creating higher feerate double-spends (replacements) is often employed by users as a fee-bumping mechanism.
    murchandamus commented at 5:48 pm on March 22, 2024:

    Maybe:

    0to keep the more incentive compatible transaction, i.e. one that would earn a miner more fees. Users utilize these rules when they create higher feerate double-spends (replacements) to expedite confirmation of their payments.
    glozow commented at 9:36 am on March 26, 2024:
    taken
  26. in bip-truc.mediawiki:32 in 63e8a7191f outdated 
    27+</ref>
28+to keep the more incentive compatible transaction, i.e. one that would earn a miner more fees. As such, creating higher feerate double-spends (replacements) is often employed by users as a fee-bumping mechanism.
29+
30+However, these policies make imperfect trade-offs between incentive compatibility and DoS-resistance. For example, malicious actors may sometimes exploit limitations to prevent incentive-compatible transactions from being accepted or fee-bumped (''pinning'').
31+
32+Pinning is very relevant to contracting protocols in which untrusted parties construct and sign time-sensitive transactions to be broadcast on-chain later
    murchandamus commented at 5:56 pm on March 22, 2024: 
    0Pinning is consequential to contracting protocols in which untrusted parties construct and sign time-sensitive transactions to be broadcast on-chain later
    glozow commented at 9:36 am on March 26, 2024:
    taken
  27. in bip-truc.mediawiki:40 in 63e8a7191f outdated 
    35+* [https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-April/002639.html "RBF Pinning with Counterparties and Competing Interest"]
36+* [https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-June/002758.html "Pinning : The Good, The Bad, The Ugly"]
37+* [https://github.com/t-bast/lightning-docs/blob/master/pinning-attacks.md "Pinning Attacks"]
38+* [https://gist.github.com/instagibbs/60264606e181451e977e439a49f69fe1 "Eltoo Pinning"]
39+</ref>.
40+When the funds available to be redeemed by each party depend on a transaction confirming within a specific time window, a malicious party may be able to steal money if the honest party cannot get their transaction confirmed. As such, the ability to fee-bump a transaction to entice miners to include it in their blocks is important to security.
    murchandamus commented at 5:58 pm on March 22, 2024: 
    0When the funds available to be redeemed by each party depend on a transaction confirming within a specific time window, a malicious party may be able to steal money if the honest party cannot get their transaction confirmed. As such, the ability to fee-bump a transaction to entice miners to include it in their blocks is crucial to the security of the protocol.
    glozow commented at 9:36 am on March 26, 2024:
    taken
  28. murchandamus commented at 6:32 pm on March 22, 2024: contributor
    ACK 63e8a7191f8ab2453e5971e62f709df613ae224c
  29. glozow force-pushed on Mar 26, 2024
  30. glozow commented at 9:37 am on March 26, 2024: member
    Thanks @murchandamus! Accepted your suggestions.
  31. jonatack added the label New BIP on Apr 23, 2024
  32. in bip-truc.mediawiki:4 in 158acdbbbf outdated 
    0@@ -0,0 +1,271 @@
1+<pre>
2+  BIP: ???
3+  Layer: Applications
4+  Title: Topologically Restricted Until Confirmation Transactions
    murchandamus commented at 1:49 pm on April 23, 2024:
    Nit: The title is longer than 44 characters
    glozow commented at 11:05 am on April 24, 2024:
    changed. 44 is not a lot of characters!
  33. in bip-truc.mediawiki:10 in 158acdbbbf outdated 
     5+  Author: Gloria Zhao <gloriajzhao@gmail.com>
 6+  Comments-URI:
 7+  Status: Draft
 8+  Type: ???
 9+  Created: 2024-01-10
10+  License: BSD-3-Clause
    murchandamus commented at 2:02 pm on April 23, 2024:
    Please add the “Post-History” header in the preamble and link to relevant mailing list threads and other discussions (e.g. delving).
    glozow commented at 11:05 am on April 24, 2024:
    done, thanks
  34. luke-jr commented at 9:13 pm on April 23, 2024: member
    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.
  35. vostrnad commented at 9:29 pm on April 23, 2024: contributor
    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.
  36. Roasbeef commented at 9:40 pm on April 23, 2024: contributor

    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.

  37. luke-jr commented at 10:11 pm on April 23, 2024: member
    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.
  38. Roasbeef commented at 10:19 pm on April 23, 2024: contributor

    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.

  39. luke-jr commented at 10:45 pm on April 23, 2024: member
    It may be poorly worded, but that isn’t the point.
  40. luke-jr commented at 10:50 pm on April 23, 2024: member
    (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)
  41. glozow force-pushed on Apr 24, 2024
  42. glozow commented at 11:45 am on April 24, 2024: member

    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.

  43. glozow force-pushed on Apr 24, 2024
  44. ariard commented at 7:12 am on April 25, 2024: member

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

  45. in bip-truc.mediawiki:95 in f2d33b5cf0 outdated 
    90+
91+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.
92+
93+===Specification===
94+
95+Senders can signal that they want a transaction to be Topologically Restricted Until Confirmation (TRUC). Sepcifically, set <code>nVersion=3</code>.
    murchandamus commented at 9:41 pm on April 26, 2024: 
    0Senders can signal that they want a transaction to be Topologically Restricted Until Confirmation (TRUC). Specifically, set <code>nVersion=3</code>.
  46. murchandamus approved
  47. murchandamus commented at 9:42 pm on April 26, 2024: contributor

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

    reACK f2d33b5cf01e04e190a3493a74c220fb64266ee8

  48. murchandamus added the label Process on May 14, 2024
  49. jonatack requested review from jonatack on May 15, 2024
  50. in bip-truc.mediawiki:63 in f2d33b5cf0 outdated 
    58+
59+RBF rules require that no replacement trigger the removal of more than 100 transactions ("Rule 5"). This number includes the descendants of the conflicted mempool transactions. Mallory can make it more difficult to replace transactions by attaching lots of descendants to them. For example, if Alice wants to batch-replace 5 transactions but each has 21 descendants, her replacement will be rejected regardless of its fees.
60+
61+===RBF incentive compatibility requirements===
62+
63+There is currently no effective rule to enforce that accepting a replacement transaction would be more incentive compatible to keep in the mempool. It is difficult to quantify the incentive compatibility of a set of transactions, especially in comparison with another set of transactions<ref>https://delvingbitcoin.org/t/mempool-incentive-compatibility/553</ref>, but Rule 6 (requiring a feerate increase) is far too simplistic.
    jonatack commented at 9:23 pm on May 21, 2024:

    “to enforce that accepting a replacement transaction would be more incentive compatible to keep in the mempool”

    I’m having trouble parsing what this means, help :)

  51. in bip-truc.mediawiki:102 in f2d33b5cf0 outdated 
     97+
 98+1. A TRUC transaction signals replaceability, even if it does not signal BIP125 replaceability.
 99+
100+2. Any TRUC transaction's unconfirmed ancestors must all be TRUC. Any descendant of an unconfirmed TRUC transaction must also be TRUC.
101+<ref>Rationale:
102+* Requiring packages to be all-or-none TRUC makes it possible to enforce the toplogy limits. For example, the TRUC descendant limit would not be very meaningful if it could be bypassed by creating a non-TRUC child.
    jonatack commented at 10:22 pm on May 21, 2024: 
    0* Requiring packages to be all-or-none TRUC makes it possible to enforce the topology limits. For example, the TRUC descendant limit would not be very meaningful if it could be bypassed by creating a non-TRUC child.
  52. in bip-truc.mediawiki:117 in f2d33b5cf0 outdated 
    112+
113+<br />Q: Why not allow multiple parents to enable batched fee-bumping?
114+<br />To mitigate Rule 3 pinning, we need to prevent a child of an unconfirmed TRUC transaction from bringing in more unconfirmed ancestors. See #2 in Rule 3 Pinning section above.
115+
116+<br />Q: Why not allow another child?
117+<br />Allowing another child disables the ability to use ancestor score to measure incentive compatibility. Imagine the original transaction, A, has a child B and co-parent C (i.e. B spends from A and C). C also has another child, D. B is one of the original transactions and thus its ancestor feerate must be lower than the package's. However, this may be an underestimation because D can bump C without B's help. This is resolved if TRUC transactions can only have TRUC ancestors, as then C cannot have another child.
    jonatack commented at 10:29 pm on May 21, 2024: 
    0<br />Allowing another child disables the ability to use ancestor score to measure incentive compatibility. Imagine the original transaction, A, has a child B and co-parent C (i.e. B spends from A and C). C also has another child, D. B is one of the original transactions and thus its ancestor feerate must be lower than the package's feerate. However, this may be an underestimation because D can bump C without B's help. This is resolved if TRUC transactions can only have TRUC ancestors, as then C cannot have another child.

    or: “than that of the package.”

  53. in bip-truc.mediawiki:123 in f2d33b5cf0 outdated 
    118+
119+<br />Q: Why allow any descendants at all?
120+<br />At least 1 descendant is required to allow CPFP of the presigned transaction. Without package RBF, multiple anchor outputs would be required to allow each counterparty to fee-bump any presigned transaction. With package RBF, since the presigned transactions can replace each other, 1 anchor output is sufficient.
121+</ref>
122+
123+4. A TRUC transaction that has an unconfirmed TRUC ancestor cannot have a sigop-adjusted virtual size larger than 1000vB.
    jonatack commented at 10:38 pm on May 21, 2024:
    Is this section 4 related to https://github.com/bitcoin/bitcoin/pull/29873 (and potentially would need updating)?
    ProofOfKeags commented at 7:29 pm on May 22, 2024:
    Is “sigop-adjusted virtual size” formally defined anywhere. I’m aware of the sigop limit and virtual size. I am unaware of how sigops may or may not “adjust” the virtual size.
    glozow commented at 7:59 pm on May 22, 2024:

    Not really, apart from the code comments written in/since its introduction in https://github.com/bitcoin/bitcoin/pull/8365. This is one of the main reasons why I think policy ought to be documented more formally, as I and others have tripped on this quite a bit.

    Also see https://github.com/bitcoin/bitcoin/pull/27591 (which I still need to get around to updating - up for grabs if you’re interested).

    ProofOfKeags commented at 10:36 pm on May 22, 2024:
    Got it. Reading that link indicates that on a policy level Core attaches a vByte price to sigops when evaluating mempool/relay stuff. However, at the consensus level we just have a sigops limit as well as a minimum vByte threshold per sigop?
    glozow commented at 7:13 am on May 23, 2024:

    Correct. It’s simplifying a 2D Knapsack problem by rolling both values into 1 score.

    I’m going to mark this thread as resolved as I don’t think this BIP would be the right place for defining it. Please feel free to comment on the above PR, open a stack exchange question, or DM me if you have further questions.

  54. in bip-truc.mediawiki:159 in f2d33b5cf0 outdated 
    154+and sibling eviction
155+<ref>
156+[https://github.com/bitcoin/bitcoin/pull/29306 This PR] implements sibling eviction for TRUC transactions: if a new transaction would exceed a transaction's descendant limit, it considers evicting the existing descendant using replacement rules. Sibling eviction is feasible for TRUC transactions because there is no difficulty in identifying which descendant to evict (there can only be 1).
157+</ref>.
158+
159+The [https://github.com/instagibbs/bips/blob/ephemeral_anchor/bip-ephemeralanchors.mediawiki Ephemeral Anchors] proposal builds on top of this one to add more features.
    jonatack commented at 10:43 pm on May 21, 2024:
    Could now link to the BIP draft (https://github.com/bitcoin/bips/pull/1524) here instead?
  55. in bip-truc.mediawiki:243 in f2d33b5cf0 outdated 
    238+Removing Rule 3 and 4 in general would allow free relay
239+<ref>Examples of free relay with the removal of Rule 3 and/or 4:
240+<br/> Consider a rule where the fee can be decreased (remove Rule 3 and 4) but the feerate must double. In this scenario, a 100KvB transaction can be replaced by a 100vB transaction paying 200 sats. That's 200 sats to relay 100,200vB of transaction data, which is less than 0.002sat/vB. It becomes quite cheap to replace large portions of the mempool, decreasing both its average feerate and total absolute fees.
241+
242+<br/>Consider a rule where the fee can stay the same (keep Rule 3 but drop Rule 4) but the feerate must double. The attacker can start out with 100KvB transaction, paying 1sat/vB. A user can reduce its size over and over again, doubling the feerate each time until it gets too small, and end up paying 100Ksat for 100KvB(1 + 1/2 + 1/4 + ... log2(mintxsize)) -> approaches 200KvB. This means the attacker pays a
243+rate of 0.5sat/vB to relay transactions, which is below our "free relay" threshold of 1/sat/vB.
    jonatack commented at 10:54 pm on May 21, 2024: 
    0rate of 0.5sat/vB to relay transactions, which is below our "free relay" threshold of 1sat/vB.
  56. jonatack commented at 11:01 pm on May 21, 2024: contributor
    Looks pretty close. Would need a README entry and a BIP number assignment, if deemed to be in-scope.
  57. in bip-truc.mediawiki:8 in f2d33b5cf0 outdated 
    0@@ -0,0 +1,286 @@
1+<pre>
2+  BIP: ???
3+  Layer: Applications
4+  Title: Topology Restrictions for Pinning
5+  Author: Gloria Zhao <gloriajzhao@gmail.com>
6+  Comments-URI:
7+  Status: Draft
8+  Type: ???
    jonatack commented at 11:36 pm on May 21, 2024:
    Suggest Informational per #1524 (review).
    KamPuc86zg commented at 7:17 pm on May 22, 2024:
    bip-truc.mediawiki
  58. glozow commented at 1:35 pm on May 22, 2024: member
    Thanks for the review @jonatack! I’ll wait for a number assignment.
  59. jonatack commented at 5:47 pm on May 22, 2024: contributor

    Assigned number 431.

    Per BIP 2: The BIP process exists for standardisation between independent projects. While policy is a per-node decision, R&D related to node relay policy and a degree of interop standardization have been and continue to be worked on to try to solve fundamental long-standing issues in bitcoin and across the LN implementations. This R&D documentation, along with signaling v3 transactions and opt-in interop standardization, seem in-scope here.

  60. murchandamus removed the label Process on May 22, 2024
  61. murchandamus added the label PR Author action required on May 22, 2024
  62. KamPuc86zg approved
  63. KamPuc86zg commented at 7:17 pm on May 22, 2024: none
    Dragankamil6@gmail.com
  64. glozow force-pushed on May 22, 2024
  65. glozow commented at 8:00 pm on May 22, 2024: member

    Thanks @jonatack @murchandamus!

    I’ve added the number, and used that to update the file name, readme table, etc. Also took all of your suggestions.

  66. jonatack renamed this:
    Opt In Topologically Restricted Until Confirmation Transactions For More Robust Fee-bumping
    BIP431: Opt In Topologically Restricted Until Confirmation Transactions For More Robust Fee-bumping
    on May 22, 2024
  67. jonatack removed the label PR Author action required on May 22, 2024
  68. in bip-0431.mediawiki:6 in 0fb58b40b9 outdated 
    0@@ -0,0 +1,291 @@
1+<pre>
2+  BIP: 431
3+  Layer: Applications
4+  Title: Topology Restrictions for Pinning
5+  Author: Gloria Zhao <gloriajzhao@gmail.com>
6+  Comments-URI:
    jonatack commented at 8:21 pm on May 22, 2024:
    Not sure, but I think the linter is balking because no link is provided here yet.
    jonatack commented at 9:24 pm on May 22, 2024:

    Here’s a diff that has ./scripts/buildtable.pl running for me locally.

     0   Layer: Applications
 1   Title: Topology Restrictions for Pinning
 2   Author: Gloria Zhao <gloriajzhao@gmail.com>
 3-  Comments-URI:
 4+  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0431
 5   Status: Draft
 6   Type: Informational
 7   Created: 2024-01-10
 8   License: BSD-3-Clause
 9   Post-History: 2022-01-27: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019817.html [bitcoin-dev] discussion
10-               2022-01-27: https://gist.github.com/glozow/25d9662c52453bd08b4b4b1d3783b9ff gist discussion
11-               2022-09-23: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020937.html [bitcoin-dev] proposal
12-               2024-01-02: https://delvingbitcoin.org/t/v3-transaction-policy-for-anti-pinning/340 Delving Bitcoin post
13-               2024-01-16: https://delvingbitcoin.org/t/lightning-transactions-with-v3-and-ephemeral-anchors/418 Delving Bitcoin post
14+                2022-01-27: https://gist.github.com/glozow/25d9662c52453bd08b4b4b1d3783b9ff gist discussion
15+                2022-09-23: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020937.html [bitcoin-dev] proposal
16+                2024-01-02: https://delvingbitcoin.org/t/v3-transaction-policy-for-anti-pinning/340 Delving Bitcoin post
17+                2024-01-16: https://delvingbitcoin.org/t/lightning-transactions-with-v3-and-ephemeral-anchors/418 Delving Bitcoin post
18 </pre>
    glozow commented at 7:14 am on May 23, 2024:
    That fixed it, thanks!
  69. glozow force-pushed on May 23, 2024
  70. glozow force-pushed on May 23, 2024
  71. carlaKC approved
  72. carlaKC commented at 1:12 pm on May 23, 2024: none

    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.

  73. in bip-0431.mediawiki:146 in 32e4e44a5a outdated 
    141+
142+====Implementation====
143+
144+- https://github.com/bitcoin/bitcoin/pull/28948
145+- https://github.com/bitcoin/bitcoin/pull/29873
146+- https://github.com/bitcoin/bitcoin/pull/29496
    murchandamus commented at 1:14 pm on May 23, 2024:

    The syntax for unordered lists in the mediawiki format uses asterisks:

    0* https://github.com/bitcoin/bitcoin/pull/28948
1* https://github.com/bitcoin/bitcoin/pull/29873
2* https://github.com/bitcoin/bitcoin/pull/29496
    glozow commented at 2:26 pm on May 23, 2024:
    done
  74. in bip-0431.mediawiki:245 in 32e4e44a5a outdated 
    240+
241+The primary problem with these proposals is the potential for free relay and DDoS attacks.
242+
243+Removing Rule 3 and 4 in general would allow free relay
244+<ref>Examples of free relay with the removal of Rule 3 and/or 4:
245+<br/> Consider a rule where the fee can be decreased (remove Rule 3 and 4) but the feerate must double. In this scenario, a 100KvB transaction can be replaced by a 100vB transaction paying 200 sats. That's 200 sats to relay 100,200vB of transaction data, which is less than 0.002sat/vB. It becomes quite cheap to replace large portions of the mempool, decreasing both its average feerate and total absolute fees.
    murchandamus commented at 1:16 pm on May 23, 2024: 
    0<br/> Consider a rule where the fee can be decreased (remove Rule 3 and 4) but the feerate must double. In this scenario, a 100 kvB transaction can be replaced by a 100 vB transaction paying 200 sats. That's 200 sats to relay 100,200 vB of transaction data, which is less than 0.002 sat/vB. It becomes quite cheap to replace large portions of the mempool, decreasing both its average feerate and total absolute fees.
    glozow commented at 2:26 pm on May 23, 2024:
    done
  75. in bip-0431.mediawiki:247 in 32e4e44a5a outdated 
    242+
243+Removing Rule 3 and 4 in general would allow free relay
244+<ref>Examples of free relay with the removal of Rule 3 and/or 4:
245+<br/> Consider a rule where the fee can be decreased (remove Rule 3 and 4) but the feerate must double. In this scenario, a 100KvB transaction can be replaced by a 100vB transaction paying 200 sats. That's 200 sats to relay 100,200vB of transaction data, which is less than 0.002sat/vB. It becomes quite cheap to replace large portions of the mempool, decreasing both its average feerate and total absolute fees.
246+
247+<br/>Consider a rule where the fee can stay the same (keep Rule 3 but drop Rule 4) but the feerate must double. The attacker can start out with 100KvB transaction, paying 1sat/vB. A user can reduce its size over and over again, doubling the feerate each time until it gets too small, and end up paying 100Ksat for 100KvB(1 + 1/2 + 1/4 + ... log2(mintxsize)) -> approaches 200KvB. This means the attacker pays a rate of 0.5sat/vB to relay transactions, which is below our "free relay" threshold of 1sat/vB.
    murchandamus commented at 1:17 pm on May 23, 2024: 
    0<br/>Consider a rule where the fee can stay the same (keep Rule 3 but drop Rule 4) but the feerate must double. The attacker can start out with 100 kvB transaction, paying 1 sat/vB. A user can reduce its size over and over again, doubling the feerate each time until it gets too small, and end up paying 100 ksat for 100 kvB (1 + 1/2 + 1/4 + ... + log2(mintxsize)) -> approaches 200 kvB. This means the attacker pays a rate of 0.5 sat/vB to relay transactions, which is below our "free relay" threshold of 1 sat/vB.
    glozow commented at 2:26 pm on May 23, 2024:
    done
  76. in bip-0431.mediawiki:132 in 32e4e44a5a outdated 
    127+5. A TRUC transaction that has an unconfirmed TRUC ancestor cannot have a sigop-adjusted virtual size larger than 1000vB.
128+<ref>Rationale: Limit the amount of virtual bytes (and thus fees) that may need to be replaced, while leaving a comfortable amount of space for inputs to fund the transaction.
129+<br />Q: Why not bigger?
130+<br />The larger the descendant size limit, the more vbytes may need to be replaced. With default limits, if the child is e.g. 100,000vB, that might be an additional 100,000sats (at 1sat/vbyte) or more, depending on the feerate. Restricting all children to 1000vB reduces the upper bound of the additional fees by a factor of 100.
131+
132+<br />This rule is also easily tacked on to existing logic for policy and wallets. A maximum size standard transaction (100KvB) can have up to 1000vB of descendants to be within the default descendant limit (101KvB).
    murchandamus commented at 1:17 pm on May 23, 2024: 
    0<br />This rule is also easily tacked on to existing logic for policy and wallets. A maximum size standard transaction (100 kvB) can have up to 1000 vB of descendants to be within the default descendant limit (101 kvB).
    glozow commented at 2:26 pm on May 23, 2024:
    done
  77. in bip-0431.mediawiki:135 in 32e4e44a5a outdated 
    130+<br />The larger the descendant size limit, the more vbytes may need to be replaced. With default limits, if the child is e.g. 100,000vB, that might be an additional 100,000sats (at 1sat/vbyte) or more, depending on the feerate. Restricting all children to 1000vB reduces the upper bound of the additional fees by a factor of 100.
131+
132+<br />This rule is also easily tacked on to existing logic for policy and wallets. A maximum size standard transaction (100KvB) can have up to 1000vB of descendants to be within the default descendant limit (101KvB).
133+
134+<br />Q: Why not smaller?
135+<br/>The smaller this limit, the fewer UTXOs a child may use to fund this fee-bump. For example, only allowing the TRUC child to have 2 inputs would require wallets to maintain a pool of high-value confirmed UTXOs. However, as the fee-bumping child only needs to fund fees (as opposed to payments), just a few UTXOs should suffice. With a limit of 1000vB and usage of taproot outputs, the child can have 15 inputs and 2 outputs (calculated using [https://bitcoinops.org/en/tools/calc-size/ this tool]).
    murchandamus commented at 1:24 pm on May 23, 2024: 
    0<br/>The smaller this limit, the fewer UTXOs a child may use to fund this fee-bump. For example, only allowing the TRUC child to have 2 inputs would require wallets to maintain a pool of high-value confirmed UTXOs. However, as the fee-bumping child only needs to fund fees (as opposed to payments), just a few UTXOs should suffice. With a limit of 1000 vB and usage of taproot outputs, the child can have 15 inputs and 2 outputs (calculated using [https://bitcoinops.org/en/tools/calc-size/ this tool]).
    glozow commented at 2:26 pm on May 23, 2024:
    done
  78. murchandamus approved
  79. murchandamus commented at 1:46 pm on May 23, 2024: contributor

    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, image via https://www.nist.gov/pml/special-publication-330/sp-330-section-5

    by NIST, image via https://physics.nist.gov/cuu/Units/checklist.html

    as well as IEEE: image 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.

  80. in bip-0431.mediawiki:130 in 32e4e44a5a outdated 
    125+</ref>
126+
127+5. A TRUC transaction that has an unconfirmed TRUC ancestor cannot have a sigop-adjusted virtual size larger than 1000vB.
128+<ref>Rationale: Limit the amount of virtual bytes (and thus fees) that may need to be replaced, while leaving a comfortable amount of space for inputs to fund the transaction.
129+<br />Q: Why not bigger?
130+<br />The larger the descendant size limit, the more vbytes may need to be replaced. With default limits, if the child is e.g. 100,000vB, that might be an additional 100,000sats (at 1sat/vbyte) or more, depending on the feerate. Restricting all children to 1000vB reduces the upper bound of the additional fees by a factor of 100.
    murchandamus commented at 1:57 pm on May 23, 2024: 
    0<br />The larger the descendant size limit, the more vbytes may need to be replaced. With default limits, if the child is e.g. 100,000 vB, that might be an additional 100,000 sats (at 1 sat/vbyte) or more, depending on the feerate. Restricting all children to 1000 vB reduces the upper bound of the additional fees by a factor of 100.
    glozow commented at 2:26 pm on May 23, 2024:
    done
  81. in bip-0431.mediawiki:123 in 32e4e44a5a outdated 
    118+
119+<br />Q: Why allow any descendants at all?
120+<br />At least 1 descendant is required to allow CPFP of the presigned transaction. Without package RBF, multiple anchor outputs would be required to allow each counterparty to fee-bump any presigned transaction. With package RBF, since the presigned transactions can replace each other, 1 anchor output is sufficient.
121+</ref>
122+
123+4. A TRUC transaction cannot have a sigop-adjusted virtual size larger than 10,000vB.
    murchandamus commented at 1:58 pm on May 23, 2024: 
    04. A TRUC transaction cannot have a sigop-adjusted virtual size larger than 10,000 vB.
    glozow commented at 2:25 pm on May 23, 2024:
    done
  82. in bip-0431.mediawiki:124 in 32e4e44a5a outdated 
    119+<br />Q: Why allow any descendants at all?
120+<br />At least 1 descendant is required to allow CPFP of the presigned transaction. Without package RBF, multiple anchor outputs would be required to allow each counterparty to fee-bump any presigned transaction. With package RBF, since the presigned transactions can replace each other, 1 anchor output is sufficient.
121+</ref>
122+
123+4. A TRUC transaction cannot have a sigop-adjusted virtual size larger than 10,000vB.
124+<ref>Rationale: Limit the amount of virtual bytes (and thus fees) that may need to be replaced, while leaving a comfortable amount of space for payments, HTLCs, or other uses of the transaction. Generally, having a smaller maximum size helps to better define bounds for algorithms and memory usage, and the existing limit of 100,000vB seems much larger than necessary.
    murchandamus commented at 1:58 pm on May 23, 2024: 
    0<ref>Rationale: Limit the amount of virtual bytes (and thus fees) that may need to be replaced, while leaving a comfortable amount of space for payments, HTLCs, or other uses of the transaction. Generally, having a smaller maximum size helps to better define bounds for algorithms and memory usage, and the existing limit of 100,000 vB seems much larger than necessary.
    glozow commented at 2:25 pm on May 23, 2024:
    done
  83. in bip-0431.mediawiki:127 in 32e4e44a5a outdated 
    122+
123+4. A TRUC transaction cannot have a sigop-adjusted virtual size larger than 10,000vB.
124+<ref>Rationale: Limit the amount of virtual bytes (and thus fees) that may need to be replaced, while leaving a comfortable amount of space for payments, HTLCs, or other uses of the transaction. Generally, having a smaller maximum size helps to better define bounds for algorithms and memory usage, and the existing limit of 100,000vB seems much larger than necessary.
125+</ref>
126+
127+5. A TRUC transaction that has an unconfirmed TRUC ancestor cannot have a sigop-adjusted virtual size larger than 1000vB.
    murchandamus commented at 1:58 pm on May 23, 2024: 
    05. A TRUC transaction that has an unconfirmed TRUC ancestor cannot have a sigop-adjusted virtual size larger than 1000 vB.
    glozow commented at 2:25 pm on May 23, 2024:
    done
  84. murchandamus commented at 2:00 pm on May 23, 2024: contributor
    Oops, I overlooked a couple more values
  85. glozow force-pushed on May 23, 2024
  86. glozow commented at 2:28 pm on May 23, 2024: member
    Thanks @carlaKC @murchandamus! I’ve fixed the italics, spacing, and “k”.
  87. Define BIP431: TRUCs 04d3a0609b
  88. in bip-0431.mediawiki:49 in c0fb4172f3 outdated 
    44+* [https://github.com/t-bast/lightning-docs/blob/master/pinning-attacks.md "Pinning Attacks"]
45+* [https://gist.github.com/instagibbs/60264606e181451e977e439a49f69fe1 "Eltoo Pinning"]
46+</ref>.
47+When the funds available to be redeemed by each party depend on a transaction confirming within a specific time window, a malicious party may be able to steal money if the honest party cannot get their transaction confirmed. As such, the ability to fee-bump a transaction to entice miners to include it in their blocks is crucial to the security of the protocol.
48+
49+===RBF pinning through Rule 3===
    sdaftuar commented at 3:02 pm on May 23, 2024:

    The reference to “Rule 3” (and “Rule 5” and “Rule 6” below) might be confusing to readers who haven’t read BIP 125 – perhaps add a link or explanation?

    EDIT: Actually I guess there is a link to Bitcoin Core’s replacement policy, and you have some explanation as well – I just found the heading to be confusing!

    glozow commented at 3:34 pm on May 23, 2024:
    I’ve renamed the headings to be more descriptive, and added links and clarifications where “Rule n” is mentioned throughout the document
    sdaftuar commented at 5:05 pm on May 23, 2024:
    Looks better to me, thanks!
  89. glozow force-pushed on May 23, 2024
  90. carlaKC approved
  91. carlaKC commented at 5:10 pm on May 24, 2024: none
    re-ACK 04d3a06 🤩
  92. glozow commented at 8:33 am on May 28, 2024: member
    (I think this is ready, please lmk if there’s anything left to do on my end)
  93. jonatack assigned jonatack on May 29, 2024
  94. in bip-0431.mediawiki:123 in 04d3a0609b 
    118+
119+<br />Q: Why allow any descendants at all?
120+<br />At least 1 descendant is required to allow CPFP of the presigned transaction. Without package RBF, multiple anchor outputs would be required to allow each counterparty to fee-bump any presigned transaction. With package RBF, since the presigned transactions can replace each other, 1 anchor output is sufficient.
121+</ref>
122+
123+4. A TRUC transaction cannot have a sigop-adjusted virtual size larger than 10,000 vB.
    jonatack commented at 2:36 am on May 29, 2024:
    Updated for https://github.com/bitcoin/bitcoin/pull/29873 👍
  95. in bip-0431.mediawiki:51 in 04d3a0609b 
    46+</ref>.
47+When the funds available to be redeemed by each party depend on a transaction confirming within a specific time window, a malicious party may be able to steal money if the honest party cannot get their transaction confirmed. As such, the ability to fee-bump a transaction to entice miners to include it in their blocks is crucial to the security of the protocol.
48+
49+===RBF pinning through absolute fees===
50+
51+Imagine that counterparties Alice and Mallory have transactions (or packages) A and B, respectively, which conflict with each other. Alice broadcasts A and Mallory broadcasts B. RBF rules require the replacement transaction pay a higher absolute fee than the aggregate fees paid by all original transactions ([https://github.com/bitcoin/bitcoin/blob/master/doc/policy/mempool-replacements.md#current-replace-by-fee-policy "Rule 3"]). This means Mallory may increase the fees required to replace B beyond what Alice was planning to pay for A's fees.
    jonatack commented at 2:42 am on May 29, 2024:
    With https://github.com/bitcoin/bitcoin/pull/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).
  96. jonatack commented at 2:50 am on May 29, 2024: contributor

    ACK 04d3a0609b548805fa2ebaf5d3a495f1b81a003c

    Re-checked the RBF rules vs description headers.

  97. jonatack merged this on May 29, 2024
  98. jonatack closed this on May 29, 2024
  99. petertodd commented at 1:21 am on July 7, 2024: contributor

    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.

  100. murchandamus commented at 2:57 pm on July 8, 2024: contributor
    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.
  101. petertodd commented at 3:02 pm on July 8, 2024: contributor

    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.

  102. glozow deleted the branch on Jul 8, 2024
  103. glozow commented at 3:27 pm on July 8, 2024: member

    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?

  104. murchandamus commented at 3:53 pm on July 8, 2024: contributor

    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.

  105. petertodd commented at 7:25 pm on July 12, 2024: contributor

    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.

  106. ariard commented at 4:50 pm on July 16, 2024: member

    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…

  107. ProofOfKeags commented at 9:40 pm on July 16, 2024: contributor

    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.

  108. glozow commented at 9:03 am on July 17, 2024: member
    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.


glozow t-bast murchandamus ismaelsadeeq ariard luke-jr vostrnad Roasbeef jonatack ProofOfKeags KamPuc86zg carlaKC sdaftuar petertodd

Labels
New BIP

github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bips. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2024-11-21 13:10 UTC
This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me