Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
Okay. Will break it down to you.
Tests for bloomfilter creation were made in terms of final binary image being equal for one thread and multiple threads creation.
In both cases the resulting binary image was equal.
.
Tests for bloomfilter creation were made in terms of final binary image being equal for one thread and multiple threads creation.
In both cases the resulting binary image was equal.
.
Not sure what you're trying to explain, I didn't see a mention that the insert method is thread-safe (that would have been sufficient, but also required). It's your code after all, so I guess when you get burned, you're doing it in a very assumed way. Bugs of these type can show up after executing many trillions of cycles, or instantly, depending on the input. Having identical outputs after thousands of runs means nothing, since the core issue is unaddressed.
The bloomfilter binary images are identical for one thread approach and for multiple threads.
So what is hard for you to grasp. The two have identical bits in every byte.
Mutex locks are necessary when multiple threads read, write and modify the same value. And order of their actions matters.
The whole principle of open-source code is that anyone can download and modify to the extent he desires.
Be my guest to present the improved version in your github. But I do not know what for.
It is not a puzzle-solver. RetiredC has already shown what is needed for that.
Array of GPUS and a SOTA method.
Since I have doubts that someone will ever find what is needed for inverse function to SCALAR_MULTIPLICATION.