Author: Chris Belcher 2020-05-03 19:28:23
Published on: 2020-05-03T19:28:23+00:00
In a discussion about CoinSwap, it was noted that mixdepths protect against inputs being co-spent and that some kind of mixdepth facility will still matter in CoinSwap. However, it was also acknowledged that for multi-transaction CoinSwap where no coins are merged, the sub-transactions from the same mixdepth may not be necessary.If coins need to be merged, it was suggested that they should be in the same mixdepth. The potential problem of two coins that cannot be merged in the same on-chain transaction was discussed, with the suggestion that any coins received via receive addresses would not be mergeable with any other coins, except coins to the same address.The issue of transactions with 1-input-1-output txes was discussed, with the proposal that using a PayJoin construction for the second tx could help. The scenario of Alice having two UTXOs she does not want to co-spend was also presented, with the suggestion that Alice could spend her UTXOs in 2-output transactions and mess with the change output detection heuristics.It was noted that if Bob does not have the coin value that Alice wants, Bob will have to split a UTXO it owns. It was proposed that Alice should tell Bob the amount she wants, and let Bob figure out how to get that amount based on the amounts he already has. However, it was pointed out that this could leak information to Bob about whether Alice is making a payment or not.A possible solution was to add randomness by having Alice randomly specify payment amounts with some probability even if she is only self-mixing. Another suggestion was to always give a specified payment amount, but a motivated Bob could still do statistical analysis on the payment amount to determine if it is likely to be a payment or a random amount on a self-payment.A proposal for private key turnover was also mentioned, which would involve turning over one's share of bilateral control to the swap partner after exchanging the swap secret. The implementation of private key turnover in CoinSwap allows for more flexibility and efficiency in the transaction process.Bob, the maker, can merge transactions without having to coordinate with Alice. If Bob gets another swap request, it can spend directly from the bilateral control address to another bilateral control address with a different taker, thus reducing blockchain footprint. Additionally, Bob can fee bump using RBF instead of CPFP. This increases complication in the process but can potentially result in an asymptote of 50% reduction in blockchain space usage for popular makers.Furthermore, if Alice wants to multipay, she could sum up all the outgoing values and modify the second transaction to pay multiple destinations since she has the private keys to do so. However, this would link all the outgoing payments together, which should be warned to the user. It would be best for both Alice and Bob to always change the destination address after private key turnover.Regarding privacy, relying on false positives works by having a large number of sets of transactions that add up to V just by chance, making it practically feasible. It is proportional to the n-choose-k function, which can still be very large. Therefore, Alice could split one of her 1 BTC coins into a 0.5 BTC and offer them in a CoinSwap to maker Bob, specifying a payment amount of 1.2 BTC. The initial standards can be derived from false-positive statistics, and once SwapMarket starts to become popular, using those standard swap amounts becomes even wiser due to larger anonymity sets.
Updated on: 2023-06-14T00:51:07.823963+00:00