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
|
Return-Path: <james.obeirne@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 6ADCFC000B
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 14 Feb 2022 19:51:40 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id 5358C81763
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 14 Feb 2022 19:51:40 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001,
HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp1.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=gmail.com
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 bRPnu4heNDwj
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 14 Feb 2022 19:51:39 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-yb1-xb2e.google.com (mail-yb1-xb2e.google.com
[IPv6:2607:f8b0:4864:20::b2e])
by smtp1.osuosl.org (Postfix) with ESMTPS id 6D0D7813BE
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 14 Feb 2022 19:51:39 +0000 (UTC)
Received: by mail-yb1-xb2e.google.com with SMTP id o19so49238389ybc.12
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 14 Feb 2022 11:51:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc; bh=UBJPVvre5aDrM4+jPfxWX8DwPyAkDA3vFP4twqr9skw=;
b=htrmfK6etL/GmBHB/aZwh/Gbw7UAW020/3HhZUCe+owaaEwTxxXD1avEqpJYZpUdIa
g9SgbLyW3eMaY/bRyBIK6QlRdMK+6JiTkHWOV+vwtVC7XzNh7Age0eISQ+7Tpu3H9LEF
hC+sODcTA9x3LLUNkBJivwCHlaHr3xMRgFmI4q6kKs/t3LV+vEiydCPZNIEMB4Pv1bQX
JAdxMklHGOLuxrUr/GurjlmrVtsDE8JvgdidrcHRDa/5ZL+Dld4oRz2rQj8AgRNFUNcB
IT/9sACm3MmaqDimrpk6xD326xHKk1bnslUAOALQaTxV/Of8aeEITMyjnn3Hj45wRzNi
MNMw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:cc;
bh=UBJPVvre5aDrM4+jPfxWX8DwPyAkDA3vFP4twqr9skw=;
b=7OFtpS4sd8Umy65kxoItAEWEJYJbemLaxIygslHyhEYPRYNwSep7YjyRxBmW68Il4s
9Os2Igw268fVNj+53J6BsZ6mL1207Hu7L+W6CsmW/ZRLJk28tkHJWKPIKFvjcREbFWkF
kJbjn3oSO7fRDkMmWA5uii626SI00mZ7pBw5u/ZIKgV3SfZMVxHKCPli5xU+Vp80zBRJ
/sIxkAgrGcNd8p3YZLsa1cho56LMtybu0Wt3h+k6xPgwPGCJL2Bd8joMPQWHg3ujqYJX
rFu7NrHHDBGrBhscczlQhlF7l32aXIy/pHWLMHefy2JVcspuKSgyU4ZnI92S6g4wS67C
7c8A==
X-Gm-Message-State: AOAM5316233sAr1zXf6PBx+GlpkKRPBbdn59EB86wB2VQiW9mB9Gsd/1
j9OfTugQMUCDHBQA4NVT0AFPYsOwhy3KD9J0lE0qxuScKXueZw==
X-Google-Smtp-Source: ABdhPJyCAsSFEFdDIWhL534e2yzXMuY76XhAkLWu0gdE6G18WUknrk0V0SRv2/liI+stmuZ/UZ8ab93lChGHcfI81Tw=
X-Received: by 2002:a81:4528:: with SMTP id s40mr386953ywa.188.1644868297905;
Mon, 14 Feb 2022 11:51:37 -0800 (PST)
MIME-Version: 1.0
References: <CAPfvXfKrnju1fzxOKs3Fx00NOPWHjedF7e4xMSGs8buwc0O2kw@mail.gmail.com>
<8be86b19-04eb-af12-a54c-e1140ac62e3f@mattcorallo.com>
In-Reply-To: <8be86b19-04eb-af12-a54c-e1140ac62e3f@mattcorallo.com>
From: "James O'Beirne" <james.obeirne@gmail.com>
Date: Mon, 14 Feb 2022 14:51:26 -0500
Message-ID: <CAPfvXfJX3sc_QKkWzPVRR=-P4eJb4SsfDNO4XjUxCgN1EK_Tpw@mail.gmail.com>
To: Matt Corallo <lf-lists@mattcorallo.com>
Content-Type: multipart/alternative; boundary="0000000000009958d205d7ffbe7b"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Thoughts on fee bumping
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, 14 Feb 2022 19:51:40 -0000
--0000000000009958d205d7ffbe7b
Content-Type: text/plain; charset="UTF-8"
> This entirely misses the network cost. Yes, sure, we can send
> "diffs", but if you send enough diffs eventually you send a lot of data.
The whole point of that section of the email was to consider the
network cost. There are many cases for which transmitting a
supplementary 1-in-1-out transaction (i.e. a sponsorship txn) is going
to be more efficient from a bandwidth standpoint than rebroadcasting a
potentially large txn during RBF.
> > In an ideal design, special structural foresight would not be
> > needed in order for a txn's feerate to be improved after broadcast.
> >
> > Anchor outputs specified solely for CPFP, which amount to many
> > bytes of wasted chainspace, are a hack. > It's probably
> > uncontroversial at this
>
> This has nothing to do with fee bumping, though, this is only solved
> with covenants or something in that direction, not different relay
> policy.
My post isn't only about relay policy; it's that txn
sponsors allows for fee-bumping in cases where RBF isn't possible and
CPFP would be wasteful, e.g. for a tree of precomputed vault
transactions or - maybe more generally - certain kinds of
covenants.
> How does this not also fail your above criteria of not wasting block
> space?
In certain cases (e.g. vault structures), using sponsorship txns to
bump fees as-needed is more blockspace-efficient than including
mostly-unused CPFP "anchor" outputs that pay to fee-management wallets.
I'm betting there are other similar cases where CPFP anchors are
included but not necessarily used, and amount to wasted blockspace.
> Further, this doesn't solve pinning attacks at all. In lightning we
> want to be able to *replace* something in the mempool (or see it
> confirm soon, but that assumes we know exactly what transaction is in
> "the" mempool). Just being able to sponsor something doesn't help if
> you don't know what that thing is.
When would you be trying to bump the fee on a transaction without
knowing what it is? Seeing a specific transaction "stuck" in the
mempool seems to be a prerequisite to bumping fees. I'm not sure what
you're getting at here.
--0000000000009958d205d7ffbe7b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">> This entirely misses the network cost. Yes, sure, we =
can send<br>> "diffs", but if you send enough diffs eventually=
you send a lot of data.<br><br>The whole point of that section of the emai=
l was to consider the<br>network cost. There are many cases for which trans=
mitting a<br>supplementary 1-in-1-out transaction (i.e. a sponsorship txn) =
is going<br>to be more efficient from a bandwidth standpoint than rebroadca=
sting a<br>potentially large txn during RBF. <br><br>> > In an ideal =
design, special structural foresight would not be<br>> > needed in or=
der for a txn's feerate to be improved after broadcast.<br>> > <b=
r>> > Anchor outputs specified solely for CPFP, which amount to many<=
br>> > bytes of wasted chainspace, are a hack. > It's probably=
<br>> > uncontroversial at this<br>><br>> This has nothing to d=
o with fee bumping, though, this is only solved<br>> with covenants or s=
omething in that direction, not different relay<br>> policy.<br><br>My p=
ost isn't only about relay policy; it's that txn<br>sponsors allows=
for fee-bumping in cases where RBF isn't possible and<br>CPFP would be=
wasteful, e.g. for a tree of precomputed vault<br><div>transactions or - m=
aybe more generally - certain kinds of</div><div>covenants.</div><br>> H=
ow does this not also fail your above criteria of not wasting block<br>>=
space?<br><br>In certain cases (e.g. vault structures), using sponsorship =
txns to<br>bump fees as-needed is more blockspace-efficient than including<=
br>mostly-unused CPFP "anchor" outputs that pay to fee-management=
wallets.<br>I'm betting there are other similar cases where CPFP ancho=
rs are<br>included but not necessarily used, and amount to wasted blockspac=
e.<br><br>> Further, this doesn't solve pinning attacks at all. In l=
ightning we<br>> want to be able to *replace* something in the mempool (=
or see it<br>> confirm soon, but that assumes we know exactly what trans=
action is in<br>> "the" mempool). Just being able to sponsor s=
omething doesn't help if<br>> you don't know what that thing is.=
<br><br>When would you be trying to bump the fee on a transaction without<b=
r>knowing what it is? Seeing a specific transaction "stuck" in th=
e<br>mempool seems to be a prerequisite to bumping fees. I'm not sure w=
hat<br>you're getting at here.<br></div>
--0000000000009958d205d7ffbe7b--
|
