By: Caleb James DeLisle
Since the very beginning of the PKT project, it was my clear intention to create a mining algorithm, which required the use of internet bandwidth to mine. I strongly believe that the best way to create a more decentralized, more inclusive internet is to create artificial demand for bandwidth.
Some people consider crypto mining to be a negative externality, but I couldn’t disagree more. Besides the fact that the only fair and decentralized way to distribute cryptocurrency, crypto mining also creates artificial demand for socially beneficial commodities.
What’s critically important is that unlike land, gold or petroleum, commodities such as electricity, bandwidth and compute power do not run out, and because of economies of scale, the more these commodities are used, the cheaper they become.
You might be saying “sure, at scale energy will be cheap, but only by burning every ounce of coal on the planet”, however this entirely misses the point. At scale, coal is not economical. To understand why, consider what it takes to double capacity of a coal powerplant: this means you need twice as much coal, twice as many deliveries, twice the surge pile capacity, the list goes on and on.
By contrast, crypto mining is in fact a huge positive externality, which along with the ongoing switch to electric vehicles, will help push renewable energy technology past the point where economies of scale render coal and petroleum energy obsolete.
PacketCrypt was designed to not only be minable using commodity CPU hardware, but it also makes it so that optimal mining requires communication between miners. This communication is the core of PacketCrypt’s bandwidth hardness. Bandwidth, like electricity, benefits from economies of scale, so the more of it that we use the more that we will have.
Bandwidth is not the only thing that PacketCrypt incentivizes. The CPU component of PacketCrypt (which needs to exist to make the bandwidth hardness work) is designed to be reusable for encrypting a packet of data for a VPN or other secure networking application. This is called a CryptoCycle and takes the place of hashing in most cases.
The functioning of PacketCrypt is based on two types of mining. First there are “announcement miners” who create announcements (little messages) and do proof of work on those messages, then they send those announcements to so-called “block miners” who collect as many announcements as possible and prove that they have them in memory when mining a block.
In order to incentivize block miners to collect as many announcements as possible, the valuation of work is augmented based on how many announcements (and how much work was done on those announcements). Simply put, the calculation is
total_work = block_miner_work * minimum_announcement_work * announcement_count
Block_miner_work is the amount of CryptoCycles done by the block miners. Minimum_announcement_work is the minimum amount of CryptoCycles done on any one of the announcements in the block miner’s dataset. And of course, announcement_count is the number of announcements that the block miner has. When the total_work exceeds the requirement for the difficulty of the chain, a block is sent out with a PacketCryptProof, a data structure that proves the announcements were in memory at that time.
Because of PacketCrypt’s uniqueness, we spent considerable time ensuring the security of the algorithm. We focused on any way that a miner could gain unfair advantage from an unexpected application. However, what we didn’t spend so much time investigating was the veracity of its bandwidth hardness properties.
The logic behind PacketCrypt1 was simple: because we multiply work from announcements by work from blocks, there is no way to get something for nothing; you need to do work. From a security perspective this was very comfortable, but we later noticed the official measure of bandwidth was missing.
About 2 months after the launch of the mainnet, we noticed that the use of bandwidth was not ramping up as we had expected. After carefully analyzing the security of the PacketCrypt protocol, it was clear we had not verified that it was actually bandwidth hard.
After some discussion about what would be the best change to make, we began investigating a solution to square the announcement count. The logic behind this was
minimum_announcement_work * announcement_count is actually a representation of
total_announcement_work and if we are only
taking block_miner_work * total_announcement_work then it’s wiser for announcement miners to focus on mining just a few extremely high work announcements and reduce their bandwidth costs.
What we really wanted was to make it so that a block miner benefits from increasing either:
minimum_announcement_work * announcement_count)
This would make for a new calculation:
total_work = block_miner_work * minimum_announcement_work * announcement_count2
But because we were departing from the simple security model, valuing every hash equally, we needed to now pay even closer attention to the security of the protocol going forward.
When we talk about PacketCrypt security, it’s important to establish some boundaries. Even if the security of PacketCrypt were to catastrophically fail, it wouldn’t allow someone to (for example) steal your wallet. The worst thing that could realistically happen with the PacketCrypt algorithm is it proves to be minable much more easily than expected (for example by an ASIC). Of course we don’t want that, we want to incentivize deployment and use of bandwidth and encryption capability.
The two key areas we needed to re-evaluate for PacketCrypt2 were in mining with a percentage of fake announcements in the dataset and “compressing” announcements (sending information to the block miner so they can efficiently re-construct announcements).
Initially when I created PacketCrypt1, rather than spend the time calculating the exact boundary of the risk zone for fake announcement attacks, I simply designed it in such a way that I was confident we were far from it. However, squaring the count would move us closer to this risk zone so this time, we needed to find the boundary. After some time calculating, we found that the safety margin was so big that squaring the count was safe and in fact we would have to cube it to reach the bounds of the safety margin.
The other major concern was the risk of “announcement compression.” Announcements are designed in such a way that communicating an announcement requires 1KB of data and no significant reduction is possible. Obviously if the announcement miners could simply tell the block miners how they created the announcements, then they would not need to use much bandwidth. The way announcements are created is by performing a slow calculation to create an 8MB dataset and then selecting and proving random elements from that dataset. Obviously an announcement miner could tell the block miner how the dataset is created, but the creation of the dataset is slow, and block miners prefer to spend their CPU cycles mining blocks.
In doing the security analysis for PacketCrypt2, we determined that announcement miners could send the entire dataset to block miners along with the “winning nonces” and the block miners would be able to reconstruct arbitrary numbers of announcements from just that. That would obviously become a problem when we are squaring the announcement count. So we created a new announcement type which is mined in a slightly different way and which has a limitation such that only about 512 valid announcements will be found for any given dataset.
Once we had validated that the new announcement types and confirmed the new PacketCryptProof was working correctly, we scheduled a hard fork in two stages: (i) first the blockchain would begin accepting the new form of announcements, and then (ii) after that it would begin accepting the new block type, which depends on those announcements. In order to smooth the transition, we decided to continue accepting the older form of PacketCrypt1 proof, because the difficulty calculation would incentivize upgrading to the new one anyway. The forks took place on October 30th, 2019 and November 6th, 2019 respectively and the Gridfinity pool upgraded to accepting the new forms on November 8th, 2019.
PacketCrypt is an undeniably ambitious proof of work algorithm. Not only does it aim to be secure and fair, but it even aims to encourage the rollout of cheaper bandwidth and encryption capability. My personal opinion of ASICs is rooted in the objectives. If someone makes a chip for PacketCrypt, which also works for encrypting mesh networks, I fully support it. What I don’t support are “tricks” to mine PKT with reduced bandwidth and data encryption. My hope is that the community will agree to future hard forks in order to protect the miners who are working toward PKT’s core objectives.
Announcements were initially conceived as a means to send “a message to the world” and in the context of a broadcast network, it works. The possibilities with announcements are endless, from a decentralized “twitter” to a decentralized order book. But I believe that announcements can become much more than just a broadcast network. We are currently investigating the possibility for announcements to behave as lightweight tokens. To achieve this, it would undoubtedly require another hard fork, but the prospects of free token transactions are too good to ignore.
It has been said that “a ship in harbor is safe, but that is not what ships are built for.” Launching the PKT project has been an exciting adventure, which we never would have experienced with even the most interesting ERC-20 token. I would like to thank all those who have helped along the way, especially on the mathematical proofs. Finally, while the PKT-denominated bandwidth market is yet to be created, we are still blazing an exciting new trail into bandwidth consumption through this new proof of work. We believe this technology will change the way people interact with their bandwidth and the internet forever.