Paul Iverson [ARCHIVE] on Nostr: 📅 Original date posted:2017-12-23 📝 Original message:Allowing a "no-RBF" flag ...
📅 Original date posted:2017-12-23
📝 Original message: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 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 [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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171223/5d90c5a8/attachment.html>;
📝 Original message: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 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 [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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171223/5d90c5a8/attachment.html>;