I'm still personally not comfortable with the level of anonymity/privacy obtained from naive Bitcoin transactions or LN ones (see #1562360). This is an attempt to improve the privacy of both at the same time, without making the CJ itself more expensive. The novelty is that it hides the participants change amounts by keeping that information offchain among the shared change UTXO owners. This change becomes a LN channel able to route payments that shift the balance split over time, and can be spent discretely in a cooperative trustless fashion. It's also better than a direct LN channel open because the initial balance is not fully on the opener's side and can't be known by onchain or LN observers.
It opens the possibility for JM makers to becomes LN swap providers (much needed after #1539278). And for existing LN swap providers to have an alternative and economically profitable way of balancing their liquidity.
For JM users (both takers and makers) it would be a way of having many ways of spending and receiving privately, both onchain and though LN.
Interested on @justin_shocknet's opinion on this. I know you think CoinJoins are bullshit, and your views on privacy solutions becoming honeypots/counter productive. But hopefully this idea opens the path for an economically rational ecosystem that creates herd privacy as a side effect.
That's the correct framework to approach solutions with, so off to a good start.
I take some issues with this, others apply to coinjoins/vtxo's as well because of the coordinator replacing the peer or swap provider.
Point of order, bolt11 can do blinded paths.
It does reduce to good practices are still required, which is correct, and that's also part of my framework of thinking about these issues.
Would take time I don't have to dive into the detailed mechanics of this properly and form a mental model, so the following impressions from a quick first pass.
I think this is presupposing the bifurcation of the coordinators. The VTXO coordinator has different information than the CoinJoin coordinator in theory, but I'm not sure that's true, because if the change is obvious on chain then its provenance is just as obvious to the VTXO coordinator.
I don't think it can be assumed that the VTXO coordinator is oblivious to the movement within the lightning channels after the fact either. You may shield chain information from your channel peer, but the same sybil risks still apply and are perhaps made worse by the VTXO coordinator having an incentive to secure Lightning liquidity.
I think this recognizes to the crux of the issue, if you use the VTXO to wash the change, its still roughly the same amount on-chain within a few bps with a similar heuristic of entrance/exit out of a coordinated scheme. I don't see what's additive by the extra steps.
Since we can't reasonably assume bifurcation of the coordinators given the shared chain view nor sybil resistance of the off-chain movement, I think this might be an over-complication of an Ark etc that only allows chain outputs of a given size with anything other than that being restricted to a Lightning payment so there are no change outputs at all.
What I don't know is if that an Ark can enforce those output size constraints, that would undermine any unilateral exit claims, which may be why you've arrived at 2 coordinators with different tasks but not inherently blinding the second.
From an economics standpoint, I don't see what appeals to the herd to make privacy the by-product of something other. Sitting on would-be change in a virtual channel adds even more costs with rounds. Since there's those added costs privacy is ultimately the product, which combined makes it honeypot. There's always going to be a cost to enter a privacy scheme vs. making a direct payment. Even if you get the post mix output costs down substantially through batching, its still at least a second tx that needs confirmation.
At the risk of sounding like a nihilist on these matters, I think what you're trying to solve is intractable. At least this is outside the box a bit and combining different elements, unfortunately I think it's just moving problems around though.
If an epiphany strikes me i'll follow up.
I'd love to see this happen!
Love seeing new ideas around making Bitcoin privacy more practical
Great writeup. The real problem with CoinJoin change outputs is that they break the assumption that all UTXOs have the same anonymity set. If you mix 100k sats and get 43k sats change, that change is now traceable to your original input even if the mixed output is private.
One approach some are exploring: use LN channels as the "change destination" — open a channel with the change amount, then use that liquidity for payments. The channel opens from an on-chain tx that looks like any other LN setup, so the change is effectively laundered through the routing network.
Have you looked at how pools like Wasabi handle change beyond just labeling it as "unmixed"?
Routing CoinJoin change directly into shared Lightning channels creates a major privacy tradeoff. In WabiSabi clients like Wasabi or Ginger Wallet, change outputs carry deterministic linkability to registered inputs. If you immediately fund a public Lightning channel using unmixed change, that channel's outpoint becomes publicly announced on the gossip network, permanently tying your node ID and subsequent routing activity back to that change UTXO. A safer approach is utilizing zero-coordinator-fee remixing (available in Ginger for outputs under 0.03 BTC) or private submarine swaps over Tor to decouple your on-chain transaction graph before opening channels.