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
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
|
Return-Path: <roconnor@blockstream.io>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id B06081171
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 8 Mar 2018 20:08:05 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-it0-f50.google.com (mail-it0-f50.google.com
[209.85.214.50])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id DBD16576
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 8 Mar 2018 20:08:04 +0000 (UTC)
Received: by mail-it0-f50.google.com with SMTP id v194-v6so61347itb.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 08 Mar 2018 12:08:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=blockstream.io; s=google;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc; bh=iH2ys7tCIPDJDz/J2WpWDOiSxZmwKN7PKWf9gUxgQ04=;
b=SRv73oQCP5cON3wIYnx39bjJDShz1HyuwGsCF99X+wEf0OdON6uBzh/o8w80TZh53B
uel7aCoKKwb7xRQm5jgGvaTS/vCFpxjKrZUaoVOwUxqxtI7Hh+bJC34vJJtfHggl4NiV
DAPVYlWBgClytodVJ9AmfRaPRXbUrvh9VvTcw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to:cc;
bh=iH2ys7tCIPDJDz/J2WpWDOiSxZmwKN7PKWf9gUxgQ04=;
b=KsHLQpZ2MQc77dnGJvBbgqGvLQW1sfT+QvUM9QBfb5zg+3pZqPlFsW4s/oDlKoCeBL
zZG/ljav3rlMpCdCc0h/Gr1tbfdOLlrMI0rf7Fb16QETeklUWPBB0cCVuwAeY51TLMD4
7i+y0G9gYe41KvvceAVXHo5+Ngqpb3fWIQoGaDQADSVm9+XZqc31ihNwsrjMJwP7PyWA
Hu16ZVIlHRou9S/a/ddgbwAFF/DAvBeM8ApDQMTJljwhZ8nngZH/NjImEdZg7VWH/xfG
RpHlRKQTEhSD/nUtaOGd0gtCBrG9Wwzo4sezsmYzOCHKkLyqzp9jn2BmHtzcVjsHuFgF
aCnA==
X-Gm-Message-State: AElRT7F4gCTu3Udh9Wg0J9KhSQY+e+POZ4woEd8lHPZkFEkoMuWGjjm4
vJ4wa60ilGVyhZqTBJvbQkj7B4Br0mX3xjh/fhaul/uZlBY=
X-Google-Smtp-Source: AG47ELtGUbz93aDfnMt7zzrFu0Vlpg46d3UvnrrPoO9vhYYlo32KIdYQmGqNqMmuMVQlhowts6Cb1QJwawxqlVlRGv4=
X-Received: by 10.36.249.203 with SMTP id l194mr62628ith.81.1520539684060;
Thu, 08 Mar 2018 12:08:04 -0800 (PST)
MIME-Version: 1.0
Received: by 10.2.166.10 with HTTP; Thu, 8 Mar 2018 12:07:43 -0800 (PST)
In-Reply-To: <20180308183426.GA1093@fedora-23-dvm>
References: <CAMZUoKnGx3p7=Kg96E3EEyJ8aFC7ezsvec_pAnN7oJz7-VbyLA@mail.gmail.com>
<20180212225828.GB8551@fedora-23-dvm>
<CAMZUoKnFBVFhaq61wKu_CcZgRKc5aoeTa-wq9h2CXH0WWHd3NQ@mail.gmail.com>
<20180212234225.GA9131@fedora-23-dvm>
<CAMZUoK=Htds5fu5vnqAhEoZDrwHALKe6uwqXnmJb17pa_peFFw@mail.gmail.com>
<20180301151129.GA9373@fedora-23-dvm>
<CAMZUoKkG8tbdb+6tGmpvgXb-=3Tu4JsTWXz77o3EC+4Bcbd17A@mail.gmail.com>
<20180308183426.GA1093@fedora-23-dvm>
From: "Russell O'Connor" <roconnor@blockstream.io>
Date: Thu, 8 Mar 2018 15:07:43 -0500
Message-ID: <CAMZUoKkDnJv33H-DveHtwpnyALS5LoX-OAnabJyvPo4c1DBJRQ@mail.gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary="94eb2c110a54bc82860566ec3b47"
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham
version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Revisiting BIP 125 RBF policy.
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
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: Thu, 08 Mar 2018 20:08:05 -0000
--94eb2c110a54bc82860566ec3b47
Content-Type: text/plain; charset="UTF-8"
On Thu, Mar 8, 2018 at 1:34 PM, Peter Todd <pete@petertodd.org> wrote:
> On Thu, Mar 08, 2018 at 10:39:46AM -0500, Russell O'Connor wrote:
> > On Thu, Mar 1, 2018 at 10:11 AM, Peter Todd <pete@petertodd.org> wrote:
> > > I mean, I think in general solving this problem is probably not
> possible.
> > > Basically, the fundamental problem is someone else has consumed network
> > > bandwidth that should be paid for with fees. What you're trying to do
> is
> > > replace a transaction without paying those fees, which is identical to
> > > what an
> > > attacker is trying to do, and thus any such scheme will be as
> vulnerable to
> > > attack as not having that protection in the first place.
> > >
> > > ...which does give you an out: maybe the attack isn't important enough
> to
> > > matter. :)
> > >
> >
> > Thanks, that makes sense.
> >
> > I still think it is worthwhile pursuing this proposed change in RBF
> policy
> > as it would seem that the current policy is problematic in practice today
> > where participants are just performing normal transactions and are not
> > trying to attack each other.
>
> But that's not a good argument: whether or not normal users are trying to
> attack each other has nothing to do with whether or not you're opening up
> an
> attack by relaxing anti-DoS protections.
>
I'm not suggesting removing the anti-DoS protections. I'm suggesting that
replaced transaction require a fee increase of at least the min-fee-rate
times the size of all the transactions being ejected (in addition to the
other proposed requirements).
> Equally, how often are normal users who aren't attacking each other
> creating
> issues anyway? You can always have your wallet code just skip use of RBF
>
replacements in the event that someone does spend an unconfirmed output that
> you sent them; how often does this actually happen in practice?
Just ask rhavar. It happens regularly.
Not many wallets let you spend unconfirmed outputs that you didn't create.
>
The problem is with institutional wallets sweeping incoming payments. It
seems that in practice they are happy to sweep unconfirmed outputs.
Setting all of the above aside for a moment. We need to understand that
rational miners are going to prefer to transactions with higher package fee
rates regardless of whatever your personal preferred RBF policy is. If we
do not bring the RBF policy to alignment with what is economically
rational, then miners are going to change their own policies anyways,
probably all in slightly different ways. It behooves everyone to develop a
reasonable standard RBF policy, that is still robust against possible DoS
vectors, and aligns with miner incentives, so that all participants know
what behaviour they can reasonably expect. It is simply a bonus that this
change in RBF policy also partially mitigates the problem of pinned
transactions.
--94eb2c110a54bc82860566ec3b47
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Thu, Mar 8, 2018 at 1:34 PM, Peter Todd <span dir=3D"ltr"><<a hre=
f=3D"mailto:pete@petertodd.org" target=3D"_blank">pete@petertodd.org</a>>=
;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On Thu, =
Mar 08, 2018 at 10:39:46AM -0500, Russell O'Connor wrote:<br>
> On Thu, Mar 1, 2018 at 10:11 AM, Peter Todd <<a href=3D"mailto:pete=
@petertodd.org">pete@petertodd.org</a>> wrote:<br>
</span><span class=3D"">> > I mean, I think in general solving this p=
roblem is probably not possible.<br>
> > Basically, the fundamental problem is someone else has consumed n=
etwork<br>
> > bandwidth that should be paid for with fees. What you're tryi=
ng to do is<br>
> > replace a transaction without paying those fees, which is identic=
al to<br>
> > what an<br>
> > attacker is trying to do, and thus any such scheme will be as vul=
nerable to<br>
> > attack as not having that protection in the first place.<br>
> ><br>
> > ...which does give you an out: maybe the attack isn't importa=
nt enough to<br>
> > matter. :)<br>
> ><br>
><br>
> Thanks, that makes sense.<br>
><br>
> I still think it is worthwhile pursuing this proposed change in RBF po=
licy<br>
> as it would seem that the current policy is problematic in practice to=
day<br>
> where participants are just performing normal transactions and are not=
<br>
> trying to attack each other.<br>
<br>
</span>But that's not a good argument: whether or not normal users are =
trying to<br>
attack each other has nothing to do with whether or not you're opening =
up an<br>
attack by relaxing anti-DoS protections.<br></blockquote><div><br></div><di=
v>I'm not suggesting removing the anti-DoS protections.=C2=A0 I'm s=
uggesting that replaced transaction require a fee increase of at least the =
min-fee-rate times the size of all the transactions being ejected (in addit=
ion to the other proposed requirements).<br>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">
Equally, how often are normal users who aren't attacking each other cre=
ating<br>
issues anyway? You can always have your wallet code just skip use of RBF<br=
></blockquote><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex">
replacements in the event that someone does spend an unconfirmed output tha=
t<br>
you sent them; how often does this actually happen in practice?</blockquote=
><div><br><div>Just ask rhavar.=C2=A0 It happens regularly.<br><br></div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft:1px solid rgb(204,204,204);padding-left:1ex"></blockquote></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex">Not many wallets let you spend unconfirmed outputs t=
hat you didn't create.<br></blockquote><div><br></div><div>The problem =
is with institutional wallets sweeping incoming payments.=C2=A0 It seems th=
at in practice they are happy to sweep unconfirmed outputs.<br><br></div><d=
iv>Setting all of the above aside for a moment.=C2=A0 We need to understand=
that rational miners are going to prefer to transactions with higher packa=
ge fee rates regardless of whatever your personal preferred RBF policy is.=
=C2=A0 If we do not bring the RBF policy to alignment with what is economic=
ally rational, then miners are going to change their own policies anyways, =
probably all in slightly different ways.=C2=A0 It behooves everyone to deve=
lop a reasonable standard RBF policy, that is still robust against possible=
DoS vectors, and aligns with miner incentives, so that all participants kn=
ow what behaviour they can reasonably expect.=C2=A0 It is simply a bonus th=
at this change in RBF policy also partially mitigates the problem of pinned=
transactions.<br></div></div></div></div>
--94eb2c110a54bc82860566ec3b47--
|
