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
|
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 <jgarzik@bitpay.com>) id 1XF2ps-0001NR-3x
for bitcoin-development@lists.sourceforge.net;
Wed, 06 Aug 2014 15:09:04 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of bitpay.com
designates 209.85.213.171 as permitted sender)
client-ip=209.85.213.171; envelope-from=jgarzik@bitpay.com;
helo=mail-ig0-f171.google.com;
Received: from mail-ig0-f171.google.com ([209.85.213.171])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1XF2pq-0002SB-3c
for bitcoin-development@lists.sourceforge.net;
Wed, 06 Aug 2014 15:09:04 +0000
Received: by mail-ig0-f171.google.com with SMTP id l13so8822899iga.10
for <bitcoin-development@lists.sourceforge.net>;
Wed, 06 Aug 2014 08:08:56 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to:cc:content-type;
bh=0g4MTjaAtsQDSlMdXEGsBiW6xXhe/YqwN+d2miz/U6k=;
b=k8EfdijW1PhUnE7UdYkeM8p4hv890V4dTPDGcshGGSpae0CQKZADx4p0tWjaTgbWxg
XwNPENsFxwmVybp35sBG/l5fpW0uIqyGIoZPUYMjQbS80uBG8vUBDKM/tO57z3GGTH3M
SbNziSWEK3uv9NOYhXGtLw3zL7WXB59onyjzB1z5aOrEFerub59BOnm4067QrreRV3Ky
nR74C911GTet/1ZbgE0HHDkJHJYGa9bLv58eTCsUAXfYLzdrIkd784tTu/2nqNrsic9z
It9/FikWWix1+B4ro/kgjgvFCekYzpZSBFWohEQO1gDQ7GR132JOl+uwafBnhjOg8hN0
Lc9Q==
X-Gm-Message-State: ALoCoQn+THv6g8h0beFpCnYXTCre1VdMqEdDLNiwaGkYXdi4h4Dr6r1ivfOPwNurUrX8us3RJ1lz
X-Received: by 10.50.80.116 with SMTP id q20mr60608690igx.22.1407337736286;
Wed, 06 Aug 2014 08:08:56 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.10.78 with HTTP; Wed, 6 Aug 2014 08:08:36 -0700 (PDT)
In-Reply-To: <53E23F49.3020605@thinlink.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>
From: Jeff Garzik <jgarzik@bitpay.com>
Date: Wed, 6 Aug 2014 11:08:36 -0400
Message-ID: <CAJHLa0OtPA3DGQuJhp3zkK5dnBux6TFAw3qDsBdO0zaxrqBgRg@mail.gmail.com>
To: Tom Harding <tomh@thinlink.com>
Content-Type: multipart/alternative; boundary=089e01536682db5fce04fff759c0
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 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: 1XF2pq-0002SB-3c
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:09:04 -0000
--089e01536682db5fce04fff759c0
Content-Type: text/plain; charset=UTF-8
...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/
--089e01536682db5fce04fff759c0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>=C2=A0...because nLockTime is the exact opposite of e=
xpiration.=C2=A0 A locked TX begins life invalid, and becomes valid (not-ex=
pired) after nLockTime passes.<br><br></div>A new field containing expirati=
on time would work.<br>
<br></div><div class=3D"gmail_extra"><br><br><div class=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@thinlink.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 class=3D""><br>
<br>
<br>
<div>On 8/6/2014 6:54 AM, Mike Hearn wrote:<br>
</div>
</div><blockquote type=3D"cite"><div class=3D"">
<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 class=3D"">On Wed, Aug 6, 2014 at 2=
:55 PM, Jeff
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 class=3D"">
<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 class=3D"">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 class=3D"">
<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>-- <br>Jeff Garzik<br>Bitcoin =
core developer and open source evangelist<br>BitPay, Inc. =C2=A0 =C2=A0 =C2=
=A0<a href=3D"https://bitpay.com/" target=3D"_blank">https://bitpay.com/</a=
>
</div>
--089e01536682db5fce04fff759c0--
|
