Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 7DF174A5 for ; 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 ; Sat, 23 Dec 2017 18:33:23 +0000 (UTC) Received: by mail-wm0-f65.google.com with SMTP id g75so27036401wme.0 for ; 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: <201712051939.33238.luke@dashjr.org> <20171211181943.GA9855@savin.petertodd.org> <790E0150-E6A3-49D5-8369-BF5A556FA24C@mattcorallo.com> From: Paul Iverson Date: Sat, 23 Dec 2017 10:33:21 -0800 Message-ID: To: Matt Corallo , Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
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

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

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

Paul.

On Sat, Dec 23, 2017 at 8:25 AM, Matt Cora= llo via bitcoin-dev <bitcoin-dev@lists.linuxfoundation= .org> wrote:
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.

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.

On December 11, 2017 1:19:43 PM EST, Peter Todd via bitcoin-dev <bitco= in-dev@lists.linuxfoundation.org> wrote:
On Tue, Dec 05, 2017 at 07:39:3=
2PM +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 discuss=
ion [2]. To ease the transition for merchants
 who are reluctant to see =
their customers use RBF, Matt Corallo suggested
 that wallets honor a no=
125=3D1 flag.
 
 So a BIP-21 URI would look like this:
 bitcoin:17=
5t...45W?amount=3D20.3&no125=3D1
 
 When this flag is set, w=
allets 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 ce=
rtainly 
 doesn't prevent double spending. Plenty of miners allow RB=
F regardless of the 
 flag, and malicious double spending doesn't be=
nefit much from RBF in any case.

I'll second the ob=
jection to a no-RBF flag.

____= ___________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org= /mailman/listinfo/bitcoin-dev


--001a11470644fb57de0561062a9c--