Measuring decentralization through unique miners
Often we hear how projects tout just how decentralized they are. I wanted to look at slightly deeper look at a particular aspect: Mining decentralization.
You see I setup 3x DE10-Nano’s that are currently mining Odocrypt, solo-mining. Since July when we locked in the Odocrypt upgrade I’ve solo mined four unique blocks with my FPGAs. They are still contributing to the security of the network!
It got me thinking: If I’m only looking at the last 100 blocks, the chance of them being “ counted” as contributing is rather slim, despite the fact they still provide security to the network. What I wanted to do was compare the last 3 months worth (500k blocks) for DigiByte, with LTC (50k blocks) and BTC (12.5k blocks). I figure then I’d also look at the “weekly” chart too and see how that differed.
Now because DigiByte has 40X faster block timings than BTC, if we were to do that based on the same number of blocks, we wouldn’t be getting an accurate comparison. This is because if we compared 500k blocks for DigiByte vs 500k blocks with Bitcoin, we would be comparing 9.5 years worth of BTC data with 87 days DGB data.
What makes me say this? Well for starters, Bitcoin was being mined on laptops (CPU-mined) back 9.5 years ago, and I can confidently assure you that nobody mines BTC on a laptop these days. Partly because it’s good at frying laptops, but also due to the incredible benefits we have from the increase in hashrate thanks to ASICs which are now securing the network.
So, I’ve gone for equivalent timing instead. 3 months (~87 days) and 7 days worth.
Method
I wanted to document this part for other people to also follow through in case they were curious about the numbers themselves and / or wanting to do this for other projects. Skip over this part to the data below if this doesn’t interest you.
Now unfortunately I’m not a programmer so I couldn’t write an app to do this, as such this was done with relatively manual bash scripts. I’m sure that any experienced sysadmin / coder will be able to see that scripting is definitely not my strong suit.
However, what I did seemed to be sufficient to get the data that we need, and you can easily copy / paste and re-create this yourself, or even do it for another project.
There were 3 parts to this, mostly due to the way we get the data out of the Core Wallet.
Step 1
The first step was writing a bash script that pulled the block hashes (blockchain-cli getblockhash BLOCKNO), as you are unable to directly ask the blockchain for each blocks information by block #. We do this because I want only a certain number of blocks (500k / 50k / 12.5k).
#!/bin/bash
for value in {591777..592785}
do
echo $value
~/bitcoin-0.18.1/bin/bitcoin-cli getblockhash $value >> ./btc-blockhash-1k.txt
done
echo Completed
Step 2
Once you have the 500,000 block hashes, you can run the second script feeding the block hashes to each respective blockchain (blockchain-cli getblock HASHID), to get the list of tx’s for that block. The first Tx we get back is the coinbase Tx. Getting clean data out of this required me to strip out a bunch of extra ‘fluff’ to get the information I wanted from the results. Again, it’s not the most eloquent script, but it’s functional.
#!/bin/bash
currentrowcount=0
cat ./btc-blockhash-1k.txt | while read line
do
currentrowcount=$((currentrowcount + 1))
echo $currentrowcount
~/bitcoin-0.18.1/bin/bitcoin-cli getblock $line | grep -A1 tx | grep -v “tx” | sed ‘s/”//g’ | sed ‘s/,//g’ | xargs >> ./btc-txhash-1k.txt
done
echo “Done”
Step 3
Then, I ran a 3rd script to pull the transaction info (blockchain-cli getrawtransaction TXID 1) which gave me the coinbase destination addresses for each of the blocks. This will return a number of addresses where the block was mined using something such a P2Pool. However it will naturally only return one if it was solo mined, or where it was pool-mined and the pool later distributes the block rewards. Again those are not hard-and-fast rules, but just to give the average reader here a bit of an idea of what they’re looking at.
#!/bin/bash
currentrowcount=0
cat ./btc-txhash-1k.txt | while read line
do
currentrowcount=$((currentrowcount + 1))
echo $currentrowcount
~/bitcoin-0.18.1/bin/bitcoin-cli getrawtransaction $line 1 | grep -A1 addresses | grep -v addresses | sed ‘s/ — //g’ | sed ‘s/”//g’ | sed ‘s/,//g’ | sed ‘/^$/d’ >> ./btc-coinbaseaddrs.txt
done
echo “Done”
Getting the number
Finally, to get unique addresses, we cat the file, sort by unique, then run a line-count:
cat btc-coinbaseaddr-1k.txt | sort -u | wc -l
The results
This was actually quite interesting, and on the one hand I’m a little surprised, but on the other hand it’s kind of what I expected to see.
Looking at a 3-month period:
Over 500k blocks, DigiByte had 1295 unique miner addresses.
During that same time (50k blocks), LTC had 251 unique miners.
Over 12.5k blocks, BTC had 60 unique miners
Looking at a 7-day period:
Over 40320 blocks for DigiByte, we had 329 unique mining addresses
During that same time, LTC had 26 unique mining addresses
Over 1008 blocks, BTC was sitting at 33 unique mining addresses
Summary
It’s great to see that Bitcoin & Litecoin are consistently distributing the mining rewards across 50+ unique miners, and Litecoin definitely far exceeding Bitcoin in this aspect over a 3-month period. Bitcoin doesn’t seem to change much across the two periods and certainly seems far less decentralized in that aspect compared with the others.
With that said, it is very reassuring to see that DigiByte with the combination of MultiAlgo, fast blocks, and the recent addition of Odocrypt is achieving the goals of increasing the decentralization of mining. We can only hope this further improves with time.
