How to prevent a miner from stealing another miner's block?

Question

Many articles only contain a phrasing like

A miner A solves the hash problem and gives the result to the network to check. Once a majority of the network confirms, A gets the reward.

But how does one protect his effort from being stolen? As I think:

1. A solved the problem, so A get original string S which could be hashed to target hash H.
2. A sends his result to the network (some other miners) intending to get the reward.
3. Other nodes (miners) need to hash S and check whether the result equal to H to determine whether A is right or not. (So I think here one can get S and H)
4. But B near A, he get A's works, so he get the S and H. Then he can construct a new result send to others, claim that B solved the problem
5. If B can spread his result faster than A, he gets the reward.

I have seen Can a miner steal another one's block? , in which @Highly Irregular says

The block that Alice mined includes the mining rewards going to Alice's address. If Eve alters the block data to output the rewards to her own receiving address, then the nonce (and other variable values, I think "extranonce" and timestamp) that Alice used to solve the block will almost certainly no longer solve the block.

But he didn't tell how in detail.

@Stéphane Gimenez gave the normal steps of mining here, in which I didn't see a measure to prevent B from stealing the block from A (or how to validate the result is originally calculated by A).

Answer 1

A is protected by adding coinbase transaction with himself's bitcoin address.

from https://en.bitcoin.it/wiki/Block_hashing_algorithm

The body of the block contains the transactions. These are hashed only indirectly through the Merkle root. Because transactions aren't hashed directly, hashing a block with 1 transaction takes exactly the same amount of effort as hashing a block with 10,000 transactions.

The compact format of target is a special kind of floating-point encoding using 3 bytes mantissa, the leading byte as exponent (where only the 5 lowest bits are used) and its base is 256. Most of these fields will be the same for all users. There might be some minor variation in the timestamps. The nonce will usually be different, but it increases in a strictly linear way. "Nonce" starts at 0 and is incremented for each hash. Whenever Nonce overflows (which it does frequently), the extraNonce portion of the generation transaction is incremented, which changes the Merkle root.

Moreover, it is extremely unlikely for two people to have the same Merkle root because the first transaction in your block is a generation "sent" to one of your unique Bitcoin addresses. Since your block is different from everyone else's blocks, you are (nearly) guaranteed to produce different hashes. Every hash you calculate has the same chance of winning as every other hash calculated by the network.

---

Another expalatation from http://www.righto.com/2014/02/bitcoin-mining-hard-way-algorithms.html

The diagram below shows the structure of a specific block, and how it is hashed. The yellow part is the block header, and it is followed by the transactions that go into the block. The first transaction is the special coinbase transaction that grants the mining reward to the miner. The remaining transactions are standard Bitcoin transactions moving bitcoins around. If the hash of the header starts with enough zeros[3], the block is successfully mined. For the block below, the hash is successful: 0000000000000000e067a478024addfecdc93628978aa52d91fabd4292982a50 and the block became block #286819 in the blockchain.

Structure of a Bitcoin block

Answer 2

When a miner solves a block, they must include a Coinbase transaction. The Coinbase transaction is unique in the block and pays out the block reward to the miner's address. In order to redirect the block reward, an attacker would have to change the Coinbase transaction. Since all transactions are committed to via the Merkle tree that resulted in the Merkle root, changing the Coinbase transaction would change the Merkle root. As the Merkle root is part of the block header, this would change the block header and thus the block's hash.

Given the pre-image resistance property of cryptographic hash functions, it's astronomically unlikely that the new block header will also be a valid block.