> For efficiency sake nodes validate the header values first.
Makes sense. Thanks.
Topic: Why is there a target field in block headers? (Read 723 times)
Nodes don't rely on the target value so in theory it could be removed however it does allow nodes to identify bad blocks quicker. If your node receives a relayed block which has a different target than what it is expecting then the block is invalid and validation can stop. IIRC at one time altcoin pump and dumpers didn't even have enough skill to realize they needed to change the magic values and ports to ensure the chain will be independent from bitcoin so the clients would be relaying blocks that are simply invalid for the Bitcoin network.
Technically that you are right it isn't needed and it shouldn't be relied upon. For efficiency sake nodes validate the header values first. If they are invalid the block is invalid. They validate the tx set next. If any tx is invalid the block is invalid. The merkle tree is constructed next. If the computed merkle tree root hash doesn't match the root hash in the header then the block is invalid. Finally only after all that validation is complete the node will hash the header and ensure it produces a hash below the target. The block is now valid and will be relayed to other peers.
Technically that you are right it isn't needed and it shouldn't be relied upon. For efficiency sake nodes validate the header values first. If they are invalid the block is invalid. They validate the tx set next. If any tx is invalid the block is invalid. The merkle tree is constructed next. If the computed merkle tree root hash doesn't match the root hash in the header then the block is invalid. Finally only after all that validation is complete the node will hash the header and ensure it produces a hash below the target. The block is now valid and will be relayed to other peers.
Oh, now I understand. Not sure, but:
1) nBits (=target) in block header is stored on disc and verified when loading, you do not want to go all way back
2) there might be some interesting problems when you try to calculate nBits "on the fly" when there are reorgs of chains near the difficulty retarget
thus, it is probably better to keep the value in the header anyway. If there is another, more important reason, I would like to know it, too.
1) nBits (=target) in block header is stored on disc and verified when loading, you do not want to go all way back
2) there might be some interesting problems when you try to calculate nBits "on the fly" when there are reorgs of chains near the difficulty retarget
thus, it is probably better to keep the value in the header anyway. If there is another, more important reason, I would like to know it, too.
Yes, I do not see why it should exist. With 293000 blocks so far, 293000*4=1.17MB is wasted. Not much, but I can't see why
Sure, I know that. I know what the target is and how it is computed.
What I wonder is why is the target is stored in block headers when it should be calculated independently by verifiers? Seems like redundant information at best and a potential pitfall for naive client implementations at worse.
What I wonder is why is the target is stored in block headers when it should be calculated independently by verifiers? Seems like redundant information at best and a potential pitfall for naive client implementations at worse.
There are strict rules how the target is calculated, so miners cannot fake the target, otherwise the block is invalid.
For example, inside the 2016 window of the same difficulty, the target must match the previous one. On the boundaries, rules for adjusting the difficulty applies.
For example, inside the 2016 window of the same difficulty, the target must match the previous one. On the boundaries, rules for adjusting the difficulty applies.
Block headers have a `bits` field representing the target at the time a block was mined (according to the Bitcoin wiki). Obviously, clients cannot trust this field as a malicious miner could simply set an easy target, rendering the PoW meaningless. What is the purpose of having a target field in block headers if it cannot be trusted?
Jump to: