deepbit version 2.0?

0. Introduction
Although the violin plots used previously were quite good at showing trends, they weren't so good for showing clear changes to total pool hashrates and total numbers of miners, or how particular amounts of hashrate changed over time. As well as this, the violins were not a good method to present an open ended chronological series.

So instead I grouped user hashrates and plotted by time:

The number of user accounts in that group.
The total hashrate attributable to that group.
All the charts in this post represent this, using various colours to represent various groups of hashrate. Think of them as a layer cake, building upwards to a total number of miners or total hashrate and to the right over time.

In doing this I gained new insight into how users hashrates were changing, and also noticed a problem with Itzod's miner count - it seemed to top out at 500 miners. On investigation I realised this was a problem with the way I'd been scraping the data which is now fixed.



1. Change in miner count and grouped hashrates by pool.
Each coloured layer in the charts below represents either the number of miners (left plot) or the total hashrate contributed by that group (right plot) - ASICMiner solo will of course only ever have a miner count of 1.

Some trends are evident:
Nearly all miners have a hashrate less than 5 Ghps, but user accounts with more than 5Ghps contribute far more to the total hashrate of each pool.
The amount of very low hashrate miners at BitMinter has decreased and the amount of hashrate contributed by high hashrate miners has increased significantly, and the same is true for BTCGuild.
The number of low hashrate miners at Eligius has increased.
At Ozcoin and HHTT, miners with hashrates greater than 5 Ghps make up more of the user base than at other pools.
1 - 4.99 Ghps miners at P2Pool, Itzod and Polmine contribute more to the total hashrate than any other group.
I'll leave it to the reader to find the other trends in visible in the charts.

It should be noted that the data from the end of January to mid April is interpolated. I have no data point in that time frame. After that point data points are weekly (or every few days).

0. Introduction

For a while I've been trying to find better ways to present pool hashrate distributions. Pie charts are OK - most people understand them (although as you should all be aware, pie charts have severe problems and can mislead you), but I wanted something that a) was not misleading and b) could show proportions of the network attributable to specific pools. I also wanted to show cumulative data, rather than the plots I usually use to show the historical hashrate distribution.

.....

I thought this would be a problem, so the charts don't show hashrate - just blocks per week and then blocks per week as a percentage of total of network blocks per week. Do you have block history going back before that?

NOTE: There will be no Weekly Pool and Network Statistics this week, as I'm going to having a communications-free week. Instead, I've written a short post commemorating one of the strangest and most fun pools of the last couple of years.

0. Introduction

Recently, fireduck (the pool operator of the HHTT bitcoin pool), announced that he would be closing the pool on New Year's Day. This made me a little sad, since it was a great pool which had some innovative fee mechanisms, and was one of the first pools to take variable share submission difficulty seriously. The open source stratum server he developed has been used by at least one other pool (just grep "SOCK" in the coinbase and you'll see which one) and saw very little downtime.

From my (non-mining) point of view, however, the best thing about HHTT was the sporadic and weird coinbase messages. I had been planning a post about my favourite bitcoin blockchain coinbase messages, but as a remembrance of all things HHTT I decided just to focus on theirs.

The chart below shows HHTT's percentage of weekly network blocks solved, and if you click on the image you can read the coinbase messages that were added at that point in time. If you haven't got a magnifying glass handy (since Blogger seems to compress the chart somewhat) then HHTT's unicode coinbase messages, along with the block height of the block with which they were included, are here: http://bitbin.it/VOXWstm9. I will leave it up to the reader to translate the Japanese keyboard emoticons (such as ╯°□°）╯︵ ┻┠┠) . It should also be noted that block 229417 message appears to be not a penis, but an ASCII sword. Finally, "Finders keepers" had half a coin in it and was found not long after the message appeared. More like that, I say!

So long and thanks for all the weirdness, fireduck. I had lots of fun wondering what weird message you'd come up with, and was more than a bit disappointed that I hadn't seen any recently. There should be more creativity and fun in the blockchain!



organofcorti.blogspot.com is a reader supported blog:
12QxPHEuxDrs7mCyGSx1iVSozTwtquDB3r

We are chums. I respect you more than almost anyone in BTC land. I am under attack from gmaxwell right now so I am a bit unpolite. Sorry.

0. Introduction

It has been a while since I last mined, and when I heard that Gridseed ASICs could mine both bitcoin and litecoin, I decided to throw caution to the wind, ignore the fact that I may never get a return on my investment, and purchase a batch of ten through seeds over at bitcointalk.org (in case you're in the market for a Gridseed miner, I can recommend seeds: he delivered within ten days, and when I had problems setting the miners up he had an engineer help me out remotely)

These ASICs can mine either bitcoin or litecoin or both simultaneously, although the point of simultaneous ltc and btc mining eludes me - surely one would simply mine whichever coin was most profitable at the time?  When mining bitcoin (SHA256 mode) one device can produce 8 Ghps at 53W; mining litecoin (scrypt mode) one device can produce 300 Mhps at 7W.

So, which is more profitable to mine with a Gridseed miner - bitcoin or litecoin?