From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 05BD3891 for ; 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 ; 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: <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 , Bitcoin Protocol Discussion , Peter Todd via bitcoin-dev , Luke Dashjr From: Matt Corallo 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 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

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 Decembe= r 11, 2017 1:19:43 PM EST, Peter Todd via bitcoin-dev <bitcoin-dev@lists= =2Elinuxfoundation=2Eorg> wrote:
On Tue, Dec 05, 2017 at 07:39:32PM +0000, Luke Dashj=
r via bitcoin-dev wrote:
 On Tuesday 05 December 2017 7:24:04 PM Sjors Provoost wrote:
 I recently submitted a pull r=
equest that would turn on RBF by default,
 which triggered some discus=
sion [2]=2E To ease the transition for merchants
 who are reluctant to=
 see their customers use RBF, Matt Corallo suggested
 that wallets hon=
or a no125=3D1 flag=2E
 
 So a BIP-21 URI would look like this: bitcoin:175t=2E=2E=2E45W?amount=3D20=2E3&no125=3D1
 
 Wh=
en this flag is set, wallets should not use RBF, regardless of their
 =
default, unless the user explicitly overrides the merchant's preference=2E<=
br />
 
 This seems counterproductive=2E There is no reaso=
n to ever avoid the RBF flag=2E 
 I'm not aware of any evidence it eve=
n reduces risk of, and it certainly 
 doesn't prevent double spending=
=2E Plenty of miners allow RBF regardless of the 
 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
------NUXP7JQJ1LJQ4716L25LISVX3428VZ--