<p>Node1 announces block B3, using an 'inv' message with B3's gash.</p>

<p>Node2 does not know about B3, or its parent B2, but does know the grandparent B1. It sends a getblocks message, starting from B1, but stopping at B3.</p>

<p>Node1 replies with an inv for B2, but not with B3 or any potential successor B4 thay may have appeared.</p>

<p>The purpose is just avoiding sending too many hashes in case the sender already knows some successor.</p>

<p>Note that since Bitcoin Core 0.10.0, getblocks is no longer used. getheaders has similar logic though.</p>

CC BY-SA 3.0
2015-05-05T15:16:17.937Z
By "[...], but stopping at B3" you mean that Node2 requests only 1 block saying "give me B2's hash but not B3's hash"? So can we say Stopping Hash defines how many block header hashes are requested, unlike the default 00000..00000 Stopping Hash?
Aliakbar Ahmadi
CC BY-SA 3.0
2015-05-05T16:35:55.443Z
No, not how many. Just the one after which the sender can stop.
Pieter Wuille
CC BY-SA 3.0
2015-05-05T14:50:33.660Z
2015-05-05T14:50:33.660Z
Pieter Wuille
<p>Reading Bitcoin Developer Guide, I couldn't fully answer following question: <br/> <strong>What is the exact purpose of the Stopping Hash field inside a GetBlocks Message?</strong></p>

<block><synchronization><peers>
Stopping Hash field in GetBlocks Message
Aliakbar Ahmadi
# Stopping Hash field in GetBlocks Message

(Asked by: username_0 on 2015-05-05)

Reading Bitcoin Developer Guide, I couldn't fully answer following question:   
 **What is the exact purpose of the Stopping Hash field inside a GetBlocks Message?**

**Tags:** block, synchronization, peers


---

## 1 answers

### Answer by username_1 on 2015-05-05. Score: 5 | Accepted answer

Node1 announces block B3, using an 'inv' message with B3's gash.

Node2 does not know about B3, or its parent B2, but does know the grandparent B1. It sends a getblocks message, starting from B1, but stopping at B3.

Node1 replies with an inv for B2, but not with B3 or any potential successor B4 thay may have appeared.

The purpose is just avoiding sending too many hashes in case the sender already knows some successor.

Note that since Bitcoin Core 0.10.0, getblocks is no longer used. getheaders has similar logic though.

> **Comments:**
> **username_0**: By "[...], but stopping at B3" you mean that Node2 requests only 1 block saying "give me B2's hash but not B3's hash"? So can we say Stopping Hash defines how many block header hashes are requested, unlike the default 00000..00000 Stopping Hash?  
> **username_1**: No, not how many. Just the one after which the sender can stop.  

---

