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
|
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 00139C016F
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 13 May 2020 08:39:51 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by hemlock.osuosl.org (Postfix) with ESMTP id E1B58883F1
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 13 May 2020 08:39:51 +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 qV338Diz0DF6
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 13 May 2020 08:39:50 +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 hemlock.osuosl.org (Postfix) with ESMTPS id BB376883E1
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 13 May 2020 08:39:49 +0000 (UTC)
Date: Wed, 13 May 2020 08:39:37 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail; t=1589359187;
bh=ULkTGKLmMqTiK22L082oqKDtkt+iwNynZaR4qBzD13E=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From;
b=oFruVwSj3J2BuRhops1Kp60eNMB8XqT9j54w3yorKULO1wSS0msRutAyvFm2kDRoN
ywbSrZ/vuhkZbp15/+iERqUYnMcuO+8iPm9ZQ+FfOMro21vXm3bNfEnph6fPKuQp7R
UktzmL/2IC8hFdZ0ysj7W48RsnI1F2VkHVpY19o8=
To: Ruben Somsen <rsomsen@gmail.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <2-ZZw_6q-EBo5DmIK5PtzWCE9zd9FdNtYuhFf84FKxRHwmL7g7kA9YvYB9iqFFkGy_xoXARzRW8hiZa-ZcLPWeZ60PNMQc9yMdZLnTsp1yo=@protonmail.com>
In-Reply-To: <CAPv7TjbfuV1YvgTS4pjr_56R_-=spb9DzPwqP1HFCBOZpSOq8Q@mail.gmail.com>
References: <CAPv7TjZGBbf6f1y49HLFD2eNiP5d4e+=dFGqiMFs6jaeYyH-NQ@mail.gmail.com>
<CAH5Bsr1d57pzmNgakt=Q2M+Ey+PL9jUVUPeJ_aFj0L0TBAHzKw@mail.gmail.com>
<CAH5Bsr1paP8dmo_z6VoEHYvB_SpD4Piw91LeLJBMgFph7Qrtfg@mail.gmail.com>
<CAPv7TjYqC73zRQq2yQy9RpeHUUexjSS23uU9VwJvvoRr50p2vA@mail.gmail.com>
<Mpqd20ZM9-93dIIhe1yS4QEGKmzT-uuBrAn1e4omDbA1YJvXrEmZ3IZeoz90s5AHVLAdYwF0PhxgMZwqDdHxQ0UQw2eEEytngEXSsXeLM14=@protonmail.com>
<CAPv7TjbfuV1YvgTS4pjr_56R_-=spb9DzPwqP1HFCBOZpSOq8Q@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] SAS: Succinct Atomic Swap
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, 13 May 2020 08:39:52 -0000
Good morning Ruben,
> >If the shortened refund transaction exists (labeled "refund transaction =
#1" in the SVG) then the same issue still occurs=C2=A0
>
> Yes, but there is one crucial difference: at that point in the protocol (=
Bob has the success transaction and then stops cooperating) Alice and Bob b=
oth had the opportunity not to take that path. Bob could have sent the succ=
ess transaction, and Alice could have waited and sent the revoke transactio=
n. They would essentially be "colluding" to fail.
Okay, so the concern is basically, that Bob misses the deadline, then Alice=
feels obligated to reclaim the funds.
In your proposal, the tx competition is between the secret-revealing succes=
s TX and the non-secret-revealing revoke tx.
Whereas in my counterproposal, under the same conditions, the tx competitio=
n is between the secret-revealing success tx and the secret-revealing backo=
ut tx, and both transactions becoming visible on P2P network means potentia=
lly both Alice and Bob know all the secrets on the LTC side and end up comp=
eting over it, RBFing each other until the entire fund goes to miners.
> >Without the refund#1 in your proposal, Bob refusing cooperation after Al=
ice puts the BTC into lock for 3 days and 2 further onchain transactions
>
> I'm not sure if I correctly understood what you're saying, but it's as fo=
llows:
>
> Refund #1 can only safely be used before the signed success tx is given t=
o Bob. The cost to Alice at this point if Bob aborts is two on-chain transa=
ctions while Bob hasn't put anything on-chain yet.
>
> Refund #2 needs to be used after Bob receives the signed success tx. The =
cost to Alice is now three transactions, but Bob also went-on-chain by this=
point, so causing this wasn't costless to Bob and is thus a similar failur=
e mode.
I think it is not accurate that Bob is already on-chain before Alice can be=
forced to use 3 transactions to fail.
The revoke tx signatures are shared at step 0 of your protocol description.
Thus Bob has a copy of the revoke tx that is valid once Alice signs and con=
firms the funding transaction.
Bob can thus give a copy of the revoke tx with signature directly to its fa=
vorite miner, forcing Alice to take 3 transactions to back out of the swap.
Since Bob gave the tx directly to its favorite miner (TANSTAAGM: "There ain=
't no such thing as a global mempool"), Alice will only know about this eve=
nt when the revoke tx is confirmed once, at which point it is very difficul=
t to reverse, even if Alice has a refund#1 tx prepared.
Bob can do this before step 2 in your protocol description, meaning before =
Bob locks up any funds, so Bob can do this for free, and will even use fund=
s going back to Alice to pay for confirmation of the revoke tx.
Because Bob can do this for free, there is no disincentive for trolling Bob=
s to exist whose sole life goal is to just grief possible Alices.
This can be slightly mitigated by adding two CPFP outputs (one for each par=
ticipant) and using the minimum relayable feerate for the revoke tx so that=
Bob is forced to bring its own fees in order to incentivize miners.
This is similar to the "bring your own fees" currently proposed for Lightni=
ng, but note the recent hand-wringing about the various problems this adds =
to mempools and CPFP and RBF rules and etc etc: https://lists.linuxfoundati=
on.org/pipermail/bitcoin-dev/2020-April/017757.html
We could use `SIGHASH_SINGLE | SIGHASH_ANYONECANPAY` as well for a bring-yo=
ur-own-fees, but that is not `SIGHASH_ALL` and thus marks the transaction g=
raph as special.
And forcing bring-your-own-fees means neither Alice nor Bob can swap all th=
eir funds in a single operation, they have to keep a reserve.
Bob cannot safely perform step 2 before getting both signatures for the rev=
oke tx, as without Bob having access to the rveoke tx, if Bob locks up LTC,=
Alice can stop responding and lock both their funds indefinitely with Bob =
not having any way to recover its funds, which a rich Alice can use to comp=
letely lock out an impoverished Bob.
But if Bob is given both signatures for the revoke tx before step 2, then B=
ob can send the revoke tx to its favorite miner, forcing Alice to take 3 tr=
ansactions to back out, before Bob locks any funds in LTC side.
>
> I also agree with your observation that alternatively Bob can just spend =
before the timelock expires.
This seems to be the safest alternative; in my context, where Bob is a Coin=
Swap server/maker, Bob can wait a short while for new clients/takers, and i=
f no new clients arrive, spend.
Bob can run multiple servers, each of which are given the completed success=
transaction, and the servers can check that if the timeout is near, to spa=
m the Bitcoin P2P network with the completed success transactions.
(these servers need not even run fullnodes, they could just periodically po=
ll a number of blockchain explorers and electrum servers, and when the bloc=
kheight approaches, attempt broadcast; if the "main" server that accepts cl=
ients/takers has already spent the TXO the broadcast of the completed succe=
ss tx is simply rejected by the Bitcoin P2P network; if the timeout is base=
d on sidereal time then the backup servers only need to be running NTP)
Regards,
ZmnSCPxj
|
