Pages:
Author

Topic: Please run a full node - page 5. (Read 6650 times)

sr. member
Activity: 686
Merit: 320
May 12, 2017, 04:26:27 AM
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.
sr. member
Activity: 686
Merit: 320
May 12, 2017, 04:08:38 AM
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").
hero member
Activity: 770
Merit: 629
May 12, 2017, 03:36:20 AM
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 ?
hero member
Activity: 770
Merit: 629
May 12, 2017, 03:27:59 AM
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.
legendary
Activity: 4270
Merit: 4534
May 12, 2017, 02:14:00 AM
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
hero member
Activity: 770
Merit: 629
May 12, 2017, 02:10:28 AM
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.
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
May 12, 2017, 01:15:12 AM
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.
full member
Activity: 184
Merit: 100
May 12, 2017, 01:12:26 AM
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.
legendary
Activity: 1232
Merit: 1030
give me your cryptos
May 12, 2017, 01:09:37 AM
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.
sr. member
Activity: 686
Merit: 320
May 12, 2017, 01:04:22 AM
#99
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
Where is the data that shows that pool A found a block a couple seconds after pool B? I don't know much about this stuff but if it's so close all the time one would think there would be a hell of a lot of orphans happening. Would that then mean this isn't an accurate reflection of that? https://blockchain.info/charts/n-orphaned-blocks Cause I'm only seeing 3 in the last month.

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

So roughly 0.18% of the blocks end up being orphaned. We know the averages that the various pools win a block. Since they stop the moment they know a block is found, we have no way of knowing what the real average would be for a given pool. I keep thinking about a calculation I saw last night from a few years back where someone posted how long it could take them to win a block given their hashrate and assuming the difficulty didn't change. It was anywhere from "immediately" to over 4 months running 24/7.

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.
legendary
Activity: 4270
Merit: 4534
May 12, 2017, 12:50:05 AM
#98
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
hero member
Activity: 770
Merit: 629
May 12, 2017, 12:42:34 AM
#97
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
Where is the data that shows that pool A found a block a couple seconds after pool B? I don't know much about this stuff but if it's so close all the time one would think there would be a hell of a lot of orphans happening. Would that then mean this isn't an accurate reflection of that? https://blockchain.info/charts/n-orphaned-blocks Cause I'm only seeing 3 in the last month.

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 its good odds to stop and restart, than it is to continue for a few more seconds (1-30 seconds) in the narrow hope your more valid than the fastest first.

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 !  But that doesn't tell you anything about all the non-colliding blocks !
hero member
Activity: 770
Merit: 629
May 12, 2017, 12:40:52 AM
#96
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
Where is the data that shows that pool A found a block a couple seconds after pool B? I don't know much about this stuff but if it's so close all the time one would think there would be a hell of a lot of orphans happening. Would that then mean this isn't an accurate reflection of that? https://blockchain.info/charts/n-orphaned-blocks Cause I'm only seeing 3 in the last month.

If ever franky1's view were right, we would have (N-1) orphans about every 10 minutes, where N is the number of competing pools.  After all, according to him, there were 10 runners, and only one won.  So the other 9 lost.  Each 10 minutes, we would have 9 orphans.
In reality, we have 2 orphans or so per week.

As I outlined elsewhere in this thread, orphaning comes about because of the network delays between mining pools, when a pool didn't see yet that a new block was won, continued mining on the old block, and happened to win exactly during that interval, that block - which will be rejected by the other miners because they had already received the new block.

The probability of that happening is equal to (window of network delay) / 10 minutes in a Poisson distribution with average time 10 minutes and small delta-t.

From the orphaning rate, one can estimate the average network delay between miners.  It is essentially given by 10 minutes, times the ratio of orphaned blocks over the number of blocks won in a given period, because "around each won block" there is this "window of orphaning" which is about the propagation delay (including checking of validity).

Roughly, if we have, say, 2 blocks orphaned per week, and in a week, about 1000 blocks are found, we have:

10 minutes * 2 / 1000 = 1.2 seconds.

From this, I can also conclude that miner pools are DIRECTLY connected, because they can hardly receive their blocks through random paths in the P2P network where each node checks the block as a whole, in such small times.
legendary
Activity: 4270
Merit: 4534
May 12, 2017, 12:38:55 AM
#95
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
Where is the data that shows that pool A found a block a couple seconds after pool B? I don't know much about this stuff but if it's so close all the time one would think there would be a hell of a lot of orphans happening. Would that then mean this isn't an accurate reflection of that? https://blockchain.info/charts/n-orphaned-blocks Cause I'm only seeing 3 in the last month.

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
hero member
Activity: 770
Merit: 629
May 12, 2017, 12:34:43 AM
#94
Absolutely. With the caveat that despite the misappropriation of the word, entities that do not mine are not 'nodes', by the original definition. That aside, you sum up pretty completely the reason that I run a fully-validating-wallet.

These are also the reasons why I run a full node, on a old core-duo PC in my basement, which I upgraded with a big hard disk, and at which I look once a month to see if it is still running.  The other reason is to study the system itself.  I actually don't use my full node as a wallet: I use a light wallet on another system, and I connect to my "empty" full node in those rare cases I use bitcoin to pay for something (once or twice a year, say).
sr. member
Activity: 686
Merit: 320
May 12, 2017, 12:25:46 AM
#93
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
Where is the data that shows that pool A found a block a couple seconds after pool B? I don't know much about this stuff but if it's so close all the time one would think there would be a hell of a lot of orphans happening. Would that then mean this isn't an accurate reflection of that? https://blockchain.info/charts/n-orphaned-blocks Cause I'm only seeing 3 in the last month.
legendary
Activity: 4270
Merit: 4534
May 12, 2017, 12:18:34 AM
#92
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
sr. member
Activity: 686
Merit: 320
May 12, 2017, 12:10:27 AM
#91
I had no idea what you all were "arguing" about. So last night I went off and finally got around to educating myself on exactly how mining works in regards to difficulty, hash rate etc etc etc. And even I can see franky1 is completely wrong.
legendary
Activity: 4270
Merit: 4534
May 11, 2017, 11:51:37 PM
#90
The 10 minute interval comes from the probability of the entire network hashrate solving a block, which can be expressed as a Poisson distribution.   If you take away most pools, your time interval goes up.

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
hero member
Activity: 770
Merit: 629
May 11, 2017, 11:36:38 PM
#89
There's really no point any more in trying to explain how mining works to you.
I did warn you  Undecided

It seemed unrealistic.
Pages:
Jump to: