Now this is a better example and you have a point, im not specifically against the idea of competing implementations, but how do we make sure they run perfectly in sync with each other, this could open different risks in return. The devil lies in the details. But still im not necessarily against it, it just depends on the execution, that i cant evaluate if they’re not here.
here was the idea..
of true decentralised consensus..(before core even existed)
instead of everyone downloading one version from one location.. and accepting that as the defacto version and all other versions treated as competition..
people had versions using different languages, from different brands that were not "competing" but cooperating.
thats the point of bitcoin decentralisation and the solution to the byzantine generals problem.. cooperation not competition..(well before 2015 that was the point)
unlike the 2015-2022 days.. the 2009-2014 days were actually sharing idea's.. there was no "that proposal is ours, dont steal it dont put it into your software its ours, you dont didnt even put our brand into the copyright, you script kiddie thieves" . instead people could copy idea's and add features into their brands. and that was the point.
cooperation not competition..
when there was a feature people wanted. people would put them into their favoured brands and the proposer was happy to see it in other brands.. and if the all diverse favoured brands all got majority agreement to flag for the activation then and only then did it upgrade.. until that point no change happens before majority.. . thus no issue with what you pretend is a problem
this did not activate simply by having competing brands.. things only activated where there was cooperating brands.
so there was no 'out od sync' problems
bitcoin in 2009-2014 had the solution to the byzantine generals problem.. now in 2015+ the core prefer to be the only general to avoid having to share control with other generals..
by this i mean, its like satoshi had his own codebase he tweaked but followed the rules. hal had his codebase he tweaked but followed the rules.. neither hal or satoshi dictated or mandated a change.. or forced each other to obey by mandate..
they had proposals for new features and published the proposals, when both hal and satoshi and others put them into their own codebases and other did too they all found they had the majority to activate the new feature.. and it activated
read alot of the old posts on this forum before 2011 where people were randomly putting code into the forum and everyone then putting it into their own codebases without having to wait for a release candidate that included it from a central repo..
forget thinking of competition and think of cooperation.. forget central repo. think diverse codebases all enjoying each others involvement and cooperation and helping each other out
the issue is core(2015+) wanted to change many rules quick without wanting to be subject to a community vote,, and didnt like having to persuade other clients brands so wanted to remove the brands out of the network so that the activations happened on core terms, with cores time frame (the main devs were employed and had a contractual timeframe deadline that would award them a large amount of bitcoin if they got it activated by the deadline.)
what core should do is instead of making proposals based on political.business contracts behind the scenes that make them money for implementing.. they should instead make proposals the actual main wide diverse community want and would be happy to see.
emphasis make proposals for their feature that the wider community wanted where the wider community would have accepted.. thus not need to force them off the network.. or madatorily scare them into accepting even without having the ful code base to validate the feature..
but core only cared about features needed by their back-end business sponsors contractual deals from certain corporate groups (blockstream and the barry silbert group) (the ones that made the liquid sidechain and LN that required segwit to allow liquid and LN to actually semi function better. (but still flawed, so i still laugh)
anyways back to the point
EG when they promoted their first version of segwit in 2016(needed for LN, and other pegged sidechains like liquid)
not even 50% of the actual bitcoin community wanted it even 7 months later (~may 2017) and the other brands seen no bitcoin large benefit, and just a benefit to the offramp to altnet groups altnets
however their spring 2017 variant was a more acceptable 2mb base block 4mb weight block proposal. this was a step forward majority was willing to accept...(but also was the mandated part.. to really push the activation)
that helped trigger more adoption of segwit but core and the silbert group re-negged on that promise on august 2nd by not fulfilling the 2mb base limit for legacy after august 1st because by august 1st 2017 core became the defacto client left on the network and didnt need to compromise to the second version of segwit that got them a little more acceptance.. (it was a bait and switch along side the mandatory game)
..
anyways..
the whole
'let core devs do whatever they want.. dont let anyone tell core what they cant do' mindset you have seen a few fangirls above mention a few times.. is not consensus...
true consensus is let anyone propose something and actually get them to help have the other brands want it too by having a feature that the wider community actually want. by offering it out willingly to all brands to implement
heres one idea of something acceptable that could have avoided all the 2016-167 controversy..
if there was a version of segwit proposed in 2016 that was a very very simple few features like:
new tx format called segwit, which had malleability fix for those that want it, and the locks and off ramp ability core wanted
the blocksize being 4mb for all to use. including legacy.(core acknowledged 4mb was network safe(no base block limit))
less sigops per transaction to avoid just a few bloated tx filling a block.
this would have actually been what core dev deem as technically possible (they all agree 4mb weight is of no harm) which means more tx per block not just due to full utility of the 4mb. but also the less sigops means less chance of single bloaty TX taking too much space.
a fee thats lower. (instead of the cludgy legacy x4 cludge that core actually proposed.. which caused legacy to get more expensive)
this would have got wide acceptance and would have still got segwit adoption.. all without having to throw large amount of unsupportive nodes off the network via mandated rejections of pools and nodes. without having to cludge up the code with 2 blocksize rules. without 2 cludgy fee rules.
..
there is absolutely no technical reason in 2022 to have the 1mb base limit still inplace hindering legacy transaction utility via the "weight" cludge
if core removed all the cludgy x4 math of weight and legacy fee. and just had a straight base 4mb blocksize along with less sigops per tx it would fix alot of things and give alot more utility without breaking anything.
there are alot more things besides all this that could be implemented to help improve bitcoin scaling too.
such as the issue with 'spam' transactions that spend every block, bloating up the block with transactions that in real world go no where but just paying the sender back just for shits and giggles.. every block. thus taking up space for no reason..
this can be solved easily by a fee mechanism that makes a transaction not pay for just its size. but also its age. EG if a transaction is spending a utxo thats only a few confirms deep. they pay higher than a utxo that is hundred+ confirms deep. EG if your spending every 10-20 minutes you could pay alot more then those that pay one or twice a day.. and alot more than that those that pay once a month.
this would make it extremely costly personally for the spammers
and with this idea.. it would mean not everyones competing fees would rise.. and it would be more personal fee based on personal needs of size and time since last spend.
unlike the current game of everyones fee's go up due to spammers because currently. everyone is "competing" due to a lack of a fee mechanism and so when spammers fill blocks everyone else has to compete and pay more to get noticed.. which is a bad way to work currently
by charging just the spammers more . it makes spammers not spam as much meaning more chance for everyone else to get their transaction seen without having to compete by fee rise races.
Too much segmentation of development can also mean that the projects drift apart, maybe it’s not a bad idea to be forced to go trough the core process, because we can’t forget that it’s also about getting consensus in the community.
if there is no other candidate at an election.. there is no election. .. its just a one party government in power day after day..
