From mattmorehouse at gmail.com  Fri Oct 20 18:35:26 2023
From: mattmorehouse at gmail.com (Matt Morehouse)
Date: Fri, 20 Oct 2023 18:35:26 +0000
Subject: [Lightning-dev] [bitcoin-dev] Full Disclosure: CVE-2023-40231 /
 CVE-2023-40232 / CVE-2023-40233 / CVE-2023-40234 "All your mempool are
 belong to us"
In-Reply-To: <ZTJej/ipIl5hZIUn@petertodd.org>
References: <CALZpt+GdyfDotdhrrVkjTALg5DbxJyiS8ruO2S7Ggmi9Ra5B9g@mail.gmail.com>
 <eW4O0HQJ2cbrzZhXSlgeDRWuhgRHXcAxIQCHJiqPh1zUxr270xPvl_tb7C4DUauZy56HaCq6BqGN9p4k-bkqQmLb4EHzPgIxZIZGVPlqyF0=@protonmail.com>
 <64VpLnXQLbeoc895Z9aR7C1CfH6IFxPFDrk0om-md1eqvdMczLSnhwH29T6EWCXgiGQiRqQnAYsezbvNvoPCdcfvCvp__Y8BA1ow5UwY2yQ=@protonmail.com>
 <ZTJW59wQ/4WLZt2h@petertodd.org> <ZTJej/ipIl5hZIUn@petertodd.org>
Message-ID: <CAGyamEVGe+z96Rc52V0j=a+He3frzhHEk_NPunXA-g1MwXXdGw@mail.gmail.com>

I think if we apply this presigned fee multiplier idea to HTLC spends,
we can prevent replacement cycles from happening.

We could modify HTLC scripts so that *both* parties can only spend the
HTLC via presigned second-stage transactions, and we can always sign
those with SIGHASH_ALL.  This will prevent the attacker from adding
inputs to their presigned transaction, so (AFAICT) a replacement
cycling attack becomes impossible.

The tradeoff is more bookkeeping and less fee granularity when
claiming HTLCs on chain.

On Fri, Oct 20, 2023 at 11:04?AM Peter Todd via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> 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
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev