<p>Bitcoin-Qt marks outputs as spent in the database once they are spent. To check whether an input's prev-out is spent, Bitcoin just needs to look up the transaction and check whether the output is marked spent.</p>

<p>Other ways of doing it are to have a set of all unspent outputs and check whether the prev-out is in this set (future versions of Bitcoin will do something like this), or to index inputs by their prev-outs.</p>

CC BY-SA 3.0
2013-01-25T00:16:32.733Z
Thanks for clarifying. So the sum of all unspent outputs is the balance for an address?
Philip Frank
CC BY-SA 3.0
2013-01-25T00:19:02.063Z
@bananer Yes, that's right.
theymos
CC BY-SA 3.0
2013-01-25T02:41:44.297Z
Where does this appear in the code?
Kinnard Hockenhull
CC BY-SA 3.0
2013-01-25T04:52:16.580Z
@KinnardHockenhull For 0.7.x and below, search for *vSpent*.
theymos
CC BY-SA 3.0
2013-01-25T09:59:08.707Z
So I imagine there is some sort of hashtable indexed on the transaction hash, with some flag indicating if it was spent.
Flavien
CC BY-SA 3.0
2013-01-25T00:05:22.117Z
2013-01-25T00:11:47.167Z
2013-01-25T00:11:47.167Z
theymos
<p>It is similar to the question <a href="https://bitcoin.stackexchange.com/questions/53217/how-does-spv-prevent-double-spending-of-utxo">here</a></p>

<p>Suppose A, a peer, receives 'B' BTCs from various transactions: B1,B2,B3, etc. Also, A had spent 'S' BTCs in various transactions S1,S2,S3, etc. Now, whenever a new transaction is initiated from A to C (eg: A wants to transfer X bitcoins to C), the transaction has to be verified as follows.</p>

<ol>
<li>The full nodes have the UTXO (Unspent Transaction) details. The full nodes go through this UTXO database and verify if S1,S2,S3 are unspent or not. UTXO's size is around 512 MB. So, not difficult to go through all of the UTXO.</li>
<li>Verification can also be done via SPV nodes, a lightweight client. These SPV nodes do not have the UTXO details. However, they have the header information of the entire blockchain. So, a new transaction is initiated, SPV client requests the full node to give information of the S1,S2,S3 transactions. Full node gives this information in the form of Merkel Trees. SPV node verifies the validity of these Merkel trees using the blockchain header info. The blockchain header would not change for all the transactions which are 'old enough'. As a conservative rule, people usually wait for at least 6 more blocks to be built on top of this present block, before delivering their goods or service.     </li>
</ol>

<p>Please refer to this <a href="https://www.cryptocoinsnews.com/bitcoin-transaction-really-works/" rel="nofollow noreferrer">link</a> as well-  Good article on how individual transactions are processed.</p>

CC BY-SA 3.0
2017-05-12T04:01:42.617Z
2017-05-12T04:01:42.617Z
honeybadger
<p>When the Bitcoin client looks at the input of a transaction, it know the hash of the previous transaction from which the funds are coming, however then, how does it know that this output has not been spent already? Does it need to scan the whole blocklist for another transaction spending that same output? Isn't that very inefficient?</p>

<blockchain><protocol><doublespend>
How does the Bitcoin client check for double spend?
Flavien
# How does the Bitcoin client check for double spend?

(Asked by: username_0 on 2013-01-24)

When the Bitcoin client looks at the input of a transaction, it know the hash of the previous transaction from which the funds are coming, however then, how does it know that this output has not been spent already? Does it need to scan the whole blocklist for another transaction spending that same output? Isn't that very inefficient?

**Tags:** blockchain, protocol, doublespend


---

## 2 answers

### Answer by username_1 on 2013-01-25. Score: 3 | Accepted answer

Bitcoin-Qt marks outputs as spent in the database once they are spent. To check whether an input's prev-out is spent, Bitcoin just needs to look up the transaction and check whether the output is marked spent.

Other ways of doing it are to have a set of all unspent outputs and check whether the prev-out is in this set (future versions of Bitcoin will do something like this), or to index inputs by their prev-outs.

> **Comments:**
> **username_2**: Thanks for clarifying. So the sum of all unspent outputs is the balance for an address?  
> **username_1**: @bananer Yes, that's right.  
> **username_3**: Where does this appear in the code?  
> **username_1**: @username_3 For 0.7.x and below, search for *vSpent*.  
> **username_0**: So I imagine there is some sort of hashtable indexed on the transaction hash, with some flag indicating if it was spent.  

---

### Answer by username_4 on 2017-05-12. Score: 0

It is similar to the question [here](https://bitcoin.stackexchange.com/questions/53217/how-does-spv-prevent-double-spending-of-utxo)

Suppose A, a peer, receives 'B' BTCs from various transactions: B1,B2,B3, etc. Also, A had spent 'S' BTCs in various transactions S1,S2,S3, etc. Now, whenever a new transaction is initiated from A to C (eg: A wants to transfer X bitcoins to C), the transaction has to be verified as follows.

1. The full nodes have the UTXO (Unspent Transaction) details. The full nodes go through this UTXO database and verify if S1,S2,S3 are unspent or not. UTXO's size is around 512 MB. So, not difficult to go through all of the UTXO.
2. Verification can also be done via SPV nodes, a lightweight client. These SPV nodes do not have the UTXO details. However, they have the header information of the entire blockchain. So, a new transaction is initiated, SPV client requests the full node to give information of the S1,S2,S3 transactions. Full node gives this information in the form of Merkel Trees. SPV node verifies the validity of these Merkel trees using the blockchain header info. The blockchain header would not change for all the transactions which are 'old enough'. As a conservative rule, people usually wait for at least 6 more blocks to be built on top of this present block, before delivering their goods or service.

Please refer to this [link](https://www.cryptocoinsnews.com/bitcoin-transaction-really-works/) as well- Good article on how individual transactions are processed.


---

