path: root/bc/887958a7c8dd531afa2e93f473039fe2a243b4

Return-Path: <antoine.riard@gmail.com>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id F050AC013E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 21 Feb 2020 22:18:07 +0000 (UTC)
Received: by mail-pl1-f179.google.com with SMTP id a6so1459765plm.3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <antoine.riard@gmail.com>
Date: Fri, 21 Feb 2020 17:17:54 -0500
Message-ID: <CALZpt+E4Mr=g8zw95tyteGh53DH1mZ2HhNzQdy92+ErTtx3VbQ@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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

<div dir=3D"ltr">Coinjoins interceptions seem to raise at an increasing pac=
e. Their onchain<br>fingerprint (high-number of inputs/outputs, lack of ant=
i-fee snipping, script<br>type, ...) makes their detection quite easy for a=
 chain observer. A ban of<br>coinjoin&#39;ed coins or any other coins linke=
d through a common ownwer would<br>undermine the long-term fungibility of t=
he whole ecosystem.<br><br>Of course, they do provide privacy for the parti=
cipating coins but at the<br>tradeoffs of creating two observable sets: coi=
njoin&#39;ed vs non-coinjoin&#39;ed.<br>Ideally, all onchain transactions s=
hould conform to a common transaction<br>pattern that provides unobservabil=
ity -- i.e a specific transaction would<br>be indistinguishable from any ot=
her transaction at all. For LN or Coinjoin<br>it means an external observer=
, not-involved in the protocol, should be<br>unable to tell which protocol =
is being used, or if _any_ specific protocol<br>is being used.<br><br>How c=
an a Bitcoin tranaction leak protocol usage ?<br>* the output type (p2sh, p=
2wsh, ...)<br>* the spending policy (2-of-3 multisig, timelock, hashlock,..=
.)<br>* outputs ordering (BIP69)<br>* nLocktime/nSequence<br>* RBF-signalin=
g<br>* Equal-value outputs<br>* weird watermark (LN commitment tx obfuscate=
d commitment number)<br>* fees strategy like CPFP<br>* in-protocol announce=
ments [0]<br><br>A solution could be to blur multiple protocol onchain tran=
sactions into<br>one common transaction format [1]. For example, if one of =
them uses nSequence<br>for some protocol semantic all the other ones should=
 do it too. Any deviation<br>would be enough to be leverage as a watermark =
and blow up all other tweaks.<br>If Schnorr-Taproot gets adopted and deploy=
ed by the community and LN specifies<br>an interactive tx construction prot=
ocol [2], the timing would be pretty good<br>to adopt such format IMO.<br><=
br>Coinjoin:<br>* nSequence can be set, it&#39;s still secure if party don&=
#39;t resign [3]<br>* nLocktime can be set for anti-fee snipping<br>* Tapro=
ot spending<br><br>LN (cooperative case):<br>* splicing may blur funding/cl=
osing as the same thing, closing<br>address can be a funding output<br>* sp=
lice-in would allow equal value outputs<br>* nSequence likely to be set for=
 multi-party tx construction<br>* nLocktime can be set for anti-fee snippin=
g<br><br>Adopting a common transaction format isn&#39;t a cure-all solution=
<br>on the long-term privacy road but if it circumvent ban of some class<br=
>of transactions that would be already a nice win and a worthy effort<br>to=
 do so.<br><br>Questions:<br>* Are there any protocol-specific semantic wrt=
 to onchain transactions incompatibility<br>between Coinjoin and cooperativ=
e LN txn ?<br>* What about RBF-by-default ?<br>* Core wallet or any other p=
rotocol or even batching algorithms could adopt<br>to this format ?<br>* Is=
 artificially increasing the number of outputs to mimic Coinjoins txn<br>ac=
ceptable wrt to utxo bloat/fees ?<br><br>Cheers,<br><br>Antoine<br><br>[0] =
Like LN announcing public channels with signatures committing both <br>to o=
nchain utxos and nodes static pubkeys. And them being display on LN<br>sear=
ch engines with full owner info...<br><br>[1] By format, I don&#39;t mean a=
 *binary* format a la PSBT but mere something<br>like BOLT3, a *logical* fo=
rmat.<br><br>[2] <a href=3D"https://lists.linuxfoundation.org/pipermail/lig=
htning-dev/2020-February/002500.html">https://lists.linuxfoundation.org/pip=
ermail/lightning-dev/2020-February/002500.html</a><br><br>[3] But &quot;bla=
nk&quot; RBF would be a privacy leak if Coinjoin are never bumped,<br>becau=
se if you see both a low-fees and high-fees transaction you now know<br>the=
y are a LN one, so Coinjoins implems should do some time spurious RBFs</div=
>

--0000000000005db695059f1d65d7--