anyway once people play scenarios around that sharding will eventually lead back around to needing masternodes (full nodes)
and then once people play scenarios of if a masternode is needed that stores all shard data. why have it separate because the regional nodes are now just lower down the network and of less importance.
and play around with scenarios of if not separate we are back to a single nodebase of code monitoring everything.. it just full circles. that the strongest network is one that is united under one ruleset
It doesn't have to be an integer, so let's get rid of that myth too. Why not:
1.25mb base/5mb weight, requires hard fork to move to
1.5mb base/6mb weight, requires hard fork to move to
1.75mb base/7mb weight requires hard fork to move to
2mb base/8mb weight requires hard fork to move to
and so on?
It's not just about it happening "over time", it's also about sensible increments. Based on what you've witnessed to date, it should be more than obvious that most BTC users are in no rush to double or quadruple the base.
fixed that for you. however having a case where we remove the witness scale factor and have code set in consensus of
4mb pool policy /32mb consensus,
4.25mb pool policy/32mb consensus,
4.5mb pool policy/32mb consensus
means no hard forks pre increment. and then just some code of when the blocks soft increment by 0.25
again to demyth the PR campaign.
this is not about 32mb blocks.
this is about avoiding 3 years of debate just to perform one hard fork. then another 3 year debate to perform another hard fork
blocks will not be 32mb. they will increment at the pool policy amounts. all monitored and adhered to by nodes enforcing that pools dont go over the policy amount until a coded thing happens that soft activate a 0.25 increment
again to demyth the PR campaign
this is not about EB (trying to turn the debate into mentioning a certain group of people)
this is about allowing progressive growth without hard forks and 3 year debates per increment