<blockquote>
<p>if I imagine to work with isolated transactions chained each other according to money flow, then i understand that we wish to have a single chain because forks would mean the presence of double-spend attempt.</p>
</blockquote>
<p>The purpose of the blockchain is to enforce this. It is cheap to make conflicting transactions - the sender of a transaction can trivially double spend themselves. The blockchain serves as a method to determine which of those &quot;forks&quot; of the transaction graph is the &quot;correct&quot; one. The fact that it does so through batches of transactions doesn't matter, it resolves the same issue for all transactions included. Forks in the blockchain allow for conflicting transactions to enter the blockchain and be considered the &quot;correct&quot; transaction.</p>

CC BY-SA 4.0
2023-04-23T19:34:50.723Z
Thank you for the answer. Is it wrong to say that ,from the point of view of a merchant who receives a payment for example, forks are informative of the fact that some nodes refuse some transaction within that orphane block and that it should be wiser to wait ,before accepting payment and provide goods,until a confirmation (i.e. it belongs to a longest chain) ? But ,rejecting a block (leaving it orphan) implies that also valid transactions become invalid ones. Can this represent a problem or is it an unavoidable collateral effect of granting this kind of security ? Thank you
loremas89
CC BY-SA 4.0
2023-05-23T15:04:59.573Z
@loremaster: follow-on questions are better asked as new questions. They can refer back to an earlier question if needed. 
[**Like this**](https://bitcoin.stackexchange.com/q/118432/13866). This is because this website intends to be a permanent easily searched repository of good, durable answers to specific problems. That goal is thwarted if we treat it as a discussion.
RedGrittyBrick
CC BY-SA 4.0
2023-06-02T18:58:43.960Z
@RedGrittyBrick thank you for the suggestion
loremas89
CC BY-SA 4.0
2023-04-23T15:19:43.497Z
2023-04-23T15:19:43.497Z
Ava Chow
<p>The whole point of Bitcoin’s proof of work is to converge on a single transaction order. Each block has to be consistent within itself and with its entire history of predecessors. Each transaction output can only be spent once in a valid transaction ordering, so having a single canonical transaction order solves the doublespending problem.</p>
<p>Two competing blocks at the same height usually contain overlapping sets of transactions. They may also contain conflicting transactions that spend some of the same transaction outputs to different recipients. In that case, the network has not yet settled which of the competing transactions will be contained in the best chain. Only when one of the two blocks is buried by significantly more proof of work than the other (e.g. one chaintip has no succeeding blocks, the other is followed by ten more blocks) there is a strong probabilistic argument that the transactions confirmed in the block that is part of the heavier chain are reliable.</p>
<p>When a Bitcoin-style blockchain has frequent forks, it means that first confirmations are generally unreliable, and users should wait for more confirmations before being confident that they got paid.</p>

CC BY-SA 4.0
2023-06-02T18:56:17.620Z
Thank you a lot
loremas89
CC BY-SA 4.0
2023-05-23T14:42:08.907Z
2023-05-23T15:47:21.240Z
2023-05-23T15:47:21.240Z
Murch
<p>To be more specific, if I imagine to work with isolated transactions chained to each other according to money flow, then I understand that we wish to have a single chain because forks would mean the presence of double-spend attempts.</p>
<p>But blocks actually are an aggregate of transactions happened in a certain window of time, so I find hard to understand the necessity of not having forks in a chain of blocks. Are transaction chains and block chains two very different things with different purposes?  What I understood is that the first has the goal to order temporally the transactions while the second serves to make tamper proof the ledger by incorporating hashes of a block in another one.</p>
<p>In my mental model the time ordering goal is already reached by the transactions data structure itself while the chain of blocks has the (only) purpose of making tamper proof the structure. What am I not understanding?</p>

<transactions><blockchain><blockchain-fork><doublespend><best-chain>
Why is not good having forks in a blockchain?
loremas89
# Why is not good having forks in a blockchain?

(Asked by: username_0 on 2023-04-23)

To be more specific, if I imagine to work with isolated transactions chained to each other according to money flow, then I understand that we wish to have a single chain because forks would mean the presence of double-spend attempts.

But blocks actually are an aggregate of transactions happened in a certain window of time, so I find hard to understand the necessity of not having forks in a chain of blocks. Are transaction chains and block chains two very different things with different purposes? What I understood is that the first has the goal to order temporally the transactions while the second serves to make tamper proof the ledger by incorporating hashes of a block in another one.

In my mental model the time ordering goal is already reached by the transactions data structure itself while the chain of blocks has the (only) purpose of making tamper proof the structure. What am I not understanding?

**Tags:** transactions, blockchain, blockchain-fork, doublespend, best-chain


---

## 2 answers

### Answer by username_1 on 2023-04-23. Score: 6

> if I imagine to work with isolated transactions chained each other according to money flow, then i understand that we wish to have a single chain because forks would mean the presence of double-spend attempt.

The purpose of the blockchain is to enforce this. It is cheap to make conflicting transactions - the sender of a transaction can trivially double spend themselves. The blockchain serves as a method to determine which of those "forks" of the transaction graph is the "correct" one. The fact that it does so through batches of transactions doesn't matter, it resolves the same issue for all transactions included. Forks in the blockchain allow for conflicting transactions to enter the blockchain and be considered the "correct" transaction.

> **Comments:**
> **username_0**: Thank you for the answer. Is it wrong to say that ,from the point of view of a merchant who receives a payment for example, forks are informative of the fact that some nodes refuse some transaction within that orphane block and that it should be wiser to wait ,before accepting payment and provide goods,until a confirmation (i.e. it belongs to a longest chain) ? But ,rejecting a block (leaving it orphan) implies that also valid transactions become invalid ones. Can this represent a problem or is it an unavoidable collateral effect of granting this kind of security ? Thank you  
> **username_2**: @loremaster: follow-on questions are better asked as new questions. They can refer back to an earlier question if needed.  [**Like this**](https://bitcoin.stackexchange.com/q/118432/13866). This is because this website intends to be a permanent easily searched repository of good, durable answers to specific problems. That goal is thwarted if we treat it as a discussion.  
> **username_0**: @username_2 thank you for the suggestion  

---

### Answer by username_3 on 2023-05-23. Score: 3

The whole point of Bitcoin’s proof of work is to converge on a single transaction order. Each block has to be consistent within itself and with its entire history of predecessors. Each transaction output can only be spent once in a valid transaction ordering, so having a single canonical transaction order solves the doublespending problem.

Two competing blocks at the same height usually contain overlapping sets of transactions. They may also contain conflicting transactions that spend some of the same transaction outputs to different recipients. In that case, the network has not yet settled which of the competing transactions will be contained in the best chain. Only when one of the two blocks is buried by significantly more proof of work than the other (e.g. one chaintip has no succeeding blocks, the other is followed by ten more blocks) there is a strong probabilistic argument that the transactions confirmed in the block that is part of the heavier chain are reliable.

When a Bitcoin-style blockchain has frequent forks, it means that first confirmations are generally unreliable, and users should wait for more confirmations before being confident that they got paid.

> **Comments:**
> **username_0**: Thank you a lot  

---

