Re: [bitcoin-dev] Detailed protocol design for routed multi-transaction CoinSwap

[ZmnSCPxj <ZmnSCPxj@protonmail.com>]

Good morning Chris,

> It seems having just one contract transaction which includes anchor
> outputs in the style already used by Lightning is one way to fix both
> these vulnerabilities.
>
> For the first attack, the other side cannot burn the entire balance
> because they only have access to the small amount of satoshi of the
> anchor output, and to add miner fees they must add their own inputs. So
> they'd burn their own coins to miner fees, not the coins in the contract.

Minimum output size is 547 sats, so anchor outputs are that amount at minimum.
A P2SH-P2WPKH output costs something like ~130 vbytes to spend, at 1.000 sat/vbyte that is only ~130 sats to spend a 547 sat anchor output, an opportunistic camper could collect from a few swaps it would have done anyway (e.g. as a passive popular maker?) and broadcast the contract txes of those swaps and then spend the anchor outputs together to get a few sats in a not-so-dusty UTXO, getting (547 - 130) sat per input minus the cost of creating a new tiny output.
Assuming the camper has already claimed its side of the swap in order to put it in cold, this is basically a tiny but free amount of extra money, and if small CoinJoins in JoinMarket are any indication, the 547 sats minus fee to spend it minus fee to create (amortized among the multiple contract txes) new UTXO might be comparable to the actual maker fee.

Since this camping attack is done after the CoinSwap, the maker fidelity bond is a weak protection against this.
The maker can keep around contract transactions indefinitely, and if standard wallets assume they can leave the coins in the same UTXO indefinitely, the contract transactions remain valid indefinitely, including up to fidelity bond timeout.
When the fidelity bond times out, the maker has to destroy its identity anyway, so it could opportunistically wait for a low-fee period after fidelity-bond timeout (we currently get low fee periods once a week, for example, so the camper can wait for at most a week to do this) to publish all still-valid contract transactions, and spend all the anchor outputs including the fidelity bond at the minimum feerate, getting a slightly larger fidelity bond fund, then CoinSwap it to honest makers to clean it, then make a new fidelity bond.
And if one of the takers happens to not be watching for contract tx timeout, it can potentially get free money, again, from the inattention.

(I call it a "camper attack" since the attacking CoinSwap participant waits around in a single place (maker fidelity bond) and snipes passing contract transactions to extract value from them when opportunity (low fee rate) is good, like a camper.)

To protect against this, we should force contract txes to signal RBF, make contract txes min-relay=feerate (requires CPFP package relay at base layer tho), and during low-fee periods we should collect outputs whose private key have been turned over to us, paying at a feerate slightly higher than 547 sat / 130 vbyte fee rate (at which point it becomes uneconomical for campers to mount their sniping attack as they would lose the anchor output amount to fees anyway).

In fact the wallet can do that all the time, and if prevailing fees are above the 547 / 130 rate it will not confirm and the wallet that wants to spend its funds *now* can sign a new RBF tx at higher feerate to replace it.

Low fees, who would have thought that would enable an attack vector....

Regards,
ZmnSCPxj