In the other thread on “Replay Attacks and possible mitigations”, I introduced the following attack scenario:
Bob requests a payment from Alice, using the invoice workflow.
This means that Alice is the first to sign for the tx. She sends her signature to Bob, but Bob doesn’t complete the tx, and either becomes unresponsive or gives some excuse for why his wallet couldn’t complete the tx.
Alice cancels the tx, and the amount re-appears in her balance.
Then some years later, after Alice had to restore her wallet, one day she suddenly see her balance decrease. She has no memory of the canceled tx to Bob. But Bob did remember…
Th cause of the above attack is that currently, the wallet cancels a tx by merely forgetting about it and returning the amount to the balance.
It fails to prevent a future replay of the tx. Which is not even a replay because the original tx never hit the chain.
This problem cannot be solved by any kind of kernel uniqueness.
We can mitigate this scenario by having the wallet put an output that it signed for to be spent in a “limbo” state, to indicate that it no longer has exclusive control over its spending. Limbo outputs do not contribute to a wallet’s balance. It would normally remain in this limbo state until the tx confirms on-chain.
Now when Alice cancels the tx, the wallet should take the input(s) out of limbo state by spending them back to herself, i.e. “sweeping” them.
Only once the sweep confirms, can the amount be included in her balance again.