what the OP is alluding to is that the mistake was not the customer.
so OKCoin should just send funds from okcoins reserves to the customer immediately after realising the error and then okcoin can settle their own internal mistake with the other swift as a separate matter at okcoins own time internally.

not making the customer wait for okcoin to get a refund.

usually if your a multimillion dollar company that made a messup, you just send a new request to the correct destination straight away and then sort up the mess behind the scenes without inconveniencing the customer.
EG
day one: cause a mess up
day two: realise the mess up and send funds to correct destination apologising for 'admin error'
day three: handle the mess up separately over a month, behind closed doors
day four: customer receives funds after 2 business days, only one day late due to a messup
day thirty-three: okcoin gets reimbursed for mess up, behind closed doors

not
day one: cause a mess up
day two: realise the mess up inform customer has to wait giving bad excuse and no intention to remedy the fault asap
day three to day thirty-two: give customer more delay excuses
day thirty-three: send customer funds to correct destination
day thirty-five: customer receives funds

bitcoin transactions are only irreversible AFTER confirmation.
imagine it like:
writing a cheque. you can validate the cheque by calling the bank and checking the balance is available to spend and the person is who they say they are. but until the cheque is cleared by the cheque clearing house you dont yet have the funds to spend yourself and the funds can bounce.

writing a transaction. you can validate the transaction by checking the inputs and checking the balance is available to spend and the signature belongs to the inputs. but until the transaction is confirmed into a block you dont yet have the funds to spend yourself and the transaction can be rejected.

there are a few ways to write a transaction announcing you as the destination. making you see the unconfirmed transaction. but then write another transaction using the same original input funds to move the funds elsewhere and getting that transaction accepted into a block before the one you were hoping for. thus making the one you were hoping for get rejected.

so until the transaction you were hoping for is confirmed (irreversible) dont trust it.

double spends are actually easy.
(a)someone makes a tx to you, but have insufficient fee.

(b)someone makes a tx to themselves with a sufficient fee. and then a (c)third transaction prespending that transaction with a suffient fee to push transaction c through.
this is using features called RBF(replace by fee) and CPFP(child pays for parent)

so until the transaction you were hoping for is confirmed (irreversible) dont trust it. especially ones with insufficient fee

i guess your eluding to the hyperledger blockchain that all the names you mentioned are programming.

the problem with that is that hyperledger is FIAT
so companies like circle if they drop bitcoin.. will just be a bank holding fiat. making them a forex company swapping america's fiat for lets say india's fiat. rather than an open currency without borders.

the problem is that there would be no need for that because the hyperledger itself can do those fiat swaps directly. thus not needing circle.

after the first 20 difficulty changes occur to get to that stabilisation point yes.
those 20 difficulty changes would happen rapidly

basically in under 3 weeks would produce 40320 blocks which would have taken 9 months.. but after the 20 difficulty changes in the 3 weeks it stabilizes to the 2016 blocks every 2 weeks ongoing at that same difficulty

thats not how bitcoin works, your trying too hard to make a placebo effect appear to be segwit related.

segwit is NOT letting in any extra transactions in. segwit is not activated to do that.
secondly next year when it is activated it doesnt make 4 blocks get solved in 15 minutes. or mess with the 'average' timing

segwit has nothing to do with the asic miners hashrate to make blocks

only reason this topic is proposing to avoid consensus and instead split is simple. those that want a split dont care about bitcoin they just want to double their money by having coins on 2 networks.

simply a boring greedy reason with no thought about "bitcoin". just quick method to double money and then to run to fiat.

guys if you actually care about bitcoin. learn consensus/orphans which allow the strongest desires to continue on a single chain and the minority left not able to sync (hence requiring a very high desire to even upgrade the single network without risk/headache)

and stop thinking forks are only about intentional splits.

funny though.. the title of this topic..

Can't we all just get along?

and the OP's solution is not to find a middleground where everyone is happy
EG
2mb base 4mbweight  so scaling can occur and segwit still functions..

but instead OP proposes splitting away from each other and going in separate directions.
that is not "getting along" but avoidance, ignorance, separation and other terms that are the opposite of getting along

you do know that ASICS do not have a hard drive, or store the blockchain, or validate transactions.
all they literally do is SHA hash a small piece of data unrelated to your transaction.

SHA hashing in a ASIC has not changed in any way and has nothing to do with any updated node software, or transaction formation.

segwit will not do anything to the average time of solving a block.
the only difference you may notice with segwit are more transactions per block.
and the time YOUR node validates and stores a block of data.
NOT solving a block.

again nothing to do with confirmations at all.
you experienced something that is not attributed to what segwit does bt due to placebo, have deemed it to be a effect of segwit.

how can the community choose it, if the dev team refuse it. its like apple saying the community wont buy an apple8 phone so lets not make one, then by not making one, a month later apple says "see noone has bought an apple8"
(because it doesnt exist for the community to even get)
its called a self fulfilling prophecy.
how about try a different prophecy "if you build it, they will come" field of dreams
ofcourse if it doesnt reach 95% then nothing happens, no harm done.

legacy in conversational terms means OLD.. legacy blocksize is a conversational term for old blocksize. not a branded buzzword that core likes to use

but thats where core love buzzwords. now the combined data they are calling "MAX_BLOCK_WEIGHT" not "blocksize", oops now its "MAX_BLOCK_SERIALIZED_SIZE" which is the same size as their other term "MAX_BLOCK_WEIGHT", yet they also have "MAX_BLOCK_BASE_SIZE" which is what the OLD term for the "blocksize" rule is about and core want to keep "MAX_BLOCK_BASE_SIZE" at 1mb
(for conversational purposes: 'base' and 'weight' are obvious abbreviations of cores new buzzwords)..

previously

https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki
as you can see they changed buzzwords "blocksize" for "basesize" then made a new metric outside of the blocksize for weight and serialised size
which can only be utilised if people no longer do legacy (old/traditional) transactions and instead do segwit transactions.
those sticking to legacy(old/traditional) implementations and legacy(old/traditional) transaction types see the MAX_BLOCK_BASE_SIZE as the "blocksize" and ignore "weight"s and "serialization" buzzwords. meaning the "blocksize" and "base"(MAX_BLOCK_BASE_SIZE) are the same.

which is where i saud you should clarified the difference of base and weight in your vote. but anyway thats just all buzzword core like to play around with, because in the "blocksize debate" we know cores 1mb base 4mb weight does not equal 4x capacity. so them pretending 4mb weight is a big improvement, is not. its just switching buzzwords to pretend its a massive improvement. yet reality is estimated at 1.8x not 4x even if the "weight" is 4x

and not all pools are detectable either, only those solving a block are detectable. so over a month period. its not showing all pools votes. only those doing enough work to get a block solved.

much like https://bitnodes.21.co/, doesnt show all nodes, but the ones with enough incoming and outgoing to be seen by the network.
same goes for pools. there may be 25 pools and 100 people (foolishly)solo mining. but they are not seen. only the 18ish that show they are a healthy part of the network are seen

seriously wrong assumption
for instance BU has the rules right now for a differing blocksize.. yet is not forking off to an altcoin.!!
its still part of the network!! same for all other diverse nodes too
at this point even a 2mb base 4mb weight is the "maximum" meaning 1mb base is still acceptable to the new rules.
0kb ->4mb weight still allows for 1mb to be acceptable
there is no altcoin doomsday here!!

ethereum did not split simple due to rule change. they split due to --oppose-dao-flag option that activated the ban list(aded intentional split code) to not be part of the consensus(majority) ethereum network
no one is proposing to intentionally split the network with banIP/useragent code. they are proposing using consensus
to upgrade the network as a single chain..
no altcoin!
ill explain more in a minute

at 95% of nodes the chain FOLLOWS the majority.. not the minority. all that happens is the orphan risk changes from about 1%-2% (standard at the moment) to being 5% risk due to the minority.

the 5% minority ends up receiving blocks it rejects and either powers off because it cant stay in sync with the majority or they upgrade to join the majority.
the only way it "altcoins" is intentionally banIP/ban useragent of the majority opposition and then forms their own small network and sync to their own lower blockheight that is not interrupted by the 95%.

if the minority do oppose the change and add some code to slit off and form their own micro network. then they become the altcoin! because they are not with the majority.

i think you have been having too many propaganda tuition seminars by your employer and colleagues and not done much independent thinking of rational and realistic outcomes

luke how about your promise for an implementation for 2mb base 4mb weight??[as an independent coder as i fear your employer and paid colleagues will refuse it in core]

---

your vote is unclear especially in concern of the word "blocksize increase" (you dont explain legacy blocksize vs base/weight)
Yes
Yes, but I would prefer it without a block size increase (prefer: 0.6mb txdata 0.4mb witness(1mb total weight) instead of 1mb base 4mb weight)
Yes, but I would prefer it without a "witness discount"
Yes, but I would prefer it as part of a hardfork(purely to have user nodes updated first)
Yes, but I would prefer it as part of a hardfork with base block increase(prefer: 2mb txdata 4mb weight instead of 1mb base 4mb weight)
No, I want to block it until after a hardfork(purely to have user nodes updated first)
No, I want to block it until after a hardfork with base block increase(prefer: 2mb txdata 4mb weight instead of 1mb base 4mb weight)
No, I want an alt-segwit without a block size increase(prefer: 0.6mb txdata 0.4mb witness(1mb total weight) instead of 1mb base 4mb weight)
No, I would prefer an alt-segwit without a "witness discount"
No, I would prefer segwit to be done as part of a hardfork
No, I will elaborate why in a comment

---

what should happen:
is node implementations are released first and the community upgrade. that way miners can see that a high percentage of nodes are running and able to FULLY validate and be ready to accept what miners will produce/allow later.
then when happy of a secure large % FULL validation by the network, the pools then and only then vote, due to being happy with the usernode adoption. and if pools reach the high percentage, then it activates. knowing the network is high majority fully validating

what should not happen:
pools flag, pools activate... and then users nodes upgrade later. (facepalm to that concept) with just 2week check and 2 week grace (double facepalm)
its especially bad when core are holding back an implementation so that users cant even use segwit wallet/transactions. and wont be available until after activation(i understand why its done, but still shoddy).. it seems like a rash rush to activate it before securing the network (thousands of nodes) to be able to utilise it.

again what should happen. and also what will make everyone happy
phase zero:
all the diverse implementations all supporting the feature, including a core version that offers dynamic blocksize (allowing 2mb base 4mb weight so everyone is happy including segwit fans) where OPTIONS within the node offer dynamic changeable settings (there is no reason for devs to spoon feed settings when users can/should change settings to then let consensus decide that everyone wants it, not the devs)

phase one: users(full nodes)
a year is given for getting to 95%, when/if it is at 95% at any time within the year..(a)
a month is then given to ensure it stays at 95%, incase of temporary fluke/sybil attack etc(b)
and then a months grace(c)

obviously if it does reach 95%(a) that is about 270 of 5400 not upgraded. probably less than 270 at(b) and even less at (c)
obviously if it never reaches 95%(a), it doesnt move to (b) or (c) or phase 2

phase two:pools(full nodes)
mining pools flag their desire(happy that phase one wasnt a fluke/sybil, etc).
again no timescale to reach 95% for pools. but at 95%(d)
a month is given to ensure it stays at 95%(e)
and a months grace(f)
obviously if it never reaches 95%(d), it never activates, no drama, no fuss

please note:
the time between (b) and (f), ends up being many many months. meaning alot of time is given for the ~270 lingering user nodes to well surpass the 95%
thus only making the orphan risk well under 5%.

all core need to do is simple.
dont do a miner vote and then users node adoption later for 1mb base 4mb weight(pushing segwit into activatatioon before usernodes are readily available to be full nodes)

but instead do
users node adoption vote for 2mb base 4mb weight (meaning segwit still happens but as hard fork) where nodes are readily avalable as full nodes before activation
then miners vote to activate it

then everyone is happy.

segwit would be using the bitcoin network. so segwit is not an altcoin but features of it and who programmed it does rub very much against the ethos of what bitcoin is, the way it bypasses node consensus. the lack of concern of diversity, etc.
but LN is definitely a different kettle of fish.

however segwits abilities and promises are not going to be met, compared to the utopian dream plastered out last year
EG
malleability fixed. you need to ask what was the end user experience that malleability was causing in the first place.
1. double spends.... um RBF, CPFP have been added to make double spends possible... so the fix solves nothing
2. LN working.. well LN is a dual signing mechanism. so if someone wanted to create a malleated tx with higher fee, after signing the first tx.. LN wont allow it anyway because the second tx needs dual signing anyway just like the first tx did, and the peer wont sign a second tx. so malleated transactions wont even reach a block due to not having dual signatures. in short, a peer would reject a malleated tx simply by seeing their counterpart trying to make one.

EG
TX fee
its said that the tx fee will be 75% cheaper. more accurate numbers are 40% cheaper. and due to the transaction price going from 3.5cents last year to over 7cents today. its not really making transactions 'cheaper' (not below 1cent like in 2012) but still at 3cent+ which will rise quickly due to other fee war pushing mechanisms added to the new implementation

but hey. everyone will argue that using real code to fix problems of bitcoin is meaningless because soon LN, soon sidechain will save the day.. (facepalm) pushing the problem down the road and into a different direction rather then dealing with it

you're not understanding what blockchain is.
imagine it like the difference between

DBMS - database management systems
RDBMS - relationship management systems

even your quote is saying the opposite of what your thinking.

not

in short a blockchain can work on one system. a blockchain can be edited by having multisig instead of hashes. which the owners of the keypairs have full access to.
a blockchain has no big built in technology requirements to be deemed a blockchain. it just needs something(literally anything) that links one lump of data to another lump of data.
that is all..

once you realise that the quote you pulled up is trying to specifically talk about bitcoins blockchain by talking about transactions, proof of work(mining) and decentralization.. rather than the fundamentals of a blockchain. you will realise that blockchain alone is not big of a deal. but what can be done once you add on the other options could make it a big deal.
emphasis: options added ontop.

now as for HOW the banks will use that simple mechanism.. well there are a million ways it can use it.
options outside of the term blockchain, but easily programmable in to increase security of a blockchain
it could go PoA, PoS, PoW, PoL, PoT
it could use SHA, ripemd, md6, (list goes on) or a combination
it could be central to one location, or distributed to regional hubs, distributed to local bank branches.
it could be split up. where local locations only holds one block of data per location and the region just holds the headers of all locations
it could be split up. where central location holds all data, and the region only holds the headers of all blocks
it could be split up. where specific location only holds the headers of all blocks and the region holds all data
all options are open
now all the stuff above is just protecting the outer shell (the blocks)

as for the data inside
the data can be anything. doesnt need to be financial (eg ID, medical records, inventory, even a phonebook/yellowpages)
the data can be locked with hashes, or signatures or timestamps, or any other method.
the data can be stored/checked as anything, hex, json, ascii, xml or anything

again a blockchain is not a big deal alone. but opens up the possibility to what can be done
the blocks and data within blocks can be secured not by requiring storing the whole data on every secure system. but just storing the link between the block securely

eg
"data123data123data123data123"-linkabc-"data456data456data456data456"-linkdef-"data789data789data789data789"-linkghi
you dont need to store all of the line above. you can as an option ontop. have the main 'checking' mechanism just stores
linkabc-linkdef-linkghi
and program it so that the system should reject a block unless its 'header' (link) is recognised.

now again how the banks will use blockchain. is another question that cannot be answered. because blockchain is just a small tools that allows MANY things top be built ontop of it and inside it... that traditionally were not being done

blockchain is not the end solution with built in security. its just a new tool that expands what the old database models limits were. and allows freedom to build layers ontop and new ways of storing/distributing/validating/editing/securing.

think of it as changing from a DBMS to a RDBMS where it opened up new options of use.
blockchain is just the next level up from that. allowing more options of use. but alone is not a big deal

its called the placebo effect wait a year and come back and see the difference

so far segwits features are not active. it requires users to download another version after activation before anything is noticable

the "whitepaper" is 90% rant.. i gave up reading about all the flaws of other systems and then a sudden injection of what this "peerless"  thing meant to do.

i think its more of a brownpaper than a whitepaper. definitely needs a major re-write

most?

4 days: 3.6%
https://blockchain.info/charts/bip-9-segwit

dont expect activation by christmas
definitely dont expect anything to change a minute after activation.

you will need to download yet another implementation to actually make a segwit transaction using segwit compatible HD seed keypairs
meaning users, merchants and pools will yet again need to test the implementation and move funds around.

again this topic is not about finding the bitcoincreator.

but finding a random person in a separate game where the person has the same name. the game predates bitcoin by a decade.

this is a game that predates bitcoin.
its a puzzle game more so than finding wally/waldo thing, as it requires cards that link to cryptographic and logic puzzles

for all we know bitcoins inventor liked the game and decided to assume the pseudonym due to that game, knowing after a decade of unsuccessfully "finding satoshi" in the game was futile, even with clues.. the bitcoins inventor could have decided to use that name as a hat tip to anonymity.

no one is saying the guy behind the pre-dated game is the same physical person. but it could elude to how the bitcoins inventor chose his name AFTER playing the game and taking a liking to the name

segwit is the bait to introduce dual-managed transactions (LN) removing peer-to-peer(no middlemen) and replacing it with peer-custodian (hub middlemen)

https://lists.linuxfoundation.org/pipermail/lightning-dev/2016-November/000648.html

as for cheap transactions. read the open office spreadsheet linked in the "results" part of the link above
and then click on the "marketing conditions", "prepaid" both suggesting 0.006 btc pre-pay LN fee

if you check the other tabs. it only becomes a cheap fee if you are using it every second. however using it just once a day.. not cheap

to use LN users need to PREPAY 0.006btc which based on a 10day locktime
and it actually costs you more to not be spending. EG dont expect to get 0.0059xxxx back if you only do a couple transactions in those 10 days.

$4+(0.006) 'pre-pay' is a barrier of entry.
would you pay $4 every 10 days just to use a service?? which then charges you for not using it, and only works out beneficial if you are doing lots of transactions a day.

if yes then if you want to do grocery shopping. prepare yourself for scanning one item at the cashiers desk and paying for that item, scanning another and pay, scan another and pay just to get the best deal for the end transaction cost when the 10 days are up.

oh and if you want to close the channel early hoping to avoid paying a time compensation. forget it. there is a penalty for closing the channel early too. also by not signing in a convenient time (measured in seconds) you are penalised aswell.

seems LN have not thought about using code to mitigate risks of DDoS, errors, blackmail. but instead used greed of economics to find the penalty/prize values of avoiding DDoS, errors, blackmail.

LN is more about making the hubs money by users entering into a dual-signed address where the user then has less independent power of their own funds, while costing the user for not using LN efficiently.

dont think LN is going to be the saviour of cheap transactions.. its a bait and switch.. its just about faster method of 'trust' that the funds will be paid, while continuing to push the fee war on to make bitcoin have less utility due to cost of use.

if only these devs can stop playing the economics game of bankers and instead use actual code to mitigate risks, instead of fee's
seems devs think fee's are the answer to security. and forget that code can do the job much better

your concentrating too much on a january 2009 start date.. and not the difficulty curve of the first 3 weeks (of any random date an attacker migh start to then re-write the chain).

i didnt literally mean someone goes physically back in time to january 2009 and start mining. i just used that date as any random date to to show within a year it would not be at block 439,600

pick any start date. where 2.1exa hash mines from a block1 difficulty 1.. within a year it wont be at block 439,600

EG pretend wuille decided to use 2.1exahash in 2013 by 2014 he would not have taken over the mainnet chain. it would take until 2018 to reach whatever block the mainnet was at in 2013 (due to difficulty changes, the first 9 months mining is done in 3 weeks, the rest is stable)
basically 4 years of data is redone in 3 years 3 months (8-9 month difference)

EG pretend wuille decided to use 2.1exahash today by nov 2017 he would not have taken over the mainnet chain. it would take until jan 2025 to reach whatever block the mainnet was at today (due to difficulty changes, the first 9 months mining is done in 3 weeks, the rest is stable)
basically 7 years 1 months of data is redone in 7 years 2 months (8-9 month difference)

all its done is shaved off 9 months of hashing right at the start before then stabilizing to the 2016blocks/fortnight.
the 2.1exa wont make 439,600 blocks in a year. due to difficulty adjustments stabilizing how many blocks are made.

oh and by the way. hashpower is not the measure of which chain wins.
its hashpower that makes blocks faster or slower and its the chain of most blocks that are deciding factor

cause -> action -> reaction -> effect
hash -> blockheight ->longest chain->follow chain
not
hash -> follow chain

after all if went back to lets say 2013 and wave in the air we have 2.1exa and the bitcoin mainnet has only 100thash
suddenly everyone will not follow the 2.1exa simply due to larger hashpower.
as on day 1 the 2.1exa would only be at block 36288
but bitcoin mainnet would be at over 210,000

it requires the attacker to OVERTAKE the BLOCKHEIGHT.

and difficulty adjustments have proven it wont be done in a year.

but hey you'll just ignore the math and just talk about a time travelling sci-fi randomly chosen start date.

we should be thinking about moving the minimum fees down to 100sat/kb. when the fiat valuation rises.

but nah. core wants to push the fee war by introducing 0.0002 fall backs and then average fees etc
rather than letting transactions through and letting pools be instantly reactive to demand and open to decide,

so lets show a scenario where nodes AND pools used the "averaging" instead of reactive

in the future it wont matter what you set in your node. if someone else in the network had their relay fee set to "average" or say 0.00024. this will cause transactions to hop around the network of ethical nodes but then get dropped by the expensive node BEFORE even getting to a pool.

imagine there were 7 hops to reach a Pool from yoUr node, and each node in the relay set a different rate

U->0.00010->0.00012->0.00016->0.00018->0.00020->0.00022->0.00024->P

now imagine you have 1000tx of 0.00011 they get dropped here. and pool never sees it
now imagine you have 1000tx of 0.00019 they get dropped here. and pool never sees it
now imagine you have 1000tx of 0.00023 they get dropped here. and pool never sees it
now imagine you have 1000tx of 0.00024 they get through and pool sees it

whatever node has the highest rate between you and a pool becomes a gatekeeper, keeping cheap transactions from reaching the pool. forcing people to pay more just to be let past the gatekeeper to even be seen by the pool.
enforcing a fee war of a price rise just to be seen even during low demand.

also pools themselves wont just add any tx if demand was low not just because they are not even receiving tx's but also the "average fee" doesnt instantly react. but slowly reacts over a number of blocks. as they are no longer reactive to just add what they please, but now what gets added is based on an "averaging".

now continue imagining the pool only sees transactions over 0.00024(due to average previous demand). and an "average fee" of 3 hours (like 21.co uses) takes upto 18 blocks to bring the average down. meaning pools then makes empty blocks. until the average drops enough to see cheaper transactions

meaning if there were only 4000 sent in one 3 hours segment. where blocks allow 2500tx in per block
where the "average" network fee starts at 0.00024 due to previous demand

now imagine the 4000tx's vary in fee like this:
1000tx of 0.00011
1000tx of 0.00019
1000tx of 0.00023
1000tx of 0.00024

3000 would not even reach the pool straight away due to expensive relayers dropping the tx, treating it as third class citizens

it would look something like this:
block 450,000 - 1000tx (average already at 0.00024) <-the relay network only lets the 1000tx at 0.00024 to reach a pool
block 450,001 - 1000tx (average decreases to 0.00022667) <-the relay network only lets the 1000tx at 0.00023to reach a pool
block 450,002 - 0tx (average decreases to 0.00020148) <-the relay network hasnt let any tx to reach a pool
block 450,003 - 1000tx (average decreases to 0.00018889) <-the relay network only lets the 1000tx at 0.00019 to reach a pool
block 450,004 - 0tx (average decreases to 0.00016371) <-the relay network hasnt let any tx to reach a pool
block 450,005 - 0tx (average decreases to 0.00015111) <-the relay network hasnt let any tx to reach a pool
block 450,006 - 0tx (average decreases to 0.00013852) <-the relay network hasnt let any tx to reach a pool
block 450,007 - 0tx (average decreases to 0.00012593) <-the relay network hasnt let any tx to reach a pool
block 450,008 - 0tx (average decreases to 0.00013333) <-the relay network hasnt let any tx to reach a pool
block 450,009 - 0tx (average decreases to 0.00011334) <-the relay network hasnt let any tx to reach a pool
block 450,010 - 1000tx (average increases to 0.00010074) <-the relay network only lets the 1000tx at 0.00011 to reach a pool

but sticking with the "average" scenario.
ofcourse human emotion would see the 450,002 was empty so the 2000tx that got rejected for the 3rd time. would up their price to get into 450,003
block 450,003 - 2000tx (average decreases to 0.00018889) <-the relay network lets the 2000, >0.00019 tx to reach a pool
and bring the average over 0.00019000

however if pools were instantly reactive to demand. and the relay network was instantly reactive. instead of the stupid concept of averages.
in this low demand scenario all transactions would have been included in 2 blocks..
eg
block 450,000 - 2500tx - includes 1000 at 0.00024, includes 1000 at 0.00023, includes 500 at 0.00019,
block 450,001 - 1500tx - includes 500 at 0.00019, includes 1000 at 0.00011,

not 11 blocks with 7 blocks being empty if just left to wait for averages to drop, or 4 blocks if getting peed off to pay more due to emotional rejection and seeing an empty block