summaryrefslogtreecommitdiff
path: root/f8/66b5a663eef83f9b9399d7ef8467c77bab9804
blob: 390253fbbfb94a668d884535d4ce56125ac48218 (plain)
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
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
Return-Path: <pete@petertodd.org>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 86DEFC0032;
 Sat, 21 Oct 2023 02:43:43 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 3D2E984DCB;
 Sat, 21 Oct 2023 02:43:43 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 3D2E984DCB
Authentication-Results: smtp1.osuosl.org; dkim=pass (2048-bit key,
 unprotected) header.d=messagingengine.com header.i=@messagingengine.com
 header.a=rsa-sha256 header.s=fm3 header.b=QBIi+rDb
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H5=0.001,
 RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
Received: from smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id rjkrDIMwn6eA; Sat, 21 Oct 2023 02:43:38 +0000 (UTC)
Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com
 [64.147.123.21])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 9389384DF2;
 Sat, 21 Oct 2023 02:43:38 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 9389384DF2
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41])
 by mailout.west.internal (Postfix) with ESMTP id 4237F3200982;
 Fri, 20 Oct 2023 22:43:37 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162])
 by compute1.internal (MEProxy); Fri, 20 Oct 2023 22:43:37 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
 messagingengine.com; h=cc:cc:content-type:content-type:date:date
 :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to
 :message-id:mime-version:references:reply-to:sender:subject
 :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender
 :x-sasl-enc; s=fm3; t=1697856216; x=1697942616; bh=II123YEYSN56U
 WH3YyNJ8lXr2TJrP9sFJ5gAFokAj68=; b=QBIi+rDbDZbJA7lu7nHcRPiJH8FF5
 Pqv5Lik0A0gEudCWqJj9mR4Ju1pTTQLiyGpHQ7AkZ7CTZeREBnAmBy/nIIoVwZA4
 FvZNzeyNGb04+IcDtaHEkzlB+5/F9UDTl31rJUnDZygbq2V8h0570JiIL4rgQYth
 M+VmrumfmrOvlSB9sWMirc87lw1oCmVhVyeh6oi340yiGIWjMEkHR+hcmKFLWEL2
 zg4WrJFbsGWVjCDp3nKeO9BVDJoSZ4/vq0ZnsTjuv0F4HA1ZmFigrI2WMV+k5Qiz
 1u/bmimPbrRmicF+gmDCHRCwa0g9Z4CVYczZoOSKaqZj9M5mle2RyXlAg==
X-ME-Sender: <xms:1zozZS3wsFZ1J7EpftpJ5Rx_IEXOxQRZnoLJW3Vi-OqsnBBqnOgGkg>
 <xme:1zozZVHNkJjZxUo_8TU5ku9DywT5ur5UCRyVxBdbqssqjP8yjG1uUIqn-wtY59uMs
 0vb3n8Gt0jIuq7dQQ8>
X-ME-Received: <xmr:1zozZa6JKopZQrSahiqHy7tnd2aFN1xpcgIkgNWZRz86dIhSUuh9aQ1W3HFdl9Rvq28A5Ytm55LK0VixlBIt_E05ZAMAtNYTgk8sNARnqQHmBQad>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrjeelgdehlecutefuodetggdotefrodftvf
 curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu
 uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc
 fjughrpeffhffvvefukfhfgggtuggjsehgtderredttddvnecuhfhrohhmpefrvghtvghr
 ucfvohguugcuoehpvghtvgesphgvthgvrhhtohguugdrohhrgheqnecuggftrfgrthhtvg
 hrnhepledvleelffdtudekudffjefgfeejueehieelfedtgfetudetgeegveeutefhjedt
 necuffhomhgrihhnpehpvghtvghrthhouggurdhorhhgnecuvehluhhsthgvrhfuihiivg
 eptdenucfrrghrrghmpehmrghilhhfrhhomhepphgvthgvsehpvghtvghrthhouggurdho
 rhhg
X-ME-Proxy: <xmx:1zozZT1fGiGBYjWmnU17xxSwTEX4TvfXzGY1XXtfMYUDZbjWlwUokw>
 <xmx:1zozZVEfS7jwXmK0Cewz_LTQRCj8DQw3AA6qqJ2-jQXVqlIe78E1IQ>
 <xmx:1zozZc-3sZM1S_PS6ZlaGWGTf9KlJtSAxpG4ncyzKwEdXjoJIvmPWw>
 <xmx:2DozZa66nsQH_ok5QOwBzWc3zZawyUYNeje9nHrfIG4vA_hzjBdCXQ>
Feedback-ID: i525146e8:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri,
 20 Oct 2023 22:43:35 -0400 (EDT)
Received: by localhost (Postfix, from userid 1000)
 id 73B415F86A; Sat, 21 Oct 2023 02:43:31 +0000 (UTC)
Date: Sat, 21 Oct 2023 02:43:31 +0000
From: Peter Todd <pete@petertodd.org>
To: Matt Corallo <lf-lists@mattcorallo.com>
Message-ID: <ZTM607UFnxgXPSNp@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>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature"; boundary="CedIk7JjJKWOfgrM"
Content-Disposition: inline
In-Reply-To: <c7ca9861-0734-4065-851a-8af9cabd7e87@mattcorallo.com>
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: Sat, 21 Oct 2023 02:43:43 -0000


--CedIk7JjJKWOfgrM
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Oct 20, 2023 at 09:55:12PM -0400, Matt Corallo wrote:
> > Quite the contrary. Schnorr signatures are 64 bytes, so in situations l=
ike
> > lightning where the transaction form is deterministically derived, sign=
ing 100
> > extra transactions requires just 6400 extra bytes. Even a very slow 100=
KB/s
> > connection can transfer that in 64ms; latency will still dominate.
>=20
> 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 rea=
lly
> 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.

Per channel, with the above numbers, you'd need <10KB worth of extra signat=
ures
to fee bump the current commitment (with pre-signed txs), and if HTLCs happ=
en
to be in flight, say <10KB of extra signatures per HTLC.

Amazon AWS charges $0.125/GB/month for their most expensive SSD volumes. Le=
t's
round that up to $1/GB/month to account for RAID and backups. Let's say each
channel constantly has 483 HTLC's in flight, and each HTLC is associated wi=
th
~10KB of extra data for pre-signed transactions.

That's ~5MB/channel of data you constantly need to store, or $0.005/month.

In what world is that too expensive or too much of a pain to deal with? If
you're node is actually that busy, you're probably making that cost back per
channel every minute, or better.

> > 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/vByt=
e to
> > 100sat/vByte. I believe that is sufficient to get mined for any block in
> > Bitcoin's entire modern history.
> >=20
> > CPFP meanwhile requires two transactions, and thus extra bytes. Other t=
han edge
> > cases with very large transactions in low-fee environments, there's no
> > circumstance where CPFP beats RBF.
>=20
> 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%

Of course, if you _do_ need to fee bump and add an additional input, that i=
nput
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 spen=
t.
That's very often not the case.

--=20
https://petertodd.org 'peter'[:-1]@petertodd.org

--CedIk7JjJKWOfgrM
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmUzOtEACgkQLly11TVR
LzeyLw/8DjdYmEWuCDfdXUX3j8NY0wH5RdOQvp5sojBjD8eoj9SZathHnQNk91Fs
GBhXNNw+Ib8EpH8EtzZN67lYlhPVe0xyGZfjN1yulgkPjsugLmpagHbNQ6em6ACq
eU/R12sjc7LFZ1ncbTIuj9HUY/TSbcbUrnH9R7BetR1YQnlZBtAAj+O3Pt8cQLxX
PMEnWhDXfYELFzWr/jMQPw61wioK40TAL8iD4CfYqg617VhfgTp3oMIQD3LwP+eT
fpANHyaMyvL3jcJvIWSSBwLz5peMMUujo+gRfcKLTF2UNF5q+Zyc69xfFqtgqp59
vAQ7c2J2oJWHe42c7GzEBurfulMAy8Rk3t1ry4zooCFbotQRVFLC/9p0KOEBE4BE
goPE1FBI2EsS0nQZxa3VG1AmRX9Bv+9h9OXWcX2N9zW/IpfcgEUmMvv2VdyCZ4vj
bx94px6IzzHgZIXKUjgBku8r6Lc4k7QqqPzcimNmLFjWj4gUytvE1hXiu1o534Xw
IGnLoG/51yRavbbmj9rVAV4mowMRL2kVexJwSbetIDAjpCQ0K5teoshkQkAmxIdp
W7wWpWiTPMdXduTFXis26a0dZePaJHOzwFaFwTqA7kNZPdKjPjD4TbO+BH5lhjjX
pDqSRnMGfHttQrIAfmJXe9Ne4SJbTiUehD2KJEmzhS9oIkD2/ZE=
=axbj
-----END PGP SIGNATURE-----

--CedIk7JjJKWOfgrM--