Topic: Please run a full node (Read 6669 times)

Running a node is a great thing to do. Everyone should. I started looking into it and am going to do one soon! Probably run other nodes too for fun hehe.

Dude or dudette....
When I posted upthread that 'dinofelis was right about how mining works', that was just a polite way of expressing 'you are categorically wrong about how mining works'.


No - you MISunderstand more than you realize.

Sorry. It's just how it is.

The funny thing is Viper did exactly that (ran his own tests/research) using actual proof of work... which proved what everyone else in the thread (except you) is saying.

You say it does not work, so whataya want from the bitcoin network?

I mean that garbage Chinese man. What does he want from bitcoin?

i have said for years dont get spoonfed data
dont just take things on face value
dont just read something on a forum/reddit and take it for granted.

do your own tests/research/scenarios/validation.
this is why DAYS AGO i said ill give dino a few months to have his mind blowing experience of seeing the bigger picture of the real depths of bitcoin rather than the 1d overview he has displayed over the last few months.

yet apparently many want me to spoonfeed them everything. and then debunk it before even examining it.. (making it pointless to spoonfeed)

so if you want to learn run your own tests for your own peace of mind.

anyway this topic has meandered soo far off track.

but i still await -ck explain his biased 'only 70ms' timing of all the combined propagation, validation, parts (outside of hashing).. as i want to see how if its just 70ms he and his fellow friends can justify their "2mb is bad" rhetoric

PS. to pre-empt short sightedness
 my "minutes" is not to be taken literally as in for all blocks... but has been the case in the past where certain 'tasks' used to be done certain ways without efficiencies. and more seconds/milliseconds can be shaved off too even now
 but on average the block (non-hashing task) is more than just 70ms..

but i would like to know where -ck can defend a bigger blocks are bad stance if non-hashing tasks are 'just 70ms)

im done with this topic.
if anyone else is unsure about the meandered 'hashtime' stuff.. just run your own scenarios

You seemed to have missed the part (on two occasions actually), where I said I had written an actual simulation and that once I had seen enough of the data to realize you were out to lunch, I shut it down.

it isnt just RAND!!!
(facepalm)
the formulae also includes the difficulty vs hash.
AND
i even factored in some efficiencies too

as you can see.. look at blockheight 469992.. there is a big difference between A and J due to MANY factors including the math of nonce and other things.

emphasis: not just rand
i only mention rand to pre-empt to the simple minds of one dimensional thinkers who would try dismissing any data by saying "i bet he manually typed in biased data" simply to avoid waffling

but seeing as people cant accept other peoples scenarios.. RUN YOUR F**KING OWN scenarios!!!

---

summary of this topic (NODES) - not just this meandered ('hashtime' debate)

TL:DR;
this whole topic proves a few things:
1. no one wants to or can just blindly accept the opinion of data from others, its always best to run tests on data yourself
2. running a full node is the same logic. dont just be a downstream node / sheep / follower of a tier network. doing own validation is important for the network
3. when there is a dispute between the data, just sheep following certain data is bad. run a full node and fully validate the data.

4. then the non-mining consensus. can all agree that blockheader 83ba26... is the most correct highest height the nodes can all agree on.
and if a pool made a new block that is not even using 83ba26 as a previous hash then that pool wont win or get support

Oh my lord. You can't prove your point by using RAND or anything that doesn't also take into account difficulty. Why the heck do you think I was writing a simulation that was doing actual hashing with difficulty. My first thought was to use "rand" and then I immediately tossed that out as it would in no way represent what really happens. For one thing, it results in a normal distribution which is NOT what you have with bitcoin. wow.. just... wow..

I think I'm done. At this point I can't take anything franky1 ever says seriously.

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.

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.

@darkbot, you're on ignore.

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

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)

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.

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.




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

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:

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.

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.

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

---

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.

As I've been telling everyone...


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

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