If I give you two numbers and ask you to add them together will you do it at the same speed with all numbers?
For example does it take you the same amount of time to add 3 and 2 together as it takes you to add 334212132454779 + 675456421213132457964?
And these numbers aren't even big!

It's the same in Elliptic Curve Cryptography.
If you can solve ECDLP in a short time when the key range is tiny, that doesn't mean you can do the same when the key range is ginormous like 2²⁵⁶. That's what the puzzle keys people are finding are, small keys in a tiny range compared to the max range of 2²⁵⁶.

Your theory is possible and have been studied about by experts. They learned how to try and prevent such things from happening. With the cosntant evolution of technology, we can expect stronger security so the likelihood of this happening keeps decreasing as time goes by. Not to mention how hard it would be to actually generate the private key from an exposed public key if there are even any.

You already started the shitstorm, so i will expect to see more of how you're going to compare seeing that bitcoin ends with the content of what you wrote down, i can only say more grease to your elbow, but know that bitcoin is not ending.

If you would be positively directed for the idea you would already know that.

If anyone can obtain pubkey and then get pvk from it, he could immediately redirect the tx to himself. That's the problem here which you don't see.


I think there is not much possible to do in this case. Trying to guess the pvks is easy, there is only time that prevents us from seeing txs redirected by larger group of persons.

If you read the topic - this security has been breached recently by bsgs and kangaroo programs. There is no more security involved. Any transaction can be redirected currently, depends on luck hitting the pvk from pub key.

It takes the same time. Integer addition is instant, O(1). Did you mean elliptic curve point addition, perhaps?

Edit: For fixed-width integers (e.g., 32-bit, 64-bit), it's O(1). For arbitrary-precision, it's O(n) (with n being the number of multiples of the fixed width integers, i.e. adding fixed-width n times). It's still fast, though.

10^9 is tiny space. We're talking about 2^256 = ~10^78. You can't store that range somewhere, if that's what you meant.

What topic? The probability of hitting a securely generated private key from public key is extremely slim. It's only public keys that were generated non-securely that are compromised.

If it would be that easy, then someone would already do it.

The only way to get the private key from the public key is by brute force, and as we know, to brute-force bitcoin addresses is a waste of time, there are better odds of finding a wallet on the street than finding a private key.

So, nothing to worry about.

I have always been fascinated by how some folks can make big claims without knowing squat about the subject.  OP, you bandy around terms like bsgs and kangaroo like they are some kind of magic that can crack any encryption just like that.  Do you even know what these methods represent and what they are capable of doing?

If you are really interested in learning about this kind of stuff, I would suggest asking questions about things you dont understand before making such outlandish claims.

Humans can't add large numbers, because of lack of memory. You can't memorize the addition of 8173 with 2509, let alone with larger numbers. That's why you write it down, and then operate mechanically the step-by-step algorithm for column addition (starting from the rightmost column), as you've learned in elementary school, which has a time complexity of O(n).

Computers on the other hand, handle addition differently. When you give a computer a number, it reads it in a fixed-size set of bits. For example, 8173 and 2509 in 32-bit will be expressed as:

The addition here is done bit-by-bit, starting from the rightmost, with the following conditions:

• If both bits added are '0', final bit is '0'.
• If one bit is '1' and the other is '0', final bit is '1'.
• If both bits are '1', final bit is '0' and we keep a carry ('1') for the next addition.

This way, regardless the digits of your number, if it can be represented with 32 or 64 bits, addition finishes in O(1) time complexity, in contrast with humans' algorithm, where time complexity increases linearly as the digits increase.