summaryrefslogtreecommitdiff
path: root/c1/d552acdd18ffc718d09d69093da495bea88480
blob: 7e12a43ffc74e5c88be799df73ddd4817de94ad4 (plain)
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
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <mh.in.england@gmail.com>) id 1XF1gG-0006N5-2w
	for bitcoin-development@lists.sourceforge.net;
	Wed, 06 Aug 2014 13:55:04 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.214.180 as permitted sender)
	client-ip=209.85.214.180; envelope-from=mh.in.england@gmail.com;
	helo=mail-ob0-f180.google.com; 
Received: from mail-ob0-f180.google.com ([209.85.214.180])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1XF1gE-0001yw-2F
	for bitcoin-development@lists.sourceforge.net;
	Wed, 06 Aug 2014 13:55:03 +0000
Received: by mail-ob0-f180.google.com with SMTP id uy5so1791699obc.39
	for <bitcoin-development@lists.sourceforge.net>;
	Wed, 06 Aug 2014 06:54:56 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.60.132.14 with SMTP id oq14mr15420381oeb.8.1407333296564;
	Wed, 06 Aug 2014 06:54:56 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.35.234 with HTTP; Wed, 6 Aug 2014 06:54:56 -0700 (PDT)
In-Reply-To: <CAJHLa0MfRhCPX8H92qc1kSebc=WrUzmSgbG331t4-zDHhTNu4w@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>
Date: Wed, 6 Aug 2014 15:54:56 +0200
X-Google-Sender-Auth: Mjt6VmiN2WPY6YFZTjF1JHCA7QE
Message-ID: <CANEZrP3eEiLxYfsAURRm4ysfS4TRgXxa_THxJ43cVH1OyR95JQ@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Jeff Garzik <jgarzik@bitpay.com>
Content-Type: multipart/alternative; boundary=047d7b41cd2e38ef0b04fff651b2
X-Spam-Score: -0.5 (/)
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
	(mh.in.england[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
	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: 1XF1gE-0001yw-2F
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 13:55:04 -0000

--047d7b41cd2e38ef0b04fff651b2
Content-Type: text/plain; charset=UTF-8

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:
>
>> On 8/5/2014 12:10 PM, Kaz Wesley wrote:
>> > Any approach based on beginning a transaction expiry countdown when a
>> > transaction is received (as in mempool janitor) seems unviable to me:
>> > once a node has forgotten a transaction, it must be susceptible to
>> > reaccepting it;
>>
>> It's hard to argue with that logic.
>>
>> 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.
>>
>>
>>
>> ------------------------------------------------------------------------------
>> 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
>>
>
>
>
> --
> 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
>
>

--047d7b41cd2e38ef0b04fff651b2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<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.</div><div class=
=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Wed, Aug 6, 2014 at =
2:55 PM, Jeff Garzik <span dir=3D"ltr">&lt;<a href=3D"mailto:jgarzik@bitpay=
.com" target=3D"_blank">jgarzik@bitpay.com</a>&gt;</span> 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">=C2=A0...and existing users=
 and uses of nLockTime 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 class=3D"gmail_extra"><div><div class=3D"h5"><br><br><div cl=
ass=3D"gmail_quote">On Wed, Aug 6, 2014 at 12:01 AM, Tom Harding <span dir=
=3D"ltr">&lt;<a href=3D"mailto:tomh@thinlink.com" target=3D"_blank">tomh@th=
inlink.com</a>&gt;</span> wrote:<br>


<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div>On 8/5/2014 12:10 PM, Kaz Wesley wrote:=
<br>
&gt; Any approach based on beginning a transaction expiry countdown when a<=
br>
&gt; transaction is received (as in mempool janitor) seems unviable to me:<=
br>
&gt; once a node has forgotten a transaction, it must be susceptible to<br>
&gt; reaccepting it;<br>
<br>
</div>It&#39;s hard to argue with that logic.<br>
<br>
If nLockTime is used for expiration, transaction creator can&#39;t lie to<b=
r>
help tx live longer without pushing initial confirmation eligibility<br>
into the future. =C2=A0Very pretty. =C2=A0It would also enable &quot;fill o=
r kill&quot;<br>
transactions with a backdated nLockTime, which must be confirmed in a<br>
few blocks, or start vanishing from mempools.<br>
<br>
<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&amp;iu=
=3D/4140/ostg.clktrk" target=3D"_blank">http://pubads.g.doubleclick.net/gam=
pad/clk?id=3D153845071&amp;iu=3D/4140/ostg.clktrk</a><br>
<div><div>_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net" target=3D"_bla=
nk">Bitcoin-development@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>
</div></div></blockquote></div><br><br clear=3D"all"><br></div></div><div c=
lass=3D"">-- <br>Jeff Garzik<br>Bitcoin core developer and open source evan=
gelist<br>BitPay, Inc. =C2=A0 =C2=A0 =C2=A0<a href=3D"https://bitpay.com/" =
target=3D"_blank">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&amp;iu=
=3D/4140/ostg.clktrk" target=3D"_blank">http://pubads.g.doubleclick.net/gam=
pad/clk?id=3D153845071&amp;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>

--047d7b41cd2e38ef0b04fff651b2--