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"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] LN & Coinjoin, a Great Tx Format Wedding
Precedence: list

--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--