Re: [Bitcoin-development] BIP draft - Auxiliary Header Format

2014-11-12 Thread Tier Nolan
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 min

Re: [Bitcoin-development] BIP draft - Auxiliary Header Format

2014-11-10 Thread Tier Nolan
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.me

Re: [Bitcoin-development] BIP draft - Auxiliary Header Format

2014-11-10 Thread Tier Nolan
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 wrote: > The aheaders message is required to make use of the data by SPV clients. > This could be in a separate BIP tho

Re: [Bitcoin-development] BIP draft - Auxiliary Header Format

2014-11-10 Thread Tier Nolan
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 prob

Re: [Bitcoin-development] BIP draft - Auxiliary Header Format

2014-11-09 Thread Gregory Maxwell
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, 20

Re: [Bitcoin-development] BIP draft - Auxiliary Header Format

2014-11-09 Thread Tier Nolan
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 "

[Bitcoin-development] BIP draft - Auxiliary Header Format

2014-11-08 Thread Tier Nolan
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 sof