Bitcoin offers the highest assurance of transaction finality of any asset known today. It is impossible to undo a transaction with multiple confirmations. However, it can take weeks or even months for a broadcast transaction to confirm if it is not sent with a competitive fee.
A signed and broadcast transaction quickly replicates in the mempools of most nodes in the network. Some of these nodes are miners and every transaction in their mempool represents a transaction fee that they could potentially claim. Therefore, miners have no incentive to remove a valid transaction from their mempool. Each node can determine the size of their mempool. If a mempool fills up, the node will begin to purge low fee transactions. However, some nodes elect to have large mempools and may rebroadcast low-fee transactions at times when the mempools are empty.
This game theory ensures that broadcast transactions will eventually be confirmed. But it can be inconvenient, especially if you didn’t plan on waiting weeks or even months for a transaction to confirm.
Nodes will generally ignore transactions that are attempting to spend the same UTXOs as another transaction already in its mempool. This is seen as a double-spend attempt and is purged to prevent mempool congestion.
Replace-by-Fee
With the release of Bitcoin Core 0.14.0 in 2017 bitcoin transactions could be sent using opt-in replace by fee (RBF). This allowed the transaction data propagated in mempools to indicate that a future version of this transaction could replace it if it includes a higher fee. Nearly one year after its introduction, RBF was enabled by default in Bitcoin 0.16.0.
Child-Pays-for-Parent
If the stuck transaction was not broadcast with Opt-In RBF, things get a bit more complex.
Child Pays for Parent (CPFP) may do the trick. Applying CPFP, miners don’t necessarily pick the transactions that include the most fees, but instead pick a set of transactions that include most combined fees.
Most transactions do not only send bitcoins to the receiver, but they also send “change” back to you. You can spend this change in a next transaction.
Some wallets let you spend this change even while it is still unconfirmed, so you can send this change to yourself in a new transaction. This time, make sure to include a high enough fee to compensate for the original low fee transaction. A miner should pick up the whole set of transactions and confirm them all at once.
If your wallet does not let you select which bitcoins to spend exactly — meaning you cannot specifically spend the unconfirmed change — you can try spending all funds in the wallet to yourself; this should include the change.
A Note on Lightning
A transaction on the lightning layer is also tricky to cancel. It achieves this in an interesting way involving agreed upon commitments and penalty transactions.
Each time a new payment is made in the channel, a new commitment transaction is created and shared with both parties to accurately reflect the agreed upon state of funds in the channel. Either participant may broadcast the commitment transaction at any time to close the channel and return funds to each party as laid out in the transaction.
We’ve just discussed how attempts to double spend or cancel on chain transactions are difficult. Therefore, there must be an extra layer of protection to prevent channel participants from publishing old commitments (i.e. undoing a transaction).
Lightning solves this by allowing the “cheated” channel peer to punish the cheater with a penalty transaction which sends the entire channel capacity to the “cheated” node.
However, the channel partner must be online to detect when it is being cheated. If the node is offline for the entire time that the cheater’s output is time-locked, then the cheater can successfully cheat; effectively undoing transactions within the channel.
Leave a Reply