Avg block time in the current diff window is 398 seconds (6.6 minutes). Difficulty increase incoming?

This mean UTXO is already spent. Check status:
https://bitokd.run/contract/99a9e46537a91544a0f3e6f17e22a7eb708d6cb30ed04cefcb736ff9049d66c3/0

In this tx: https://bitokd.run/tx/0924f5b0046b93bef8dc73a5710a96ae2b07bdc99f1b6ffb9e195442fbe61632
This address: 18A9Pcnpq8TnEWY19zY6PKWJTHqF5o3p9Q


Congratulations!

KEEP BITCOIN LEGACY!

Funding txid is not correct and my hashlock is custom script, not template from web wallet.
Follow this: https://bitcointalk.org/index.php?topic=5571165.msg66486671#msg66486671

Fixed


All 3 secrets released
3rd word hidden here:
Bitok tx: bf11263580230fde4e47ad65a8e562bbc2aaf28f184046458873e1f853252b86

Combine them in order, no spaces, uppercase and unlock 50 $BITOK

Fixed

[POOL UPDATE] Infrastructure scaling completed.
Over the last hour we performed maintenance to increase pool capacity and hashing power. All systems are now operating normally.

When you have all 3 words (WORD1, WORD2, WORD3), combine them: no spaces, uppercase, in order WORD1WORD2WORD3

2nd secret is hidden here:
  TXID: 65456d98f6cb62b0a13ccd0090035a0713a292d412301d6ad65e1b82deae49e7


This is hashlock data:

Step by step:

Step 1. Combine the 3 secret words and encode to hex.
If you are on Linux/Mac, run:
Replace WORD1WORD2WORD3 with your actual combined answer.
That output is your PREIMAGE_HEX.

Step 2. Create the claim transaction:
Copy the output hex. Call it SPEND_HEX.

Step 3. Inject the preimage:
From the JSON output, copy the "hex" value. Call it SPEND_SIGNED.

Step 4. Verify before broadcasting:
Must return: "verified": true
If false - your answer is wrong. Do not broadcast. Recheck.

Step 5. Broadcast and win:
The returned txid is your win proof.

1st word is hidden here:
  TXID: 40b65eacacd9dc1693ea48dc57b85bdc69f996dcf2a49c930b068ea1308f4995

How to find the word:
1. bitokd getrawtransaction TXID 1
   Look at the vout array. Find the output with "type": "nulldata".
   The "hex" field will be the OP_RETURN data prefixed with "6a" and a length byte.
   Strip the prefix (6a + first byte ) and decode the remaining hex to ASCII.

2. Or use the block explorer - paste the txid, find OP_RETURN output, and *decode the hex.
*Thanks to Elvis, our explorer is powerful and decode it automatically (do the work for you, haha).

This is really huge. I can build scripts like puzzles, natively! Why has no one done this for Bitcoin?
We could even create a UI where users can drag and drop opcodes and insert data like they’re playing a game
Big respect for this.

---

Lets make some fun and learn something new

Im just locked 50$BITOK in a SHA256 hashlock script on the Bitok blockchain:
https://bitokd.run/contract/99a9e46537a91544a0f3e6f17e22a7eb708d6cb30ed04cefcb736ff9049d66c3/0

The prize can only be claimed by broadcasting a transaction with the correct preimage (secret).
The secret is built from 3 words hidden across 3 transactions.

I will post one transaction per day for 3 days. Each transaction contains one word encoded as UTF-8 hex in an OP_RETURN output.
Find the word, write it down, wait for the other.

PRIZE TRANSACTION:
  Funding txid: 99a9e46537a91544a0f3e6f17e22a7eb708d6cb30ed04cefcb736ff9049d66c3
  Output index: 0
  Lock script:  a8201804ab125392cdac647c3fb048f59c9d05fa4f103571239e2c379cb15084a5f187

Verify the prize is real (run this yourself):
  ./bitokd getrawtransaction 99a9e46537a91544a0f3e6f17e22a7eb708d6cb30ed04cefcb736ff9049d66c3 1

No admin. No submission. Broadcasting the spend transaction is how you claim.
The first valid spend transaction wins.

https://x.com/antitongpu/status/2029896414516347233

[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.

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

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

If you were solo mining, each block reward created a new address inside your local wallet.dat. The web wallet only restored the one key you imported, that’s why you don’t see your mined balance.

Open your downloaded wallet, let it sync, and send all your funds to one address from your web wallet. After confirmation, everything will show there.

If you mined on a pool, this wouldn’t be needed since pool rewards go to the address you set.

P.s. also 'changes' creating new addresses for every new incoming change when you send, not only mining (it is only for full wallet. If you use send with web wallet changes back to your logged address)

I want bitok t-shirt like this lol, looks cool

cool 

https://bitokd.run/network

Pool can abstract some parameters internally. But this is technically a bad idea in crypto.

1. It breaks transparency
When you explicitly pass params in miner you know exactly what hash function executing. If the pool injects parameters internally, you rely on the pool operator’s correctness and lose verifiability at the miner layer.

2. Multicoin proxy abuse
A generic yespower miner could be pointed to multiple coins. Pool can silently redirect hashing between chains. And yes, rented hash services can adapt more easily.

3. Share Validation
If miners configure params, invalid shares are rejected at miner level. Misconfigured miners fail fast. But if pools inject parameters, miner could compute wrong variant hashes.


Any mining soft (cpuminer, etc.) can easily bundle the required algorithm parameters into a named variant. In your example, minerd uses -a yespowerurx, which internally includes the specific parameters for UraniumX. But technically this is the same as explicitly passing yespower, n, r, key

---

"Has a real soul to it" - that's exactly what Im thinking.

We need to move from just the "Satoshi's Legacy" concept to the "Satoshi's Programmable Money" concept, since that's what we really are. Because thats what he originally put into Bitcoin. And now, 15 years later we've activated what had been hidden for so many years. In that sense, the new explorer really hits the mark.

Not a pool quirk. Bitok uses a custom pow algorithm BitokPoW (modified YesPower).
https://github.com/elvisjedusor/bitok/blob/master/BITOKPOW.md

Not bulletproof against rented hash, but it raises the barrier for quick flash attacks. Smart move implementing it from start.


Miners must use those exact parameters or they will produce invalid hashes/shares.

More pools are needed. It's not hard to implement Bitok on an existing pool.

from your logs: compilation is ok, linker fails.
You need remove -static from line 41 at makefile.mingw (but keep -static-libgcc -static-libstdc++):

40 # Static linking for portability (no DLL dependencies)
41 LDFLAGS = -static -static-libgcc -static-libstdc++

or build wxWidgets static

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.