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
|
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 1082EC016F
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 13 May 2020 11:39:21 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by hemlock.osuosl.org (Postfix) with ESMTP id EE34F88ABC
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 13 May 2020 11:39:20 +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 Vwha3UHG5RnY
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 13 May 2020 11:39:19 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40137.protonmail.ch (mail-40137.protonmail.ch
[185.70.40.137])
by hemlock.osuosl.org (Postfix) with ESMTPS id 0A4C388B24
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 13 May 2020 11:39:19 +0000 (UTC)
Date: Wed, 13 May 2020 11:39:10 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail; t=1589369956;
bh=A2OYMWZdLTSTacED7ebyvuwnoKjEQP9E3hWP9CWnZsk=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From;
b=u0wB9sK7yjPAO0cAbPgoiPcElQFB1ZiS2G5m8zOo0mjA0uh+ipIvwH63GoCUQot5G
rYcl+Heim8w++bt5rW4tuyd77FJgvZRMZ3Rs8lvEF15KvLmXQJPPDr6ave8qIHy1uZ
HgBBhzdvBM0MxmlnAOcx8AX0PYe1zdoHWlqZQy1w=
To: Ruben Somsen <rsomsen@gmail.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <oIiSWK9E-M53lQD3BxO8vQBHzZ7vUSISzDElSaA0v3BFS4_WeFAHNybHttJLstlAiz6Xem4VWy9Ktp6hgklsPqkvqnKVMOUAuA_aKpjOFLA=@protonmail.com>
In-Reply-To: <CAPv7TjYewKe=Gt8io+uGNzeKmAq758vH9aB2OpFt=rGth8DZEg@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>
<2-ZZw_6q-EBo5DmIK5PtzWCE9zd9FdNtYuhFf84FKxRHwmL7g7kA9YvYB9iqFFkGy_xoXARzRW8hiZa-ZcLPWeZ60PNMQc9yMdZLnTsp1yo=@protonmail.com>
<CAPv7TjZAv_tVn=Wxf3LpfMmAzj8+mWiLr+7HMjjNArD7ThKO_A@mail.gmail.com>
<CAPv7TjYewKe=Gt8io+uGNzeKmAq758vH9aB2OpFt=rGth8DZEg@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 11:39:21 -0000
Good morning Ruben,
> Hi ZmnSCPxj,
>
> >potentially both Alice and Bob know all the secrets on the LTC side and =
end up competing over it
>
> That's exactly right.
>
> >Bob can thus give a copy of the revoke tx with signature directly to its=
favorite miner, forcing Alice to take 3 transactions
>
> Note that the timelock on the revoke tx is longer than the timelock on re=
fund tx #1. The idea is that Alice aborts the protocol by publishing refund=
tx #1 if the protocol hasn't reached step 4 in the svg by the time it beco=
mes valid. This should entirely mitigate the issue you're describing.
But if refund tx #1 at all exists, then you drop to the same issue you obje=
cted to with my proposal, which is that, on completion of the protocol, if =
Bob lets the refund tx#1 become valid (i.e. does not spend the BTC txo) the=
n Alice can broadcast it, putting both their funds into chaos.
So you might as well just use my counterproposal instead, which is simpler,=
gets bring-your-own-fees for free, etc.
I suppose there is some *slight* improvement in that with your proposal, Al=
ice *can* use revoke tx -> refund tx #2, but still, if Alice is insane then=
it could very well mess with the protocol by instead using refund tx #1.
Thus, if Bob wants to survive in an environment where Alices are possibly i=
nsane (e.g. the real world), it should do everything in its power to ensure=
that the BTC txo is spent before the timeout of refund tx #1, if refund tx=
#1 exists at all.
And if Bob is already going to do that, then Alice and Bob might as well ju=
st use my counterproposal etc etc.
> >adding two CPFP outputs (one for each participant)
>
> There seems to be a situation where RBF can be disabled by the other part=
y, but I'm not sure I see it... Why would a single output spendable by eith=
er key be insufficient?
If one party quickly broadcasts a long chain of low-feerate transactions on=
top of the single output, then the output is "pinned".
Low feerate means it is undesirable for miners to mine it, because it pays =
low for the amount of blockspace it has.
But because there is a long chain of transactions, the absolute fee of that=
chain can be sizable, and we have a rule in RBF which, paraphrased, goes s=
omething like "the replacing transaction should also have a higher absolute=
fee than *all* the transactions it replaces", meaning the fee jump that th=
e other side has to offer *has to be* pretty big.
If the other outputs of the tx are then multisig, then the pinning particip=
ant can simply refuse to sign for those, and if the existing txes spending =
the other outputs are relative-time-locked, they cannot be used to CPFP the=
revoke tx onchain.
This is why we eventually decided in Lightning to use two CPFP outpoints ra=
ther than one, and are also realizing just how much of a headache the RBF r=
ules are, sigh.
Still, in your proposed protocol the dependent transactions are all relativ=
e-timelocked, so timely confirmation of the revoke tx is not necessary, unl=
ike in the case of Lightning where all HTLCs have to use an absolute timelo=
ck because we have to coordinate multiple HTLCs in forwarding and violation=
of the timelocks can lead to headaches and fund loss and so on.
So maybe a single hook output, or even none at all, is workable.
>
> >We could use `SIGHASH_SINGLE | SIGHASH_ANYONECANPAY` as well
>
> Allowing others to add inputs/outputs would introduce malleability. Refun=
d tx #2 and the timeout tx would become invalid.
Ah, right, you still need `SIGHASH_ANYPREVOUT`/`SIGHASH_NOINPUT` for that.
> >Bob cannot safely perform step 2 before getting both signatures for the =
revoke tx
>
> That's right, as you guessed, he does receive a copy of the signed revoke=
tx at protocol start.
>
> >>alternatively Bob can just spend before the timelock expires.
> >This seems to be the safest alternative
>
> I agree not giving Alice time to publish the revoke tx is safest, but one=
does not preclude the other. The revoke tx is on an absolute timelock, so =
spending it before that time means you don't have anything to worry=C2=
=A0about, and spending it later means you'll have to be online and keep an =
eye out. If staying online is not a problem, then fee wise that seems prefe=
rable. As long as less than half of all valid (i.e. the timelock was reache=
d)=C2=A0revoke transactions get broadcast, you'll be saving on fees.
In a world where Alice may be insane and mess with the protocol just to gri=
ef Bob even if Alice loses its money (e.g. the real world), Bob should not =
depend on Alice behaving correctly or politely, so it should still have bac=
kup watchers set up in case it accidentally goes to sleep and so on.
Regards,
ZmnSCPxj
|
