Date: Thu, 23 Apr 2020 17:56:08 +0000
To: German Luna <german@diviproject.org>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <mRCFEsXTvivO-I7sBdoTbqV0RsnX9vdGGORqzJBGYWXd1Xqis-oBNtEFaCEWIt3g9ARrvNeqH3l6sWSH4uQdcj5ps5WAmaEbEUvb9Znk9Rw=@protonmail.com>
In-Reply-To: <CALmj_sVwLG82_pCEnc-mdT-Cf+cPitpL59AruBbvyYLjaYoZ2Q@mail.gmail.com>
References: <CALmj_sWCA6S_4bnmLetvLuzNhv=PfQvLnX3zVEZwsRtgzA=yqw@mail.gmail.com>
 <CALmj_sVwLG82_pCEnc-mdT-Cf+cPitpL59AruBbvyYLjaYoZ2Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] Fwd: (Semi)Traceless 2-party coinjoin off-chain
	protocol using schnorr signatures
Precedence: list

Good morning Germ=C3=A1n,

It looks to me like this is CoinSwap with Schnorr Scriptless Scripts.

* https://joinmarket.me/blog/blog/coinswaps/
* https://joinmarket.me/blog/blog/flipping-the-scriptless-script-on-schnorr=
/

I also recently put up an article on extending such a protocol across 3 or =
more participants:

* https://zmnscpxj.github.io/bitcoin/multiswap.html

Regards,
ZmnSCPxj

> ## Objective
> * Make atomic swaps within the same chain possible in a traceless way
> * Achieving traceless same-chain atomic-swaps effectively turns an entire=
 chain into a=C2=A0 (P2PKH) mixer by default
>
> ## Proposed solution
> Similar to the way that atomic swaps would work with schnorr signatures (=
i.e. leveraging adaptor signatures), the proposed solution is to use - in p=
lace of the secret 't' - a suitably chosen schnorr signature. The end resul=
t being that when one counterparty claims their side of the funds, the part=
y can obtain the signature they're missing to claim the funds in the (schno=
rr) multisig that pays them.
> On-chain, this would appear like two independent transactions, even thoug=
h effectively the two parties have =E2=80=9Cexchanged=E2=80=9D the history =
attached to the UTXOs. Unlike a mixing service, in which all of the histori=
es get merged, with this protocol histories can be pairwise swapped without=
 anybody=E2=80=99s knowledge.
>
> ## Protocol description
> * Alice and Bob, holding funds at UTXO1 (controlled by Alice) and UTXO2 (=
controlled by Bob) wish to swap them.=C2=A0
> * Alice provides Bob with a single public key P_A
> * Bob provides Alice two pubkeys P_B1, P_B2.
> * Bob and Alice construct the P2PKH addresses Addr1 =3D Hash(P_A+P_B1) [w=
here the UTXO1 funds will be sent to eventually] and Addr2=C2=A0 =3D Hash(P=
_A+P_B2) [where the UTXO2 funds will be sent to eventually]
> * Bob and Alice exchange time-locked refund transactions for the funding =
transactions sending the funds to Addr1 and Addr2.
> * Bob and Alice submit the funding transactions (Alice pays to Addr1 from=
 UTXO1; Bob pays to Addr2 from UTXO2)
> * Alice sends Bob an adaptor signature: r1=C2=A0+ H(r1 | m)*x_a=C2=A0+ r2=
=C2=A0+ H( r2 | m')*x_a
> * Bob verifies the adaptor signature Alice sent contains a valid signatur=
e for spending from Addr1 AND another valid signature for spending from Add=
r2. Both signatures from Alice. Bob cannot separate out the two signatures =
and hence cannot claim any of the funds, provided H( r1 | m) !=3D H( r2 | m=
') in the signature commitment.=C2=A0
> * Bob now sends Alice the valid signature: r2=C2=A0+ H( r2 | m' )*x_b2
> * Alice can now add her signature to Bob's and get: r2 + H( r2| m' )*(x_b=
2=C2=A0+ x_a) which is a valid signature to spend the funding transaction s=
ent to Addr2.
> * Finally, Bob sees Alice claims the fund sent to Addr2 and uses that sig=
nature to subtract his own: r2 + H( r2 | m' )*(x_b2=C2=A0+ x_a) - (r2=C2=
=A0+ H( r2 | m' )*x_b2) =3D H( r2 | m ')*x_a
> * Bob takes the original adaptor signature and subtracts the known quanti=
ty r2+ H( r2 | m' )*x_a, to get a valid signature: r1=C2=A0+ H( r1 | m )*x_=
a
> * Bob can now add to that valid signature, his own signature and retrieve=
 the funds.
> ## Notes
> * It is possible for the counterparty to store copies of the signatures a=
s proof that such a join has taken place. But plausible deniability is avai=
lable upon discarding signatures since the joint private keys (x_a=C2=A0+ x=
_b*)=C2=A0are unavailable.
>
> I'm interested in hearing feedback on this idea if possible, and deemed i=
nteresting enough.
>
> Best regards,
> --
> Germ=C3=A1n
> Mathematician