2 things
1. bitcoin is not inflationary (to address your many earlier points that still gripe me)
2. bitcoin is not a commodity. its an asset.

a commodity is a raw material used to make other products
beef=hamburgers, steaks
oil=plastic, fuel
wheat=bread, animal feed
gold=jewellery/circuits

gold sits in 2 categories and on multiple markets. 1 being the commodity market (jewellery/circuitry). the other being asset market.

just because you see bitcoin as the similar principles of golds ASSET values. does not mean bitcoin also holds golds commodity value.

they are 2 separate categories.

---

you are also mixing up golds value(utility/desire) to fit whatever narrative you like.
golds value(price) is a culmination of desire(asset store of value) AND utility(commodity usefulness as jewelery and circults)

take away golds commodity utility.. and people only value(desire price) it as the equivalent of rust.

take away bitcoins ability to be spendable to pay rent once a week or groceries once a week. and you affect its utility and desire. making its store of value(price) deminish

the store of value(price) is only there if and only if there is desire and utility. (otherwise we would see all 1000 altcoins at $1200 if it was based on just 'existing')

if you take away utility. desire errodes. and then price errodes.. thus store of value(price) drops

if we simply turned bitcoin into... say... 42coin. that has fixed limit, scarce and no development.. and not used for buying coffee.. or anything for that matter.. bitcoins store of value(price) would be the same as 42coin.

---

increasing the tx/s is not about coffee its about progressively and naturally allowing more people to transact. even if its 2mill users using it 5times a month now .. to for instance 1 billion people IN 30 YEARS(not overnight, but natural dynamic progression over time) using it 5 times a month.

just for a weekly wage/grocery shop.

that will help desire grow and with more user adoption (not frequency of spending per person) the extra user adoption will actually help stableise the value(price)

FTFY

i think many need to start using brackets against "value" to effectively show what version of "value" you are discussing

also the value(price) does not become stable simply by stalling its utility. infact it can become more unstable if utility is halted but desire increas or decrease. or many other factors.

stablising price cannot occur simply by stopping development. there is more than one element that cause the PRICE to be affected.

as for the "spam" and people presuming its BU driven....

check out the unconfirmed mempool sizes over the last year
https://blockchain.info/charts/mempool-size?daysAverageString=7&timespan=1year

apart from a blip in june/july (hmm ill get to this later)
mempool size was 2mb-3mb..

then in october(hmm ill get to this later). (around the 10th october) it started to get into 4mb.. and started rising...and rising. and rising..

hmmm i wonder what new feature was introduced in october that needed the community to get frustrated and delayed to "sell" the community into thinking this feature being the promise to fix the issue..

hmm.. oh yea.. segwit.

as for june july. (CLTV+CSV)

what a coincidence.. spam attacks right around the times blockstream devs want pools to think certain features need to be added to be stepping stones to something that (*may* cough wont cough) eventually fix spam attacks..

its not about band camp arguing. its about network propogation..

even BTCC (pro segwit) has near empty blocks
455807 (Main Chain) BTCC Pool 00000000000000000107a158529ac9448946981489894a00075b2a9968f567b7 0.27mb  2017-03-05 03:39:05

the reason is rather apparent
455907 2017-03-05 03:39:05
455806 2017-03-05 03:38:44
hint: 21 seconds

in the 21 seconds to see 806 exists.... then get 806... btcc started mining its own new block with transactions it knew were NOT in 806(because its their own tx's or other reasons so they know they were not relayed at 806) so deemed it safe to include them. rather than do the usual empty block philosophy of mine new while validating old including none at all.

but btcc was LUCKY enough to get a block solution to 807 before being able to fully validated 806 and so didnt have time to add more tx's to their block after confirming 806. because 807 had a solution.

---

in short.. if you see a block not at over 900k.. and instead low kb.. check the time between blocks.. if its short. EG under 2minutes.. its usually about the empty block game of starting a new block BEFORE validating the old block thus not able to fill the new block because you are stil unsure whats truly 'unconfirmed' to allow into a new block.


if a block is near empty and its taken ~5min+ and no sign of any holdups in previous block due to sigop spamming.. then and only then treat it as intentional ignoring unconfirm additions

1. if nodes and pools decide 95% of the network is the metric then it requires 5.01% of the network to hold up block growth with 5% possible orphan heaches. if 75% of the network is the metric . the 25.01% of the network is needed to hold back growth with upto 25% orphan headaches if pools tried to exceed limits.

what you need to also take into account is nodes might have 75%-95%.. but pools may also have their own safer metric to reduce orphan risks

EG nodes at 75% where consensus.h 4mb and policy at 2.5mb
EG pools at 95% where consensus.h 2.499mb and policy at 1.01mb

for instance. resulting in pools only making blocks 1mb-2.499mb before seeing issues and pools only moving passed 2.5 if 95% of pools agree and 75% of nodes agree..

2. if an orphan game results in bilateral split(it doesnt).. we would be having several altcoins being created a week for the last 8 years just because of orphans
https://blockchain.info/orphaned-blocks

orphans KILL OFF opposing blocks. to keep to one chain

to avoid orphaning a block. the nodes need to ban the opposition to not see/try syncing to oppositions blockheight and to successfully build their own.

othrwise they end up in orphan hell rejecting their own small network because its lower blockheight, to instead request data from the nodes with higher blockheight... but then rejecting the oppositions because although they have higher blockheight the data (blocksize) breaks the rules when they get that block they request..thus being left unsynced.

so it requires not connecting to that main chain. to avoid seeing it to then happily grow their own chain (as clams2.0)

remember ethereum was not a CONSENSUS fork it was a bilateral split involving banning nodes. hint: "--oppose-dao-fork"

1. thats where your skipping to step 3..
three step process based on your 2.5mb scenario
step one
92% of nodes say 4mb is fine...(reality is a mix of more than 4mb to lets say 16mb)
1% of nodes say 3.6mb is fine
1% of nodes say 3.3mb is fine
1% of nodes say 3mb is fine
5% of nodes say 2.5mb is fine...
^ the nodes 'consensus.h limit'

but ALL nodes then have a policy.h limit too which is at 2.5mb


pools too have 2 limits. they see the 95% 2.5 limit and that becomes the POOLS consensus.h limit (2.5)
pools then have the policy.h limit where they make blocks at 1.001mb to test the water, see the orphan risk rate. if fine they then move to 1.002mb and it grows from there..
DO NOT think pools will jump straight to 2.5 or 4mb instantly

step two.(2)
as the blocks get to 2.5mb. orphans start to occur(due to A). but at an acceptable 5% risk tolerance. meaning the 5% (node A) rejects and has to choose to either move up its consensus limit to allow the policy limit to have some wiggle room or be left unsynced with the network.(3)
pools then decide if they move their limit up to 3mb consensus.h and try 2.6mb policy.h (depending on orphan risk)

step three.
by nodeA continuing to run but not moving the limit.. if blocks got to 3mb.. the orphan risk goes above 5% and pools start to get worried and stop growing. because network consensus is no longer at or below 95% tolerance

by nodeA continuing to run and moving the limit.. if blocks got above 2.5 but only to 3mb.. the orphan risk is below 5% and pools continue
by nodeA not running.. if blocks got to 3mb.. the orphan risk is below 5% and pools continue

3. defining your understanding of "fork"
the node if not moving its limits. is just going to continue rejecting blocks(left unsynced) its an ORPHAN EVENT.  or it switchs off its node.

by continuing to run but not upping the limit. it and other nodes where by the network goes under 95% would stop pools from growing.

the thing most forget is that there are 2 'limits' not one.

now..
lets imagine there was a pool that separately dcided it wanted to hlp node A by not following the network dynamic consensus. and dropped down to 2mb to mine for node A.
again an orphan event. this time also affecting the pool aswell(2 opposing pools fighting for blockheight of a single chain)

to cause a altcoin (bilateral split) node A and the pool will have to intentionally BAN the other pools and nodes to avoid the orphan game of consensus and then they become their own little network we would probably call 'clams 2.0'

the thing most forget is that even in a soft fork event nodes can ban opposition and cause a bilateral split (altcoin maker). even gmaxwll admits to wanting this to happen for certain reasons

imagine bitcoin was not measured against the dollar and then arbitraged to the other forex currencies... but instead measured against lets say 'the cost of living index' (google it)

that way bitcoin becomes valued in manhours not fiat.

EG today lets say bitcoin was 160 minwage hours.
in america that = $1200
in cuba that = $80

thus causing the forex arbitrage to get americans to buy the cuban currency to then buy bitcoin cheap to sell to america. rinse and repeat to raise cuba's economy

effectively and eventually stablising world currencies once arbitrage has leveled the playing field of world currencies

2012 there was only like half a dozen pools... now there are over 20.

only difference is majority in the past were american. and now majority spread out across the world.
yep even the ones people think are 'chinese' actually have farms in georgia, mongolia, sanfran, thailand and iceland

it doesnt.
quadratic spam WILL still occur after activation of segwit.

segwit only disarms people who move funds to segwit keys.. segwit does not disarm the network from quadratic spam.. just the users who voluntarily use sgwit keys.
malicious spammers will just stick to native keys. meaning blocks can still be quadraticly spammed.

the real fix is limiting transaction sigops.
analogy: taking guns away from innocent people does not make gangsters stop doing drive-by's


the fake narrative of how dynamics work in blockstreamers scripts is not the reality of how dynamic blocks will work. blockstreamers have their scripts purely like religion has their bible. to get people to not think for themselves and instead seek guidance from a cultish leader preaching to his flock.

pleas open your mind and do your own research beyond the 30 second elevator sales pitches of blockstream scripts.. its becoming too obvious

dynamic blocks DO NOT give pools the power.
node consensus is the power. and pools know that.
pools could produce any blocksize they want but if nodes orphan a block... that block is metaphorically in the trashcan. thus pools wont do things that waste their electric and time.

dynamic scaling works in a 1,2,3 step bases.. the blockstream 'dynamic is doomsday'ers however twist the logic of reality and talk about the 3,1 fake methodology(backwards and skipping a step) which is not how it will play out, but helps them scare the community into thinking that without the blockstream devs spoonfeeding and without king maxwell standing on his mount preaching the rules, bitcoin would break

blockstreams soft fork gave pools the vote so that if it succeeds in activating. blockstream take the glory. if it fails they have the bait and switch to blame it on the pools.
(typical banker economic illogic: if economy rises bankers celebrate their greed saved the economy. if it fails, blame the poor)

your forgetting that all the complaints to blame miners is also due to blockstream

if it was a full hard consensus (nodes first then pools second) the nodes would upgrade and given confidence to pools to then vote second because the pools would know that node could cope with it.

but blockstream devs envisioned going soft and gave only the pools the vote.. emphasis blockstream devs gave pools the vote.

but the pools are smart to not change anything without nodes being there to accept the change, so the pools are waiting undecided. the only pools voting for segwit are BTCC and slush which are if you research their VC funding BTCC are funded by the same guys as blockstream. so its obvious why BTCC jumped right onboard the segwit train before thinking about the pro's and cons to the network effect or if segwit would actually solve issues for the whole network.
http://dcg.co/network/#b  <- blockstream, BTCC

concerns years ago. blockstream take over.
community wanted onchain scaling with dynamic blocks and compromised down to initially 2mb dynamic in late 2015..

yes carlton too wanted dynamic blocks aswell, funnily enough
^ one of many examples


blockstream devs LukeJr and Adam back said they will do their part....
spring 2016.. they backtracked and now we are left with their empty gesture that is not even a guaranteed or real expected fixed 2mb. let alone dynamic
and instead an attempt to get their nodes at the top of the network topology (upstream filters)

their 2mb boost wont occur, the other fixes wont occur* and we are still left on the reliance of them spoon feeding out code rather than let the nodes independantly set the limits and use consensus to set the overall rule.
*(needs users to move funds to segwit keys and only use segwit keys to achieve anything, but doesnt fix/prevent the native key users = problems not solved, solutions not achieved)


thre was a compromise.. the consensus roundtable of late 2015.. the community settled on a 2mb starting point but wanting it dynamic so that we didnt need these "human" meetings and instead could let the nodes decide what node can cope with and then the pools produce blocks within what nodes can tolerate.

but guess what blockstream backtracked and pretended they are not involved that much in core and cant code a solution.
strange thing is that thee late 2015 consensus event should have just invited the blockstreams office janitor instead and that probably would have been more productive

delayed reaction to the reward halving + ASIC's hitting the market.. (mainly it was the ASICS event)

https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki#freezing-funds
note the blue below FROZEN IN UTXO DIRECTLY ON THE BLOCKCHAIN = confirmed TX froze out from being spent(meaning its not about holding unconfirmed in mempool for X.. but getting confirmed but THEN unspendable for X


https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki#retroactive-invalidation
note the purple "delayed" below is referring to CLTV

though unsupervised by the food giver. most people in a public place close together around a table feel extra guilt if they just took food and walked away. so they pay due to 'peer pressure' of not looking like a cheap-ass.

but in the bedroom of your own house where no one is there to judge you. less chance of peer pressure persuading you to pay something.

this is why people rattling donation tins for red cross or other organisations, get better success not standing in the street because people walk on by.. but if they go into a bar and find a group of say 5-10 people who know each other.. that peer pressure sinks in. if one person pays. suddenly everyone checks their pocket just because they dont like to look like a cheapskate infront of their social group. usually  6/10 put something into a tin. compared to 1/100 on the street

studies have been done on this. social/peer pressure outweighs individual moral decision

check out the unconfirmed
https://blockchain.info/charts/mempool-size?daysAverageString=7&timespan=1year

apart from a blip in june/july (ill get to this later)
mempool size was 2mb-3mb..

then in october. (around the 10th october) it started to get into 4mb.. and started rising...and rising. and rising.. hmmm i wonder what new feature was introduced in october that needed the community to get frustrated and delayed to "sell" the community into thinking this feature being the promise to fix the issue..

hmm.. oh yea.. segwit.

as for june july. (CLTV+CSV)

what a coincidence.. spam attacks right around the times blockstream devs want pools to think certain features need to be added to be stepping stones to something that (may) eventually fix spam attacks..

what if i told you LN is buggy  (remember the one-use address issues where signing a tx using the same key multiple times could reveal said privkey)
what if i told you CLTV if you read what it does is AFTER the close channel transaction confirms. funds are unavailable to spend and in a maturity bubble like blockreward 100confirm (real world feel of the 3-5day bank delay spending of funds)
what if i told you CSV if you read what it does is AFTER the close channel transaction confirms. while maturing. the other party(cosigner) can revoke the payment to themselves(real world feel of paypal/credit card chargebacks)

LN is not intended for everyone. LN is intented for people that spend micro amounts multiple times a day. (faucet raiders) and thats its niche.
LN wont see satisfaction from regular users that just want to spend once or twice a month to pay rent or take a salary

---

what if i told you its not permissionless.. because you cant simply send funds to a person. you need the person your in contract with to authorise (remember its a multisig)
and if using hops. you need each hop to AGREE(permission) to use them as a hop.
and if its a hub you need the hub to agree(permission)

its then no longer just peer to peer permissionless, but needing other people to sign off on YOUR funds

please forget the 20 second elevator sales pitches that have lead many to kiss blockstream ass, and go look at the fine details.
think about the net work topology. how blockstreams creations are at the UPSTREAM (closest to pools) and how the data filters down to the hodge podge of nodes that are down stream that are not
full archival 100% validation 100% relay nodes.

FIBRE

---

Fibre coded by Matt corallo and released with bitcoin(segwit) core.
matt was an employee of blockstream at the time f helping them make FIBRE (secretly still is but as a 'technical advisor')

segwit coded mainly by sipa and released with bitcoin core.
sipa is an employee of blockstream

LN coded by rusty russell and released under blockstreams github https://github.com/ElementsProject/lightning
rusty russell is an employee of blockstream