[...]
This is a great idea and further adds to decentralization. However, I think you may run into a problem if you don't have a preset default. Many non-technical users or users that have not followed the debate may not understand this setting or be fully aware of all of its implications. If the user enters 1 mb as the limit while the network is producing >1mb blocks, then they run the risk of getting routed to a bad fork. I would suggest having a default despite perception of bias, to protect users only. Perhaps you could even have no limit as the default.
For example, you could have two radio buttons. One with a default value and the caption "choose this setting if you don't fully understand the block size limit." The other that enables a text box or drop-down menu that let's the user input the block size limit of their choosing with the caption "advanced - leave blank for no limit" - or something similar.
Thank you! I specifically worded it like I did because I think it only has a chance of adoption by staying as neutral as possible. Default == no limit won't fly with the Blockstreamers, but
at least with the current edition, it should get them sweating for answers that do not eventually point to them being some bogus authorities.
And don't get me wrong: I agree on the issue of lack of user education. We need to make sure
as the community then that new full node operators do not shoot themselves in the foot.
And, yes, personally if this ever gets accepted, I will argue for putting in a very high value (and maybe I should add a suggestion for a a 'max' setting?) with any new full node operator that I might interact with.
So, again, yes, I completely see your point, but I think this variant is the only one neutral enough to have a chance at acceptance or at least stirring things up. And before I get accused of being an agent of chaos by saying 'to stir things up': I mean it in the sense of furthering the blocksize discussion.