Can We Stop Or Cancel An Unconfirmed Bitcoin Transaction ? \ stacker news ~bitcoin

Can We Stop Or Cancel An Unconfirmed Bitcoin Transaction ?

1473 sats \ 18 comments \ @0xbitcoiner 9 Apr bitcoin_beginners

When sending Bitcoin, we may make a mistake and want to cancel the transaction. From my research, there are only two ways to reverse an unconfirmed transaction:

Replace by Fee (RBF);
Double spend using a higher fee;

Both methods require wallets that support these features.

My question for stackers is whether there is any way to cancel a transaction beyond these two methods.

During this research, I had the idea of creating a Bitcoin anti-theft service. The idea was to create a service that monitors the mempool and, when it detects an unsolicited transaction from a specific address, the service would try to cancel the transaction and notify the user that their Bitcoins were being stolen. Does anyone know if such a service already exists? Or is it a stupid idea?

view all related items

172 sats \ 0 replies \ @supertestnet 9 Apr

I have some software called Hoard which lets a user or a third party of their choice cancel a transaction by sending it into something called a vault. It requires no soft forks and works today. https://github.com/supertestnet/hoard

139 sats \ 10 replies \ @DarthCoin 9 Apr

You can do multiple RBF. The only anti-theft solution will be implementing covenants. So in the tx construction could be enforced the rule to be sent to the same destination address.

76 sats \ 6 replies \ @0xbitcoiner OP 9 Apr

Thanks for your reply!

I'm curious, why is it not possible to cancel unconfirmed transactions? Is it to prevent spam attacks on the mempool?

202 sats \ 1 reply \ @SpaceHodler 9 Apr

In my limited understanding, a cancellation wouldn't be guaranteed to propagate to all nodes.

A feature of distributed networks. Kind of like it's not possible to delete Nostr notes - some relays would receive the deletion, some wouldn't, so there is no surefire way to delete it. A note only needs to be broadcasted to some relays, whereas a deletion would have to be broadcast to all, which is a much harder distributed computing problem.

With RBF you can effectively achieve a cancellation by sending it back to an address you control, but it makes the protocol more robust than a deletion would (because the double spend prevention with the longest chain heuristic, which is already in place, gives you the reliability needed without having to handle a special 'cancellation' case) and it costs a fee, which also helps prevent spam.

0 sats \ 0 replies \ @nym 9 Apr

Great response

100 sats \ 3 replies \ @DarthCoin 9 Apr

once is broadcast and all mempools knows about it the only way to "cancel" it is RBF or CPFP. If the fee is too low, then you could just wait and after 2-3 weeks is purged.

0 sats \ 2 replies \ @LaserStack 9 Apr

I don't think it's possible to cancel a transaction with CPFP, no?

125 sats \ 1 reply \ @DarthCoin 9 Apr

You never cancel... you just replace it.

21 sats \ 0 replies \ @Scoresby 9 Apr

Darth is right. The original transaction is a valid transaction. Once you broadcast it, you have no way of knowing who has a copy of it.

When you broadcast a new one, like a RBF or just a simple double spend, you are hoping that your new transaction will get mined before the old one does.

But you don't have any way of reaching into other nodes' mempools and deleting the old transaction. So you can never truly cancel it until the new transaction is mined and it makes the old one invalid.

0 sats \ 2 replies \ @DiedOnTitan 9 Apr

Not to hijack the thread, but curious if you, @darthcoin, support OP_CTV proposal soft fork.

24 sats \ 1 reply \ @DarthCoin 9 Apr

I am more inclined to LNHANCE

0 sats \ 0 replies \ @DiedOnTitan 9 Apr

I will read that BIP. Cheers

21 sats \ 2 replies \ @Scoresby 9 Apr

Your service would have to sign the double spend transaction which means it would be a hot wallet. So either you are turning your cold storage into a hot wallet...

Or you could get around this by presigning a transaction for every single one of your utxos, and then just have the service select which one is required, but then you have to guess what a high enough fee rate would be long before you actually need to get the transaction confirmed.

27 sats \ 0 replies \ @C_Otto 9 Apr

FYI: The second ("or") part is what a watchtower in the lightning network does.

16 sats \ 0 replies \ @Scoresby 9 Apr

And in the case of theft, you have to deal with out of band payment via one of the transaction accelerator services offered by miners.

You might not even know how much a miner will get paid to mine it and so it could be very difficult to find a high enough rate for rbf or cpfp.

If anti theft is the use case, you should probably assume that the thief is taking the transaction directly to a miner and skipping mempool propagation altogether.

16 sats \ 0 replies \ @piecover 9 Apr

You may not be able to cancel after broadcast, but you use RBF(replace by fee) or CPFP(Child pay for Parent). I explained this in more details on piecover.com here: https://www.piecover.com/2023/10/how-to-unstuck-your-unconfirm-bitcoin.html?m=1

10 sats \ 1 reply \ @025738dda8 9 Apr

Bitcoin is asynchronous and decentralized system. Once you push a valid transaction into the network, there is no way how to 'unpush'. The nodes just have it and share it with others, nobody controls this. You cannot force them to delete it. So the only way that works is to override it by a 'better' transaction that the miners would prefer over the old one (which would invalidate it). And that's by RBF or CPFP.

0 sats \ 0 replies \ @Ghoost 9 Apr

Thank you for your clear answer! This helped me better understand why we can't reverse a Bitcoin transaction :)