<p>The syncnode concept was added in v0.8.2, to make sure we always have at least one connected peer from which we have at least once asked what their current blocks are. The name was pretty confusing, as it does not actually correspond to which peer we're downloading blocks from - just through which peer we actively seek to learn about blocks' existence.</p>

<p>v0.10.0 has a completely different synchronization mechanism (called headers-first), which does no longer have a syncnode. In fact, it downloads from all outgoing peers simultaneously.</p>

CC BY-SA 3.0
2015-02-13T18:39:21.077Z
2015-02-13T18:39:21.077Z
Pieter Wuille
<p>The p2p algorithm only selects one peer node to sync from. "syncnode" is a boolean that lets you know if that ip is the one you're currently downloading blockchain from.</p>

<p><a href="https://github.com/bitcoin/bitcoin/issues/2034" rel="nofollow">https://github.com/bitcoin/bitcoin/issues/2034</a> has this to say about it:</p>

<p>"There is one designated "sync node", from which the synchronization is supposed to happen.
getblocks messages are never sent to any but the sync node."</p>

CC BY-SA 3.0
2015-02-13T23:12:05.270Z
The idea presented in that issue does not actually correspond with what was implemented (in 0.8.2-0.9.x). As of 0.10.0, it's totally outdated.
Pieter Wuille
CC BY-SA 3.0
2014-12-05T13:41:58.553Z
2014-12-05T13:41:58.553Z
dbkeys
<p>maxconnections=1<br>
listen=0<br>
connect={IP you want as your sync node}</p>

<p>That's only way to guarantee it, outside of modifying source.</p>

CC BY-SA 3.0
2015-02-13T16:59:02.457Z
2015-02-15T23:27:40.937Z
2015-02-15T23:27:40.937Z
James Eze
<p>I have a testnet connection with 3 clients. When I am doing getpeerinfo on 1 I am getting </p>

<pre><code>[

    {
        "addr" : "172.20.61.111:63379",
        "services" : "00000001",
        "lastsend" : 1403246741,
        "lastrecv" : 1403246743,
        "bytessent" : 1074,
        "bytesrecv" : 1098,
        "conntime" : 1403246741,
        "pingtime" : 0.00000000,
        "version" : 70002,
        "subver" : "/Satoshi:0.9.2/",
        "inbound" : true,
        "startingheight" : 56114,
        "banscore" : 0,
        "syncnode" : true
    },
    {
        "addr" : "172.20.53.82:63416",
        "services" : "00000001",
        "lastsend" : 1403246741,
        "lastrecv" : 1403246743,
        "bytessent" : 149,
        "bytesrecv" : 1098,
        "conntime" : 1403246741,
        "pingtime" : 0.00000000,
        "version" : 70002,
        "subver" : "/Satoshi:0.9.2/",
        "inbound" : true,
        "startingheight" : 56114,
        "banscore" : 0,
        "syncnode" : false
    }
]
</code></pre>

<p>as a result of syncnode false this node is not syncing. How do I fix this?</p>

<synchronization>
How to set syncnode of a peer to true?
Pinaki
# How to set syncnode of a peer to true?

(Asked by: username_0 on 2014-06-20)

I have a testnet connection with 3 clients. When I am doing getpeerinfo on 1 I am getting 
[

    {
        "addr" : "172.20.61.111:63379",
        "services" : "00000001",
        "lastsend" : 1403246741,
        "lastrecv" : 1403246743,
        "bytessent" : 1074,
        "bytesrecv" : 1098,
        "conntime" : 1403246741,
        "pingtime" : 0.00000000,
        "version" : 70002,
        "subver" : "/Satoshi:0.9.2/",
        "inbound" : true,
        "startingheight" : 56114,
        "banscore" : 0,
        "syncnode" : true
    },
    {
        "addr" : "172.20.53.82:63416",
        "services" : "00000001",
        "lastsend" : 1403246741,
        "lastrecv" : 1403246743,
        "bytessent" : 149,
        "bytesrecv" : 1098,
        "conntime" : 1403246741,
        "pingtime" : 0.00000000,
        "version" : 70002,
        "subver" : "/Satoshi:0.9.2/",
        "inbound" : true,
        "startingheight" : 56114,
        "banscore" : 0,
        "syncnode" : false
    }
]

as a result of syncnode false this node is not syncing. How do I fix this?

**Tags:** synchronization


---

## 3 answers

### Answer by username_1 on 2015-02-13. Score: 5

The syncnode concept was added in v0.8.2, to make sure we always have at least one connected peer from which we have at least once asked what their current blocks are. The name was pretty confusing, as it does not actually correspond to which peer we're downloading blocks from - just through which peer we actively seek to learn about blocks' existence.

v0.10.0 has a completely different synchronization mechanism (called headers-first), which does no longer have a syncnode. In fact, it downloads from all outgoing peers simultaneously.


---

### Answer by username_2 on 2014-12-05. Score: 2

The p2p algorithm only selects one peer node to sync from. "syncnode" is a boolean that lets you know if that ip is the one you're currently downloading blockchain from.

<https://github.com/bitcoin/bitcoin/issues/2034> has this to say about it:

"There is one designated "sync node", from which the synchronization is supposed to happen.
getblocks messages are never sent to any but the sync node."

> **Comments:**
> **username_1**: The idea presented in that issue does not actually correspond with what was implemented (in 0.8.2-0.9.x). As of 0.10.0, it's totally outdated.  

---

### Answer by username_3 on 2015-02-13. Score: 0

maxconnections=1  
listen=0  
connect={IP you want as your sync node}

That's only way to guarantee it, outside of modifying source.


---

