log: frequent `CreateNewBlock()` log lines on 32.x with electrum server #36334

willcl-ark commented at 7:08 AM on September 25, 2026: member

Is there an existing issue for this?

I have searched the existing issues

Current behaviour

When running a 32.x node with the new mempool-based fee estimator in a stack with electrs, which forwards Electrum blockchain.estimatefee requests to bitcoind’s estimatesmartfee, we are regularly presented with a log line of the form:

2026-09-24T19:53:08Z CreateNewBlock(): block weight: 3992645 txs: 4104 fees: 7564873 sigops 12469

...as the mempool-based estimator constructs a block to calculate fee estimates.

This was notable to me as it seems that electrs polls this RPC every 30 seconds, which means my debug log is filled with many of these lines and can end up looking rather "spammy" (see log excerpt below). And worse, they can't be turned off.

I have also heard reports of similar CreateNewBlock() log-filling when using sv2 ipc mining (where it is significantly more frequent).

Expected behaviour

I might expect that I'd be able to enable/disable such a log line; perhaps we might want to consider moving the log line behind a [mining] or other debug log level?

Steps to reproduce

Run bitcoind 32.x with electrs or with an IPC-connected sv2 miner.

Relevant log output

2026-09-24T18:59:29Z CreateNewBlock(): block weight: 3992584 txs: 6710 fees: 751068 sigops 8189
2026-09-24T18:59:59Z CreateNewBlock(): block weight: 3992713 txs: 6671 fees: 813257 sigops 8272
2026-09-24T19:00:29Z CreateNewBlock(): block weight: 3992626 txs: 6514 fees: 971589 sigops 8467
2026-09-24T19:00:59Z CreateNewBlock(): block weight: 3992670 txs: 6287 fees: 1094273 sigops 8792
2026-09-24T19:01:29Z CreateNewBlock(): block weight: 3992544 txs: 6130 fees: 1178317 sigops 8976
2026-09-24T19:01:59Z CreateNewBlock(): block weight: 3992619 txs: 5967 fees: 1263305 sigops 9161
2026-09-24T19:02:07Z Saw new header hash=000000000000000000012705d1440a631dc30631ad1f0ab49add116f2006fe87 height=968443 peer=535
2026-09-24T19:02:07Z UpdateTip: new best=000000000000000000012705d1440a631dc30631ad1f0ab49add116f2006fe87 height=968443 version=0x36000000 log2_work=96.366525 tx=1445920889 date='2026-09-24T19:01:54Z' progress=1.000000 cache=170.1MiB(1302321txo)
2026-09-24T19:02:29Z CreateNewBlock(): block weight: 3992798 txs: 7028 fees: 398486 sigops 7596
2026-09-24T19:02:29Z New block-relay-only peer connected: transport: v2, version: 70016, peer=2034, mapped_as=42275
2026-09-24T19:02:59Z CreateNewBlock(): block weight: 3992777 txs: 6719 fees: 500889 sigops 7760
2026-09-24T19:03:29Z CreateNewBlock(): block weight: 3992731 txs: 6498 fees: 591316 sigops 8051
2026-09-24T19:03:59Z CreateNewBlock(): block weight: 3992809 txs: 6411 fees: 651116 sigops 8160
2026-09-24T19:04:29Z CreateNewBlock(): block weight: 3992743 txs: 6235 fees: 757136 sigops 8333
2026-09-24T19:04:59Z CreateNewBlock(): block weight: 3992639 txs: 6190 fees: 804384 sigops 8438
2026-09-24T19:05:29Z CreateNewBlock(): block weight: 3992664 txs: 6138 fees: 920774 sigops 8431
2026-09-24T19:05:59Z CreateNewBlock(): block weight: 3992458 txs: 6090 fees: 1006546 sigops 8435
2026-09-24T19:06:29Z CreateNewBlock(): block weight: 3992636 txs: 6091 fees: 1061654 sigops 8422
2026-09-24T19:06:59Z CreateNewBlock(): block weight: 3992719 txs: 6020 fees: 1130980 sigops 8605
2026-09-24T19:07:29Z CreateNewBlock(): block weight: 3992452 txs: 5983 fees: 1182920 sigops 8713
2026-09-24T19:07:59Z CreateNewBlock(): block weight: 3992797 txs: 5928 fees: 1269561 sigops 8804
2026-09-24T19:08:29Z CreateNewBlock(): block weight: 3992812 txs: 5896 fees: 1320182 sigops 8813
2026-09-24T19:08:59Z CreateNewBlock(): block weight: 3992782 txs: 5852 fees: 1386118 sigops 8940
2026-09-24T19:09:29Z CreateNewBlock(): block weight: 3992704 txs: 5791 fees: 1435433 sigops 9049
2026-09-24T19:09:59Z CreateNewBlock(): block weight: 3992812 txs: 5741 fees: 1488977 sigops 9159
2026-09-24T19:10:03Z New block-relay-only peer connected: transport: v2, version: 70016, peer=2038
2026-09-24T19:10:29Z CreateNewBlock(): block weight: 3992562 txs: 5595 fees: 1587448 sigops 9336
2026-09-24T19:10:59Z CreateNewBlock(): block weight: 3992729 txs: 5435 fees: 1663288 sigops 9579
2026-09-24T19:11:29Z CreateNewBlock(): block weight: 3992781 txs: 4907 fees: 1820499 sigops 9450
2026-09-24T19:11:59Z CreateNewBlock(): block weight: 3992567 txs: 4837 fees: 1896855 sigops 9587
2026-09-24T19:12:29Z CreateNewBlock(): block weight: 3992676 txs: 4757 fees: 1969578 sigops 9744

How did you obtain Bitcoin Core

Pre-built binaries

What version of Bitcoin Core are you using?

v32.0rc2

Operating system and version

NixOS

Machine specifications

No response

maflcko added this to the milestone 32.0 on Sep 25, 2026

maflcko added the label Utils/log/libs on Sep 25, 2026

sedited commented at 7:19 AM on September 25, 2026: contributor

We already have print_modified_fee in the BlockAssembler. Maybe an analogous field for this line would make sense?

willcl-ark commented at 7:29 AM on September 25, 2026: member

We already have print_modified_fee in the BlockAssembler. Maybe an analogous field for this line would make sense?

Yeah I think something like this would be good to fix it on the fee estimator.

If we end up wanting to add multiple of these though, say, one for sv2 too, a new debug log level might be a better fit; not sure. I've not actually run an sv2 miner myself so have not verified that one and am only imagining what the debug log might look like :)

ismaelsadeeq commented at 10:39 AM on September 25, 2026: member

We already have print_modified_fee in the BlockAssembler. Maybe an analogous field for this line would make sense?

This is a minimal fix, but I think a separate mining-log debug category fix would work for both fees and mining (sv2 tp waitnext) (which is more severe because it happens every tick), though it changes behaviour, do we expect the client to parse or attempt to read these logs? cc @Sjors

Sjors commented at 10:45 AM on September 25, 2026: member

a separate mining-log debug category

This seems like a good idea (-debug=mining).

do we expect the client to parse or attempt to read these logs

Not that I know, but we should have a release note, especially for users of getblockblocktemplate.