Enable RBF transactions in wallet by default

ryanofsky commented at 3:31 pm on January 12, 2017: member

Suggested by @gmaxwell in #8456 (comment)

instagibbs commented at 3:44 pm on January 12, 2017: member

concept ACK, although good point in that thread that currently users would have no way of replacing this transaction with something non-replaceable. I suppose this doesn’t matter much until a release however.

luke-jr commented at 5:02 pm on January 12, 2017: member

Probably shouldn’t be merged until something can actually use it (preferably from the GUI).

ryanofsky commented at 7:25 pm on January 12, 2017: member

@instagibbs, I added an option to create non-replaceable bumpfee transactions in 8d3cd2844b844cad92d741d848ee0ffebdffef40.

fanquake added the label Wallet on Jan 12, 2017

jtimon commented at 2:06 am on January 13, 2017: contributor

Concept ACK

gmaxwell commented at 4:59 am on January 13, 2017: contributor

@luke-jr thats why it was a comment in 8456 which both gives a way of using it, and (well once it’s updated) will let you deactivate it on a transaction after you’ve made it. (by bumping with it disabled).

I think this one probably needs a GUI setting too at the same time.

(Though Wladimir also said in chat, and I agree, that this may be too late for 0.14 now– esp. with that gui integration comment)

luke-jr commented at 5:35 am on January 13, 2017: member

Also related: #9519

RHavar commented at 5:43 am on January 13, 2017: contributor

I was supportive of bip125 because it was marketed, sold and even titled: “Opt-in”. But this simple change in defaults really makes it “Opt-out” and will end up causing huge impacts to people who are currently relying on 0-conf transactions, as suddenly everyone is going to be accidentally sending “opt-in” RBF.

For what it’s worth, I’ve tried using bip125 for “fee bumping” but it pretty much sucks for most normal cases. For anti-dos reasons, you generally have to 2x the fees, which is often a huge waste of money. And it doesn’t work to prioritize incoming transactions. On the other hand CPFP gives much finer grain control, doesn’t break transaction chains, works on incoming transactions and has the nice property of not screwing anyone (although it has a caveat that it requires you always use a change address).

Anyway, this change won’t actually impact me as I don’t accept 0-confs – but the whole thing strikes me as needlessly antagonistic.

luke-jr commented at 5:51 am on January 13, 2017: member

@RHavar has a point too. Maybe some day it will make sense to enable it by default, but today is probably not that. Instead, let’s focus on 1) making it do something actually useful; and then 2) allowing users to enable it on a per-transaction basis (we can also let them change the default in the GUI options).

TheBlueMatt commented at 6:04 am on January 13, 2017: member

I was supportive of bip125 because it was marketed, sold and even titled: “Opt-in”. But this simple change in defaults really makes it “Opt-out” and will end up causing huge impacts to people who are currently relying on 0-conf transactions, as suddenly everyone is going to be accidentally sending “opt-in” RBF.

Bitcoin Core is a relatively small wallet when it comes to consumer transactions. I think this is far from a large concern. On the flip side, if we ship a “bumpfee” option in 0.14, it’d be super confusing to users if it by default doesn’t work. There are way more user complaints about a transaction not confirming than there are about a payment not happening instantly (because users have seen “confirmations” since they started using bitcoin, and the vast majority of consumer Bitcoin use requires confirmations).

For what it’s worth, I’ve tried using bip125 for “fee bumping” but is pretty much sucks for most normal cases. For anti-dos reasons, you generally have to 2x the fees, which is often a huge waste of money.

This seems strange. The min relay fee you should have to pay is relatively small. Are you looking at relay or are you looking at mining-time? (Many pools currently lose a few tens or hundreds of dollars by still not mining Opt-in RBF).

And it doesn’t work to prioritize incoming transactions. On the other hand CPFP gives much finer grain control, doesn’t break transaction chains, works on incoming transactions and has the nice property of not screwing anyone (although it has a caveat that it requires you always use a change address).

CPFP, on the other hand, always does require something like 2x fees :(. Obviously there are use cases for both depending on which party of the transaction you are, but the massive increase in user fee and network cost to CPFP doesn’t seem to merit the cost to very uncommon use-cases (which are free to require non-opt-in RBF transactions at their own risk).

Anyway, this change won’t actually impact me as I don’t accept 0-confs – but the whole thing strikes me as needlessly antagonistic.

I’d look at it a different way - given the lack of community cohesion, full blocks aren’t going away, and random spikes resulting in user complaints are easily solved by this and simple bumpfee utility (and much cheaper and more flexibly than CPFP).

Obviously I’d agree we shouldn’t do this unless bumpfee goes in.

On January 12, 2017 9:51:07 PM PST, Luke Dashjr notifications@github.com wrote:

@RHavar has a point too. Maybe some day it will make sense to enable it by default, but today is probably not that. Instead, let’s focus on 1) making it do something actually useful; and then 2) allowing users to enable it on a per-transaction basis (we can also let them change the default in the GUI options).

– You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/bitcoin/bitcoin/pull/9527#issuecomment-272366897

RHavar commented at 6:10 am on January 13, 2017: contributor

This seems strange. The min relay fee you should have to pay is relatively small. Are you looking at relay or are you looking at mining-time? (Many pools currently lose a few tens or hundreds of dollars by still not mining Opt-in RBF).

Not really. You don’t need to pay just an extra “min relay fee”, you need to pay transaction fees on the size of the old + new transaction. So if you’re replacing a transaction with a transaction the same size (which is the general case) the network will not propagate any replacement transaction that doesn’t pay at least >= 2x the fee.

(and much cheaper and more flexibly than CPFP).

I’ve been bumping dozens of transactions for months now, using both CPFP and bip125. I listed reasons earlier why CPFP has been strictly better, more flexible and significantly cheaper (when I do a CPFP, I use a transaction I was going to make anyway so there’s almost no extra fee overhead). The only edge case I’ve found so far is just when sending a transaction it doesn’t have a change address (which is actually exceedingly rare, due to a bug in the coin selection)

TheBlueMatt commented at 6:19 am on January 13, 2017: member

What am I missing? If you’re replacing a transaction with a transaction the same size (which is the general case) the network will not propagate any replacement transaction that doesn’t pay at least >= 2x the fee

No, the network will not propagate a transaction which does not pay at least the “min relay fee” in addition to the previous transaction’s fee. The “min relay fee” is currently defaulted to 1000 satoshis per KB.

On January 12, 2017 10:10:18 PM PST, Ryan Havar notifications@github.com wrote:

This seems strange. The min relay fee you should have to pay is relatively small. Are you looking at relay or are you looking at mining-time? (Many pools currently lose a few tens or hundreds of dollars by still not mining Opt-in RBF).

What am I missing? If you’re replacing a transaction with a transaction the same size (which is the general case) the network will not propagate any replacement transaction that doesn’t pay at least >= 2x the fee

– You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/bitcoin/bitcoin/pull/9527#issuecomment-272369123

TheBlueMatt commented at 6:23 am on January 13, 2017: member

Not really. You don’t need to pay just an extra “min relay fee”, you need to pay transaction fees on the size of the old + new transaction. So if you’re replacing a transaction with a transaction the same size (which is the general case) the network will not propagate any replacement transaction that doesn’t pay at least >= 2x the fee.

No you don’t? You have to pay only 1000 satoshis per KB to cover the old, and meet network fee for the new transaction. If you’re replacing a transaction with one of the same size, you need to pay at least 1000 satoshis extra per KB, which is something like 40-50x less than current network fees.

On January 12, 2017 10:10:18 PM PST, Ryan Havar notifications@github.com wrote:

This seems strange. The min relay fee you should have to pay is relatively small. Are you looking at relay or are you looking at mining-time? (Many pools currently lose a few tens or hundreds of dollars by still not mining Opt-in RBF).

What am I missing? If you’re replacing a transaction with a transaction the same size (which is the general case) the network will not propagate any replacement transaction that doesn’t pay at least >= 2x the fee

– You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/bitcoin/bitcoin/pull/9527#issuecomment-272369123

RHavar commented at 6:25 am on January 13, 2017: contributor

No you don’t? You have to pay only 1000 satoshis per KB to cover the old, and meet network fee for the new transaction.

Oh god. Seems like I misread the bip and have been massively overpaying for my RBF =/ Ok, that’s my fault. I’m a retard. I take back my claims of RBF being crappy and will apply that to my reading comprehension.

I apologize for derailing this with my own stupidity.

TheBlueMatt commented at 6:25 am on January 13, 2017: member

I read the BIP text differently from you, I suppose (and mine meets the implementation, and also if it were to work the way you claim, I agree it’d be very useless). Probably means the BIP text needs clarification :).

On January 12, 2017 10:22:44 PM PST, Ryan Havar notifications@github.com wrote:

No, the network will not propagate a transaction which does not pay at least the “min relay fee” in addition to the previous transaction’s fee. The “min relay fee” is currently defaulted to 1000 satoshis per KB.

https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki#implementation-details

Check point 4

– You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/bitcoin/bitcoin/pull/9527#issuecomment-272370547

jonasschnelli commented at 7:12 am on January 13, 2017: contributor

General Concept ACK. I think this should not be merge before we have a bumpfee option accessible over the GUI, otherwise there are little reasons why to enable this for pure GUI users.

gmaxwell commented at 7:37 am on January 13, 2017: contributor

@RHavar The reading may be more clear to some due to understanding the motivation: The reason it works the way it does is so that RBF doesn’t allow an attacker to use any more relay bandwidth than they could use without RBF (e.g. creating additional transactions at the minrelayfee rate). So that means that every bump just needs to increase by the minimum rate that would have caused relay– the rate already used so far isn’t relevant. RBFing should be unconditionally less expensive than CPFP, usually considerably so– especially if you use it to combine what would have been a chain of several transactions, it can easily be three or more times cheaper (and less network resource hungry) to use replacement.

As far as your zero-conf comments, that is why my comment here and on the bumpfee PR talk about being able to after-the-fact turn it off. Though in the last couple months of helping people with slow transactions I’ve never had a double spend of a non-RBF transaction take more than three blocks to confirm, and usually they’re confirmed in the next block; so I’m dubious that it makes any real difference for zero-conf safety, but just in case I think it’s also important to have an instant option to flip it off on a txn the user has already sent.

morcos commented at 3:18 pm on January 13, 2017: member

I do think we should eventually make this the default. I’m ambivalent about whether we do it now or not. I do think the release notes, and possibly the help for bumpfee should make it clear you need to explicitly set walletrbf in order to have transactions that you could apply bumpfee to if we don’t change the default.

TheBlueMatt commented at 3:37 pm on January 13, 2017: member

@jonasschnelli there is still a ton of value in being able to respond to user complaints with “OK, copy txid from transaction inspector, then type bumpfee $TXID in the debug window”.

On January 13, 2017 7:18:37 AM PST, Alex Morcos notifications@github.com wrote:

I do think we should eventually make this the default. I’m ambivalent about whether we do it now or not. I do think the release notes, and possibly the help for bumpfee should make it clear you need to explicitly set walletrbf in order to have transactions that you could apply bumpfee to if we don’t change the default.

– You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/bitcoin/bitcoin/pull/9527#issuecomment-272467549

jonasschnelli commented at 3:42 pm on January 13, 2017: contributor

@jonasschnelli there is still a ton of value in being able to respond to user complaints with “OK, copy txid from transaction inspector, then type bumpfee $TXID in the debug window”.

Thats true. But maybe new conplaints will appear (non final nSequence can lead to merchants rejects during confirmation phase).

IMO before merging this we should:

have bumpfee in RPC (ideally in the GUI)
optional checkbox in the GUI to opt-in to RBF when creating a transaction

sipa commented at 11:19 pm on January 13, 2017: member

I don’t think BIP125 should be enabled by default - it seems like it should be something the user can choose for individual transactions.

MarcoFalke added the label TX fees and policy on Jan 14, 2017

ryanofsky commented at 11:53 pm on January 19, 2017: member

I created a PR adding an RBF checkbox to the GUI in #9592. That change, while minor, probably should not be merged until after the feature freeze. This change might make more sense after that one.

laanwj commented at 5:46 pm on May 23, 2017: member

Needs rebase (if we still want this.)

jgarzik commented at 5:56 pm on May 23, 2017: contributor

concept ACK

ryanofsky force-pushed on May 23, 2017

ryanofsky commented at 6:56 pm on May 23, 2017: member

Rebased 700af943fe08cd0491875e4cb0b09fcf49e549e1 -> 02b059dd6a609f1a18a9acc5fe383ee90c4b8a85 (pr/walletrbf.0 -> pr/walletrbf.1)

paveljanik commented at 7:38 pm on May 23, 2017: contributor

ACK https://github.com/bitcoin/bitcoin/commit/02b059dd6a609f1a18a9acc5fe383ee90c4b8a85

instagibbs commented at 8:26 pm on May 24, 2017: member

ACK https://github.com/bitcoin/bitcoin/pull/9527/commits/02b059dd6a609f1a18a9acc5fe383ee90c4b8a85

RHavar commented at 8:34 pm on May 24, 2017: contributor

If this is going to be the default, it seems that bumpfee first at least be able to handle all transactions (e.g. ones without change)? Otherwise it seems a bit premature to be making transactions replaceable that can’t even be replaced (and pushes the complexity of detecting and understanding that distinction onto users).

dougstrong77 approved

Enable RBF transactions in wallet by default

Suggested by Gregory Maxwell <greg@xiph.org> in
https://github.com/bitcoin/bitcoin/pull/8456#issuecomment-272050079

ea282da6da

instagibbs commented at 2:21 pm on June 2, 2017: member

rebase needed. @RHavar I don’t see the logic in having ~zero ability to update fee versus some. Users don’t learn about this feature until they’re burned.

ryanofsky force-pushed on Jun 2, 2017

ryanofsky commented at 3:00 pm on June 2, 2017: member

Rebased 02b059dd6a609f1a18a9acc5fe383ee90c4b8a85 -> ea282da6da3fbf8c2892f41cf1b8f9d973f3facd (pr/walletrbf.1 -> pr/walletrbf.2)

RHavar commented at 3:58 pm on June 2, 2017: contributor

@instagibbs because this feature comes with significant negative repercussions. At the moment merchants can (and do) accept 0-conf transaction if they take adequate precautions, such as making sure the transaction fully propagates and has a decent mining fee. (It’s even used in risky businesses like casinos, where a double-spend success rate of 1% would be enough to be profitable).

Using bip125 transactions generally require merchants to wait for an +1 confirmation, which results in a worse user experience. So if we’re going to do that, it only makes sense that users get the benefit of bip125 (being able to fee bump).

Likewise it would also make sense to have “reverttransaction” as a prerequisite too. It would help people fully realize how revertible bip125 transactions are, while providing actual utility (e.g. about a week ago through a mishap with ctrl+r’ing through my bash history, I accidentally resent someone 1 bitcoin. The ability to revert that would’ve been extremely useful).

On a side note, I find it a bit tasteful that bip125 was heavily advertising and promoting the controversial feature as “opt-in” (which is even in the name of the BIP) and now quietly being changing it to “opt-out”. But as I mentioned, I think it could be justified if users get enough utility from it (which imo would mean reliable fee bumping, and reliable transaction reverting)

instagibbs commented at 4:08 pm on June 2, 2017: member

@RHavar Currently rather than forcing people to wait a confirmation users are essentially forced to wait 2 weeks, or play games importing keys and hoping to find nodes that accept double-spends. bumpfee even has a way of turning off the bip125 flag for this very purpose you bring up.

Not going to re-litigate RBF history on this PR as that is off-topic.

RHavar commented at 4:25 pm on June 2, 2017: contributor

@RHavar Currently rather than forcing people to wait a confirmation users are essentially forced to wait 2 weeks

Of 168049 sends I’ve made with bitcoin core, using default (and often lower) fees, the longest time to confirm has been 5 hours and 48 minutes. Obviously that’s a rather horrible experience, but it’s been extremely rare (and the fee estimation in 0.15 is set to be a lot more responsive, making that even less of a problem) with me estimating there’s only ever really been two ~15-30m windows like that before.

From what I’ve seen the bulk of users affected from being stuck in the perpetual backlog have been blockchain.info and coins.ph users. A change in core’s defaults isn’t going to help them.

So at least in my personal opinion, it’s premature to bring all the negative effects of default bip125 to the entire bitcoin ecosystem without even at first even giving the users who are creating the transactions all the benefits (reliable fee bumps, and undos).

laanwj added this to the milestone Future on Jun 28, 2017

laanwj commented at 1:25 pm on June 28, 2017: member

As this stays a controversial topic (woohoo, what is not in bitcoin…) for now I think adding the option on a per-spend basis is preferable. This is already the case for RPC (since #9672) and the GUI (in #9592).

Users can be incentivized to enable it by lower fees - as done in #10589. Lower fee estimates can be used when there is the possibility to bump it later.

As further defaults discussion is non-constructive, closing for now and assigning to “Future” milestone, to be reopened later.

laanwj closed this on Jun 28, 2017

Sjors commented at 4:23 pm on November 6, 2017: member

#11605 would enable RBF by default, only for QT and only if the -walletrbf flag isn’t present.

Thanks @ryanofsky for linking to this PR; I wasn’t aware of this discussion.

DrahtBot locked this on Sep 8, 2021

Enable RBF transactions in wallet by default #9527