Bitcoin Forum

If you have a machine you can spare, please run a full node. The more nodes there are, the stronger the network is. Also, if you run a full node you can potentially mine your node for information of various kinds. You can tell if you have a full node by giving the following command:


If the "connections" field is greater than 8, then you are running a full node, congratulations!

You can find information on how to run a full node on bitcoin.org here:

https://bitcoin.org/en/full-node

I will disagree.  More non-mining nodes doesn't necessarily make the network stronger if there are a sufficient number of nodes already.  Remember that only mining nodes can extend and secure the ledger. 

Daily reminder: Bitcoin is controlled by a pompous pimpled faced rich kid in China and jonald_fyookball is his cock holster.
Jihan Wu of Bitmain is killing bitcoin you can ether run a full node, buy non-chines mining hardware and run your non-chines mining hardware on a non chines pool or you could...

https://pbs.twimg.com/profile_images/567383388659523585/S15iNdqD.jpeg

...Kneel before your god!

Yeah, we need more miners rather than more full nodes I think to help make the network stronger. But miners require significant investments so most folks won't be setting up new miners even though its needed.

This is sigspam nonsense. There is more than enough mining hardware around. What isn't enough of in mining is enough spread of the hashrate. More people buying hardware won't fix that when the economies of scale and cheap electricity means most hardware is clustered in a small number of huge farms owned by very few people.

Title of this post should really be "Please run a full node, because..." followed by some short blurb about why that's important.  There are various people reading here new or new-ish to bitcoin or are returning to it very interested after hiatus.

Also a reference to bitcoin.org/en/full-node isn't the best.  I think they need to shorten that instructional.  And what many people don't realize if they have never run a full node before is the port 8333 thing is actually important.  That is buried in the text of the instructions at bitcoin.org/en/full-node way at the end, easy to miss, and it's not explained why it's important.  

Here are a few examples of reddit discussions lately about full nodes and how-to's

https://www.reddit.com/r/Bitcoin/comments/5yubg0/run_a_014_fullnode_on_raspberrypi3_prunedless/

https://www.reddit.com/r/Bitcoin/comments/624xd0/first_time_running_bitcoin_core_full_node/

By the way, this handy site tells you kind of why it's important regarding the port issue, and even tells you if port 8333 is open or closed for you.  https://www.lurkmore.com/mining/port8333/

Who should run a full node and why? are any of you miners willing to share your rewards with us if we were to run full nodes? every time I brought that up people said: don't run a full node because we don't need you to but only if we ask for a share.
Satoshi didn't think of this happening because he never thought about ASIC. running a full node does not help me to get a fast confirmation.
There is zero incentive for non miners to run full node, I am no longer running mine 6 hours a day but only 4 hours just to get synced and that's it.

Even if I own 1000 full nodes I'll have to kiss miners a*ses so they get to include my TX in a block, 10K FN still have to wait hours actually I feel like miners taking advantage of me and think that I'm a fool when they tell me to do this to help the network, network doesn't give a sh*t about me what so ever.

So once again if miners wanted to share their rewards with people running full nodes then why even bother to tell us? they can run them and keep the rewards for themselves.

It's ok ImHash our dear leader Jihan Wu the merciful does not need nor want you to run a full node.

People are finally getting that, as Satoshi said already in 2008, "only people trying to make new coins need to run full nodes", and that full nodes that do not mine have almost no utility.  In fact, they have one, important, utility, and that is for its owner: 
1) the owner can verify for himself whether the miners have decided to change the protocol or not
2) the owner has extra privacy and security, because he doesn't need to rely on a third party full node to verify his transactions, and the transactions he sends out could come from just any light wallet connected to his node, so he has "plausible deniability" for his transaction.

Why wouldn't he ?  You're being his proxy server, taking some load off his infrastructure, so of course he likes you to be his proxy server full node.

Blasphemer

https://www.strat-talk.com/data/attachments/71/71814-9c93df15a9f54bddbf35275994e1807b.jpg

Our God Jihan Wu the eternal is good and trusting only he can confirm all transactions only he is strong and moral enough to uphold the bitcoin.

this can't be helped, unless there is that algo change that we were talking abaout few week ago, and even then i think chinese would control gpu miner if we were to return back to our roots

i bet they have the majority of hash in altcoin too with gpu mining, still it's true that more casual mining wuld be possible without asic, which is good for decentralization

Until we get some competition for the big Asic manufacturers and get more hardware into people's hands, we are fk'ed. These mining giants are just growing bigger by the day, and they use our money to do it. We buy obsolete hardware from them and we pay them more fees when the Blockchain is spammed and they mine more efficiently with the help of ASICBOOST and cheaper electricity.

Bend over and take it from behind or get someone to compete with them. ^grrrrrrr^

I think this is a cause of the alt coin rise.  To hedge against bitcoin monopoly risk, now that it has a very centralized power structure.

ok here is me being unbiased

NODES DO MATTER:

bitcoin is a symbiotic relationship.
pools collate the tx data in a certain format.

the node network judge which block of data is a valid format of collated data and keeps that block if everything is valid/approved.

other nodes then see that a node has a new 'height' and requests that new accepted block. and as a snowball effect if the majority of the nodes have the same consensus rules, that block gets shared to the majority and that block gets set in stone.

by nodes holding a block and then pools building ontop of the most approved/valid previous block a single chain of good, valid accepted data becomes locked in and immutable.

if pools build upon blocks that are not majority accepted, they can find their newest attempt rejected because of the orphaning effect.

anyone shouting non-mining nodes do not matter, are only saying so because they dont want 'the opposition' gaining majority.

the problem with this is if both sides of the 'opposition' were to turn off their non mining nodes, then the only nodes of majority left are the miners nodes which then makes the mining nodes have more control because they become the majority.

for network safety sake dont let the 20 pools have the 'majority' otherwise they then control the network.

yes some will argue ' but if there are non-mining nodes setting rule A but pools want rule B it makes it harder/impossible for rule B to become law' well thats the point.

rule B should only become law if the community want rule B as a combined majority. it prevents pools changing the rules at a whim, it makes devs and pools actually fall inline and only change the rules if the new rules are good for the community as a majority.

this does not mean everyone should run 20+ nodes it just means dont let the decisions of rule changes become centralised

---

tl:dr;
its not just a mining game of who builds the biggest tower of blocks the fastest wins. where everyone then copies(like sheep) the fastest built tower..
its actually jenga.
who has the most stable and accepted highest tower of blocks without holes or risks of toppling over wins.
and its the node majority that get to poke holes in the tower until there is only one tower of strong immutable blocks that wont topple over

All of the arguments that "nodes do matter" have the logical fallacy of taking the "intended way the network SHOULD work" as the "actually technically resulting technical operation".

This is the fallacy that is similar to:
- you've build a rocket to go to the moon with propellers, but propellers don't work in space !
- Of course propellers work in space !
- No, they don't.  They need air to function and in space, there is no air.
- But propellers obviously work in space, because we designed a rocket to go to the moon, and it has propellers !  Hence, propellers work in space, Q.E.D.

The argument here is that "because nodes SHOULD (that is: "we desire that", like we desire that our rocket flies to the moon) keep the miners in check, well, nodes ARE keeping the miners in check".

They don't.  I'll show you:


=> my desire


That block doesn't get set in stone because a majority of nodes copy it.  It will get set in stone if the following miner pools DECIDE TO MINE on top of it.  And they don't need the network to get their block ; they get it from the miner pool that mined it.  Directly.  Because they are in a hurry.  They don't WAIT for the P2P network to "approve it", because they would be wasting their time and hash rate in the mean time.


==> the only way a block becomes accepted, locked and immutable is because other miners mine their blocks on top of it.  Whether remote nodes download it or not, doesn't matter in this case.


==> what "orphaning effect" ?  Orphaning occurs when OTHER MINERS decide to mine upon ANOTHER block than the orphaned block.  If miners decided to mine upon block A, with blocks B, C, D and E, there simply isn't any other set of blocks around that a P2P node could "prefer".  Suppose that a majority of P2P nodes decides to "orphan" block B.  But the miners have been building blocks C, D and E on top of B.  What happens ?

Well, these nodes stop.  They stop at block A.  And they can't find any other block that pleases them.  B wasn't according to their taste.  But there's NO OTHER BLOCK around that is built upon A.  Nobody has ever made a block on top of A with a higher PoW than the chain B,C,D,E.  In fact, nobody ever made a block on top of A.

So what is the difference between our full node "not accepting" block B, and our full node just being switched off ?
What's the "orphan effect" of switching off your full node ?


No.  They are people that don't confuse "desires" with logical consequences.  If miners don't make another block than block B, you can chose between accepting block B, whatever miners did with it, or stop your node.  What else can you do, with your full node that doesn't like block B ?

Let us take a very simple example.  Let us assume that the miners, collectively, decide to make bigger blocks.  From block B onward, they make blocks of 1.2 MB.  All miners agree (to show you that it are the MINERS that decide).  They build a chain in which block B is 1.2 MB.  Nobody builds a chain with an alternative B block of only 1 MB.
99% of nodes refuse.  They don't accept a block of 1 MB.  But miners happily continue building blocks.  What now ?


But there is no "majority rule" of nodes.  The reason why Satoshi introduced vote per hashrate, was exactly to nullify every effect of "majority of nodes".  As miner pools are directly connected between themselves (for reasons of not wasting hash rate), they don't need the P2P network to get a block from another miner.

So all non-mining nodes can do, is copy the one and unique chain that miners make.  If they like it, they keep it ; if they don't like it, they stop.

=> but it is exactly like that.

(because there is no OTHER tower)

But PCs need to be pretty configurable and online continuously! Full node mode is very secure because it is certainly not fraudulent. But it is not convenient with small traders

Is there anything we can do to fight this monopoly? My understanding is that changing the structure of the Bitcoin network needs a hard fork, and a hard fork needs hashing power. Or we are just fu**ed? Is this the biggest flaw in Nakamoto's vision?

If you are mining I think this is very convenient for you but if you are a non miner and just want a stronger network and because you just have a spare machine that doesn't really have in use there is a limited number of nodes to connect, and Running a Bitcoin full node comes with certain costs and can expose you to certain risks. and Some Internet plans will charge an additional amount for any excess upload bandwidth used that isn’t included in the plan.

Yeah that is what I was implying. We need more new miners that aren't controlled by the same small group of people. New people buying mining hardware would indeed help spread the hashing power out which would help make the network stronger and less centralized into the power of these farms that are controlled by few people. However, as I was saying this would require a significant investment and likely wouldn't be profitable which is why there aren't many people willing to setup miners just to help the network grow stronger and less centralized.

there are other towers.. you are just seeing it from the mid-endgame... you have not seen it from the start-midgame.

EG your only seeing the end result. you have not played out the scenarios from beginning to end

the reason there is now only one tower is because the diverse pools and nodes have learned their lessons. so you dont really see much drama of the different towers.
but now and again find out that they still have lessons to learn (orphans happen weekly)

Agree with you. We need more 'real' mining nodes to make BTC more secure. Seems we have average 6-7K daily nodes. But mining still dominate by China even they only have 200-300 nodes.

Well, the first thing one should realize is that in block chain land, *everything* is decided by an interaction between two classes of entities in the eco system:
- the "chain builders" on one hand
- the "users" on the other hand: the users are the people that are willing to OFFER VALUE FOR TOKENS.

In most cases, the chain builders get "rewards" for building the chain in the form of tokens on the chain they are building.  So in the end, the chain builders usually want to convert those tokens to value, by dumping them on the "users", who, for several reasons, desire to possess tokens on the chain at hand ; so to a certain extend, chain builders are sensitive to the willingness of users to pay for their chain.  On the other hand, users need the chain builders to be able to use the tokens they acquired, and to be able to sell them.

This is about the fundamental relationship between the entities in the crypto eco system.

So who's the boss ?  As we saw, both users and chain builders need one another: chain builders need users to buy their tokens ; users need chain builders to transact their tokens.  

As such:
a) users are the boss, because they are free not to buy chain builder's tokens
b) chain builders are the boss, because they can fix the rules by which users can access their possessions

So new buyers are the boss of the chain builders because they pay them, or not, and chain builders are the boss over stake holders because they give them access to their stake, or not.  But new buyers become stake holders.

As usual in such an eco-system, those that are more divided, are less powerful than those that are in agreement.

The most important point is however, this:
If chain builders are divided, then several chains can be built.   If chain builders are in agreement, then only one single chain is built.

If there is only one chain out there, and nobody else is building a chain, then the only option is to accept that chain as the ruling chain, or to leave the system (not buy any coins, and sell one's coins according to the requirements of the chain builders).  As such, chain builders in agreement have total technical control over all of the rules of the system, but they still need to seduce buyers.

So the only way to "attack" chain builders that are in agreement, apart from leaving the system, is:

a) to divide them or
b) to build other chains "oneself".

a) means: to give better terms to those going in your direction, than to what they are agreeing upon ; but most of the time, you would like them to have WORSE terms (lower fees, say) and less power.  So that's not going to work.

b) build another chain yourself remains.

This could be done in two ways:
a) change the PoW algorithm, making the miner's installations useless
b) change to a PoS style algorithm

In both cases, however, you are making a competing chain with the original one, and the question is: how will the users vote with their money ?  Users have equal amounts of coins on both chains, and will try to "dump" the chain of which they expect not to win, and will try to keep their coins on the chain that they expect to win in the market.  --> if you make a mistake, you lose all of your stake !

And this is where things get nasty.  How do you know that most users will prefer the new chain, and not stick to the old chain, or think that most users will stick to the old chain ?

After all, chances are that the old chain is considered "true bitcoin" (nothing changes !) and the new chain an alt coin.  It can even be that, if this is successful, did one open the flood gates, because what stops yet another entity from proposing YET ANOTHER "other chain" ?  Once you've successfully forked off, why not fork off N more times ?

It could work.  With ETH, it sort of worked.  The old chain, ETC, lived on, but an economic majority + devs went to the new chain (maybe also because the name was, remarkably, put on the new chain).  But ETH didn't have a "first mover brand name".

So, until one decides to divide the miners, or have the miners agree on a change, the option of making a totally new chain with another PoW or PoS, is going to be a most risky operation without any guarantee.

but then pools see that all the merchants cant see their rewards for BCDE..
the users waiting on transactions cannot see BCDE

and pools have to wait until Z4 before they can even spend B...

so way way way before z4 (z4=going through the alphabet 4times(100 block confirm maturity)) occurs just to spend B.. pools realise they better make blocks according to rule A otherwise they have wasted half a day building b-zb-zb-zb-z that would be unspendable.

this is why instead of having orphans of 100 blocks deep where pools realise they cant spend their funds..
they only at most regularly have orphans of 1 block deep. because:
they know its foolish to keep mining b-z 4times.
they know its foolish to keep mining b-z 4times HOPING the delay would force 6000 nodes to download and waste a week re-syncing to new B rules.

pools only move to B rules if the nodes accept it, which pools find out about alot sooner than 6 hours+ when its time to spend.
pools can usually find out within a few minutes if their block is 'good' for the majority

some pools realise in 3 seconds

These orphans have nothing to do with full nodes.  They have to do with the propagation delay of blocks amongst mining pools.
In other words, if, say, an orphaned block appears on average once or twice a week, say about every 400 blocks, it means that it takes on average 600 seconds / 400 blocks = 1.5 seconds for mined blocks to propagate to all miner pools
(rough estimation).

It means that within 1.5 seconds, a miner pool has received a valid block, has verified it, and starts mining a new block on top of it.  So one out of 400 times, a pool has found, by coincidence, a competing block, before realizing that a competitor was faster.

(BTW, this also indicates why miners are most probably directly connected: they could never have such a low orphaning rate if the 1MB blocks propagated through the P2P network: the delays between sending a block and having all other miners stop their work and start mining on top of yours would be too long, and would cause much more orphaning).

nooo
the MAJORITY of orphans happen now because of propogation delay....
 because pools are no longer risking changing the rules to make orphans happen for other reasons..

but if pools were to change the rules they would get orphaned

No Satoshi actually envisioned that we would reach a stage where only big companies would be hosting nodes. We already see a scenario where only

people with fast internet and lots of disk space are capable of running FULL nodes. It takes a lot of bandwidth too, so you will have to take that into

consideration, if you want to run a FULL node. All of this can become pretty expensive, if you are living in some 3rd world country with expensive data

packages and slow internet.  >:(

Most people will have only 8 connections or will shut down the node from time to time and will be syncing most of time, so they will be a burden for the network most of time.

Also I think the network is more than strong enough with the current nodes. It is more a future problem maybe than an urgent issue

Of course they can if they configure their wallet to connect directly to a miner pool node !   And do you think that a merchant or an exchange is going to stop its business for a day, while the competition accepts the new rules on the chain, and gets its node and wallet up and running again ?

Suppose that miners have announced that you should configure your node to 1.2 MB, because otherwise, you won't be able to see their chain.  Now, suppose that you need to send or receive 100 BTC for an important deal.  What are you going to do ?  Stop your node ?  Or accept their change ?  Suppose you are a merchant.  You simply want to be able to get bitcoins, and to send them for conversion.  You don't care about the technicalities, you simply want to use it.  What are you going to do ?  Connect to a stopped node, or connect to something that sees the current chain and accepts transactions ?

Suppose that you are an exchange.  Are you going to block withdrawals and deposits from customers, or are you going to update your node to suit the new chain ?  

As you say, the miners can wait to spend, they even have to wait to spend !  They just keep on mining the same chain, and you can chose to join them, and see your funds and be able to transact, or simply do nothing.  You upgrade, you are online again with bitcoin ; you don't upgrade, you are off the chain and off bitcoin.  What are you going to do ?

As a user, you are rather agnostic, and just want to use bitcoin.  As a full node owner, you can chose to have your node halted or to agree with the miner's protocol.  But by doing so, you are just going to get a user to ignore you, because the user wants a working chain to be able to transact on.


Of course it will be spendable.  Nobody else can in any case spend what so ever during all of this time.  All those not accepting the chain are "taken hostage" too.  So who's going to give in first ?  The mining pools, that eventually would like to sell their coins, or the nodes that serve the users, that cannot do anything on the network any more until they accept the new chain ? 

Remember that most users don't have full nodes.  There are millions of users, and only a few thousand of full nodes.  Users have wallets that connect to a reference node - this could just as well be a miner node.

1. his whole mindset (full context) is that there would be ~100k full nodes and no need for millions/billions of full nodes. the reason for this is:
a. the more nodes to propogate to makes it more delayed to get the data to everyone. so having 7billion full nodes actually hurts a decentralised network. (x degree's of separation)
b. not everyone NEEDS to be a full node
c. it would mainly be businesses and enthusiasts that NEED to run full nodes

No, if SOME pools would change the rules.  But we are considering the case where ALL pools fix the rules (the same ones, or the same change).

You are just printing what your local full node would tell YOU.  But if all miners are in agreement on the rules (old ones or new ones) - that's the case we consider - then there's no orphaning.  Because only miners can orphan blocks, by building on other blocks.

(btw, strictly speaking, an invalid block is not orphaned but rejected: the definition of orphaning is a VALID block that is not built upon ; by definition, blocks in the chain are valid).

your ignoring the past and creating scenario's that never happened..

pools learn in seconds if their block is going to be accepted.. they wont just continue for 16 hours HOPING merchants adapt..
pools learned this lesson the hard way years ago..

it seems you are trying too hard to downplay satoshi's consensus mechanism and trying too hard to make bitcoin sound like the fiat system.

its time you stop looking at the end result and thinking "its just a database" and instead actually look at all the different security mechanisms that make bitcoin completely different to fiat.

.... by other miners.  We are in the scenario where all pools agree upon a protocol, and the full nodes want another one.  Pools only care about their block being accepted by other miners - if that's the case, their block is not orphaned, but is now part of the immutable history.  The few seconds is exactly that.

No, on the contrary.  Satoshi introduced "consensus by majority of hash rate" to avoid any "majority of nodes".  Satoshi wrote that "only people wanting to make new coins should run full nodes", and he considered these to be "big data centers with special purpose hardware".

Now, Satoshi estimated that there would be less than 100 000, and he was right: there are only about 20.  20 is less than 100 000.

What Satoshi didn't realize or didn't want to say openly if he did, was that miners would pool together to increase their hash rate efficiency and that in a winner-takes all lottery, of course, pooling together is advantageous.  Instead of potentially winning one block every 6 months, you can be paid the same average amount by selling your hash power to a pool, delegating your decision on what block to mine.

  He didn't realize or he didn't want to say openly if he did, that economies of scale would bring the mining market into what every mature market does: a power distribution of market shares, concentrated in those areas of the world where the systems can work most efficiently.

In other words, an industry with about 20 entities sharing most of the market is normally to be expected from his design.

and while say pools BCDE are creating their blocks ontop of B for 16 hours.

pool A gives nodes blocks that are rule A acceptable. and pool A get to spend the funds(pool Awins every 10 minutes, zero competition)

so 16 hours earlier.. it would be like

nodes 399,999 height rule A
poolb 400,000b height rule B
poola 400,000a height rule A

nodes 400,000a
poolb 400,001b
poola 400,001a

..16 hours later
nodes 400,100a
poolb 400,101b - dang it i cant spend 400,001 and it looks like i cannot spend the other 99 blocks either. dang it i wasted half a day
poola 400,101a - woo hoo i won every block for last 100, PARTY AT MY HOUSE 1250 btc to spend :D thanks B for being a dumb & orphaning urself for 16 hours

..16 hours later
nodes 400,101a
poolb 400,102a - ok i lost 100 rewards, ill just stick with rule A from now on.. i wont be changing the rules that easily again
poola 400,102a - dang it B learned his lesson.. ok guys party only every other block, we have competition again, seems they learned their lesson

..
which is why NOW when a pool sees their bloc getting ropped by the ntwork.. they wont continue for 16 hours they realise their mistake straight away.


by the way strictly speaking an orphan was 'suppose' to be used in terms of, when a CHILD (newest addition) gets rejected purely because the parent(previous block) disappears..

but reality is a new block can be an orphan if the parent still exists but just gives up its child..

check the definition
An orphan is a child whose parents are dead or have permanently abandoned the child.

most pretend that "orphans" = parents are dead.. but the reality of human orphanages/foster care system is that children do not have to have dead parents to be classed as orphans.

says the idiot who recently exclaimed: "its my opinion Bitcoin is only at 10% capacity"  (when charts clearly show full blocks.)   :D

First of all, no. If you want to prove that full nodes can impose their verification onto mining pools, you must be able to prove that in the case where all mining pools are agreeing amongst themselves ; otherwise you do not distinguish the effects of a hard fork, and the effects of the power of the full nodes, which is what you want to prove.

In other words, if you want to prove that full non mining nodes have decision power over miners, you must be able to prove that they can impose their rules also over a set of mutually agreeing mining pools.  

So the Gedanken experiment is simply that: all mining pools (of any significance, say the 20 biggest) AGREE on a set of rules, and the full nodes DISAGREE.  It is in this Gedanken Experiment that you have to show how the full nodes are going to impose their rule set over those of the mutually agreeing miners.

We are NOT talking about users, and not talking about miners making different chains and forking.  We are talking about how full nodes "keep the miner pools in check".  So show me how the large majority of full nodes is going to impose its rules against all miner pools mutually agreeing.

Moreover, even outside of the argument, the forking pool that agrees with the full nodes will not make a block every 10 minutes: it will make a block at exactly the same rate as it was winning blocks when in competition, because that's given by the constant difficulty.  So if pool A was winning a block every 3 hours, it is still going to be able to make a block every 3 hours, grossly.  And, again, this doesn't prove anything about the power of full nodes ; this only indicates what happens when pools fork.  Stick to the case where all miners agree on a set of rules, where the full nodes don't agree with, if you want to show the power of full nodes imposing their rules on miners.

nope. because IF pools right now made blocks 465623-465723 that were, say using MD5 hashing..

by this evening.. they would find out that all the merchants wont see their rewards of 465622+
the pools would have most definetly realised that merchants wont buy their 465622 reward by at most 465623

so pools wont continue making md5 hashed blocks for 16 hours because 1 pool will see a nice easy income by switching back to sha256 and win every block that is spendable to the merchants and have no competition

Well, they would realize that all merchants are simply locked out of all transactions, unless merchants use the new rule software on their full node, or connect their wallet to a miner node.  Because there aren't any other transactions in accepted blocks.

So yes, miners can't cash out their coins to users, as long as ALL USERS decide not to upgrade, and accept being locked out of bitcoin, their funds and their transactions at the same time.  The question is why users would keep themselves locked out, while they can be up and running with bitcoin by simply running nodes that accept the existing block chain, or by connecting their wallets to such nodes, of which the miner pool nodes are of course examples.

1. pools are not going to waste 16 hours to double prove what they learn in 3-seconds to 10 minutes.. which is they cannot spend funds
2. pools are not going to waste days/weeks/month to really trying to push it in the HOPE that nodes download a MD5 hashing rule implementation..
after all even core suggest it would take a year to get clear node acceptance..

reality is..
if there was some secret cartel of "lets make md5 blocks for the next 6 months to force nodes to be less secured"
initially 20 pools have that motive.. but soon enough a pool gets greedy and jumps back to sha256 and wins every block.

Nope, it won't win anything more than if it were keeping his agreement with other miners, because it has only a fraction of the hash rate, and can hence only provide just as many blocks as it would when with his peers.  In other words, that pool is betting on making a very short chain, with much less PoW than the rest of his peers, and breaking his agreement.

In other words, if this pool has 10% of all the hash rate, when his peers have mined 90 blocks on the new chain, he will have mined 10 blocks on the old chain.  Most merchants and exchanges will not see their transactions on this small chain because the blocks are too full.  So merchants and exchanges would still be locked out of bitcoin for 90% - while they would be running entirely NORMALLY if they simply upgrade their node to the majority hash rate of the miners' rules, and see all their transactions.

And as I told you, you are now considering a hard fork, so in the end, you are considering the power game of a hard fork, not the power which you pretended, came from full nodes, so you are now building an argument for a statement that is not what you pretended.  But moreover, who is going to bet on this small chain with less PoW ?  Who is going to be confident in the transactions on this short chain with minority hash power ?

Your example of MINERS changing the hash algorithm is of course somewhat strange, because they would kill their own hardware.  But if you want to prove the power of full nodes, you will have to leave aside hard forking.  Hard forking will be decided in the market ; NOT by full nodes.  So this is a straw man argument.

Try rather to argue how full nodes would impose MD5 mining upon miners who continue to use SHA-256. THEN you will prove the power of full nodes over miners !

you have no clue..
now you are meandering into trying to argue about hash power.. yet you dont even understand hashpower either

you are presuming if it takes pool A 10minutes.. then it would take pool B 20 minutes, pool C 30 minutes.
that is not the case.
pools B and C could have found a block just SECONDS later.. but because there is only 1 winner. no one cares about the runners up timing.

if you take 1 pool away its not going to take 20 minutes to make a block. it can still take 10 minutes average block, just less competition so that the runners up now become winners more often, without affecting the average time much

i think its time you go to a shop and get some dice.. and some friends and family and play out some scenarios of randomness.. and see some real world scenarios play out.. it will surprise you

take your 10% of network hash scnario for instance
buy 100 dice..

get 10 people and give them 10 dice each. and ask them all to keep rolling until they get a total of lets say 600(adding each roll)
at very luckiest 1 person MIGHT get it in 10 rolls.. at unluckiest 1 person might get it in 60 rolls.

what you wont find is that if after playing the game for 2 weeks you found out the average took 20 rolls .. does not mean
if you took one person away it would average 40 rolls,
took one person away it would average 60 rolls,
took one person away it would average 80 rolls,
took one person away it would average 100 rolls
took one person away it would average 120 rolls
took one person away it would average 140 rolls
took one person away it would average 160 rolls
took one person away it would average 180 rolls
took one person away it would average 200 rolls

you would see the average would still be ~20 rolls. but now there are less people competing. so other people win more often.. and getting the result just miliseconds/couple roll variance before the other

You have visibly a fundamental misunderstanding about mining blocks.  

If you have hash power that is so that, with a given difficulty, on average, you find a good block, say, every hour, which means that you have about 1/6 of the total hash power *when the difficulty was determined*, then it doesn't matter whether others are mining or not, you will win, on average, one block every hour - minus those few seconds that you were mining on the wrong block each time.

What does it mean, having hash rate that gives you a good block every hour on average ?   It means that you need to hash about 60 minutes on average, to find a hash that satisfies the difficulty.  Whenever that happens, you win a block - unless this happens during those few seconds when your block will get orphaned, which means that you've wasted a few seconds of hash rate.

Your chances don't increase when you've been mining for 20 minutes on the same block.  It doesn't matter on which block you mine.  You could change every 20 seconds the block on which you're mining, and you would STILL be finding a block, on average, every 60 minutes.

So if all other miners shut down, the only thing that happens is that THEIR blocks don't appear any more.  Yours will.  On average, every 60 minutes.

Other miners disappearing doesn't make you win more blocks (except those few that were orphaned).  Other miners not being there any more will make you win more blocks AFTER DIFFICULTY GETS LOWERED, but not before.

If you have hash rate to win a block every 60 minutes with a given difficulty, that's what will happen, *independent of others*.  The fact that others are NOT mining, doesn't make you, by miracle find solutions faster.  It is not a competition of the BEST solution: it is a competition of finding A solution.  If another one found a solution after 10 minutes and you didn't, it means that you, well, didn't.  So if he wasn't there, you still wouldn't have a solution.

To take the example of your dice, if the game is: you have 5 dice, and you need to throw at least 4 times a 6 (difficulty) to win a point, then the number of times you will have to try on average before winning a point, is independent of the number of players you play with.

What is the size of the blockchain currently ?

About 140GB but you can run a full node in pruned form and specify how much space to use with 550MB being the lowest setting. However a pruned node isn't as useful to the network as a full one since it can't serve old blocks to the rest of the network.

your not getting it at all!!

ok try this..

imagine the olympics 100m

5 guys.. they all run
average is 10 seconds to get to the other end, and only 1 guy wins

now then, you ask the 5 guys to run the length 6 times..

out of those 6 times there is a guy that only wins once..

does that mean if he was the only runner it would take him 60 seconds.. no

because the game is run for 10 seconds and reset.
all the guys run within milliseconds of each other but there is only one winner, the timings of the other 4 guys per race are not multiples of the first guy, but miliseconds behind the first guy.

Really, you are mistaken on how mining works.  No point in discussing further until this is cleared out.

For a given difficulty level, mining is a Poisson process with an average probability to win a block in a given time window dT, which equals

dT / 10 minutes * (your hash rate / hash rate corresponding to the difficulty level)

The rate of winning blocks is independent of others winning blocks as long as the same difficulty level is maintained.

But all this has nothing to do with your claim that full nodes can enforce a protocol (or a protocol chain) on the set of miners if these are agreeing amongst themselves on a different protocol and do not fork off.

This is simply wrong, because the mining process is not a cumulative work towards a solution.  Every hash is a random trial, independent of other trials.  It is not because you have been hashing for 20 minutes on a block, that your probability of finding a solution in the next second is higher than if you just started hashing on that block or any other one.  It is a Poisson process, not a cumulative calculation.

The process is much closer to:  everyone has a certain number of dice (= hash rate ; you have 7 dice say).  The difficulty is: in one throw, you have to have at least 4 six.  You (just as anyone else) throws every second the dice he has).  Each time someone has 4 six, he wins the round.  Most of the time, when someone wins, nobody else wins (orphaning rate is low).  Your rate of winning rounds is essentially unaffected by the fact that others play too, because most of the time when you throw 4 six, nobody else does.  Whether the others play or not, your RATE of winning a round is independent of that.
In fact, in each round, you have a chance of 1/56.7 to win, so you will win about one round every 57 rounds.  As long as you are much less than 57 players, what the other players do has not much influence on your rate of winning.

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.

YOU WERE saying by taking people away makes the time double, triple quadruple.. not me

but now you are switching so now you are proving my point
my point is that everyone is independant and there is only one winner.. i never said its cumulative.. it was you that said it was cumulative by suggesting take 90% away and people will be waiting hours..

they wont..
AGAIN
have an olympic 100m race of 10 guys.. the winner gets to the end in 10 seconds..
now imagine if he was shot..
the runner up WONT!!!!!! have got to the other end in 20 seconds.. he would have got there in about 10seconds (plus a few miliseconds)

shoot all 9 runners so there is only 1 runner.. that last runner. again would still reach the end point in ~10 seconds.

based on YOUR scenario of everyone having 10% of hashrate. ill show you what i mean
YOUR (wrong) scenario:
"In other words, if this pool has 10% of all the hash rate, when his peers have mined 90 blocks on the new chain, he will have mined 10 blocks on the old chain. "

AGAIN only winning 1 block an hour does not mean your X* slower than anyone else.. it just means your competing against X number of people and 1 of X times you happen to be milisecond faster that anyone else.

you wont find runner 1 =10seconds
you wont find runner 2 =20seconds
you wont find runner 3 =30seconds
you wont find runner 4 =40seconds
you wont find runner 5 =40seconds
you wont find runner 6 =40seconds

you will find they are all close by each other yes a difference in hashrate can make a difference .. BUT so can LUCK of the randomness of the solution

take your example again
"In other words, if this pool has 10% of all the hash rate, when his peers have mined 90 blocks on the new chain, he will have mined 10 blocks on the old chain. "
if 9 pools went off and mined on chain X and 1 pool remained on chain A

after say 900 minutes
pool1chainX =~10 blocks taking ~10 minutes EACH block
pool2chainX =~10 blocks taking ~10 minutes EACH block
pool3chainX =~10 blocks taking ~10 minutes EACH block
pool4chainX =~10 blocks taking ~10 minutes EACH block
pool5chainX =~10 blocks taking ~10 minutes EACH block
pool6chainX =~10 blocks taking ~10 minutes EACH block
pool7chainX =~10 blocks taking ~10 minutes EACH block
pool8chainX =~10 blocks taking ~10 minutes EACH block
pool9chainX =~10 blocks taking ~10 minutes EACH block
(totalling 90 blocks with average 10minutes)

and
pool1chainA =~90 blocks in ~900 minutes
pool1chainA has no competition to lose by, by seconds

check out the orphan timing
https://blockchain.info/orphaned-blocks
the runner ups are SECONDS behind each other not minutes/hours


465722    
Timestamp    2017-05-10 08:19:11
Number Of Transactions    2752
Relayed By    Bixin
   
Timestamp    2017-05-10 08:19:10
Number Of Transactions    2726
Relayed By    GBMiners

Last try to make you understand the basics of bitcoin mining.

Consider 5 mining pools, each with 20% of the hash rate and with "difficulty in equilibrium" which means that ON AVERAGE there's 1 block every 10 minutes in all, and each pool wins a block every 50 minutes on average (1/5 of the blocks).

Up to here, I hope you are with me, OK ?

Now, consider that the first 4 pools switch off, but the difficulty level remains unchanged (it will not change for the next 2000 blocks).

Well, the fifth pool will still make his blocks every 50 minutes, and that's it.

So:

1) the fifth pool won't see much of a difference in his rate of winning blocks (namely about 1 every 50 minutes on average, with exponential probability distribution)

2) the total chain now being made by only this pool, the whole chain only wins 1 block every 50 minutes on average.

This is a very elementary notion in bitcoin mining.  If you don't agree, you've seriously misunderstood something.  Go ask elsewhere if you don't believe me.  Until this point is cleared up, there's no point in discussing other aspects of the bitcoin system.

Haha! Join the Club Dino!! we've all tried that.. (never works..)


Boom.. Have you met Franky1 ? Let me introduce you..  :P

I hope it is not that bad...

I need to add something, to lift a potential confusion: the orphaned blocks.

One may erroneously think that there are, say, 5 miners *in competition* and that it takes them *about exactly* 10 minutes of computing to get a block, but that sometimes, it takes the first one only 9 minutes and 59 seconds, and the second one, 10 minutes and 1 second, and they were all almost within a few seconds "in time".

This would be the case if mining a block were a cumulative effort: that the calculation took 10 minutes (and sometimes a few seconds less, and sometimes a few seconds more).

But, as pointed out before, this is not the case.  Mining a block is calculating hashes, and only one out of X hashes is an acceptable one, but calculating more hashes doesn't change the *probability* for the next hash to be good or bad.

As such, at each hash you calculate, you have a probability of 1/X to have a good hash and win the block.  This means that ON AVERAGE you have to calculate about X hashes, before you can hope ON AVERAGE to have a good one.  But this good one could be the first, or it could only come after 3X trials.  The probability distribution of the number of hashes needed to find the first good hash, is an exponential, with an average of X.

This means that miners find blocks at random times.  Sometimes, you find it directly.  The first hash you tried was the good one.  Sometimes, you have to calculate 3X hashes.  It is not that there is a block EVERY 10 minutes.  There is a block at RANDOM TIMES, and the interval is ON AVERAGE 10 minutes of all miners combined, but has an exponential distribution.
Each miner has an exponential distribution of "winning blocks", with an AVERAGE time that is given by

T_av = 10 minutes * (1/fraction of hash rate needed for 10 minute difficulty)


This means that MOST OF THE TIME, when a miner finds a block, HE'S THE ONLY ONE.  So MOST OF THE TIME, a miner wins all the blocks that he can solve, at an average time of T_av.

But it can be that during the small interval of time when the miner was calculating on the wrong (old) block, he happens to find a block JUST after another miner already found a block.  Essentially, the probability of this happening is dT / T_av, where dT is the kind of propagation time of a block from other miners to him.  In that case, our miner didn't know he was mining on the wrong (old) block, and publishes his block, to see that in fact, he was late.  That's orphaning. 

The frequency of orphaning can be estimated as follows:

Let us say in our artificial example that there are 5 mining pools with each, 20% of the hash rate.  This means that for all of them, T_av = 3000 seconds.

They all produce a block according to an exponential distribution, with an average of 3000 seconds each of them.

Suppose that it takes 2 seconds for a block to get propagated and checked by the other miners.  This means that during these 2 seconds, a miner hasn't yet seen and accepted the block of his peer that was published.  He has a probability of 2 s / 3000 s to find a block exactly during this time.  So once out of 1500, he will also publish a block, which will be orphaned.  So every miner will have a block orphaned once out of 1500.  Because there are 5 miners, it means that about every 300 blocks, a block is orphaned.

I believe you guys are just arguing semantics.   Franky never implied it wasn't a poisson process.  

In other news, I find it hilarious in this thread that Satoshi's vision is now considered "blasphemy".  Funny how that
never happened before Blockstream came on the scene.

Of course he did.  He thinks that if there are 5 mining pools, with each of them 20% of the hash rate, and 4 of them switch off, the 5th one will continue make blocks every 10 minutes.

This is the argument he used for a mining pool to leave the agreement he has  with his peers to remain on their mutual protocol, and to switch to the protocol the full nodes want to impose on the miners, because "then he is alone and will make blocks every 10 minutes, pleasing the full nodes and reaping in all the rewards".

My point was that
1) this was not the Gedanken experiment that needed to prove that full nodes can force their protocol onto miners
2) the betraying node is not winning anything, because he's not making blocks at any faster pace than if he remained faithful to the other miners and their agreed-upon protocol.

I never interpreted anything in this thread that he implied that (I actually think he tried to argue exactly what you are arguing -- that the percentages don't change based on the other pools) but I guess he can answer to that point.

Why would anyone run a full node?

First and more importantly, it doesn't earn me any money.

Second and moderately importantly, as it is not generating any money; it costs me money >:( It takes ram, cpu power, hdd space, electricity, internet bandwidth >> money to run a full node. What do i get in return? Nothing. There are many people who run it already no need for more.

If there weren't enough people on the other hand, i would gladly run one.

I agree with all you say. However, the situation is even more dire. Turns out we have been lied to all this time. The reality is that no entity is a node, if that entity does not mine. Indeed, this is the true, original, and proper definition of a node.

We need to reevaluate who 'sold us a bill of goods'. We have abdicated our authority in the network. In reality, non-mining nodes are irrelevant. Indeed, in the original wallet, nodes mine - period.

from https://github.com/trottier/original-bitcoin/blob/92ee8d9a994391d148733da77e2bbc2f4acc43cd/src/main.h#L795

GitHub
trottier/original-bitcoin
original-bitcoin - This is a historical repository of Satoshi Nakamoto's original bitcoin sourcecode

(emphasis added)

I don't know when the definition of 'node' became corrupted to include non-mining entities. I don't know who introduced this lie. Though I must admit to propagating it. For years. Sorry. I was ignorant.

He can, of course.  But I took this as such an indication:


... and have no competition ....

together with:


where he says:
(pool Awins every 10 minutes, zero competition)

and where indeed, he puts as many blocks (100) by pool A as by the 4 other pools.

This is what I'm trying to point out.  I don't know if it is "lying" or "indoctrinated" or whatever.
But the argument that bigger blocks would lead to centralization, while the centralization already took place, always left me astonished: no-body ever reacted to that.  It is not so much that I absolutely want bigger blocks or whatever - it is that the argumentation is fallacious, and I have a hard time believing that the experts saying so, can't make the same obvious reasoning than I did here, and did several times, just to be greeted with the counter argument "but everyone knows that full nodes matter / keep the network honest / .... " and if that doesn't work, that "I'm a paid shill " or something of the kind.  So, are all these people self-deluded ; or do some of them know this but don't want it to be acknowledged ?

I have difficulties with fallacious arguments from experts.

That said, full nodes are not totally useless, but their only use is for *their owner* who is the only one who can *check for himself*.  But with that knowledge, he can do nothing else but acknowledge "that he has been had" or "that he hasn't been had", but that's about it.  The other advantage of a full node, for his owner, is that his owner can send out his own transactions, and nobody can know that HE was the one sending that transaction, as, being a full node, he would also send all transactions of light wallets connected to him.  So there is some kind of deniable anonymity of the IP address that sent out a transaction.

But that's about it.  These can be sufficiently good reasons to run a full node, BTW.

Of course, it is true that full nodes DID HAVE power of filtering "bad blocks" when mining nodes were connected only to the P2P network to other mining nodes, and didn't talk to themselves directly.  Then the P2P network could stop them from building a chain with which the full nodes didn't agree, because they would not receive one-another's blocks.

But as I explained several times, a miner pool would be crazy to wait for other miners' blocks through the P2P network, while he can just configure his node to connect directly to the other miner pool's node and get it faster, wasting less hash rate.  As this is mutually beneficial, I don't see why mining pools wouldn't do so.

When I look at the LOW orphan rate, I arrive at the conclusion that miners know one another's blocks in about 1.5 seconds on average, which indicates that those blocks cannot really hop from node to node in between.  1 MB blocks, transmitted and verified within 1.5 seconds seems impossible to do over a random P2P path, where each node receives the block, checks it, and sends it out again.

ut if you want to prove the power of full nodes, you will have to leave aside hard forking.  Hard forking will be decided in the market ; NOT by full nodes.

wrong.. he has no competition so although his average times of maybe say 10.026.. he is not fighting off competition

ok

imagine it this way...

there are 2 100m tracks
track A
5 runners
they do their runs and after 100 races
on average each racer wins 20 races (give or take as some racers are slightly faster) but each race has a winner somewhere around 10 seconds


track B
1 runner
he runs, and after 100 races
he wins 100 races no competition
each race take around 10 seconds give or take a few miliseconds

he does not take 50 seconds.. he still only takes ~10 seconds but because he has no competition he wins every time

here il display it better

https://i.imgur.com/gvkrRQM.png
remember only the green numbers matter as thats the "fastest win", and there is no second place.. hense why no one cares about how long it takes the rest, which is where you wrongly think it takes the others much much much longer than reality(you imply he only gets 1 block every ~50 seconds)

as you can see.. on a track of 5 racers 1 guy only wins once out of 5 races..
but on his own he wins every race.. obviously.. and also it does not mean that if he only wins 1 race out of 5 with competition. that it would take 50 seconds without competition

What full node should i run ? chinese nodes aka BUg nodes ?
that is using an exploit called ASICBOOST that only mines an empty block.
Or should i run a core devs nodes that maintained the welfare of bitcoin through all this years ?

lol your reading too much reddit
seems you are already reading the scripts of the doomsday FUD buzzwords


so far other nodes brands lik BU have only dropped at most 420ish
 on march 17th CORE dropped 560 nodes in on go.
https://i.imgur.com/ebddd6x.png

also core is not perfect
https://github.com/bitcoin/bitcoin/issues?q=is%3Aissue+is%3Aopen+label%3ABug
and thats just the bugs they want to reveal. they also have a policy to not publicly divulge certain bugs for atleast a month after a fix
as commented here
https://github.com/bitcoin/bitcoin/issues/10364

all in all nothing is perfect. and even microsoft with thousands of devs has bugs
linux has bugs, even web browsers have bugs.

i would just choose which ever implementation offers you the features you will use/want.
PS. dont get the 30 second sales pitches from reddit/twitter. do proper research on the code/documentation if it means alot to you to want/need to run a full node. (especially if you are running a business)

also if people tell you Gmaxwell is god
even gmaxwell gets bugs in his own client which he has yet to fix
https://github.com/bitcoin/bitcoin/issues/9997


oh and BTCC (core/blockstream/dcg cartel pool) also does empty blocks
https://blockchain.info/block-height/465117

See: now you got it directly from him  :D


franky1, really, you have a serious, serious misunderstanding of the basics of bitcoin mining.

You are EXACTLY committing the error I pointed out above:


I think it is because you do not understand the difference between a very peaked distribution around 10 minutes intervals, and an exponential distribution with AVERAGE 10 minutes.

I think ideally, you run the full node you wrote yourself !  As such, you don't have to trust anyone and the reason to run a full node is to verify whether the thing one presents you as bitcoin corresponds to what has been sold/told to you as bitcoin.  If you trust code writers, you can just as well trust block chain writers, and you don't need a full node.

i do understand, much more then you think

my maths are only simplified not due to not understanding, but just to try getting to the point in a way even a layman can understand easily.
i use layman analogies to tone DOWN technicals into average guy speak. however it seems you try to grasp things at a laymen and try to abstract it into technical babble, while still missing the main points

yes there are more variables, but my posts only explain parts of them because the parts i mention are trying to show where your parts fall flat and it would end up taking a whole book to explain how the other parts interplay aswell..(which then just sidetracks the point)

you some how think there are only like 2 mechanisms of bitcoin and that non-mining nodes play no part in any security, bar being a data backup.

there are over a dozen mechanisms that all interplay each other. where nodes and pools have a symbiotic relationship not just for data backup, but for security purposes and data validation, collation and formation.

bitcoins symbiotic relationship, the fastest first, the orphan consensus, the propagation, the relay the tx validation, the block validation, and all the others all have a part to play.

you keep thinking that its only a pool is master.. node is slave game. where if a pool only gets a block every 6th block its average solution must take 60 minutes to find.. is RIDICULOUS

your maths of statistics has not looked at the context of where the numbers come from, nor (it seems) have you run scenarios either using algorithms, or paper or dice or just your mind.

the short and curlies of the part you try to suggest is that if there were 20 pools of say 5% (where the average pool only gets 1 block every 20th block) in your eyes means a pool only finds a block every 3 hours 20 minutes..(wrong on so many levels of understanding the context of numbers)

when the reality is they find block solutions much faster, but are IGNORED/GIVE UP as soon as a winner is found. and they all start again.. the hashtime does not add up on the next round. it starts at 0 again.
just look at the times of orphans where a runner up actually does get to win because the fastest first cheated or done something wrong, or other unmentioned reasons
https://blockchain.info/orphaned-blocks
not hours apart

much like olympic runners, having to run 100m..
just because linford christie or usain bolt win the majority of races, does NOT mean it takes 20 years for someone else to run 100m because they only win every 4th Olympic game

please look deeper at the numbers and look at the context of the stats.

You're digging yourself deeper in the hole.  Of course, that is EXACTLY the reason why he only has a block every hour, and hence, about 1/6 of the total amount of blocks.  

https://upload.wikimedia.org/wikipedia/commons/a/a7/Stop_Digging_%5E_-_geograph.org.uk_-_195319.jpg

he only gets a block every one sixth, because there is other competitors that beat him by seconds. and only the fastest guy wins..
as soon as the winner is found the clock resets.. blocks are found in 10 minute average. they do not continue hashing the same data for hours..
they reset and start again on fresh data as soon as a winner is found

As I said, and tried (in vain, apparently) to explain, you're totally wrong about how mining happens.  You think it is a cumulative calculation effort (even if you say you know it isn't, you think it takes very close to 10 minutes for every miner each time, whether that miner has 1% of the hash rate, or 40% of the hash rate, it always takes, up to a few seconds, 10 minutes). Can't help you any more.  This invalidates much of what you think about many things in bitcoin.

you argue it takes hours, and you knitpick my simplifying of "a few seconds" difference (facepalm)
the few seconds difference is in regards to your scenarios of all pools having equal hash..
you mention 10 pools of 10% hash.. so times would be similar...

yes if you add in other variables and change your scenario the times become more than just a few seconds.. but still not going to be hours like you suggest.

seriously go run some tests.. get some dice.. get you and some friends to run a few lengths of a field
make an alt and buy a few usb asics and run some proper tests
make an bitcoin testnet and buy a few usb asics and run some proper tests

10 pools with each 10% of the hash power find, each individually, a single solution on average every 100 minutes (1 hour and 20 minutes).  On AVERAGE with an exponential distribution: so sometimes after 1 minute, sometimes after 5 hours.  Note that statistically, there is not the slightest influence *on what block* they mine.  They could change block at each hash, that wouldn't change their rate of success nor the statistical distribution of their finding solutions.  As such, they don't care when they have to switch blocks on which they mine: it doesn't change anything to their success.

Each time they find a solution, they win a block.  The chronological order in which the different blocs are found, is the block chain.  

Very rarely, it can happen that two pools find a solution within a few seconds interval, while they were mining on the same block - then, one of them will orphan.  The only reason why the second pool has an orphaned block, was that he wasn't aware he had to switch the block on which he was mining, and continued to mine on the old block (in vain), and happened to find a solution right at that moment.

If miners would know each-others' solutions instantaneously (no propagation delay, no verification delay) there wouldn't be any orphaning, because at the microsecond when a pool found a block, all others are aware of this, and switch to the next one.  So if 3 seconds later, a miner finds another block, it is already the following block, not an orphan on the old block.  Orphaning only happens because of delays between miners.

It is simply fascinatingly amazing to be talking about bitcoin technical aspects, and to miss this ultra elementary aspect.

they dont
they find a solution in an average of 10 minutes..

SEPARATELY

their solution is only accepted every 10th time, due to the competition

being accepted as part of the chain.. is different than how long it takes them to make a solution.

learn the context

There's really no point any more in trying to explain how mining works to you.

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.

Franky1 -

You've made some good observations over the years. However, I think your clinging to bad analogies has you confused. On this mining issue, dinofelis is correct.

dinofelis is looking at things from a 2 dimensional view. he is not understanding all the features of bitcoin and what makes bitcoin so different than a fiat cheque clearing house.

bitcoin is unique for many more reasons than dinofelis seems to realise. and it seems all he wants to do is convince people to run lite wallets to hand pools more power by diluting the node count that can obstruct pools from changing the rules soo easily.(sorry if my critical mind things thats his motives, where it could just b he has yet to really fall down the bitcoin rabbit hole)

nodes do provide a crucial and critical part ofthe symbiotic relationship way more than dinofelis ieither wants to admit to, or yet to grasp.
but if he wants to run a lite wallet he should just go ahead and run a lite wallet.. but those of us that understand the real need/reasons for running a node will continue to

i feel that dinofelis is still stuck in the mindset of the fiat world of central control. and is still learning but not yet grasped ALL of the beauty of ALL of the bitcoin features that differentiate it from fiat archaic systems

lets say there are atleast a dozen different mechanisms of bitcoin.
i feel dinfelis only understands 4 out of 12... and is only brushing against understanding another 1or2 (from reading his post history).. id give him another year of actually running simulations and learning the context of it.. before he see's the mindblowing wonder of why bitcoin is better than fiat.

i feel he has not yet had that mind blowing experience.. but it will come

I run a full node, multiple actually. My reasoning for this is I am not a programmer I also do not own a business that I can accept Bitcoin at. The only way I can do my part in this community is to buy/spend Bitcoin, which I do, try to explain the benifits of using Bitcoin, which I do, and run a full node. I also dont currently mine Bitcoin and havent for quite awhile. Running a full node really doesnt cost that much if you have the hardware laying around. I was given a few old dell desktops with Core2Duo CPUs. I upgraded the hard drives to 1TB for cheap and taa-daa!

If this is all I am able to do to help out, even if its only a small help, Im ok with the tiny cost of doing so.

Bull crap all of you, you tell us to run a full node so miners get fat faster? what is the reason for a person not mining to run a full node? if a miner wants the votes of nodes then he will run them by himself, Bitcoin is not peer to peer, who says that? if miners refuse to include our transactions we can't do jack by our so called full nodes.
People like Franky1 can diversify the network by the money they earn through covert asicboost mining.

Generally ASIC miners are hacking machines, I can't mine with CPU and GPU? so I need to buy ASIC from a private manufacturer which turns out to be worse than governments?
Joke is on you hackers, miner=node no miner node=fool
Any miner out there to include my 120sat/b transactions if I broadcast from my full node every time without exception? then I will run a full node.

This is probably a good reason to run a full node: to get a feeling of satisfaction of contributing "something" to this Great Network and sleep with the comforting thought of a deed well done.

I did warn you  :-\

This is only true if you mean that : once the other miners are removed and the difficulty re-adjusts to the one miner/pool.... at THAT POINT, it would be every 10 minutes on average.

But sans difficulty adjustment, if you kill 9 out of 10 pools and have only 1 pool left, it would take 100 minutes, not 10.

Is that what you meant?

I run a full node whenever my PC is on so I can solo-mine whilst playing games / photography / etc...

I am also on the hunt for old miners for an Aussie solar panel system I am putting in...if you want to help strengthen the network, consider all those old dust collecting miners you have and now think about donating some.

Details from my marketplace post...

%%%%%%%%%%%%%%%%
https://bitcointalk.org/index.php?topic=1907886.0 (https://bitcointalk.org/index.php?topic=1907886.0)
%%%%%%%%%%%%%%%%

Please consider supporting crytpocurrency security with active distributed hashing, not consolidated into a handful of big miners / pools. If you have any old ASIC miners of any type that are currently door stoppers / dust collectors, please consider donating the items to an Aussie for strengthening the networks.

I am an electrical engineer that is putting some of my crypto into a modest stand alone solar / wind system using salvaged parts;
1. ~480W of solar panel
2. MPPT regulator
3. 2 car batteries
4. 3 UPS
5. 10 year old motherboard with AMD dual core processor
6. 30GHs R-Box (SHA-256) consumes 30W
7. 5GHs Butterfly labs consumes 30W

With this set up, I can establish some stand-alone ASIC miners to help strengthen the networks.

I am on the look out for:
1. Old ASIC miners of any type

I have some spoondoolies to cover shipping costs....

no
the pool would make blocks on average of 10 minutes
https://i.imgur.com/0Uxs6UU.png

Sorry bud... Franky... that's not how it works at all!

Time most certainly does not reset after any block.
The chances of solving a block are exactly the same at any point in time.

It doesn't matter if you run 100 trillion hashes, your chance of solving the block is (for all intents and purposes), exactly the same as when you started hashing.

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.

It seemed unrealistic.

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

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.

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.

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

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

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.

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 !

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

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.

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.

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.

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.

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

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.

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

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


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

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.

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:

https://www.probabilitycourse.com/images/chapter11/Poisson-merge.png

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.

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.

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.

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.

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

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

---

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
https://i.imgur.com/ddafdiw.png

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)
https://i.imgur.com/vpnnSfp.png

and now lets see if his 6 hours to make 6 blocks still holds weight

https://i.imgur.com/8mKyQjw.png

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

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

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.

That would mean that the orphan rate is 600%. 

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

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

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

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

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

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)

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

your taking things too one dimensionally literally.
ok lets try this.. be warned there is a test

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

1. what height is A working on while C was solving 469998 (imagining current height was 469997 and 469998-4700000 have not yet been solved)
[] 469998      [] 469996      [] 470000    [] 469995

2. imagine A did win 469998 instead of C, how long would you think it took using approx (meaning give or take a little variance.. not literal/exact)
[] 10 mins     [] 60mins      [] 30 mins     [] 40 mins  

please think beyond 1 dimension of counting blocks

While C was solving 469998, A is also working on the same block.  All miners are working on that block (unless there was some kind of latency and they didn't get 469997)


10 minutes.

This is what tricked me in trying many times too. And yes, they warned me and I didn't want to believe I couldn't get him to see this simple fact.  franky1 is not a total ignoramus concerning crypto, so it is beyond comprehension that he has a misunderstanding on which he is locked in so hard that nobody can get him out of there.... but there's no hope I'm afraid.  

But I'm starting to see part of franky1's confusion.  Yes, of course, all miners work on average about 10 minutes on EACH BLOCK.  When they win a block, they were only working on it for about 10 minutes.   It seems that "all the rest was wasted".  Probably franky1's confusion comes from the fact that "if there hadn't been that bastard of a competitor, I could have continued working on the block instead of having to give up on it and start all over again with a fresh one". So if, each time I WIN, I only needed about 10 minutes on average, I would only need 10 minutes on those that I had to give up because a bastard of a competitor forced me.

I think that is the core of his reasoning.

But this is wrong, because, exactly, it is not a race, but a lottery, like jonald tried to explain.

There is statistically not a single difference between mining on the same block, or changing blocks.  Your probability of success doesn't change.  It is as if you  had to throw different dice.  You chances of throwing a number don't change because you use different dice.  In other words, the fact that a "bastard of a competitor" forced you to change the block doesn't alter anything to your chances of winning one.  But I can somehow understand how this can be counter-intuitive, because by far most tasks we know, are a cumulative effort towards a result.

Let us try once more (you see, I'm tricked again in trying !).

Let us say that the "block on which you are working" is the specific dice you throw.   If I give you 3 red dice, and you need to throw 3 times a 6, you will have to try several times.  I have 3 blue dice and I try too.  You have one chance out of 216 to get 3 times a six.  Now after you've thrown 50 times without success, I have also thrown 50 times, and hey, I have 3 six !  At this point, you have to leave your red dice, and you have to use my blue dice now, while I take grey dice.  And we continue playing.
Do you think that you were "close to having 3 six" with your 3 red dice, and because I was a bastard of a competitor, forcing you to abandon the red dice, you can start over again ?

At each "round" (each second, say), both of us throw our dice.  As each of us has 1 chance in 216 to have a triple six, there will be a triple six found every 108 seconds on average, do you agree ?  But you will only find a triple six, on average, every 216 seconds, and me too.  The fact that I am present, doesn't change your chances of winning the next time.
It is only in very rare circumstances, that both of us win at the same throw.  In that case, one of us gets orphaned.  But that only happens very rarely.  Most of the time, each time you win, I don't win, and vice versa.  And whether I win or not, doesn't change the rate at which you win.

Be careful.  They are working on SIMILAR blocks, but each pool has made his own block, with its own picking of transactions from the mem pool, and with its own specific order of course.  They are working on top of the same consensus block, 469997, of course, because this one has been published.

Think of it like this:  Imagine a ginormous fish tank, 1000 miles high , wide, and deep, filled with plastic balls.  Most of the balls are yellow, but a few select balls are red.  The tank is constantly churning and mixing the balls, so if you reach your hand down and pull one ball it, its completely random.  You can toss a ball back in after choosing one, and still have the same exact chance of choosing a red ball.  Let's same three miners: Alice, Bob, and Carol each can pull one ball a second , check if its red, and then toss it back before trying again, and lets say the ratio of yellow to red balls is 1:1800.  After 10 minutes, each of them has done 600 pulls, and together 1800.  There's no guarantee they will pull a red ball in 10 minutes but that's the average.  Sometimes Alice will find a red ball quickly after Bob finds one, sometimes no one will find one for an hour.  The key thing is that whenever they pull a ball, the chances are always almost exactly 1:1800, because the tank is so huge.  


The mistake is to think that after 30 minutes of pulling balls, Alice's next pull will be anything different than 1:1800 chance.

Now lets say Bob starts to get really quick on the draw and he starts pulling 2 balls a second, so that now instead of 1800 pulls in 10 minutes, the 3 miners can do 2400 pulls in 10 minutes.  After 2 weeks, the tank magically adjusts the difficultly and now there's only 1:2400 red balls to yellow balls.

by the way im not an ignoramus about cryptography.
nor am i ignoramus about the odds of finding a block with 1 leading 0 vs odds of finding 18 leading 0's (im not being literal, im talking laymens)
nor am i ignoramus about for instance antpools 650peta hash a second and how many hashes over ~10minutes that equates too

p.s its not 1:1800

but until you realise that each pool works on EVERY BLOCK win or lose, theres no point talking about the the 3rd dimension


wow.. finally seems now you admit the pools work on every block.

so now your seeing that it resets each height (thank god your now seeing that.. after 2 days)
now imagine if it didnt stop hashing 469998 even when C won.. it kept hashing 469998. you would see that it would have a solved 469998 in approx:

i hope you see now that you realise its not working on say 470,000 based on the time from 469994.. but 469999 you can see things more two dimensionally..

can you atleast see how just VIEWING 2 blocks in a blockchain in a 1 hour period. DOES NOT mean it takes 30 minutes to solve a block

---

as for the new analogy of the lottery game

for 2 pages others were taking all the lottery tickets bought over 6 week of 6 games. and when winning only 2 lotteries. thinking it took all 6 weeks worth of tickets to win the 2 game .. but then double failed by saying it would still take 3 weeks to win..

rather than thinking that each week without anyone else buying tickets. then you could just yorself keep buying tickets until you win that weeks lottery. and it wont take 3-6x the amount of tickets

It IS hopeless.

lol. I had this really long reply to him typed up and just deleted it as I knew it would go no where. I was thinking maybe there was some unique thing that happens when you stick a bunch of miners in a pool that doesn't happen if they were all solo mining. So I was writing a simulation of 100k miners. But after seeing the true distribution (which, despite knowing better I still was thinking of it as a normal one), I shelved it as I had proved enough to myself that what he's saying just can't be true. For me the whole "average" thing is sort of misleading as it immediately puts a normal distribution in the back of your mind. But when you actually see it, things get pretty clear. At least it did for me.

anyway back on topic..

nodes DO have a crucial role to play..
anyone saying other wise just wants people to turn off their node..

Funny, me too !  :)  I edited my post with a long reply concerning the "lottery" stuff, when I wanted to submit, your post was there, I also realized the futility and didn't submit after all :)

Lol.

Well, 95% of all blocks being mined into existence are mined using my software so if he can't believe me telling him he's wrong then I'm not sure how much higher an authority you can appeal to?

I would like to recall to you, that our long digression into how mining works, was needed to try to make you see that you had an erroneous argument in favour of full nodes, because a miner with 10% of the hash power has NO INCENTIVE to step back from remaining in agreement with the other miners, simply because he's then hard-forking all by himself, and will make a 10 times shorter chain.

Your erroneous understanding of mining made (probably still makes) you think that that betraying miner is going to mine all by himself a fork of just the same length as the chain of the rest of the miners, and hence "reap in all the rewards, orphaning the 90% chain" because full nodes agree with him, and not with the miner consortium.  

But this is not the case: our dissident miner will make just as many blocks on his own little fork, than he would have made on the consortium chain (*), with just as many rewards: so there's no incentive for him to leave the consortium, and make his little hard fork.  There *may be* such an incentive, if our dissident miner thinks that he will have the majority of the USERS on his side, and that the majority of the USERS will dump their coins on the long chain, and will fight for the coins on HIS fork.  But this is "hard forking power games", and has nothing to do with full node power.
The irony in this is that in order for his hardforking to work, users need to be ABLE TO TRANSACT on the chain they would dump and which, in our gedanken experiment, no node wants to accept !

==> "the dissident miner" story has hence no relevance to the "full node power" story.  It is a different power game that is described.

You are in a kind of bleak position to use an argument of authority, after having blatantly shown your total misunderstanding of elementary mining dynamics.  Of course, any logically built up argument is independent of its author, but there isn't any such in your post.

I do recognise UTILITY (but no POWER) to non-mining full nodes.  The elements of utility are:

1) to the owner: to be informed of the eventual deviation of the actually used protocol on the block chain, and the protocol requirement of his node (in other words, to acknowledge that the miners are using a different protocol than the one he would like with his node)

2) to the owner: anonymity of sending transactions (deniability of IP address).

3) helping a P2P network of data propagation, in case that direct internet links to miner nodes have problems (technical/political/....)

4) as a proxy, relieving the miner nodes from user traffic and helping them to make bigger profits because they can spend less on their network infrastructure towards users (uh :) )

Edit (*): caveat: at least, if in his hard fork, he didn't mess with the difficulty of course and kept the difficulty of the parent chain.

Interesting.  So what is the distribution then , if not gaussian?

Perhaps he is mentally stuck on "proof of work" when a more descriptive term might be "proof of lottery participation"

(Hint:  A powerball lottery doesn't have a winner ever week necessarily.  If no one wins, the pot keeps growing until a winning ticket is found)

Exponential.
(at least, the "inter-block times" are distributed according to an exponential distribution)

gotcha. thx.

Yeah, like he said, exponential. My first full run was using a low difficulty and the solve times were really low as I just wanted to get a feeling for how it would work out. For that run, the "average" solve time was 4 seconds. The longest was 28 seconds. The median was somewhere between 2 and 3 seconds. i.e. half the block were solved before that, the other half after that. For the last run I was doing I had increased the difficulty and tweaked some performance issues and was running a much longer test but the damn computer locked up so I have't bothered starting it up again. The interm data from that test was following the same sort of distribution anyway.

actually there are a few things, which help.
in laymens.(simplified so dont knitpick literally)

say you had to go from "helloworld-0000001" to "helloworld-9999999" hashing each try where the solution is somewhere inbetween
solo mining takes 10mill attempts and each participent does this
"helloworld-0000001" to "helloworld-9999999" hashing each try (very inefficient)
however, pools gives participant
A: "helloworld-0000001" to "helloworld-2499999" hashing each try
B: "helloworld-2500000" to "helloworld-4999999" hashing each try
C: "helloworld-5000001" to "helloworld-7499999" hashing each try
D: "helloworld-7500000" to "helloworld-9999999" hashing each try

which is efficient...
which at 1-d makes people think that killing POOLS takes 4x longer...

---

---

but here is the failure...
pool U does "helloWORLD-0000001" to "helloWORLD-9999999" hashing each try 20min to get to 10mill where a solve is somewhere inbetween (average 10min to win)
pool V does "HELLOworld-0000001" to "HELLOworld-9999999" hashing each try 20min to get to 10mill where a solve is somewhere inbetween (average 10min to win)
pool W does "helloworld-0000001" to "helloworld-9999999" hashing each try 20min to get to 10mill where a solve is somewhere inbetween (average 10min to win)
pool X does "HElloworld-0000001" to "HElloworld-9999999" hashing each try 20min to get to 10mill where a solve is somewhere inbetween (average 10min to win)
pool Y does "HelloWorld-0000001" to "HelloWorld-9999999" hashing each try 20min to get to 10mill where a solve is somewhere inbetween (average 10min to win)
pool Z does "HelLoWorLd-0000001" to "HelLoWorLd-9999999" hashing each try 20min to get to 10mill where a solve is somewhere inbetween (average 10min to win)
it takes each pool similar times to get to 9999999 and each would get a solution inbetween should they not give up
and if you take away pool W,X,Y guess what..
pool Z doing "HelLoWorLd-0000001" to "HelLoWorLd-9999999" hashing each try would NOT suddenly take 4x longer to get to 99999999
because Z is not working on a quarter of the nonce of other pools!!!!!!!!!!!!!!!!!

because the work pool Z is doing 'HelLoWorLd' is not linked to the other 3 pools.

---

so 2 dimensionally
pool U does "helloWORLD-0000001" to "helloWORLD-9999999" 20min to get to 10mill (average 10min to win)
pool V does "HELLOworld-0000001" to "HELLOworld-9999999" 20min to get to 10mill (average 10min to win)
pool W does "helloworld-0000001" to "helloworld-9999999" 20min to get to 10mill (average 10min to win)
pool X does "HElloworld-0000001" to "HElloworld-9999999" 20min to get to 10mill (average 10min to win)
pool Y does "HelloWorld-0000001" to "HelloWorld-9999999" 20min to get to 10mill (average 10min to win)
pool Z does "HelLoWorLd-0000001" to "HelLoWorLd-9999999" 20min to get to 10mill (average 10min to win)

because they are not LOSING efficiency pool Z does "HelLoWorLd-0000001" to "HelLoWorLd-9999999" still takes 20min to get to 10mill (average 10min to win)

---

now do you want to know the mind blowing part..
lets say we had 10minutes of time
you would think if pool W had 650peta and that if pool Z had 450peta
you would think pool Z =14 minutes due to hash difference

but
what if i told you out of the 10 minutes upto 2minutes is wasted on the propogation, latency, validation, utxo cache.. (note: not the hashing)
so
if pool W had 650peta
if pool Z had 450peta
pool Z =11min33 due to other factors because the calculating of hash is not based on 10 minutes.. but only ~8ish (not literally) of hashing occuring per new block to get from 0-9999999 (not literally)

now imagine Z done spv mining.. to save the seconds-2minutes of the non-hashing tasks- propogation, latency, validation, utxo cache.. (note: not the hashing))
Z averages under 11min:33sec

so if Z went alone his average would be UNDER 11:33sec average

---

so while some are arguing that out of 6 blocks
U wins once, V wins once, W wins once, X wins once, Y wins once, Z wins once..
they want you to believe it take 60 minutes per pool to solve a block (facepalm) because they only see W having 1 block in an hour

if you actually asked each pool not to giveup/stale/orphan .. you would see the average is 10 minutes(spv:10min average or 11:33 if validate/propagate).. but only 1 out of 6 gets to win thus only 1 gets to be seen.

but if you peel away what gets to be seen and play scenarios on the pools that are not seen (scenarios of if they didnt give up).. you would see it not 60 minutes

not gonna argue with you Franky , cause i'd be simply repeating myself.

On a sidenote.... question for _ck:  -- how much time is actually spent validating, and is this typically done in parrellel?

ask him
not to be biased on the leanest linear block... but a average block that has some quadratics and where UTXO cache delays things
and
not to be biased of FIBRE header only.. but a average full block relay or average where latency and other things are included, such as average connections
and
all the other non hashing functions, then come to a total

and guess what.. if they try to argue its all milliseconds of non hashing function...
then that debunks all the issues core extremists ever had against "big blocks"

P.S
im gonna laugh when he wants to knit pick '2min' difference.. but cannot explain himself out of the 50-60 min difference he thinks

Block validation speed depends on a combination of software, hardware, optimisations, block complexity etc. An average current 1MB block is about 3000 inputs, 30,000 sigops and on my pool's heavily customised coin daemon and server hardware it takes 70ms. This is done in parallel to the functioning of bitcoind, but it cannot process more than one block at a time - if it did, the memory requirements of doing so would blow all out of proportion for a sigop heavy block. Older versions of the core client were much slower (such as 0.12 which BU is based on.) This doesn't take into account time to generate new work for the pool which adds another 70ms.

70 milliseconds?

So, then... negligible, right?  As far as orphan rates.

Your error is (again) that in your proposal, one is doing cumulative work.  If you are going to do an exhaustive search, here, over 10 million potential solutions, and you have done 5 million of them without success, then you have INCREASED your probability to have a good answer next time from 1/10 million, to 1/5 million.  The more you work on a block, the higher the probability becomes that the next trial will be a winning one.

So having to reset, in this case, is a pain in the butt, because you lose the advantage of cumulative work.  This is because your statistical model (in 20 minutes, you have the answer for sure) is not the one of the proof of work.    If you had been working for 19 minutes and 59 seconds on a block, you KNOW that you will win in the second that follows.  Your probability to win is 1 now.  While the probability to win, the first second you started on that block, was 1/1200.  In the bitcoin PoW function, this is never the case: the probability to win, after working for 10 hours on a block, is exactly the same as the probability to win the first second.  This is because there is not "one answer in a set of 10 million" but "gazillion answers out of megasupergazillion".

I know it's in vain, but I am fascinated.

There really isn't any efficiency there. How you assign the nonces doesn't matter since which nonces will result in a solution is completely random. For example, nonces that yield a solution for a given block could be 500000, 600000, 7000000. In which case the distribution you've shown would result in them taking a very long time to get a solution. You could just give each miner the next sequential nonce as they completed their work and it would be just as "efficient".

The only reason in your example all the pools take the same amount of time to get to 10mil nonces is because you're giving them the exact same hash rate which isn't reality. They're also each trying to solve completely different blocks (same # but different data). The block they're solving for has their address in it and whatever transactions they decide to put in that block. They're not all racing towards the exact same nonce/solution.

Regardless, can you explain how the entire premise and math that has gone into bitcoin that says that 4,300PH at 559,970,892,891 difficulty will yield an average block time of 10 minutes and yet a pool with 20% of that hash rate will still get an average block time of 10 minutes. Can you provide the math that shows that?

(facepalm)

im starting to see where you have gone wrong...

you at one point say
"then hard-forking all by himself"
"going to mine all by himself"

 but then you back track by bringing him back into the competition by talking about orphans.

if a pool went at it alone.. there would be no competition. no stales no orphans no giving up..

now can you see that it would get every block
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"
now can you see that instead of timing an hour and dividing it by how many blocks solved in competition.. you instead of look at the ACTUAL TIME of a block from height to height+1... not height to height+6

Orphaning makes up a small percentage of blocks.  This is known both from actual data and common sense:  If it takes milliseconds to validate a block and seconds to propagate one, compared with the fact that the entire network solves a block every 10 minutes, its a very small ratio.

So its better to ignore orphaning to simplify the conversation.

I know you still think that.  See above. 

But it is still just as wrong as before :)

Franky1 is still locked in thinking that a mining pool that had 1/6 of the hash rate, and hence 1/6 of the blocks when he was in consensus with the others, is going to make 6 times faster blocks if he forks of on a hard fork, pleasing the full nodes and leaving his peers behind with their 5/6 of the hash rate.

Of course, he will make all the blocks on his own new forked chain ; but he will make them 6 times slower too, so concerning "winning rewards", he's not going to make any more profit if his chain gets adopted in the end, than when he was remaining on the consensus chain.  Franky1 thinks he will make 6 times more rewards because now "all the blocks are his", but he doesn't understand that our miner will make 6 times less blocks in the same time.  

(back to square one....)

Caveat: at least, if our forking miner is not MODIFYING the difficulty or reward of the chain, but that's not very probable that the full nodes would be running code that has this changed...

To run full node, atleast need minimum storage around 200GB with unlimited bandwidth. These node wont make network stronger, thats miner will make network stronger. Full node really help to secure network if network use POS as main consensus

(facepalm)

for the third time
forget about % of VISIBLE orphans (theres more then you think. )
forget about counting acceptd blocks over an hour and divide by brand amount (theres more then you think. )


instead JUST LOOK at the times to create a BLOCK:
height X to height X+1...
not
height of last visible brand z to height of next visible brand z / hour

what you dont realise is that more block attempts occur then people think.
EG. dino thought the only blocks a pool works on is the block that gets accepted(visible), hense the bad maths.

i did not bring up showing the orphans to talk about %
just to display and wake people up to the fact that more blocks are being attempted in the background

look beyond the one dimensional (literal) view.
actually run some scenarios!!


P.S
orphan % is only based on the blocks that actually got to a certain node..
EG blockchain.info lists
466252
465722
464681

blockstrail lists
466252
466161
463316

cryptoid.info lists
466253
466252
464792

again.. dont suddenly think you have to count orphans. or do percentage games..
just wake up and realise that pools do more block attempts then you thought.
think of it only as a illustration of opening the curtains to a window to a deeper world beyond the wall that the blockchain paints

then do tests realising if those hidden attempts behind the curtain (all pools every blockheight) worked out...
the times of every blockheight by continuing instead of staling, giving up, orphaning, etc....
you would see a big difference between  
height X to height X+1...
vs
height of last visible by brand z to height of next visible by brand z / hour

moral of this topic:

run a full node, not just to:
make transactions without third party server permission
see transactions/value/balance without third party server permission
secure the network from pool attack
secure the network from cartel node(sybil) attack
secure the network from government shutdown of certain things
secure the data on the chain is valid
secure the rules
help with many other symbiotic things


but
to also be able to run tests and scenarios and see beyond the curtain of the immutable chain and see all the fascinating things behind the scene that all go towards making bitcoin much more then just a list of visible blocks/transactions

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.

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.

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

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.

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

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

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.

@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 ?

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

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

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

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.

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.

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.

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:

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

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.

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

https://i.imgur.com/S440yqi.png

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)

@darkbot, you're on ignore.

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

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.

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.

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.

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

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.

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 say it does not work, so whataya want from the bitcoin network?

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

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.

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.

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.