💡 The Pool Mining Problem Stratum Solves:

• Work Distribution: Pool must efficiently assign unique work to thousands of miners simultaneously without duplication
• Share Verification: Pool must verify miners are actually performing work (submitting “shares”) to prevent reward theft
• Real-Time Coordination: When a new block is found on the network, pool must instantly notify all miners to start working on the next block
• Difficulty Adjustment: Pool must dynamically adjust each miner’s difficulty to maintain optimal share submission rates
• Reward Distribution: Pool must track each miner’s contribution and distribute rewards proportionally

Stratum Connection Flow (Simplified):

1. TCP Connect: Miner establishes TCP connection to pool server (typically port 3333, 3334, or 443)
2. Subscribe: Miner sends mining.subscribe request with client software details
3. Authorize: Miner sends mining.authorize with worker name and password
4. Set Difficulty: Pool sends mining.set_difficulty assigning initial difficulty target
5. Notify Job: Pool sends mining.notify with current block template parameters
6. Mining Loop: Miner hashes continuously, submitting shares via mining.submit when found
7. New Block: When network finds new block, pool sends new mining.notify to restart cycle

Share Difficulty Concept:

Bitcoin network difficulty (May 2026): ~650,000,000,000,000,000 (650 quintillion)

Typical pool share difficulty: ~65,536 (1 million times easier)

What this means: If a valid Bitcoin block requires a hash starting with ~19 leading zeros, a pool share might only require ~13 leading zeros. Your ASIC finds thousands of shares per day but might only contribute to finding an actual block every few weeks or months (depending on pool size).

Formula:

Share Difficulty = Network Difficulty / Difficulty Divisor

Shares Per Block (pool average) = Network Difficulty / Share Difficulty

Example: With share difficulty 65,536, pool needs approximately 10 million shares to find one valid block.

Example: mining.subscribe request (from miner to pool):

{"id": 1, "method": "mining.subscribe", "params": ["cgminer/4.12.0"]}\n

Example: mining.subscribe response (from pool to miner):

{"id": 1, "result": [["mining.notify", "ae6812eb4cd7735a302a8a9dd95c6578"], "08000002", 4], "error": null}\n

Example: mining.notify (pool pushes new job to miner):

{"id": null, "method": "mining.notify", "params": ["bf", "4d16b6f85af6e2198f44ae2a6de67f78487ae5611b77c6c0440b921e00000000", "01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff20020862062f503253482f04b8864e5008", "072f736c7573682f000000000100f2052a010000001976a914d23fcdf86f7e756a64a7a9688ef9903327048ed988ac00000000", [], "00000002", "1c2ac4af", "504e86b9", false]}\n

💡 Block Header Construction Process:

1. Coinbase Construction: Concatenate coinb1 + extranonce1 + extranonce2 + coinb2 to create complete coinbase transaction
2. Coinbase Hash: Double-SHA256 hash the coinbase transaction
3. Merkle Root: Using coinbase hash and merkle_branch array, calculate merkle root through iterative hashing
4. Assemble Header: Combine version (4 bytes) + prevhash (32 bytes) + merkle_root (32 bytes) + ntime (4 bytes) + nbits (4 bytes) + nonce (4 bytes) = 80 bytes total
5. Hash Header: Double-SHA256 hash the 80-byte header
6. Check Result: If hash meets difficulty target, submit as share. If hash is below network difficulty, you found a block!

Search Space Calculation:

Nonce: 4 bytes = 2^32 = ~4.3 billion possibilities

Extranonce2: 4 bytes = 2^32 = ~4.3 billion possibilities

nTime rolling: Can increment timestamp every second for additional space

Total Search Space: 2^32 (nonce) × 2^32 (extranonce2) × time = effectively unlimited

Practical Example: Antminer S21 (200 TH/s) exhausts 4.3 billion nonces in: 4,300,000,000 / 200,000,000,000,000 = 0.0000215 seconds (21.5 microseconds). Extranonce2 provides 4.3 billion additional workspaces, giving ~1.5 minutes before needing new work.

Why Variable Difficulty Matters:

Low Hashrate Miner (1 TH/s): At network difficulty, would find share once every 650,000 seconds (~7.5 days). Pool assigns difficulty 1,000, so miner finds shares every ~10 seconds.

High Hashrate Miner (200 TH/s): At difficulty 1,000, would find 200,000 shares per second (overwhelming pool server). Pool assigns difficulty 200,000, so miner finds shares every ~10 seconds.

Pool’s Goal: Every miner, regardless of hashrate, submits shares at consistent interval (typically 5-30 seconds). This provides accurate hashrate measurement without overwhelming servers with submissions.

🔴 Stratum V1 Security and Centralization Problems:

• No Encryption: All communication is plaintext JSON, vulnerable to eavesdropping, man-in-the-middle attacks, and hashrate hijacking
• Pool Controls Block Construction: Mining pools have exclusive control over which transactions go into blocks. Miners blindly accept whatever the pool dictates, creating censorship risk
• Inefficient Data Format: JSON with verbose field names and whitespace wastes bandwidth. For large mining farms, this adds up to significant costs
• No Standardization: V1 implementations vary across pools, causing compatibility issues and vendor lock-in
• Latency: JSON parsing and verbose messages create ~325ms block-switching latency, resulting in stale shares

✅ What V2 Encryption Prevents:

• Hashrate Hijacking: Attackers can’t intercept and redirect shares to their own accounts
• Man-in-the-Middle Attacks: ISPs or network attackers can’t modify work assignments or steal credentials
• Traffic Analysis: Encrypted traffic prevents surveillance of mining operations and revenue estimation
• Censorship Resistance: Encrypted mining traffic is harder for governments or ISPs to detect and block

How Job Negotiation Works:

1. Miner Runs Template Provider: Miner runs local Bitcoin Core node or connects to external template provider service
2. Template Construction: Miner selects which transactions to include in block (from mempool) and constructs block template
3. Template Submission: Miner sends custom template to pool via Job Negotiation Protocol
4. Pool Verification: Pool verifies template validity and merges with pool’s coinbase transaction (for payout)
5. Mining Begins: Miner hashes their custom template. If they find block, it includes their chosen transactions

Why This Matters: Individual miners can now enforce transaction selection policies (e.g., refusing to mine blocks censoring specific addresses), making pool-level censorship impossible without losing hashrate.

💡 Bandwidth Comparison Example:

Stratum V1 mining.notify message: ~500-800 bytes (JSON with full transaction data)

Stratum V2 standard mode: ~350-500 bytes (binary encoding, -30% bandwidth)

Stratum V2 header-only mode: ~120 bytes (only 80-byte header + metadata, -70% bandwidth)

For 10,000-miner farm: V2 saves ~15-50 GB bandwidth per day depending on mode. At $0.05/GB, this is $275-$2,500 savings per day = $100k-$900k per year.

Required Pool Configuration Fields:

1. Pool URL: Format is stratum+tcp://poolserver.com:port
   • Example: stratum+tcp://us1.btc.com:3333
   • Common ports: 3333 (standard), 3334 (SSL), 443 (HTTPS-compatible), 25 (alternative)
2. Worker Name (Username): Format varies by pool
   • Account-based: yourusername.workername (e.g., john.miner01)
   • Wallet-based: yourBTC_address.workername (e.g., 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa.antminer1)
3. Password: Usually x or 123 (ignored by most pools, legacy field)

💡 Antminer Configuration Walkthrough:

1. Power and Network: Connect miner to power and Ethernet. Wait 2-3 minutes for boot
2. Find IP Address: Use router DHCP client list or IP scanner tool (Advanced IP Scanner, Angry IP Scanner)
3. Access Web Interface: Open browser, navigate to miner’s IP (e.g., http://192.168.1.100)
4. Login: Default credentials usually root/root or admin/admin
5. Navigate to Miner Configuration: Click “Miner Configuration” or “Pool Settings” tab
6. Configure Pools: Enter three pools (primary, backup 1, backup 2):
   • Pool 1 URL: stratum+tcp://us-east.slushpool.com:3333
   • Worker: yourusername.miner01
   • Password: x
   • Repeat for Pool 2 and Pool 3 (different pools or regions for redundancy)
7. Save and Apply: Click “Save & Apply”. Miner will restart (~30 seconds)
8. Verify Connection: Check “Miner Status” page. Should show “Alive” status and hashrate ramping up within 5-10 minutes

Advanced Stratum Options:

• Fixed Difficulty: Add +difficulty to worker name (e.g., username.worker+8192) to request specific share difficulty. Useful for large farms to reduce server load
• Worker Groups: Use descriptive worker names to track performance (e.g., username.warehouse-a-row1, username.warehouse-a-row2)
• Frequency Tuning: Most ASICs allow overclocking/underclocking. Lower frequency = lower power, higher efficiency, fewer shares. Higher frequency = more power, more hashrate, more shares
• Failover Delay: Some firmware allows configuring how long to wait before switching to backup pool (default 5-30 seconds)

✅ Stratum V2 Connection Example:

Pool URL: stratum2+tcp://v2.braiins.com:3336 (note “stratum2” prefix)

Encryption: Enabled by default (AEAD)

Worker Name: Same format as V1

Firmware Requirement: Requires V2-compatible firmware:

• BraiinsOS+ (all models)
• Bitmain official firmware (S21 series, May 2026+)
• MicroBT official firmware (M60S+ series, Q2 2026+)
• Vnish firmware (V2 support added Q1 2026)

Job Negotiation (Optional): To use custom block templates, must run Template Provider (Bitcoin Core + translator proxy). Most miners use standard mode without JNP initially.

⚠️ Connection Verification Checklist:

1. Miner Dashboard: Shows “Alive” status, not “Dead” or “Sick”
2. Hashrate Display: Shows expected hashrate (e.g., 200 TH/s for S21) within 10-15 minutes of starting
3. Accepted Shares: “Accepted” share count increasing steadily. “Rejected” should be <1-2%
4. Pool Dashboard: Log into pool website, verify worker appears as active with hashrate matching miner dashboard
5. Earnings Tracking: After 1-2 hours, should see estimated earnings appearing on pool dashboard

Red Flags: If “Rejected” shares exceed 5%, “Stale” shares exceed 3%, or hashrate is significantly below specification, troubleshoot connection, pool configuration, or hardware issues.

Symptoms: Miner shows “Dead” status, no hashrate, pool dashboard shows worker offline

Possible Causes and Solutions:

• Incorrect Pool URL: Verify URL exactly matches pool documentation. Check for typos, wrong protocol (http vs stratum+tcp), or wrong port number
• Firewall Blocking: Corporate/residential firewalls may block outbound TCP connections on mining ports. Try port 443 (HTTPS-compatible) or contact IT to whitelist pool IPs
• Pool Offline/Maintenance: Visit pool’s status page or Twitter/Discord to check for outages. Switch to backup pool temporarily
• Network Issues: Ping pool server from miner’s IP address to verify network connectivity: ping poolserver.com
• Invalid Worker Credentials: For account-based pools, verify username exists and is spelled correctly. For wallet-based pools, verify Bitcoin address is valid

Symptoms: Miner connects successfully but >5% of shares rejected by pool

Possible Causes and Solutions:

• High Network Latency: Check ping time to pool (should be <50ms ideally, <150ms acceptable). If high, switch to geographically closer pool server
• Hardware Errors: Overheating or unstable overclocking causes invalid hashes. Check temperatures (should be <75°C) and reduce frequency if overclocked
• Outdated Firmware: Old firmware may have Stratum compatibility bugs. Update to latest official or custom firmware (BraiinsOS+, Vnish)
• Clock Synchronization: Miner’s system clock must be accurate. Enable NTP (Network Time Protocol) in miner settings
• Duplicate Extranonce: Running multiple miners with identical worker names can cause extranonce collisions. Use unique worker names for each miner

Symptoms: Miner connects but frequently drops connection and reconnects

Possible Causes and Solutions:

• Unstable Network: Check for WiFi issues (use wired Ethernet instead), router problems, or ISP connectivity issues
• Miner Overheating/Crashing: High temps cause automatic restarts. Improve cooling, clean dust from fans, reduce overclock
• Power Supply Issues: Insufficient or unstable PSU causes reboots. Verify PSU wattage meets miner requirements with 10-15% headroom
• Pool Server Load: Overwhelmed pool servers may drop connections. Switch to less congested pool or server region
• DDoS Protection: Some pools have aggressive DDoS protection that may flag legitimate miners as attacks. Contact pool support for whitelisting

Symptoms: Miner connects and submits shares, but reported hashrate significantly below specification

Possible Causes and Solutions:

• Missing Hash Boards: One or more hash boards not detected. Check physical connections, reseat boards, inspect for damage
• Thermal Throttling: Overheating causes automatic frequency reduction. Improve cooling, clean fans, verify ambient temperature <35°C
• Power Supply Insufficient: Undersized PSU can’t deliver full power, limiting performance. Use properly rated PSU (e.g., 3,600W for S21)
• Software Underclocking: Check miner frequency settings—may be accidentally set to low-power mode. Reset to default or increase frequency
• Pool Difficulty Too High: Very high assigned difficulty causes infrequent share submissions, making hashrate estimation inaccurate. Wait 2-4 hours for more accurate average

Symptoms: Miner hashing correctly but daily earnings below profitability calculator estimates

Possible Causes and Solutions:

• Pool Fees: Calculators often show gross revenue. Subtract pool fee (typically 0.5-3%). Example: $10/day gross – 2% fee = $9.80 net
• Payment Method (PPS vs PPLNS): PPLNS pools have variance—some days higher, some lower. Average over 7-14 days for accurate comparison
• Stale/Rejected Shares: 2-5% stale/rejected reduces effective hashrate. Improve connection quality, reduce latency, fix hardware errors
• Network Difficulty Increased: Bitcoin difficulty adjusts every 2 weeks. Recent increase reduces earnings. Use current difficulty in calculator, not old data
• Pool Luck: Small pools have higher variance in block finding. Some weeks lucky (more earnings), some unlucky (less). Large pools smooth this variance

✅ Benefits for Individual Miners:

• Higher Effective Hashrate: 1.5-2.5% more revenue from reduced stale shares (worth $200-500/year for typical home miner)
• Better Privacy: Encrypted communication prevents ISPs, governments, or attackers from monitoring mining activity or revenue
• Censorship Resistance: Job Negotiation Protocol allows choosing which transactions to include, preventing pool-level censorship
• Lower Bandwidth Costs: Particularly valuable for satellite internet or metered connections (save 30-70% bandwidth)
• More Reliable Connection: Binary protocol more resilient to parsing errors and network issues

💡 Benefits for Bitcoin Network:

• True Decentralization: Shifting transaction selection from pools to individual miners eliminates single point of censorship
• Regulatory Resistance: Encrypted miningtraffic harder to detect and regulate, protecting mining freedom
• Improved Security: Eliminates hashrate hijacking attacks that plagued V1 pools
• Better Fee Markets: Miners selecting transactions create more efficient fee markets, benefiting users
• Geographic Distribution: Lower bandwidth requirements enable mining in bandwidth-constrained regions, improving geographic decentralization

V2 Preparation Checklist:

1. Firmware Upgrade: Update miners to latest firmware supporting V2 (BraiinsOS+, official Bitmain/MicroBT firmware from Q2 2026+)
2. Choose V2-Supporting Pool: Select pool offering V2 endpoints (Braiins, Foundry USA beta, others launching Q3 2026)
3. Test Configuration: Configure one miner with V2 endpoint to verify compatibility before migrating fleet
4. Monitor Performance: Compare stale share rates between V1 and V2 connections to quantify improvement
5. Consider Job Negotiation: For advanced users, explore running Template Provider to enable custom transaction selection
6. Update Documentation: Revise your standard operating procedures and configuration templates for V2 protocol

Job Negotiation Requirements:

1. Bitcoin Core Node: Run full Bitcoin node (Bitcoin Core 24.0+) synchronized with latest blockchain
   • Hardware: ~4 CPU cores, 8 GB RAM, 600 GB SSD storage, 100 Mbps internet
   • Initial sync: ~24-48 hours
2. Template Provider: Run translation software between Bitcoin Core and pool
   • Options: Braiins Template Provider (official), community forks
   • Connects to Bitcoin Core via RPC, communicates with pool via V2 protocol
3. Configure Miners: Point miners to Template Provider instead of directly to pool
   • Template Provider acts as local proxy, handling job negotiation with pool
   • Miners receive custom-built block templates matching your transaction selection policy

Who Should Use JNP: Miners with strong censorship resistance principles, large operations (>10 PH/s) wanting transaction selection control, or those philosophically aligned with decentralization. Not necessary for profit-maximizing miners who trust pools.

⚠️ The Centralization Problem V2 Solves:

In Stratum V1, mining pools control which transactions get included in blocks. Top 5 pools control ~65% of hashrate. If governments pressure these 5 entities to censor specific transactions (e.g., from sanctioned addresses, privacy tools, competitors), they can effectively censor Bitcoin at the protocol level.

V2 Job Negotiation Changes This: Even if you mine at a large pool, YOU decide which transactions to include. If the pool tries to force censorship, you can:

• Override their template with your own (including “censored” transactions)
• Switch to different pool that respects transaction selection freedom
• Mine solo with your custom templates

Result: Bitcoin becomes truly censorship-resistant at the individual miner level, not just pool level. This is critical for Bitcoin’s value proposition as permissionless money.