5

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).

Improve this question

1 Answer 1

Reset to default
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)
Improve this answer
4
  • 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
    Feb 19, 2018 at 13:25
  • 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
    Feb 19, 2018 at 18:47
  • 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
    Feb 19, 2018 at 22:02
  • 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
    Feb 20, 2018 at 2:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.