From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id F050AC013E for ; Fri, 21 Feb 2020 22:18:08 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by whitealder.osuosl.org (Postfix) with ESMTP id DB22F875C0 for ; Fri, 21 Feb 2020 22:18:08 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from whitealder.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RAAElmeUEk2a for ; Fri, 21 Feb 2020 22:18:07 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-pl1-f179.google.com (mail-pl1-f179.google.com [209.85.214.179]) by whitealder.osuosl.org (Postfix) with ESMTPS id CDB91875E0 for ; Fri, 21 Feb 2020 22:18:07 +0000 (UTC) Received: by mail-pl1-f179.google.com with SMTP id a6so1459765plm.3 for ; Fri, 21 Feb 2020 14:18:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=5BUR0q/Dypt11YmY1zA+fcIa9k598NWvW30k7MhNqqg=; b=R0rSyK6Qmi1EPe26CRx1jPsFE5A59U61Xz7LAF5SnHP/4npqRf5PtlL0PJT6ywoaXZ aOXS5lGW4HhR4gWbzqaReLFCogxQOXaRPIfuZ55spSVAy+ZTuqjY3YupPL7pfm/VY71c hjmMS21GFMQsqEHvUzeGeXdX8V4AKeoHic4ei7wi7WsmyL+MORUOoP7qkVftyiHKegAh /HUjRII90gMGfgLF+ArEhpdYIyAe/WCQiPOz4fVXvTgNikZ+UD6rZo2+Tt+2DQWC4eY8 VBEGnBPgtIu0rT7nJmBcyy5gCBpYMPJRfpfNFm5epc3C1PtA0haD05yCdqG5IYEHT/2Q 8F1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=5BUR0q/Dypt11YmY1zA+fcIa9k598NWvW30k7MhNqqg=; b=YvNzo4bwHXzOB4YHYglUQJrk7iYaX3ZDGTO1f2TPMWRmJNYtCI1o+m3Q2EH5VYNSaC oIhhNkPxA7I685ZieaKJM+KG1yn4U+N4VpajpbB2oAj5vJAe/fkE2dr7JMFo0JBfID8g 8j3YO7/EXNBD/Gb41OOoDygzgNJdxdysNnxzythgTH8uk8uY3PFwjAnsTEazf1WGKhZr HHfCQgjJa3YdIhUi2jpCee6yhflAQtDa+c4gAnDbcj9djxTRVUEW/0BY/dowXJARucTQ Vk2L7M7Vl67l1lcqdY+Ct9VS0ouPPYte4PvLy3yhPoXvyQ6ggpp1/g5GdJnrdJuDmZ9e 8Y1g== X-Gm-Message-State: APjAAAXRmeX+dnbMDwRby1WWBOvFboscfRHgcy771zSyM1iEswKzaDR+ F+Jho9om91WgegolxYTTg7MZGbJrLcfzozk9wLjaUXd1hLY= X-Google-Smtp-Source: APXvYqx67ao9lKK0e+Kr0Lwu25x4p03Vr0x0JWuJz6fzO6HnhyQ1EmvYvbg20+MFK+xA3Oz+8uirrCGaafMlwXb5BXo= X-Received: by 2002:a17:902:82c9:: with SMTP id u9mr38094765plz.264.1582323487060; Fri, 21 Feb 2020 14:18:07 -0800 (PST) MIME-Version: 1.0 From: Antoine Riard Date: Fri, 21 Feb 2020 17:17:54 -0500 Message-ID: To: Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="0000000000005db695059f1d65d7" X-Mailman-Approved-At: Fri, 21 Feb 2020 22:43:06 +0000 Subject: [bitcoin-dev] LN & Coinjoin, a Great Tx Format Wedding X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2020 22:18:09 -0000 --0000000000005db695059f1d65d7 Content-Type: text/plain; charset="UTF-8" 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 --0000000000005db695059f1d65d7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Coinjoins interceptions seem to raise at an increasing pac= e. Their onchain
fingerprint (high-number of inputs/outputs, lack of ant= i-fee snipping, script
type, ...) makes their detection quite easy for a= chain observer. A ban of
coinjoin'ed coins or any other coins linke= d through a common ownwer would
undermine the long-term fungibility of t= he whole ecosystem.

Of course, they do provide privacy for the parti= cipating coins but at the
tradeoffs of creating two observable sets: coi= njoin'ed vs non-coinjoin'ed.
Ideally, all onchain transactions s= hould conform to a common transaction
pattern that provides unobservabil= ity -- i.e a specific transaction would
be indistinguishable from any ot= her 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 c= an a Bitcoin tranaction leak protocol usage ?
* the output type (p2sh, p= 2wsh, ...)
* the spending policy (2-of-3 multisig, timelock, hashlock,..= .)
* outputs ordering (BIP69)
* nLocktime/nSequence
* RBF-signalin= g
* Equal-value outputs
* weird watermark (LN commitment tx obfuscate= d commitment number)
* fees strategy like CPFP
* in-protocol announce= ments [0]

A solution could be to blur multiple protocol onchain tran= sactions 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 deploy= ed by the community and LN specifies
an interactive tx construction prot= ocol [2], the timing would be pretty good
to adopt such format IMO.
<= br>Coinjoin:
* nSequence can be set, it's still secure if party don&= #39;t resign [3]
* nLocktime can be set for anti-fee snipping
* Tapro= ot spending

LN (cooperative case):
* splicing may blur funding/cl= osing as the same thing, closing
address can be a funding output
* sp= lice-in would allow equal value outputs
* nSequence likely to be set for= multi-party tx construction
* nLocktime can be set for anti-fee snippin= g

Adopting a common transaction format isn't a cure-all solution=
on the long-term privacy road but if it circumvent ban of some classof 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 cooperativ= e LN txn ?
* What about RBF-by-default ?
* Core wallet or any other p= rotocol or even batching algorithms could adopt
to this format ?
* Is= artificially increasing the number of outputs to mimic Coinjoins txn
ac= ceptable wrt to utxo bloat/fees ?

Cheers,

Antoine

[0] = Like LN announcing public channels with signatures committing both
to o= nchain utxos and nodes static pubkeys. And them being display on LN
sear= ch 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* fo= rmat.

[2] https://lists.linuxfoundation.org/pip= ermail/lightning-dev/2020-February/002500.html

[3] But "bla= nk" RBF would be a privacy leak if Coinjoin are never bumped,
becau= se if you see both a low-fees and high-fees transaction you now know
the= y are a LN one, so Coinjoins implems should do some time spurious RBFs --0000000000005db695059f1d65d7--