summaryrefslogtreecommitdiff
path: root/d0/d8db2caa7ec99e72e2f73638f4f7f11842b4ae
blob: dca0797a383d604b6d5b3ad29645ff58a84c3d19 (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
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 1XF3sW-0004sP-3Q
	for bitcoin-development@lists.sourceforge.net;
	Wed, 06 Aug 2014 16:15:52 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of bitpay.com
	designates 209.85.223.179 as permitted sender)
	client-ip=209.85.223.179; envelope-from=jgarzik@bitpay.com;
	helo=mail-ie0-f179.google.com; 
Received: from mail-ie0-f179.google.com ([209.85.223.179])
	by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1XF3sQ-0004lj-Ex
	for bitcoin-development@lists.sourceforge.net;
	Wed, 06 Aug 2014 16:15:52 +0000
Received: by mail-ie0-f179.google.com with SMTP id rl12so3156435iec.38
	for <bitcoin-development@lists.sourceforge.net>;
	Wed, 06 Aug 2014 09:15:41 -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=AZNA4Qlzrx8NjjVywCx1HcRDw3PwA9951ph4NQxmsDE=;
	b=IFnYgUa0NcvkOSZkC3RWPKsOG0dTKM5YOF2tnsSZwgesI99yWDO2o0GgAclzbegAKI
	vcvTkTW5aFfkC5qckoqr3Li0+3pPoLeqcbRI8ZIWHae5hTO/I8ZqYGw5AIrDIi5W2kkf
	UPYRJUqENE8KYoXcS7J4Wtf1HRe1zJFvd2LU+e3djeNjsZmX3nZEDDCwwun0taIA+J7p
	hAdKeQ7+TO+iPtrMAGy1i0ks1Vrz8ZOeutPTE1pYBVI8J0hI1EWWcFzTfUBOGBPx8wHM
	GR6K9eqblIvm8JlzQqnqZIrIz6/hFrkVMgEsol69EWcyHC77ATLhtYU/JTRnfeA1xVjh
	bxTg==
X-Gm-Message-State: ALoCoQmUixCJQYwDvwlATrvQ3ez1lw2bIBg1Vp4KrfDup72CA1ZLRnpa++Y6TlUknDnr4APVHAkg
X-Received: by 10.42.48.197 with SMTP id t5mr16568466icf.11.1407341740968;
	Wed, 06 Aug 2014 09:15:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.10.78 with HTTP; Wed, 6 Aug 2014 09:15:20 -0700 (PDT)
In-Reply-To: <63a80796-609e-43f5-9280-4cd8cf5d2648@email.android.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>
	<63a80796-609e-43f5-9280-4cd8cf5d2648@email.android.com>
From: Jeff Garzik <jgarzik@bitpay.com>
Date: Wed, 6 Aug 2014 12:15:20 -0400
Message-ID: <CAJHLa0OQJEvQht_chF1gVG_BOwp=DW0zOOo3VE_acZonsSguWw@mail.gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary=90e6ba6e8e3e8c639e04fff84889
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: 1XF3sQ-0004lj-Ex
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 16:15:52 -0000

--90e6ba6e8e3e8c639e04fff84889
Content-Type: text/plain; charset=UTF-8

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> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
>
>
> On 6 August 2014 08:17:02 GMT-07:00, Christian Decker <
> 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/

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

<div dir=3D"ltr">A fork is not necessarily required, if you are talking abo=
ut information that deals primarily with pre-consensus mempool behavior.=C2=
=A0 You can make a &quot;network TX&quot; with some information that is dig=
itally signed, yet discarded before it reaches miners.<br>

</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Wed,=
 Aug 6, 2014 at 11:42 AM, Peter Todd <span dir=3D"ltr">&lt;<a href=3D"mailt=
o:pete@petertodd.org" target=3D"_blank">pete@petertodd.org</a>&gt;</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">-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA256<br>
<div class=3D""><br>
<br>
<br>
On 6 August 2014 08:17:02 GMT-07:00, Christian Decker &lt;<a href=3D"mailto=
:decker.christian@gmail.com">decker.christian@gmail.com</a>&gt; wrote:<br>
&gt;+1 for the new field, overloading fields with new meaning is definitely=
<br>
&gt;not<br>
&gt;a good idea.<br>
<br>
</div>To add a new field the best way to do it is create a new, parallel, t=
x format where fields are committed by merkle radix tree in an extensible a=
nd provable way. You&#39;d then commit to that tree with a mandatory OP_RET=
URN 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>
=3DoPSo<br>
-----END PGP SIGNATURE-----<br>
<br>
</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>

--90e6ba6e8e3e8c639e04fff84889--