diff options
| author | Tier Nolan <tier.nolan@gmail.com> | 2014-11-10 11:42:17 +0000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2014-11-10 11:42:24 +0000 |
| commit | 482ee395ff256c3d08e11e058b6cdfa07aa984b1 (patch) | |
| tree | 04d78ed4324eb2107c59519e26f179de48244159 | |
| parent | d7de6d8b4c8b2a2b3a66f1cce13b16193ef2199d (diff) | |
| download | pi-bitcoindev-482ee395ff256c3d08e11e058b6cdfa07aa984b1.tar.gz pi-bitcoindev-482ee395ff256c3d08e11e058b6cdfa07aa984b1.zip | |
Re: [Bitcoin-development] BIP draft - Auxiliary Header Format
| -rw-r--r-- | 09/fde8ba09dbb7eea27f6d0ac3149b201ee949bf | 286 |
1 files changed, 286 insertions, 0 deletions
diff --git a/09/fde8ba09dbb7eea27f6d0ac3149b201ee949bf b/09/fde8ba09dbb7eea27f6d0ac3149b201ee949bf new file mode 100644 index 000000000..25843494e --- /dev/null +++ b/09/fde8ba09dbb7eea27f6d0ac3149b201ee949bf @@ -0,0 +1,286 @@ +Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] + helo=mx.sourceforge.net) + by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) + (envelope-from <tier.nolan@gmail.com>) id 1XnnMW-0004U8-HQ + for bitcoin-development@lists.sourceforge.net; + Mon, 10 Nov 2014 11:42:24 +0000 +Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com + designates 209.85.216.45 as permitted sender) + client-ip=209.85.216.45; envelope-from=tier.nolan@gmail.com; + helo=mail-qa0-f45.google.com; +Received: from mail-qa0-f45.google.com ([209.85.216.45]) + by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) + (Exim 4.76) id 1XnnMV-0006hQ-7e + for bitcoin-development@lists.sourceforge.net; + Mon, 10 Nov 2014 11:42:24 +0000 +Received: by mail-qa0-f45.google.com with SMTP id dc16so5141839qab.32 + for <bitcoin-development@lists.sourceforge.net>; + Mon, 10 Nov 2014 03:42:17 -0800 (PST) +MIME-Version: 1.0 +X-Received: by 10.140.40.239 with SMTP id x102mr40406190qgx.69.1415619737225; + Mon, 10 Nov 2014 03:42:17 -0800 (PST) +Received: by 10.140.41.18 with HTTP; Mon, 10 Nov 2014 03:42:17 -0800 (PST) +In-Reply-To: <CAAS2fgQanj6QN3UFvO8Lw=9ZQgLM3wzZknVQ3hbMxyODyEUF_w@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> +Date: Mon, 10 Nov 2014 11:42:17 +0000 +Message-ID: <CAE-z3OV9xDvJ3VY5q6sayZGc4Zr3cxszjGMs7AXo7FRWJSLy7Q@mail.gmail.com> +From: Tier Nolan <tier.nolan@gmail.com> +To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net> +Content-Type: multipart/alternative; boundary=001a11c12a1a930f3a05077fa7e6 +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: 1XnnMV-0006hQ-7e +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 11:42:24 -0000 + +--001a11c12a1a930f3a05077fa7e6 +Content-Type: text/plain; charset=UTF-8 + +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 +> > +> + +--001a11c12a1a930f3a05077fa7e6 +Content-Type: text/html; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr"><div><div>The aheaders message is required to make use of = +the data by SPV clients.=C2=A0 This could be in a separate BIP though.=C2= +=A0 I wanted to show that the merkle path to the aux-header transaction cou= +ld be efficiently encoded, but a reference to the other BIP would be suffic= +ient.<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 means that the aux header has to be sent for validation of the blo= +ck.<br><br></div>I will change it so that the entire aux-header is encoded = +in the block.=C2=A0 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.=C2=A0 Thi= +s has the added advantage of reducing the changes to block data storage, si= +nce the aux-header doesn't have to be stored separately.<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"><<a href=3D"= +mailto:gmaxwell@gmail.com" target=3D"_blank">gmaxwell@gmail.com</a>></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'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 <<a href=3D"mailto:tier.nol= +an@gmail.com" target=3D"_blank">tier.nolan@gmail.com</a>> wrote:<br> +> I made some changes to the draft.=C2=A0 The merkleblock now has the au= +xiliary<br> +> header information too.<br> +><br> +> There is a tradeoff between overhead and delayed transactions.=C2=A0 I= +s 12.5%<br> +> transactions being delayed to the next block unacceptable?=C2=A0 Would= + adding<br> +> padding transactions be an improvement?<br> +><br> +> Creating the "seed" transactions is an implementation headac= +he.<br> +><br> +> Each node needs to have control over an UTXO to create the final trans= +action<br> +> in the block that has the digest of the auxiliary header.=C2=A0 This m= +eans that<br> +> it is not possible to simply start a node and have it mine.=C2=A0 It h= +as to<br> +> somehow be given the private key.=C2=A0 If two nodes were given the sa= +me key by<br> +> accident, then one could end up blocking the other.<br> +><br> +> On one end of the scale is adding a transaction with a few thousand ou= +tputs<br> +> into the block chain.=C2=A0 The signatures for locktime restricted tra= +nsactions<br> +> that spend those outputs could be hard-coded into the software.=C2=A0 = +This is the<br> +> easiest to implement, but would mean a large table of signatures.=C2= +=A0 The<br> +> person who generates the signature list would have to be trusted not t= +o<br> +> spend the outputs early.<br> +><br> +> The other end of the scale means that mining nodes need to include a w= +allets<br> +> to manage their UTXO entry.=C2=A0 Miners can split a zero value output= + into lots<br> +> of outputs, if they wish.<br> +><br> +> A middle ground would be for nodes to be able to detect the special<br= +> +> transactions and use them.=C2=A0 A server could send out timelocked tr= +ansactions<br> +> that pay to a particular address but the transaction would be timelock= +ed.<br> +> The private key for the output would be known.=C2=A0 However, miners w= +ho mine<br> +> version 2 blocks wouldn't be able to spend them early.<br> +><br> +><br> +> On Sat, Nov 8, 2014 at 11:45 PM, Tier Nolan <<a href=3D"mailto:tier= +.nolan@gmail.com" target=3D"_blank">tier.nolan@gmail.com</a>> wrote:<br> +>><br> +>> I created a draft BIP detailing a way to add auxiliary headers to = +Bitcoin<br> +>> in a bandwidth efficient way.=C2=A0 The overhead per auxiliary hea= +der is only<br> +>> around 104 bytes per header.=C2=A0 This is much smaller than would= + be required by<br> +>> embedding the hash of the header in the coinbase of the block.<br> +>><br> +>> It is a soft fork and it uses the last transaction in the block to= + store<br> +>> the hash of the auxiliary header.<br> +>><br> +>> It makes use of the fact that the last transaction in the block ha= +s a much<br> +>> less complex Merkle branch than the other transactions.<br> +>><br> +>> <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> +>><br> +><br> +><br> +</div></div><div><div>> ------------------------------------------------= +------------------------------<br> +><br> +> _______________________________________________<br> +> Bitcoin-development mailing list<br> +> <a href=3D"mailto:Bitcoin-development@lists.sourceforge.net" target=3D= +"_blank">Bitcoin-development@lists.sourceforge.net</a><br> +> <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> +><br> +</div></div></blockquote></div><br></div></div></div></div></div></div> + +--001a11c12a1a930f3a05077fa7e6-- + + |