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.

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

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

Concept ACK

@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)

Also related: #9519

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.

@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).

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)

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.

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.

@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.

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.

@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

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

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.

Needs rebase (if we still want this.)

concept ACK

Rebased 700af94 -> 02b059d (pr/walletrbf.0 -> pr/walletrbf.1)

ACK 02b059d

ACK 02b059d

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).

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.

Rebased 02b059d -> ea282da (pr/walletrbf.1 -> pr/walletrbf.2)

@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)

@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 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).

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.

#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.