Quote from: ETFbitcoin on Today at 01:01:14 PM

Quote from: tiltedIceCream on Today at 12:44:11 AM

A real-world case study of this approach can be showcased through web browsers. Sure most browsers are based on chromium but browsers like Safari and Firefox (and spin-offs like the Tor browser) have unique approaches to protocol implementations that many internet users value.

It's great example. Now i'm inspired to try running alternate Bitcoin full node implementation and will write short review/guide about it within next few days.

Quote from: franky1 on Today at 09:29:11 AM

--snip--

as for saying 'its just following consensus'. which you forget, whom is in control of consensus changes. yep one dev team, and who is that dev team.. (rhetorical)

Just wondering, do you think are any implementation which do more than following most/all consensus? If yes, do you currently run such implementation (even if it's not running 24/7)?

its not about there being different wallets. its about the hierarchy of proposals of upgrades being cores dominion.

im not saying 'competing' nodes need to fight core. im saying diverse brands not sponsored by the same umbrella company being the decision makers of what gets into the release candidate that all wallets follow.

EG if there is a proposal.
instead of core just making it like version 23.2 and everyone just blindly updates to it and by default it gets activated
or core puts in a mandatory activation if the upgrade takes too long, (disconnect nodes not flagging or rejecting blocks not flagging to force an upgrade by a deadline)..

but instead where all brands release a version (a) of their own codebases that also has a proposed code addition. where people wanting a feature but not wanting to have to download core. can stick with their favoured brand and still vote it in. and also the other brands dont lose adoption or get treated as enemies when a proposals is submitted because all brands offer it as a version(a) to allow their userbase the choice. thus it becomes a more cooperative open and decentralised vote and not a brand fight.

it also helps by having all custom wallets ready for activation rather then waiting for a core vote to then decide if its worth changing custom wallets to then add new code. thus by al brans having the code before activation and offering it to its users, if/when it activates all brands are ready. thus all stay on an equal footing with core, rather than follow the leader

this ofcourse means that if another brand had a proposal. core too should have a core version 24(a) include that proposal for the core fans to have the option. where if all brands with a version(a) got majority participation, flagging, and acceptance. then the feature activates.
and core also follow the new change even if they didnt 'invent'/patent/get sponsored for the feature/upgrade

where nothing happens unless feature activates (so no cries of 'forking' for just offering a proposal)