One Start9 with two Datum Gateways

Following on from Fletchers helpful post for setting up two instances of Datum on Start9 OS.

I followed the instuctions by downloading then side loading the datumtwo.s9pk package, then altered the Block Notify field in Knots with ```
curl -s -m5 http://datum.embassy:7152/NOTIFY http://datumtwo.embassy:17152/NOTIFY

as per the instructions, then followed the ssh commands for the simple proxy.

All very straight forward - BUT - it wouldn't work and the orginal Datum (ie Datum number one, not the second instance) gave the following error:
Bitcoind Blocknotify Setting
Error: The blocknotify field is not set correctly. Please delete it and auto-configure Knots from Datum Gateway then restart Datum Gateway.

From an earlier thread I read that Paul ran into the same snag and said the only solution seemed to be unistalling Datum then re-installing and the error went away. I tried that but to no avail, the error is still there.

Anyone got any ideas?

Depending on how they modified their “datumtwo” service, they might have left the original code in that checks for a specific value in the blocknotify settings during installation. I would try running the below processes to check if that is the problem:

  1. Stop Datum (the official one)
  2. Uninstall “datumtwo”
  3. Stop Knots
  4. Update the blocknotify field for Knots so that it contains just this:
curl -s -m5 http://datum.embassy:7152/NOTIFY
  1. Start Knots
  2. Reinstall “datumtwo” and start it. If problem is resolved, proceed to step 7:
  3. Stop “datumtwo”
  4. Stop Knots
  5. Update the blocknotify field for Knots back to:
curl -s -m5 http://datum.embassy:7152/NOTIFY http://datumtwo.embassy:17152/NOTIFY
  1. Start Knots
  2. Start Datum and “datumtwo”
1 Like

I’ve now Stopped the 2nd Datum. The first and original Datum is running with the error, but is accepting the little NerdAxe miner and shows shares in the Clients tab, and AxeOS is showing shares etc, everything normal. So…I suspect some part of Block Notify field in Knots is incorrect.
If I connect my Nano 3s to the 2nd Datum with the parameters given in the Instructions bit of Datum 2, the Avalon page shows it won’t connect to the (Ocean) mining pool.

Thanks Paul! I’ll try it

Sorry Paul, no joy. Followed all your steps but the same error and Nano 3s not connecting to Ocean in solo/lottery mode.

I think I’ll scrap the idea of having “datumtwo” and just have both miners connecting as solo miners to Ocean. Once I’ve sorted out the LND and CLN channels I’ll set Datum to Pooled mining. V busy over the next few days so won’t have time to tinker.

Thanks very much for your time and taking the trouble to help, much appreciated.

Ok, cool. The other option is to install Public Pool (on the community registry) for solo mining, and use Datum Gateway for pool mining.

1 Like

Just to clarify (if its even possible…), what Ocean calls “solo mining” is actually just pool mining, except you write your own block templates via the datum protocol. You still share the rewards with everyone in the pool. What people usually call “solo mining” (and if you configure your Datum Gateway to solo mine or if you self-host the Public Pool service on your server) is self-contained on your own local network and does not connect to Ocean at all (i.e. you do not “solo mine to Ocean” as you stated it, unless you are adopting the new definition of “solo”).

I know, confusing as heck. I hate that Ocean has tried to re-define this term that has a well established meaning. I think we should probably drop the term “solo” when we are having a conversation where Ocean is part of the topic, and instead refer to “loto mining” and “pool mining” to be clear on what we mean. If necessary, we can use either “stratum pool mining” or “datum pool mining” if the need to distinguish whether the pool writes the block templates or you write them yourself.

Likewise, we could distinguish “3rd-party lotto mining pool” from “self hosted lotto mining pool” to make the same distinction about who writes the block templates. But that then brings up another potential point of confusion – the term “lotto mining pool” itself doesn’t really make sense, since there is no pooling going on :crazy_face:

2 Likes

And after your clarification to me a few weeks or so ago that is exactly what I did. So confusing until you think about it…

have both miners connecting as solo miners to Ocean

I was going to respond to your comment about this @FouBaar but I knew Paul would answer so I kept quite.

1 Like

Thinking about this some more, I think some good terms to use will be:

Pool Mining

  • Stratum Pool Mining
  • Datum Pool Mining

Lotto Mining

  • 3rd-Party Lotto Mining
  • Self-Hosted Lotto Mining

This gives us two easily-distinguishable categories (pool mining vs lotto mining), which can be broken down to be more specific if the need ever arises. And we can add the word “service” to the end of any of these to describe the interface that you connect your ASICs to. I’ll start using these terms myself when I post in the future.

With the above in mind:

Datum Gateway

  • Can be used as a Datum Pool Mining service (interacts with the OCEAN pool)
  • Can be used as a Self-Hosted Lotto Mining service (does not interact with OCEAN pool)

Public Pool

  • Can be used as a 3rd-Party Lotto Mining service (via public-pool.io)
  • Can be installed on Start9 as a Self-hosted Lotto Mining service (does not interact with public-pool.io)
2 Likes