$PAC network ‘too robust’ for malicious transaction attackers

$PAC network ‘too robust’ for malicious transaction attackers

On the 3rd October 2018 $PAC came under attack from a co-ordinated group of individuals who attempted to bring the $PAC payment network down by launching a flood of malicious transactions, attempting to over-run the memory of all Masternode servers.

The result of this attack saw total masternode count on the $PAC network drop from just over 6,100 Masternodes to roughly 3,500 Masternodes. Whilst that may seem like a ‘successful’ attack, managing to drop ~40% of the active Masternodes on the network, this actually had very little effect on transaction times, payment reliability and network security. Merchants currently utilizing the $PAC network for payments saw no downtime as the 3,500+ nodes unaffected on the network were more than capable of handling the current workload.

In short: there is NOTHING wrong with the $PAC core code. $PAC is still a safe, instant & low fee digital currency and despite this ‘attack’ continued to function flawlessly as a financial product for cross border and peer to peer transactions.

What this did achieve however, was cause an inconvenience to existing Masternode holders. Many node owners lost their position in the payment queue and will now require a reset/update in order to become payable again.

The $PAC network attack explained


Over 40% of $PAC masternodes changed to an invalid status (mostly EXPIRED and NEW_START_REQUIRED). Most of the masternodes affected were on VULTR hosting at 512MB memory servers or less. While this led many to believe the fault was with VULTR hosting, it was not as VULTR nodes were not the only masternodes affected.

In simple terms: Any Masternode on a ‘cheap’ server with low RAM (under 1GB) was taken offline, whilst any server with 1GB+ was able to handle the increased ‘strain’ on the network.

Root Cause:

Thousands of malicious transactions (they were malicious because they were crafted to max the size of the transaction but provided no “value” as they were sent to and from the same wallet address) were sent across the network causing the memory pool to completely fill up, spiking memory usage on every masternode to increase by ~350MB.

What is MemoryPool?

The MemoryPool is simply a holding queue for transactions that could not be processed in a single block. The maximum amount of data that can be held in the MemoryPool is 300MB by default. This is the normal way cryptocoin networks deal with many transactions per second that can not all be processed at once, it is normal behavior.

Example of the Malicious Transaction: http://explorer.foxrtb.com/block/00000000000001d369ef5c8886c2c5e5894fe26c7c161a05c7c8ea84da440cec

Expand each single transaction to see how they expanded each transaction to bloat the size. We are currently investigating this wallet and will take appropriate further action if necessary.

The $PAC community and Devs worked tirelessly to bring clarity and information to those affected asap

“The $PAC DEV team isolated the masternode issue from October 3rd. It affected VULTR servers (and any other Ubuntu 16.04 servers with ‘0’ for their swap files). There was a flood of malicious transactions that over-ran the memory in these VULTR servers and the paccoind daemon crashed. Other servers on other providers “handled” this without any issues.”

We suggest that you no longer use the cheap VULTR 512mb servers and add the following command to all your masternodes:


https://gist.githubusercontent.com/foxrtb/b703ae761472c5599c4d83ab0d3d62ae/raw/e8913deb9e1b7cc9c649febd2942930e4f6f5127/add-systemd-from-script && chmod +x add-systemd-from-script && ./add-systemd-from-script

sudo dd if=/dev/zero of=/var/swapfile bs=1M count=4000

sudo chmod 600 /var/swapfile

sudo mkswap /var/swapfile

echo /var/swapfile none swap defaults 0 0 | sudo tee -a /etc/fstab

sudo swapon -a

swapon -s

So, in simpler terms – there was an exploit that “exposed” the default “0” swap memory parameter on the VULTR base system installations.

To clarify, all those worried about potential future exploits… this IS NOT a code issue in $PAC – but an opportunity to fix this in a future release.

Whilst we do not wish to provide a statement regarding the price/satoshi value of $PAC as a result of this ‘attack’. It is clear that whoever was responsible for this wanted to lower investor sentiment, cause a ‘sell off’ and tarnish the reputation of the $PAC brand and its team.

We want to thank our amazing community for seeing through this and continuing to support our efforts to provide a world class financial product to merchants across the globe. We will continue to form new business relationships in the coming months and this will not affect our roadmap/releases already scheduled for Q4 2018.

You can’t stop $PAC – You’ve proven that our product works flawlessly when stress tested.

This Post Has 2 Comments

  1. We have a quality team that cares, and carry out quick responses to keep the excellent reputation of the PAC community top shelf. We are the underdog and we will continue to amaze!

Leave a Reply