user101343: In all of the blockchain samples that I see
e.g. 
adilmoujahid, 
Savjee
 as I checked, they added previous Hash by creating a block.
Suppose that, L is the current last block in a chain. Block A and B are created at the same time. So they set their previous hash with the same hash e.g. Hash of L.
What happens by mining when both of them are mined successfully, but B was mined faster. 
Therefore normally previous hash of B is correct, but previous hash of A should be changed to the hash of B.
What I want to reach, I think assigning previous hash by creating a block is not necessary, but by mining. Am I right?  

user5406: Each block commits to the previous block in the block header by including the previous block's hash. A block's hash is defined as the output of hashing the block header, and for a block to be valid, this hash must fulfill the current difficulty requirement. While blocks can have more than one child block, the Bitcoin network finally agrees on just one best chain. In the best chain there is only one block at each height, so while blocks can have multiple child blocks, only one of them will be relevant in the longterm.

Therefore normally previous hash of B is correct, but previous hash of A should be changed to the hash of B.

Firstly, changing even a single bit in the block header will cause the hash of the block header to come out differently (see e.g. Mastering Bitcoin (Ch8, section "Mining the Block")). It's astronomically unlikely that the new hash also fulfills the difficulty statement. Therefore, the modified block header would no longer represent a valid block.
Secondly, given that A and B were drawing on the same set of unconfirmed transactions when they were found, it's extremely likely that the transactions included in the blocks for confirmation have some overlap. However, each transaction can only be included in one block, because each transaction output can only be spent once, and therefore the inputs of a transaction that was already confirmed are no longer available in a later block. It follows that A would likely include invalid transactions if it were following B.
So, once both A and B were found, and both have each independently committed to block L as their predecessor as well as including some of the same transactions, the blocks A and B are competing to be part of the best chain and exclusive to each other.

user98287: A fork happens. If A and B are competing for the next block, they probably share transactions. So you cannot simply append A to B.
They're both valid blocks, nodes hold both of them until they hear about a new block that was built on top of either A or B. Let's say a node hears a new block C was built on top of B, that node will then disregard A because it isn't a part of the longest/heaviest chain. The transactions in A that are not in B are returned to the mempool to be mined in a new block.
The network reaches consensus by trusting the longest chain. This is why it is suggested to wait 6 confirmations for a transaction. This gives extremely high confidence that the network has reached consensus on your transaction and there is a very low probability that your transaction will be apart of a reorganization of the blockchain.

101343: <p>In all of the blockchain samples that I see
e.g. 
<a href="https://github.com/adilmoujahid/blockchain-python-tutorial.git" rel="nofollow noreferrer">adilmoujahid</a>, 
<a href="https://github.com/Savjee/SavjeeCoin.git" rel="nofollow noreferrer">Savjee</a>
 as I checked, they added previous Hash by creating a block.</p>

<p>Suppose that, L is the current last block in a chain. Block A and B are created at the same time. So they set their previous hash with the same hash e.g. Hash of L.</p>

<p>What happens by mining when both of them are mined successfully, but B was mined faster. </p>

<p>Therefore normally previous hash of B is correct, but previous hash of A should be changed to the hash of B.</p>

<p>What I want to reach, I think assigning previous hash by creating a block is not necessary, but by mining. Am I right?  </p>
 5406: <p>Each block <a href="https://bitcoin.stackexchange.com/q/12427/5406">commits to the previous block</a> in the block header by including the previous block's hash. A block's hash is defined as the output of hashing the block header, and for a block to be valid, this hash must fulfill the current difficulty requirement. While blocks can have more than one child block, the Bitcoin network finally agrees on just one best chain. In the best chain there is only one block at each height, so while blocks can have multiple child blocks, only one of them will be relevant in the longterm.</p>

<blockquote>
  <p>Therefore normally previous hash of B is correct, but previous hash of A should be changed to the hash of B.</p>
</blockquote>

<p>Firstly, changing even a single bit in the block header will cause the hash of the block header to come out differently (see e.g. <a href="https://www.oreilly.com/library/view/mastering-bitcoin/9781491902639/ch08.html" rel="nofollow noreferrer">Mastering Bitcoin (Ch8, section "Mining the Block")</a>). It's astronomically unlikely that the new hash also fulfills the difficulty statement. Therefore, the modified block header would no longer represent a valid block.</p>

<p>Secondly, given that A and B were drawing on the same set of unconfirmed transactions when they were found, it's extremely likely that the transactions included in the blocks for confirmation have some overlap. However, each transaction can only be included in one block, because each transaction output can only be spent once, and therefore the inputs of a transaction that was already confirmed are no longer available in a later block. It follows that A would likely include invalid transactions if it were following B.</p>

<p>So, once both A and B were found, and both have each independently committed to block L as their predecessor as well as including some of the same transactions, the blocks A and B are competing to be part of the best chain and exclusive to each other.</p>
 98287: <p>A fork happens. If A and B are competing for the next block, they probably share transactions. So you cannot simply append A to B.</p>

<p>They're both valid blocks, nodes hold both of them until they hear about a new block that was built on top of either A or B. Let's say a node hears a new block C was built on top of B, that node will then disregard A because it isn't a part of the longest/heaviest chain. The transactions in A that are not in B are returned to the mempool to be mined in a new block.</p>

<p>The network reaches consensus by trusting the longest chain. This is why it is suggested to wait 6 confirmations for a transaction. This gives extremely high confidence that the network has reached consensus on your transaction and there is a very low probability that your transaction will be apart of a reorganization of the blockchain.</p>
