summaryrefslogtreecommitdiff
path: root/b3/0e486c7897de4a82de02e430602d18d24ed388
blob: d73e920e5a96da2d183af8964d338b8390995420 (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
Return-Path: <lf-lists@mattcorallo.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id A3DB8C0032;
 Sat, 21 Oct 2023 01:55:23 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 6BBF484D4E;
 Sat, 21 Oct 2023 01:55:23 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 6BBF484D4E
Authentication-Results: smtp1.osuosl.org;
 dkim=pass (2048-bit key) header.d=mattcorallo.com header.i=@mattcorallo.com
 header.a=rsa-sha256 header.s=1697851262 header.b=CcijblC0; 
 dkim=pass (2048-bit key) header.d=clients.mail.as397444.net
 header.i=@clients.mail.as397444.net header.a=rsa-sha256 header.s=1697851263
 header.b=bENwD389
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 smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id zNOzQH-wX99I; Sat, 21 Oct 2023 01:55:19 +0000 (UTC)
Received: from mail.as397444.net (mail.as397444.net [69.59.18.99])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 87C4984D3F;
 Sat, 21 Oct 2023 01:55:18 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 87C4984D3F
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=mattcorallo.com; s=1697851262; h=In-Reply-To:From:References:Cc:To:Subject:
 From:Subject:To:Cc:Reply-To; bh=TD42ybGzno0I5yZomDZAGX9IdgYTByBtBrfmKD18UBM=; 
 b=CcijblC0PrnSNw+QfMCdILU9bNZKrbHLBJy1YGnRbYLzRDrKr1CTJzYbiy+792wntDeY3jbW2Jw
 0N0BFvVpg9orR4amPcboyVwpOCijtBO5GrBfi8bGqJBKT8ws8hQhiSWuYpjVm4zrD79YhRjV17ViP
 sC1RR+BPrlNkHr3R5O2u20JBGdkRnQEqRxP4GGRgpLAigKB/BEcKk8DR+SfsgJ43xHrJN3rCWSViT
 /xog8noWtup0/SXvx/yvlALDkhBDTtesatA1nz9tkTsBOhgGNFNRZOcT+Vdi4OI8V6UUbbQiNnIas
 5RD6g/aOTe8mZlsmPqBVlrXwMudhFKePNLrQ==;
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=clients.mail.as397444.net; s=1697851263; h=In-Reply-To:From:References:Cc:
 To:Subject:From:Subject:To:Cc:Reply-To;
 bh=TD42ybGzno0I5yZomDZAGX9IdgYTByBtBrfmKD18UBM=; b=bENwD389/dQR4wpd0JoQAHP0em
 1Q4krghNhc56S30DkItpSyVi+d54AMQ3y8DEiBeP9/lz0PkH8MwyfcAfC7MvprPsS9SRIJeh2T0sS
 eRU4mVCCE7abbc7LWf/KkiGI4adltPLvS8UPcxaf74Ka9xmyFFLgPiQT9R/E+wVpue4DUs292Ubwp
 TcpdAzaWCcCQ4U6zCm5cUAmTvO8uHioW4qCkIbRHhubCT54eJknoFElvJxAl2kEMVRtCF0vV5GqB/
 bdb1lI2JzOSxQd1O/T84sWMk8xJZnzW0/adfuIHPycErYigvU14PjgQySD8qac6zyp7OtEuBeIoaL
 GapgRoEg==;
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 1qu1Cs-001YdD-1L;
 Sat, 21 Oct 2023 01:55:14 +0000
Message-ID: <c7ca9861-0734-4065-851a-8af9cabd7e87@mattcorallo.com>
Date: Fri, 20 Oct 2023 21:55:12 -0400
MIME-Version: 1.0
Content-Language: en-US
To: 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>
 <1a84a36c-ec23-43b5-9a61-1aafdc188892@mattcorallo.com>
 <ZTMYGcRvHh0Iwe2y@petertodd.org>
 <24a18bdd-eef6-4f96-b8a5-05f64130a5c5@mattcorallo.com>
 <ZTModpNyIQ3qFFI3@petertodd.org>
From: Matt Corallo <lf-lists@mattcorallo.com>
In-Reply-To: <ZTModpNyIQ3qFFI3@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: Sat, 21 Oct 2023 01:55:23 -0000



On 10/20/23 9:25 PM, Peter Todd wrote:
> On Fri, Oct 20, 2023 at 09:03:49PM -0400, Matt Corallo wrote:
>>> What are anchor outputs used for other than increasing fees?
>>>
>>> Because if we've pre-signed the full fee range, there is simply no need for
>>> anchor outputs. Under any circumstance we can broadcast a transaction with a
>>> sufficiently high fee to get mined.
>>
>>
>> Indeed, that is what anchor outputs are for. Removing the pre-set feerate
>> solved a number of issues with edge-cases and helped address the
>> fee-inflation attack. Now, just using pre-signed transactions doesn't have
>> to re-introduce those issues - as long as the broadcaster gets to pick which
>> of the possible transactions they broadcast its just another transaction of
>> theirs.
>>
>> Still, I'm generally really dubious of the multiple pre-signed transaction
>> thing, (a) it would mean more fee overhead (not the end of the world for a
>> force-closure, but it sucks to have all these individual transactions
>> rolling around and be unable to batch), but more importantly (b) its a bunch
>> of overhead to keep track of a ton of variants across a sufficiently
>> granular set of feerates for it to not result in substantially overspending
>> on fees.
> 
> 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.

> 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.

Matt