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

[ZmnSCPxj]

Good morning Chris,


> > This seems a great solution!
> > Since B is the one offering HTLCs, the taker of a CoinSwap sequence can be B as well.
> > This means, the taker has to have some collateral input, of at least value K, that it cannot swap (because if it tried to swap that amount, it would be unable to provide a collateral as well).
> > How much does C need to know about the B collateralized contract transaction?
> > At the minimum, it has to know the output pays out to the correct contract, so it seems to me it has to know the entire B collateralized contract transaction, meaning it learns another input of B ("collateral(B)") that is not otherwise involved in the CoinSwap.
> > This is important, again, if B is a taker, as it means an unrelated input of B is now learned by C as having the same ownership as B.
>
> Yes, in fact that's why in my example I talk about a CoinSwap between
> two makers Bob and Charlie. Makers can be reasonably expected to own
> multiple UTXOs, but takers cannot. As you say because collateral
> payments breaks the ability of takers to sweep their entire wallet
> through CoinSwap.
>
> Happily, I think takers themselves don't need to use collateral
> payments. Here's an argument to why:
>
> Riskless theft attempts by the taker who no longer controls the coins
> actually isnt riskless or costless: Because it reduces the privacy of
> the previously-owned coins. If a taker genuinely wanted good privacy
> (Which, after all, they're paying for via miner fees and CoinSwap fees)
> then they would benefit if the coins they no longer own remain unspent
> for a long time, because it increases their anonymity set by making them
> hide among a greater crowd of coins which also don't get spent for a
> long time.

Hmmm.

The attack can only be mounted after protocol completion.
Thus, at that point, makers have made money, and takers have paid.
And taker is now in possession of a coin unlinked with its original coin, which is what it paid for.

However, if the taker considers the maker fee it has already paid as a sunk cost, then it would still be rational of them to mount this attack (sunk costs should be ignored).
>From this point-of-view, it is possible to do so with only a *subsequent* potential gain, and still no downside.

For example, suppose the taker has already performed an "honest" CoinSwap.
Then, it is now in possession of a UTXO that is not linked with its income stream.
It can then perform another CoinSwap, and *then* perform the attack.
This reveals that the UTXO it provided is involved in a CoinSwap due to publication of the contract transaction, which is not a loss in this case since the UTXO it put in was not linked to its income stream already, via a previous non-attacked CoinSwap.

A taker might rationally consider doing riskless costless theft with its already-delinked coins if it assesses that some maker is not sufficiently online and with insufficient watchtowers (both operating expenditures!) that it has some probability of success times amount it has to seed the theft, versus the fee of that maker plus miner fees.

In response, a maker that is forced to accept a sweeping taker will raise its fee, so as to disincentivize this attack using already-delinked coins.

Hmmm.

In addition, post-Scriptless-Script, assuming relative-locktime-use is "normalized" as proposed in https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-January/002412.html , then the "contract transaction" and its timelock-path-transaction look exactly the same as ordinary (P2SH-)P2WPKH single-input-single-output transactions, thus in that case the taker does ***not*** lose any privacy.
This removes whatever protection you can get from contract transaction blackmail.

--

The above suggests to me that you still want the collateralized contract transaction from the taker as well.

A sweeping taker can split its funds in half, swapping one half (and using the remainder for collateral input), then after that swap, using the already-swapped coins for the collateral input of the remaining unswapped coins.
This leaks information: you are now linking a post-mix coin with a pre-mix coin, not onchain (if you do not mount an attack, which you probably will not) but you *do* reveal this information to the maker (one input is from the funding tx that is pre-mix, the collateral input is from the post-mix coin).

The only protection here is that the maker is unaware of the fact that your input coin is pre-mix and your collateral input is post-mix, so it can be hard for a maker to *use* this information.


However, it might be possible to prevent the maker from learning the collateral input at all.

If my understanding of BIP-143 is correct, inputs are hashed separately (`hashPrevouts`) from outputs (`hashOutputs`).
Bob can provide the `hashPrevouts` as an opaque hash, while providing a decommitment of `hashOutputs` to show that the outputs of the collateralized contract transaction are correct, which is all that Charlie really needs to know.

Bob is incentivized to provide the correct `hashPrevouts`, because if it provides an incorrect `hashPrevouts` it cannot get a signature for a transaction it can use in case of a protocol abort, thus potentially losing its money in case of a protocol abort.
Conversely, Charlie does not care *where* Bob gets the funds that goes into its contract output come from, it only cares that the Bob collateralized contract output is I+K.
It loses nothing to sign that transaction, and it would prefer that transaction since its own contract output is only I.

This solution is mildly "unclean" as it depends on the details of the sighash algorithm, though, and is not proposed seriously.
Hopefully nobody will change the sighash algorithm anytime soon.........

In addition, it complicates reusing Lightning watchtowers.
Lightning watchtowers currently trigger on txid (i.e. it would have triggered on the txid of the B collateralized contract tx), but watching this needs to trigger on the spend of a txo, since it is not possible to prove that a specific `hashPrevouts` etc. goes with a specific txid without revealing the whole tx (which is precisely what we are trying to avoid), as both are hashes.
Watchtowers may need to be entrusted with privkeys, or need to wait for `SIGHASH_ANYPREVOUT` so that the exact txid of the B collateralized contract tx does not need to be fixed at signing time, thus this solution is undesirable as well.

Regards,
ZmnSCPxj