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
|
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 19585C0051
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 5 Sep 2020 02:29:36 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by hemlock.osuosl.org (Postfix) with ESMTP id F086B8753D
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 5 Sep 2020 02:29:35 +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 JWiWUPZoCjGQ
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 5 Sep 2020 02:29:34 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail4.protonmail.ch (mail4.protonmail.ch [185.70.40.27])
by hemlock.osuosl.org (Postfix) with ESMTPS id 0FBDA87522
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 5 Sep 2020 02:29:33 +0000 (UTC)
Date: Sat, 05 Sep 2020 02:29:18 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail; t=1599272970;
bh=aIqAzTB+A9fVLCj1Suyr0D184rPn1GqBtWoJVUCt07M=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From;
b=stGbyQ6jP+azmRbUZkgzzTrxdlefKBIAQCIkvtKdgF/gyOqw0V2pSH2eZmgJiMF2t
b+gc/jh0wlda5WoIBvcA8jGmdU+DzcX4dTsfBwQVkiJULqIfeD/YOIDYq66wqEaNwW
gst4F+idjwLmf/g9oYrhWHDi38/vpx6tetx2yhE0=
To: Antoine Riard <antoine.riard@gmail.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <HY0TQs10f6EP6tpw4gaY4W68m1vmn7zGY2EYa_jqMEN3ofSvyQgBGGIDotcAPmRNPg7oFteTugWFOwI9avdtLN0YVOZNiF9HrxnKtycVPG0=@protonmail.com>
In-Reply-To: <CALZpt+F0LDTERsPv7nZuuc34oyCPN-gMPspfxTM5kKqz4mSJqg@mail.gmail.com>
References: <813e51a1-4252-08c0-d42d-5cef32f684bc@riseup.net>
<CALZpt+GxKDEDAGUH3Jb3rcZdh_jy_depLRE5KzGTpkZOLVH+QA@mail.gmail.com>
<VpsctPiYOV704v9wZiSROdRggid7uRv2mZVnCIILEPL4_VmwKhMVdNMPBj9XaF73-39jFLl3cq1o2tSk8h45tMuWM9W_i4_MQHKoJdYh9ew=@protonmail.com>
<CALZpt+F0LDTERsPv7nZuuc34oyCPN-gMPspfxTM5kKqz4mSJqg@mail.gmail.com>
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] 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: Sat, 05 Sep 2020 02:29:36 -0000
Good morning Antoine,
> > This can be arranged by having one side offer partial signatures for th=
e transaction of the other, and once completing the signature, not sharing =
it with the other until we are ready to actually broadcast the transaction =
of our own volition.
> > There is no transaction that both participants hold in completely-signe=
d form
>
> I don't think that's different from the current model where you have eith=
er a valid HTLC-timeout or HTLC-Sucess tx to solve a HTLC output but never =
full witness material to build both ?
It is different in that the current (actually, now *previous*) model looks =
like this:
funding out -> contract tx --> HTLC-timeout
OR
HTLC-success
Whereas what I am describing looks like this:
funding out -> HTLC-timeout
OR
HTLC-success
The attack being described has to do with the fact that, after private key =
turnover (i.e. after hash-lock resolution), the contract tx can be used to =
at least annoy the supposed new owner of the funding out, since the contrac=
t tx deducts fees from its input to pay for itself.
And at the end of the swap (after private key turnover) the one who funded =
the funding outpoint (and swapped its control for this outpoint already, fo=
r a different outpoint) can at least try to broadcast the contract tx for a=
*chance* that the HTLC-timeout becomes valid and it can steal the coin eve=
n after taking the swapped coin on the other side of the swap.
Chris recently described a different technique, which has different contrac=
t txes, with the contract tx held by the offerrer of the HTLC (who can othe=
rwise later annoy the acceptor of the HTLC once the HTLC has been hash-reso=
lved) costing the offerrer of the HTLC some coins if it is published after =
swap completion.
> > To reduce this risk, A can instead first swap A->B->A, then when that c=
ompletes, A->C->A.
> This limits its funding lockup to 1 week.
>
> Okay I think I understand your point. So by intermediating the chain with=
the taker you ensure that in case of previous hop failure, taker funds are=
only timelocked for the delta of this faulting hop not the whole route. Bu=
t still not anchoring onchain the next route segment means that any moment =
the next maker can exit from the proposed position ?
>
> That's interesting, so a) you require all takers to lock their funds onch=
ain before initiating the whole routing and you will pay more in service fe=
es or b) you only lock them step by step but you increase risk of next hop =
default and thus latency. Roughly.
> =C2=A0
> It might be an interesting construction to explore on its own, minus the =
downside of producing weird spend patterns due to next hop maker bidding wi=
th another party.
>
Correct, a taker can pay higher fees for lots of smaller swaps that reduce =
its lockup risk, or pay less (with similar privacy bought) but with greater=
total lockup risk.
Regards,
ZmnSCPxj
|
