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
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id C81A4C0051
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 25 Aug 2020 03:16:13 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by hemlock.osuosl.org (Postfix) with ESMTP id AE0E48709D
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 25 Aug 2020 03:16:13 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from hemlock.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id iKfRLBgVvuZD
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 25 Aug 2020 03:16:11 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40138.protonmail.ch (mail-40138.protonmail.ch
[185.70.40.138])
by hemlock.osuosl.org (Postfix) with ESMTPS id 8612D86DA3
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 25 Aug 2020 03:16:11 +0000 (UTC)
Date: Tue, 25 Aug 2020 03:16:05 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail; t=1598325368;
bh=WGN0b7jE7jVsfEP1DRAsI2xoXKRvGJujl/AQYbCiQg0=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From;
b=BD44gK940zHERDTJTQkAYrjhh+Bp7tMsGn8aBF0p4bYWWj4SPKVZzwgmRPU/VAvkJ
+8bGA/xX55TV21baPVHawCR4vi6HIZ3LfSF0RmQw0PJE1YaD/rlp+zwpfHLKavgMGT
O42p8Uw8mssR2BO7+kmyooFhQ9DevHbJaugc+hfo=
To: Antoine Riard <antoine.riard@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <VpsctPiYOV704v9wZiSROdRggid7uRv2mZVnCIILEPL4_VmwKhMVdNMPBj9XaF73-39jFLl3cq1o2tSk8h45tMuWM9W_i4_MQHKoJdYh9ew=@protonmail.com>
In-Reply-To: <CALZpt+GxKDEDAGUH3Jb3rcZdh_jy_depLRE5KzGTpkZOLVH+QA@mail.gmail.com>
References: <813e51a1-4252-08c0-d42d-5cef32f684bc@riseup.net>
<CALZpt+GxKDEDAGUH3Jb3rcZdh_jy_depLRE5KzGTpkZOLVH+QA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] Detailed protocol design for routed
multi-transaction CoinSwap
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: Tue, 25 Aug 2020 03:16:13 -0000
Good morning Antoine,
> Note, I think this is independent of picking up either relative or absolu=
te timelocks as what matters is the block delta between two links.
I believe it is quite dependent on relative locktimes.
Relative locktimes *require* a contract transaction to kick off the relativ=
e locktime period.
On the other hand, with Scriptless Script (which we know how to do with 2p-=
ECDSA only, i.e. doable pre-Taproot), absolute locktimes do not need a cont=
ract transaction.
With absolute locktimes + Scriptless SCript, in a single onchain PTLC, one =
participant holds a completely-signed timelock transaction while the other =
participant holds a completely-signed pointlock transaction.
This can be arranged by having one side offer partial signatures for the tr=
ansaction of the other, and once completing the signature, not sharing it w=
ith the other until we are ready to actually broadcast the transaction of o=
ur own volition.
There is no transaction that both participants hold in completely-signed fo=
rm.
This should remove most of the shenanigans possible, and makes the 30xRBF s=
afe for any range of fees.
I think.
Since for each PTLC a participant holds only its "own" transaction, it is p=
ossible for a participant to define its range of fees for the RBF versions =
of the transaction it owns, without negotiation with the other participant.
Since the fee involved is deducted from its own transaction, each participa=
nt can define this range of RBFed fees and impose it on the partial signatu=
res it gets from the other participant.
--
Private key turnover is still useful even in an absolute-timelock world.
If we need to bump up the block delta between links, it might be impractica=
l to have the total delta of a multi-hop swap be too long at the taker.
As a concrete example, suppose A is a taker who wants to route over makers =
B and C.
However, B and C require a CLTV delta of 1 week.
If A wants to route "directly" A->B->C->A, then if something bad happens, i=
t could be looking at having its funds locked for two weeks.
To reduce this risk, A can instead first swap A->B->A, then when that compl=
etes, A->C->A.
This limits its funding lockup to 1 week.
Private key turnover is useful since as soon as the A->B->A swap completes,=
it can directly fund the A->C->A swap from the B-side funding transaction =
of the A->B->A swap.
| A->B->A | A->C->A |
: : :
A -:->funding A&B--> B : :
: : :
B -:->funding A&B -----:--> funding A&C --> C :
: : :
: :C-> funding A&C ------:-> to-cold A -->
: : :
This increases the number of transactions by 1 per swap beyond the first, c=
ompared to a direct routing A->B->C->A, but this may be worth it for A if t=
he timelocks involved are too big for A.
With 2p-ECDSA, a funding A&C looks exactly the same as a to-cold A, so B is=
unable to reliably determine if it is the last hop in the route.
Without private key turnover, A would have:
**NO** private key turnover!
| A->B->A | A->C->A |
: : :
A -:->funding A&B--> B : :
: : :
B -:->funding A&B -----:--> claim A -> funding A&C --> C :
: : :
: : C-> funding A&C ------:-> to-cold =
A -->
: : :
So if timelock-deltas are possibly-high (to reduce the probability of the M=
AD-HTLC argument, and other attacks, succeeding), takers might prefer to ro=
ute by completing one swap first before starting the next one, and private =
key turnover is useful by reducing blockspace required by each hop.
For reference, this is how it looks like with a single A->B->C->A swap with=
private key turnover:
| A->B->C->A |
: :
A -:->funding A&B--> B :
: :
B -:->funding B&C -> C :
: :
C -:->funding A&C -----:-> to-cold A -->
: :
This is still smaller than in the A->B->A, A->C->A with private key turnove=
r, by one funding tx per hop.
However, A risks a much higher timelock (twice the timelock).
Thus, A might prefer a lower timelock in exchange for paying for an additio=
nal transaction.
Regards,
ZmnSCPxj
|
