Clarify or drop -sv2interval configuration

[Sjors]

The current documentation is confusing and seems to stem from before sv2-tp became a standalone application communicating over IPC.

In reality it's parsed and stored as m_options.fee_check_interval. It causes fee changes to be ignored for the first -sv2interval seconds.

It was originally intended to limit how often the node would generate a block template internally, but it no longer has that effect.

Additionally it rate limits how often we send new templates downstream, as there may be some overhead for miners to switch templates. But arguably that overhead is already covered by the minimum fee delta.

It now also functions as an interval for how long each waitNext() times out. That's currently still useful because ctrl + c can't interrupt the process with Bitcoin Core v30 (it can on master, since #57).

I'm tempted to drop the option and instead hardcode a 15 second interval when connected to v30 and no timeout for modern node versions.

[Sjors]

See also discussion here: https://github.com/stratum-mining/sv2-apps/pull/59/files#r2537032256

And in the context of node memory management: https://github.com/stratum-mining/sv2-apps/pull/59/files#r2533701427

[xyephy]

let me have a look at this.

[plebhash]

no timeout for modern node versions.

I don't understand this part?

[Sjors]

For node versions that support interruptWait() (v31, maybe v30.1 if it's back-ported), we would call waitNext() without a timeout. This is fine because we can interrupt it at any time. To stay compatible with v30 we'd use a timeout of e.g. 15 seconds, because then we can do a clean shutdown in 15 seconds or less.

[xyephy]

my thinking is to implement a hybrid that would automatically deprecate the hardcoded 15 seconds, something like:

• v30 users: 15s hardcoded timeout (good enough for Ctrl+C)
• v31+ users: No timeout needed (interruptWait works)

[Sjors]

@xyephy that makes sense. The tricky part is how to figure out if the client supports interruptWait() without calling it. As a proxy, you could store whether getCoinbase() succeeds (after #59).

[xyephy]

@Sjors That's a clever approach - using getCoinbase() as a proxy for interruptWait() support makes sense since they were both added around the same time.

I have a question about the implementation order:

Option 1: Implement the simple fix now (remove -sv2interval, hardcode 15s timeout) and add auto-detection in a follow-up PR after #59 merges.

Option 2: Wait for #59 to merge first, then implement this fix with auto-detection from the start.

For Option 1, the 15s hardcoded timeout works correctly for both versions:

• v30: Gets the timeout needed for Ctrl+C
• v31+: Harmless since interruptWait() makes it irrelevant

Then we can enhance it with auto-detection once #59 lands.

[plebhash]

cross referencing: stratum-mining/sv2-apps#59 (comment)

[Sjors]

@xyephy option 1 makes sense.

But we still need some conceptual discussion about whether or not rate limiting by time is needed (rather than only by fees). So if you open a PR I might hold off on merging it for a while.

I also like @plebhash's idea of renaming to -mintemplateinterval.

Even if we keep it, the code can be simplified. In places where we only use it to catch interrupts, we can hardcode 15 seconds instead.

[xyephy]

@Sjors Thanks for the feedback! After researching bitcoin/bitcoin#33899 and sv2-apps#59, I agree with @plebhash - renaming to -mintemplateinterval makes the purpose much clearer.
New approach would look like:

1. Rename: -sv2interval → -mintemplateinterval (or -sv2mintemplateinterval to match)
2. Lower default: 30s → 10s (align with sv2-apps#59 where @GitGab19 recommended 10s)
3. Simplify implementation: Always send new blocks immediately, only rate-limit fee-based updates
4. Separate timeout: Hardcode 15s for waitNext() (v30 Ctrl+C support)

// Only rate-limit fee-based updates
bool is_new_block = (new_prev_hash != old_prev_hash);
auto elapsed = now - last_fee_update_time;
if (is_new_block || elapsed >= min_template_interval) {
    SendWork(*client, template_id, *block_template, is_new_block);
    if (!is_new_block) last_fee_update_time = now;
}

Help Text

-mintemplateinterval=<n>
    Minimum seconds between fee-based template updates (default: 10).
    New blocks always propagate immediately. Reduces template switching
    overhead and Bitcoin Core memory pressure during mempool volatility.

Let me know if this approach better or we stick with the initial one of dropping -sv2interval?

[Sjors]

That makes sense, except:

3. Simplify implementation: Always send new blocks immediately, only rate-limit fee-based updates

We already do this.

[xyephy]

We already do this.

@Sjors Got it - thanks for clarifying that we already prioritize new blocks, that makes things simpler.