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.
yep
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 ?
I think there is a misunderstanding.
The third principle protects against parallel computing. This is his main task.
For example, if we do not use the third principle, each miner can generate 1000 different headers for the same block. This is possible because any rearrangement of transactions in places gives a different Merkle root. For 2 transactions, you can get 2 different Merkle roots. For 3 transactions already - 6 different Merkle roots, etc. The same goes for the time stamp. The miner can adjust the time when he began to mine the block. And this means that he can create many headings in advance from different seconds.
Thus, if a miner immediately makes a lot of block headers, he can start doing calculations from all headers at once. For example, there are 1000 of them. I take 1000 cores on the video card and each core counts 1 version of the header. Then I have 1000 chances against 1 that I will quickly find the right pre-hash.
To avoid this possibility of parallel calculations, the header should start only from the data that cannot be changed. And this is the height of the previous block, the hash of the previous block and the address of the miner's wallet. This data cannot be parallelized. This is the secret - why you can not mine on all the cores of the CPU or GPU. Only 1 core for 1 IP address, which is associated with 1 wallet address.
How this can help against long-range attacks, I do not quite understand. Long-range attacks are more characteristic of POS algorithms. However, if we assume a long-range attack option for the POW algorithm, then I think that “fixing the accumulation of network complexity” and a short distance of recalculating the complexity of the network would be a much better way to deal with them.
How it works...
Let's say that the attacker started with the genesis block and, after making a long calculation, forced the blockchain to increase complexity. Then he begins to make quick calculations and generates many blocks at high speed. Thus, after some time, the height of the block that the attacker will generate will be greater than that of the real blockchain. In this case, the nodes can go to a longer chain of the attacker.
What would be the best way to deal with this?
It will be good if the distance between the blocks until the next recalculation of complexity is short. But this does not save 100%.
But accumulating network complexity is a 100% solution.
It looks simple. In each block, we fix the complexity of the network at which it was calculated. In the next block, we add the old complexity of the network with the new one and fix the sum of complexity. In the third block, we add the complexity of the new block to the old amount of complexity. Thus, the “heavy” block chain will always be heavier than the light blocks of the fraudulent chain. This is a good marker by which the network can fight long-range attacks.
Now about the benefits of the pool.
The pool in my algorithm cannot bring an advantage precisely because it is impossible to divide the range of search values between miners. Since each miner can mine only from the header of the block that contains his wallet, and this value is hashed along with the hash of the previous block, for each miner the starting value will be unique, BUT - predetermined. The pool cannot allocate a range of values from 8 to 12 to the first miner, and from 56 to 72 to the other, because each miner has a predetermined starting value. In addition, due to the fact that the spectrum of values is distributed randomly in the ring of values, it also cannot be correctly divided.
For example, the first miner will have his range of values not from 100 to 200, but from this set: {100, 282, 13, 86, 72, 254, 989.} These are his predetermined values that he must pass. He can’t jump after 282 to 283 ... Do you understand?
And so for each miner.
Moreover, these values are NOT KNOWN in advance !!! That is - they are predetermined, because they are determined by the algorithm. BUT! They are not known in advance.
Thus, the pool does not have any data that can allow it to make a competent distribution of the spectrum of calculations.
That's why I drew that when using my algorithm, each miner will have the same range of values for searching a hash.
However, you should not be mistaken that such a situation will lead to the fact that all miners will find the hash value at the same time. Someone, after starting the calculation of the block, will not be able to find a suitable pre-hash even for 1000 years.
But this problem is also being solved. The algorithm will check for a new block in the chain. As soon as a message appears about a new block (of a higher height), the algorithm will immediately stop calculating the obsolete block and begin to calculate a new one.
I hope I clarified your doubt to you.