taking down a node does not destroy coins.
private keys are protected

as unbiased as i can be

segwit works not by simple activation. but by moving funds long after activation to new keys that allow part of a tx's data to safely sit outside the native(normal/base) bitcoin block.

to achieve say 1.1x(1.1mb) scaling of the tx count requires ~10% of transactions inside the native block to be using segwit keys to allow and allowing more space within the native block

as you can see by this. where the yellow is the old native key use. and the grey is the new segwit key use to achieve ~2mb of data and ~2x tx count

---

dynamics works not by simple activation. but by allowing the native(normal/base) block to grow passed its old 1mb limit to allow in more transactions. without users needing to move funds to new special keys

in reality this wont be an overnight sudden jump to 2mb. pools and nodes would test the water in small increments to see the orphan and unsync node risk/count. and if deemed safe the consensus mechanism keeps the new increment and then steadily grows over time, based on how safe it is to do so

as you can see by this. where the yellow is the old native key use.

---

there are some pro's and cons of each
currently editing pros and cons to address OP's questions, (trying to be as unbiased as i can(but hard to achieve))

---

segwit pros
*if 100% of key utility inside the base block will be segwit. then those using segwit keys cannot perform sigop, maleation, .. and it offers extra tx count
*non segwit nodes get trimmed data (lacking signatures of segwit tx's outside native block). allowing them to connect as second tier nodes downstream nodes but are not part of the full validation/syncing network.
*expect if 100% segwit key utility, an average of 2mb of full untrimmed data. (based on current natural healthy lean-ish tx's stats)

segwit cons
*100% of key utility inside the base block will not be segwit! native key are not prevented and can perform sigop/bloat attacks bringing down tx count
*non segwit nodes get trimmed data (lacking signatures of segwit tx's outside native block). becoming second tier nodes that are not part of the full validation/syncing network. but connected as downstream nodes
*non segwit nodes need to completely rewrite the entire implementation with thousands of lines of code to be segwit validatable/ full syncing
*expect untrimmed blocks to be less than 2mb if native attacked, more if segwit bloat attacked
*if there was a bug/exploit requiring downgrading. those funds on segwit keys become locked and unspendable if no chance to move back to native keys before downgrading

---

dynamic pros
*grows the blocksize without users needing to change to different keytypes
*compatible with several diverse implementations but not core.
*core require only rewriting a few lines of code to stay part of a dynamic network
*if there was a bug/exploit blocks are simply made at under 1mb and dont require users changing keys/moving funds/having funds locked

dynamic cons
*not compatible with core.
*non dynamic accepting nodes fall off the network completely once dynamics reach the limits non dynamic implementations have set

ok guys

if there was a bug on core (imagining shoe on other foot)
those blockstream lovers would hope that core got informed first. to fix the bug and release an update, once X% of nodes were running the fix to negate any exploiters, then publicly releasing the exploit

EG
2013 levelDB bug.
not explain what went wrong until days after the fix was released and everyone updated.

..
but when the shoe is on the other foot.. core/blockstream do not believe in diversity of nodes and decentralisation to protect the network by offering the same moral stance of offer fix first, then release exploit publicly.

it proves core devs are NOT "independent"

seems to me that its obvious that "attack and rekt anything not blockstream, protect anything that is blockstream" (centralist mindset) is the game here

you forgot .. then bypass real consensus and make it so the pools vote.. then blame the pools for having the vote and start waving a victim card because all the pools didnt instantly kiss ass

adam back, gmaxwell and corallo having a combined 70,000 coins in 2014.. um no

probably more like 7000 coins

america are hating china.. not because there is some chinese guy sleeping on the american peoples door steps. but because america has been watching too much fox news.

while we had the "everyone hate russia" moment for the last decade.. america was actually doing trade deals with russia.. literally giving russia the front door key to the international space station and a taxi licence to charge americans to be taken to the door and open the door for america to access the space station.

you can buy apple iphones, mcdonalds, and thousands of other american things all in russia.. all while fox news was spewing out to hate russia..

bringing politics back on topic:

and now we have core who gave the pools the vote and bypass node consensus. core changed the fee estimation, relay and allowance lines of code..
but good old coindesk (barry silbert: DGC: blockstream) is using the media band wagon to try swaying people to blame china for bitcoin issues...

never accept what has been spoonfed for you by script writers. even if 100 people repeat it.. instead do you own research.
blockstream changed the fee mechanisms, blockstream changed who gets to vote. but blockstream didnt expect 50% undecided resistance and 25% opposition. they thought it was a easy domination with soft strokes of peoples asses.. but now realise they didnt get it soo easy.. so now they wanna ram the ban hammer hard and blame it all on the pools or other nodes for causing a split..
either playing the victim card of the fake first strike defense tactic as a way to stroke asses to pretend they are protecting bitcoin when really its about gaining domination of bitcoin.

if anyone dares reply that they want to avoid consensus and happy to have blockstream control it and no one else can or shoot keep them on their toes... then just reply "centralising is ok"

mempool bloat and fee increase (due to spam/congestion) is more about showing the network something needs to be done. and not about GREED

when you look at which team removed priority, removed reactive fee and replaced it with biasly increasing 'average' fee estimations you se its core that are pushing fee's up even if demand became low.

when you look at the stats of when mempools increase. you see there was a short rise and fall in june/july 2016 and a general rise after october.
this is normally done to sway miners into thinking something needs to change.

now taking into account that core CHOSE to avoid a node first pool second confidence building consensus event. and just do a give the vote to pools.
means you cannot blame the pools for having the vote and deciding one way or the other. its not their fault that nodes were bypassed.

also the timing of the mempool bloat events coincide with CORES bips wanting activation. shows who wants to sway pools into thinking something needs to be done sooner rather than later.

lastly.
BU can accept blocks from core, xt, classic and others no matter what their parameters change to.
xt can accept blocks from core, BU, classic and others no matter what their parameters change to.
classic can accept blocks from core, BU, xt and others no matter what their parameters change to.
BUT
core's current and near future releases wont accept blocks from BU, xt, classic and others if parameters of the longest chain change.

meaning if core is left as the minority they would then need to ban nodes to keep a minority chain alive
meaning if core becomes a majority they would then need to ban minority nodes and blocks to avoid orphan headaches

other implementations want to work on the same playing field using consensus.. only core are the ones that are offering to do uni/bilateral splits.

for clarity

hard = node vote then pool
soft = pool only

the term fork does not mean automatic permanent altcoin maker. it just means change of rules leading to different blocks being created.
what happens after that defines different scenarios

consensus/orphaning mechanism would trash blocks it did not like(orphans). and unify the blockchain into something the majority can accept, leaving the minority stuck and unsynced to the network due to not liking blocks it did not agree with.

the only way to keep a minority alive is to actively and intentionally ban the opposition to avoid seeing or using the consensus mechanism and only connecting to peers with the same acceptable parameters as you. this is called a split. which is bilateral if both sides agree to the split or unilateral if only one side agreed to split.

below these umbrella terms is what could happen.. in both hard and soft it can either continue as one chain. or bilateral split
softfork: consensus - >94% pools no banning/ignoring of minority. result: small 5% orphan drama then one chain. minority unsynced and dead
softfork: controversial - >50% pools no banning/ignoring of minority. result: long big% orphan drama then one chain. minority unsynced and dead
softfork: uni/bilateral split - intentionally ignoring/banning opposing rules and not including them. result: 2 chains

hardfork: consensus - >94% nodes, then >94% pools no banning/ignoring of minority. result: 5% orphan drama then one chain. minority unsynced / dead
hardfork: controversial - >50% nodes, then >50% pools no banning/ignoring of minority. result: big% orphan drama then one chain. minority unsynced / dead
hardfork: uni/bilateral split - intentionally ignoring/banning opposing rules and not including them. result: 2 chains


it requires intentionally banning the opposition to keep different blocks alive(ignoring consensus orphan mechanism). otherwise the orphaning mechanism causes some drama and one height is found the majority can agree on.

alot of people will try to tell you that bitcoin has not protective self regulating mechanism (the consensus orphaning mechanism) they will tell you you have to trust devs. you have to trust pools etc.. but you dont. the nodes will sort out a single unified chain if everyone puts up with some orphan drama, leaving the minority simply unsynced.

---

actively banning nodes to then build ontop a chain that the majority reject/minority accept may give you "double coins" but this is just temporary. once you spent those coins. thats it. gone.

a few minutes of greed to spend double the coins does not mean you will guarantee to profit because the market reaction of having 2 differing coins will cause the value of each side to change.

it can also cause peoples opinion of 'security' to diminish if it becomes easy to double coins. (EG like the fiat share market, regular share dilution devalues the shares when new A or B class shares are introduced and people lose trust in holding shares)
intentionally keeping 2 chains alive can be disastrous for a currency worth something . but profitable for a useless speculative coin.

think beyond the temporary greed of a double coin event and think about the long term result us such an action of splitting to a minority alt.

nope not the same.
segwit is still limited and dependant on the 1mb base block.
(by this i mean if no segwit key tx's get into the 1mb base.. the 3mb is empty)
Vs
BU,xt,classic, and and other dynamic proposals, grow beyond the 1mb base. meaning its not limited to 1mb thus requires more effort to spam.

EG SEGWIT
fill a baseblock with 1mb of native garbage and the other 3mb of weight are MEANINGLESS (100%native bloat=0% weight occupied)
you seem to forget that the weight is dependant on the base and what can get into the base to then utilise the weight.
segwit just doesnt give real capacity growth unless a few issues are sorted. which it cannot sort because it doesnt stop native attacks.

all it does is disarm segwit volunteers. but those segwit volunteers are still at the mercy of the 1mb base block and native key spammers.
its not like a berlin wall wher ALL segwit data sits in the 3mbweight. and all native sit in the base
segwit need to get into the base to then spread their legs into the weight.

vs BU, classic, xt (and other real-block growth proposals)
2mb baseblock means it requires twice as much effort..

its not a native block increase!
its only a growth if people use segwit keys and only reaches potential amounts dependant on how much segwit key adoption there is.

stop thinking just segwit activation causes native tx's to have 2mb..

you know this. you have admitted such in different posts/topics. so dont exaggerate it into a native base block increase, when its not.

again its only a 'effective size if X,Y,Z is achieved AFTER activation..
no promises no guarantee's.

this 'effective potential' can be inhibited(prevented) by atleast 5 attack vectors that can stop segwit ever getting any effective increase in tx counts

any dynamic is acceptable to BU, and with for instance. the 5% every 2week max growth. it will take a few years before affecting xt.. so the only one it does affect at activation is core.
(funnily enough a few people have manually taken core and already put in a 2mb+ in their limits to cover any network change and they all run fine on the network)

all core need to do is actually give in and add just the few minimal changes. or be a**hats and orphan&ban the majority if they want to dig their heels in and oppose it.(creating their own altcoin)

i would actually prefer core to have some extra RPC commands or a GUI options tab where users can while LIVE. change settings.
that way users are now slaves to devs digging their heels in by refusing to change something

i have my own. with a few tweaks.
infact i have core, my own(wrote in different language) bu, classic, bitcoin j and others. i play with them all depending on what im doing/testing

but in short.. if segwit activates.. BU, xt, classic, and al the dozen others 'brands' (if not biasedly banned by blockstreamers) will still get the filtered (trimmed) blocks. but obviously by not having segwit validation. will only be in the hodgepodge of second tier(downstream) part of the network but not fully validating segwit data.. and just relaying native tx's upto segwit upstream nodes..
essntially making BU classic, xt and older nodes just lite wallets.

but if BU, activates.
xt, classic and a dozen other 'brands' will all be ok ALL on same level.(no 2 tier)
 but then core end up seeing orphans and banning nodes to ignore the orphan drama. thus stalling out core, forcing them to either
tweak code to join the majority (give in and raise the block limit).
ban nodes and only white list core nodes to start their minority coin
stay stalled and turn node off

if classic activate
BU xt and a dozen other 'brands' will all be ok ALL on same level.(no 2 tier)
but then core end up seeing blocks it doesnt like .. so orphans and banning nodes to ignore the orphan drama. thus stalling out core, forcing them to either
tweak code to join the majority (give in and raise the block limit).
ban nodes and only white list core nodes to start their minority coin
stay stalled and turn node off

---

i think the simple solution is for core to:
keep the TXSIGOPLIMIT at 4000.. that way no matter what the blocksize is, malicious TX's dont start making bigger sigops (EG cores 0.14 16,000 rather than 4000 - facepalm)
and core to put in a RPC and GUI options tab where users can reset the blocklimit live...WITHOUT needing devs to give in/spoonfeed.  without needing to recompile.. so that users are more incontrol and adaptable to change without needing devs to decide for them if/when/how.
that way users can change settings at their leisure and become more independent

dino

you do know pools spend too.
exchangees spend too
users spend too..
node users spend too.

your thinking of the end-user USABILITY..
in which case everyone is a user..(in your eyes)

but your not thinking about the underlying code/protocol/network infrastructure of bitcoin

all your grasping is the end user experience.

EG if bitcoin was a bank all your thinking about is the person and an ATM
your not thinking about the behind the scenes stuff..

.. if you are.. you are only comprehending it at a high-school 30second laymens understanding. but not the real function and features that make bitcoin stronger than banks or anything else

if you think that non mining nodes only job is just a data store.. you have been missinformed

are you saying that core are independent.. and that those non BU (but do "99% copying-pasting" and surviving off each other) is not the same. (EG matt corallo has his own repo, luke JR has his own repo. as do many others... are they all bad gys for having their own repo.. including the pools
are you saying that having a repo of your own is the problem because all you care about is core because of its management
are you saying you trust core because its not independent because they only want to work with blockstream devs.
are you saying that no one should take the core code and make tweaks. and instead have to beg blockstream for something
are you saying that if a core release has not been completely rewritten and only adjusted slightly. that suddenly its an altcoin(eventhough it runs on bitcoins mainnet as other implementations do)
are you saying that independent devs cannot do anything unless gmaxwell is involved and where it has to have gmaxwells wishes complied with.

---

personally i think pruning is stupid. once pruned you cant be part of the full node syncing mechanism.
you might aswell just run a litenode.
allowing a node to be no witness and pruned should be treated as third tier nodes and not categorised as a full node.

i can think of many things core have not done. or even things core have done that have caused big issues (sipa's 2013 leveldb mega orphan event)
devs are not perfect.

and only code matters.
people should decide what node to use on the abilities and features the code allows or doesnt allow.
in my eyes segwit is an empty gesture of half promises that opens up new attack vectors

1. jihan only manages 15% and of that 15% not all of it is actually his.
2. your forgetting the ~50% undecided either way
.. so trying to blame a few small numbers as the reason why segwit is only achieving 26% is a laugh.(segwit is at 26% not 85%)
3. core CHOSE to avoid node support first then pool support second by going soft. dont blame who core allowed to vote. blame core for making them the only voters.
.. because smart pools wont activate /flag unless they know that the nodes can cope/accept the changes. so even without official vote, pools will wait for node acceptability(to avoid orphans and ensure that people accept their version of blocks to atleast spend the rewards)
.. thus core have literally shot themselves in the foot thinking they can get 100% dominance without REAL full network consent by going soft.
4. if core done a node first pool second. whereby a OVER say 75%-95% nodecount triggers a pool vote. the pools would have been more confident.

but
5. even if you think its just about votes. you need to remember WHY they vote. segwit is not perfect, core devs are not gods, they are human and can come and go..

..what CODE is best for the long term survival of bitcoin for generations to come mean more then some temporary gesture that is meaningless in a few years.

anyone can download a copy of a node and then with a friend. set the 2 nodes to only talk to each other and then change the rules as they see fit.
this is called making an altcoin.

many people have done this and no one cares because its just an alt.

however if you want the network to follow you. you need the majority of the networks consent.
you can set the announcement for 1 week, 1 year 5 years etc(whatever). but if your changes/desires do not meet the desires of the others on the network. they will not follow you.

the current bitcoin debates are trying to get network majority consent or they simply wont bother.
yes segwit may want to split off and ban ~75% of the pools using UASF even if the 'vote' is only around ~25% by this october.

but they then become a minority altcoin. which is less secure and can be attacked by the majority. where by it takes longer for blocks to be solved. the blocks are spammed and many blocks get orphaned.

this is why both sides are hoping for a majority to reduce risks of orphans, hash attacks, spamming and sybil attacks

summary of my post below for all the TL:DR people
dinofelis you are just talking about end user experience of just spnding coins. you have not talked about the integrity, security, consensus of bitcoins self regulation of protecting the coins.

by having diverse nodes and INDEPENDENT DEVS makes it less likely for corruption of the rules aswell as avoiding the physical location attack, the more diverse the nodes get

i think you need to learn about bitcoin consensus and the protocol, beyond just the end-user experience

---

---

long explanation
what you are talking about is NOT about how bitcoin works at the consensus level nor the job of what the nodes do
your talking about the millions of users that rely on third parties services to not need full nodes for all the millions of 'users'.

essentially your talking about users. not the bitcoin security network protocol.

i agree 6millionish current users dont need to run a node just to spend coins. bt that has nothing to do with how the network functions.
all your doing is explaining that users can rely on middlemen, if they wanted to. rather than be an active part of the self regulating node network.

but thats where your now talking about users becoming reliant on middle men. rather than the network rules.

---

what your not taking into account are that all these lite/web wallets and market services are third parties.. but they need to communicate to full node network.
even pools run a node.
so whether your emailing a pool, or api submitting a tx via a webwallet or litewallet... the tx has to sit in a mempool and meet the rules that the majority of nodes can accept. otherwise that tx wont exist.
its either rejected at mempool/relay level due to not meeting the rules. or rjected after being in the block if the node network decide the block attributes the pool used dont meet the node networks rules.

---

what you are forgetting is what the full node network actually does.

firstly.
again, you are right the 6mill+ users dont need full nodes. as lite and webwallets can act as the middlemen talking to a server that has the full node talking to the network.

secondly.
spending coins does not mean damned all to nodes or pools.
if you want to push a TX to ETH.. ETC wont care. data is data
ETH or ETC dont get giddy with excitement more if im spending 100000 coins and less excited if your only spending 1 coin..
data is data. tx vale is meaningless to the block/rules.

BUT

what matters is what atleast 50% (preferable as close to 95% as possible) of nodes can agree on to reduce the risks of orphaning blocks.
for instance. ALL the pools worked on ETH.. but no exchange eth node, no localbitcoin eth node and no fiat OTC private trader used ETH nodes.. then the ETH miners cant spend their coins because no one there to buy them.
those blocks and coins are just invisible to the network of ETC.

so pools will follow the NODES rules of what the nodes will accept
firstly AND more importantly follow the nodes rules otherwise the block gets orphaned and the pools reward coins dont exist so the pool has wasted time making a block that ends up in the trash.
secondly
so pools can spend their reward with exchanges that see the blocks they created

---

you even admit it yourself users need to make sure which chain their third party service is communicating with(or who thy are emailing to). otherwise you might aswell be emailing your transaction to the Clams network(an altcoin) rather than the bitcoin network.

your entire scenario has nothing to do with network security or integrity of validating the data. or how blocks are either accepted or rejected, it is just talking about surface layer coin USAGE, not the underlying code/protocol/security of bitcoin.

---

yes all coin users can just rely on third party services to handle the messages, api,emails on the users behalf. and the network can have just 1  pool node in the network
but then thats centralising the network where the pool can make changes and the users are then subject to that change.

however by having many nodes and many pools. ensures that changes do not occur as easily and the nodes and pools become accountable to eachother whereby changes can only occur due to mutual consent(consensus) or risk having the blocks rejected if they do not meet the nodes rules.

---

i know you are going to rebut that there could be a altcoin that is just the pools node running things. and then having many offchain communication methods like API to the websites and lite clients and email addresses.

but now users are completely reliant on one entity setting the rules for itself. which.. just makes it corruptible and nothing more than FIAT. but without the regulations.

..
bitcoin doesnt need regulators because the diversity of the network self-regulates. thats the beauty of it.

and to be ontopic.
if all nodes were running core. and all pools were running core. then there might aswell just be 1 pool node and a huge bunch of API calls to all the services(from a rule changing prospective).
because the only benefit of distributing the chain is not about protecting the rules, as such. because core can change the rules.

but purely about not having a physical location attack to take them offline.

only the "markets" that are VC funded by DGC, http://dcg.co/portfolio/
which are in blockstreams pocket

hence why BTCC is the loudest pool supporting segwit..and flagged segwit support within minutes of the october start, rather than take the time to assess things first... oh look DCG->BTCC

maybe bloating up a tx from say 450bytes to 1.4kb by adding commitments is less important than keeping transactions lean.
maybe mimble and other 'confidential' matters should be left for second layer solutions like LN or sidechains. and to keep bitcoin lean is more practical

well if core want to change tx encoding for minimal tx efficiences, but then bloat tx's with in-efficient bloating commitments for the sake of confidentiality. results in no beneficial efficiency trade-off.

thus by just keeping things lean actually becomes more efficient, than the bait and switch of gaining then subtracting efficiency.

an idea...

IBD concerns are less about time of IBD but actually of..
(subtle difference of psychology(nodes function-ability vs users utility))
time to get it synced to have a full UTXO set to see their uptodate imported key balance and actually start spending.

by simply (much like a liteclient) downloading a UTXO set first as a temporary measure. it then allows people to see their upto date "balance" to then start spending. making the IBD still important, but in practice something that becomes more of a background matter and atleast not have people "waiting".

then as the IBD works in the background. it just makes any changes to the UTXO as it gets updated.

then IBD becomes less practically tiresome to the user