📅 Original date posted:2017-12-23
📝 Original message: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.
>
>--
>https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171223/feda2c15/attachment.html>;
Matt Corallo [ARCHIVE] /
npub1e4…jxmcu
2023-06-07 18:08:21
in reply to nevent1q…wyr6
Author Public Key
npub1e46n428mcyfwznl7nlsf6d3s7rhlwm9x3cmkuqzt3emmdpadmkaqqjxmcuPublished at
2023-06-07 18:08:21Event JSON
{
"id": "a1c3b7c1277468ca878eb43f7faee51071a49ed269f82be207805b748725843e",
"pubkey": "cd753aa8fbc112e14ffe9fe09d3630f0eff76ca68e376e004b8e77b687adddba",
"created_at": 1686161301,
"kind": 1,
"tags": [
[
"e",
"927a6dd1724c8700c1a4ae5c603baecdc05f61d5c01cc7f05dc3b724033ff24a",
"",
"root"
],
[
"e",
"fd20165f0d67f3c448b9d4a70454caaa9db481e12ded8e1857ab77e6b48812d1",
"",
"reply"
],
[
"p",
"daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa"
]
],
"content": "📅 Original date posted:2017-12-23\n📝 Original message: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.\n\nHonestly, 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.\n\nOn December 11, 2017 1:19:43 PM EST, Peter Todd via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003eOn Tue, Dec 05, 2017 at 07:39:32PM +0000, Luke Dashjr via bitcoin-dev\n\u003ewrote:\n\u003e\u003e On Tuesday 05 December 2017 7:24:04 PM Sjors Provoost wrote:\n\u003e\u003e \u003e I recently submitted a pull request that would turn on RBF by\n\u003edefault,\n\u003e\u003e \u003e which triggered some discussion [2]. To ease the transition for\n\u003emerchants\n\u003e\u003e \u003e who are reluctant to see their customers use RBF, Matt Corallo\n\u003esuggested\n\u003e\u003e \u003e that wallets honor a no125=1 flag.\n\u003e\u003e \u003e \n\u003e\u003e \u003e So a BIP-21 URI would look like this:\n\u003e\u003e \u003e bitcoin:175t...45W?amount=20.3\u0026no125=1\n\u003e\u003e \u003e \n\u003e\u003e \u003e When this flag is set, wallets should not use RBF, regardless of\n\u003etheir\n\u003e\u003e \u003e default, unless the user explicitly overrides the merchant's\n\u003epreference.\n\u003e\u003e \n\u003e\u003e This seems counterproductive. There is no reason to ever avoid the\n\u003eRBF flag. \n\u003e\u003e I'm not aware of any evidence it even reduces risk of, and it\n\u003ecertainly \n\u003e\u003e doesn't prevent double spending. Plenty of miners allow RBF\n\u003eregardless of the \n\u003e\u003e flag, and malicious double spending doesn't benefit much from RBF in\n\u003eany case.\n\u003e\n\u003eI'll second the objection to a no-RBF flag.\n\u003e\n\u003e-- \n\u003ehttps://petertodd.org 'peter'[:-1]@petertodd.org\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171223/feda2c15/attachment.html\u003e",
"sig": "a2f0563ad4fbcc4ea154281575056f64cb9ff1cb316b22ac914203e82b950fb26aa2ec78c0f8a3ce79f8cc3690704ac2384bee75b8f98f451f659bf8c875df00"
}