Bitcoin Forum

Let's just say the NSA cracks it tomorrow... is that the end, or can the developers shift gears to a different form of encryption?

The devs can change the hashing protocol with a hard fork (if everyone accepts their new client of course,) but if they change from SHA 256 all the asic miners gonna be real pissed off because that would make their asics worthless over night because their asics cant do anything else, so there would be a lot of resistance.

Gotcha.
Is there no way to change & retain ASICs use?

EDIT: And ultimately, while it would suck for hardware owners, it is a necessity if BTC is to remain viable.

No, ASICs are hard-coded to a specific mining sha256d implementation.

FPGA's however could become relevant again.

Very interesting!  Thanks!

Switching Bitcoin protocol will be extremely difficult and risky. If petaflop power of currently implemented ASIC hardware is lost, the network would become so weak that it'd be vulnerable to anyone who can afford to spend $50ish-million on developing ASICs that use new protocol.

So switching is viable, but dangerous for the network until overall computational power is restored to the point where no single entity can easily amass 51% of hashrate. The 'problem' will worsen as time goes on and more SHA256 ASIC are added to network.

Luckily, the market has already created a solution to this. It's called Litecoin (only big non-SHA-256 coin at present). As for ASIC miners, their expected ROI point is usually 3 - 6 months out at most anyway; and most are aware SHA-256 will not live forever. The market will hedge its bets with a big shift to LTC if necessary, but really I doubt the actual cracking of it will be a big issue. It's unlikely to occur and be used in an attack. More likely, it will be published (maybe even with a couple weeks of heads-up lead time to Bitcoin devs, since that's the single biggest implication of it) with the details held secret until the hash function is updated and mining strength is strong (which would happen quickly, as even CPU mining would again be viable, and the circle of life of a crypto's hash function continues).

Also, please explain your logic in thinking a 51% attack is any more viable while a new hash function is in it's infancy, and everyone goes back to CPU, then GPU, etc. It seems to me that this is perhaps actually desirable, for the decentralization and prevention of 51% accumulations. I believe Satoshi would agree with me.

is Scrypt vulnerable like sha256 though?

Neither is vulnerable...

Bitcoin could switch to scryp, most scrypt hashing power goes go
to bitcoin , other scrypt alts lose most of their scrypt hash power.
The biggest danger here is for alts  IMO if sha is broken.

You are either very confused about the mining, merged mining, and the relationship between scrypt-based chains and SHA-based chains, or I was unable to make any sense of what you wrote.


Or, put another way, both are just as vulnerable, in that there are not any major weaknesses known for either. Probably more attention is paid to SHA-256 which is used in regular banks and a million other places. If they are equally strong, SHA-256 would probably be broken first, in that case. It is not possible to know which is stronger until both are broken, however.

Ehhh no, it's the NSA breaking SHA256 that pisses them off, not the devs taking necessary steps to keep Bitcoin alive.

What would piss off those asic miners more: their hardware becoming worthless because Bitcoin switched from SHA256 to something else, or their hardware AND all the precious bitcoins they mind becoming worthless because Bitcoin didn't switch and got effectively killed because SHA256 was broken?

Think. Miners deliberately take a risk by investing in mining hardware that could, theoretically, become worthless over night. To say it's extremely unlikely is still a vast understatement, but it's not impossible. Don't take that out on the devs.

The logic is strong with this one.

The ASICs would then get pointed at altcoins that use SHA-256 protocols, such as Peercoins and Terracoins, provided they themselves don't switch as well.

Mining hardware has such a short life cycle that it would not be difficult to schedule a changeover.

1. Pick a suitable replacement hash function and announce it. Give the ASIC designers time to prepare new chips.

2. Pick a block where the changeover happens, far enough in the future that everybody has time to get new hardware and have it ready to go when the switch happens.

It could probably be done in a year without too much disruption. Usually hash functions don't fail all at once so that should be plenty of time.

If this would be neccessary they would switch to a hashing algorithm for which ASICs are already out there. Yes, Litecoin could become Bitcoin's saviour in that (unlikely) scenario. It would probably also mean the (semi-) death of Litecoin because all the hashing power would leave.

Litecoin with Scrypt is kind of the backup redundancy of Bitcoin. I wish altcoins with alternate hashing algorithms be developed (instead of clones) and would gain sufficient popularity for ASICs to be developed. Redundancy's nice, but double redundancy's better :)

good to have some Litecoins  :D

Good to have some Scryt ASICs ;)

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.

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.

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

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.

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

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.

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

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.

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

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.

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.

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.

How does one compress a key?

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.

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.

nice summary

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.

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.