Braiins Pool: `SetupConnection` with `protocol=1` (Job Declaration) accepted on the mining endpoint, then no Job Declaration service (C-SC-7)

Open
  • Is something wrong?
#19 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
1-2 days
Newbie friendliness
35/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
rust
Domain
networking, testing-qa

Research direction

Start by reading C-SC-7 in the interoperability test suite and the linked spec section for SetupConnection. The issue points to #17 for the refined probe that waits for a Job Declaration response after SetupConnection.Success; compare that probe with the current test and its documented assumptions. Done means the test distinguishes a valid multi-protocol endpoint from one that accepts protocol 1 but does not provide the service.

Written by the indexing model from the issue text.

Description

awaiting maintainer feedback

Found in the ecosystem run on #12. Filing per the process sketched in #13, one issue per bug, tagging the project maintainer.

Maintainer: @jakubtrnka (Braiins)

Target
Project Braiins Pool
Role Mining Protocol Server
Endpoint stratum2+tcp://stratum.braiins.com:3333/9awtMD5KQgvRUh2yFbjVeT7b6hjipWcAsQHd6wEhgtDT9soosna
Resolved to 172.65.65.63:3333
Account stratumv2 (worker stratumv2.ci)
Implementation closed source

Scenario

C-SC-7 unsupported-protocol-rejected (COVERAGE.md), compliance tier Ω1.

The client sends SetupConnection with protocol=1 (Job Declaration) to the Mining Protocol endpoint and expects a framed SetupConnection.Error, unless the endpoint actually serves Job Declaration on that port.

Spec basis

sv2-spec §3.6.1 SetupConnection:

If the server does not support the requested protocol, it MUST respond with SetupConnection.Error.

Nothing in the spec forbids one host:port from serving several sub-protocols. §3 describes the split as a choice the pool makes:

This is a separate protocol so that pools can handle job-declaration connections on separate infrastructure from Mining Protocol connections (i.e. share submissions).

So a .Success to protocol=1 is only a violation if the server does not then serve Job Declaration on that connection. That is what was checked next.

Observed

Suite run at 890d37f (lucasbalieiro, #12, 2026-11-04):

── Braiins Pool: MiningServer at 172.65.65.63:3333 ──
  ✓ C-SCS-1 framed-setup-connection-response (used_version=2)
  ✓ C-SCS-2 used-version-within-range (used_version=2)
  ✗ C-SC-7 unsupported-protocol-rejected: endpoint accepted the SetupConnection with used_version=2
  ✓ C-SC-8 unsupported-version-rejected ((3,3), (3,2), (1,1) rejected)

Follow-up with the SRI JDC pointed at 172.65.65.63:3333 as both pool and JDS (lucasbalieiro, #12, 2026-11-04). Trimmed log:

Received: SetupConnectionSuccess(used_version: 2, flags: 0x00000000)      # pool connection
Received: SetupConnectionSuccess(used_version: 2, flags: 0x00000000)      # JDS connection, protocol=1
Requested allocation of 2 mining job tokens to JDS
... 14 s of silence ...
ERROR jd_client_sv2::io_task: Reader error error=SocketClosed

Follow-up with a prototype of the refined C-SC-7 (sends AllocateMiningJobToken after .Success, waits 10 s), three runs on 2026-11-04 between 17:01 and 17:03 UTC-3, same result each time:

✗ C-SC-7 unsupported-protocol-rejected: endpoint accepted SetupConnection for protocol 1 it does not serve: no reply to its opening request (timeout waiting for any message from endpoint)

Every other pool in the #12 table answers protocol=1 with SetupConnection.Error (error_code="unsupported-protocol" on SRI, Blitzpool, CKPool, NexusPool, Public Pool, PyBLØCK).

Why it matters

A JDC that does upstream discovery by SetupConnection reads .Success as "this server speaks Job Declaration". It then waits on AllocateMiningJobToken and has no spec-defined signal to fall back on until the socket closes. The SRI JDC above spent 14 s in that state before its fallback fired. A SetupConnection.Error would have told it immediately.

Expected

Either a framed SetupConnection.Error to protocol=1 on port 3333, or an AllocateMiningJobToken.Success (or a Job Declaration error) on the connection after .Success.

Caveats

  • §6.4.2 only says AllocateMiningJobToken is "rate limited to a rather slow rate"; it does not put a deadline on the reply. The 10 s and 14 s windows are our judgement of "more than enough".
  • From outside we cannot distinguish "port 3333 does not serve Job Declaration" from "a JDS that silently drops requests from this account". If the latter, the fix on the Braiins side is still a framed error rather than silence, but the title of this issue would be wrong. Confirmation from Braiins settles it.
  • The current C-SC-7 fails on the .Success alone, which the spec allows. That is a bug in this suite, tracked in #17. The finding here stands on the follow-up probes, not on the original suite line.

Reproduce

From interoperability-tests-sv2 at 890d37f (fails on .Success, see #17), or from the probe prototype in #17 (fails on silence after .Success):

# targets.toml
[[site]]
name = "Braiins Pool"
mining_server_address = "stratum.braiins.com:3333"
user_identity = "stratumv2.ci"

cargo run --bin sv2-compliance -- --config targets.toml

Or with the SRI JDC: set both the pool and the JDS upstream to stratum.braiins.com:3333 and watch for AllocateMiningJobToken.Success after the second SetupConnectionSuccess.

Notes on the process (for #13)

  • Unlike the PyBLØCK C-SC-8 case, the raw suite line was not enough to file this. The scenario's MUST is conditional on a server property the suite assumed instead of observed, so a human had to run two more probes before the finding held. #17 moves that observation into the scenario.
  • Braiins needs an account. The CI runner will need the stratumv2 credentials as a secret, and the issue template should carry the user_identity used.
  • Braiins rate-limits rapid reconnects (preflight Noise timeouts and one C-SC-8 (3,2) timeout seen during the probe runs). A nightly run should space connections or retry before reporting those as failures, or the auto-filed issues will be noise.
Dominant language
Rust
Stars
0
Forks
5
No merged PRs in 30d

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from stratum-mining/interoperability-tests-sv2

All issues in stratum-mining/interoperability-tests-sv2

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.