Published on: 2022-08-08T13:12:44+00:00
The email thread discusses the idea of trading replacement transactions for privacy. Alice and Bob can share outputs, which are swapped in the replacement transactions. A 2of3 multisig with Carol is required to prevent cheating. Trading of private keys is not required, and PGP is not needed to share them securely. The process is similar to an HTLC, but with the addition of trading private keys for actual trades. Taproot may be used to selectively reveal certain script branches, but details are unclear.The proposed implementation involves creating an API managed by Carol, using a 2of3 multisig with Alice, Bob, and Carol's keys. Alice and Bob create orders for replacement, either matched automatically or accepted manually by Bob. Bob locks 0.01 BTC in the multisig and shares outputs e2 and f2 with Alice. Alice signs tx2 and shares it with Bob. Alice locks 0.011 BTC in the multisig and shares outputs b2 and c2 with Bob. Bob signs tx2 and shares it with Alice. Both replacement transactions can be broadcasted, and funds are released from the multisig with a transaction having three outputs, with one output paying the fee which goes to Carol.The positives of this process are privacy, while the negatives include extra fees and time taken to manage everything with the API provided by Carol. It requires locking bitcoin with the same amount as used in tx1, and amounts could still be used to link transactions in some cases.The email thread discusses the concept of trading replacement transactions for privacy. The goal is to break the assumption that a replacement transaction is done only to use a higher fee rate with the same sender and recipient. This method offers an extra privacy option, and if the user selects it, everything happens in the background. The UX will be simple, and the user just needs to approve in between. This scheme aims to provide different levels of privacy from coinjoin and coinswap methods. However, the protocol's additional complexity raises questions about whether this is worth it.A two-party coinjoin can get you an output where it isn't clear to blockchain observers which output you control, and coinswap has you taking the coin history of your counterparty. The proposed method involves creating an API to manage trades that will use 2 of 3 multisig. Alice and Bob create orders for replacement, and they could be matched automatically using some algorithm or Bob manually accepts the offer. Two of three multisig is created with Alice, Bob, and Carol keys. Bob locks 0.01 BTC in it and shares outputs e2, f2 with Alice. Alice signs tx2 and shares the transaction with Bob. Alice locks 0.011 BTC in it and shares outputs b2, c2 with Bob. Bob signs tx2 and shares it with Alice. Both replacement transactions can be broadcasted, and funds are released from 2 of 3 multisig with a transaction having three outputs (one to pay fee which goes to Carol).Although this method would improve privacy, there are negatives like extra fees, time consumption, knowing details by Carol and other peers, and need to lock bitcoin with the same amount as used in tx1. However, if this method makes sense or a similar market to trade replacements in the future, it could help create a process in which a chain of replacements happens before Bitcoin reaches the destination, similar to a tor circuit.In a message to Bitcoin Developers, a user named 'alicexbt' asked whether it makes sense to trade replacement transactions for privacy. They shared basic details on how this could be done and requested opinions or suggestions for improvement. Another user named Michael replied, stating that he was struggling to understand the purpose of this scheme in terms of privacy, especially considering the added protocol complexity. He stated that a 2-party coinjoin or coinswap could offer similar privacy benefits without the extra complexity.Alicexbt's proposal involved creating an API managed by a third party named Carol, which would enable trades using a 2-of-3 multisig setup. Alice and Bob would create orders for replacement transactions, which would involve swapping outputs with a counterparty. The matching process could either be automated or done manually by Bob. Both parties would lock their bitcoin and share outputs with each other, before signing the transaction and broadcasting it. The positives of this scheme were increased privacy, while the negatives included extra fees, time, and the need to lock bitcoin with the same amount used in the initial transaction.The email is addressed to Bitcoin developers and discusses the concept of trading replacement transactions for privacy. The email includes a proposal by Alice to implement this idea, which involves creating two transactions (tx1 and tx2) with specific inputs and outputs. Bob also has his own set of transactions, and Carol creates an API to manage trades using a 2 of 3 multisig system.
Updated on: 2023-08-02T07:15:43.350522+00:00