Published on: 2020-06-03T14:36:46+00:00
In an email conversation, ZmnSCPxj informs Dmitry about creating a version of the TLA+ spec in the 'variant_ZmnSCPxj' branch of the SASwap repo. However, there is a possible deadlock after step 9 if Bob fails to publish a success transaction on time. To address this issue, Bob will have a short timeout period after which he will force publication of the success transaction if Alice does not respond. Running multiple servers can mitigate accidents due to computer crashes. A dead man switch system can countermand the main server in such situations. The probability of accidents occurring can be reduced to negligible levels.In another discussion between Ruben and ZmnSCPxj, they discuss the possibility of chaos if Bob neglects to broadcast the success tx before refund tx #1 becomes valid. They propose using sighash_single + anyonecanpay to ensure the TXO is spent before refund tx #1 becomes valid. They also suggest that in a client-server CoinSwap, the server should take Alice's position and the client should take Bob's position. Bob should spend his UTXO first to reduce resource wastage. They also discuss how Bob can specify address/value pairs in the success tx, allowing for additional flexibility later.The conversation revolves around a hypothetical situation where Alice and Bob are participating in a protocol. There are concerns about potential chaos if Bob misses the deadline for broadcasting the success tx. It is suggested that Bob should broadcast the success tx before refund tx #1 becomes valid. In a client-server CoinSwap, the server should take Alice's position and the client should take Bob's position. It is also important for Bob to spend his UTXO first to minimize resource waste. Additionally, there is a discussion about the use of private key handover and the risks associated with it.In a discussion between Ruben and ZmnSCPxj, they discuss potential issues with a proposed Lightning Network protocol. One concern is the possibility of chaos if Bob lets refund tx #1 become valid after completing the protocol. Another concern is the risk of both Alice and Bob knowing all the secrets on the LTC side and competing over it. The use of multiple CPFP outpoints is suggested to prevent pinning. They also discuss the need for backup watchers in case of irrational behavior.The conversation discusses a proposed protocol where Alice and Bob share secrets on the Litecoin (LTC) side and compete for it. Potential issues with the proposal are highlighted, including the risk of competing revoke transactions and the use of refund transactions that could lead to chaos if broadcasted. The need for a backup watcher is emphasized. The proposal is compared to Lightning Network's HTLCs and the benefits of spending the revoke transaction before or after its absolute timelock period are discussed.The email conversation discusses the use of private key handover for old-style coinswaps to mitigate potential issues with the traditional four-transaction swap. A proposal involving a shortened refund transaction is mentioned, but ZmnSCPxj notes an issue where Bob can give a copy of the revoke tx directly to a miner, forcing Alice to take three transactions to back out of the swap. Mitigation strategies, such as using CPFP outputs and minimum relayable feerate, are discussed. The safest alternative is for Bob to spend before the timelock expires.The conversation between Ruben and ZmnSCPxj discusses the technicalities of conducting a secure and efficient coinswap. Ruben proposes a pre-swap setup to reduce privacy concerns, while ZmnSCPxj suggests using relative timelocks and private key handover. The conversation delves into the specifics of the protocol, potential risks, and mitigation strategies. The importance of running multiple servers to ensure timely execution of transactions is emphasized.The email exchange between Ruben and ZmnSCPxj discusses a proposed CoinSwap protocol and its potential vulnerabilities. The concern is that if Bob misses the deadline, Alice will reclaim the funds. Different proposals are discussed, including using CPFP outputs and minimum relayable feerate. The safety of spending before the timelock expires is highlighted.The email exchange discusses a proposed coinswap scheme with improved scalability and privacy. The conversation highlights the use of relative timelocks and private key handover to achieve efficiency and privacy gains. The benefits of applying private key handover to coinswaps are mentioned.The email exchange between Ruben Somsen and ZmnSCPxj discusses a proposed CoinSwap model and the risks associated with it. The discussion focuses on the possibility of both Alice and Bob claiming the BTC, leading to claimable LTC by both parties. Strategies to mitigate these risks, such as adding two CPFP outputs and using the minimum relayable feerate, are discussed. The safest alternative is suggested to be for Bob to spend before the timelock expires.Ruben Somsen, a Bitcoin developer, has gained recognition for his innovative protocol called "Forced Refund TLC."
Updated on: 2023-08-02T02:13:08.885550+00:00