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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <tomh@thinlink.com>) id 1XF4bj-0007IX-Op
for bitcoin-development@lists.sourceforge.net;
Wed, 06 Aug 2014 17:02:35 +0000
X-ACL-Warn:
Received: from mail-pa0-f45.google.com ([209.85.220.45])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1XF4bi-0002Or-EW
for bitcoin-development@lists.sourceforge.net;
Wed, 06 Aug 2014 17:02:35 +0000
Received: by mail-pa0-f45.google.com with SMTP id eu11so3760984pac.18
for <bitcoin-development@lists.sourceforge.net>;
Wed, 06 Aug 2014 10:02:28 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
:subject:references:in-reply-to:content-type;
bh=BwwFT5ST6aPNXTlaq4Djv5HTAaQpRDrzKOtgLeXisA4=;
b=Xsnhe2lF9GSjJgTGI4kidlFAFucR3At0kD7G+UOghTs9Kmh6phOshqqirRo/1Wdf1I
4260xs2muhH9kBfnpiN/SorjmgF8w0KGOxe1eUxQV8abma5eB8NsM9RlDKi2S6VtAFwH
JdN6n5eVfl9vT12q2zAk2kLYsYu/WsGdSIMC7v8h2kDoXty7jX7+OqfCxUO4K+WLWL12
IRcA4Rxv/yzSxKbcaTFHjCeo9MCtjB712+fLUEe+cWaO/a9krOCgS1TEXWe3XaDIshLh
qng0dONHn8A7fTRa+wug8b9vFhEz0P0JC4Hjn9tBS9wrxqOgIT3pT9nuJYbl8sow6E/r
TbsA==
X-Gm-Message-State: ALoCoQmvmJ+1ZA7knxbwZut3L/NscVXGbS6ITCmvLUyAG5ftolnXMX08wL/U+wv1qFzvt/27gJ6G
X-Received: by 10.70.127.207 with SMTP id ni15mr12240065pdb.129.1407344548633;
Wed, 06 Aug 2014 10:02:28 -0700 (PDT)
Received: from [10.100.1.239] ([204.58.254.99])
by mx.google.com with ESMTPSA id id4sm1817030pbb.57.2014.08.06.10.02.27
for <bitcoin-development@lists.sourceforge.net>
(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
Wed, 06 Aug 2014 10:02:28 -0700 (PDT)
Message-ID: <53E25F8A.5070905@thinlink.com>
Date: Wed, 06 Aug 2014 10:02:02 -0700
From: Tom Harding <tomh@thinlink.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
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> <63a80796-609e-43f5-9280-4cd8cf5d2648@email.android.com>
<CAJHLa0OQJEvQht_chF1gVG_BOwp=DW0zOOo3VE_acZonsSguWw@mail.gmail.com>
In-Reply-To: <CAJHLa0OQJEvQht_chF1gVG_BOwp=DW0zOOo3VE_acZonsSguWw@mail.gmail.com>
Content-Type: multipart/alternative;
boundary="------------080602060402000605060602"
X-Spam-Score: 1.6 (+)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
0.6 RCVD_IN_SORBS_WEB RBL: SORBS: sender is an abusable web server
[204.58.254.99 listed in dnsbl.sorbs.net]
1.0 HTML_MESSAGE BODY: HTML included in message
X-Headers-End: 1XF4bi-0002Or-EW
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 17:02:35 -0000
This is a multi-part message in MIME format.
--------------080602060402000605060602
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Today we have first-eligible-height (nLockTime), and mempool expiration
measured from this height would work for the goals being discussed, no
fork or protocol rev.
With first-eligible-height and last-eligible-height, creator could
choose a lifetime shorter than the max, and in addition, lock the whole
thing until some point in the future.
On 8/6/2014 9:15 AM, Jeff Garzik wrote:
> A fork is not necessarily required, if you are talking about
> information that deals primarily with pre-consensus mempool behavior.
> You can make a "network TX" with some information that is digitally
> signed, yet discarded before it reaches miners.
>
>
> On Wed, Aug 6, 2014 at 11:42 AM, Peter Todd <pete@petertodd.org
> <mailto:pete@petertodd.org>> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
>
>
> On 6 August 2014 08:17:02 GMT-07:00, Christian Decker
> <decker.christian@gmail.com <mailto:decker.christian@gmail.com>>
> wrote:
> >+1 for the new field, overloading fields with new meaning is
> definitely
> >not
> >a good idea.
>
> To add a new field the best way to do it is create a new,
> parallel, tx format where fields are committed by merkle radix
> tree in an extensible and provable way. You'd then commit to that
> tree with a mandatory OP_RETURN output in the last txout, or with
> a new merkle root.
>
> Changing the tx format itself in a hard-fork is needlessly
> disruptive, and in this case, wastes opportunities for improvement.
> -----BEGIN PGP SIGNATURE-----
> Version: APG v1.1.1
>
> iQFQBAEBCAA6BQJT4kzQMxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
> cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhamzCAC+zRaXRodP63+ke3K+
> Viapiepvk4uIOlqxqtMB2O0zWcyu2+xCJDiRPykK/6HLDBeFDEC9/dGK8++Lovl6
> //qZ340LOPFlgT2kYy9E5h/yX469fhtsWhBCv2K47fWwkMS0S/0r4SQnCkbt2R2c
> 4dQjkoldhw6rNMBTUmwvhSlL30KsT/msWTZiX7DW/YjfOzezEJzy+mYyKp9Sk7ba
> 1fOiBXORk7mNOs7sTYTvje3sqEGpGTOLP08cY/RCEvl6bG8mHkPqwiojq+3biHFP
> RsoBVu1f5cbnU7Wq0gPNdVnQssnEQDadyTX8gT0Wze7PuVyaZT2mXFZBKzSHuLy2
> sJKN
> =oPSo
> -----END PGP SIGNATURE-----
>
>
>
>
> --
> 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
--------------080602060402000605060602
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
Today we have first-eligible-height (nLockTime), and mempool
expiration measured from this height would work for the goals being
discussed, no fork or protocol rev.<br>
<br>
With first-eligible-height and last-eligible-height, creator could
choose a lifetime shorter than the max, and in addition, lock the
whole thing until some point in the future.<br>
<br>
<br>
<div class="moz-cite-prefix">On 8/6/2014 9:15 AM, Jeff Garzik wrote:<br>
</div>
<blockquote
cite="mid:CAJHLa0OQJEvQht_chF1gVG_BOwp=DW0zOOo3VE_acZonsSguWw@mail.gmail.com"
type="cite">
<div dir="ltr">A fork is not necessarily required, if you are
talking about information that deals primarily with
pre-consensus mempool behavior. You can make a "network TX"
with some information that is digitally signed, yet discarded
before it reaches miners.<br>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Wed, Aug 6, 2014 at 11:42 AM, Peter
Todd <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:pete@petertodd.org" target="_blank">pete@petertodd.org</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">-----BEGIN
PGP SIGNED MESSAGE-----<br>
Hash: SHA256<br>
<div class=""><br>
<br>
<br>
On 6 August 2014 08:17:02 GMT-07:00, Christian Decker <<a
moz-do-not-send="true"
href="mailto:decker.christian@gmail.com">decker.christian@gmail.com</a>>
wrote:<br>
>+1 for the new field, overloading fields with new
meaning is definitely<br>
>not<br>
>a good idea.<br>
<br>
</div>
To add a new field the best way to do it is create a new,
parallel, tx format where fields are committed by merkle
radix tree in an extensible and provable way. You'd then
commit to that tree with a mandatory OP_RETURN output in the
last txout, or with a new merkle root.<br>
<br>
Changing the tx format itself in a hard-fork is needlessly
disruptive, and in this case, wastes opportunities for
improvement.<br>
-----BEGIN PGP SIGNATURE-----<br>
Version: APG v1.1.1<br>
<br>
iQFQBAEBCAA6BQJT4kzQMxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8<br>
cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhamzCAC+zRaXRodP63+ke3K+<br>
Viapiepvk4uIOlqxqtMB2O0zWcyu2+xCJDiRPykK/6HLDBeFDEC9/dGK8++Lovl6<br>
//qZ340LOPFlgT2kYy9E5h/yX469fhtsWhBCv2K47fWwkMS0S/0r4SQnCkbt2R2c<br>
4dQjkoldhw6rNMBTUmwvhSlL30KsT/msWTZiX7DW/YjfOzezEJzy+mYyKp9Sk7ba<br>
1fOiBXORk7mNOs7sTYTvje3sqEGpGTOLP08cY/RCEvl6bG8mHkPqwiojq+3biHFP<br>
RsoBVu1f5cbnU7Wq0gPNdVnQssnEQDadyTX8gT0Wze7PuVyaZT2mXFZBKzSHuLy2<br>
sJKN<br>
=oPSo<br>
-----END PGP SIGNATURE-----<br>
<br>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
Jeff Garzik<br>
Bitcoin core developer and open source evangelist<br>
BitPay, Inc. <a moz-do-not-send="true"
href="https://bitpay.com/" target="_blank">https://bitpay.com/</a>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">------------------------------------------------------------------------------
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.
<a class="moz-txt-link-freetext" href="http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk">http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk</a></pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Bitcoin-development mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-development@lists.sourceforge.net</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/bitcoin-development">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a>
</pre>
</blockquote>
<br>
</body>
</html>
--------------080602060402000605060602--
|
