Updated Bitcoin CoinSwap Protocol Design Spurs Further Discussion
UK-based developer Chris Belcher has released a design document for a routed multi-transaction CoinSwap implementation, further developing his work on improving Bitcoin (BTC) transaction privacy and fungibility. The post, which comprises a detailed design of the first protocol version, has spurred further discussions, with various voices from the Cryptoverse inquiring on the protocol’s safety in using cryptography and ensuring the transactions would be safe for both parties.
The latest development “makes use of the building blocks of multi-transaction CoinSwaps, routed CoinSwaps, liquidity market, private key handover, and fidelity bonds. It does not include PayJoin-with-CoinSwap, but that’s in the plan to be added later,” according to Belcher.
The proposal builds on the developer’s design from last May in which he explained how CoinSwap’s implementation could ensure undetectable privacy to crypto transactions.
CoinSwap is actually not new. It’s an old privacy protocol originally created seven years ago by Greg Maxwell, co-founder of Blockstream and the creator of CoinJoin. It came back into public’s attention with Belcher’s implementation. It basically allows two or several parties to swap coins, while the end recipient’s address is not published on the blokchain, in theory meaning improved privacy and fungibility.
The August design has triggered a number of reactions on GitHub. While generally recognizing the innovativeness of Belcher’s code, some users have asked a number of highly technical and detailed questions about the protocol’s functionalities.
“In CoinJoin, since all participants sign a single transaction, every participant knows the total number of participants. Thus, in CoinJoin, it is fairly useless to have just one taker and one maker, the maker knows exactly which output belongs to the taker. Even if all communications were done via the single paying taker, the maker(s) are shown the final transaction and thus can easily know how many participants there are (by counting the number of equal-valued outputs),” wrote user ZmnSCPxj.
In principle, with CoinSwap, “no maker has to know how many other makers are in the swap,” so it “would still be useful to make a single-maker CoinSwap, as that would be difficult, for the maker, to differentiate from a multi-maker CoinSwap,” according to the user.
ZmnSCPxj also pointed to “a few potential leaks”:
“If paying through a CoinSwap, the cheapest option for the taker would be to send out a single large UTXO (single-output txes) to the first maker, and then demand the final payment and any change as two separate swaps from the final maker. Intermediate makers are likely to not have exact amounts, thus [it] is unlikely to create a single-output tx when forwarding. Thus, the first maker could identify the taker.”
Antoine Riard, a Bitcoin Core and Rust-Lightning contributor at Chaincode Labs, pointed to what he found to be vulnerability issues with the presented design.
“With regards to the fee model for contract transactions, AFAICT timely confirmation is a fund safety matter for an intermediate hop. Between the offchain preimage reveal phase and the offchain private key handover phase, the next hop can broadcast your outgoing contract transactions, thus forcing you to claim quickly backward as you can’t assume previous hop will honestly cooperate to achieve the private key handover,” Riard said.
With a number of questions around this privacy technique to be answered, the discussions continue.