Propagating orphan block headers | Bitcointalksearch.org

According to the official protocol rules, when a node receives a block that extends an orphan branch (but doesn't make it the main chain), the client simply stores the block. It doesn't relay it.

This makes it impossible for nodes on the network to know if there is an orphan chain receiving significant hashing power.

If the rule was changed so that the block headers are forwarded, then the network would be informed about alt chains that are being hashed against.

This would allow a warning to be given that a potential network split is occurring. The client could then mark a transaction as unconfirmed if it occurs after the split.

The change would be to amend rule 17 from

Code:

For case 2, adding to a side branch, we don't do anything.

Code:

For case 2, adding to a side branch, if the fork point is within  blocks of the end of the main chain, relay the block header of the block to our peers.

Transmitting a block header shouldn't be taken to mean that the block has been verified. It only means that block header forms part of the PoW tree.

This could cause problems with SPV clients, but they already assume that PoW alone is secure.

There would also need to be rules added for receiving a header. It should be forwarded if it extends any branch in the tree (near the end of the main chain)

Topic: Propagating orphan block headers (Read 1070 times)