Everything you need to know about the $PAC 51% attack patch

Everything you need to know about the $PAC 51% attack patch

The following article is a community guest post by ‘Unick’ – Thank you for your hard work and contribution.

What is a 51% Attack?

To understand what a 51 percent attack is, you need to understand how mining works.

Mining cryptocurrency is the action of solving complicated mathematical problems in such a way that the solutions to such problems are related to one another in an expected and verifiable manner, forming what is known as the blockchain.

To further put into context how a 51 percent attack can be carried out, you need to keep in mind that mining is expected to be done by independent and honest miners. The more miners, the more decentralized the mining is and the more you can expect that no one person/group can take control of the blockchain. This is the base premise of the blockchain concept. Everyone can access the information stored into the blockchain (units of coins typically) without relying on any “middleman” as a trusted party validated said information and where no one can manipulate the historical data without breaking the chain consensus of mathematical results (work).

Now, a 51 percent attack is, as its name implies, an attack where 51% or more mining power is under the control of one person or group. This is generally bad because now, that person/group could potentially split the main chain of blocks, and fool the recipient (victim), long enough to get something out of him without a proper and honest exchange.

This is better explained with an example.

Take Bob, who’s a bad actor trying to carry out a 51% attack. So Bob has more than 51% of the mining power of network C. Now, Bob will mine a private chain, faster than the network, and keep it hidden from network C, for the meanwhile.

Bob will now send his coins to Exchange E (the victim) using the normal public chain, while mining his private side chain. Bob will also keep mining his private chain long enough so Exchange E can clear his deposit.

Once his deposit is cleared, Bob will rapidly sell the newly deposited coins for some other currency, like BTC for instance, on Exchange E and withdraw those BTC as soon as possible.

Now that the fake transaction is cleared on the exchange, Bob can render his hidden chain public to network C, and since his chain is longer then the main chain, a reorg (Reorganisation – Detaching the shorter chain and attaching the longer one) will occur making Bob’s chain the main chain. This would roll back all transactions that occurred between the starting point of the hidden chain, up to the height of the hidden chain when it’s made public.

Bob gets his coin back and keeps the BTC. The con is completed.

So a 51 percent attack is a way of temporarily gaining influence over the Satoshi consensus. During that time of influence, the attacker can trick a recipient by sending a real transaction that, because of the influence over the consensus, will be reversed when the con is complete.

A more in depth explanation can be found on Medium, here.

Are My Coins at Risk During a 51% Attack?

Generally no. To be more precise, a malicious actor cannot steal any random person’s coins with a 51% attack. The attacker usually targets a recipient prior to the attack, in order to double spend his own coins. A double spend is not stealing the recipients coins, rather, it’s the attacker trying to momentarily trick the recipient with a fake transaction long enough to complete their con. Once the con his complete, the release of the attacker’s hidden chain will force a reorg of the blockchain, rolling back their fake transaction, sending back the coins to the attacker and leaving the recipient at a loss for the value of what was exchanged for the rolled back coins.

Honest transactions would also rollback once the hidden chain becomes public, but would eventually resend and reconfirm in a later block. So everybody else on the network his not affected by the 51% attack. Clever, really.

The $PAC solution – A Penalty System For Delayed Block Submission

The solution implemented with $PAC was proposed initially by the Horizen team, (Thanks guys, great project!). This solution considers private mining (hidden chain from network) as the source of the 51% attack and proposes a penalty system for delayed block submission, which would penalize a malicious actor more and more the longer he keeps his private chain hidden from the network.

Figure 1 represents a split chain scenario from Normal Block 100 (NB100). When the hidden chain is made public at block NB116, it contains 119 blocks (MB119). Since the MB chain is longer than the NB chain, blocks NB117 and onward are not going to be mined since the MB chain becomes the main chain.

To prevent the attack, the proposed solution introduces a fork acceptance delay . Which tells the honest miners that before accepting the hidden (malicious) MB chain as the main chain, the Delay function (Df) needs to equals 0.

How is the Df defined? Well there are 2 parts to it. The first part contains blocks up to the current NB height, and the second part contains the blocks after the current NB height.

For the first part, we are using the sum of a series of items, where each item of the series is the difference between each block’s height on the MB chain with the current height of the NB chain. For the this first part in our Figure 1 example, there are 17 items (16, 15, 14, …, 0). The sum of a series is equal to n1 * ( a1 + an) / 2 where n1 is the number of items up to current height and a1 is the first item’s value and an is the last item’s value.

Here a1 = 16 (116 – 100) and an = 0 (116 – 116)

For the second part, each block of MB that is submitted that is greater than current NB height gets a value of -1. Here, there are 3 items (blocks) n2 over NB116, so the second part of the formula is equal to n2 * -1 =3 * -1 = -3

We then add the two parts which gives us:

(n1 * (a1 + an) / 2) + (n2 * -1)

in our example from Figure 1, this would look like

(17 * (16 + 0) / 2) + (3 * -1) = 133

Which means that the attacker would have to mine another 133 blocks before his MB chain becomes the main chain.

This can be fine tuned in order to become effective. But let’s assume we set a 25 block confirmation time for any transaction on the network, then an attacker would need to mine 26 blocks before trying to release his hidden chain and effectively reverse his malicious transaction(s).

That would translate into a minimum delay penalty, imposed by the network before the new MB chain becomes the main chain, of 27 * 26 / 2 = 351 blocks. This renders a 51% attack less economically viable as 351 blocks on the $PAC network would mean that the attacker would need to run the attack for at least 14 hours and 37 minutes on average and possibly more, as honest miners would still continue to mine the NB making it even more difficult to bring the delay penalty equal to 0.

The Horizen paper about A Penalty System For Delayed Block Submission can be found here.

Why This Solution?

While this solution cannot prevent natural forks from happening or if an attacker mines his chain publicly, it still helps in preventing malicious 51 % attacks by adding a layer of complexity to the issue, this is why this patch was dubbed ‘51% attack MITIGATION‘ by the team.

This solution also gives time for an exchange to react and freeze potentially malicious deposits until the fork as been resolved.

Honest miners still continue to mine the main chain, adding to the difficulty an attacker needs to overcome to catch up to and carry out a successful attack. Plus, in the event of such a hidden mining 51% attack, those honest miners would have all that delay penalty window to react by increasing their mining power to further reduce the influence of the attacker’s mining power on the network, effectively protecting that delay penalty.

What’s next?

While nothing should ever be considered completely neutralized when it comes to attacks and security in general, this system lays the foundation for a more complete layered system where additional methods can be added to further strengthen the network. For instance, a block notarization system, where block’s could be signed by masternodes on the network. Combined with the above penalty system and this would make it exponentially more complicated and economically irrational to attempt such attacks on the network.

Furthermore, the latest Long Lived Masternode Quorum (LLMQ) proposed improvement from the Dash team could also neutralize 51% attacks on the network. But while LLMQ could be implemented into $PAC, having the penalty system for delayed submission already in place, protects the network while we implement further security measures to improve the network. And that is a good thing.

More can be read on LLMQ here and here as well as the more technical read on DIP8 here.

This article was a community guest post by ‘Unick’ – Thank you for your hard work and contribution.

Leave a Reply