Bitok experimental pool support

[Tongpu]

The mining pool Bitok node has been upgraded to the latest release 0.3.19.8 (Security Hardening)  

[yoshikiazuma]

Pool Optimizations Live

✅ Difficulty targets and varDiff optimized - blocks coming more frequently (I believe)
✅ Pending payouts update in real-time when blocks confirm
✅ Better earnings visibility across the board

Happy mining! 🚀

The mining pool Bitok node has been upgraded to the latest release 0.3.19.8 (Security Hardening)  

nice!

[yoshikiazuma]

hi

this is my miner address: 1Bg8QHGJATvFdW5NasGi53zHevvHsNzom9

ive been mining 10 hours. i only got one payout during that 10 hours of leaving my miner online

my pending immature balance did not accurately correctly update compared to my shares rate for, 10 hours = 1323 accepted shares

could you have a look and confirm if im correct on this

thank you

[Tongpu]

hi

this is my miner address: 1Bg8QHGJATvFdW5NasGi53zHevvHsNzom9

ive been mining 10 hours. i only got one payout during that 10 hours of leaving my miner online

my pending immature balance did not accurately correctly update compared to my shares rate for, 10 hours = 1323 accepted shares

could you have a look and confirm if im correct on this

thank you

Pool payouts are calculated correctly. It uses 60-minute window before each found block. Only shares submitted in that round are counted. Shares are weighted by difficulty, mean - one higher-diff share is worth more than many low-diff shares. Raw share count (like 1323) does not equal payout amount.

If no block is found during part of your mining time, there is nothing to pay for that period. Immature balance updates only when a block is found and your weighted shares are included in that round.

Read this also - https://bitcointalk.org/index.php?topic=5572258.msg66331755#msg66331755

[Tongpu]

Pool just upgraded! Bug fixed

Bitok uses >> 17 instead of >> 16
Most yespower coins (Tidecoin, Cranepay, etc.) use bnProofOfWorkLimit = ~uint256(0) >> 16, which gives diff1 = 2^240 and perfectly matches cpuminer-opt's opt_target_factor = 65536.

Bitok chose >> 17 (diff1 = 2^239), making the minimum difficulty target 2x harder than the yespower standard. This is a valid design choice -- it means Bitok's "difficulty 1" represents twice as much work as other yespower coins' "difficulty 1". The multiplier of 2 bridges this gap at the pool level.

[Tongpu]

Bitok pool node upgraded to latest 0.3.19.9 release

[zipnoid]

It's been a wild ride to see the pool hashrate going up and up! Almost at 200KH/s!

[aviestegmeier]

is pool down? My stratum connectin is failed

[Tongpu]

is pool down? My stratum connectin is failed

Hey, pool working, yesterday my hosting provider experienced a DDoS attack that impacted network connectivity to the VPS running the stratum server, causing instability for approximately 30 minutes.

[weesdr]

Thanks for open sourcing the pool.

I'm trying to set it up. I have a miner running against my pool, but then after about 1 minute mining, the pool stops accepting shares

On my miner I keep seeing this, and eventually stratum connection timeout. Why is that?

[2026-03-03 05:22:58] 47 Submitted Diff 1.2177e-05, Block 21822, Job 3
[2026-03-03 05:23:03] 48 Submitted Diff 1.6719e-05, Block 21822, Job 3
[2026-03-03 05:23:03] 49 Submitted Diff 1.7693e-05, Block 21822, Job 3
[2026-03-03 05:23:10] 50 Submitted Diff 3.7941e-05, Block 21822, Job 3
[2026-03-03 05:23:26] 51 Submitted Diff 1.8675e-05, Block 21822, Job 3
[2026-03-03 05:23:28] 52 Submitted Diff 1.566e-05, Block 21822, Job 3
[2026-03-03 05:23:29] 53 Submitted Diff 0.00013631, Block 21822, Job 3
[2026-03-03 05:23:29] Stratum connection timeout

[Tongpu]

Thanks for open sourcing the pool.

I'm trying to set it up. I have a miner running against my pool, but then after about 1 minute mining, the pool stops accepting shares

On my miner I keep seeing this, and eventually stratum connection timeout. Why is that?
..
[2026-03-03 05:23:29] Stratum connection timeout

Check your setup with this guide:
https://github.com/antitongpu/bitok-stratum-pool/blob/main/DEPLOY.md

[weesdr]

Thanks a lot for the guide. It really helps a lot but I have a few issues if you can help me out please

I followed the instructions and I'm getting the error about immature table not existed when running the pool

I also can't access my miner details (workers, payment made, hashrate graph etc) in web portal

When I run the pool, I can see it's showing pool fee 0% in the log, but the web portal is showing pool fee 1%

[Tongpu]

Thanks a lot for the guide. It really helps a lot but I have a few issues if you can help me out please

I followed the instructions and I'm getting the error about immature table not existed when running the pool

I also can't access my miner details (workers, payment made, hashrate graph etc) in web portal

When I run the pool, I can see it's showing pool fee 0% in the log, but the web portal is showing pool fee 1%

pool db schema was upgraded from this guide. you need:

go to bitok-pool/pool-server and run:

Code:

PGPASSWORD='YOUR_PG_PASSWORD' psql -h localhost -U bitokpool -d bitok_pool -f sql/schema.sql

verify

Code:

PGPASSWORD='YOUR_PG_PASSWORD' psql -h localhost -U bitokpool -d bitok_pool -c "\dt"

Expected output:

Code:

            List of relations
 Schema |    Name     | Type  |   Owner
--------+-------------+-------+-----------
 public | blocks      | table | bitokpool
 public | miners      | table | bitokpool
 public | payments    | table | bitokpool
 public | pool_stats  | table | bitokpool
 public | shares      | table | bitokpool

Verify the miners table has all required columns:

Code:

PGPASSWORD='YOUR_PG_PASSWORD' psql -h localhost -U bitokpool -d bitok_pool -c "\d miners"

the output must include `balance` and `immature` columns. If they are missing, drop and recreate the tables using the schema file (safe to do on a fresh install with no data).

Verify the blocks table:

Code:

PGPASSWORD='YOUR_PG_PASSWORD' psql -h localhost -U bitokpool -d bitok_pool -c "\d blocks"

The output must include `paid` and `credited` columns.

*or run all migrations https://github.com/antitongpu/bitok-stratum-pool/tree/main/pool-server/sql/migrations from pool-server folder:

Code:

# Migration 1: Adds error_message and blocks_included to payments table
PGPASSWORD='YOUR_PG_PASSWORD' psql -h localhost -U bitokpool -d bitok_pool -f sql/migrations/001_update_payments_table.sql

# Migration 2: Adds paid column to blocks table
PGPASSWORD='YOUR_PG_PASSWORD' psql -h localhost -U bitokpool -d bitok_pool -f sql/migrations/002_add_paid_column.sql

# Migration 3: Adds balance and immature columns to miners table (REQUIRED)
PGPASSWORD='YOUR_PG_PASSWORD' psql -h localhost -U bitokpool -d bitok_pool -f sql/migrations/003_add_balance_tracking.sql

# Migration 4: Adds credited column to blocks table (REQUIRED)
PGPASSWORD='YOUR_PG_PASSWORD' psql -h localhost -U bitokpool -d bitok_pool -f sql/migrations/004_add_credited_column.sql

# Migration 5: Fixes credited flag for blocks that were already paid out
PGPASSWORD='YOUR_PG_PASSWORD' psql -h localhost -U bitokpool -d bitok_pool -f sql/migrations/005_fix_credited_for_paid_blocks.sql

[Tongpu]

[POOL UPDATE] Stability Fix

Pushed a stability fix that resolves the performance degradation issue some of you may have noticed.

What was happening:

Every time a miner connected and then disconnected (normal reconnects, network drops, rig reboots), the pool was leaving behind ghost event listeners that never got cleaned up. This caused increasing memory pressure, incorrect difficulty calculations, and eventually the pool would slow down finding blocks until we restarted it.

A second related issue: miners who disconnected with a hard TCP reset (power loss, network cut) would sometimes stay in the active client list invisibly. The pool kept sending new jobs to these dead connections on every block, making broadcasts slower and slower as the list grew.

What was fixed:

Miner disconnect now properly cleans up all associated state and listeners immediately
Added a background sweep every 60 seconds to purge any dead socket connections that slipped through
Some security fixes

Result: Pool should now run stably for days/weeks without needing manual restarts. Block find times should remain consistent throughout the day.

No action needed from miners.