Date: Sun, 23 Feb 2020 00:59:46 +0000
To: AdamISZ <AdamISZ@protonmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <x7A06kB4r0DzPTeDDWWouWLXT5_5YRaHax76XP_ToY0aUAPHXVt8Wuvf3RRpFpguIFD53Ho_KQM4WYEkFl6ZZlVw6KIk-GP5izmGDVppfvA=@protonmail.com>
In-Reply-To: <L95umnyb-GwoyP_ZWM7oNmMbhooYpCFXoKAGRPoPOpGpMGhMHQWuczKhJ2VX2nrZt3jaJ5bOMy5dvQ3DYqs_O_eEsA_63dd2_rvdoOzoGoI=@protonmail.com>
References: <CALZpt+E4Mr=g8zw95tyteGh53DH1mZ2HhNzQdy92+ErTtx3VbQ@mail.gmail.com>
 <L95umnyb-GwoyP_ZWM7oNmMbhooYpCFXoKAGRPoPOpGpMGhMHQWuczKhJ2VX2nrZt3jaJ5bOMy5dvQ3DYqs_O_eEsA_63dd2_rvdoOzoGoI=@protonmail.com>
Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] LN & Coinjoin, a Great Tx Format Wedding
Precedence: list

Good morning waxwing,

> =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, but =
could be: utxo selection algorithm (which of course may be difficult to ded=
uce, 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 bro=
ader), 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 tapr=
oot/schnorr world, since it addresses this exact point. With a short (not c=
ross-block like swaps or LN setup) interaction, participants can arrange th=
e effect of coinjoin without the on-chain watermark of coinjoin (so, stegan=
ographic). The taproot/schnorr part is needed there because multisig is req=
uired from transaction to transaction in that protocol, so doing it today i=
s less interesting (albeit still interesting).

CoinJoinXT is indeed something I am interested in at some point: https://zm=
nscpxj.github.io/bitcoin/coinjoinxt.html
The above writeup is a client-server model, with multiple clients mixing.
If none of the participants reveal that a CoinJoinXT was done, then the gra=
ph is difficult to detect as such.
However, if any participants reveal that a CoinJoinXT was done, it has a fa=
llback such that it is almost as good as an equal-value CoinJoin (but takes=
 up more block space).
At least it is not immediately obvious that it is in fact a CoinJoinXT from=
 *just* a simple transaction analysis, which we hope is enough to deter sim=
ple policies like "check N transactions back for a transaction with more th=
an one equal-valued output".

Regards,
ZmnSCPxj