Subject: Re: [bitcoin-dev] [Lightning-dev] Full Disclosure: CVE-2023-40231 / CVE-2023-40232 / CVE-2023-40233 / CVE-2023-40234 "All your mempool are belong to us"

From: Peter Todd <[email-masked]>
Date: Fri, 20 Oct 2023 11:03:43 +0000

On Fri, Oct 20, 2023 at 10:31:03AM +0000, Peter Todd via bitcoin-dev wrote:
> As I have suggested before, the correct way to do pre-signed transactions is to
> pre-sign enough *different* transactions to cover all reasonable needs for
> bumping fees. Even if you just increase the fee by 2x each time, pre-signing 10
> different replacement transactions covers a fee range of 1024x. And you
> obviously can improve on this by increasing the multiplier towards the end of
> the range.

To be clear, when I say "increasing the multiplier", I mean, starting with a
smaller multiplier at the beginning of the range, and ending with a bigger one.

Eg feebumping with fee increases pre-signed for something like:

    1.1
    1.2
    1.4
    1.8
    2.6
    4.2
    7.4

etc.

That would use most of the range for smaller bumps, as a %, with larger % bumps
reserved for the end where our strategy is changing to something more
"scorched-earth"

And of course, applying this idea properly to commitment transactions will mean
that the replacements may have HTLCs removed, when their value drops below the
fees necessary to get those outputs mined.

Note too that we can sign simultaneous variants of transactions that deduct the
fees from different party's outputs. Eg Alice can give Bob the ability to
broadcast higher and higher fee txs, taking the fees from Bob's output(s), and
Bob can give Alice the same ability, taking the fees from Alice's output(s). I
haven't thought through how this would work with musig. But you can certainly
do that with plain old OP_CheckMultisig.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org