m0wer's avatar
m0wer
m0wer@sgn.space
npub1w3va...4c5c
JoinMarket NG
m0wer's avatar
m0wer 5 days ago
23 out of the total of 102 JoinMarket makers are using JoinMarket NG! Very happy to see that. And 28 out of the 102 offers have exact grid fees, helping each other create more confusion on their CJs.
m0wer's avatar
m0wer 1 week ago
Let me present you what could be the future of JoinMarket and hopefully a great tool for Bitcoin privacy and fungibility. First of all, there is the motivation. JM makers have an onchain fingerprint, that although it's hard to follow, limits the privacy achieved by the takers. The full details are at
Gist
maker_swaps.md
GitHub Gist: instantly share code, notes, and snippets.
 But to save you some time, here the main problems described there are: unique enough maker fees, co-spending of inputs, makers never spending, ... Which in the worst case scenario, would mean that a pure onchain observer could potentially cluster some makers across mixdepths and reduce the anonymity set by one of CoinJoins where they participate. So what can we do? Well, we can use this chance to bring JM to the next level. And create such a transaction graph "mess" that becomes a chain analyst nightmare :-) Let me explain. We can't ever get fully rid of the links between UTXOs onchain, or at least not without a way more complex multi taker model that leads to Knapsack "dense" transactions. But we can strive for something, that is that no single party ever has all the information. The idea is the following. JM makers could become Lightning Network swap providers. Like Boltz, like SwapMarket, like electrum swapserver. Using Taproot swaps and advertising through Nostr. LN swap users get a simple and trustless client side web UI, makers get "fresh" UTXOs from onchain->LN swaps and the opportunity to "spend" CJ outputs for LN->onchain swaps. Oh, and another source of fees. LN swap users get cheaper swaps from the increased competition. But this is not enough. We need to break the subset sum analysis onchain. We want to stop maker clustering from the root. Here is the next idea, JM CJ participants (makers and taker) could get their change as an LN channel open. Or two, with random other peers and the change amount split randomly between both channels. So a maker that has a 10 M sats input in a 5 M sats CJ no longer gets just a clear ~5M sats change, instead, two LN channel opens where the balance is hidden. Maybe 2M sats in one and 3M sats in the other. But an external observer wouldn't know. Not even which channel is whose! You could say, well, but an active attacker could probe those channels balance. Maybe, but not really. Those channels would be private simple taproot (HTLC based, not PTLC yet unfortunately), so not advertised to the network. And, BTW, onchain they look like any other P2TR output BTW. Advertised only when needed with a SCID alias that does not reveal the onchain UTXO. But hey, who knows, maybe some peer node that gets the SCID could try to probe it. Fear not! There's another ingredient coming to the mix. lnproxy is a great service to hide the destination node of an LN BOLT11 invoice by having a relay/proxy node wrap it. The payment hash is the same, only the recipient can settle the payment. But whoever sees the wrapped invoice sees the relay/proxy pubkey instead of the destination one. Why not decentralize lnproxy through Nostr and then makers can be lnproxy providers as well? Just to add a little bit more noise to their LN activity and help move the balances around. So that if these change as channels ever close (cooperatively) the onchain fingerprint those not help understand what happened in the opening CJ. Or that UTXO can still be used as CJ inputs if signed cooperatively. Or, of course, as LN channels for swaps of lnproxy. Some kind of noisy spin of CoinjoinXT. What we need for this and what we're currently working on at jm-ng: - A JM taproot only pit. - Decentralized lnproxy. - Decentralized LN swap providers. - Protocol wiring for the change as channel CJ coordination. - People to actually use this and not be overwhelmed by the complexity. But if we manage to make this work, we will have awesome onchain and LN privacy. And a way for service providers to earn money anonymously by providing privacy to others. So it's definitely worth a try :-)
m0wer's avatar
m0wer 2 weeks ago
JoinMarket makers with unique enough fees are easily clustereable across mixdepths and don't provide much privacy to takers that choose them. Imagine there is only one maker that charges 0.123% fee. An external observer can identify that maker's equal amount outputs when they are provided as inputs for another coinjoin with the same fee (observable onchain). So I would encourage makers to select one of these quantized fees and disable randomization. This is an opt in change that joinmarket-clientserver and joinmarket-ng makers can apply on their own. The more makers on the same quantized fee, the better anonymity for them and consequently for takers that pick them. More info at
JoinMarket Maker Clustering and Taker Anonymity-Set Reduction
 and
GitHub
Taker-side maker fee quantization · Issue #508 · joinmarket-ng/joinmarket-ng
Each maker advertises a per-CJ fee policy (cjfee_a, cjfee_r). Within a single round the realized maker fees are a deterministic function of each po...
 image
m0wer's avatar
m0wer 3 weeks ago
JoinMarket makers can be clustered (across mixdepths). Two ways: - Easily if their CJ fee is unique enough and reused between rounds. - Harder by gathering co-spending thought many rounds and waiting for the intersection to be narrow enough. It's easier said than done in practice. Bit it's still something to improve. Here is a more detailed explanation of the problem and possible solutions that could bring JM achieved anonymity to the next level.
Gist
maker_swaps.md
GitHub Gist: instantly share code, notes, and snippets.
 Feedback welcome!
m0wer's avatar
m0wer 3 weeks ago
Nice podcast. Bitcoin is unstoppable, but you are not. Privacy is what makes you not worth attacking.
↑