In Wuillie's presentation at Scaling Bitcoin Hong Kong, I believe* he stated that by looking at recent transactions, the current scaling factor would seem to be about 1.75x. Or that signature data is slightly less than half the block data.

*my memory is at times faulty. But I'll stick to a claim that some prominent Core dev stated that analysis of recent blocks led to this figure.

Others I have seen use a 4x figure - totally dependent upon an assumption that multisig become a much larger portion of the transaction volume.

For this little branch of the discussion, the salient point is that any node that performs validation (i.e. any node operating in a trustless manner) must process not the claimed 1MB block size worth of data, but an amount of data that reflects the signature data as well - 1MB multiplied by this (instantaneous) scaling factor, be it 1.75x, 4x, or whatever else represents the proportion of signature data associated with the transactions included in that block.

Dude, I posted a link.  Who's the hysterical one here again?

And imbues my focus with hysteria?   uhm, ok 

You obviously are not interested in any kind of a conversation here, so I will just leave you to what you were doing...

Meanwhile, anyone who actually gives a damn about understanding the issue will still have access to the link I posted.

Many understands the statistic thats why conservative value of 75% is choosen so you cant claim the change is tiggered by minority, or to be exact, there is real chance of this happening by variance.

ok alot of people are discussing the consensus, the debate about separate chains and not many seem to be using logic.

so here goes


A.
this scenario is where just one miner with the most hash power compared to any other single miner.
although it appear the miner has 27% of hash power, effectively because it is adding more transactions the processing time is longer so the 'feel' of the hashing speed is more like 24%, thus its not going to be racing ahead making longer chains and only has 1 turn on average every 4 blocks to win.
thus with 90% consensus against it.. that 1 block out of 4 would get orphaned because the other 90% would ignore it and the next block they add wont have the over1mb block in its chain.

so there are 2 defenses, not enough hashpower to race ahead with over 1mb blockheights, and not enough peer consensus (nodes running same implementation).

B.
this is where there is a hashrate power of over 75%. but even in this case there is only 40% peer consensus, and so with all 10 miners connecting together to show each other a solved block. 6 out of 10 would orphan off that over1mb block. a bit more complicated to explain, but basically the end result is that eventually there is still just 1 chain of the under 1mb blocks, once the miners communicate and sort out the orphans.

C.
this is where there is 75% of peer consensus where the hashrate is over 90%. in this case the majority wins on both counts and the minority (under1mb) gets left behind with a chain that does not sync up.

remember. 2mb rule allows both under 1mb blocks and over1mb blocks.. so even if a 2mb consensus has not been reached the 2mb implementations would still happily accept the valid under1mb rules.. there would not be any hard forks as orphaning will rejoin any disputing blocks.

however old 1mb implementations, if they lose dominance in both counts. will end up with:
1. having a chain that doesnt sync up because it rejects the majority of blocks
2. the amount of peer nodes with an altnative chain would be limited.
3. miners who continue to mine in the minority wont be able to spend the efforts as its rejected.
4. would have to upgrade to regain sync ability and earning potential.

but as i say. this is only a concern for those that dont upgrade to a 2mb implementation. and only then if scenario C came into play.

so there is no issue in users having a 2mb implementation, where the setting just sits there as a buffer, doing nothing until scenario C comes about.
what is more disasterous. is that bitcoin-core refuses to code a 2mb implementation which means if a scenario C came about.. the entire community would be left behind with unsync-able nodes.

so just as a line of safety for the possibility of something happening in the next 3 years, its far better to allow users to have the setting there, just as a buffer.. than to refuse to give people the buffer and scream that the disaster is someone elses fault.

as i said having the setting for users, is not a call to arms. its not a red nuclear button. its just a setting that sits there as a buffer.. just like the 1mb limit was just a buffer while miners were making only 0-500k blocks in 2009-2013.

miners logic and psychology shows and proves that they wont risk adding more transactions (increasing processing time) if they think there blocks will get orphaned. and so they are not going to jump the gun. its not in their financial interest to do so unless the community is ready to accept their blocks, so they can atleast spend their rewards.
and anyone trying to imply nefarious intent of some miners.. ill refer you to scenario A, and possibly B(if collusion and naferious intent are combined). but in general long term reward earnings outweight possibility of short term nefarious intent. so relax

now onto bitcoin-core
we all know, bitcoin-core is a full node client. anyone interested in being a full node in april will need to upgrade to remain full node status, due to segwit. otherwise they are automatically causing their non-upgraded clients to become "compatible" nodes. not full validation nodes.

so knowing full nodes will be upgrading just to stay full node status. i think the April update should also include the 2mb setting buffer. that way even 3 years later or 6 months.. whenever the miners feel comfortable to be scenario C.. it wont impact the community because the community is already prepared.

remember the 2mb rule is not a rule that says "you have to accept blocks over 1mb". its not a nuclear launchcode of bloat.
its a buffer setting of "anything from 0b to 2mb" which includes normal blocks as they stand today.
again just like the 1mb was a buffer while miners were happy below 500k a few years back

so while miners stick safely to their 1mb rule the community can happily be prepared for 2mb possibilities of the future.
if bitcoin-core refuses to prepare the community before miners act.. then it would be bitcoin-cores fault for users not being able to sync once consensus has been reached.

ill just leave this image here for Lauda

My understanding is that the Chinese miners are now not going to back Classic so it is thankfully REKT and therefore I feel no need to continue this (now thankfully unnecessary) topic.

I am going to go back to focusing on working in this field rather than trying to herd cats.