Detailed protocol design for routed multi-transaction CoinSwap



Summary:

The email thread discusses the implementation of CoinSwap, which is a protocol that looks like a regular Bitcoin transaction and improves privacy for all users. The protocol involves multi-transaction CoinSwaps, routed CoinSwaps, liquidity market, private key handover, and fidelity bonds. In a routed CoinSwap, Alice gives coins to Bob, who gives coins to Charlie, who gives coins back to Alice. Multiple transactions are used in a single CoinSwap to avoid amount correlation. Only Alice, the market taker, knows the entire route, while Bob and Charlie only know their previous and next transactions. They do not have direct connections with each other, only with Alice. Makers have no incentive to pay any miner fees. Funding transactions pay into the 2-of-2 multisig addresses, and contract transactions transfer the coins into a contract where they can be spent either by waiting for a timeout or providing a hash preimage value. The protocol has some vulnerabilities, such as pinning scenarios, where the victim would be an intermediate hop targeted by a malicious taker. However, this vulnerability can be overcome by restraining the contract transaction to one version. Another issue is that using relative timelocks forces every other upstream hop to go on-chain in case of one downstream link failure, which reveals the CoinSwap route and breaks privacy.The CoinSwap protocol involves parties broadcasting and mining contract transactions, waiting for timeouts, and using hash preimage values to get their money back. The parties pay for their own miner fees in the timeout failure case, and there are anti-DOS features to prevent malicious attacks. A possible attack by a malicious party is also discussed, along with the failure case where each party gets their money using hash preimage values instead of timeouts. Staggered timelocks are used to ensure that the right people learn the preimage and have enough time to get their coins back. The EC tweak trick is used to avoid one round trip when two parties are agreeing on a 2-of-2 multisig address. The protocol involves several steps, including setting up funding transactions and contract transactions for possible refund. Abort scenarios are analyzed, where one party halts the protocol and doesn't continue. Retaliation as DOS-resistance is discussed as the best way to resist DOS because it produces a concrete cost every time a DOS happens. Deviations from the protocol, such as broadcasting an htlc contract tx when one shouldn't have, are also discussed.The document describes the first version of a protocol that implements multi-transaction Coinswap, routed Coinswap, fidelity bonds, a liquidity market, and private key handover. The protocol allows parties to swap Bitcoin without revealing the amounts being swapped or the addresses involved. The protocol also includes steps for handling aborts and deviations from the protocol. If multiple deviations are possible in a step, they are numbered. The multisig outputs of the funding transactions can stay unspent indefinitely, but parties must always be watching the network and ready to respond with their own sweep using a preimage. Alice's reaction of blacklisting both fidelity bonds might not be the right way because one maker could use it to get another one blacklisted (as well as themselves).


Updated on: 2023-06-14T03:17:30.684913+00:00