The year was 2025, in the month of march — I was having an interview with a big blockchain company for a Blockchain Engineer role. After spitting a lot of technical jargons back and forth for about 75 minutes, I was asked a trick question. "If you were to gain about 51% validator's stake in the Ethereum network, how can you profit from it?"

At the time, I had not studied what an attacker in control of more than 51% power of a consensus mechanism (PoW or PoS) could do theoretically to act in bad faith. I just knew that I had heard the term being tossed around a lot of times that it was bad for decentralization, and pretty bad things could happen. After the interview, I did a bit of search about the topic, and I found answers, but they were not really direct and definitely not from first principles of the blockchain. Very recently, I started studying blockchain concepts afresh from first principles and now I have the precise answer of the extents to which an attack like this can go.

The way we'd go about this is by presenting some assumptions and then trying to come up with proofs that either support or refute those assumptions. We'd be using the bitcoin network as our case study, and occasionally explain the ethereum's network variant, but the principles easily applies to other blockchain networks with slight variations here and there. Alright…. let's dive right into it.

Claim 1: An attacker can steal coins or tokens from your wallet.

uhhhhmmm…. let's take a pause first and define what a wallet is. For the most part, a wallet is a tool that holds a private key, signs transactions or arbitrary data using the key, broadcasts the signed transaction to a network. Accounts that can be stored in wallets usually exist as a public and private key pair — note that there are other types of accounts like P2SH and smart contracts which allow code to control an account rather than a private key. In this type of public/private key account (which you probably own) a wallet address is generated from the public key, and only the private key can sign transactions on behalf of that public key or address.

In public/private key cryptography, which is largely used in blockchain systems, the public key can be used to verify a message/data that the corresponding private key signed. It so happens that for coins/tokens to be spent or "signed-off" from an account, the private key has to sign some data describing the details of the transaction about to take place on the account. Now that we've established the protective measures in place in an account, let's examine what a miner has access to.

At the core of it, the blockchain is a series of ledgers (or spread sheet) chained together where a given block keeps the reference to the previous block before it. The so called "miners" or "validators" are, for the most part, in charge of keeping a copy of this chain-of-legders (which is intended to always be in sync — hence "consensus") and proposing new ledgers or "blocks" to be added to the chain — and that's about it. The only perk they get is getting incentives for participating in the network like getting block rewards and transaction fees. The same information foreign to me (e.g your private key) is also foreign to the miners/validators who keep these records. In order words, no matter how many of this miner nodes you control, you don't know what you don't know. Without the private key of an account, the best you can do is to use its public key to validate that the data being signed is truly coming from the "unknown" private key. That's about it — no more, no less.

The only way another person (miner or no miner) can gain access to the funds locked up in your wallet is by obtaining your private key by random guesses or brute force which is computationally infeasible, but that's a conversation for another day. I hope it's clear now why an attacker gaining a majority consensus power in a blockchain network is no threat to your tokens. And if you'd like to learn more and delve into elliptic curve cryptography — the maths powering keys on the blockchain, I recommend Programming Bitcoin by Jimmy Song. It's such a good book, I remember smiling sheepishly when I was reading it because of how simple he breaks down these concepts.

Claim 2: An attacker can create coins out of thin air

This one tickles my fancy most of the time…. I can't even lie. But let's ask the right question….. are coins — bitcoin in particular — really created out of "thin air"?! And the answer is……. technically YES, they are — up until year 2140 🙃R. whatt?! I'm actually being serious. But the catch is that it's actually been programmed to do so, so every miner does this…. not only an attacker that controls >51% of the network's mining compute.

Come to think of it, how are bitcoins issued? Well, they are given as block rewards to miners…. and then it starts circulation from there. Remember we defined what miners do above, well the bitcoin protocol gives rewards to miners that propose new blocks to the chain. They're rewarded with some bitcoins that's created out of thin air for being the first to solve the SHA256(SHA256(block_header)) < target equation (which uses brute force and serious compute power) and propose a new block to the network. In these new blocks they propose to the network, the first transaction — also called the coinbase transaction — is always their block reward which creates new Unspent Transaction Output (UTXO) — in the case of bitcoin — out of "thin air". This block reward started out at 50 bitcoins but is slashed in half every 4 years. These rules are written directly into the protocol.

This is how new bitcoins get into circulation — and there's a capped supply of 21 million bitcoins, after which they cannot be created from "thin air" anymore. When the reward ends, why will miners continue to participate in the network….. you ask — well they've still got transaction fees rolling into their wallets. So back to our claim, can an attacker controlling >51% of the network's compute create bitcoins out of thin air? Yes they can, but no more than honest nodes can do when they get to propose new blocks to the network. It's just the way the protocol works.

The only implication of controlling that much power is that around 51% of the time or more, the attacker's nodes get to propose a new block, which means they also get the block rewards that many times….. that's it. It's just like buying half the lottery tickets that are being sold…. of course you've got about 50% chance of winning — even though it'll cost you more to buy that amount of tickets than you'll be rewarded for winning. The same analogy applies here — the block rewards are negligible compared to what it'll cost an attacker to control >51% of the network's compute.

Claim 3: An attacker can stop you from using the blockchain, essentially censoring transactions.

With how far we've come in this article, I think we've sufficiently established the meaning of blockchain (distributed ledgers linked together) & transactions (which are entries on this distributed ledger). Now what does it mean for an attacker to censor transactions from "you"?!

what does "you" mean on the blockchain?! Is it the account where you have the most tokens?! Is it the account where you make the most transfers from? or is it a collection of addresses you've ever transacted with?

I'm sure you see where I'm driving at… the concept of "you" is largely loosely defined on the blockchain. Some could even make an argument that the concept doesn't exist on the blockchain — but that's not where I'm getting at. You can easily create an account that has no links to your offline identity. Miners who keep the blockchain ledger are also responsible for adding new blocks to the chain. A block comprises of signed data (in other words transactions) that have been sent to the network.

This is what happens when "you" send a signed transaction to the network. It lives in a place called the mempool which is like a buffer of unconfirmed transactions. Every transaction "you" have sent to the network once lived in the mempool. Now these miners are responsible for building new blocks — called candidate blocks — which are to be added to the block. After a miner node build its candidate block, then it starts trying to solve the SHA256(SHA256(block_header)) < target equation so that it gets to propose that new block to the network. The thing is that the transactions and order of transactions included in a miner's candidate block is totally at its discretion. It can choose to include transactions based on transaction fees, maximizing profit or any way of its choosing. And yes, it can also choose to reject (or not include) a transaction sent by a particular address — which can loosely be defined as the concept of "you" — in its candidate block.

But the blockchain is decentralized and permissionless. The fact that a particular miner node is refusing to add transactions from an address to its candidate block doesn't mean others would — and what's nice about the blockchain is that different nodes get to propose blocks, not just one node.

But what if a miner that controls > 51% of the blockchain's compute choose not to include the transactions from a particular address to the chain? Well, the short answer is that the attacker can choose not to include transactions from an address in any of the candidate blocks proposed by the nodes he/she controls, but it doesn't mean other nodes aren't going to include the transaction in their candidate blocks if they get to be the proposer of the next block to the network. And the long answer is that it's going to be a battle of ReOrgs(a concept I'd explain in the next section). The gist of it is that even though the other honest nodes get to propose new blocks at times, the attacker could secretly still be building its own candidate blocks on each other, and when the attacker nodes get to propose a new block, it can send it's modified chain that was secretly built, and because it's the longest chain with the largest "proof of work" or compute behind it, the network will accept it.

But if the attacker chooses not to include transactions from an address in any of it's nodes, "you" can just get another address and do your transaction using the new address. But it's possible for a particular address to be tied to a single function or reward — like the case of the address being a leaf in a merkle tree's root in an ethereum smart contract — where an address has been "computed" into an hash. In that case, a particular address is the only entity that can successfully carry out a function.

So theoretically, an attacker that controls > 51% of the networks' compute can censor transactions by not including them in any block, but it's practically less likely for that to happen.

Claim 4: An attacker can spend the same coins twice, essentially double-spending.

The core problem the bitcoin network was created to solve is actually the double-spending problem — without the need of a central financial institution, as that can be seen in the Abstract section of the whitepaper:

What is the double spending? It's essentially when digital money (the numbers you see on your bank app or wallet) can be used or "spent" more than once primarily because of discrepancy in agreement of weather or not it's been spent. That's why in the traditional banking system, the government setup a central institution where all transactions has to be routed by, so as to curb the creation of money out of "thin air" — even though the government print money out of "thin air" or "paper" essentially creating value out of nothing, but this is a discussion for another day.

How can tokens be "double-spent" in blockchain? Technically speaking, it's impossible. Period. But introducing some semantics, we can agree that it happened, but even then it's a zero sum game where one party is defrauded or pays for the "double spending" — value is not created out of thin air.

Why is it technically impossible? When money (or balance — ethereum, or transaction output — bitcoin) is sent from one address to another, it creates a record in a list of transactions added to a block, and then that "value" is now assigned to another address synchronously, after which it is considered to be completed when the block is accepted by the network. The concept of asynchronous doesn't exist in blockchain systems…. So how do we know the new owner of a transaction output?? We simply traverse the blockchain to know what address was assigned that transaction output. The sender address simple doesn't have it anymore, so it can't be double-spent. In the case of the ethereum network, the sender's balance is reduced immediately that transaction is added to a block, so even if it has multiple transactions in one block, the balance is reduced according to the order of transactions.

Now to explore how double-spending could be a possibility, we need to explore the concept of "finality" and "ReOrgs". Finality is said to be achieved when a number of blocks have been added or "chained" to the block where a transaction was included, such that it is infeasible for a "reorg" to make that transaction unconfirmed or no longer included in a block — back to the mempool.

What is a "reorg"? Looking at the snippet of the whitepaper I annotated above, "The longest chain not only serves as proof of the sequence of events witnessed, but proof that it came from the largest pool of CPU power". The way new blocks get added to the chain is that miners create their candidate blocks from transactions on the mempool, then they try to solve a computationally expensive equation — which can only be solved using brute force. The equation entails them 2x hashing the block header for this candidate block they've created and solving this "puzzle": SHA256(SHA256(block_header)) < target in which target is adjusted such that a nonce variable in block_header that satisfies the inequality is found approximately every 10 minutes. Target is usually adjusted to account for the speed and innovation in electronic devices compute over time. Now because all these miner nodes are competing to solve this equation, sometimes two nodes can find a nonce that satisfies the inequality at the same time, and broadcast this block to other participants in the network. Some nodes receive block #101A whilst some others receive block #101B. The nodes that receive block #101A starts building another candidate block from the mempool, using block #101A as their new latest block and trying to solve the "puzzle" so they can suggest the next block and claim the block reward whilst some other nodes do the same thing, but using block #101B as their latest block.

In this case, the nodes that created these blocks both receive the block reward — which suggest the creation of more bitcoins that should exist at that point in time. But relax, it's all a fugazi as this will soon be changed. The next node that solves the "puzzle" first will propose a new block to the network, and depending on the node, it'll either build on block #101A or #101B. Let's say it's built on #101A — what happens when the node propagates the latest block to the network is that all other nodes that have #101B as their latest blocks will get "reorg"anized so that they now build on top of #101A — block #101B will get discarded and it's transactions that are not in #101A will get returned to the mempool, the block reward given to the node that mined #101B will also get discarded, as its record doesn't exist on the blockchain anymore. The network will always accept the longest valid chain, because in Satoshi's words "it came from the largest pool of CPU power" — therefore it has the highest amount of proof-of-work behind it.

Now that reorgs are out of the way, I'm here to tell you that the way an attacker controlling > 51% of the network's compute can double-spend is by combining reorgs and a reward system that's disjoint from the network. What do I mean by this? If an attacker uses bitcoin to buy something offline — say coffee — and the transaction was mined in a block, the attacker can secretely build blocks that doesn't contain his coffee payment transaction and propose that to the network and if his secret blocks is the longest chain with the highest "proof of work" then it'll get accepted by the network and the coffee merchant will not get paid. The attacker can easily cancel the transaction, removing it from the mempool so that it never gets mined. Semantically, we can say this is double spending but in reality, the coffee merchant bore the liability instead of the attacker. So the attacker can use the money to purchase another thing, thereby getting double (or more) of the value he/she realistically spent.

Let's consider another scenario in the ethereum network that support smart contracts. An attacker could interact with a bridge on the network he controls where he deposit coins into a contract and gets an equivalent value on another blockchain network. The bridge application can see that the transaction was mined initially, and release the tokens to the attacker on a different network — after which the attacker can essentially make his deposit transaction into the contract disappear by forcing a reorg to happen on the chain.

I'm sure you can see a pattern now: for double-spending to happen, what is exchanged has to be disjoint from the network the attacker controls. This is essentially how an attacker controlling > 51% of a network can "double-spend". Just to make sure you understand the concept, try to imaging how an attacker can get fiat from a centralized exchange whilst still claiming his/her tokens back.

Claim 5: An attacker can rewrite the blockchain history

Short answer: capital NO… Long answer: other than reorg happening on a very small number of blocks, the answer is still a capital NO.

While an attacker is trying to rewrite the blockchain history, honest nodes are still creating new blocks — at the same pace in which he's "rewriting" the history. Imagine racing the exact same car to a finish line, but putting them on different starting points. All things being equal they'll maintain that same gap up until the finish line. So the chances of an attacker rewriting the blockchain happening is essentially next to zero.

Conclusion

In hindsight, after understanding all these, I later found out that the answer to the question is quite simple as Satoshi answered it in section 6 of the bitcoin whitepaper.

So guys, just read the fucking whitepaper. Any change the attacker makes to the underlying principles of the network creates a fork, meaning the attacker now runs an entirely separate network with is no longer "bitcoin" or "ethereum". To understand why this is, I encourage you to read up on Ethereum classic and bitcoin cash.

And to finish the story I started in the intro, feedback from HR was that I didn't get the job solely for my ambiguity in answering the question. But I moveee…. better days are ahead 😎.