Running Bitok - 0.3.19 Mainnet

[elvisjedusor]

Bitok Web Wallet Update

New features added:

• Send BITOK to Contract Script
• Escrow management interface
• Developer Mode (enable in Settings)

Developer Mode includes new contract templates:

Hashlock / HTLC

Multisig (m-of-n)

Data embedding (OP_RETURN)

Contract templates allow users to construct, inspect, and manage raw scripts and transactions directly in the browser, without custodial intermediaries.

Thanks to Tongpu for contributing to this update.

Web wallet:
http://wallet.bitokd.run

[neur0n.inc]

Patched for wxWidgets 3.2. The issue was that wxWidgets 3.2 with GCC 15 on MinGW no longer allows implicit conversion from wxString to const char*.

Please pull from git and try building again, following the instructions. The windows GUI wallet should build successfully now.

Thank you.
Now something else is happening here...
Or something else is wrong here, or something is wrong with my msys2...
There are a lot of lines and I can't post it here. I posted this text file in a file sharing service - https://dropmefiles.com/67CZX

As a last resort, I'm thinking about compiling this program in wsl2 (debian 12/ubuntu). But I would like to do it in msys2.

And one more thing... In the makefile.mingw, I make changes:
lines 93, 110
-lboost_system-mt instead of -lboost_system-mt-x64
lines 94, 111
-lboost_filesystem-mt instead of -lboost_filesystem-mt-x64
There are no libboost_system-mt-x64 and libboost_filesystem-mt-x64 files/libs in msys2, but there are libboost_system-mt and libboost_filesystem-mt.
I add the libboost_system-mt files/libs manually from the mingw-w64-x86_64-boost-1.86.0-1 package, since newer packages don't have it (mingw-w64-x86_64-boost-libs-1.90.0-3 and mingw-w64-x86_64-boost-1.90.0-3, for example).
I don't think all this has a negative impact on bitok compilation - bitokd compilation is always successful.

[Tongpu]

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

[shinohai]

Bitok Web Wallet Update

New features added:

• Send BITOK to Contract Script
• Escrow management interface
• Developer Mode (enable in Settings)

Developer Mode includes new contract templates:

Hashlock / HTLC

Multisig (m-of-n)

Data embedding (OP_RETURN)

Contract templates allow users to construct, inspect, and manage raw scripts and transactions directly in the browser, without custodial intermediaries.

Thanks to Tongpu for contributing to this update.

Web wallet:
http://wallet.bitokd.run

Testing the web wallet with developer options on, and did not get OP_RETURN working. Client gives me a tx id but it does not appear to broadcast to network.

UPDATE: Got it working, nm. Had to do some firewall tinkering back to node.

[elvisjedusor]

bitokd.run explorer upgraded

https://bitokd.run

New design. Added contracts page, script decoding and classifications.

[yoshikiazuma]

bitokd.run explorer upgraded

https://bitokd.run

New design. Added contracts page, script decoding and classifications.

https://i.ibb.co/GfXmYQW1/Screenshot-from-2026-02-23-15-02-44.png

https://i.ibb.co/RGwvLRP8/Screenshot-from-2026-02-23-15-03-00.png

cool. but could you also make a link to the old block explorer too, with all the original formats and document and document too, you could title the old bitok explorer's httplink as ".old" or something you could think of

because i think we should keep a history of the changes and as reference to revisit the old site format? do you think that would be a good idea?

i just want to be able to revisit and reread the old stuff in the future, thats also the reason why

the new look of the explorer seems mysterious cool (:

[elvisjedusor]

cool. but could you also make a link to the old block explorer too, with all the original formats and document and document too, you could title the old bitok explorer's httplink as ".old" or something you could think of

because i think we should keep a history of the changes and as reference to revisit the old site format? do you think that would be a good idea?

i just want to be able to revisit and reread the old stuff in the future, thats also the reason why

the new look of the explorer seems mysterious (:

Old explorer code is available at https://github.com/elvisjedusor/explorer.

[neur0n.inc]

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

Thank you. It worked. Now these MinGW DLLs are required:

for bitokd.exe:
libcrypto-3-x64.dll
libdb_cxx-6.2.dll
libgcc_s_seh-1.dll
libstdc++-6.dll
libwinpthread-1.dll

for bitok.exe:
libcrypto-3-x64.dll
libdb_cxx-6.2.dll
libdeflate.dll
libgcc_s_seh-1.dll
libjbig-0.dll
libjpeg-8.dll
libLerc.dll
liblzma-5.dll
libpcre2-16-0.dll
libpng16-16.dll
libsharpyuv-0.dll
libstdc++-6.dll
libtiff-6.dll
libwebp-7.dll
libwinpthread-1.dll
libzstd.dll
wxbase32u_gcc_custom.dll
wxmsw32u_core_gcc_custom.dll
wxmsw32u_html_gcc_custom.dll
zlib1.dll

But it's okay.
I hope to get to static in the near future.

[zipnoid]

Personal opinion, I liked the old version of the block explorer better. It stood out as a solid back-to-the-basics UI - which inspired a lot of confidence.
This one looks too underground, which could scare some new supporters.

[weesdr]

Yes, I have the same feeling too. Not a fan of the new explorer, I would prefer the old one instead

[yoshikiazuma]

cool. but could you also make a link to the old block explorer too, with all the original formats and document and document too, you could title the old bitok explorer's httplink as ".old" or something you could think of

because i think we should keep a history of the changes and as reference to revisit the old site format? do you think that would be a good idea?

i just want to be able to revisit and reread the old stuff in the future, thats also the reason why

the new look of the explorer seems mysterious (:

Old explorer code is available at https://github.com/elvisjedusor/explorer.

Thanks someone could build a secondary explorer. I'll see if I can get idpool could recreate it and see if I get a reply

[garmin]

Why does the only Bitok pool require custom mining settings?  (--param-n=2048 --param-r=32 --param-key="BitokPoW")

Is this to keep rented hash off the pool? It looks like those extra coin specific settings could be implemented in the pools bitok.json, config.php, serverconfig.php
files on the backend according to the repos POOL_INTEGRATION.md

https://github.com/elvisjedusor/bitok/blob/master/POOL_INTEGRATION.md

Bottom line, Bitok needs more pools.

[Tongpu]

Why does the only Bitok pool require custom mining settings?  (--param-n=2048 --param-r=32 --param-key="BitokPoW")

Is this to keep rented hash off the pool?

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.

It looks like those extra coin specific settings could be implemented in the pools bitok.json
Bottom line Bitok needs more pools.

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.

[Laheeboo]

we are AFRIAD OF CHANGE the old explorer looked more OG

[garmin]

Why does the only Bitok pool require custom mining settings?  (--param-n=2048 --param-r=32 --param-key="BitokPoW")

Is this to keep rented hash off the pool?

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.

It looks like those extra coin specific settings could be implemented in the pools bitok.json
Bottom line Bitok needs more pools.

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.

Strange UraniumX has the same parameters minus the  --param-key="BitokPoW"  It uses --param-key "UraniumX"

Yet the UraniumX pools don't require the special parameters to mine.

--algo yespower: Specifies the primary mining algorithm is yespower.
--param-n 2048 --param-r 32: These are standard parameters for many yespower implementations (specifically yespower version 0.5) and define the algorithm's memory usage and iterations.
--param-key "UraniumX": This is a unique parameter, specific to the UraniumX coin, which acts as a key or salt for the algorithm, ensuring that only miners configured with this specific key can mine the coin's blockchain.

It looks like some other mining SW used prepend (ALGO -a) minerd.exe -a yespowerurx -o stratum+tcp://cpu-pool.com:63378 -u [WalletAddress] to designate the specific ALGO rather than adding the special parameters to the miner

https://github.com/RainbowMiner/RainbowMiner/blob/5e264ec70af8287aa8deec68a7353cb96228d7bf/Miners/CpuminerJayddee.ps1#L104
[PSCustomObject]@{MainAlgorithm = "yespowerURX"; Params = "--param-n 2048 --param-r 32 --param-key `"UraniumX`""; Algorithm = "yespower"} #Yespower Uranium-X (URX)

Looks like we need a special miner to fix this unless it can be done on the backend. Several coins already accommodate the special parameters by prepending the algo in the miner. I.E.  (-a yespowerBitok)  

LIKE THIS > ./cpuminer -a yespowerBitok -o stratum+tcp://lastbitcoin.org:3032 -u YOUR_BITOK_ADDRESS.worker1

--algo yespower --param-key "CPUpower: The number of CPU working or available for proof-of-work mining"

power2b: --algo yespower-b2b --param-n 2048 --param-r 32 --param-key "Now I am become Death, the destroyer of worlds"

sugarchain: --algo yespower --param-n 2048 -param-r 32 --param-key "Satoshi Nakamoto 31/Oct/2008 Proof-of-work is essentially one-CPU-one-vote"

yespoweriots: --algo yespower --param-n 2048 --param-key "Iots is committed to the development of IOT"

yespowerlitb: --algo yespower --param-n 2048 --param-r 32 --param-key "LITBpower: The number of LITB working or available for proof-of-work mini"

yespoweric: --algo yespower --param-n 2048 --param-r 32 --param-key "IsotopeC"

yespowerurx: --algo yespower --param-n 2048 --param-r 32 --param-key "UraniumX"

yespowerltncg: --algo yespower --param-n 2048 --param-r 32 --param-key "LTNCGYES"


Am I missing something?

[Bumbulas]

Personally, I really like the new look. The old explorer is definitely OG, but this new one has a real soul to it. The functionality actually got even better, and the new theme reflects the current state of the project really well. Honestly, seeing this level of work, it’s hard to believe elvisjedusor is pulling this off alone 

[Tongpu]

Yet the UraniumX pools don't require the special parameters to mine.

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.

It looks like some other mining SW used prepend (ALGO -a) minerd.exe -a yespowerurx -o stratum+tcp://cpu-pool.com:63378 -u [WalletAddress] to designate the specific ALGO rather than adding the special parameters to the miner

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

[Tongpu]

Personally, I really like the new look. The old explorer is definitely OG, but this new one has a real soul to it. The functionality actually got even better, and the new theme reflects the current state of the project really well. Honestly, seeing this level of work, it’s hard to believe elvisjedusor is pulling this off alone  

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

[yoshikiazuma]

Bitok Added Idpool

Pool : https://bitok.idpool.id
Discord : https://discord.gg/8KnMJyx6
Telegram: https://t.me/idpool_id

Thanks

Hello everyone. Here you see above is the idpool's links. I've spoken with jerri the owner and he is happy to boot up the old bitok blockexplorer. He's looking for donations. So please get in contact with him and donate to him directly. I'll try and get him to post here on bitcoin talk with the details

I know some people here are wanting the old bitok blockexplorer. I think it's a good idea too, and good idea to have a secondary explorer alongside the main one

[yoshikiazuma]

This is the old bitok style explorer by idpool:

https://bitokexp.idpool.id/

And this is idpool's bitok donation address to keep the server running:

https://bitokexp.idpool.id/donate

1M64pazhX8TTbDMocvC2ZwbfAwNeMeVBBS