Electrum: how to use Full RBF?

[LoyceV]

Let's say you have a transaction without RBF enabled, and want to create a new transaction to replace it (to try your luck broadcasting it to a Full RBF node). How can you do this in Electrum?
TL;DR: how to remove the unconfirmed transaction, and create a new one.

[1714515037]

1714515037

[1714515037]

1714515037

[1714515037]

1714515037

[Charles-Tim]

I have not tried it before but I think it would work: https://bitcointalk.org/index.php?topic=5474986.msg63198878#msg63198878

Did you try it and not working? Because you sent the post merits.

Only servers that has enabled full RBF can make the coin rebroadcast work. I think you have to change the server manually.

[Zaguru12]

TL;DR: how to remove the unconfirmed transaction, and create a new one.

You can actually follow the guide link from Charles-Tim, but I don’t think that actually removes the unconfirmed transaction because as you know an unconfirmed transaction cannot be removed, what is basically done is you’re double spending same transaction and since the new one would have a much higher transaction fee it gets confirmed first and then invalidate the first one. Even if you delete the local transaction and didn’t broadcast a new one it will still be there and could get confirmed later if the mempool congestion reduces before it is totally dropped from all nodes

You can switch servers manually following this guide https://bitcoinelectrum.com/how-to-switch-to-a-different-electrum-server/

[AB de Royse777]

It used to have an option for RBF in the preference section but it seems now it's not there. I guess RBF is now a default setting for Electrum.

[LoyceV]

Did you try it and not working? Because you sent the post merits.

Thanks, I couldn't find it anymore. This should work! I've now bookmarked it.

[Charles-Tim]

You can actually follow the guide link from Charles-Tim, but I don’t think that actually removes the unconfirmed transaction because as you know an unconfirmed transaction cannot be removed, what is basically done is you’re double spending same transaction and since the new one would have a much higher transaction fee it gets confirmed first and then invalidate the first one. Even if you delete the local transaction and didn’t broadcast a new one it will still be there and could get confirmed later if the mempool congestion reduces before it is totally dropped from all nodes

What I noticed is that if the coin is dropped due to mempool congestion making the purging to be greater than the fee rate used, or the transaction is getting longer than 14 days that most nodes would have dropped it, some nodes can still have it because nodes can change the default settings. That was why I am not surprised when a transaction I made dropped from mempool of a node but I was still able to accelerate it using ViaBTC free accelerator.

But if you replace the fee using opt-in RBF, the transaction will drop from mempool of other nodes.

For full RBF, I am not certain about it and you may be right. But I am not sure.

It used to have an option for RBF in the preference section but it seems now it's not there. I guess RBF is now a default setting for Electrum.

You are referring to opt-in RBF. But this is about Full RBF. Electrum remove the option and make all transactions to be flagged as opt-in RBF since version 4.4 or so which was some months ago in last year. So all transactions made on Electrum now all support opt-in RBF.

[hosseinimr93]

You can actually follow the guide link from Charles-Tim, but I don’t think that actually removes the unconfirmed transaction because as you know an unconfirmed transaction cannot be removed

LoyceV wants to remove the unconfirmed transaction from his wallet file, so that the coin(s) become available again and he can make a new transaction.
As I mentioned in my guide in another thread, you can use the following command to remove the unconfirmed transaction from your wallet file.

Code:

wallet.adb.remove_transaction("TXID")

[Zaguru12]

What I noticed is that if the coin is dropped due to mempool congestion making the purging to be greater than the fee rate used, or the transaction is getting longer than 14 days that most nodes would have dropped it, some nodes can still have it because nodes can change the default settings. That was why I am not surprised when a transaction I made dropped from mempool of a node but I was still able to accelerate it using ViaBTC free accelerator.

But if you replace the fee using opt-in RBF, the transaction will drop from mempool of other nodes.

For full RBF, I am not certain about it and you may be right. But I am not sure.

You’re definitely right the transaction that was RBF opt in will certainly be replaced but as for the transaction the transaction which was done through nodes full RBF you’re actually not replacing them but actually double spending them and nodes will have both the old and the new transactions since the nodes settings allows that. It is after the second transaction has been confirmed (since it is the one with higher fee) that the old one will be invalidated since it’s UTXO has already been spent in the second transaction

[hosseinimr93]

and nodes will have both the old and the new transactions since the nodes settings allows that.

I don't think there's any node with such behavior. Nodes don't keep two conflicting transactions in their mempool.

If a node has enabled full RBF treats all transactions as RBF-enabled and would remove the first transaction from its mempool once it receives the replacement transaction even if the original transaction hasn't been flagged as RBF. (This is assuming the fee used for the replacement transaction is sufficient.)

If a node has not enabled full RBF and the original transaction has not been flagged as RBF, it would reject the second transaction and keep the first one.

Note that it's possible that some nodes have the first transaction in their mempool and some have the second transaction, but no node would keep both transactions.

[Zaguru12]

Note that it's possible that some nodes have the first transaction in their mempool and some have the second transaction, but no node would keep both transactions.

Now I get, that’s why both the transactions, the first one and second one both have almost same chance of been confirmed, since the node that holds the first transaction could still add it to the block it mines (if the fee later meets the node’s requirement), if he mines first before the other block and then it invalidates the second transaction

[khaled0111]

Now I get, that’s why both the transactions, the first one and second one both have almost same chance of been confirmed, since the node that holds the first transaction could still add it to the block it mines (if the fee later meets the node’s requirement), if he mines first before the other block and then it invalidates the second transaction

Nodes do not necessarily mine bitcoin but miners pick transactions from nodes' mempools. Miners will most likely pick the transaction paying higher fee rate and ignore the other one.
The chances of getting included into a block depends mostly on the level of propagation of each transaction, though.

[Zaguru12]

Nodes do not necessarily mine bitcoin but miners pick transactions from nodes' mempools. Miners will most likely pick the transaction paying higher fee rate and ignore the other one.
The chances of getting included into a block depends mostly on the level of propagation of each transaction, though.

Was actually referring to mining nodes. Just as said above by hosseinimr93 no two same transactions can be in a particular nodes mempool, so if the mining node actually gets to mine a block and the first transaction is in its mempool and it meets its fee rate criteria then it can be included in the block mined by that miner or say mining node. After the first transaction gets confirmed, the other one in another nodes mempool will definitely be invalidated. What I was emphasizing on is that both the old transaction and new transaction can be included in a block since a miner can pick just any transaction (although they use high fee as the priority) they want from there mempool to include in a block they miner.

[Yamane_Keto]

What I was emphasizing on is that both the old transaction and new transaction can be included in a block since a miner can pick just any transaction (although they use high fee as the priority) they want from there mempool to include in a block they miner.

This cannot happen, if the mempool node is not full RBF enabled. Any transaction that does not contain the RBF flag will not be accepted. However, if it is full RBF enabled, the old transaction will be removed, and what you say can only happen in two different nodes, so that when you broadcast your transaction to a node Your old transaction in a different mempool will have been confirmed, as the miner has mined the block and included your transaction, and here the new transaction will be invalid.

But if you mean Child-Pays-For-Parent transaction, it is different from RBF.

[Zaguru12]

This cannot happen, if the mempool node is not full RBF enabled. Any transaction that does not contain the RBF flag will not be accepted. However, if it is full RBF enabled, the old transaction will be removed, and what you say can only happen in two different nodes, so that when you broadcast your transaction to a node Your old transaction in a different mempool will have been confirmed, as the miner has mined the block and included your transaction, and here the new transaction will be invalid.

But if you mean Child-Pays-For-Parent transaction, it is different from RBF.

You might have quoted me out of context I didn’t say both transaction can be in the same node’s mempool but rather both transactions have the tendency of getting included in any mined block since both transactions actually existed but in different nodes mempool so it is a matter of which of the transactions gets confirmed first and the other becomes invalid. The first two lines of the post you quoted was where I said so.

To be clear, if first transaction is in Node A mempool, (this node doesn’t supports full RBF) and the second transaction is in Node B mempool (this node supports full RBF). Then the first transaction can still get confirmed if miner owning node A mines a block first before miner owning node B and it included first transaction in its mempool, this means the second transaction is invalid even though it has the higher fee

[tranthidung]

It used to have an option for RBF in the preference section but it seems now it's not there. I guess RBF is now a default setting for Electrum.

Electrum only allows users to turn RBF on and off with older versions.

They disable that feature months ago since version 4.4.0 so now it's impossible to enable, disable it.

The team made this commit to turn RBF by default and remove all RBF settings.
https://github.com/spesmilo/electrum/commit/e1dc7d1e6fb2fc5b88195b62cbe1613b252db388

https://github.com/spesmilo/electrum/issues/8088
https://github.com/spesmilo/electrum/issues/8490

[LoyceV]

They disable that feature months ago since version 4.4.0 so now it's impossible to enable, disable it.

The team made this commit to turn RBF by default and remove all RBF settings.

If that's the case, then why can't you apply RBF to a transaction that doesn't have RBF set? That would be a useful feature to add to the GUI in Electrum.

[ghost43]

why can't you apply RBF to a transaction that doesn't have RBF set? That would be a useful feature to add to the GUI in Electrum.

What is your use case for trying to RBF txs that do not signal RBF?

~All txs created by Electrum signal RBF. Is it to bump the fee of txs created by other wallets?

[LoyceV]

Is it to bump the fee of txs created by other wallets?

Yes.

[Zaguru12]

What is your use case for trying to RBF txs that do not signal RBF?

~All txs created by Electrum signal RBF. Is it to bump the fee of txs created by other wallets?

Yes the idea to RBF a non-RBF transaction, ideally there is no way to turn an already non-RBF transaction to a RBF transaction, the way round that is finding a node that actually has its setting as Full RBF this kind of nodes will still accept double spending of same transaction with a bigger transaction fee and then remove the older transaction from its mempool. Using electrum is just to change server and actually look for that one with a Full RBF mempool setting. Not that it will automatically change the transaction to a RBF one

[nc50lc]

-snip-

-snip- Not that it will automatically change the transaction to a RBF one

I think it's needless to explain that to an Electrum developer 

The logic of his question is because all transactions created by Electrum since Dec 11, 2022 already have opt-in RBF set to true,
so it's unnecessary to try full-rbf on Electrum unless it's imported from another wallet that created a transaction with opt-in RBF false flag.