falcon2019

Nice work on the puzzle hint, but that’s not the missing character.

There's a missing character in the second code from the first post. I’ll correct it once someone cracks it. Everything else is spot on and there’s a prize involved. If you’re thinking it’s unsolvable, you might be…

So, I checked pow(2, T, n) and got this result: 0xac9c52b33fa3cf1f5ad9e3fd77ed9ba4a880b9fc8ec739c2e0cfc810b51283ce. It’s one of the endomorphism constants for secp256k1's scalar domain. When you multiply any point by…

I think the main issue is if we try to exploit this for breaking ECDLP. There’s no way to restrict three of k1, k2, k3, k4. Even if we limit k to an interval, the other three scalars could still be anywhere in that…

Checked the first 3000 G multiples, got these stats: 988 roots for 1, 1521 for 2, 0 for 3, and 491 for 4. It breaks down to a half, a third, and a sixth ratio for the roots. If we can find three scalars and hit the same…

That's pretty cool! So, when the doubling slope is 5, adding up those four points cancels out. I noticed the second point has an odd parity, but that was easy to sort out. So yeah, we get k1 + k2 = -(k3 + k4). And yeah,…

Nice one. But gotta say, your tool is kinda slow since it leans on that JLP-based secp256k1 math. I know a few users here who are already smashing your speeds. Private clients from some mining pools are also likely…

How much RAM do we need for 2^30 points? And what GPUs could keep operation speeds instant?

If a single file with a B*-tree structure has no advantage for lookups, I’m not sure what does. Maybe a ton of text files and linear searches?

I cleaned up some ops in a separate branch: Pre-computed negated x2. Still, speed fluctuates too much to notice a difference.

So is it all in one file? How do I even run this? I know C++ and Python, but C is a whole different beast.

It’s about fast point generation across the entire range. Check db.c for how the X coordinates are stored. They’re saved as little-endian bytes, with an integer key offset. What did you expect?

You’re spot on! That would save a few operations. And yeah, small optimizations can make a difference. I also forgot to add -march=native for native CPU instructions. Gonna fix that.

Appreciate the code! Just skimmed it on my phone. Is it just batch inverse and additions? I think I have an OpenCL version that does something similar. I’ll benchmark it on my 7950X.

Wait, what does your code actually do? How does it fit into this whole discussion?

I bet some people are gonna spend days breaking down that code.

Yo! I just wrote a C library that showcases how to use libsecp256k1 for super quick batch additions. It can scan a specified range from start to end really fast. You can stream the generated points or use it to test…

Ultimately, the key owner is whoever controls the key. The network doesn’t care how you got it. We need to improve security and stop reusing addresses.

You’re missing the point. Owning Bitcoin is all about the signature and cryptographic proof. If you can derive keys, that’s not illegal. But legally, it might be seen differently.

Thanks for the feedback. I know the example curve is small, but this attack isn’t like traditional ECDLP solvers.