> Another one, usually wouldn't be *protocol* as much as wallet leakage, but could be: utxo selection algorithm (which of course may be difficult to deduce, but often, far from impossible).

Yes sure that's a good point, it may affect protocol too if your LN implementation has its own onchain wallet. If not, and it reuses a non-LN wallet you just carry on its fingerprint.
An extension in the future could be for closing/splicing transaction, your liquidity algorithm may select in a really specific fashion which channels must be closed or increased...

> But I would ask people to consider CoinJoinXT[1] more seriously in a taproot/schnorr world, since it addresses this exact point.

The equal value paradigm is such a watermark and I assume it leans to increase the number of outputs so I don't see it followed by any other protocol. But yes CoinjoinXT, if you can come up with a easy interactive
multi-tx construction protocol that would be interesting (and could be reused by any cut-through implementation I guess).

Overall, my thinking was to start specifying this now because such thing would take a fair amount of time/coordination to get adopted. This way if and when Taproot/Schnorr happen we don't
have to wait another period to start enjoying the privacy enhancement (worst-case we can fallback on 2p-ecdsa).



Le sam. 22 févr. 2020 à 07:10, AdamISZ <AdamISZ@protonmail.com> a écrit :
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Friday, 21 February 2020 22:17, Antoine Riard via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

> How can a Bitcoin tranaction leak protocol usage ?
> * the output type (p2sh, p2wsh, ...)
> * the spending policy (2-of-3 multisig, timelock, hashlock,...)
> * outputs ordering (BIP69)
> * nLocktime/nSequence
> * RBF-signaling
> * Equal-value outputs
> * weird watermark (LN commitment tx obfuscated commitment number)
> * fees strategy like CPFP
> * in-protocol announcements [0]
>
Good list.
Another one, usually wouldn't be *protocol* as much as wallet leakage, but could be: utxo selection algorithm (which of course may be difficult to deduce, but often, far from impossible).
(Also trivial and increasingly irrelevant, but nVersion).

With regards to coinjoin in this context (I know your points are much broader), my comment is:
For existing protocols (joinmarket's, wasabi's, samourai's), in the equal-outs paradigm, I don't see much that can be done in this area.
But I would ask people to consider CoinJoinXT[1] more seriously in a taproot/schnorr world, since it addresses this exact point. With a short (not cross-block like swaps or LN setup) interaction, participants can arrange the effect of coinjoin without the on-chain watermark of coinjoin (so, steganographic). The taproot/schnorr part is needed there because multisig is required from transaction to transaction in that protocol, so doing it today is less interesting (albeit still interesting).

waxwing

[1] https://joinmarket.me/blog/blog/coinjoinxt/