Quick answer: bitcoin mining over satellite internet can work when the link stays stable and the pool tolerates some delay. Judge a satellite connection by latency and jitter, not headline speed, and prefer pools that support Stratum V2.
The wider topic of satellite links for blockchain work is covered in the crypto satellite hub. Operators who only need to sync a full node rather than hash can start with how to run a bitcoin node over starlink.
How latency turns into stale shares
Latency causes stale shares because a miner keeps hashing the old job for as long as the pool’s new job takes to arrive. Any share found in that window refers to work the pool has already replaced, so the pool rejects it as stale. The miner’s hardware did real work, but the work earns nothing.
Job updates and block switching
In the Stratum protocol, the Mining sub-protocol handles job assignment, share submission and difficulty adjustments. Each time the network finds a block, the pool issues fresh jobs, and every connected miner must receive them promptly. D-Central’s Stratum V2 explainer puts block-switching latency at about 325 ms on Stratum V1, against roughly 1.4 ms on Stratum V2, and says the lower figure means fewer stale shares and more efficient hashing.
Those figures describe protocol overhead, not the satellite hop. A satellite link adds its own round-trip delay on top of whatever the protocol costs. The practical lesson is that the protocol is the part of the delay budget you can change, while the physical path usually cannot be changed.
Jitter and dropouts
Jitter is variation in delay from one packet to the next. Average latency can look acceptable while occasional slow packets still delay a job update at the worst moment. A link with a steady, predictable delay generally treats a miner better than one that alternates between fast and slow. Short outages cause a different problem: the miner hashes without fresh jobs until the connection returns, and shares submitted in that period are likely to be rejected.
What the link must deliver
A mining link must deliver consistency first and capacity second. Miners exchange small messages with the pool, and the cost of a late message is a lost share. Raw download speed is a weak guide to how well a site will mine.
- Low and steady latency. Compare repeated measurements taken at different times of day, not a single speed test. A link that is fast at midday and erratic in the evening will show up as uneven stale rates.
- Low jitter. Wide swings in delay matter as much as the average. Choose the plan or provider whose delay varies least.
- Reliable uptime. Each dropout leaves the miners hashing on outdated jobs. Satellite terminals with a clear, unobstructed view of the sky are less likely to drop out.
- Modest but sufficient bandwidth. Stratum V2 consumes approximately 70% less bandwidth than V1, and its header-only mode sends miners just the 80-byte block header instead of the full block template. Check the provider’s plan terms for data caps and fair-use limits before relying on any connection for continuous traffic.
No source in the pack gives a per-miner data rate in kilobits, so size the link by the protocol savings above and by the number of miners sharing one connection. Several miners behind one satellite terminal share one delay path. A site with many machines needs a link that stays stable under that combined load, not merely one that passes a single-device test.
Stratum V1 and V2 on a higher-latency link
Stratum V2 suits a satellite site better than V1 because it trims the parts of the protocol that a slow link makes worse. V1 was introduced in 2012 and replaced the earlier getwork method. V2 replaces V1’s text-based messages with a binary protocol and was initially developed by Braiins.
| Attribute | Stratum V1 | Stratum V2 | Planning use |
|---|---|---|---|
| Block-switching latency | About 325 ms | About 1.4 ms | Lower switching delay leaves more margin for the satellite hop |
| Bandwidth use | Baseline | Approximately 70% less | Eases pressure on a capped or shared satellite plan |
| Message format | Text-based | Binary | Compact messages suit a link where every round trip counts |
| Encryption | None, plaintext messages | Noise_NX handshake pattern, authenticated encryption | Protects traffic on paths you do not control |
Figures are from D-Central’s Stratum V2 explainer, which describes Stratum V2 as composed of three sub-protocols: Mining, Job Negotiation and Template Distribution.
Encryption deserves attention on any link you do not fully control. Every V1 message travels in plaintext, so an attacker who can intercept traffic can redirect a miner’s hashrate to another pool. The same source notes that residential links may traverse multiple untrusted hops, and a satellite path carries the same lesson: do not assume the route is private.
Pool settings for a higher-latency link
The settings that help most are the ones that reduce the work lost to delay and the damage from a failed connection. Support for the newer protocol sits at the top of the list.
- Choose a Stratum V2 endpoint where the pool offers one. The pool must run the newer protocol for its lower switching latency to apply, and releases such as SRI 1.0.0 in March 2024, followed by SRI 1.1.0 with improved documentation and expanded testing, made open-source tooling available to try.
- Use the Job Negotiation sub-protocol if you want template control. It lets miners construct their own block templates, which moves a decision from the pool to the site. It adds setup work, so it suits operators comfortable running extra software.
- Configure fallback pools. The Job Declarator client automatically falls back to alternative pools, and if every pool rejects the miner’s template it falls back to solo mining. Listing sensible alternates means a pool outage or a dropped satellite session does not leave machines hashing for nothing.
- Choose the pool endpoint with the shortest delay from the site. If the pool offers several server locations, test each from the satellite connection and pick the one with the lowest and steadiest delay.
These settings reduce exposure to latency, but they do not remove it. If stale rates stay high after switching protocol and endpoint, the link itself is the limit, and the options below become the next decision.
Remote sites and their internet options
Why wired service is often missing
Sites that make economic sense for mining, such as off-grid solar or hydro locations, are often the same places where wired internet does not reach. Satellite becomes the default when the alternative is no connection at all, and bitcoin mining over satellite internet is mainly a practical answer to that constraint.
Satellite versus the alternatives
Compare any remote link on the same criteria: steadiness of latency, jitter, uptime, data limits and what the site can install. Satellite wins on reach, because a terminal with a clear view of the sky works almost anywhere. Wired or point-to-point links, where they can be installed, generally give steadier delay, which matters most for stale shares. Cellular links suit sites with coverage but need the same repeated delay measurements before committing. A crypto satellite setup is a sensible choice when nothing steadier is available. It is the wrong one when a lower-jitter option exists at similar cost.
Satellite also suits secondary tasks on the same connection. Operators who want to settle bills in coins can read how to pay with crypto via satellite, which covers the payment side separately from hashing.
Troubleshooting rising stale shares
- Check the pool dashboard first. Look at rejected shares as a share of total, and note whether stale rejections cluster at particular times.
- Test the link at the same times. Repeated latency and jitter readings show whether the spikes match link behaviour or point to miner or pool problems.
- Inspect the terminal’s view of the sky. Obstructions cause dropouts, and every dropout leaves miners on outdated jobs.
- Move to a Stratum V2 endpoint. The reduction in block-switching latency from about 325 ms to about 1.4 ms in D-Central’s comparison is the largest protocol-side gain available.
- Try another pool server location. A closer or better-routed endpoint can lower delay without changing hardware.
- Reconsider the link. If stale rates remain high with a modern protocol and a good endpoint, a steadier connection type is the remaining fix.
Frequently asked questions
Does Stratum V2 make satellite mining practical?
It makes it more practical, not guaranteed. Lower block-switching latency and reduced bandwidth help, but the satellite hop’s own delay and jitter still decide how many shares go stale.
Is Stratum V1 traffic encrypted?
No. V1 messages travel in plaintext between miner and pool, while V2 uses authenticated encryption through the Noise_NX handshake pattern.
What happens if a pool rejects a miner’s own template?
With Job Negotiation, the Job Declarator client automatically falls back to alternative pools. If all of them reject the template, it falls back to solo mining.
Why does an average speed test not predict stale shares?
Stale shares depend on how quickly each job update arrives, not on throughput. A fast link with erratic delay can still lose shares, so repeated latency and jitter measurements are a better guide.
