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.

then we will sell bits (100 satoshis) instead of btc's

EG we are no longer in ancint egypt selling gold by the tonne. we are not quite at the stage of selling gold by the gram as the norm. but trying to suggest we make more tonnes of gold or sell gold by the microgram when it has only ever been measured: gram->tonne. messes with scarcity.
its stupid to create more bitcoins or increase CODED units of measure.. that ruins the whole premise of deflationary scarcity.

EG in this village there will only be 2.1 quadrillion gold coin segments. which put together make 21million gold coins.

enough for 21million villagers to have 1 gold coin or 21m villagers to have 10,000,0000 gold segments each.

2 weeks later. ok now everyone can now have 10,000,0000,000 segments.

scarity dies

the boysclub usually ask you to discuss it with devs in IRC first. then join the mailing list. discuss it further and explain it in more detail and use the github only for final code.

unless its a spelling mistake you are usually met with many barriers and slaps to your face if you even hint there is an issue or a better way.

most objections to issues get shut down due to boysclub protection and rants about they know how things should be done while chest thumping they know better and to quietly tell outsiders to shut up go away and if you dont like it, fork off and play with an altcoin with their preferred code.

so although the code is open. to view. what is viewable it not always clear. and if you do translate it and see an issue. then trying to sort it or overcome their boysclub is met with what can only be described as the opposite to an open community

many do know programming languages. but if the code uses undescribed variables or just randomly selected characters as variables, where no comments describe what the function does.. it is a headache

there is a major difference between quickly reading code to see if it has any "kill commands" and reading it line by line to see what the code does.
it took many people alot of time to read line for line and translate it in their head into 'pseudocode' and then work out what a function does by simulating it. which all can be solved by some basic etiquette. most of the people that actually bother reading it line by line and do simulations are those that then make their own implementations that run better. due to the boysclub of core being close minded to outside criticism.

the issues arise when one coder does stuff that 'works' but does so in a fancy way which could have been done in other ways. though passing a review test, the peers are not simulating it to think of other ways it can be written. they just put their thumbs up and move on. 'trusting' the dev that wrote it.

there have been many times we have seen bitcoin toyed around with later purely because one function passed a review, but later finding out if a function was wrote differently it would work better.

just because 90 spell checkers put their thumbs up, doesnt mean the code is perfect. doesnt mean all 90 spell checkers have run simulations or thought of different strategies. most of they time they quickly browse the code doesnt have 'kill commands' and then "TRUST!!!!" the dev that wrote it knows what he is doing, thus resulting in a fake positive peer review

its why there are all the core fanboys throwing out doomsdays. they dont run real simlations or actually read code, they just read summaries and other peoples opinions and trust.. trust of one person who trusts another who trusts another even when all 3 have not read a line of code. makes things go wrong.

take a notable name in the forum.. Lauda.. he doesnt know C++ yet has been very vocal of his trust of core code and core devs. and people then trust him. all because the code is not laid out.

take the way devs implemented the tx fee.. not only subverting coded methods of 'priority' which would have alleviated the war, but also using 'averages' which dont make the fee's drop reactively when demand is low. but actually keeps fee's up. even when one block is low demand.
EG take a 25 block average.. imagine first 24 are 0.0001 and the 25th is 0.0025 then look at the 'average' after that.. even if demand was near 0 and no one was pushing the fee up.... the "average" itself pushes up


so although the tx fee passes 'peer review' its sloppily coded in a way that is not reactive to low demand. or cares about using code logic to show real priority. all its doing is pushing/maintaining a high price even when demand is low.

it requires pools to avoid using the 'average' and to accept cheap tx's just to break the cycle that the 'average' fee war game is playing.

the dictionary definition of open source is that the code is not locked away in some vault that only available to authorised people.
BUT
the concept and context of bitcoins openness is that anyone should be able to get involved. which can actually be hindered by the ettiquete some devs have. especially if its required that their code should be peer reviewed.

this is how bugs happen. by not clearly laying out the code. people gloss over the code and just think. 'this guy looks like he knows what he is doing lets just let the code fly' and not actually reading line by line and running scenarios.

its already happened a couple times even after being so called 'peer reviewed'

OP is having issues with:
updated documentation that actually explain it properly
code lacking comments.
signposting to the best source of code, comments, documentation.

though it is open source, the organisation of HOW its open is missing.
back in my day nearly every line of code had comments to explain what it does.
back in my day nearly every line of code had namespaces/variables with WORDS that explained what it does not just characters

there are many modules that do have comments and variables with understandable names. but there are some without.

EG https://github.com/bitcoin/bitcoin/blob/master/src/secp256k1/src/ecdsa_impl.h (grabbed randomly)
if you see a module assign variables 'b1' 'rs' 'rr' 's1' 'u1' 'u2' 'sn' 'pr' without commenting what they do. it helps no one.

yes with a couple re reads and running it through your mind in what used to be called 'pseudocode' you get the gist of it eventually. but its still badly organised

the funnier part is that many core devs get very snobby if forum posts are not wrote in 100% white paper approved level of English grammar, even when knowing forums are just for common/social communication where only 10% of the planet deem English to be their first language. but their own code lacks the basic coding etiquette

i agree although trezor is a hardware wallet. to get full functionality you need browser add-ons and connect via their server. (facepalm to obvious trojan/hack weakness via phishing sites and hijacked add-ons) though you can link it to other desktop wallets like multibit, etc. but still..

though trezor and other hardware wallets are one security 'step up' from the standard desktop installed software due to the privkeys/seeds not being stored on the computer the app/add-on is stored. and many steps up from just a webwallet...its still not perfect and still has points of weakness.

the two main desktop wallets that are compatible with trezor and can be deemed trusted are
electrum and multibit

advantages of trezor:
private key/seed held separately from computer. adding the layer of defense

disadvantages:
watch out for any desktop app/browser addin/page telling you there is an error and you need to type in your seed. be cautious to check its a real error and not a phishing attempt

a true hardware wallet should not connect to any middlemen service or require anything installed on a persons pc to function. hopefully future hardware wallets will be true independently and fully run from the USB hardware device, without risk of fake "error, please type in seed" phishing scams via trojans.(no requirement to download/use anything on pc/middleman webservice)

imagine bitcoin priced against not fiat.. but "cost of living index" (yes its a real metric, go research it)
EG
no matter where in the world you are, you can say i want enough bitcoin that values at around 10 loaves of bread.
no need for someone in africa to need to convert m-pesa to a dollar value and then look up the bitcoin price.

they just use the "cost of living index" and automatically know what bitcoin equates to by knowing the average price of bread or other produce in their native country. thus removing the dollar as the metric

but ECC is more vulnerable than SHA256.  not the other way round.
but bitcoin can adapt. new keypairs will be introduced using different curves and higher hash security

lol biometrics. nope thats not a solution, thats:
worse than a password.
better then a 4 digit pin number/door code

sorry but the entropy of biometrics is weak.
also it starts locking funds to someones identity. forever, you cant just move funds to a different password/privkey
lastly brute forcing the entropy of biometrics is easier than you think. its less entropy than 256bit

put it this way. people are put in prison for matching just 9 points of reference of a fingerprint

bitcoin ETF is not bitcoin.
its a small amount of bitcoin held in a trust and then that trust is treated like a company where it sells shares..

thos shares initially will correlate to the bitcoin price but because they are on separate markets the bitcoin price and ETF price will separate.

this is because the ETF funds are locked in to the 'trust' and cannot be arbitraged to affect the real bitcoin price.

at very best if the ETF excels compared to the bitcoin price. the ETF will have spare profits to add more 'baskets' of bitcoins to its ETF and sell shares. the issue is the selling of more shares dilutes the ETF price. due to extra supply. so you wont see the ETF do much to the real bitcoin economy. but the real economy can affect the ETF

QC has limitations.

solving binary logic problems QC doesnt handle well.. expect a 2x 'efficiency' rate
so things like SHA.. dont expect much efficiency of being brute forced by a QC system.

but things like ECDSA that can have deeper efficiency of being brute forced by a QC system.25-256x efficiency.

the thing is though. the cycle rate of a QC CPU compared to a binary based CPU right now has not much difference. so its going to take a while for something desktop PC size to outperform a PC.

QC computers has along time before its truly scaled to compete.