path: root/2b/2096cb2c9daee50495594665fa833975d04a09

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 8D383C0177
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 24 Feb 2020 17:58:15 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by whitealder.osuosl.org (Postfix) with ESMTP id 7BDD386019
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 24 Feb 2020 17:58:15 +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 5F0dj4OtgQ1w
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 24 Feb 2020 17:58:14 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-pf1-f175.google.com (mail-pf1-f175.google.com
 [209.85.210.175])
 by whitealder.osuosl.org (Postfix) with ESMTPS id 8F05285FAC
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 24 Feb 2020 17:58:14 +0000 (UTC)
Received: by mail-pf1-f175.google.com with SMTP id 84so5735965pfy.6
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 24 Feb 2020 09:58:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=KDM36vR4jcyxCoI/q/HFw8edBgfIaqkVQY3khQ6S3sA=;
 b=GQkwyawUL0FkwYNFFSDXHeUt2OO/myA83Qu+GajG8cy7yr6/3Hd8cghqcQw4hTwdim
 SOkBdz7ISUJgEDb4VNUQfvxvBrtg5HujXwwnax9BNhaASe5dqJ9JxiD4bypDThJkTIn5
 cPkvcpKtb5PflT8GL6QjHVdqxgon1n1T6PHrKavTK2jULwHYaXyjPoMcspKhBFKZt51+
 eRHFTfRsFfn/XRpBMjs7USFFeI6Ouy3OspKpshiHOns0zkDtDdWymQV8/jEbndyJtFaA
 z7nkg/3w3wHJ6ft4/jn9dSXO7u0p6bdmFZ9lUbfl26f675xNuTFoJ/bAVpBe1qn2cF/I
 kuLg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=KDM36vR4jcyxCoI/q/HFw8edBgfIaqkVQY3khQ6S3sA=;
 b=BmuMwQqiyTVcvfGH8r7e3NRtk/pG584oH5QxzkOr47GFOf4cxM9ai81IDtVEtY/wjW
 OM9IUVU3eAYOUrIIWRWyzO0e2OOaq8fQV4nBfFCOU3D63dM46GMTvV1Jfpdf3OM9FXpC
 L6JTiDCJGMbjblb7hk8rAU8ZuYD+C5NdKX23CQ14B1UAFyRyJ34op3O1Uh4k3WFlAaJl
 dUNf9L7CYvmFQLFfRWpZUyJa8S45qz4S+pc/VIDLJprLpUUWADwk+pAvNq5kBrM9AQcm
 uKLBes4Ept0sLmkrOgkdoUM1xE/ohoZQdxUiArxQ9M54AaBfh7BE1mvoxUL/kY8m/FDW
 WLZg==
X-Gm-Message-State: APjAAAUSCw0cmCyVyTN1kmWV9+9ak447mjxeKe6XZH6t9P5/EXpCmpL1
 unyaoHH4lkSRSXLlsMbfTAg5/3esaWKPUHBXz5s=
X-Google-Smtp-Source: APXvYqxOg6TDgjDxXawwK0Ycosp5PaW9a/FH9Faalf4T/JYMenLRsqiIkTcJm04Me9iO5pptj6KaSsQjf6TwhiaGEC4=
X-Received: by 2002:a63:8342:: with SMTP id h63mr17134458pge.141.1582567094107; 
 Mon, 24 Feb 2020 09:58:14 -0800 (PST)
MIME-Version: 1.0
References: <CALZpt+E4Mr=g8zw95tyteGh53DH1mZ2HhNzQdy92+ErTtx3VbQ@mail.gmail.com>
 <L95umnyb-GwoyP_ZWM7oNmMbhooYpCFXoKAGRPoPOpGpMGhMHQWuczKhJ2VX2nrZt3jaJ5bOMy5dvQ3DYqs_O_eEsA_63dd2_rvdoOzoGoI=@protonmail.com>
In-Reply-To: <L95umnyb-GwoyP_ZWM7oNmMbhooYpCFXoKAGRPoPOpGpMGhMHQWuczKhJ2VX2nrZt3jaJ5bOMy5dvQ3DYqs_O_eEsA_63dd2_rvdoOzoGoI=@protonmail.com>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Mon, 24 Feb 2020 12:58:02 -0500
Message-ID: <CALZpt+FbWc8FnwW+gZ0eEJU6xT39=GnUbv4f2RupKJT4xjCN0w@mail.gmail.com>
To: AdamISZ <AdamISZ@protonmail.com>
Content-Type: multipart/alternative; boundary="0000000000007a46a9059f561d11"
X-Mailman-Approved-At: Mon, 24 Feb 2020 18:19:05 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [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: Mon, 24 Feb 2020 17:58:15 -0000

--0000000000007a46a9059f561d11
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

> Another one, usually wouldn't be *protocol* as much as wallet leakage,
but could be: utxo selection algorithm (which of course may be difficult to
deduce, but often, far from impossible).

Yes sure that's a good point, it may affect protocol too if your LN
implementation has its own onchain wallet. If not, and it reuses a non-LN
wallet you just carry on its fingerprint.
An extension in the future could be for closing/splicing transaction, your
liquidity algorithm may select in a really specific fashion which channels
must be closed or increased...

> But I would ask people to consider CoinJoinXT[1] more seriously in a
taproot/schnorr world, since it addresses this exact point.

The equal value paradigm is such a watermark and I assume it leans to
increase the number of outputs so I don't see it followed by any other
protocol. But yes CoinjoinXT, if you can come up with a easy interactive
multi-tx construction protocol that would be interesting (and could be
reused by any cut-through implementation I guess).

Overall, my thinking was to start specifying this now because such thing
would take a fair amount of time/coordination to get adopted. This way if
and when Taproot/Schnorr happen we don't
have to wait another period to start enjoying the privacy enhancement
(worst-case we can fallback on 2p-ecdsa).



Le sam. 22 f=C3=A9vr. 2020 =C3=A0 07:10, AdamISZ <AdamISZ@protonmail.com> a=
 =C3=A9crit :

> =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original =
Message =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90
> On Friday, 21 February 2020 22:17, Antoine Riard via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> > 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]
> >
> Good list.
> Another one, usually wouldn't be *protocol* as much as wallet leakage, bu=
t
> could be: utxo selection algorithm (which of course may be difficult to
> deduce, but often, far from impossible).
> (Also trivial and increasingly irrelevant, but nVersion).
>
> With regards to coinjoin in this context (I know your points are much
> broader), my comment is:
> For existing protocols (joinmarket's, wasabi's, samourai's), in the
> equal-outs paradigm, I don't see much that can be done in this area.
> But I would ask people to consider CoinJoinXT[1] more seriously in a
> taproot/schnorr world, since it addresses this exact point. With a short
> (not cross-block like swaps or LN setup) interaction, participants can
> arrange the effect of coinjoin without the on-chain watermark of coinjoin
> (so, steganographic). The taproot/schnorr part is needed there because
> multisig is required from transaction to transaction in that protocol, so
> doing it today is less interesting (albeit still interesting).
>
> waxwing
>
> [1] https://joinmarket.me/blog/blog/coinjoinxt/
>

--0000000000007a46a9059f561d11
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div><div><div><div>&gt; Another one, usually wo=
uldn&#39;t be *protocol* as much as wallet leakage,=20
but could be: utxo selection algorithm (which of course may be difficult
 to deduce, but often, far from impossible).<br><br></div>Yes sure that&#39=
;s a good point, it may affect protocol too if your LN implementation has i=
ts own onchain wallet. If not, and it reuses a non-LN wallet you just carry=
 on its fingerprint.<br></div>An extension in the future could be for closi=
ng/splicing transaction, your liquidity algorithm may select in a really sp=
ecific fashion which channels must be closed or increased...<br><br>&gt; Bu=
t I would ask people to consider CoinJoinXT[1] more seriously in a taproot/=
schnorr world, since it addresses this exact point.<br><br></div>The equal =
value paradigm is such a watermark and I assume it leans to increase the nu=
mber of outputs so I don&#39;t see it followed by any other protocol. But y=
es CoinjoinXT, if you can come up with a easy interactive <br></div>multi-t=
x construction protocol that would be interesting (and could be reused by a=
ny cut-through implementation I guess).<br><br></div>Overall, my thinking w=
as to start specifying this now because such thing would take a fair amount=
 of time/coordination to get adopted. This way if and when Taproot/Schnorr =
happen we don&#39;t<br></div>have to wait another period to start enjoying =
the privacy enhancement (worst-case we can fallback on 2p-ecdsa).<br><div><=
div><div><br><div><br></div></div></div></div></div><br><div class=3D"gmail=
_quote"><div dir=3D"ltr" class=3D"gmail_attr">Le=C2=A0sam. 22 f=C3=A9vr. 20=
20 =C3=A0=C2=A007:10, AdamISZ &lt;<a href=3D"mailto:AdamISZ@protonmail.com"=
>AdamISZ@protonmail.com</a>&gt; a =C3=A9crit=C2=A0:<br></div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid=
 rgb(204,204,204);padding-left:1ex">=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=
=80=90=E2=80=90=E2=80=90 Original Message =E2=80=90=E2=80=90=E2=80=90=E2=80=
=90=E2=80=90=E2=80=90=E2=80=90<br>
On Friday, 21 February 2020 22:17, Antoine Riard via bitcoin-dev &lt;<a hre=
f=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoi=
n-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>
<br>
&gt; How can a Bitcoin tranaction leak protocol usage ?<br>
&gt; * the output type (p2sh, p2wsh, ...)<br>
&gt; * the spending policy (2-of-3 multisig, timelock, hashlock,...)<br>
&gt; * outputs ordering (BIP69)<br>
&gt; * nLocktime/nSequence<br>
&gt; * RBF-signaling<br>
&gt; * Equal-value outputs<br>
&gt; * weird watermark (LN commitment tx obfuscated commitment number)<br>
&gt; * fees strategy like CPFP<br>
&gt; * in-protocol announcements [0]<br>
&gt;<br>
Good list.<br>
Another one, usually wouldn&#39;t be *protocol* as much as wallet leakage, =
but could be: utxo selection algorithm (which of course may be difficult to=
 deduce, but often, far from impossible).<br>
(Also trivial and increasingly irrelevant, but nVersion).<br>
<br>
With regards to coinjoin in this context (I know your points are much broad=
er), my comment is:<br>
For existing protocols (joinmarket&#39;s, wasabi&#39;s, samourai&#39;s), in=
 the equal-outs paradigm, I don&#39;t see much that can be done in this are=
a.<br>
But I would ask people to consider CoinJoinXT[1] more seriously in a taproo=
t/schnorr world, since it addresses this exact point. With a short (not cro=
ss-block like swaps or LN setup) interaction, participants can arrange the =
effect of coinjoin without the on-chain watermark of coinjoin (so, steganog=
raphic). The taproot/schnorr part is needed there because multisig is requi=
red from transaction to transaction in that protocol, so doing it today is =
less interesting (albeit still interesting).<br>
<br>
waxwing<br>
<br>
[1] <a href=3D"https://joinmarket.me/blog/blog/coinjoinxt/" rel=3D"noreferr=
er" target=3D"_blank">https://joinmarket.me/blog/blog/coinjoinxt/</a><br>
</blockquote></div>

--0000000000007a46a9059f561d11--