Search content
Sort by
Showing 20 of 157 results by AlexanderCurl
Re: Mark1 - pollard rho implementation (38 minutes for 80 bits solving on CPU)
P.S Publish your code that implements what I explained and fails to work. Since I have a clear picture of what should be going on there I can make modifications to make it work. But I am sure you will not do that. Because you did not do anything and your goal is just "for your personal kicks" to prove that everyone is wrong but you.
Batch addition for static delta points and/or shared inverses to do P±Q doesn't work in Kangaroo nor rho (which is what this thread is about before you hijacked it with your evolutionary breakthrough). This was the whole point.
Otherwise, you're simply trying to do something which has long been done in KeyHunt, JLP, etc. However it feels like you are stating that you found a way that saves on storage or lookup. Maybe you should take a piece of paper, draw your idea on it, and maybe notice how it fails reducing any of the complexity or required storage whatsoever. The intersection / collision can only be optimal if sqrt(n) points are stored, no matter what clever trick geniuses try to come up with.
Here's what I got from you explanation. If it's wrong, maybe explain it better. You wanted to save / check the "middle points" or something like that, right? The red point is the real (and unique) BSGS collision, blue points are the saved points, green points are the checked giant points. Collision is missed since it would jump right through unsaved / unchecked points in both baby and giant ranges.
Just as I thought. Nothing more than usual crap that is constatntly coming out of you.
Re: Mark1 - pollard rho implementation (38 minutes for 80 bits solving on CPU)
If something doesn't work on a freaking PAPER, I'm not sure how it could ever work in practice.
The crappy bullshitter never stops!!! 
Go fuck youself stupid dork!!! I've sent you back all the merit points I had. I now owe you the rest of 11 points, I will compensate it back when I can afford it.
I don't need anything from people like you. Also, your idea is genius, so forgive me. That would be a cool Kangaroo Hopping!!! And your BSGS optimization is spot on. Let's reduce that bitch down to .5 sqrt, magical batch addition, yay.
Yeah do that!!! I have respect only for worthy people and not the kind like yourself. You been told that many times here. The one who is disrespectful to others - what could you expect?
Re: Mark1 - pollard rho implementation (38 minutes for 80 bits solving on CPU)
⭐ Merited by kTimesG (22)
Exacly my answer is for Akito and not for you. I guess he understood what I meant. And moreover I heard that fairytale from you before that something "will not work or should not work and only you know how". Let alone that explanation of mine is pretty simple to implement and see that it works. I have much complex ones that work as well when I implement them but it is a waste of time explaining something to you.
Eagerly waiting for someone to implement it just so they get bit in the ass. Maybe you should be the magician to do it, since you're the one claiming that it speeds up anything, using a concept that can only increase the number of operations (or even worse, that isn't even applicable to the issue).
If something doesn't work on a freaking PAPER, I'm not sure how it could ever work in practice.
The crappy bullshitter never stops!!!
Go fuck youself stupid dork!!! Re: Mark1 - pollard rho implementation (38 minutes for 80 bits solving on CPU)
It works fine the way I explained it on my PC and my implementation. I am not interested in Kangaroo and never refer to it.
Here is the TEMPLATE for you.
Here is the TEMPLATE for you.
Thx for the template, but I already use that in my PointsBuilder demo.
I think you misunderstood my point though. This batch addition that computes both P + Q and P - Q has no usefulness outside BSGS or simply building that specific array of results (e.g. for brute-forcing the H160).
It simply slows down the processing, since there is nothing useful for having both of those points computed. Maybe you should read again what Akito was asking, but more carefully. The answer to his question is that having a DP obtained via P - Q will almost never be hit from another route then the current one, since the pseudo-random walk ends (the point is not used as a new base point). It's basically equivalent to having a DP which is 1 bit lower, however the processing is slowed down. The probability of having it hit by another walk is so close to zero, that it's simply not worth computing it at all. RC does use it though, but not always, and it's for a different purpose anyway.
And for rho or Kangaroo, you always, always need the Y coordinate, because it's needed to actually do the next jump. So your "let's only compute X" is useless for this case.
Exacly my answer is for Akito and not for you. I guess he understood what I meant. And moreover I heard that fairytale from you before that something "will not work or should not work and only you know how". Let alone that explanation of mine is pretty simple to implement and see that it works. I have much complex ones that work as well when I implement them but it is a waste of time explaining something to you.
Re: Mark1 - pollard rho implementation (38 minutes for 80 bits solving on CPU)
Maybe this is a stupid question, but is it possible to make the same Kangaroo have both odd and even DPs, like @AlexanderCurl does? Could we reach 90-bit *f* this way? 
That would be a cool Kangaroo Hopping!!! If BSGS is concerned one of possible ways is to divide the range according to the number of cpu cores and start the search from the middle of each interval using batch logic and calculating only X coordinate for the batch_size - 1 and the last one full (x,y). Make a database from the target point as large as your RAM can hold. Or since you know the size of each block do calculations to put the point closer to the middle. Maybe that way you can hit higher bits. But that depends on what time you have on your mind for that collision to happen.That's only useful for brute-forcing, however brute-forcing is un-needed for DLP problems.
For BSGS this trick is also useless because it requires shifting the key by range/2 (to have the same-X mapping to 2 points), but the shift itself may move the point in the left side, which means the solution will never be found (unless you use two giant points instead of one, so zero benefit overall).
Someone shut the fuck up that bonehead. Try to implement this and see for yourself.
Cool. But I did implement it, that's why I said it doesn't work. Otherwise, you might have explained things in a way that wasn't understood.
It's pointless to use the X coord and use batch block points the way you (tried to) explain. It simply doesn't work the way you attempted to explain. And for kangaroo, this is even more pointless.
Re: Mark1 - pollard rho implementation (38 minutes for 80 bits solving on CPU)
Maybe this is a stupid question, but is it possible to make the same Kangaroo have both odd and even DPs, like @AlexanderCurl does? Could we reach 90-bit *f* this way?
That would be a cool Kangaroo Hopping!!! If BSGS is concerned one of possible ways is to divide the range according to the number of cpu cores and start the search from the middle of each interval using batch logic and calculating only X coordinate for the batch_size - 1 and the last one full (x,y). Make a database from the target point as large as your RAM can hold. Or since you know the size of each block do calculations to put the point closer to the middle. Maybe that way you can hit higher bits. But that depends on what time you have on your mind for that collision to happen.That's only useful for brute-forcing, however brute-forcing is un-needed for DLP problems.
For BSGS this trick is also useless because it requires shifting the key by range/2 (to have the same-X mapping to 2 points), but the shift itself may move the point in the left side, which means the solution will never be found (unless you use two giant points instead of one, so zero benefit overall).
Someone shut the fuck up that bonehead. Try to implement this and see for yourself.
Re: Mark1 - pollard rho implementation (38 minutes for 80 bits solving on CPU)
Maybe this is a stupid question, but is it possible to make the same Kangaroo have both odd and even DPs, like @AlexanderCurl does? Could we reach 90-bit *f* this way?
That would be a cool Kangaroo Hopping!!! If BSGS is concerned one of possible ways is to divide the range according to the number of cpu cores and start the search from the middle of each interval using batch logic and calculating only X coordinate for the batch_size - 1 and the last one full (x,y). Make a database from the target point as large as your RAM can hold. Or since you know the size of each block do calculations to put the point closer to the middle. Maybe that way you can hit higher bits. But that depends on what time you have on your mind for that collision to happen.Re: Mark1 - pollard rho implementation (38 minutes for 80 bits solving on CPU)
NoMachine, plz return your GitHub back!
I like your coding skills (and readme files), and Mark1 is the deep refactoring and a few reingeneering of your Kangaroo-hops file.
I updated Mark1.cpp code
I like your coding skills (and readme files), and Mark1 is the deep refactoring and a few reingeneering of your Kangaroo-hops file.
I updated Mark1.cpp code
Code:
/***************************************************************************************************
* Pollard–Kangaroo (wrap-aware, user-configurable k, live counter, loop detector, restart counter)
* Coded by DooKoo2
* Load/Save DP tech by NoMachine
*
* g++ Mark1.cpp Int.cpp SECP256K1.cpp Point.cpp Random.cpp IntMod.cpp IntGroup.cpp Timer.cpp -O3 -march=native -funroll-loops -ftree-vectorize -fstrict-aliasing -fno-semantic-
* interposition -fvect-cost-model=unlimited -fno-trapping-math -fipa-ra -fipa-modref -flto -fassociative-math -fopenmp -mavx2 -mbmi2 -madx -std=c++17 -fopenmp -pthread -o Mark1
*
***************************************************************************************************/
* Pollard–Kangaroo (wrap-aware, user-configurable k, live counter, loop detector, restart counter)
* Coded by DooKoo2
* Load/Save DP tech by NoMachine
*
* g++ Mark1.cpp Int.cpp SECP256K1.cpp Point.cpp Random.cpp IntMod.cpp IntGroup.cpp Timer.cpp -O3 -march=native -funroll-loops -ftree-vectorize -fstrict-aliasing -fno-semantic-
* interposition -fvect-cost-model=unlimited -fno-trapping-math -fipa-ra -fipa-modref -flto -fassociative-math -fopenmp -mavx2 -mbmi2 -madx -std=c++17 -fopenmp -pthread -o Mark1
*
***************************************************************************************************/
He is definitely right. NoMachine there was no obvious reason to delete your account just because of some stupid dork writing shit. For example I code for my pleasure and share code in case someone might find it useful. And I do not care a bit about someone telling me where I am wrong or what to do. I have marked all you repos with postfix _NoMachine in my repo. Waiting for your comeback on github...
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
You forgot to mention the even/odd inverse function. The problem is still open.
Yo, you're on the right track with that batch point addition logic from JLP, especially how you're mixing in batch processing like Cyclone does. But here’s the thing. You need a compressed database. Or, if you wanna keep it light, whip up a database that only takes up 8 bytes. Kinda like that slick public key database from @Mcdouglas-X3. That’ll speed things up big time, givin’ you enough bandwidth to hit at least 90 bits.
[/quote]
Definitely JLP has implemented the fastest logic possible.
But of course it is not his invention but many others from pro cryptography domain.
I will implement JLP way in Point_Search just for kicks. And yes using compressed database could make things better.
Hitting any higher bits with CPU code like 80..90bits depends on the size of elements used for database for sure.
Point_Search is by design not a puzzle solver. But emerged from testing even/odd concept. That is what interests me most.
I have an idea for improved BSGS with bloomfilter JLP way, but way of scanning the space a little different. Havent tested it yet.
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
Of course pity for those who think that someone will publish here some code that will make them rich overnight.
Especially funny I find here those saying that they can find here nothing interesting and introducing themself as experts of some kind.
The best thing for them would be to join some pro cryptographers and math geeks forum to find new ideas there.
But they hang around reading every thread to prove to themselves that they can find here nothing. Some pretty odd situation.
Especially funny I find here those saying that they can find here nothing interesting and introducing themself as experts of some kind.
The best thing for them would be to join some pro cryptographers and math geeks forum to find new ideas there.
But they hang around reading every thread to prove to themselves that they can find here nothing. Some pretty odd situation.
Yes my friend you are right. In many platforms, everyone is full of free code, dreams of getting rich.
Many of the people who want to show themselves as EXPERTS have become famous only with the answers given through AI (Artificial Intelligence).
I do not think that people who are cryptographers or math experts will want to come here. Because here, a person who comes will immediately encounter trolls or people who give similar answers, so they will not come.
Actually the subject is very simple, as the creator said.
"Testing the power of society." But many people I see do not deserve to be a society or a group.
I have already experienced that power of trolls. To me it looks like one psycho personality having multiple accounts.
He does not spread his trolling acts to github though because he knows the owner can delete such issues. Here they seem to do nothing about it.
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
I wonder how many million years it takes you to solve puzzle 135?
Scripts based on public keys and x and y coordinates are completely useless here because there are no public keys until puzzle #135. There are only two logical options: either invent a new algorithm that will compute HASH160 1000 times faster, or go for 2000 GPUs. I don’t know which method is worse. In any case, this is a dead end. All we can do is showcase useless scripts. Which is exactly what we’re already doing.
You forgot to mention the even/odd inverse function. The problem is still open.
Not a single brightest mind on this planet can find the solution. Otherwise one would know the keys to satoshi treasures.
Pesonally I do not compete on who will introduce the best C++ or GPU program.
For me the main interest is in learning new things. Programming itself is a good way to keep the mind spinning.
Of course pity for those who thinks that someone will publish here some code that will make them rich overnight.
Especially funny I find here those saying that they can find here nothing interesting and introducing themself as experts of some kind.
The best thing for them would be to join some pro cryptographers and math geeks forum to find new ideas there.
But they hang around reading every thread to prove to themselves that they can find here nothing. Some pretty odd situation.
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
Locking the batch compared to locking just bf.insert is faster time-wise.
This probably depends on the batch size. Since the atomic lock is basically just a clock cycle, this might indicate that multiple cores are often accessing overlapping RAM areas, forcing I/O between CPU caches and main memory.
I think a synchronized queue fits better, and it fills the compute pipeline. Add the hashed pubKeys to the queue (and signal addition), consume them from an auxiliary thread (using signaled events). This ensures no false sharing of L1 cache occurs, and no threads get blocked (unless the queue itself goes OOM).
Thanks a lot for explanations. Will definitely see to it. But I do not feel like improving Point_Search further. At least not now.
I have recently came to a new idea. Will devote my spare time to put it to code.
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
The most amusing stuff using mutex locks and creating bloomfilters with the same inputs two times in row.
Code:
alexander@alexander-home:~/Documents/Test_Dir/Point_Search_GMP$ diff bloom1B.bf bloom1.bf
Binary files bloom1B.bf and bloom1.bf differ
Binary files bloom1B.bf and bloom1.bf differ
What did you expect? I looked at your update, and you are simply creating multiple mutexes, one for each thread that runs process_chunk. And locking the entire loop. Basically protecting nothing.
That's not mutexes are for. You only need a single mutex, and you only need to lock the "bf.insert" call, not the entire loop (or else the entire loops will be exclusive).
I'd personally move the mutex to the bloom filter code, and further block only the actual code that accesses data which can potentially be shared (for example, the hashing part probably doesn't need exclusive access).
But I'm glad that at least you got to a case where you can clearly see that the output is wrong, when synchronization is missing. So which one of those 2 outputs is the right one? You'll never know, since they were basically in a race condition, running both in parallel under different mutexes (so, identical as not having a mutex at all).
If you wanna go fancy you can implement a multi-mutex scheme, one for each some memory area size, and only lock the specific mutex for the area the bloom filter writes. This may increase throughput, or it may not, the right balance needs to be found by trial and error. But this is not a programming thread, after all.
LE: another option is to compute the points in parallel, and queue them in a producer-consumer fashion. And consuming the queue in a single thread, that only does the BF insertions. This simply moves the sync on the queue itself, of course, if you don't want to mess with the bloom class.
for (int i = 0; i < POINTS_BATCH_SIZE; i++) { // inserting all batch points into the bloomfilter
BloomP.x = pointBatchX;
BloomP.y = pointBatchY;
std::lock_guard<std::mutex> lock(mtx);
bf.insert(secp256k1->GetPublicKeyHex(BloomP));
}
Exactly. Locking the bf like this leads to nothing. The same. May be no diff. Might be multiple.
But the running instance yields the right result even so no matter what. Has no impact after all. 69 bits. Tested.
AMD Ryzen Threadripper PRO 5995WX I guess that monster could push it to 80bits with further improvements.
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
Writing a value involves reading the value.
Since each thread is just a sequence of instructions. We can log each step of its insertion way and compare the results afterwards.Yeah, but those instructions run in parallel, hence it's guaranteed that, without an access sync, at some point, a r/w race condition will occur. You should know best what'ya doin', so I won't insist.
Or are you saying this can never happen:
Code:
X = 0
Cycle T0 T1
0 read X read X // T0: is X 0 or 32? T1: is X 0 or 8?
1 set x[3] set X[5] // T0: is X 8 or 40? T1: is X 32 or 40?
2 write X write X // what X is final? what about cache lines refresh?
3 X = ???????? // one of 8, 32, or 40
Cycle T0 T1
0 read X read X // T0: is X 0 or 32? T1: is X 0 or 8?
1 set x[3] set X[5] // T0: is X 8 or 40? T1: is X 32 or 40?
2 write X write X // what X is final? what about cache lines refresh?
3 X = ???????? // one of 8, 32, or 40
The most amusing stuff using with locks and creating bloomfilters with the same inputs two times in row.
Code:
alexander@alexander-home:~/Documents/Test_Dir/Point_Search_GMP$ diff bloom1B.bf bloom1.bf
Binary files bloom1B.bf and bloom1.bf differ
alexander@alexander-home:~/Documents/Test_Dir/Point_Search_GMP$ diff bloom2B.bf bloom2.bf
Binary files bloom2B.bf and bloom2.bf differ
alexander@alexander-home:~/Documents/Test_Dir/Point_Search_GMP$ xxd bloom1.bf > 1.hex
alexander@alexander-home:~/Documents/Test_Dir/Point_Search_GMP$ xxd bloom1B.bf > 2.hex
alexander@alexander-home:~/Documents/Test_Dir/Point_Search_GMP$ diff 1.hex 2.hex
22207627c22207627
< 152dc8a0: 3ad7 2abf 9562 b27b 8582 d16f 1141 f67c :.*..b.{...o.A.|
---
> 152dc8a0: 3ad7 2abf 9562 b27b 8580 d16f 1141 f67c :.*..b.{...o.A.|
alexander@alexander-home:~/Documents/Test_Dir/Point_Search_GMP$ ./point_search_batch
[12:23:11] S_table generated
[12:23:11] Range Start: 54 bits
[12:23:11] Range End : 57 bits
[12:23:11] Block Width: 2^26
[12:23:11] Search Pub : 03752210872cdc16aef43c804271c1799f7198d1201e0db6fd997fac674ac60169
[12:23:11] Loading Bloomfilter bloom1.bf
[12:23:11] Loading Bloomfilter bloom2.bf
[12:23:11] Search in progress...
[12:23:28] BloomFilter Hit bloom1.bf (Even Point) [Higher Range Half]
[12:23:28] Privatekey: 000000000000000000000000000000000000000000000000007259db92c35ed8
[12:23:28] Elapsed time: (0)hours (0)minutes (17)seconds
alexander@alexander-home:~/Documents/Test_Dir/Point_Search_GMP$ ./point_search_batch
[12:23:57] S_table generated
[12:23:57] Range Start: 54 bits
[12:23:57] Range End : 57 bits
[12:23:57] Block Width: 2^26
[12:23:57] Search Pub : 03752210872cdc16aef43c804271c1799f7198d1201e0db6fd997fac674ac60169
[12:23:57] Loading Bloomfilter bloom1.bf
[12:23:57] Loading Bloomfilter bloom2.bf
[12:23:57] Search in progress...
[12:24:16] BloomFilter Hit bloom1.bf (Even Point) [Higher Range Half]
[12:24:16] Privatekey: 000000000000000000000000000000000000000000000000007259db92c35ed8
[12:24:16] Elapsed time: (0)hours (0)minutes (18)seconds
Binary files bloom1B.bf and bloom1.bf differ
alexander@alexander-home:~/Documents/Test_Dir/Point_Search_GMP$ diff bloom2B.bf bloom2.bf
Binary files bloom2B.bf and bloom2.bf differ
alexander@alexander-home:~/Documents/Test_Dir/Point_Search_GMP$ xxd bloom1.bf > 1.hex
alexander@alexander-home:~/Documents/Test_Dir/Point_Search_GMP$ xxd bloom1B.bf > 2.hex
alexander@alexander-home:~/Documents/Test_Dir/Point_Search_GMP$ diff 1.hex 2.hex
22207627c22207627
< 152dc8a0: 3ad7 2abf 9562 b27b 8582 d16f 1141 f67c :.*..b.{...o.A.|
---
> 152dc8a0: 3ad7 2abf 9562 b27b 8580 d16f 1141 f67c :.*..b.{...o.A.|
alexander@alexander-home:~/Documents/Test_Dir/Point_Search_GMP$ ./point_search_batch
[12:23:11] S_table generated
[12:23:11] Range Start: 54 bits
[12:23:11] Range End : 57 bits
[12:23:11] Block Width: 2^26
[12:23:11] Search Pub : 03752210872cdc16aef43c804271c1799f7198d1201e0db6fd997fac674ac60169
[12:23:11] Loading Bloomfilter bloom1.bf
[12:23:11] Loading Bloomfilter bloom2.bf
[12:23:11] Search in progress...
[12:23:28] BloomFilter Hit bloom1.bf (Even Point) [Higher Range Half]
[12:23:28] Privatekey: 000000000000000000000000000000000000000000000000007259db92c35ed8
[12:23:28] Elapsed time: (0)hours (0)minutes (17)seconds
alexander@alexander-home:~/Documents/Test_Dir/Point_Search_GMP$ ./point_search_batch
[12:23:57] S_table generated
[12:23:57] Range Start: 54 bits
[12:23:57] Range End : 57 bits
[12:23:57] Block Width: 2^26
[12:23:57] Search Pub : 03752210872cdc16aef43c804271c1799f7198d1201e0db6fd997fac674ac60169
[12:23:57] Loading Bloomfilter bloom1.bf
[12:23:57] Loading Bloomfilter bloom2.bf
[12:23:57] Search in progress...
[12:24:16] BloomFilter Hit bloom1.bf (Even Point) [Higher Range Half]
[12:24:16] Privatekey: 000000000000000000000000000000000000000000000000007259db92c35ed8
[12:24:16] Elapsed time: (0)hours (0)minutes (18)seconds
But anyway works like a charm. Today tested range 68-69 bits with 2^32 bloomfilter size.
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
Writing a value involves reading the value.
Since each thread is just a sequence of instructions. We can log each step of its insertion way and compare the results afterwards.Yeah, but those instructions run in parallel, hence it's guaranteed that, without an access sync, at some point, a r/w race condition will occur. You should know best what'ya doin', so I won't insist.
Or are you saying this can never happen:
Code:
X = 0
Cycle T0 T1
0 read X read X // T0: is X 0 or 32? T1: is X 0 or 8?
1 set x[3] set X[5] // T0: is X 8 or 40? T1: is X 32 or 40?
2 write X write X // what X is final? what about cache lines refresh?
3 X = ???????? // one of 8, 32, or 40
Cycle T0 T1
0 read X read X // T0: is X 0 or 32? T1: is X 0 or 8?
1 set x[3] set X[5] // T0: is X 8 or 40? T1: is X 32 or 40?
2 write X write X // what X is final? what about cache lines refresh?
3 X = ???????? // one of 8, 32, or 40
It can happen. But in practice I have everything working fine.
Bloomfilters due to their multiple use of hashes to insert one element are sure to hit the same bit in the same byte or different bits in the same byte in multithreaded approach.
But no matter how many times I tested this never cause any broken state to the resulting binary image of the bloomfilter file.
And concerning my code concept bloomfilter is used excessively to compute the decimal places in order to get the index of the bloomfilter hit .
That is later used to calculate the private key.
If bloomfilter integrity was broken this would never happen.
All in all thanks for explanation. Will add mutex stuff later to make sure everything is fine.
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
Mutex locks are necessary when multiple threads read, write and modify the same value. And order of their actions matters.
At the beginning all bits of a bloomfilter are off (set to 0).
The insert function sets some bit to 1 according to hash_value modulo bloomfilter size.
The race condition may happen very often. But which one thread will set the bit to 1 first does not matter.
The bit will be set to one as a result.
At the beginning all bits of a bloomfilter are off (set to 0).
The insert function sets some bit to 1 according to hash_value modulo bloomfilter size.
The race condition may happen very often. But which one thread will set the bit to 1 first does not matter.
The bit will be set to one as a result.
Writing a value involves reading the value. You're just ignoring this, and describing a perfect fallacy. When the different bits that need to be written end up on the same cache lines (let's say, in the same 64 bytes region, and a lot of cache lines can fit in L1) of different cores, you have two different results, both wrong, and one of those will end up in your filter.
You're not seeing the issue because the allocated area is very large, so the probability of updating nearby bits is low, but a low probability just means it will eventually happen, not that it is impossible to happen.
It is easy to check when two or more threads try to access the same byte/bit to set it to 1 concurrently.
The first one I already did. Comparing the resulting binary images to be equal.
Since each thread is just a sequence of instructions. We can log each step of its insertion way and compare the results afterwards.
To be near or exact, at which step, in what quantity.
No need for debugger.
For classic BSGS it is much easier since the babyTable is just a sequence from 1 to some power of two value.
And I guess for home PC 2^40 or lower is the limit and that is with 256G RAM.
What I see good in this is that at least now started to write answers as the sane man and not some perverse nutcase.
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.
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
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?
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.
.
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
Nothing is changing. The same shit-stream from the main-branch bullshit-master.
Hello. You have a critical multi-threading bug in your PointsSearch repository.
Code:
bf.insert(someHexString)
Ignoring the fact that you are effectively using twice as much RAM then needed, the more problematic issue is that you are totally missing any form of race condition checks, resulting in potential corruption of your bf object internal state, which is not thread-safe.
So yeah, nothing is changing indeed. Script kiddies wanna-be coders f**ing it up as they go along.
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.
See it as you wish.
What is the purpose of your presence here?
If you know a lot than be helpful to newcomers and spread the knowledge.
But from what I see in you attitude to others.
Some good for nothing piece of shit showing off and just blah-blah topics.
We can read the research papers also if that is suprising to you.