<p>In Bitcoin, each full node follows all transaction activity on the network by digesting the blockchain. To that end, every full node enforces their ruleset on the data that they receive. As (usually) the full nodes all follow the same ruleset, every node indivdually converges on the same state.<br>
Hereby, the blockchain's transaction data represents a journal of the activity, which if digested according to Bitcoin rules yields a ledger of all balances at the current blockchain tip, the <em>Unspent Transaction Output Set (UTXO Set)</em>.</p>

<p>Every full node maintains this complete set of UTXOs. Each UTXO is uniquely identifiablee by the transaction it was created in, and the position in that transaction's output list.</p>

<p>When a transaction is confirmed, the UTXOs in the transaction inputs get spent and removed from the UTXO set, while the transaction's outputs in turn get added to the UTXO set. If someone tries to replay the same transaction again, the referenced inputs are no longer in the UTXO Set as they were previously removed and the transaction is just as easily identified to be invalid as a transaction spending made-up UTXOs.</p>

CC BY-SA 3.0
2017-10-02T21:41:27.650Z
Thanks. So the UTXO set must be rather large? A look on http://statoshi.info/dashboard/db/unspent-transaction-output-set suggests that there are 22,500,000 unspent transaction outputs? and this all has to be searched in order to validate a block?
Roger
CC BY-SA 3.0
2017-10-02T21:43:19.600Z
Would distributing coins to a large number of addresses serve to increase the UTXO set, and gathering coins into a single address reduce the UTXO set?
Roger
CC BY-SA 3.0
2017-10-02T23:14:01.147Z
Yes, sounds about right. Searching 22.5M UTXO is fast if you put them into an adequate data structure. If you meant sending into a single UTXO in one address, yes on both counts.
Murch
CC BY-SA 3.0
2018-04-06T21:26:50.910Z
So UTXO is another data set, different from the blockchain, right? How is consensus over UTXO reached?
Mark Neuhaus
CC BY-SA 3.0
2018-04-07T18:38:21.803Z
@MarkNeuhaus: I've improved my answer to better explain your follow-up question.
Murch
CC BY-SA 3.0
2017-10-02T04:53:51.120Z
2018-04-07T18:38:01.420Z
2018-04-07T18:38:01.420Z
Murch
<p>As I understand it, a transaction basically consists of a <code>from address</code>, <code>to address</code>, <code>amount</code> and some component that verifies that the owner of the <code>from_address</code> has requested the transaction. A transaction is broadcast to the network in the hope that it will get included into a freshly mined block.</p>

<p>If the miner can choose which transactions to add to a block. How does the Bitcoin protocol stop a miner from re-adding an existing transaction to the chain? and thus recreating the transaction and doubling the effect of the transaction.</p>

<p>Surely it is not feasible to search the entire transaction history to make sure the transaction hasn't already been included.</p>

<p>EDIT - from a bit of further research, it looks like including a confirmed transaction will render a block invalid and it will be rejected by other Bitcoin nodes. But how can you determine if the block contained an already confirmed transaction in an efficient way?</p>

<transactions><protocol><mining-theory>
What prevents a transaction being added to the block chain twice?
Roger
# What prevents a transaction being added to the block chain twice?

(Asked by: username_0 on 2017-10-01)

As I understand it, a transaction basically consists of a `from address`, `to address`, `amount` and some component that verifies that the owner of the `from_address` has requested the transaction. A transaction is broadcast to the network in the hope that it will get included into a freshly mined block.

If the miner can choose which transactions to add to a block. How does the Bitcoin protocol stop a miner from re-adding an existing transaction to the chain? and thus recreating the transaction and doubling the effect of the transaction.

Surely it is not feasible to search the entire transaction history to make sure the transaction hasn't already been included.

EDIT - from a bit of further research, it looks like including a confirmed transaction will render a block invalid and it will be rejected by other Bitcoin nodes. But how can you determine if the block contained an already confirmed transaction in an efficient way?

**Tags:** transactions, protocol, mining-theory


---

## 1 answers

### Answer by username_1 on 2017-10-02. Score: 4 | Accepted answer

In Bitcoin, each full node follows all transaction activity on the network by digesting the blockchain. To that end, every full node enforces their ruleset on the data that they receive. As (usually) the full nodes all follow the same ruleset, every node indivdually converges on the same state.  
Hereby, the blockchain's transaction data represents a journal of the activity, which if digested according to Bitcoin rules yields a ledger of all balances at the current blockchain tip, the *Unspent Transaction Output Set (UTXO Set)*.

Every full node maintains this complete set of UTXOs. Each UTXO is uniquely identifiablee by the transaction it was created in, and the position in that transaction's output list.

When a transaction is confirmed, the UTXOs in the transaction inputs get spent and removed from the UTXO set, while the transaction's outputs in turn get added to the UTXO set. If someone tries to replay the same transaction again, the referenced inputs are no longer in the UTXO Set as they were previously removed and the transaction is just as easily identified to be invalid as a transaction spending made-up UTXOs.

> **Comments:**
> **username_0**: Thanks. So the UTXO set must be rather large? A look on http://statoshi.info/dashboard/db/unspent-transaction-output-set suggests that there are 22,500,000 unspent transaction outputs? and this all has to be searched in order to validate a block?  
> **username_0**: Would distributing coins to a large number of addresses serve to increase the UTXO set, and gathering coins into a single address reduce the UTXO set?  
> **username_1**: Yes, sounds about right. Searching 22.5M UTXO is fast if you put them into an adequate data structure. If you meant sending into a single UTXO in one address, yes on both counts.  
> **username_2**: So UTXO is another data set, different from the blockchain, right? How is consensus over UTXO reached?  
> **username_1**: @username_2: I've improved my answer to better explain your follow-up question.  

---

