Post
Topic
Board Bitcoin Discussion
Re: SegWit + Variable and Adaptive (but highly conservative) Blocksize Proposal
by
franky1
on 22/05/2017, 00:09:30 UTC
But I'm reluctant to drop the reduction aspect in the same way I'm reluctant to adopt Carlton's fixed upper cap.  I sincerely doubt you'd accept his idea and there's no way he'd accept yours, heh.  Both views are a bit too far towards one of the polarised extremes.  In order to be a compromise, I'm trying to steer this thing somewhere towards a happy middle-ground.

carltons 'infinite growth' .. or as the reddit script Fudster buzzword calls it "gigabytes by midnight"
i facepalm that.

imagine it this way.
we are in 2013.. consensus is 1mb.. but policy is 0.5mb
now imagine if that 0.5mb was not simply a decision pools made alone. but nodes had some control of. to ensure it didnt jack up above 0.5mb too fast.
where nodes had a speed test benchmark mechanism in their node which publicised what they could cope with.
nodes wouldnt necessarily orphan the blocks above 0.5mb. but would atleast highlight to pools where pools should slowdown if there was not a good healthy node capability

EG
2018 new rules
8mb consensus
nodes publicise 4mb capability

pools made blocks below 4mb at healthy increments of 1mb-4mb over time(eg 0.25mb/year (kind of like 2011-2015(roughly))).. where pools knew what they do would not cause risks to nodes.. thus not cause orphan drama. or drops of node count
if pools know what the network can handle then pools know what not to risk


separate rant
what i do truly laugh at is while the "gigabytes by midnight" fudsters are screaming 'it will kill full node count'
they are not arguing how many full nodecounts are dropping due to prunned, no witness(stripped/filtered/downstream) features which have been added and told are "all good and safe"