Search content
Sort by

Showing 20 of 114 results by _Counselor
Post
Topic
Board Project Development
Re: Keyhunt - development requests - bug reports
by
_Counselor
on 30/11/2024, 10:53:45 UTC
1/ Is there anyway to fix Xpoint mode? it seems like Xpoint compress mode calculate-y as well, fixing it might give us better speed.

Hi. Fixing what? Is there something to fix there?

Main cycle of xpoint need to calculate one Y value for each 1024 values of X, it can't be done in any other way, But one Y for each 1024 X values is not representative, aka it is negligible.

1/1024 = 0.0009765625 = 0.09% of the process

I have already pointed out this bug in this post
Post
Topic
Board Development & Technical Discussion
Re: 5-7 kangaroo method
by
_Counselor
on 20/10/2024, 17:57:44 UTC
So for DP=32 every kang finds a DP every 270 days (on average).
Correct?
Now the problem is obvious, isn't it?

Yes, such a problem does exist. The kangaroos still find the DP, because of their huge amounts, but the paths are too short and the first DP found by single kangaroo is always much worse than the subsequent ones.

As for me, I launched JLP Kangaroo with specially modified grid size, group size and other slight improvements, lets call it "fast kangaroos". But I personally know programming in CUDA quite poorly, so I couldn't write a good kernel for these conditions, and I couldn't achieve the necessary speed increase so that, so to speak, quality worked, not quantity.


Post
Topic
Board Development & Technical Discussion
Re: 5-7 kangaroo method
by
_Counselor
on 17/10/2024, 07:12:30 UTC
Such papers is just a way to get a degree, zero new ideas.
And all this is not important actually.
The main problem that you won't get better than K=1.7 this way even if you use 1000 instead of 3-4-5-7 kangs.
K=1.7 is boring, really. It's like solving puzzles #6x  Grin
Why don't you try this? https://www.iacr.org/archive/pkc2010/60560372/60560372.pdf
Going this way (a long way btw) you can "invent" something interesting and get real K (not in theory but real) around 1.2 if you are smart enough Cheesy I call this approach "mirrored" kangs.
But, of course, this way is not so easy as "normal" kangs that always jump in one direction.
Just a tip for you because it seems you read some papers instead of creating magic circles/code as most people here Cheesy
Though I doubt that you will break #135, it's always fun to invent and discover so you can spend a lot of time having fun...

Most people here don't have access to/possibility to rent much computing power, so it doesn't matter to them whether the K is 2.0, 1.7 or 1.2. That's why attempts to do some kind of magic begin. How many GPUs did you use to solve 120-130?

Fruitless cycles is the main problem of using equivalence, but there is few good ways to deal with them. By the way, I was very surprised when I saw how quickly kangaroos get into a primitive two-point cycle.

Also, thanks for sharing 120 PK.
Post
Topic
Board Bitcoin Discussion
Re: == Bitcoin challenge transaction: ~1000 BTC total bounty to solvers! ==UPDATED==
by
_Counselor
on 03/10/2024, 08:00:10 UTC
The entered phrase with a request to send the solution to PM is the only thing I can do to be able to learn the solutions... at least for statistical purposes... because this is probably the MAX of what you can be happy about today in the subject of this challenge.
Yes, i am also interested in knowing the private keys to these solved wallets, but when a year ago I asked to share 120 workfiles to possibly find out the private key, no one shared them.
Post
Topic
Board Development & Technical Discussion
Re: LLL_nonce_leakage.py -->> simple Sagemath code
by
_Counselor
on 17/04/2024, 06:33:50 UTC
Yes, I know, but I am asking for simple math for easy understanding.
Please explain how LLL_nonce_leakage works, write simple math, or explain

Lenstra–Lenstra–Lovász lattice basis reduction algorithm is not a something that can be understood using simple mathematics.

Try to read this for example.
Post
Topic
Board Project Development
Merits 4 from 1 user
Re: Keyhunt - development requests - bug reports
by
_Counselor
on 03/04/2024, 20:30:24 UTC
⭐ Merited by albert0bsd (4)
Hi, Alberto.

xpoint mode does not work at full possible speed, because FLAGSEARCH has default value of 2 (SEARCH_BOTH); then at thread_process you have following condition:
Code:
calculate_y = FLAGSEARCH == SEARCH_UNCOMPRESS || FLAGSEARCH == SEARCH_BOTH || FLAGCRYPTO  == CRYPTO_ETH;
If you add an exception there for xpoint, unnecessary calculations of Y-coordinate will not occur, this will at least double the speed in xpoint mode I think.
Post
Topic
Board Development & Technical Discussion
Re: Pollard's kangaroo ECDLP solver
by
_Counselor
on 21/03/2024, 05:50:54 UTC
So I still believe it could solve 130 and then you would have to do some manual math (nothing hard) to get the actual private key. If the key starts with a 2, I think it would not require the manual math, but if it starts with a 3, then it will.
You can't because GPU uses only 128 bit variable to store distance on each kernel call, it means that when kangaroo jumps out of 128 bit space, all subsequent jumps are calculated incorrectly.

130 puzzle still can be solved with unmodified JLP's kangaroo if you divide 129 bit space into two 128 bits parts, but kangaroos still can jumps out, so you have to control the wrong DPs.

Post
Topic
Board Development & Technical Discussion
Re: Binary Baby Step Giant Step with lightweight database - Brute force (BSGS)
by
_Counselor
on 08/01/2024, 18:49:34 UTC
I don't see any benefits of this. If you have N baby steps with 1 bit of each, then roughly N/2 steps will collide with each giant step. This mean you will need to perform at least N/2 additional operations on each giant step to check false positives.

This leads to the fact that the ability to store n-times more baby steps leads to an n-times increase in the size of the giant step, but at the same time increases the number of operations required to check the collision by the same number.

Simply put, this ultimately will not give any increase in speed compared to maintaining the full baby step value.
Post
Topic
Board Bitcoin Discussion
Merits 1 from 1 user
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
by
_Counselor
on 28/12/2023, 06:35:19 UTC
⭐ Merited by digaran (1)
It seems as though nobody is knowledgeable enough to figure out as to why generator points of 2 curves secp and secq256k1 both when divided by 2 generate the same coordinates. Either the so called "experts" and "cryptographers" are clueless as well or they refuse to reveal the secret. Asking questions on other platforms seems to produce the same scripted answers.

It's just because both generators were created by doubling the same point.
Post
Topic
Board Development & Technical Discussion
Re: Pollard's kangaroo ECDLP solver
by
_Counselor
on 13/10/2023, 18:04:35 UTC
Code question!

Why the jump table is not saved with work save file?

That way, jump table will be different every time we continue work and loading file, and the potential cycles will be different!


Jump table generator uses hard-coded fixed seed each time to keep jump sizes equal for all workers.
Post
Topic
Board Bitcoin Discussion
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
by
_Counselor
on 08/10/2023, 09:21:31 UTC
I understand what you wrote, but I don't understand the real interest. Let's assume this is the real key for the 120bit puzzle 9C15FC66A182003BB1BE5D1DF12CAB
what did you gain from this insight other than the satisfaction of pure curiosity ?

I don’t know what else to answer you other than what I already wrote.

Anyway, as I wrote above, if anyone else besides me is still interested in finding out the key to 120 and still has kangaroo's workfiles for 120 puzzle with DP of 30 bits and above, please share them. Workfiles for 125 not interesting me, because I did not work on it.
Post
Topic
Board Bitcoin Discussion
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
by
_Counselor
on 08/10/2023, 08:30:52 UTC
yeah, but what's the point? I cannot imagine it's pure curiosity. What's the real reason ?
I already wrote the real reason. Or are you expecting me to write something like "using the 120 key, I know how to calculate 130"? Unfortunately, this is not so, and if it were possible, then the one who found 120 and 125 would have solved the next puzzles long ago.
Post
Topic
Board Bitcoin Discussion
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
by
_Counselor
on 08/10/2023, 07:57:08 UTC
let's say the finder of puzzle 120 will reveal the private key. In what way does it help you proceeding with finding #66 or #130 or ... ?
I strongly doubt that this will somehow help to solve 130 or 66, just as the keys 63, 115 and below previously did not help solve 120 and 64. This is just something like scientific interest. I previously spent a lot of time and resources trying to solve puzzle 120 and I'm still curious about its key.
Post
Topic
Board Bitcoin Discussion
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
by
_Counselor
on 08/10/2023, 07:48:34 UTC
Even though the 120 key was found, I'm still interested in finding it since it hasn't been published. If anyone still has kangaroo's workfiles with DP of 30 bits and above, I would be grateful if you share them.
Post
Topic
Board Development & Technical Discussion
Re: Pollard's kangaroo ECDLP solver
by
_Counselor
on 08/10/2023, 07:40:54 UTC
So I'm messing with Puzzle #130 and JLP's Pollard Kangaroo ECDLP Solver using a RTX 2070. When I first launch it, this is the speed I get:
[1553.87 MK/s][GPU 1459.12 MK/s]

After a few seconds running at that speed it will slowly decrease until it reaches this speed, where it stays for the rest of the operation:
[1209.19 MK/s][GPU 1134.42 MK/s]

Does anyone know why this is happening?

Thanks in advance!  Smiley

Because statistics are wrong until all threads loads kangaroos. Wait about 10-15 seconds to get right numbers.
Post
Topic
Board Bitcoin Discussion
Merits 2 from 1 user
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
by
_Counselor
on 29/09/2023, 04:35:29 UTC
⭐ Merited by albert0bsd (2)
Seems that sha256 and rmd160 is a joke for most users here, all those partial address are not useful at all.
With a high level of entropy that sha256+rmd160 provides, I would say that from a mathematical point of view, the desired address is quite far from addresses starting with similar letters. Therefore, in theory, we can exclude some ranges from search where addresses with similar prefixes was found. But anyway the real random is the kind of thing from which you can expect anything.
Post
Topic
Board Bitcoin Discussion
Merits 3 from 2 users
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
by
_Counselor
on 25/09/2023, 19:14:54 UTC
⭐ Merited by digaran (2) ,citb0in (1)

It is difficult to know which division is a fraction or not, because the curve sees them as integers.

Of course it's difficult, that's one reason to love bitcoin and be assured of it's security, I don't deny that. My goal is to find out what is the remainder of a fraction for different values and if there is a way to find that out, like 4501/230 =
 19.56956522, and I want to know how to detect .56956522 and extract it's representation on the curve, we have 4500/230 =  19.56521739, I want to know how we could find curve representations of :
.56956522  and
.56521739 difference between them is : .434783
Now if we could find .434783 on the curve we can potentially determine the range to solve 4501.

There is no decimal fractions. You should work with these as if they were simple fractions.

4501/230 = 19 131/230. Fraction part = 131/230 or 131*modinv(230) on curve

4500/230 = 19 130/230.

4501/230 - 4500/230 = 1/230 => difference on curve = 1*modinv(230)

If you really need to find decimal fraction, just convert it to simple fractions:
0.5 = 5/10 = 1/2 = 1 * modinv(2) (or 5*modinv(10) - doesn't matter).
.434783 = 434783/1000000 = 434783*modinv(1000000)



Post
Topic
Board Bitcoin Discussion
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
by
_Counselor
on 19/09/2023, 17:45:22 UTC
Hi, nice code Smiley The prime numbers approach is a good idea, I also try it some time ago, but it only works as you said if you have the right factors if no then the brute force approach of the prime numbers is also some exhaustive, we can try some small and common factors but those don't provide much speed, but if the prime factors aren't common then the probabilities of some prime number is factor of our key are very low probabilities.

IMHO this prime number approach is a nice as proof of concept but with some low success


I tried and tested similar approach a year ago. The best result I could achieve is O(N/4) complexity for a random number, so this is 4x better than bruteforce. But it's requires a lot of scalar multiplications, therefore optimized sequential key generation is still faster despite the higher complexity of O(N).
Post
Topic
Board Bitcoin Discussion
Merits 1 from 1 user
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
by
_Counselor
on 14/09/2023, 12:41:58 UTC
⭐ Merited by albert0bsd (1)

- Puzzle/challenge 64 solve by Unknown a year ago ‎2022-09-09 privatekey f7051f27b09112d4


If the solver is unknown, where is this private key came from?
When the solver move reward from 64 puzzle, it public key has been revealed; after that, finding a key in such a small range is trivial.
Post
Topic
Board Bitcoin Discussion
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
by
_Counselor
on 09/09/2023, 17:23:08 UTC
Just to share something I found out, so if you for example divide a point by 35, and then add 1 G to your point and divide the +1 of your point by 35, what do you think will happen?
Well the results of both divisions will have a distance equal of n/35, so if you after dividing p/35, start adding n/35 to your result, for each addition you'd get the result of +1p/35, add n/35 twice, you'd get +2p/35.

Do not fix on EC points, elliptic curve is just "graphical" interpretation of a numbers, all maths behind it works at finite field and obey all laws of "real" numbers math.
If you divide any "real" number by 35, then divide number+1 by 35, then difference between results will be 1/35. This is also works in finite fields and for EC points.

of course if after adding 9 to p, your k ends with 5, then dividing by 5 adding 9/5 won't give you the right key, that's how you can determine what the last digit of your k is.
This is not true, for example - 26/5 = 5,2; 35/5 = 7; 9/5 = 1,8. 26/5+9/5 = 5,2+1,8 = 7 = 35/5
you can also check this with EC points like:
Code:
p95 = curve.fromPrivate(9).div(5)
p265 = curve.fromPrivate(26).div(5)
p355 = curve.fromPrivate(35).div(5)
print(p265, p355)
print(p265.add(p95))

output:
Code:
03F18D7188F16C93BB251A68DE95A057E02356BA0602854041BA4E170676E54169 025CBDF0646E5DB4EAA398F365F2EA7A0E3D419B7E0330E39CE92BDDEDCAC4F9BC
025CBDF0646E5DB4EAA398F365F2EA7A0E3D419B7E0330E39CE92BDDEDCAC4F9BC