Message-ID: <1a84a36c-ec23-43b5-9a61-1aafdc188892@mattcorallo.com>
Date: Fri, 20 Oct 2023 17:05:48 -0400
MIME-Version: 1.0
Content-Language: en-US
To: Matt Morehouse <mattmorehouse@gmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 Peter Todd <pete@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>
 <CAGyamEVGe+z96Rc52V0j=a+He3frzhHEk_NPunXA-g1MwXXdGw@mail.gmail.com>
From: Matt Corallo <lf-lists@mattcorallo.com>
In-Reply-To: <CAGyamEVGe+z96Rc52V0j=a+He3frzhHEk_NPunXA-g1MwXXdGw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
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

Sadly this only is really viable for pre-anchor channels. With anchor channels the attack can be 
performed by either side of the closure, as the HTLCs are now, at max, only signed 
SIGHASH_SINGLE|ANYONECANPAY, allowing you to add more inputs and perform this attack even as the 
broadcaster.

I don't think its really viable to walk that change back to fix this, as it also fixed plenty of 
other issues with channel usability and important edge-cases.

I'll highlight that fixing this issue on the lightning end isn't really the right approach generally 
- we're talking about a case where a lightning counterparty engineered a transaction broadcast 
ordering such that miners are *not* including the optimal set of transactions for fee revenue. Given 
such a scenario exists (and its not unrealistic to think someone might wish to engineer such a 
situation), the fix ultimately needs to lie with Bitcoin Core (or other parts of the mining stack).

Now, fixing this in the Bitcoin Core stack is no trivial deal - the reason for this attack is to 
keep enough history to fix it Bitcoin Core would need unbounded memory. However, its not hard to 
imagine a simple external piece of software which monitors the mempool for transactions which were 
replaced out but which may be able to re-enter the mempool later with other replacements and store 
them on disk. From there, this software could optimize the revenue of block template selection, 
while also accidentally fixing this issue.

Matt

On 10/20/23 2:35 PM, Matt Morehouse via bitcoin-dev wrote:
> 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@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@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev