Deep reorg scalenet as soon as possible

Consensus
#1

Dear scalenet gentlemen,

Your new BCHN overlords have come up with the idea to either deep reorg or completely restart scalenet so that we can change ASERT activation logic from MTP-based to height-based (for performance reasons) on all networks.

Scalenet was planned to be deep reorged back to height 10,000 periodically. If we do this reorg later, it will change the ASERT activation height. Hence the proposal is to do the reorg as soon as possible, so that ASERT will always activate shortly after height 10,000. This height will then remain the same after future deep reorgs, so it can then be hardcoded. Alternatively, we could restart scalenet completely with ASERT from genesis, but note that future reorgs will cause an instamine in that case, because of the absolute schedule.

For further discussion of pros/cons see:

Don’t like it? Stiff or let us know.

1 Like
Auto reorg scalenet as intelligently as possible
#2

I suddenly understand what happened with testnet1 and 2.

1 Like
#3

Some initial observations:

as Mark points out, scalenet restarts are a hard fork. What this implies is that the old blocks won’t go away, if there are machines hosting them they will stay. And they will have a much larger proof of work than any restart does. It could get messy if the new “fork” client recognizes the old ones as valid, so you really want to avoid this.

This is going to be a repeating process, as we might want to restart this chain every 6 months or so.

My takeaway here is that we would benefit from a command-line option that actively forks scalenet. The command line version of ‘invalidateblock / reconsiderblock’.
Because what you want is to tell the local node to start seeing a certain chain as invalid. And thus start mining on its direct parent.

And with regards to ASERT, what about making the first new block to come AFTER the new tip to become the anchor. Simple math, simple activation.

Example: --scalenet-invalidate=000000000045feffcc6a17f58008f1892e69f0f1ef6ba560f4247d48986906c4.

Would then:

  1. invalidate block at height 10001, making block 10000 the new tip.
  2. keep mining CRW144 for the next 2 blocks (because logic).
  3. mark the new block 10001 as the Anchor block.
  4. mark the new block 10002 as the activation block for ASERT.
  5. use the ASERT based difficulty for block 10003.

This sounds repeatable, easy for operators (no recompile) and since we already persist invalidated blocks, this is future-proof.

#4

In my experience with BU’s “nolnet” scalenet, its likely that somebody (including yourself) will forget about a machine you have running somewhere or you won’t know who is running some server,etc. So that chain will continue to grab newly synchronizing nodes, there might be confusion as to the chain in bug reports, etc. All of this is irritating.

Other options are:

  1. pre-generate a bunch of genesis blocks and chose a particular one based on the scalenet iteration
  2. tweak the DAA on the block on block 1 only to require a slightly harder puzzle for every reset.
  3. tweak the mining algorithm on block 1 only to be something like SHA256(SHA256(Header.ScalenetItration)) – you’d just CPU mine this diff 1 block rather than bothering to push this alg change to mining software.

And whenever full nodes start up (or periodically, or via CLI, or when the scalenet iteration time rolls over, whatever a full node wants to do), the node re-validates block 1 and if validation fails then a big rollback gets tested.

If resets are scheduled on calendar time, these options can be coded once.

1 Like