Author: Antoine Riard 2020-02-21 22:17:54
Published on: 2020-02-21T22:17:54+00:00
Coinjoin interceptions are increasing in pace and their detection is quite easy for a chain observer due to their onchain fingerprint such as high-number of inputs/outputs, lack of anti-fee snipping, script type, etc. However, banning coinjoin'ed coins or any other coins linked through a common owner would undermine the long-term fungibility of the whole ecosystem. While coinjoin transactions provide privacy for participating coins, they create two observable sets: coinjoin'ed vs non-coinjoin'ed transactions. Ideally, all onchain transactions should conform to a common transaction pattern that provides unobservability. 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. Bitcoin transactions can leak protocol usage through output type, spending policy, outputs ordering, nLocktime/nSequence, RBF-signaling, equal-value outputs, weird watermark, fees strategy like CPFP, and in-protocol announcements.A solution could be to blur multiple protocol onchain transactions into one common transaction format. Adopting a common transaction format isn't a cure-all solution on the long-term privacy road but if it circumvents a ban of some class of transactions that would be already a nice win and a worthy effort to do so. Questions arise regarding protocol-specific semantic wrt to onchain transactions incompatibility between Coinjoin and cooperative LN txn, RBF-by-default, whether core wallet or any other protocol or even batching algorithms could adopt this format, and whether artificially increasing the number of outputs to mimic Coinjoins txn is acceptable wrt to utxo bloat/fees. Coinjoin allows nSequence to be set and is still secure if party don't resign, nLocktime can be set for anti-fee snipping, and Taproot spending. On the other hand, cooperative LN txn has splicing capabilities that may blur funding/closing as the same thing, closing address can be a funding output, splice-in would allow equal value outputs, nSequence is likely to be set for multi-party tx construction, and nLocktime can be set for anti-fee snipping. If Schnorr-Taproot gets adopted and deployed by the community and LN specifies an interactive tx construction protocol, the timing would be pretty good to adopt such format.
Updated on: 2023-06-13T23:37:18.985014+00:00