Quote from: kTimesG on Today at 08:38:58 AM

Quote from: AlexanderCurl on Today at 08:04:06 AM

I have tested it in a step by step manner. On my machine everything works fine with point_search.
And moreover it is just a concept code. As almost everything that can be found in the open-source domain.
What is the purpose of your presence here?

That's pretty much how MT bugs present themselves: Heisenbugs that eventually manifest sooner or later. So your code is conceptually broken, even if it passes your tests. Also, are you aware that debugging a MT program is pretty much useless when running concurrent threads, especially if you have breakpoints that are reached one at a time? So of course everything works fine in that scenario, since debugging a concurrent function is basically identical as if running it single-threaded. Tests are not even needed to spot it as a bug. This is simple CS 101. At some point, at some time, you'll have two threads accessing the same bloom filter RAM, and the CPU cache lines will screw up the bloom filter because of R/W lack of sync.

Well, my presence here is definitely not to show off broken code to n00bz that think it actually works correctly, while calling other people that know their thing as main-branch BS-ers. See it as you wish, and take from it what you want.

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.

Of course thanks a lot for spending some amount of your precious time to take a peek at my code.
Probably that break_down_to_pow10 function somehow omitted your peek.
It namely breaks the number to power of ten decomposition. That way I count the index of a bloomfilter hit.
It is a lot of consecutive bloomfilter hits. If any bit was damaged due to not using mutex lock Private key recovering could not be possible.
No matter what random scalar i chose n, matter what range, works like a charm on my side.
According to you I should smash my PC to pieces for showing right result when it should not.

The whole thing is just idea sharing that came from testing even/odd concept. This is not puzzle-solver or some BSGS improved version.
If you see ways to improve that concept well be my guest.

Every coder should somehow know that checks are nessary where they are really needed.
I do not put checks where not necessary.

Even JLP did not put (scalar % N) in his ComputePublicKey class method.
And lately one starter guy have found out and now thinks he can use that to break secp256k1 curve.
Well I tried to explain. But he keeps thinking that way anyway. Grin

.