Topic: **** Solution for biggest security problem of pow, 51 attact, Safe Proof of Work (Read 233 times)

https://raw.githubusercontent.com/onuratakan/SPOW/main/What%20is%20the%20SPOW.png

I have released a new update that includes what will happen if the consensus breaks, now the miners will move from complexity to order when the consensus breaks. This way, in the next try, honest miners will agree on a block as a majority. Attackers, on the other hand, will most likely leave the game as they do not bear the costs.

Someone enlightened me about mining pools and this consensus algorithm, I prepared a pdf with a solution for it and sent it to the repo, Please help to disseminate and discuss this idea.

Thanks and best regards

Thank you very much for your comments.Since the only goal of the attacker will be to impose the chain attacker has changed to the network, if the miner cannot ensure the dispersion rate, the transaction she made will appear.
The purpose of this algorithm is basically if there is a confusion, that is, if the miners are arguing between the two chains, it draws a roadmap according to this situation and if one wants to make a 51 attack, it gives the possibility to lose all their money.


We need some more expert people
we need to share for this

A very good and honest miner that was not informed yet that a new block was mined will have his own chain with different last block. Or it can happen that 2 miners find a block in the same second and since both are relaying that, some will pick chain 1, some will pick chain 2. The "correct" chain will be the one with the fastest new next block.

Satoshi knew that you cannot rely onto the stability of the internet and his solution works great.
Bitcoin handles this by considering the longest chain as good. You seem to not care about this.


And what if the attacker broadcast his findings only when he knows that his chain is the longest?


As I said, unless I misunderstood something, all you do is confuse (more or less) the honest miners while not preventing anything related to 51% attack.
But maybe I missed something, so I'll wait for others' replies too.

Firstly thank you for your reply, Well, there is a situation like this, shouldn't the bad miner add his own chain by finding it in the last block?

In this case, the block structure is asking for two hash fields to occur, if the malicious miner has a lot of power (85% or bigger), when the largely bad miner finds one, the other honest miners will find one (because the malicious miner is the result of the randomness of the honest miners while working on one. some of them will work on the other hash), and when other miners find one, if the chain merkle roots of hash1 and hash2 are not equal, so both are not thinking on the same chain, it creates a mess, and this mess might seem like a normal process, but this protocol encourages to block it that is, keeping the network on the same blockchain as much as possible, trying to prevent a fork from occurring, and since the majority of miners will not be getting incentives if they are not on the same fork, the miners will be compelled to support the same blockchain and change them for that blockchain, and if the vast majority of each miner audience agree on the same fork, then They will have developed immunity against future attacks.

You seem to be forgetting that even honest miners can have short-lived chain splits now and then, it's a normal process, still, as soon as they find out of a longer chain they go there and the wrong chain is forgotten.
And I think that you are confusing attacking with the actual mining.

The attacker will not care about the others' consensus rules, he will go on on his own chain. He did not break any visible rule, he will add transactions to his own chain by the same rules. So as long as the attacker started from a valid block and goes on adding valid blocks to his own chain, in the moment it has the longest chain, he won and he will cause the shorter chain get "forgotten".



Your solution seems to mostly confuse honest miners than solve a problem (which should occur only in the low hashrate coins anyway).

If you look at the pdf on the link I gave information about a sample situation and the consequences of the situation.

This is not important, If you want to attack, you need to find the hash of the last block faster than anyone else, but this consensus allows you to find one hash on other honest miners even if you find it (if you cannot predict the dispersion rate of honest miners with high accuracy, you will find one in the time you will spend, but in other miners during that time Because they deal with hash, they get ahead of you and they find one) and if they find one on the other side, the attacker will contradict the blockchain you want to spread and the whole network will go into the process of finding a new hash, so your expense will be of no avail.

First ıf there is no attacker, if all miners are honest, a different chain will not appear anyway, all miners that solve hashes will send the same merkle root blockchain. Why do I add the blockchain merkle root because when I add honor, I can compare the blockchain miners will send (it doesn't matter bad or good), so if someone wants to add a different chain, i.e. if they want to cheat the network, I can detect it and start the process again.


Second be careful why I start it a second time, if the hashes of the miners are different from the blockchain merkle roots, the consensus is broken and in this case I prevent the block addition and start the process again, so if an attacker does not make the correct guess, that much expense will be wasted, here is the problem, how is the same hash two times they find it directly copy and paste. To prevent this, I add a text to the hash algorithm in consensus breakdowns, so there are two new hashes that can be found.



lastly the likelihood of the attacker's fending off process failing is that if the attacker cannot predict with great accuracy which hash other miners will solve, in all probability other honest miners find at least one hash, and the consensus is broken because the merkle root of the hash of honest miners and bad miners do not match, in this case The entire cost of the attacker was rubbish, this is a very dangerous rate, it is very difficult for the attacker to reach this randomly adjusted rate

OK, so let's say I want to go on with an attack and I have the computing power for it. Incredibly huge computing power.

I choose an existing block (10 blocks back in history) to start with. And I don't care that there are 2 hashes, I always pick the first. After certain time I reach to a longer chain than the official, hence the consensus will choose my chain to become the official one. I have just succeeded a 51% attack and I didn't care at all that there are 2 hashes there.

What did I miss?

The way you explain it is like differing the "honest miner" with the "attacker". If the attacker can't change an old block and then work on extending the chain, then how the honest nodes verify the chain? As for the merkle root, what exactly do you mean, I don't get you. Two different merkle roots? Why? This means different transactions, which doesn't make sense.

So they add 09ff5c75b871c0687e04e08952d9b0d494cd36b56edf776ae0b02323d067707e and then restart mining? Can you explain that too?

Okay. What prevents an attacker from changing a transaction x blocks deep. The randomness you describe doesn't solve this problem as long as the attacker simply starts mining no matter the new blocks that are coming.

I am use two hash because ı had to miss the target, however, the attacker should not have known how much mining was working on which target (first hash or second hash). I can build this structer with random selected. Each miner randomly determines the hash (first or second hash) miner wants to solve.

Hello, ı am explain for you. Two hash system not effect without random, because if attacker know miner/hash rate attacker is win, but if not know (with random (miners select hash with random mechanic, anyminer work on the first hash or second hash)) attackers can not attack because, if not know, most probably end of mining procces, the honest miner find one hash (first hash or second hash) and attacker find one hash, this situation first hash merkle root and secon hash merkle root is not equal, so consensus is breaked, and nodes add the hash algorithm sha256("breaked consensus") and restart mining, lastly as you can see attacker loser. Sory for my english =)

This seems interesting, I'm watching it from now on. I want to read the replies too. On your whitepaper you say that the method is consisted from a block that contains two hashes. Can you clarify me why there should be exactly two and not more to improve the security?

Also, let's assume that the attacker (with the 51%) wants to remove a transaction 100 blocks deep. I haven't understood how he'll fail on his try. He will work on changing the older blocks and the new ones as well. The new blocks that will have two different hashes won't affect the old ones.

Solution is basic, the new consensus algorithm Safe Proof of Work, blocks will have a two hash block, and miner select from random, first hash mining or second hash mining. this is changed all mining proccess. And add into the hash, the merkle root of the blocks of the blockchain the miners wants to add. If first hash blocks merkler root not equal second hash blocks merkle root, all nodes and miners restart process.

If you want to know more, you can check the my github repository. (https://github.com/onuratakan/SPOW ) I published with mozilla public license.