non-Future template not arriving in regtest

[lucasbalieiro]

When running in regtest mode with any TP version above 0.1.15, it appears that a non-Future template never arrives, even after setting sv2feedelta=0.

The configuration for the TP (0.1.19) is as follows:

2025-07-25T20:47:50.126037Z Command-line arg: debug="rpc"
2025-07-25T20:47:50.126046Z Command-line arg: debug="sv2"
2025-07-25T20:47:50.126055Z Command-line arg: fallbackfee="0.0001"
2025-07-25T20:47:50.126063Z Command-line arg: listen="0"
2025-07-25T20:47:50.126073Z Command-line arg: loglevel="sv2:trace"
2025-07-25T20:47:50.126082Z Command-line arg: logtimemicros="1"
2025-07-25T20:47:50.126092Z Command-line arg: regtest=""
2025-07-25T20:47:50.126104Z Command-line arg: rpcport="34433"
2025-07-25T20:47:50.126115Z Command-line arg: sv2=""
2025-07-25T20:47:50.126125Z Command-line arg: sv2feedelta="0"
2025-07-25T20:47:50.126133Z Command-line arg: sv2interval="5"
2025-07-25T20:47:50.126142Z Command-line arg: sv2port="35339"

As seen in the image below, the only reference to a NewTemplate is a future template:

The full log for this TP is available here: debug.log.

For comparison, when using the same parameters with version 0.1.15:

2025-07-26T00:28:01.500759Z Command-line arg: debug="rpc"
2025-07-26T00:28:01.500788Z Command-line arg: debug="sv2"
2025-07-26T00:28:01.500802Z Command-line arg: fallbackfee="0.0001"
2025-07-26T00:28:01.500811Z Command-line arg: listen="0"
2025-07-26T00:28:01.500819Z Command-line arg: loglevel="sv2:trace"
2025-07-26T00:28:01.500828Z Command-line arg: logtimemicros="1"
2025-07-26T00:28:01.500838Z Command-line arg: regtest=""
2025-07-26T00:28:01.500850Z Command-line arg: rpcport="41419"
2025-07-26T00:28:01.500861Z Command-line arg: sv2=""
2025-07-26T00:28:01.500871Z Command-line arg: sv2feedelta="0"
2025-07-26T00:28:01.500880Z Command-line arg: sv2interval="1"
2025-07-26T00:28:01.500888Z Command-line arg: sv2port="33475"
2025-07-26T00:28:01.500894Z Command-line arg: txindex="1"

In the image below, you can see that a non-future template is sent while on regtest:

Additionally, on testnet4, the TP behaves as expected, likely due to the active mempool. This seems to be enough to trigger a non-future template.

It appears that the sv2feedelta=0 parameter is enough to trigger the non-future template in 0.1.15. Since version 0.1.16, this parameter does not seem to have any effect.

---

### Context about what triggered this from the SRI perspective.(It may not be relevant to you, but it could be! 😅 )

SRI currently uses the Template Provider (TP) at version 0.1.15 in its integration tests.

While updating the TP to the latest available version (0.1.19), the following integration test began to fail:

• header_timestamp_value_assertion_in_new_extended_mining_job

The failure occurs when the test awaits a second NewExtendedMiningJob message from the pool to the Translator Proxy:

• Line 138

This breaks the expectation defined in the test:

// The test ensures that:
// - The Template Provider sends valid `SetNewPrevHash` and `NewTemplate` messages.
// - The `minntime` field in the second `NewExtendedMiningJob` message sent to the Translator Proxy
//   matches the `header_timestamp` from the `SetNewPrevHash` message, addressing a bug that
//   occurred with non-future jobs.

Scope of Regression

The test passes on version 0.1.15 but fails consistently on all versions from 0.1.16 onward, including the latest 0.1.19. This suggests that a change introduced between versions 0.1.15 and 0.1.16 caused the discrepancy in behavior.

Environment Details

TP is running in regtest mode with flags defined here:

conf.args.extend(vec![
    "-txindex=1",
    "-sv2",
    &port_arg,
    "-debug=rpc",
    "-debug=sv2",
    &sv2_interval_arg,
    "-sv2feedelta=0",
    "-loglevel=sv2:trace",
    "-logtimemicros=1",
]);

Logs

Attached are:

• Output from running the test manually:

$ pwd
/home/lucasbalieiro/Projects/stratum/test/integration-tests

$ cargo test header_timestamp_value_assertion_in_new_extended_mining_job -- --exact

test.log

• The debug.log from the Template Provider for the same test session.
  debug.log

System Information

Tests were run on:

$ uname -a
Linux 6.15.6-arch1-1 #1 SMP PREEMPT_DYNAMIC Thu, 10 Jul 2025 17:10:18 +0000 x86_64 GNU/Linux

Additional Information

A more detailed log message from the sniffer is present in the logs:

Timeout while waiting for message: NewExtendedMiningJob to go Downstream. Sniffer identifier: header_timestamp_value_assertion_in_new_extended_mining_job pool_translator sniffer

This message was added as part of a local modification to the sniffer to provide more detailed logs. If you run the test from the current master, the message will simply show:

Timeout waiting for message type

You can check the full diff in my fork here: lucasbalieiro/stratum@57dd0d0

[Sjors]

future_template should be:

• true when the tip changes (i.e. a new block was found)
• false when only fees change

When sv2feedelta=0 it should send a new template even when fees are identical. However, not when they go down. But that doesn't seem to be the issue in your example, as fees are simply 0.

From your log I see:

Wait for fees to rise by 0 sat or a new tip,

And then every second it checks if fees have gone up CreateNewBlock(). This should have produced a new template, per:

bitcoin/src/node/miner.cpp

Lines 529 to 541 in 064b01a

	// Calculate the original template total fees if we haven't already
	if (current_fees == -1) {
	current_fees = 0;
	for (CAmount fee : block_template->vTxFees) {
	current_fees += fee;
	}
	}
	CAmount new_fees = 0;
	for (CAmount fee : new_tmpl->vTxFees) {
	new_fees += fee;
	Assume(options.fee_threshold != MAX_MONEY);
	if (new_fees >= current_fees + options.fee_threshold) return new_tmpl;

I'll investigate why that's not working.

As a workaround, I suggest generating some trivial transaction on regtest.

[Sjors]

Tracking this in https://github.com/Sjors/sv2-tp/issues/9