Anti ASIC/GPU/FPGA POW-algorithm. New (2019).

[flamehowk]

The hash algorithm seems already more complex, but if the video is correct it still mean you can find a correlation between the hashes between each ring and the proof of work become mostly on the hash.

Maybe i did something wrong in the procedure, but if the rbf can be regressed with 99%+ correlation like this, its not going to be a very good proof of work, and its very simple regression from free website, not even really tough crypto analysis. On weak numbers there is 70%+ correlation even on simpler functions.

If the video is correct still need to add something additionally to the rbf to break algebraic regression, and even weak correlation with simple regression doesnt mean there is no vulnerability.

Even if there is large part of the number that are eliminated from the brute force, it can still be ok because the attack time is short, essentially the target time between blocks, so in the 10minutes for bitcoin but would still need something a bit stronger.

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

Video response.
And you confused the names a little. My ring function algorithm is called RBF. Mystigue is the name of my hash algorithm. These are different algorithms. I just use them in my POW code both.

[IadixDev]

I need think this more, but its possible there is still hidden property on the last numbers that are going to be used for the signature, as its only one step away from the original, and lot of the entropy has been removed at this point.

There are way to scramble it more, but need to keep the cyclic property as well, which is the more difficult part.

Maybe using something like onion cypher, and each round encrypt the last exploiting same property of bit rotation with certain algorithm its possible it will still cycle back. And then you will have something with a strong entropy.

Im looking into simple cypher like this

https://www.cryptolux.org/index.php/SPARX


SPARX is a family of ARX-based 64- and 128-bit block ciphers. Only addition modulo 216, 16-bit XOR and 16-bit rotations are needed to implement any version. SPARX-n/k denotes the version encrypting an n-bit block with a k-bit key.

The SPARX ciphers have been designed according to the Long Trail Strategy put forward by its authors in the same paper. It can be seen as a counterpart of the Wide-Trail Strategy suitable for algorithms built using a large and weak S-Box rather than a small strong one. This method allows the designers to bound the differential and linear trial probabilities, unlike for all other ARX-based designs. Non-linearity is provided by SPECKEY, a 32-bit block cipher identical to SPECK-32except for its key addition. The linear layer is very different from that of, say, the AES as it consists simply in a linear Feistel round for all versions.

The designers claim that no attack using less than 2k operations exists against SPARX-n/k in neither the single-key nor in the related-key setting. They also faithfully declare that they have not hidden any weakness in these ciphers. SPARX is free for use and its source code is available in the public domain (it can be obtained below).

It doesnt need something very strong, just to resist 10 minutes brute force attacks, even using all the cpu power of the world on the brute force, even 64bits of "true entropy" would be enough from a 256bits space it mean even if its 75% broken its still ok for this purpose.


I will rename the files to remove confusion between rbf & hash

[flamehowk]

Maybe using something like onion cypher, and each round encrypt the last exploiting same property of bit rotation with certain algorithm its possible it will still cycle back. And then you will have something with a strong entropy.

Monsieur, in SHA256 hashing, which is used in Bitcoin, there is only ONE encryption operation, similar to the one I use in RBF. She is coming - at the very end. ONLY ONE!!! And ANYONE has not been able to crack this algorithm even despite the fact that it has an obvious built-in backdoor.
My algorithm uses thousands of such operations, and besides, they are all triple. You can also use quadruples, although this will not change anything. For example, rotate_right ^ rotate_left ^ shift_right ^ shift_left ... The difficulty level will be the same.
Perhaps you may ask why the level of difficulty when using the quadruple operation will be the same. I explain ... When the complexity level of the triple operation is greater than (the number of all atoms in the universe) ** 2 (to the second degree), then the difference between the triple operation and the quadruple operation, in which the level of complexity will be equal to (the number of all atoms in the universe) ** 3 (to the third degree), then for any cracker this will not change anything. That one, that the other - for hacking it is equally IMPOSSIBLE to hack.
HOWEVER, this will greatly complicate the task for us! Because we, as developers, need to find all the working keys, and this is a very difficult computational task. Especially because it cannot be parallelized. If we add complexity to this algorithm, then it will take us more time to search for working keys. Do you understand what I'm talking about? Not all key sets provide direct ring functions. Many key sets provide deferred ring functions and cannot be used as POWs. Our task is to find working keys and add them to the array of keys so that there are as many of them as possible (not 4, as I use in my videos for simplicity).
Therefore, your proposal to make even more complex what is IMPOSSIBLE difficult is meaningless. Absolutely.
If this idea really captivated you, then better let’s think about how to implement it. We can organize a project and create a new cryptocurrency, which will be for all people in the world. But to do this, we need funding. At least a little. I don’t know how much you need, but I need $ 500 per month so that I can work on the project. Otherwise, labor emigration to another country awaits me. I can not survive in my state. There is almost nothing here. Only one war and political butts of different politicians.
Let's just join forces and think about how to do it. Moreover, I have other solutions for Bitcoin. For example, I have a simple and elegant algorithm that allows me to solve the problem of the “BIG” blockchain, which is growing very quickly in any cryptocurrency. And things like that. If we implement them all in New Bitcoin, then this will be real Crypto_2.0.
Think - what can we do? This will be the best contribution of your precious time, I assure you.
And with this algorithm, everything is absolutely transparent and obvious. The XOR operation is one-way. That is - it is not reversible if you do not have starting numbers. Everything. There is nothing more to think about. No “weak solutions” can be found here. There is none of them.

[IadixDev]

If its to make a full coin, i can get into this, but also it needs block explorer, wallet etc and existing software for this will probably need to be modified as well to take in account the block signature format.

Im not sure how difficult it can be To adapt all the bitcore code for this algorithm, as blocks are also indexed with the block header hash, it probably needs changes in many places but i can look into this. Already got familliar with some versions of bitcore.

Sha256 has very high entropy, zero regression or anything it has non linear components to cascade and amplify all the source entropy capped with a mod.

I understand the problem with finding working keys as the number of rounds has to be found by brute force.

I still put my number crunching neurons at work on this one to find simple solution.

Sbox is just essentially a table look up, its not going to use lot of cpu power, but not sure if this can keep the cyclic property with the cypher implementation, but i believe similar technique can be used to increase entropy. With the sparx concept of large weak sbox it mean you can change it yourself and any weak sbox is supposed to keep the non linearity.

But adding entropy to break linear regression ( linear as in linear system) is not necessarily complex or it doesnt need lot of cpu power, the problem is to keep it cyclic, otherwise simple algorithm can works well.

With the few research i did so far, it doesnt seem that non linear function can be cyclic, because determined cycle period means its not non linear. Maybe its possible to find such non linear function that has at least bounded cycle period but didnt find this so far.

[flamehowk]

Sha256 has very high entropy, zero regression or anything it has non linear components to cascade and amplify all the source entropy capped with a mod.

Good. I think I understand what you don’t understand. Let's do so - I'll finish the code today and shoot the last video. Then I will post the video and my code. You will take one ring from this code, BUT + take my hash function Mystique to it and use it to mask the starting number.
That is, your sequence should be like this:
Take a weak starting number, for example - 0x1 (256 bit, like in SHA256)
We perform its hashing through Mystigue.
We calculate one ring through RBF.
You then pass this combination through your tests and see what they show you.
OK?

[IadixDev]

Sha256 has very high entropy, zero regression or anything it has non linear components to cascade and amplify all the source entropy capped with a mod.

Good. I think I understand what you don’t understand. Let's do so - I'll finish the code today and shoot the last video. Then I will post the video and my code. You will take one ring from this code, BUT + take my hash function Mystique to it and use it to mask the starting number.
That is, your sequence should be like this:
Take a weak starting number, for example - 0x1 (256 bit, like in SHA256)
We perform its hashing through Mystigue.
We calculate one ring through RBF.
You then pass this combination through your tests and see what they show you.
OK?

Oki Can do more testing adding the hash, im always up to cracking a good number sequence

[IadixDev]

I made some code to find all possible rings, and storing them in a csv file

it's all the combination i found : https://github.com/NodixBlockchain/rbf/blob/master/keylst.csv

Also made a thing to generate loops path randomly and run the forward/backward thing, it seems to work 

I did some more testing, testing more combination of rings it doesn't seem too bad But there are probably some combination that works better than others.

[flamehowk]

I made some code to find all possible rings, and storing them in a csv file
it's all the combination i found : https://github.com/NodixBlockchain/rbf/blob/master/keylst.csv
Also made a thing to generate loops path randomly and run the forward/backward thing, it seems to work 
I did some more testing, testing more combination of rings it doesn't seem too bad But there are probably some combination that works better than others.

Why did you spend time on this? This has already been done by me and it can be seen from my video. In addition, this is not necessary, because in this code 32-bit numbers will not be used, 256-bit numbers will be used there, and completely different keys are needed for them.

[IadixDev]

I made some code to find all possible rings, and storing them in a csv file
it's all the combination i found : https://github.com/NodixBlockchain/rbf/blob/master/keylst.csv
Also made a thing to generate loops path randomly and run the forward/backward thing, it seems to work  
I did some more testing, testing more combination of rings it doesn't seem too bad But there are probably some combination that works better than others.

Why did you spend time on this? This has already been done by me and it can be seen from my video. In addition, this is not necessary, because in this code 32-bit numbers will not be used, 256-bit numbers will be used there, and completely different keys are needed for them.

Just to do some testing but it seems ok but ok i wait for the full code

But it's not very long to compute, it took less than a minute to scan most possible value, even doing it four times with four different number to make sure there is no false positive.

Tested with many different combination of rings up To 1024 picked randomly seems To work

[tevador]

This idea is not new. Search for the "RSA timelock puzzle" - this is the most famous non-parallelizable proof of work. However, it only works when some central authority is generating the work. It is absolutely useless for decentralized consensus in cryptocurrencies.

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.

1. You need timestamps to adjust the difficulty of the PoW so you can keep an approximately constant block rate.
2. Even if you remove the timestamp and nonce from the block header, any miner can generate as many wallet addresses as they want to get unlimited parallelization.

[IadixDev]

2. Even if you remove the timestamp and nonce from the block header, any miner can generate as many wallet addresses as they want to get unlimited parallelization.

Only one address will get the reward, and they cant work in parallel on the same chain, no ring chain can advance faster with parallelisation. They can compute differents ring chain in // with different address, they will all take the same time to compute, and only one reward, so there is no huge benefits To that. ( if i get it right )

The issue with the address spamming can become a problem to distribute the work across different miners, but even if there is address spamming, they will still have same cost/hash To compute the ring for each address, and everyone can address spam as well, so i think its solvable. In any case it comes back closer To 1 cpu one vote, even if someone with many addresses could get more work and reward in a pooled work, even with a single cpu, the number of cpu doesnt matter.

This idea is not new. Search for the "RSA timelock puzzle" - this is the most famous non-parallelizable proof of work. However, it only works when some central authority is generating the work. It is absolutely useless for decentralized consensus in cryptocurrencies.

There are many problems that can be solved only throught recursion, but its not cyclic like this, so it needs the solution to be known first, then puzzle made from it, for system like this where the solution is known first there are many way to have proof of work, but here the solution is not known first, but the work can still be verified in one step.

[tevador]

they will all take the same time to compute

Then it's not progress-free, which is a fundamental requirement for decentralized proof of work. PoW that is not progress-free will not work in practice because it encourages selfish mining, i.e. each miner will mine their own chain to avoid the network latency delay.

[IadixDev]

they will all take the same time to compute

Then it's not progress-free, which is a fundamental requirement for decentralized proof of work. PoW that is not progress-free will not work in practice because it encourages selfish mining, i.e. each miner will mine their own chain to avoid the network latency delay.

Its a problem i pointed before, but not sure it cannot be solved. I didnt see a full solution for this, but in theory it should still be possible to force a break down of the work, like forcing each ring to be computed with a different address, as it can still be broken into small pieces and the proof still need all the work to be done, and the minimal unit of work is very small, so maybe it can still be forced into small bits including network latency.

I still dont see a perfect solution for this, but i think it can be worked around. I think if a way To make poisson like distribution on the address or miner id can be found, it can replace the progress free problem up stream by forcing a break down of the work, it require zero initialisation time , and the minimal unit of work can be very small, so i think it would be equivalent. It still have same property than any miner id has equal chance to get a reward even with small computational power, even if it needs another mechanism to distribute the work than the pow itself.

It could be a system similar in some aspect to ourobos in cardanno, even if the difference is cardanno works with POS so the reward is related to the stake power of an address, and here the reward distribution would be more based on a "proof of miner id" than the pow itself, but then anyone with even small cpu power can participate and have equal chance to get reward with other miners, and its less vulnerable than POS to long range attack with the nothing at stake problem, even if i cant see a good way To avoid penalising miners with high network latency, without ending with problems if a node in the mining chain stop responding or have high latency to compute his part of the work.

Another potential problem i see is that the total pow is not going to scale with the number of miners, the amount of work to do to solve a full block will stay constant for a given block target, which will limit the maximum number of miner that can get a reward for a given block, so there is lower probability for a miner to get a reward in short time on a large network with lots of miners.

There are certain number of issue to study well, but i dont think its completely unsolvable even if it would more thinking and few more mechanism for it To work Well in practice.

[tevador]

If you make the unit of work small, you will achieve progress-freeness, but you will lose non-parallelizability. "Proof of miner id" is susceptible to sybil attacks since you can't limit the generation of new addresses without some central authority.

In short, there is no way to distinguish many small miners from a single entity mining in parallel with many addresses.

I spent a fair bit of time researching this myself and I'm pretty sure it's a dead end.

[IadixDev]

If you make the unit of work small, you will achieve progress-freeness, but you will lose non-parallelizability.

Why ? If each unit of work depend on the result of previous work, it's still non parallelizable ?

"Proof of miner id" is susceptible to sybil attacks since you can't limit the generation of new addresses without some central authority.

In short, there is no way to distinguish many small miners from a single entity mining in parallel with many addresses.

I spent a fair bit of time researching this myself and I'm pretty sure it's a dead end.

Even if already it get to the point of not being able to distinguish many small miners from a big entity, they will still all mine with equal work-cost, which is already a win as i see it And its possible to find way to prevent it to a degree, or make it harder to do.


The principle in itself could be close to some onion routing as each node re encrypt the previous message, except it cycle back to the original point after a certain number of rounds. It would need to establish a route through nodes to compute all the work sequentially, adding their address to the computation.

But maybe the OP has a solution to this   need to wait a bit for updates

[tevador]

Why ? If each unit of work depend on the result of previous work, it's still non parallelizable ?

Then it's not progress-free. The miner who starts first will always solve the block, which is not what you want in a decentralized cryptocurrency.

Even if already it get to the point of not being able to distinguish many small miners from a big entity, they will still all mine with equal work-cost, which is already a win as i see it And its possible to find way to prevent it to a degree, or make it harder to do.

No, the large entity will mine more efficiently using many parallel calculations. The standard progress is: CPU -> GPU -> FPGA -> ASIC. On the blockchain, it will look like many small miners claiming the block reward, but in reality there will be no decentralization.

[IadixDev]

Then it's not progress-free. The miner who starts first will always solve the block, which is not what you want in a decentralized cryptocurrency.

It's not progress-free, but the work can still be distributed on different addresses, selected evenly for each block. In the end it still have same property than progress-free work for decentralization of the mining. But it needs another system to distribute the work than the pow itself.

[tevador]

My main point is that you cannot have a permissionless proof of work system that's not parallelizable.

[IadixDev]

My main point is that you cannot have a permissionless proof of work system that's not parallelizable.

Really ? you have link to a book or paper explaining this ?

[tevador]

In case it was not clear from the conversation above, I'm posting an informal proof:

If an algorithm is progress-free (or memoryless), the distribution of time between solutions must be exponential (since it's the only memoryless distribution), i.e. the probability of finding a solution at time t < T is:

Code:

P(t < T) = 1 - exp(-C*T)

for some constant C, which equals to the relative computational power.

If I have two equally powerful machines, then the probability that I find a solution at time t < T if I mine with both of them is:

Code:

P2(t < T) = 1 - (1 - P(t < T)) * (1 - P(t < T))
          = 1 - exp(-C*T) * exp(-C*T)
	  = 1 - exp(-2*C*T) 

    
which is exactly the same as the probability for a twice more powerful machine.

So progress-freeness implies perfect parallelizability.