How many bits does it subtract it by?
03f1d41da8acf0506f3bf7140b5629dd33a5cf546133479530cd8065e335a97666 # - 13292279957849158729038070602803446
022ec3a210bcb8ef6cf7b703b39539a83dc0c1318ccdb42daf48db2f0742971239 # + 13292279957849158729038070602803446
02b70ae2dcb442548570313f652b91ca093a3acac3a2441cb64614e8195505b6b8 # - 26584559915698317458076141205606892
0367dabeef20a6a8b7b5555b162cc8c8489e3134dcec624fe028573c34dbbf20f6 # + 26584559915698317458076141205606892
02a1d21298779f888cd8169f9ed59e4383219cdadbdb342ba886034ef9013b89be # - 39876839873547476187114211808410338
02ae015703cbaee9570dc648d7bce78ac7cb438630e09d69eef4f1208655e1027d # + 39876839873547476187114211808410338
(Output omitted)
If you see the number after the # char, is that the number that is being substracted or added to the original given publickey.
I am not sure if I understand the reason to add and compare.
It makes total sense to subtract from the 120bit key and compare it with a smaller range.
Yes you are totally right, my logic in the first version was was the next:
- if the target publickey was at the middle of the range, the subtracted keys will land from the beginning of the bit range up to the end of the same bit range.
- if the target publickey was at the begging of the range, the subtracted keys will land in the first half of the bit range and the other half will land in the previous bit range
- but if the target publickey was at the end of the range, the subtracted keys will land in the last half of the bit range and the other half will land in the next bit range
- Obviously those are perfect cases, but the reality is that we don't know where is the target publickey, so my orignal idea was just increase the probability to have near a subtracted key in anywhere in the selected keyspace
But I repeat you are right i will add the option of select only make a subtract or addition.
Also think in the next one:
- if you are working with targets in the 256 bit space, any addition may end in a lower bit space due to cyclical behavior of the eliptic curve
I know you mainly build for Linux but wasn't sure if this was something you have seen/experienced before.
Yes i see that error before, is some re-declaration of that G variable (gmpecc.c load the gmpecc.h but also keysubtracter is loading that header file, i manage avoid that with the Makefile), maybe adding some header directive like #prama once can be useful , but i don't know if it can work for you.
Are you using the command "make" in Mingw64 ?
If not, can you add the command that you are using to compile it?