Theoretic paper on 51% attack and double spend prevention

Post Jok
Commercium (CMM)
Published in
5 min readFeb 8, 2019

--

INTRODUCTION

This document explains the theoretical implementation to secure and prevent 51% blockchain attacks.

What is a 51% attack?

A 51% blockchain attack is when a miner (usually with the help of a hash rental service like nicehash) gains more than 51% of the network hash. The network hash is calculated by the difficulty of the current block being mined,. While some blockchains average hashrate=difficulty over 2016 blocks, true hash rate is never known and so never reported.

It is calculated from time of finding a solution at a certain difficulty level. Once 51% of the total hashrate or more is achieved, they mine more blocks than the real blockchain, meanwhile transmitting a transaction of a number of coins which would be the double spend. To clarify: Double spend is a transaction that reverses after the attack and is the vector of profitability of the attack.

The blockchain will follow the chain that is the longest or has the highest height. The attacker mines more blocks than the real chain, connecting to all the nodes possible to cause a network reorganization. This reorganization contains the double spend coins, usually sent to an exchange to collect profit from the attack.

An exchange requires 3 confirmations for example for Bitcoin. The malicious actor would need to connect to all nodes to cause the reorganization and then mine for more than 3 blocks to achieve the confirmations required, and then sell the asset for profit on the exchange. The next step is to stop mining with the extra hash power, causing the pools or legitimate miners to continue mining and create a longer chain than the ´faux chain´ which would cause another reorganization to correct the blockchain. This would in effect return the coins to the malicious actor by marking all of their blocks as Orphans. An orphan block is a block that is mined but rejected and marked invalid by the blockchain. Normally, an orphan block happens when someone mines a block milliseconds before another miner.

That’s why exchanges nowadays adjust the confirmation time to the total hashrate, since it is easier and more cost-effective for the malicious actor to start a 51% attack with a lower network hashrate and a low confirmation time.

How to execute a 51% attack

Requirement 1 - Hashpower

A malicious actor has to obtain and usually hold more than 51% of the network hashrate for a successful attack. To attack e.g. the Commercium network (2.9 Msol/s), the actor would only need more than 1.5 Msol/s of
hash/compute/mining power.

Requirement 2 - Full node server and stratum/private mining pool

The actor edits the blockchain code to allow mining without any peers synced (by default we must have a synced peer if mining is allowed). He syncs the full node server/daemon to the current block height, disconnects from the main blockchain network and starts mining with peers turned off. He now points the hash power to his private mining pool and waits until he finds more blocks than the legitimate Commercium blockchain.

Once obtained, he executes his double spend, continue mining for the desired
confirmation height and reconnects his node to the blockchain. He now initiates a reorganization of the blockchain through notification of a chain with a higher block height than the ´current legitimate chain´, passing peer to peer.

Protection from 51% attacks

The implementation of masternodes have multiple purposes, which ranges from data storage to instant swift-tx transactions. Commercium is aiming to implement a system of recalling information.
All computers connect to a DNS (Domain Name System) server, which executes a lookup or recall of information, translating a DOMAIN name to an IP address.
Commercium will have a Block Inquiry System based on a protocol just like DNS:

!ActivateBestChainStep(state, pindexMostWork, pblock &&
pindexMasterNodeCheckPoint-> GetBlockVerifyHash() && pblock->GetHash() == pindexMostWork->GetBlockHash() ? pblock

The above code is split up in two pieces, the cursive portion is current blockchain code, while the bold portion is where it calls a function to verify the hash before it ‘activates’ the best chain.

pindexMasterNodeCheckPoint-> GetBlockVerifyHash()

The above would be a checkpoint function where every block becomes a checkpoint, immutable and where any history cannot be reversed. The blockchain will not function if the blockhash from these checkpoints are non existent. The front line of a reorganization can block a reorganization from happening and spreading to other peers if it can decide whether to abandon or accept a reorganization. If the node could find out, what height the whole network was on, it would know if a reorganization is malicious or not.

Remember a node must synchronize up to the current height of the blockchain. We just don’t want it to synchronize up to a malicious height.
The node would synchronize up to the current height of the malicious chain, and would verify the current block height by asking all masternodes if they have the current blockhash in their chain.

000000406bf82cd29da2f9174ddf04ebc56abae7870fe2192511ecb82ecc15c3

The above tx would be submitted over the Block Inquiry System. If the majority of consensus is YES or 1, then the node will accept the reorganization or synchronization and broadcast the block height to the other nodes. If the majority of consensus is NO or 0, then the node would abandon the reorganization and return to the last known block before the reorganization and look to sync from its peers.

In other words, if the current legitimate chain is on block number 12880 and the reorganization is up to block 12999, it will say: OK that node is broadcasting a block height of 12999 but by verification from the majority of the masternodes this is known to be a trick, then will ban
the peer that is broadcasting a higher block height/longer chain.

Block Inquiry System visualized

CONCLUSION

Taking control of the network via hashrate AND the Block Inquiry System through masternodes would require upfront costs and a considerable amount of CMM, which leads to unprofitably of the attack vector.

Furthermore, as the masternode network grows, the possibility of a 51% attack diminishes.

You can reach us via the links below, if you have further questions about the Block Inquiry System or Commercium Blockchain Technologies in general.

Website: https://www.commercium.net/

Discord: https://discord.gg/st9pCjk

Telegram: https://t.me/CommerciumOfficial/

Twitter: https://twitter.com/CMMBlockchain

--

--

Post Jok
Commercium (CMM)

Community Manager and Marketing Consultant at Commercium Blockchain Technologies