On Tue, Dec 12, 2017 at 9:07 PM, Suhas Daftuar <sdaft...@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. _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
