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