Hi ZmnSCPxj, thank you for your detailed comments. I agree that the centralization risk is a big problem. I didn't fully take into account how hard it might be to distinguish honest service providers, which makes that problem so much worse. I think I'll not pursue this approach for that reason. While such a system can't be prevented I don't need to encourage it.
I might look into the "pay someone to add their UTXO to a tx for fees and give them back the remainder" approach though, it doesn't seem as hazardous and might even be possible to do in a decentralized fashion. > Now, you have mentioned a number of times that you believe Bitcoin will > eventually be a settlement layer, and somehow link this with standardized > UTXO sizes. > But I think the end goal should be: > > * To improve Bitcoin blockchain layer privacy. > > It should not matter how we achieve this, whether it involves standardized > UTXO sizes or not; if you want to use this solution, you need to present a > good reason why this is the best solution for Bitcoin privacy, and better > than other solutions. I completely agree. > For example, the JoinMarket way of CoinJoining does not require any > particular standardized UTXO size. > The upcoming SwapMarket that Chris Belcher is working on, also does not > require such a standardized UTXO size, as it is based as well on the > JoinMarket technique, where the client can select whatever sizes it wants. > Why should the Bitcoin ecosystem adopt a strict schedule of UTXO sizes for > privacy, if apparently JoinMarket and SwapMarket can improve privacy without > this? These efforts are great! Yet all CoinJoin based protocols I have seen (mostly academic ones tbh, that provide strong guarantees) have some amount of overhead in the form of creating more UTXOs and bigger transactions than minimally possible or even "toxic waste" we don't know what to do with. As far as I understand it there's now way around that without relaxing anonymity guarantees. Maybe I'm not up to date in that regard. I also think that the privacy properties/the actual anonymity set of unequal output size CoinJoins (i.e. knapsack mixing) is not as well understood as for evenly-sized output CoinJoins. If we are only talking about user-defined CoinJoin output sizes it comes down to efficiency again. This will nearly always lead to change and not many parties will be interested in the particular output size so you even need to pay them to participate. Please bear with me as the following part is _very_ speculative: I believe that if Bitcoin becomes mainstream (I take no stance whether this is good or not, but consider it a possibility) transaction prices are bound to increase dramatically, which would make such protocols uneconomical. This also means most people will rely on some L2 technology. But the fees might even make Lightning nodes uneconomical for the majority of people. So if we are lucky federated L2 systems, or if we are unlucky centralized ones, will play an important role imo. In such an environment, where on-chain transactions are mostly used as settlements between somewhat big players, having (multiple tiers of) evenly sized UTXOs makes a lot of sense. You don't need exact valued transfers and get free/cheaper than free and effective mixing on spends if you just combine your transactions. So imo the pros of this technique are: * as simple as possible (easy to assess exact anonymity set) * cheap, so it could be made a default, leading to a large anon set while the cons are: * only makes sense when exact values aren't important (e.g. L2 funding) * needs fee hacks I don't want to derail this any further. I agree that my initial idea bears too great risks of regulatory capture. While I find the evenly-sized UTXO idea intriguing I'd be even happier about a arbitrary-amount scheme that gives the same strong assurances in an _efficient_ manner, I just haven't seen a way to achieve this so far. Best, Sebastian _______________________________________________ bitcoin-dev mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
