Not is not that, the bloom filter that he is using have some bugs i report those bugs to the developer of the bloomfilter
https://github.com/jvirkki/libbloom/issues/20But the developer update it some year before that, i solve by my own implementation.
I notify to KV but he didn't solve as far i can remember
What or who do you mean by KV ?
So for small list of address it work fime, but for bigger lists it can fail.
Yes, for small list of address or a single address the bug that I'm describing don't exist, so it will work fine, but i don't know if there are other errors there.
Are you saying if your address list contains close to 2^32 addresses, a bug may exist, as you described above? That’s a large number of addresses! I’ve ran it with 2^28 addresses and found the key I had put in there as a POW address.
Yes the bug exists, but the behaivor of it is unexpected
if you see this PoC:
https://github.com/jvirkki/libbloom/issues/20Items 4194304 bloom filter bytes 7537997
Items 8388608 bloom filter bytes 15075994
Items 16777216 bloom filter bytes 30151987
Items 33554432 bloom filter bytes 60303973
Items 67108864 bloom filter bytes 120607946
Items 134217728 bloom filter bytes 241215893
Items 268435456 bloom filter bytes 482431785
Items 536870912 bloom filter bytes 427992657
Items 1073741824 bloom filter bytes 319114402
Items 2147483648 bloom filter bytes 101357891
Why more items in the bloom lead to a lower number of bytes? Look carefully:
Items
268435456 bloom filter bytes
482431785Items
536870912 bloom filter bytes
427992657Items
1073741824 bloom filter bytes
319114402Items
2147483648 bloom filter bytes
101357891If understood correctly the mismatch occurs after 536870912 items, so up to 536,870,912 (2^29) there are no issues and errors in KeyHunt-Cuda implementation by Qalander or Manyu, can anyone confirm this?
I updated my bloom filter implementation to use xxhash (64 bits) instead of murmurhash (32bits), because with murmurhash if the number of addresses in the list, is near to 32 bits then the bloom may be some saturated because almost any data tha that you pass to the bloom filter will do a collision. Look the original code in
https://github.com/jvirkki/libbloom/blob/master/bloom.c#L57 With a 64 bit hash the problem will be solved, but the original bloom may never change it because compatibility reasons. the KV version may have some other bugs but since it was some kind of copy of my keyhunt, i prefer to improve my own version than fix another versions.
@albert0bsd
if I read between the lines correctly, there seems to be something bothering you about the versions of KeyHunt-Cuda available on github (I'm thinking of the versions of Qalander and/or Manyu). I'm guessing that you may be upset because they may have stolen code from you or otherwise misused it without giving you credit. But that's just my guess. At least I read out that you have no interest in a cooperation with them. Nevertheless, thank you very much for your work so far and for sharing your programs with the community. Hats off and keep it up!
Out of pure curiosity and personal interest in a working KeyHunt-Cuda version, I'd like to ask you: for what reasons haven't you designed a CUDA-enabled version yet? Working with CPU is completely behind for the purposes after all, GPUs simply have the highest power and performance. Or did you design a KeyHunt-Cuda version in the meantime and I missed it and didn't notice? Am curious and look forward to your answer.
I would be very interested in a multi-GPU CUDA capable KeyHunt versio that comes with a fully functional bloom filter and can handle not only p2pkh legacy (compressed and uncompressed) but also p2sh and bech32 addresses. That would be gigantic. But I know, that's not a wishful thinking and surely needs a lot of work. Does anyone know if something like this already exists ? I am looking forward to your feedback.
Nice config, I really wish you good luck, you will need it
