0

Headers-first sync is defined somewhat by BIP 130 and expanded upon with compact block relay in BIP 152. I believe this is the commit in which it was added to Bitcoin Core.

The result is that Bitcoin Core nodes never send getblocks messages anymore, they get headers first with getheaders, then after some verification, they request full blocks with getdata.

My question is, do SPV nodes need to follow this scheme as well? They certainly could, they'd just open the peer connection with a filterload so when they getdata they get merkleblock messages back instead of full block or cmpctblock messages.

This is an implementation-specific question, but I am actually hoping for examples. For one, Breadwallet seems to have a custom network protocol in which both getheaders and getblocks are used.

Are there any other examples of SPV applications using getheaders and getblocks in this way?

Do most SPV clients just use getblocks or do they try to sync headers-first, even though they'll never request full blocks?

  • headers-first sync is a local strategy, and it was implemented by Bitcoin Core before BIP130; that BIP just reduces the number of messages exchanges when announcing a new block. And nobody "needs" to follow this scheme; I believe it's superior, but there is no authority to tell you in what way to use the protocol as long as it's not damaging to others. – Pieter Wuille Apr 19 at 17:23
  • @PieterWuille Thanks, I might be asking more for advice on "best practices" -- if I were implementing a new SPV node, would headers first still be the superior strategy? – pinhead Apr 19 at 17:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.