Yes, seems that way.
Hopefully a major hardware upgrade!

Friedcat in the latest update:


Any idea what "exponentially increased devices" means?
Does this mean they're planning on assembling a large number of "old" devices?
Or does that mean that they're planning to assemble some form of better devices ("gen1.5")?
Or even gen2 chips (this I doubt, since the plan was November at the earliest)?

Block discovery is still Poisson distributed.
According to Wikipedia: "[...] the Poisson distribution [...] is a discrete probability distribution that expresses the probability of a given number of events occurring in a fixed interval of time and/or space if these events occur with a known average rate and independently of the time since the last event."
What matters is the average rate. It does not matter that the rate fluctuates.
So we do have a Poisson distribution, though we don't know the average rate exactly.


Using your coin flipping analogy: Why not flip the coin 500 times? 5000? An infinite number of times? This is uninteresting. Given very long time periods we can expect any number of unlikely events (e.g. Boltzmann brains).
What we are interested in is a given 6 hour period.

Nice!
I wonder how/why that happened.

Is it possible that the "low transaction number per block" problem has been solved?
E.g. this block
http://blockchain.info/block-index/411874/0000000000000038473a6c40b4fd8b0c78eaa597292e2ebd1107b8fdfdbec11d
contains 619 transactions and 0.37 btc in transaction fees.

Agreed: The 6 and 12 hour estimates are essentially useless.
But maybe we could have the estimated stddevs for the longer-term (maybe 24 hour and above) hash-rate estimates?

Yes, over a week it is indeed not too important.
However, it would seem that it makes little sense to display 6 hour and 12 hour hash rate estimates on, e.g. http://www.asicminercharts.com/live/ . Even 24 hour estimates are quite unreliable: stddev of 26% assuming 10% network control, 37% assuming 5% control.

Or maybe the charts could be modified to include this standard deviation, so that the level of uncertainty can also be visualized?

Regarding variance in general:

Since blocks are randomly discovered, the number of blocks discovered over a given period of time is Poisson distributed.
The expected number of blocks discovered by ASICMINER in a week is: 6*24*7*network_fraction.
Since in a Poisson distribution, the mean is equal to the variance, and the standard deviation is equal to the square root of the variance, we have a standard deviation of
sqrt(6*24*7*0.1), or approximately 10 blocks, assuming ASICMINER controls 10% of the network, or
sqrt(6*24*7*0.05), or approximately 7 blocks, assuming ASICMINER controls 5% of the network.

This means that the standard deviation is approximately 10% the expected number of discovered blocks if ASICMINER controls 10% of the nework, or 14% if ASICMINER controls 5% of the network.
If this is a lot or not is up for debate, but it is not insignificant.

Using the same math, we get a standard deviation of 53% (assuming 10% of network) for a six hour window and 37% for a 12 hour windows. That's quite a lot.

Got it, thanks!
Sorry for not reading the README.

Can anyone tell me how to get a higher status than newbie?

Do miners really require the whole blockchain to verify transactions? It would seem that it would be more efficient to have a database containing which address is allowed to spend how much, rather than traversing the whole blockchain to verify each transaction.
Related to this: If miners indeed use such a database, why not periodically "summarize" the blockchain? What I mean is: Old blocks are summarized using such a database. Then, the old blocks can be discarded and replaced with the database. It would seem that this scheme would dramatically decrease the size of the blockchain. Why is this scheme not implemented?

Interesting!
How would that work exactly? According to https://en.bitcoin.it/wiki/Script, script only has a limited set of instructions, and I fail to see anything related to time.
What also worries me is the statement "Note that there is a small number of standard script forms that are relayed from node to node; non-standard scripts are accepted if they are in a block, but nodes will not relay them.". Could it still be made to work somehow?

Is it possible to do something like this:
"A" pays x bitcoins to "B", but wants B to be able to spend the x bitcoins no sooner than on some date that is pre-defined by "A". Does script allow this maybe?
If this is possible, "A" could send all his bitcoins to himself, but only allow himself to spend his funds after a certain date. This would temporarily freeze his funds and could be regarded as a present to the network: The money supply is temporarily provably reduced.