EggdraSyl - Sept 2018
From earlier unpublished notes.
Instead of having a single simple mining algorithm like now, move to a dual (or more) mining algorithm system.
The current BIS mining algo is pretty simple (2 sha rounds + diff matching) and can be ported to fpgas and asics with little difficulty and a huge increase in hash/w.
Therefore, first FPGA movers have a huge advantage over the current GPU miners.
We welcome fpga and asics miners on the long term, since it's the natural evolution of a coin, to be more secure.
However to be fair and not centralized, the mining equipment has to be widely available.
As of today, modern high end FPGAs are almost impossible to buy. Only relatively small batches are bought by group buys and end up in a few big mining operations and some small miners.
For instance, a single FPGA miner operator proved possible to get 30% of Bismuth hash power in a consistent way.
Split the mining into 2 different algorithms.
-
Algo "A" is the current mining Algorithm. Not memory hungry, it can be mined on everything and gains huge performances on fpgas and asics.
-
Algo "B" is a new fpga/asic hard algorithm. It still could be mined on fpgas or asics, but will need way more logic, ram and bandwith, therefore the performance gain can be marginal.
-
GPUS can mine both "A" and "B"
-
FPGAS can mine "A" with a big advantage but will only have marginal gain on "B"
See https://blog.theabacus.io/the-verge-hack-explained-7942f63a3017
This attack exploited several flaws. One is the difficulty adjustment algorithm, the other was the multi possible mining algorithms.
Verge allowed all 5 algos to run in parallel.
That is, every single block could be mined by any algorithm, the first ok block from any algo was accepted.
This means that instead of needing 51% of total hash, an attacker only needed 51% of the less used algorithm hash power.
On some other coins, the algo or the order of the inner hash functions changes in a pseudo-deterministic way, depending on the previous hash.
That also is a design flaw, since a miner can adjust the tx in a block to get the block hash that best suits its interest, therefore imposing the next algo.
What I propose is both simpler and more secure.
- Even blocks can only be mined with algo "A"
- Odd block can only be mined with algo "B"
This way:
- no way to cheat. Each algo has perfect 50/50 chances.
- no competition between algos
- the FPGA miners only can abuse (or secure, depends on the point of view) at most 50% of the blocks
- They still can mine, so we do not enter an endless fork war.
- GPU miners still have advantage over 50% of the blocks.
What is needed:
A dual difficulty controller.
Instead of having one value of (network hash, block time, difficulty) we simply need two.
One for even blocks (with a target time of 1 minute, but half the blocks)
One for odd blocks.
Of course, since the algorithm is different, the hash will be also, and since the miners for A and B are not the same, the values of Diff(A) and diff(B) can end up very different.
In practice, we have two interleaved chains, each adjusting to its own 1 min block time, both linked together at each block.
(one can't go faster than the other)
This can be extended to more than 2 algos, for instance to test a new mining algo version before final release, or just to keep ahead and always have a resistant algorithm if needed.
Instead of 50/50, we can decide of another repartition, like 2/3.
Just play with modulos and a list of algos, like
A,A,B or A,B,B,B,B
The current algorithm list (and therefore, algos number and probability) can be synced across the network via a message in the pow chain.
This allow for near real time adjustment if needed, like moving to 100% of a "C" algorithm once fpgas are commonly available and we have an open source fpga miner and hardware, or on the contrary, if we decide to go full fpga resistant for a reason.
Needs an HF. No technical difficulties I foresee.
Would probably need some work, notably for the communication protocol with their miners. Each new block should embed an extra information: which algorithm is to be used for this block.
Where most of the work lies.
Apart from the protocol change, means implementing and optimizing the new mining algorithm.
Also, mining software will have to be updated for all miners.
From experience, this will take a lot of time.
Many options are open.
- tweaked Bis algo to become a memory intensive algo, like adding a dag or a CSPRNG buffer.
- progPoW
- use of floating point arithmetics
- snowballs
Balance to be found between reinventing the wheel or choosing an algo that will attract heat because used elsewhere.
If we stay fully custom, we need to be targeted, we won't get impacted the same way.