Published on: 2020-09-06T03:06:52+00:00
to create multisig addresses, and funds were locked into these addresses. Contract transactions were created to transfer funds using timelocks or hash preimage values. Various vulnerabilities in the protocol were identified, such as fee model vulnerability and transaction pinning vulnerability. Proposed solutions included using anchor outputs in contract transactions and separating timelock and hashlock cases into separate transactions. The implementation of CoinSwap involved broadcasting and mining contract transactions, waiting for timeouts, and using hash preimage values to retrieve funds. Parties paid their own miner fees in timeout failure cases, and anti-DOS features were implemented to prevent attacks.The email exchanges also discussed the usage of relative and absolute locktimes in contract transactions with Scriptless Script, specifically Pointlock transactions. Absolute locktimes allowed participants to define their fee ranges without negotiation. Private key turnover was suggested to reduce funding lockup time for multi-hop swaps, and diagrams were provided to illustrate different scenarios.The CoinSwap protocol aimed to improve privacy by allowing users to swap Bitcoin without revealing amounts or addresses. Multiple transactions were used in a single CoinSwap to avoid amount correlation. Makers only knew their previous and next transactions, while the taker knew the entire route. Funding transactions paid into 2-of-2 multisig addresses, and contract transactions transferred coins to a contract that could be spent with timelocks or hash preimage values. Vulnerabilities such as pinning scenarios and theft attempts were addressed through various solutions, including watchtowers to guard CoinSwaps and prevent theft attempts.The implementation of CoinSwap for privacy and fungibility was being worked on by Chris Belcher. The protocol included multi-transaction CoinSwaps, routed CoinSwaps, liquidity markets, private key handover, and fidelity bonds. Contract transactions played a crucial role, and vulnerabilities and proposed solutions were discussed. Absolute timelocks, watchtowers, and split UTXOs were proposed to enhance the protocol. Relative timelocks, DOS-resistance, and deviations from the protocol were also addressed.In an email exchange between Nadav and ZmnSCPxj, concerns about the security of a proposed public key scheme for Bitcoin transactions were discussed. The main concern was the potential for the taker to steal funds by manipulating the nonce point used in the transaction. ZmnSCPxj clarified that the taker must provide the actual value of the nonce to the maker, eliminating the need for the maker to trust the taker's calculations. The discussion then shifted towards the use of 2p-ECDSA for privacy protection in CoinSwap transactions. While ZmnSCPxj argued that using OP_CHECKMULTISIG instead of 2p-ECDSA would remove most of the privacy advantages, he acknowledged the possibility of implementing OP_CHECKMULTISIG first and adding 2p-ECDSA later. Nadav agreed but emphasized the significant privacy benefits of singlesig anonymity sets.The implementation of CoinSwap involved two parties, the taker and maker, exchanging coins through atomic cross-chain trading. The protocol started with the taker broadcasting a funding transaction to a 2-of-2 multisig address and creating HTLCs specifying amounts and addresses. The maker signed the HTLCs, creating contract transactions that were not broadcast but exchanged between the parties. The EC tweak trick could be used to reduce round trips required for agreeing on public keys. Concerns were raised about a possible attack by a malicious taker who intentionally aborts the swap, causing makers to lose more money than the attacker. Parties needed to be prepared to respond to contract transactions at all times, as the outputs of the funding transactions could remain unspent indefinitely.ZmnSCPxj raised concerns about the security of CoinSwap, particularly regarding the taker providing the nonce 'p' to the maker, which could potentially lead to fund theft. He suggested using 2p-ECDSA to address this issue. Additionally, he emphasized the importance of hiding among larger singlesig anonymity sets and discussed the use of HTLCs in open-coded SCRIPTs for increased privacy.Nadav raised concerns about the proposed CoinSwap protocol on the bitcoin-dev mailing list, particularly regarding the generation of signatures for HTLCs from the pubkey used in Bitcoin transactions. He suggested the use of Zero Knowledge Proof of Knowledge (ZKPoK) or a different key implementation like MuSig. The email also explored the advantages of direct connections to Alice over CoinJoin and potential leaks in CoinSwap. Makers having no incentive to pay fees and takers setting limits on maker's transactions were mentioned. Contract transactions that spend from the 2-of-2 multisig outputs were explained, with staggered timelocks to allow for recovery in case of malicious actions. The EC tweak trick was highlighted as a way to reduce one round trip when agreeing on public keys.The email thread provided insights into the proposed CoinSwap protocol and its potential deviations.
Updated on: 2023-08-02T02:33:40.925726+00:00