Topic: Can Bitcoin eventually shift away from SHA256? (Read 3312 times)

If that happened so abruptly, which is incredibly unlikely, I'm sure no one would object to the client getting a tweak that allowed the difficulty to retarget at a snappier rate until we normalize.

That said, there is no reason why miners can't ramp down mining. In fact, just like the "selfish miner" objections, as long as the secret is out, it's mutually assured destruction. I'm told that works.

Could you imagine if difficulty is at 11ty zillion and all of a sudden we reverted back to GPUs as the only viable method of mining? We'd get stuck in the same difficulty period for months on end, like what happened with Namecoin a couple years ago.

nice summary

This isnt a new discussion, please use the search function.

1) SHA2 isnt vulnerable, and if it ever becomes vulnerable, its not like a switch thats flipped. We can see it coming, and adapt.

2). Bitcoin used double-SHA256. So even if SHA2 gets weakened, Bitcoin is still fine.

Use 0.6+ of the client, or software built / updated since then. More specifically: http://bitcoin.stackexchange.com/questions/3059/what-is-a-compressed-bitcoin-key

Rules that anyone might actually care about in simple terms:

Compressed public key (cpubkey):
039D85F2F2C4C9295ECBADB09AA118FF787B7FBDFBE528776D57C61C2E3A945F40 (Bold is the x-coordinate.)

Uncompressed public key (pubkey, I prefer upubkey for clarity):
049D85F2F2C4C9295ECBADB09AA118FF787B7FBDFBE528776D57C61C2E3A945F4010F812A01E8CDC71FB399EE7713EBDE44C55914172520EAD3135F84C3DCB7C1D

See the commonality?

Now, naturally, these both hash to different values. Specifically, under Bitcoin's current rules:

hash(cpubkey): E65C95EEC06C903B4CA2CA745A8245B232DE3BB7

hash(upubkey): 751B61B1646FB2AC1BB8CA34623AA29F1A821D18

Which then of course are different in the Bitcoin Base58-encoded format, also:

Compressed: 1N13L61jaUb481CWTgXCuJixJ7Sf1EXpGY

Uncompressed: 1BgCrxDUz44bU1YsBxLSkPcsep9bih1SmZ


Thus, without breaking RIPEMD-160, there's no way to guess about the pre-hashed string, and hash algorithms don't break into 1-to-1 matrices when they are considered "broken" anyway. In fact, if you notice the length difference, we're going to run into hash collisions long, long, long before address collisions. At which point we'd switch to a longer hash, and the client would switch to a new one, and it's all good.

So, despite them both corresponding to the same private key,  you can't see the balance of both by checking one. You'd need to check both of them. Your private key contains the information to unlock either one. Consider it -- since it is exactly the same type of thing -- like how there is a negative and a positive root of any real number. As in, sqrt(4) can be -2, or 2. "4" is your private key, and you need to know which public key (2 or -2) your funds are in. Or both. The difference in Bitcoin is, much bigger numbers, and the curve isn't a mirror at the origin, so one "root" can be a longer number than the other. For compressed keys, we use the small one. Also the mathematical operation is much more complex than just roots. And this was an analogy, and therefore a simplification.

If you are really curious, there is always this (which includes a graph of an elliptic curve): http://blog.cloudflare.com/a-relatively-easy-to-understand-primer-on-elliptic-curve-cryptography


Aaanyway, that's why compressed keys save blockspace, and more importantly, why you shouldn't reuse addresses, because you're less protected -- once you've spent from an address, you no longer have the additional protection of RIPEMD-160 guarding your funds.

How does one compress a key?

Actually, please just read through the Q&A here: http://bitcoin.stackexchange.com/questions/14278/if-sha256-were-compromised-tomorrow-would-bitcoin-collapse-or-is-there-some-co?rq=1

If you are still confused, then we can carry on.

And banks and everyone on the planet that uses it are fucked temporarily. Or, more correctly, "exposed".

Also, bitcoins are additionally protected by RIPEMD-160 -- if you aren't super clear on what that specifically could mean, I suggest research, possibly google terms "ripemd sha bitcoin address". No promises, but that's what I'd type, and my google-fu is strong.

One key point is that if it is broken, you'll wish you were never repeating address usage. As everyone has been telling people for ages, but both are still ignored flagrantly.

Edited because I wrote a phrase that did not mean what I wanted, and implied something else entirely. There is a related point to the security of compressed keys but it's a side topic, and minor, and not cryptographic in nature, and I'm too tired to explain what I mean by that.

Okay, maybe I didn't provide enough background about Gavin's words, MD5 is an already broken hashing algorithm, we wouldn't need to change the mining hash function even if it's broken, that was the point, because there is only a certain degree to which a hash function can be broken.


https://en.bitcoin.it/wiki/Block_hashing_algorithm read it here, you can'tjust  put random data in and create a hash meeting a certain difficulty target, the data that the hash is created from must contain lots of information which is contained in previous blocks and everyone has a full copy of the blockchain can verify, the wiggle room for a malicious miner is actually pretty limited.

But double-spending could still happen by creating two transactions hashed to the same value, this could be tackled by not allowing random data in transactions.

Proof of Stake solves that... just sayin'
NXT ~

Wait a minute, it wouldn't just be mining that needs to change. If sha256 was no longer reliable the whole thing is fucked isn't it? Signed messages could be faked easily, wallets could be decrypted easily.

Your condescension makes me a little wet. Would you like to go out on a date some time?

Yes I agree this logic is pretty strong, however, only if the news would be like "SHA-256 is cracked, replace it now or we loose everything" in that case asic miners would probably agree in their own best interest, but if the news is more like "an x number of steps of SHA-256 have been cracked and we better change now before the entire hashing algo is cracked in the future", it could be a different story., and their could be opposition to changing the algo when the threat is not imminent.

huh   , what exactly is incorrect, I basically said yes the devs can change the mining hashing algo, how is that incorrect ?

Incorrect, to quote Gavin, mining would have been just fine had we used MD5.

You can't just submit a block hash transformed from random data, the preimage must have deterministic data in it., that's one of the reasons why we use a blockchain rather than individual blocks.

This can be done if prepared on a huge scale on time.

First preimage attack just means that mining gets easier. As soon as all the miners adopt the attack as part of their mining process then the difficulty just goes up and the network keeps working.

Second preimage attack is the scary one that opens up the possibility of editing history cheaply.

To answer the question, Bitcoin can change any part about it's protocol, if enough people accept that change.

To comment on cracking SHA-2, I suspect most people talking about this don't even understand what cracking a hash function means. If this were to happen however, there is a solid chance that all hashes at once get broken, and no Quark or Litecoin offers a solution.

Good to have some Scryt ASICs

good to have some Litecoins