3

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

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)
  • 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? – OvGeny Feb 19 '18 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 '18 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? – OvGeny Feb 19 '18 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 '18 at 2:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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