1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
|
Return-Path: <lf-lists@mattcorallo.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
by lists.linuxfoundation.org (Postfix) with ESMTP id 2B2AAC0032;
Fri, 20 Oct 2023 21:05:59 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id 00C5641E5C;
Fri, 20 Oct 2023 21:05:59 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 00C5641E5C
Authentication-Results: smtp4.osuosl.org;
dkim=pass (2048-bit key) header.d=mattcorallo.com header.i=@mattcorallo.com
header.a=rsa-sha256 header.s=1697834462 header.b=P+4BnGlh;
dkim=pass (2048-bit key) header.d=clients.mail.as397444.net
header.i=@clients.mail.as397444.net header.a=rsa-sha256 header.s=1697834465
header.b=S16zlg9I
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.102
X-Spam-Level:
X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_PASS=-0.001,
SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp4.osuosl.org ([127.0.0.1])
by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id lArZzUssu2pX; Fri, 20 Oct 2023 21:05:57 +0000 (UTC)
Received: from mail.as397444.net (mail.as397444.net [69.59.18.99])
by smtp4.osuosl.org (Postfix) with ESMTPS id 57D4B41E46;
Fri, 20 Oct 2023 21:05:57 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 57D4B41E46
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
d=mattcorallo.com; s=1697834462; h=In-Reply-To:From:References:Cc:To:Subject:
From:Subject:To:Cc:Reply-To; bh=ZPxZvU/RF6DYWXLJPtlBd3jsejviEjnCBntjsFYgY+g=;
b=P+4BnGlhXXHmWBcaVp9pupAQxfomAu4H+KGe70iOo0X9Euftp8cBYpv8Sqa2FEUqYlQ44QDofN9
Mi/ZfejffS+Lny5PTt67+bg70byZh7O3utrMzCmWD9SC5qInx4yKq9w0Q3X15ip1Zb7oE0QThuZeV
M5pkVfoBGUW3x8ShGUvNvpu7i3bXkJqtWYBK/oNGZad6rbb6NgcilQQZ2Ls8RNaM5YDxtEZyTn0ZM
e1owC/CRkkAtZmtAHYsBGKJUssPVQ9D+mC8gXwKEzLW5WKbO/036uFV5SIx+19Cin+Yy4pMxpgyuQ
FH6wdbJ8PxE5IDigN8yjouG0Uar5V0xaPeWQ==;
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
d=clients.mail.as397444.net; s=1697834465; h=In-Reply-To:From:References:Cc:
To:Subject:From:Subject:To:Cc:Reply-To;
bh=ZPxZvU/RF6DYWXLJPtlBd3jsejviEjnCBntjsFYgY+g=; b=S16zlg9IHrt2iMusgffeZewURN
0gKisbbbJmMIgvOjAQbeR3Ow7fyI+BiWnCKkGNlBWMURItIZMOu7ILcsqB4FsrMOruedOPjTEnExM
tFwN47WaA7rNtLcQDkem74bdxk2oFfn0pdiQaiut4h+F+GXlOBaDd+hJ0ckffQBEtF0Y0T/eEBQtu
Z+DrPcygY0B7gE2IEeaBqE8u1SG93acM1mro50i4hdZmeO9aqOAjUqMwhIcDATkA78Rs2k1Idlzli
xDSuhDqbu/BZBFY542qe/OR/TY+mTSO87ZzlVyp3IFNyPtZh5FTs0YUOcu4/WsZermfFZoojZtdb5
y14w/C8g==;
X-DKIM-Note: Keys used to sign are likely public at
X-DKIM-Note: https://as397444.net/dkim/mattcorallo.com and
X-DKIM-Note: https://as397444.net/dkim/clients.mail.as397444.net
X-DKIM-Note: For more info, see https://as397444.net/dkim/
Received: by mail.as397444.net with esmtpsa (TLS1.3) (Exim)
(envelope-from <lf-lists@mattcorallo.com>) id 1qtwgr-001We6-2k;
Fri, 20 Oct 2023 21:05:53 +0000
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"
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Oct 2023 21:05:59 -0000
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
|
