Topic: Hash/sec Throttling for Democracy - page 2. (Read 13467 times)

I'm not sure which random number thing you're referring to, but here is a quick outline of how the generation works:

Prepare a block of memory organized as a struct - certain fields like the hash of the previous block, the current time and some other housekeeeping information is filled in.  The struct has an integer field and another 'expansion' field where the data is free form.  This free form data is altered (simple increment of a number) and then the struct is hashed.  The resulting hash is interpreted as a large integer.  If it is equal to or less than the current difficulty function then the proof of work has been found and this block is added locally and broadcast to other nodes.

This is similar to having a 100 sided die - if you roll below 70 you win.  To make the game harder you have to roll below 50, then 40, etc.  Basically there is no known shortcut to go from a desired hash value to the original input, we only know how to do it quickly in the other direction, so it is simply a brute force iterative process.  Statistically, less blocks of data will be below the target value, the lower the target value is.  Finding a block that hashes below the difficulty value proves that you worked on the problem, or got lucky and hit it on the first try, but over a long period of time you won't keep getting lucky, you'll have to try lots and lots of different values.

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.

Say I have a RNG that can output 1024 different numbers, and we run it 1024*1024 times.
We will keep statistics of how many times it gives us what number between 0 and 1024.
The more we run it, the more difference in the array between the two numbers which got out putted the least and the most.

And so, I can say with a certain amount of security without looking like a fool that how RNGs are used in Bitcoin affects the "chance" of generating a block.



We can't.
Bitcoin's Opensource so anyone can run a modified client and thus remove the cap!



The Linux kernel RNG is seeded by noise on the system actually.

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.

I've seen a number of posts complaining that coin generation on old machines is impractical (actually, the posts say impossible, but that's not correct).  A number of others have espoused the general idea that flops*luck=coins, which seems to me to be about right.  One even advocated for OpenCL/CUDA support, which seems to me like it would give those with OpenCL capable cards an incredible advantage in the "flops" category of flops*luck.  

Now, some have said "If you have no luck, you don't get coins...." but come on here...we're dealing with computers - RNGs have nothing, really, to do with luck.  They operate upon statistical averages.  (If BTC is using a true RNG based upon machine atmospheric noise, I could be wrong here, but I don't know that such a generator would be practical in that it would be too slow).  

Therefore, why not cap the number of hashes per second?  If the operations were capped at say, 250khash/sec based upon system clock and not the available number of cycles, then anyone with the "minimum requirements" could participate in generation at no disadvantage to the guy with the TESLA cluster running CUDA (okay...so people aren't going to use TESLA clusters for this...but you see my point, I hope).  Of course, difficulty would need to be adjusted accordingly to keep block generation on pace, and checks for blocks generated clients violating the cap (and thus outpacing other clients by cheating) would be required, but these are matters solved with relative ease in the code.