Topic: Please run a full node - page 4. (Read 6680 times)

its not a race, its a lottery.  Guys, I tried.   

facepalm
im on about time between current block and last block
im on about time a pool is working on other blocks WIN OR LOSE!!!.

for instance
470000 A 10:00
469999 B 10:00
469998 C 10:00
469997 D 10:00
469996 C 10:00
469995 D 10:00
469994 A 10:00
469993 B 10:00

you/dino are counting from 469994 A to 470000 A = 60:00 = WRONG
what your not seeing is that 470000 was made 10:00 after 469999 B, meaning 10 not 60

also
470000 A 10:00
469999 B 10:00    A:10:01
469998 C 10:00    A:10:03
469997 D 10:00    A:10:01
469996 C 10:00    A:10:06
469995 D 10:00    A:10:02
469994 A 10:00
469993 B 10:00    A:10:07

(dont take the 1-7 seconds literally)

when 469999 was being made... A was also doing a fresh race of 469999 but didnt win.. this doesnt mean it didnt take A 10:01..
when 469998 was being made... A was also doing a fresh race of 469998 but didnt win.. this doesnt mean it didnt take A 10:03..
when 469997 was being made... A was also doing a fresh race of 469997 but didnt win.. this doesnt mean it didnt take A 10:01..
when 469996 was being made... A was also doing a fresh race of 469996 but didnt win.. this doesnt mean it didnt take A 10:06..
when 469995 was being made... A was also doing a fresh race of 469995 but didnt win.. this doesnt mean it didnt take A 10:05..
when 469993 was being made... A was also doing a fresh race of 469993 but didnt win.. this doesnt mean it didnt take A 10:07..

if you could see all the attempts in between of each blockheight you would see that its not spending an hour working on 1 block!!!

because if there was no competition.. A would not give up as soon as a competitor broadcast. because there would not be a competitor to stop them!!

meaning without competitors to stop them at stale share, or stale block or orphaned stages you would then see
470000 A 10:00
469999 A 10:01
469998 A 10:03
469997 A 10:01
469996 A 10:06
469995 A 10:02
469994 A 10:00
469993 A 10:07

(again dont take the 1-7 seconds literally)

You have a misunderstanding about mining, my friend.  The time from the previous block IS irrelevant.   You believe trying more nonces will make the next try more likely to succeed, when in reality each chance is completely separate. 

When you have 4 people telling you (dinofelis, myself, jbreher, _ck ) that you are incorrect...you might want to consider the possibility that you might be.
 

you still think you can get an accurate block time by only counting what you can see.
dinofelis thinks he can get an accurate time by not looking at the TIME from previous block. but just counting how many blocks a brand makes an hour

both of you are not thinking that pools are working on OTHER blocks inbetween which messes up your simple block counting.

run some scenarios. get passed the 1-dimensional view

its been 2 days and you are still counting blocks.................. ignoring what pools do inbetween and ignoring the times per block
i need another beer

You still seem to be under the impression that a block attempt gets you closer to a solution.

now your COUNTING orphans FACEPALM
look at the TIMES.

atleast look past the 1 dimension overview of counting blocks
if you really wanna derail a topic. run some scenarios. think about the stales, invalids, orphans, etc that happen inbetween that you never see and think about the TIMES of that block subtracted by the TIMES of the previous block that the block contains(its parent)

again your not thinking about the 20 pools that LOSE when one pool wins..
think about the attempt pools make that LOSE

orphans are just one example dont do the foolish count blocks per hour
or count blocks made by pool between when the last time pool X made a block and the same pool made a block..
because your not thinking about all the other block attempts inbetween

use the TIME of the block it has as its previous hash against the time of that block

look at the TIMES
doing block counting is just 1-dimensional. especially if you cannot see all of the block attempts to make a fair count

https://blockchain.info/charts/n-orphaned-blocks

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

That would mean that the orphan rate is 600%. 

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.

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.

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

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?

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

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?  

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

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.

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×pan=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.

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.

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.