if you are saying native keys cant be spent on activation day.. then your funds cannot be added to a block (because your own funds are on native keys right now)
I didn't say that; stop twisting my argument.
if you can admit native transactions can be added to blocks. you start to see that people with native keys will just spam the 1mb base block.
Irrelevant. You can spam whatever you want, miners can prioritize Segwit transactions and are incentivized to do so.
you have mis-sold a "definitely deliver' by then saying > (im thinking you should have used < but even that is still mis-selling)
meaning its an EMPTY promise.
Nope. Read the above.
160 million users and 20 MB maximum block size (1 TB/year) as a mid-term goal is based on the present consumer HD market storage prices, but also on the idea to capture a significant (at least 10%) part of the market of Western Union and similar services (WU claims to have 1 billion clients). The remittance market is, for the time being, the most interesting one for BTC if it manages to continue to offer fees of less than ~1 USD per (simple) transaction.
The "upper cap" of 20 MB could be the mid-term cap, to be reached ~ 10 years from now. We could set a lower cap for the first 2-3 years (5 MB should be enough, or 2 MB + Segwit) because of current bandwith limitations. Or a moving cap based on speed tests like the one Franky proposes (good idea, I think).
You are not thinking about this straight. Let's say there is no risk for 20 MB blocks, DoS nor orphan wise. Storing 1 TB per year maybe won't be *that big of a problem* for existing nodes. You are forgeting about:
1) IBD.
2) Reindexing in case something goes wrong.
Imagine syncing and validating a 3 TB blockchain from scratch. Do I need to run my nodes only on top end Xeon machines? There was some discussions about a 'drastic' future in which new nodes would never be able to catch up (I think this was scaling workshop 2015).