I do not give a fuck what the ratio will be, because I know people will warm up to SegWit as soon as they see the impact it will have on the network. We will be able to fit more transactions into a block, without having to increase the Block size, just by ignoring data that are not going to be used.
We also spank malleable transactions & increase security and it also has the potential to decrease bandwidth requirements for SPV nodes.
We now have a network geared for the next evolution to the LN. ^smile^ So play around with ratios all you want, we do not care.
Has anyone identified any real downside or risk with SegWit? I've not heard of any. So the only reason I can think of for someone to oppose SegWit is just to hold it hostage (keeping under the 95% threshold for activation) while promoting their own alternative scheme. I would hope such a tactic fails, as there is nothing preventing worthy alternatives from being implemented later on their own merits.
segwit is a big code rewrite.. though the features offer something. the actual coding should not be deemed uptopian dream of safety.
nor should everyone running just one codebase. or have all pools running one codebase.
the whole point of bitcoin is not to trust third parties 'because they have 4-6 years experience' or 'because they are well funded by banks' but instead have a diverse system that self sustains the network independently. where features grow where diversity can all come to their own solution that all nodes are happy with(consensus)
decentralized, diverse distribution should matter more then features of everyone jumping to one codebase.
the devs will say its been running for months.. but that is on some sandbox testbed, never needing to care about spending real bitcoins on the real blockchain of 7 years worth of data. not even thinking about users headaches of having to move funds from privkeys to seeds to even be able to use it. or users communicating with the codebase via RPC
if there is a bug in one codebase and everyone is running the same codebase your all screwed and old nodes wont be able to defend against it because they would blindly accept the erroring block because they cannot validate independently. resulting in a whirlwind of orphans or at worse keeping the error locked in the chain due to not vetoing it out.
this is why the 95% is required and also why no one should run just one codebase. diversity reduces the risk of lengthy orphans while also having different codebases to spot a bug where one codebase might miss.
old nodes cannot veto out changes. they can only blindly look passed it. some say its a positive but you should also look at the negative such as not spotting a bug
as for using it, rpc calls have changed, the import key/seed mechanics and other things have changed so it requires alot of playing around before actually using. and ensuring everything works within your system before trusting it to be confidently used by your customers. EG deposit/reserve keys need to change and funds need to move and get re-audited by merchant services before they are happy and confident.
anyone shouting "its brilliant, perfect, it needs to run now now now, everyone jump into one band camp and let the devs control decisions"
are people sold on the brand and dont care for security or bitcoin or the network.
the core devs have shunned alternatives to the sides, saying
even after being coded alternatives need to be delayed by a further 18 months (hypocrisy when people feel 1month seems like a opposition delay tactic)
even ones actually with live code fully working on bitcoins network have been dismissed and falsely called altcoins
even gmaxwell has been telling other implementations to intentionally split rather then treating bitcoin as a community effort to help ALL implementations come to a agreeable consensus.
gmaxwell and chums have only been lobbying the pools. not the merchants. because all they care about is speedy activation, not utility
even recently the core devs have been downselling the proposition. because peoples care of malleability was about double spending.. which even with malleability gone, double spending can still occur due to new features of RBF and CPFP. thus malleability fix has not/will not fix double spend risk
everyone is screaming utopia about segwit making LN possible. but a flaw of LN (address re-use) still has to be addressed
thus all the promises of utopia in late 2015 are getting diluted and core could care less about capacity growth onchain. their agenda is fee-wars and onchain suppression to move people offchain.
as for the linear/quadratic debate. who actually has a legitimate reason to make a single transaction of 4500 input/outputs. there are many many ways to solve quadratic delays, such as limiting signops. thus avoiding large tx attacks
