public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Tier Nolan <tier.nolan@gmail.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] BIP draft - Auxiliary Header Format
Date: Mon, 10 Nov 2014 23:39:23 +0000	[thread overview]
Message-ID: <CAE-z3OUzjYzL0j6zi59jwV9oWQ=85xcG2Hh2Tc0y5Ru2couQ9w@mail.gmail.com> (raw)
In-Reply-To: <CAE-z3OWULmtZY=VS8xWxiPJ3sA7kCALBgW2T6kWjMXrVVBW4Vg@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 4938 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 6798 bytes --]

  reply	other threads:[~2014-11-10 23:39 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-08 23:45 [Bitcoin-development] BIP draft - Auxiliary Header Format Tier Nolan
2014-11-10  0:39 ` Tier Nolan
2014-11-10  0:52   ` Gregory Maxwell
2014-11-10 11:42     ` Tier Nolan
2014-11-10 21:21       ` Tier Nolan
2014-11-10 23:39         ` Tier Nolan [this message]
2014-11-12 19:00           ` Tier Nolan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAE-z3OUzjYzL0j6zi59jwV9oWQ=85xcG2Hh2Tc0y5Ru2couQ9w@mail.gmail.com' \
    --to=tier.nolan@gmail.com \
    --cc=bitcoin-development@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox