Very interesting discussion in this thread. I think I understand both the goals which Forp tries to achieve and the reasons for it.
One possibility to include badly parallelizing serialization into the Bitcoin would be to request that each step of PoW depends on the previous one.
Example of the idea (unusable for real usage):
To find a block (PoW):
1. Set initial hash H0 = SHA256([ block header ] )
2. Perform following serial steps:
3. Let Hn+1 = SHA256([Hn | Kn]), where each Kn is randomly chosen
4. When Hn is lower than difficulty, stop, solution is found, store nonce and all Kn ;-)
By [a | b] I mean concatenation of the blocks a and b into single message.
Thus, even if I own 4 computers, they will compete each against other and will not help me to find more blocks in given time frame.
Of course, there is big flaw in the above - verification of block requires the same time as took to find the block, plus one needs to store all Kn chosen. But its an idea that came up. Feel free to improve on it
.
One possibility to include badly parallelizing serialization into the Bitcoin would be to request that each step of PoW depends on the previous one.
Example of the idea (unusable for real usage):
To find a block (PoW):
1. Set initial hash H0 = SHA256([ block header ] )
2. Perform following serial steps:
3. Let Hn+1 = SHA256([Hn | Kn]), where each Kn is randomly chosen
4. When Hn is lower than difficulty, stop, solution is found, store nonce and all Kn ;-)
By [a | b] I mean concatenation of the blocks a and b into single message.
Thus, even if I own 4 computers, they will compete each against other and will not help me to find more blocks in given time frame.
Of course, there is big flaw in the above - verification of block requires the same time as took to find the block, plus one needs to store all Kn chosen. But its an idea that came up. Feel free to improve on it
.If you have 4 computers you can test 4 different Kn at a time -> 4 times the chance of finding a winning nonce.