Bitcoin full node and query server

Oct 16, 2018

View in context in the libbitcoin Slack #general mirror.

@evoskuil continuing on my work the next task is to implement FTC's diff algo which itself consists of 3 hard forks. I'd like to discuss them here briefly so we can align ideas about implementation. Let's call the 3 hard forks HF1, HF2, HF3. HF1 is trivial. It just changes the value of a couple of settings parameters which yields to a shorter retargeting interval. Implementation-wise there are two possible approaches: either set the parameter value upon hard fork activation or add new dedicated parameters for HF1. The former feels a bit hacky but the latter clutters the settings a bit and adds conditional logic to the code. HF2 and HF3 use an additional timestamp sample to compute the new required difficulty. Therefore, chain_state::data::timestamp::retarget is not sufficient anymore. Moreover, HF3 computes a new difficulty target for every block. Thus, it would make sense to increase the size of chain_state::data::timestamps::ordered such that the required values can be obtained from there.
evoskuil08:25
HF1, I would use the parameter change. This is the reason for exposing the parameters. I agree it feels a little hacky, but this pattern is already established with activations, checkpoints and network parameters. The flags are really for logic forks. Flags are recorded with validation, so in any case where a fork is conditionally activated it must be a flag.
(edited)