Please run a full node

[Qartada]

Moral of this topic:  franky1 isn't listening to a vast selection of technically proficient users explaining in detail why his perception of mining is wrong.

[1713428136]

1713428136

[1713428136]

1713428136

[1713428136]

1713428136

[franky1]

(facepalm)

for the third time
forget about % of VISIBLE orphans (theres more then you think. )

Nonsense.

An orphan only becomes an orphan because another valid block beat it out.

Since the time between valid blocks is so much larger than the propagation/validation time
(which is seconds, not minutes), the proportion of orphans to valid blocks has to be tiny.

The only way that, say, 5 orphans would be created during 1 valid block is if they
all happened to be published within a few seconds of each other -- which, given
that valid blocks only occur about every 600 seconds, is quite unlikely.
[/quote]

(facepalm)
seems your not gonna run any scenarios.. so you might aswell just carry on with one dimensional thinking and move on
its like i open up a curtain. and all you want to talk about is the next wall.. your not ready to see beyond the wall and finding reasons to avoid looking beyond the wall..

might be best to let you have more time to immerse yourself with all the extra things behind the scene.. which your not ready to grasp just yet

[jonald_fyookball]

Franky,  I have ran the scenarios in my head.  I could give one to you but it would be a waste of time because we'd end up in a circular argument.

...because you would challenge the underlying assumption behind the scenario, which is this:

The natural frequency to find a block for the entire network (which is set by the difficulty level) is always 600 seconds on average.
Unless and until you accept that assumption, discussing scenarios are pointless.

[franky1]

Moral of this topic:  franky1 isn't listening to a vast selection of technically proficient users explaining in detail why his perception of mining is wrong.

i understand more then you think. but people cant even get passed the basics for me to even start confusing them further with the extra dimensions..
it would take a book to explain it all.. but some are stuck at the first paragraph.. so this topic im only talking about their first paragraph failures ..

ok.. lets word it this way to confuse the matter by talking about some 2 dimensional stuff
(using some peoples rationale)
if it only takes 70ms (im laughing) to see a block, grab the block, validate the block, make a new(unsolved) block template, add transactions..
                                ...... before hashing

then why SPV??
why do(avoiding grey): see a block, grab the block validate the block, make a new block add transactions start hashing
hint:  its more then 70ms to do all the tasks before hashing.
hint: the efficiency gains of doing spv are noticable
hint: by doing spv, the gains are more than 5%, compared to a pool that does the full validation
hint: even OVERT asicboost can gain more than 5% efficiency by tinkering around with certain things too
hint: even COVERT asicboost can gain more than 5% efficiency by tinkering around with certain things too

remember 5% of 10 minutes is 30 seconds.
there are ways to shave off more than 20% of average block creation processes (2minutes) without buying 20% more hash power

once you realise there is much more than just hashing to make a block. the difference between each pools "hash power" becomes negligible..

where all those tasks sat beside the time of hashing to make up the solved block creation time..
dilute the 'hash time' per block solution variance. thus making the "hashing time" negligible

tl:dr;
without buying more ASIC rigs
a 11% hashpower pool can out perform a 13% hashpower pool. just by knowing some efficiency tricks
meaning arguing about the


until dino and others can grasp the basics that pools dont just work on 1 block an hour.. there is no point going into the deeper level stuff

third level hint..
if a pool went at it alone. it can happily avoid all the latency, validation, propogation times (which would be more than 70ms if it was competing)
because going it alone means the previous block already belongs to them so they already know the data.. and as such they gain time to create the next block by not having to relay, propagate, etc, etc..
totally separate matter.
but the bit i laugh at.
if it only takes 70ms to see a block download a block validate a block then why are cry babies crying so much that "2mb blocks are bad".

look beyond the curtain, find the answers. piece the layers together, see the whole picture

[franky1]

The natural frequency to find a block for the entire network (which is set by the difficulty level) is always 600 seconds on average.[/b]

you are right. but your not seeing it from more than a 1 dimension...

so lets just get back to the topic at hand..

running a node is just as important as running an asic. infact more important

having diverse codebases of nodes is as important as having multiple pools. infact more important

[Viper1]

Some real block times over a few hours from yesterday. Each pool was working towards solving a block at each of those heights. Each pool was trying to solve a completely different "block" as the data they work on is different from any other pool. I seriously don't know how franky1 could possibly think that a pool with 5 S9s (as an example), would be able to solve their unique block at the same average time as a pool with 1000 S9s. At this point I have to conclude he's simply incapable of admitting he's wrong and/or is trolling us.

466332 05:22
466331 35:01
466330 34:56
466329 09:24
466328 05:02
466327 11:12
466326 03:29
466325 13:08
466324 42:03
466323 05:09
466322 07:15
466321 01:17
466320 01:40
466319 24:02
466318 06:19
466317 14:06
466316 04:10
466315 00:52
466314 14:32
466313 07:36
466312 10:35
466311 08:05
466310 02:43
466309 03:03

I must admit, for some reason I had thought that these times would be a lot closer to the 10 min average since pooling is supposed to "smooth out" the times.

[dinofelis]

@franky1.  One more trial.

Take an old piece of block chain, say, around block number 200 000 or so, but consider the actual, today's, difficulty, take a given miner setup, with a given hash rate, say, 1/6 of the total hash rate for that difficulty, and compare two different experiments:

A) take the transactions of block 200 000, make your own block of it, and hash on it.  Regularly, you will find a solution, but you continue trying to find new solutions on that very same block.  Do this for a day.   ==> at what average rate do you think you will find solutions for this same block ?

B) do the same as in A, but switch blocks every 30 seconds, that is, work 30 seconds on a block made of the transactions of block 200 000 ; then work 30 seconds on the block made of the transactions of block 201 000 ; then work 30 seconds on the transactions of block 200 002 etc...  Do this also for a day.
==> at what average rate do you think this time, you will find solutions for some of the blocks during the time you hash on them ?

How do the rates in A and in B compare ?

[dinofelis]

I must admit, for some reason I had thought that these times would be a lot closer to the 10 min average since pooling is supposed to "smooth out" the times.

Nope, they remain exponential.  The only thing pooling does is smoothing out the GAINS as compared to solo mining for each of its customers (and a bit of economy of scale which is probably lost on the fact that the customers have some overhead to prove their work: trustlessness comes at a price).

If you have a small amount of hash rate that would, on average, let you win a block per month, some times you might only win a block after 3 months and no gains in between ; some times you might win 3 blocks in one month.  This uncertainty of income is smoothed out by pooling together, where the pool will pay you regularly about one block per month minus his fees and margins etc... and the pooling together also removes the hassle to have to constitute blocks yourself, check, have a good network node, etc... (and at the same time, take away your decision power on that).

[jbreher]

now can you see that if he only got 1 block out of 6 in the "consortium competition", he will get 6 out of 6 "on his own"

Yes. And in the time that it takes for him to get these 6 out of 6 on his minority chain, the 5x miners on the majority chain will have mined 30 blocks (+/-, after variance).

[-ck]

As I've been telling everyone...

It's incredible that you have to explain something so basic about mining to this moron who claims to be so knowledgeable that he posts hundreds of times a day, purely to discredit core, blockstream, segwit, whatever isn't BU. Do yourself a favour and put him on ignore; he feigns some kind of smarts that look like he's creating a counterargument when in fact it's a load of bollocks. He's probably laughing about how he pretends to answer the question while attempting to ridicule real progress, development and intelligent discussion as a shill... or more likely he's just a moron.

I'm tempted to unignore him temporarily just to see all his pearls of wisdom for hours of entertainment on this thread. It's really amazing how hard you guys are trying...

[franky1]

Some real block times over a few hours from yesterday. Each pool was working towards solving a block at each of those heights. Each pool was trying to solve a completely different "block" as the data they work on is different from any other pool. I seriously don't know how franky1 could possibly think that a pool with 5 S9s (as an example), would be able to solve their unique block at the same average time as a pool with 1000 S9s. At this point I have to conclude he's simply incapable of admitting he's wrong and/or is trolling us.

viper...
go read the scenario DINO presented!!
HE said if 10 pools all had 10% hash  meaning all pools had 1000 s9's
then if 1 pool went at it alone it would take that pool 1 hour 40 minutes to make a block.

that was HIS 1 dimensional view..
which would be wrong

the last 3-4 pages of debate was about equal hash and how dino thought even in equal hash a pool would take 10x longer that another pool..

separately.. and not even related to dino's error

bringing in such details of x=5 y=1000 was going to be something i was going to handle once dino and others realise his error of his mis understanding of the 1 dimensional view of all pools with same hash power


i know a pool of just 5 S9's vs a pool of 1000 S9's would have different timings..

i would have gone into this as a 3rd dimension discussion. but dino and others were still locked into the error of the 1 dimensional error concerning all pools of equal hash scenario.. which would have confused the whole matter if they couldnt even get around the basics

such as confusing them further by saying x=5 y=1000 is not a 200x variance.
for instance a 1000 S9 could be forced to do full validation and not do all its efficiency gains (non hash tasks) and not do overt/covert hash gains.

bringing the different average timings down by 20%+ for the 1000 S9
while if the 5 S9 pool was not doing efficiency gains before could be allowed to on a new separate chain.

making the efficiency variance between the two be more like, as if x=6 and y=800 efficiency while not actually changing the asic count which would be a variance of 133 not 200

I must admit, for some reason I had thought that these times would be a lot closer to the 10 min average since pooling is supposed to "smooth out" the times.

again this is a 3rd dimensional discussion about the ~2week2016 block understanding. and not the 'literal' 10 minute misunderstanding by them same people. but that would confuse the 1st dimensional scenario dino was erroneous over..


.. last thing, i would have if they grasped it all. threw in a curveball to then say..
if one pool went at it alone. who said it would be the xof 5 s9's going at it alone. what if the y of 1000 s9's went at it alone.. to really make dino think..

but dino first needed to grasp these 1 dimensional scenario errors he made:
a. if a pool only has 1 block out of 10 on the blockchain, does not mean he was only working on 1 block for the entire time
b. out of 10 blockheights every pool attempts every blockheight win or lose
c. if the other 9 attempted blocks a pool attempted(but didnt win) followed through without staling, giving up, aborting, moving on, orphaning. each block would not be 1hour 40mins per blockheight

but even after several pages dino and others could not grasp that. they could not see beyond the curtain of the blocks they cant see and were only counting and dividing the times of the winners. not the bachground hidden attempts (if they ran scenarios where the background attempts had timings too)

tl:dr;
i do understand alot more then you think but i was trying to give dino baby steps of eli5 layman worded understanding, to atleast get him to realise the scenario he presented of ALL pools having same hash wont take 1 hour 40 minutes if they went alone.
but even after several pages dino and others could not grasp that.

[dinofelis]

Some real block times over a few hours from yesterday. Each pool was working towards solving a block at each of those heights. Each pool was trying to solve a completely different "block" as the data they work on is different from any other pool. I seriously don't know how franky1 could possibly think that a pool with 5 S9s (as an example), would be able to solve their unique block at the same average time as a pool with 1000 S9s. At this point I have to conclude he's simply incapable of admitting he's wrong and/or is trolling us.

viper...
go read the scenario DINO presented!!
HE said if 10 pools all had 10% hash  meaning all pools had 1000 s9's
then if 1 pool went at it alone it would take that pool 1 hour 40 minutes to make a block.

Of course it is going to take on average 1 hour and 40 minutes.   That's really so trivially true that I can't wrap my mind around you not understanding that, unless you know ZILCH about probabilities.

If you have one chance in 1000 to win each time you play, and you have a "hash rate" of 100, meaning, you can play 100 times per second, it will take you on average 10 seconds to win ; if you play for, say, 5000 seconds, you will have won about 500 times.

If you play with 9 other peers in the same way, and all of you have a "hash rate" of 100, meaning, ALL of you play 100 times per second, it will take each of you on average 10 seconds to win, like you ; but every second, on average, SOMEONE will win because all 10 of you won on average once in 10 seconds.

So if all of you play 5000 seconds, each of you will have won about 500 times, and in total, you will all have won together, 5000 times of which, you have one out of 10.  If the 9 others stop playing, this will not influence your winning rate, which is 500 times in 5000 seconds, but the 4500 other winnings by the others are of course not there, because they didn't play.

That's so elementary trivially true, that I really don't see how you can't get that.

[franky1]

as for -ck
he thinks im a BU shill..
(facepalm)

as for -ck's 70ms stat
that is not a complete validation/propogation/new raw template creation(non hashtime parts) timing that factors in all the things like latency, caching, and many other factors.
hense why pools do SPV... because the combined non hashtime parts are more than just 70ms

but thats a separate dimension debate to the 1st dimension error that dino cant grasp..

anyway. lets all agree to disagree and leave people to do their own scenario's
if you cant be bothered to run scenarios to realise what happens behind the curtain.. then just agree to disagree and move on until you can run scenarios.

[dinofelis]

a. if a pool only has 1 block out of 10 on the blockchain, does not mean he was only working on 1 block for the entire time

I hope you understand that the probability of winning a block doesn't depend on what block you are mining, or how long you were mining on that block.  Each hash you calculate, on each thinkable block, has exactly the same probability to "win the block" as any other.  I hope you understand that.

You should first answer this:

@franky1.  One more trial.

Take an old piece of block chain, say, around block number 200 000 or so, but consider the actual, today's, difficulty, take a given miner setup, with a given hash rate, say, 1/6 of the total hash rate for that difficulty, and compare two different experiments:

A) take the transactions of block 200 000, make your own block of it, and hash on it.  Regularly, you will find a solution, but you continue trying to find new solutions on that very same block.  Do this for a day.   ==> at what average rate do you think you will find solutions for this same block ?

B) do the same as in A, but switch blocks every 30 seconds, that is, work 30 seconds on a block made of the transactions of block 200 000 ; then work 30 seconds on the block made of the transactions of block 201 000 ; then work 30 seconds on the transactions of block 200 002 etc...  Do this also for a day.
==> at what average rate do you think this time, you will find solutions for some of the blocks during the time you hash on them ?

How do the rates in A and in B compare ?

[jonald_fyookball]

As I've been telling everyone...

It's incredible that you have to explain something so basic about mining to this moron who claims to be so knowledgeable that he posts hundreds of times a day, purely to discredit core, blockstream, segwit, whatever isn't BU. Do yourself a favour and put him on ignore; he feigns some kind of smarts that look like he's creating a counterargument when in fact it's a load of bollocks. He's probably laughing about how he pretends to answer the question while attempting to ridicule real progress, development and intelligent discussion as a shill... or more likely he's just a moron.

I'm tempted to unignore him temporarily just to see all his pearls of wisdom for hours of entertainment on this thread. It's really amazing how hard you guys are trying...

Well, I'm a big blocker too and think Blockstream/Core is 100% wrong.  Most of the time Franky posts good things, although, I also can't understand Franky's thinking in this thread.

but thats a separate dimension debate to the 1st dimension error that dino cant grasp..
 

the thing is, even if simplify it and say "lets talk 1 dimension - forget orphans" -- there seems to be a disconnect somewhere.  Try to answer Dino's question

[Darkbot]

Well, I'm a big blocker too and think Blockstream/Core is 100% wrong.  Most of the time Franky posts good things, although, I also can't understand Franky's thinking in this thread.

R.I.P BU Noob Jonald Fyookball. Why are you still doing here, why dont you move youre ass back to r/btc? You love sitting in Rogers ass even when he farts you keep smiling.

[franky1]

a. if a pool only has 1 block out of 10 on the blockchain, does not mean he was only working on 1 block for the entire time

I hope you understand that the probability of winning a block doesn't depend on what block you are mining, or how long you were mining on that block.  Each hash you calculate, on each thinkable block, has exactly the same probability to "win the block" as any other.  I hope you understand that.

You should first answer this:

@franky1.  One more trial.

Take an old piece of block chain, say, around block number 200 000 or so, but consider the actual, today's, difficulty, take a given miner setup, with a given hash rate, say, 1/6 of the total hash rate for that difficulty, and compare two different experiments:

A) take the transactions of block 200 000, make your own block of it, and hash on it.  Regularly, you will find a solution, but you continue trying to find new solutions on that very same block.  Do this for a day.   ==> at what average rate do you think you will find solutions for this same block ?

B) do the same as in A, but switch blocks every 30 seconds, that is, work 30 seconds on a block made of the transactions of block 200 000 ; then work 30 seconds on the block made of the transactions of block 201 000 ; then work 30 seconds on the transactions of block 200 002 etc...  Do this also for a day.
==> at what average rate do you think this time, you will find solutions for some of the blocks during the time you hash on them ?

How do the rates in A and in B compare ?

B is just meandering... 30 seconds has nothing to do with anything.. ..
screw it.. ill throw something at you and let you wrap your head around it



also to answer jonalds meander of the meander of the topic (his poking at the orphan's)
take the top table and block height 469990
C won.
but A would have been a close second.. if it did not stale, giveup, etc..
but even then without giving up/staling it would not show as a "orphan" unless there was an issue with C. where C won... and then got replaced by A.

this is why i said do not take the orphans as literally showing all background attempts..
but just as a quick opening of the curtains to those that think the only blocks ever worked on are the ones that win are wrong.. by just illustrating that there are more background attempts then they thought
EG dino only counting the wins and dividing by X hours (very very bad math)

[jonald_fyookball]

@darkbot, you're on ignore.

@Franky, how did you generate the data for each cell?  what calculation/formula?

[dinofelis]

a. if a pool only has 1 block out of 10 on the blockchain, does not mean he was only working on 1 block for the entire time

I hope you understand that the probability of winning a block doesn't depend on what block you are mining, or how long you were mining on that block.  Each hash you calculate, on each thinkable block, has exactly the same probability to "win the block" as any other.  I hope you understand that.

You should first answer this:

@franky1.  One more trial.

Take an old piece of block chain, say, around block number 200 000 or so, but consider the actual, today's, difficulty, take a given miner setup, with a given hash rate, say, 1/6 of the total hash rate for that difficulty, and compare two different experiments:

A) take the transactions of block 200 000, make your own block of it, and hash on it.  Regularly, you will find a solution, but you continue trying to find new solutions on that very same block.  Do this for a day.   ==> at what average rate do you think you will find solutions for this same block ?

B) do the same as in A, but switch blocks every 30 seconds, that is, work 30 seconds on a block made of the transactions of block 200 000 ; then work 30 seconds on the block made of the transactions of block 201 000 ; then work 30 seconds on the transactions of block 200 002 etc...  Do this also for a day.
==> at what average rate do you think this time, you will find solutions for some of the blocks during the time you hash on them ?

How do the rates in A and in B compare ?

B is just meandering... 30 seconds has nothing to do with anything.. ..

The question simply was: will B find solutions to blocks at any other rate than A ?

The answer is that B will find solutions to blocks AT EXACTLY THE SAME AVERAGE RATE than A, but it would have been great if you saw this yourself.

[dinofelis]

screw it.. ill throw something at you and let you wrap your head around it

From what distribution were the times between discoveries of the same pool drawn ?  I have the impression it are UNIFORM random distributions, and not EXPONENTIAL distributions.  That's crucial.  Uniform distributions, as I said before, increase the probability of winning if you have already worked a lot without success.