OG platform. OG meme coin. SOL

Guys if we found public key for puzzle 67,68,,69
will it make it easier to find private keys ?
i know the public key but dont know what to do

Its not like that, there is no place .. its generating many different arrays of data which is not so easy to understand.
Anyhow thanks, and hope maybe someone can give a hint.

Regards

Yes there are several ways.
1. When same K is used 2 times either in same or different Transaction, its trivial to calculate PVK. Its already extensively exploited.
2. When K values are closeby so that difference can be bruteforced quickly, then also PVK can be calculated.
3. When you somehow know the mathematical relationship between 2 K, like K2 =K1/2 or K2 = K1 + 1637737337373738373729826362936, whatever, then also PVK can be calculated.
4. When you have several Tx and there may be few bits common, either LSB or MSB, then also it's possible to calculate PVK through Lattice reduction. (Check minimum required Tx for Bit Leakage).
5. If the number of Tx is not sufficient for Lattice reduction but there is info about sufficient bit leakage, we could use the same Kangaroo solver approach on the Rvalue of Tx to get K.
6. We could mathematically generate Tx for known Leakage in Privatkeys and then try to bruteforce. For example Puzzle 130 is know to have a 126 bits Leakage in PVK. So several derived Tx from it can be considered for bruteforce.
7. There could be more which I am not aware of yet.

The main point is, there is no 100% sureshot method which will work on generic Tx. All different approaches either need some vulnerability or prior info or some bruteforce.

posible make MSB LSB  in r known:

k = 0x157cb65b27a820acb0df711e28550521930

new k ,= fffff5d576e7357a4501ddfe92f467d8381e976131536b49b6e4411220885a7


./modmath 0x157cb65b27a820acb0df711e28550521930 -  0x80000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000
Result: fffff5d576e7357a4501ddfe92f467d8381e976131536b49b6e4411220885a71

userland@localhost:~/ecctools$ ./modmath 0x157cb65b27a820acb0df711e28550521930 -  0x70000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000
Result: fffff71ac80a4ecafc61a23ec095db0801dd566131536b49b6e4411220885a71

userland@localhost:~/ecctools$ ./modmath 0x157cb65b27a820acb0df711e28550521930 -  0x80000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000
Result: fffff5d576e7357a4501ddfe92f467d8381e976131536b49b6e4411220885a71

userland@localhost:~/ecctools$ ./modmath 0x157cb65b27a820acb0df711e28550521930 -  0x60000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000
Result: fffff860192d681bb3c1667eee374e37cb9c156131536b49b6e4411220885a71

for bigger k:

./modmath 0x257cb65b27a820acb0df711e2855052193f - 0x60000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000  Result: fffff860192d681bb3c1667eee374f37cb9c156131536b49b6e4411220885a80

userland@localhost:~/ecctools$ ./modmath 0xb32f2f28d07cd0  - 0x60000000000000000000000000000000000000000000000000000000000000000000000000000 000000000000000                     Result: ffff860192d681bb3c1667eee374ce1313273ce6af48a03bc0858dbbf906be11

userland@localhost:~/ecctools$ ./modmath 0xa32f2f28d07cd0  - 0x60000000000000000000000000000000000000000000000000000000000000000000000000000 000000000000000
Result: ffff860192d681bb3c1667eee374ce1313273ce6af48a03bc0758dbbf906be11

Pubkey =  02ceb6cbbcdbdf5ef7150682150f4ce2c6f4807b349827dcdbdd1f2efa885a2630
puzzle #120   

---
k1      =  0x00000000000000000000000000000000025d46d0bccbc08eafa03912b3f2c206
r1      =  0x890895144c4a40cd18126d1ce6534e03ab909c8c3692f1cc108fec8e2e4dea97
s1      =  0x51bc4ff0a414d66113e354a7070f47eba8ab76035e776ed2123c7d5ee991b800
z1      =  0xf11d940943f16b4117aea030d0b0cf7f6781e99f2babe05daa574a10b072bc44

k2      =  0x00000000000000000000000000000000029c9ececdceab18cfba91146e5ded7e
r2      =  0x2e772d6ea8cd5dc0b4f06a5f4e5ea057cb65b27a820acb0df711e2855052193f
s2      =  0x83e65d972d090e8d975e5ed99f55c9bbc20fcf692344cf847f3639f4ff026d63
z2      =  0x625ed03aa7e42bb1f65e5546861807a0a52fc52cb20a6b4bdc32b2028e70904b

k3      =  0x000000000000000000000000000000000141bf2eb7b3d7b7b5bbf78d4f28bcda
r3      =  0xb32f2f28d07cd0a9cc139905e1875379b9349fd21ccb838e380215afa5f26eac
s3      =  0x15d30ec6841a4e59bbb87bfc11ebf7cab78b5eb2e5ce742ebe7d07a060ebfc5b
z3      =  0x3677c07287e8742faf74b964476405f1f153466b26234b3461b268ee00676ce8


121 bit :    3  r,s,z      use  LLL_nonce_leakage.py  , you  can  found private key about 1~2 second

It is possible to reduce a little bit the complexity of the classic kangaroo algorithm by spreading the starting kangaroo in a non uniform maner.
Roughly speaking, if the private key lies in certain areas it will be found faster. As a counterpart if it lies in certain other areas it will be found slower.
But in average, considering the whole range, the compexity is well reduced.
It you read and understand carefully the reference in the gitbub page, you will find the trick

Thanks WanderingPhilospher for the quick answer, i am sorry as i was away for few days.

Also many thanks for the explanation, you are very right  Etar Kangaroo didn't even start and i was wondering why but as you explained the range was very small.
After using a bigger range (as you did) and i even used bigger range and found the key - perfect.

Then i started it with the #130 and the full range .. and after 24h there was 100GB of work file but nothing was found - as expected 

Now i started it with the fractional but as you know it uses the JeanLucPons Kangaroo (which loses performance) but lets see how it goes.

Another issue with the tools is the good explanation of the parameters and the configuration also some more detailed information behind those to understand how and why to use them.

by the way, are you the developer of this https://github.com/WanderingPhilosopher/VanBitCrackenRandom2 ... seems you are also very expert in that subject 


Thanks citb0in for your response and the info about the Kanga-256.

I wish to spend more time on this subject, but not easy.

I will update you about any progress

Regards

JLP doesn't respond much these days. I know his code works (but is limited to x bits) because his code was used to solve #110 and #115. Not sure about #120 or #125 because no one has claimed they solved them and what was used.

did you run the normal etar kangaroo or the fractional one?

UPDATE:
Try etar's again. Here's the thing, your initial range size is 2^26; his says the range has to be higher than 2^32 (or else it's just a waste of time since even a brute force program can find that within seconds)

Try this config:
-rb 2F633CBE3EC02B9401000000000000000 -re 2F633CBE3EC02B94010000000ffffffff -pub 021c20007f8c8984d403a695494d6afbff37f55a01c8bd1aafb9b958fa9485bb02

I ran it and it found the key.

The source code is there. It's built with PureBasic. Nice, simple, clean code.

DPs can be at the beginning, middle, end.

JLPs DPs (Zeros) are leading, meaning they are at the beginning. I believe Etar's are trailing, at the end.

So JLP DP 20 = 00000xxxxxxx
Etar's DP 20  = xxxxxxx00000

It doesn't matter if they are trailing or leading. Both are good and work.

Test Etar's version out.

Yes, you are correct, it was meant to expand the search range, like you said, be able to solve 160.

However, I am pretty sure it had bugs or speed was lost. I'm not sure it he has tinkered with it any more since his original post.

Check out Etar's kangaroo version; it is same as JLPs (but trailing DPs; zeros at the end) but can solve up to 192 bit range.

I pushed an update to Kangaroo-256 a couple of days ago that fixes the botched GPU implementation. https://gitea.datahoarding.agency/ZenulAbidin/Kangaroo-256

Next I want to add the ability to create your own dpmask - whether you want certain bits to always be set and others always be cleared. I think I will need two different masks for this, one for the bits that should be set and another for the ones that should be cleared.

Currently all of the dpmask bits are at the left of every kangaroo but I think the ability to define it at random positions could influence the speed it takes to find a collision. I could even make the dpmask to change at random it I want to.

No, i mean I can reduce a generator range to skip not random values, so time to bruteforce reduced too.

For example, 23 bit key to test (python 3.11 + ice_secp256k1.dll).
with secret algo:
GOT: KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rVkthFNsQ6i7
10.363348245620728 s

with usual range (2^22 ... 2^23-1)
GOT: KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rVkthFNsQ6i7
16.832353353500366 s

with big values, like 66 bit, a lot of values just skiped as NOT random binary values, because cant be randomly generated by author (by wallet software).
for example, first value for 66-bit range is 100000100100100101010011001011000111000111001011000111000111001011, all values less is fail.
this value give generator as first value applyed with random's rules

anyway, pure python not a good instrument to get result. wanna use numba cuda.jit, but still learning how to.