Are bitcoin transactions reversable?

[?QuestionMark?]

In a book about bitcoin I read that as soon you broadcast a transaction it's not reversable. But in a tweet about the evolution of bitcoin I saw that it wasn't reversable but now (since 2018) it is. I also read a few online articles saying that you can reverse an transactions if its still in a mempool by using the same input, paying a higher fee and changing the output to yourself. Is the UTXO removed from UTXO set after it got confirmed in a block, is it that why you can reverse it while in mempool? I know you can do it with a mining attack but I'm talking more about the "legit" way.

[Rath_]

I also read a few online articles saying that you can reverse an transactions if its still in a mempool by using the same input, paying a higher fee and changing the output to yourself. [...] I know you can do it with a mining attack but I'm talking more about the "legit" way.

If your transaction is marked as replaceable and is unconfirmed, you can double-spend it. Some wallets allow to do that easily. For example, in Electrum, you can right-click on a transaction and select "Cancel tx" if you are running the latest version. Next, Electrum will create a transaction spending the same inputs to one of your addresses with a higher fee automatically. As for the Bitcoin Core, I think that you need to use zapwallettxes=1 parameter at startup before you will be able to create a conflicting transaction.

[?QuestionMark?]

Thanks for your answer. So just to be sure. An UTXO only gets removed from the UTXO set after being confirmed in a block, right? And was it always like that?

[LoyceV]

I saw that it wasn't reversable but now (since 2018) it is.

Isn't it the other way around? When I started with Bitcoin, broadcasting a double spend was easier than it is now.

An UTXO only gets removed from the UTXO set after being confirmed in a block, right? And was it always like that?

Yes.

Even though most nodes reject "classic" double spend transactions nowadays, a miner could always choose which transactions they include when they find a block. That's probably why the thiefs who monitor addresses with known/compromised private keys usually pay a very large transaction fee.

[ranochigo]

As for the Bitcoin Core, I think that you need to use zapwallettxes=1 parameter at startup before you will be able to create a conflicting transaction.

Abandontransaction would be more appropriate. It works for pruned nodes as well, zapwallettxes requires a rescan.
In the past, Blockchain.info used to have a double spend page which allows the users to test out their double spends. It executes a race attack by broadcasting a transaction to a few peers and the other conflicting transaction to another set of peers. It was an interesting experiment but wouldn't be effective since you'll just have to be well connected to different peers or just get a confirmation.

Just to add, transactions without opt-in RBF flag are still "reversible". Miners get to choose the set of transactions which are included into their block and thus they can easily ignore the legitimate transaction and include another replacement transaction. Ghash.io did it against a gambling site and they said it was done by an employee.[1] Of course, the replacement transaction still has to be signed so it's usually done with the participation of the addresses' owner as well as the mining pool but I haven't seen anything like that since then.


[1] https://bitcointalk.org/index.php?topic=327767.0

[BrewMaster]

imagine you have $1000 in the bank with a check-book. you can write 10 checks all of which spending the same $1000 to 10 different people. when you right the second check is the same as when you double spend a transaction. all 10 checks are valid and can exist simultaneously until one and only one of them is approved by the bank and the person claims the $1000. the other 9 become invalid right away.

that's the same when sending a transaction. you can't reverse it just as you can't reverse the check you wrote and gave to someone. but you can double spend the inputs of that transaction and create multiple transactions (10 checks) sending the same coins to different destinations.
as soon as one and only one of them were confirmed (was included in a block) the rest become invalid right away.

[?QuestionMark?]

As for the Bitcoin Core, I think that you need to use zapwallettxes=1 parameter at startup before you will be able to create a conflicting transaction.

Abandontransaction would be more appropriate. It works for pruned nodes as well, zapwallettxes requires a rescan.

Thank you both for your helpful references.

I found this on bitcoin.org:
https://developer.bitcoin.org/reference/rpc/abandontransaction.html

Quote:
It only works on transactions which are not included in a block and are not currently in the mempool.

Is it a typo?

[ranochigo]

Thank you both for your helpful references.

I found this on bitcoin.org:
https://developer.bitcoin.org/reference/rpc/abandontransaction.html

Quote:
It only works on transactions which are not included in a block and are not currently in the mempool.

Is it a typo?

I'm sorry, my bad. I missed the part where you said it's still in the mempool. If that's the case, you need to use zapwallettxes and your wallet can't be pruned.

If it's pruned, then you'll have to manually craft and sign your own transaction.