That occurred to me while writing the comment, but I assume there are other factors which could be worth monitoring and improving, for example network topologies or even cooling methods.
A little note about the "make a privkey" section of the signature example; it can sometimes* make invalid privkeys that are off the end of the EC curve. Only integers between 0x1 and 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141 are valid in our particular case. Super unlikely to ever get a sha256 hash that matches the invalid portion, but it's worthwhile to point out.
This curve order limit actually introduces a small bias. You can choose a number greater than a curve order, but then it'll be taken modulo the order, so some incredibly small amount of numbers will be biased closer to zero. In practice the probability to hit such numbers is less than 2^-128, so you may easily skip all checks and take the number as is. Of course, nitpickers will nitpick and that's why in all standards that describe key and nonce generation (BIP32, RFC 6979 etc), you'll see boilerplate code that checks for such numbers and does some extra cumbersome computations just to avoid these from happening.
In a decentralized consensus every single node must have the same behavior, handle errors the same way, make the same decisions based on the same core rules. Experience with Bitcoin has taught us that nobody is currently capable of duplicating the Bitcoin behavior perfectly. Many have tried such as bitcoin-ruby (ruby) and btcd (go), but they are plagued by almost constant issues of them having different states and getting forked off the network.
Starting with three different languages, three different codebases is absolute madness.
Madness? Tackling problems (consensus, protocol, etc) early on a "stupid move"? You believe that copying bugs (as something you'll have to do if you want to create a new btc node from scratch) is something we should strive for? Having another client to fall back to if there's a bug in one of the others is, again, "a stupid move"?
"Many have tried such as bitcoin-ruby (ruby) and btcd (go), but they are plagued by almost constant issues of them having different states and getting forked off the network."
This is _exactly_ why you should have multiple, clean room implementation from the start.
Oh btw, we've already got consensus with 3 full nodes for quite a while.
It's not about number of users, it's about liquidity for the money/currency in question (whether it be bitcoins, litecoins or "ethers").
Ie. how much will selling/buying a certain amount of the currency affect the market price. This is what defines money: high liquidity (market depth). Something cannot be money without this property. It might have the potential to become money, though. But without liquidity it is as much money as baseball cards and wine.
