DATUM Gateway (BLAKE2b) 1.0.0:52: Fix to continue supporting the full payout window and reducing make-good payments

Bitcoin
1

Paul, thanks for your work on the Start9 packages. I’m mining on Lazarus using your DATUM Gateway (BLAKE2b) Companion and would appreciate clarification about coinbase payouts and whether there is a need for a tweak to this Datum Companion to continue supporting the full payout window and reducing make-good payments.

My setup:

  • StartOS 0.4.0

  • DATUM Companion package 1.0.0:52

  • Gateway reports CONVOY 0.4.1-beta, build e998e38

  • Goldshell SC5 Pro II

Lazarus’s documentation says some CONVOY builds limit the coinbase to approximately 17 miner payouts, with omitted payments becoming “make-goods” paid separately by the pool. They recommend iohzrd to include the full payout window.

My question: Does your current package include the full-payout fix, or is my build still subject to that limitation? If it is affected, what’s the recommended way to use iohzrd or an equivalent fix on Start9 while keeping my existing Knots Companion setup?

I understand other miners’ gateways can still cause omitted payouts. I want to ensure that if my miner finds a block, my own gateway includes the full eligible payout list. With the extended coinbase maturity period, I’d like to minimize dependence on later make-good payments.

I also thought your Datum gateway was using an iohzrd-based gateway before the recent update introducing the 45-day maturity period, but I may be mistaken. The gateway now reports CONVOY, and I don’t see an option to select iohzrd. Did the underlying gateway change, or am I misunderstanding the labeling?

I know you have a lot on your plate, and I appreciate your help. My concern is that the longer wait for make-good payments increases reliance on the pool and could discourage miners from staying on Lazarus, although I don’t know whether that explains any recent hashrate changes.

On the Lazarus discord i found this:

image
image972×785 74 KB

Thank you!

J(newbie) K

2

I’ve been focused on getting Lightning Fork aligned and published, so haven’t been keeping up on the Datum Gateway changes. I’ll take a look this week to pull in anything new from upstream.

2 Likes
3

Hi everyone, I’m trying to better understand what “Make-Good” payments actually imply for miners on Lazarus .

Normally, mining rewards are paid directly to our own address through the block’s coinbase transaction. However, when a gateway cannot include all eligible miners, some payouts are dropped from the coinbase and appear as Make-Good instead.

In our case, the dashboard currently shows 0.2099 XBT in Make-Goods across 27 blocks .

As I understand it, this money is not necessarily lost. Instead, Lazarus records it as an amount the pool owes us and should compensate later. But that seems to change the nature of the payout: instead of already having an on-chain coinbase output to our address and simply waiting for maturity, we are relying on Lazarus to make that payment later.

Is this understanding correct? And what are the practical implications for miners?

In particular, what happens if Make-Good balances continue to accumulate faster than they are paid out? How and when are these Make-Goods settled, and is there any additional counterparty risk compared with receiving the reward directly through the coinbase?

I’d appreciate clarification from anyone who understands the payout mechanism in detail.

4

Update pushed.

Background: TIDES is meant to pay everyone in the pool’s window as outputs of each block found. When a block can’t carry someone’s payout, Lazarus records the amount and pays it in a later block. That later payment is the make-good. Until it is paid, it is a balance the pool owes you, so yes, it carries counterparty risk that a payout inside the block does not. Once paid, it is an ordinary output and matures like any other mined coins: 6,481 confirmations under the current rule.

The reason blocks were leaving people out is because of the gateway that found the block. Several gateway builds limit how many payouts fit in a block, and mine was one of them. Every version of Datum Gateway (BLAKE2b) Companion up to and including 1.0.0:52 put at most about 17 payouts in each block it found, against a window of around 440 miners. The gateway gave each miner a coinbase size limit based on its firmware, and used a 750-byte limit for any hardware it didn’t recognise. The limit only matters for SHA256 hardware, which rebuilds the coinbase itself. BLAKE2b miners never see the coinbase, so on this chain it only cut payouts. Lazarus’s gateway list shows other builds with similar limits, so make-goods have been coming from blocks found by several of them, ours among them.

The fix. Update to Datum Gateway (BLAKE2b) Companion 1.0.0:53 on StartOS, or 1.2.1 on Umbrel. On plain Docker, the image is paulscode/datum-blake2b:1.0.17. The new gateway is built from CONVOY’s current gateway plus the same coinbase commits from iohzrd that Lazarus recommends (through c031568), plus our own changes. On top of that is a patch from Lazarus that stops the gateway handing out work that pays only the pool, which used to happen for a moment after each new block. A block now holds up to 1024 payouts, sized to the room left in the block. At the node’s default settings that is room for about 900, more than twice Lazarus’s current window. Lazarus will list the gateway as v0.4.1-beta/79595ce.

The iohzrd-based DATUM package on StartOS (pow 0.4.1:23, the one Lazarus mentions) is Retropex’s. It is still on iohzrd’s older 7491a50, and it pairs with Retropex’s Knots package, not with Bitcoin Knots (BLAKE2b) Companion.

Did my gateway change underneath you? No, it was never iohzrd-based. It was my own fork of OCEAN’s gateway until 1.0.0:43. It moved to CONVOY’s fork in 1.0.0:47 on 12 September, because CONVOY’s and Lazarus’s pools only accept CONVOY’s handshake. The 45-day maturity releases (1.0.0:51 and 1.0.0:52) did not touch the gateway. If you remember an iohzrd build on StartOS, it was most likely Retropex’s package.

Two settings that help:

Keep your node’s Max Block Weight at its default. A block full of transactions leaves less room for payouts, and some would be left to the pool again. At a pool, set each miner’s username to youraddress.workername. The part before the first dot is the address the pool pays. If you mine with the plain-Docker setup: download docker-compose.yml again and run docker compose pull, then docker compose up -d. The old file pinned a node image without the long coinbase maturity rule, so blocks built on it are rejected by the network. Your wallet is kept.

Make-goods you are already owed are not affected by this update; they are Lazarus’s to settle. New ones will keep appearing while gateways with payout limits find blocks, though less often as people update. For how and when Lazarus pays them, in what order, and what happens if they pile up faster than they are paid, you’ll need to ask Lazarus directly. Their public API currently shows about 160.6 XBT owed to miners in total. That figure includes balances still below the payout minimum, not only make-goods.

2 Likes
5

Hi Paul!

Wanted to let you know that i updated this morning and can confirm it appears to be working perfectly with my miner on Lazarus.
Gateway showing:

Generating coinbases for up to 118 outputs (out put window included rather than 17 output limit.

Lazarus connected and ready.

local and pool shares accepted without rejects with strong hashrate.

This update appears to have fixed exactly what i was asking about with the make-good payments.

One thing i did notice is that the UI shows the pool tag as “Lazarus/solo”, even though it is clearly operating in pooled mode as pool shares are being accepted.

Is this tag just the tag Lazarus is sending or is this something worth looking at?

Thank you for getting this update out so quickly!

image

6

Just now, i went back and looked and it now shows pool tag as just “Lazarus”. Maybe i did not run it long enough, but all good!

7

Paul,

On the Knots discord I posted your update is available. But the real trick would be StartOS updating its datum gateway for blake2b so the masses also run the tweak for the outputs. Thanks.

8

Hi Paul,

Could you clarify what you recommend for our current StartOS setup?

We are currently running:

  • Knots: #knots:29.4.2:3
  • DATUM: #pow:0.4.1:24

After reading your latest update about the payout limits and the new Datum Gateway (BLAKE2b) Companion 1.0.0:53 , we’re not completely sure what the correct upgrade path is for our setup.

Can we simply replace our current DATUM #pow:0.4.1:24 service with Datum Gateway (BLAKE2b) Companion , while continuing to use our existing Knots service?

Or does the Companion gateway require us to also switch to Bitcoin Knots (BLAKE2b) Companion ?

We’d like to make sure we use the correct combination and don’t accidentally break compatibility or mining.

Thanks!

1 Like
9

What you have is probably closer to an “official” setup, so I wouldn’t recommend switching just for the sake of switching. If you have a problem with your version of Datum, it is probably worth reaching out upstream to address it. Switching to the Companion stack would require repeating the IBD, and you’d be moving from a full node to a pruned one (which introduces latency in some scenarios)

1 Like
10

Yes that make sense. We keep this setup running.
For besides we have the pruned for the SHA256 chain.

11

Is this effected by what Datum the others in the pool are using or what Datum the one that finds the block in the pool is using?

12

It is the Datum version of the user who finds the block. So the odds of it happening are roughly determined by the percentage of users on the pool who have the right version.

2 Likes