<ul>
<li>First the peer who chooses to connect shares their version.</li>
<li>Each of the peers can only send one version message.</li>
</ul>

<p><code>PushNodeVersion</code> is used to send the version message. It is called by two functions</p>

<p>1) <code>PeerLogicValidation::InitializeNode</code> when the connection is outbound.</p>

<p>2) <code>ProcessMessage</code> when a message is received. It looks like this:</p>

<pre><code>bool static ProcessMessage(...) {
    if (strCommand == NetMsgType::VERSION) {
        if (pfrom-&gt;fInbound)
            PushNodeVersion(pfrom, connman, GetAdjustedTime());
    }
}
</code></pre>

<p>If it was</p>

<pre><code>    if (strCommand == NetMsgType::VERSION) {
        // If this if clause didn't exist: if (pfrom-&gt;fInbound)
            PushNodeVersion(pfrom, connman, GetAdjustedTime());
    }
</code></pre>

<p>Consider the following case:</p>

<p>1) Client A connects to Client B</p>

<p>2) Client A sends its version to Client B</p>

<p>3) Client B, as an answer, shares its version</p>

<p>Now, if that <code>if</code> caluse didn't exist, Client A would send the version message once again.</p>

<p>The comment <code>// Be shy and don't send version until we hear</code> is actually irrelevant.</p>

CC BY-SA 4.0
2018-10-12T13:47:43.207Z
2018-10-12T13:47:43.207Z
MCCCS
<p>This is more of a technical/programming question. </p>

<p>I am referring to this line of code: <a href="https://github.com/bitcoin/bitcoin/blob/be992701b018f256db6d64786624be4cb60d8975/src/net_processing.cpp#L1699" rel="nofollow noreferrer">https://github.com/bitcoin/bitcoin/blob/be992701b018f256db6d64786624be4cb60d8975/src/net_processing.cpp#L1699</a></p>

<p>I understand the logic behind not sending a version packet to a newly <code>accept</code>ed connection unless they send one first, but the code I linked to does not quite do that, or does it?</p>

<p>At that point we are already inside an <code>if</code> block which verifies that the command received is "version", so the peer has already sent us a version packet, irrespective of who initiated the connection. Am I missing something?</p>

<bitcoind><network><source-code><packets>
How is bitcoind "shy" when exchanging `version` packets?
Tedy S.
# How is bitcoind "shy" when exchanging `version` packets?

(Asked by: username_0 on 2018-10-10)

This is more of a technical/programming question.

I am referring to this line of code: <https://github.com/bitcoin/bitcoin/blob/be992701b018f256db6d64786624be4cb60d8975/src/net_processing.cpp#L1699>

I understand the logic behind not sending a version packet to a newly `accept`ed connection unless they send one first, but the code I linked to does not quite do that, or does it?

At that point we are already inside an `if` block which verifies that the command received is "version", so the peer has already sent us a version packet, irrespective of who initiated the connection. Am I missing something?

**Tags:** bitcoind, network, source-code, packets


---

## 1 answers

### Answer by username_1 on 2018-10-12. Score: 1 | Accepted answer

First the peer who chooses to connect shares their version.
Each of the peers can only send one version message.

PushNodeVersion is used to send the version message. It is called by two functions
1) PeerLogicValidation::InitializeNode when the connection is outbound.
2) ProcessMessage when a message is received. It looks like this:
bool static ProcessMessage(...) {
    if (strCommand == NetMsgType::VERSION) {
        if (pfrom->fInbound)
            PushNodeVersion(pfrom, connman, GetAdjustedTime());
    }
}

If it was
    if (strCommand == NetMsgType::VERSION) {
        // If this if clause didn't exist: if (pfrom->fInbound)
            PushNodeVersion(pfrom, connman, GetAdjustedTime());
    }

Consider the following case:
1) Client A connects to Client B
2) Client A sends its version to Client B
3) Client B, as an answer, shares its version
Now, if that if caluse didn't exist, Client A would send the version message once again.
The comment // Be shy and don't send version until we hear is actually irrelevant.


---

