Quest to Understand UTXO functionality

[hmbdofficial]

What really happens technically if a transaction attempts to spend the UTXO that has already been spent and how do the node identifies and invalidate such during the mempool and block validation
Is it just enough that spent UTXO are destroyed and no trace of them in the mempoo afterwards?

[Charles-Tim]

If bitcoin has been used in a transaction, you can not use the same bitcoin in another transaction unless it is the one that has already been spent which the receiver can also send to another person or sent to his another bitcoin address.

But if an unconfirmed transaction is valid before but double spent with replace-by-fee, the transaction will be replaced by another transaction, rendering the old unconfirmed transaction invalid.

[ABCbits]

Node will check whether any UTXO in a TX actually exist on its UTXO set/database. But since the UTXO already spend, node would know the TX attempt to spend non-exist UTXO or UTXO that already spend.

[Zaguru12]

Just as ABCbits has put it out, we can say that each UTXO must belong to a UTXO set, this is like a database and all the full nodes stores this database. and once spend it’s actual removed and the technicality of bitcoin is that every outputs (UTXO) are referenced in inputs as unspent and that is when the nodes actually validates the UTXO.  The only transaction that doesn’t have an input is a coinbase transaction

It should be understand that there is a transaction lock on each UTXO and each of this lock at tied to the users public key hash. So if the transaction is actually spent, the New UTXO will be now tied to the recipients script hash or public key hash and can he only spent by that public key’s private key.

In simplicity each outputs is linked to a input of subsequent transaction while an output is linked to a previous inputs too

[bitmover]

Node will check whether any UTXO in a TX actually exist on its UTXO set/database. But since the UTXO already spend, node would know the TX attempt to spend non-exist UTXO or UTXO that already spend.

Just to expand this answer a bit.

If a node tries to include a transaction with an UTXO which is already spent, marking it as a valid transaction,  this node will get banned by other other nodes , as it is not following consensus rules.

In the end, transaction wont get propagated even if you control a corrupted node. If the block gets mined with an invalid transaction,  it will be ignored by the other node (like a fork which doesnt follow consensus rules)

[She shining]

It is identified because it's not in the UTXO set where only unspent transactions are found. So if it's not there then it means it has already be spent. The spent output is consumed and removed from the UTXO set and the transaction creates a new output( New UTXO).

[d5000]

If a node tries to include a transaction with an UTXO which is already spent, marking it as a valid transaction,  this node will get banned by other other nodes , as it is not following consensus rules.

This afaik only happens if the UTXO was already spent in a previous block, i.e. the "spending transaction" was already confirmed by a miner.

The real difficulty for nodes is to know to order double spends occurring in the same block. Let's imagine we have transaction X spending the same UTXO than transaction Y, and both are created only few milliseconds one after another. Let's say the person trying to double spend wants to damage a person or service in Australia who accepts 0-confirmation transactions, so they broadcast transaction X targeting specifically several nodes in Australia, hoping that the victim sees it first. At the same time they broadcast double spend Y to nodes close to many mining pools, e.g. in the US. So the Australian potential victim node "sees" transaction X and discards transaction Y, but most US miners do the opposite and include transaction Y instead, because they didn't see in their UTXO set that transaction X happened (as it is still unconfirmed and they received it after transaction Y).

As this is something that can happen all the time due to the latency between different networks (and more so if they're far away one from another, like in the example) I believe nodes won't ban another node for trying to broadcast an unconfirmed double spend. They simply check if the transaction is consistent with their own UTXO set, and if not, they discard it.

Of course this "attack" is very unlikely to succeed, because it is unlikely that somebody really accepts a 0 confirmation transaction, and latency issues tend to improve with network speed. But it shows that the "chain state" and thus the "UTXO set" are always a local phenomenon, and all nodes manage it independently. This means in double spend cases nodes can't really see which transaction is the "valid" one, until a miner includes and thus confirms one of both transactions.

[Mia Chloe]

What really happens technically if a transaction attempts to spend the UTXO that has already been spent and how do the node identifies and invalidate such during the mempool and block validation
Is it just enough that spent UTXO are destroyed and no trace of them in the mempoo afterwards?

The bitcoin network is a public ledger meaning they will publicly be marked as spent. During the process of broadcasting and , validation and even confirmation, nodes use a time stamp and witness and a few other data that all confirms the coins are authentic, haven't been spent before and have an origin.

Every coin spent or unspent must have a valid origin and once you've spent it once you can't spend it anymore because publicily it's origin is already marked as spent.

[PrimeNumber7]

If a node tries to include a transaction with an UTXO which is already spent, marking it as a valid transaction,  this node will get banned by other other nodes , as it is not following consensus rules.

This afaik only happens if the UTXO was already spent in a previous block, i.e. the "spending transaction" was already confirmed by a miner.

The real difficulty for nodes is to know to order double spends occurring in the same block. Let's imagine we have transaction X spending the same UTXO than transaction Y, and both are created only few milliseconds one after another. Let's say the person trying to double spend wants to damage a person or service in Australia who accepts 0-confirmation transactions, so they broadcast transaction X targeting specifically several nodes in Australia, hoping that the victim sees it first. At the same time they broadcast double spend Y to nodes close to many mining pools, e.g. in the US. So the Australian potential victim node "sees" transaction X and discards transaction Y, but most US miners do the opposite and include transaction Y instead, because they didn't see in their UTXO set that transaction X happened (as it is still unconfirmed and they received it after transaction Y).

As this is something that can happen all the time due to the latency between different networks (and more so if they're far away one from another, like in the example) I believe nodes won't ban another node for trying to broadcast an unconfirmed double spend. They simply check if the transaction is consistent with their own UTXO set, and if not, they discard it.

Of course this "attack" is very unlikely to succeed, because it is unlikely that somebody really accepts a 0 confirmation transaction, and latency issues tend to improve with network speed. But it shows that the "chain state" and thus the "UTXO set" are always a local phenomenon, and all nodes manage it independently. This means in double spend cases nodes can't really see which transaction is the "valid" one, until a miner includes and thus confirms one of both transactions.

Most miners have very well-connected nodes that are geographically diverse. The reason for this is that they want to get started on a new block ASAP after a previous block has been found.

Similarly, many merchants have multiple nodes that are geographically diverse.

In both cases, the node owners try to avoid it being known the entity who is behind the node so to prevent attackers from being able to segment them from the rest of the network.

So spending two conflicting transactions at nearly the same time will not necessarily result in a particular transaction being confirmed. I would speculate that all else being equal, the transaction with the higher fee will be confirmed, and the other discarded in most cases.

Also, any entity accepting 0/unconfirmed transactions is likely to monitor the network for conflicting transactions, and not accept the transaction if a double spend attempt is detected.

[hmbdofficial]

I was thinking if a pruned node will reliably serve UTXO data for wallet in all cases? Or there is limitations compared to an archival node?

[PrimeNumber7]

I was thinking if a pruned node will reliably serve UTXO data for wallet in all cases? Or there is limitations compared to an archival node?

There will always be edge cases for all engineering problems. Your question is also somewhat ambiguous.

If you want to add an address to your wallet after your node has synced, it will be difficult for you to know the available UTXOs associated with your address. Similarly, you won't be able to use Electrum with a pruned node. If you have your private key/address in your wallet software as of when your purned node starts syncing, you should have no issue with knowing the available UTXOs associated with your address. If your node receives a transaction that attempts to spend an output that is invalid or has already been spent, it will reject the transaction.

[ABCbits]

Also, any entity accepting 0/unconfirmed transactions is likely to monitor the network for conflicting transactions, and not accept the transaction if a double spend attempt is detected.

Sometimes they also have other limitation, such as accepting 0-conf TX below $500 or from customer with some past purchase.

I was thinking if a pruned node will reliably serve UTXO data for wallet in all cases? Or there is limitations compared to an archival node?

Your question is ambiguous, but
1. Pruned node store all UTXO data (and other necessary data), so it can verify new block/TX.
2. Pruned node only send latest 288 blocks to other node/client due to NODE_NETWORK_LIMITED behavior.
3. Lightweight/SPV usually request full TX history (rather than UTXO) that associated with certain Bitcoin address.

[BlackHatCoiner]

Is it just enough that spent UTXO are destroyed

UTXO stands for "Unspent Transaction Output". Therefore, there cannot be a "spent UTXO". Linguistic correction might help in your case, because it's not very clear what the question is. The UTXO set represents all the outputs that it is valid to spend from.

I was thinking if a pruned node will reliably serve UTXO data for wallet in all cases? Or there is limitations compared to an archival node?

Serve UTXO data to whom and what kind of data? A pruned node cannot index transactions, for example, nor does it contribute to the network the same as an archival node.

[hmbdofficial]

Serve UTXO data to whom and what kind of data?

I was referring to UTXO data for light clients, although @ABCbit has made it clear to me already that from his explanation.

[BlackHatCoiner]

I was referring to UTXO data for light clients

The answer is: it depends the light client. Although I'm not aware of a light client for which the UTXO set alone suffices. And even it does, it cannot show you the history of your previous transactions. It can only show you the current balance.

Unless of course it's your personal wallet which was scanned from genesis block, during pruned node's syncing. But no, I don't think there's a light client that allows you to just import a new, random wallet, connected to your pruned node, and does not require you to rescan the blockchain.

[hmbdofficial]

The answer is: it depends the light client. Although I'm not aware of a light client for which the UTXO set alone suffices. And even it does, it cannot show you the history of your previous transactions. It can only show you the current balance.

If I get it very clear you’re Practically saying that pruned node cannot serve as the genesis for newer node in the blockchain network in case of any bad circumstances since it doesn’t have the complete history of the blockchain so you will not be able to synchronise from it genesis to other nodes and you may also not be able to to restart the network from its point of origin in case of when need to do so.

[stwenhao]

Exactly. If you have the full history, then it is trustless. But if you have only the UTXO set, then some malicious node could add some non-existing entries, claiming that you have for example 21 BTCs. And then, you have no way of knowing, if it is fake or real, without checking previous coins.

Which is why nodes don't send the UTXO set between themselves, but they only send transactions and blocks.