Both problems can be fixed by changing my protocol rule from honest chain's next block must include the nominations from any that occurred in the 6 second window to honest chain must include the nominations from all block solutions that occurred (with the same difficulty). Thus the difficulty has to be calculated counting all block solutions.
Thus chains can't diverge, except if they disagree about the difficulty. The objectivity about difficulty is a combination of using very long periods for the calculation so that difficulty is the same in calculations that differ only in small changes in the blocks included can't result in half or double the difficulty (since difficulty increments are a factor of 2 since they are the leading bits of the PoW with a 0 value),
Why don't disagreements in the set of all nominations cause the same forking problem that would occur with a fixed time window?
Astute question.
(also glad you found my last post, I was intending to message you but I haven't opened my PMs box yet and have 16 msgs to deal with there...)
The nominations don't take effect immediately. The nominated verification nodes can't begin verifying until a certain number of blocks announcements. Thus rendering irrelevant any recent PoW chain ambiguity over nominations (said ambiguity due to the last block included in any count of announcements may have disagreement due to propagation). There is still the issue of conflict (even though the conflict is displaced in time, it is still there) if there is disagreement over the nominations in set of blocks in the count. This is fixed by choosing the greater set of any alternatives where the displacement in time allows propagation to be unambiguous and for the set of alternatives to be well defined and stable. See why I have sometimes alluded to my design being an anti-aliasing method for PoW. Again we see that my conceptual insight from 2014 on how to defeat selfish mining is always the way to resolve ambiguity by being inclusive of all block announcement state (and my key paradigm shift that nominations are additive and can't conflict, i.e. I used the concept of separation-of-concerns in order to move the double-spend threat to an orthogonal concern so it gets out of the way of consensus).
Also I had mentioned that to defeat the 49-99% game theory attacks on the predetermined entropy (coming from chain history) of the quorums (very similar to Dash Evolution's quorums except as I previously noted I believe Evolution has design flaws), the nominations are not changed until every verification node has been the designated node for at least one block. This makes it sure that even if a payer's transactiont is rejected by all quorums (the quorum for a UTXO will change every block or after every N blocks) due to the attacker controlling 49 - 99% of the verification nodes, then the payer can alternatively (the designed node for each block is an optional choice for the payee) still get his friendly verification node to be designated (by waiting for the round-robin) so he can push his transaction onto the block chain in a permissionless paradigm even against a 99% PoW attacker! Amazing! I proud of that aspect of the design. And without incurring the flaws and downsides of PoS.
Also because the side-effects of nominations of verification nodes is accumulative and can't conflict, unlike the double-spends that can conflict with different relative perspectives on which PoW chain is valid. Verification nodes can't create double-spends (other than due to conflicts in the PoW chain which I resolved as I already explained as per the above). Explaining in more explicit detail beyond this would require revealing virtually all the finer details of my design and implementation, so I will withhold for now. But I think I have already spilled the beans for any astute implementator can now duplicate my design.
Also, isn't adjusting difficulty by factors of 2 is in danger of increasing the volatility of the currency? The cost of production will double or halve rather than smoothly increasing/decreasing as it does in bitcoin.
Keeping the difficulty in alignment (as required by my design's way of eliminating conflicts by merging all chains) is perhaps one of the areas to look for a potential flaw in my design. I haven't expended as much effort yet thinking about that aspect.
One of the attacks a 49 - 99% attacker can do is to mine sporadically which in Satoshi's design can wreck havoc on the block period variance. That is why I said the block difficulty adjustment will be calculated over a very long window. And remember this amazing insight... that is that since transaction confirmations don't slow down when block period does, my design doesn't have any problem with block period variance!
Remember the cost of production affects the attacker, not the payers who will be mining without care for cost. The debasement rate will be a very small annual % maybe even less than 0.5%. So the economics of the debasement are irrelevant. The only reason to have any debasement (other than the macroeconomic arguments of Gresham's Law), is to countervail the incidence of lost private keys. Bitcoin after 2032 will eventually shrink to a 0 money supply due to lost coins. In a microtransaction world, users will lose coins quite frequently due to abandoning small balance accounts.
Edit:
What I expect to remain the generative essence is that any rule of containment that contains everything that can contain itself (and note I need to correct what I wrote in the post to this improved wording) that does not leak in the type of the computation model employed, would need to be so rich as to model everything that can be modeled, and thus can't exist because the world is open to unbounded composition.
Tangentially I believe
my improvement to Satoshi's design essentially hinges on the similar kind of paradigm shift where the containment test for double-spends shifted to an orthogonality via a separation-of-concerns.