Bitcoin Forum

Does anyone know a web page which shows a live statistic of the number of orphans created in a day ?

Is there any paper that presents this information?

Have anyone computed the average orphan rate during last year and previous years?

Best regards,
 Sergio.

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

Why are there 32 orphan blocks on March 11-March 15?

is that an unusual number of orphan blocks?

BIP 50 (https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki)

The 0.7 - 0.8 fork, and then the required reorg thereafter orphaned a long chain.

There is not, and such a thing is not possible.  The concept of orphanhood is purely local.  Some sites have lists of orphans as seen by their node.  Blockchain.info has already been mentioned, block explorer has another.  There are probably others too.

A while back I estimated the global race/fork rate to be in the neighborhood of 1 in 300.  My method was not very special, merely counting the orphans seen by a node and dividing by the number of blocks over the same span and multiplying by two (because I figure on average a given node will land on the winning side first about half the time).  I have vague memories of other people arriving at similar figures, but I doubt that I could find any references.

The spike on April 1st, 2012 is due to the P2SH roll-out.  As I understand it, there was an unusual transaction floating about which was being included in blocks by the old code which were then rejected by the new code.  This was not a long fork but a collection of small forks (a chain of length 4 was the longest reported).

The blockchain.info data doesn't seem to go back past about August 2011.

There's some data here (https://gist.github.com/anonymous/3635514) which goes back about one more year but is less complete (because the node observed was less well-connected).

Going back a little further, there was the 50+ orphan chain in August 2010 (the infamous Value Overflow bug).

It would depend on the connectivity of the network. 

For an orphan, there will be 3 groups, those on one side, those on the other and those on the boundary.  Those on the boundary will receive both.

When the block is orphaned, the entire network will learn of the accepted block.

On the other hand, the block that is orphaned is more likely to be the 2nd block found of the two.  This means that the number of nodes who see it first will be smaller.

So, maybe <smaller - half> + <boundary> = <bigger-half>, so back to seeing half of the orphans.

A well connected node is likely to be on the boundary, so will see the orphan directly.

It's possible to get the number of orphans as seen by pools who found the orphaned blocks. You'll find the pools orphan rate depends on the pool software.

Question: in light of the relativity of the statistic "# of orphans" to the reporting node, what exactly in specifics is the statistic blockchain.info is reporting in the chart?

Blockchain.info is connected to every major pool, so they will see much more than half of all orphans.

I can say with considerable confidence that you are not in possession of data supporting that claim.

Not sure we have a working definition of orphan.  A solved block which is never broadcast shouldn't qualify as an orphan; for an edge case, I mine one mentally and never tell anyone.  There could be many of these, but they lack physical meaning.

Probably, the only meaningful metric has units of orphans*nodes orphans*edges¹ and so is weighted by how popular an orphan is before it is orphaned...

Another problem with creating a definition for orphan is the remote possibility that a shorter chain catches up later...it may or may not be possible to say a block is certainly an orphan at some time - unless 100 confirms is used as a hard limit?  Not sure.

¹ in the graph theory sense.  Since a solo disconnected node can mine infinity orphans tomorrow, it is perhaps necessary to exclude the (root?) (seed?), or count edges.

Terminology may exist here http://research.microsoft.com/pubs/156072/bitcoin.pdf

Well right here it says who the block was relayed by. It either was sent to them originally by an unknown node, or it was sent to them by a known node which is owned by the pool.

https://blockchain.info/pools

How do you define orphan?

A mined block that was not included in the main blockchain.

http://media.dcentertainment.com/sites/default/files/galleries/file/ajax/field_galleryimages/und/form-2qVMXrakEpw5pPLErZud1h-ZtF3b8WMQz3Cax0E6eY8/Batman-Coin.jpg

The same way everyone else does. https://en.bitcoin.it/wiki/Orphan_Block

Those are technically stale blocks, not orphans.

/nitpick

Right, well I made serious remarks about the shortcomings of that definition - it doesn't refer to a measurable quantity.  It refers to nothing in fact - there is no way to prove that there aren't infinity of those every day.

Here it is, again, because I can't watch y'all try to debate the measurement of a quantity that isn't even well defined.  kjj suggested something a little weaker, I agreed and took it further with:




TL;DR "orphans" means nothing - can't measure orphans/day but perhaps could measure (orphans) times (nodes who thought the block was legit)

There is no way to prove that, but when a miner generates a block they will immediately broadcast it so they *don't* get orphaned.

Blockchain.info is connected to most of the major pool nodes (75% of the network hashrate is identifiable to them).

75% is more than half,

therefore blockchain.info probabilistically should see more than half of all orphaned blocks. You can't prove that there aren't infinity, but if unknown miners were producing a ton of orphans on top of the main chain then they would also be producing a ton of blocks on top of the mainchain.

Well not if they're "selfish" right....

That's why I am interested in this metric. It could be to useful infer statistically if pools are delaying broadcasts.

I want to understand your 75% figure but I can't get past the lack of a clear definition for orphan. You must mean something like 75% of blocks broadcast by major pools which were seen by many nodes and are not part of the main chain today, if we measure the longest chain right now.

Unless a pool has over 50% of the mining power it will always be bad for them to delay a broadcast because delaying that broadcast could mean losing the block. It isn't selfless to broadcast your blocks.

I mean 75% of the blocks on blockchain.info aren't in the unknown category meaning 75% of them were relayed directly from the miner. If 75% of the blocks are relayed by known miners, then 75% of the orphans are going to be directly relayed to them. Orphans that aren't released fast enough and not directly may not make it to them (this is the 50% you were talking about).

You seem to have a peculiar amount of faith in the guesses that blockchain.info posts on their site.  Go look up some of your own past transactions and see how well they do at figuring out which outputs are the value and which outputs are the change.

Go on.  We'll wait for you.

For blockchain.info orphan == stale
(definition in https://blockchain.info/orphaned-blocks)
This is a technical mistake, since "orphan" means "no parent", but this is how the term has been used, not only there but also in https://en.bitcoin.it/wiki/Orphan_Block

As I understand, stale blocks will be forwarded to all the network, even if they are not in the best chain.
So all nodes known how many stale blocks are created.

I don't think this is correct.  My understanding is that the process is something like

- Block received
- Find parent from block header's hash
- Total_POW(new_block) = Total_POW(parent) + POW(new_block)
- If Total_POW(new_block) > best_chain_so_far then update best_chain_so_far and attempt to validate block
- If block is validated then forward to all peers

Blocks which don't extend the main chain don't get checked or forwarded.

Personally, I think the headers should be forwarded, even if the blocks aren't.  That would have the advantage that (near) exact orphan counts could be made.

It would also allow miners to more quickly agree on which block was found first.

It has the disadvantage that anyone can spam the network by creating blocks from an easier point in the past.

You would only forward stale block headers if their difficulty was equal to the current difficulty of course.

Right.  I would set it to a percentage though.  If all headers that met 1/64 of the block difficulty were forwarded, then it would bring miners to consensus on the leaf block faster, but that is a separate discussion.

Another way would be to only forward headers if they link to a block within 100 of the leaf.

I don't think this is correct.

Why not? If you have a block and wait instead of broadcasting, someone else could broadcast their block in that time, which would mean the network would start mining on their block instead of yours and you would be left with a stale block instead of 25btc rewards.

You seem to be assuming that broadcasting a block is an instantaneous process.  This would make things far easier but, alas, it is not the case.

Notice also how it's possible to have one fraction of the network building on one block while another fraction builds on its brother.  This is not a fleeting state but one that will likely endure until someone finds a block to settle the issue.

I am not assuming that it is instantaneous. If you broadcast sooner, it is more likely that more of the network will recognize your block over another. Your strawman is irrelevant anyways because whether or not the broadcast to the entire network is instantaneous, it is beneficial to broadcast as soon as possible.

It isn't necessarily a strawman.

With a properly operating network, broadcasting the block brings a significant portion of the hashing power onto your block.  Therefore, by broadcasting, most of the rest of the network's hashing power helps protect your block.

Some alt chains with block rates less than a second ended up dying due to collapse of this effect.

There was very little advantage in broadcasting.  By the time everyone knew about your block, many more blocks would have been found anyway.

It turned out that holding back your blocks was the best strategy for the miner with the most hashing power. 

This is only true if they have 51% of the network power. Otherwise broadcasting (even if the odds of stale are high) increases your odds of making money from 0% to something%.

No, but it depends on a breakdown of a the core assumption about network conditions.

Imagine that you have a miner with 20% of the network power and the other 80% are lots of small miners.

It takes 5 seconds for blocks to propagate over the network.  However, the network produces 10 blocks per second.

The 20% miner gets 2 blocks per second.  This means that he can create a chain of 10 blocks during the network propagation time.

The other 80% can't coordinate.

They produce 8 blocks per second.  What should they set as previous block?  The can't coordinate, so they all set it to point at some block from the last 5 seconds which is 40 possible blocks.

They all spread their mining power over 40 possible previous blocks.  This means that their chain grows 40X slower.

If the 20% miner released his chain, it would help them coordinate, so he doesn't.  They produce 8 blocks a second but their chain only grows by 1 block every 5 seconds.

The 20% miner grows his chain at 2 blocks a second, which is faster than any of them.  His advantage is that he gets 100% efficiency from his mining power and directs it at one chain.

That example doesn't illustrate that producing a 10 block chain before broadcasting is advantageous. If you wait to broadcast until you have a 10 block chain you will only succeed when you have a 10 block chain faster than the rest of the network. Broadcasting the blocks individually and building on top of those makes you win both in the case that your 10 block chain is the tallest and the case where some of the first are part of the tallest.

What your example does demonstrate (and I think this is where the confusion is coming from) is that it is an advantage to be in a pool when you have ridiculous block generation speed.

This was not a strawman.  I have not mis-represented your argument.
very clearly suggests that the first to broadcast will receive the attention of the network as a whole, guaranteeing that a later broadcast rival block will become an orphan.

You've merely changed your argument to:

Unfortunately, while true, this is insufficient to support your earlier claim:

Certainly, a pool wants to reduce the probability of its blocks becoming orphans.  To this end, the broadcast strategy: "broadcast as soon as possible" is optimal.  However, a pool will also want to reduce difficulty so that it is able to find more blocks.  To this end, the broadcast strategy: "broadcast a block only once a rival block has been seen" is (roughly) optimal.  It is not clear that the first concern always outweighs the second (for pools controlling no more than 50% of the network by hashrate), especially in light of the fact that some nodes are better connected than others.

You are helping the other miners.

If you produce 1000 blocks before broadcasting, the rest of the network would be 975 block behind if you don't broadcast every block.  If you broadcast every block, they would be only 10 blocks behind.

You are right that it doesn't help them overtake the main chain.  

The only case I can think of is where keeping them secret is if a larger miner joins the network.

If you have 10% of the network power and have a 500 block chain produced in secret and an 11% miner joins the network, then you will reach the 1000 block point before he can produce 1000.

This means you get 500 more coinbases than you would otherwise have received.

Keeping them secret means that he will have a 500 block orphaned chain before he can take control of the network.  This might discourage him, so he leaves the coin.  This is an added bonus.

There is no advantage to broadcasting blocks and sometimes disadvantages.  That means keeping them secret is the best strategy.

You misrepresented my argument saying I thought the propagation was instantaneous. I didn't suggest the first to broadcast that the network would immediately recognize theirs, I only implied that it could be propagated in that time "someone else could broadcast their block in that time".


If you broadcast block-you-found 1 and that is chosen as the winning block by the network, then you have 1 block. If you keep mining on that block, you will keep having the same chance of having your block winning. If you wait until you have 10, you will only win if 10 haven't been mined in that time. You aren't giving anyone an advantage by letting them mine on your blocks because it's either your blocks or someone elses blocks they're going to be mining on.

Question: What does this obscure example of a network with terrible rules have to do with anything?

The conclusion is that broadcasting as fast as possible is the best strategy, except for networks with "terrible rules".

This comes up when discussing reducing the time between blocks.

Certainly they gain something.  By building upon your block rather than beside it the probability of their next block becoming an orphan is reduced.


I don't know about you but I'm talking about Bitcoin with it's current rules.

If there are 10 blocks per second they could easily be mining on someone elses block. They benefit you by mining on it.

You aren't talking about Bitcoins rules. If we were talking about bitcoins rules we would be talking about blocks that are propogated in 1/500th of the block generation time, not 10 times the block time.