MIME-Version: 1.0
References: <CALZpt+GdyfDotdhrrVkjTALg5DbxJyiS8ruO2S7Ggmi9Ra5B9g@mail.gmail.com>
 <eW4O0HQJ2cbrzZhXSlgeDRWuhgRHXcAxIQCHJiqPh1zUxr270xPvl_tb7C4DUauZy56HaCq6BqGN9p4k-bkqQmLb4EHzPgIxZIZGVPlqyF0=@protonmail.com>
 <64VpLnXQLbeoc895Z9aR7C1CfH6IFxPFDrk0om-md1eqvdMczLSnhwH29T6EWCXgiGQiRqQnAYsezbvNvoPCdcfvCvp__Y8BA1ow5UwY2yQ=@protonmail.com>
 <ZTJW59wQ/4WLZt2h@petertodd.org> <ZTJej/ipIl5hZIUn@petertodd.org>
In-Reply-To: <ZTJej/ipIl5hZIUn@petertodd.org>
From: Matt Morehouse <mattmorehouse@gmail.com>
Date: Fri, 20 Oct 2023 18:35:26 +0000
Message-ID: <CAGyamEVGe+z96Rc52V0j=a+He3frzhHEk_NPunXA-g1MwXXdGw@mail.gmail.com>
To: Peter Todd <pete@petertodd.org>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: security@ariard.me,
 "lightning-dev\\\\\\\\\\\\\\\\@lists.linuxfoundation.org"
 <lightning-dev@lists.linuxfoundation.org>
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"
Precedence: list

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=E2=80=AFAM Peter Todd via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> On Fri, Oct 20, 2023 at 10:31:03AM +0000, Peter Todd via bitcoin-dev wrot=
e:
> > As I have suggested before, the correct way to do pre-signed transactio=
ns 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-si=
gning 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 wit=
h a
> smaller multiplier at the beginning of the range, and ending with a bigge=
r 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 wil=
l mean
> that the replacements may have HTLCs removed, when their value drops belo=
w the
> fees necessary to get those outputs mined.
>
> Note too that we can sign simultaneous variants of transactions that dedu=
ct 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 certa=
inly
> do that with plain old OP_CheckMultisig.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev