@franky1
BU is basically a completely separate fork that has nothing to do with bitcoin core.
If the majority of miners, nodes, exchanges, wallets decide to use BU instead of core then BU is the new bitcoin.
This however is most likely never going to happen since a large group of people, miners, developers,etc… do not support BU.( that’s probably what you refer as consensus)
you have fallen too deep into the blockstream owns bitcoin.
no one should own bitcoin.
secondly BU and XT are running right now on bitcoin and no fork is occuring. yep they even right now have larger blocksizes and nothing has gone wrong..
However if someone published the segwit core code with a 2mb anonymously, then the miners are most likely to show their support for this version because that’s basically what they want.
also segwit is not active you cannot make a P2WPKH transaction right now.. so segwit is not part off bitcoin.
its just a bitcoin release with an inactive feature thats sitting on the side thats not allowed on bitcoin yet.
Both XT and classic didn’t get miner support because they didn’t have unanimous support . [neither] does Segwit today.
Segwit+2mb pretty much has unanimous support, even the most hard core CORE crowd would support it, and the BU camp is just whining because core don’t want to compromise .
well having a release that has both dynamic and segwit would be the "have the cake and be able to eat it" best of both propositions which would actually get better acceptance rate by the community as a whole.
sorry but spoonfeeding with just a release thats hardcoded as 2000000 fixed. is still just kicking the can down the road. relying on devs to release a EG 3000000 buffer later on.. which still feels like a oliver twist "please sir can i have some more" begging to devs game.
The problem we have now is not how we should scale , but it is who will control bitcoin in the future. The only way you can get rid of the politics is for someone to anonymously publish code that everyone wants. You will be surprised by how much support such code would have, especially in these uncertain times.
consensus is about no one controlling
meaning its not devs setting the setting. but offering a settings panel or a method for users to set what they want AFTER compiling and using it. thus not need continual spoonfeeding of devs. because consensus changes by what majority of nodes allow. which can change when USERS choose. not devs.
i agree that there should be more diverse implementations released. where it dilutes cores dictatorship. so that
if cores 1mb dictatorship wall dilutes to became only 5% dominance.. meaning the 1mb becomes small minority. then what the majority accept as the next safe buffer is what the pools choose to move towards. then users get to set what they are happy with. and if a majority show acceptance, things move forward. all without constant waiting for dev's to spoonfeed the setting.
ill save repeating myself by rewritting it again how consensus works
imagine the network had 55 nodes. for easy display purposs of 5500
and the acceptable node tolerances(user settings) were all collated and put into order
1.0mb, 1.5mb, 1.5mb, 2.0mb, 2.3mb, 2.5mb, 2.6mb, 2.7mb, 2.8mb, 2.9mb, 3.0mb,
3.0mb, 3.0mb, 3.2mb, 3.5mb, 3.6mb, 3.6mb, 3.7mb, 3.8mb, 4.0mb, 4.1mb, 4.1mb,
4.1mb, 4.3mb, 4.6mb, 4.7mb, 4.8mb, 4.9mb, 4.9mb, 5.0mb, 5.0mb, 5.1mb, 5.1mb,
5.2mb, 5.6mb, 5.8mb, 5.9mb, 5.9mb, 5.9mb, 5.9mb, 6.0mb, 6.1mb, 6.1mb, 6.2mb,
6.2mb, 6.2mb, 6.2mb, 6.3mb, 6.3mb, 6.4mb, 6.4mb, 6.5mb, 6.5mb, 6.6mb, 6.6mb,
the pool then takes away three nodes (~275 of 5500) to get to what would be ~95%
1.0mb, 1.5mb, 1.5mb, 2.0mb, 2.3mb, 2.5mb, 2.6mb, 2.7mb, 2.8mb, 2.9mb, 3.0mb,
3.0mb, 3.0mb, 3.2mb, 3.5mb, 3.6mb, 3.6mb, 3.7mb, 3.8mb, 4.0mb, 4.1mb, 4.1mb,
4.1mb, 4.3mb, 4.6mb, 4.7mb, 4.8mb, 4.9mb, 4.9mb, 5.0mb, 5.0mb, 5.1mb, 5.1mb,
5.2mb, 5.6mb, 5.8mb, 5.9mb, 5.9mb, 5.9mb, 5.9mb, 6.0mb, 6.1mb, 6.1mb, 6.2mb,
6.2mb, 6.2mb, 6.2mb, 6.3mb, 6.3mb, 6.4mb, 6.4mb, 6.5mb, 6.5mb, 6.6mb, 6.6mb,
then knowing that all remaining 52 nodes can accept 2mb.. thats what they make..
now here is the fun part most people forget.
pools start a flagging vote consensus saying we will make upto 2mb.. once the pools get 95% consensus.. those 3(275) nodes in the minority can up their limit.. as it takes time for pool consensus to get reached.. (eg 2 months for segwit and not near 95% yet)
so plenty of time for them to change a setting.
then. lets say it activates. pools can now push passed the 1mb old barrier and start moving to 2mb (much like the 2013DB bug where it pushed passed the 500k barrier even when nodes had a higher buffer.)
and guess what.. they wont jump straight to 2mb.. (much like they didnt jump straight to 1mb in 2013). they would try 1.001mb and test the water, see if any bugs present themselves any orphan risk. any issues.. if not. they push on 1.002mb, 1.003mb and so on over time naturally growing until* they get to 2mb due to demand and need.
*side note the 2 grey nodes(1.5mb i underlined) actually still happily accept blocks during the early movements meaning they dont actually need to decide to join consensus as early as the lowest single node at 1mb.. so while pools are testing the water only 1 node (100 of 5500) need to make a decision during the pool consensus+grace period before activation. the other 2(200 of 5500) can have a bit of breathing room ontop of pools consensus+grace period..
then when the limit is reached, finally after a lengthy natural growth period. the process begins again.
slow natural risk averting process where the nodes decide the tolerance
so dont expect a spammer to force a pools hand to make a pool jump up to 2mb on day one of activation.. pools are smarter then that
(much like the spam attacks of 2012-2015 didnt cause blocks to all be 1mb non stop, it was a slow curve over a couple of years)