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>
Subject: Re: [bitcoin-dev] BIP-21 amendment proposal: -no125
Precedence: list

------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 &lt;bitcoin-dev@lists=
=2Elinuxfoundation=2Eorg&gt; 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&amp;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--