Add option to opt into full-RBF when sending funds #7119

Easy first-step for those who are using third-party scripts like my replace-by-fee-tools

There's a good argument for making this default to true - BlockCypher is rejecting Bitcoin Core txs as "might be doublespent", and whether or not the tx fee is high enough to satisfy such services isn't reliable anyway. Defaulting to true also makes it much easier to give people help on fixing a stuck transaction after the fact, even without explicit support in Bitcoin Core yet.

Your usage docs have a copy paste error... It's a binary flag so you want s/=<amt>//

On November 27, 2015 1:53:52 PM EST, Peter Todd notifications@github.com wrote:

There's a good argument for making this default to true - BlockCypher is rejecting Bitcoin Core txs as "might be doublespent", and whether or not the tx fee is high enough to satisfy such services isn't reliable anyway. Defaulting to true also makes it much easier to give people help on fixing a stuck transaction after the fact, even without explicit support in Bitcoin Core yet.

---

Reply to this email directly or view it on GitHub: #7119 (comment)

This is kinda ugly (per-node start instead of per-tx). IMO we shouldn't opt-in by default until Core can actually double-spend them itself.

@TheBlueMatt Thanks, fixed. @luke-jr Yeah, per-tx would be nice, but that'll take a lot more work on UX and RPC calls.

Re: default, remember that we don't try to make any guarantees about the likely hood that a tx will be mined according to what the recipient needs re: double-spending. For instance, a low fee tx is very easy to double-spend, and we'll happily produce them. Similarly we'll happily spend unconfirmed change in many circumstances, which again causes txs to get rejected by zeroconf risk analysis's. Not a particularly predictable UX, so i'm not worried about a default to opt-in, which does have benefits. (also the benefit of ensuring opt-in txs are accepted properly by other wallets!)

The opt-in being standard makes it sound more opt-out from the Core user's perspective. I don't care a ton, but it should to be clear from description.

I didn't even quite get that:

There's a good argument for making this default to true

meant that's how it was until I read the code itself.

NACK. This is not Bitcoin.

I don't think we should make this default.

I agree with Luke, it should be a per-tx option, but this should absolutely be the default. The Bitcoin Core wallet should be setting the example of how to best interact with Bitcoin, which means fill RBF eventually, but normalizing txn with RBF enabled until then.

On November 27, 2015 4:10:31 PM EST, Luke-Jr notifications@github.com wrote:

This is kinda ugly (per-node start instead of per-tx). IMO we shouldn't opt-in by default until Core can actually double-spend them itself.

---

Reply to this email directly or view it on GitHub: #7119 (comment)

0-confirmation transactions are important. If people include a too small fee they can wait until the transaction drops from the mempool.

Having the option is important, but I'd much rather it be per-transaction, and I'm certainly not convinced RBF-enabled should be default. What's the argument for it as default, that it's impossible to be certain of required transaction fee before relaying?

Maybe the default for fee-less transactions only? Aware that's somewhat complicating things.

The best way to optimize fee for users is to always use RBF and shoot for a low fee initially. Certainly this is the way we'd go in the future, the question is whether to default txn to opt into RBF before we've implemented the actual fee-bump-RBF logic in wallet or not.

On November 28, 2015 7:02:27 PM EST, Ross Nicoll notifications@github.com wrote:

Having the option is important, but I'd much rather it be per-transaction, and I'm certainly not convinced RBF-enabled should be default. What's the argument for it as default, that it's impossible to be certain of required transaction fee before relaying?

Maybe the default for fee-less transactions only? Aware that's somewhat complicating things.

---

Reply to this email directly or view it on GitHub: #7119 (comment)

Merchants are users too. RBF is not the way to go in the future.

Concept ACK. Branch doesn't currently merge.

Needs rebase @petertodd

No.

I'm closing this, it's just going to be a magnet for harassment due to people dishonestly misrepresenting what a pullreq means and I can't see us taking this particular patch as is.