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

--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 &quot;no-RBF&quot; 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&quot; policy in Bitcoin. So I agree with Luke and Peter: remo=
ve the flag and make all transactions RBF as &quot;de jure&quot; 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">&lt;<a href=3D"mailto:bitcoin-dev@lis=
ts.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation=
.org</a>&gt;</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&#39;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 &lt;<a hr=
ef=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitco=
in-dev@lists.<wbr>linuxfoundation.org</a>&gt; 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&amp;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&#39;s preference.<br></blockquote> <br> =
This seems counterproductive. There is no reason to ever avoid the RBF flag=
. <br> I&#39;m not aware of any evidence it even reduces risk of, and it ce=
rtainly <br> doesn&#39;t prevent double spending. Plenty of miners allow RB=
F regardless of the <br> flag, and malicious double spending doesn&#39;t be=
nefit much from RBF in any case.<br></blockquote><br>I&#39;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--