here we go someone else trying to meander all the types back into on umbrella term and then make that term sound bad. by only mentioning the worse cases

ethereum did not split and survive due to consensus.
it was not just 2 differing rules that battled it out in an orphan war.

they literally walked in different directions never looking at each other.
learn --oppose-dao-fork
im literally spelling it out for you which google can guide you further
--oppose-dao-fork is not a consensus orphan war. but a surrender and retreat to different corners and never look at eachother

ethereum should not be used as an example because ethereum did not use consensus.
no bitcoin proposal should use the intentional altcoin maker. all the blocksize bips that are viable are not using the intentional altcoin maker
the community want a consensus driven vote to grow on one mainnet. not split.
so why even mention something that requires adding intentional rules to ignore and walk away.
it has nothing to do with a viable bitcoin scaling. but everything to do with making clams2.0 (which the majority do not want anyway)

if people stop umbrella terming the creation of an altcoin to be the definition of a hard fork. and start running real simulations of using consensus
if people stop thinking that orphans only ever happen when an altcoin is potentially forming. and instead realise orphans happen more times then they think without an altcoin forming
.
they will realise consensus and orphans are part of bitcoin and a security feature built into bitcoin from day one.
banning nodes is not built into bitcoin. so atleast learn the difference and stop doomsdaying a normal consensus driven fork

as for the ban. the ban is not permanent.. its 100 seconds or any amount a node chooses.. (then when time is up the orphans return and wipe out that work of the minority in that time)
also the ban is if someone is intentionally broadcasting a block not requested and doesnt fit rules. (a DDoS)
however usually theres a handshake.
EG A requests data. gets bad data doesnt make B the bad guy that should be banned.. because B sent something that A requested...

unlike if lets say C (a malicious node) DDoSed A with unrequested data
in this event C would get banned.

but A would simply just not ask B to resend again. and would look for another source while keeping B active.

unlike the ethereum intentional split where its a permanent ban by extra ban rules being added.

its also not recommended to use the ban (meant for DDoS) to be used as an intentional split. (by adding in new rules)

as dannyhamilton has meandered upon.. the term hardfork has lost its meaning. and become an umbrella term that can be many things.

he however twists the scenarios to fit a rhetoric of A (staying low is best) by not staying on track with his scenarios.
by scenario 1
being consensual fork where A wins..

but for scenario 2
he doesnt use consensual fork where B wins.(like a mirror of A)
instead 'suggest' consensual fork where B wins but throws in intentional splits to make it sound bad.

in scenario 3
he doesnt use consensual fork where eventually A wins.
instead he ignores consensual fork and talks about controversial fork and intentional splits.

he should have, to be unbiased done a scenario 4.
consensual B majority, no mention of intentional split

he should have, to be unbiased done a scenario 5.
consensual B majority, A splits

but no he wanted to make B sound bad

but hey its funny seeing them try throwing controversial, consensual and intentional split under one buzzword to scare people. rather than explain the details and differences and what is actually involved.

hardforks under bitcoin resolve themselves due to orphans/consensus

an intentional split like ethereum (--oppose-dao-fork)
are things that are NOT proposed in any viable BIP and are not a hardfork. they are an intentional split(altcoin maker).

dont think of forks as 2 persistant chains. think of it as one chain that branches off and one limb will be cut off.. once orphan drama sorts out the victor.
any rational and viable fork should use consensus. to reduce orphan risk

a controversial hardfork is when the consensus is low. meaning LOTS of orphans (a tree branches out, you cut its limb. another branches out, you cut its limb. over and over)
again not 2 persistent chains

a consensual hardfork is when the consensus is high. meaning minimal orphans (a tree branches out, you cut the weak limb quite fast and continue the strong limb)
again not 2 persistent chains

a softfork changes a rule without branching, unless there is a bug.. (like the leveldb upgrade in 0.8 that started as soft. but ended up as hard and controversial)
a hardfork has a bigger chance of branching off even without a bug.. depending on node acceptance levels.

however
a controversial hardfork can be seen by the leveldb bug.
yep changing to leveldb was suppose to be a soft upgrade.. but ended up causing a controversial hard fork where there was not a clear majority running 0.7 or 0.8
where by 0.7nodes hung.. and were not syncing..
it was not 2 persistent chains. 0.8 continued on. 0.7 hung and didnt persist.

a decision was made to downgrade back to 0.7 and fix the cause later. thus cutting off the 0.8 limb rather than leaving 0.7 hanging in the unsyncing abyss of screaming out orphans. due to the high orphan risk

if there was a clear majority wanting to move forward. it would be more prudent to get the minority to upgrade..
if there was a clear majority wanting to stay back. it would be more prudent to get the minority to downgrade..

these days. pools wont even do anything unless there is a clear majority acceptance. they want to avoid orphans.(zero reward)
merchants want to avoid orphans(double spends)
fullnodes want to avoid orphans (bandwidth, loops, hangups)

hang on.
lets get this right
so icebreaker. who was happy with gmaxwell R3cking hearn(r3) . for being paid by bankers.
now icebreaker seems less friendly towards gmaxwell because its now public knowledge gmaxwell is paid by bankers too.

sidenote:
gmaxwell hates gavin.
where gavin(Bloq) and gmax(blockstream) are both paid by the same guy coindesk(DCG) who is involved with hyperledger(bankers altcoin) where all three (r3) (Bloq) and (blockstream) are highlighted as involved with hyperledger directly (members).. plus indirectly via investors

so hearn, gavin and gmax all paid by bankers and all have direct AND indirect ties to hyperledger ..

and then we have gmaxwell trying to take the moral highground pretending to be 'all about the bitcoin dcentralization' and 'it will all be ok' and anyone not blockstream friendly must be an altcoiner and should F**k off.. and if you are blockstream friendly you should patent your code under blockstream DLP so that blockstream can charge you FRAND royalties if you want to revoke your blockstream owned licence from your software

while gmaxwell plays with hyperledger and monero.. oh and multimillions of banker FIAT..

gmaxwells mindset
national elections.. sorry folks citizens cant vote.. civil servants cant vote.
only the senators can vote.
but dont worry civil servants. YOU will notify yourself that you have been made obsolete. the day your obsolete..
but dont worry your still citizens. nothing wrong with being just a citizen. dont worry.
you can watch from a distance. its then upto you to reapply for a civil servants role under new contract. but dont worry. we done this in a way that you cant go on strike against it..
now all we have to do is bribe the senate with a few all-inclusive weekends

dont worry there nothing wrong with being downgraded to a citizen, dont worry

citizens =not full nodes
civil servants = full node
senate=pools

you scenario1
==========
you say B will have trouble receiving B blocks because A nodes wont relay it. your right so B sticks with A chain, due to high orphan risk. and because A's are acceptable to B. so no harm sticking with A. (ergo network does not implement new rule A rule still enforced)

you scenario2
==========
but you forgot scenario 1 flipped. A will have trouble getting A blocks for the same reason as scenario 1.(majority B isnt relaying A blocks if B blocks have the height) thus leaving A dormant not able to sync. here ill explain

without ignoring B.. A ends up requesting B's blocks because of height and rejecting the data due to size. requesting B's blocks and rejecting. requesting B's blocks and rejecting. endless loop.
(ergo network implements new rule B is enforced A nodes cant sync)

your scenario3
===========
reality is lots of orphans many times a day. branch out, kill off .. branch out, off kill.. branch, kill off.
eventually it settles down presumably to A due to headaches of high orphan risk and knowing A is acceptable to ALL but B is only acceptable to HALF..

but if they were to keep up the orphan fight.
if B attained a higher height. refer to scenario 2
if A attained a higher height. refer to scenario 1
logic dictates a drawn out orphan fight (not a persistent 2 chain fight) results in settling for the most compatible.

think of it this way. if personB can hold 10 oranges but personA can hold 5 oranges.. is there a problem with handing B just 5 oranges if he is not already holding any...... nope.
opposite cant be said for A. they will be dropping the oranges and asking to pick them up. eventually either A shuts down never holding oranges. or B agree's the rule should only be 5 oranges for the benefit of the network (unless B had super majority to not care about A)

its not 2 persistent chains
EG
| |
| |
| |
| |
| |
 \|

but orphans, many branches that get cut off
\ |
*|
 \|
*|
 \|
*|
 \|

summary
======
pools are not stupid enough to risk their time/income on high orphan risk. so your scenarios are meaningless..
if B didnt have majority. B would stick with A rule to avoid wasted time/money.

but i atleast helped by highlighting what would happen if pools did do it without super high majority, due to your thought process of thinking that pools would stupidly do it at lower numbers.

the only way a minority branch of A survives is to intentionally avoid connecting to the opposition and forming an intentional altcoin via banning IP addresses and forming their own DNS seed/network

no need??
you do know FULL NODES want to be FULL NODES for a reason right!!
a soft fork is not about keping full nodes as full nodes. its about bypassing opposition to push a change without a full node vetoing out a change.

much like avoiding an election by killing the president and having the senate vote in someone without the countries consent.
in the UK we never voted in Theresa may. and she already is causing grief and we have nothing to do to stop her.

seriously i know you love work arounds to not fix problems but just jump passed problems (you have displayed this many times). but full nodes want to be full nodes for a reason.

so saying that a full node will be downgraded but shouldnt care, and shouldnt need to worry because its not a problem.. is like saying you should go back to grade school and not worry about the world around you because your opinion doesnt count

though you STORE the blocks.. old node not validating segwit wont be independantly testing and veryifying a tx within a block if the TX is segwit.
it just deems it as acceptable without even fully checking it.

its like having a wife. she goes to the supermarket and checks the fruit is ripe. you double check its ripe, but now she is saying to you 'just grab a fruit it will be ok, put it in the trolley nothing is wrong.

full nodes are like food connoisseurs/critics. and they want to be fully critical and checking everything for a reason. if they are not checking every part of the stuff they get. then they are not a full node..

in short they are now a trolley pusher not a fruit connoisseur
turning 5000 connoisseurs into 3000 trolley pushers. 2000 connoisseurs can cause problems for the meal(network) especially if those 2000 all have the same tastebuds (running one implementation from one source)

if they are not being critical about the data then they might aswell save the hard drive space and be relay nodes. because they cant independently trust what they have been handed.

find something your fussy about, whether its who cleans the house or who pays the bills. where you want to be in control. then hand it off to someone else.

nope.
blue line
soft fork is where there is a change. but it doesnt trigger a new branch, doesnt cause an orphan

first red line
hardfork is a single chain that branchs off and then is cut off when eventually orphaned.
if there is no clear majority. then it branch off often. then get cut off often. its not 2 chains. but multiple branches that get trimmed (orphaned)

intentional split is where the branchs survive ONLY because they ban opposition from connecting to them and ignore/dont receive the orphaning blocks (avoid consensus orphan mechanism) and instead link up in their own clan to a pool(s) that have similar rules.(this is not consensus)

second redline
the 32mb rule is a protocol rule. still inplace and used due to risk of packet loss..
below that there is a consensus rule, nodes have(core default 1mb)
below that there is a policy rule, pools have.(core default 0.7mb, but most pools adjust this to 0.99 immediately)
the policy rule is a pool 'preference' which before 2013 they had it at 0.5 and slowly increased it since.

third red line
if there is no agreement pools wont risk it.. if they are stupid and do risk it, orphans take care of it. in short it wont happen unless there is agreement and eventually, orphan drama or not, there is one chain heading in one direction building ontop of the last.

the only way to make a new network is intentionally banning the opposition to avoid consensus/orphans so that both dont orphan each other out

join LN and have atleast 7 types of fee's and the ability to chargeback the entire contents of the multisig even when the close session has been broadcast. (CSV revoke codes)

but core have been selling the "backward compatible".. now they are selling the need to upgrade..
they should have sold the need to upgrade from day one.

bitcoin doesnt need a CEO

but the boysclub of core need to stop being selfish and circlejerking in their club and learn things like
consensus
compromise
community
co-operation
coexistance

it shouldnt be too hard the first 2 letters of the words are the first 2 letters of their brand name

and dont play games saying core are open to be on the same level playing ground with other implementations.
they chose the word CORE. because they want to be at the centre

flip flop

"its a notice"
lol!!!!

so now you are avoiding the word "obsolete" again, by distracting people by calling it a "notice".
oh and from your screenshot the guy never said you sent a "notice" he said that the "notice" wording mentions OBSOLETE

as for the rest of your post.
my mindset and others are proved right. you have made a change and tried to hide it by making new nodes not see alerts and by underplaying how old nodes will treat the change.
even now you want to downplay the ALERT by calling it "a notice". lol

how about be upfront from the start and just say old nodes wont be fully validating 100% so upgrade. instead of "old nodes are fine, its only a notice, your free to decide what to do".

after all <2000 are ready to validate sgwit. which is a BAD BAD thing for the other 3000+ to rely on other nodes. instead of the network independantly fully validating every bit of data it receives.

you should have done a NODE first. then bribe the miningpools with free party weekends.. not bribed pools first and downplay effect of the network nodes after

old nodes we both agree will be downgraded. the issue is that there is no node consensus to even give them the choice. nodes cannot veto out an option if they dont like it. you have simply skipped letting nodes choose. and went straight to bribing the pools
i think its been 4 little papering social events your employer has organised this year.

a couple of them were meant to be fully discussing possibilities of things like dymanic blocksize. but your employer said those couple events were just social, not intended to formally discuss scalability.

from what i can read.

one guy argues that althought NEW implementations will not see an alert.. OLD implementations can. so old implementations CAN be alerted.
as for the content of the alert. checking github. it does show "obsolete" as a standard message when a node see's a rule break.

by alerts it does not mean 'human broadcasted' alerts. but default internal node rule checking alerts (which are still active)

so old nodes will see this .. emphasis OLD nodes will see alerts.
emphasis only these versions have human broadcasted alerts disabled
Bitcoin Core 0.13.1, 0.13.0, 0.12.1

then i see Gmaxwell chime in to wash over the post first by distraction "its been disabled".. yea ONLY FOR NEW NODES!!! and only the human broadcasted alerts
then he uses an demonstration of an alert. could have been grabbed anywhere any time. to not argue the word "obsolete" but to argue that the demonstration had gavins name involved.

i think gmaxwell totally missed the point and was trying to poke at the name "gavin" and ignore the topic word "obsolete"..

how boring gmaxwell. arguing about gavin when the topic was about an alert that even github proves says "obsolete" to the old nodes

the definitions have been plagued with word twistings and doomsdays.

right now many implementations have a rule to accept 2mb-16mb blocks.. guess what nothing happened.
in 2010-2014
many implementations had 1mb while blocks were only 0.1mb-0.9mb.. guess what. nothing happened.

mining pools will NOT make a block bigger than majority acceptable amount unless majority nodes will accept it.. not due to causing an altcoin. but due to ORPHANS.

yep thats right at the moment there is a 85% risk of orphans because only 15% of nodes have more than 1mb base block rule.

this risk is too high for pools to lose their income.. its not nor ever has been about making an altcoin. just orphan risk.
to create an altcoin the nodes need to literally ban(ip/useragent) themselves from the other side to not even see the other side to not b involved.

ethereum done this with its "--oopose-dao-fork". thus avoiding consensus orphan mechanism and splitting the network by ignoring each other. as oppose to orphaning each other.

once you realise that the base block can grow more than 1mb by having nodes accept more than 1mb. just like they accepted more then lets say 0.2mb from 2010-2016 you will see all these doomsdays about splitting the network are foolish.

the only result is orphans.
the risk of orphans reduces the more nodes that accept the rule.. pools are happy with a 5% risk which is a 95% acceptance.

in short dont think hard fork=intentional split. just think orphan risk and the losing side when the orphan drama subsides simple wont sync to anything.

again pools wont risk it without majority consent.

i feel the op is talking about the whole bitcoin openness trustless ethos. more so then the literal meaning of "opensource"

WIP is good. it means they are peer reviewing, testing on mainnet and double checking... rather then "blind trust and run"

its like Windows. never blindly install and run a new version of windows until its atleast released its first batch of patches

as above.. but with added:
those pools, being mainly BTCC, slush. they quickly rushed to flag their approval. this means the day the final code release was released they didnt tweak it and test it. they just ran it.

most pools have been watching the code since june (first real bitcoin testnets began) but because between june and october the code was continually changing many were not gonna bother writing their own implementations until final code was released. to then emulate.

so by running the final software pretty much as soon as it was released shows that btcc and shush didnt really independantly test it on bitcoins MAIN NET before flagging. they just trusted the TESTNET tests were adequate and just ran with it.

we should/may see more pools eventually flag for segwit after doing some MAINNET tests. but dont expect anything before the new year to get activated.

and as for anyone blaming Ver right now.. Ver only has 9% hashrate not 75%. so atleast stick to reality of realising its more then just Ver saying no right now.

dont worry about "question authority". he stopped questioning authority years ago, now he just seems to accept authority.