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
>
>