Minimum viable PoW change

[luke-jr]

This adds the ability to define a PoW change to any of SHA256 (not double), RIPEMD160, or "Hash160" (SHA256+RIPEMD160). It is intentionally flexible such that other, more realistic options can be added without making a final decision until the last minute (to prevent anyone getting a head start on ASICs).

The hardfork will also trigger an immediate drop of the difficulty to about 0.0001% (target is shifted left by 2²⁰) of its previous level. (This is a guess based on comparing pre-ASIC to post-ASIC network hashrate, not a final decision.)

---

CBlockHeader::GetHash uses Consensus::Params to decide what hashing algorithm to use. Once the hardfork has completed, this can be cleaned up nicer.

The 10 blocks after the first non-SHA2 block are limited such that their timestamp cannot precede the hardfork-defined timestamp. This shouldn't have any real effect, and can also be removed once we get past the hardfork.

---

For testing, regtest is configured to rotate between the total of all four (ie, including SHA256d) algorithms.

(No PoW change is defined for mainnet or testnet in this PR.)

[luke-jr]

Trolling will not be tolerated. Review is welcome.

[luke-jr]

@highriser This is just the basic framework for a PoW change. It doesn't define the algorithm itself, which should be decided last-minute if we move forward with a PoW change.

However, ASIC-resistant is NOT a good attribute for a PoW algorithm. ASIC resistance simply means making the ideal ASIC is harder, and therefore a monopoly once someone does it. For example, SHA256d with ASICBoost is an example of an ASIC-resistant algorithm - that's half the problem with our current situation.

Instead, what we should be aiming for is either a readily-available ASIC (eg, a truly memory-based algorithm, which doesn't exist to date), or at least an algorithm for which the best possible ASIC is simple and straightforward to produce, so it is easy to compete in the production of it (and therefore hard to monopolise).

[mariodian]

Hey @luke-jr have you looked into PoWA (proof of work additions)? Do you think that's a viable mechanism to change the PoW?

[luke-jr]

@mariodian I don't believe it has been studied sufficiently, and I suspect it is vulnerable to some attacks. I would be interested in discussing these risks, but the proper venue for that would be a new issue, or perhaps on IRC/Slack.

To all: Please do not use pull requests for questions. These are meant for code review. Instead, open an issue if you have a specific idea (or a new pull request if you can write the code for it; it doesn't need to be perfect code!), or join the Bitcoin Core community slack's #UASF-WG channel for real-time discussion (please use the normal #UASF channel for simple questions).

[nukebloodaxe]

utACK : it appears as though it will do what it is supposed to do, I will need to become more intimately acquainted with the code and the overall operation of the classes concerned, though. Be aware I am very rusty with C++ code; like two decades rusty.

[GratefulTony]

Concept ACK:

Looks like you are using wall time to determine the POW algorithm to be used... Is there a reason for doing this instead of using the blockheight? Also, is the intention to actually use rotating POW, or is this just a testing idea? If the former, do you have an idea about what would happen if there were dramatically different hashrates on the various POWs?

It would seem this causes the dominant hash algo to always pick up the block after the dormant ones expire/timeout/rotate out... Is this the design intent?

[luke-jr]

Block height isn't part of the (current) header, so isn't known here.

Rotating PoW is strictly for testing purposes. Having multiple active PoW algorithms has a lot of unaddressed adversarial issues. If someone wants to do the R&D for this, we could consider it, but I'm not planning to.