Pages:
Author

Topic: Anti ASIC/GPU/FPGA POW-algorithm. New (2019). - page 5. (Read 1230 times)

hero member
Activity: 1484
Merit: 505
December 09, 2019, 12:51:44 AM
#4
if there is no possibility of mining coins using GPU or ASIC or CPU then how will pow yours mine the coin Huh?
sr. member
Activity: 1330
Merit: 251
December 09, 2019, 12:43:46 AM
#3
Maybe I posted in the wrong thread?

 
   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?
member
Activity: 264
Merit: 13
December 08, 2019, 05:36:28 PM
#2
Maybe I posted in the wrong thread?
member
Activity: 264
Merit: 13
December 08, 2019, 01:49:34 PM
#1
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! Smiley
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
Pages:
Jump to: