Please run a full node

[cryptomium]

I'm pretty sure running a full node only helps with network propagation (Only if your internet connection is fast, otherwise someone else will do your job) and preventing false transactions from propagating. I your connection speed is too slow, you won't be sending anything, just receiving. You'll be a waste if bandwidth.

You will need to mine to make any difference to Bitcoin "politics", or make the blocks more secure.

But the main question is, why would I run a node when all the incentives is being taken by miners?  I think this is one of the flaws of Satoshis plan.  He would never think that asic would come into play and that pc that should alse be running a full nodes and mining  will become obsolete and can only function as full node without any incentives.

[-ck]

Frankly I think you're both "wrong" as, unless there's more info I'm not aware of, we simply don't have enough real data to know what the true average time is for a given pool. Saying if all but one pool stopped that the blocks would continue on being generated every 10 minutes with the exact same difficulty is clearly wrong. As is saying that the "win" average is an accurate representation of a pools true average if they were the only one solving blocks at a given difficulty.

But that relationship is a known relationship; the current network mining difficulty and likelihood of finding a block according to hashrate. That's precisely what diff is. One finds a block on average every N diff shares where N = the current network difficulty. The vast majority of pools record the difficulty% number of shares each block takes to find and report it as luck. If block finding was not proportional to hashrate / network difficulty, then the bitcoin difficulty mechanism would be broken.

[dinofelis]

Frankly I think you're both "wrong" as, unless there's more info I'm not aware of, we simply don't have enough real data to know what the true average time is for a given pool. Saying if all but one pool stopped that the blocks would continue on being generated every 10 minutes with the exact same difficulty is clearly wrong. As is saying that the "win" average is an accurate representation of a pools true average if they were the only one solving blocks at a given difficulty.

You should understand what "mining" is: it is finding a hash of a given block that satisfies a "rareness" condition: the difficulty.  If the difficulty is, say, 1000, that means that only one hash out of a thousand satisfy this requirement.  Now, the specificity of a cryptographic hash is that you cannot have the slightest idea of what it is, before you've calculated it.  This means that each time you calculate a hash of something, you have one chance out of 1000 to have a hash that satisfies the condition.  But it is really random.  It could be the very first hash you calculate, and it could be only after you've calculated 2000 of them.    However, ON AVERAGE, you will win one good hash every 1000 hashes you calculate, because, exactly, one hash out of 1000 is a good one.

Now, your hardware can calculate a certain number of hashes per second: it is your "hashrate".  If you can calculate, say, 20 hashes per second, then you will need 50 seconds to do 1000 hashes.  So ON AVERAGE, you will win a good hash every 50 seconds.  But it can be after 1 second, or it can be after 200 seconds, because the lottery is random.  However, ON AVERAGE you win a block every 50 seconds.

Now, bitcoin (and many other PoW crypto) have a self-regulating difficulty, so that the difficulty INCREASES until the average time of winning a block is 10 minutes for the whole network.  However, this update of difficulty happens only once every 2000 blocks (2 weeks if we have, exactly, 10 minute blocks).  In our discussion here, we are considering short time spans, with constant difficulty.

It means that the hashrate of the whole network is such that on average, the whole network wins a good hash every 10 minutes.  If you have only, say, 10% of that hash rate, you will only win a block, on average, every 100 minutes.  As the "winning of a block" is entirely random, the "moments of winning" by a given pool are rarely coincident.  So MOST OF THE TIME, you win the block of which you find a good hash, because exactly at that moment, no-one else is winning a block.
It is only in those rare circumstances that you won a block and someone else did too, on the same old block, that one of them has to orphan, as decided by the other miners.

[franky1]

Frankly I think you're both "wrong" as, unless there's more info I'm not aware of, we simply don't have enough real data to know what the true average time is for a given pool. Saying if all but one pool stopped that the blocks would continue on being generated every 10 minutes with the exact same difficulty is clearly wrong. As is saying that the "win" average is an accurate representation of a pools true average if they were the only one solving blocks at a given difficulty.

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

[dinofelis]

or even cheaper get some friends to run 100 metre races

I said you're a hopeless case, but as sometimes you do make good points, I cannot wrap my mind around you being confused to that point.

People running races are doing *cumulative* work.  If you run a race, you cannot win the race at your first step.  You have to do a certain number of steps.  This is why this is a bad analogy with mining, where each hash is an independent lottery draw.  People running do not "draw a lottery of winning" at each step they take in the race.  The distribution of winning of race runners is strongly peaked around "10 minutes".  It is not an exponential distribution.
A guy just starting out and doing his first step has much less chances to win the race, as compared to a guy that has already run 90% of the distance.  While a miner calculating one single hash has just as much chance of winning a block than someone who has been hashing for the last 50 minutes, at the next hash.

If you want a better analogy, take sets of 5 dice, and consider that the difficulty is "throwing at least 4 times a six out of 5 dice".

Suppose that you are throwing your 5 dice every 3 seconds.
Suppose that others are doing the same with their dice, but some throw them every second, others, only every 5 seconds.  (they have different hash rates)

Whenever one of you "hits" a 4 six out of 5, he "wins a block".  It is only when two of you happen to win within the same second, that the first one wins, and the second one loses his won block.

Think of how "the others winning" influences the rate at which you win, and how many times you lose because of competition.

[dinofelis]

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..

Did you do this yourself ?
Or are you also "reasoning with math" ... or without it ?

[Viper1]

You should understand what "mining" is

As I said, I went and did a bunch of research on it yesterday so have a much clear idea today.

It means that the hashrate of the whole network is such that on average, the whole network wins a good hash every 10 minutes.  If you have only, say, 10% of that hash rate, you will only win a block, on average, every 100 minutes.

That's really the most important part of your post. Assuming all things being equal, I can see how that would be true. I assume that somewhere out there is statistical "proof" of all of this? There was some online calculator that was supposed to provide that sort of information but it doesn't seem to exist anymore.

I do have a couple questions about pool mining. Getting real information about the nuts and bolts of how it works proved a bit more difficult as most things just talked about how payouts are determined etc. Since pool miners are "wasting" a bunch of their hash rate proving they're actually working, does that result in an overall lower difficulty for the network compared to if everyone was solo mining? Along with that, are they also wasting a lot of power which means that they're less profitable compared to if they were solo mining (not taking into account the many years it could take to actually reach any sort of "average").

[Viper1]

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

Huh? How could that be. Each pool is trying to solve a completely different block (data). So even if they all had the exact same hash and miners etc, they would solve their problem at much different time frames. If that wasn't the case, all the math behind this stuff simply wouldn't apply.

The thing about your racer analogy is that each runner is actually on their own track and they're of different lengths (not even taking into account that each racer runs at different speeds and that each track is actually a treadmill and each treadmill is at a speed representing the current difficulty). So they each complete their race at different times but the average is 10 mins. Next race, they're assigned to completely different tracks. Is this analogy not far more representative?

I can see how pool mining should narrow the distribution, But even so, we're talking such large time frames that I can't see it being such that all the pools are within a minutes or two of each other. Surely there's some actual statistical information out there on this.

[dinofelis]

You should understand what "mining" is

As I said, I went and did a bunch of research on it yesterday so have a much clear idea today.

It means that the hashrate of the whole network is such that on average, the whole network wins a good hash every 10 minutes.  If you have only, say, 10% of that hash rate, you will only win a block, on average, every 100 minutes.

That's really the most important part of your post. Assuming all things being equal, I can see how that would be true. I assume that somewhere out there is statistical "proof" of all of this? There was some online calculator that was supposed to provide that sort of information but it doesn't seem to exist anymore.

This is a property of Poisson processes.  In fact, exactly the same things happen with elementary particle detection.
The union of two Poisson processes is again a Poisson process that has a "count rate" that is the sum of the individual processes.

https://www.probabilitycourse.com/chapter11/11_1_3_merging_and_splitting_poisson_processes.php

So, if you have 10 miner pools which each, win a block, on average, every 100 minutes, their combined Poisson streams are a Poisson stream with an average of 10 minutes.

The picture there is a very good illustration of the mining process:



Orphaning happens when two "merger points" happen so close in time, that the "late" one was still working on the wrong block.  This happens when they are "closer in time than the time needed to learn the existence of the new block.

The particle detection analogy is the following:
Each miner pool corresponds to a certain intensity of particles (say, photons).  All the mining pools together make up the intensity of the total beam.  A particle detector (photomultiplier) sees them arrive at a rate of one every 10 minutes ; but each beam individually is of lesser intensity.
The "orphaning" corresponds to the dead time of the detector in this case.
If you switch off the beams of the other miners, and only keep one, you have lower intensity, and hence a lower count rate in the detector.

Pool mining is just distributing the hash tasks over different miner "customers" but it acts as one single miner.  

Apart some small overhead, there's normally no difference between, say, 10 independent miners, and these 10 miners pooling together, as seen from the outside.

The reason for pooling is that these independent miners would simply only win, say, 1 block every year ON AVERAGE, but the POOL will win 10 blocks a year on average.  This makes the miners have more UNIFORM income.

[-ck]

I do have a couple questions about pool mining. Getting real information about the nuts and bolts of how it works proved a bit more difficult as most things just talked about how payouts are determined etc. Since pool miners are "wasting" a bunch of their hash rate proving they're actually working, does that result in an overall lower difficulty for the network compared to if everyone was solo mining? Along with that, are they also wasting a lot of power which means that they're less profitable compared to if they were solo mining (not taking into account the many years it could take to actually reach any sort of "average").

No. The proof of work at lower difficulty adds zero overhead since it doesn't happen at the actual ASIC level but at either the communicating FPGA or the CPU controller level. Consequently there are also no wasted hashes mining at regular pool difficulties versus solo mining.

[dinofelis]

Concerning the "miner pool network back bone", I think one can see proof of that in the following plot:

https://blockchain.info/charts/n-orphaned-blocks?timespan=2years

or even more telling when taking 7 day averages of the DAILY number of orphaned blocks:

https://blockchain.info/charts/n-orphaned-blocks?timespan=2years&daysAverageString=7


Clearly, we see that the probability to get an orphaned block has dropped significantly these last two years, which means that the synchronisation between miners has smaller and smaller time jitter.  Miner pools are faster and faster aware of each-other's blocks and right now, the time window in which the important pools are aware of one-another's blocks is less than 2 seconds (estimated 1.2 seconds) from the orphaning rate.

In 2015, we have grossly 1.5 orphaned blocks per day, which puts us at a "synchronisation time between pools" of (144 blocks per day):

(1.5 / 144) * 600 seconds = 6.25 seconds.

Recently, we see rather 0.29 blocks per day, so (0.29 / 144) * 600 = 1.2 seconds.

This means that in 2015, it took the major pools about 6.25 seconds to receive a block from another miner, and to check it ; today, this time is only 1.2 seconds.

This, while the block size

https://blockchain.info/charts/avg-block-size?daysAverageString=7&timespan=2years

increased by a factor of roughly 2 (from about 450 KB in 2015 to 0.9 MB now).

This essentially means that the connection speed between the major pools increased by a factor of 10.4 over 2 years time.

[-ck]

Concerning the "miner pool network back bone", I think one can see proof of that in the following plot:

https://blockchain.info/charts/n-orphaned-blocks?timespan=2years

Clearly, we see that the probability to get an orphaned block has dropped significantly these last two years, which means that the synchronisation between miners has smaller and smaller time jitter.  Miner pools are faster and faster aware of each-other's blocks and right now, the time window in which the important pools are aware of one-another's blocks is less than 2 seconds (estimated 1.5 seconds) from the orphaning rate.

4 things have happened that contribute to that decreased orphaning rate.

The Chinese pools have all adopted the use of SPV/SPY mining from as many other pools as possible as a workaround for their butt slow blockchanges in their pool software; thus they've achieved very fast blockchanges based on headers only from other pools but create empty blocks as a result and risk creating a broken extended fork without full verification the way they did in the past. They've gotten smarter about it now and switch to verified work sooner than they used to but empty blocks are still a problem with them.
The non-Chinese mining pools have spent a lot of time optimising their code to improve blockchanges and minimise propagation times with better knowledge of how important this has been in the last couple of years; usually they've added remote nodes across the planet to help propagate their own blocks from multiple places.
Bitcoind from CORE has gotten a lot faster as of 0.13 and even more so with 0.14 with a much faster mempool implementation and the implementation of compact blocks. BU which is based on 0.12 does not have these performance improvements; they implemented their own x-thin implementation that has had network-wide crashes on multiple occasions from bugs in it.
Matt has been maintaining his relaynetwork and more recently fibre network which most pools have connected to which minimises block propagation time for all pools who connect to it; see http://bitcoinfibre.org/ He helped contribute to the core improvements previously mentioned.

We often benchmark the speed of block changes at pools to get an idea of likelihood of orphaning; one of the forum members maintains a site here https://poolbench.antminer.link/ which shows the delta of the last ~500 blocks (slow to load, be patient and refresh if it comes up with bugs.) If you look at the list there you will see a cluster of Chinese pools all first - these are all performing header only mining which is why they're faster than the rest. The next fastest pools are all my *.ckpool.org pools as I've spent a lot of time myself in optimising my own pool code, coin daemon, and network, and are still full verifying nodes. Note that poolbench is located in west coast USA so the speed is affected by the relative latency to that place.

[dinofelis]

Concerning the "miner pool network back bone", I think one can see proof of that in the following plot:

https://blockchain.info/charts/n-orphaned-blocks?timespan=2years

Clearly, we see that the probability to get an orphaned block has dropped significantly these last two years, which means that the synchronisation between miners has smaller and smaller time jitter.  Miner pools are faster and faster aware of each-other's blocks and right now, the time window in which the important pools are aware of one-another's blocks is less than 2 seconds (estimated 1.5 seconds) from the orphaning rate.

4 things have happened that contribute to that decreased orphaning rate.

The Chinese pools have all adopted the use of SPV/SPY mining from as many other pools as possible as a workaround for their butt slow blockchanges in their pool software; thus they've achieved very fast blockchanges based on headers only from other pools but create empty blocks as a result and risk creating a broken extended fork without full verification the way they did in the past. They've gotten smarter about it now and switch to verified work sooner than they used to but empty blocks are still a problem with them.
The non-Chinese mining pools have spent a lot of time optimising their code to improve blockchanges and minimise propagation times with better knowledge of how important this has been in the last couple of years; usually they've added remote nodes across the planet to help propagate their own blocks from multiple places.
...

Thanks for that update from someone in the business !

My point is simply that "Joe's full node in his basement" is not going to stop miner pools communicate blocs if ever the protocol that Joe's full node is running doesn't comply with the protocol all miners are running, and that the speed of connection between mining pools confirms this.

As such, Joe's "full node in his basement" is not "keeping the mining pools in check" and cannot stop them from getting one another's blocs to continue building the bloc chain according to the protocol that miner pools agreed upon (whatever that is).

[jonald_fyookball]

You cannot even use the time stamps at seconds precision, because the lower bits of the time stamp are used as nonce.

Most of the orphaned blocks are in reality much closer in time - simply because if the window of "collision" were bigger, there would be much more of them.

What you do, is post selection bias, however.   ALL orphaned blocks will be close in time !  Otherwise, they wouldn't collide !

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

It doesn't matter at all that there is a non-zero orphaning rate.   The difficulty adjusts to the actual number of blocks being added to the chain.  
 
Hopefully you see how it works now?  

[franky1]

It doesn't matter at all that there is a non-zero orphaning rate.   The difficulty adjusts to the actual number of blocks being added to the chain.  
 
Hopefully you see how it works now?  

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..

or even cheaper get some friends to run 100 metre races

I said you're a hopeless case, but as sometimes you do make good points, I cannot wrap my mind around you being confused to that point.

People running races are doing *cumulative* work.

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

[jonald_fyookball]

It doesn't matter at all that there is a non-zero orphaning rate.   The difficulty adjusts to the actual number of blocks being added to the chain.  
 
Hopefully you see how it works now?  

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..
 

If 6 pools each got one block added to the blockchain per hour , then 1 pool by itself might get blocks a bit more often than once an hour because of the absense of orphaning, but it definitely doesn't mean they would suddenly start solving blocks every 10 minutes by themselves.
 
Do you agree?

[franky1]

If 6 pools each got one block added to the blockchain per hour , then 1 pool by itself might get blocks a bit more often than once an hour because of the absense of orphaning, but it definitely doesn't mean they would suddenly start solving blocks every 10 minutes by themselves.
 
Do you agree?

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

[jonald_fyookball]

If 6 pools each got one block added to the blockchain per hour , then 1 pool by itself might get blocks a bit more often than once an hour because of the absense of orphaning, but it definitely doesn't mean they would suddenly start solving blocks every 10 minutes by themselves.
 
Do you agree?

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)
 

Why would it be closer to 10 minutes when they would have 1/6th the hashpower?  It's not like the orphan factor would account for a 600% increase.  So, that don't make no sense.

[franky1]

Why would it be closer to 10 minutes when they would have 1/6th the hashpower?  It's not like the orphan factor would account for a 600% increase.  So, that don't make no sense.

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.

[jonald_fyookball]

Why would it be closer to 10 minutes when they would have 1/6th the hashpower?  It's not like the orphan factor would account for a 600% increase.  So, that don't make no sense.

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)

That would mean that the orphan rate is 600%.