<blockquote>
  <p>As a lightweight client doesn't have the full UTXO set at hand</p>
</blockquote>

<p>I assume you're right and in addition to your second message, I suppose the only way to check UTXO without BIP64 is to call a full node.<br>
Here is a simple exemple to do that :<br></p>

<pre><code>curl "https://bitcoin.toshi.io/api/v0/addresses/12c6DSiU4Rq3P4ZxziKxzrL5LmMBrzjrJX/unspent_outputs"
</code></pre>

<p>from <a href="https://toshi.io/docs/#get-address-unspent-outputs" rel="nofollow">https://toshi.io/docs/#get-address-unspent-outputs</a></p>

CC BY-SA 3.0
2016-04-26T09:37:19.120Z
2016-04-26T09:37:19.120Z
onepix
<p>I don't think an SPV node can know for sure for 0-conf transactions.</p>

<p>However, once the transaction is in a block, the full node will provide you with a Merkle path proving that this transaction is part of that block. So then you're sure and if you also keep track of the PoW and subsequent blocks you can count how many confirmations the transactions has.</p>

CC BY-SA 3.0
2016-04-26T13:22:39.227Z
Yeah, the proof of the contrary is trivial, no question. I am however actually wondering about the stated problem: How can a lightweight node be reasonable sure about an output *not being spent yet*?
Murch
CC BY-SA 3.0
2016-04-26T21:00:04.070Z
Ah you mean the question as "without waiting for a confirmation". Another way would be to trace back the input of the transaction all the way back to the coinbase transaction(s). Downloading only the (parts of the) blocks that are relevant along that graph. That could add up to serious amounts of data (worst case the whole blockchain I guess). However, if UTXO commitments ever become a thing, a light client might do the above tracing only until it has a UTXO commitment. Or depending on how the UTXO commitments will work, no tracing at all: every block contains a delta to update the UTXO set.
Jannes
CC BY-SA 3.0
2016-04-27T00:20:59.823Z
No, I mean, that it is still in the UTXO set.
Murch
CC BY-SA 3.0
2016-04-27T08:42:24.843Z
I've edited my question to clarify my interest.
Murch
CC BY-SA 3.0
2016-04-26T10:14:11.720Z
2016-04-26T10:14:11.720Z
Jannes
<p>It appears that BIP64 was <a href="https://github.com/bitcoin/bitcoin/pull/4351" rel="nofollow">reverted</a> soon after it was merged, and only lived on in BitcoinXT as Mike Hearn originally introduced it for his Lighthouse application. The <code>getutxo</code> message is also not part of Bitcoin Classic, as Classic was forked from Core, and not from XT.</p>

<p>Therefore, it seems to me that being sure an output is still unspent is only practical by running your own full-node to query with <code>gettxout</code>. </p>

<p>Please feel free to correct me, if the above is not accurate.</p>

CC BY-SA 3.0
2016-04-26T08:08:38.720Z
2016-04-26T08:08:38.720Z
Murch
<p>There are currently <a href="https://bitnodes.21.co/nodes/?q=NODE_GETUTXOS" rel="nofollow">115 or so nodes</a> which will answer the <code>getutxos</code> message.  This is as good a source of this information as calling a 3rd party API.  The problem with both of these sources is that they do not provide cryptographic proof.</p>

<p>It's not actually possible to prove an output unspent, for the simple reason that it may have been spent in a block found an instant after the proof was produced.</p>

<p>The idea of UTXO commitments would have miners publish a digest of the entire UTXO set in every block, which could be referenced to prove that a specific UTXO was unspent as of the lastest one, but you're probably also interested in any unconfirmed spends that are floating around out there.</p>

<p>It may be a better idea to ask your peers to try to prove that an output is already spent.  Only confirmation should build your confidence in an incoming payment, but a spend proof in the form of a conflicting transaction (+ merkle branch, if found in the chain) can instantly lower your confidence to zero.</p>

CC BY-SA 3.0
2016-04-27T08:32:27.637Z
UTXO commitments seems to be exactly what I was looking for, thank you. The nodes are the XT nodes, right? I've edited the question to clarify what I am exactly interested in knowing.
Murch
CC BY-SA 3.0
2016-04-27T00:48:52.967Z
2016-04-27T00:48:52.967Z
Tom Harding
<p>It's simple to prove the creation of a UTXO: You just need to provide the transaction data, the Merkle branch, and block of the creating transaction.</p>

<p>Then, as a full-node, it is simple to check whether the output hasn't been spent yet: You're keeping track of the UTXO yourself, and if it hasn't been removed from your UTXO set, it's still unspent.</p>

<p>As a <strong>lightweight client</strong> doesn't have the full UTXO set at hand, how could it make sure that an output is still unspent? I see that BIP0064 introduced a <code>getutxo</code> message, but can't seem to find more about it. Is such an interface still in effect? Is there an option beyond polling a number of different nodes for a particular UTXO, or running a full-node?</p>

<hr>

<p>Clarification of what I'm interested in: I've recently read the paper <a href="http://telematics.tm.kit.edu/publications/Files/566/wpes25f-florianA.pdf" rel="nofollow">Sybil-Resistant Pseudonymization and Pseudonym Change without Trusted Third Parties</a>. The proposed system <em>BitNym</em> manages pseudonyms by storing them in transaction outputs. A pseudonym stays valid until the anchoring output is spent. It is therefore of interest to check whether an output is still in the UTXO set.</p>

<json-rpc><utxo>
How can a lightweight client make sure output has not been spent yet?
Murch
# How can a lightweight client make sure output has not been spent yet?

(Asked by: username_0 on 2016-04-26)

It's simple to prove the creation of a UTXO: You just need to provide the transaction data, the Merkle branch, and block of the creating transaction.

Then, as a full-node, it is simple to check whether the output hasn't been spent yet: You're keeping track of the UTXO yourself, and if it hasn't been removed from your UTXO set, it's still unspent.

As a **lightweight client** doesn't have the full UTXO set at hand, how could it make sure that an output is still unspent? I see that BIP0064 introduced a `getutxo` message, but can't seem to find more about it. Is such an interface still in effect? Is there an option beyond polling a number of different nodes for a particular UTXO, or running a full-node?

---

Clarification of what I'm interested in: I've recently read the paper [Sybil-Resistant Pseudonymization and Pseudonym Change without Trusted Third Parties](http://telematics.tm.kit.edu/publications/Files/566/wpes25f-florianA.pdf). The proposed system *BitNym* manages pseudonyms by storing them in transaction outputs. A pseudonym stays valid until the anchoring output is spent. It is therefore of interest to check whether an output is still in the UTXO set.

**Tags:** json-rpc, utxo


---

## 4 answers

### Answer by username_3 on 2016-04-27. Score: 3 | Accepted answer

There are currently [115 or so nodes](https://bitnodes.21.co/nodes/?q=NODE_GETUTXOS) which will answer the `getutxos` message. This is as good a source of this information as calling a 3rd party API. The problem with both of these sources is that they do not provide cryptographic proof.

It's not actually possible to prove an output unspent, for the simple reason that it may have been spent in a block found an instant after the proof was produced.

The idea of UTXO commitments would have miners publish a digest of the entire UTXO set in every block, which could be referenced to prove that a specific UTXO was unspent as of the lastest one, but you're probably also interested in any unconfirmed spends that are floating around out there.

It may be a better idea to ask your peers to try to prove that an output is already spent. Only confirmation should build your confidence in an incoming payment, but a spend proof in the form of a conflicting transaction (+ merkle branch, if found in the chain) can instantly lower your confidence to zero.

> **Comments:**
> **username_0**: UTXO commitments seems to be exactly what I was looking for, thank you. The nodes are the XT nodes, right? I've edited the question to clarify what I am exactly interested in knowing.  

---

### Answer by username_1 on 2016-04-26. Score: 1

> As a lightweight client doesn't have the full UTXO set at hand

I assume you're right and in addition to your second message, I suppose the only way to check UTXO without BIP64 is to call a full node.  
Here is a simple exemple to do that :

```
curl "https://bitcoin.toshi.io/api/v0/addresses/12c6DSiU4Rq3P4ZxziKxzrL5LmMBrzjrJX/unspent_outputs"

```

from <https://toshi.io/docs/#get-address-unspent-outputs>


---

### Answer by username_2 on 2016-04-26. Score: 0

I don't think an SPV node can know for sure for 0-conf transactions.

However, once the transaction is in a block, the full node will provide you with a Merkle path proving that this transaction is part of that block. So then you're sure and if you also keep track of the PoW and subsequent blocks you can count how many confirmations the transactions has.

> **Comments:**
> **username_0**: Yeah, the proof of the contrary is trivial, no question. I am however actually wondering about the stated problem: How can a lightweight node be reasonable sure about an output *not being spent yet*?  
> **username_2**: Ah you mean the question as "without waiting for a confirmation". Another way would be to trace back the input of the transaction all the way back to the coinbase transaction(s). Downloading only the (parts of the) blocks that are relevant along that graph. That could add up to serious amounts of data (worst case the whole blockchain I guess). However, if UTXO commitments ever become a thing, a light client might do the above tracing only until it has a UTXO commitment. Or depending on how the UTXO commitments will work, no tracing at all: every block contains a delta to update the UTXO set.  
> **username_0**: No, I mean, that it is still in the UTXO set.  
> **username_0**: I've edited my question to clarify my interest.  

---

### Answer by username_0 on 2016-04-26. Score: 0

It appears that BIP64 was [reverted](https://github.com/bitcoin/bitcoin/pull/4351) soon after it was merged, and only lived on in BitcoinXT as Mike Hearn originally introduced it for his Lighthouse application. The `getutxo` message is also not part of Bitcoin Classic, as Classic was forked from Core, and not from XT.

Therefore, it seems to me that being sure an output is still unspent is only practical by running your own full-node to query with `gettxout`.

Please feel free to correct me, if the above is not accurate.


---

