With the release of The Burst Dymaxion white paper on December 27th 2017, the PoC Consortium not only presented the groundbreaking concept of a tangle-based Lightning Network, they also introducted a number of Capability Improvement Proposals (CIPs) meant to advance further development of Burst and describe proposed standards for the platform.
One of these CIPs, called PoC2, proposes an upgrade to the consensus protocol of Burst (Proof-of-Capacity) to fix a known issue detailed below. A few individuals have expressed their concerns with this upgrade – which I believe are fundamentally based on a misunderstanding of the underlying stakes and mechanisms.
But first thing first: what is the issue with PoC1, and how can PoC2 fix it?
The issue with PoC1
Proof-of-Capacity has many decisive advantages that make it more energy efficient than Proof-of-Work and fairer than Proof-of-Stake. Still, it is not perfect because of an underlying weakness in the way plot files are created, which allows an exploit called time-memory tradeoff first discussed in the old SpaceMint white paper.
To explain this exploit, we need to consider PoC1 from a technical standpoint. I will try to keep it quite simple. For a deeper look into plot files, consider reading this great documentation written by Quibus.
With time-memory tradeoffs, a miner can use less Capacity and invest more Work, by doing extra computations (Proof-of-Work style). Under certain conditions, he can mine at the same rate or faster than an honest miner, while using just a small fraction of the space.
The PoC1 protocol hashes all scoops in sequence and at the end with a final hash:
In an attack scenario only the final hash is stored. This hash is 32 bytes in size and is all the data a dishonest miner need to not have to create all other 8192 hashes to get to the scoop he wants to compute. In this scenario we store that instead of a full nonce. Therefore, with 32 bytes we get the equivalent of 256 Kb for an honest miner. This means the dishonest miner can store the equivalent of 8589934592 nonces on a single 256Gb nvme disk. That many nonces equals approximately 2 petabytes of normal storage.
The exploit code exists, but does not represent a fatal threat to Burst in its current form. In fact, one can assume it can allow around 2% of all mining capacity to go to dishonest miners. Not more than that, because the more iterations you make to shabal the slower it gets – the power you have will basically be weakened by every iteration.
This attack on PoC mining fairness was possible in theory since 2014, but not interesting economically because the PoW required for this mode of operation consumes far more energy than traditional PoC. However recent advancements in hardware and GPU performance do show that economical feasibility is just a matter of time.
The best solution: PoC2
The PoC2 proposal is a minimally invasive way to achieve time-memory tradeoff resistance, while keeping the currently used plots functional. The following figure represents the PoC2 concept of hash interleaving to re-shuffle SHABAL256 hashes in scoops in a way so that each scoop represents an equal amount of hashing effort:
In consequence, the PoC1 plots will require twice the reads compared to PoC2 and work on both optimized as well as unoptimized format. The difference between seek times of a PoC1 plot interpreted as a PoC2 (unoptimized PoC2) and “native” PoC2 is merely a factor of 2, as for each PoC2 scoop, two PoC1 scoops have to be read (consisting of the two 32-byte SHABAL256 hashes).
In other words, PoC2 plots will not find better deadlines and will not forge more blocks. They will, however, be read 2 times faster than traditional PoC1 plots – something that can be important for people mining with larger capacities. But how will PoC2 be integrated anyway?
What it implies for current miners
When the PoC Consortium started working on the PoC2 concept, the developers imagined options that would have made up an entirely new system and would have required replotting. Instead, they chose the path with the less hassle for current miners, the one offering maximum compatibility. Much energy has been spent to make something that allows a seamless migration path.
Indeed, contrary to what some people seem to think, miners with PoC1 plots will not need to replot. I repeat: miners with PoC1 plots will not need to replot.
Instead, miners who are concerned about the disadvantage in the reading speed of their PoC1 plots will be able to optimize their plots to convert them to PoC2. Two options will be offered to them:
In-place converting: the plot files are being rearranged directly where they are – you do not need any extra space.
Second location converting: the rearranged plot files are being copied on another location. Here we need as much free space as the plot file is occuping.
Mining software will operate on both PoC1 and PoC2 plot format. The optimizing process will require no computational power at all – it only copies data around on the disk. Concerning the time needed to optimize, it will be as fast as the drive allows. The faster the drive, the faster the optimization.
Why fixing this issue is a necessity
A signal we send to the crypto world
A signal we send to the crypto world
We just discussed the technical aspects of PoC2 and its implementation. However, PoC2 is more than just a fix to a technical issue: it is also a display of professionalism and reactivity from our development team.
The PoC Consortium strongly believes in flawless fundamentals, decentralization and innovation. Developers look at everything long-term and from a sustainability standpoint. That means fixing every possible attack vector as soon as possible, even if they are only theoretical at that point like time-memory tradeoffs.
If we truly want to bring Burst to its rightful place and to provide the world with a completely new financial system, we simply cannot allow hypotheses undermining the future of the coin to exist. Who would trust his money to a platform with known vulnerabilities that are not fixed just because it is more convenient to leave them there?
What would everyone think if Apple willingly left a potential security issue in the latest iPhone?
With the Dymaxion, the Burst blockchain will be the backbone of a global and scalable transaction system. We need it to be as secure, as reliable and as fool-proof as possible.
Cognitive biases from the opposing side
“A cognitive bias is a systematic pattern of deviation from norm or rationality in judgment. Individuals create their own “subjective social reality” from their perception of the input. Cognitive biases sometimes lead to perceptual distortion, inaccurate judgment, illogical interpretation, or what is broadly called irrationality.” (Wikipedia)
A few people have raised objections with PoC2 – oftentimes because they are misinformed, and sometimes simply because they are subject to biases in their reasoning. More specificaly, I usually see a present bias on this topic: individuals placing a greater value on goods/income achieved in the present moment – rather than receiving same goods/income in the future.
We have heard that “miners will quit if they have to optimize”. First, this is a very bold ipse dixit statement. A lot more miners are likely to be upset if the issue isn’t fixed and gets exploited in the future. Of course, they have every interest in the success of Burst in the long term as it increases their earnings – especially since we are currently the only Proof-of-Capacity coin: there is no other options out there.
We have also heard that the “PoC Consortium should work on the stability of the wallet instead of fixing theoretical exploits”. This strawman argument is entirely irrelevant since the PoC Consortium is close to releasing the new wallet version; it is simply distracting from an important issue.
Sure, implementing PoC2 now will represent a small hassle. Yet, it is insignificant compared to what would happen if the issue gets effectively exploited in the future: loss of faith in the coin, PoC2 implementation with a much higher amount of upset miners, reduced earning to honest miners, and so on.
So why are some pool operators opposing PoC2?
A few pool operators are reluctant to upgrade their infrastructure to PoC2 compatible software. While I believe they aren’t bad intentioned for the most part, they might have a limited view of the problem. They usually care about the miners on their platform from a short-term and profitability standpoint – sustainability comes second. We have Burst’s best long-term interests in mind.
This is not an issue as there is a majority of pools supporting the Dymaxion hard forks that are coming. If you are a miner and you want to express your support to the efforts of the PoC Consortium, simply switch to one of the pools listed on the link above.
With that being said, let’s focus on making Burst stronger and more reliable than ever.
source: www.burstcoin.ist
