path: root/9c/4eff3f57a1eaeedc77a17bcd364800fcc74ba8

Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <tier.nolan@gmail.com>) id 1XodA0-0001Fr-4l
	for bitcoin-development@lists.sourceforge.net;
	Wed, 12 Nov 2014 19:00:56 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.216.175 as permitted sender)
	client-ip=209.85.216.175; envelope-from=tier.nolan@gmail.com;
	helo=mail-qc0-f175.google.com; 
Received: from mail-qc0-f175.google.com ([209.85.216.175])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1Xod9y-0002zt-F3
	for bitcoin-development@lists.sourceforge.net;
	Wed, 12 Nov 2014 19:00:56 +0000
Received: by mail-qc0-f175.google.com with SMTP id b13so10863882qcw.20
	for <bitcoin-development@lists.sourceforge.net>;
	Wed, 12 Nov 2014 11:00:49 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.224.151.207 with SMTP id d15mr64415902qaw.4.1415818849013;
	Wed, 12 Nov 2014 11:00:49 -0800 (PST)
Received: by 10.140.41.18 with HTTP; Wed, 12 Nov 2014 11:00:48 -0800 (PST)
In-Reply-To: <CAE-z3OUzjYzL0j6zi59jwV9oWQ=85xcG2Hh2Tc0y5Ru2couQ9w@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>
	<CAE-z3OUzjYzL0j6zi59jwV9oWQ=85xcG2Hh2Tc0y5Ru2couQ9w@mail.gmail.com>
Date: Wed, 12 Nov 2014 19:00:48 +0000
Message-ID: <CAE-z3OVtByTokf9KzpUu116FRyUA_6y_3Kvem-gQJVAeoCMCzg@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=089e015373b68fd88e0507ae034c
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: 1Xod9y-0002zt-F3
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: Wed, 12 Nov 2014 19:00:56 -0000

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

I was going to look into creating reference code for this.

The first BIP could be reasonably easy, since it just needs to check for
the presence of the 2 special transactions.

That would mean that it doesn't actually create version 3 blocks at all.

Ideally, I would make it easy for miners to mine version 3 blocks.  I could
add a new field to the getblocktemplate that has the 2 transactions ready
to go.

What do pools actually use for generating blocks.  I assume it's custom
code but that they use (near) standard software for the memory pool?


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

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

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

<div dir=3D"ltr"><div><div><div>I was going to look into creating reference=
 code for this.<br><br></div>The first BIP could be reasonably easy, since =
it just needs to check for the presence of the 2 special transactions.<br><=
br></div><div>That would mean that it doesn&#39;t actually create version 3=
 blocks at all.<br></div><div><br></div>Ideally, I would make it easy for m=
iners to mine version 3 blocks.=C2=A0 I could add a new field to the getblo=
cktemplate that has the 2 transactions ready to go.<br><br></div><div>What =
do pools actually use for generating blocks.=C2=A0 I assume it&#39;s custom=
 code but that they use (near) standard software for the memory pool?<br></=
div><br></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On =
Mon, Nov 10, 2014 at 11:39 PM, Tier Nolan <span dir=3D"ltr">&lt;<a href=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 have ad=
ded the network BIP too.=C2=A0 It only has the aheaders message and the ext=
ra field for getheaders.<br><br><a href=3D"https://github.com/TierNolan/bip=
s/blob/aux_header/bip-aux-header-network.mediawiki" target=3D"_blank">https=
://github.com/TierNolan/bips/blob/aux_header/bip-aux-header-network.mediawi=
ki</a><br><br>The transaction definitions are still at:<br><br><a href=3D"h=
ttps://github.com/TierNolan/bips/blob/aux_header/bip-aux-header.mediawiki" =
target=3D"_blank">https://github.com/TierNolan/bips/blob/aux_header/bip-aux=
-header.mediawiki</a><br></div><div class=3D"HOEnZb"><div class=3D"h5"><div=
 class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Mon, Nov 10, 2014 =
at 9:21 PM, Tier Nolan <span dir=3D"ltr">&lt;<a href=3D"mailto:tier.nolan@g=
mail.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 updated the BIP to cover o=
nly the specification of the transactions that need to be added.=C2=A0 I wi=
ll create a network BIP tomorrow.<br></div><div><div><div class=3D"gmail_ex=
tra"><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.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;padd=
ing-left:1ex"><div dir=3D"ltr"><div><div>The aheaders message is required t=
o make use of the data by SPV clients.=C2=A0 This could be in a separate BI=
P though.=C2=A0 I wanted to show that the merkle path to the aux-header tra=
nsaction could be efficiently encoded, but a reference to the other BIP wou=
ld 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 means 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 i=
s encoded in the block.=C2=A0 I think encoding the hash in the final transa=
ction and the full aux-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 s=
torage, since the aux-header doesn&#39;t have to be stored separately.<div>=
<div><br><div><br><div><div><div><div class=3D"gmail_extra"><div class=3D"g=
mail_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@g=
mail.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">Some ini=
tial 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>
</div></div></blockquote></div><br></div>

--089e015373b68fd88e0507ae034c--