public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Matt Corallo <lf-lists@mattcorallo.com>
To: Matt Morehouse <mattmorehouse@gmail.com>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>,
	Peter Todd <pete@petertodd.org>
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"
Date: Fri, 20 Oct 2023 17:05:48 -0400	[thread overview]
Message-ID: <1a84a36c-ec23-43b5-9a61-1aafdc188892@mattcorallo.com> (raw)
In-Reply-To: <CAGyamEVGe+z96Rc52V0j=a+He3frzhHEk_NPunXA-g1MwXXdGw@mail.gmail.com>

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


  reply	other threads:[~2023-10-20 21:05 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-16 16:57 [bitcoin-dev] Full Disclosure: CVE-2023-40231 / CVE-2023-40232 / CVE-2023-40233 / CVE-2023-40234 "All your mempool are belong to us" Antoine Riard
2023-10-16 19:13 ` Peter Todd
2023-10-16 22:10   ` Matt Morehouse
2023-10-17  1:11   ` Antoine Riard
2023-10-20 10:47     ` Peter Todd
2023-10-20 11:18       ` Jochen Hoenicke
2023-10-16 22:51 ` Olaoluwa Osuntokun
2023-10-17  7:21 ` [bitcoin-dev] [Lightning-dev] " ziggie1984
2023-10-17 10:34   ` ZmnSCPxj
2023-10-17 18:34     ` Antoine Riard
2023-10-20 10:31     ` Peter Todd
2023-10-20 11:03       ` Peter Todd
2023-10-20 18:35         ` Matt Morehouse
2023-10-20 21:05           ` Matt Corallo [this message]
2023-10-21  0:15             ` Peter Todd
2023-10-21  1:03               ` Matt Corallo
2023-10-21  1:25                 ` Peter Todd
2023-10-21  1:55                   ` Matt Corallo
2023-10-21  2:43                     ` Peter Todd
2023-10-23 16:09                       ` Matt Corallo
2023-10-17 17:47   ` Antoine Riard
2023-10-17 18:47     ` Antoine Riard
2023-10-18  0:17 ` Matt Corallo
2023-10-18  2:57   ` Antoine Riard
2023-10-19  8:12     ` Bastien TEINTURIER
2023-10-19 16:23   ` Matt Morehouse
2023-10-19 17:22     ` Antoine Riard
2023-10-19 17:53       ` Matt Morehouse
2023-10-19 19:33         ` Antoine Riard
2023-10-21  0:18           ` Olaoluwa Osuntokun
2023-11-17 22:36             ` Antoine Riard
2023-10-19 18:02     ` Matt Corallo
2023-10-20  6:56 ` [bitcoin-dev] " Antoine Riard
2023-10-21 20:05   ` Antoine Riard
2023-10-27  0:43     ` Peter Todd
2023-11-02  4:46     ` Antoine Riard
2023-10-21  0:09 ` [bitcoin-dev] OP_Expire and Coinbase-Like Behavior: Making HTLCs Safer by Letting Transactions Expire Safely Peter Todd
2023-10-21  8:58   ` David A. Harding
2023-10-21 10:31     ` Peter Todd
2023-10-22  8:30   ` vjudeu
2023-10-23 11:10   ` [bitcoin-dev] [Lightning-dev] " ZmnSCPxj
2023-10-23 15:45     ` Peter Todd
2023-11-02  5:24   ` [bitcoin-dev] " Antoine Riard
2023-11-02  6:26     ` Peter Todd
2023-11-02 17:07       ` Matt Morehouse
2023-11-03  5:27         ` Antoine Riard
2023-11-03  5:25       ` Antoine Riard
2023-11-04  7:26         ` Peter Todd
2023-11-06 18:45           ` Antoine Riard
2023-11-07 11:11             ` [bitcoin-dev] [Lightning-dev] " ZmnSCPxj
2023-11-07 15:44               ` Antoine Riard
2023-11-08  0:51             ` [bitcoin-dev] " Peter Todd
2023-11-08  2:06               ` Peter Todd
2023-11-13  2:18                 ` Antoine Riard
2023-11-14 19:50                   ` Peter Todd
     [not found]                     ` <CALZpt+H38cU9L8kq0mSYCDirzL39fxhdoz4pAPiS8dGJP8akKg@mail.gmail.com>
2023-11-15 17:53                       ` [bitcoin-dev] Fwd: " Antoine Riard
2023-10-22  4:49 ` [bitcoin-dev] Full Disclosure: CVE-2023-40231 / CVE-2023-40232 / CVE-2023-40233 / CVE-2023-40234 "All your mempool are belong to us" Nadav Ivgi
2023-10-23  8:49   ` David A. Harding
2023-10-21 14:21 [bitcoin-dev] [Lightning-dev] " Nagaev Boris

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1a84a36c-ec23-43b5-9a61-1aafdc188892@mattcorallo.com \
    --to=lf-lists@mattcorallo.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=lightning-dev@lists.linuxfoundation.org \
    --cc=mattmorehouse@gmail.com \
    --cc=pete@petertodd.org \
    --cc=security@ariard.me \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox