<p>Miners submit new blocks to a few nearby nodes in the Bitcoin network. Nodes include wallets and miners. Every node checks the block follows a set of rules known as the Bitcoin consensus rules. If the blocks meet those rules they are passed on to other nearby nodes and soon reach the entire network.</p>
<p>One of those rules is that a transaction may not spend money that has already been spent. This is called double-spending.</p>
<p>It can happen that two similar blocks are produced at about the same time and two different groups of nodes each see one or other of these first. This is called a blockchain fork. Eventually other miners will succeed in creating new blocks on one or other of these and one will have a greater amount of a metric called &quot;work&quot;. Nodes then abandon the weaker fork and accept the stronger one.</p>
<p>There are other questions which cover some of this further:</p>
<ul>
<li><p><a href="https://bitcoin.stackexchange.com/search?q=blockchain+fork+is%3Aq">Fork</a></p>
<ul>
<li><a href="https://bitcoin.stackexchange.com/q/8172/13866">What happens if two miners mine the next block at the same time?</a></li>
<li><a href="https://bitcoin.stackexchange.com/q/79646/13866">When does a blockchain fork resolution happen?</a></li>
<li><a href="https://bitcoin.stackexchange.com/q/3343/13866">What is the longest blockchain fork that has been orphaned to date?</a></li>
<li><a href="https://bitcoin.stackexchange.com/q/92183/13866">How does the blockchain prevent spending money during a &quot;short fork&quot;?</a></li>
</ul>
</li>
<li><p><a href="https://bitcoin.stackexchange.com/search?q=double+spend">Double spend</a></p>
<ul>
<li><a href="https://bitcoin.stackexchange.com/q/4974/13866">What is a double spend?</a></li>
<li><a href="https://bitcoin.stackexchange.com/q/101827/13866">Would first-seen prevent a double spend attack?</a></li>
</ul>
</li>
</ul>

CC BY-SA 4.0
2021-02-14T10:55:23.500Z
Thanks explaining the fork, because that is something I was wondering about as well. What if two valid blocks at the same time are produced that may seem to be valid for groups of nodes. Then I have one more question about this. If fork happens what about the transactions that were left in the abandoned branch? Do they need to be resubmitted? It is possible that the answer is on the links you provided but I will look into those later. Thanks!
Eduard
CC BY-SA 4.0
2021-02-14T11:44:58.363Z
@Eduard, no those transactions don't need to be resubmitted by their original creators. I believe they just get put back into the mempool and then will be added to a new block by a miner a short while later. This is something that happens and gets taken care of without anyone really noticing there was a hiccup.
RedGrittyBrick
CC BY-SA 4.0
2021-02-15T08:20:35.207Z
that makes sense that this is possible, Im just imagining if there would be a small bug or intention to hurt the network, then that would be quite possible to see some big issues. I guess that the network is build on trust and also people have so much money in it that no miner running the full node wants to hurt the network now-days.
Eduard
CC BY-SA 4.0
2021-02-15T09:31:26.027Z
@Eduard  Bitcoin is not built on trust. It  is designed so that one person can send money to another without ever having to trust a third party, you never have to trust miners or any other intermediary nodes
RedGrittyBrick
CC BY-SA 4.0
2021-02-15T11:25:44.897Z
I guess it is hard for me to imagine that if somebody couldn't create a node that slightly changes consesnus rules to their advantege. I think I will have to read more about validation rules and consensus algorythm.
Eduard
CC BY-SA 4.0
2021-02-15T11:31:50.647Z
@Eduard: See [How exactly are Bitcoin's consensus rules enforced?](https://bitcoin.stackexchange.com/q/61759/13866)
RedGrittyBrick
CC BY-SA 4.0
2021-02-14T08:53:41.423Z
2021-02-15T11:34:59.723Z
2021-02-15T11:34:59.723Z
RedGrittyBrick
<p>First of all let's discuss what would happen if a block indeed contains a transaction that was already included in the chain:</p>
<p>All full nodes validate all blocks, and will not accept a block with any invalid transaction in it. If a transaction is repeated, it means its inputs are already spent by the first instance. The second one will thus be considered a double spend, and regarded as invalid, which by extension means the entire block in which it was included the second time is invalid. Thus, the entire block will simply be ignores by the network.</p>
<p>This means miners have a <em>very</em> strong incentive to not do this. It doesn't really matter how they do this, but if they risk including a transaction twice, they'd lose the entire reward (subsidy + fee) from that block if they'd win it.</p>
<p>Turns out, it doesn't need much to prevent it, and arguably with existing software it is much harder to do include duplicates than not. Recall that every block needs to contain the hash of its parent block. This means the miner needs to be informed of that parent block first, and gets to see it. A new block tenplate (with transaction selection) can't be constructed before the previous block is known. Since building on top of an invalid block is also invalid, software will also validate that new parent when it comes in. As a side effect, it knows about its transactions, and thus knows what a successor block is allowed to contain (which excludes duplicates of course, but also other forms of double spending).</p>
<p>There is sort of a shortcut that is sometimes taken in practice. When a new block is found, miners may learn about its existence faster than that its validation nodes have learned and processed the full block. In this case, a miner may instruct its hashers to temporarily switch to mining on top of an empty block (which is certainly valid). When the new parent is fully procsssed, hashers get an upgraded template with actual transactions. This can be dangerous, and has caused a significant fork of empty blocks building on top of an invalid block, around the time BIP66 activated.</p>

CC BY-SA 4.0
2021-02-14T08:50:53.457Z
2021-02-14T08:50:53.457Z
Pieter Wuille
<p>Assuming that there is multiple miners in the network that have access to the same transactions that were submitted by users. How does Bitcoin network prevent from accidentally including the same transaction into different blockchain blocks? Im thinking that if multiple miners successfully mine new block at the same time (very close), the notification that some transactions were included in a block might not have propagated to others soon enough. Could this race condition cause some issues in blockchain or is this allowed to happen and then duplicate transactions are simply ignored?</p>

<bitcoin-core><currencies>
How Does Bitcoin network prevent from the same transaction being included multiple time in a block
Eduard
# How Does Bitcoin network prevent from the same transaction being included multiple time in a block

(Asked by: username_0 on 2021-02-14)

Assuming that there is multiple miners in the network that have access to the same transactions that were submitted by users. How does Bitcoin network prevent from accidentally including the same transaction into different blockchain blocks? Im thinking that if multiple miners successfully mine new block at the same time (very close), the notification that some transactions were included in a block might not have propagated to others soon enough. Could this race condition cause some issues in blockchain or is this allowed to happen and then duplicate transactions are simply ignored?

**Tags:** bitcoin-core, currencies


---

## 2 answers

### Answer by username_1 on 2021-02-14. Score: 2

Miners submit new blocks to a few nearby nodes in the Bitcoin network. Nodes include wallets and miners. Every node checks the block follows a set of rules known as the Bitcoin consensus rules. If the blocks meet those rules they are passed on to other nearby nodes and soon reach the entire network.

One of those rules is that a transaction may not spend money that has already been spent. This is called double-spending.

It can happen that two similar blocks are produced at about the same time and two different groups of nodes each see one or other of these first. This is called a blockchain fork. Eventually other miners will succeed in creating new blocks on one or other of these and one will have a greater amount of a metric called "work". Nodes then abandon the weaker fork and accept the stronger one.

There are other questions which cover some of this further:

* [Fork](https://bitcoin.stackexchange.com/search?q=blockchain+fork+is%3Aq)

  + [What happens if two miners mine the next block at the same time?](https://bitcoin.stackexchange.com/q/8172/13866)
  + [When does a blockchain fork resolution happen?](https://bitcoin.stackexchange.com/q/79646/13866)
  + [What is the longest blockchain fork that has been orphaned to date?](https://bitcoin.stackexchange.com/q/3343/13866)
  + [How does the blockchain prevent spending money during a "short fork"?](https://bitcoin.stackexchange.com/q/92183/13866)
* [Double spend](https://bitcoin.stackexchange.com/search?q=double+spend)

  + [What is a double spend?](https://bitcoin.stackexchange.com/q/4974/13866)
  + [Would first-seen prevent a double spend attack?](https://bitcoin.stackexchange.com/q/101827/13866)

> **Comments:**
> **username_0**: Thanks explaining the fork, because that is something I was wondering about as well. What if two valid blocks at the same time are produced that may seem to be valid for groups of nodes. Then I have one more question about this. If fork happens what about the transactions that were left in the abandoned branch? Do they need to be resubmitted? It is possible that the answer is on the links you provided but I will look into those later. Thanks!  
> **username_1**: @username_0, no those transactions don't need to be resubmitted by their original creators. I believe they just get put back into the mempool and then will be added to a new block by a miner a short while later. This is something that happens and gets taken care of without anyone really noticing there was a hiccup.  
> **username_0**: that makes sense that this is possible, Im just imagining if there would be a small bug or intention to hurt the network, then that would be quite possible to see some big issues. I guess that the network is build on trust and also people have so much money in it that no miner running the full node wants to hurt the network now-days.  
> **username_1**: @username_0  Bitcoin is not built on trust. It  is designed so that one person can send money to another without ever having to trust a third party, you never have to trust miners or any other intermediary nodes  
> **username_0**: I guess it is hard for me to imagine that if somebody couldn't create a node that slightly changes consesnus rules to their advantege. I think I will have to read more about validation rules and consensus algorythm.  
> **username_1**: @username_0: See [How exactly are Bitcoin's consensus rules enforced?](https://bitcoin.stackexchange.com/q/61759/13866)  

---

### Answer by username_2 on 2021-02-14. Score: 2

First of all let's discuss what would happen if a block indeed contains a transaction that was already included in the chain:

All full nodes validate all blocks, and will not accept a block with any invalid transaction in it. If a transaction is repeated, it means its inputs are already spent by the first instance. The second one will thus be considered a double spend, and regarded as invalid, which by extension means the entire block in which it was included the second time is invalid. Thus, the entire block will simply be ignores by the network.

This means miners have a *very* strong incentive to not do this. It doesn't really matter how they do this, but if they risk including a transaction twice, they'd lose the entire reward (subsidy + fee) from that block if they'd win it.

Turns out, it doesn't need much to prevent it, and arguably with existing software it is much harder to do include duplicates than not. Recall that every block needs to contain the hash of its parent block. This means the miner needs to be informed of that parent block first, and gets to see it. A new block tenplate (with transaction selection) can't be constructed before the previous block is known. Since building on top of an invalid block is also invalid, software will also validate that new parent when it comes in. As a side effect, it knows about its transactions, and thus knows what a successor block is allowed to contain (which excludes duplicates of course, but also other forms of double spending).

There is sort of a shortcut that is sometimes taken in practice. When a new block is found, miners may learn about its existence faster than that its validation nodes have learned and processed the full block. In this case, a miner may instruct its hashers to temporarily switch to mining on top of an empty block (which is certainly valid). When the new parent is fully procsssed, hashers get an upgraded template with actual transactions. This can be dangerous, and has caused a significant fork of empty blocks building on top of an invalid block, around the time BIP66 activated.


---

