Bitcoin’s Biggest Hack in History: 184.4B Bitcoin from Thin Air | Hacker News Reader

Bitcoin’s Biggest Hack in History: 184.4B Bitcoin from Thin Air

hackernoon.com

115 pointsvinnyglennon47 comments

The change that invalidated the transaction was not a hard fork. It was a soft fork.

https://en.bitcoin.it/wiki/Value_overflow_incident

A hard fork expands the range of valid transactions. A soft fork narrows that range.

Remember the book Javascript the good parts? It proposes that developers ignore certain language features that can cause trouble. The interesting thing about this approach is that all the code you write by following the book's guidelines will run on all existing runtimes. Your code is backward compatible.

Had the book advocated new language constructs, then those applying them would not be able to run their software on existing runtimes.

This difference is roughly comparable to the difference betweeen hard and soft forks.

Prior to the Bitcoin update, no check was made for overflow conditions. After the update, only transactions obeying a narrower set of rules involving an overflow check were considered valid.

A soft fork can be deployed by miners censoring blocks containing the transactions which are longer valid. Nodes that don't generate blocks need not update for they will never see the now invalid transactions. Miners need to update to avoid generating blocks that will be rejected by the network.

A hard fork requires even non-generating nodes to update, for they will need to determine the validity of blocks with transactions applying an expanded rule set.

This is the clearest explanation of the distinction I've read, thanks.

It wasn't the last time that centralized decision-making saved the day. Another incident that is worth reading about if Bitcoin failures interest you is the 2013 Bitcoin fork: https://freedom-to-tinker.com/2015/07/28/analyzing-the-2013-...

Basically, a new version of Bitcoin Core software was released (v0.8) and only part of the network was running it. Then a block caused a divergence, where folks running v0.8 started mining on top of a different chain than the one mined by folks on v0.7. Amidst the chaos, 2 developers (Luke DashJr and Pieter Wuille), decided that miners should rollback to v0.7 and mine on top of the "v0.7" chain. Miners and other devs quickly fell in line.

One lesson gleaned from these two incidents (featured article and this one) is that centralized problem-solving clearly made these events less catastrophic than they would otherwise have been. If in 2013 there had been no leader to advise the crowd which chain Bitcoin should be, the divergence may have been permanent. And then people wonder why nowadays Bitcoin keeps forking, when history shows that strong leadership prevents persistent forks. A persistent chain fork is not a technical failure, it is a leadership failure.

Which raises the question: If strong leadership is needed to define the meta-consensus, what use is it that the technical consensus is decentralized?

It takes for core developers years of great and conservative technical leadership to get to the point where I would trust them on the few points where a quick decision is needed. For example I'm glad that Luke came up with the idea of the segwit soft fork, but I will never forget his messing with Bitcoin Gentoo packages.

Technical consensus provides an important backup / tie-breaker when meta-consensus isn't clear.

This has happened multiple times in the past with Bitcoin, most recently with Bitcoin Cash vs. Bitcoin Core. The user-base is split, there is lots of propaganda on both sides. However the technical consensus yields a single chain (Bitcoin Core).

Actually there were 2 persistent bitcoin chains to emerge from that conflict, one led by Bitcoin Core’s consensus rules and one led by Bitcoin Cash’s consensus rules. Nothing technical prevented the fork. And to claim one is more “bitcoin” than the other is moot. In fact the argument of which bitcoin chain is what Satoshi would have wanted is still being argued about every single day...

True both are still around, but a user can simply choose the fork with the longest chain (most PoW).

This is important because all other metrics such as choosing based on message boards, market cap, etc. can be more easily gamed.

Not sure if this is entirely right but I think technical decentralization depends on its participants making conscious decisions to react to events, but that doesn't happen and somehow you need to assign higher weight (centralization) to certain participants (core developers) to correct a few things.

Don't "hard" changes require network consensus to be enacted?

As in if every one who uses bitcoin decided that changes suggested by leadership are wrong, and not in the best interest of the network, they choose not to update their client or they don't verify transactions containing the change?

there can be no immediate decentralisation the way you want to put it. The moment an OSS system is being implemented there is a main contributor and a core team of devs. It would take years for a system to be completely independent. Bitcoin is approaching towards this goal. But to think that decentralisation is useless because the devs along with the miners and users decided by consensus that a bug was indeed a bug is the wrong approach.

Now that so many coins are doing private encrypted transaction amounts, I wonder if a bug like this could go undetected. If you could find an inflation-causing bug in a popular private coin and exploit it, you could easily make tens of millions of dollars within a few days. Possibly hundreds of millions if you played it right. And even if you were later found out, it's not clear to me that it would be illegal or whether you could be prosecuted for it. It's the biggest bug bounty ever.

https://medium.com/@bitcoinprivate/official-statement-on-coi...

https://zcoin.io/important-announcement-zerocoin-implementat...

ok that explains how they know pretty well.

What always confused me about cases like this one is what is considered a hard fork. This was a software bug, and not a flaw in the design or protocol itself. When is it a bug fix, and when is it a hard fork? Is the client law, or is the protocol law?

- If there were more than one clients would this be an issue?

- If there were more than one clients and only one had the bug, would it still be a hard fork?

It's miner and user confidence in a specific chain that ultimately defines it.

Similar to country sovereignty, these things are defined only by how most people define it. You can't just stand up and say you are now your own country, you need to get other countries, other people, to agree with you. But at the same time, if a country changes its name/laws/maps, it doesn't become a "new country", it just changes.

You can fork bitcoin, but unless most users and miners out there agree to call your fork "bitcoin", then it won't be bitcoin. But if "bitcoin" decides to radically change, and most people agree with the change, then it is still bitcoin, despite the differences.

(as an aside, anywhere I say "most people" here, you can replace that with "most hash power" or "most users" or any other metric you want. I'm not trying to speak to specifics, but more the overall idea)

It's both: it's a bug fix, whose side effect is a hard fork.

The whole point of a blockchain is that there is no single authority that can unilaterally impose "law" by fiat. In practical terms, the software used by the majority of clients is "law", but it's entirely possible for forked and non-forked chains to coexist: for example, Ethereum Classic is a pre-fork version of Ethereum, and Bitcoin Cash is a fork of Bitcoin.

https://en.wikipedia.org/wiki/Ethereum_Classic

https://en.wikipedia.org/wiki/Bitcoin_Cash

> When is it a bug fix, and when is it a hard fork?

The simple answer is that this is a false dichotomy. A hard fork was necessary to fix this bug.

This was a soft fork, the article is incorrect.

Off topic: I can't read stories on hackernoon. The bright green header makes my eyes watery and after closing my eyes I can see the afterglow. I can see it even right now with eyes open. The fact that I can't scroll away from it, makes it even worse. Why would you make this header sticky?

Permanently burning the logo into users' retinas - it's an advertiser's dream!

you can either block it with uBlock Origin or use Stylish with

    .u-tintBgColor {
        background-color: rgb(255, 255, 255) !important;
    }

It really is an awful header.

That's most of the internet for me (off black text on off white backgrounds). Firefox reader mode is my saviour.

I remove the element using uBlock Origin.

> Satoshi Nakamoto quickly hard forked the blockchain to remove the 184.467 billion Bitcoins, which is the only thing that saved Bitcoin from dying an early death that day.

Of course, if something like this happens today, I’m not sure the solution would be as simple as this…

I was there. Someone would post the code for the hard fork and most miners would switch to the chain without the bug. A chain that has infinite bitcoins on it is worthless... Just as it happened back then. I switched over as soon as I read the thread about it and saw the chatter on irc.

I understand that most people probably would switch. I’m actually looking it this from a different perspective: would Bitcoin be able to regain trust? A large hack might kill Bitcoin if everyone decides that they don’t trust Bitcoin’s security.

I think it depends how it goes. Some people might gain trust if the community could move swiftly to fix the problem

It's an interesting question but I'm fairly sure that after ten years Bitcoin has matured enough that all possible exploitation vectors have been tested.

In theory though this would definitely cause some chaos if something like this happened today, I don't know if it's enough to kill bitcoin but it would certainly drop the price. Most people only interact with bitcoin in a very abstract way through exchanges and don't understand enough of the details to care. If the exchange switched to the proper chain and everything appeared to be fine to the end user I don't think you'd see too many long term problems.

The really huge problem would be if the digital signatures would have a weakness. I believe all the other parts of the protocol are simple enough to fix, but there's no mathematical guarantee that the discrete log problem in the Bitcoin elliptic curve is algorithmically hard, we just think it is, because it has the test of time.

Yes. The trust is not in the code, it’s in the hash power.

From a normal investor’s standpoint, the hash power is an implementation detail. Trust has to be in the integrity of the blockchain.

Maybe that investor shouldn’t invest in bitcoin or Proof of Work based chains.

These systems are nothing like PayPal and Venmo and investing in ignorance is just asking for losses.

I agree; nobody should be considering cryptocurrencies an investment. That’s not the message coming from most Bitcoin enthusiasts, though.

But what if the transaction had gone unnoticed for a year? What would you have rolled back? The created bitcoins would have spread all over the ledger.

The hacker should also have distributed a fraction of the newly created BTC to all known wallets. Would incentivize BTC users strongly to stay on the existing blockchain.

Its abundance renders it completely worthless. https://en.wikipedia.org/wiki/Hyperinflation is what you get.

  […]
  In short, whoever you may be,
  To this conclusion you’ll agree,
  When everyone is somebodee,
  Then no one’s anybody!

– W. S. Gilbert

It isn't really possible for something like that to go unnoticed.

Any time anyone at all makes a big transaction, there are a bunch of posts about it on Reddit and Twitter, because everyone is watching all the time, and Bitcoin is easily auditable.

But! There are some coins that focus more on privacy, such as ZCash. And those coins are indeed vulnerable yo this situation. Maybe there is a secret transaction, that has already happened that massively increases supply. The coins can't be audited, so they are there.

This problem does not exist in auditable Blockchains though.

>I’m not sure the solution would be as simple as this…

Why not? This is clearly a bug in the (reference) implementation, rather than a bug in the specification. An alternate implementation (in a safe language) would have caught this. This is different than say, a buggy smart contract, where all implementations will produce the same result.

What was the problem exactly? The article is a bit shy about it. Integer overflows usually reduce the value instead of increasing it.

The transaction took an input of half a bitcoin, and had two outputs of roughly 2^63 each plus another output that got a tiny amount.

Skipping over a few details, that means you send 92 billion to one address, 92 billion to another address, and the total overflows back under .5 bitcoins.

From [1] I think the issue is that you want the total output of the transaction to be less than or equal to the input, to ensure a transaction doesn't create value. The negative total output is less than any nonnegative input.

[1] https://bitcointalk.org/index.php?topic=822.msg9503#msg9503

Is there collateral damage when forks like this happen? Or can they precisely target just the one thing?

Yep. Transactions in subsequent blocks may be reordered or not included at all in the new chain forked from before the incident. Temporarily diverging forks are a property of Bitcoin anyway and must be expected. So your transaction being first confirmed but then dropping out is a possibility without assuming malfeasance.

Still it is also possible to revert transactions in Bitcoin if enough people agree. As demonstrated after this hack. The biggest collateral damage is in trust when this is demonstrated in vivo.

> Is there collateral damage when forks like this happen?

In this specific case, the only collateral damage would be if the attacker used the produced bitcoins to pay someone, and received something in exchange for this.

In this case, whoever sent the attacker something in exchange for the bitcoins, would stand empty-handed after these bitcoins ceased to exist.

hard forking is consensus and the whole system is built on consensus. it's the democracy of the developers, the miners and the people with skin in the game.

Reply on news.ycombinator.com