<p>Once a checkpoint block has been verified, it is not checked again. Changing the checkpoints will therefore not have any effect unless a checkpoint is added that is at a higher height than what you have synced.</p>
<p>If you also change the genesis block, it will think that the  databases have been corrupted and so it will attempt to redownload the entire blockchain. When it does, it will find that all of the blocks are invalid (because you changed the genesis block) and then it will just do nothing as it is unable to sync what it believes to be a valid blockchain.</p>
<blockquote>
<p>Is this what orphan block is?</p>
</blockquote>
<p>No. Orphan blocks are something else entirely and unrelated.</p>

CC BY-SA 4.0
2018-05-03T07:25:24.010Z
what is i changed one block lets say block no 100 on source code and recompile the code when i am already synchronised with current block number in bitcoin blockchain
Parishilan Rayamajhi
CC BY-SA 4.0
2018-05-03T14:52:12.460Z
Checkpoints are not checked when you are fully synced, so changing a checkpoint should not effect your node.
Ava Chow
CC BY-SA 4.0
2018-07-30T07:44:47.747Z
The question is changing checkpoints and not the genesis block, so your reply doesn't seem to follow.
G. Maxwell
CC BY-SA 4.0
2023-10-20T15:09:55.217Z
Your comment here contains the answer to the actual answer, and your answer doesn’t. Could you perhaps fold your comment into your answer?
Murch
CC BY-SA 4.0
2018-05-03T03:31:30.357Z
2023-10-20T15:18:50.927Z
2023-10-20T15:18:50.927Z
Ava Chow
<p>Assume the following example. You already have a fully sync'd bitcoin node and you then build a new wallet by changing a single line from <a href="https://github.com/bitcoin/bitcoin/blob/master/src/chainparams.cpp#L160" rel="nofollow noreferrer">here</a> :</p>

<p>Change this:</p>

<pre><code>{295000, uint256S("0x00000000000000004d9b4ef50f0f9d686fd69db2e03af35a100370c64632a983")},
</code></pre>

<p>to:</p>

<pre><code>{295000, uint256S("0x01")},
</code></pre>

<p>Recompile the code into a new wallet and run it on your already sync'd blockchain, but you will notice zero differences from the original wallet. Checkpoints only have an effect on nodes that have not yet synced up to the block height specified by the checkpoint. Therefore, if you take your custom built wallet and try to use it to sync a new blockchain, it will error out when it gets to block 295000 with the following error: <code>forked chain older than last checkpoint (height 295000)</code>.</p>

<p>Essentially checkpoints prevent forked chains from being seen as the longest chain, since they will not be able to pass this error validation. Only new nodes and nodes that have not yet synced up to the block height specified in the checkpoint are affected.</p>

<p>To answer your second question, orphaned blocks have nothing to do with checkpoints. An orphaned block is the result of having two (or more) miners solve the proof-of-work challenge at the same time. Since only one of the blocks can be valid, both miners that solved the POW challenge race to notify all of their peers about the new block they found and the network temporarily splits as a result of half of the network thinking Block A is correct and the other half thinking Block B is correct. These types of splits are typically corrected in the next block, but can sometimes span more than one block if the competing chains both continue to solve their POW challenges at the exact same time (very rare but it has happened). This is precisely the reason why many exchanges and other payment services require a certain amount of confirmations before a deposit is considered valid. The more confirmations a block has, the more likely that it is the one and only valid block at that height.</p>

CC BY-SA 4.0
2019-03-20T00:06:15.267Z
2019-03-20T00:06:15.267Z
Joe Uhren
<p>Suppose I have a fully synchronized Bitcoin node running on my local machine and I change its checkpoints data apart from its genesis block and recompile the code. Now what will happen when I try to run the daemon, having older block data residing inside <code>.bitcoin</code> folder.
Is this what <strong>orphan block</strong> is?</p>

<bitcoin-core><bitcoind><synchronization><orphaned-blocks><checkpoints>
What will happen if I change the checkpoint data from bitcoin source code and try to synchronize the blockchain?
Parishilan Rayamajhi
# What will happen if I change the checkpoint data from bitcoin source code and try to synchronize the blockchain?

(Asked by: username_0 on 2018-05-02)

Suppose I have a fully synchronized Bitcoin node running on my local machine and I change its checkpoints data apart from its genesis block and recompile the code. Now what will happen when I try to run the daemon, having older block data residing inside `.bitcoin` folder.
Is this what **orphan block** is?

**Tags:** bitcoin-core, bitcoind, synchronization, orphaned-blocks, checkpoints


---

## 2 answers

### Answer by username_1 on 2018-05-03. Score: 0 | Accepted answer

Once a checkpoint block has been verified, it is not checked again. Changing the checkpoints will therefore not have any effect unless a checkpoint is added that is at a higher height than what you have synced.

If you also change the genesis block, it will think that the databases have been corrupted and so it will attempt to redownload the entire blockchain. When it does, it will find that all of the blocks are invalid (because you changed the genesis block) and then it will just do nothing as it is unable to sync what it believes to be a valid blockchain.

> Is this what orphan block is?

No. Orphan blocks are something else entirely and unrelated.

> **Comments:**
> **username_0**: what is i changed one block lets say block no 100 on source code and recompile the code when i am already synchronised with current block number in bitcoin blockchain  
> **username_1**: Checkpoints are not checked when you are fully synced, so changing a checkpoint should not effect your node.  
> **username_2**: The question is changing checkpoints and not the genesis block, so your reply doesn't seem to follow.  
> **username_3**: Your comment here contains the answer to the actual answer, and your answer doesn’t. Could you perhaps fold your comment into your answer?  

---

### Answer by username_4 on 2019-03-20. Score: 0

Assume the following example. You already have a fully sync'd bitcoin node and you then build a new wallet by changing a single line from [here](https://github.com/bitcoin/bitcoin/blob/master/src/chainparams.cpp#L160) :

Change this:

```
{295000, uint256S("0x00000000000000004d9b4ef50f0f9d686fd69db2e03af35a100370c64632a983")},

```

to:

```
{295000, uint256S("0x01")},

```

Recompile the code into a new wallet and run it on your already sync'd blockchain, but you will notice zero differences from the original wallet. Checkpoints only have an effect on nodes that have not yet synced up to the block height specified by the checkpoint. Therefore, if you take your custom built wallet and try to use it to sync a new blockchain, it will error out when it gets to block 295000 with the following error: `forked chain older than last checkpoint (height 295000)`.

Essentially checkpoints prevent forked chains from being seen as the longest chain, since they will not be able to pass this error validation. Only new nodes and nodes that have not yet synced up to the block height specified in the checkpoint are affected.

To answer your second question, orphaned blocks have nothing to do with checkpoints. An orphaned block is the result of having two (or more) miners solve the proof-of-work challenge at the same time. Since only one of the blocks can be valid, both miners that solved the POW challenge race to notify all of their peers about the new block they found and the network temporarily splits as a result of half of the network thinking Block A is correct and the other half thinking Block B is correct. These types of splits are typically corrected in the next block, but can sometimes span more than one block if the competing chains both continue to solve their POW challenges at the exact same time (very rare but it has happened). This is precisely the reason why many exchanges and other payment services require a certain amount of confirmations before a deposit is considered valid. The more confirmations a block has, the more likely that it is the one and only valid block at that height.


---

