Adjust default config file depending on hardware #10188

Often bitcoin users are recomended to set dbcache=4000 at least during innitial syncronization. Raspberry Pi nodes also tweak maxconnections and maxmempool parameters.

Bitcoin Core should -on its first startup- try to guess the best config depending on the amount of RAM installed, the number of CPU cores and ARM architecture.

The goal is to be able to run Bitcoin Core on low end hardware without additional configuration, for example if Bitcoin Core is installed on a Raspberry Pi it shouldn't use the same default configuration as on a high-end server.

core should have a speed test that logs when it see's a block, downloads it and verifies it. and along with whatever the blocksize limit is, can along with i-rme's idea of updating the config, suggest the best cache and also suggest what the max blocksize the node can be capable of. to allow nodes to be more in control of limitations the nodes set. which pools later have to follow due to what hopefully would be a node controlled consensus of pool blocksize preference. thus not needing dev guesswork for many variables and growth

@MickSHunt Max blocksize is a consensus rule. All nodes need to enforce the exact same limit. So unlike configurable parameters like dbcache, max block size cannot be adjusted depending on hardware capabilities.

@luke-jr we could argue all day who or when max blocksize consensus should change from 1mb but lets say we are in the future and it moved to 8mb consensus.h, but allowing nodes to have a second parameter to control pools further. EG preference of 4mb based on speed tests, hardware, etc. EG economic(user) nodes have their policy/preference/useragent of different amounts BELOW 8mb for instance 80% of nodes say 4mb based on user settings then pools follow majority of the preference which is WAY below "consensus.h" and solves the cries about data centre risks and also the cries of dependency of dev's to manage the network. giving more power back to nodes TL:DR; non-mining nodes have more control of settings as part of their own policy.h that can be adjusted at runtime and display certain settings in useragent to help the network see/determine what is possible

Nodes cannot set a limit either higher or lower than the consensus rule without losing full node security or risking getting split off the network. The effective limit must match exactly for all nodes. Policies are only things that affect off-chain transactions in the mempool - they can never affect validity of blocks.

again imagine the future 8mb full network consensus.h. everyone has it. safety point 1 =8mb limit. then nodes can as a second safety level to suggest what pools should make. BELOW 8mb

for instance lets go back in time 1mb limit in consensus. now imagine in 2011 nodes also said "we prefer pools to only make 0.25mb blocks. pools would follow the suggestion, until nodes later suggest 0.5mb was ok. it doesn't cause chain splits because the 1mb consensus is there. but the second limit is not a hard limit but a "suggestion" making nodes have more control over pools growth. to avoid the datacentre cries

So a suggestion the miners can and will just ignore? Right now, the recommendation would be 750k at most, yet pools are almost always making 1 MB. Anyhow, we've gone too far off-topic here.

im talking about suggestions in relation to i-rme where nodes display whats preferable such as his dbcache, because along side the speed test results everyone can see what nodes are capable of and what the hard rules could/ should be. taking the guess work out of it and giving users more control of their settings also allows pools see what kind of risks there are if pools started going too far. or when its near time to re-evaluate the consensus.h because the suggestion is that majority of nodes could cope with 8mb blocks

EG what if people done some tests of blocks over 500kb in 2012 and had a user setting suggestion of 500kb blocks and berkeley locks of xxxxxxxx, pools and users can see what is healthy for the network by seeing what the majority of the network preferred. taking the guess work out of it

EG what if people done some tests of blocks over 4mb in 2017 and had a user setting suggestion of 8mb blocks, pools and users can see what is healthy for the network by seeing what the majority of the network preferred. taking the guess work out of it

in those events. a pool will try to stick to 500kb in 2012. because the majority of nodes think there is something bad about going over 500kb even with a 1mb limit. and if pools see 8mb was safe this year. they wont go passed the 1mb consensus limit but it would be then less guess work over what the next bump in consensus.h should be

@luke-jr @MickSHunt Please stick to the OP. I think @i-rme's suggestion of tweaking some parameters based on a server profile is useful, but if this turns into a block size discussion I will close and lock it.

im just saying add a speed test in core. which can then be used for many things later including setting settings i-rme is on about