Electrum: Support fee bumping in the UI

[btcdrak]

First seen safe replace-by-fee is now actively mined by f2pool (21% of the network hash) and we can expect more pools to support this soon. The feature allows users to increase the fee of an existing transaction and rebroadcast it. This offers the possibility of significant usability improvements for bitcoin users who send a transaction with an insufficient fee, or at a time when the network is busy confirming spam transactions, can now rebroadcast with a higher fee to bump the priority.

code can be found here: https://github.com/bitcoin/bitcoin/pull/6176

[ecdsa]

are there electrum servers that support this?

[petertodd]

@ecdsa Not that I know of, but supporting it shouldn't be very hard - just run RBF under the hood.

[ecdsa]

Does f2pool actually implement FSS-RBF, or full-RBF, as stated in the following post ?
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008843.html

Also, what is the state of the controversy?
Sorry, but it's difficult to follow all the debates going on now...

[petertodd]

F2Pool was running full-RBF, but switched to FSS-RBF and has been running that since.

I personally would suggest you implement FSS-RBF, but do so in a way that allows full-RBF to be added later - see https://github.com/petertodd/replace-by-fee-tools/blob/master/doublespend.py for a good example of how to easily do this.

Re: "the controversy", full-RBF is still fairly controversial, but FSS-RBF has pretty good support among the Bitcoin Core devs. There's a lot of work being done on the mempool right now, but once that settles down I'll be making another FSS-RBF patch for it, which will likely be in the next major release.

[petertodd]

Oh, and I'm also still actively maintaining a full-RBF patch for the v0.11.x branch.

[kyuupichan]

Replace by fee undermines a core value-adding principle of bitcoin. I do not want to see Electrum support this diversion in any way whatsoever.

[ecdsa]

@kyuupichan FSS-RBF is less controversial

[petertodd]

Opt-in RBF was implemented in Satoshi's first Bitcoin release, modulo anti-dos protections.

[dabura667]

I agree with @kyuupichan

Electrum should only support replacement once it is clear and apparent that replacing transactions is done by the everyday user. Electrum is not a wallet for exchanges to use in their back end, it's for end users. Rather than complicating the UI for a feature that no one is asking for, we should wait and see if replacing transactions becomes "hip" with the non-nerdy non-businessy crowd.

[kyuupichan]

Yes @petertodd, like the other bugs in the early releases Satoshi and others noticed and fixed them.

[ecdsa]

follow-up on #1702 :
We should also detect unconfirmed RBF transactions.
This makes sense only if we also check that all the parent transactions are confirmed.

[petertodd]

@ecdsa Be careful you aren't giving users a false sense of security; there's many more ways than just RBF to replace transactions.

[ecdsa]

added in bc1bef60a0e9c01dedc37368f9a64ae9621a7d35

[ecdsa]

note: this commit does NOT detect incoming RBF transactions

[petertodd]

@ecdsa Awesome!

FYI I've been arguing that detecting incoming txs - at least in general purpose UI's - isn't the right thing to do as it risks giving users the wrong impression about the safety of unconfirmed txs: https://github.com/bitcoin/bitcoin/pull/7817#issuecomment-220544312

So I'd recommend that Electrum leave out incoming RBF detection.

[ecdsa]

@petertodd I tend to agree. I guess the proper way to accept instant transactions will be to use payment channels and lightning network.

[HostFat]

@ecdsa
If you aren't adding a way to detect RBF transactions, that it's better to NOT notify/show any incoming transaction that haven't at least 1 confirmation.
Showing instead only when they come from payment channels.

If you choose to to not hide them, than the mycelium way is the preferred: showing a warning if the transaction is RBF.

[petertodd]

@HostFat We should show unconfirmed transactions - they simply mean "Someone appears to be trying to pay you; unless they're trying to defraud you the transaction will probably eventually confirm."

That's very useful to know, and I think users understand what that means.

[HostFat]

I also prefer to show them, but I also prefer to show a warning with RBF transactions, because they are 100% sure double spend transactions, and users aren't used to them.

[petertodd]

@HostFat See my response to that same argument here: https://github.com/bitcoin/bitcoin/pull/7817#issuecomment-220544312

[HostFat]

I prefer to always give more information to the users and not less.

If I'll see an increase of double spent attempts by using RBF, I'll advise using only wallets that show the RBF label on incoming transactions.

[dabura667]

-1

Currently, new users WILL ASSUME TRANSACTIONS ARE FINAL.

Adding this feature and doing nothing to the UI because "users should know better anyways, it's their fault if they get defrauded" is stupid as fuck. Basically pissing on new users and laughing about it.

We should display a big red warning on ALL unconfirmed transactions in the history window saying "not yet arrived" or "Someone is trying to pay you maybe and if they don't defraud you, you're good ok?"

Taking the "lol u shoulda studied harder before messing with us 1337 crypto-bros lol @ u for getting defrauded" stance at development is a new low.

All wallets supporting RBF should change ALL unconfirmed transactions in histories to scary red letter messages, prevent spending them completely.

[ecdsa]

@dabura667 that has never been my stance. My point is, however, that if we warn users about RBF transactions, we should be similarly warning them against any transaction that has unconfirmed inputs.

[dabura667]

I was primarily aiming toward peter, and I'm a little drunk. Sorry.

I agree, we should combat the misconception that unconfirmed are good as gold, and make it much more apparent to the user that unconfirmed transactions are dangerous.

1. Disable spending unconfirmed by default
2. Change the "pending: xxx" parenthesis in the bottom to red
3. In history, show "pending" in red next to amount.

These are some ideas.

[EagleTM]

+1 There should be a general note about what "unconfirmed" means when looking at the tx for all unconfirmed tx.

As to what to write in the note about RBF - afaik there's currently only "First seen safe replace-by-fee" as linked by OP active. If that's the case it's not harmful as only the fee can be increased...

[EagleTM]

Relvant link here is https://bitcoincore.org/en/faq/optin_rbf/
From what I gather Opt-In RBF is full RBF + making use of the notification field so it can be detected. Outputs can be changed - intentionally and much easier than without RBF. Receivers of tx should be made aware of this fact.

[bencxr]

+1 on making the user aware.

You should make the user aware of the fact that the transaction is unsafe (designed to be double spent).
Or else, don't show it at all.

[HostFat]

Also, I think that it should be possible to cut the fee from the sending amount, instead of the local balance.

If I send 0.1 BTC to someone with 0.00001 fee, and he asks a faster transaction, I should be able to easily change the sending amount, example: 0.0999 BTC and 0.0001 fee.

He is the one that need a faster tx, not me, so he is he one that need to pay for it.

[ecdsa]

follow-up: 1a46a795a5cf510789f21c47771363a7b31f1b4a
this commit displays non-final transactions, and transactions with unconfirmed parents

[HostFat]

With "Replaceable" do you mean that it detects that the tx is RBF enabled?

[EagleTM]

@HostFat: Yes