PoC coming soon.

It's already baked in to The Four Horsemen, but it should be upstreamed to Payjoin:

In order to comply with this spec, wallet synchronization must be performed using compact block filters or the user’s full node *by default*. A client that passively intercepts coinjoin data from users should be considered .

I am going to propose an edit to BIP77 first. Default network level privacy is a critical prerequisite for any payjoin BIP compliance:

- Senders are disincentivized from opting in to payjoin by default since the receiver might be using a third party Electrum server. Their fee will be wasted, and chainalysis will intercept their data.

- Receivers are disincentivized from opting in to payjoin by default since the sender might be using a third party Electrum server. Their UTXO consolidation will be covertly exposed, and chainalysis will intercept their data.

- These compounding disincentives undermine the meta goal of payjoin, which is to dilute the certainty of mappings for any 2+ input 2+ output transaction.

- Third party Electrum servers create a perverse incentive between devs and their users, giving them privileged access to the data of users of unrelated wallets.

- Third party Electrum servers create a honeypot target, creating a dangerous environment for wallet developers.

All the prerequisite software exists, it's just scattered around. It could be assembled from Wasabi 1.0, Wasabi 2.0, and JoinMarket (all of these have overlapping payjoin support).

Wasn't Samourai both a Ten31 VC investment and Opensats donation beneficiary?

Even if a user doesn't care about their privacy at all, there is still a cost advantage for switching to a Four Horsemen supporting wallet.

Incentives matter in order to achieve privacy by default.

You identified the weakest UX flow in the entire spec 🎯

The only scenario where "Solo transaction" is the preferable path in the Four Horsemen workflow would be if the user needs an immediate payment, no batching, and bare minimum transaction fees. Using equal size outputs from taker coinjoins mitigates this.

Payjoin is the next cheapest, fastest option, only consuming ~40% more on chain fees than a solo transaction.

No, it makes sense when you add a third premise:

3. Scamming is easy when you print your own money and you'll probably get away with it

Tl;dr:

- If you are consolidating UTXOs, use WabiSabi
- If you are sending payments, use WabiSabi for maximum privacy, or Payjoin for lowest fees/wait
- If you are remixing, use ZeroLink
- If you are a whale, use JoinMarket's taker role
- If your node is waiting around, use JoinMarket's maker role
- If you are accepting payments, use Payjoin

Ambitious! My first concern is that this fragments liquidity even further. 5 mix depths is already restrictive, having (long lived) LN channels is somewhat of a counter-incentive.

The problem of overly-passive makers has another solution: Automatically sweep all UTXOs using a taker transaction whenever a mix depth accumulates N number of change/equal output UTXOs. Maybe default 19-21 UTXO limit per mix depth (randomized)?