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 fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])
by lists.linuxfoundation.org (Postfix) with ESMTP id 7D2D7C016E
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 6 Jun 2020 01:40:32 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by fraxinus.osuosl.org (Postfix) with ESMTP id 658E48638E
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 6 Jun 2020 01:40:32 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from fraxinus.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id k3v-GWg4DiiJ
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 6 Jun 2020 01:40:30 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40130.protonmail.ch (mail-40130.protonmail.ch
[185.70.40.130])
by fraxinus.osuosl.org (Postfix) with ESMTPS id 8E17F86302
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 6 Jun 2020 01:40:30 +0000 (UTC)
Date: Sat, 06 Jun 2020 01:40:18 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail; t=1591407628;
bh=D68ita+Gg18KoFs0mxXUiDoxN7N2Els+idgT39BNb3g=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From;
b=i1oOMu3Oh+OLovXhVImANUDeFaTnNA1GDjdPDJwK+wennKNoNS//z9yJyoRJTTpmB
t7s/PEwIQk336cYPj3ijhZ6I6WylgIXIhPLOAX/6q3bSOe8QTFSmYBDlEd+KsW2lr1
P6PJ/Bmrs0uhuNDMn0TZHcMcoCV0dHYc53pHYIlY=
To: Chris Belcher <belcher@riseup.net>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <Sy14DpcFGdAYL95d7e6tfkOe87oY53tJReo9CYvPT5J3Gb85AqedMheq1NbfVKUXZtZrwZqwVV4wSztikgWBAgNfTh8J5h5gXC6HDMxvsNg=@protonmail.com>
In-Reply-To: <e724b4c5-9efd-66c4-163b-492f17cafd7d@riseup.net>
References: <82d90d57-ad07-fc7d-4aca-2b227ac2068d@riseup.net>
<CAPv7TjY9h8n-nK_CPiYCWYDcbXpT1gfRMQDgf9VUkcR532rxOw@mail.gmail.com>
<VxL93WE7bDrK1riquTWTTEgJj9mDQ4W5CuhOgdnnDPeidw2ho6evVh4cLZLz0jEYMqejaD1tiLULVTXkNRbI5A7wSwV49qSwnXcTWCDJ96E=@protonmail.com>
<cbf78f63-cf8c-c5d8-06ea-afc79aabc23c@riseup.net>
<5LiZqpFxklAAbGFiiAE3ijRbIteODXKcHrXvGJ-qabgQj5hG8beFtHNbVZ-XUxETVwduJYz94UYuJGAPxBrbGeZpSClUtXYsPJBABfr03KM=@protonmail.com>
<e724b4c5-9efd-66c4-163b-492f17cafd7d@riseup.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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: Sat, 06 Jun 2020 01:40:32 -0000
Good morning Chris,
> I think I'm having trouble understanding this, does it work like this:
>
> Say we're in the 2-party coinswap case (Alice and Bob)
>
> We have Alice's funding transaction:
> Alice UTXO ---> 2of2 multisig (Alice+Bob)
>
> And we have the regular contract transaction
> 2of2 multisig (Alice+Bob) ---> Alice+timelock1 OR Bob+hashlock
>
> And you propose a second pre-signed transaction?
> 2of2 multisig (Alice+Bob) ---> Bob+timelock2
No, it is:
2of2 multisig (Alice+Bob) --(nLockTime=3Dlocktime1)-> Alice
The timelock is imposed as a `nLockTime`, not as an `OP_CLTV` (so not in t=
he output of the tx, but part of the tx), and the backout returns the funds=
to Alice, not sends it to Bob.
This transaction is created *before* the contract transaction.
The order is:
* Create (but not sign) Alice funding tx (Alice --> Alice+Bob).
* Create and sign Alice backout transaction (Alice+Bob -(nLockTime=3Dlockti=
me1)-> Alice).
* Create (but not sign) Bob funding tx (Bob --> Alice+Bob+sharedSecret).
* Create and sign Bob backout transaction (Alice+Bob+sharedSecret -(nLockti=
me=3Dlocktime2)-> Bob) where timelock2 < timelock1.
* Sign and broadcast funding txes.
* At this point, even if Bob funding tx is confirmed but Alice funding tx=
is not, Bob can recover funds with the backout, but Alice cannot steal the=
funds (since there is no hashlock branch at this point).
* When Alice funding tx is confirmed, create and sign contract transaction =
(Alice+Bob --> Alice+timelock1 OR Bob+hashlock).
* When Bob funding tx is confirmed and Bob has received the Alice contract =
transaction, create and sign Bob contract transaction (Alice+Bob+sharedSecr=
et --> Bob+timelock2 OR Alice+hashlock).
* Continue as normal.
In effect, the backout transaction creates a temporary Spilman unidirection=
al time-bound channel.
We just reuse the same timelock on the HTLC we expect to instantiate, as th=
e time bound of the Spilman channel; the timelock exists anyway, we might a=
s well reuse it for the Spilman.
Creation of the contract tx invalidates the backout tx (the backout tx is `=
nLockTime`d, the contract tx has no such encumbrance), but the backout allo=
ws Alice and Bob to fund their txes simultaneously without risk of race los=
s.
However, they do still have to wait for (deep) confirmation before signing =
contract transactions, and Bob has to wait for the incoming contract transa=
ction as well before it signs its outgoing contract transaction.
The protocol is trivially extendable with more than one Bob.
The insight basically is that we can split CoinSwap into a "channel establi=
shment" phase and "HTLC forwarding" phase followed by "HTLC resolution" and=
"private key handover".
HTLC forwarding and HTLC resolution are "done offchain" in the channels, an=
d channel establishment can be done in any order, including reverse.
Indeed, the Spilman channel need not have the same timelock as the HTLC it =
will eventually host: it could have a shorter timelock, since the contract =
transaction has no `nLockTime` it can be instantiated (with loss of privacy=
due to the nonstandard script) before the Spilman timeout.
Regards,
ZmnSCPxj
|
