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
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <decker.christian@gmail.com>) id 1XF2yM-0001lt-0u
for bitcoin-development@lists.sourceforge.net;
Wed, 06 Aug 2014 15:17:50 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.219.50 as permitted sender)
client-ip=209.85.219.50;
envelope-from=decker.christian@gmail.com;
helo=mail-oa0-f50.google.com;
Received: from mail-oa0-f50.google.com ([209.85.219.50])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1XF2yK-0002i5-Ho
for bitcoin-development@lists.sourceforge.net;
Wed, 06 Aug 2014 15:17:49 +0000
Received: by mail-oa0-f50.google.com with SMTP id g18so1963163oah.9
for <bitcoin-development@lists.sourceforge.net>;
Wed, 06 Aug 2014 08:17:43 -0700 (PDT)
X-Received: by 10.60.34.98 with SMTP id y2mr16405223oei.9.1407338263047; Wed,
06 Aug 2014 08:17:43 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.76.3.161 with HTTP; Wed, 6 Aug 2014 08:17:02 -0700 (PDT)
In-Reply-To: <CAJHLa0OtPA3DGQuJhp3zkK5dnBux6TFAw3qDsBdO0zaxrqBgRg@mail.gmail.com>
References: <CA+iPb=HkxeVPF0SynxCPgUkq4msrdfayFrVNFjzg29rFwqXv1w@mail.gmail.com>
<CAJHLa0O2wFq2Vs5Bes_8x1q_j0VC+U4DQkx=6GqT8w5e8Lh5Qg@mail.gmail.com>
<CA+iPb=ET+A-qB8TgPX8D-ut1DWnq9tZJ=14igfRVWO6eog6Xgw@mail.gmail.com>
<53E1A8AF.4030206@thinlink.com>
<CAJHLa0MfRhCPX8H92qc1kSebc=WrUzmSgbG331t4-zDHhTNu4w@mail.gmail.com>
<CANEZrP3eEiLxYfsAURRm4ysfS4TRgXxa_THxJ43cVH1OyR95JQ@mail.gmail.com>
<53E23F49.3020605@thinlink.com>
<CAJHLa0OtPA3DGQuJhp3zkK5dnBux6TFAw3qDsBdO0zaxrqBgRg@mail.gmail.com>
From: Christian Decker <decker.christian@gmail.com>
Date: Wed, 6 Aug 2014 16:17:02 +0100
Message-ID: <CALxbBHXh-Fktsr96PMXdohJdgcUKoNreJ-ZuApKOX3-qSkdk2w@mail.gmail.com>
To: Jeff Garzik <jgarzik@bitpay.com>
Content-Type: multipart/alternative; boundary=089e01175d0740002104fff779d8
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
(decker.christian[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: 1XF2yK-0002i5-Ho
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] deterministic transaction expiration
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, 06 Aug 2014 15:17:50 -0000
--089e01175d0740002104fff779d8
Content-Type: text/plain; charset=UTF-8
+1 for the new field, overloading fields with new meaning is definitely not
a good idea.
Something like nExpireAt with a block height sounds reasonable to me, but
we need to document that the usual caveats with blockchain reorgs apply.
On Wed, Aug 6, 2014 at 4:08 PM, Jeff Garzik <jgarzik@bitpay.com> wrote:
> ...because nLockTime is the exact opposite of expiration. A locked TX
> begins life invalid, and becomes valid (not-expired) after nLockTime passes.
>
> A new field containing expiration time would work.
>
>
>
> On Wed, Aug 6, 2014 at 10:44 AM, Tom Harding <tomh@thinlink.com> wrote:
>
>>
>> How is eventual expiration of a tx that started life with an nLockTime in
>> the future "breaking", any more than any other tx expiring?
>>
>>
>>
>> On 8/6/2014 6:54 AM, Mike Hearn wrote:
>>
>> We could however introduce a new field in a new tx version. We know we
>> need to rev the format at some point anyway.
>>
>>
>> On Wed, Aug 6, 2014 at 2:55 PM, Jeff Garzik <jgarzik@bitpay.com> wrote:
>>
>>> ...and existing users and uses of nLockTime suddenly become worthless,
>>> breaking payment channel refunds and other active uses of nLockTime.
>>>
>>> You cannot assume the user is around to rewrite their nLockTime, if it
>>> fails to be confirmed before some arbitrary deadline being set.
>>>
>>>
>>>
>>> On Wed, Aug 6, 2014 at 12:01 AM, Tom Harding <tomh@thinlink.com> wrote:
>>>
>>>> ...
>>>>
>>>
>> If nLockTime is used for expiration, transaction creator can't lie
>>>> to
>>>> help tx live longer without pushing initial confirmation eligibility
>>>> into the future. Very pretty. It would also enable "fill or kill"
>>>> transactions with a backdated nLockTime, which must be confirmed in a
>>>> few blocks, or start vanishing from mempools.
>>>>
>>>
>>
>
>
> --
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc. https://bitpay.com/
>
>
> ------------------------------------------------------------------------------
> Infragistics Professional
> Build stunning WinForms apps today!
> Reboot your WinForms applications with our WinForms controls.
> Build a bridge from your legacy apps to the future.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--089e01175d0740002104fff779d8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">+1 for the new field, overloading fields with new meaning =
is definitely not a good idea.<div><br></div><div>Something like nExpireAt =
with a block height sounds reasonable to me, but we need to document that t=
he usual caveats with blockchain reorgs apply.<div>
<br></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Wed,=
Aug 6, 2014 at 4:08 PM, Jeff Garzik <span dir=3D"ltr"><<a href=3D"mailt=
o:jgarzik@bitpay.com" target=3D"_blank">jgarzik@bitpay.com</a>></span> w=
rote:<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>=C2=A0...because nLock=
Time is the exact opposite of expiration.=C2=A0 A locked TX begins life inv=
alid, and becomes valid (not-expired) after nLockTime passes.<br>
<br></div>A new field containing expiration time would work.<br>
<br></div><div class=3D"gmail_extra"><div><div class=3D"h5"><br><br><div cl=
ass=3D"gmail_quote">On Wed, Aug 6, 2014 at 10:44 AM, Tom Harding <span dir=
=3D"ltr"><<a href=3D"mailto:tomh@thinlink.com" target=3D"_blank">tomh@th=
inlink.com</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">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<br>
How is eventual expiration of a tx that started life with an
nLockTime in the future "breaking", any more than any other t=
x
expiring?<div><br>
<br>
<br>
<div>On 8/6/2014 6:54 AM, Mike Hearn wrote:<br>
</div>
</div><blockquote type=3D"cite"><div>
<div dir=3D"ltr">We could however introduce a new field in a new tx
version. We know we need to rev the format at some point anyway.</d=
iv>
</div><div class=3D"gmail_extra"><br>
<br>
<div class=3D"gmail_quote"><div>On Wed, Aug 6, 2014 at 2:55 PM, Jef=
f
Garzik <span dir=3D"ltr"><<a href=3D"mailto:jgarzik@bitpay.com=
" target=3D"_blank">jgarzik@bitpay.com</a>></span>
wrote:<br>
</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div>
<div dir=3D"ltr">=C2=A0...and existing users and uses of nLockT=
ime
suddenly become worthless, breaking payment channel
refunds and other active uses of nLockTime.<br>
<br>
You cannot assume the user is around to rewrite their
nLockTime, if it fails to be confirmed before some
arbitrary deadline being set.<br>
<br>
</div>
</div><div class=3D"gmail_extra">
<div>
<div><br>
<br>
<div class=3D"gmail_quote"><div>On Wed, Aug 6, 2014 at 12=
:01
AM, Tom Harding <span dir=3D"ltr"><<a href=3D"mailto=
:tomh@thinlink.com" target=3D"_blank">tomh@thinlink.com</a>></span>
wrote:<br>
</div><blockquote class=3D"gmail_quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">...<br>
</blockquote>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote><div>
<br>
<blockquote type=3D"cite">
<div class=3D"gmail_extra">
<div class=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex">
<div class=3D"gmail_extra">
<div>
<div>
<div class=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
.8ex;border-left:1px #ccc solid;padding-left:1ex">
If nLockTime is used for expiration, transaction
creator can't lie to<br>
help tx live longer without pushing initial
confirmation eligibility<br>
into the future. =C2=A0Very pretty. =C2=A0It would al=
so
enable "fill or kill"<br>
transactions with a backdated nLockTime, which
must be confirmed in a<br>
few blocks, or start vanishing from mempools.<br>
</blockquote>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
<br>
</div></div>
</blockquote></div><br><br clear=3D"all"><br></div></div><div class=3D"">--=
<br>Jeff Garzik<br>Bitcoin core developer and open source evangelist<br>Bi=
tPay, Inc. =C2=A0 =C2=A0 =C2=A0<a href=3D"https://bitpay.com/" target=3D"_b=
lank">https://bitpay.com/</a>
</div></div>
<br>-----------------------------------------------------------------------=
-------<br>
Infragistics Professional<br>
Build stunning WinForms apps today!<br>
Reboot your WinForms applications with our WinForms controls.<br>
Build a bridge from your legacy apps to the future.<br>
<a href=3D"http://pubads.g.doubleclick.net/gampad/clk?id=3D153845071&iu=
=3D/4140/ostg.clktrk" target=3D"_blank">http://pubads.g.doubleclick.net/gam=
pad/clk?id=3D153845071&iu=3D/4140/ostg.clktrk</a><br>__________________=
_____________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
<br></blockquote></div><br></div></div></div>
--089e01175d0740002104fff779d8--
|
