We can do everything, podizzle
As an example: You take the Blackcoin code and build a new zeit-client based on Blackcoin.
You need parts of your old code for the syncing procedure till Block X. After Block X the client works with a completely different chain format.(SHA256 POS in this case)
Example: Hobonickels
The following constants have been added by Tranz:
/** Hard Fork Change Times/Block */
static const unsigned int PROTOCOL_SWITCH_TIME = 1371686400; // 20 Jun 2013 00:00:00
static const unsigned int REWARD_SWITCH_TIME = 1369432800; // 25 May 2013 00:00:00
static const unsigned int POS_REWARD_SWITCH_TIME = 1378684800; // 9 SEP 2013 00:00:00
static const unsigned int POS_REWARD_FIX_TIME = 1383177600; // 31 OCT 2013 00:00:00
static const unsigned int POS_REWARD_FIX_TIME2 = 1383606000; // 04 Nov 2013 23:00:00
static const unsigned int VERSION1_5_SWITCH_TIME = 1421489410; // Sat, 17 Jan 2015 10:10:10 GMT
static const unsigned int VERSION1_5_SWITCH_BLOCK = 1600000; // Block 1.6 million, approx same time
For a better understanding:
Let's change the drift time from 1h to 10s. What can happen?
Every new client will work without any issue if the chain is fully synced, BUT if u start syncing at Genesis Block (0), the latest change does not meet the rules.
The new client will not accept any blocks with a drift >10sec.
You have to tell the client that 1h is valid till block X. The constant values are hardcoded blocks in the future. On certain day X at 0:00 the whole network accepts the new rule.
My plan is the following:
We could make a list with all the features that we wanna have.
Then I need some time and some Knights (Clients) for internal testing.
When the new client is working well, we can switch over.
Cheers,
Ray
Show Posts
