/u/smartfbrankings's recent attempts to lampoon Bitcoin Unlimited have given me an idea: in the first place why didn't Core just make every parameter user-adjustable? (but of course with the Core defaults and warning messages if you adjust them)
Block reward, halving rate, blocksize cap, difficulty targeting, signing algorithms, etc.
Of course there are some justifiable reasons, but they have easy objections:
Because it would give a clear demonstration that it isn't Satoshi's design proclamations nor Core dev wisdom that enforces these parameters, but rather the Schelling consensus around those parameters, which miners adhere to because they aren't fools as they know their blocks would likely be orphaned if they didn't adhere to them.
However, although each of the parameters are "technically" all just lines of code, the market values adherence to them very differently. For example, adhering to the block reward and halving schedule have always been extremely important to the market (meaning people would sell BTC off extremely heavily if if they were altered, maybe even to zero) and this will likely always be true, whereas adherence to the 1MB blocksize cap might soon be seen as not very important to many miners and nodes, resulting in some miners in some situations eventually mining some bigger blocks if they find it to have a positive expected return even when taking into account the elevated orphan risk.
Also, if the devs ever turned out to be wrong about something and a parameter did require changing, people wouldn't have to download and verify a new client each time.
Finally, users could hard fork more conveniently whenever they wanted to (provided enough people went along), with Core and/or other experts merely giving *verbal guidance* on which settings to choose. Miners could also coordinate with each other to, for example, plan a "flag day" for a change in the consensus. Miners should be greater experts in mining than the devs, so they should make the decisions for their own unique business profit/loss situation and dynamically in response to events.
Why not just have all sorts of proposed changes (BIPs) "waiting in the wings" in the client code, and instead of of downloading a new client when Core says "Go!" people just change the settings to include those changes when Core (or some other experts they trust) give the go-ahead? Those changes could even include XT-like "flag days" that would activate later. Core would have a user-selectable menu with BIP101, BIP102, etc. to choose from. If the user activates BIP101 the clock starts ticking toward the flag day, and if they disable it before the flag day the clock stops ticking.
Block reward, halving rate, blocksize cap, difficulty targeting, signing algorithms, etc.
Of course there are some justifiable reasons, but they have easy objections:
- It could confuse users (OK, then put the options in an "Experts Only" menu with multiple big scary warnings not to change them or else risk falling out of consensus)
- A user might change the settings accidentally and lose their block reward due to orphaning (see above; if they accidentally bumble past all those warnings then there's a much bigger danger of them accidentally sending coins to the wrong address)
- It makes aberrant behavior more convenient (so what? In Bitcoin we assume economic rationality from the start, and no economically rational miner will ever mess with, say, the coinbase setting. Miners already can and do modify the software anyway. This just makes the modding more convenient and accessible - surely mere inconvenience isn't what we rely on to keep Bitcoin secure!)
Because it would give a clear demonstration that it isn't Satoshi's design proclamations nor Core dev wisdom that enforces these parameters, but rather the Schelling consensus around those parameters, which miners adhere to because they aren't fools as they know their blocks would likely be orphaned if they didn't adhere to them.
However, although each of the parameters are "technically" all just lines of code, the market values adherence to them very differently. For example, adhering to the block reward and halving schedule have always been extremely important to the market (meaning people would sell BTC off extremely heavily if if they were altered, maybe even to zero) and this will likely always be true, whereas adherence to the 1MB blocksize cap might soon be seen as not very important to many miners and nodes, resulting in some miners in some situations eventually mining some bigger blocks if they find it to have a positive expected return even when taking into account the elevated orphan risk.
Also, if the devs ever turned out to be wrong about something and a parameter did require changing, people wouldn't have to download and verify a new client each time.
Finally, users could hard fork more conveniently whenever they wanted to (provided enough people went along), with Core and/or other experts merely giving *verbal guidance* on which settings to choose. Miners could also coordinate with each other to, for example, plan a "flag day" for a change in the consensus. Miners should be greater experts in mining than the devs, so they should make the decisions for their own unique business profit/loss situation and dynamically in response to events.
Why not just have all sorts of proposed changes (BIPs) "waiting in the wings" in the client code, and instead of of downloading a new client when Core says "Go!" people just change the settings to include those changes when Core (or some other experts they trust) give the go-ahead? Those changes could even include XT-like "flag days" that would activate later. Core would have a user-selectable menu with BIP101, BIP102, etc. to choose from. If the user activates BIP101 the clock starts ticking toward the flag day, and if they disable it before the flag day the clock stops ticking.
Last edited:
