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 00:39:20 +0000 [thread overview]
Message-ID: <CAE-z3OXr0wudFe2qVs0i8Y0PNtHUmfS_PDiOH5UeRyf1LnJC2A@mail.gmail.com> (raw)
In-Reply-To: <CAE-z3OW3=mBNC_p911y6HspF4r9g=sSPM2S-mmBTm+=hoxDprA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2329 bytes --]
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
>
>
[-- Attachment #2: Type: text/html, Size: 2968 bytes --]
next prev parent reply other threads:[~2014-11-10 0:39 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-08 23:45 Tier Nolan
2014-11-10 0:39 ` Tier Nolan [this message]
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
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-z3OXr0wudFe2qVs0i8Y0PNtHUmfS_PDiOH5UeRyf1LnJC2A@mail.gmail.com \
--to=tier.nolan@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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