yes the orphan rate would be higher if all pools didnt stop..(because there is competition its more effiecient to stop and move to next block if competitor wins)
im not saying that pools now should do such a thing of continuing on the mainnet.. as that would make the current competition of 20 pools on one network less efficient. as i said try some testnet tests using usb asics.


im saying based on a network of 1 pool... to get some maths of average REAL blocktime if there was no competition(single pool network) then a pool would not give up(stale shares) would not solve but not bother propagating(stale blocks) would not lose the race(orphan) because there would be no competition. so al their background failed attempts become valid...

which would reveal they make more blocks in X time.. which would counter the 1dimensional overview of the 20pool competing network of only seeing and doing bad math on only the accepted blockchain blocks

anyway.. lets bring this back on topic
time for me to have a beer

because your only seeing the blocks that you see in the blockchain.. your not realising the blocks in the background that dont make it.
you would only understand it if you run some scenarios.

ok.. go learn about "stales" and you will see more of what im on about (stale blocks not stale shares) hint stale blocks are solved blocks that dont even get propogated.

then run scenarios where, even if a competitor has a solved block you actually continue until you have a solved block
then
only take the time from when you add the previous hash of the last block height. and take the time when the block is solved.
do not take just the time from the last block you created to the next block you created.

1. of course its not LITERALLY 10 minutes.... but its not 1 block an hour per pool either,
its much much closer to 10 minute (average) than it is to 1 hour (average)

firstly forget about the term orphans and the purpose of the orphan mechanism
2. realise that behind the scenes pools make blocks more often then you think
some propogate and get orphaned.. BUT
others get solved and pools just hold locally(not propagate) and just start working on the next block and only propagate the first block if the competitors fails validation..
also
some pools GIVE UP a few seconds/minutes before they would have got a solution, purely because its more efficient to give up and restart with new block
3. the point is of this whole meandered debate.. dont just see btcc making 5 blocks in 5 hours and say "pool only makes 1 block an hour"
the point is there is a vast difference between the time it takes to make a block.. and how often it win a race

the"orphan" link is not proof that only one competitor gets close. i only mention it as the easiest way to show dino that pools make more blocks then he thought.. that show that pools times are close... to counter dinofelis's 1-d thinking that only blocks ever made are the 6 blocks an hour that make it into a chain.

dino for month also fails to understand the purpose of non mining nodes..
so lets get back to that topic and let dinofelis spend a few months learning more about bitcoin to see the full depths of the many things that mak bitcoin way way way better and different to what h believes.

as i feel dinofelis is trying to think that bitcoin is just a centralised cheque clearing house that doesnt need nodes and only processes one batch of cheques/transactions an hour per cheque clearing house

i have always seen how it works.

when i have described it i have took my 3 dimensional view of it all and brought it down to 1 dimensional to describe the specific problems some people are not seeing..

i NEVER said or presumed that orphan blocks account towards difficulty..
the only reason i linked the orphans was to show that other blocks are made behind thenscene/forgot about within seconds.

id say dinofelis has about a year more research and running scenario's before he see's al the many things that make bitcoin what it is.

anyway i could keep trying to make him try to see that if 6 pools had 1 block each an hour(combined means 6 blocks an hour as a united network) does not mean they would take 6 hours if they went at it alone..

---

seriously!!
you are taking the 100m race too literally as a comparison of the many factors..

the 100m was a analogy of explaining one part which you were mis understanding..

you were assuming a particular runners time was based on how often that particular runner won divided by an a minute(6 races) if there were 6 runners.

i was correcting your misunderstanding other runners in one race all start at the same time(when the se a previous hash as a trigger).

reality is that they are not timed from the last time THEY themself won. (which was your mistake)
nor
about how many races they won divided by 60 seconds (time of 6 races).. (your mistake again)
nor
by taking how many races are won by a participant over a given period EG 1 race every 20 years(5th olympic games) to then in your mind be it take them 20 years to run 100metres(taking your mindset to the extreme)

but by actually looking at how long it would actually take each runner to cross the finish line win or lose

---

anyway the dice game or even using USB erupters is better ways to run scenarios once you get passed your one dimensional view.

and the fact that without stopping when a winner is found would show if you actually cared about the runner-ups times rather then avoid looking at them, you would see there is a difference between how often racer A won a race. vs how fast he took per race.

and that was me trying to go down to a 1 dimensional view to try to match your one dimensional view
the 100m race was not meant to be a complete 3 dimensional comparison of bitcoin mining vs olympic races..

---

yes the dice game is better as it includes more factors, but it seemed you were only understanding things 1-2 dimensionally so i was answering things you misunderstand by trying to simplify things to 1-2 dimensionally, just to make you try to understand where each of your 1-2 dimensions were wrong.

it would take a whole book to waffle through the 3 dimensions that make up the whole mining process in detail.
..
anyway
answer this
from a 1 dimensional view you had are you still holding onto this mindset of:

out of 6 blocks. if a pool has 2 blocks in the chain, you still believe it takes 30 minutes to solve a block for that pool IF IT WENT ALONE
or
can you atleast now see from a 2 dimensional view that the pool could have had 6 blocks solved.. but just not qualifying as the ultimate fastest to get displayed/locked in the chain/win the race.

..
answer this
from a 2 dimensional view you had are you still holding onto this mindset of:
if you shot 5 out of 6 pools.. suddenly the 6th pool would find a block 6 times slower / 6 blocks in 6 hours without any competition
or
can you atleast see that from a 3 dimensional view that if you knew all the timings of all the pools WIN OR LOSE without competition it would win every block
AND
that every block would not be an hour apart but much less

ok.. illustration time


but lets look at all the pools times IF they didnt give up, win or lose the times they would make a block.. and to avoid dinofelis taking things too literally lets stretch out the "just a few seconds" to be a few minutes apart
(dont take it too literally)


and now lets see if his 6 hours to make 6 blocks still holds weight



dont take it tooo literally/knitpicky.
 just understand the concept that pools dont take an hour a block..

anyway, this whole block timing has meandered away from why its important to run a node, which dinofelis still needs a few months of learning bitcoin to realise the importance of non-mining nodes

but shhhhh dont mention, BTCC pool mines an empty block (#465117).

making blocks average to say 1minute means. that 12.5btc is made every 1min average instead of 10min average (or as amph notes 2016 blocks in 1.4 days instead of 14 days)
which results in the reward halving event every 145 days instead of 4 years.
which means all bitcoins will be mined in about 12 years as oppose to 120 years.

so to mess around with reducing block reward to 1.25 for 1min blocks. and then mess with the reward halving and so on to correct things back to scale, takes alot more coding than you think.. plus breaking a lot more fundamental rules..

ALSO
whether its 10 minutes or 1minute.. the people that say "10mins is too long" usually are buying things where even 1min would still be too long.
EG queuing up at a grocery store checkout. standing there, waiting a minute is still too long.
as many people know seeing someone count their change for 40 seconds instead of just swiping a card infuriates people.

dont believe me.
next time you are at a grocery store.. just stand there and do absolutely nothing for 60 seconds. and then look at the people behind you.
dont beleive me.
day trade on an exchange. see a good price and instead of hitting the order button.. just sit there for 60 seconds.. and then look to see if the good offer is still there.

---

now when it comes to data movement.
whether its 4032 blocks of 1mb each a month.. 4032 blocks of 10mb each a month
whether its 4032 blocks of 1mb each a month.. 40320 blocks of 1mb each a month

the bandwidth of both 'more data' is the same 40gb and anyone complaining about internet data caps will still run into the same problem

---

and as other have mentioned if blocks are being created once a minute, by the time they get passed to a node, verified, passed to another node, verified (the relay propagation) this can cause alot more congestion, orphans, rejects and other issues.

this is where pools who think they have won the fastest block, realise someone else beat them by milliseconds, and as such they end up wasting time and not getting as much income..

viper you are mainly right there is not enough info displayed because in most cases all you see is the winners, most pools give up/reset to start on the next block for efficiency reasons.

just to note
the difficulty is based on ONLY the 2016 blocks  ~fortnight that WIN being added to the blockchain. not including the hidden times of the blocks that did not win.

if people ran a test net and set up usb asics (cheap simulations) and run tests. not just on times of winning but times the other usb asics got a result if they didnt giveup they would get more data and see the real data of the network. rather than just data of the "winner first"

EG get 100 usb asics..
make 10 'pools' on a test net where each pool has 10 asics.. (same hashrate) and then time how long each pool solves a block.
by this i mean have it set that the pools dont give up/stop when there was a winner, but continue on until each pool has a solution for the same blockheight..

i guarantee you it wont be a=10min  b=20m c=30m d=40m etc etc..

or even cheaper.. do the dice game
or even cheaper get some friends to run 100 metre races

it will really wake people up once they see all the information

..
however just doing maths only on the winners ..is very 2-dimension thinking
not looking at the time of solving block 460,001 by subtracting the timestamp from the timestamp of 460,000. but foolishly counting blocks per hour of a certain brand, is very 1-dimensional thinking

what you ar not understanding is many more blocks are produced per hour then you think. some propagate and get displayed. some propagate but dont get displayed, some are solved locally but realise theres no point propagating them and some stop just short of getting a solution to save precious seconds that they could use making the next block

but either way you thinking antpool (using the examples above) averages a block every 30 minutes simply because you only publicly see 2 blocks in that hour. is FLAWED

you are not accounting for the blocks it SOLVED but didnt win.. or the blocks it didnt bother propogating. or the blocks it stopped just shy of solving to save time on the next round....

all you done is seen 2 blocks displayed and done 60mins/2 =30min average

https://blockchain.info/orphaned-blocks
465722
Timestamp    2017-05-10 08:19:11 Relayed By    Bixin
Timestamp    2017-05-10 08:19:10 Relayed By    GBMiners
1 second apart

464681
Timestamp    2017-05-03 18:55:39 Relayed By    ViaBTC
Timestamp    2017-05-03 18:55:46 Relayed By    BTC.com
7 seconds apart

464185    
Timestamp    2017-04-30 11:40:29 Relayed By    BitFury
Timestamp    2017-04-30 11:39:59 Relayed By    Bixin
30 seconds apart

463505    
Timestamp    2017-04-25 23:15:20 Relayed By    Bitcoin.com
Timestamp    2017-04-25 23:15:22 Relayed By    AntPool
2 seconds apart

---

imagine it this way knowing only one person can win... some STOP when they see a winner as there is no point wasting precious seconds.. and RESET and work on a new block.

this does not mean it takes them 30 minutes it just means that stopping the instant a winner crosses the line is good odds to stop and restart, rather than to continue for a few more seconds (1-30 seconds) in the narrow hope you are more valid than the fastest first.

there are many many layers of security, efficiencies, percentages, features at play. far more then dino is putting into context when he just counts how many "winning" blocks he sees. rather than how long it actually takes a pool to make a block win or lose.

there is a difference
again for emphasise
the number of blocks that win per hour vs how many blocks are created per hour

people need to actually run scenarios..

and not just do retroactive maths on only the results of winners..

look behind the winners and see the times of the undisplayed losers aswell to see the real times

lol
go check some stats, before making assumptions.


for instance. block 463505
how long did it take antpool to make their block knowing antpools previous block was 463503

i guarantee you it was not 30 minutes, based on dino's bad maths of counting blocks


hint..
will you start the count from 463504 when it added 463504 hash and started working on 463505..
or will you base it off of the last time antpool got listed at 463503

the time to make block 463505 is not based on the last time that same pool had a block in the chain..
but the time it took to create a block with the previous hash (463504) until it has a solution of 463505

again its not based on assuming
if in an hour antpool only shows 2 blocks in a chain of 6 that it can only make 2 blocks an hour... where you average it as 30mins
all that shows is that only 2 blocks beat the competition..
but separately could have made 6 blocks in the hour, but were just not quite quick enough to get listed.

as you can see by the orphan list.
it made a block 2 seconds after bitcoin.com.. but was simply seen as a runner up and not counted..

so again how long do you think it took antpool to make 463505
i guarantee you it was not 30 minutes, (which is based on dino's bad maths of counting blocks that got listed)
but IS about how long a pool actually gets a solution listed or not listed

TL:DR;
more blocks are made then you think... they are just not displayed.
if you could see all the blocks even the ones not displayed you would see things differently

---

lets word it a different way to end the debate
pools make blocks in an average ~10 minutes..

pools make SPENDABLE/publicly displayed blocks less often dependant on if the competition beats them

can i add that even core dont disclose issues for atleast a month after fix
https://github.com/bitcoin/bitcoin/issues/10364

the main blockstreamist trolls dont complain.. they (wrongly) think huge fee's are good for 2 reasons.
1. they have been told by their masters that one day they can run a LN hub and get many cents from users by just being on a route between customer/merchant

2. they are economists rubbing hands together thinking it helps raise the price of bitcoin

segwit was a secret project/altcoin as part of blockstream:elements, done separately from the bitcoin community from 2014-2015
consensus 2015 meeting was their first main roadmap that core decided to follow and have not listened/done the other things that the community asked of them.. its either the blockstream highway(roadmap) or no way..
no B roads, no diversion no secondary routes.. just follow blockstreams roadmap or get chucked off the network by the end of 2018

people have... but devs have their fingers in ears and only want to do things the way THEY plan using THEIR road map that THEY designed without any community input.

here is one example of a solution
develop a NEW priority fee formulae that actually does a job

also worth noting that the 86% includes versions of core 0.8 - 0.12 which are not even segwit compatible.
infact many are INDEPENDENT people that forked the core, and made their own tweaks and updates themselves and not bothered sticking with core.
some are even classic/BU/XT nodes in disguise to avoid DDoS attacks from the core gang who only attack user agents that appear not to be core.


also worth noting segwit is IMPLICITLY at 66% and EXPLICITLY well BELOW 66%

also worth noting and even funnier is that BTCC (highly ass kissing core/blockstream/segwit) doesnt even use cores upto date software, they done their own tweaks to their own pool software
https://bitnodes.21.co/nodes/?q=BTCC:0.13.1

activating segwit is meaningless..
the "extra space" for the cludgy 2merkle version of segwit is for users who move funds to new keypairs AFTER activation.. so that they can hang their asses the main block and have their feet spread out in another area. allowing more transactions to sit in the main area the first persons feet used to be in..

the issue is getting 46m outputs to switch over to segwit keypairs will cause a mega mempool fill event of people trying to move funds across.
the issue is malicious people will stay with native keys and fill the seats of the main block so even segwit users cant sit down. so never get to put their feet up out the way.

the solution is a 4mb single block where both native and segwit keypairs can all sitdown side by side all sharing the same area.. and then limiting what malicious things the native key users can do.

without sorting out the native key users.. segwit is an empty gesture, a hope..

no
the pool would make blocks on average of 10 minutes

if there was to be a hard consensus to move to dynamics.. then its much better to use that oppertunity to unite segwit AND native keypairs in the same area.
EG 4mb for both native and segwit to sit in, in a single merkle block. then have it increase by x% a fortnight.

people running speed tests know that on current modern baseline systems (raspberrypi3) and average internet speed of 2017 along with all the efficiences since 2009 (libsecp256k1) have revealed that 8mb is raspberrypi average home user safe..

so starting with a 4mb single merkle block would be deemed more than safe.

and remember
even with a 4mb rule DOES NOT mean pools will make 4mb instantly..
just like they didnt make 1mb blocks in 2009-2014 even with a 1mb allowable buffer..
pools done their own risk analysis and done their own preferential increments below consensus.