1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 02AD7C0175
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 23 Apr 2020 17:56:15 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by whitealder.osuosl.org (Postfix) with ESMTP id DFCC3876DD
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 23 Apr 2020 17:56: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 XfX2cqpUCHXF
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 23 Apr 2020 17:56:14 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40140.protonmail.ch (mail-40140.protonmail.ch
[185.70.40.140])
by whitealder.osuosl.org (Postfix) with ESMTPS id DF11A87E32
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 23 Apr 2020 17:56:13 +0000 (UTC)
Date: Thu, 23 Apr 2020 17:56:08 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail; t=1587664571;
bh=Be6EcEqfg3oYwbNCAvIt5m0tFH2JMnQ2s1T1SNFh/wk=;
h=Date:To:From:Reply-To:Subject:In-Reply-To:References:From;
b=GipFb6M5lLm+mPcsslp2ZO+T82sol+QtVharV6tf58aXvpZWDdgaM4SQKGx7RokmG
d/yIQtEOV6jNMCDCmqZV+Ilkz3baMP77uxbPfadHZ8ieN2eULAumlPSp5d2UKrJ3IV
yuZxKWppLUOMvI1lBPKPakPy7an/au00Qirez4rI=
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
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: Thu, 23 Apr 2020 17:56:16 -0000
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
|
