public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Antoine Riard <antoine.riard@gmail.com>
To: AdamISZ <AdamISZ@protonmail.com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] LN & Coinjoin, a Great Tx Format Wedding
Date: Mon, 24 Feb 2020 12:58:02 -0500	[thread overview]
Message-ID: <CALZpt+FbWc8FnwW+gZ0eEJU6xT39=GnUbv4f2RupKJT4xjCN0w@mail.gmail.com> (raw)
In-Reply-To: <L95umnyb-GwoyP_ZWM7oNmMbhooYpCFXoKAGRPoPOpGpMGhMHQWuczKhJ2VX2nrZt3jaJ5bOMy5dvQ3DYqs_O_eEsA_63dd2_rvdoOzoGoI=@protonmail.com>

[-- Attachment #1: Type: text/plain, Size: 3147 bytes --]

> 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évr. 2020 à 07:10, AdamISZ <AdamISZ@protonmail.com> a écrit :

> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> 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
> 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/
>

[-- Attachment #2: Type: text/html, Size: 3824 bytes --]

  parent reply	other threads:[~2020-02-24 17:58 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-21 22:17 [bitcoin-dev] LN & Coinjoin, a Great Tx Format Wedding Antoine Riard
2020-02-22 12:10 ` AdamISZ
2020-02-23  0:59   ` ZmnSCPxj
2020-02-24 17:58   ` Antoine Riard [this message]
2020-02-23  1:29 ` ZmnSCPxj
2020-02-24 18:26   ` Antoine Riard
2020-02-24 23:35     ` ZmnSCPxj
2020-02-25 19:16       ` Antoine Riard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CALZpt+FbWc8FnwW+gZ0eEJU6xT39=GnUbv4f2RupKJT4xjCN0w@mail.gmail.com' \
    --to=antoine.riard@gmail.com \
    --cc=AdamISZ@protonmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox