As the value of bitcoin increases, the cost of mining an invalid block becomes very high. Therefore, all nodes should relay a block, even an invalid one, as long as it's hash is not significantly higher than the target (say 3%), is not significantly larger than the block size limit (say <1.05MB), and does not take too much resources to verify (cf. other block limits like sigop restriction). A few percent room is suggested to detect any unexpected behaviour in these edge cases.
Regardless of the block content, a block header is always relayed if there were enough PoW or just slightly above the target.
Miners will include their public keys in the coinbase. For safety reason, this key-pair shouldn't be associated with any bitcoin as it has to be hot stored. For anonymity reason, the same miner may use a new public key for each block he finds. When a owner of the last X blocks (say X = 2016) see a new valid block, he will sign a message ("Block witness report") and broadcast to the network:
Quote
I am running . The block, with , is first seen at . This is the block of height I have ever seen. I think this block is valid
This timestamp is the time he first saw the block header
If he thinks the block is invalid, he will sign this:
Quote
I am running ..........(same as above). I think this block is invalid because
If he just got the block header, he will sign this:
Quote
I am running ..........(same as above). I see the block header only
A miner shouldn't sign any conflicting Block witness report, or his public key will be black-listed. Nodes will relay Block witness reports as long as they are signed by eligible miners.
The bitcoind will run in safe-mode if there are long competing forks. Merchants will be able to detect a fork early, and refuse to deliver until the fork is resolved.
What if a miner tries to abuse this system to DoS the network?
1. They may deliberately mine a invalid block. Therefore, the red flag should be raised only if there is an invalid chain with >1 blocks, not just a single invalid block. Anyway, an attack like this is very costly and the effect is limited.
2. They may troll us by claiming valid blocks as invalid. Therefore, the red flag should be raised only if there is an actual fork, not just a invalid chain. Therefore, the attacker has to mine a side chain to make the attack successful. With <50% mining power, he will most likely lose all mining reward.
------------
If this system was implemented in the Mar 2013 fork, what would it look like?
All clients will see 2 competing chains growing
For 0.7 clients, although they think the v0.8 fork is invalid, they will notice that all v0.8 nodes think it is valid, while all/most v0.7 nodes think it is invalid. Even worse, the invalid chain becomes longer and longer. The safe-mode is triggered
For 0.8 clients, although they think both chains are valid, they will find all/most v0.7 nodes reject the v0.8 chain (the longer chain), and some people are mining on top of the v0.7 chain (the shorter chain). The safe-mode is triggered
-------------
If an attacker suddenly release a chain of 6 blocks, outpacing the current chain, all bitcoin nodes will go to safe-mode. Human intervention is required. By looking at all the Block witness reports, it will be easy to identify the attacker's chain.
Participation in block witness is optional. But once a miner decided to join the system by including his key in the coinbase, nodes on the network will expect Block witness reports from this miner for the following 2016 blocks. If the miner failed to continuously submitting reports, he will be blacklisted. This will make an attack more difficult because while the attacker is mining a fork secretly, he has to acknowledge the honest fork or his power as witness is lost.
To make it more difficult to cheat, we may have "witness report for block witness report", which eligible miners will timestamp and sign other miners' block witness reports.