Shouldn't we start using safer keys from now instead of waiting for problems?

[cedivad]

From what I read, a brute force attack to the blockchain is impossible with normal computers and unlikely with quantum ones.

Quantum computers will eventually become a reallity.

Why don't we start using safer keys and a bigger keyspace for the addresses from now, instead of waiting for troubles?

2^160 is cool, but what about 2^2048?

I dont know it it has sense, but i think that we should start to implement this in the next future as was done with ipv6, dual stack network for 20 years, etc.

[ShadowOfHarbringer]

I support this. Additionally I propose we add more decimal places (4 zeros or more) simultaneously. Logical reasons:

1. In the future, there may be multiple "mainstream clients", so coordinating between different development teams may be more difficult by few orders of magnitude
1a. If that happens, there will also be multiple code bases and changing all of them to comply with new standards will be very difficult
1b. Because of that, there will be also much much much more testing required, and many many more possible bugs will be produced because of the transition

2. In the future, Bitcoin may be heavily used by many powerful financial institutions and each of them will have its own agenda. They may or may not like the enlargement of decimal places & private/public keys for reasons not yet known currently.
2a. Large institutions (including financial, governments) have large inertia. It will be difficult for them to make transition to any new standards.

3. In the future, Bitcoin will probably be implemented in many embedded devices (such as ATMs, smart wallets, smart credit cards, "smart bitcoin safes") etc. So it will be even more difficult to implement it

4. In the future, it will require much more convincing people to switch to the "new, better Bitcoin with longer keys".

5. Just look what happened with Ipv4 -> Ipv6 transition. The same will happen with Bitcoin. It will be extremely difficult to make any changes once it is widespread.

[payb.tc]

^ i disagree.

i think in the future, most bitcoin-related transactions will not occur on the actual blockchain and hence won't be restricted to 8 decimals anyway.

the 8 decimals will only restrict the balancing of accounts between large institutions that actually use real tx's.

[ShadowOfHarbringer]

^ i disagree.
i think in the future, most bitcoin-related transactions will not occur on the actual blockchain and hence won't be restricted to 8 decimals anyway.
the 8 decimals will only restrict the balancing of accounts between large institutions that actually use real tx's.

This is one of possible scenarios.
However nobody can exactly predict the future and it won't hurt to prepare for another probable scenarios instead of just doing nothing ?

However, the UNIX sysadmins of 1970s also never thought that their code will be used to this day and by so many people and
- This is the reason we need to do Ipv4 to Ipv6 transition today.
- For the same reason, the UNIX TIMESTAMP does not support dates beyond 2038 (was it 2038 ? or 2035 ? I don't remember exactly), which already causes problems in software today.
- The same issue with Y2K problem.

The conclusion ? Everybody always thinks that their system will be replaced by something new & better in the future, but it often does not happen, hence the problems we have today.

[kwukduck]

I think you don't really grasp what 2^160 actually means... let alone 2^2048...

[greyhawk]

- The same issue with Y2K problem.

The conclusion ? Everybody always thinks that their system will be replaced by something new & better in the future, but it often does not happen, hence the problems we have today.

Know why Y2K happened and went without anything happening?

Because the systems were replaced by something new & better before then.

Deal with issues when the need arises. There's way more important stuff to deal with first.

[cbeast]

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.

[cedivad]

I think you don't really grasp what 2^160 actually means... let alone 2^2048...

I do.

[ShadowOfHarbringer]

- The same issue with Y2K problem.

The conclusion ? Everybody always thinks that their system will be replaced by something new & better in the future, but it often does not happen, hence the problems we have today.

Know why Y2K happened and went without anything happening?

Because the systems were replaced by something new & better before then.

Deal with issues when the need arises. There's way more important stuff to deal with first.

obviously the Y2K problem got solved far more expensively than if they had fixed it in the first place by thinking long term, but …
if you always care about every eventuality beforehand you might decide to not even get started. It's about priorities and not about doing the right thing now for all eternity.

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.

[CIYAM]

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).

[ShadowOfHarbringer]

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.

[ShadowOfHarbringer]

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 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).

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.

[CIYAM]

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.

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?).

[meowmeowbrowncow]

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.

[ShadowOfHarbringer]

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.

+ 1000

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

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.

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

[FreeMoney]

- Longer private/public keys = more possible addresses, better protection against money loss due to the identical address generated by 2 people

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

[ShadowOfHarbringer]

- Longer private/public keys = more possible addresses, better protection against money loss due to the identical address generated by 2 people

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

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 !!

[greyhawk]

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

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

[DeathAndTaxes]

I think you don't really grasp what 2^160 actually means... let alone 2^2048...

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.

[ShadowOfHarbringer]

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

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.