<p>These messages may be confusing, but there is nothing wrong. Let me go over them:</p>
<blockquote>
<p>FlushStateToDisk: write coins cache to disk (coins, kB) completed (s) , OK</p>
</blockquote>
<p>This means that the contents of the validation state cache is written to disk. Without this, you'd need to start over if Bitcoin Core were to shutdown uncleanly (e.g. your machine crashing or power loss).</p>
<p>This regularly happens from time to time, or when the cache grows too big (see further).</p>
<blockquote>
<p>Imported mempool transactions from disk: X succeeded, X failed, X expired, X already there, X waiting for initial broadcast</p>
</blockquote>
<p>This is a log message informing you about the result of unconfirmed transactions being loaded from disk.</p>
<blockquote>
<p>Cache size () exceeds total space ()</p>
</blockquote>
<p>This is giving the reason why the validation cache state is being written to disk: the amount stored in memory grew larger than how much memory Bitcoin Core was configured to use. This is normal. You can let Bitcoin Core grow the cache bigger using the <code>-dbcache</code> command line option, the <code>dbcache=</code> configuration file option, or the &quot;Database cache&quot; setting in the GUI.</p>
<blockquote>
<p>ERROR: AcceptBlockHeader: prev block not found</p>
</blockquote>
<p>A peer gave you a block header which Bitcoin Core couldn't interpret. Bitcoin Core simply ignores this.</p>
<blockquote>
<p>Disconnecting outbound peer XXX for old chain, best known block =</p>
</blockquote>
<p>A peer seemed to be on an invalid or old block, and didn't seem to synchronize with what your Bitcoin Core believes to be the best chain. There is either something wrong with that peer, or it isn't following the same rules. In either case, it's not a peer we'll learn anything useful from. Because the number of connections Bitcoin Core makes is limited, it decided it's better to disconnect this useless peer to make space for another, potentially better, peer.</p>
<blockquote>
<p>ERROR: AcceptBlockHeader: Consensus::ContextualCheckBlockHeader: 000XXX...XXX, bad-diffbits, incorrect proof of work</p>
</blockquote>
<p>A peer gave you an invalid block header. It is ignored.</p>
<blockquote>
<p>What do I have to do?</p>
</blockquote>
<p>Nothing.</p>

CC BY-SA 4.0
2022-06-27T18:43:55.420Z
Hello Peter!

I would like to ask you a question about bitcoin core mepool,


Is it possible not to see my funds because they are in the mempool?

AND OR

If a transaction (bitcoin core) has not succeeded, blocked in the mempool, the entire wallet (wallet.dat) must wait for ONE transaction to be synchronized, to show the entire balance?

do you have an answer ?

Cordially.
signbertrand
CC BY-SA 4.0
2022-06-28T14:00:44.447Z
or, is there a bitcoin cache size to have? a size that: "reads all" / "syncs all" in the dbcache??
signbertrand
CC BY-SA 4.0
2022-06-28T14:06:39.143Z
This isn't a discussion box. If you have more questions, ask them as questions, but please be respective of the time and effort of the volunteers who answer here. Please get someone to translate for you, or it'll get only more frustrating for everyone.
Pieter Wuille
CC BY-SA 4.0
2022-06-28T15:25:08.083Z
so, i've understood...
signbertrand
CC BY-SA 4.0
2024-11-18T17:21:10.607Z
dbcache even if 16 GB can be fully taken. And that's the largest size supported. New version of Core should change it. Computers have more memory nowadays.
pbies
CC BY-SA 4.0
2022-05-19T17:08:10.207Z
Thank you ! a lot, I really understand better, the EVERYTHING!

So I just have to wait?

So I have a chance to see My Pieces, if you know?

if I have a chance, I would like to pay for your work, which must not be simple...!
but is very well explained!

Cordially ! Friends
signbertrand
CC BY-SA 4.0
2022-05-19T17:42:01.400Z
If the problem is that your funds haven't shown up because you're still rescanning or synchronization: yes, they'll only show up when that is done. None of the log messages you quote are related to this at all.
Pieter Wuille
CC BY-SA 4.0
2022-05-19T18:03:59.763Z
Yes!!! I leave the PC on!

But how can I see the trace of the TX or the coins?

By simply waiting ? and I look up the TX and Coins
signbertrand
CC BY-SA 4.0
2022-05-19T18:50:12.107Z
Cordially ... !!
signbertrand
CC BY-SA 4.0
2022-05-19T19:34:55.837Z
error : "I leave the PC on!" NO, I don't close : Bitcoin-qt !
signbertrand
CC BY-SA 4.0
2022-05-20T20:10:21.270Z
do you have a sign of signature bitcoins coins are trusted on client bitcoin-qt ? 
 "FlushStateToDisk: write coins cache to disk : 0 coins and  0 kB) " and 
 "Imported mempool transactions from disk: 0 succeeded, 0 failed, 0 expired, 0 already there, 0 waiting for initial broadcast" It's That ? all imported of mempool and also disk ?
signbertrand
CC BY-SA 4.0
2022-05-20T20:56:48.743Z
I'm sorry, but I have no idea what you are trying to say or ask.
Pieter Wuille
CC BY-SA 4.0
2022-05-20T21:54:52.357Z
I want to talk about my bitcoin coins, I mean, how to find my coins?

should I wait for a particular writing on the debug of bitcoin Core? - Who will say end of synchronization of the old wallet.dat file with the transactions in the mempool with those in the disk, in the blockchain? (and given that the blockchain is downloaded, with BUGs, parcial, but downloaded)
signbertrand
CC BY-SA 4.0
2022-05-20T21:55:00.043Z
or let the software re-sync, "naturally" with nothing to do but wait, so should I wait, leave bitcoin-qt open and do nothing?

I think the command -debug or -debugexclude, no! (because I don't know the output - the outputs)

and run a -rescan command... there, I don't see the point, because I already did that a few days ago...

so any advice?
signbertrand
CC BY-SA 4.0
2022-05-21T02:58:43.957Z
You just need to wait until it is synchronized.
Pieter Wuille
CC BY-SA 4.0
2022-06-04T19:22:52.850Z
It's possible to faster the sync with (if it is the)

Log2_work

OR not ?

the Log2_work sync, are very slowly !


and other faster sync, tell me please ! if it is ! @Pieter Wuille
signbertrand
CC BY-SA 4.0
2022-06-04T19:30:39.657Z
log2_work is just a metric for the amount of hashrate the chain has had. It has nothing to do with progress of synchronization, nor does it contribute to it.
Pieter Wuille
CC BY-SA 4.0
2022-05-19T15:49:21.233Z
2022-05-19T16:00:28.253Z
2022-05-19T16:00:28.253Z
Pieter Wuille
<p>About <code>-dbcache</code>:</p>
<p>Maximum hard coded in Bitcoin Core 28.0 is 16384 MB, which gives 16 GB. For now it is not enough for chainstate reindex as it runs out of space.</p>
<p>I needed to exclusively compile Core for 32 GB of <code>dbcache</code>.</p>

CC BY-SA 4.0
2024-11-18T19:33:15.470Z
2024-11-18T19:33:15.470Z
pbies
<p>Help, with bitcoin core : AFTER the Rescan :</p>
<p>1 - rescan</p>
<p>2 - response output, on the debug file out:</p>
<p>3 - FlushStateToDisk: write coins cache to disk (coins, kB) completed (s) , OK</p>
<p>4 - Imported mempool transactions from disk: X succeeded, X failed, X expired, X already there, X waiting for initial broadcast</p>
<p><em>problems that I don't understand, problems that I can't solve :</em></p>
<p>5 - Problem one : Cache size () exceeds total space ()</p>
<p>6 - Problem two : ERROR: AcceptBlockHeader: prev block not found</p>
<p>7 - with =&gt; Disconnecting outbound peer XXX for old chain, best known block =</p>
<p>8 - and with =&gt; ERROR: AcceptBlockHeader: Consensus::ContextualCheckBlockHeader: 000XXX...XXX, bad-diffbits, incorrect proof of work</p>
<p><em>Sorry for my bad english !</em></p>
<p>What do I have to do ? Help me Please Thanks !</p>

<bitcoin-core><synchronization><cache>
What should I do about these messages in Bitcoin-core's debug-log?
signbertrand
# What should I do about these messages in Bitcoin-core's debug-log?

(Asked by: username_0 on 2022-05-19)

Help, with bitcoin core : AFTER the Rescan :

1 - rescan

2 - response output, on the debug file out:

3 - FlushStateToDisk: write coins cache to disk (coins, kB) completed (s) , OK

4 - Imported mempool transactions from disk: X succeeded, X failed, X expired, X already there, X waiting for initial broadcast

*problems that I don't understand, problems that I can't solve :*

5 - Problem one : Cache size () exceeds total space ()

6 - Problem two : ERROR: AcceptBlockHeader: prev block not found

7 - with => Disconnecting outbound peer XXX for old chain, best known block =

8 - and with => ERROR: AcceptBlockHeader: Consensus::ContextualCheckBlockHeader: 000XXX...XXX, bad-diffbits, incorrect proof of work

*Sorry for my bad english !*

What do I have to do ? Help me Please Thanks !

**Tags:** bitcoin-core, synchronization, cache


---

## 2 answers

### Answer by username_1 on 2022-05-19. Score: 6

These messages may be confusing, but there is nothing wrong. Let me go over them:

> FlushStateToDisk: write coins cache to disk (coins, kB) completed (s) , OK

This means that the contents of the validation state cache is written to disk. Without this, you'd need to start over if Bitcoin Core were to shutdown uncleanly (e.g. your machine crashing or power loss).

This regularly happens from time to time, or when the cache grows too big (see further).

> Imported mempool transactions from disk: X succeeded, X failed, X expired, X already there, X waiting for initial broadcast

This is a log message informing you about the result of unconfirmed transactions being loaded from disk.

> Cache size () exceeds total space ()

This is giving the reason why the validation cache state is being written to disk: the amount stored in memory grew larger than how much memory Bitcoin Core was configured to use. This is normal. You can let Bitcoin Core grow the cache bigger using the `-dbcache` command line option, the `dbcache=` configuration file option, or the "Database cache" setting in the GUI.

> ERROR: AcceptBlockHeader: prev block not found

A peer gave you a block header which Bitcoin Core couldn't interpret. Bitcoin Core simply ignores this.

> Disconnecting outbound peer XXX for old chain, best known block =

A peer seemed to be on an invalid or old block, and didn't seem to synchronize with what your Bitcoin Core believes to be the best chain. There is either something wrong with that peer, or it isn't following the same rules. In either case, it's not a peer we'll learn anything useful from. Because the number of connections Bitcoin Core makes is limited, it decided it's better to disconnect this useless peer to make space for another, potentially better, peer.

> ERROR: AcceptBlockHeader: Consensus::ContextualCheckBlockHeader: 000XXX...XXX, bad-diffbits, incorrect proof of work

A peer gave you an invalid block header. It is ignored.

> What do I have to do?

Nothing.

> **Comments:**
> **username_0**: Thank you ! a lot, I really understand better, the EVERYTHING!  So I just have to wait?  So I have a chance to see My Pieces, if you know?  if I have a chance, I would like to pay for your work, which must not be simple...! but is very well explained!  Cordially ! Friends  
> **username_1**: If the problem is that your funds haven't shown up because you're still rescanning or synchronization: yes, they'll only show up when that is done. None of the log messages you quote are related to this at all.  
> **username_0**: Yes!!! I leave the PC on!  But how can I see the trace of the TX or the coins?  By simply waiting ? and I look up the TX and Coins  
> **username_0**: Cordially ... !!  
> **username_0**: error : "I leave the PC on!" NO, I don't close : Bitcoin-qt !  
> **username_0**: do you have a sign of signature bitcoins coins are trusted on client bitcoin-qt ?   "FlushStateToDisk: write coins cache to disk : 0 coins and  0 kB) " and   "Imported mempool transactions from disk: 0 succeeded, 0 failed, 0 expired, 0 already there, 0 waiting for initial broadcast" It's That ? all imported of mempool and also disk ?  
> **username_1**: I'm sorry, but I have no idea what you are trying to say or ask.  
> **username_0**: I want to talk about my bitcoin coins, I mean, how to find my coins?  should I wait for a particular writing on the debug of bitcoin Core? - Who will say end of synchronization of the old wallet.dat file with the transactions in the mempool with those in the disk, in the blockchain? (and given that the blockchain is downloaded, with BUGs, parcial, but downloaded)  
> **username_0**: or let the software re-sync, "naturally" with nothing to do but wait, so should I wait, leave bitcoin-qt open and do nothing?  I think the command -debug or -debugexclude, no! (because I don't know the output - the outputs)  and run a -rescan command... there, I don't see the point, because I already did that a few days ago...  so any advice?  
> **username_1**: You just need to wait until it is synchronized.  
> **username_0**: It's possible to faster the sync with (if it is the)  Log2_work  OR not ?  the Log2_work sync, are very slowly !   and other faster sync, tell me please ! if it is ! @username_1  
> **username_1**: log2_work is just a metric for the amount of hashrate the chain has had. It has nothing to do with progress of synchronization, nor does it contribute to it.  
> **username_0**: Hello Peter!  I would like to ask you a question about bitcoin core mepool,   Is it possible not to see my funds because they are in the mempool?  AND OR  If a transaction (bitcoin core) has not succeeded, blocked in the mempool, the entire wallet (wallet.dat) must wait for ONE transaction to be synchronized, to show the entire balance?  do you have an answer ?  Cordially.  
> **username_0**: or, is there a bitcoin cache size to have? a size that: "reads all" / "syncs all" in the dbcache??  
> **username_1**: This isn't a discussion box. If you have more questions, ask them as questions, but please be respective of the time and effort of the volunteers who answer here. Please get someone to translate for you, or it'll get only more frustrating for everyone.  
> **username_0**: so, i've understood...  
> **username_2**: dbcache even if 16 GB can be fully taken. And that's the largest size supported. New version of Core should change it. Computers have more memory nowadays.  

---

### Answer by username_2 on 2024-11-18. Score: 0

About `-dbcache`:

Maximum hard coded in Bitcoin Core 28.0 is 16384 MB, which gives 16 GB. For now it is not enough for chainstate reindex as it runs out of space.

I needed to exclusively compile Core for 32 GB of `dbcache`.


---

