Hello erik,
thank you for reading and commenting.
Interesting proposal. The concerns I'd have include:
- If a vote must be used to initiate the hard fork, it should be 95%. Note that this concept only became necessary because of the XT code fork. Otherwise, we could of just set a date in the future and asked miners to upgrade by then.
In the presence of the many BIPs, I think a supermajority criterion is needed. I am not sure why 95% would be better than 75%. I think 75% is enough, and I think 95% might not be reachable. Of course, if a consensus could be reached and "bitcoin-core" or another project convinces everybody to use the SW, then the new BIP10X protocol could be simply activated at a given block height.
My assumption though was that we are dealing here in a somewhat competitive environment between different proposals.
- Not sure why we want miners voting every week.
Maybe a misunderstanding. Miners don't vote "every week", they vote continuously in "every block". The 1 week relates to the intervals in which miner votes are EVALUATED and possibly adjustments on the block size limit take place. I re-phrased this in my updated version at Github, to avoid this misunderstanding in the future.
1> Miners are unlikely to want to interact. How would this work with ASICs? Miners probably don't want to have to update anything on a weekly basis.
They don't need to. This "BIP10X" proposal suggests that miner operators do not need to interact but just configure what is their voting preference in "bitcoin.conf", and then the miner will automatically cast the correct vote according to miner operator's preferences. Operator can adjust his preferences any time (no need to respect the 1-week-intervals in any way). Also note that instead of the voting strategy "vote for fixed value", miner operator can also configure via bitcoin.conf that the voting strategy should for example be "vote for average actual block size of last week times a certain self-selected factor", or miner can vote for "same block size limit as current block size limit".
2> Why would miner voting be needed for anything other than the hard fork? Couldn't we just have it always calculate the block size limit periodically based on history? I see you have a notion of this. Buy, why as a fall-back instead of the primary method?
First, I use the actual block size criterion as a "constraint", not a "fall back" method. (But maybe you understood it right and just termed it differently)
You suggest auto-adaptation of BlockSizeLimit e.g. solely based on the actual fillings of the blocks? In principle possible, but I want to introduce miner voting "institutionalized" inside the protocol, to avoid tiring "block size limit"-motivated hard fork discussions for the future, as we have it now. Because if miners can vote within the protocol, they do not need to vote for a completely new hardfork SW but can just use the voting mechanisms already present within the protocol. I also wrote it like this in the "Motivation" section of the BIP10X proposal.
Also, we see from miners' reactions today that they like a solution where they can actively vote, hence their BIP100 support is so great. And we cannot ignore this fact. But I want to propose a solution that removes the drawbacks of BIP100 (which maybe not all miner operators have completely figured out and are aware of), i.e. an improved version of BIP100 if you want, that the miners can hopefully also well agree with, hopefully even better than with BIP100 itself. One could consider BIP10X an evolution of BIP100.
Another reason against complete "auto-adaptation" without voting is that there could be natural (e.g. seasonal) periods of lesser traffic that should not necessarily promptly lead to BlockSizeLimit adaptations (decrease) too soon. I really think that voting (or the human = miner's influence) should play an important role, and the "actual block size" constraint should only step in if the divergence between actual block size and BlockSizeLimit vote becomes too much.