📅 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>;
Paul Iverson [ARCHIVE] /
npub1tt…0gtzm
2023-06-07 18:08:21
in reply to nevent1q…q775
Author Public Key
npub1ttkq82l7hflyj6r3vxuw9c9pu7ce0fmaky98x3awz3cqpk7t5l0sz0gtzmSeen on
wss://relay.nostr.bandPublished at
2023-06-07 18:08:21Event JSON
{
"id": "5b255954ee3cd89feefb5d186369baf0d4557fe8dac56400737fb44273d237aa",
"pubkey": "5aec03abfeba7e49687161b8e2e0a1e7b197a77db10a7347ae147000dbcba7df",
"created_at": 1686161301,
"kind": 1,
"tags": [
[
"e",
"927a6dd1724c8700c1a4ae5c603baecdc05f61d5c01cc7f05dc3b724033ff24a",
"",
"root"
],
[
"e",
"a1c3b7c1277468ca878eb43f7faee51071a49ed269f82be207805b748725843e",
"",
"reply"
],
[
"p",
"cd753aa8fbc112e14ffe9fe09d3630f0eff76ca68e376e004b8e77b687adddba"
]
],
"content": "📅 Original date posted:2017-12-23\n📝 Original message:Allowing a \"no-RBF\" flag serves only to fool new users into believing that\n0-conf is more secure than it is. There is already too much confusion about\nthis point.\n\nIn Bitcoin was assume that miners are profit-maximizing agents, and so we\nmust assume that (flag or not) miners will replace transactions from\nmempool with conflicts paying a higher fee. From that viewpoint, full RBF\nis already \"de facto\" policy in Bitcoin. So I agree with Luke and Peter:\nremove the flag and make all transactions RBF as \"de jure\" policy too.\n\nAt the same time, we need more outreach and education to clarify the risks\nof 0-conf, and we need to show miners how they can earn more profits by\nadopting full RBF.\n\nPaul.\n\nOn Sat, Dec 23, 2017 at 8:25 AM, Matt Corallo via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e While the usability of non-RBF transactions tends to be quite poor, there\n\u003e are some legitimate risk-analysis-based reasons why people use them (eg to\n\u003e sell BTC based on a incoming transaction which you will need to convert to\n\u003e fiat, which has low cost if the transaction doesn't confirm), and if people\n\u003e want to overpay on fees to do so, no reason not to let them, including if\n\u003e the merchant is willing to CPFP to do so.\n\u003e\n\u003e Honestly, I anticipate very low usage of such a flag, which is\n\u003e appropriate, but also strongly support including it. If things turn out\n\u003e differently with merchants reducing the usability of BTC without taking\n\u003e over the CPFP responsibility we could make the option imply\n\u003e receiver-pays-fee, but no reason to overcomplicate it yet.\n\u003e\n\u003e On December 11, 2017 1:19:43 PM EST, Peter Todd via bitcoin-dev \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e\n\u003e\u003e On Tue, Dec 05, 2017 at 07:39:32PM +0000, Luke Dashjr via bitcoin-dev wrote:\n\u003e\u003e\n\u003e\u003e\u003e On Tuesday 05 December 2017 7:24:04 PM Sjors Provoost wrote:\n\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e I recently submitted a pull request that would turn on RBF by default,\n\u003e\u003e\u003e\u003e which triggered some discussion [2]. To ease the transition for merchants\n\u003e\u003e\u003e\u003e who are reluctant to see their customers use RBF, Matt Corallo suggested\n\u003e\u003e\u003e\u003e that wallets honor a no125=1 flag.\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e So a BIP-21 URI would look like this:\n\u003e\u003e\u003e\u003e bitcoin:175t...45W?amount=20.3\u0026no125=1\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e When this flag is set, wallets should not use RBF, regardless of their\n\u003e\u003e\u003e\u003e default, unless the user explicitly overrides the merchant's preference.\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e This seems counterproductive. There is no reason to ever avoid the RBF flag.\n\u003e\u003e\u003e I'm not aware of any evidence it even reduces risk of, and it certainly\n\u003e\u003e\u003e doesn't prevent double spending. Plenty of miners allow RBF regardless of the\n\u003e\u003e\u003e flag, and malicious double spending doesn't benefit much from RBF in any case.\n\u003e\u003e\u003e\n\u003e\u003e\n\u003e\u003e I'll second the objection to a no-RBF flag.\n\u003e\u003e\n\u003e\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171223/5d90c5a8/attachment.html\u003e",
"sig": "31a2d4a82df9003d62311a6a95ada665378a18ec95f35f68144599f6c96267e0cc3a834c72dab0bfd020fb3e71513c1db155e2e9030b063a5bccffe570d50889"
}