[Bitcoin-development] BIP draft - Auxiliary Header Format
tier.nolan at gmail.com
Mon Nov 10 21:21:58 UTC 2014
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 at 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 at gmail.com>
>> 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 at gmail.com>
>> > 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
>> > in the block that has the digest of the auxiliary header. This means
>> > 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
>> > accident, then one could end up blocking the other.
>> > On one end of the scale is adding a transaction with a few thousand
>> > into the block chain. The signatures for locktime restricted
>> > 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
>> > to manage their UTXO entry. Miners can split a zero value output into
>> > 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
>> > that pay to a particular address but the transaction would be
>> > 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 at gmail.com>
>> >> I created a draft BIP detailing a way to add auxiliary headers to
>> >> in a bandwidth efficient way. The overhead per auxiliary header is
>> >> 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
>> >> the hash of the auxiliary header.
>> >> It makes use of the fact that the last transaction in the block has a
>> >> less complex Merkle branch than the other transactions.
>> > _______________________________________________
>> > Bitcoin-development mailing list
>> > Bitcoin-development at lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the bitcoin-dev