Replace by Fee - the UNDO button...

[nerioseole]

Bitcoin-core 0.12 introduced an opt-in function which allows a broadcasted transaction to be Replaced by (higher) Fees - as long as the first transaction has not been included into a block already - the infamous UNDO button...  

There is a lot of ink on forums about the pros and cons of such function. But, regardless if we are for, or against RBF - it is now part of the landscape.  

Are Electrum developers working on a way to warn users, and to clearly identify which incoming transactions have opted-in on this RBF function?  I believe that those transactions have a special flag that Electrum could check to advise users that they should wait for at least 1 confirmation before providing the product/service that the buyer is purchasing.  I understand that waiting for a least 1 confirmation was always a best practice, but now with RBF, it becomes mandatory.   To advise Electrum users of incoming transactions that would have the potential to be double-spent would be very, very useful...

Second, I understand that at the moment only Bitcoin-core users have access to this function (as senders) and that Electrum doesn't allow it.  What are Electrum developers positions on this topic?  Will they also allow the users to opt-in to this function in the future?  

Ref:  Peter Todd has tested most common wallets a few months ago and Electrum (then at 2.5.4) was not able to warn its users. https://petertodd.org/2016/are-wallets-ready-for-rbf

 



  

[shsmith]

Replace by fee only allows replacement of a TX to the very same output address as the lower fee original TX, so there is no double-spend risk.
The only kind of "double spend" is sending to the SAME output twice, to the recipient will still get the BTC regardless.
Look at the linked "doublespend.py" and you can see there is only ONE address you are sending to, not two.
There is a lot of FUD about this.

If you see the original TX to one of your addresses, there is no way for the sender to replace that with an alternate higher-fee TX to a different address. The only purpose is to bump the fee, leaving everything else the same, as a way to increase priority of a TX.

FUD aside, it would be handy if the Electrum UI gave users the opportunity to try sending with a low fee, and if they get impatient they can resubmit with higher fee to speed up the TX.

[Quickseller]

Replace by fee only allows replacement of a TX to the very same output address as the lower fee original TX, so there is no double-spend risk.
The only kind of "double spend" is sending to the SAME output twice, to the recipient will still get the BTC regardless.
Look at the linked "doublespend.py" and you can see there is only ONE address you are sending to, not two.
There is a lot of FUD about this.

This is not true. RBF allows you to change anything about the makeup of the transaction, including both inputs and outputs. The argument that the blockstream core devs were making to support RBF is that unconfirmed transactions are not always safe to accept, therefore it would not be harmful to make it so unconfirmed transactions are never safe to accept.

The common use case for a RBF transaction would be that the same inputs would be used, and that the fee would be increased at the expense of the change address, however the Bitcoin protocol has no way to know which address is the change address, therefore it would be trivial for the sender to create/push a new transaction that sends less btc to the person you are claiming to send btc to.

Furthermore, it is possible that a malicious sender could create/sign/push a transaction that actually lowers the fee paid to a point in which it would be unlikely to ever get confirmed, and then double spending the transaction once it has dropped out of the node's mempool in a few days.

Blockchain.info appears to employ a policy of not even displaying information regarding RBF transactions while they are 0/unconfirmed, likely because displaying them on their block explorer will be misleading. I would suggest that electrum employ a similar policy of not even having the transaction show up on the UI until the transaction has at least 1 confirmation. 

[shsmith]

Is there some proof-of-concept script that RBF double-spends to a DIFFERENT output address? I wasn't able to find one. Still sounds like FUD to me.

[shsmith]

I read the doublespend.py code, and I see your point and also why you tagged it "UNDO" -- it can't be used to spend the same btc twice, but it can be used to "unspend" by returning the whole amount back to the sender. 
That is discouraging. What were they thinking? 

Does that mean this is all lies? https://bitcoincore.org/en/faq/optin_rbf/

[ThomasV]

Ref:  Peter Todd has tested most common wallets a few months ago and Electrum (then at 2.5.4) was not able to warn its users. https://petertodd.org/2016/are-wallets-ready-for-rbf

there is a lot of misundestanding about this...
simply detecting that a transaction is RBF, and warning users about it, would give users a false sense of security about non-RBF transactions.
for example, a non-RBF tx can spend outputs from an unconfirmed RBF parent...

[shorena]

...it would give users a false sense of security about non-RBF transactions.

ThomasV, thanks for providing comment.

If I read you correctly - you are of the school of "if you don't have a confirmation, don't even trust any input"?   Still -  identification of a RBF would be even more obvious and useful - because it is Opt-in, it would show the intent (read: pre-meditation).  We could play the probability game here - but wouldn't someone that decides to Opt-in be more likely to RBF a transaction?

The crucial point is this

-snip-
a non-RBF tx can spend outputs from an unconfirmed RBF parent...

A TX that does not advertise itself as RBF can depend on a RBF TX. These chains can (and have been without RBF) very long. A single RBF in the chain is enough to possibly revert all following TX.