<p>We can find all instances in the code where the client will send a <code>block</code> message by searching for <code>PushMessage("block"</code>. This is the only match:</p>

<pre><code>void static ProcessGetData(CNode* pfrom)
{
[...]
    pfrom-&gt;PushMessage("block", block);
</code></pre>

<p><a href="https://github.com/bitcoin/bitcoin/blob/3fce72eaa3ea75aa911e32c4d96313848338cede/src/main.cpp#L3830" rel="nofollow">(Source.)</a></p>

<p>This means that the standard client only ever sends a block message when specifically asked for it. That incoming <code>getdata</code> message is probably triggered in turn by sending the remote node an <code>inv</code> message. (Though that's not necessary - you can ask for a block that the other node hasn't advertised.) This is the code that sends inventory messages:</p>

<pre><code>//
// Message: inventory
//
vector&lt;CInv&gt; vInv;
vector&lt;CInv&gt; vInvWait;
{
    LOCK(pto-&gt;cs_inventory);
    vInv.reserve(pto-&gt;vInventoryToSend.size());
    vInvWait.reserve(pto-&gt;vInventoryToSend.size());
    BOOST_FOREACH(const CInv&amp; inv, pto-&gt;vInventoryToSend)
    {
        // If the other node already knows the message, don't send
        if (pto-&gt;setInventoryKnown.count(inv))
            continue;

        // trickle out tx inv to protect privacy
        [...]

        // returns true if remote node hasn't seen it
        if (pto-&gt;setInventoryKnown.insert(inv).second)
        {
            // Add to the list of inventory messages to send
            vInv.push_back(inv);
            // If there's 1000 inventory messages queued up, send them
            // (Protocol limit is 50000 at a time.)
            if (vInv.size() &gt;= 1000)
            {
                pto-&gt;PushMessage("inv", vInv);
                vInv.clear();
            }
        }
    }
    pto-&gt;vInventoryToSend = vInvWait;
}
// Send any that are left over.
if (!vInv.empty())
    pto-&gt;PushMessage("inv", vInv);
</code></pre>

<p><a href="https://github.com/bitcoin/bitcoin/blob/3fce72eaa3ea75aa911e32c4d96313848338cede/src/main.cpp#L4973" rel="nofollow">(Source.)</a></p>

<p>(pto represents the remote node in the above code.)</p>

<p>So the page you're looking at describes a behavior that you could implement, and that other clients will accept, but it doesn't describe the current core client behavior.</p>

CC BY-SA 3.0
2015-06-05T18:15:52.017Z
"describes a behavior that you could implement, and that other clients will accept, but it doesn't describe the current core client behavior."  I wrote the docs linked above, and I didn't realize that wasn't obvious.  Sorry.  It should be updated shortly: https://github.com/bitcoin/bitcoin.org/commit/b847610e1b129a85b3fd00c251b97864f2f89781
David A. Harding
CC BY-SA 3.0
2015-06-05T18:16:41.707Z
@DavidA.Harding That was fast. :)
Nick ODell
CC BY-SA 3.0
2015-06-06T13:57:50.037Z
@NickODell: Thanks, Nick! One thing is still not completely clear. You say: "_This means that the standard client only ever sends a block message when specifically asked for it. That incoming getdata message is probably triggered in turn by sending the remote node an inv message._" - does this mean: (1) node1 & node2 are both at _height n_ on a common active chain (2) node1 is faster and finds a _block n+1_ and pushes it to an inv message and sends this inv message to node2 and gets a getdata message from node2 asking for _block n+1_ (3) node1 sends a single block message with _block n+1_ ?
Aliakbar Ahmadi
CC BY-SA 3.0
2015-06-06T14:48:02.820Z
@AliakbarAhmadi Yes.
Nick ODell
CC BY-SA 3.0
2015-06-06T15:08:17.193Z
@NickODell: Ok but in what case will a **unsolicited** **single** block message be broadcasted to peers then??? Never? Is a freshly mined block sent unsolicitedly only inside an inv message?
Aliakbar Ahmadi
CC BY-SA 3.0
2015-06-06T15:09:33.523Z
@AliakbarAhmadi Never. Unless you modify your client.
Nick ODell
CC BY-SA 3.0
2015-06-05T17:13:02.080Z
2015-06-19T18:06:14.197Z
2015-06-19T18:06:14.197Z
Nick ODell
<p>Can someone, please, direct me to the <strong>source code section(s) relevant for an Unsolicited Block Push</strong> as described in the <a href="https://bitcoin.org/en/developer-guide#term-unsolicited-block-push" rel="nofollow noreferrer">Bitcoin Developer Guide</a>?</p>

<p>I've been going through <code>main.cpp</code> and searched for the term <em>MSG_BLOCK</em>, serving as a beagle for finding the correct place in the code. <br/>But as I'm reading further, it seems to me as if a freshly mined block is not appended to a inventory message, with <em>MSG_BLOCK</em>, in order to send it as a "package" as response to a request <a href="https://bitcoin.org/en/developer-reference#block" rel="nofollow noreferrer">(GetData Response)</a> BUT is sent as a single message of this structure:</p>

<p><img src="https://i.sstatic.net/HIKzz.jpg" alt="image is a cropped version of en-ibd-block.svg from Bitcoin Developer Guide"></p>

<p>To me, up to now, the best canditate for <em>Unsolicited Block Push</em> seems to be <a href="https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L2393" rel="nofollow noreferrer">main.cpp#L2393</a> part of <code>main.cpp</code> but I'm confused since I don't know if there is more of possibly relevant code (like <a href="https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L3830" rel="nofollow noreferrer">main.cpp#L3830</a>) for <em>Unsolicited Block Push</em> in <code>/src/</code>.</p>

<p><strong><em>So:</em> In a first step, I'm looking for code that is relevant for broadcasting a newly found block. Can someone please help?</strong></p>

<block><message><c++><block-header><broadcast>
Block Broadcasting - Unsolicited Block Push
Aliakbar Ahmadi
# Block Broadcasting - Unsolicited Block Push

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

Can someone, please, direct me to the **source code section(s) relevant for an Unsolicited Block Push** as described in the [Bitcoin Developer Guide](https://bitcoin.org/en/developer-guide#term-unsolicited-block-push)?

I've been going through `main.cpp` and searched for the term *MSG\_BLOCK*, serving as a beagle for finding the correct place in the code.   
But as I'm reading further, it seems to me as if a freshly mined block is not appended to a inventory message, with *MSG\_BLOCK*, in order to send it as a "package" as response to a request [(GetData Response)](https://bitcoin.org/en/developer-reference#block) BUT is sent as a single message of this structure:

![image is a cropped version of en-ibd-block.svg from Bitcoin Developer Guide](https://i.sstatic.net/HIKzz.jpg)

To me, up to now, the best canditate for *Unsolicited Block Push* seems to be [main.cpp#L2393](https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L2393) part of `main.cpp` but I'm confused since I don't know if there is more of possibly relevant code (like [main.cpp#L3830](https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L3830)) for *Unsolicited Block Push* in `/src/`.

***So:* In a first step, I'm looking for code that is relevant for broadcasting a newly found block. Can someone please help?**

**Tags:** block, message, c++, block-header, broadcast


---

## 1 answers

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

We can find all instances in the code where the client will send a `block` message by searching for `PushMessage("block"`. This is the only match:

```
void static ProcessGetData(CNode* pfrom)
{
[...]
    pfrom->PushMessage("block", block);

```

[(Source.)](https://github.com/bitcoin/bitcoin/blob/3fce72eaa3ea75aa911e32c4d96313848338cede/src/main.cpp#L3830)

This means that the standard client only ever sends a block message when specifically asked for it. That incoming `getdata` message is probably triggered in turn by sending the remote node an `inv` message. (Though that's not necessary - you can ask for a block that the other node hasn't advertised.) This is the code that sends inventory messages:

```
//
// Message: inventory
//
vector<CInv> vInv;
vector<CInv> vInvWait;
{
    LOCK(pto->cs_inventory);
    vInv.reserve(pto->vInventoryToSend.size());
    vInvWait.reserve(pto->vInventoryToSend.size());
    BOOST_FOREACH(const CInv& inv, pto->vInventoryToSend)
    {
        // If the other node already knows the message, don't send
        if (pto->setInventoryKnown.count(inv))
            continue;

        // trickle out tx inv to protect privacy
        [...]

        // returns true if remote node hasn't seen it
        if (pto->setInventoryKnown.insert(inv).second)
        {
            // Add to the list of inventory messages to send
            vInv.push_back(inv);
            // If there's 1000 inventory messages queued up, send them
            // (Protocol limit is 50000 at a time.)
            if (vInv.size() >= 1000)
            {
                pto->PushMessage("inv", vInv);
                vInv.clear();
            }
        }
    }
    pto->vInventoryToSend = vInvWait;
}
// Send any that are left over.
if (!vInv.empty())
    pto->PushMessage("inv", vInv);

```

[(Source.)](https://github.com/bitcoin/bitcoin/blob/3fce72eaa3ea75aa911e32c4d96313848338cede/src/main.cpp#L4973)

(pto represents the remote node in the above code.)

So the page you're looking at describes a behavior that you could implement, and that other clients will accept, but it doesn't describe the current core client behavior.

> **Comments:**
> **username_2**: "describes a behavior that you could implement, and that other clients will accept, but it doesn't describe the current core client behavior."  I wrote the docs linked above, and I didn't realize that wasn't obvious.  Sorry.  It should be updated shortly: https://github.com/bitcoin/bitcoin.org/commit/b847610e1b129a85b3fd00c251b97864f2f89781  
> **username_1**: @username_2 That was fast. :)  
> **username_0**: @username_1: Thanks, username_1! One thing is still not completely clear. You say: "_This means that the standard client only ever sends a block message when specifically asked for it. That incoming getdata message is probably triggered in turn by sending the remote node an inv message._" - does this mean: (1) node1 & node2 are both at _height n_ on a common active chain (2) node1 is faster and finds a _block n+1_ and pushes it to an inv message and sends this inv message to node2 and gets a getdata message from node2 asking for _block n+1_ (3) node1 sends a single block message with _block n+1_ ?  
> **username_1**: @username_0 Yes.  
> **username_0**: @username_1: Ok but in what case will a **unsolicited** **single** block message be broadcasted to peers then??? Never? Is a freshly mined block sent unsolicitedly only inside an inv message?  
> **username_1**: @username_0 Never. Unless you modify your client.  

---

