Can a Bitcoin node build a partial UTXO set from only the most recent blocks and use it to validate new transactions?

External question — Bitcoin Stack Exchange Author: hongping cao Original post: https://bitcoin.stackexchange.com/questions/131051 License: CC BY-SA 4.0 — https://creativecommons.org/licenses/by-sa/4.0/ Adaptation: HTML converted to plain text; contact email addresses removed. I’m working on a lightweight-node design for improving independent verification of new/unconfirmed Bitcoin transactions under limited storage. I’d like to get some technical feedback on the design. The idea is that the lightweight node first synchronizes the main-chain headers, then caches the latest N full blocks and builds a partial UTXO set and spent-output state from them. When a new transaction arrives, it independently verifies the inputs for which the required UTXO data is locally available; inputs whose UTXO data is unavailable are treated as unverifiable rather than valid or invalid. The local verification result is only for the lightweight node itself. The node does not need to relay a transaction based on this result or act as a fully validating node. For new blocks, it checks the header, PoW and Merkle commitment, and verifies transaction inputs where the required UTXO information is locally available. It does not treat the whole block as valid simply because most inputs can be verified. For reorg risk, I’m considering treating the latest M blocks as a confirmation-sensitive protected tail. For eclipse attacks, my assumption is that caching N blocks does not prevent eclipse/isolation attacks, but an attacker trying to fabricate an alternative recent chain would need valid PoW, so replacing a longer recent history would require more cumulative work. Does this basic design and its security boundary make sense from a Bitcoin/Bitcoin Core perspective? Is there anything fundamentally wrong with it? I’m also considering an improvement to the initialization process and a graded verification mechanism for new transactions. Instead of initializing HBC directly from the latest N blocks, the node could start much further back, e.g. at H-(N+10,000), where H is the current chain height. These deeply confirmed blocks on the highest-work header chain would provide a high-confidence historical starting point. The node would then process blocks sequentially from that point toward the current tip while constructing and updating its partial UTXO state. During this forward initialization process, transactions would be classified into three categories based on what the node can verify locally: Locally fully verifiable: all required input information is locally available and the transaction can be fully checked. Its outputs can then be treated as high-confidence UTXO sources for verifying subsequent transactions. Locally partially verifiable: only some of the required input information is locally available. Its outputs could still be tracked, but with lower verification confidence, and this lower confidence would propagate when those outputs are later spent. Locally unverifiable: the required input information is not available locally, so the transaction cannot be independently verified. Its outputs would therefore not be treated as verified UTXO sources. As blocks are processed sequentially toward the tip, more transactions may depend on outputs that the node has already classified and tracked. In this way, the partial UTXO state and its associated verification status are continuously propagated forward during initialization. After initialization reaches the current tip, the same information can be used for graded verification of newly received unconfirmed transactions. A new transaction whose inputs all come from fully verified local UTXOs would have high verification confidence. If some inputs depend on partially verified UTXOs, or on outputs from the latest M confirmation-sensitive blocks, its verification confidence would be lower. If required inputs depend on locally unverifiable sources, the new transaction would have very low confidence or be classified as locally unverifiable. Potentially, this could be represented by a transaction-level verification-confidence score, with a configurable acceptance threshold. Alternatively, the result could remain categorical: fully verified / partially verified / unverifiable. Does this forward-initialization and confidence-propagation approach make technical sense in Bitcoin? In particular, is it meaningful to propagate different verification levels through subsequently spent UTXOs, and would a numerical confidence score be defensible, or would categorical states be more appropriate?

External answer — Bitcoin Stack Exchange Author: StackQsUp Original post: https://bitcoin.stackexchange.com/a/131052 License: CC BY-SA 4.0 — https://creativecommons.org/licenses/by-sa/4.0/ Adaptation: HTML converted to plain text; contact email addresses removed. One of the things that happens when someone starts running their own node is the software validates the entire chain, and every single transaction within it. Doing so ensures the downloaded copy of the blockchain is the consensus chain and valid. If you were to ask another node to just send you the last 100, 1000, or 10,000 blocks, the only transactions you would be able to partially validate would the ones that arose from the coinbase transactions in those blocks. You are assuming that because the transactions are in a block you downloaded, they are legit. While that is likely the case, you have not ensured that the blocks are building on valid blocks. You only asked for the last n blocks, and while you can see whether or not the last n blocks are valid in isolation, you can not ensure that the nth block validly builds on the n+1th previous block. More aligned with your perspective about UTXOs, you cannot verify that those UTXOs that are in those blocks that did NOT arise from a coinbase in those n blocks are actually valid, because you have not verified where the original inputs came from. You are trusting someone else’s node to verify things for you. This is essentially what every bitcoin wallet (non-node) does. That is fine for the purpose, for example, an iPhone wallet shouldn’t need to download the entire chain before checking a balance. But in this context, running a node like this does not have any of the benefits of running a full node but all the downsides. Mantra in Bitcoin: Don’t trust, verify!

External answer — Bitcoin Stack Exchange Author: Pieter Wuille Original post: https://bitcoin.stackexchange.com/a/131054 License: CC BY-SA 4.0 — https://creativecommons.org/licenses/by-sa/4.0/ Adaptation: HTML converted to plain text; contact email addresses removed. I don't believe this is a useful approach. If you only process the last N blocks, you can indeed build a partial UTXO set, but you cannot know what you're missing. When a block arrives to be validated, and one of its inputs is missing from your partial UTXO set, you have no way to distinguish "UTXO was already spent" from "UTXO was created in a part of the chain I ignored". The result of this is that you cannot perform any useful validation at all. An attacker can simply claim to have received arbitrary amounts of BTC in the early part of the chain you skipped, and you cannot reject those transactions as invalid. If you cannot maintain an entire UTXO set, don't bother with UTXO-level validation at all. The construction is equivalent in security to SPV validation, where you rely entirely on PoW to consider transactions valid.