summaryrefslogtreecommitdiff
path: root/82/20030b89f54027b7b9f51d52f9ca3d5b6276ae
blob: 56e84e389346cd69734b1dd0699821a67479c456 (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
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
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <tier.nolan@gmail.com>) id 1XnyYU-0008Rs-41
	for bitcoin-development@lists.sourceforge.net;
	Mon, 10 Nov 2014 23:39:30 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.216.179 as permitted sender)
	client-ip=209.85.216.179; envelope-from=tier.nolan@gmail.com;
	helo=mail-qc0-f179.google.com; 
Received: from mail-qc0-f179.google.com ([209.85.216.179])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1XnyYS-0002Tj-JX
	for bitcoin-development@lists.sourceforge.net;
	Mon, 10 Nov 2014 23:39:30 +0000
Received: by mail-qc0-f179.google.com with SMTP id o8so6565997qcw.24
	for <bitcoin-development@lists.sourceforge.net>;
	Mon, 10 Nov 2014 15:39:23 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.140.29.226 with SMTP id b89mr24905130qgb.94.1415662763143;
	Mon, 10 Nov 2014 15:39:23 -0800 (PST)
Received: by 10.140.41.18 with HTTP; Mon, 10 Nov 2014 15:39:23 -0800 (PST)
In-Reply-To: <CAE-z3OWULmtZY=VS8xWxiPJ3sA7kCALBgW2T6kWjMXrVVBW4Vg@mail.gmail.com>
References: <CAE-z3OW3=mBNC_p911y6HspF4r9g=sSPM2S-mmBTm+=hoxDprA@mail.gmail.com>
	<CAE-z3OXr0wudFe2qVs0i8Y0PNtHUmfS_PDiOH5UeRyf1LnJC2A@mail.gmail.com>
	<CAAS2fgQanj6QN3UFvO8Lw=9ZQgLM3wzZknVQ3hbMxyODyEUF_w@mail.gmail.com>
	<CAE-z3OV9xDvJ3VY5q6sayZGc4Zr3cxszjGMs7AXo7FRWJSLy7Q@mail.gmail.com>
	<CAE-z3OWULmtZY=VS8xWxiPJ3sA7kCALBgW2T6kWjMXrVVBW4Vg@mail.gmail.com>
Date: Mon, 10 Nov 2014 23:39:23 +0000
Message-ID: <CAE-z3OUzjYzL0j6zi59jwV9oWQ=85xcG2Hh2Tc0y5Ru2couQ9w@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=001a113aac4a1e7adb050789ace3
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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(tier.nolan[at]gmail.com)
	-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: 1XnyYS-0002Tj-JX
Subject: Re: [Bitcoin-development] BIP draft - Auxiliary Header Format
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: Mon, 10 Nov 2014 23:39:30 -0000

--001a113aac4a1e7adb050789ace3
Content-Type: text/plain; charset=UTF-8

I have added the network BIP too.  It only has the aheaders message and the
extra field for getheaders.

https://github.com/TierNolan/bips/blob/aux_header/bip-aux-header-network.mediawiki

The transaction definitions are still at:

https://github.com/TierNolan/bips/blob/aux_header/bip-aux-header.mediawiki

On Mon, Nov 10, 2014 at 9:21 PM, Tier Nolan <tier.nolan@gmail.com> wrote:

> I updated the BIP to cover only the specification of the transactions that
> need to be added.  I will create a network BIP tomorrow.
>
> On Mon, Nov 10, 2014 at 11:42 AM, Tier Nolan <tier.nolan@gmail.com> wrote:
>
>> The aheaders message is required to make use of the data by SPV clients.
>> This could be in a separate BIP though.  I wanted to show that the merkle
>> path to the aux-header transaction could be efficiently encoded, but a
>> reference to the other BIP would be sufficient.
>>
>> For the other messages, the problem is that the hash of the aux header is
>> part of the block, but the aux header itself is not.  That means that the
>> aux header has to be sent for validation of the block.
>>
>> I will change it so that the entire aux-header is encoded in the block.
>> I think encoding the hash in the final transaction and the full aux-header
>> in the 2nd last one is the best way to do it.  This has the added advantage
>> of reducing the changes to block data storage, since the aux-header doesn't
>> have to be stored separately.
>>
>>
>> On Mon, Nov 10, 2014 at 12:52 AM, Gregory Maxwell <gmaxwell@gmail.com>
>> wrote:
>>
>>> Some initial comments...
>>>
>>> Tying in the protocol changes is really confusing and the fact that
>>> they seem to be required out the gates would seemingly make this much
>>> harder to deploy.   Is there a need to do that? Why can't the p2p part
>>> be entirely separate from the comitted data?
>>>
>>> On Mon, Nov 10, 2014 at 12:39 AM, Tier Nolan <tier.nolan@gmail.com>
>>> wrote:
>>> > I made some changes to the draft.  The merkleblock now has the
>>> auxiliary
>>> > header information too.
>>> >
>>> > There is a tradeoff between overhead and delayed transactions.  Is
>>> 12.5%
>>> > transactions being delayed to the next block unacceptable?  Would
>>> adding
>>> > padding transactions be an improvement?
>>> >
>>> > Creating the "seed" transactions is an implementation headache.
>>> >
>>> > Each node needs to have control over an UTXO to create the final
>>> transaction
>>> > in the block that has the digest of the auxiliary header.  This means
>>> that
>>> > it is not possible to simply start a node and have it mine.  It has to
>>> > somehow be given the private key.  If two nodes were given the same
>>> key by
>>> > accident, then one could end up blocking the other.
>>> >
>>> > On one end of the scale is adding a transaction with a few thousand
>>> outputs
>>> > into the block chain.  The signatures for locktime restricted
>>> transactions
>>> > that spend those outputs could be hard-coded into the software.  This
>>> is the
>>> > easiest to implement, but would mean a large table of signatures.  The
>>> > person who generates the signature list would have to be trusted not to
>>> > spend the outputs early.
>>> >
>>> > The other end of the scale means that mining nodes need to include a
>>> wallets
>>> > to manage their UTXO entry.  Miners can split a zero value output into
>>> lots
>>> > of outputs, if they wish.
>>> >
>>> > A middle ground would be for nodes to be able to detect the special
>>> > transactions and use them.  A server could send out timelocked
>>> transactions
>>> > that pay to a particular address but the transaction would be
>>> timelocked.
>>> > The private key for the output would be known.  However, miners who
>>> mine
>>> > version 2 blocks wouldn't be able to spend them early.
>>> >
>>> >
>>> > On Sat, Nov 8, 2014 at 11:45 PM, Tier Nolan <tier.nolan@gmail.com>
>>> wrote:
>>> >>
>>> >> I created a draft BIP detailing a way to add auxiliary headers to
>>> Bitcoin
>>> >> in a bandwidth efficient way.  The overhead per auxiliary header is
>>> only
>>> >> around 104 bytes per header.  This is much smaller than would be
>>> required by
>>> >> embedding the hash of the header in the coinbase of the block.
>>> >>
>>> >> It is a soft fork and it uses the last transaction in the block to
>>> store
>>> >> the hash of the auxiliary header.
>>> >>
>>> >> It makes use of the fact that the last transaction in the block has a
>>> much
>>> >> less complex Merkle branch than the other transactions.
>>> >>
>>> >>
>>> https://github.com/TierNolan/bips/blob/aux_header/bip-aux-header.mediawiki
>>> >>
>>> >
>>> >
>>> >
>>> ------------------------------------------------------------------------------
>>> >
>>> > _______________________________________________
>>> > Bitcoin-development mailing list
>>> > Bitcoin-development@lists.sourceforge.net
>>> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>> >
>>>
>>
>>
>

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

<div dir=3D"ltr">I have added the network BIP too.=C2=A0 It only has the ah=
eaders message and the extra field for getheaders.<br><br><a href=3D"https:=
//github.com/TierNolan/bips/blob/aux_header/bip-aux-header-network.mediawik=
i">https://github.com/TierNolan/bips/blob/aux_header/bip-aux-header-network=
.mediawiki</a><br><br>The transaction definitions are still at:<br><br><a h=
ref=3D"https://github.com/TierNolan/bips/blob/aux_header/bip-aux-header.med=
iawiki">https://github.com/TierNolan/bips/blob/aux_header/bip-aux-header.me=
diawiki</a><br></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Mon, Nov 10, 2014 at 9:21 PM, Tier Nolan <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:tier.nolan@gmail.com" target=3D"_blank">tier.nolan@gmail.com</=
a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0=
 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">I u=
pdated the BIP to cover only the specification of the transactions that nee=
d to be added.=C2=A0 I will create a network BIP tomorrow.<br></div><div cl=
ass=3D"HOEnZb"><div class=3D"h5"><div class=3D"gmail_extra"><br><div class=
=3D"gmail_quote">On Mon, Nov 10, 2014 at 11:42 AM, Tier Nolan <span dir=3D"=
ltr">&lt;<a href=3D"mailto:tier.nolan@gmail.com" target=3D"_blank">tier.nol=
an@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div d=
ir=3D"ltr"><div><div>The aheaders message is required to make use of the da=
ta by SPV clients.=C2=A0 This could be in a separate BIP though.=C2=A0 I wa=
nted to show that the merkle path to the aux-header transaction could be ef=
ficiently encoded, but a reference to the other BIP would be sufficient.<br=
><br></div>For the other messages, the problem is that the hash of the aux =
header is part of the block, but the aux header itself is not.=C2=A0 That m=
eans that the aux header has to be sent for validation of the block.<br><br=
></div>I will change it so that the entire aux-header is encoded in the blo=
ck.=C2=A0 I think encoding the hash in the final transaction and the full a=
ux-header in the 2nd last one is the best way to do it.=C2=A0 This has the =
added advantage of reducing the changes to block data storage, since the au=
x-header doesn&#39;t have to be stored separately.<div><div><br><div><br><d=
iv><div><div><div class=3D"gmail_extra"><div class=3D"gmail_quote">On Mon, =
Nov 10, 2014 at 12:52 AM, Gregory Maxwell <span dir=3D"ltr">&lt;<a href=3D"=
mailto:gmaxwell@gmail.com" target=3D"_blank">gmaxwell@gmail.com</a>&gt;</sp=
an> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex">Some initial comments...<br>
<br>
Tying in the protocol changes is really confusing and the fact that<br>
they seem to be required out the gates would seemingly make this much<br>
harder to deploy.=C2=A0 =C2=A0Is there a need to do that? Why can&#39;t the=
 p2p part<br>
be entirely separate from the comitted data?<br>
<div><div><br>
On Mon, Nov 10, 2014 at 12:39 AM, Tier Nolan &lt;<a href=3D"mailto:tier.nol=
an@gmail.com" target=3D"_blank">tier.nolan@gmail.com</a>&gt; wrote:<br>
&gt; I made some changes to the draft.=C2=A0 The merkleblock now has the au=
xiliary<br>
&gt; header information too.<br>
&gt;<br>
&gt; There is a tradeoff between overhead and delayed transactions.=C2=A0 I=
s 12.5%<br>
&gt; transactions being delayed to the next block unacceptable?=C2=A0 Would=
 adding<br>
&gt; padding transactions be an improvement?<br>
&gt;<br>
&gt; Creating the &quot;seed&quot; transactions is an implementation headac=
he.<br>
&gt;<br>
&gt; Each node needs to have control over an UTXO to create the final trans=
action<br>
&gt; in the block that has the digest of the auxiliary header.=C2=A0 This m=
eans that<br>
&gt; it is not possible to simply start a node and have it mine.=C2=A0 It h=
as to<br>
&gt; somehow be given the private key.=C2=A0 If two nodes were given the sa=
me key by<br>
&gt; accident, then one could end up blocking the other.<br>
&gt;<br>
&gt; On one end of the scale is adding a transaction with a few thousand ou=
tputs<br>
&gt; into the block chain.=C2=A0 The signatures for locktime restricted tra=
nsactions<br>
&gt; that spend those outputs could be hard-coded into the software.=C2=A0 =
This is the<br>
&gt; easiest to implement, but would mean a large table of signatures.=C2=
=A0 The<br>
&gt; person who generates the signature list would have to be trusted not t=
o<br>
&gt; spend the outputs early.<br>
&gt;<br>
&gt; The other end of the scale means that mining nodes need to include a w=
allets<br>
&gt; to manage their UTXO entry.=C2=A0 Miners can split a zero value output=
 into lots<br>
&gt; of outputs, if they wish.<br>
&gt;<br>
&gt; A middle ground would be for nodes to be able to detect the special<br=
>
&gt; transactions and use them.=C2=A0 A server could send out timelocked tr=
ansactions<br>
&gt; that pay to a particular address but the transaction would be timelock=
ed.<br>
&gt; The private key for the output would be known.=C2=A0 However, miners w=
ho mine<br>
&gt; version 2 blocks wouldn&#39;t be able to spend them early.<br>
&gt;<br>
&gt;<br>
&gt; On Sat, Nov 8, 2014 at 11:45 PM, Tier Nolan &lt;<a href=3D"mailto:tier=
.nolan@gmail.com" target=3D"_blank">tier.nolan@gmail.com</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; I created a draft BIP detailing a way to add auxiliary headers to =
Bitcoin<br>
&gt;&gt; in a bandwidth efficient way.=C2=A0 The overhead per auxiliary hea=
der is only<br>
&gt;&gt; around 104 bytes per header.=C2=A0 This is much smaller than would=
 be required by<br>
&gt;&gt; embedding the hash of the header in the coinbase of the block.<br>
&gt;&gt;<br>
&gt;&gt; It is a soft fork and it uses the last transaction in the block to=
 store<br>
&gt;&gt; the hash of the auxiliary header.<br>
&gt;&gt;<br>
&gt;&gt; It makes use of the fact that the last transaction in the block ha=
s a much<br>
&gt;&gt; less complex Merkle branch than the other transactions.<br>
&gt;&gt;<br>
&gt;&gt; <a href=3D"https://github.com/TierNolan/bips/blob/aux_header/bip-a=
ux-header.mediawiki" target=3D"_blank">https://github.com/TierNolan/bips/bl=
ob/aux_header/bip-aux-header.mediawiki</a><br>
&gt;&gt;<br>
&gt;<br>
&gt;<br>
</div></div><div><div>&gt; ------------------------------------------------=
------------------------------<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; Bitcoin-development mailing list<br>
&gt; <a href=3D"mailto:Bitcoin-development@lists.sourceforge.net" target=3D=
"_blank">Bitcoin-development@lists.sourceforge.net</a><br>
&gt; <a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-develo=
pment" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitco=
in-development</a><br>
&gt;<br>
</div></div></blockquote></div><br></div></div></div></div></div></div></di=
v></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>

--001a113aac4a1e7adb050789ace3--