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
|
Return-Path: <lf-lists@mattcorallo.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 05BD3891
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 23 Dec 2017 16:25:13 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail.bluematt.me (mail.bluematt.me [192.241.179.72])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0DE66517
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 23 Dec 2017 16:25:11 +0000 (UTC)
Received: from [IPv6:2607:fb90:1bd2:c070:7c1d:e84e:6489:4f23] (unknown
[172.56.5.22])
by mail.bluematt.me (Postfix) with ESMTPSA id 7A8201A07B7;
Sat, 23 Dec 2017 16:25:10 +0000 (UTC)
Date: Sat, 23 Dec 2017 16:25:08 +0000
In-Reply-To: <20171211181943.GA9855@savin.petertodd.org>
References: <AE14915B-37DF-4D94-A0B1-E32A26903807@sprovoost.nl>
<201712051939.33238.luke@dashjr.org>
<20171211181943.GA9855@savin.petertodd.org>
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----NUXP7JQJ1LJQ4716L25LISVX3428VZ"
Content-Transfer-Encoding: 7bit
To: Peter Todd <pete@petertodd.org>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
Peter Todd via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>,
Luke Dashjr <luke@dashjr.org>
From: Matt Corallo <lf-lists@mattcorallo.com>
Message-ID: <790E0150-E6A3-49D5-8369-BF5A556FA24C@mattcorallo.com>
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,HTML_MESSAGE
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
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 16:25:13 -0000
------NUXP7JQJ1LJQ4716L25LISVX3428VZ
Content-Type: text/plain;
charset=utf-8
Content-Transfer-Encoding: quoted-printable
While the usability of non-RBF transactions tends to be quite poor, there a=
re some legitimate risk-analysis-based reasons why people use them (eg to s=
ell BTC based on a incoming transaction which you will need to convert to f=
iat, 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 t=
he merchant is willing to CPFP to do so=2E
Honestly, I anticipate very low usage of such a flag, which is appropriate=
, but also strongly support including it=2E If things turn out differently =
with merchants reducing the usability of BTC without taking over the CPFP r=
esponsibility we could make the option imply receiver-pays-fee, but no reas=
on to overcomplicate it yet=2E
On December 11, 2017 1:19:43 PM EST, Peter Todd via bitcoin-dev <bitcoin-d=
ev@lists=2Elinuxfoundation=2Eorg> 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]=2E To ease the transition for
>merchants
>> > who are reluctant to see their customers use RBF, Matt Corallo
>suggested
>> > that wallets honor a no125=3D1 flag=2E
>> >=20
>> > So a BIP-21 URI would look like this:
>> > bitcoin:175t=2E=2E=2E45W?amount=3D20=2E3&no125=3D1
>> >=20
>> > When this flag is set, wallets should not use RBF, regardless of
>their
>> > default, unless the user explicitly overrides the merchant's
>preference=2E
>>=20
>> This seems counterproductive=2E There is no reason to ever avoid the
>RBF flag=2E=20
>> I'm not aware of any evidence it even reduces risk of, and it
>certainly=20
>> doesn't prevent double spending=2E Plenty of miners allow RBF
>regardless of the=20
>> flag, and malicious double spending doesn't benefit much from RBF in
>any case=2E
>
>I'll second the objection to a no-RBF flag=2E
>
>--=20
>https://petertodd=2Eorg 'peter'[:-1]@petertodd=2Eorg
------NUXP7JQJ1LJQ4716L25LISVX3428VZ
Content-Type: text/html;
charset=utf-8
Content-Transfer-Encoding: quoted-printable
<html><head></head><body>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&#=
39;t confirm), and if people want to overpay on fees to do so, no reason no=
t to let them, including if the merchant is willing to CPFP to do so=2E<br>
<br>
Honestly, I anticipate very low usage of such a flag, which is appropriate=
, but also strongly support including it=2E If things turn out differently =
with merchants reducing the usability of BTC without taking over the CPFP r=
esponsibility we could make the option imply receiver-pays-fee, but no reas=
on to overcomplicate it yet=2E<br><br><div class=3D"gmail_quote">On Decembe=
r 11, 2017 1:19:43 PM EST, Peter Todd via bitcoin-dev <bitcoin-dev@lists=
=2Elinuxfoundation=2Eorg> wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin: 0pt 0pt 0pt 0=2E8ex; border-left: 1px solid rgb(204, 204, 204);=
padding-left: 1ex;">
<pre class=3D"k9mail">On Tue, Dec 05, 2017 at 07:39:32PM +0000, Luke Dashj=
r via bitcoin-dev wrote:<br /><blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0pt 0pt 1ex 0=2E8ex; border-left: 1px solid #729fcf; padding-left: 1e=
x;"> On Tuesday 05 December 2017 7:24:04 PM Sjors Provoost wrote:<br /><blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 1ex 0=2E8ex; border-=
left: 1px solid #ad7fa8; padding-left: 1ex;"> I recently submitted a pull r=
equest that would turn on RBF by default,<br /> which triggered some discus=
sion [2]=2E To ease the transition for merchants<br /> who are reluctant to=
see their customers use RBF, Matt Corallo suggested<br /> that wallets hon=
or a no125=3D1 flag=2E<br /> <br /> So a BIP-21 URI would look like this:<b=
r /> bitcoin:175t=2E=2E=2E45W?amount=3D20=2E3&no125=3D1<br /> <br /> Wh=
en this flag is set, wallets should not use RBF, regardless of their<br /> =
default, unless the user explicitly overrides the merchant's preference=2E<=
br /></blockquote> <br /> This seems counterproductive=2E There is no reaso=
n to ever avoid the RBF flag=2E <br /> I'm not aware of any evidence it eve=
n reduces risk of, and it certainly <br /> doesn't prevent double spending=
=2E Plenty of miners allow RBF regardless of the <br /> flag, and malicious=
double spending doesn't benefit much from RBF in any case=2E<br /></blockq=
uote><br />I'll second the objection to a no-RBF flag=2E<br /></pre></block=
quote></div></body></html>
------NUXP7JQJ1LJQ4716L25LISVX3428VZ--
|
