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

  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:

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

  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:

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.

  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:

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

 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:

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

 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:

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

 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:

This 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
<ref>Proposals for changes to LN commitment transaction format using v3 and a single anchor:
* [https://delvingbitcoin.org/t/lightning-transactions-with-v3-and-ephemeral-anchors/418 "Lightning transactions with v3 and ephemeral anchors"]

 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:

<br />Related proposal for changing the amount of bandwidth that replacement transactions use:

 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

  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:

Senders 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:

Users 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

  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:

Instead 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

  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:

to 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

  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:

Pinning 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

  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:

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.

glozow commented at 9:36 AM on March 26, 2024:

taken

   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!

   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

  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:

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

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

  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:

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

 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:

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

 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.

 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?

 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:

rate of 0.5sat/vB to relay transactions, which is below our "free relay" threshold of 1sat/vB.

   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

   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.

   Layer: Applications
   Title: Topology Restrictions for Pinning
   Author: Gloria Zhao <gloriajzhao@gmail.com>
-  Comments-URI:
+  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0431
   Status: Draft
   Type: Informational
   Created: 2024-01-10
   License: BSD-3-Clause
   Post-History: 2022-01-27: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019817.html [bitcoin-dev] discussion
-               2022-01-27: https://gist.github.com/glozow/25d9662c52453bd08b4b4b1d3783b9ff gist discussion
-               2022-09-23: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020937.html [bitcoin-dev] proposal
-               2024-01-02: https://delvingbitcoin.org/t/v3-transaction-policy-for-anti-pinning/340 Delving Bitcoin post
-               2024-01-16: https://delvingbitcoin.org/t/lightning-transactions-with-v3-and-ephemeral-anchors/418 Delving Bitcoin post
+                2022-01-27: https://gist.github.com/glozow/25d9662c52453bd08b4b4b1d3783b9ff gist discussion
+                2022-09-23: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020937.html [bitcoin-dev] proposal
+                2024-01-02: https://delvingbitcoin.org/t/v3-transaction-policy-for-anti-pinning/340 Delving Bitcoin post
+                2024-01-16: https://delvingbitcoin.org/t/lightning-transactions-with-v3-and-ephemeral-anchors/418 Delving Bitcoin post
 </pre>

glozow commented at 7:14 AM on May 23, 2024:

That fixed it, thanks!

 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:

* https://github.com/bitcoin/bitcoin/pull/28948
* https://github.com/bitcoin/bitcoin/pull/29873
* https://github.com/bitcoin/bitcoin/pull/29496

glozow commented at 2:26 PM on May 23, 2024:

done

 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:

<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

 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:

<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

 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:

<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

 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:

<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

 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:

<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

 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:

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

 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:

<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

 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:

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

  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!

 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 👍

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