Confirmed that my custom Kangaroo mods function properly with 125 bit, 160 bit and 256 bit ranges on CPU, I will keep you guys updated as I fix up GPU/networking/merge.
We appreciate it.Thank you.
Seems like it is more difficult than what I had thought. JLP said it was an easy 'mod' to take it to 256 bits.
It's not that, I'm just working under shitty environmental conditions e.g we just had a major power outage yesterday that lasted the entire day, and the internet's so $@&#ing slow here
This was supposed to be a one-week gig.I *feel* that it's almost done but when we apply DevOps Borat's Law "To estimate project duration we apply Celsius to Fahrenheit formula. C is internal estimate and F is what we tell PM: C x 9/5+ 32 = F days." I estimate I am about 75% of the way there.
Silly project management.
I was thinking one just needed to store/save the point and distances in a 256 format versus the current 128. Program I use is much easier...it's 256 and I can just change the size limit to store how ever many characters in the point and distance rows.
The problem is that there are three different representations of big (>64) bits in the Kangaroo program, a fixed-width 4-element array used in CUDA solver, the int128_t struct you showed me earlier and that Int class which is artificially masked to 125 bits, and all of these occurrences have to be expanded or otherwise decrippled.
And a bunch of unrelated stuff are shoved into the distance Int variables do all of those have to either be moved somewhere else or otherwise phased out (hence my deterministic hashtable index function using XOR of all the 64-bit parts, because apparently that used to be in bits64[2] of the distance variable!)
Kangaroo type also had to be moved out to a 32-bit variable. Sign bit was completely removed, it was only needed because Int arithmetic already %modulus's down negative numbers obtained from arithmetic overflow.
For this kangaroo program... for the tames, the distance is a private key and the point is that private keys pubkey, so the program already knows the full point/pubkey, it has already calculated it, but pubkey was choked down to 32 characters to save RAM/file storage space... it was just a matter of storing the full pubkey (64 chars) and padding the private key/distance with zeros to equal 64 characters.
May I ask which custom program is it you are referring to?
Things like this are a step backwards, why does it assume my CUDA lives in cuda-8.0/ ?
Code:
# make gpu=1
cd obj && mkdir -p SECPK1
cd obj && mkdir -p GPU
/usr/local/cuda-8.0/bin/nvcc -maxrregcount=0 --ptxas-options=-v --compile --compiler-options -fPIC -ccbin /usr/bin/g++-4.8 -m64 -O2 -I/usr/local/cuda-8.0/include -gencode=arch=compute_,code=sm_ -o obj/GPU/GPUEngine.o -c GPU/GPUEngine.cu
make: /usr/local/cuda-8.0/bin/nvcc: Command not found
make: *** [Makefile:75: obj/GPU/GPUEngine.o] Error 127
cd obj && mkdir -p SECPK1
cd obj && mkdir -p GPU
/usr/local/cuda-8.0/bin/nvcc -maxrregcount=0 --ptxas-options=-v --compile --compiler-options -fPIC -ccbin /usr/bin/g++-4.8 -m64 -O2 -I/usr/local/cuda-8.0/include -gencode=arch=compute_,code=sm_ -o obj/GPU/GPUEngine.o -c GPU/GPUEngine.cu
make: /usr/local/cuda-8.0/bin/nvcc: Command not found
make: *** [Makefile:75: obj/GPU/GPUEngine.o] Error 127
)