How to set up a solo mining pool? (Solo vs Pool)

Solo Mining Fundamentals

1. Solo mining means a miner attempts to solve blocks independently without sharing computational resources or rewards with others.

2. The miner retains 100% of the block reward if successful, including both the base block subsidy and transaction fees.

3. Success probability depends entirely on hash rate relative to the network’s total hash rate — a 0.1% share implies roughly one block every 1,000 blocks mined globally.

4. No third-party pool operator is involved; the miner runs their own full node and mining software stack.

5. Block validation, transaction selection, and header construction are fully under the miner’s control — no delegation to external infrastructure.

Technical Infrastructure Requirements

1. A fully synced, archival Bitcoin (or altcoin) full node is mandatory — pruning disables critical indexing needed for efficient block template generation.

2. Mining software such as BFGMiner or CGMiner must be configured to communicate directly with the local node via RPC.

3. Stratum protocol is not used in true solo setups; instead, miners poll the node using getblocktemplate (GBT) requests at regular intervals.

4. Stable low-latency networking is essential — delays in receiving new block announcements can cause stale shares and orphaned work.

5. Redundant power supply and thermal management become critical when running ASICs continuously alongside a full node on shared hardware.

Block Template Management

1. The local node must accept custom transaction selection logic — some miners implement fee-sniping filters or prioritize RBF-enabled transactions.

2. Miners manually configure coinbase output scripts to direct rewards to their own wallet address — an error here results in permanent loss of funds.

3. GBT responses include version bits, nBits, and curtime fields that must be interpreted correctly to avoid invalid timestamps or difficulty mismatches.

4. Mempool synchronization lag must be monitored — if the node’s mempool diverges significantly from network consensus, generated templates may contain invalid or low-fee transactions.

5. Some operators integrate ElectrumX or Esplora backends to enrich UTXO set visibility and improve coinbase construction accuracy.

Risk Exposure and Operational Realities

1. Long variance periods between blocks mean income is highly irregular — a miner with 2% network hash rate may wait over 50 hours for confirmation.

2. Orphan rates increase during network propagation delays — solo miners lack the redundancy of pooled timestamp coordination.

3. Software bugs in custom mining orchestration layers have led to repeated submission of identical extranonce2 values, causing rejected submissions.

4. No payout automation exists — each found block requires manual UTXO inspection, script verification, and wallet import procedures.

5. Monitoring tools like Prometheus + Grafana dashboards are often deployed to track stale share ratios, GBT latency percentiles, and node uptime.

Frequently Asked Questions

Q: Can I run solo mining on a VPS?A: It is strongly discouraged. Most VPS providers prohibit ASIC-related traffic and lack sufficient I/O bandwidth for mempool synchronization. Full node disk I/O saturation commonly occurs under sustained load.

Q: Does solo mining require port forwarding?A: Not for mining itself — only inbound P2P connections need open ports if the node serves as a relay. However, RPC access must remain firewalled to localhost only for security.

Q: What happens if my node loses sync mid-mining?A: All subsequent GBT requests return outdated data. Blocks built on stale chain tips will be rejected by the network even if cryptographically valid.

Q: Is there a minimum hash rate threshold for viable solo mining?A: There is no fixed threshold, but statistically, below 0.05% of network hash rate, expected time between blocks exceeds three weeks on Bitcoin — making cash flow planning impractical.