Author

Topic: Broadcasting all headers that are at least 6 blocks deep (Read 1084 times)

legendary
Activity: 1232
Merit: 1094
Seems overly complicated considering that little that existing implementations due today to deal with weird cases.

I don't think it is that complex. 

If a block or header is received that extends the tree, then you scan back 6 blocks and forward the block header to all peers that haven't that header.

It wouldn't be necessary for the main chain, since those blocks/headers should have already been forwarded.

Quote
and I've seen no evidence so far that it does any good... including cases where services were running bitcoinds on faulty hardware that ended up forked, and still failed to respond at all to it.)

Well, that is partly a separate issue.
staff
Activity: 4242
Merit: 8672
Seems overly complicated considering that little that existing implementations due today to deal with weird cases. I'd be more interested if there were any evidence of implementations making .. well. really.. almost any effort to handle exceptional cases like this usefully.  (Bitcoin-qt does something more than nothing but only very slightly more than nothing; and I've seen no evidence so far that it does any good... including cases where services were running bitcoinds on faulty hardware that ended up forked, and still failed to respond at all to it.)

But, at the same time, I do agree that would address the goals there. Just given the environment today, it may not be worth the additional implementation complexity and risks. This may change, I'd certainly like to see better reactions to weird cases.
legendary
Activity: 1232
Merit: 1094
When a miner finds a block, he could broadcast the block header immediately.  It could spread over the network much faster than sending the whole block, but headers aren't forwarded without the block to back them up.

This policy exists due to potential problems with incentives of broadcasting headers. 

If a miner receives the header but not the full block, then he should stop mining on the old block.  Since he doesn't have the new block and doesn't know which transactions were in the new block, he has to mine empty blocks.  This means that miners would have an incentive to wait a while before sending the full block, but they must send the headers as fast as possible.

The policy means that miners don't send off main-chain headers.  This could be useful in a fork situation.  If nodes could see that a large amount of mining power is hashing on an alternative fork, then it shows that there are problems with the system.  Merchants could shutdown their operations.

The current reference code goes into safemode if there is a fork larger than 6 blocks.

This doesn't cover the situation where there is a hard-fork (or a soft-fork with < 50% of the hashing power supporting it).  In that case, miners would simply reject the other fork and so a re-org wouldn't be triggered.

I suggest that headers should be forwarded if

  • It is less than 1008 blocks worth of POW behind the main chain
  • The header has at least 6 headers built on top of it

The first rule prevents spamming with low difficulty chains.    The second rule blocks the withholding attack.  By the time the block has 6 blocks on top of it, the block would have been forwarded anyway.

The advantage is that it allows the entire block header tree to be forwarded.
Jump to: