Bitcoin · SHA-256 AsicBoost · Solo mining pool with direct on-chain payout

Bitcoin (BTC) Solo Mining Pool: How It Works and What to Check

Choosing a Bitcoin mining pool takes more than looking at the hardware alone. Bitcoin remains the network that sets the standard for SHA-256d mining, and its hashrate is almost entirely dominated by specialised ASICs, machines refined over years for a single purpose: computing as many hashes as possible per watt consumed. Against that scale, a CPU or GPU simply isn't in the race.

Deciding where to point that hardware, though, isn't just a matter of comparing a fee table. What matters is the pool's reward model, the real quality of its Stratum infrastructure, latency from your location, compatibility with the extensions your ASIC uses, and something often overlooked: the behaviour of network difficulty itself.

That last point has a quirk unique to Bitcoin. The network aims for a ten-minute average per block, but it doesn't correct course continuously: it waits until 2016 blocks are complete — roughly two weeks — before recalculating the target. Between one adjustment and the next, a sharp hashrate swing can leave the network producing blocks noticeably faster or slower than usual.

At the model level, you essentially have two paths: join a shared pool or operate in solo mining. OwnBlock built its BTC service on the second: it provides all the necessary Stratum infrastructure, but you keep your own probability of finding a block instead of splitting it with everyone else.

View pool dashboard

What exactly is a Bitcoin mining pool?

In a shared setup, the pool combines the hashrate of many miners to find blocks more regularly and then splits the reward under an agreed payout system. The two most common are PPLNS and PPS. PPLNS — Pay Per Last N Shares — pays based on the shares submitted within a specific window right before a block is found. PPS — Pay Per Share — is more predictable for the miner: it pays a fixed amount per valid share, with the operator carrying the risk if the actual block variance doesn't cooperate.

Solo mining breaks that shared logic. Every hash your ASIC produces is, in effect, an independent ticket: there's a probability that result lands below the target the network requires, and if it does, you've just found an entire Bitcoin block. More hashrate means more tickets per second, but not a guaranteed schedule — you can go weeks without a result and then find two blocks back to back shortly after. That irregularity isn't a flaw in the system; it's exactly how it's meant to work.

Nothing stops you from building this infrastructure yourself, but the technical bar is high. You need to run Bitcoin Core and add a mining layer on top that talks to the ASICs: the node exposes getblocktemplate to build block candidates, but no commercial ASIC speaks that RPC directly, so you need intermediate software translating that work into Stratum. A solo mining pool exists precisely to save you from building that piece.

OwnBlock runs neither PPLNS nor PPS — there's no split among miners at all. If your ASIC finds a valid block, the reward is yours, minus the pool fee; if it doesn't, the work submitted is logged, but it doesn't create any balance owed.

What to check before choosing a Bitcoin mining pool?

With an ASIC burning power around the clock, any poorly handled operational detail translates directly into lost money. It's worth understanding exactly what happens between the first hash computed and the block that finally reaches the network.

Reward model

Shared or solo mining? That's the first question to settle. A shared pool spreads variance across many participants and usually pays more often, though the actual amount depends on the operator's chosen system. Solo mining has no dilution: your own probability of finding a block stays intact, and you also carry all the associated variance. OwnBlock operates exclusively under this second scheme. The shares you submit prove valid work and let the server gauge your performance, but they don't amount to a reserved slice of a future reward — payment only appears once your own work crosses the line and finds a block.

Share difficulty vs Bitcoin's network difficulty

These are two numbers that sound alike but mean different things. Network difficulty is a consensus rule: it defines how hard it is to find a valid block, and it's the same for every Bitcoin miner at any given moment. Share difficulty, by contrast, is set by the pool itself just so it can measure your work often enough: it's much lower, and an accepted share is almost never an actual block, just partial proof that your ASIC is computing correctly. Whether the pool raises or lowers that share difficulty changes nothing about how hard Bitcoin is to mine — it only changes how many proofs the server receives per minute.

Infrastructure and latency

The connection between your ASIC and the Stratum server isn't a minor detail. High latency doesn't automatically mean rejected shares, but it's part of a set of things that do matter: stability, packet loss, reconnections, and above all how quickly the server notifies you when a new block appears. Working too long on a stale template produces obsolete shares that count for nothing. Chasing the lowest possible millisecond figure matters less than watching for a stable network path and a high acceptance rate; judging a pool purely on whether it advertises anycast or unicast doesn't help either — what counts is how the endpoint you're connected to actually behaves in practice. OwnBlock's BTC infrastructure runs out of Europe; you can connect from anywhere, though real latency depends on the specific route between your source and the server.

AsicBoost and version rolling

Today's SHA-256 ASICs usually ship with overt ASICBoost, an optimisation that squeezes extra efficiency out of the hardware. The piece that makes it possible on Stratum is version rolling: the miner rearranges certain bits of the header's nVersion field to generate extra working space without rebuilding the whole block candidate. BIP 310 is the standard describing exactly that extension and how it's negotiated between miner and server. If the server doesn't hand over enough bits, the ASIC ends up performing below its real capacity. ASICBoost compatibility, then, isn't a box that ticks itself — the extension the hardware or rented hashrate provider requires has to be properly implemented. OwnBlock supports SHA256AsicBoost, the algorithm NiceHash uses for its BTC hashrate orders.

Difficulty adjustment every 2016 blocks

Bitcoin chases a ten-minute average per block by recalculating the target every 2016 blocks, roughly fourteen days if the pace holds. At the end of each cycle, the network compares actual elapsed time against expected time: if it ran faster, difficulty rises for the next cycle; if slower, it falls, capped at up to a fourfold change per cycle. The key detail is that nothing self-corrects in between: if a lot of hashrate joins right after a cycle starts, the network can spend weeks producing sub-ten-minute blocks with nothing reacting until the 2016 blocks close — and the opposite happens if hashrate pulls out. That's a different mechanism from Bitcoin Cash, where ASERT corrects continuously and gradually instead of waiting for a closed cycle. As long as difficulty stays put, the probability that any given hash from your ASIC finds a block stays put too — other people's hashrate arriving doesn't hit you immediately, but if it manages to speed up block production, the next readjustment will raise difficulty, and from then on the same machine will find blocks less often. A hashrate exodus has the opposite effect.

Difficulty adjustment and hashrate rental

This timing gap weighs heavily when you rent hashrate for hours or days at a time. If you're weighing an order with only a few blocks left before the cycle closes, and that cycle has run faster than expected, the difficulty you see right now is still the current one, but it may rise shortly after your rental kicks off; if the readjustment lands within that window, part of your order ran under one difficulty and the rest under another. The reverse can happen if the cycle has run slower. Before committing to a sizeable hashrate order, it's worth checking three things together: the current difficulty, how many blocks remain until the next adjustment, and a reasonable estimate of where it's headed given the cycle's current pace. That estimate is never a hard certainty — remaining time and global hashrate can keep shifting — but completely ignoring where Bitcoin sits in its cycle can throw off the numbers on a short order quite a bit.

Custody and how the reward is paid

In quite a few shared pools, the block reward lands first in the operator's own infrastructure, which keeps an internal tally of what it owes each miner and runs payouts later, under its own rules, minimums, and schedules. OwnBlock does something different: when you find a valid block, the reward is split directly within the coinbase transaction — your share goes to the script tied to your own Bitcoin address, and the pool fee (2% currently) sits in another output of that same transaction. There's no intermediate balance inside OwnBlock that later needs withdrawing from an operator wallet. That doesn't mean the funds are spendable instantly, though: like any coinbase reward, that output needs to reach the maturity the protocol demands — 100 additional blocks — before it can be spent.

Fees and registration

OwnBlock's fee is 2%, and it's only charged if your miner actually finds a block — with no reward, there's nothing to apply it to. Connecting an ASIC requires no KYC process whatsoever: your BTC address and a worker name are enough to identify the connection, using the format BTC_ADDRESS.WORKER, with the worker mandatory under the currently published configuration. The pool accepts Bitcoin addresses in Legacy, Native SegWit, and Taproot formats.

Compatibility with rented hashrate

You don't need to buy an ASIC to mine on OwnBlock — you can also rent SHA-256 hashrate from a third-party provider. There, it's not enough for the provider to sell raw power; it needs to let you point at an external pool and speak the same protocol and parameters the destination server requires. OwnBlock documents compatibility with NiceHash, MiningRigRentals and Braiins. Before launching an order, check the host, the port, the exact worker format, the region the rented hashrate comes from, and any provider-specific conditions. With solo mining you're paying for computational work over a fixed period, not for a guaranteed slice of a block.

Where OwnBlock fits into this

OwnBlock operates as a solo mining pool for Bitcoin: it doesn't blend the rewards of its users or split each block proportionally among everyone connected. Each miner keeps their own probability of finding a block and carries the variance that comes with it. What the pool contributes is the infrastructure: a Stratum connection for the ASICs, share validation, and submitting the block to the network the moment one of its miners lands a valid solution.

Today, the BTC service brings together: solo mining with no PPLNS or PPS, servers in Europe, a 2% fee, reward delivered directly via coinbase, zero custodial balance held inside the pool, connection with no KYC, support for SHA-256 ASICs, compatibility with NiceHash's SHA256AsicBoost, integration with NiceHash, MiningRigRentals and Braiins, Stratum V1 endpoints, and a public dashboard showing hashrate, connected miners, and blocks found.

The variance inherent to solo mining stays completely intact under this scheme. An accepted share confirms your rig is working correctly for the pool, but it doesn't amount to a collectable piece of the reward — you can rack up millions of shares without finding anything, or hit a block well before the statistical average would suggest. Both outcomes are perfectly normal under this model.

If frequent payouts are your priority and you'd rather have the variance spread across many participants, a shared pool fits that goal better. If, instead, you'd rather take on that variance in exchange for keeping the entire reward when your own work lands a block, solo mining follows that other logic.

OwnBlock's public dashboard lets you check the pool's and network's hashrate at any time, who's connected, and the full history of blocks found.

Transparency and on-chain verification

Bitcoin runs on a public blockchain, so anyone can examine a block's transactions directly on-chain, including the coinbase that creates the mining reward.

The coinbase opens every block and bundles together both the subsidy and the fees from the transactions the miner chose to include. Its outputs are part of the block itself, so they can be verified completely independently.

Under OwnBlock's scheme, this lets you confirm your reward came directly out of that coinbase and not from a later transfer out of a pool wallet. It also lets you verify the exact amounts and destination scripts of every output involved in the split.

That said, there's a clear line between what the chain proves and what the pool records. Bitcoin knows nothing about Stratum worker names like rig1, s21-01, or miner03 — those identifiers only exist inside the pool's own infrastructure.

The chain proves a given block exists, what its coinbase is, and where its outputs went. Exactly which worker found that block is information that only shows up in OwnBlock's own records. In short: you verify the on-chain reward independently, and the pool dashboard supplies the operational data linking it to your miner.

This also comes in handy for documenting the origin of funds. Receiving BTC directly from a coinbase leaves on-chain evidence that the money originated as a mining reward, not as an ordinary transfer out of an operator's wallet.

If an exchange, custodian, or other entity asks you to justify the origin of some funds, this evidence can be submitted as part of that documentation. Whether it's enough will depend on each entity's own internal compliance procedures.

Compatible hashrate rental

For BTC, OwnBlock currently documents compatibility with three external providers:

NiceHash Stratum V1

MiningRigRentals Stratum V1

Braiins Stratum V1

Ready to connect your miner?

Follow the step-by-step guide to connect your ASIC to the OwnBlock BTC pool.

View connection guide

Frequently asked questions about BTC pools

What hardware do I need to mine Bitcoin?

In practice, a SHA-256 ASIC: Antminer, WhatsMiner, Avalon, and other specialised families are what actually compete on the main network. A CPU or GPU can compute SHA-256 hashes just fine, but it falls well short in hashrate and power efficiency compared with any modern ASIC.

Does OwnBlock use PPLNS or PPS?

Neither. OwnBlock is a solo mining pool — shares from different miners are never combined to split anything. If your miner finds a valid block, you get the full reward minus the 2% fee; if it doesn't, the shares submitted generate no payout at all.

What is ASICBoost and why should it matter when choosing a pool?

It's an optimisation that reuses part of the internal hashing work to gain efficiency on compatible ASICs. The modern implementation, version rolling, generates header variations by shifting certain nVersion bits, and that requires the Stratum server to negotiate them correctly with your rig. A pool that doesn't properly support that extension leaves you performing below your real capacity.

How often does Bitcoin's difficulty change?

Every 2016 blocks — roughly two weeks if the pace holds steady. If that cycle closes faster than expected, difficulty rises; if it closes slower, it falls. The underlying goal is sustaining a long-term average close to ten minutes per block.

What happens if a lot of hashrate joins right after a readjustment?

Difficulty doesn't react instantly — it stays fixed until the next 2016 blocks close. In the meantime, if that hashrate influx is large enough, blocks tend to arrive faster than usual. Once the cycle completes, the next readjustment will raise difficulty if the pace stayed above what was expected.

Does more network hashrate immediately lower my odds of finding a block?

No, not while difficulty stays the same. The probability that one of your hashes succeeds depends solely on the network's current target. If your hashrate stays constant and difficulty doesn't move, your mathematical probability per unit of time doesn't move either. The real effect of a sustained increase in other people's hashrate only arrives once the readjustment actually tightens the target.

What do I gain by submitting shares if I never find a block?

Shares prove your ASIC is working correctly and let the pool measure your performance in real time. In solo mining they don't amount to a balance or a proportional stake in anything. The only possible payout arrives when your own work finds a valid Bitcoin block.

Can I rent BTC hashrate instead of buying my own ASIC?

Yes. OwnBlock documents compatibility with NiceHash, MiningRigRentals and Braiins for this. The rented hashrate is pointed at the pool's BTC endpoint for the whole order. More hashrate means more attempts per second and therefore a higher chance of finding a block, but it's never a guarantee you'll actually get one.

Should I check the next difficulty adjustment before renting hashrate?

Yes, especially if that adjustment could land right during your rental. If Bitcoin is close to closing a 2016-block cycle and a sharp difficulty increase is expected, part of your order may end up running under different conditions than what you saw when you placed it. The same applies in reverse if a drop is expected. It's worth checking the current difficulty, how many blocks remain until the next readjustment, and an estimate of where it's headed before committing hashrate for any meaningful period.