Topic: Transaction pending after 1 week (Read 301 times)

RBF works in most cases but I was talking about the one where you need to make a bunch of different payments at once, so you'd need a completely different receiving address, which is not how RBF is normally used.

Of course, pay-to-many should have been used from the beginning in those cases, and you can actually use RBF to replace a transaction with such, but again, most wallets that support RBF do not support changing the receiving addreses, and also autoselect the sending addresses obviously.

But that's exactly what RBF is - taking a UTXO which is already being spent in an unconfirmed transaction, and spending it again with a higher fee, therefore replacing the original transaction.

This setting only prohibits you from spending unconfirmed outputs you are receiving in to one of your addresses. It does not prevent you from using already confirmed outputs which are being spent elsewhere in an RBF replacement transaction. I'm not sure I agree about turning it off since then it limits your option and prevents you from using CPFP. Better simply to learn how transactions and UTXOs work so you understand what is going on.

Yeah, when you send Bitcoins in any kind of transaction, it's going to use some of your UTXOs to make that transaction - Electrum has a tab to show you the UTXOs you have available.

Once a UTXO is in an unconfirmed transaction, it can't be used to make another one because it's going to be spent very soon, so if you're not careful you could end up with a lot of bitcoin UTXOs stuck in unconfirmed transactions with low fees.

The Electrum setting "Spend unconfirmed outputs" should be switched off for this reason.

Great question. There are two main reasons why a replacement transaction must pay higher fees than all the unconfirmed transactions it is replacing.

The first reason you almost figured out yourself in the sentence I quoted above. Taking your example - let's say I have a chain of three unconfirmed transactions paying 10 sats/vbyte each. I want to replace the first one with a new transaction paying 11 sats/vbyte, which would evict the other two, freeing up space for the miner to include other transactions. But maybe the next highest fee paying transactions in the mempool which the miner can include only pay 3 sats/vbyte. It then makes more sense for the miner to ignore my replacement and mine my three original transactions at 10 sats/vbyte each, than it does for them to accept my replacement and mine one transaction at 11 sats/vbyte and two transactions at 3 sats/vbyte. My replacement must therefore pay more than all the transactions it is evicting to ensure it is always economical for miners to accept it.

The second reason is DoS protection. Let's say I broadcast a transaction at 1 sat/vbyte when the mempool is quite full and I know it isn't going to be confirmed any time soon. I then broadcast 20 more transactions building on this transaction, with a combined size of tens of thousands of bytes, all paying 1 sat/vbyte. Every node in the network has to receive, validate, and then broadcast my huge transactions. I can then immediately cancel all of those transactions by replacing my original transaction at a fee of 1.01 sats/vbyte. I can then broadcast another 20 more new child transactions with a huge size building on this replacement, which again, every node has to receive, validate, and broadcast. I can then cancel them all by replacing my original transaction again with a new one paying 1.02 sats/vbyte. I can repeat this thousands of times for almost zero cost and completely spam out the network. But by making me pay a fee higher than all the transactions I am evicting, this kind of attack rapidly becomes prohibitively expensive.

It's all about BIP125's standard which is widely adapted by nodes.
BIP-0125: https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki#implementation-details

For the "space used", the client can consolidate it into one transaction if the user choses to, in fact Electrum has a "Batch unconfirmed transactions" option to do so.
but the fee must still comply with the standard which is equal to the fee of the to-be-replaced transactions plus its own fee.

The only mistake you did is that you tried to bump the transaction but you paid a low fee. Because when using the bump fee feature on Electrum you need to increase the fee more than the previous transaction but you paid it low than the recommendation.

And there is no problem sending your BTC to your wallet and actually, it helps to consolidate all UTXO into one that can reduce the transaction fee in the future when you made a new transaction.

I think that's to make abusing RBF feature more expensive.


Miners are free to include any valid transaction. Miners can include the replacing transaction, even if it pays less fee. But since almost all nodes follow standard rules, your replacing transaction has to meet the requirements stated in BIP125.

Hi, I've been following this case from the French sub-forum and am trying to understand this.
As you said, and considering that the problem was (apparently) solved by putting the suggested fee, it seems that unconfirmed children were indeed included.

But I don't understand why. More specifically, why would miners not replace three transactions at 10 sat/vB (for example) by a single one at 11 sat/vB ? Because of course it's less fees overall, but also less space used, so the important metric should be the fee/space_used ratio (that is, the sat/vB rate). What am I missing?

Edit: or maybe miners would mine it but the transaction isn't relayed by nodes because it's just not in compliance with the BIP?

You can certainly increase your fees if you sent RBF transaction like you did, but I would recommend always checking state of bitcoin mempool before making a transaction, especially if you are in a hurry.
Easiest way of doing this is by using Mempool.space website that gives you recommended fees with different priorities, and higher fees means faster transaction confirmaion.
As for correct addresses, it's easy to copy-paste and then visually confirm addresses, I hope you are not manually typing every character  

yes of course, i still dont understand how i could make the mistake four times
but now i have selected "send only confirmed money"
hope i will never do the mistake

to resume i didnt sent coin to other address except mine for 30sat?

was a good lesson :p

thanks guys

As I write this it should have gotten the first confirmation. But dude, seriously, the destination address(es) are probably the most important thing that you should always check very carefully when you are about to send out coins!

Clipboard malware could replace your intended target address(es) by some address(es) of a thief. You want to be sure that you have exactly the right target address(es) in the send dialog. It usually is enough to check a bunch of characters at the beginning (exclude the bc1 prefix), in the middle and carefully the last 6-8 characters.

If you want to practice sending transactions properly I suggest you invoke Electrum in Testnet mode, create two new Testnet Bitcoin wallets, fetch some Testnet Bitcoins for free from https://testnet.coinfaucet.eu and play around. Send coins from Testnet-wallet-1 to Testnet-wallet-2 and vice versa. You can also play around with Coin Control and Send-Many and whatnot.

Practice, repeat, practice makes perfect!

yes it's running 

i had 1 merit point, sorry i'm new here i dont know at which person i have sent it between o_e_l_e_o and hosseinimr93
but thank youu

Glad you got it working!

That's the transaction you just made. It's very close to the tip of the mempool given the high fee, so it will almost certainly be confirmed in the next block. I can confirm all your child transactions have been evicted from the mempool.

Edit: It's already been confirmed. All unconfirmed transactions should now have been cleared from your wallet.

guys you rock

i tried with 30sat, finally ! direclty accepted \o/
https://ibb.co/LPMmR8x

a little expensive but wow it solved my problem

but no at all
there is still an unconfimed transaction but i think it's on the way

now i will try to never send to myself mBtc lol

thanks again for your time

The "original transactions" are all the transactions which are currently in the mempool which will be evicted by the replacement. So if the unconfirmed transaction you intended to replace has 5 unconfirmed children, then you must pay a fee higher than the total of all 6 unconfirmed transactions which are to be evicted.

The total size of OP's 4 transactions is 2,933 WU. The total fee paid is 3,891 sats. The combined fee rate therefore is 5.307 sats/vbyte.

To replace the first transaction and evict the other 3 child transactions, his replacement transaction would need to pay a fee of at least 4,031 sats for a 140 vbyte transaction, which would be a rate of 28.8 sats/vbyte.

So I would agree with hosseinimr93, and pay 30 sats/vbyte to be on the safe side.

thanks a lot for your help

Your transaction will be dropped from mempool of most nodes 14 days after they were broadcasted to the network (7 days from today).
Take note that you didn't change anything with connecting to a different server.

I tried to change of servers, the 14 days correspond to the first day i have sent the transaction or 14 days on a server?
thanks

BIP125 says that:


The thing I am not sure about is what exactly "original transactions" refers to.
Does it mean the transactions that have the same input(s) as the replacing transaction or their unconfirmed children are also included?

Considering what happened to OP when trying to increase the fee, it seems that it's the latter.

If that's the case and OP wants to replace the first transaction with a new one, there are four transactions that must be removed from the mempool.
The absolute fee that is paid for the replacing transaction must be bigger than the total fee paid for those four transactions which is around 0.000039 BTC.
According to rule number 4, the replacing transaction must pay another ~140 satoshi too.

In the case my calculations are correct and OP wants to replace the first transaction with a new one, the replacing transaction must have the fee rate of around 30 sat/vbyte.

Anyway i cant increase parent or child.
Well that's a good news, i can wait 7 more days,   

so i will come back in a week to let you know what happened