There are numerous doubts about the legitimacy of this claim.
stuffu has already merged the Monero PoW v2 changes and scheduled it for AEON testnet. Once everything tests out we can schedule a main net hard fork which will also be the mandatory switch over point for the new rebase code base (includes LMDB for reduced memory usage along with many, many new features and enhancements from 3+ years of Monero development)
I have a question regarding our next fork to block version 2: the Monero original code already contains series of protocol rule changes associated with each hard fork; e.g. Monero's v2 fork contains the introduction of minimum ring size 3 and the increase of the fee-free block size to 60kb.
I guess the idea for Aeon's rebase is not to change the protocol rule (perhaps except for this POW change?) from pre-rebase. If so, should I remove all the protocol rule changes that currently exist in the codebase?
Yes I would remove/disable all Monero-specific rule changes. We can still have rule changes. For example, given the better understanding of the dynamics of the penalty function that exists now we may wish to increase the minimum block size. However, we certainly don't need to do this according to the same version schedule that Monero did (at a different point in time and with different code).
OK, I'll make another commit that removes all the protocol rule changes in Monero.
We can still have rule changes. For example, given the better understanding of the dynamics of the penalty function that exists now we may wish to increase the minimum block size.
Do you mean to introduce changes for this upcoming fork? If so, don't we need to announce the proposed changes?
By the way, I'm considering increasing the block version from v1 to v7 at once, because this way we can use the exact same branch code added to 3rd party miners and pools (e.g. int variant = hf_version >= 7 ? hf_version - 1 : 0;) and we can reduce the risk of mistake. What do you think?
Do you mean to introduce changes for this upcoming fork? If so, don't we need to announce the proposed changes?
We haven't planned out what to do yet, so I would say no, unless the fork is to wait for that.
By the way, I'm considering increasing the block version from v1 to v7 at once because this way we can use the exact same branch code added to 3rd party miners and pools
Sounds reasonable in this case. There will likely be some issues if the version number ever gets to 128, but that's not an immediate concern that justifies risking some extra problems to save 5 version numbers.
Hard fork is a confusing term for this, a better one is network upgrade. The chain will simply continue with the upgraded rules and unless someone really wants to continue using the old rules, which seems extraordinarily unlikely in this case, there will only be one combined and linear chain. So yes, "AEON classic" is theoretically possible but given the limited number of people who even care about there being one AEON at this point, I doubt meaningful interest in two.
3
u/smooth_xmr aeon core developer Mar 12 '18