Topic: I will Pay you for your help. TX STUCK FOR 23 DAYS AND COUNTING (Read 289 times)

The OP would be better off locking this thread ( lower left of page) given their transaction was confirmed seven days ago.

OP, feel free to shoot me a PM if you have the raw transaction. If the transaction is still valid, I should be able to help you. I would expect payment in advance.

Fee rates going up and down has nothing to do with "manipuation" by custodial wallets, exchanges or gambling sites.

It is simply a function of the "supply and demand" nature of the Bitcoin network. Space in bitcoin blocks is limited, so if you want to get your transaction in on quickly, you need to "outbid" others trying to get in.

For instance... if there are 1000 transactions in the mempool (that will completely fill a block)... and there are 999 transactions that pay a fee rate of 1000 sats/vbyte and 1 transaction that pays 1 sat/byte... and you want to send a transaction and get it in the next block.

It makes no difference that 999 transactions are sending with 1000 sats/byte... you would only need to outbid the 1000th ranked transaction to likely get in... in which case, you could use 2 sats/byte and you would "outrank" the 1 sat/byte transaction.

What causes problems is that often, we have a situation where there are just a lot more transactions being generated and sent than can be included... and a lot of the people sending these transactions, want them confirmed fast... so they start outbidding each other to try and get it the next block.

THAT is what causes fees to go up... not anything untoward by exchanges, gambling sites or custodial wallets... if anything, they usually end up sending with low fees to try and minimise their expenses (and increasing their profits).

Someone paying an unnecessarily high fee doesn't affect the fee that you must pay. All that matters is whether they are paying a higher or lower fee than you. If a 10 sats/vbyte fee is necessary to make it into the next block, then it doesn't make a difference whether an exchange pays 100 sats/vbyte or 1 million sats/vbyte.

It's no coincidence that I see a default mempoolminfee of 1 sat/vbyte.

This site becomes my basis when I make a Bitcoin transaction A member just shared that in another thread that became my reference as well. But knowing that, when the transaction is not supported by the RBF, it is unlikely to be able to double spend.

If you look at mempool transactions, almost everyone chooses the lowest transaction fee.

Custodial wallets, exchanges even gambling sites are the main reasons why the fees are highly volatile and insane when the required fee is very low so its like some kind of manipulation too. Every exchanges and sites should move to dynamic fee structure so they can avoid spiking the mempool fee with their high fee which is win-win for them as well as to the crypto community.

If it's been removed from a node's mempool... how would it magically appear again? The node has no record of it any more. So, most likely it won't "appear" again unless it gets rebroadcast.

So, either a node that still had it, would have to rebroadcast it... not sure how many nodes actually do this? or your wallet would need to rebroadcast it... or someone else who happened to have the raw transaction would have to broadcast it.

The OP got lucky considering the crazy fees we have seen for the next few months. A few days ago it was over 150 sat/vMB from jochen reading. Even a few hours ago it was over 80 sat/vMB. These days the miner's fees are very volatile. I think some online services has high fees set as default and they create all these high fees paying transactions.

Anyway, it was a good experience for OP maybe next time he will know which wallet will be best for him after reading above responses.

From what I can tell, the transaction was confirmed seven hours ago:



The number of transactions in the mempool has been dwindling over the last couple of days which has enabled a lot of smaller fee's paid transactions to finally get processed.  It's absurd that CORE users have to outbid each-other to make a payment whereas the Lightning Network they are undercutting each-other to send the TX.

When I was making the post above, the default mempoolminfee was 1 satoshi. So I assumed that most nodes should have the transaction in their mempool and they will reject a transaction spending same inputs. I also checked the transaction in three explorers and could see that in all of them.

A question:
Let's say last week I made a transaction with 2 sat/vbyte.
Two days ago, the default mempoolminfee increased to 5 sat/vbyte and my transaction was dropped from the mempool of most nodes.
Now the mempoolminfee is 1 sat/vbyte. Shouldn't my transaction appear again?
If I double-spend the same inputs, will nodes accept my transaction? (My transaction hasn't been flagged as RBF)

If I can double-spend same inputs, because the first transaction is no longer in mempools of most nodes, then why did OP's transaction get confirmed?
I don't think OP's transaction was rebroadcast. If I remember correctly, the transaction time was 23 days ago in all three explorers I checked.

Quite the opposite: in the past weeks, a 2 sat/byte transaction would easily drop from most mempools, so a new transaction using the same inputs can be broadcasted to most nodes.

This was discussed in OP's other topic already. FYI: at the bottom-left, you can move a topic to another board when needed.
Considering OP isn't the owner of the sending or receiving wallet, he basically is no party in this transaction. That's the risk of using custodial Bitcoin wallets, and if the sender isn't cooperating, there's really nothing more OP can do than wait:

That's actually quite fast, considering for how long fees have been quite high.

Theoretically... it can stay there forever (providing certain conditions are met). Don't forget, there isn't just one global mempool... each node has it's own mempool and they're not necessarily all configured the same.

"Default" Bitcoin Core nodes, will generally drop a transaction after 14 days (or when the transaction fee falls below the "mempool min fee" value) etc... but not all nodes are configured like this... some will hold onto a transaction forever until it is confirmed or becomes invalid.

Some nodes might even override the default behaviour and drop transactions after only 3 days or X days... or never!

Additionally, if a node (or wallet) takes it upon itself to keep rebroadcasting the transaction, it might briefly drop from some (but not all) nodes after the 14 days, but then be put right back into those mempools because of the rebroadcast.



Not necessarily... *some* custodial wallets allow users to set fees... but yes, most don't... some use RBF (but that's generally useless to the user as they can't execute RBF transactions anyway, at least I've not seen any that support this)... and if you sending from a custodial wallet, CPFP might still be an option if the receiver is not using a custodial service.

Yeah, I know the importance of enabling RBF while broadcasting a transaction but technically I just wants to know how long a transaction can stay in the mempool?

I will never make a transaction more than 1MB depth from the mempool so I always keep an eye on the mempool chart whenever I want to make transactions but it's completely out of our hands when we use custodial wallets.

The transaction is now confirmed naturally without anyone's help, mempools just got to the point that your 2.2sat/vB transaction's position got to the tip.
If anyone's claiming that they helped you, do not trust it.

What did they tell you exactly? Did they tell you they can't help accelerate the transaction or they don't own the receiving address? Because if it's the latter then you're having a totally different and more serious problem than a stuck transaction due to low fees as it could mean you've sent the coins to a wrong address. Check your account to see if the receiving address is correct, just to be sure.

If the address is correct then the only thing that could help you accelerate this transaction is to use a paid accelerator such as viabtc but you will have to pay them 25% of the total sent amount wich is more than the $400 you're willing to pay.

Sorry to tell you this but since you don't have the private keys then you are not the receiver and the wallet is not yours. See: not your keys, not your coins

WOW... just... WOW


No wonder they send with only 2 sat/byte fee... it's a 25868 byte transaction I don't know what this company and/or BitGo are doing... but that is just fucking ridiculous. 25kb to send 0.08 BTC??!? And they didn't even use RBF

Even a CPFP is going to be ludicrously expensive... to achieve a 10 sat/vbyte overall fee, you would need to spend something like 210,000 sats in a CPFP transaction for an all up total fee for child/parent of ~260,000 sats... Which would cost something like ~US$147.

However, it seems like the crypto.com "app" is a typical custodial exchange type wallet... so you won't be able to execute a CPFP transaction... and I really doubt that crypto.com will go to the effort of creating a CPFP transaction for you. They would need to compromise their own security protocols to be able to access the private key you deposited to, to manually create a specific transaction to do this.


At this point, unfortunately, your only option is to wait for fees to drop to a level that will enable the transaction to confirm... or for the transaction to drop out of the mempool... however if it has already been 23 days, then it would seem that some party (maybe BitGo?) is rebroadcasting your transaction. It should really have dropped after 14 days.

This entire situation is a basically reinforcing why custodial, centralised services are "bad"™

If the bitcoins were sent to your wallet (not custodial, of course), then you can speed up the transaction by sending the unconfirmed bitcoins to yourself with a $400 fee. It is called CPFP.

If not, then don't give up hope. Fees will probably be dropping very low this weekend, and even a 2.2 s/b transaction may be confirmed.

It's very unlikely that you can double-spend a non-RBF transaction successfully.
A transaction spending an input of a non-RBF transaction is rejected by nodes even if you pay a very high fee for the second transaction.

Actually, you can double-spend even it is RBF or not unless if it was changed recently?

CPFP is another solution only if the wallet of the sender has an extra balance on the wallet.


I think there is another option if he can find someone who mines on f2pool he can try to deal with them to submit his transaction to F2pool from here https://www.f2pool.com/pushtx
It is free for those who mine on their pool with a referral code.

What I am saying is that a transaction may remain stuck in mempool, the best is to make sure you have possible ways to make sure a transaction can be unstuck easily either through RBF or CPFP because thinking of a transaction to finally leave the mempool in a way you can rebroadcaste it can be so frustrating, it may even never happen.