Coinjoins interceptions seem to raise at an increasing pace. Their onchain fingerprint (high-number of inputs/outputs, lack of anti-fee snipping, script type, ...) makes their detection quite easy for a chain observer. A ban of coinjoin'ed coins or any other coins linked through a common ownwer would undermine the long-term fungibility of the whole ecosystem.
Of course, they do provide privacy for the participating coins but at the tradeoffs of creating two observable sets: coinjoin'ed vs non-coinjoin'ed. Ideally, all onchain transactions should conform to a common transaction pattern that provides unobservability -- i.e a specific transaction would be indistinguishable from any other transaction at all. For LN or Coinjoin it means an external observer, not-involved in the protocol, should be unable to tell which protocol is being used, or if _any_ specific protocol is being used. 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] A solution could be to blur multiple protocol onchain transactions into one common transaction format [1]. For example, if one of them uses nSequence for some protocol semantic all the other ones should do it too. Any deviation would be enough to be leverage as a watermark and blow up all other tweaks. If Schnorr-Taproot gets adopted and deployed by the community and LN specifies an interactive tx construction protocol [2], the timing would be pretty good to adopt such format IMO. Coinjoin: * nSequence can be set, it's still secure if party don't resign [3] * nLocktime can be set for anti-fee snipping * Taproot spending LN (cooperative case): * splicing may blur funding/closing as the same thing, closing address can be a funding output * splice-in would allow equal value outputs * nSequence likely to be set for multi-party tx construction * nLocktime can be set for anti-fee snipping Adopting a common transaction format isn't a cure-all solution on the long-term privacy road but if it circumvent ban of some class of transactions that would be already a nice win and a worthy effort to do so. Questions: * Are there any protocol-specific semantic wrt to onchain transactions incompatibility between Coinjoin and cooperative LN txn ? * What about RBF-by-default ? * Core wallet or any other protocol or even batching algorithms could adopt to this format ? * Is artificially increasing the number of outputs to mimic Coinjoins txn acceptable wrt to utxo bloat/fees ? Cheers, Antoine [0] Like LN announcing public channels with signatures committing both to onchain utxos and nodes static pubkeys. And them being display on LN search engines with full owner info... [1] By format, I don't mean a *binary* format a la PSBT but mere something like BOLT3, a *logical* format. [2] https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-February/002500.html [3] But "blank" RBF would be a privacy leak if Coinjoin are never bumped, because if you see both a low-fees and high-fees transaction you now know they are a LN one, so Coinjoins implems should do some time spurious RBFs
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
