Topic: Shouldn't we start using safer keys from now instead of waiting for problems? - page 4. (Read 6065 times)

Well, I tried.

I should be still alive 50 years from now, i will resume the topic.

Go f*ck yourself now is better than go f*ck yourself later.
There are many other things that we must thing before, don't you think?

cedividad, you should probably first get a basic grounding in cryptography before demanding illusory changes.

Also, are you Atlas?

I got it, you are talking about Facebook.

It's a problem that will arise sooner or later. It's sure.

Fixing it now is better than fixing it later.

Successful technology companies do not waste their time solving problems that they THINK they MIGHT have in 20 years.

They don't even spend much time thinking about problems that they might have in four years.

I don't spend any time worrying about the strength of 256-bit ECDSA or 160-bit RIPEMD, and I spend even less time worrying about the strength of those two combined.

Yes, now.
Do you know what hardware and tech the military has? Do you know what we will have in 20 years? I don't. No one knows. This is the point. It's the same as projecting the future costs and sizes of computers before the transistor.

PS, I made you wrote your 8888+1 post. Proud of it!

Hardware & human lazyness combined with reluctance to change scales even worse.

As i pointed out, it will be at least 1000 times as difficult (& costly) to add decimal places or increase cryptographic keys lengths in the future once Bitcoin becomes widespread.

So why not do it now instead of waiting for it to become another "case" like Ipv4->Ipv6 transition.

This +1.

To the supports .... D&T rant mode engaged.

1) Bit strength alone is utterly meaningless.  ECC was designed to use a smaller key size yet produce the equivelent security of larger key sizes used by RSA.  256 bit ECC has the equivelent security of 3072 bit RSA.   The whole POINT of ECC was to reduce key sizes without reducing security.  Increasing the size of the hash to larger than the ECC key is a good way to just waste space.  It does absolutely nothing.

2) There aren't even any vetted ECC curves beyond 512 bit because it makes about as much sense as idiot LEET hackers speculating that if 2048 bit RSA is good then 4892374190289378952347589347528945 bit RSA must be even better.

3) 160 bits can't be brute forced.  Period.  To put it into perspective the entire bitcoin network has performed roughly 2^56 hashes and comparisons.  If the Bitcoin network was one trillion times faster (note that is roughly a million times more computing power than the entire planet combined) it would take "only" 80 quadrillion years to have a 50% chance of brute forcing a single 160 bit hash.   Most miners understand difficulty so brute forcing a 160 bit key is like a solving a block with a difficulty of 79,228,162,514,264,300,000,000,000,000

4) Larger key strengths are useful in the event an algorithm is partially compromised HOWEVER it is more important to use well known and vetted algorithms which are less likely to be compromised in the first place.  Moving to Bobs Leet 2048 bit hash is of little utility if it is broken wide open providing about 20 bits of effective security vs no practical attacks on RIPEMD-160 or SHA-256.

5) Public addresses are the product of a double SHA-256 hash AND RIPEMD-160 hash of the public key.  This provides resistance to cryptographic attacks as it would require not just a flaw in one algorithm but a significant exploitable flaw in two completely unrelated and highly vetted hashing algorithms to have any useful applications.

6) Nothing is free.  Larger keys, larger public addresses (hashes), and more decimal precision takes up space.  The idiotic idea of going to a 2048 hash would increase the size of all transactions by a factor of nearly 13.  To put it into perspective if the network currently used that the blockchain would be nearly 40GB and growing by 5GB or so a month.  All those scalability limits (bandwidth for a node, computing power to verify tx, annual storage growth requirements, time to bootstrap a new node) would all be increased by a factor of 13.

Increasing the number of digits is equally stupid.  Bitcoin may never scale to a level where such precision is useful.  Say we increase it to 16 digits.  Why not 48? or 96? or 2000?   Now you likely are thinking 2000 digits, now that is stupid.  9+ is really no different.  Taking time and resources from areas where Bitcoin could use some real improvement to "fix" unbroken problems is just dumb.

Want to improve Bitcoin how about donate 20 BTC to an alt-client developer?  How about make or improve a bitcoin library in your favorite programming language/platform?  Maybe crowdfund the development of a node class library so the logic of a node can be decoupled from the GUI and wallet portions of the reference bitcoin client?  No lets "fix" things which aren't broken, that is where we will unlock some value.

Math is scalable.
HDD space and bandwidth isn't necessarily.

Isn't the Great Chain bloated enough as is already?

Yeah, i know that if right now everybody on earth would generate 10 random addresses a second for 10 years, then the probability of hitting the same address by 2 people would be like 1 to 66,205,589,862,420,404,716,771,980,897 but still... using longer addresses would be even safer !!

There might be something to other points, but this is not a real thing.

+ 1000

Yeah, I really hate the "Let's wait until it becomes a problem" attitude.


Exactly what I am saying.

--------
Let me sum up the benefits:

- Longer private/public keys = more possible addresses, better protection against money loss due to the identical address generated by 2 people
- Longer private/public keys = better security when a flaw in one of the fundamental algorithms is discovered
- More decimal places = after bitcoin becomes widespread, it will be suitable for transferring/storing smaller amounts of money
- It is 1000 X easier to fix the issues right now instead of later

Disclaimer:  This is a general attitude and not based on defeating ECDSA with RIPEMD

It's sad and all too common to see reactive positions on problems or tweaks when it's relatively easier to fix them sooner than later.  Particularly when system adoption is a few thousand vs. possibly millions in the future.


A good example of major change in a widely adopted, but loosely organized system is IPv4/IPv6.  This transition has been dragging out for many years and has resulted in all sorts of intermediate protocols in attempt to overcome the sheer difficulty of wholesale replacement.


But, let's not forget what Satoshi said.  To paraphrase: The nature of Bitcoin is that once it was brought online it's core would remain fundamentally unchanged.  That's a broad assertion and I wonder what the boundaries are of his assertion.

Sure - the point is taken but I do think that the threat of QC is *far* less than the threat of a > 50% attack (just how many FPGA/GPUs are there mining Bitcoin right now and do you not think that a government couldn't just buy 10x that amount of hashing power especially if say they are the only one in the world where ASIC is being manufactured?).

This discussion is also about adding more decimal places *before it becomes a problem* rather after it becomes a problem some 30-40 years in the future.

I forgot to add, than we can add just the networking & protocol support for 2^512 & 4-6 more decimal places and wait 2 or 4 years with the actual implementation, so everybody will have enough time to prepare.

Also because a Bitcoin address is a combination of ECDSA with RIPEMD then provided that you don't re-use addresses (so yes vanitygen addresses are not the best and I am well aware of my own sig) then even if ECDSA (in terms of the particular version being used by Bitcoin) is broken by some future QC machine (which I seriously doubt will exist for a very long time from all that I've read so far about this technology) you will not lose your bitcoins (as *both* ECDSA and RIPEMD would have to be broken for this to occur).

Yep, exactly.

"Let's fix it when it becomes a problem" is IMHO a very shortsighted & foolish way of thinking.

Especially when fixing it now is extremely simple and fixing it 10 years into the future will be orders of magnitude more difficult because of the reasons i wrote earlier.

Of course, 2^2048 is obviously too much, but why not 2^384 or 2^512 ? I don't see anything wrong with that.

I do.

If a computer is designed that can hack Bitcoin, it will be used for more important things than making money. It will be used for predicting the consequences of butterfly wing flappings.