Skip to content

sv2: resend template pair on subsequent CoinbaseOutputConstraints#106

Open
enirox001 wants to merge 2 commits into
stratum-mining:masterfrom
enirox001:2025_06_resend_template_pair
Open

sv2: resend template pair on subsequent CoinbaseOutputConstraints#106
enirox001 wants to merge 2 commits into
stratum-mining:masterfrom
enirox001:2025_06_resend_template_pair

Conversation

@enirox001

@enirox001 enirox001 commented Jun 2, 2026

Copy link
Copy Markdown
Contributor

Fixes the issue where sv2-tp only sends a NewTemplate + SetNewPrevHash pair on the initial CoinbaseOutputConstraints but not on subsequent ones

This causes problems during JDC fallback (stratum-mining/sv2-apps#466 (comment)), where the JDC sends a new CoinbaseOutputConstraints to sv2-tp but remains stuck waiting for a template pair to arrive naturally.

We now track the coinbase constraints generation per-client and interrupt the handler's wait loop when constraints are updated, forcing an immediate template rebuild.

Fixes #99

@Sjors

Sjors commented Jun 6, 2026

Copy link
Copy Markdown
Collaborator

I'd like to suggest a slightly different approach. When a new
CoinbaseOutputConstraints arrives:

  • bump a per-client m_coinbase_constraints_generation
  • call interruptWait() on that client's in-progress waitNext()
  • have ThreadSv2ClientHandler discard its current block_template if it was
    built with an older m_coinbase_constraints_generation; this makes the next
    loop behave like a fresh connection
  • before sending work, re-check the generation used to build the template and
    drop it if stale; the client handler will rebuild on the next loop iteration

I pushed an improvement to src/test/sv2_mock_mining.cpp in #107 to make the above easier to test.

enirox001 added 2 commits June 8, 2026 11:43
Previously, only the initial CoinbaseOutputConstraints from a client
triggered sending a TemplatePair. Subsequent messages updated the
constraint but did not send new work because the client handler was
already running.

This caused an issue where the JDC would send a new CoinbaseOutputConstraints
but remain stuck waiting for a template pair until it arrived naturally.

This change bumps an atomic constraints generation counter on Sv2Client and
interrupts the client handler thread's wait when a subsequent
CoinbaseOutputConstraints is received. The client handler thread checks
if the generation has changed and rebuilds the template with the
updated constraints.
Verify that a subsequent CoinbaseOutputConstraints message triggers
a new NewTemplate + SetNewPrevHash pair immediately, rather than
just the initial one.
@enirox001 enirox001 force-pushed the 2025_06_resend_template_pair branch from 266b955 to f25737e Compare June 8, 2026 10:45
@enirox001

Copy link
Copy Markdown
Contributor Author

Thanks for the review @Sjors

Implemented this as suggested, now using an atomic constraints generation counter and interrupting the active template wait.

Also rebased on top of master to utilize the new WaitForWaitNext() test helper from #107

uint64_t constraints_generation_at_build{0};
while (!m_flag_interrupt_sv2) {
if (!block_template) {
LogPrintLevel(BCLog::SV2, BCLog::Level::Trace, "Generate initial block template for client id=%zu\n",

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

5f25346: nit: this is initial only when constraints_generation_at_build == 0

client_id);

// Create block template and store interface reference
// TODO: reuse template_id for clients with the same coinbase constraints

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

5f25346: this comment is now stale, since clients no longer have a lifetime coinbase constraint. I also think that template reuse is better suited for the node (e.g. with bitcoin/bitcoin#33758), so might as well drop this comment.

uint256 prev_hash;

// Track the coinbase constraints generation that was active when block_template was built.
uint64_t constraints_generation_at_build{0};

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

5f25346: would it make sense to narrow the scope of this to inside the while loop, defining it closer to its first use?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

CoinbaseOutputConstraints should always trigger NewTemplate+SetNewPrevHash

2 participants