The decision making processes should be based on where the miners point their hashing power and what code people choose to run. This is the level at which consensus should be achieved. To think that important decisions should be made by a Core development team is tantamount to centralization of power.
There is a very big difference between being a benevolent dictator of your own implementation of Bitcoin and actually being the dictator of Bitcoin. This is a very important distinction. It is not wrong to be in charge of your own implementation of Bitcoin when people are free to choice whatever client they want. Having multiple implementations of Bitcoin is good for decentralization and freedom.
Agreed. One group of developers should not be considered a permanent authority on what Bitcoin is or should be. I don't see how anyone could possibly be advocating for such a thing, but sadly it seems increasingly common at the moment. Disparate factions are emerging here and no one is any closer to agreeing on anything. If anything, the gap appears to be widening. We're not working towards a solution, we're working towards a split. I honestly don't see this ending amicably.
Points to remember:
- If you want to use an open source coin, that means anyone can modify that code and submit their own version under another name.
- Such actions are not an attack on the system and actually prevent the possibility of a single group having permanent control over development.
- Successfully forking with an alternative client does not give those developers any special power or diktat to enforce future changes on the network.
- Assuming that Core developers are the only permanent authority on what Bitcoin "is" or "should be" is an extremely dangerous mindset.
- Consensus is not a group of developers agreeing, because the people securing the network make the decisions, not the developers.
Oxymorons to avoid:
- "Bitcoin is great because it's decentralised, but only the core devs can be trusted to write code"
- "Bitcoin is great because it's open source, but releasing a client to propose a fork means you're a dictator"
- "Bitcoin is great because it's permissionless, but you can't use it to buy a cup of coffee"
- "Bitcoin is great because only the economic majority can decide the rules of the network, but only when I personally agree with them, otherwise I'll dismiss it as an altcoin like a petulant child"
XT was rejected. Get over it, we'll be scaling up without BIP101 or XT. Go away.
There's nothing to "get over". The points I've outlined above apply in
all instances. They aren't specific to XT. Stop trying to portray every single comment on the forum as "XT vs Core" and making out like anyone who thinks we need a larger blocksize is some sort of XT fanatic who wants 800GB blocks tomorrow. We're not all extremists. Calm the shit down already.
My preference is leaning more towards a dynamic limit:
Anyway, since some are determined to deflect away from technical proposals and throw silly memes around, we'll drag the topic back to one of merit.
The ideal solution is one that doesn't create a blocksize too large for full nodes to cope with, but at the same time, one that doesn't force a large number of people off chain. Even doubling to 2MB in one go is quite high when you think about it, so we should aim to increase (or decrease) in smaller increments more often,
if needed. One possible route is to take the best elements of BIP100 and
BIP106. BIP100 only considers what benefits the miners and not the users. BIP106 only considers what benefits the users and not the miners. So neither is particularly balanced on its own. If we can find a way of allowing half of the "vote" to go to the miners and half to an automated, algorithmic vote based on traffic volumes, then we maintain some kind of equilibrium that should (in theory, at least) benefit the network as a whole.
Miners vote by encoding BV+BlockSizeRequestValue into coinbase scriptSig to:
raise blocksize limit by 12.5%,
lower blocksize limit by 12.5%,
or remain at current blocksize limit.
This vote, however, only counts for half of the total vote and the other half is determined by algorithm based on network traffic:
If more than 50% of block's size, found in the first 1008 of the last difficulty period, is more than 90% MaxBlockSize
Network votes for MaxBlockSize = MaxBlockSize +12.5%
Else if more than 90% of block's size, found in the first 1008 of the last difficulty period, is less than 50% MaxBlockSize
Network votes for MaxBlockSize = MaxBlockSize -12.5%
Else
Network votes for keeping the same MaxBlockSize
The 12.5% part is open to negotiation, some think 10% is more reasonable (i.e. BIP105). If every 1008 blocks is too fast, we could (for example) increase that to 2016 blocks, approximately every two weeks. Tweaks are inevitable, but I feel it's something that could work if it's not too complex to code.
Is that not reasonable?
As for BIP101, I honestly don't think it was the catastrophic, apocalyptic doomsday scenario you portray it to be. If you had simply argued to curtail it to a more reserved increase, without all the doubling and such, it really wouldn't have been the massive drama you've helped turn it into. But it doesn't matter, what's done is done. Now we need to move on. The manner in which we move on is the more important issue, though. There are people on this forum who are capable of providing constructive criticism and speaking reasonably, discussing amendments to proposals to try and find an optimal solution. There are others on this forum who simply attack, dismiss, mock and spread misinformation because they can't accept that people see blocksize as an issue. Please strive to be one of the former, we have more than enough of the latter at the moment. We really don't need any more. I'm sure whatever happens, the usual suspects will still be throwing their silly "#rekt" memes around and mocking every single discussion because they have nothing of value whatsoever to contribute, but the rest of us will carry on with more reasoned debate.