refactor: have CCoins* data managed under CChainState #16443

jamesob · 2019-07-23T19:27:50Z

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.

maflcko

Would it make sense to split this into dumb refactoring and then hard-to-review changes, like the on in init.cpp?

An early commit (scripted-diff or not) could add ChainstateActive::CoinsTip, a dumb alias to return pcoinsTip; and replace the usages. The later commit could then make the other changes in this pull.

src/validation.h

src/validation.cpp

src/net_processing.cpp

DrahtBot · 2019-07-23T22:30:06Z

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Conflicts

Reviewers, this pull request conflicts with the following ones:

#16411 (Signet support by kallewoof)
#16400 ([refactor] Rewrite AcceptToMemoryPoolWorker() using smaller parts by sdaftuar)
#16324 (Get cs_main out of the critical path in ProcessMessages by TheBlueMatt)
#16323 (Call ProcessNewBlock() asynchronously by TheBlueMatt)
#15997 (refactor: GuessVerificationProgress requires cs_main lock by promag)
#13868 (Remove unused fScriptChecks parameter from CheckInputs by Empact)

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

ryanofsky

utACK ceca2c9. This looks good and is very straightforward. Feel free to ignore all my suggestions below! (They are not important and possibly not coherent.)

src/validation.cpp

src/validation.h

src/validation.cpp

src/rpc/blockchain.cpp

src/validation.h

src/validation.cpp

src/init.cpp

src/test/setup_common.cpp

src/init.cpp

src/txdb.h

jamesob · 2019-07-24T21:52:05Z

Thanks for the feedback, @ryanofsky. I think I've incorporated all of it.

ariard

ACK d0e1e37 minus pcoinsTip removal.

Also I checked the other access to CoinsViews members via CoinsTip like in src/rpc/blockchain.cpp or src/rpc/rawtransaction.cpp. I've found every to be annotated or with a lock before, but was wandering if we shouldn't rely on EXCLUSIVE_LOCK_REQUIRED if possible and not AssertLockHeld. What's the exact diff between them ?

src/validation.h

ariard · 2019-07-25T01:43:28Z

src/validation.h

+        size_t cache_size_bytes,
+        bool in_memory,
+        bool should_wipe,
+        std::string leveldb_name = "chainstate");


Hmmm is there any risk than having a default leveldb_name cause database collisions for different CChainState at some point ?

This seems like something that would be caught pretty easily in tests if the confusion ever did happen, and I'm not sure if repeating "chainstate" in a few different places inline is any better. That said I'm happy to make this change if others agree it seems worthwhile.

src/validation.h

sipa · 2019-07-25T01:55:15Z

EXCLUSIVE_LOCK_REQUIRED is checked at compile time, but only when the compiler has certain flags enabled (only on Clang, I believe).

AssertLockHeld is checked at runtime when lock debugging is compiled in (available for all compilers, but only enabled in debug builds).

ariard · 2019-07-25T02:01:46Z

Yes EXCLUSIVE_LOCK_REQUIRED is defined in threadsafety.h and is part of Clang static analysis on Mac OS X. But reviewing last commit, e.g in ActivateBestChainStep we only use AssertLockHeld but in fact we should use Clang attribute (or maybe both). Is there a consistent policy on which one to favour ?

jamesob · 2019-07-25T15:30:52Z

Thanks for the look, @ariard. Feedback pushed.

ryanofsky

utACK c860b44. There have just been a lot of small changes since last review: rebase for bilingual_str, many new code comments and commit comments, more MakeUniques and c++ references replacing raw pointers, avoiding recursive cs_main lock in gettxoutsetinfo.

re: #16443 (comment)

Is there a consistent policy on which one to favour ?

It's good to use EXCLUSIVE_LOCK_REQUIRED wherever possible. AssertLockHeld is older and not used as much recently, but still useful for compilers other than clang and cases where clang annotations don't work (sometimes when there are private mutexes, locks in callbacks and virtual methods).

maflcko · 2019-07-26T10:51:26Z

https://clang.llvm.org/docs/ThreadSafetyAnalysis.html#known-limitations

maflcko · 2019-07-26T12:15:11Z

In commit 53c8d59 refactor: have CCoins* data managed under CChainState

   - The initialization order in init.cpp is changed slightly: the coinsdb (leveldb)
      creation is moved to be earlier than block index and genesis block loading,
      though this shouldn't have any noticeable effect.

Could you elaborate a bit more why it is save to flush the chainstate when shutdown is requested during the init sequence? As I read the code, previously we wouldn't flush and now we flush an empty db (potentially not having the best block hash set, because genesis is not loaded?).

maflcko

ACK c860b44, code looks good overall. Running into segfaults when testing

Show signature and timestamp

Signature:

Timestamp of file with hash ccd43c0d933c3fca4055f6f6006fddbebd4ec81c67d0810961187dc2dab9838d -

maflcko · 2019-07-26T12:35:21Z

src/validation.cpp

 {
-    CBlockIndex *pindexDelete = m_chain.Tip();
+    CBlockIndex* pindexDelete = m_chain.Tip();


Why are you removing the mempool lock annotation? Aren't the lock annotations in the header correct?

Ah you're right - dumb mistake on my part.

maflcko · 2019-07-26T12:35:30Z

src/validation.cpp

@@ -2297,7 +2326,8 @@ class ConnectTrace {
 *
 * The block is added to connectTrace if connection succeeds.
 */
-bool CChainState::ConnectTip(CValidationState& state, const CChainParams& chainparams, CBlockIndex* pindexNew, const std::shared_ptr<const CBlock>& pblock, ConnectTrace& connectTrace, DisconnectedBlockTransactions &disconnectpool)
+bool CChainState::ConnectTip(CValidationState& state, const CChainParams& chainparams, CBlockIndex* pindexNew, const std::shared_ptr<const CBlock>& pblock, ConnectTrace& connectTrace, DisconnectedBlockTransactions& disconnectpool)
+    EXCLUSIVE_LOCKS_REQUIRED(::cs_main)


maflcko · 2019-07-26T12:35:45Z

I am seeing segmentation faults when shutting down during init:

==4778== Thread 9 bitcoin-shutoff:
==4778== Invalid read of size 4
==4778==    at 0x4953BC: FlushBlockFile(bool) (validation.cpp:1548)
==4778==    by 0x496B76: CChainState::FlushStateToDisk(CChainParams const&, CValidationState&, FlushStateMode, int) (validation.cpp:2061)
==4778==    by 0x497AB5: CChainState::ForceFlushStateToDisk() (validation.cpp:2115)
==4778==    by 0x32AE19: Shutdown(InitInterfaces&) (init.cpp:239)
==4778==    by 0x223F6F: BitcoinCore::shutdown() (bitcoin.cpp:161)
==4778==    by 0x58F4BF9: QObject::event(QEvent*) (in /usr/lib64/libQt5Core.so.5.12.4)
==4778==    by 0x4BFCAF5: QApplicationPrivate::notify_helper(QObject*, QEvent*) (in /usr/lib64/libQt5Widgets.so.5.12.4)
==4778==    by 0x4C05E7F: QApplication::notify(QObject*, QEvent*) (in /usr/lib64/libQt5Widgets.so.5.12.4)
==4778==    by 0x58C9AE7: QCoreApplication::notifyInternal2(QObject*, QEvent*) (in /usr/lib64/libQt5Core.so.5.12.4)
==4778==    by 0x58CCA92: QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) (in /usr/lib64/libQt5Core.so.5.12.4)
==4778==    by 0x591EE46: ??? (in /usr/lib64/libQt5Core.so.5.12.4)
==4778==    by 0x6F2EEDC: g_main_context_dispatch (in /usr/lib64/libglib-2.0.so.0.6000.5)
==4778==  Address 0x4 is not stack'd, malloc'd or (recently) free'd
==4778== 
==4778== 
==4778== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==4778==  Access not within mapped region at address 0x4
==4778==    at 0x4953BC: FlushBlockFile(bool) (validation.cpp:1548)
==4778==    by 0x496B76: CChainState::FlushStateToDisk(CChainParams const&, CValidationState&, FlushStateMode, int) (validation.cpp:2061)
==4778==    by 0x497AB5: CChainState::ForceFlushStateToDisk() (validation.cpp:2115)
==4778==    by 0x32AE19: Shutdown(InitInterfaces&) (init.cpp:239)
==4778==    by 0x223F6F: BitcoinCore::shutdown() (bitcoin.cpp:161)
==4778==    by 0x58F4BF9: QObject::event(QEvent*) (in /usr/lib64/libQt5Core.so.5.12.4)
==4778==    by 0x4BFCAF5: QApplicationPrivate::notify_helper(QObject*, QEvent*) (in /usr/lib64/libQt5Widgets.so.5.12.4)
==4778==    by 0x4C05E7F: QApplication::notify(QObject*, QEvent*) (in /usr/lib64/libQt5Widgets.so.5.12.4)
==4778==    by 0x58C9AE7: QCoreApplication::notifyInternal2(QObject*, QEvent*) (in /usr/lib64/libQt5Core.so.5.12.4)
==4778==    by 0x58CCA92: QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) (in /usr/lib64/libQt5Core.so.5.12.4)
==4778==    by 0x591EE46: ??? (in /usr/lib64/libQt5Core.so.5.12.4)
==4778==    by 0x6F2EEDC: g_main_context_dispatch (in /usr/lib64/libglib-2.0.so.0.6000.5)

jamesob · 2019-07-26T16:10:11Z

Good catches, @MarcoFalke! I've pushed fixes, including e4b3247 to solve the init bug you found. There are a few ways of addressing that one but I think an early exit from FlushStateToDisk() is the cleanest since it doesn't involve partial construction of CoinsViews or introducing more have-I-initialized-yet state, but let me know if you think there's a better way.

ryanofsky · 2019-07-26T17:41:09Z

In commit 53c8d59 refactor: have CCoins* data managed under CChainState
   - The initialization order in init.cpp is changed slightly: the coinsdb (leveldb)
      creation is moved to be earlier than block index and genesis block loading,
      though this shouldn't have any noticeable effect.
Could you elaborate a bit more why it is save to flush the chainstate when shutdown is requested during the init sequence?

I'm also curious about the answer to this. Would be good to say what's motivating the move in the comment. I guess I also had a similar question previously: #15606 (comment)

jamesob · 2019-07-26T19:53:28Z

@ryanofsky @MarcoFalke good points. I've abandoned trying to reorder the init.cpp stuff and now have separated the construction of CChainState from CoinsViews to preserve the existing order.

ryanofsky

utACK 4e307e5. Only changes since last review are adding and using little InitCoinsViews / HasCoinsViews helpers so the init order doesn't have to change, and reverting the new FlushStateToDisk check which is no longer needed because the init order is not changing. Also, Marco's name is now added to the credits, but I can live with that.

-Thanks to Russell Yanofsky for helpful feedback.
+Thanks to Russell Yanofsky and Marco Falke for helpful feedback.

ariard

ACK 4e307e5 (reviewed changes since last one and ran tests)

ariard · 2019-07-31T00:09:29Z

src/validation.cpp

@@ -314,7 +314,8 @@ bool CheckSequenceLocks(const CTxMemPool& pool, const CTransaction& tx, int flag
 // Returns the script flags which should be checked for a given block
 static unsigned int GetBlockScriptFlags(const CBlockIndex* pindex, const Consensus::Params& chainparams);

-static void LimitMempoolSize(CTxMemPool& pool, size_t limit, unsigned long age) EXCLUSIVE_LOCKS_REQUIRED(pool.cs)
+static void LimitMempoolSize(CTxMemPool& pool, size_t limit, unsigned long age)
+    EXCLUSIVE_LOCKS_REQUIRED(pool.cs, ::cs_main)


Based on above discussion on lock annotations, you may use also AssertLockHeld here and in UpdateTip
(also AcceptToMemoryPoolWithTime, DisconnectTip, ConnectTip)

maflcko · 2019-07-31T12:08:37Z

ACK 4e307e5 (only checked that my name is in the credits, did not look at the changes)

Show signature and timestamp

Signature:

Timestamp of file with hash 055fc53ddab45b0500c4174e6690d5cf015f456b1806475966f66a2d74e0de0c -

src/init.cpp

src/validation.h

src/validation.cpp

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. Construction of its various pieces (db, coinscatcher, in-memory cache) is split up so that we avoid flushing bad state to disk if startup is interrupted. We also introduce `CChainState::CanFlushToDisk()` which tells us when it is safe to flush the chainstate based on this partial construction. This commit could be broken into smaller pieces, but it would require more ephemeral diffs to, e.g., temporarily change CCoinsViewDB's constructor invocations. Other changes: - A parameter has been added to the CCoinsViewDB constructor that allows the name of the corresponding leveldb directory to be specified. Thanks to Russell Yanofsky and Marco Falke for helpful feedback.

i.e. any CoinsViews members. Adds a lock acquisition to `gettxoutsetinfo` RPC to comply with added annotations. Co-authored-by: Russell Yanofsky <russ@yanofsky.org>

jamesob · 2019-08-15T15:21:32Z

au.coins-under-chainstate.10 -> au.coins-under-chainstate.12

Thanks for finding that stuff @MarcoFalke; fixes pushed.

Sjors · 2019-08-15T16:18:09Z

reACK 582d2cd

maflcko · 2019-08-15T16:46:30Z

ACK 582d2cd

Show signature and timestamp

Signature:

Timestamp of file with hash 8c58c7b1c21f3568020ef04ac438a92aba830446a5172e171b37e02c744d64e0 -

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

Similarly to upstream's -segwitheight argument for tests, we allow also controlling BIP16's activation height with -bip16height. This is used in name_multisig.py; we also include BIP16 in getblockchaininfo with the other buried softforks. Since BIP16 is not yet active in Namecoin (and thus especially not activated from the start), this is useful at least in the forseeable future. Use ::ChainstateActive().CoinsTip() instead of pcoinsTip in the Namecoin code. See bitcoin/bitcoin#16443. Rebranded the privkey / address versions in the updated descriptor_tests unit test.

…ce.cpp Summary: upcoming [[bitcoin/bitcoin#16443 | PR16443]] adds an `#include <txdb.h>` to validation.h which makes zmq want leveldb symbols. this is the first step towards avoiding that and a generally Good Thing To Do. `#include <primitives/block.h>` will do. Test Plan: ninja check check-functional Reviewers: #bitcoin_abc, deadalnix Reviewed By: #bitcoin_abc, deadalnix Differential Revision: https://reviews.bitcoinabc.org/D7550

…tate Summary: Upcoming Core [[bitcoin/bitcoin#16443 | PR16443]] adds `g_chainstate` to validation.cpp, this caused a bit of a havoc with initializaion order of pindexFinalized (also declared in validation.cpp) so I took this opportunity to encapsulate the finalizedBlockIndex pointer into CChainState additionally: * moved an assertion that cs_main lock must be held down to where the actual pointer is accessed, to guarantee that all code paths trigger that. * ~~added an assert to prevent users from changing the finalizationBlockIndex pointer to nullptr~~ Test Plan: cmake .. -DENABLE_SANITIZERS=address ninja all check check-functional Reviewers: #bitcoin_abc, deadalnix Reviewed By: #bitcoin_abc, deadalnix Subscribers: deadalnix Differential Revision: https://reviews.bitcoinabc.org/D7578

Summary: Upcoming Core [[bitcoin/bitcoin#16443 | PR16443]] makes validation.h #include <txdb.h>, which has the unwelcome effect of making zmq transitively #include <leveldb/db.h> which cmake helpfully doesn't make available to it. turns out zmqpublishnotifier.cpp (the only translation unit requiring validation.h) needs it only for ReadBlockFrom disk. This looks like a good place to start to cut things out of the validation TU which is basically responsible for everything right now. This diff moves a few functions related to handling block files into the (tentatively named) readblockfromdisk.cpp translation unit so that zmqpublishnotifier.cpp no longer pulls leveldb transitively. Test Plan: ninja check check-functional Reviewers: #bitcoin_abc, deadalnix Reviewed By: #bitcoin_abc, deadalnix Subscribers: deadalnix Differential Revision: https://reviews.bitcoinabc.org/D7579

Summary: This aliasing makes subsequent commits easier to review; eventually CoinsTip() will return the CCoinsViewCache managed by CChainState. bitcoin/bitcoin@fae6ab6 --- Depends on D7578 and D7579 Partial backport of Core [[bitcoin/bitcoin#16443 | PR16443]] Test Plan: ninja check check-functional Reviewers: #bitcoin_abc, deadalnix Reviewed By: #bitcoin_abc, deadalnix Differential Revision: https://reviews.bitcoinabc.org/D7580

…State Summary: 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. Construction of its various pieces (db, coinscatcher, in-memory cache) is split up so that we avoid flushing bad state to disk if startup is interrupted. We also introduce `CChainState::CanFlushToDisk()` which tells us when it is safe to flush the chainstate based on this partial construction. This commit could be broken into smaller pieces, but it would require more ephemeral diffs to, e.g., temporarily change CCoinsViewDB's constructor invocations. Other changes: - A parameter has been added to the CCoinsViewDB constructor that allows the name of the corresponding leveldb directory to be specified. Thanks to Russell Yanofsky and Marco Falke for helpful feedback. --- bitcoin/bitcoin@5693530 Partial backport of Core [[bitcoin/bitcoin#16443 | PR16443]] Depends on D7580 Test Plan: cmake .. -DENABLE_SANITIZERS=address ninja check check-functional Reviewers: #bitcoin_abc, deadalnix Reviewed By: #bitcoin_abc, deadalnix Differential Revision: https://reviews.bitcoinabc.org/D7581

Summary: i.e. any CoinsViews members. Adds a lock acquisition to `gettxoutsetinfo` RPC to comply with added annotations. Co-authored-by: Russell Yanofsky <russ@yanofsky.org> --- bitcoin/bitcoin@582d2cd Depends on D7581 Concludes backport of Core [[bitcoin/bitcoin#16443 | PR16443]] Test Plan: cmake .. -DENABLE_SANITIZERS=address ninja check check-functional Reviewers: #bitcoin_abc, deadalnix Reviewed By: #bitcoin_abc, deadalnix Differential Revision: https://reviews.bitcoinabc.org/D7582

fanquake added the Refactoring label Jul 23, 2019

maflcko reviewed Jul 23, 2019

View reviewed changes

src/validation.h Outdated Show resolved Hide resolved

src/validation.h Show resolved Hide resolved

src/validation.cpp Outdated Show resolved Hide resolved

src/validation.cpp Outdated Show resolved Hide resolved

src/net_processing.cpp Outdated Show resolved Hide resolved

jamesob force-pushed the 2019-07-au-coins-under-chainstate branch from e56af43 to ceca2c9 Compare July 24, 2019 17:45

DrahtBot added the Needs rebase label Jul 24, 2019

jamesob force-pushed the 2019-07-au-coins-under-chainstate branch from ceca2c9 to cce18b8 Compare July 24, 2019 19:46

ryanofsky approved these changes Jul 24, 2019

View reviewed changes

DrahtBot removed the Needs rebase label Jul 24, 2019

jamesob force-pushed the 2019-07-au-coins-under-chainstate branch 2 times, most recently from 63a3e4e to d0e1e37 Compare July 24, 2019 21:51

ariard approved these changes Jul 25, 2019

View reviewed changes

jamesob force-pushed the 2019-07-au-coins-under-chainstate branch from d0e1e37 to c860b44 Compare July 25, 2019 14:24

ryanofsky approved these changes Jul 26, 2019

View reviewed changes

maflcko reviewed Jul 26, 2019

View reviewed changes

jamesob force-pushed the 2019-07-au-coins-under-chainstate branch from c860b44 to 8cd527d Compare July 26, 2019 16:06

jamesob force-pushed the 2019-07-au-coins-under-chainstate branch from 8cd527d to 4f44bd2 Compare July 26, 2019 16:40

jamesob force-pushed the 2019-07-au-coins-under-chainstate branch from 4f44bd2 to 4e307e5 Compare July 26, 2019 19:49

ryanofsky approved these changes Jul 30, 2019

View reviewed changes

ariard approved these changes Jul 31, 2019

View reviewed changes

maflcko reviewed Aug 15, 2019

View reviewed changes

jamesob force-pushed the 2019-07-au-coins-under-chainstate branch from cdf6afb to c41bcbd Compare August 15, 2019 15:10

Cover UTXO set access with lock annotations

582d2cd

i.e. any CoinsViews members. Adds a lock acquisition to `gettxoutsetinfo` RPC to comply with added annotations. Co-authored-by: Russell Yanofsky <russ@yanofsky.org>

jamesob force-pushed the 2019-07-au-coins-under-chainstate branch from c41bcbd to 582d2cd Compare August 15, 2019 15:20

maflcko merged commit 582d2cd into bitcoin:master Aug 15, 2019

promag mentioned this pull request Aug 19, 2019

fix: GuessVerificationProgress requires cs_main lock #15997

Closed

maflcko mentioned this pull request Sep 8, 2019

[WIP] [FEATURE] RPC: Add command for pruning past ChainTip #16827

Closed

jamesob mentioned this pull request Aug 5, 2021

assumeutxo #15606

Closed

18 tasks

kwvg mentioned this pull request Oct 9, 2021

merge bitcoin#15948, #15976, #16194...: assumeutxo project backports (part 1) dashpay/dash#4498

Merged

kwvg added a commit to kwvg/dash that referenced this pull request Oct 10, 2021

merge bitcoin#16443: have CCoins* data managed under CChainState

1bb2d2b

kwvg added a commit to kwvg/dash that referenced this pull request Oct 10, 2021

merge bitcoin#16443: have CCoins* data managed under CChainState

0384ec2

kwvg added a commit to kwvg/dash that referenced this pull request Oct 16, 2021

merge bitcoin#16443: have CCoins* data managed under CChainState

1617b7c

kwvg added a commit to kwvg/dash that referenced this pull request Oct 16, 2021

merge bitcoin#16443: have CCoins* data managed under CChainState

a69c771

kwvg added a commit to kwvg/dash that referenced this pull request Oct 16, 2021

merge bitcoin#16443: have CCoins* data managed under CChainState

ff22091

kwvg added a commit to kwvg/dash that referenced this pull request Oct 21, 2021

merge bitcoin#16443: have CCoins* data managed under CChainState

96ccf93

kwvg added a commit to kwvg/dash that referenced this pull request Oct 22, 2021

merge bitcoin#16443: have CCoins* data managed under CChainState

84339a4

pravblockc pushed a commit to pravblockc/dash that referenced this pull request Nov 18, 2021

merge bitcoin#16443: have CCoins* data managed under CChainState

1229d63

bitcoin locked as resolved and limited conversation to collaborators Dec 16, 2021

refactor: have CCoins* data managed under CChainState #16443

refactor: have CCoins* data managed under CChainState #16443

Uh oh!

Conversation

jamesob commented Jul 23, 2019

Uh oh!

maflcko left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

DrahtBot commented Jul 23, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Conflicts

Uh oh!

ryanofsky left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

jamesob commented Jul 24, 2019

Uh oh!

ariard left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

ariard Jul 25, 2019

Choose a reason for hiding this comment

Uh oh!

jamesob Jul 25, 2019

Choose a reason for hiding this comment

Uh oh!

Uh oh!

sipa commented Jul 25, 2019

Uh oh!

ariard commented Jul 25, 2019

Uh oh!

jamesob commented Jul 25, 2019

Uh oh!

ryanofsky left a comment

Choose a reason for hiding this comment

Uh oh!

maflcko commented Jul 26, 2019

Uh oh!

maflcko commented Jul 26, 2019

Uh oh!

maflcko left a comment

Choose a reason for hiding this comment

Uh oh!

maflcko Jul 26, 2019

Choose a reason for hiding this comment

Uh oh!

jamesob Jul 26, 2019

Choose a reason for hiding this comment

Uh oh!

maflcko Jul 26, 2019

Choose a reason for hiding this comment

Uh oh!

maflcko commented Jul 26, 2019

Uh oh!

jamesob commented Jul 26, 2019

Uh oh!

ryanofsky commented Jul 26, 2019

Uh oh!

jamesob commented Jul 26, 2019

Uh oh!

ryanofsky left a comment

Choose a reason for hiding this comment

DrahtBot commented Jul 23, 2019 •

edited

Loading