Bitcoin full node and query server

Jun 4, 2018

View in context in the libbitcoin Slack #general mirror.

@evoskuil Thank you for your detailed response. Given the huge variety of coins it's quite difficult to assess all required parametrizations. Parametrizing the ones needed for Feathercoin and also the obvious ones should be a fairly good start though. Because I'm a newcomer to the codebase my plan is to start by parametrizing only a few parameters and then ask for early feedback. That way we can limit the amount of comments needed to get the development conventions and code layout across. Regarding the pervasiveness of this task my idea was to remove constants, that have been parametrized, from constants.h only after they are not in use in other repos any more (if any). That way the whole migration process can be split into multiple PRs which makes it more managable for everyone involved.

Eric Voskuil

@Fil You are welcome to do so, but parameterizing those values into all uses will be fairly pervasive. Expect a lot of comments. All constants that could vary by coin should be parameterized. There should be a settings class analogous to that of other repos (we want no more than one per repo). There are trade-offs to passing a full settings reference (vs. individual values) into a class, method or function. I'd be looking for consistency here and generally we opt for passing individual values if there is just one or two and no expectation that the set would expand over time, and the se…