Cryptography Lifespan

[BitSteam]

What happens when the technology is at the point where the cryptography behind bitcoin is no longer secure? Will the cryptography really last another 28 years?

[1715559059]

1715559059

[1715559059]

1715559059

[1715559059]

1715559059

[1715559059]

1715559059

[Atruk]

What happens when the technology is at the point where the cryptography behind bitcoin is no longer secure? Will the cryptography really last another 28 years?

Probably at least for a century on the really important parts, but if something seems imminent it is possible to switch that out for a new algorithm.

[BitSteam]

how would the conversion go from bitcoin 1.0 to bitcoin 2.0? Is that something that was pre-planned or will we just have to cross that bridge when we get to?

[Atruk]

how would the conversion go from bitcoin 1.0 to bitcoin 2.0? Is that something that was pre-planned or will we just have to cross that bridge when we get to?

The big change would be from ECDSA private keys and signatures to Lamport or another quantum resistant algorithm. The change would require no big disruption on the bitcoin network, and it was designed to be able to calmly make a switch like this. New and old algorithm addresses could co-exist.

[BitSteam]

Well thanks for the reassurance!

[Atruk]

Well thanks for the reassurance!

You're welcome

[DannyHamilton]

One thing to keep in mind. . .
Your bitcoin wouldn't automatically move from the old algorithm to the new algorithm just because the protocol had been updated.  The new algorithm would use new transaction types, so to get your bitcoin secured under the new algorithm you'd need to create a transaction sending them (back to your self).  If you have your bitcoin stored offline (removable media or paper wallet) and you are not keeping yourself up-to-date on the latest developments, you might not hear about the need to move your coins to keep them secure.  Depending on the weakness that is discovered in the current algorithm, it is possible that you could wait too long to move your bitcoin, someone exploits the discovered weakness, and your bitcoin are stolen.

That being said, it will probably be pretty big news if a weakness is discovered in ECDSA, SHA-256, and/or RIPEMD-160.

If your bitcoin is sent to an address that has ONLY received and NEVER sent any bitcoin, then they are secured by all three of the algorithms listed above.  Weaknesses in all three would have to be discovered before someone could take your bitcoin.  If you have any bitcoin that is sent to an address that has EVER been used to send bitcoin, then those are only secured with ECDSA (meaning a weakness discovered in ECDSA would leave your bitcoin vulnerable).  The likelihood of a weakness being discoved in all three algorithms within a short time of each other is pretty slim.  This is one reason that it is generally recommended that you use a new address for every transaction and never re-use bitcoin addresses.

[Node]

but also any change in the protocol would need the acceptance of the majority of bitcoin users.

Even if SHA-256 is partially broken (say easier to find hashes, but not fully broken), you-d see major resistance from ASIC miners. You might even get a split network.

Whoever holds the crowd holds the coinvalue.

[wtfvanity]

but also any change in the protocol would need the acceptance of the majority of bitcoin users.

Even if SHA-256 is partially broken (say easier to find hashes, but not fully broken), you-d see major resistance from ASIC miners. You might even get a split network.

Whoever holds the crowd holds the coinvalue.

Majority of the miners probably more like it.

[MoonShadow]

The first ascii character in the bitcoin address is what tells the bitcoin network what type of bitcoin address it is, and thus what method of cryptography is employed.  Currently, all regular bitcoin addresses begin with a "1", and the network cannot recognize any other kind within the main network.  (there is also a 'testnet' for development, which can use addresses that begin with "a" as well, IIRC)

The point is that you can use the current algo for as long as you like, and the network will not care; but if the algo is ever 'broken' there will be a push into another address algo that will be able to coexist with the running network.  As long as you transition to the new algo within a reasonable period of time, you won't risk losing your coins and a "Bitcoin v.2.x" will not be necessary.  This has been pre-planned from the start, by Satoshi himself.  There is a different modular algo system in place for transitioning the blockchain crypto (which is different, BTW) should that ever prove necessary, also without so much as skipping a block/beat.

The next address algo will likely produce addresses that start with a "2", so as you can guess, we've got till at least "9" before things get visually confusing.

[DannyHamilton]

Even if SHA-256 is partially broken (say easier to find hashes, but not fully broken), you-d see major resistance from ASIC miners. You might even get a split network.

SHA-256 wouldn't really need to be swapped out unless it was fully broken.  The most significant risk of a partial break would be ECDSA with the secp256k1 curve.  The miners really shouldn't care much if this algorithm were swapped out, and all non-mining bitcoins users would have a financial interest in accepting the swap.  If a significant number of users (10%?) started using a client that used something other than ECDSA with the secp256k1 curve for signing transactions, the miners who wanted to collect the fees from those transactions would quickly accommodate the inclusion of the transactions in blocks.

I don't believe this change would even require a fork, but if it did I don't think that would be a significant hurdle after a partial break of ECDSA with the secp256k1 curve is discovered.

[DannyHamilton]

The next address algo will likely produce addresses that start with a "2", so as you can guess, we've got till at least "9" before things get visually confusing.

Nah.  By the time 1 through 9 were used, most people would be pretty comfortable with the idea that "A" comes next.  You'd almost certainly be ok through addresses starting with "Z".  After then when you start using "a" I suppose there'd be a chance for some confusion, but that's so far off, I'm not really concerned about it.

[MoonShadow]

but also any change in the protocol would need the acceptance of the majority of bitcoin users.

Even if SHA-256 is partially broken (say easier to find hashes, but not fully broken), you-d see major resistance from ASIC miners. You might even get a split network.

Whoever holds the crowd holds the coinvalue.

We'd be on the 3rd or 4th generation of ASICs by the time SHA-256 needs to be replaced under any realistic conditions, but even then the transitional process wouldn't likely make the ASIC's completely worthless.  For example, the crypto setup for the blockchain (wherein SHA-256 is used) has "hooks" for using two different algo's in series.  Currently, SHA-256 is simply used twice, but if things start looking like SHA-256 is at risk of being undermined; the developers could switch one of those methods to some other algo, so that both SHA-256 and the new algo must be employed.  This would still give those professional miners with SHA-256 ASICs an advantage over GPUs for a time, as well as a future set of algos in order to develop the next set of ASICs for.  If SHA-256 is ever broken, it won't matter much what the ASIC miners had planned.

[DannyHamilton]

. . . Even if SHA-256 is partially broken (say easier to find hashes, but not fully broken) . . .

. . . If SHA-256 is ever broken, it won't matter much what the ASIC miners had planned.

If it is only partially broken, we'd just see the difficulty increase substantially.  Beyond that everything else would remain the same until/unless there was an effort to replace on the the hashes in the series. If that happened, I assume there would be an effort to replace the SHA-256 hash in the generation of bitcoin addresses at the same time.

[MoonShadow]

. . . Even if SHA-256 is partially broken (say easier to find hashes, but not fully broken) . . .

. . . If SHA-256 is ever broken, it won't matter much what the ASIC miners had planned.

If it is only partially broken, we'd just see the difficulty increase substantially.

And in a way that ASICs likely couldn't compete with anyway, since they can't be altered to take advantage of any shortcuts found; whereas GPU miners most certainly could.  I'd say it's almost a certainty that if any portion of SHA-256 appears to be at risk, there will be little resistance from the mining community.

[conv3rsion]

If the cryptography behind bitcoin is broken, we have much bigger problems then with just bitcoin.

[MoonShadow]

If the cryptography behind bitcoin is broken, we have much bigger problems then with just bitcoin.

Amen to that.  If the algos used in bitcoin are ever broken, it's highly likely that just about every algo in common use on the Internet is at risk, including those that secure your connection to your bank's secure website.

[Node]

if SHA-256 is partially broken, and its proposed to swap one of the 2 algorithms with a newer replacement such as say Keccak (SHA-3), you'd see some resistance from large ASIC investors as it's no longer feasible to use their infrastructure once the swap happens. We'd be back to GPUs or very likely the swap would be announced for a future date (a few months), giving enough time for new ASICs to be developed that run the new algorithms.

The urgency of the swap would largely depend on how much SHA-256 is broken, if difficulty can't be set hard enough or becomes too closely to being able to break the address space (https://bitcointalk.org/index.php?topic=107172.0), then urgency would be high.

Either way an interesting and potentially volatile situation.

[wtfvanity]

...the swap would be announced for a future date (a few months), giving enough time for new ASICs to be developed that run the new algorithms.

A few months would be plenty of time for BFL /end sarcasm

[bluedye]

Nice post here. Lot to gain from reading and I do hope you are right about the lifespan of encryption applied.