How Bitcoin dose find and verify UTXO ? is this efficient? 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.
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 UTXO). 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&amp;A website not a discussion forum. Try our chat room or some other website (e.g. reddit, facebook, twitter, etc)