"Mix Depth" concept borrowed from JoinMarket & applied in Wasabi
2477 sats \ 11 comments \ @kruw 6 Aug privacy
Joinmarket/Jam compartmentalizes your privacy by segregating the equal sized private UTXO created by each coinjoin transaction into the next subwallet while leaving the nonprivate change UTXO in the original subwallet. This means if you received a deposit in the first subwallet, then any coin spent from your third subwallet is guaranteed to be at least two "hops" away from the original transaction.
Wasabi Wallet is built with a different coinjoin protocol and uses anonymity scores instead to determine when a coin is considered private enough to spend. Since there are no change UTXOs left behind by Wasabi's coinjoins (unless you are the largest whale in the transaction), there's no risk of merging non private UTXOs with private funds, allowing all of your coins to share the same derivation path.
But anonymity score is an opaque concept with a lot of weighted factors while distance acquired by mix depth is fairly straightforward. The "Coinjoin to another wallet" feature added to the GUI in Wasabi v2.0.7.2 allows users to mimic the mix depth concept to ensure a minimum number of hops in addition to a minimum anonymity score.
Basically, you send coins from subwallet A to subwallet B within a coinjoin, and send coins from subwallet B to subwallet C within a coinjoin. So with this setup, if you only receive coins in wallet A and only spend from wallet C, you will always be at least 2 "hops" away from the initial deposit regardless of what your anonymity score is.
https://m.stacker.news/43996
This can be coupled with the "stop coinjoin threshold" feature to keep control of the amount of UTXOs accumulated in your final destination. For example, you could set subwallet A to autostart coinjoin at 250k sats, set subwallet B to autostart coinjoin at 1m sats, and set subwallet C to autostart coinjoin at 5m sats. This will consolidate small UTXOs into larger ones as they get shifted into the next subwallet.
This method provides extra safeguards for preventing incoming transactions from being linked to outgoing transactions, but it doesn't do anything extra for buffering incoming transactions from being linked to each other, or outgoing transactions from being linked to each other.
Note that the anonymity score displayed when using the "coinjoin to another wallet" feature requires both subwallets to be loaded and depends on the order you loaded the subwallets in. For the best accuracy, load the sending subwallet before the receiving subwallet.
write
preview
related posts
121 sats \ 7 replies \ @DarthCoin 6 Aug
I am still not convinced that I should do a coinjoin in a "LN era" of Bitcoin. Coinjoins (that I also made in the past) were good only in the pre-LN era of Bitcoin. Now are totally a grift...
Nobody's gives a shit about my spending sats over LN buying a fucking beer. And I would challenge anybody to trace my beer shopping with sats over LN. Hey I can even give you a clue: I bought a beer with sats from SN account. Please find who I paid and from which UTXO was made...
reply
83 sats \ 0 replies \ @petertodd 7 Aug
LN does not have perfect privacy in all situations.
You should be using both LN and coinjoin if you want to maximize privacy.
reply
21 sats \ 0 replies \ @0277316049 7 Aug
I view coinjoins and LN as very different use cases that can provide some of the same benefits. I agree with you that lightning can be very private, but I don’t want to have large amounts of bitcoin tied up in a hot wallet on a lightning node. There is too much risk there. I’m going to coinjoin it and send it to a hardware wallet.
I’ll keep a several hundred thousand sats in a lightning node but not more than that.
reply
0 sats \ 4 replies \ @028559d218 7 Aug
please clarify if this is incorrect... but my understanding is that coinjoinining a utxo prior to opening a lightning channel with it is important (or at least can be).
this is because the receiver of the funds (on lightning) can look and see the 'opening channel transaction' originally used to create the 'sending' lightning channel. Other lightning users unrelated to the transaction cannot see anything going on as there is no 'public ledger' of lightning. however the receiver of the lightning funds can see the onchain transaction associated with the sending channel - the 'channel opening' transaction and therefore those 'utxos' have a history. in that way lightning is an improvement to privacy, but not a silver bullet. (that's my understanding)
reply
0 sats \ 3 replies \ @Longtermwizard 8 Aug
How?
reply
0 sats \ 2 replies \ @kruw OP 8 Aug
It's the sender, not the receiver, who is often able to see the UTXO of the other party. BOLT12, Blinded paths, or invoice wrapping can improve this.
reply
0 sats \ 0 replies \ @Longtermwizard 9 Aug
how can the sender see that?
reply
0 sats \ 0 replies \ @028559d218 8 Aug
+1
reply
21 sats \ 2 replies \ @0277316049 6 Aug
I attempted to use this feature in Wasabi right after it was released. What I found was that it outputted the coins to the new output wallet after only one round of coinjoins, regardless of the privacy scores reached in that round. I assumed that it would continue to mix the coins within the original wallet until it reached the privacy score that I had set and then on the final coinjoin round it would output to the configured wallet.
My use case is to receive new coins to a hotwallet within Wasabi and then coinjoin them and transfer to a hardware wallet that is also configured within Wasabi. I was hoping this feature would save a transaction at the end of the rounds of coinjoins, but it didn't work the way I was expecting.
reply
100 sats \ 1 reply \ @kruw OP 6 Aug
Yeah, the UX is a bit clunky. For your scenario, you would need to undershoot your intended anonymity score target, then apply the setting, then increase the target to be +1 higher than your most private existing coin to empty your first wallet into the second one.
reply
21 sats \ 0 replies \ @0277316049 7 Aug
That makes sense. Thanks for a good work around.
reply