Published on: 2014-08-11T17:06:48+00:00
The discussion revolves around the requirement to ensure validity at a certain level and how it can constrain the use cases of protocol implementations. It is mentioned that parties can generate chained transactions on unconfirmed transactions, which can be difficult to do safely but may be safe or desirable in some circumstances. Clients are recommended to validate the inputs to a shuffle they are participating in, depending on the client type. SPV clients without servers can use getUTXO or verify the validity of the transaction that created the input designated for mixing. A signed transaction that spends the money can also convince even SPV clients that a participant with these inputs is trying to cheat. However, lite clients cannot perform this check, making the protocol vulnerable to DoS attacks. An alternative solution is to have participants submit the merkle proof for the input, but this requires inputs to have at least one confirmation.The efficacy of coinjoin is discussed, with concerns raised about the input potentially being spent already, which would make it invalid. In such cases, a signed transaction that spends the money would be sufficient to convince even SPV clients that the participant with these inputs is cheating. However, getutxo cannot return the spending transaction as the UTXO set doesn't record this information. The divergence can be detected if enough peers are honest, but if all peers are lying and the attacker controls the internet connection, it wouldn't make much difference as they could swallow the transaction being broadcasted. Ultimately, if peers think a TXO is spent and refuse to relay transactions that spend them, there is not much that can be done, even in the non-SPV context. The ability to reach at least one peer who believes in the same world is crucial.The conversation explores the possibility of using lightweight clients in a protocol. The worst-case scenario for these clients is that a transaction will not confirm, leading to a DoS attack. For clients relying on servers, it is reasonable to trust these servers to prevent such attacks. However, for SPV clients without servers, alternative solutions like getUTXO or verifying the validity of the transaction designated for mixing need to be considered. The only remaining issue would be if the input has already been spent, but one honest client with full information can provide a signed transaction that spends the money, convincing even SPV clients that the participant with this input is cheating. Merkle proofs for inputs are also discussed, but they require at least one confirmation. Overall, a policy for lightweight clients needs to be established to ensure the security of the protocol.A group of researchers in Germany has proposed CoinShuffle, a decentralized protocol for CoinJoin that allows for mixing coins among users to improve anonymity. CoinShuffle provides a clever way to create a CoinJoin transaction without the need for trusted third parties. The advantage of CoinJoin over mixing with a server or trusted party is that nobody can steal coins. Each user can check if the transaction sends enough coins to their fresh output address, and if not, refuse to sign the transaction. CoinShuffle ensures anonymity by eliminating the need for a server to know which input addresses belong to which output addresses. It is secure against thefts and robust against denial-of-service attacks. The protocol requires only public-key encryption and signatures, making it efficient and compatible with the current Bitcoin system without requiring changes to the protocol. While a proof-of-concept implementation is available, it is insecure and not well-written. The researchers plan to develop a full, open-source implementation and welcome help in the process, including design, coding, and feedback.In an email exchange between Sergio Lerner and Tim, the possibility of de-anonymizing the first party in a protocol is discussed. Sergio suggests that the second party can de-anonymize the first party, but Tim disagrees, stating that the second party doesn't know how the other parties shuffled the outputs as it doesn't have their decryption keys.The issue of decentralization in a shuffle protocol is raised in an email exchange between Sergio and Tim Ruffing. Direct connections to a randomly elected leader responsible for broadcasts or overlay networks like distributed hash tables are suggested as possible solutions. The issue of Sybil attacks is also discussed, with suggestions to divide users into individual groups and ensure that the assignment cannot be influenced by the attacker. Various methods for setting up initial pools of participants are mentioned, including using peer-to-peer networks like Bitcoin or chans in Bitmessage. Combining several pools and using information from friends are also proposed as solutions. While there is no perfect solution, several proposals work well enough if implemented correctly.Tim Ruffing expresses concerns about the decentralization and security of CoinShuffle, questioning how users can securely communicate with each other and prevent Sybil attacks. He does not see how CoinShuffle offers a solution to these problems.
Updated on: 2023-08-01T10:11:08.502872+00:00