Increasing the survival chances of a sha256 hard fork

[freetrader]

@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.

 

[nmag]

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.

That's exactly the point. There should be no change on the consensus rules for the sha256 headers (appart from the resetting the difficulty obviously). However, for a block to be accepted it must come with the 2nd POW, whose difficulty is derived from the sha256 difficulty. There is no need for the sha256 or secondary headers to form a chain with the previous secondary header. Just the hash of the current block is enough, since the "chaining" is established on the sha256 headers.

It's exactly like anti-spam protection with hashcash. The email client says: if you want me to accept your email, provide me some POW. Similarly, a miner mining the fork says: if you want me to build on top of your block, you have to provide me enough secondary POW and a valid sha256 header and a valid block.

 

[johnyj]

I think PoW in general does not solve the centralization of mining problem: If you are a bank that can print unlimited fiat money, you could always buy majority of the mining infrastructure with a pocket change (of course you don't do it as a single entity), so the centralized control is unavoidable

Banks did not care about bitcoin from the beginning because it was just a small computer game. But if it really becomes significant, then acquisition of mining farms will become the new norm, ASIC farms, GPU farms, it doesn't matter

So I think it might be a time to give up on PoW and switch to PoS. Anyway in a spin-off fork, the only one you care is the previous bitcoin owner, so why don't use PoS to keep their support?

 

[freetrader]

Who has miners gathering dust and would be willing to turn them on and point them at our bitcoin spinoff? #MineBitcoinAgain

This is a just a survey - not an announcement of impending tests or active fork mining... but please let us know so that we can get an idea of how much % of hashrate might back a SHA256 fork attempt.

We've been discussing what kind of hashing power we can gather just from old ASIC miners that have been turned off because they are no longer profitable.

We'd like to see how much hashing power you have if you would be willing to point it at a bitcoin spinoff. Please post on here OR twitter to let us know so that we can tally it up.

We don't expect to get everyone involved at this early stage and most forum users are lurkers anyway but it might be interesting to see.

Spread the word on twitter with the handle #MineBitcoinAgain.

 

[79b79aa8]

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.

how to determine the level of ASIC resistance of the secondary, non SHA256 POW?

 

[cbeast]

Decentralization is not distribution. Decentralization is permissionless competition. It doesn't matter what the algorithm is or who is competing as long as it remains a permissionless Game of Thrones.

 

[greatwolf]

Here's a case-study for Megacoin on what happens when an entity w/ too much hashing power floods the network with it: https://forum.megacoin.co.nz/index.php?topic=893.0. The subsection "The History of the Gravity Well Mining Difficulty Readjustment Algorithm" is particularly relevant.

To me it's obvious careful thought has to be put into how we do diff retargeting. Don't let it turn into another instance of Ethereum's replay attack -- a problem that could easily be anticipated for but no one cared enough to put forth a plan to mitigate it.