Thank you for your feedback AJ and Riccardo.
Nice observation about using nBits from every 2016th block as a short
specifier of chain work. You can get some savings from the 4 byte nBits
encoding over VLQ for total chain work as in my spec.
I tried it out on the current chain. At block height 516
Yes, I think the checkpoints and the compressed headers streams should be
handled in chunks of 2016 headers and queried by chunk number instead of
height, falling back to current method if the chunk is not full yet.
This is cache friendly and allows to avoid bit 0 and bit 1 in the bitfield
(becaus
On Thu, Mar 29, 2018 at 05:50:30PM -0700, Jim Posen via bitcoin-dev wrote:
> Taken a step further though, I'm really interested in treating the checkpoints
> as commitments to chain work [...]
In that case, shouldn't the checkpoints just be every 2016 blocks and
include the corresponding bits valu
Thanks for giving it a read and for sparking the discussion with your
observation about the 40% savings from dropping prev_hash!
> Thought this wasn't effective in case overt asic boost get widely adopted,
> but then I understood that at the moment only two bits of version get
> scrambled by that
Hi Jim,
| version[i] = version[i - ((bit[3] << 2) + (bit[4] << 1) +
bit[5])]
Thought this wasn't effective in case overt asic boost get widely adopted,
but then I understood that at the moment only two bits of version get
scrambled by that technique so this looks fine, maybe add a comment about
Based on some ideas that were thrown around in this thread (
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-December/015385.html),
I have been working on a P2P extension that will allow faster header sync
mechanisms. The one-sentence summary is that by encoding headers more
efficientl
