<p>This is already done, somewhat implicitly.</p>

<p>As a bitcoin node syncs, it constantly updates a utxo database. For each block, it removes all utxos consumed in that block, and adds all new ones created.</p>

<p>As a result, once the node has synced, it has a full list of all unspent utxos. </p>

<p>When a new transaction is processes, the node only needs to check this database for utxo validity - if the utxo is in the database, it has not been spent. If it is not, it has either already been spent, or never existed to begin with.</p>

CC BY-SA 4.0
2019-09-24T08:43:25.027Z
Thanks for kind replying :)

Are you Bitcoin core developer? (because you said "somewhat implicitly")

Where can I find the material(please give a web link) that you said ?
Hyunsoo
CC BY-SA 4.0
2019-09-24T09:18:44.133Z
I don't work on the BItcoin project, but I work in the space. There are probably a few articles out there describing this in more detail, but I don't know any off the top of my head to recommend. @RedGrittyBrick goes into some more detail in his answer.
Raghav Sood
CC BY-SA 4.0
2019-09-24T07:58:47.980Z
2019-09-24T07:58:47.980Z
Raghav Sood
<blockquote>
  <p><strong>How Bitcoin dose find and verify UTXO?</strong></p>
</blockquote>

<p>By Bitcoin, I think you must mean "Bitcoin core" - the Bitcoin wallet software derived from the original reference implementation by Satoshi Nakamoto. The word Bitcoin also encompasses the specific set of concepts outlined in the Bitcoin whitepaper, the network protocol definitions, the Bitcoin improvement proposals (BIPS), the worldwide network of Bitcoin nodes and Bitcoin users, etc.</p>

<p>How Bitcoin core manages UTXOs is probably best answered by inspecting the source code. I can however make some guesses, which even if wrong will show that the issue which concerns you is a non-issue.</p>

<p>Bitcoin core maintains several sets of data files. One of these is the wallet.dat file. Another set is the blockchain data itself, represented in a series of files. There may be other sets of data.</p>

<blockquote>
  <p><strong>I know that blockchain is never modified any previous block</strong></p>
</blockquote>

<p>Yes, but that does not mean that some Bitcoin software has to have a persistent storage format that exactly follows the over-the-network blockchain block layout. The software could store the data in a normalised SQL database and only reconstruct the blocks when it needs to re-verify the hashes, signatures etc - which would normally only be needed to be verified once when the block is first received. Such a data storage arrangement would allow lots of additional fields and associated tables to store extra information such as a flag showing whether a TXO had been subsequently spent (hence no longer a <em>U</em>TXO). Alternatively the Blockchain data could be stored in files exactly as received and ancilliary files used to store additional indexes of block-numbers and transaction-IDs associated with addresses of interest or a table of UTXOs that are added to and deleted from as blocks arrive and are verified and processed.</p>

<blockquote>
  <p><strong>it must check all the blocks to see whether TXO(reference to UTXO) is existed or not.</strong></p>
</blockquote>

<p>No, it only needs to check each block once. After that it can consult an efficient index into a separate small efficient table of <em>current</em> UTXOs which it maintains independently of the actual blockchain data.</p>

<blockquote>
  <p><strong>I have a good idea. that is we should mark something in the UTXO</strong></p>
</blockquote>

<p>Effectively this is already done. Except that most likely the mark is not made in a copy of the blockchain block structure but in separate data structures that Bitcoin core maintains for this purpose.</p>

<p>There is no need to alter the agreed Blockchain data structure that is used to transmit blocks between nodes.</p>

<p>It is not necessary for any node's software (wallet or not) to store Blockchain blocks at all, especially not SPV wallets. They are all free to choose any internal storage implementation and formats that their designers feel addresses their goals.</p>

<p>Nodes may need to be able to transmit to other nodes, requested blocks that they have previously received. But this could be achieved by reconstructing blocks from other, completely different and more comprehensive, storage formats.</p>

<blockquote>
  <p><strong>I would like to discuss about my point.</strong></p>
</blockquote>

<p>Please note that this is a Q&amp;A website not a discussion forum. Try our <a href="https://chat.stackexchange.com/?tab=site&amp;host=bitcoin.stackexchange.com">chat room</a> or some other website (e.g. reddit, facebook, twitter, etc)</p>

CC BY-SA 4.0
2019-09-24T09:46:43.327Z
In your answer of "I have a good idea. that is we should mark something in the UTXO", I understood that blockchain software(for full-node) dose not need to have same processing of finding, deleting the UTXO. so this is under full-node capability of developer if they can modify and rebuild(re-compile) the origin source code. okay... so what is a standard efficient mechanism on UTXO management in the Bitcoin? is there no existed? if so, my idea is not bad to experiment?
Hyunsoo
CC BY-SA 4.0
2019-09-24T08:40:31.683Z
2019-09-24T08:48:37.497Z
2019-09-24T08:48:37.497Z
RedGrittyBrick
<p>If Bitcoin sees all blocks, it will be very slow based on chain length and block size but, it can certainly verify incoming transactions.</p>

<p>I know that blockchain is never modified any previous block. so if user consumes own transaction, Bitcoin dose just create new TXO which is reference to UTXO. so it is two penalty. one is that our disk is quickly filled and lastly it must check all the blocks to see whether TXO(reference to UTXO) is existed or not. </p>

<p>I have a good idea. that is we should mark something in the UTXO. so it gives two good points. one is that we don't need to create TXO to figure out whether UTXO was used or not. and lastly we don't need to fill our disk with TXO.
But my idea has strange point that information of transaction already written on block should be modified.</p>

<p>How think about it? I would like to discuss about my point.</p>

<p>Sorry for my English.</p>

<transactions><utxo><verification>
How Bitcoin dose find and verify UTXO ? is this efficient?
Hyunsoo
# How Bitcoin dose find and verify UTXO ? is this efficient?

(Asked by: username_0 on 2019-09-24)

If Bitcoin sees all blocks, it will be very slow based on chain length and block size but, it can certainly verify incoming transactions.

I know that blockchain is never modified any previous block. so if user consumes own transaction, Bitcoin dose just create new TXO which is reference to UTXO. so it is two penalty. one is that our disk is quickly filled and lastly it must check all the blocks to see whether TXO(reference to UTXO) is existed or not.

I have a good idea. that is we should mark something in the UTXO. so it gives two good points. one is that we don't need to create TXO to figure out whether UTXO was used or not. and lastly we don't need to fill our disk with TXO.
But my idea has strange point that information of transaction already written on block should be modified.

How think about it? I would like to discuss about my point.

Sorry for my English.

**Tags:** transactions, utxo, verification


---

## 2 answers

### Answer by username_2 on 2019-09-24. Score: 3 | Accepted answer

> **How Bitcoin dose find and verify UTXO?**

By Bitcoin, I think you must mean "Bitcoin core" - the Bitcoin wallet software derived from the original reference implementation by Satoshi Nakamoto. The word Bitcoin also encompasses the specific set of concepts outlined in the Bitcoin whitepaper, the network protocol definitions, the Bitcoin improvement proposals (BIPS), the worldwide network of Bitcoin nodes and Bitcoin users, etc.

How Bitcoin core manages UTXOs is probably best answered by inspecting the source code. I can however make some guesses, which even if wrong will show that the issue which concerns you is a non-issue.

Bitcoin core maintains several sets of data files. One of these is the wallet.dat file. Another set is the blockchain data itself, represented in a series of files. There may be other sets of data.

> **I know that blockchain is never modified any previous block**

Yes, but that does not mean that some Bitcoin software has to have a persistent storage format that exactly follows the over-the-network blockchain block layout. The software could store the data in a normalised SQL database and only reconstruct the blocks when it needs to re-verify the hashes, signatures etc - which would normally only be needed to be verified once when the block is first received. Such a data storage arrangement would allow lots of additional fields and associated tables to store extra information such as a flag showing whether a TXO had been subsequently spent (hence no longer a *U*TXO). Alternatively the Blockchain data could be stored in files exactly as received and ancilliary files used to store additional indexes of block-numbers and transaction-IDs associated with addresses of interest or a table of UTXOs that are added to and deleted from as blocks arrive and are verified and processed.

> **it must check all the blocks to see whether TXO(reference to UTXO) is existed or not.**

No, it only needs to check each block once. After that it can consult an efficient index into a separate small efficient table of *current* UTXOs which it maintains independently of the actual blockchain data.

> **I have a good idea. that is we should mark something in the UTXO**

Effectively this is already done. Except that most likely the mark is not made in a copy of the blockchain block structure but in separate data structures that Bitcoin core maintains for this purpose.

There is no need to alter the agreed Blockchain data structure that is used to transmit blocks between nodes.

It is not necessary for any node's software (wallet or not) to store Blockchain blocks at all, especially not SPV wallets. They are all free to choose any internal storage implementation and formats that their designers feel addresses their goals.

Nodes may need to be able to transmit to other nodes, requested blocks that they have previously received. But this could be achieved by reconstructing blocks from other, completely different and more comprehensive, storage formats.

> **I would like to discuss about my point.**

Please note that this is a Q&A website not a discussion forum. Try our [chat room](https://chat.stackexchange.com/?tab=site&host=bitcoin.stackexchange.com) or some other website (e.g. reddit, facebook, twitter, etc)

> **Comments:**
> **username_0**: In your answer of "I have a good idea. that is we should mark something in the UTXO", I understood that blockchain software(for full-node) dose not need to have same processing of finding, deleting the UTXO. so this is under full-node capability of developer if they can modify and rebuild(re-compile) the origin source code. okay... so what is a standard efficient mechanism on UTXO management in the Bitcoin? is there no existed? if so, my idea is not bad to experiment?  

---

### Answer by username_1 on 2019-09-24. Score: 1

This is already done, somewhat implicitly.

As a bitcoin node syncs, it constantly updates a utxo database. For each block, it removes all utxos consumed in that block, and adds all new ones created.

As a result, once the node has synced, it has a full list of all unspent utxos.

When a new transaction is processes, the node only needs to check this database for utxo validity - if the utxo is in the database, it has not been spent. If it is not, it has either already been spent, or never existed to begin with.

> **Comments:**
> **username_0**: Thanks for kind replying :)  Are you Bitcoin core developer? (because you said "somewhat implicitly")  Where can I find the material(please give a web link) that you said ?  
> **username_1**: I don't work on the BItcoin project, but I work in the space. There are probably a few articles out there describing this in more detail, but I don't know any off the top of my head to recommend. @username_2 goes into some more detail in his answer.  

---

