Block orphans/day?

[Altoidnerd]

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.

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.

[t3a]

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.

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

[kjj]

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.

[Sergio_Demian_Lerner]

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.

[TierNolan]

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.

[kjj]

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

[Peter Todd]

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.

[TierNolan]

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.

[Altoidnerd]

Unless a pool has over 50% of the mining power it will always be bad for them to delay a broadcast...

I don't think this is correct.

[t3a]

Unless a pool has over 50% of the mining power it will always be bad for them to delay a broadcast...

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.

[teukon]

Unless a pool has over 50% of the mining power it will always be bad for them to delay a broadcast...

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.

[t3a]

Unless a pool has over 50% of the mining power it will always be bad for them to delay a broadcast...

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.

[TierNolan]

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. 

[t3a]

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

[TierNolan]

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.

[t3a]

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.

[teukon]

This was not a strawman.  I have not mis-represented your argument.

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.

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:

If you broadcast sooner, it is more likely that more of the network will recognize your block over another.

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

Unless a pool has over 50% of the mining power it will always be bad for them to delay a broadcast...

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.

[TierNolan]

That example doesn't illustrate that producing a 10 block chain before broadcasting is advantageous.

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.

[t3a]

This was not a strawman.  I have not mis-represented your argument.

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.

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:

If you broadcast sooner, it is more likely that more of the network will recognize your block over another.

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

Unless a pool has over 50% of the mining power it will always be bad for them to delay a broadcast...

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

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.

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?

[TierNolan]

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.