<blockquote>
  <p>either I broke some rule, or the other person did; In this case, how does my client find a trusted peer</p>
</blockquote>

<p>Your client does not trust any peer. It fully validates the blockchain. In the event of multiple conflicting blocks at a given block height, your node will choose to go with the first block it hears of. However it will still retain and validate all of the other blocks that it has received for that block height. Only after more blocks have been mined does it actually choose which of those conflicting blocks becomes part of its main chain. It chooses based upon which branch has the most cumulative work.</p>

<p>There is no trust in this process; it uses first heard initially and then will readjust if later blocks belong to a different branch. These reorganizations are why it is recommended to wait for multiple confirmations as one block reorgs are not uncommon.</p>

<p>Also, the blockchain with the most cumulative work (typically referred to as the longest blockchain) is not the only determination for what blockchain to use. The blockchain also has to be valid, it can't just have the most work.</p>

<blockquote>
  <p>2: Lets say I stopped my client for 100 days, during those 100 days there was 500 new transactions, which means that if I was to compare my last block with someone elses then my client would be outdated, therefore it needs to download the extra blocks, where does it find these blocks and how does it determine which peers to sync to and to trust?</p>
</blockquote>

<p>Your node does the normal peer discovery process every time it goes online. Your node will then randomly choose one of the peers it has connected to to be the "sync node". It doesn't actually sync much off of this node, just the block headers. It downloads the block headers from this node and validates them. Then it will download the blocks for those headers from the other nodes it has connected to.</p>

<p>Once the headers chain of one node has been synced, it will request the headers of other nodes to get an idea of what their best headers chain is in order to determine if the sync node was dishonest.</p>

<p>Again, there is no trust in this process as all blocks and headers are still fully validated. Since the download involves checking against multiple nodes, it is unlikely that your node will have the incorrect blockchain as not just one node dictates what chain you download.</p>

<blockquote>
  <p>so the question is what is the real need for the nonce?</p>
</blockquote>

<p>The nonce is completely unrelated to validity except for the fact that it is part of the block header which is hashed. The nonce's sole purpose is to have something to change when mining. It provides no security characteristics nor is it related to the consensus rules (except for the fact that it has to exist, it could be zero). Miners could very well just not do anything to the nonce and change something else to get a different hash. It exists solely as a convenience.</p>

CC BY-SA 4.0
2018-07-16T05:38:10.677Z
Assuming the network as a whole isn't broken, the only way this can fail is if every single node you connect to is malicious and none of them are willing to reveal the actual longest valid chain to you. This is called a Sybil attack and there are various defenses against them. For PoW systems, anyone who mined blocks in the longest chain wants to get them to as many people as possible to ensure they stay in the longest chain so they get to keep their reward. It's very hard for a third party to stop two people who want to exchange information from doing so.
David Schwartz
CC BY-SA 4.0
2021-09-13T17:22:41.240Z
Plus: To get started the validation started with a known good state, the blockchain software frequently (always?) has the blockchain's genesis block (block 0) _built-in_ (or at least it's hash).  For example, [here it is in Bitcoin Core](https://github.com/bitcoin/bitcoin/blob/7ecb309c4ed1bb9ae6b9a12cbb4f083328edc125/src/chainparams.cpp#L19).
davidbak
CC BY-SA 3.0
2018-04-25T04:35:54.620Z
2018-04-25T04:35:54.620Z
Ava Chow
<ol>
<li><p>So the way I understand how the blockchain works is that each new block uses the previous block's hash, which means if my <code>block[100].hash != someone_elses_block[100].hash</code> that means that either I broke some rule, or the other person did; In this case, how does my client find a trusted peer? And WHERE does my client get the latest CORRECT blockchain? Is there a central server for it? If so, where did the server it from? Because the miner will have the longest chain, but what if they are not actually following the rules? Then what?</p></li>
<li><p>Lets say I stopped my client for 100 days, during those 100 days there was 500 new transactions, which means that if I was to compare my last block with someone elses then my client would be outdated, therefore it needs to download the extra blocks, where does it find these blocks and how does it determine which peers to sync to and to trust?</p></li>
<li><p>A question about the nonce, if lets say there was no nonce; If client A has a chain that followed the rules and client B was verifying transactions without actually doing all the proper checks, that means that client A at block[100].hash != client B at block[100] therefore client B is not following the rules, so the question is what is the real need for the nonce? Because in my mind it seems like it's just there to make it harder to mine for people, correct? Or does it add some sort of security? And if it does, will it have the same security if let's say the nonce was always any number between 0 and 15? Or would it have to be adjusted as mining gets faster?</p></li>
</ol>

<p>Thanks!</p>

CC BY-SA 4.0
2018-07-16T05:37:04.380Z
It's worth pointing out that not all blockchains have nonces.
David Schwartz
<blockchain><synchronization><nonce><peers><peer-discovery>
How Do Peers Choose Which Peer To Trust?
ABOODYFJ
# How Do Peers Choose Which Peer To Trust?

(Asked by: username_0 on 2018-04-25)

1. So the way I understand how the blockchain works is that each new block uses the previous block's hash, which means if my `block[100].hash != someone_elses_block[100].hash` that means that either I broke some rule, or the other person did; In this case, how does my client find a trusted peer? And WHERE does my client get the latest CORRECT blockchain? Is there a central server for it? If so, where did the server it from? Because the miner will have the longest chain, but what if they are not actually following the rules? Then what?
2. Lets say I stopped my client for 100 days, during those 100 days there was 500 new transactions, which means that if I was to compare my last block with someone elses then my client would be outdated, therefore it needs to download the extra blocks, where does it find these blocks and how does it determine which peers to sync to and to trust?
3. A question about the nonce, if lets say there was no nonce; If client A has a chain that followed the rules and client B was verifying transactions without actually doing all the proper checks, that means that client A at block[100].hash != client B at block[100] therefore client B is not following the rules, so the question is what is the real need for the nonce? Because in my mind it seems like it's just there to make it harder to mine for people, correct? Or does it add some sort of security? And if it does, will it have the same security if let's say the nonce was always any number between 0 and 15? Or would it have to be adjusted as mining gets faster?

Thanks!

**Tags:** blockchain, synchronization, nonce, peers, peer-discovery

> **Comments:**
> **username_1**: It's worth pointing out that not all blockchains have nonces.  

---

## 1 answers

### Answer by username_2 on 2018-04-25. Score: 5 | Accepted answer

> either I broke some rule, or the other person did; In this case, how does my client find a trusted peer

Your client does not trust any peer. It fully validates the blockchain. In the event of multiple conflicting blocks at a given block height, your node will choose to go with the first block it hears of. However it will still retain and validate all of the other blocks that it has received for that block height. Only after more blocks have been mined does it actually choose which of those conflicting blocks becomes part of its main chain. It chooses based upon which branch has the most cumulative work.

There is no trust in this process; it uses first heard initially and then will readjust if later blocks belong to a different branch. These reorganizations are why it is recommended to wait for multiple confirmations as one block reorgs are not uncommon.

Also, the blockchain with the most cumulative work (typically referred to as the longest blockchain) is not the only determination for what blockchain to use. The blockchain also has to be valid, it can't just have the most work.

> 2: Lets say I stopped my client for 100 days, during those 100 days there was 500 new transactions, which means that if I was to compare my last block with someone elses then my client would be outdated, therefore it needs to download the extra blocks, where does it find these blocks and how does it determine which peers to sync to and to trust?

Your node does the normal peer discovery process every time it goes online. Your node will then randomly choose one of the peers it has connected to to be the "sync node". It doesn't actually sync much off of this node, just the block headers. It downloads the block headers from this node and validates them. Then it will download the blocks for those headers from the other nodes it has connected to.

Once the headers chain of one node has been synced, it will request the headers of other nodes to get an idea of what their best headers chain is in order to determine if the sync node was dishonest.

Again, there is no trust in this process as all blocks and headers are still fully validated. Since the download involves checking against multiple nodes, it is unlikely that your node will have the incorrect blockchain as not just one node dictates what chain you download.

> so the question is what is the real need for the nonce?

The nonce is completely unrelated to validity except for the fact that it is part of the block header which is hashed. The nonce's sole purpose is to have something to change when mining. It provides no security characteristics nor is it related to the consensus rules (except for the fact that it has to exist, it could be zero). Miners could very well just not do anything to the nonce and change something else to get a different hash. It exists solely as a convenience.

> **Comments:**
> **username_1**: Assuming the network as a whole isn't broken, the only way this can fail is if every single node you connect to is malicious and none of them are willing to reveal the actual longest valid chain to you. This is called a Sybil attack and there are various defenses against them. For PoW systems, anyone who mined blocks in the longest chain wants to get them to as many people as possible to ensure they stay in the longest chain so they get to keep their reward. It's very hard for a third party to stop two people who want to exchange information from doing so.  
> **username_3**: Plus: To get started the validation started with a known good state, the blockchain software frequently (always?) has the blockchain's genesis block (block 0) _built-in_ (or at least it's hash).  For example, [here it is in Bitcoin Core](https://github.com/bitcoin/bitcoin/blob/7ecb309c4ed1bb9ae6b9a12cbb4f083328edc125/src/chainparams.cpp#L19).  

---

