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
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 69E12C0051
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Sep 2020 01:04:38 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by silver.osuosl.org (Postfix) with ESMTP id 4C293229D4
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Sep 2020 01:04:38 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from silver.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 4sGz09-RXX8A
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Sep 2020 01:04:35 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40135.protonmail.ch (mail-40135.protonmail.ch
[185.70.40.135])
by silver.osuosl.org (Postfix) with ESMTPS id B85FF204D9
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Sep 2020 01:04:35 +0000 (UTC)
Date: Wed, 16 Sep 2020 01:04:29 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail; t=1600218272;
bh=VjVtRom+tE8dMXF+vY6bxJra4A23vPxWUmsugPz1P5k=;
h=Date:To:From:Reply-To:Subject:In-Reply-To:References:From;
b=GkgRt4deiOjWpuDFxY4qMM5nl8ue86Ue5bd3tYIUQI12WOnY3jr9b+ErlZ19MEnNZ
JwhL/KqVHnfeLFsFL/1xvkrSvWJ4lyJ21BHAMQAOENJfSlLQKV/ckcSx+ZWZf0dTcA
VE4qX67lMKwKlzQTQIOwZK4zZrrF3dHIFli+sfDI=
To: Tom Trevethan <tom@commerceblock.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <2Abk4Gqv5hJyGtA8Gg1WCP5RNuyUFkmRn1uUKp_mdUaXrRTz4SDBTPi0MGU7D5jj36VSzrqsIiO5lMR4gGRApRX2jyp8vXDeHBnFt-6ca-g=@protonmail.com>
In-Reply-To: <CAJvkSseOx8mwYowLEnfKVEUuM5xsiYkbLdAvtaYxPpu4jY9pCg@mail.gmail.com>
References: <CAJvkSseOx8mwYowLEnfKVEUuM5xsiYkbLdAvtaYxPpu4jY9pCg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] Statechain coinswap: assigning blame for failure
in a two-stage transfer protocol.
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: Wed, 16 Sep 2020 01:04:38 -0000
Good morning Tom,
> Here is a high-level description of how this blinding can operate - with =
the aim that the conductor does learn how the ownership of individual coins=
has changed.
> For example, imagine 4 individuals (A,B,C and D) who own equal value stat=
ecoins utxo1, utxo2, utxo3 and utxo4 respectively. They want to swap owners=
hip privately, trusting the conductor/SCE to enforce atomicity. In other wo=
rds, the conductor will randomly assign each statecoin to one of the owners=
(the mix), but will not be able to gain knowledge of that assignment.
> 1. A,B,C and D signal their participation by signing the swap_token (whic=
h has details of the swap) with the proof-key of their input coin. (A state=
coin address is formed of a concatenation of the proof key and backup addre=
ss).
> 2. Each of A,B,C and D then generate a new statecoin address (where they =
what to receive the swapped coin), which they blind (encrypt) and sign with=
the proof key of their input coin: add1, add2, add3 and add4 and send to t=
he conductor.
> 3. The conductor authenticates each signature and then signs each payload=
(i.e. the blinded destination addresses) with a blinded signature scheme a=
nd returns these signatures to A,B,C and D.
> 4. Each of A,B,C and D then reconnects over TOR with a new identity.
> 5. Each of A,B,C and D then send their unblinded destination address with=
the conductor signature to the conductor (the conductor now knows that the=
se 4 addresses belong to A,B,C and D, but not which ones map to each input.=
)
> 6. The conductor randomly assigns each address to one of utxo1, utxo2, ut=
xo3 and utxo4 (e.g. utxo1:add3, utxo2:add1, utxo3:add4 and utxo4:add2) and =
requests each participant to initiate the transfer to the given address.
> 7. Each participant then finalises each transfer - if any transfer fails =
(due to a participant disappearing or acting maliciously) then all transfer=
s are reverted - here atomicity is guaranteed by the SCE.
Okay, I suppose this is much too high-level a view, and I have no idea what=
you mean by "statecoin" exactly.
Let me try to fill in the details and correct me if I am wrong okay?
I imagine that the `add1` etc. are implemented as 2-of-2 between the purpor=
ted owner and the tr\*sted signing module.
The owner of that address can easily create this knowing only the pubkey of=
the tr\*sted signing module.
The initial `utxo1`... are also in similar 2-of-2s.
(they cannot be unilateral control, since then a participant can broadcast =
a replacement transaction, even without RBF, almost directly to miners.)
So when the coordinator talks to Alice, who owns `utxo1` and destination `a=
ddr1`, it provides partially-signed transactions of `utxo#:addr#`.
Alice then checks that its `addr1` is on one of those transactions, with th=
e correct amount, then provides a signature for the `utxo1:addr#` transacti=
on.
However, then the coordinator, who happens to be in cahoots with Bob, Charl=
ie, and Dave, simply broadcasts that transaction without soliciting the `ut=
xo#:addr1` transaction.
So it seems to me that this requires tr\*st that the coordinator is not goi=
ng to collude with other participants.
This is strictly worse than say Wasabi, where the coordinator colluding wit=
h other participants only allows the coordinator to break privacy, not outr=
ight steal funds.
It seems to me that the trust-minimized CoinSwap plan by belcher_ is superi=
or to this, with reduced scope for theft.
The plan by belcher_ is potentially compatible with using watchtowers that =
can be used for both CoinSwap and Lightning as well (if we design it well) =
with the watchtower potentially not even learning whether it is watching a =
CoinSwap or a Lightning channel.
Though of course I could be misunderstanding the scheme itself.
Is my understanding correct?
Regards,
ZmnSCPxj
|
