1

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.

Improve this question
7
  • 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
    Dec 7, 2017 at 19:40
  • 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
    Dec 7, 2017 at 20:05
  • 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
    Dec 7, 2017 at 20:46
  • This might be good call. Here is the chart with block versions changing in time: data.bitcoinity.org/bitcoin/block_version
    – Michał Zabielski
    Dec 7, 2017 at 20:53
  • 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
    Dec 7, 2017 at 21:00

1 Answer 1

Reset to default
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.

Improve this answer
1
  • 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.
    – Andrew Chow ♦
    Dec 8, 2017 at 16:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.