Hacker News new | past | comments | ask | show | jobs | submit login

Is it correct to call it a $6.5 billion bounty? Once Bitcoin is hacked, the value of all the coins go to 0, no? Who would accept them knowing they could lose them so easily.



On the flip side, if the perpetrator could cover their tracks, the potential would be much greater than 6.5 billion. The feasibility of this depends on how many wallets are audited by external systems (humans and machines), and the ability to identify ones that are not. Once the word gets out, I agree with you it becomes a bank run and the value goes to zero.


> if the perpetrator could cover their tracks, the potential would be much greater than 6.5 billion

I think it's interesting to consider that this already could have happened or could currently be happening. A sophisticated attacker may be quietly reaping rewards in such a way that it's going unnoticed.

Granted it's unlikely given Bitcoin's core design is to prevent exactly that kind of untrackable-bad-actor-behavior, but it's absolutely possible with known weaknesses like a 51% attack.

I would hope some of the parties heavily invested in Bitcoin have verification tools that monitor the mempool vs. what ends in the Blockchain as I think even the most subtle attacks could be discovered that way... however even that may require an impossible perfect knowledge of the global mempool at any point-in-time.


A smart actor who broke Bitcoin would do things at the edges to manipulate the market and the value of BTC to extract as much as they could before people realized something was seriously wrong.


Most retail accept them through companies like coinbase or bitpay but they immediately convert them to USD so their exposure to a bitcoin hack is minimal.

The reason they do this has more to do with the fluctuating price though as they can't risk the value dropping after they sell something.


Right, also it's a bounty that can only be claimed through effecting a double-spend attack. I'm pretty sure that you would not be able to extract anywhere close to the full market cap in this manner.


In theory there could be a short window between when Bitcoin gets hacked and when people realize it; during that window the hackers could cash out some amount, although not billions.


What do you mean by "once Bitcoin is hacked"?


Using context from the article I think the commenter and article author are both referring to attacks (like a 51% attack or an unthought of new attack) where coins can effectively be stolen.


Good point, attacks on mining were probably what was being referred to here. Specifically because one of the counterarguments to the blocksize increase was that it promoted centralized mining, increasing the odds of a 51% attack.

I'll leave my other comment in this tree as food for thought, because Bitcoin has definitely driven research in cryptography. But it's the least likely attack vector.


I imagine a compromise in Bitcoin's cryptographic foundation, such as SHA256, is what is being referred to here.


SHA256 is used for mining but that would only expose new coins that are being generated. If there was a vulnerability there the community would switch to a new mining algorithm to secure new blocks.

Addresses are protected by hashing a public key to the bitcoin address (https://en.bitcoin.it/wiki/Technical_background_of_version_1...). If you've always sent coins to new addresses like the hierarchical deterministic wallets do then your public key is only exposed after you spend the coins, so you are not susceptible to a cracking attempt on the public key.


> If there was a vulnerability there the community would switch to a new mining algorithm to secure new blocks.

This would be extremely interesting to watch as a new algorithm would render all (or at least most) existing miners useless as they use SHA256-specific-ASICs. The economic and control fundamentals of Bitcoin completely change if you change the hash algorithm.

Not to mention it takes non-zero time to choose a new hash, make the code changes, and deploy it worldwide. Even if somehow you do that in hours or days, what happens in the mean time? Bitcoin would be entirely unsafe to use and anyone using it as their primary financial store better hope they have some food stockpiled (and bills paid)!

Luckily I've not heard anyone question the math behind Bitcoin's proof-of-work algorithm, so I think this possibility is exceedingly unlikely as the math is well understood.


Breaking Bitcoin's hash algorithm would require a feasible pre-image attack on SHA-256. Such a thing would have far greater consequences than forcing Bitcoin to change its proof-of-work algorithm. Tons of protocols and applications would be rendered insecure. We'd all be scrambling to fix TLS, SSH, IPSec, GPG, and dozens of other key pieces of software. I'm not sure how Debian-based systems would upgrade, since deb packages are verified by SHA-256. In short, it would be utter chaos.


Every system you mentioned other than Bitcoin already supports alternatives to SHA-256. There'd be a scramble for sure, but no different than the current steady stream of OpenSSL vulns. Probably less of a scramble than many OpenSSL vulns as SHA-256 could often be disabled via simple config file changes.

Bitcoin on the other hand would have to fundamentally change due to miners with ASICs. The code change might be minimal, but the economic, political, and psychological impact would be huge. For miners to lose their entire infrastructure investment in ASICs may cause an unrecoverable drop in hash rate as it takes 2 weeks for difficulty to recalculate.


This is why SHA-3 exists. If it starts looking feasible that SHA-256 is going to be broken, we already have alternatives. We've already seen TLS et al switch from hashes like MD5 and SHA-1 a few years ago. Pretty much all the other systems have systems in place to migrate in case one part of the validation system is cracked. Bitcoin doesn't, and given the fractured state of the community, having a migration system would be difficult at the very least.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: