Running Bitok - 0.3.19 Mainnet

[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

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

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

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.

Yes (: it's more of a cypherpunk vibe which I like the new explorer

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

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.

bitok is way more than standard, im liking what i see and i agree me you and three (:

[Tongpu]

cool 

https://bitokd.run/network

[neur0n.inc]

Yes, it's great. And the orange color is very suitable, bitok explorer looks nicer.

[Btc_order]

Do you guys know if any vps platform or something like that can mine with cpu?

[aviestegmeier]

Do you guys know if any vps platform or something like that can mine with cpu?

i don't really recommend you to mine on a rented vps/vds. Most of the cloud providers prohibit mining on rented devices.

[aviestegmeier]

Do you guys know if any vps platform or something like that can mine with cpu?

i don't really recommend you to mine on a rented vps/vds. Most of the cloud providers prohibit mining on rented devices.

i agree. use it for personal gains on a personal computers.

it was to have more power

Technically you could try.. but cloud provider will most likely terminate your server and account and you won't receive a refund for that. You could try to rent hash power from nicehash but i don't really sure if they support yespower algorithm. There is also providers available that rent cpu and gpu power for ai stuff, but with a few tweaks i guess you can use them for bitok mining too.

[Btc_order]

Do you guys know if any vps platform or something like that can mine with cpu?

i don't really recommend you to mine on a rented vps/vds. Most of the cloud providers prohibit mining on rented devices.

i agree. use it for personal gains on a personal computers.

it was to have more power

Technically you could try.. but cloud provider will most likely terminate your server and account and you won't receive a refund for that. You could try to rent hash power from nicehash but i don't really sure if they support yespower algorithm. There is also providers available that rent cpu and gpu power for ai stuff, but with a few tweaks i guess you can use them for bitok mining too.

can you send me the link of the ai for mining?

[elvisjedusor]

The privacy model in the Bitcoin whitepaper was always meant to be stronger than what the network delivered in practice. Satoshi knew this. He researched key blinding. He sketched out network-level unlinkability. He recommended Tor. He said addresses should be used only once.

Bitok takes these ideas and makes them real, in working code, in a way that is compatible with the original protocol design. No forks. No new trust assumptions. Just the privacy that was always supposed to be there.

This is the first feature, and it is the one Satoshi described most concretely. I have implemented it exactly as he envisioned: blinded variations of a public key, where each payment goes to a unique, unlinkable address, and only the intended recipient can detect and spend the funds.

Read more: https://github.com/elvisjedusor/bitok/blob/master/docs/PRIVACY.md

Commit: https://github.com/elvisjedusor/bitok/commit/b3f4d67246d58a673fc99b93c6ecc21a3cbcb5d6

Stealth ok-addresses support will be included in next Bitok release

How it works:

You have ONE stealth ok-address (for ex. okCQyc...N5NX). When someone sends you coins, the protocol automatically generates a brand new, unique one-time address for that specific transaction. So on the blockchain, every payment to you looks like it goes to a completely different address, no one can link them together or see they all belong to you.

The two secrets:

Scan secret - lets your wallet scan the blockchain and detect "this transaction is mine"
Spend secret - lets you actually spend those coins

Backup / Recovery:

You only need to save those two secrets (scan_secret + spend_secret). That's it. You can throw away the wallet.dat, set up a completely fresh wallet on a new machine, import those two secrets, and your wallet will:
Scan the blockchain
Find all transactions that were sent to your stealth address
Derive all the one-time private keys needed to spend them
Show your full balance

In a simple words two WIF keys (new update) one secret key (SK...) on a piece of paper is your entire backup. No need to keep track of hundreds of generated addresses or back up wallet.dat after every transaction. That's the main advantage ok-addresses over regular addresses.

[yoshikiazuma]

The privacy model in the Bitcoin whitepaper was always meant to be stronger than what the network delivered in practice. Satoshi knew this. He researched key blinding. He sketched out network-level unlinkability. He recommended Tor. He said addresses should be used only once.

Bitok takes these ideas and makes them real, in working code, in a way that is compatible with the original protocol design. No forks. No new trust assumptions. Just the privacy that was always supposed to be there.

This is the first feature, and it is the one Satoshi described most concretely. I have implemented it exactly as he envisioned: blinded variations of a public key, where each payment goes to a unique, unlinkable address, and only the intended recipient can detect and spend the funds.

Read more: https://github.com/elvisjedusor/bitok/blob/master/docs/PRIVACY.md

Commit: https://github.com/elvisjedusor/bitok/commit/b3f4d67246d58a673fc99b93c6ecc21a3cbcb5d6

Stealth ok-addresses support will be included in next Bitok release

How it works:

You have ONE stealth ok-address (for ex. okCQyc...N5NX). When someone sends you coins, the protocol automatically generates a brand new, unique one-time address for that specific transaction. So on the blockchain, every payment to you looks like it goes to a completely different address, no one can link them together or see they all belong to you.

The two secrets:

Scan secret - lets your wallet scan the blockchain and detect "this transaction is mine"
Spend secret - lets you actually spend those coins

Backup / Recovery:

You only need to save those two secrets (scan_secret + spend_secret). That's it. You can throw away the wallet.dat, set up a completely fresh wallet on a new machine, import those two secrets, and your wallet will:
Scan the blockchain
Find all transactions that were sent to your stealth address
Derive all the one-time private keys needed to spend them
Show your full balance

In a simple words two WIF keys on a piece of paper is your entire backup. No need to keep track of hundreds of generated addresses or back up wallet.dat after every transaction. That's the main advantage ok-addresses over regular addresses.

 i first met my first cryptonote coin back in 2012-13, mined my first ever coins. now lost (but the dice later changed in 2014. and which i missed and later to find out what those two were about, i was late).

i like the idea of bitokoin to incorporate a sense of privacy too (:

because as you mention because bitcoin has the tools built in to achieve those goals

i also think that quantum resistance would be necessary before the future takes hold of bitokoin

and a some solution to having a stable coin mechanism between bitok (bitok's very own designed stable coin built in)

im looking forwards to the next software release
is there anyone upto making a new bitok exchange or forum website, if you do

name it 'Y'nance (yoshiki+finance)

haha (:

get it

probably my message will stand as a meme, unless there's results

-Yinancial

[Tongpu]

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

[yoshikiazuma]

Uh?? Bitok has contracts? Like smart contracts woah.

It be nice to see collectables, coins, etc which are also minable too. Possibly having their own network or layer maybe?

I'm imagining for bitok to have a live playable game playable directly on the Blockchain maybe, which the collectables are minable/mintable

And for the smart contracts coins like other technology and features directly minable or maybe also add a staking function that could be fair

And a minable stable coin or also mintable maybe also adding burning function for a stable coin on the bitok ecosystem that would be also insane (:

A coin that also generates yields somehow

All that could make use for a in game trading (I could be missing some other mechanisms but Blockchain/technology isn't as bound as much to a limit at the moment there's limitless possibilities in the current time

A real world in game Blockchain economy. Scarce assets tradable for collectables or stable value etc

Anyways the game

If there is a Blockchain bitok game in the future that could or will be built. I'd like the first game on bitok to be something of like a monster collection, battle, level up, evolution, unique stats etc. feature game. Similar to how Pokémon works. A Pokémon like games also having an immersive story line and experience like directly competing with Pokémon games. I've always been a fan but I've changed since. I've turned to Blockchain been anticipating for a game of such on Blockchain which is like no other

If I could code or even build a game I would have done it years ago but I lack the skills

I've always loved the 2d/3d isometric games. My first game, on game boy game was Pokémon crystal and also silver

[Laheeboo]

I was excited for the web wallet, I restored my wallet using the key, it shows my transfers balance from faucet but not my mined balance, how would I be able to access that?

[Tongpu]

I was excited for the web wallet, I restored my wallet using the key, it shows my transfers balance from faucet but not my mined balance, how would I be able to access that?

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)

[elvisjedusor]

Bitok v0.3.19.11 “Native Blind” released

• Full RPC support for arbitrary script contract construction and validation
• Native Blind (ok-addresses): ECDH-based stealth payments
• Deterministic change for stealth UTXOs
• GUI support for stealth address management

No consensus changes.

1. Full Script Contract RPC Suite

This release completes the missing pieces required to build, sign, and validate arbitrary custom scripts without template-specific RPCs.

New RPC Commands:

buildscript

Assemble scripts from opcode names and hex pushes.

Code:

buildscript '["OP_ADD","OP_5","OP_EQUAL"]'

Returns serialized script hex.

No manual hex encoding required.

--------------------------------------------------

setscriptsig

Inject a custom scriptSig into any transaction input.

Accepts:

• Raw hex
• Array of hex pushes
• Space-separated opcode strings

This is the key missing component.

signrawtransaction only auto-signs known templates.  
setscriptsig allows arbitrary stack construction for any script.

--------------------------------------------------

getscriptsighash

Exposes the internal SignatureHash() computation.

Returns the exact 32-byte digest that OP_CHECKSIG verifies.

Required for:

• Custom scripts mixing logic and signatures
• External/offline signing workflows
• Non-standard signature flows

--------------------------------------------------

decodescriptsig

Decodes a scriptSig in context of its scriptPubKey.

Stack elements are labeled by role (signature, pubkey, preimage, push_0, etc.) based on script classification.

--------------------------------------------------

verifyscriptpair

Full scriptSig + scriptPubKey verification against a real transaction context.

Unlike validatescript, this supports OP_CHECKSIG.

Includes failure diagnostics.

--------------------------------------------------

Complete Custom Script Workflow

Any arbitrary contract can now follow:

Code:

buildscript
→ createrawtransaction
→ signrawtransaction
→ sendrawtransaction
→ createrawtransaction (spend)
→ getscriptsighash
→ setscriptsig
→ verifyscriptpair
→ sendrawtransaction

No special-case RPCs required.

--------------------------------------------------

Script Classification

analyzescript continues to classify scripts automatically:

• Arithmetic
• Bitwise
• Hashlock
• Multisig
• CAT-based covenant
• Splice

This allows introspection without per-template RPC methods.

--------------------------------------------------------------------

2. Native Blind — ok-Addresses

This release implements ECDH-based stealth addresses at the wallet layer.

No consensus change required.  
Transactions remain standard P2PKH + OP_RETURN.

Design

Receiver generates:

• Scan keypair
• Spend keypair

Stealth address encodes both compressed pubkeys:

• Prefix: ok
• Version byte: 0x01
• Payload: scan_pubkey || spend_pubkey
• Base58Check encoded

--------------------------------------------------

Sending

Sender:

• Generates ephemeral keypair
• Performs ECDH with receiver scan pubkey
• Derives shared secret via double-SHA256
• Computes one-time destination:

Code:

P_dest = P_spend + Hash(shared_secret) * G

• Creates normal P2PKH output to derived address
• Embeds ephemeral compressed pubkey in OP_RETURN with prefix 0x06

--------------------------------------------------

Receiving

Wallet scanning logic:

• Checks OP_RETURN outputs for 0x06 + 33-byte pubkey
• Performs ECDH with scan private key
• Derives expected destination
• If matched, computes:

Code:

p_dest = p_spend + Hash(shared_secret) mod n

Derived private key is imported into the keystore automatically.

No manual step required.

--------------------------------------------------

What This Achieves

• Each payment to the same ok-address produces a unique on-chain destination
• Outside observers cannot link payments to the published stealth address
• Receiver does not need to be online

--------------------------------------------------------------------

Deterministic Change for Stealth UTXOs

When spending stealth-derived outputs, change is deterministically derived:

Code:

change_priv = SHA256d(spend_secret || "stealth_change" || index)

• Ensures recoverability from exported stealth secret
• No dependency on address pool backups
• Rescan recovers derived change keys automatically

--------------------------------------------------------------------

RPC Commands for Stealth

• getnewstealthaddress
• liststealthaddresses
• sendtostealthaddress
• decodestealthaddress
• exportstealthaddress
• importstealthaddress
• getstealthephemerals
• getstealthtxids

Import performs two-pass scan to recover stealth payments and deterministic change.

--------------------------------------------------------------------

GUI Updates

GUI wallet upgraded with:

• ok-address generation
• Stealth transaction sending
• Stealth address management

--------------------------------------------------------------------

Compatibility

• Wallet-layer feature only
• Fully backward compatible
• Standard transaction format
• No hard fork
• No consensus rule changes

Bitok continues building on the 0.3.19 execution model, restoring original opcode capability and expanding contract tooling without altering consensus.

Repository updated. Documentation included.



https://github.com/elvisjedusor/bitok

https://github.com/elvisjedusor/bitok/releases/tag/0.3.19.11

https://bitokd.run/download

https://bitokd.run/docs