[bitcoin-dev] BIP-21 amendment proposal: -no125
piverson1024 at gmail.com
Sat Dec 23 18:33:21 UTC 2017
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
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.
On Sat, Dec 23, 2017 at 8:25 AM, Matt Corallo via bitcoin-dev <
bitcoin-dev at 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 at 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 . 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:
>>>> 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 at lists.linuxfoundation.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the bitcoin-dev