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
|
Return-Path: <jlrubin@mit.edu>
Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])
by lists.linuxfoundation.org (Postfix) with ESMTP id 19728C0051
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 19 Sep 2020 16:31:11 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by fraxinus.osuosl.org (Postfix) with ESMTP id 0104B86B4E
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 19 Sep 2020 16:31:11 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from fraxinus.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id fCm7YHggwpHb
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 19 Sep 2020 16:31:10 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11])
by fraxinus.osuosl.org (Postfix) with ESMTPS id 1E307860DE
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 19 Sep 2020 16:31:10 +0000 (UTC)
Received: from mail-ej1-f50.google.com (mail-ej1-f50.google.com
[209.85.218.50]) (authenticated bits=0)
(User authenticated as jlrubin@ATHENA.MIT.EDU)
by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 08JGV7m9031570
(version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT)
for <bitcoin-dev@lists.linuxfoundation.org>; Sat, 19 Sep 2020 12:31:08 -0400
Received: by mail-ej1-f50.google.com with SMTP id u21so12182073eja.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 19 Sep 2020 09:31:08 -0700 (PDT)
X-Gm-Message-State: AOAM533YNAcGJ6aY7wfDDwG/QGXIVJepsN+VvhARv0so7oKTYTVM+73m
XR1yOIyRbSyshj04gMdRgoKMZLUtqTcwGINDH5c=
X-Google-Smtp-Source: ABdhPJz8zRP6JMkLglebkWdub23yGrYbRJuD2vfnSz60Nhhl7grjQVNMlOduy8/lXgN9OiKvPC2bHWAL7XIy9TvJdK0=
X-Received: by 2002:a17:906:6007:: with SMTP id
o7mr43483421ejj.550.1600533067307;
Sat, 19 Sep 2020 09:31:07 -0700 (PDT)
MIME-Version: 1.0
References: <CAD5xwhi6+Q-UX2xVnD4TE9uEbe-omQ748tpJJpYdrMNnG6D5vA@mail.gmail.com>
<20200919133716.d5ofags2tprlvpqm@ganymede>
In-Reply-To: <20200919133716.d5ofags2tprlvpqm@ganymede>
From: Jeremy <jlrubin@mit.edu>
Date: Sat, 19 Sep 2020 09:30:56 -0700
X-Gmail-Original-Message-ID: <CAD5xwhjZt25Bx+0MqfuY4OLJRWYmKZrfof86pPUAfJRDDsBQWA@mail.gmail.com>
Message-ID: <CAD5xwhjZt25Bx+0MqfuY4OLJRWYmKZrfof86pPUAfJRDDsBQWA@mail.gmail.com>
To: "David A. Harding" <dave@dtrt.org>
Content-Type: multipart/alternative; boundary="000000000000ed9f9005afad246a"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] A Replacement for RBF and CPFP: Non-Destructive
TXID Dependencies for Fee Sponsoring
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, 19 Sep 2020 16:31:11 -0000
--000000000000ed9f9005afad246a
Content-Type: text/plain; charset="UTF-8"
Hi David!
Thanks for taking a look, and great question.
> Is this in the reference implementation?
It is indeed in the reference implementation. Please see
https://github.com/bitcoin/bitcoin/compare/master...JeremyRubin:subsidy-tx#diff-24efdb00bfbe56b140fb006b562cc70bR741-R743
There is no requirement that there be any input in common, just that the
sponsor vectors are identical (keep in mind that we limit our sponsor
vector by policy to 1 element, because, as you rightfully point out,
multiple sponsors is more complex to implement).
> In the second case, I think Mallory can use an existing pinning
> technique to make it expensive for Bob to fee bump. The normal
> replacement policies require a replacement to pay an absolute higher fee
> than the original transaction, so Mallory can create a 100,000 vbyte
> transaction with a single-vector sponsor at the end pointing to Bob's
> transaction. This sponsor transaction pays the same feerate as Bob's
> transaction---let's say 50 nBTC/vbyte, so 5 mBTC total fee. In order
> for Bob to replace Mallory's sponsor transaction with his own sponsor
> transaction, Bob needs to pay the incremental relay feerate (10
> nBTC/vbyte) more, so 6 mBTC total ($66 at $11k/BTC).
Yup, I was aware of this limitation but I'm not sure how practical it is as
an attack because it's quite expensive for the attacker. But there are a
few simple policies that can eliminate it:
1) A Sponsoring TX never needs to be more than, say, 2 inputs and 2
outputs. Restricting this via policy would help, or more flexibly limiting
the total size of a sponsoring paying transaction to 1000 bytes.
2) Make A Sponsoring TX not need to pay more absolute fee, just needs to
increase the feerate (perhaps with a constant relay fee bump to prevent
spam).
I think 1) is simpler and should allow full use of the sponsor mechanism
while preventing this class of issue mostly.
What do you think?
--000000000000ed9f9005afad246a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_default" style=3D"fon=
t-family:arial,helvetica,sans-serif;font-size:small;color:#000000">Hi David=
!</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sa=
ns-serif;font-size:small;color:#000000"><br></div><div class=3D"gmail_defau=
lt" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#=
000000">Thanks for taking a look, and great question.</div><div class=3D"gm=
ail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:smal=
l;color:#000000"><br></div><div class=3D"gmail_default" style=3D"font-famil=
y:arial,helvetica,sans-serif;font-size:small;color:#000000">> <span clas=
s=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-si=
ze:small;color:rgb(0,0,0)"></span>Is this in the reference implementation? =
<br></div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica=
,sans-serif;font-size:small;color:#000000"><br></div><div class=3D"gmail_de=
fault" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;colo=
r:#000000">It is indeed in the reference implementation. Please see <a href=
=3D"https://github.com/bitcoin/bitcoin/compare/master...JeremyRubin:subsidy=
-tx#diff-24efdb00bfbe56b140fb006b562cc70bR741-R743">https://github.com/bitc=
oin/bitcoin/compare/master...JeremyRubin:subsidy-tx#diff-24efdb00bfbe56b140=
fb006b562cc70bR741-R743</a></div><div class=3D"gmail_default" style=3D"font=
-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div=
><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-ser=
if;font-size:small;color:#000000">There is no requirement that there be any=
input in common, just that the sponsor vectors are identical (keep in mind=
that we limit our sponsor vector by policy to 1 element, because, as you r=
ightfully point out, multiple sponsors is more complex to implement).</div>=
<div class=3D"gmail_quote"><br><div>=C2=A0</div><div><div style=3D"font-fam=
ily:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"g=
mail_default">> <span class=3D"gmail_default" style=3D"font-family:arial=
,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"></span>In the secon=
d case, I think Mallory can use an existing pinning<br>> technique to ma=
ke it expensive for Bob to fee bump.=C2=A0 The normal<br>> replacement p=
olicies require a replacement to pay an absolute higher fee<br>> than th=
e original transaction, so Mallory can create a 100,000 vbyte<br>> trans=
action with a single-vector sponsor at the end pointing to Bob's<br>>=
; transaction.=C2=A0 This sponsor transaction pays the same feerate as Bob&=
#39;s<br>> transaction---let's say 50 nBTC/vbyte, so 5 mBTC total fe=
e.=C2=A0 In order<br>> for Bob to replace Mallory's sponsor transact=
ion with his own sponsor<br>> transaction, Bob needs to pay the incremen=
tal relay feerate (10<br>> nBTC/vbyte) more, so 6 mBTC total ($66 at $11=
k/BTC).</div></div><div><br></div><div><div style=3D"font-family:arial,helv=
etica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default">=
Yup, I was aware of this limitation but I'm not sure how practical it i=
s as an attack because it's quite expensive for the attacker. But there=
are a few simple policies that can eliminate it:</div><div style=3D"font-f=
amily:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D=
"gmail_default"><br></div><div style=3D"font-family:arial,helvetica,sans-se=
rif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default">1) A Sponsori=
ng TX never needs to be more than, say, 2 inputs and 2 outputs. Restricting=
this via policy would help, or more flexibly limiting the total size of a =
sponsoring paying transaction to 1000 bytes.<br></div><div style=3D"font-fa=
mily:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"=
gmail_default">2) Make A Sponsoring TX not need to pay more absolute fee, j=
ust needs to increase the feerate (perhaps with a constant relay fee bump t=
o prevent spam).</div><div style=3D"font-family:arial,helvetica,sans-serif;=
font-size:small;color:rgb(0,0,0)" class=3D"gmail_default"><br></div><div st=
yle=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0=
,0)" class=3D"gmail_default">I think 1) is simpler and should allow full us=
e of the sponsor mechanism while preventing this class of issue mostly.</di=
v><div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;colo=
r:rgb(0,0,0)" class=3D"gmail_default"><br></div><div style=3D"font-family:a=
rial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_=
default">What do you think?<br></div><div style=3D"font-family:arial,helvet=
ica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default"><b=
r></div><br></div><div>=C2=A0</div></div></div></div>
--000000000000ed9f9005afad246a--
|
