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: <piverson1024@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 7DF174A5
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 23 Dec 2017 18:33:24 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm0-f65.google.com (mail-wm0-f65.google.com [74.125.82.65])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B9B46411
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 23 Dec 2017 18:33:23 +0000 (UTC)
Received: by mail-wm0-f65.google.com with SMTP id g75so27036401wme.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 23 Dec 2017 10:33:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to;
bh=n4Z+N3WddE3zNWc6KOZqrStSWIWfYS/ZFH5ELYky0e0=;
b=ungQbtG7W9FLj8If0iwqL80MCSvMYiUWpV92RtlwXoUW021esDxisdQps3mzzlFC/Q
Te80PzUZEYlMWFkrx1kDOWZXhvbRmbTjDpInHWzHsnHLd9m0O3UqkRT3+07OLUe+uoZo
G2h3gGddBvhl5OxsQlCEDqz1gPw0ghodM4ZHfYpGjfvQBZS35cNt8zPqTgelO6yWPIcq
ZyO3wOlMP/uNNztix2JIP5+hPMq3dvbroEBz17bQeemvQzntRLb4/PXzGGjZMcpyRvh7
CtQmKHNeUIgoSiYE3wVR5BKcrPxdPjfhNaXm01qdYvBNNrw0lxWPrzrRZlcdm23pgIOx
pxUQ==
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;
bh=n4Z+N3WddE3zNWc6KOZqrStSWIWfYS/ZFH5ELYky0e0=;
b=sqkZ+j0nDtjFP0vytddAiRO5xzwazFWZVbAeNzfy7kZyFW+YLopSlDoYX7wzAEOJCV
HKxfyddg7VeZsL8HiBRZ1rOYLPJKfm+rgcExWJWcMHy+KiXBnMa04FMwSjj35XC0womJ
aPr+lD3q+M64Uygo3bQnNNYtfD86A6e0+rlWEy1nl4/3wC4JuyOc8RwA9fPo7XkbPBN+
SAPRFfk6T+eOc7j4SMGEVgY0RarYXs1mfRyQDOuL1uS5MtCVUvkdFYD2XkjkIvO20x2a
XpHDev/muUik0H7/5Y0jGw9FTohl2X2aZKbjTLMJ1xwVup9rpbBR+Tn3XXwdMKNDW05G
dHSA==
X-Gm-Message-State: AKGB3mJTDBPvhtE2HnGW+5OLUap6ZxXXLX4m3aHK2O83Hrcz61SFk5vK
BQylRFEcUz14149rhIyRiGULPGLtXemQubsAJKGhkg==
X-Google-Smtp-Source: ACJfBotRftkHifeq9gUmkD6XLZlNr3SC7luFk7bPNOWnrgb2RvCMq8BAHrBuIg6NAxIQd6eMVkustAO7gA38IT5+WRA=
X-Received: by 10.28.213.69 with SMTP id m66mr7388414wmg.151.1514054002365;
Sat, 23 Dec 2017 10:33:22 -0800 (PST)
MIME-Version: 1.0
Received: by 10.223.132.34 with HTTP; Sat, 23 Dec 2017 10:33:21 -0800 (PST)
In-Reply-To: <790E0150-E6A3-49D5-8369-BF5A556FA24C@mattcorallo.com>
References: <AE14915B-37DF-4D94-A0B1-E32A26903807@sprovoost.nl>
<201712051939.33238.luke@dashjr.org>
<20171211181943.GA9855@savin.petertodd.org>
<790E0150-E6A3-49D5-8369-BF5A556FA24C@mattcorallo.com>
From: Paul Iverson <piverson1024@gmail.com>
Date: Sat, 23 Dec 2017 10:33:21 -0800
Message-ID: <CAAeo5+j01Wtyy9mm-adN+wbFZNo3jFDpUc=BzHgncoWWytUU3A@mail.gmail.com>
To: Matt Corallo <lf-lists@mattcorallo.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="001a11470644fb57de0561062a9c"
X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,
HTML_MESSAGE,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Sat, 23 Dec 2017 18:35:19 +0000
Subject: Re: [bitcoin-dev] BIP-21 amendment proposal: -no125
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: Sat, 23 Dec 2017 18:33:24 -0000
--001a11470644fb57de0561062a9c
Content-Type: text/plain; charset="UTF-8"
Allowing a "no-RBF" flag serves only to fool new users into believing that
0-conf is more secure than it is. There is already too much confusion about
this point.
In Bitcoin was assume that miners are profit-maximizing agents, and so we
must assume that (flag or not) miners will replace transactions from
mempool with conflicts paying a higher fee. From that viewpoint, full RBF
is already "de facto" policy in Bitcoin. So I agree with Luke and Peter:
remove the flag and make all transactions RBF as "de jure" policy too.
At the same time, we need more outreach and education to clarify the risks
of 0-conf, and we need to show miners how they can earn more profits by
adopting full RBF.
Paul.
On Sat, Dec 23, 2017 at 8:25 AM, Matt Corallo via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> While the usability of non-RBF transactions tends to be quite poor, there
> are some legitimate risk-analysis-based reasons why people use them (eg to
> sell BTC based on a incoming transaction which you will need to convert to
> fiat, which has low cost if the transaction doesn't confirm), and if people
> want to overpay on fees to do so, no reason not to let them, including if
> the merchant is willing to CPFP to do so.
>
> Honestly, I anticipate very low usage of such a flag, which is
> appropriate, but also strongly support including it. If things turn out
> differently with merchants reducing the usability of BTC without taking
> over the CPFP responsibility we could make the option imply
> receiver-pays-fee, but no reason to overcomplicate it yet.
>
> On December 11, 2017 1:19:43 PM EST, Peter Todd via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>> On Tue, Dec 05, 2017 at 07:39:32PM +0000, Luke Dashjr via bitcoin-dev wrote:
>>
>>> On Tuesday 05 December 2017 7:24:04 PM Sjors Provoost wrote:
>>>
>>>> I recently submitted a pull request that would turn on RBF by default,
>>>> which triggered some discussion [2]. To ease the transition for merchants
>>>> who are reluctant to see their customers use RBF, Matt Corallo suggested
>>>> that wallets honor a no125=1 flag.
>>>>
>>>> So a BIP-21 URI would look like this:
>>>> bitcoin:175t...45W?amount=20.3&no125=1
>>>>
>>>> When this flag is set, wallets should not use RBF, regardless of their
>>>> default, unless the user explicitly overrides the merchant's preference.
>>>>
>>>
>>> This seems counterproductive. There is no reason to ever avoid the RBF flag.
>>> I'm not aware of any evidence it even reduces risk of, and it certainly
>>> doesn't prevent double spending. Plenty of miners allow RBF regardless of the
>>> flag, and malicious double spending doesn't benefit much from RBF in any case.
>>>
>>
>> I'll second the objection to a no-RBF flag.
>>
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--001a11470644fb57de0561062a9c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Allowing a "no-RBF" flag serves only to fool new=
users into believing that 0-conf is more secure than it is. There is alrea=
dy too much confusion about this point.=C2=A0=C2=A0<div><br></div><div>In B=
itcoin was assume that miners are profit-maximizing agents, and so we must =
assume that (flag or not) miners will replace transactions from mempool wit=
h conflicts paying a higher fee. From that viewpoint, full RBF is already &=
quot;de facto" policy in Bitcoin. So I agree with Luke and Peter: remo=
ve the flag and make all transactions RBF as "de jure" policy too=
.=C2=A0 =C2=A0<div><div><br></div><div>At the same time, we need more outre=
ach and education to clarify the risks of 0-conf, and we need to show miner=
s how they can earn more profits by adopting full RBF.=C2=A0=C2=A0<br></div=
><div><br></div><div>Paul.</div></div></div></div><div class=3D"gmail_extra=
"><br><div class=3D"gmail_quote">On Sat, Dec 23, 2017 at 8:25 AM, Matt Cora=
llo via bitcoin-dev <span dir=3D"ltr"><<a href=3D"mailto:bitcoin-dev@lis=
ts.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation=
.org</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>While the=
usability of non-RBF transactions tends to be quite poor, there are some l=
egitimate risk-analysis-based reasons why people use them (eg to sell BTC b=
ased on a incoming transaction which you will need to convert to fiat, whic=
h has low cost if the transaction doesn't confirm), and if people want =
to overpay on fees to do so, no reason not to let them, including if the me=
rchant is willing to CPFP to do so.<br>
<br>
Honestly, I anticipate very low usage of such a flag, which is appropriate,=
but also strongly support including it. If things turn out differently wit=
h merchants reducing the usability of BTC without taking over the CPFP resp=
onsibility we could make the option imply receiver-pays-fee, but no reason =
to overcomplicate it yet.<span class=3D""><br><br><div class=3D"gmail_quote=
">On December 11, 2017 1:19:43 PM EST, Peter Todd via bitcoin-dev <<a hr=
ef=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitco=
in-dev@lists.<wbr>linuxfoundation.org</a>> wrote:<blockquote class=3D"gm=
ail_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,=
204,204);padding-left:1ex">
<pre class=3D"m_-9098417941422415674k9mail">On Tue, Dec 05, 2017 at 07:39:3=
2PM +0000, Luke Dashjr via bitcoin-dev wrote:<br><blockquote class=3D"gmail=
_quote" style=3D"margin:0pt 0pt 1ex 0.8ex;border-left:1px solid #729fcf;pad=
ding-left:1ex"> On Tuesday 05 December 2017 7:24:04 PM Sjors Provoost wrote=
:<br><blockquote class=3D"gmail_quote" style=3D"margin:0pt 0pt 1ex 0.8ex;bo=
rder-left:1px solid #ad7fa8;padding-left:1ex"> I recently submitted a pull =
request that would turn on RBF by default,<br> which triggered some discuss=
ion [2]. To ease the transition for merchants<br> who are reluctant to see =
their customers use RBF, Matt Corallo suggested<br> that wallets honor a no=
125=3D1 flag.<br> <br> So a BIP-21 URI would look like this:<br> bitcoin:17=
5t...45W?amount=3D20.<wbr>3&no125=3D1<br> <br> When this flag is set, w=
allets should not use RBF, regardless of their<br> default, unless the user=
explicitly overrides the merchant's preference.<br></blockquote> <br> =
This seems counterproductive. There is no reason to ever avoid the RBF flag=
. <br> I'm not aware of any evidence it even reduces risk of, and it ce=
rtainly <br> doesn't prevent double spending. Plenty of miners allow RB=
F regardless of the <br> flag, and malicious double spending doesn't be=
nefit much from RBF in any case.<br></blockquote><br>I'll second the ob=
jection to a no-RBF flag.<br></pre></blockquote></div></span></div><br>____=
__________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
<br></blockquote></div><br></div>
--001a11470644fb57de0561062a9c--
|
