<blockquote>
  <p>When exactly an entry is added to the set of unspent transactions outputs?</p>
  
  <p>When exactly an entry is removed from the set of unspent transactions outputs?</p>
</blockquote>

<p>The answer to these questions is that there is no singular set of unspent transaction outputs. There are multiple versions that are maintained and/or implied for different purposes.</p>

<p>1) There is the UTXO set defined by the on-disk LevelDB database. This only changes after a flush (see further).</p>

<p>2) There is the UTXO set defined by the in-memory cache (the <code>pcoinsTip</code> object). It represents the state of the network at the current best block, but does not include the effect of any unconfirmed transactions. Whenever the number of changes in this cache grows too big (see <code>-dbcache</code>) it gets flushed to disk.</p>

<p>3) There is the UTXO set defined by the memory pool. It consists of the UTXO set defined in 2, plus all outputs created by unconfirmed transactions, minus all outputs spent by unconfirmed transactions. This changes every time the mempool changes. Note that this UTXO set is nowhere materialized explicitly - it's just defined by what is in the cache (see 2) and unconfirmed transactions in the mempool.</p>

<blockquote>
  <p>Whats' the difference between validating a transaction that is validated in block (case of a relayed block) and a transaction that is validated standalone (case of a relayed transaction).</p>
</blockquote>

<p>From the top of my head:</p>

<ul>
<li>Only consensus rules are validated, not policy/standardness rules</li>
<li>All scripts are validated in parallel (on multiple CPU cores)</li>
<li>The changes are flushed to <code>pcoinsTip</code> (and possibly to disk)</li>
</ul>

CC BY-SA 3.0
2018-02-19T13:25:26.460Z
In a scenario where my Node A received a transaction x, validated successfully and then removed its input from the utxo set. Then come a block with that transaction x in it, don't you think that I might tag the transaction x invalid because its input was already removed from my utxo set?
Eddy
CC BY-SA 3.0
2018-02-19T18:47:32.987Z
A new transaction (not in a block) only affects the UTXO set number 3 in my list above. When a new block comes in with that same transaction, it is still in UTXO set 2, which it will be removed from if that block is accepted as active.
Pieter Wuille
CC BY-SA 3.0
2018-02-19T22:02:11.970Z
1. When exactly is the utxo set data written on disk? 2.When does the inverse operation happen? I mean load the data from disk to the cache memory?  3.Why do we need  three data sets for doing almost the same task?
Eddy
CC BY-SA 3.0
2018-02-20T02:48:29.977Z
1. When the cache grows too big to fit in memory (controlled by -dbcache). 2. Whenever a UTXO entry is needed that isn't in the cache already. 3) The cache is there for performance reasons. The separate UTXO set implied by the mempool is there to solve the issue in your previous question (and is never materialized explicitly - the data structures inside the program are just literally the cache from (2) and the mempool).
Pieter Wuille
CC BY-SA 3.0
2018-02-19T02:13:18.447Z
2018-02-20T03:07:19.803Z
2018-02-20T03:07:19.803Z
Pieter Wuille
<p>I do have this implementation question and wanted to know how it's implemented specifically in the <strong>Bitcoin core</strong>.</p>

<p><strong>1</strong>. <em>When exactly</em> an entry is added to the set of unspent transactions outputs?
Is it when a block is persisted (added to the bchain) after being validated and then all the utxo from its txs are added to the utxo set?</p>

<p><strong>2</strong>. <em>When exactly</em> an entry is removed from the set of unspent transactions outputs? 
Does the bitcoin core remove a spent utxo when validating a standalone transaction ? Or is it done on block persistence ?</p>

<p><strong>3</strong>. <em>Whats' the difference</em> between validating  a transaction that is validated in block (case of a relayed block) and a transaction that is validated standalone (case of a relayed transaction).</p>

<transactions><utxo-set>
When exactly an entry is removed or added to the UTXO's set in the Bitcoin core?
Eddy
# When exactly an entry is removed or added to the UTXO's set in the Bitcoin core?

(Asked by: username_0 on 2018-02-18)

I do have this implementation question and wanted to know how it's implemented specifically in the **Bitcoin core**.

**1**. *When exactly* an entry is added to the set of unspent transactions outputs?
Is it when a block is persisted (added to the bchain) after being validated and then all the utxo from its txs are added to the utxo set?

**2**. *When exactly* an entry is removed from the set of unspent transactions outputs?
Does the bitcoin core remove a spent utxo when validating a standalone transaction ? Or is it done on block persistence ?

**3**. *Whats' the difference* between validating a transaction that is validated in block (case of a relayed block) and a transaction that is validated standalone (case of a relayed transaction).

**Tags:** transactions, utxo-set


---

## 1 answers

### Answer by username_1 on 2018-02-19. Score: 4

> When exactly an entry is added to the set of unspent transactions outputs?
>
> When exactly an entry is removed from the set of unspent transactions outputs?

The answer to these questions is that there is no singular set of unspent transaction outputs. There are multiple versions that are maintained and/or implied for different purposes.

1) There is the UTXO set defined by the on-disk LevelDB database. This only changes after a flush (see further).

2) There is the UTXO set defined by the in-memory cache (the `pcoinsTip` object). It represents the state of the network at the current best block, but does not include the effect of any unconfirmed transactions. Whenever the number of changes in this cache grows too big (see `-dbcache`) it gets flushed to disk.

3) There is the UTXO set defined by the memory pool. It consists of the UTXO set defined in 2, plus all outputs created by unconfirmed transactions, minus all outputs spent by unconfirmed transactions. This changes every time the mempool changes. Note that this UTXO set is nowhere materialized explicitly - it's just defined by what is in the cache (see 2) and unconfirmed transactions in the mempool.

> Whats' the difference between validating a transaction that is validated in block (case of a relayed block) and a transaction that is validated standalone (case of a relayed transaction).

From the top of my head:

* Only consensus rules are validated, not policy/standardness rules
* All scripts are validated in parallel (on multiple CPU cores)
* The changes are flushed to `pcoinsTip` (and possibly to disk)

> **Comments:**
> **username_0**: In a scenario where my Node A received a transaction x, validated successfully and then removed its input from the utxo set. Then come a block with that transaction x in it, don't you think that I might tag the transaction x invalid because its input was already removed from my utxo set?  
> **username_1**: A new transaction (not in a block) only affects the UTXO set number 3 in my list above. When a new block comes in with that same transaction, it is still in UTXO set 2, which it will be removed from if that block is accepted as active.  
> **username_0**: 1. When exactly is the utxo set data written on disk? 2.When does the inverse operation happen? I mean load the data from disk to the cache memory?  3.Why do we need  three data sets for doing almost the same task?  
> **username_1**: 1. When the cache grows too big to fit in memory (controlled by -dbcache). 2. Whenever a UTXO entry is needed that isn't in the cache already. 3) The cache is there for performance reasons. The separate UTXO set implied by the mempool is there to solve the issue in your previous question (and is never materialized explicitly - the data structures inside the program are just literally the cache from (2) and the mempool).  

---

