Author: seid Mohammed 2020-09-06 03:06:52
Published on: 2020-09-06T03:06:52+00:00
On September 5, 2020, Antoine Riard wrote about the design vulnerabilities in the current CoinSwap implementation. In his response to Chris Belcher on bitcoin-dev, he suggested solutions to fix these issues. The first problem is that contract transaction output must be grieved by at least a CSV of 1 because a malicious counterparty can occupy with garbage both the timelock-or-preimage output and its own anchor output thus blocking you to use the bumping capability of your own anchor ouput. One possible solution to both vulnerabilities is to separate the timelock and hashlock cases into two separate transactions. Another possible fix for the second attack is to encumber the output with a `1 OP_CSV` which stops that output being spent while unconfirmed. However, these solutions have their limitations. The anchors-on-second-stage are more risky here, as otherwise your counterparty can again attach a low-feerate child. In case of concurrent broadcast, you might not see your counterparty version. You're left with a RBF-range, which is mostly okay except for a theoretical concern: a party guessing the odds to lose the balance are high can broadcast/send out-of-band the highest-fee bound to miners thus incentivizing them to censor an honest, low-fee preimage tx. Antoine suggests using dual-anchor outputs spec'ed out by Lightning, which lets the party who has a balance at stake unilaterally increase feerate with a CPFP. He also warns that if one downstream link failure occurs, it forces every other upstream hops to go on-chain to protect against this kind of pinning scenario, which would be a privacy breakdown.Chris Belcher is working on implementing CoinSwap, which improves the privacy even for people who do not use them. His email contained a detailed design of the first protocol version, which makes use of the building blocks of multi-transaction CoinSwaps, routed CoinSwaps, liquidity market, private key handover, and fidelity bonds. He explains that each single CoinSwap is made up of multiple transactions to avoid amount correlation. The design has one market taker and two market makers in its route but can easily be extended to any number of makers.The CoinSwap protocol involves a 2-of-2 multisig which is controlled by the next party in the route after the private key handover. The privacy provided by a single CoinSwap would be greater than that provided by an Equal-Output CoinJoin, and wouldn't have to be repeated. Only the taker knows the entire route; Bob and Charlie only know their previous and next transactions. When Bob and Charlie communicate, they send and receive messages via Alice who relays them to each other. This helps hide whether the previous or next counterparty in a CoinSwap route is a maker or taker. Makers have no incentive to pay any miner fees, while takers want to create transactions more urgently. Takers will pay all the miner fees, but must set limits on how large the maker's transactions are so as to prevent abuse. Funding transactions pay into the 2-of-2 multisig addresses, with I being the initial coinswap amount sent by Alice, (WA, WB, WC) being the total value of UTXOs being spent by Alice, Bob, and Charlie respectively, and (B, C) being coinswap fees paid by Alice and earned by Bob and Charlie. If a CoinSwap is successful, all multisig outputs in the funding transactions will become controlled unilaterally by one party. The table of balances before and after a successful CoinSwap shows how the balances of each party change. Contract transactions may spend from the 2-of-2 multisig outputs and transfer the coins into a contract where the coins can be spent either by waiting for a timeout or providing a hash preimage value. In the situation where each party gets their money using hash preimage values instead of timeouts, makers earn their CoinSwap fees but pay an additional miner fee twice. Using the timelock path is like a refund, while using the preimage is like the CoinSwap transaction happened, with the coins being sent ahead one hop. The timelocks are staggered so that if Alice uses the preimage to take coins, the right people will also learn the preimage and have enough time to be able to get their coins back too.The EC tweak trick allows two parties to agree on a 2-of-2 multisig address without agreeing on their public keys first, removing one round trip from the protocol. The document describes a coinswap protocol that allows two parties to exchange cryptocurrencies without revealing their identities. The protocol involves several steps, including the creation of multi-signature funding transactions and contract transactions containing hashed preimages. Each party also generates a nonce point to calculate their public key, which is used in the transaction. An eavesdropper can see the nonce but cannot find the private key because of the ECDLP.
Updated on: 2023-06-14T03:26:13.560449+00:00