Topic: Segwit and 2MB blocks together ? (Read 387 times)

lets delve into this point.

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(300) nodes at the bottom 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 then 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)

because i read and research and seen what gmaxwell and gang have been getting excited and are talking about.
then i have seen a few other bits about why they are getting excited. and then i read and research more and deeper into it.

by the way there are other proposals.. just not been added to cores moderated bip list.

but by you being aware of it atleast shows the chit chat within their group has reached your ears for you to be aware of it too

p.s i edited previous post to added context to the other question you mentioned

I'm not talking about BU, I'm talking about existing dynamic block size proposals. Nodes would accept anything that miners throw out at them with those, unless there is a hard cap.

What made you mention this?

There isn't one that I'm aware of.

the A base  Ax2 weight   EG 2mb base 4mb weight  would allow segwit and actual tx count rise..
the A base  Ax4 weight   EG 1mb base 4mb weight  or 2mb base 8mb weight.  is cores desire..

the reason that need Ax4 is because 2017 they wanted to slide in segwit, and have the spare 1.9best bet expectation of spare weight (remember your 2.1mb utility) as just spare unused buffer..
but later while still at 2.1mb with 4500tx.. they want to turn the same transactions of ~450byte into 1450byte with their confidential payments idea.

thus still 4500tx but instead of 2.1mb total it would be 4mb total..

in short
Ax2 (2mb base 4mb weight -> 3mb base 6mb weight) allows segwit and lean tx growth
Ax4 (1mb base 4mb weight -> 2mb base 8mb weight-> 3mb base 12mb weight) allows segwit and bloated confidential tx growth


more power to miners?

seriously!!

miners cant produce blocks bigger than the majority of nodes would accept. end of..

let me guessing your thinking then financially penalising pools by changing the blockreward mechanism is gonna help?..
no thats just a tactic to turn nodes and pools away from agreeing to that bip (because its stupid) so that dev's can say "oh look the community dont want it"

rather than doing a proper natural consensus dynamic implementation

I wonder what the implications would be of going from: '1 MB base and 4 MB weight' to '2 MB base and 4 MB weight' as opposed to '2 MB base and 8 MB weight'.

I don't think there is a good dynamic block size proposal that doesn't allow gaming in one way or another or gives even more power to the miners just yet. I'd be in favor of a block size increase HF (along with other changes that are 'to-do' but require a HF) post Segwit.

Community's input doesn't mean a penny in here so lets minimize any uncalled for debates and conversations shall we? Things like these are in gray dictatorship state of bitcoin, just like US and laws about guns, as though they're called united but with many differences yet having one federal government with one president. just let the miners decide what is best so then we follow, like we have any other choice lol.

2mb fixed?
nah we long way passed that compromise of dev orchestrated fixed boosts. it needs to be dynamic to stop the devs from spoonfeeding and controling the community with their tactics

id say 2mb base 4mb weight default beginning. so both segwit and natural onchain growth can begin..
but where its dynamic to grow when the community want/need it. not when the devs decide it

Is there any reason why we cant do both of these in 1 go?  it might appease both sides of the block size debate and we could see where we go from there.