Pool Compatibility#

Braiins Hashpower delivers purchased hashrate to a destination pool you choose. Most major Bitcoin pools work without any setup on your side. This page covers what the platform requires, how to check a pool before you buy, and — for pool operators — what to implement so aggregated hashrate arrives cleanly.

#What the Platform Requires

A destination pool must speak Stratum, either V1 or V2.

Stratum V1 — reachable as stratum+tcp://pool.example.com:port, offering an extranonce2_size of at least 7. That requirement exists because a single Braiins Hashpower session aggregates multiple miners, and a smaller value exhausts the search space available to that session.

Stratum V2 — reachable as stratum2+tcp://pool.example.com:port/<pubkey>, with the pool's authority public key as part of the URL. See Stratum V2.

#Stratum V2

Braiins Hashpower can deliver to a Stratum V2 pool. We have tested this and it works.

Enter the endpoint as stratum2+tcp://pool.example.com:port/<pubkey>, including the pool's authority public key.

For pool operators: we open an extended channel for each group of miners we aggregate, much as we would open a V1 connection for them. We do not use standard channels, and we do not multiplex devices into group channels. A destination pool therefore has to support extended channels.

Stratum V2 support differs between pools and between configurations, so we cannot promise every V2 endpoint will work. If delivery does not start against one you believe is correct, check it with your pool or contact support.

#How Compatibility Is Checked

When you enter a pool URL, the platform checks three things automatically:

1. extranonce2_size — must be 7 or higher.
2. Worker authorization — mining.authorize is used to verify that your username is valid.
3. Initial job difficulty — the difficulty of the pool's first job. Below 10,000 you get a warning rather than a rejection: delivery still works, but the pool is set up for individual miners and should be starting aggregated sessions much higher. See Difficulty for the values we recommend.

#Check a Pool Yourself

You can read a pool's extranonce2_size with nc and jq:

(echo '{"id":1,"method":"mining.subscribe","params":[]}'; sleep 1) | nc stratum.example.com 3333 | head -1 | jq -r '.result[2]'

Replace stratum.example.com and 3333 with your pool's host and port. The output must be 7 or higher.

The public stratum.braiins.com endpoint returns an extranonce2_size of 6, but Braiins Hashpower uses a dedicated node with the required size.

#Known Compatible Pools

Confirmed compatible at the time of writing:

• Braiins Pool, Braiins Solo
• All other major pools, among them Antpool, Binance, CK Pool, Cloverpool, EMCD, F2Pool, Foundry, Lincoin, Luxor, Ocean, Poolin, SBI, Ultimus, and ViaBTC

#Known Incompatible Pools

Not compatible, because of insufficient extranonce2_size:

• NiceHash
• MiningRigRentals
• Public Pool

If your pool is not listed, check it with the command above or contact support.

#Recommendations for Pool Operators

The rest of this page is for pool operators who want to accept hashrate from Braiins Hashpower. A Braiins Hashpower session is not a single miner: it aggregates multiple miners, sharing one difficulty, into a single connection — which makes some otherwise harmless behaviour expensive.

#When a Pool Is Blacklisted

A pool that breaks these expectations can be blacklisted for 24 hours, during which we stop routing hashrate to it. The reasons vary, but they fall into three groups:

• Rejection rate. We stop sending hashrate to a pool that rejects a large share of it. This protects you as much as the buyer — rejected work costs you nothing but earns nobody anything.
• Frequent disconnects. Sessions that keep dropping lose delivery that cannot be recovered.
• Job invalidation. Work in flight being invalidated rapidly and repeatedly, which in practice almost always means the clean_jobs flag — see Clean Jobs.

A high rejection rate on your side almost always has one of three causes:

• Duplicate jobs. The pool hands out the same job more than once, then rejects the resulting submits as duplicates.
• Difficulty churn. Frequent, rapid difficulty changes, combined with imprecise tracking of which job was issued at which difficulty, so valid submits come back as low-difficulty rejects.
• Dropped connections. The pool closes a session while submits are still in flight, so that work is lost and counted against you. This also counts on its own as a frequent disconnect.

Both are worth ruling out first if your pool is blacklisted and the cause is not obvious. The guidance below protects your own delivery as much as ours.

#Stratum Handshake

• Respond to mining.configure with version-rolling: true and a version-rolling.mask of 1fffe000 (BIP 320).
• Respond to mining.subscribe with an extranonce1 that is unique per session and an extranonce2_size of at least 7. We recommend 8.
• Respond to mining.authorize explicitly, returning true or false in the Stratum result. Never close the TCP connection silently after subscribe without sending a notify — sessions that are dropped this way fail while waiting for their first job, even though a connectivity probe succeeds.
• Send the first mining.notify within 5 seconds of a successful authorize. If your pool gates access by identity, reject at authorize with an explicit error rather than by disconnecting.

#Extranonce

• Set extranonce2_size to 7 at minimum; 8 is better.
• Give each session a unique extranonce1 at mining.subscribe time, and keep it fixed for the life of that session. Reusing one across concurrent sessions produces duplicate shares.
• Do not use mining.set_extranonce to rotate session state mid-connection. We do not subscribe to extranonce changes, so a set_extranonce arriving mid-session is rejected as an invalid message and never reaches the miners behind that session.
• If you need to rotate a session's extranonce, close the connection instead and let us re-subscribe.

#Difficulty

A single connection from Braiins Hashpower typically carries hundreds of TH/s, so it needs a far higher difficulty than an individual miner would.

• Start new sessions at 2^18 (262,144). Let vardiff adjust from there.
• The technical minimum is 2^10 (1,024). Jobs below that are not accepted.
• Avoid frequent, rapid difficulty changes, and accept a submit at the difficulty its job was issued at. Churn combined with imprecise job tracking is a common cause of low-difficulty rejects.

Starting anywhere near the minimum floods your pool with submits. We have seen a number of upstream pools fail to handle that load, so the recommended starting difficulty protects your own infrastructure as much as it protects delivery quality.

#ntime Rolling

• Allow ntime rolling of ±7200 seconds. This lets an aggregated session keep working on a notify a little longer instead of idling.
• Accept any ntime inside your allowed window, not only the exact ntime from the notify.

#Clean Jobs

Mishandled clean_jobs is the single most common cause of delivery problems.

• Never send clean_jobs=true twice within 30 seconds. Back-to-back clean-block cascades invalidate work in flight in both directions and produce large bursts of stale shares.
• During fast clean-block sequences — two or more blocks within a minute — queue the intermediate jobs with clean_jobs=false and flag only the first new-block event with clean_jobs=true.
• Wait at least 10 seconds after any clean_jobs=true before sending another.

#Share Rejection

• Respond to mining.submit within 1 second. Submits left unacknowledged past our timeout are counted as rejected.
• When you reject a share, include a human-readable reason rather than an opaque code. Reasons such as Stale share, stale share (block changed), Job not found, Low difficulty, Duplicate, and Unauthorized are all handled correctly.
• Never fall back to a sentinel such as bug or unknown. A reject we cannot classify is treated as your pool's fault.

#Connectivity Probes

Braiins Hashpower probes destination pools regularly with short connections that subscribe, authorize, and disconnect again without taking any delivery. This is how reachability and compatibility are checked.

During the BETA period the probe rate is considerably higher than it needs to be, and it will come down. Probes do not affect delivery, but they do add connection load, and they explain short-lived sessions in your logs that never submit a share.

#Operational

• Avoid maintenance restarts during buyer traffic. Every restart forces all downstream sessions to reconnect, which causes a stale burst on its own.

Before you advertise your endpoint as compatible, test it under the load it will actually see from us and size it accordingly. A pool that passes a connectivity check but cannot carry the submit rate of an aggregated session will fail once real delivery starts, and that shows up as a rejection problem on your side.

#Test, Immature, and Fork Chains

Small or young SHA-256 chains — eCash forks, drivechains, BIP300 sidechains, Bitcoin II and BCH2-style forks — are the highest-risk case.

• Low difficulty combined with a high clean_jobs rate reliably produces a stale cascade. Fast blocks of 10 to 60 seconds plus aggressive clean_jobs will cause problems within minutes of real volume.
• Buffer at least one job when clean-block events arrive within 30 seconds of each other, and release the second with clean_jobs=false once the first wave has drained.
• Expect the first 24 to 48 hours after a fork activation to be the riskiest window. After that, sound clean_jobs handling keeps delivery stable.