<p>(yes/no/sort of... see better answer by Andrew Chow)</p>

<p>Yes, it will sync. Although it will be really slow as the blockchain is pretty big these days and the code wasn't as well optimized back then.</p>

<p>The 2013 event won't have any effect as it will sync with the longest (most work) chain.</p>

CC BY-SA 3.0
2018-04-24T17:06:41.153Z
Actually, it won't, but for a stupid reason. Checksums were introduced in the P2P protocol in v0.2.10 (June 2010), and in 2012 the no-checksum support was removed. You will need some node from between those dates to act as a bridge between the two.
Pieter Wuille
CC BY-SA 3.0
2018-04-24T17:15:30.467Z
The 2013 hard fork will still cause a problem because not enough BDB locks are available to the original Bitcoin client.
Ava Chow
CC BY-SA 3.0
2018-04-24T13:08:15.977Z
2018-04-25T20:55:16.437Z
2018-04-25T20:55:16.437Z
Jannes
<p>In theory it can as the explicit consensus rules have not changed. However in practice, it will not be able to sync without some special modifications.</p>

<p>First of all, the network version is so old that no modern node software will accept connections from it. Furthermore, the format of the network messages has changed since the first release so that it now contains a checksum of the message. The first version of the Bitcoin client did not have a checksum for messages. This difference in the network protocol will result in messages that do not make sense to either node in a connection.</p>

<p>In addition to the network message change, the original Bitcoin client will be unable to find nodes to connect to. It was only able to connect solely through using IRC node discovery which has since been disabled and removed. So you will need to specially construct the peers.dat file so that it will be able to find a peer to connect to.</p>

<p>Lastly, the original Bitcoin client will be unable to sync past the 2013 fork unless the number of BDB locks is increased. Using the default settings, it will run out of locks when it reaches around that time and thus fail to sync.</p>

<p>If you can to avoid all of these issues (e.g. by using a special node software specifically to sync off of) and increase the number of BDB locks, then the original Bitcoin client should be able to sync the current blockchain, albeit very slowly and possibly never be able to sync to the tip. Towards the current tip of the blockchain, it will probably take longer to validate a block than it takes for a new block to be found.</p>

<hr>

<p>Several months ago I modified a version of Bitcoin Core to be compatible with Bitcoin 0.1.0 and to then try to sync it. The code for that is <a href="https://github.com/achow101/bitcoin/tree/0.1.0-compat" rel="noreferrer">here</a>. I stopped that experiment after a few days when it was able to only sync ~25,000 blocks.</p>

CC BY-SA 3.0
2018-04-24T17:14:03.257Z
2018-04-24T17:14:03.257Z
Ava Chow
<p>So does a 2009 node sync the whole bitcoin blockchain and does the temporary split of 2013 have any impact on that?</p>

<bitcoin-core><blockchain-fork><nodes><full-node>
Does a 2009 node sync the whole bitcoin blockchain
Bram
# Does a 2009 node sync the whole bitcoin blockchain

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

So does a 2009 node sync the whole bitcoin blockchain and does the temporary split of 2013 have any impact on that?

**Tags:** bitcoin-core, blockchain-fork, nodes, full-node


---

## 2 answers

### Answer by username_3 on 2018-04-24. Score: 8 | Accepted answer

In theory it can as the explicit consensus rules have not changed. However in practice, it will not be able to sync without some special modifications.

First of all, the network version is so old that no modern node software will accept connections from it. Furthermore, the format of the network messages has changed since the first release so that it now contains a checksum of the message. The first version of the Bitcoin client did not have a checksum for messages. This difference in the network protocol will result in messages that do not make sense to either node in a connection.

In addition to the network message change, the original Bitcoin client will be unable to find nodes to connect to. It was only able to connect solely through using IRC node discovery which has since been disabled and removed. So you will need to specially construct the peers.dat file so that it will be able to find a peer to connect to.

Lastly, the original Bitcoin client will be unable to sync past the 2013 fork unless the number of BDB locks is increased. Using the default settings, it will run out of locks when it reaches around that time and thus fail to sync.

If you can to avoid all of these issues (e.g. by using a special node software specifically to sync off of) and increase the number of BDB locks, then the original Bitcoin client should be able to sync the current blockchain, albeit very slowly and possibly never be able to sync to the tip. Towards the current tip of the blockchain, it will probably take longer to validate a block than it takes for a new block to be found.

---

Several months ago I modified a version of Bitcoin Core to be compatible with Bitcoin 0.1.0 and to then try to sync it. The code for that is [here](https://github.com/achow101/bitcoin/tree/0.1.0-compat). I stopped that experiment after a few days when it was able to only sync ~25,000 blocks.


---

### Answer by username_1 on 2018-04-24. Score: 0

(yes/no/sort of... see better answer by Andrew Chow)

Yes, it will sync. Although it will be really slow as the blockchain is pretty big these days and the code wasn't as well optimized back then.

The 2013 event won't have any effect as it will sync with the longest (most work) chain.

> **Comments:**
> **username_2**: Actually, it won't, but for a stupid reason. Checksums were introduced in the P2P protocol in v0.2.10 (June 2010), and in 2012 the no-checksum support was removed. You will need some node from between those dates to act as a bridge between the two.  
> **username_3**: The 2013 hard fork will still cause a problem because not enough BDB locks are available to the original Bitcoin client.  

---

