Below is a summary of HF24  work by BlockTrades team in the past week:

# Hived work

The witnesses have continued to create testnets to test hived. No major issues were discovered so far. There’s still one big test to be completed, which is to operate a testnet where transactions are injected from the mainnet using tinman.

Some minor issues were discovered and/or fixed:

@howo fixed the uint32 overflow problem that caused a minor progress reporting problem during sync: https://gitlab.syncad.com/hive/hive/-/merge_requests/108 

Also, @gtg identified a post-HF problem: nodes with a different chainid will reject connections from a node reporting a different chainid, and this would cause problems for unsynced Eclipse nodes connecting up to the network after the HF, where the chainid has changed on synced eclipse nodes. There’s two fairly simple solutions to this issue: 
1. the simplest, would be to create a new version of Eclipse for syncing up post-HF that contains the new chainid.
2. alternatively, we can add a command-line option and/or environment variable that allows the node’s chainid to be specified at startup. In this case, eclipse nodes connected before the HF time would use the old default chain id, and swap to the chainid at HF time, and eclipse nodes connected after the HF time would be launched with new chain id.

It’s still under discussion, but I think we’ll probably employ both solutions. We’ll add a command-line option for specifying the chainid, since this can also be useful for specifying multiple testnets with different chainids in such a way that a node doesn’t need to worry about accidentally connecting to the wrong testnet. And we’ll also produce a new version (e.g. 1.24.1) after the HF, that defaults to the new chainid, so that node operators won’t need to continue specifying the new chainid on the command line in order to connect up to the mainnet.

# Hivemind work

Most of our work last week continued to focus on hivemind. 

We implemented reputation calculation in hivemind last week, but we consider the current implementation to be too slow during the initial hivemind sync process, so we’re still looking into ways to speed up the calculation.

Another big task currently underway is a new notification algorithm (i.e. notifications about when an account receives a vote, rehive, or mention). The old notification algorithm was broken during the switch to the Eclipse version of hivemind and during investigation we found that the old version seemed to use excessive storage space, so we’re trying a new algorithm that generates notification information on demand instead of constantly updating it for all accounts.

We completed a second “full sync” of hivemind today (these tests take 4 days to complete) and found another problem in the post-sync fixup of the database, which we’re fixing now.

Finally, we continue to optimize the code, create more API tests for hivemind, and fix small discrepancies between the old version of hivemind and the Eclipse version as we find them:
https://gitlab.syncad.com/hive/hivemind/-/merge_requests/108 
https://gitlab.syncad.com/hive/hivemind/-/merge_requests/109 
https://gitlab.syncad.com/hive/hivemind/-/merge_requests/111 
https://gitlab.syncad.com/hive/hivemind/-/merge_requests/112 
https://gitlab.syncad.com/hive/hivemind/-/merge_requests/113 
https://gitlab.syncad.com/hive/hivemind/-/merge_requests/103 
https://gitlab.syncad.com/hive/hivemind/-/merge_requests/110 
https://gitlab.syncad.com/hive/hivemind/-/merge_requests/116 
https://gitlab.syncad.com/hive/hivemind/-/merge_requests/120 
https://gitlab.syncad.com/hive/hivemind/-/merge_requests/124 
https://gitlab.syncad.com/hive/hivemind/-/merge_requests/126 

The hivemind tests themselves are being updated here, but I've omitted the full list of changes for brevity:
https://gitlab.syncad.com/hive/tests_api/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged

# Hardfork release date and plans for upcoming week

While hived seems quite stable, we’re still working on hivemind, so we’re not yet able to provide a full API node that apps developers can use to test against. I think that we need to give apps developers at least a full week to test against an Eclipse API node, so we’re setting the hardfork date to 22nd, as we don’t think we’ll have a full API node (i.e. hived + hivemind) ready until at least next week.

We’ll likely be tagging an official 1.24.0 release of hived either tomorrow or the day after with the updated hardfork date, assuming the code for setting the chainid at startup works as expected. Witnesses and exchanges will be able to deploy this upcoming version on the mainnet, although full API nodes will still need to use the current release version of hived until the Eclipse version of hivemind is ready.

Although we are setting the hardfork date to the 22nd in hived 1.24.0,  it’s still possible that the date may need to change again, if hivemind work isn’t completed next week. In such case, we would tag a new version of hived with the updated hardfork date. But this should not pose any major inconvenience to witnesses or exchanges who’ve already updated to hived 1.24.0 if it happens, since no blockchain replay would be required.