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
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
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.no...@gmail.com wrote:
The aheaders message is required to make use of the data by SPV clients.
This could be in
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
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,
5 matches
Mail list logo
