Gregory Maxwell [ARCHIVE] on Nostr: 📅 Original date posted:2017-12-12 📝 Original message:On Tue, Dec 12, 2017 at ...
📅 Original date posted:2017-12-12
📝 Original message:On Tue, Dec 12, 2017 at 9:07 PM, Suhas Daftuar <sdaftuar at gmail.com> wrote:
> I agree with this. Specifically the way I envisioned this working is that
> we could introduce a new 'cmpctheaders'/'getcmpcthdrs' message pair for
> syncing using this new message type, while leaving the existing
> 'headers'/'getheaders' messages unchanged. So when communicating with
> upgraded peers, we'd never use 'getheaders' messages, and we'd only use
> 'headers' messages for potentially announcing new blocks.
The question becomes there-- how should it work.
In an ideal world, we'd decide what peers to fetch headers from based
on a compact proof of the total work in their chains... but we cannot
construct such proofs in Bitcoin today.
I think that instead of that a weak heuristic is to fetch first from
the peers with the tip at the highest difficulty. Then work backwards.
See: https://en.bitcoin.it/wiki/User:Gmaxwell/Reverse_header-fetching_sync
Which is the inspiration for the current headers first sync, but
without the reverse part because the protocol didn't permit it: you
can't request a linear wad of headers that come before a header. This
is the thing I was mostly thinking of when I mentioned that we may
want to change the interface.
📝 Original message:On Tue, Dec 12, 2017 at 9:07 PM, Suhas Daftuar <sdaftuar at gmail.com> wrote:
> I agree with this. Specifically the way I envisioned this working is that
> we could introduce a new 'cmpctheaders'/'getcmpcthdrs' message pair for
> syncing using this new message type, while leaving the existing
> 'headers'/'getheaders' messages unchanged. So when communicating with
> upgraded peers, we'd never use 'getheaders' messages, and we'd only use
> 'headers' messages for potentially announcing new blocks.
The question becomes there-- how should it work.
In an ideal world, we'd decide what peers to fetch headers from based
on a compact proof of the total work in their chains... but we cannot
construct such proofs in Bitcoin today.
I think that instead of that a weak heuristic is to fetch first from
the peers with the tip at the highest difficulty. Then work backwards.
See: https://en.bitcoin.it/wiki/User:Gmaxwell/Reverse_header-fetching_sync
Which is the inspiration for the current headers first sync, but
without the reverse part because the protocol didn't permit it: you
can't request a linear wad of headers that come before a header. This
is the thing I was mostly thinking of when I mentioned that we may
want to change the interface.