POW idea

[zawy12]

I'm exploring the following procedure in this Github and have implemented it in the code file pow_gpu.cpp. It's hopefully a demonstration of how to make it difficult to improve the efficiency of a GPU by optimized coding, and to possibly make it difficult for a GPU to do better than a CPU on a hash/electricity basis. It does not protect against FPGA's or ASICs because the core functions can be optimized, but I'll try to use its structure to try to construct much more general algorithms on the fly in each iteration of each nonce. My next comment in this issue will start exploring that.

"function" can be any valid program that has a standard output type (I've chosen doubles and math functions for now).

// coin defines it own functions
myhash = ffx32;
while (myhash >= target) {
   nonce++;
   h =  sha256 ( "previous_block_hash" + "nonce");
   seed = get_seed ( h )
   for (1 to 10,000)  { 
       sequence = get_a_sequence_of_functions ( seed )
       for (1 to N_functions) { 
           seed = execute_function ( seed );
           seed = normalize_seed_to_safe_input_form ( seed );
       }
   }
   myhash = hash(seed)
}
claim my block;

I've chosen math functions for C++ that I hope a GPU can't optimize or do better than a CPU (due to its internal math co-processor). The functions' slowness makes the support code become less relevant. I have to select the function, normalize the output, shift it a variable way based so it's not connected to previous math function, and prevent potential round off error. The 3 lines to do this are:

// The following takes 40 ns.
long double seed = frexp (k , &n); // get significant digits from the output from previous function
// Now reject top 2 b/c above output is binary weirdness (0.50 to 0.99). BTW, conversely, bottom 
// 2 digits of doubles are not random b/c they are needed to convert decimal to a precise binary.
seed = modfl (100*seed , &intpart); // Turn top 2 fractparts into intparts & get remaining fractpart 
seed = (int64_t)(seed*1e12); // Reject bottom digits to prevent rounding differences. Faster than trunc().

A FPGA might have a big advantage by having dedicated circuits for each of the small number of functions I've chosen. This paper shows how to calculate cosine (or sine) in 30 clock cycles, where my code requires 235 cycles on my CPU. This paper says CPUs can't compete with FPGAs for individual math functions. It appears FPGAs can do the basic math functions I've used with 10x less electricity.

Speeds on 3.4 GHz intel i7-2600 with doubles. Add about 30% for long doubles. Notice the last calculation consists of 3 really fast functions, inverse, erf, and sqrt.

if ( functs[seq] == 1 ) { k = pow(k,5.123); } // 60 ns
else if ( functs[seq] == 2 ){ k = log(k); } // 80 ns, 100 ns w/ long doubles
else if ( functs[seq] == 3 ){ k = exp(k*1e-11); } // 72 ns
else if ( functs[seq] == 4 ){ k = sin(k*6.28e-12)+1.01; } // 70 ns, 88 w/ long doubles
else if ( functs[seq] == 5 ){ k = asin(k*1e-12); } // 30 ns, 50 w/ longs
else if ( functs[seq] == 6 ){ k = sinh(k*1e-11); } // 55 ns
else if ( functs[seq] == 7 ){ k = asinh(k*1e-12); } // 53 ns asinh(k*1e-12); 
else if ( functs[seq] == 8 ){ k = 1/erf(0.001*sqrt(sqrt(k))); } //  40 ns, 60 w/ longs 

[zawy12]

This is a more general algorithm generator, hopefully hard for any architecture to do much better than a CPU.

myhash = ffx32;
while (myhash >= target) {
   nonce++;
   h =  sha256 ( "previous_block_hash" + "nonce");
   seed = get_seed ( h );
   while (timer < 1)  { 
       get_for_or_if_with_data_type ( seed ); 
       get_object_data_and_type ( seed ); 
       get_action_to_perform_on_data_and_loop_var (seed ); // very simple
       seed = perform_conditional_and_action_on_object_data ( );
   }
   myhash = sha256(seed)
}
claim_my_ block();

There are many complexities to work out. The per-iteration constructor has to be faster than its execution. "timer" is slow. Could use a definite number of iterations, or test timer once every x iterations, and test for seed < some value. The if statement might need to be no more or less than a NAND gate: unless ( a > b || c > d) { } and it would need to be capable being fed back up to previous constructions, so the termination of the for and if blocks can't be each iteration. (A NAND gate output should be capable of being fed back into to previous NAND gates for feedback). Definitely terminating then becomes a problem. So a timer or counter becomes necessary.