LBRYCommunity/lbcd
1
0
Fork 0
Code Issues 17 Pull requests 4 Projects Releases 28 Packages Wiki Activity

Update getheaders unknown block locator handling.

Browse source 
When no blocks in the block locator are found, start with the block after
the genesis block.  This means the client will start over with the genesis
block if unknown block locators are provided.  This mirrors the behavior
in the reference implementation.
This commit is contained in:
Dave Collins 2013-09-04 20:24:58 -05:00
parent f07d427837
commit 83a9bbd4dd
1 changed files with 4 additions and 10 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

14
peer.go
View file

@ -495,7 +495,10 @@ func (p *peer) handleGetHeadersMsg(msg *btcwire.MsgGetHeaders) {
}
// Find the most recent known block based on the block locator.
startIdx := int64(-1)
// It's the block after the genesis block if no other blocks in the
// provided locator are known. This does mean the client will start
// over with the genesis block if unknown block locators are provided.
startIdx := int64(1)
for _, hash := range msg.BlockLocatorHashes {
block, err := p.server.db.FetchBlockBySha(hash)
if err == nil {
@ -505,15 +508,6 @@ func (p *peer) handleGetHeadersMsg(msg *btcwire.MsgGetHeaders) {
}
}
// When the block locator refers to an unknown block, just return an
// empty headers message. This behavior mirrors the reference
// implementation.
if startIdx == -1 {
headersMsg := btcwire.NewMsgHeaders()
p.QueueMessage(headersMsg)
return
}
// Don't attempt to fetch more than we can put into a single message.
if endIdx-startIdx > btcwire.MaxBlockHeadersPerMsg {
endIdx = startIdx + btcwire.MaxBlockHeadersPerMsg