Anti ASIC/GPU/FPGA/CLOUD/MAINFRAME POW-algorithm
Now mining is available to everyone...

Hello to all.
For several years I was thinking about how to make a POW algorithm that will be stable not only against ASIC devices, but also against GPU miners.
And I developed it!
Last night I successfully conducted the generation and confirmation of the first local chain of signatures to confirm the block (see screenshot below). Therefore, from today on, I will publish a description of the algorithm and parts of the C++ code.



The main decision.

The only reason that does not allow the crypto community to solve the problem of specialized devices is the adaptability of modern POW algorithms to parallel calculations.
This is where the ideal solution comes from - the calculation algorithm must be consistent and resistant to any possibility of performing calculations in parallel.

The first principle is cyclic calculations.

We must abandon hashing, which is now the main calculation algorithm for block signing. I propose replacing it with the Ring Bit Function (RBF), because it perfectly fulfills all the requirements for the POW algorithm.

POW algorithm requirements:
1) one-way function;
2) hard to calculate;
3) easy to check;
4) only sequential calculations.

Let me give you an example of RBF for a 32-bit number.



You see that after 8 rounds of such calculations, we again get the initial number. Since the calculations go in a ring, we can use them for the POW algorithm. For example, from the 1st to the 7th round is a search for the result of calculations. The 7th is the signature found. And the 8th round is a test of accuracy of calculations!



Moreover, this function is one-sided, that is, the inverse transformation is possible only by brute force.
Thus, for this type of computation, which I called the "Ring Bit Function", all 4 requirements for the POW algorithm are fulfilled.



If we talk about ordinary hashing, then parallel computations are possible in it, which allows the use of special devices to speed up computations.


(Thanks to IadixDev for the diagram.)

The ring size in RBF may be different. It depends on the combination of rotations and shifts that we apply. Some combinations do not create ring functions, so you must first check which combination works.



I will give some working examples for 32-bit numbers:

239 rounds
NewNum = (num >> 1) ^ (num <<< 1)

55117 rounds
NewNum = (num >> 1) ^ (num <<< 1) ^ (num >>> 3)

131069 rounds
NewNum = (num >> 1) ^ (num <<< 1) ^ (num >>> 13)

There are a lot of such combinations, which allows us to vary the level of computational complexity.

The second principle is Olympic rings.

One ring function can give us only one signature. But in order to find a “beautiful” signature, we need to calculate many ring functions. The fourth principle of the POW algorithm requires that all ring functions be connected. Since the calculations in the ring function are one-sided, when searching for a “beautiful” signature we move along the ring in one direction, and during verification, in the other. If we begin to calculate a new ring from an old signature using the same algorithm, then we will move along the same ring. To create a new ring from the old signature, we must change the algorithm to another. In this case, the chain of calculations will be similar to the Olympic rings (only longer - it will consist of hundreds or thousands of rings). Changing the calculation algorithm on each ring will help us increase the stability of our algorithm against ASIC devices.



To further complicate the algorithm against ASIC and FPGA devices, we will use masks at each transition from one ring to another. This masking algorithm is two-way. I called him Mystique.



The third principle is two-step signature.

However, an attacker can still increase his chances of receiving a block reward, since he can do parallel calculations based on different Merkle roots, as well as different points in time.
In order to eliminate this possibility, when calculating the signature, it is necessary to use only the data that cannot be calculated in parallel. At the same time, they must constantly change from block to block. Such data includes only the signature of the previous block and the block number.
Additionally, you need to fix the right of the miner to receive the reward, therefore, I propose to add the miner's wallet to the signature of the previous block, to which the reward for the block will be credited. All other data can be changed for the same block, so they are not suitable for calculating the signature.
However, all other data should also be fixed in the signature of the block.
To solve this problem, I suggest creating a block signature in two stages:

Stage 1.
Based on the signature of the previous block, block number, and miner wallet address, hashing is performed (for example, SHA256).
The resulting hash serves as a start for the main calculation when searching for a "beautiful" signature.

2 stage.
The signature found is only a pre-signature.
The pre-signature serves as a starting number for hashing, which receives all other block data - Merkle root, chain counter, timestamp, etc. as input.
We consider the resulting hash to be the signature of the block.
Thus, the miner will not be able to calculate the hash of the block until it finds the correct pre-signature. But finding it already makes no sense to calculate different hashes from different input data.

The fourth principle is self programming.

The latter principle allows maximum protection of calculations from ASIC devices. It is based on the idea that each input number is simultaneously a program by which it will be converted. Thus, each new calculation will be performed according to a unique program, which will not allow the use of ASIC devices to speed up the calculations.
To do this, it is necessary to divide the starting number into groups of several bits, and attach a certain sequence of transformations to the value of each group. This will best be illustrated by the example of the powerful one-way hash algorithm Mystique, which I developed specifically to enhance hash operations when computing a block. It uses various number conversions, examples of which you can see in the picture below. This algorithm will be considered separately, as it is an additional solution.



The problem is resolved.

Done. The problem of protecting the POW algorithm from ASIC / GPU / FPGA and other special devices is resolved. For greater strength of the algorithm, 256 bit numbers will be used in it.

What has already been done.

At the moment, the entire POW algorithm is developed and tested. The main algorithm code is implemented locally in C++.



What to do with it?

You can implement this algorithm in any cryptocurrency and it will be the best POW algorithm you have ever known.

Ring Bit Function. 1 part.
https://www.youtube.com/watch?v=yg-G6itsHpU&feature=youtu.be
An explanation of the new POW algorithm, which I call the Ring Bit Function (RBF), with C ++ code examples.

Ring Bit Function. 2 part.
https://www.youtube.com/watch?v=Ir9Ptfg0Nbg&feature=youtu.be
In this part we make a chain of RBF rings.

Ring Bit Function. 3 part.
https://www.youtube.com/watch?v=9-7NmuZXbdU&feature=youtu.be
An explanation of the new POW algorithm, which I call the Ring Bit Function (RBF), with C ++ code examples. In this part we will masking our chain of RBF rings.

Entropy of numbers in my algorithm (RBF).
https://www.youtube.com/watch?v=F3D1mgMJvuw&feature=youtu.be

 
   Hello! If you will transfer to another place, please leave a new address here, I would like to watch your development.


 p.s.  perhaps you have links to any other addresses related to your project?

I myself am Russian but I do not have such links
and what is the algorithm say for litecoin and miner ?

This looks nice and promising. But you may also wanna take this to the Altcoin Discussion section for more exposure and also for more feedback from people.

Go here

https://bitcointalk.org/index.php?board=67.0;sort=first_post;desc

Ok so if i understand correctly the first part, the idea is to use cyclic algorithm like rings, who have a known cycle length before it comes back to the initial number, and the miner need to provide the result at N-1 of the final result, prooving he has computed all the other values in the cycle before, and those rings can be combined to make longer proof that are still easy To check because only the last Step has To be computed by validator , is this correct ? and it cannot be parallelized because its lot of small sequential steps that depends on the previous result.

The third part the idea is to solve long range attack ? Like there only a single determinstic "seed" for each block height, which is also why its pool resistant as you explained in the other thread , because there can be only one problem to solve at each block height , so a huge mining rate doesnt give a big advantage for long range attack , as the only solution for this block has already been found before ?

The problem i would see with this approach is it mean if all miners have equal mining power, it would mean they will all find the block at the same time if they all have the same amount of computation to do no ?

With the original btc solo mining, all nodes have different tx in the mempool and work on different blocks with non linear solving time, so there is more chance one find a block before the other and make it easier to settle on longest chain.

It would be harder to get to a longest chain if all mining work is perfectly equal between all miners no ? The non linear solving time with the hash function still make it easy to have winners of the longest chain even with equal hash power. And game theory incitate to stay on the longest chain.

With your algorithm it is linear amount of computation for all miners no ?

Maybe using the 4th part also on the address to select the ring algorithm and forcing address change on each block. Maybe it could get less linear solving time.

Is it still supposed to work with constant block target time with the difficulty adjusting to keep time between blocks constant ?

Yes i think i get it, still need to give it more thoughts but it looks interesting.

So the rounds can still be distributed but they still need to be computed sequentially even if its by different miners to share the work, and needs a limit on the addresses that can be used for mining.

IP is not very good for this because it can become cheap and it would require that IP and its not possible for everyone to check if the Ip match the address, would be better with a solution that doesnt depend on IP.


But maybe need to find a way to register address for mining in way that cannot be spammed easily. Or another way to identify individual miners that would be costly to réplicate i think its not impossible though. Im thinking if every miner has it own different ring path that depends on his address in sort that it would cost something to start mining from a new address because of cumulated proof of work on a specific path that depends on an address. Or some way that would penalise changing address for the pow.

Ok
I see that you are looking for a serious solution. Then I will tell you a secret. Remember what I wrote about my first ICO project? VenusGEET ...?
So - in this project, all the problems of cryptocurrencies are solved radically. Everything is built there on completely different principles. Including in terms of economics. BUT! This project requires a lot of development time, which means that it need a lot of finance. Nobody will give me this money. Therefore, I decided so far to offer the community ONLY ONE algorithm that can be implemented in most cryptocurrencies, and which solves a really useful task.
This is necessary in order to solve the problem of my personal survival at the moment, and also allows me to earn a little trust from the crypto community.
Therefore, at the moment I am considering the application of this POW algorithm only to the cryptocurrency architecture that already exists, and which is now recognized. And in this architecture there are a lot of problems that are still not resolved. But I will not touch them. So far, I am focused on solving ONLY ONE of them.
If you are interested in a more global solution, then it will be solved fundamentally, but only after I can find funding for my VenusGEET project.

You bolded is contradictory as latency would factor in to such an extent that a sequential system cannot be timely distributed.

Whether or not this effects what is trying to be achieved here is beyond me but I figured i'd point that out.

Edit: OK, I see that each portion or these rings must be sequential and then they can be combined. Weird wording, maybe I'll delve into this later I have no time today.

Have you ever heard of RandomX? RandomX is not against anything. It just dont give advantage to anything. No one can build an ASIC that have double efficiency as top CPUs you can buy in computer stores all around the world.



Monero should not change mining algo anymore. If RandomX works as is intended to that is it.