Request no-RBF via BIP21/70 URI (no125=1) #11828

@TheBlueMatt suggested:

There may be cases where not using RBF is preferable, and I've suggested many times that people who want that put something like no125=1 in their URIs do so, and we should honor such things [...]

Supporting such a no125 flag seems trivial.

For BIP-21 URI's: bitcoin:175t...45W?amount=20.3&no125=1 would disable RBF by default.

For BIP-70 a new field optional boolean no125 = 1; could be added to PaymentDetails.

In addition to disabling RBF by default when this flag is set, the wallet could warn users when they try to activate it.

Steps (?):

• 1. implement BIP-21 change as a proof of concept: WIP Sjors/bitcoin#12
• 2. propose an amendment to the BIP-21 (cc @luke-jr)
• 3. merge BIP-21 implementation
• 4. implement BIP-71 change as a proof of concept
• 5. propose an amendment to the BIP-70
• 6. merge BIP-70 implementation

There is no case where not indicating RBF is rationally preferable, and if merchants refuse RBF-signalling transactions, it's really no different than refusing to accept bitcoins.

I think this makes a lot of sense and would go a long ways towards those who really want to avoid receiving RBF transactions being able to do so as wallets move more towards RBF-by-default. This probably needs a bitcoin-dev discussion, though.

A bitcoin-dev discussion is always part of changing a BIP, right? That would be step 2 then, assuming working code is a prerequisite to such an amendment (step 1). My WIP code in Sjors/bitcoin#12 crashes at the moment, because I don't understand how the SendCoinsRecipient class is supposed to work (and I'm still brushing up on my C++11). @luke-jr see #11605 (comment) and #11605 (comment) for potential situations where merchants may want users to not use RBF, because of the way it impacts their assessment of double-spend or exchange rate risk.

I dont believe working code is neccessarily a prerequisite to such a simple change, for a consensus-rule change or something for which the implementation may be unclear or may help analyze the implications of the change, sure, but adding a standard URI parameter seems more than discussable without well-tested/reviewed code.

I've not seen any evidence the RBF flag in any meaningful way impacts risk. Plenty of miners ignore it and unconditionally allow RBF.

Two NACKs and no fans so far in the mailinglist discussion.

I'd like to leave this open until #11605 is merged and used in the wild for a month, or some other large wallet turns on RBF by default.

Bitcoin Core 0.16 has been out for a few weeks now. Not seeing a dramatic change in BIP-125 signaling (cc @alecalve):

<img width="1396" alt="schermafbeelding 2018-03-16 om 09 50 40" src="https://user-images.githubusercontent.com/10217/37524373-0a2396ec-2900-11e8-8bf1-f41d79f30627.png">

I don't see much enthusiasm for this idea, not even in myself. I suggest closing it.