- Dec 16, 2015
- 2,806
- 6,088
@nmag : It's an interesting proposal you made, and it made me think a bit more about it.
I suppose any additional POW algorithms could be accomodated by "blending them" into the existing proof of work using something like a simple XOR with current POW and a deterministic RNG seeded by block hash and the probability required according to your concept of "some fraction".
Being separate POWs, the crux lies in tracking their difficulty correctly. If it were easy to compute it as a derivative of the standard POW difficulty, we could just re-use the data that's already in the blocks.
Otherwise, it would require new field(s) in the block, which would be a greater change.
I've proposed before that one could invert the output of the first SHA256 before doing the second hash in the SHA256d. This could be done intermittently at a frequency similar to your "fraction" as needed, and I wondered if this could be useful to thwart attacking ASICs.
I think it wouldn't be, because it's such a trivial change to make also in hardware.
That's why I find your idea of using different POW but mixing them in quite attractive for a fork which doesn't entirely want to throw away the SHA256 investments.
I suppose any additional POW algorithms could be accomodated by "blending them" into the existing proof of work using something like a simple XOR with current POW and a deterministic RNG seeded by block hash and the probability required according to your concept of "some fraction".
Being separate POWs, the crux lies in tracking their difficulty correctly. If it were easy to compute it as a derivative of the standard POW difficulty, we could just re-use the data that's already in the blocks.
Otherwise, it would require new field(s) in the block, which would be a greater change.
I've proposed before that one could invert the output of the first SHA256 before doing the second hash in the SHA256d. This could be done intermittently at a frequency similar to your "fraction" as needed, and I wondered if this could be useful to thwart attacking ASICs.
I think it wouldn't be, because it's such a trivial change to make also in hardware.
That's why I find your idea of using different POW but mixing them in quite attractive for a fork which doesn't entirely want to throw away the SHA256 investments.