Antoine Riard [ARCHIVE] on Nostr: ð Original date posted:2020-02-21 ð Original message:Coinjoins interceptions ...
ð
Original date posted:2020-02-21
ð Original message: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200221/671ebd47/attachment.html>;
ð Original message: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200221/671ebd47/attachment.html>;