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:34
chain_state::data::timestamp::ordered is a dequeue with dynamically-computed size (timestamp_count(...)), so you just need to incorporate the different size computation.
(edited)