when a soft-fork is a spoon (a spork)

Since late 2015, the main debate of bitcoin really began, 18 months later things have not changed much. The debate continues, the issues and concerns continue and the transaction fee rises continue.

We have Core on one side that have spoon-fed at least 4 different versions of their software in the last 6 months alone, but still unwilling to release a version that has some longevity. 
Thinking ahead, to have a fully functional ‘segwit complete’ version, requires at least a couple more releases before and after the activation of it. 
Yet hypocritically Core is suggesting it will take 18 months just to code and activate ONE version that could give some respite to endless downloading of updates and allow some longevity within bitcoin.

We have on the other side, many other implementation brands that seem to have code ready within days of announcing proposals, yet just as fast get REKT by the nonsense social troops of political FUDsters. Simply because they are not following the spoon dug road of Core.

We need to end the cycle of developer dependence of spoon-feeding political decisions of what they think is best and instead get them to listen to what is best for bitcoin.

Having segwit as a block inside a block[[1mb]3mb] is only meant to be a temporal measure to bypass the need for non-pool nodes to adopt. 
Yet now, the suggestion is to have non-pool nodes download a version to push through the temporary block inside a block segwit. Which then makes the need for the block inside a block temporary measure become no longer required.

The solution then becomes very transparent.
A version that is not a block inside a block, but just a single 4mb block.
Have this version include the new keypair types that different parties want, such as schnorr, segwit, new contract opcodes, etc. With a pool block policy that starts at just 0.25mb above the last pool policy limit and increments up
eg: 1.25mb, 1.5mb 1.75mb, and so on. just like the last 8 years.
Where all the new keypairs happily utilise the same block space. No filtering, no pruning, no stripping. 
Emphasis: all block data being treated the exact same way on a equal and level playing field of a peer network.
Further to this opportunity, other needed fixes can be included too, such as allowing users to change settings that will change over time anyway. 
eg: ability to change the 4mb blocklimit at runtime when the future need arises.

making some parts static instead of variable, Thus removing alot of the mathematical manipulation of rules.
eg: fixing the TXsigop limit permanently to under 4k no matter the blocksize
eg: fixing the TXbyte limit permanently to under 100kb no matter the blocksize

which solves the quadratics/bloat cries, ends the constant need to be spoonfed every couple months and can then allow developers to concentrate on fixing bugs instead of orchestrating political controls. 
where actual issues and concerns are being dealt with on a more long term bases, which is what users want and what developers should hope to achieve.

It is time we actually stop letting developers dictate their roadmaps and instead get them to listen to the community and release what the community can unite around.

in short
Take away the developers spoon, which is not useful and most certainly going to cause a split or keep debates alive. Then get the developers to learn how a consensual fork can unite the community by getting them to actually listen to the concerns of the community.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.