summaryrefslogtreecommitdiff
path: root/47/15bab98c5e2b2c6a551e16846de0e1f096ba12
blob: 384c993b44dfc57d630aecba51065fd95d19e6c0 (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
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <keziahw@gmail.com>) id 1XFp7i-0003qk-6x
	for bitcoin-development@lists.sourceforge.net;
	Fri, 08 Aug 2014 18:42:42 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.218.45 as permitted sender)
	client-ip=209.85.218.45; envelope-from=keziahw@gmail.com;
	helo=mail-oi0-f45.google.com; 
Received: from mail-oi0-f45.google.com ([209.85.218.45])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1XFp7h-0001U8-42
	for bitcoin-development@lists.sourceforge.net;
	Fri, 08 Aug 2014 18:42:42 +0000
Received: by mail-oi0-f45.google.com with SMTP id e131so3928140oig.4
	for <bitcoin-development@lists.sourceforge.net>;
	Fri, 08 Aug 2014 11:42:35 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.182.191.7 with SMTP id gu7mr31901445obc.14.1407523355613;
	Fri, 08 Aug 2014 11:42:35 -0700 (PDT)
Sender: keziahw@gmail.com
Received: by 10.202.61.195 with HTTP; Fri, 8 Aug 2014 11:42:35 -0700 (PDT)
Received: by 10.202.61.195 with HTTP; Fri, 8 Aug 2014 11:42:35 -0700 (PDT)
In-Reply-To: <CAJHLa0OsKxugMc39mw0xTXnLse0+oJWu_vyYmYyLU1WC2y=ZUg@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>
	<CALxbBHXh-Fktsr96PMXdohJdgcUKoNreJ-ZuApKOX3-qSkdk2w@mail.gmail.com>
	<53E50B00.8030505@thinlink.com>
	<CAJHLa0OsKxugMc39mw0xTXnLse0+oJWu_vyYmYyLU1WC2y=ZUg@mail.gmail.com>
Date: Fri, 8 Aug 2014 11:42:35 -0700
X-Google-Sender-Auth: UCFS47baptsjjUqOdpEJa7qOwJM
Message-ID: <CA+iPb=HEhU4-vXQYOU5SuKQFJcepMMgoZBQprTorhyWrW4DzWA@mail.gmail.com>
From: Kaz Wesley <kaz@revolveforward.com>
To: Jeff Garzik <jgarzik@bitpay.com>
Content-Type: multipart/alternative; boundary=089e0158b6429fdf6905002291ab
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
	(keziahw[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: 1XFp7h-0001U8-42
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: Fri, 08 Aug 2014 18:42:42 -0000

--089e0158b6429fdf6905002291ab
Content-Type: text/plain; charset=UTF-8

A new network tx field would have the same problem, right?

With a child-refreshes-parent policy, someone wishing to redeem a
transaction that has passed its relay window without being confirmed could
still do so.
On Aug 8, 2014 11:16 AM, "Jeff Garzik" <jgarzik@bitpay.com> wrote:

> On Fri, Aug 8, 2014 at 1:38 PM, Tom Harding <tomh@thinlink.com> wrote:
> >> 4. add a new IsStandard rule rejecting transactions with an nLockTime
> >> more than N blocks behind the current tip (for some fixed value N, to
> >> be determined)
>
> It cannot be assumed that transaction creation time and transaction
> publish-to-outside-world time are the same, even though they often
> are.
>
> --
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc.      https://bitpay.com/
>
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

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

<p dir=3D"ltr">A new network tx field would have the same problem, right?</=
p>
<p dir=3D"ltr">With a child-refreshes-parent policy, someone wishing to red=
eem a transaction that has passed its relay window without being confirmed =
could still do so.</p>
<div class=3D"gmail_quote">On Aug 8, 2014 11:16 AM, &quot;Jeff Garzik&quot;=
 &lt;<a href=3D"mailto:jgarzik@bitpay.com">jgarzik@bitpay.com</a>&gt; wrote=
:<br type=3D"attribution"><blockquote class=3D"gmail_quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Fri, Aug 8, 2014 at 1:38 PM, Tom Harding &lt;<a href=3D"mailto:tomh@thin=
link.com">tomh@thinlink.com</a>&gt; wrote:<br>
&gt;&gt; 4. add a new IsStandard rule rejecting transactions with an nLockT=
ime<br>
&gt;&gt; more than N blocks behind the current tip (for some fixed value N,=
 to<br>
&gt;&gt; be determined)<br>
<br>
It cannot be assumed that transaction creation time and transaction<br>
publish-to-outside-world time are the same, even though they often<br>
are.<br>
<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><br>
<br>
---------------------------------------------------------------------------=
---<br>
Want fast and easy access to all the code in your enterprise? Index and<br>
search up to 200,000 lines of code with a free copy of Black Duck<br>
Code Sight - the same software that powers the world&#39;s largest code<br>
search on Ohloh, the Black Duck Open Hub! Try it now.<br>
<a href=3D"http://p.sf.net/sfu/bds" target=3D"_blank">http://p.sf.net/sfu/b=
ds</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>
</blockquote></div>

--089e0158b6429fdf6905002291ab--