path: root/7e/bdbd22ae31861f5e7ebfb739875796a68b9b8d

Return-Path: <rsomsen@gmail.com>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 7BA86C0176
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 31 May 2020 21:19:39 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by whitealder.osuosl.org (Postfix) with ESMTP id 635AF86849
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 31 May 2020 21:19:39 +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 DIMSlNodhmo9
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 31 May 2020 21:19:38 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-ej1-f42.google.com (mail-ej1-f42.google.com
 [209.85.218.42])
 by whitealder.osuosl.org (Postfix) with ESMTPS id A6DBD86937
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 31 May 2020 21:19:37 +0000 (UTC)
Received: by mail-ej1-f42.google.com with SMTP id gl26so7329929ejb.11
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 31 May 2020 14:19:37 -0700 (PDT)
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=owIloNEDIyP0JQR5thv/Qz1Q0NTgLDOOYkjfv5LvBP8=;
 b=TfcpT4hubzsu3neP6YIeTFNujiCwUzjX9zNeHkfv4CXwQOWZAG+ShcBe2NdV4XlqQd
 Cz9dOTVYVccjcSeAfbtlDJ3H+3sb4iurXk24R1q+ex16nD9DJGHCcTA8B4JzVNRY1sLR
 tcnkv9CYkP3Oxb3/ZZo3xDmdxiL14W70/4uPkyk+ugodjn8pZkArMBEp5U2lztrLg+c0
 FuqlWbwixW4GGD57gg46OT9/BHnhpTBc1UE/s3XYdptED8B3I9u6MMPgokALZdQsCb2j
 5oXDtBqybOAGCt0I6LjTqCtxW4aRS06kDt1fBh8A+z9sX7P7UsrB2uADNfLXBb+vwbyz
 v8rA==
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=owIloNEDIyP0JQR5thv/Qz1Q0NTgLDOOYkjfv5LvBP8=;
 b=bFNt8vx6gMwIQm5AEn2iE6PXGNcwpbYN49IFQBPb73IIExGrxGQaMN8FfZztqkb+lf
 QlbxLCShf09MMcGObDGUmalcLX1hNxV6GlPlYDPd/xx5d1hRFxkZimE/I9N8c/35N5iK
 aQPm+I99jJrwm1vR6ICbzAgu3vvXFsEOUHg8SB1PEmQHAPKCSjq2ZI44gbjh0DUu7QVH
 jhHoV0sRGYtcf/I68BSh45OIkFXd4yIjgqqJbFRj5QHzm/PrHzGhpxG8TPyq452IrK8k
 VXeH3nD4cRya/NORdBGRJ++Qlt7ft5wWtsK+gUED8Tb1qkOYgt1rIy1UhkLXVYyd0OUe
 5eqA==
X-Gm-Message-State: AOAM532r9yqoQ9pp4Malq6ctCPVE367QmtFBmDoDk8tDbwfM60LYqfx5
 dHB6/XzQ/rO01SuLTMpjIyb85+sjfB8UdtlWZjpzIL579+8=
X-Google-Smtp-Source: ABdhPJxuryprVQyMt56wtDEZantUfNvO9BINTC41adAzN//iSwSi4IYHiMm38cViVJrGC4M2AqdlT2lr3AnFSL+Rzfw=
X-Received: by 2002:a17:907:40ed:: with SMTP id
 nn21mr236096ejb.71.1590959975776; 
 Sun, 31 May 2020 14:19:35 -0700 (PDT)
MIME-Version: 1.0
References: <82d90d57-ad07-fc7d-4aca-2b227ac2068d@riseup.net>
 <CAPv7TjY9h8n-nK_CPiYCWYDcbXpT1gfRMQDgf9VUkcR532rxOw@mail.gmail.com>
 <VxL93WE7bDrK1riquTWTTEgJj9mDQ4W5CuhOgdnnDPeidw2ho6evVh4cLZLz0jEYMqejaD1tiLULVTXkNRbI5A7wSwV49qSwnXcTWCDJ96E=@protonmail.com>
In-Reply-To: <VxL93WE7bDrK1riquTWTTEgJj9mDQ4W5CuhOgdnnDPeidw2ho6evVh4cLZLz0jEYMqejaD1tiLULVTXkNRbI5A7wSwV49qSwnXcTWCDJ96E=@protonmail.com>
From: Ruben Somsen <rsomsen@gmail.com>
Date: Sun, 31 May 2020 23:19:22 +0200
Message-ID: <CAPv7TjZn6+j10a_X_vCG3Qn1Fv19uidw50Cf38NNUvp8m+uh2w@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000035445d05a6f83cfe"
X-Mailman-Approved-At: Sun, 31 May 2020 21:19:48 +0000
Subject: Re: [bitcoin-dev] Design for a CoinSwap implementation for
 massively improving Bitcoin privacy and fungibility
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: Sun, 31 May 2020 21:19:39 -0000

--00000000000035445d05a6f83cfe
Content-Type: text/plain; charset="UTF-8"

Hi ZmnSCPxj,

>Just to be clear, you mean we can use the MuSig key-combination protocol
for the non-timelocked SAS output, but (of course) not the signing protocol
which is inherently Schnorr. Then knowledge of both of the original private
keys is enough to derive the single combined private key.

That's correct.

>basically private key handover gets us PayJoin for free

That assumes there will be a second transaction. With SAS I believe we can
avoid that, and make it look like this:

             +---+
    Alice ---|   |--- Bob
    Alice ---|   |
      Bob ---|   |
             +---+

This is basically what I was trying to explain in my previous email: "I
believe PayJoin can also be applied to the non-timelocked side. This does
require adding a transaction that undoes the PayJoin in case the swap gets
aborted, which means MuSig can't be used. Everything else stays the same:
only one tx if successful, and no timelock (= instant settlement)"

I don't have a strong opinion on whether it is actually useful to combine
CoinSwap with PayJoin.

>A thing I have been trying to work out is whether SAS can be done with
more than one participant, like in S6

S6 requires timelocks for each output in order to function, so I doubt it
can be made to work with SAS.

I've also tried applying SAS to partially blind swaps and ran into
likability issues, though it's less clear to me whether there is some
fundamental reason why it couldn't work there.

Cheers,
Ruben

On Sun, May 31, 2020 at 4:31 AM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:

> Good morning Ruben and Chris,
>
> > >For a much greater anonymity set we can use 2-party ECDSA to create
> 2-of-2 multisignature addresses that look the same as regular
> single-signature addresses
> >
> > This may perhaps be counter-intuitive, but SAS doesn't actually require
> multisig for one of the two outputs, so a single key will suffice. ECDSA is
> a signing algorithm that doesn't support single key multisig (at least not
> without 2p-ECDSA), but notice how for the non-timelocked SAS output we
> never actually have to sign anything together with the other party. We swap
> one of the two keys, and the final owner will create a signature completely
> on their own. No multisig required, which means we can simply use MuSig,
> even today without Schnorr.
>
> Just to be clear, you mean we can use the MuSig key-combination protocol
> for the non-timelocked SAS output, but (of course) not the signing protocol
> which is inherently Schnorr.
>
> Then knowledge of both of the original private keys is enough to derive
> the single combined private key.
>
> > Of course the other output will still have to be a 2-of-2, for which you
> rightly note 2p-ECDSA could be considered. It may also be interesting to
> combine a swap with the opening of a Lightning channel. E.g. Alice and Bob
> want to open a channel with 1 BTC each, but Alice funds it in her entirety
> with 2 BTC, and Bob gives 1 BTC to Alice in a swap. This makes it difficult
> to tell Bob entered the Lightning Network, especially if the channel is
> opened in a state that isn't perfectly balanced. And Alice will gain an
> uncorrelated single key output.
>
> Dual-funding could be done by a single-funding Lightning open followed by
> an onchain-to-offchain swap.
> Though the onchain swap would have to be done, at least currently, with
> hashes.
>
> > >=== PayJoin with CoinSwap ===
> >
> > While it's probably clear how to do it on the timelocked side of SAS, I
> believe PayJoin can also be applied to the non-timelocked side. This does
> require adding a transaction that undoes the PayJoin in case the swap gets
> aborted, which means MuSig can't be used. Everything else stays the same:
> only one tx if successful, and no timelock (= instant settlement). I can
> explain it in detail, if it happens to catch your interest.
>
> I am not in fact convinced that PayJoin-with-CoinSwap adds *that* much
> privacy.
>
> These transactions:
>
>              +---+  +---+
>     Alice ---|   |--|   |--- Bob
>     Alice ---|   |  |   |
>       Bob ---|   |  +---+
>              +---+
>
> Are not really much different in coin ownership analysis from these:
>
>              +---+    +---+
>     Alice ---|   |----|   |--- Bob
>     Alice ---|   | +--|   |
>              +---+ |  +---+
>       Bob ---------+
>
> The latter is possible due to private key handover, the intermediate
> output becomes owned solely by Bob and Bob can add many more inputs to that
> second transaction unilaterally for even greater confusion to chain
> analysis, basically private key handover gets us PayJoin for free.
> It also removes the need for Bob to reveal additional UTXOs to Alice
> during the swap protocol; yes PoDLE mitigates the privacy probing attack
> that Alice can mount on Bob, but it is helpful to remember this is "only" a
> mitigation.
>
> Now of course things are different if Alice is paying some exact amount to
> Carol, and Alice wants to dissociate her funds from the payment.
> The difference is then:
>
>              +---+    +---+
>     Alice ---|   |----|   |--- Bob
>     Alice ---|   |--+ |   |
>       Bob ---|   |  | +---+
>              +---+  +--------- Alice Change
>
>              +---+    +---+
>       Bob ---|   |----|   |--- Carol
>              |   |--+ +---+
>              +---+  |
>                     +--------- Bob Change
>
> Versus:
>
>              +---+    +---+
>     Alice ---|   |----|   |--- Bob
>     Alice ---|   | +--|   |
>              +---+ |  +---+
>       Bob ---------+
>
>              +---+    +---+
>       Bob ---|   |----|   |--- Carol
>              |   |--+ |   |--- Alice Change
>              +---+  | +---+
>                     +--------- Bob Change
>
> In the above, with PayJoin on the first-layer transaction, the Alice
> Change is correlated with Alice and Bob inputs, whereas with the PayJoin on
> the second the Alice change is correlated with Bob inputs and Carol outputs.
>
> But if Alice, using commodity CoinSwap wallets, always has a policy that
> all sends are via CoinSwap (a reasonable policy, similar to the policy in
> JoinMarket of ensuring that all spends out of the wallet are via CoinJoin),
> then the above two trees are not much different for Alice in practice.
> The Alice Change will be swapped with some other maker anyway when it gets
> spent, so what it correlates with will not be much of a problem for Alice.
> At the same time, with PayJoin on the second-layer transaction (possible
> due to private key turnover, which is an inherent part of the SAS protocol):
>
> * Bob does not have to reveal any other coins it owns to Alice other than
> what it is directly swapping, removing a privacy probe vector.
> * Bob can unilaterally combine more than one input to the second
> transaction going to Bob, which further increases the uncertainty of
> clustering around the inputs from Alice than just adding *one* input.
>
> ---
>
> A thing I have been trying to work out is whether SAS can be done with
> more than one participant, like in [S6](
> https://joinmarket.me/blog/blog/multiparty-s6/).
>
> So far, I have not figured out a way to make it multiparty (multihop?).
> Because the secret being transported is a private key that protects a
> specific UTXO, it seems it is not possible to safely use the same secret
> across more than two parties.
> Perhaps others have come ideas?
>
> Regards,
> ZmnSCPxj
>

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

<div dir=3D"ltr">Hi=C2=A0ZmnSCPxj,<div><br></div><div>&gt;Just to be clear,=
 you mean we can use the MuSig key-combination protocol for the non-timeloc=
ked SAS output, but (of course) not the signing protocol which is inherentl=
y Schnorr. Then knowledge of both of the original private keys is enough to=
 derive the single combined private key.<br></div><div><br></div><div>That&=
#39;s correct.</div><div><br></div><div>&gt;basically private key handover =
gets us PayJoin for free</div><div><br></div><div>That assumes there will b=
e a second transaction. With SAS I believe we can avoid that, and make it l=
ook like this:</div><div><br></div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0+---+<br>=C2=A0 =C2=A0 Alice ---| =C2=A0 |--- Bob<br>=C2=A0 =
=C2=A0 Alice ---| =C2=A0 |<br>=C2=A0 =C2=A0 =C2=A0 Bob ---| =C2=A0 |<br>=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+---+<br></div><div><br></div>=
<div>This is basically what I was trying to explain in my previous email: &=
quot;I believe PayJoin can also be applied to the non-timelocked side. This=
 does require adding a transaction that undoes the PayJoin in case the swap=
 gets aborted, which means MuSig can&#39;t be used. Everything else stays t=
he same: only one tx if successful, and no timelock (=3D instant settlement=
)&quot;</div><div><br></div><div>I don&#39;t have a strong opinion on wheth=
er it is actually useful to combine CoinSwap with PayJoin.</div><div><br></=
div><div>&gt;A thing I have been trying to work out is whether SAS can be d=
one with more than one participant, like in S6<br></div><div><br></div><div=
>S6 requires timelocks for each output in order to function, so I doubt it =
can be made to work with SAS.</div><div><br></div><div>I&#39;ve also tried =
applying SAS to partially blind swaps and ran into likability issues, thoug=
h it&#39;s less clear to me whether there is some fundamental reason why it=
 couldn&#39;t work there.</div><div><br></div><div>Cheers,</div><div>Ruben<=
/div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_a=
ttr">On Sun, May 31, 2020 at 4:31 AM ZmnSCPxj &lt;<a href=3D"mailto:ZmnSCPx=
j@protonmail.com">ZmnSCPxj@protonmail.com</a>&gt; wrote:<br></div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px =
solid rgb(204,204,204);padding-left:1ex">Good morning Ruben and Chris,<br>
<br>
&gt; &gt;For a much greater anonymity set we can use 2-party ECDSA to creat=
e 2-of-2 multisignature addresses that look the same as regular single-sign=
ature addresses<br>
&gt;<br>
&gt; This may perhaps be counter-intuitive, but SAS doesn&#39;t actually re=
quire multisig for one of the two outputs, so a single key will suffice. EC=
DSA is a signing algorithm that doesn&#39;t support single key multisig (at=
 least not without 2p-ECDSA), but notice how for the non-timelocked SAS out=
put we never actually have to sign anything together with the other party. =
We swap one of the two keys, and the final owner will create a signature co=
mpletely on their own. No multisig required, which means we can simply use =
MuSig, even today without Schnorr.<br>
<br>
Just to be clear, you mean we can use the MuSig key-combination protocol fo=
r the non-timelocked SAS output, but (of course) not the signing protocol w=
hich is inherently Schnorr.<br>
<br>
Then knowledge of both of the original private keys is enough to derive the=
 single combined private key.<br>
<br>
&gt; Of course the other output will still have to be a 2-of-2, for which y=
ou rightly note 2p-ECDSA could be considered. It may also be interesting to=
 combine a swap with the opening of a Lightning channel. E.g. Alice and Bob=
 want to open a channel with 1 BTC each, but Alice funds it in her entirety=
 with 2 BTC, and Bob gives 1 BTC to Alice in a swap. This makes it difficul=
t to tell Bob entered the Lightning Network, especially if the channel is o=
pened in a state that isn&#39;t perfectly balanced. And Alice will gain an =
uncorrelated single key output.<br>
<br>
Dual-funding could be done by a single-funding Lightning open followed by a=
n onchain-to-offchain swap.<br>
Though the onchain swap would have to be done, at least currently, with has=
hes.<br>
<br>
&gt; &gt;=3D=3D=3D PayJoin with CoinSwap =3D=3D=3D<br>
&gt;<br>
&gt; While it&#39;s probably clear how to do it on the timelocked side of S=
AS, I believe PayJoin can also be applied to the non-timelocked side. This =
does require adding a transaction that undoes the PayJoin in case the swap =
gets aborted, which means MuSig can&#39;t be used. Everything else stays th=
e same: only one tx if successful, and no timelock (=3D instant settlement)=
. I can explain it in detail, if it happens to catch your interest.<br>
<br>
I am not in fact convinced that PayJoin-with-CoinSwap adds *that* much priv=
acy.<br>
<br>
These transactions:<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+---+=C2=A0 +---+<br>
=C2=A0 =C2=A0 Alice ---|=C2=A0 =C2=A0|--|=C2=A0 =C2=A0|--- Bob<br>
=C2=A0 =C2=A0 Alice ---|=C2=A0 =C2=A0|=C2=A0 |=C2=A0 =C2=A0|<br>
=C2=A0 =C2=A0 =C2=A0 Bob ---|=C2=A0 =C2=A0|=C2=A0 +---+<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+---+<br>
<br>
Are not really much different in coin ownership analysis from these:<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+---+=C2=A0 =C2=A0 +---+<br=
>
=C2=A0 =C2=A0 Alice ---|=C2=A0 =C2=A0|----|=C2=A0 =C2=A0|--- Bob<br>
=C2=A0 =C2=A0 Alice ---|=C2=A0 =C2=A0| +--|=C2=A0 =C2=A0|<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+---+ |=C2=A0 +---+<br>
=C2=A0 =C2=A0 =C2=A0 Bob ---------+<br>
<br>
The latter is possible due to private key handover, the intermediate output=
 becomes owned solely by Bob and Bob can add many more inputs to that secon=
d transaction unilaterally for even greater confusion to chain analysis, ba=
sically private key handover gets us PayJoin for free.<br>
It also removes the need for Bob to reveal additional UTXOs to Alice during=
 the swap protocol; yes PoDLE mitigates the privacy probing attack that Ali=
ce can mount on Bob, but it is helpful to remember this is &quot;only&quot;=
 a mitigation.<br>
<br>
Now of course things are different if Alice is paying some exact amount to =
Carol, and Alice wants to dissociate her funds from the payment.<br>
The difference is then:<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+---+=C2=A0 =C2=A0 +---+<br=
>
=C2=A0 =C2=A0 Alice ---|=C2=A0 =C2=A0|----|=C2=A0 =C2=A0|--- Bob<br>
=C2=A0 =C2=A0 Alice ---|=C2=A0 =C2=A0|--+ |=C2=A0 =C2=A0|<br>
=C2=A0 =C2=A0 =C2=A0 Bob ---|=C2=A0 =C2=A0|=C2=A0 | +---+<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+---+=C2=A0 +--------- Alic=
e Change<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+---+=C2=A0 =C2=A0 +---+<br=
>
=C2=A0 =C2=A0 =C2=A0 Bob ---|=C2=A0 =C2=A0|----|=C2=A0 =C2=A0|--- Carol<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0|--+ +---+<br=
>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+---+=C2=A0 |<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +----=
----- Bob Change<br>
<br>
Versus:<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+---+=C2=A0 =C2=A0 +---+<br=
>
=C2=A0 =C2=A0 Alice ---|=C2=A0 =C2=A0|----|=C2=A0 =C2=A0|--- Bob<br>
=C2=A0 =C2=A0 Alice ---|=C2=A0 =C2=A0| +--|=C2=A0 =C2=A0|<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+---+ |=C2=A0 +---+<br>
=C2=A0 =C2=A0 =C2=A0 Bob ---------+<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+---+=C2=A0 =C2=A0 +---+<br=
>
=C2=A0 =C2=A0 =C2=A0 Bob ---|=C2=A0 =C2=A0|----|=C2=A0 =C2=A0|--- Carol<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0|--+ |=C2=A0 =
=C2=A0|--- Alice Change<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+---+=C2=A0 | +---+<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +----=
----- Bob Change<br>
<br>
In the above, with PayJoin on the first-layer transaction, the Alice Change=
 is correlated with Alice and Bob inputs, whereas with the PayJoin on the s=
econd the Alice change is correlated with Bob inputs and Carol outputs.<br>
<br>
But if Alice, using commodity CoinSwap wallets, always has a policy that al=
l sends are via CoinSwap (a reasonable policy, similar to the policy in Joi=
nMarket of ensuring that all spends out of the wallet are via CoinJoin), th=
en the above two trees are not much different for Alice in practice.<br>
The Alice Change will be swapped with some other maker anyway when it gets =
spent, so what it correlates with will not be much of a problem for Alice.<=
br>
At the same time, with PayJoin on the second-layer transaction (possible du=
e to private key turnover, which is an inherent part of the SAS protocol):<=
br>
<br>
* Bob does not have to reveal any other coins it owns to Alice other than w=
hat it is directly swapping, removing a privacy probe vector.<br>
* Bob can unilaterally combine more than one input to the second transactio=
n going to Bob, which further increases the uncertainty of clustering aroun=
d the inputs from Alice than just adding *one* input.<br>
<br>
---<br>
<br>
A thing I have been trying to work out is whether SAS can be done with more=
 than one participant, like in [S6](<a href=3D"https://joinmarket.me/blog/b=
log/multiparty-s6/" rel=3D"noreferrer" target=3D"_blank">https://joinmarket=
.me/blog/blog/multiparty-s6/</a>).<br>
<br>
So far, I have not figured out a way to make it multiparty (multihop?).<br>
Because the secret being transported is a private key that protects a speci=
fic UTXO, it seems it is not possible to safely use the same secret across =
more than two parties.<br>
Perhaps others have come ideas?<br>
<br>
Regards,<br>
ZmnSCPxj<br>
</blockquote></div>

--00000000000035445d05a6f83cfe--