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.mdNot 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 (:
