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
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <tier.nolan@gmail.com>) id 1WfdWc-0006sV-JM
for bitcoin-development@lists.sourceforge.net;
Wed, 30 Apr 2014 23:02:50 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.192.53 as permitted sender)
client-ip=209.85.192.53; envelope-from=tier.nolan@gmail.com;
helo=mail-qg0-f53.google.com;
Received: from mail-qg0-f53.google.com ([209.85.192.53])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WfdWZ-00067y-54
for bitcoin-development@lists.sourceforge.net;
Wed, 30 Apr 2014 23:02:50 +0000
Received: by mail-qg0-f53.google.com with SMTP id f51so1945461qge.12
for <bitcoin-development@lists.sourceforge.net>;
Wed, 30 Apr 2014 16:02:41 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.140.48.13 with SMTP id n13mr8989730qga.90.1398898961679;
Wed, 30 Apr 2014 16:02:41 -0700 (PDT)
Received: by 10.140.25.86 with HTTP; Wed, 30 Apr 2014 16:02:41 -0700 (PDT)
In-Reply-To: <CAE-z3OXO2uQb=yhsjfvTUC33kQ9HVvaXxhPsd3Ki4Oy2jE9SCg@mail.gmail.com>
References: <CAE-z3OUE5AQAC2G4MtF=RVHwYEP1TKXTOopO14rmPiGkxC5MQw@mail.gmail.com>
<201404301859.07833.luke@dashjr.org>
<CAE-z3OXO2uQb=yhsjfvTUC33kQ9HVvaXxhPsd3Ki4Oy2jE9SCg@mail.gmail.com>
Date: Thu, 1 May 2014 00:02:41 +0100
Message-ID: <CAE-z3OWJAGonitgrP87WBBwenztqGrR_6qUYZnR_8PZUaSdm-A@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=001a11351cceb00a2404f84a8b25
X-Spam-Score: -0.6 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(tier.nolan[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1WfdWZ-00067y-54
Subject: Re: [Bitcoin-development] BIP Draft: Atomic Cross Chain Transfer
Protocol
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Wed, 30 Apr 2014 23:02:50 -0000
--001a11351cceb00a2404f84a8b25
Content-Type: text/plain; charset=UTF-8
I updated again.
The new version only requires non-standard transactions on one of the two
networks.
Next step is a simple TCP / RPC server that will implement the protocol to
trade between testnet and mainnet. Timeouts of much less than 24 hours
should be possible now.
On Wed, Apr 30, 2014 at 9:48 PM, Tier Nolan <tier.nolan@gmail.com> wrote:
> On Wed, Apr 30, 2014 at 7:59 PM, Luke Dashjr <luke@dashjr.org> wrote:
>
>> Instead of TX0, TX1, etc, can you put some kind of meaningful identifier
>> for
>> these transactions?
>>
>
> Sorry, that is the names come from the original thread, where I was
> outlining the idea. I updated the names.
>
>
>> TX1 and TX2 *cannot* be signed until after TX0 is completely signed by
>> both
>> parties.
>
>
> The bail in transactions are only signed by one of the parties. They are
> kept secret until the refund/payout transactions are all properly signed.
>
> There is a malleability risk though, hence the need for the 3rd party.
>
> It works on the same refund principle as payment channels.
>
> After TX0 is signed, but before TX2 is signed, either party could
>> walk away or otherwise hold the funds hostage. The sequence of signing
>> proposed in this BIP is *not possible to perform*.
>
>
> TX0 is not broadcast until the refund transactions are complete.
>
>
>> How did you implement and test this? :/
>>
>
> This is a draft at the moment.
>
> There is an implementation of (almost) this system but not by me. This
> proposal reduces the number of non-standard transaction types required.
>
> A full implement is the next step.
>
>
>> What is the purpose of the OP_EQUAL_VERIFY in TX4? I don't see a use...
>>
>
> That is a typo, I have updated it.
>
>
>> IMO, there should be separate BIPs for the exchange itself, and the
>> protocol
>> to negotiate the exchange.
>
>
> I can do that.
>
>
>> I would recommend changing the latter from JSON-RPC
>> to some extension of the Payment Protocol, if possible.
>>
>
> I wanted it to be as simple as possible, but I guess MIME is just a
> different way of doing things.
>
>>
>> Perhaps it would be good to only support compressed keys, to discourage
>> use of
>> uncompressed ones..
>>
>
> I would have no objection.
>
>
>>
>> Luke
>>
>
>
--001a11351cceb00a2404f84a8b25
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>I updated again.<br><br>The new version only requires=
non-standard transactions on one of the two networks.<br><br></div>Next st=
ep is a simple TCP / RPC server that will implement the protocol to trade b=
etween testnet and mainnet.=C2=A0 Timeouts of much less than 24 hours shoul=
d be possible now.<br>
</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Wed,=
Apr 30, 2014 at 9:48 PM, Tier Nolan <span dir=3D"ltr"><<a href=3D"mailt=
o:tier.nolan@gmail.com" target=3D"_blank">tier.nolan@gmail.com</a>></spa=
n> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">=
<div class=3D"gmail_quote"><div class=3D"">On Wed, Apr 30, 2014 at 7:59 PM,=
Luke Dashjr <span dir=3D"ltr"><<a href=3D"mailto:luke@dashjr.org" targe=
t=3D"_blank">luke@dashjr.org</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Instead of TX0, TX1, etc, can you put some kind of meaningful identifier fo=
r<br>
these transactions?<br></blockquote><div><br></div></div><div>Sorry, that i=
s the names come from the original thread, where I was outlining the idea.=
=C2=A0 I updated the names.<br></div><div class=3D""><div>=C2=A0<br></div><=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
#ccc solid;padding-left:1ex">
TX1 and TX2 *cannot* be signed until after TX0 is completely signed by both=
<br>
parties.</blockquote><div><br></div></div><div>The bail in transactions are=
only signed by one of the parties.=C2=A0 They are kept secret until the re=
fund/payout transactions are all properly signed.<br><br></div><div>There i=
s a malleability risk though, hence the need for the 3rd party.<br>
<br></div><div>It works on the same refund principle as payment channels.<b=
r></div><div class=3D""><div> <br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Aft=
er TX0 is signed, but before TX2 is signed, either party could<br>
walk away or otherwise hold the funds hostage. The sequence of signing<br>
proposed in this BIP is *not possible to perform*. </blockquote><div><br></=
div></div><div>TX0 is not broadcast until the refund transactions are compl=
ete.<br></div><div class=3D""><div>=C2=A0</div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x">
How did you implement and test this? :/<br></blockquote><div><br></div></di=
v><div>This is a draft at the moment.=C2=A0 <br><br>There is an implementat=
ion of (almost) this system but not by me.=C2=A0 This proposal reduces the =
number of non-standard transaction types required.<br>
<br></div><div>A full implement is the next step.<br></div><div class=3D"">=
<div>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
What is the purpose of the OP_EQUAL_VERIFY in TX4? I don't see a use...=
<br></blockquote><div><br></div></div><div>That is a typo, I have updated i=
t.<br></div><div class=3D""><div>=C2=A0<br></div><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex">
IMO, there should be separate BIPs for the exchange itself, and the protoco=
l<br>
to negotiate the exchange. </blockquote><div><br></div></div><div>I can do =
that.<br></div><div class=3D""><div>=C2=A0</div><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex">I would recommend changing the latter from JSON-RPC<br>
to some extension of the Payment Protocol, if possible.<br></blockquote><di=
v><br></div></div><div>I wanted it to be as simple as possible, but I guess=
MIME is just a different way of doing things.<br></div><div class=3D"">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<br>
Perhaps it would be good to only support compressed keys, to discourage use=
of<br>
uncompressed ones..<br></blockquote><div><br></div></div><div>I would have =
no objection.<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span><font color=3D"#888888"><br>
Luke<br>
</font></span></blockquote></div><br></div></div>
</blockquote></div><br></div>
--001a11351cceb00a2404f84a8b25--
|
