Oh ya, I get that. But the goal is to avoid reusing an address that's used in a different tx, on the output side of the coinjoin. If you can guarantee that never happens, even if the recipient of some UTXO's in the coinjoin is distinct from the sender who owns some inputs in the coinjoin (for example I'm making a donation to some org via a coinjoin), without requiring interaction from the recipient, that would be good and worth added complexity to do the silent protocol within the coinjoin.
Discussion
That's a good point actually.
However the receiver ultimately has to run a custom synchronization to find his coins, so legacy wallets won't work.
Ya this is a significant downside of silent payments. I think the custom sync is worth the downside. Could implement both legacy sync and silent payment sync for users of the feature
Why no lightning address, sir?
Where am I supposed to toss them sats... You can't just rob me of the joy of zapping great content!
I'll get my non custodial LN address set up one of these days
Adding to this: you could flag all "silent" coinjoin txs via an OP RETURN field and implement an RPC that returns those txs for the silent sync. A wallet need only sync new txs since it last loaded. Should keep sync overhead low.
This idea to implement coinjoin friendly silent payments or a similar scheme may be of interest to you
#[3]