Hash/sec Throttling for Democracy

Couldn't I just run 500 instances of the proposed capped client?  This is more about trading than generating - the generation is just to make it so the supply is limited.

The original question still applies here, however, and the idea that people new to the network don't have coins with which to even experiment is an issue, where in this case it is a hoarding issue of those who have come earlier.

Is it possible to have a multi-tiered coin generation system, where you would have a cryptographically difficult series that would generate a whole bunch of coins at once when the series is completed (taking a few days, weeks, or even months to complete on average), but for those who are more interested in generating coins on a more gradual basis could generate say one bitcoin or even a fractional amount of a bitcoin every few minutes or hours?

The complaint right now is that given the current number of users on the network (which has increased substantially since the slashdot story.... look at the download statistics on Source Forge with a huge spike in the last few days for downloads alone) that coins simply aren't being generated at all.

BTW, it would be nice to see if some other alternative random number generators could be used, as the current one seems to be a time-randomized Linear Congruential Generator.  (see http://en.wikipedia.org/wiki/Linear_congruential_generator for details)  BTW, feel free to correct me if I'm wrong on this point too. 

It might be kind of interesting to experiment with alternate number generators, and it certainly would be healthy for the network if more than one kind of generator was being used.  The nice thing with the LCG as a random number generator is that it can be implemented using only integer arithmetic (often with floating point operations, however) and generally is the most efficient generator in terms of simply getting a number for most common implementations (such as is found with a typical video game) with the fewest CPU cycles.  There are some classes of numerical analysis applications where a generator of this nature may not be the best choice.

Maybe, or maybe not.  It would depend upon whether the code did any checking for running clients. The software could easily run some check and prevent a machine from running more than one client.  Of course, there are ways around this, a la VMs, etc, but that's another issue altogether.


Actually, the number of outputs for the least output number and the number of the outputs for the most output number would tend, as you increased the number of runs to infinity, toward the same number.  Specifically, each would tend toward RUNS*1/RNG_RANGE.  This was my initial point - there is no luck involved - there's a mechanistic algorithmic process that simulates luck for a small set, but for any large number of runs or large number of machines performing runs, you get the result of the above formula.

Just because the program is open source doesn't mean that it can't check work for validity.  This comment is akin to saying "Anyone could modify the program to create fifty billion bitcoins, since its open source."  No.  The other nodes on the network run checks to determine that blocks (I think blocks is the right terminology, I just found bitcoin recently) are legitimate.  Similarly, there are a myriad of ways to sign work to verify that it is originating from an un-hacked client.  This would reject work from clients which had been modified to remove the cap, or to remove the limit of one instance of the program per machine.  Sure, someone is free to modify the source and remove all caps.  However, if they do that, their work would be rejected by the network of legitimate clients, and the "hacked" client would be useless unless someone wanted to start an entire new chain, and thus a competitive currency.


Yes, dev/random works this way, but it is blocking, and as I said, very slow.  Run "cat /dev/random" and see how quickly the bytes pour onto your screen - they trickle.  This may or may not be fast enough for bitcoin - I haven't delved into the source as of yet.  Conversely, dev/urandom does not work exclusively off of atmospheric noise, and thus is not truly random.   Run "cat /dev/urandom" and you'll be deluged with pseudorandom noise.  /dev/urandom, obviously, is more practical due to the fact that it doesn't hang the machine as it waits for more truly random data - it generates more as it needs it if there is none left in the kernel noise pool.  Even with fully random clients, however, they tend, statistically, over time, to the RUNS*1/RNG_RANGE formula for each output possibility.  Luck applies per each individual chance.  Statistically, as the number of blocks processed grows, it ceases to be a factor.

My key point, or key question....Do those with faster computers have an advantage, or do they not?  In the general forums people claim that the "luck" factor makes up for this...but statistics beg to differ.  Granted, and I do agree, the point is trading, not generation, but essentially with generation we're handing out free (though inflating) money.  I would like to think that the process is equitable and not based upon one's ability to afford, in USD, a beast of a machine.  This would loosely tie the initial distribution of BTC to the present distribution of USD of those willing to contribute...and seems to undermine the currency philosophically, apart from being unfair.

Thanks for all the hearty discussion on the matter, everyone.

Given our sample size of 67082 runs, I think that luck is ironed out by statistics at this point.  Finding a crypto solution by "luck" would imply that the machines began the calculations at a different starting point in instruction sequence, wouldn't it?  However, if my machine does, say, 100MFLOPS, and begins a 10-trillion operation procedure to decode a block, and another machine with 1GFLOPS begins the same procedure at ANY time when I'm not 90% done with the process, then the faster machine will always finish faster, will it not?  These are deterministic machines working on deterministic problems, with finite starting and ending points and X number of steps in between....I fail to see where luck comes in to play.

On the other hand, as I have a rather slow (but not ancient) laptop, I'd LIKE to see how luck comes into the equation...so if anyone can fill me, in, please do so.

One question...Do machines cease work on a block upon discovery that it has been finished first by someone else, or does everyone keep working on a block until he/she is done?  In this case, it is conceivable that if I happen to start the next block at the right time, I could "by luck" finish first...on the other hand, if machines all discard their current block when it is finished by someone else, then everyone is beginning the blocks at roughly the same time, and the fastest machines will win almost universally.  Anyone care to shed any clarity on the situation?

From what I've read, when a new block is discovered, the other machines will take a few milliseconds to verify if it's real or not first because say two people's computer discovered a solution within a second of each other. How do we know who the winner is? Well, again more luck. Other people's computers have to verify that your PC wasn't cheating/stupid/error/etc for the block. After a hundred or more confirmations, it's accepted by the "group" that your PC founding the winning block and everyone assigns the credit to your PC. So when two computers at the same time find the block, it's more luck on how fast it will be accepted by the group by how many other people's computers verify your find.

The chain is updated and if your neighbors computer was working on block 66777, it hears the news that your found the winning block and says "well, time to start on the next block" and begins the calculations over. Now your computer and your neighbors computer are working on block 66778, but each is doing it's own unique brute force. They aren't both working on the same brute force for the same block, otherwise, the fastest computer would always win over and over. The faster computer does have an advantage that it can brute force the next find faster than the slow guy, but the slow guy still has luck on his side.

Now imagine this with thousands of PCs out there playing the lotto every second. Just because you have a quad-core system churning 2,400 khash/s doesn't mean you are going to win every time. It makes your odds better of course, but by no means is it a sure thing just because of the raw CPU power you have. Ask the people at this forum who are running this on a server farm (like myself) and you'll see. I'm churning 10,000 khash/s on one of my systems (6 cpu) and it hasn't won a single block yet    I'm not bitter though, it proves to me that the system is being fair in the block generation, so I'm happy actually.

Okay - if everyone's machines are working on a hash to a different problem, then I can see how luck would be a factor.  However, what is the source of the variation between the problem my machine is working on, the problem yours is, etc?  One reply earlier seemed to imply that it had to do with transactions in which the individual recently took part....but what about those of us not taking part in any recent transactions? (My most recent one is at least two days old now)

But the problem for solving block X is the same across all the computers, right?  So they have a starting point, an algorithm for finding the hash, and a processor.  Each starts churning away at the instruction sequence...fastest one wins.  I still don't see the luck.



So the starting point for the crypto hash problems is different for the various nodes?  This would make sense - if a slow machine happened to get a block that needed only 100,000 steps to solve, but a fast machine happened to get a block that needed 10 trillion steps, the slow machine might "win."  My question remains, though.  What is the source of the variation between starting points?  How are the differences created?  Obviously, if every machine starts in the same place each time, the fastest machine always wins...so from where do the different starting points come?

Take this lightly until confirmed, but here's my understanding...

There is no variation in the problem itself - every node is intended to work on the same block at the same time (accounting for latencies and such). The luck factor is really the random number generated at the beginning of each node's attempt to solve a new block. When a new block needs to be solved, each node generates a random value (nonce), which is used to hash the block. If that hash isn't the right one, the nonce is incremented, and the new incremented value is used to hash the block again.

Say my clunker manages 1,000 khash/s (which it really does...  ), and you have a cluster that cranks out 100,000 khash/s, there's still a reasonable chance that my clunker will randomly (and very luckily) land on the value that solves the block within a very small number of hashes... say my nonce is a winner after only 10 hashes. I'm working out 1,000,000 hashes per second, so it only took me 1/100,000 of a second to solve the block. You cluster would have to (again, luckily) generate the right nonce in less than 0.00001 seconds to beat my lucky guess... which means your cluster would have guess correctly in less than 100,000,000 (hash/s) / 100,000 (s) = 1,000 hashes. Given the huge number of hashes possible, the likelihood of you hitting it in under 1,000 is remarkably low...

Granted, my chances of hitting it in under 10 hashes was even more insanely low, but you get the idea I think. So yes, the cluster will, overall, solve more blocks than my clunker, but it won't win out every single time.

Now that I've gone through all that... I'm sure someone will point out a flaw in my reasoning! I'm fine with that though, I want to make sure I understand it all correctly!

Edit - Laszlo said it much more conscisely, but I think we made the same point...? Hopefully!

This is a common point of confusion.  There's no such thing as being 1% towards solving a block.  You don't make progress towards solving it.  After working on it for 24 hours, your chances of solving it are equal to what your chances were at the start or at any moment.

It's like trying to flip 37 coins at once and have them all come up heads.  Each time you try, your chances of success are the same.

The RNG is the OpenSSL secure random number generator.  On Windows it's seeded with the complete set of all hardware performance counters since your computer started, on Linux it's dev/random.