<p>I will take the suggestion above and post the answer for others.</p>

<p>As mentioned I am a noob at looking into the bitcoin and blockchain.  My interest is the programming code behind the cryptocurrencies and the various blockchain implementations.</p>

<p>When I was backtesting the correctness of my code, which I did in Python and Ruby, I discovered that it wasn't working at a certain point.  I wasn't sure at which block #, where it was failing until I tightened up the test and discovered it was at that block #410000.  A simple look at the data, I realized that either the mining algorithm changed slightly for difficulty or something in the inputs wasn't correct, so I isolated all the inputs and realized that it was the VERSION field that changed.</p>

<p>Of course, I know nothing about the different versions of the blocks, nor the forking behaviors yet... it wasn't clear until the poster provided the link that confirmed to me that the versions had changed, thus throwing off my program.  But I can easily tweek it to adapt to the version field, now that I realize it is not as hardcoded as the other fields.</p>

<p>One thing that I noticed, and I am not a probabilities expert, but the nonce values seem to land in the 9 or 10-digit range... so when a miner is searching for the nonce, I would assume that the miner does not need to start the search at 0.... but rather 100000000 and increment, it seems the time to calculate is reduced substantially.</p>

<p>My next step is I'd like to analyze the range of nonce values and see if they fall within a certain spectrum of values and where they cluster, whether 9 or 10-digit lengths. It's all just curious analysis.</p>

<p>My goal to all of this is the create a fully running program that pulls all of the blockchain, and dynamically confirm the blocks(merkle roots and header hashes), store the info in a csv file.  The point is for me to learn to scrape, process and analyze the results just to find any irregularities, or randomness if that's the case... just from curiousity sakes.</p>

<p>As a pet project, I am going to create a blockchain-distributed ledger for a friend who has a PhD in food safety and security, and see where it goes from there.</p>

CC BY-SA 3.0
2017-12-08T16:53:07.737Z
The algorithm itself did not change, and changing the inputs fields is not a change of the algorithm. The version field is used to signal soft forks.
Ava Chow
CC BY-SA 3.0
2017-12-08T16:20:11.330Z
2017-12-08T16:20:11.330Z
Tom Branson
<p>I am in a graduate program in Software Engineering and have recreated the mining programs in Python and Ruby, as well as computing the Merkle Root, etc..</p>

<p>I have been randomly chosing blocks from Bitcoin to test my algo(s).  I notice that my nonce and current block hash finder works upto a certain point.  It seems that it works upto about block 400,000, circa 2015... but fails beyond this point.  Did they tweak the mining algorithms around that time?  Should there be another data point?</p>

<p>I have these data points:</p>

<ul>
<li>previous hash</li>
<li>merkle root</li>
<li>difficulty</li>
<li>version</li>
<li>time in unix</li>
<li>nonce: (this is what the program searches for and puts out the nonce and current block hash, if found)</li>
</ul>

<p>As I mentioned it confirms and "mines" the blocks up to about block 400,000... but fails afterwards.</p>

<p>Some enlightenment is appreciated.</p>

CC BY-SA 3.0
2017-12-07T19:40:00.443Z
You validate the correctness of generated block hashes, or claim that you were able found hashes of some of 400,000 blocks using code written in python?
Michał Zabielski
CC BY-SA 3.0
2017-12-07T20:05:04.527Z
I guess that I wasn't clear.  I can validate the hash of block 'n' for all blocks from #0 the genesis, but have discovered that my program doesn't validate the correct hash of the blocks starting around #400000, around 2015.
Tom Branson
CC BY-SA 3.0
2017-12-07T20:46:03.340Z
Block #410000 is where it fails, I guess that it's related to the "VERSION" field... all previous blocks had a single integer entry of 1to 4... changed the way data is displayed in this field... that is my only guess.
Tom Branson
CC BY-SA 3.0
2017-12-07T20:53:14.950Z
This might be good call. Here is the chart with block versions changing in time: https://data.bitcoinity.org/bitcoin/block_version
Michał Zabielski
CC BY-SA 3.0
2017-12-07T21:00:32.007Z
Yes, that is it.  I plugged in the new version number and it confirmed it.  It's confusing as a noob, I noticed that Blockchain.info and Blockexplorer.com display the info differently.  I am learning my way through this.  Thanks for the link.
Tom Branson
CC BY-SA 3.0
2017-12-07T21:01:25.043Z
I wrote a python program to hash a block header a while back: https://bitcoin.stackexchange.com/a/46024/2306
Nick ODell
CC BY-SA 3.0
2017-12-08T02:28:38.403Z
You can post your own answer to this question, explaining what you learned.  Otherwise it will remain marked as "unanswered" forever.
Nate Eldredge
<mining-theory>
Has the PoW algorithm changed?
Tom Branson
# Has the PoW algorithm changed?

(Asked by: username_0 on 2017-12-07)

I am in a graduate program in Software Engineering and have recreated the mining programs in Python and Ruby, as well as computing the Merkle Root, etc..

I have been randomly chosing blocks from Bitcoin to test my algo(s). I notice that my nonce and current block hash finder works upto a certain point. It seems that it works upto about block 400,000, circa 2015... but fails beyond this point. Did they tweak the mining algorithms around that time? Should there be another data point?

I have these data points:

* previous hash
* merkle root
* difficulty
* version
* time in unix
* nonce: (this is what the program searches for and puts out the nonce and current block hash, if found)

As I mentioned it confirms and "mines" the blocks up to about block 400,000... but fails afterwards.

Some enlightenment is appreciated.

**Tags:** mining-theory

> **Comments:**
> **username_1**: You validate the correctness of generated block hashes, or claim that you were able found hashes of some of 400,000 blocks using code written in python?  
> **username_0**: I guess that I wasn't clear.  I can validate the hash of block 'n' for all blocks from #0 the genesis, but have discovered that my program doesn't validate the correct hash of the blocks starting around #400000, around 2015.  
> **username_0**: Block #410000 is where it fails, I guess that it's related to the "VERSION" field... all previous blocks had a single integer entry of 1to 4... changed the way data is displayed in this field... that is my only guess.  
> **username_1**: This might be good call. Here is the chart with block versions changing in time: https://data.bitcoinity.org/bitcoin/block_version  
> **username_0**: Yes, that is it.  I plugged in the new version number and it confirmed it.  It's confusing as a noob, I noticed that Blockchain.info and Blockexplorer.com display the info differently.  I am learning my way through this.  Thanks for the link.  
> **username_2**: I wrote a python program to hash a block header a while back: https://bitcoin.stackexchange.com/a/46024/2306  
> **username_3**: You can post your own answer to this question, explaining what you learned.  Otherwise it will remain marked as "unanswered" forever.  

---

## 1 answers

### Answer by username_0 on 2017-12-08. Score: 1

I will take the suggestion above and post the answer for others.

As mentioned I am a noob at looking into the bitcoin and blockchain. My interest is the programming code behind the cryptocurrencies and the various blockchain implementations.

When I was backtesting the correctness of my code, which I did in Python and Ruby, I discovered that it wasn't working at a certain point. I wasn't sure at which block #, where it was failing until I tightened up the test and discovered it was at that block #410000. A simple look at the data, I realized that either the mining algorithm changed slightly for difficulty or something in the inputs wasn't correct, so I isolated all the inputs and realized that it was the VERSION field that changed.

Of course, I know nothing about the different versions of the blocks, nor the forking behaviors yet... it wasn't clear until the poster provided the link that confirmed to me that the versions had changed, thus throwing off my program. But I can easily tweek it to adapt to the version field, now that I realize it is not as hardcoded as the other fields.

One thing that I noticed, and I am not a probabilities expert, but the nonce values seem to land in the 9 or 10-digit range... so when a miner is searching for the nonce, I would assume that the miner does not need to start the search at 0.... but rather 100000000 and increment, it seems the time to calculate is reduced substantially.

My next step is I'd like to analyze the range of nonce values and see if they fall within a certain spectrum of values and where they cluster, whether 9 or 10-digit lengths. It's all just curious analysis.

My goal to all of this is the create a fully running program that pulls all of the blockchain, and dynamically confirm the blocks(merkle roots and header hashes), store the info in a csv file. The point is for me to learn to scrape, process and analyze the results just to find any irregularities, or randomness if that's the case... just from curiousity sakes.

As a pet project, I am going to create a blockchain-distributed ledger for a friend who has a PhD in food safety and security, and see where it goes from there.

> **Comments:**
> **username_4**: The algorithm itself did not change, and changing the inputs fields is not a change of the algorithm. The version field is used to signal soft forks.  

---

