scripted-diff: rename CChainState -> Chainstate

-BEGIN VERIFY SCRIPT-
sed -i 's/CChainState/Chainstate/g' $(git grep -l CChainState ':(exclude)doc/release-notes*')
-END VERIFY SCRIPT-

Co-authored-by: MacroFake <falke.marco@gmail.com>

2 files changed, 4 insertions, 4 deletions

diff --git a/doc/design/assumeutxo.md b/doc/design/assumeutxo.md
index 2726cf779b..c353c78ff8 100644
--- a/doc/design/assumeutxo.md
+++ b/doc/design/assumeutxo.md
@@ -41,7 +41,7 @@ be of use.
 
 Chainstate within the system goes through a number of phases when UTXO snapshots are
 used, as managed by `ChainstateManager`. At various points there can be multiple
-`CChainState` objects in existence to facilitate both maintaining the network tip and
+`Chainstate` objects in existence to facilitate both maintaining the network tip and
 performing historical validation of the assumed-valid chain.
 
 It is worth noting that though there are multiple separate chainstates, those
@@ -53,7 +53,7 @@ data.
 
 ### "Normal" operation via initial block download
 
-`ChainstateManager` manages a single CChainState object, for which
+`ChainstateManager` manages a single Chainstate object, for which
 `m_snapshot_blockhash` is null. This chainstate is (maybe obviously)
 considered active. This is the "traditional" mode of operation for bitcoind.
 
diff --git a/doc/developer-notes.md b/doc/developer-notes.md
index abd6c7bb59..00c68911ef 100644
--- a/doc/developer-notes.md
+++ b/doc/developer-notes.md
@@ -962,7 +962,7 @@ void CTxMemPool::UpdateTransactionsFromBlock(...)
 
 ```C++
 // validation.h
-class CChainState
+class Chainstate
 {
 protected:
     ...
@@ -983,7 +983,7 @@ public:
 }
 
 // validation.cpp
-bool CChainState::PreciousBlock(BlockValidationState& state, CBlockIndex* pindex)
+bool Chainstate::PreciousBlock(BlockValidationState& state, CBlockIndex* pindex)
 {
     AssertLockNotHeld(m_chainstate_mutex);
     AssertLockNotHeld(::cs_main);