Luke Dashjr

@ethankosakovsky

Does this consider the scenario where bitcoin.conf has valid rpcauth params, but the user specifies -norpcauth or such on the command line to disable them?

Tested this. Bare `-rpcauth` cannot be used to reverse `-norpcauth`. Since `-rpcauth=somethingvalid` does reverse `-norpcauth` (including reinstating `-rpcauth` params prior to the `-norpcauth`), this seems like it should be supported?

Any reason not to scope the new variables? https://github.com/luke-jr/bitcoin/commit/851d354fc4f94695aabd12d21e470dc90d267b93

Probably better to just remain backward compatible, at least for a release or two...?

Actually, looking at the implementation deeper, I'm not sure we gain anything from this change. Just use batch RPC calls? Concept NACK for now.

>It also suggest to mark headers between an invalidatetd block and the previous m_best_header as invalid, so they won't be considered in the recalculation. You mean if you invalidateblock, then...

@kristapsk @jonatack @achow101

>A new circular dependency in the form of "kernel/mempool_options -> policy/policy -> kernel/mempool_options" appears to have been introduced. How do you propose resolving this? It's not really a circular dependency,...

Besides making the code cleaner, I'm hoping to get to a point where it's practical to fix the remaining vsize bugs.