<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>

CC BY-SA 4.0
2019-12-15T23:00:05.177Z
Blocks are not discarded if they’re not part of the main chain.
Claris
CC BY-SA 4.0
2019-12-16T09:53:10.907Z
@Anonymous when I refer to the stale block A being disregarded, I mean that it simply isn't part of the main chain. I said, "disregarded", because I was not sure what actually happened to it.
Matthew Cruz
CC BY-SA 4.0
2019-12-16T15:02:20.030Z
They’re retained on disk just in case they become part of the main chain, it’s a minor distinction.
Claris
CC BY-SA 4.0
2019-12-17T15:19:16.830Z
@RedGrittyBrick is there a timeout period that addresses how long a node should hold a stale block?
Matthew Cruz
CC BY-SA 4.0
2019-12-17T15:30:25.960Z
@MatthewCruz: I don't know how long stale blocks are retained in memory or on disk for any/all software implementations. The duration probably depends on the particular software that is in use. Some may keep stale blocks on disk forever, others may not. This may also be affected by what pruning options are configured. Obviously software is unlikely to keep a stale block in memory indefinitely. I don't know any reason the Bitcoin network protocol or algorithms would mandate any specific duration for stale blocks in memory nor in persistent storage.
RedGrittyBrick
CC BY-SA 4.0
2019-12-22T09:23:48.970Z
@MatthewCruz ,Do you have any reference for what you said about fork? Fork can be used when we have several branches in chain  they are all valid but they follow different rules(e.g. different)
masoud2011
CC BY-SA 4.0
2019-12-22T09:28:06.470Z
What here I talked about is more like Orphan block, regarding to this page https://www.investopedia.com/terms/o/orphan-block-cryptocurrency.asp, they don't create a fork they will be rejected, or if they are valid transaction they will be added to chain but mine don'receive any reward for them
masoud2011
CC BY-SA 4.0
2019-12-22T11:38:03.227Z
@masoud2011 we’re actually talking about the same thing here and what you said in your first comment is correct. In this scenario it is just a one block fork and is generally resolved after the next block is mined. The fork you’re thinking of is like Bitcoin Cash. The difference is that there are miners building on the new branch, where as just working within Bitcoin’s blockchain the miners will only work on the longest chain (because of the reward).
Matthew Cruz
CC BY-SA 4.0
2019-12-22T11:52:56.233Z
@MatthewCruz that is correct, The blockchain completely is new concept and expression could have not identical meaning. fork and branch could be similar in general meaning but in blockchain concept they refer to different thingshttps://swissborg.com/blog/bitcoin-fork. In my older reference it said orphan block could refer stale block too.https://www.investopedia.com/terms/o/orphan-block-cryptocurrency.asp .
masoud2011
CC BY-SA 4.0
2019-12-22T15:23:43.563Z
@masoud2011 the blockchain is not a new concept. Look up Cipher Block Chaining (CBC) encryption/decryption, this where the idea came from. Also, forks and branches also have historic meaning in computer science, so I wouldn't try and separate blockchain from other topics because they're inherently related.
Matthew Cruz
CC BY-SA 4.0
2019-12-22T15:39:25.667Z
@MatthewCruz Anyway "fork" is a wrong word that you used here. Because when you search for fork in Blockchain you get completely different result as we discuss here.
masoud2011
CC BY-SA 4.0
2019-12-22T18:12:51.117Z
@masoud2011: The term "fork" appears in more than one context in Bitcoin. You can read more about forks here: https://bitcoin.stackexchange.com/q/30817/5406
Murch
CC BY-SA 4.0
2019-12-15T18:31:20.767Z
2019-12-15T18:31:20.767Z
Matthew Cruz
<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>

CC BY-SA 4.0
2019-12-22T12:28:37.207Z
An important problem that I have here, nobody talks with references, what you said here is wrong, please read here https://blog.goodaudience.com/blockchain-for-beginners-what-is-blockchain-519db8c6677a , We create identical hash with data inside the block. But previous hash is part of header of block, and changing in header of block doesn't make any change in hash of block.
masoud2011
CC BY-SA 4.0
2019-12-22T12:38:16.323Z
On the other hand please read here https://99bitcoins.com/bitcoin/mempool/ . Most of the block in memory pool with lower fee will be delayed. Because they are priorities and transactions with more fee have more priority. That means previous hash of most of transaction with lower fee should be changed by mining. Because they should be added after transaction with higher fee, even if previous hash of lower fee is earlier than previous hash of higher fee
masoud2011
CC BY-SA 4.0
2019-12-22T18:05:33.337Z
Hi Masoud, "changing in header of block doesn't make any change in hash of block". Maybe that was a confusing. The block hash is the digest of the block header, so if one changes anything in a block header that block's hash will change and all subsequent blocks also need to change because they referred to that previous header directly or indirectly. (See e.g. Mastering Bitcoin https://www.oreilly.com/library/view/mastering-bitcoin/9781491902639/ch08.html
Murch
CC BY-SA 4.0
2019-12-22T18:09:54.633Z
Transaction hashes are only dependent on the content of the transaction. Mining a transaction doesn't change the transaction (that would invalidate the signature) or the transaction hash. The only thing that changes about the transaction is that it is now being referred to by a block, i.e. it's part of a Merkle tree whose Merkle root is part of a block header that's part of the best chain.
Murch
CC BY-SA 4.0
2019-12-15T21:43:56.183Z
2019-12-22T18:20:50.503Z
2019-12-22T18:20:50.503Z
Murch
<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>

CC BY-SA 4.0
2019-12-16T07:02:57.847Z
Does this answer your question? [What happens if two miners mine the next block at the same time?](https://bitcoin.stackexchange.com/questions/8172/what-happens-if-two-miners-mine-the-next-block-at-the-same-time)
chytrik
CC BY-SA 4.0
2019-12-18T12:58:00.223Z
Thanks to mention that, that helped me to differ my situation from normal blockchain.

I am working on arduino device for health care, that it cannot synch it self every time with main ledger. Because of that, Arduino just sing the data and send it without previous hash to the server. And my server as a miner verify the signature and add the hash of last block as previous hash.

My solution is not proper for shared ledger, but because I am using individual ledger for each member there shouldn't be any conflict between transaction and member data
masoud2011
<block-validity><stale-block>
What happen if some blocks are added simultaneously with same previous hash
masoud2011
# What happen if some blocks are added simultaneously with same previous hash

(Asked by: username_0 on 2019-12-15)

In all of the blockchain samples that I see
e.g.
[adilmoujahid](https://github.com/adilmoujahid/blockchain-python-tutorial.git),
[Savjee](https://github.com/Savjee/SavjeeCoin.git)
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?

**Tags:** block-validity, stale-block

> **Comments:**
> **username_1**: Does this answer your question? [What happens if two miners mine the next block at the same time?](https://bitcoin.stackexchange.com/questions/8172/what-happens-if-two-miners-mine-the-next-block-at-the-same-time)  
> **username_0**: Thanks to mention that, that helped me to differ my situation from normal blockchain.  I am working on arduino device for health care, that it cannot synch it self every time with main ledger. Because of that, Arduino just sing the data and send it without previous hash to the server. And my server as a miner verify the signature and add the hash of last block as previous hash.  My solution is not proper for shared ledger, but because I am using individual ledger for each member there shouldn't be any conflict between transaction and member data  

---

## 2 answers

### Answer by username_2 on 2019-12-15. Score: 4

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.

> **Comments:**
> **username_3**: Blocks are not discarded if they’re not part of the main chain.  
> **username_2**: @Anonymous when I refer to the stale block A being disregarded, I mean that it simply isn't part of the main chain. I said, "disregarded", because I was not sure what actually happened to it.  
> **username_3**: They’re retained on disk just in case they become part of the main chain, it’s a minor distinction.  
> **username_2**: @username_4 is there a timeout period that addresses how long a node should hold a stale block?  
> **username_4**: @username_2: I don't know how long stale blocks are retained in memory or on disk for any/all software implementations. The duration probably depends on the particular software that is in use. Some may keep stale blocks on disk forever, others may not. This may also be affected by what pruning options are configured. Obviously software is unlikely to keep a stale block in memory indefinitely. I don't know any reason the Bitcoin network protocol or algorithms would mandate any specific duration for stale blocks in memory nor in persistent storage.  
> **username_0**: @username_2 ,Do you have any reference for what you said about fork? Fork can be used when we have several branches in chain  they are all valid but they follow different rules(e.g. different)  
> **username_0**: What here I talked about is more like Orphan block, regarding to this page https://www.investopedia.com/terms/o/orphan-block-cryptocurrency.asp, they don't create a fork they will be rejected, or if they are valid transaction they will be added to chain but mine don'receive any reward for them  
> **username_2**: @username_0 we’re actually talking about the same thing here and what you said in your first comment is correct. In this scenario it is just a one block fork and is generally resolved after the next block is mined. The fork you’re thinking of is like Bitcoin Cash. The difference is that there are miners building on the new branch, where as just working within Bitcoin’s blockchain the miners will only work on the longest chain (because of the reward).  
> **username_0**: @username_2 that is correct, The blockchain completely is new concept and expression could have not identical meaning. fork and branch could be similar in general meaning but in blockchain concept they refer to different thingshttps://swissborg.com/blog/bitcoin-fork. In my older reference it said orphan block could refer stale block too.https://www.investopedia.com/terms/o/orphan-block-cryptocurrency.asp .  
> **username_2**: @username_0 the blockchain is not a new concept. Look up Cipher Block Chaining (CBC) encryption/decryption, this where the idea came from. Also, forks and branches also have historic meaning in computer science, so I wouldn't try and separate blockchain from other topics because they're inherently related.  
> **username_0**: @username_2 Anyway "fork" is a wrong word that you used here. Because when you search for fork in Blockchain you get completely different result as we discuss here.  
> **username_5**: @username_0: The term "fork" appears in more than one context in Bitcoin. You can read more about forks here: https://bitcoin.stackexchange.com/q/30817/5406  

---

### Answer by username_5 on 2019-12-15. Score: 3

Each block [commits to the previous block](https://bitcoin.stackexchange.com/q/12427/5406) 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")](https://www.oreilly.com/library/view/mastering-bitcoin/9781491902639/ch08.html)). 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.

> **Comments:**
> **username_0**: An important problem that I have here, nobody talks with references, what you said here is wrong, please read here https://blog.goodaudience.com/blockchain-for-beginners-what-is-blockchain-519db8c6677a , We create identical hash with data inside the block. But previous hash is part of header of block, and changing in header of block doesn't make any change in hash of block.  
> **username_0**: On the other hand please read here https://99bitcoins.com/bitcoin/mempool/ . Most of the block in memory pool with lower fee will be delayed. Because they are priorities and transactions with more fee have more priority. That means previous hash of most of transaction with lower fee should be changed by mining. Because they should be added after transaction with higher fee, even if previous hash of lower fee is earlier than previous hash of higher fee  
> **username_5**: Hi Masoud, "changing in header of block doesn't make any change in hash of block". Maybe that was a confusing. The block hash is the digest of the block header, so if one changes anything in a block header that block's hash will change and all subsequent blocks also need to change because they referred to that previous header directly or indirectly. (See e.g. Mastering Bitcoin https://www.oreilly.com/library/view/mastering-bitcoin/9781491902639/ch08.html  
> **username_5**: Transaction hashes are only dependent on the content of the transaction. Mining a transaction doesn't change the transaction (that would invalidate the signature) or the transaction hash. The only thing that changes about the transaction is that it is now being referred to by a block, i.e. it's part of a Merkle tree whose Merkle root is part of a block header that's part of the best chain.  

---

