I published my latest video tutorial HERE.
In this video I introduce a couple services I built for StartOS and Umbrel to simplify testing BLAKE2b ASICs via regtest, and for easily capturing and reporting diagnostics for models which fail to connect.
6 Likes
Does installing Knots and Datum Gateway Blake2b version mess with the other Knots (RDTS) & Datum Gateway that’s on the stalled chain that’s connected to the main-net or can I run both without any issues? Does the Knots (RDTS) let you send / view the btc you get from the testnet4 ?
thanks for the video Paul. What would be the steps for those of us not using start9 or umbrel but running node on linux machine and want to mine with asics? thanks
@Mikeperry the apps are completely separate, and regtest coins do not transfer to mainnet.
@Vango77 It can be done with Docker. I’ll put together the steps when I get some time.
1 Like
Goodmorning Paul, ok thank you. I was wondering if the regtest coins would be able to be sent to other users that are testing as well & if the wallet balance can be viewed , Just how users that are using an rc2 testnet4 node are doing.
Regtest works a bit different than testnet. It creates a private chain that lives entirely on your own server, and has no way to find anyone else’s node (and nobody else’s node can find yours). Every person who installs it gets their own separate chain that starts from the same empty state.
I’ll add a way to see the balance to the next release though, so you’ll be able to confirm whether or not coins are being mined.
4 Likes
This should work for running on Linux (assumes you have installed Docker and your user is in the docker group):
Create a folder, retrieve the compose file and startup script, mark it as as executable:
mkdir ~/blake2b-mining && cd ~/blake2b-mining
curl -fsSLO https://raw.githubusercontent.com/paulscode/datum-blake2b-startos/main/docker/docker-compose.yml
curl -fsSLO https://raw.githubusercontent.com/paulscode/datum-blake2b-startos/main/docker/start.sh
chmod +x start.sh
Then any time you want to start the test services:
cd ~/blake2b-mining
./start.sh
To stop the test services, but keep the test chain:
cd ~/blake2b-mining
docker compose down
Or to stop them and delete the chain:
cd ~/blake2b-mining
docker compose down -v
2 Likes
Great thanks Paul, I’m expecting SC5 pro 2 any day now.
1 Like
Sounds good. Thank you. I was wondering if we had a small lighting channel open with you , what will happen to it if I decide to install the final client of knots (Blake2b) when it’s released?
Lightning isn’t compatible between the two chains (due to the gossip data that starts to accumulate transactions that are invalid on the new chain). Adding support for Lightning to the new chain is one of Chris Guida’s top priorities, though, so I would expect to see a second lightning network start to form on the new chain fairly quickly. Ironically, he’ll have a big challenge dealing with Luke’s decision not to add replay protection, since channel open transactions do not violate RDTS rules, and thus will replay on both chains. It may require adding replay protection into the Lightning protocol itself to separate the gossip between the two chains (which would require a new BOLT to be adopted)
1 Like
So far so good. The SC and HS Box’s are running okay in the testing enviroment.
Question: Once the new BLAKE2b PoW chain goes live on September 1st, where is the best place to find the official information about the correct mainnet client/node and wallet for this chain? I want to safely create a new wallet before starting solo mining, verify the public receiving address, and then configure that address correctly in DATUM for block rewards.
Is there an official GitHub repository, website, release page, or other channel that I should follow from launch day onward? And will there be an official announcement when the wallet/client is ready for mainnet use?
I would watch the Bitcoin Knots repository, which is where all of the work is being done (and where the actual release will happen). https://github.com/bitcoinknots/bitcoin
As far as wallet compatibility, this is something I am exploring now. It turns out that a protocol needs to be agreed to for indexers. I’ve started discussions on this with my own proposal HERE for how I think it should work if nobody else has a better suggestion (with the understanding that I am not as plugged into this as a lot of other devs, so I may be totally behind). One interesting fact is that these are changes to a version that only Fulcrum currently supports, so I would guess that it will be the indexer to reach for (though it too will require an update).
My interest in this topic stems from a project I am working on to create a version of electrs which supports pruned nodes (since a lot of folks that would like to follow both chains can’t afford to beef up their RAM and storage, or buy two servers). I’ve already written a version of electrs that follows my proposed protocol (and of course I’ll update it if a different protocol besides mine becomes the official one).
The main wrinkle is that Sparrow wallet (and presumably many other wallets) does not support the new chain for a couple of reasons. The obvious one is that it verifies rather than trusts what it gets from the indexer, by checking the POW hash itself (and that check assumes SHA256). I’ll be releasing a fork of Sparrow Wallet that supports the new chain (using my proposed protocol, until an official one is decided on).
I should have the full stack up on the next couple of days (on testnet4). So even if some of the players are slow to update, at least folks will have a temporary solution once the hard fork goes live. Once official decisions have been made, then I’ll put in PRs for electrs and Sparrow. Whether they will be accepted is another question (I don’t know how these projects view the hard fork). They are both open-source though, so if anything related to the hard fork is rejected, then supporters can always maintain an alternate implementation for them (and I am happy to host the repos if nobody else does – I just won’t be putting the majority of my time into maintaining them myself, so would expect contributors to help chip in).
4 Likes
Okay will see how things evolve. For now do you think it is a good idea to use fulcrum instead of electrs to be well prepared for as far as pow blake2b goes. My point is that we can connect a wallet address to our miners asap as 1 sept things get running.
That sounds great Paul!
For me at this point it is still a bit above my head. But we are stand by so far. Our Goldshell blake2bsc hardware has a total potential of 5th for less then 1500W (€12,50 daily). For now we are ready and stand by for the new release. Feels like a gold miner is the 19th century 
I was wondering if I can have my SC Box mine to my normal Bitcoin wallet address type. That shouldn’t be an issue as long as my node is set up for the RDTS Knots hard fork?
Mainnet addresses will be supported after the hardfork activates. Until then, you can only mine to a regtest or testnet4 address, depending on which network you connect Knots blake2b to.
1 Like
Thank you for the clarification.
Just to clarify, can I use MRR on Sept.1st to mine on the hardfork through Ocean?
If so, can I also use the set you previously described on my Start9 3.5 with
- Bitcoin Knots
- Mempool BIP-110
- Agent Wallet
- Hash GG
- Pickhash
- Datum
- Ocean
Thank you
I wouldn’t think so.