Unconfirmed transaction. How to make my wallet made whole

Question

I am running a node with an unconfirmed transaction. I tried shutting down my btc qt so the transaction would be forgotten. To no avail it keeps rebroadcasting the transaction. I am in the process of upgrading and syncing my btc qt now too. But it's taking forever to sync. What will happen if I import my keys to a software wallet, electrum? Will my electrum wallet be made whole from the unconfirmed transaction? Any suggestions? I'm not in love with running a node anymore or coinbases ability to retrieve my transaction. Coinbase was the supposed recipient. It's been two weeks.

Answer 1

It's not possible to remove your transmitted transaction from the network.

Even if you shut down and clean your own local client, other clients around the world have it in their mempool. That's why your local client reflects the balance minus the amount you sent, even though it's not confirmed. That's how it's supposed to work, Bitcoin TX's are supposed to be irreversible even before being mined.

So, Bitcoin does not have a TX revocation network message available.

Only thing you can do is, before this unwanted TX is confirmed, to use another client, which either didn't see your TX or allows you to craft TX's and broadcast them, to submit a new transaction containing a much higher fee and same UTXO's. (Double spending on purpose.)

This new TX will cost you the fee, but if you set your own address as beneficiary, the funds will return to your wallet and the old transaction will get discarded by the network as a double spend. This higher fee is your cost to revoke the old unwanted TX. All this has to be done before the old TX is confirmed in a block.

Answer 2

According to your description (having problems while syncing full node), I wonder if your "unconfirmed transaction" is really unconfirmed? Is it already confirmed, or discarded (due to double-spending etc)?

The first problem: "stuck" 0-confirmation transaction

First of all, replace-by-fee is there to deal with "low-fee stuck transactions" problem, you would be able to bump fee with ease if the transaction had RBF enabled.

If your stuck transaction is not so urgent, you may just wait for the mempool to be cleared naturally, then your transaction will finally be confirmed, since the mempool is not so crowded (like old times in 2017) nowadays.

Just watch the last "Mempool size in MB" chart here: https://core.jochen-hoenicke.de/queue/#24h

If you want to "accelerate" or "revert" this transaction, you have two options.

The first option: you may contact a mining pool which provides "transaction accelerating (prioritising)" service, like Poolin or BTC.COM. However, this option can be expensive, and, there won't be any refund.

The second option: "double-spend" by yourself with Electrum, which is usually much cheaper than transaction prioritising services mentioned above, but a bit complicated.

1. Find out the previous transaction(s) which the stuck transaction is spending from. You may use the getrawtransaction STUCK_TXID true (replace STUCK_TXID with your own stuck transaction ID) command in debug console of Bitcoin Core, or just query it on an online block explorer like https://blockstream.info.

   Blockstream explorer shows previous outpoints clearly, where the outpoint is represented in TXID(long alphanumeric text string):INDEX(number) format. For example: this transaction spent 2 previous transactions, which have TXIDs of 00f5854cebdcd318edd325ab07e4157964f225a659302f3f5949ffe07020db4e and 6d4a34592200324f716a92d8d84db8c85bc97189610b1d4bee4fcb7d56713857

2. Copy raw transaction data of previous transaction(s). You may simply double-click each transaction showed on Bitcoin Core GUI in turn, to find them by transaction ID, and then right-click -> Copy raw transaction.

   You may also use the getrawtransaction PREVIOUS_TXID command instead, you need to run this command separately on each PREVIOUS_TXID, if multiple previous transactions were spent.

3. Create a new Electrum wallet on an offline device, then choose the Import Bitcoin addresses or private keys option.

4. Import your private keys to Electrum. The wallet won't sync, because there's no internet - that's fine, because we don't want Electrum to fetch back the stuck transaction.

5. Import the previous transaction(s) by clicking Tools menu -> Load transaction -> From text.

6. Click the View menu -> Show Coins to show the Coins tab. Then switch to the Coins tab, select all of them, and right-click -> Spend.

   Of course, if you are sure about exactly which coins were spent, you won't need to spend all available coins this time, which could reduce the fee cost a bit - but this situation is relatively rare. To keep yourself from off-by-one human errors, you'd better just spend all of them.

7. Now, you are about to construct a double-spending transaction which will send these coins back to your own wallet, or any other address(es) you want, by clicking Preview button. This time you should choose a higher fee rate (sat/Byte), at least higher than the stuck transaction.

   By the way, it is highly recommended to enable replace-by-fee on this transaction, in case of further fee-bumping.

8. Electrum is able to show QR code of this double-spending transaction. Use another online device to scan it with Electrum, then it could be sent out. You may also try to send it directly after reconnecting the device to Internet. If the stuck transaction has not yet expired on the Electrum server you are using, broadcasting the double-spending transaction might face some errors. You may try to broadcast it through other methods, eg. block explorers, and sendrawtransaction of Bitcoin Core.

The second problem: Bitcoin Core full node is painful to sync

First, the performance bottleneck usually lies at frequent I/O operations on the chainstate subdirectory, which stores the UTXO database, especially the data directory was placed on an HDD (which is supposed to make the situation worse if the HDD is SMR).

Second, currently, I'm personally not in favor of pruning, because almost all historical transaction history (which is exactly what the gigantic block chain contains) is discarded, thus rescanning becomes limited within recent blocks only. Rescanning happens if you are importing keys/addresses/wallet.dat, or zapwallettxes. In the future, this problem might be finally relieved by some improvements.

If your computer has plenty of available RAM, you may allocate more than 6GB (depends on historical peak UTXO size) of RAM for the database cache (see the Options window) of Bitcoin Core. This tweak effectively removes the I/O bottleneck. (well, you may still face this problem if you are catching up from some date before, you may cat (Linux/Mac) or type all files (use the * wildcard) into /dev/null (Linux/Mac) or nul (Windows) to force the OS to read them once, then they could be cached into the RAM)

If you have both HDD and SSD, you can configure the blocksdir parameter to migrate the gigantic block chain to a cheap-but-slow HDD, while keeping the frequently-accessed chainstate etc on a fast-but-expensive SSD.