Quote from: achow101 on January 30, 2017, 06:03:34 PM

A fork most certainly could have happened because of the BU and SPV miners. Those miners make up nearly half of the entire hash rate of the network. If the SPV miners and BU miners began building on the invalid block, then there would be two branches that are just about the same length. As we have seen in the July 2015 fork, the SPV miners could accidentally cause this to happen. One chain would probably die off once the human operators got involved as happened with the July 2015 fork.

it was disregarded in 3 seconds.. a new block would not have built ontop if it..
if it stupidly did. then the reject would "officially" be named an orphan event in your eyes because the reject becomes the parents of the child and the parent and child still end up being cast aside.

WAKE UP

stop making mountains out of mole hills about events that didnt happen and then you meandering into fake narratives of if's and maybes..
. especially when the real problem of the real non event.. which you worry about concerting a bilateral split, would have been caused only by CORES REACTION to the mole hill. by banning the nodes to make the mountain... not due simply to a reject/bad block/invalid block/orphan.

rejects occur alot. orphans happen too. but CORE banning NODES is what would cause bilateral forks.
however sticking to consensus would have just dropped the dodgy block and thats it.. no drama.. gone, forgot about, life moves on without it.. non event

CORE have set the 'banscore' biasedly high for this event. but its funny that core then went and blamed it on non-core nodes for why CORE had so much biased in such a non event.

Quote from: achow101 on January 30, 2017, 06:03:34 PM

Now those miners should have learned from the July 2015 fork that SPV mining can be problematic, but I don't think any of them have stopped doing SPV mining. It really all depends on how their validation systems work, but such a scenario is entirely possible as we have seen in the past.

I apologize about some poor word choice in my earlier posts. I will fix them.

Quote from: Lauda on January 30, 2017, 03:08:39 PM

Most definitely. I'm certain that there would be a fair amount of support for a proposal (post SegWit) that increases it somewhere between 10-20% yearly. However, there is definitely going to be very little-to-no support for proposal such as the one from Luke-jr. That proposal even goes as far as reducing the current block size. Cheesy

Supposedly Luke-Jr is going to modify it so that by the time the hard fork is predicted to be ready to activate, the period of the smaller blocks has already passed.

both luke Jr and Gmaxwell are devising the worse methods of dynamic block implementation.. maybe not for the intention of breaking the chain to make a point.. but to just to scare people from wanting to accept them as the ruse to then pretend people dont want dynamic blocks..

EG here is a banana, but if i wipe it under my armpit after a sweaty game of tennis, i can make a banana lover decline wanting a banana and then tell the world banana's are now bad because banana lovers refuse to eat banana's.

Gmaxwell wants to mess with the block reward and luke wants to make blocks shrink.. both are silly and are going to fail the user desire.
lets delve into lukes idea.
if all nodes can accept 1.5mb blocks.. they by default wont reject a block of 0.75mb or an 'empty block'.. because bitcoins consensus in that activation is that anything under 1.5mb is acceptable. so there is no need to dowgrade nodes.
much like todays reality we dont need to downgrade nodes consensus rules if a pool decides to create 'empty blocks'

lets delve into gmaxwells desire of an idea.
if pools X wants to increase 25% the pool C makes block with 75% reward. and the the other 25% is handed over to the next block solver.
firstly messing with the block reward is dangerous, so using it as a ploy. makes a dynamic block more dangerous to get people confident about

but not to due with lack of desire for dynamic blocks, but for HOW they are implemented and what penalties/downsides the core devs decide to add to scare their sheep. its obvious even now what their insidious plan is.

like they said 'look the community asked for 2mb or even 4mb.. we are offering them 4mb weight and they are declining' - fully aware of why the community is declining 4mb weight.. but core devs not being ethical to admit the reason for not wanting 4mb of empty gesture