RBF: Require unconfirmed inputs to come from a single conflicting transaction #29297

1. 
   petertodd commented at 9:03 pm on January 23, 2024: contributor

   Extends BIP-125 Rule #2 slightly. Rational: if we allow unconfirmed inputs to come from multiple conflicts, we could allow a desirable transaction, and an undesirable transaction, to be replaced by a single undesirable transaction.

   This solves the same problem that #26451 was intended to solve, in a simpler way.

   May not actually be worth adding to Bitcoin Core, as other solutions are coming. But I wrote the code for my replace-by-fee-rate work, where it fixes the infinite replacement cycle issue @murchandamus outlines here, so I figured I might as well open a pull-req.

2. Require unconfirmed inputs to come from a single conflict

   Extends BIP-125 Rule #2 slightly. If we allow unconfirmed inputs to come from
   multiple conflicts, we could allow a desirable transaction, and an undesirable
   transaction, to be replaced by a single undesirable transaction.

   beb1f1970b
3. 
   DrahtBot commented at 9:03 pm on January 23, 2024: contributor

   The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

   Code Coverage

   For detailed information about the code coverage, see the test coverage report.

   Reviews

   See the guideline for information on the review process. A summary of reviews will appear here.

   Conflicts

   Reviewers, this pull request conflicts with the following ones:

   • #28886 (refactor: Replace sets of txiter with CTxMemPoolEntryRefs by TheCharlatan)

   If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

4. willcl-ark added the label TX fees and policy on Jan 24, 2024
5. 
   morehouse commented at 9:18 pm on January 24, 2024: none

   As another benefit, I think this change helps prevent replacement cycling attacks against LN. The attacker would be unable to make their preimage spend depend on a second unconfirmed transaction, and therefore couldn’t evict their preimage spend.

   Edit: Actually, I think replacement cycling is still possible because the second parent doesn’t need to be unconfirmed.

6. DrahtBot added the label CI failed on Jan 25, 2024
7. 
   petertodd commented at 0:45 am on January 26, 2024: contributor

   @morehouse

   Actually, I think replacement cycling is still possible because the second parent doesn’t need to be unconfirmed.

   Heh, you nearly noticed the dumb mistake I made here. As Murch mentioned on the mailing list, this does not fix the infinite cycle problem with replace-by-fee-rate, as the second parent isn’t unconfirmed.

   However, if I change this pull req to only allowing fresh confirmed inputs, not including in an existing conflict, if transaction is being replaced that spends unconfirmed outputs, I think we’ve solved both, if only accidentally. :)

8. 
   petertodd commented at 0:19 am on January 28, 2024: contributor

   Closing. Turns out the exploit this was meant to solve doesn’t actually exist: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2024-January/022314.html
9. petertodd closed this on Jan 28, 2024

   ---

Contributors
petertodd DrahtBot morehouse

Labels
TX fees and policy CI failed