From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 8D383C0177 for ; 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 ; 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 ; 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 ; Mon, 24 Feb 2020 17:58:14 +0000 (UTC) Received: by mail-pf1-f175.google.com with SMTP id 84so5735965pfy.6 for ; 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: In-Reply-To: From: Antoine Riard Date: Mon, 24 Feb 2020 12:58:02 -0500 Message-ID: To: AdamISZ Content-Type: multipart/alternative; boundary="0000000000007a46a9059f561d11" X-Mailman-Approved-At: Mon, 24 Feb 2020 18:19:05 +0000 Cc: Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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
> Another one, usually wo= uldn'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).

Yes sure that'= ;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.
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...

> Bu= t 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 nu= mber of outputs so I don't see it followed by any other protocol. But y= es CoinjoinXT, if you can come up with a easy interactive
multi-t= x construction protocol that would be interesting (and could be reused by a= ny cut-through implementation I guess).

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't
have to wait another period to start enjoying = the privacy enhancement (worst-case we can fallback on 2p-ecdsa).
<= div>



Le=C2=A0sam. 22 f=C3=A9vr. 20= 20 =C3=A0=C2=A007:10, AdamISZ <AdamISZ@protonmail.com> a =C3=A9crit=C2=A0:
=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 <bitcoi= n-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 broad= er), 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 are= a.
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).

waxwing

[1] https://joinmarket.me/blog/blog/coinjoinxt/
--0000000000007a46a9059f561d11--