<p>With blockchains, you can basically do anything with a hard fork.  In the case of private blockchains, you will have a much easier time getting consensus for a hard fork, perhaps as easy as the authority running the blockchain dictating that everyone must accept an upgrade.</p>

<p>The genesis block is hard-coded into the software.  To re-assign a later block to be the new genesis block, you would need to hard-code <em>that</em> block into a newer version of the software.  This will only be recognized as valid by nodes running the newer version of the software.  Assuming gaining consensus isn't an issue, this is possible.</p>

<p>Another thing to be concerned with is block height, and all calculations based on it.  It's easy to modify the client to start counting at N+1, but this also may need to be taken into consideration when calculations are made.  This will effect things such as difficulty targets and halvings.  If you modify all relevant code to take this into account, you should be able to keep things working correctly.</p>

CC BY-SA 3.0
2017-04-28T17:53:24.677Z
Can you specify some more things on how to do the implementation?
spharish
CC BY-SA 3.0
2017-04-28T17:55:37.280Z
Not really.  This is just an overview of what would need to be done, and I likely missed a few things.  Personally, I feel like this is a strange way to solve a problem.  My guess is that whatever problem you have could be better solved another way.
Jestin
CC BY-SA 3.0
2017-04-28T18:12:42.607Z
You also need to consider whether there's an associated data structure, like the UTXO set, which is needed to validate new blocks. If there is, that data structure will need to get to new nodes somehow, preferably by downloading it from existing nodes and checking the data against a hash distributed with the upgrade client.
Nick ODell
CC BY-SA 3.0
2017-04-28T17:47:03.490Z
2017-04-28T17:47:03.490Z
Jestin
<p>I am aware of the data loss caused by deleting the first N blocks. But I am curious to know whether such a task is possible or not. If so, how to practically implement it?</p>

CC BY-SA 3.0
2017-04-28T23:49:34.373Z
In a consensus change of a system, anything is possible if all participants agree - you simply all switch to different software. So the answer is obviously yes, but perhaps that is not what you want to know. Could you clarify why you would want to do that, or what you would hope to achieve by doing so?
Pieter Wuille
<blockchain><genesis-block><storage><private-blockchains>
In a private blockchain network, can we delete the first N blocks and reassign the N+1th block as the genesis block?
spharish
# In a private blockchain network, can we delete the first N blocks and reassign the N+1th block as the genesis block?

(Asked by: username_0 on 2017-04-28)

I am aware of the data loss caused by deleting the first N blocks. But I am curious to know whether such a task is possible or not. If so, how to practically implement it?

**Tags:** blockchain, genesis-block, storage, private-blockchains

> **Comments:**
> **username_1**: In a consensus change of a system, anything is possible if all participants agree - you simply all switch to different software. So the answer is obviously yes, but perhaps that is not what you want to know. Could you clarify why you would want to do that, or what you would hope to achieve by doing so?  

---

## 1 answers

### Answer by username_2 on 2017-04-28. Score: 1

With blockchains, you can basically do anything with a hard fork. In the case of private blockchains, you will have a much easier time getting consensus for a hard fork, perhaps as easy as the authority running the blockchain dictating that everyone must accept an upgrade.

The genesis block is hard-coded into the software. To re-assign a later block to be the new genesis block, you would need to hard-code *that* block into a newer version of the software. This will only be recognized as valid by nodes running the newer version of the software. Assuming gaining consensus isn't an issue, this is possible.

Another thing to be concerned with is block height, and all calculations based on it. It's easy to modify the client to start counting at N+1, but this also may need to be taken into consideration when calculations are made. This will effect things such as difficulty targets and halvings. If you modify all relevant code to take this into account, you should be able to keep things working correctly.

> **Comments:**
> **username_0**: Can you specify some more things on how to do the implementation?  
> **username_2**: Not really.  This is just an overview of what would need to be done, and I likely missed a few things.  Personally, I feel like this is a strange way to solve a problem.  My guess is that whatever problem you have could be better solved another way.  
> **username_3**: You also need to consider whether there's an associated data structure, like the UTXO set, which is needed to validate new blocks. If there is, that data structure will need to get to new nodes somehow, preferably by downloading it from existing nodes and checking the data against a hash distributed with the upgrade client.  

---

