2

If so, why not do it after (re)broadcast? I think it would cut down on lag time.

  • Since the node would still validate the PoW and the previousblockhash, it would not be possible to DoS the network with invalid headers
  • Miners could begin processing the candidate block from its header and the list of transaction hashes since they already likely have > 90% of those txs.
  • Miners and full-nodes would still only update their head once all the txs are validated.
  • Miners could determine how much time (=money) they are losing by comparing the time they receive the header and the last tx.
3

Do full-nodes process all txs before broadcasting the new blockheader?

It depends. For nodes having protocol version 70015 and higher, the peer will announce the compact block even before full validation of the transactions contained in the block. However, the header has to be conform with the difficulty requirement. For nodes using protocol version 70015 and lower, the blocks are fully processed before broadcast.

Since the node would still validate the PoW and the previousblockhash, it would not be possible to DoS the network with invalid headers

Yes, that is exactly what Bitcoin full nodes do. Whenever you come online, or receive a new block header, the block headers will be verified first to see that it has the required PoW. As you mentioned this does help prevent DoS attacks.

Miners could begin processing the candidate block from its header and the list of transaction hashes since they already likely have > 90% of those txs.

Miners actually do that. Most of them will build and start processing the new block before even verifying the old one so as to not waste any time mining. However, there will be some transactions in that previous block that the miner hadn't seen in the past. Although those transactions will be very few, the miner would not know which UTXOs have been consumed by those transactions.

Thus miners would start building an empty block (containing only the coinbase transaction) on top of the block that they have just received which hasn't been fully verified. After the previous block gets verified in parallel, the miners will then add the unconfirmed valid transactions from the mempool to the block that they are currently mining.

Miners could determine how much time (=money) they are losing by comparing the time they receive the header and the last tx.

As I mentioned above, it is not only the time but also the uncertainty related to what UTXOs have been consumed by the block that had transactions that the miner did not see in the past. As a result miners have to start building an empty block before fully verifying its parent.

However, it is important to note an incident that happened when blocks does not get fully verified. When BIP 66 (strict DER encoding of signatures) was implemented, some miners running the BIP 66 enabled Bitcoin Core versions were listening to pre-BIP 66 pools. One of the pool running a pre-BIP 66 version produced a block that had an incorrect block version number. The miner with BIP 66 started working on top of that unverified block by processing an empty block.

However, their bitcoind never accepted the full block as it was invalid. The result was building a series of empty blocks on top of the other that were ultimately not accepted by the network.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.