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
|
Return-Path: <lf-lists@mattcorallo.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 7A9E3C0032;
Mon, 23 Oct 2023 16:09:56 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id 5685B61262;
Mon, 23 Oct 2023 16:09:56 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 5685B61262
Authentication-Results: smtp3.osuosl.org;
dkim=pass (2048-bit key) header.d=mattcorallo.com header.i=@mattcorallo.com
header.a=rsa-sha256 header.s=1698075662 header.b=PW15pDzv;
dkim=pass (2048-bit key) header.d=clients.mail.as397444.net
header.i=@clients.mail.as397444.net header.a=rsa-sha256 header.s=1698075664
header.b=Q2fLVCmn
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 smtp3.osuosl.org ([127.0.0.1])
by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id fKOCpjz2P7Kb; Mon, 23 Oct 2023 16:09:55 +0000 (UTC)
Received: from mail.as397444.net (mail.as397444.net [69.59.18.99])
by smtp3.osuosl.org (Postfix) with ESMTPS id CFBD861261;
Mon, 23 Oct 2023 16:09:54 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org CFBD861261
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
d=mattcorallo.com; s=1698075662; h=In-Reply-To:From:References:Cc:To:Subject:
From:Subject:To:Cc:Reply-To; bh=PdZNMpEFEZ7jaLrW99QuDnSQkkTgDYWfWqWgZ2BBnsM=;
b=PW15pDzvsFZC5U5VTQrm/2VatuVtKnOGL+32p9p7vzfwWvyjZk4Mv9R03be40EzvGRrqdY0OJ7k
DKRbgEPWGjTdPkjc8C6UrShVQ7wvb6sHlif19wbWFnwpfrvIe1uETJ3OwCkzwmPGOxEgOZccOjTah
mYA4BBEeVDf2UynnGGyPY9TF+Ae5kk4xDJNHsUEdd2tnMEe3k/luq3FKM1P5NUg1iDjK40bsMmXqP
ZG2flBzZN+rM32wD6sWpl5HH8EpWp2MKEdXt6S40GASzFOj+sbeTAXscRrQ+IOMio8CSIAJ7m5PAv
8l21K3Ch6aY71pHRQk2f8TyoqHLwLb+XrsyA==;
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
d=clients.mail.as397444.net; s=1698075664; h=In-Reply-To:From:References:Cc:
To:Subject:From:Subject:To:Cc:Reply-To;
bh=PdZNMpEFEZ7jaLrW99QuDnSQkkTgDYWfWqWgZ2BBnsM=; b=Q2fLVCmnrL3VvuyP/OeIGEsAY6
QLeEqdhIPXTLKzFlJ3KGm0fjY8oFAk3Sqi3Uwbk+lvw9f1kqlmp4+MBzENJcP2NodUcg7lBVDvok1
LjZJoLlrKIJmoC21QHeFlLAq9KFEgieNSyBv4D2O3ZH5BjZ3Oho+mgsAqRHNO/jzSsFTAAmPSA9b7
SlW0+q65smsHcl4C4vyl3VIaw+I5/6GM+SVfhEe0NvbjHCt1VwlIPPzxejomKRQzekqDIHNcYZmB0
k9SGttOxKCGwChd/KD3ALLiiiBdfjOYoj99EdJkW9hULT9AwOCOrJlX1CPlnD0oZpp3XfB9shWA0O
gyhsY8bw==;
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 1quxV1-001xMA-1e;
Mon, 23 Oct 2023 16:09:51 +0000
Message-ID: <82353ef0-71c3-4c18-8e2b-80c69a391212@mattcorallo.com>
Date: Mon, 23 Oct 2023 09:09:50 -0700
MIME-Version: 1.0
Content-Language: en-US
To: Peter Todd <pete@petertodd.org>
References: <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>
<1a84a36c-ec23-43b5-9a61-1aafdc188892@mattcorallo.com>
<ZTMYGcRvHh0Iwe2y@petertodd.org>
<24a18bdd-eef6-4f96-b8a5-05f64130a5c5@mattcorallo.com>
<ZTModpNyIQ3qFFI3@petertodd.org>
<c7ca9861-0734-4065-851a-8af9cabd7e87@mattcorallo.com>
<ZTM607UFnxgXPSNp@petertodd.org>
From: Matt Corallo <lf-lists@mattcorallo.com>
In-Reply-To: <ZTM607UFnxgXPSNp@petertodd.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
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: Mon, 23 Oct 2023 16:09:56 -0000
On 10/20/23 7:43 PM, Peter Todd wrote:
> On Fri, Oct 20, 2023 at 09:55:12PM -0400, Matt Corallo wrote:
>>> Quite the contrary. Schnorr signatures are 64 bytes, so in situations like
>>> lightning where the transaction form is deterministically derived, signing 100
>>> extra transactions requires just 6400 extra bytes. Even a very slow 100KB/s
>>> connection can transfer that in 64ms; latency will still dominate.
>>
>> Lightning today isn't all that much data, but multiply it by 100 and we
>> start racking up data enough that people may start to have to store a really
>> material amount of data for larger nodes and dealing with that starts to be
>> a much bigger pain then when we're talking about a GiB or twenty.
>
> We are talking about storing ephemeral data here, HTLC transactions and
> possibly commitment transactions. Since lightning uses disclosed secrets to
> invalidate old state, you do not need to keep every signature from your
> counterparty indefinitely.
Mmm, fair point, yes.
>>> RBF has a minimum incremental relay fee of 1sat/vByte by default. So if you use
>>> those 100 pre-signed transaction variants to do nothing more than sign every
>>> possible minimum incremental relay, you've covered a range of 1sat/vByte to
>>> 100sat/vByte. I believe that is sufficient to get mined for any block in
>>> Bitcoin's entire modern history.
>>>
>>> CPFP meanwhile requires two transactions, and thus extra bytes. Other than edge
>>> cases with very large transactions in low-fee environments, there's no
>>> circumstance where CPFP beats RBF.
>>
>> What I was referring to is that if we have the SIGHASH_SINGLE|ANYONECANPAY
>> we can combine many HTLC claims into one transaction, vs pre-signing means
>> we're stuck with a ton of individual transactions.
>
> Since SIGHASH_SINGLE requires one output per input, the savings you get by
> combining multiple SIGHASH_SINGLE transactions together aren't very
> significant. Just 18 bytes for nVersion, nLockTime, and the txin and txout size
> fields. The HTLC-timeout transaction is 166.5 vBytes, so that's a savings of
> just 11%
Yep, its not a lot, but for a thing that's inherently super chain-spammy, its still quite nice.
> Of course, if you _do_ need to fee bump and add an additional input, that input
> takes up space, and you'll probably need a change output. At which point you
> again would probably have been better off with a pre-signed transaction.
>
> You are also assuming there's lots of HTLC's in flight that need to be spent.
> That's very often not the case.
In general, yes, in force-close cases often there's been some failure which is repeated in several
HTLCs :).
More generally, I think we're getting lost here - this isn't really a material change for
lightning's trust model - its already the case that a peer that is willing to put a lot of work in
can probably steal your money, and there's now just one more way they can do that. We really don't
need to rush to "fix lightning" here, we can do it right and fix it at the ecosystem level. It
shouldn't be the case that a policy restriction results in both screwing up a L2 network *and*
results in miners getting paid less. That's a policy bug.
Matt
|
