Quote from: zerodrama on February 02, 2014, 11:36:48 PM

Quote from: etblvu1 on February 02, 2014, 10:19:08 PM

Hi strelok369,

From a mathematical perspective, what do you think about the idea of breaking up the tendency for harmonics to develop, by replacing just the "36" portion of "SMA36LIM12" with a prime number pseudo-randomly at each block retarget, to be selected from a table? For example, if we take the least significant 4 bits of the hash of the last block, and used it to look up a table of 16 prime numbers for example consisting of {7, 11, 13, 17, 19, 23, 29, 31, 37, 41, 43, 47, 53, 59, 61, 67}. Why this sequence of prime numbers? It's the closest consecutive list of prime numbers that approaches the average of 36 that we already have in place (average of this list of primes is 34.875 and median is 31 or 37, so responsiveness to sudden changes in hash power would roughly match what we have now at 36, actually slightly better). And why prime numbers? By using prime numbers, we eliminate any unintended/unforeseen harmonics that could happen in relation to sampling sizes. Even if there is no danger of harmonics in this sense, it seems good to spread out the numbers a bit, and using prime numbers seems as good a way as any to distribute the numbers.

Thank you for your thoughts.

Etblvu1

How do you synchronize the RANDOM selection number across all clients? We have already clients that don't agree what block we're on.

That aside +9001 for short READABLE proposal. This could be useful.

Hi zerodrama,

I appreciate your thoughtful question.

All the clients inherently and necessarily agree on what the hash of the last solved block is, or else they could not agree on the next block being valid, either.

So we take the least significant 4 bits of that hash, so all the clients agree on which prime number to use from the list. So it's technically a deterministic pseudorandom number that all the clients inherently already have access to in common.

We inherently can't worry about clients not on the correct fork, so they are not a factor. Clients that aren't caught up are also not a problem, because they inherently will see the same pseudorandom number (last block known) to validate the next block as they catch up, the same exact way they already validate blocks as they catch up.

Etblvu1