Topic: Bitcoin has 2^512 bit security (Read 214 times)
This thread seems silly to me. Some underspecified and inept way of attacking it requires 2^whatever work? Who cares. Secp256k1 has 2^infinity security against attack by green tree slugs because green tree slugs cannot do math.
Bitcoins security strength is at 128 bit.
With ECDSA on secp256k1 and a key size of 256 bit, the strength is at 128 bit.
2512 bit is an absurdly large number and completely off. But i guess you meant 512 bit.
ECDSA's security is dependend on the key size. With a key length of 2n bit, the bit strength (security) is at 2n-1 bit.
Of course I meant 512 bit With ECDSA on secp256k1 and a key size of 256 bit, the strength is at 128 bit.
2512 bit is an absurdly large number and completely off. But i guess you meant 512 bit.
ECDSA's security is dependend on the key size. With a key length of 2n bit, the bit strength (security) is at 2n-1 bit.
Sorry I was thinking 2^512 possibilities not bits. And about the 256 bits vs 128 bits, bitcoin security is 256 bit (originally), but as we currently have algorithms that can solve it using just 128 bit search space you can also say that the strength is (currently) 128 bits. Maybe tomorrow it is just 100 bits? Who knows. That is why (in my opinion) it is easier to speak of 256 bits, because it is a number that wont change.
But I disagree with that.
No. That's nothing one can agree or disagree with.
You can either decide to accept or to deny it.
I agree that with the current way of trying to solve the problem, which is just brute forcing (or pollard rho), the search space is what you say.
BUT
IF you want to try to develop smarter algorithms for solving the problem, then you will have to convert the problem to something else first. And in that conversion the difficulty (unfortunately) does change. Because of the mod operator.
Bitcoins security strength is at 128 bit.
With ECDSA on secp256k1 and a key size of 256 bit, the strength is at 128 bit.
2512 bit is an absurdly large number and completely off. But i guess you meant 512 bit.
ECDSA's security is dependend on the key size. With a key length of 2n bit, the bit strength (security) is at 2n-1 bit.
No. That's nothing one can agree or disagree with.
You can either decide to accept or to deny it.
With ECDSA on secp256k1 and a key size of 256 bit, the strength is at 128 bit.
2512 bit is an absurdly large number and completely off. But i guess you meant 512 bit.
ECDSA's security is dependend on the key size. With a key length of 2n bit, the bit strength (security) is at 2n-1 bit.
But I disagree with that.
No. That's nothing one can agree or disagree with.
You can either decide to accept or to deny it.
It is generally thought that bitcoin has 2^256 bit security and with the best algorithms (Pollard rho, Kangaroo) the search space can be lowered to about 2^128 bit.
But I disagree with that.
We have 2^256 bit security WITH a mod operator, and if we want to get rid of the mess and complexity of mod, then we are looking at 2^512 bit security level.
Getting rid of mod operator enables us to develop algorithms that are not as much based on brute force or statistics (like Pollard rho).
The best algorithm I can come up with starts with 2^512 bit security (without mod) which can be lowered all the way to about 2^128 bit with a clever algorithm. It is quite a big reduction but unfortunately still at the same level than with just using regular Pollard rho.
What I think makes bitcoin secure is not the curve itself, but the (damn) mod operator. Does anyone know how to get rid of the mod while still remaining at the 2^256 bit level?
But I disagree with that.
We have 2^256 bit security WITH a mod operator, and if we want to get rid of the mess and complexity of mod, then we are looking at 2^512 bit security level.
Getting rid of mod operator enables us to develop algorithms that are not as much based on brute force or statistics (like Pollard rho).
The best algorithm I can come up with starts with 2^512 bit security (without mod) which can be lowered all the way to about 2^128 bit with a clever algorithm. It is quite a big reduction but unfortunately still at the same level than with just using regular Pollard rho.
What I think makes bitcoin secure is not the curve itself, but the (damn) mod operator. Does anyone know how to get rid of the mod while still remaining at the 2^256 bit level?
Jump to: