[Hard-Fork] Implement time-activated "protocol cleanup" flag-day hard-fork, set to activate in April 2021

[maaku]

To achieve desired scaling limits, the forward blocks architecture will eventually trigger a hard-fork modification of the consensus rules, for the primary purposes of dropping enforcement of many aggregate block limits and altering the difficulty adjustment algorithm.

This hard-fork will not activate until it is absolutely necessary for it to do so, at the point when real demand for additional shard space in aggregate across all forward block shard-chains exceeds the available space in the compatibility chain. It is anticipated that this will not occur until many, many years into the future, when Freicoin/Tradecraft's usage exceeds even the levels of bitcoin usage ca. 2018. However when it does eventually trigger, any node enforcing the old rules will be left behind.

Since the rule changes for forward blocks have not been written yet and because this flag-day code doesn't know how to detect actual activation, we cannot have older clients enforce the new rules. What is do instead is that any rule which we anticipate changes becomes simply unenforced after this activation time, and aggregate limits are set to the maximum values the software is able to support. After the flag-day, older clients of at least version 10.4 will continue to receive blocks, but with only SPV security ("trust the most work") for the new protocol rules. So starting with the release of 10.4, activation of forward blocks new scaling limits becomes a soft-fork, with the only concern being the forking off of pre-10.4 nodes upon activation.

The protocol cleanup rule change is scheduled for activation on 2 April 2021 at midnight UTC. This is 4PM PDT, 7PM EDT, and 9AM JST. Since the activation time is median-time-past, it'll actually trigger about an hour after this wall-clock time.

This date is chosen to be roughly 2 years after the expected release date of official binaries. While the Freicoin developer team doesn't have the resources to provide strong ongoing support beyond emergency fixes, we nevertheless have an ideal goal of supporting release binaries for up to 2 years following the first release from that series. Any release of a new series prior to the deployment of forward blocks should set this to be at least two years from the time of release. When forward blocks is deployed, this parameter should be set to the highest value used in prior releases, and becomes the earliest time at which the hard-fork rules can activate.

Fixess #19 .

[kallewoof]

I had so many comments that github thinks it's a good idea to collapse them, so make sure you decollapse where it says "17 more". :P

[kallewoof]

I made comments in various places. Unfortunately git thinks they're all outdated. I'll go through the code again after squash and repeat in places (so if you chose to not do something I suggested, feel free to ignore any such comments; it's not me being insistent).

[maaku]

Tx 0 (coinbase) -> x (= issuance token for asset A) Tx 1 (same block) x -> y (and issue some A) Tx 2 (same block) y -> (return as fee to the coinbase)

In this example the miner creates an output in his coinbase of an asset he has no right to own, which is an issuance token for another asset. He then uses it to issue the asset, then returns the issuance token to the coinbase as fee. From the block’s perspective the coinbase didn’t generate anything which wasn’t given to it as fee, but that extra issuance token does exist for the duration of the block.

Alternatively, the miner issues a bajillion coins to himself, gets to use them for the duration of the block, before returning them all back to himself as fee. By itself this isn’t useful, but if there was another undiscovered overflow bug it could be catastrophic.

In short, the issue is that the miner can print money that shouldn’t exist, use it for the duration of the block only, and then return it in a time traveling payment back to himself at the end of the block, as fee. This should probably be outlawed just for being weird and unexpected, but could actually cause problems too with new features (asset issuance) or undiscovered bugs (overflow).

Requiring 1 block maturity for coinbases prevents this.

On Feb 25, 2019, at 9:10 AM, kallewoof notifications@github.com wrote:

@kallewoof commented on this pull request.

In src/main.cpp https://github.com/tradecraftio/tradecraft/pull/26#discussion_r259711450:

@@ -1472,14 +1483,16 @@ bool CheckInputs(const CTransaction& tx, CValidationState &state, const CCoinsVi

         // If prev is coinbase, check that it's matured
         if (coins->IsCoinBase()) {

• if (nSpendHeight - coins->nHeight < COINBASE_MATURITY)
• if (nSpendHeight - coins->nHeight < (protocol_cleanup ? 1 : COINBASE_MATURITY)) Wait, so this ends up checking the single case where the miner creates a coinbase output, and then immediately spends the coinbase transaction inside the block itself. I.e.

tx 0 (coinbase) -> x tx 1 (same block) x -> y ? I have no idea why you even care about that, as I believe coinbases can have multiple outputs as it is (so doing tx1 above is literally pointless, if maturity = 1).

That aside, I at least understand what the code is forbidding now, even if I don't really understand the "why". :)

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/tradecraftio/tradecraft/pull/26#discussion_r259711450, or mute the thread https://github.com/notifications/unsubscribe-auth/AAEOIm-T6y84Y8v7NrkVJLpBaay5qBFAks5vQ5pmgaJpZM4bHNGx.

[kallewoof]

Ahh, I didn't think about issuing and using inside the block like that. Makes sense.

[maaku]

Rebase to most recent rebase-0.10 target branch, and squashed commits in the process. The combined diff is the same.

Verify with:

git diff a33f174..5d9271f >a git diff 2d6203e..ba13908 >b diff a b

[maaku]

The NOTEQUAL and NOTEQUALVERIFY opcodes were removed from this pull request since the underlying protocol cleanup code has matured while the opcode stuff has received little review. There will be a separate pull request to add these features, which are a soft-fork on top of the existing protocol-cleanup fork.