Mining IPC createNewBlock should not return before IBD is over #33994

issue plebhash openend this issue on December 2, 2025
  1. plebhash commented at 12:10 pm on December 2, 2025: none

    Please describe the feature you’d like to see added.

    Mining IPC createNewBlock should not return before IBD is over

    on SRI bitcoin_core_sv2 crate, we want to wait for IBD is over as part of the bootstrapping processes

    discussing with @ismaelsadeeq and @Shourya742 during BTrust dev day, we came to the conclusion that createNewBlock shouldn’t even return before IBD is over

    Describe the solution you’d like

    Mining IPC createNewBlock should not return before IBD is over

    Describe any alternatives you’ve considered

    isInitialBlockDownload is already available, but it would require us to poll it, which feels a bit backwards with capnproto

    Please leave any additional context

    we’re getting reports of crashes when sv2-tp is connected to v30 during IBD

    https://discord.com/channels/950687892169195530/1179824984592490496/1445351230258937867

  2. plebhash added the label Feature on Dec 2, 2025
  3. ismaelsadeeq commented at 1:47 pm on December 2, 2025: member
    @plebhash It will be nice to get to the root of the issue and see whether it’s bitcoin core or from the template provider. Can you please provide the logs and setups accessible in a text file and not a discord link I think some people might not have discord. cc @Sjors I attempt to reproduce the failure but was not successful yet. blocking createnewblock from creating template during ibd is potential solution and would also delegate the responsibility of polling isinitialblockdownload to the node, which is more ideal IMO. We can just make the thread sleeps and wakes up when we are done with ibd and return an empty block. curious to hear what others think.
  4. Sjors commented at 2:37 pm on December 2, 2025: member

    The problem is that ChainstateManager::IsInitialBlockDownload() uses a fairly relaxed heuristic:

    https://github.com/bitcoin/bitcoin/blob/d0f6d9953a15d7c7111d46dcb76ab2bb18e5dee3/src/validation.cpp#L1998-L2023

    So it latches to true when there’s still a day worth of blocks left to process.

    We could make this function much more precise by having it consider the most proof-of-work (not invalid) header chain. It would then insist that we have all blocks fully downloaded and verified.

    But that might have impacts in other places in the codebase, potentially causing things to get stuck longer than needed just because we’re missing a few recent blocks. So it’s probably better to have a new function like ReallyAtTheTipNow().

    Both the isInitialBlockDownload() and createNewBlock() interface methods could switch to that. It’s better for those methods to wait until we’re really at the tip, because otherwise we start emitting templates for blocks that are guaranteed to be stale.

  5. sipa commented at 2:42 pm on December 2, 2025: member

    You can’t use “active_tip == best_known_block_header” as condition for mining, because an attacker could mine a block, relay the header, and never relay the block. Sure, very expensive, but if the outcome is shutting down other miners, some joker might try it.

    Bitcoin nodes are always synchronizing, and unless you have very strong evidence to the contrary, you should act as if your active tip is the best block on the chain. If we had evidence of a better block, it would be our best tip instead.

    IsInitialBlockDownload() is essentially this very conservative check. Only if you’re really behind it’ll say true.

  6. Sjors commented at 3:11 pm on December 2, 2025: member

    Makes sense. We’ll have to find another method of preventing a burst of new templates while the node churns through the last day worth of blocks.

    The Template Provider client could simply wait 1 minute at startup if IBD was initially true and changed to false. In practice that only happens after the node restarts (we wouldn’t want to waste one minute each time the TP restarts).

  7. plebhash commented at 3:14 pm on December 2, 2025: none

    Can you please provide the logs and setups accessible in a text file and not a discord link I think some people might not have discord.

    yeah sorry I was in a hurry for the workshop, indeed pasting Discord links is not ideal

    this is what @jbesraa said:

    I think handling IBD and other initialization aspects is critical when working in production env. As these two services need to set on the same machine you usually deploy them through the same “task” and I think they should wait for each other to come fully available until they connect. I did observe issues with core30/tp when it is restarted alongside sv2-tp(this is actually very consistent error that iam still investigating):

    0./node/interfaces.cpp:980 chainman: Assertion `m_node.chainman' failed.

    also sv2-tp seem to be handling initial IBD fine for some period but then something happen:

    02025-12-02T09:12:18Z [sv2:trace] Waiting to come out of IBD

    I can see this is printed while core is downloading but then core reach 100%

    0   
12025-12-02T09:34:17Z UpdateTip: new best=000000000000000000010925227dbff92c7e5d41d120cec541487f4fcde6d71c height=926118 version=0x2e9ea000 log2_work=95.967332 tx=1278190156 date='2025-12-02T09:33:49Z' progress=1.000000 cache=587.5MiB(4072609txo)

    but I dont see logs from sv2-tp

    i think (2) is really just logging and sv2-tp is just working after that but (1) is kinda a problem(might actually be more core problem than sv2-tp)

    I think @jbesraa knows how to reproduce it deterministically?

  8. plebhash commented at 3:35 pm on December 2, 2025: none

    IsInitialBlockDownload() is essentially this very conservative check. Only if you’re really behind it’ll say true.

    how far behind? are we talking ~2, ~20 or ~200 blocks behind?

  9. sipa commented at 3:37 pm on December 2, 2025: member

    how far behind? are we talking ~2, ~20 or ~200 blocks behind?

    A day.

  10. jbesraa commented at 5:14 pm on December 2, 2025: none

    Can you please provide the logs and setups accessible in a text file and not a discord link I think some people might not have discord.

    yeah sorry I was in a hurry for the workshop, indeed pasting Discord links is not ideal

    this is what @jbesraa said:

    I think handling IBD and other initialization aspects is critical when working in production env. As these two services need to set on the same machine you usually deploy them through the same “task” and I think they should wait for each other to come fully available until they connect. I did observe issues with core30/tp when it is restarted alongside sv2-tp(this is actually very consistent error that iam still investigating):

    0./node/interfaces.cpp:980 chainman: Assertion `m_node.chainman' failed.

    also sv2-tp seem to be handling initial IBD fine for some period but then something happen:

    02025-12-02T09:12:18Z [sv2:trace] Waiting to come out of IBD

    I can see this is printed while core is downloading but then core reach 100%

    0   
12025-12-02T09:34:17Z UpdateTip: new best=000000000000000000010925227dbff92c7e5d41d120cec541487f4fcde6d71c height=926118 version=0x2e9ea000 log2_work=95.967332 tx=1278190156 date='2025-12-02T09:33:49Z' progress=1.000000 cache=587.5MiB(4072609txo)

    but I dont see logs from sv2-tp

    i think (2) is really just logging and sv2-tp is just working after that but (1) is kinda a problem(might actually be more core problem than sv2-tp)

    I think @jbesraa knows how to reproduce it deterministically?

    Oh hey.

    As mentioned in the original comment, I think there is mainly a problem with (1). A bit of info about our setup:

    We run both sv2-tp(by sjors, version 1.0.4) and core 30 via docker on the same (aws)linux EC2 machine. When starting fresh setup, its usually smooth but whenever we need to update a config or something similar and restart the setup, we encounter the following:

    sv2-tp logs (some data is redacted due to security reasons)

     02025-11-28T13:40:39Z Default data directory
 12025-11-28T13:40:39Z Using data directory 
 22025-11-28T13:40:39Z Config file: 
 32025-11-28T13:40:39Z Command-line arg: datadir=
 42025-11-28T13:40:39Z Command-line arg: debug=sv2
 52025-11-28T13:40:39Z Command-line arg: ipcconnect=unix:/run/bitcoin/node.sock
 62025-11-28T13:40:39Z Command-line arg: loglevel=
 72025-11-28T13:40:39Z Command-line arg: sv2bind=
 82025-11-28T13:40:39Z Command-line arg: sv2port=
 92025-11-28T13:40:39Z Using the 'sse4(1way),sse41(4way),avx2(8way)' SHA256 implementation
102025-11-28T13:40:39Z Using RdSeed as an additional entropy source
112025-11-28T13:40:39Z Using RdRand as an additional entropy source
122025-11-28T13:40:39Z [ipc:info] {sv2-tp-1/sv2-tp-1} IPC client first request from current thread, constructing waiter
13Connected to bitcoin-node
142025-11-28T13:40:39Z [sv2] Reading cached static key from
152025-11-28T13:40:39Z [sv2:info] Static key: 
162025-11-28T13:40:39Z [sv2:info] Template Provider authority key: 
172025-11-28T13:40:39Z [sv2:trace] Authority key: 
182025-11-28T13:40:39Z [sv2:trace] Certificate hashed data: 
192025-11-28T13:40:39Z [sv2:info] Template Provider listening on 
202025-11-28T13:40:39Z  thread start
212025-11-28T13:40:39Z sv2 thread start
222025-11-28T13:40:39Z [ipc:info] {sv2-tp-1/b-sv2-9} IPC client first request from current thread, constructing waiter
232025-11-28T13:40:39Z [ipc:warning] {sv2-tp-1/b-capnp-loop-7} IPC client: unexpected network disconnect.
242025-11-28T13:40:39Z [ipc:error] IPC client method call interrupted by disconnect.
252025-11-28T13:40:39Z 
26************************
27************************
28EXCEPTION: N3ipc9ExceptionE       
29EXCEPTION: N3ipc9ExceptionE       
30IPC client method call interrupted by disconnect.       
31IPC client method call interrupted by disconnect.       
32bitcoin in sv2       
33bitcoin in sv2       
34terminate called after throwing an instance of 'ipc::Exception'
35  what():  IPC client method call interrupted by disconnect.

    core-v30 logs (some data is redacted due to security reasons)

     02025-11-28T13:40:38Z Bitcoin Core version v30.0 (release build)
 12025-11-28T13:40:38Z parameter interaction: -bind set -> setting -listen=1
 22025-11-28T13:40:38Z Using the 'sse4(1way);sse41(4way);avx2(8way)' SHA256 implementation
 32025-11-28T13:40:39Z Using RdSeed as an additional entropy source
 42025-11-28T13:40:39Z Using RdRand as an additional entropy source
 52025-11-28T13:40:39Z Default data directory
 62025-11-28T13:40:39Z Using data directory 
 72025-11-28T13:40:39Z Config file: 
 82025-11-28T13:40:39Z Command-line arg: bind="0.0.0.0"
 92025-11-28T13:40:39Z Command-line arg: chain="main"
102025-11-28T13:40:39Z Command-line arg: datadir=
112025-11-28T13:40:39Z Command-line arg: ipcbind=
122025-11-28T13:40:39Z Command-line arg: port=
132025-11-28T13:40:39Z Command-line arg: printtoconsole=""
142025-11-28T13:40:39Z Command-line arg: prune="1092"
152025-11-28T13:40:39Z Command-line arg: rpcbind=
162025-11-28T13:40:39Z Command-line arg: rpcport=
172025-11-28T13:40:39Z scheduler thread start
182025-11-28T13:40:39Z Listening for IPC requests on address 
192025-11-28T13:40:39Z Using wallet directory 
202025-11-28T13:40:39Z init message: Verifying wallet(s)…
212025-11-28T13:40:39Z Using /16 prefix for IP bucketing
222025-11-28T13:40:39Z init message: Loading P2P addresses…
23./node/interfaces.cpp:980 chainman: Assertion `m_node.chainman' failed.
  11. ryanofsky commented at 6:25 pm on December 2, 2025: contributor

    re: #33994 (comment)

    Makes sense. We’ll have to find another method of preventing a burst of new templates while the node churns through the last day worth of blocks.

    I think the fact that we have separate createNewBlock and waitNext to functions to fetch the initial block template and subsequent ones should make this easier to solve, because createNewBlock can be conservative and wait to return until after some cooldown period, and waitNext can be more responsive and always try to return as quickly as possible. So I think we could just add something like the following to createNewBlock

    0constexpr auto COOLDOWN = 1s;
1while (!interrupted && (GetTime() - last_block_connected_time < COOLDOWN) && active_tip != best_known_block_header) {
2    cv.wait_for(lock, COOLDOWN);
3}

    Checking best_known_block_header would just be an optimization. This wouldn’t wait longer than the cooldown period to return after the last block was connected.

  12. Sjors commented at 6:56 pm on December 2, 2025: member

    @ryanofsky wrote:

    GetTime() - last_block_connected_time < COOLDOWN @jbesraa:

    That looks nice, and would keep client code simple.

    We run both sv2-tp(by sjors, version 1.0.4)

    You should upgrade to v1.0.5 :-)

    and core 30

    At this point I think it’s better to run the 30.x branch built from source if you can. It has quite a few IPC related bug fixes. Otherwise you’re going to hunt for bugs that have already been fixed. Once v30.1 is out it’s fine to switch to a release again.

  13. Sjors referenced this in commit 4a0b81dc8d on Dec 31, 2025
  14. Sjors commented at 5:17 am on December 31, 2025: member
    Implemented the cooldown functionality in #34184.
  15. Sjors referenced this in commit a73a5b603f on Dec 31, 2025
  16. Sjors referenced this in commit 62524ac69c on Dec 31, 2025
  17. Sjors referenced this in commit e8b01c43bb on Dec 31, 2025
  18. plebhash commented at 5:41 pm on January 5, 2026: none
    @Sjors do you think this would land on v30.2 or v31?
  19. Sjors commented at 3:04 am on January 6, 2026: member
    @plebhash if enough people review it, v31 is still a few months away.
  20. Sjors referenced this in commit c02c2832f7 on Jan 22, 2026
  21. Sjors referenced this in commit 9817657d46 on Jan 27, 2026
  22. Sjors referenced this in commit 34e768d992 on Jan 29, 2026
  23. Sjors referenced this in commit fdd1291e96 on Feb 3, 2026
  24. Sjors referenced this in commit 617eb13ec1 on Feb 4, 2026
  25. Sjors referenced this in commit a98510d805 on Feb 4, 2026
  26. Sjors referenced this in commit 0d4cf7041a on Feb 7, 2026
  27. Sjors referenced this in commit 2fa3475bed on Feb 12, 2026
  28. Sjors referenced this in commit 6eac1d5864 on Feb 13, 2026
  29. Sjors referenced this in commit a7d2c2d21c on Feb 13, 2026
  30. Sjors referenced this in commit d92382f09f on Feb 13, 2026
  31. plebhash commented at 2:34 pm on February 18, 2026: none

    while testing on the Sv2 Wizard (which automates deployments of the Sv2 stack, but does not assert IBD is done), we witnessed a segfault on Bitcoin Core 30.2 (which was still doing IBD)

    Image

    cc @Sjors

  32. Sjors commented at 4:46 pm on February 18, 2026: member
    @plebhash a segfault after disconnect sounds like #34284, even if in a different code path. Let’s see if that still happens after #34422 is merged.
  33. Sjors referenced this in commit d5ac2bc64f on Feb 20, 2026
  34. Sjors referenced this in commit a11297a904 on Feb 20, 2026
  35. plebhash commented at 4:40 pm on February 23, 2026: none

    we are seeing Bitcoin Core crash when connected to SRI JDC

    here’s how we reproduced it on a macos with arm64 apple silicon:

    • enter https://stratumprotocol.org/
    • click “Start Mining”
    • follow the wizard to run JDC with docker
    • make sure you’re connecting to SRI community mainnet deployment
    • make sure you launch JDC while Bitcoin Core v30.2 is still doing IBD

    then bitcoin Core crashes with similar logs:

      0p@MacBook-Pro Downloads % ./bitcoin-30.2/bin/bitcoin -m node -ipcbind=unix
  12026-02-23T16:23:17Z Bitcoin Core version v30.2.0 (release build)
  22026-02-23T16:23:17Z Using the 'sse4(1way);sse41(4way)' SHA256 implementation
  32026-02-23T16:23:17Z Default data directory /Users/p/Library/Application Support/Bitcoin
  42026-02-23T16:23:17Z Using data directory /Users/p/Library/Application Support/Bitcoin
  52026-02-23T16:23:17Z Config file: /Users/p/Library/Application Support/Bitcoin/bitcoin.conf
  62026-02-23T16:23:17Z Config file arg: prune="200"
  72026-02-23T16:23:17Z Config file arg: rpcallowip="0.0.0.0/0"
  82026-02-23T16:23:17Z Config file arg: rpcbind="0.0.0.0"
  92026-02-23T16:23:17Z Config file arg: rpcpassword=****
 102026-02-23T16:23:17Z Config file arg: rpcuser=****
 112026-02-23T16:23:17Z Config file arg: server="1"
 122026-02-23T16:23:17Z Setting file arg: prune = "57220"
 132026-02-23T16:23:17Z Setting file arg: wallet = ["novcanik"]
 142026-02-23T16:23:17Z Command-line arg: ipcbind="unix"
 152026-02-23T16:23:17Z Using at most 125 automatic connections (285 file descriptors available)
 162026-02-23T16:23:17Z scheduler thread start
 172026-02-23T16:23:17Z Listening for IPC requests on address unix:/Users/p/Library/Application Support/Bitcoin/node.sock
 182026-02-23T16:23:17Z Binding RPC on address 0.0.0.0 port 8332
 192026-02-23T16:23:17Z WARNING: the RPC server is not safe to expose to untrusted networks such as the public internet
 202026-02-23T16:23:17Z Using rpcuser/rpcpassword authentication.
 212026-02-23T16:23:17Z [warning] The use of rpcuser/rpcpassword is less secure, because credentials are configured in plain text. It is recommended that locally-run instances switch to cookie-based auth, or otherwise to use hashed rpcauth credentials. See share/rpcauth in the source directory for more information.
 222026-02-23T16:23:17Z Starting HTTP server with 16 worker threads
 232026-02-23T16:23:17Z Using wallet directory /Users/p/Library/Application Support/Bitcoin/wallets
 242026-02-23T16:23:17Z init message: Verifying wallet(s)…
 252026-02-23T16:23:17Z Using SQLite Version 3.46.1
 262026-02-23T16:23:17Z Using wallet /Users/p/Library/Application Support/Bitcoin/wallets/novcanik
 272026-02-23T16:23:17Z Using /16 prefix for IP bucketing
 282026-02-23T16:23:17Z init message: Loading P2P addresses…
 292026-02-23T16:23:17Z Loaded 66288 addresses from peers.dat  166ms
 302026-02-23T16:23:17Z init message: Loading banlist…
 312026-02-23T16:23:17Z SetNetworkActive: true
 322026-02-23T16:23:17Z Cache configuration:
 332026-02-23T16:23:17Z * Using 2.0 MiB for block index database
 342026-02-23T16:23:17Z * Using 8.0 MiB for chain state database
 352026-02-23T16:23:17Z * Using 440.0 MiB for in-memory UTXO set (plus up to 286.1 MiB of unused mempool space)
 362026-02-23T16:23:17Z Script verification uses 11 additional threads
 372026-02-23T16:23:17Z Using obfuscation key for blocksdir *.dat files (/Users/p/Library/Application Support/Bitcoin/blocks): '0000000000000000'
 382026-02-23T16:23:17Z Opening LevelDB in /Users/p/Library/Application Support/Bitcoin/blocks/index
 392026-02-23T16:23:17Z Opened LevelDB successfully
 402026-02-23T16:23:17Z Using obfuscation key for /Users/p/Library/Application Support/Bitcoin/blocks/index: 0000000000000000
 412026-02-23T16:23:17Z Using 16 MiB out of 16 MiB requested for signature cache, able to store 524288 elements
 422026-02-23T16:23:17Z Using 16 MiB out of 16 MiB requested for script execution cache, able to store 524288 elements
 432026-02-23T16:23:17Z init message: Loading block index…
 442026-02-23T16:23:17Z Assuming ancestors of block 00000000000000000000611fd22f2df7c8fbd0688745c3a6c3bb5109cc2a12cb have valid signatures.
 452026-02-23T16:23:17Z Setting nMinimumChainWork=0000000000000000000000000000000000000000dee8e2a309ad8a9820433c68
 462026-02-23T16:23:17Z Prune configured to target 57220 MiB on disk for block and undo files.
 472026-02-23T16:23:19Z Loading block index db: last block file = 5409
 482026-02-23T16:23:19Z Loading block index db: last block file info: CBlockFileInfo(blocks=47, size=65771086, heights=937945...937991, time=2026-02-23...2026-02-23)
 492026-02-23T16:23:19Z Checking all blk files are present...
 502026-02-23T16:23:19Z Loading block index db: Block files have previously been pruned
 512026-02-23T16:23:20Z Initializing chainstate Chainstate [ibd] @ height -1 (null)
 522026-02-23T16:23:20Z Opening LevelDB in /Users/p/Library/Application Support/Bitcoin/chainstate
 532026-02-23T16:23:20Z Opened LevelDB successfully
 542026-02-23T16:23:20Z Using obfuscation key for /Users/p/Library/Application Support/Bitcoin/chainstate: ce0efc211ec92aaf
 552026-02-23T16:23:20Z Loaded best chain: hashBestChain=00000000000000000001bd96c5201616a5c58aa6460f0d926cae714223666c93 height=937991 date=2026-02-23T16:17:08Z progress=0.999998
 562026-02-23T16:23:20Z init message: Verifying blocks…
 572026-02-23T16:23:20Z CreateNewBlock(): block weight: 812 txs: 0 fees: 0 sigops 0
 582026-02-23T16:23:20Z Verifying last 6 blocks at level 3
 592026-02-23T16:23:20Z Verification progress: 0%
 602026-02-23T16:23:20Z Verification progress: 16%
 612026-02-23T16:23:20Z Verification progress: 33%
 622026-02-23T16:23:21Z Verification progress: 50%
 632026-02-23T16:23:21Z Verification progress: 66%
 642026-02-23T16:23:21Z [ipc:info] {bitcoin-node-32628/b-capnp-loop-621785} IPC server destroy N2mp11ProxyServerIN3ipc5capnp8messages6MiningEEE
 652026-02-23T16:23:21Z [ipc:info] {bitcoin-node-32628/b-capnp-loop-621785} IPC server: socket disconnected.
 662026-02-23T16:23:21Z [ipc:info] {bitcoin-node-32628/b-capnp-loop-621785} IPC server destroy N2mp11ProxyServerIN3ipc5capnp8messages4InitEEE
 672026-02-23T16:23:21Z Verification progress: 83%
 682026-02-23T16:23:21Z Verification progress: 99%
 692026-02-23T16:23:21Z Verification: No coin database inconsistencies in last 6 blocks (8097 transactions)
 702026-02-23T16:23:21Z Block index and chainstate loaded
 712026-02-23T16:23:21Z CreateNewBlock(): block weight: 812 txs: 0 fees: 0 sigops 0
 722026-02-23T16:23:21Z Using SQLite Version 3.46.1
 732026-02-23T16:23:21Z Using wallet /Users/p/Library/Application Support/Bitcoin/wallets/novcanik
 742026-02-23T16:23:21Z init message: Loading wallet…
 752026-02-23T16:23:21Z [novcanik] Last client version = 300200
 762026-02-23T16:23:21Z [novcanik] Descriptors: 8, Descriptor Keys: 0 plaintext, 1 encrypted, 1 total.
 772026-02-23T16:23:21Z [novcanik] Setting spkMan to active: id = edb28fd27a4b47ae0e316603d3991cafad2f7e6fdcb096a89fdafcd34627702c, type = legacy, internal = false
 782026-02-23T16:23:21Z [novcanik] Setting spkMan to active: id = f7aada836e876af423ca3e80339506f90d3bbf4a8c024b353967dd3161ff8be5, type = p2sh-segwit, internal = false
 792026-02-23T16:23:21Z [novcanik] Setting spkMan to active: id = 1fcb15c6c2ee3a63f4a890bfdc69bc97a17d1f32a46337603511fcc8a37e95b3, type = bech32, internal = false
 802026-02-23T16:23:21Z [novcanik] Setting spkMan to active: id = 995dd7b253d565466fba909ffe67ca8ab2cb1794f7fc604fcce7e36ff8b0f8c8, type = bech32m, internal = false
 812026-02-23T16:23:21Z [novcanik] Setting spkMan to active: id = ad8668ef94ea7747a80402b8f466852bfca8780e321dcb67418cb4584f6b9978, type = legacy, internal = true
 822026-02-23T16:23:21Z [novcanik] Setting spkMan to active: id = 4375208e97ac934895c2cce4e70a04193ab53cd445dfc00ba92d96136eba7fa1, type = p2sh-segwit, internal = true
 832026-02-23T16:23:21Z [novcanik] Setting spkMan to active: id = 951c97ac022ad382ea68f3ec073fd41c5170513d0e8c430ad51320bb313abff7, type = bech32, internal = true
 842026-02-23T16:23:21Z [novcanik] Setting spkMan to active: id = dfba5b81e3aa1473f58553f63eea5ba12b7ef5fe2f209ec665701b0d8292ab42, type = bech32m, internal = true
 852026-02-23T16:23:21Z [novcanik] Wallet completed loading in             235ms
 862026-02-23T16:23:21Z [novcanik] setKeyPool.size() = 8000
 872026-02-23T16:23:21Z [novcanik] mapWallet.size() = 0
 882026-02-23T16:23:21Z [novcanik] m_address_book.size() = 2
 892026-02-23T16:23:21Z init message: Pruning blockstore…
 902026-02-23T16:23:21Z initload thread start
 912026-02-23T16:23:21Z block tree size = 937993
 922026-02-23T16:23:21Z nBestHeight = 937991
 932026-02-23T16:23:21Z mapport thread start
 942026-02-23T16:23:21Z Loading 1814 mempool transactions from file...
 952026-02-23T16:23:21Z torcontrol thread start
 962026-02-23T16:23:21Z Bound to 127.0.0.1:8334
 972026-02-23T16:23:21Z Bound to [::]:8333
 982026-02-23T16:23:21Z Leaving InitialBlockDownload (latching to false)
 992026-02-23T16:23:21Z Bound to 0.0.0.0:8333
1002026-02-23T16:23:21Z Loaded 2 addresses from "anchors.dat"
1012026-02-23T16:23:21Z 2 block-relay-only anchors will be tried for connections.
1022026-02-23T16:23:21Z init message: Starting network threads…
1032026-02-23T16:23:21Z net thread start
1042026-02-23T16:23:21Z dnsseed thread start
1052026-02-23T16:23:21Z addcon thread start
1062026-02-23T16:23:21Z Waiting 300 seconds before querying DNS seeds.
1072026-02-23T16:23:21Z init message: Done loading
1082026-02-23T16:23:21Z msghand thread start
1092026-02-23T16:23:21Z opencon thread start
1102026-02-23T16:23:21Z tor: The only supported authentication mechanism left is password, but no password provided with -torpassword
1112026-02-23T16:23:22Z Progress loading mempool transactions from file: 10% (tried 182, 1632 remaining)
1122026-02-23T16:23:22Z Progress loading mempool transactions from file: 20% (tried 363, 1451 remaining)
1132026-02-23T16:23:22Z Progress loading mempool transactions from file: 30% (tried 545, 1269 remaining)
1142026-02-23T16:23:22Z Progress loading mempool transactions from file: 40% (tried 726, 1088 remaining)
1152026-02-23T16:23:22Z Progress loading mempool transactions from file: 50% (tried 907, 907 remaining)
1162026-02-23T16:23:22Z Progress loading mempool transactions from file: 60% (tried 1089, 725 remaining)
1172026-02-23T16:23:22Z Progress loading mempool transactions from file: 70% (tried 1270, 544 remaining)
1182026-02-23T16:23:22Z Progress loading mempool transactions from file: 80% (tried 1452, 362 remaining)
1192026-02-23T16:23:22Z Progress loading mempool transactions from file: 90% (tried 1633, 181 remaining)
1202026-02-23T16:23:22Z Imported mempool transactions from file: 1814 succeeded, 0 failed, 0 expired, 0 already there, 0 waiting for initial broadcast
1212026-02-23T16:23:22Z initload thread exit
1222026-02-23T16:23:22Z CreateNewBlock(): block weight: 2269527 txs: 1814 fees: 1045954 sigops 3946
123Assertion failed: (m_loop), function operator*, file proxy.h, line 59.
124zsh: abort      ./bitcoin-30.2/bin/bitcoin -m node -ipcbind=unix
  36. plebhash commented at 4:40 pm on February 23, 2026: none

    another way to crash it is to run JDC first, and immediately start Bitcoin Core v30.2 with these logs on tail:

     02026-02-23T16:30:08Z Config file arg: rpcpassword=****
 12026-02-23T16:30:08Z Config file arg: rpcuser=****
 22026-02-23T16:30:08Z Config file arg: server="1"
 32026-02-23T16:30:08Z Setting file arg: prune = "57220"
 42026-02-23T16:30:08Z Setting file arg: wallet = ["novcanik"]
 52026-02-23T16:30:08Z Command-line arg: ipcbind="unix"
 62026-02-23T16:30:08Z Using at most 125 automatic connections (285 file descriptors available)
 72026-02-23T16:30:08Z scheduler thread start
 82026-02-23T16:30:08Z Listening for IPC requests on address unix:/Users/p/Library/Application Support/Bitcoin/node.sock
 9node/interfaces.cpp:980 chainman: Assertion `m_node.chainman' failed.
10zsh: abort      ./bitcoin-30.2/bin/bitcoin -m node -ipcbind=unix
  37. Sjors commented at 4:43 pm on February 23, 2026: member
    @plebhash do these go away with #34422?
  38. jbesraa commented at 5:08 pm on February 23, 2026: none

    another way to crash it is to run JDC first, and immediately start Bitcoin Core v30.2 with these logs on tail:

     02026-02-23T16:30:08Z Config file arg: rpcpassword=****
 12026-02-23T16:30:08Z Config file arg: rpcuser=****
 22026-02-23T16:30:08Z Config file arg: server="1"
 32026-02-23T16:30:08Z Setting file arg: prune = "57220"
 42026-02-23T16:30:08Z Setting file arg: wallet = ["novcanik"]
 52026-02-23T16:30:08Z Command-line arg: ipcbind="unix"
 62026-02-23T16:30:08Z Using at most 125 automatic connections (285 file descriptors available)
 72026-02-23T16:30:08Z scheduler thread start
 82026-02-23T16:30:08Z Listening for IPC requests on address unix:/Users/p/Library/Application Support/Bitcoin/node.sock
 9node/interfaces.cpp:980 chainman: Assertion `m_node.chainman' failed.
10zsh: abort      ./bitcoin-30.2/bin/bitcoin -m node -ipcbind=unix

    I also encountered this with core 30.2 and template provider(by sjors) 1.0.5. It happens when starting core with wrong config and it fails correctly, but then restarting it with correct config takes a try or two to correctly start, in between it throws the above error

  39. ryanofsky commented at 6:40 pm on February 23, 2026: contributor

    From what I can can tell from above it looks node/interfaces.cpp:980 chainman: Assertion m_node.chainman’ failed` happens because the IPC server starts listening for connections before chainman is ready. Listening starts here:

    https://github.com/bitcoin/bitcoin/blob/9581a0a5b18a4d7b22e293b069c731421d6135b1/src/init.cpp#L1497

    before InitAndLoadChainstate constructs ChainstateManager and assigns node.chainman here:

    https://github.com/bitcoin/bitcoin/blob/9581a0a5b18a4d7b22e293b069c731421d6135b1/src/init.cpp#L1868

    We might need to add new signal that mining interface interface can use to know when it is safe to access chainstatemanager, if there is a not an existing one. A nice solution might to initialize the KernelNotifications earlier and use the existing condition variable & mutex there. Probably also we should add a functional test trying to access mining IPC interface before node fully starts up and make sure mining methods wait or return errors and not crash.

    The other reported error Assertion failed: (m_loop), function operator*, file proxy.h, line 59 is more ambiguous and might indicate the same problem or be caused by something different. It would be most useful to have a stack trace from that crash if possible.

    Would also recommend opening new bugs for any newly observed crashes. It should be easier to close bugs as duplicates if necessary than try to track debug multiple problems in a single github thread.

  40. plebhash commented at 8:29 pm on February 23, 2026: none
    @ryanofsky to make sure I understand correctly: neither #34184 nor #34422 fix the root cause of the logs shared above, and we need to open a new issue for that?
  41. jbesraa commented at 8:38 pm on February 23, 2026: none

    another way to crash it is to run JDC first, and immediately start Bitcoin Core v30.2 with these logs on tail:

     02026-02-23T16:30:08Z Config file arg: rpcpassword=****
 12026-02-23T16:30:08Z Config file arg: rpcuser=****
 22026-02-23T16:30:08Z Config file arg: server="1"
 32026-02-23T16:30:08Z Setting file arg: prune = "57220"
 42026-02-23T16:30:08Z Setting file arg: wallet = ["novcanik"]
 52026-02-23T16:30:08Z Command-line arg: ipcbind="unix"
 62026-02-23T16:30:08Z Using at most 125 automatic connections (285 file descriptors available)
 72026-02-23T16:30:08Z scheduler thread start
 82026-02-23T16:30:08Z Listening for IPC requests on address unix:/Users/p/Library/Application Support/Bitcoin/node.sock
 9node/interfaces.cpp:980 chainman: Assertion `m_node.chainman' failed.
10zsh: abort      ./bitcoin-30.2/bin/bitcoin -m node -ipcbind=unix

    I also encountered this with core 30.2 and template provider(by sjors) 1.0.5. It happens when starting core with wrong config and it fails correctly, but then restarting it with correct config takes a try or two to correctly start, in between it throws the above error

    Logs

    Core

     02026-02-23T16:08:23Z Bitcoin Core version v30.2 (release build)
 12026-02-23T16:08:23Z parameter interaction: -bind set -> setting -listen=1
 22026-02-23T16:08:23Z Using the 'sse4(1way);sse41(4way);avx2(8way)' SHA256 implementation
 32026-02-23T16:08:23Z Using RdSeed as an additional entropy source
 42026-02-23T16:08:23Z Using RdRand as an additional entropy source
 52026-02-23T16:08:23Z Default data directory /root/.bitcoin
 62026-02-23T16:08:23Z Using data directory /home/user/.bitcoin
 72026-02-23T16:08:23Z Config file: /home/user/.bitcoin/bitcoin.conf (not found, skipping)
 82026-02-23T16:08:23Z Command-line arg: bind="0.0.0.0"
 92026-02-23T16:08:23Z Command-line arg: datadir="/home/user/.bitcoin"
102026-02-23T16:08:23Z Command-line arg: dbbatchsize="16MB"
112026-02-23T16:08:23Z Command-line arg: ipcbind="unix:/run/bitcoin/node.sock"
122026-02-23T16:08:23Z Command-line arg: server="1"
132026-02-23T16:08:23Z No wallet support compiled in!
142026-02-23T16:08:23Z Listening for IPC requests on address unix:/run/bitcoin/node.sock
152026-02-23T16:08:23Z scheduler thread start
162026-02-23T16:08:23Z Binding RPC on address 0.0.0.0 port 8332
172026-02-23T16:08:23Z Starting HTTP server with 16 worker threads
182026-02-23T16:08:23Z Using /16 prefix for IP bucketing
192026-02-23T16:08:23Z init message: Loading P2P addresses…
20./node/interfaces.cpp:980 chainman: Assertion `m_node.chainman' failed.

    Template provider

     026-02-23T16:08:23Z Default data directory /root/.bitcoin
 12026-02-23T16:08:23Z Using data directory /home/user/.bitcoin
 22026-02-23T16:08:23Z Config file: /home/user/.bitcoin/sv2-tp.conf (not found, skipping)
 32026-02-23T16:08:23Z Command-line arg: datadir=/home/user/.bitcoin
 42026-02-23T16:08:23Z Command-line arg: debug=sv2
 52026-02-23T16:08:23Z Command-line arg: ipcconnect=unix:/run/bitcoin/node.sock
 62026-02-23T16:08:23Z Command-line arg: loglevel=sv2:trace
 72026-02-23T16:08:23Z Command-line arg: sv2bind=0.0.0.0
 82026-02-23T16:08:23Z Command-line arg: sv2feedelta=5000
 92026-02-23T16:08:23Z Command-line arg: sv2interval=5
102026-02-23T16:08:23Z Command-line arg: sv2port=8336
112026-02-23T16:08:23Z Created PID file /home/user/.bitcoin/sv2-tp.pid
122026-02-23T16:08:23Z Starting sv2-tp on main network
132026-02-23T16:08:23Z Using the 'sse4(1way),sse41(4way),avx2(8way)' SHA256 implementation
142026-02-23T16:08:23Z Using RdSeed as an additional entropy source
152026-02-23T16:08:23Z Using RdRand as an additional entropy source
162026-02-23T16:08:23Z Attempting IPC connection to bitcoin-node at unix:/run/bitcoin/node.sock
172026-02-23T16:08:23Z Ensure Bitcoin Core is running with '-ipcbind=unix' and the correct network (main)
182026-02-23T16:08:23Z [ipc:info] {sv2-tp-1/sv2-tp-1} IPC client first request from current thread, constructing waiter
192026-02-23T16:08:23Z Connected to bitcoin-node via IPC at: unix:/run/bitcoin/node.sock
202026-02-23T16:08:23Z [sv2:info] Template Provider listening on 0.0.0.0:8336
212026-02-23T16:08:23Z sv2-tp listening for Stratum v2 connections on 0.0.0.0:8336
222026-02-23T16:08:23Z sv2 thread start
232026-02-23T16:08:23Z [ipc:info] {sv2-tp-1/b-sv2-9} IPC client first request from current thread, constructing waiter
242026-02-23T16:08:23Z  thread start
252026-02-23T16:08:24Z [ipc:error] IPC client method call interrupted by disconnect.
262026-02-23T16:08:24Z 
27************************
28EXCEPTION: N3ipc9ExceptionE       
29IPC client method call interrupted by disconnect.       
30bitcoin in sv2       
312026-02-23T16:08:24Z [ipc:warning] {sv2-tp-1/b-capnp-loop-7} IPC client: unexpected network disconnect.
32************************
33EXCEPTION: N3ipc9ExceptionE       
34IPC client method call interrupted by disconnect.       
35bitcoin in sv2       
36terminate called after throwing an instance of 'ipc::Exception'
37  what():  IPC client method call interrupted by disconnect.
  42. ryanofsky commented at 9:29 pm on February 23, 2026: contributor

    @ryanofsky to make sure I understand correctly: neither #34184 nor #34422 fix the root cause of the logs shared above, and we need to open a new issue for that?

    You should feel free to open a new issue, but now I understand why you posted it here. In my last post I thought the Assertion `m_node.chainman' failed message was an entirely new error, but now I see it was previously mentioned in comments back in December, just not in the original issue description.

    It does look to me like #34184 and #34422 will not fix that error, so there is more work to do here, and that is a reason it could be nice to have a new issue. I’d also say in general any time you see a bug, it’s good to open a new issue clearly describing observed and expected behavior and steps to reproduce if it doesn’t directly duplicate an existing issue, so we can track it and it doesn’t get lost in discussion history.

  43. ryanofsky closed this on Feb 24, 2026
  44. ryanofsky referenced this in commit bd9e0e65f5 on Feb 24, 2026
  45. ryanofsky referenced this in commit 0564f1e449 on Feb 24, 2026
  46. ryanofsky reopened this on Feb 24, 2026
  47. ryanofsky commented at 2:05 pm on February 24, 2026: contributor

    Update: #34184 is merged now which should fix the originally reported issue of createNewBlock returning before IBD is over and I just opened #34661 to fix the Assertion `m_node.chainman' failed crash that can also happen and was originally reported in #33994 (comment).

    There seems to be a third issue: Assertion failed: (m_loop), function operator*, file proxy.h, line 59. crashes reported Feb 18 #33994 (comment) and again Feb 23 #33994 (comment). It is unclear if the Feb 18 and Feb 23 reports are caused by the same bug. In both cases, the error messages are the same and both errors are immediately preceded by CreateNewBlock() log messages. But before the CreateNewBlock() log message, the Feb 18 error is immediately preceded by a client disconnect, while the Feb 23 error is immediately preceded by “initload thread exit” indicating blocks and mempool transactions were just loaded on startup.

    As sjors pointed out, the crash after disconnect could likely fixed by #34422, and I think the crash after initload could be fixed by #34661, so it would be good to have testing with those PRs to see if that’s the case. GDB stack traces & -debug=ipc logs could be helpful too.

  48. ryanofsky referenced this in commit bbc8f1e0a7 on Feb 24, 2026
  49. plebhash commented at 7:19 pm on February 24, 2026: none

    You should feel free to open a new issue @ryanofsky there you go #34664

  50. ryanofsky commented at 9:48 am on February 25, 2026: contributor

    Will close this issue since the requested behavior of making createNewBlock block during IBD was implemented in #34184.

    In the thread there were also reports of createNewBlock calls causing crashes during IBD:

    • Assertion `m_node.chainman' failed crashes that should be fixed by #34661
    • Assertion failed: (m_loop) crash after disconnect which is likely fixed by #34422
    • Assertion failed: (m_loop) crash on early startup that might be fixed by #34184

    We can track these in #34664 and any new problems in new issues

  51. ryanofsky closed this on Feb 25, 2026


plebhash ismaelsadeeq Sjors sipa jbesraa ryanofsky

Labels
Feature

github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bitcoin. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2026-03-03 00:13 UTC
This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me