without the technical side.
your theory is based on the assumption that the hash is accepted as is and checked if it meets the difficulty.
instead the values you send are run through the client, a hash is produced using the algo of the coin, and if that production matches up the block is valid.
so a sha256 hash matching isn't enough, it'll be invalid.
snipped code:
class CBlockHeader
{
uint256 GetHash() const
{
return Hash9(BEGIN(nVersion), END(nNonce));
}
};
class CBlock : public CBlockHeader
{
uint256 GetPoWHash() const
{
return GetHash();
}
};
(you were looking at the gethash function from transactions, not blocks in your above snip)
How will it be invalid? the target and all underlying block data are the same. when the hash is converted to sha256, how would the hash be accepted but rejected if it is short circuited with sha256?
Because sha256d(blockheader) produces a different result to sha256d(other_hashing_algo(blockheader)).
If you assert that it can produce the same, that'd be a sha256 collission and every crypto program which uses sha256 is screwed.
As I said earlier, the checks you are looking at all assume the hash you send is the one being used, when the hash is reproduced by each client when a block is broadcast. The client will come to a totally different hash that doesn't match the one you specified and just reject the block.
