Opening a new topic that relates to this thread (and the fact that scalenet has grown to something like 200GB).
In this thread I would like to explore a different approach:
- Automatic re-organization of scalenet at regular intervals
Scalenet right now consists of a fixed common genesis block (height 0) with a checkpoint at a “last permanent block” which is currently at height 9,999, making block 10,000 the first impermanent block on that network.
There have been some deliberations on shifting that last permanent block out to e.g. 10,006 to simplify code for certain DAA algorithms.
For the purposes of this thread, we will simply talk about block L as the last permanent block, regardless of what height it’s at, and call the next block L+1 , and so forth.
The proposal here in brief is to establish a way to re-org to a new block L+1 at some pre-determined interval.
We form a consensus on a ‘starting date’ S, expressed in seconds past the epoch, from when this scalenet auto-reorg mechanism should take over from the current infinitely extending scalenet.
We pick an interval D along the UNIX epoch timeline at which we want nodes to deep-reorg their scalenet chains automatically. Here I propose every roughly D=2,592,000 seconds (30 days).
If the scalenet tip’s MTP exceeds S but is less than S+D and the block L+1 is still the “old” L+1 (i.e. a never re-orged scalenet ), then we need to perform the First Automatic Scalenet Reorg (FASR) which is described below in a separate section and skip step 4.
(we only get here if FASR has been done at least once, so the block L+1 contains a commitment of the MTP at which the previous re-org was done)
If the scalenet tip’s MTP exceeds the MTP time in current block L+1 (committed either in the coinbase message string or via in an extra OP_RETURN of the coinbase of block L+1) by more than D , then we are due for an auto-reorg and we perform the Yet Another Scalenet Reorg (YASR) procedure.
For each block incoming on scalenet, we evaluate from Step (3) again. If FASR (3) or YASR (4) is not performed, carry on processing as normal. Entering FASR/YASR will perform a re-org down to block L and append a newly constructed block L+1 which should be identical for all nodes. Processing then continues normally after return from FASR/YASR with block L+2 mined as normal by some miner on the network.
- Use S as the commitment value for the new block L+1 to be mined
- Also use S for the timestamp of block L+1
- Use the MTP at current chaintip as the commitment value for the new block L+1 to be mined
- Use MTP+D as the timestamp for the block L+1
Common procedure for FASR and YASR:
Construct the common new block L+1.
In each case, the new block L+1 will carry a commitment to a UNIX epoch timestamp.
In the normal (YASR) case, this block will carry a commitment timestamp T equal to the MTP value at the chain tip prior to auto-reorg.
In the FASR case this commitment T will be equal to the value S.
This commitment (to a UNIX timestamp) can be encoded in the coinbase string as a null terminated string of decimal digits (which have to be convertible to a number 0 < C <= 2^64-1 to be valid). This would have the benefit of being easy to read in block explorers. Alternatives could be to encode it in an additional OP_RETURN output of the coinbase transaction.
For the coinbase transaction:
- tx version set to 1
- locktime set to 0
- single output, locking script is simple fixed OP_TRUE and sequence number set to 0xFFFFFFFF (4294967295)
For the block L+1:
- block version set to 0x02000000 (536870912)
- block timestamp set as computed per FASR or YASR (see sections above)
- difficulty target of block L+1 is computed and set “as normal” (same expected value on all nodes).
- Nonce to be computed with all nodes mining from same nonce starting nonce value: 0
Given these parameters are all deterministic and fixed, all nodes should be able to mine the same block L+1 with identical proof of work.
They must do so before resuming their regular processing on scalenet.
They must NOT announce this newly created block L+1 to other peers via inventory message, but instead validate it themselves and advance the chain tip to wait for the next block, L+2, to be mined normally by whoever finds it. Thus life goes on until the next YASR.
Nodes starting up who need to do IBD from below block L or who have sat out on a reorg cycle:
- might need to be invalidated manually (or just wipe their scalenet datadir so that they IBD afresh)
- should query and receive block L+1 normally and enter the processing loop to check for FASR / YASR
- might need to receive the expected commitment value of block L+1 manually to ensure they end up on the right chain, in case there are peers serving them chains that are not compliant to this scheme
 this can be confirmed via checkpoint set up prior to FASR if we wanted to be quite sure, or by deeming any block L+1 without a suitable timestamp commitment as “old”.