DATUM Gateway v0.5.0beta

Don't use the "Source code" downloads below, use git to fetch from GitHub:

git clone https://github.com/CONVOYMining/datum_gateway.git

For Ubuntu, there is also a PPA: ppa:CONVOYMining/datum-gateway (or ppa:CONVOYMining/datum-gateway-0.5 if you don't want to upgrade to 0.6+ later)

For StartOS, we have a sideloadable package here.

There are DATUM support and development channels in the Bitcoin mining Discord community.

What's Changed

• DATUM Gateway is now maintained under the stewardship of @CONVOYMining (which is now the default pool) by @luke-jr
• Updated for Bitcoin's BLAKE2b proof-of-work change by @innerhat-dev
• Protections against block withholding attacks (including accidental block-loss bugs) on compatible pools by @luke-jr
• Added macOS support by @5w4kjd95yk-eng
• Hasher time rolling is now disabled by default due to bugs in some firmware by @innerhat-dev (it can be enabled with mining.allow_hasher_time_rolling if you know your hardware is compatible)
• Local and pool share acceptance/rejection statistics are now tracked and displayed separately by @innerhat-dev
• Briefly interrupted pool connections can now be resumed without losing work (on compatible pools) by @luke-jr
• Pools can request connection migration to other servers by @luke-jr (for security, the datum.migration_max_seconds option can be set to a time limit, 1 day by default, or zero to disable)
• Pool-rejected shares are now logged at ERROR level (except for ordinary stale shares) by @luke-jr
• Authentication is now required to view configuration in the web interface by @luke-jr
• Fixed a compatibility issue with Bitcoin nodes using libevent 2.1.13 by @Retropex
• Fixed extra_block_submissions.urls (broken since v0.2.3) by @luke-jr
• Block submission failures are now reported correctly by @luke-jr
• Many other reliability, validation, and protocol-hardening fixes

New Contributors

• @MattDHill made his first contribution in 79632cc
• @innerhat-dev made their first contribution in c61c2e7
• @jasonsopko made their first contribution in 4d03f5a
• @paulscode made their first contribution in 57f1aee
• @5w4kjd95yk-eng made his first contribution in 2e9dcb4
• @alphaminetech made their first contribution in #21
• @iohzrd made their first contribution in #24
• @Maveth made their first contribution in #35

Full Changelog: https://github.com/CONVOYMining/datum_gateway/commits/v0.5.0beta

DATUM Gateway

Decentralized Alternative Templates for Universal Mining
(c) 2024-2026 Bitcoin Ocean, LLC, Jason Hughes, and individual contributors

The DATUM Gateway implements lightweight efficient client side decentralized block template creation for true solo mining.

It reaches out to a local Bitcoin node for block templates, generates and distributes work for mining hardware, and submits solved blocks to the network directly.

For miners wanting to pool rewards, it facilitates communication with a DATUM-supporting pool in addition to the above. The pool is responsible for coordinating the block reward split based on work done for the pool by the miner, but does not create work for the miner.

The work provided by the gateway to mining hardware is generated only from the local node generating templates for the miner. The real miner is always whoever is running the Bitcoin node. With DATUM, that's not the pool. As the protocol is intended solely for mining of decentralized block templates, the DATUM protocol has no mechanisms for the pool providing the information needed to construct work or a block template.

Currently the DATUM Gateway supports communication with mining hardware using the Stratum v1 protocol. BLAKE2b and BLAKE2b-Sia miners are supported. Communication with the Bitcoin node is via RPC and must support GBT ("getblocktemplate"). Finally, communication with the pool is via the DATUM protocol.

The DATUM Gateway only supports mining Bitcoin. Modifying the code to support non-Bitcoin is not straightforward, as many optimizations and design considerations are tightly tied to Bitcoin-specific restraints for efficiency.

DATUM Protocol

The DATUM Gateway's communication with the mining pool is via the DATUM Protocol. This is an encrypted communication link between the DATUM Gateway (client) and the DATUM server (pool side).

The protocol itself was made from the ground up as a custom protocol. Its specification is evolving, subject to change, and will be published elsewhere.

The core concepts of the protocol:

• Encrypt communications between the Gateway and pool
• Obfuscate the communications somewhat so a MITM is unable to glean useful or accurate insight into the miner's operation via analysis of the still-ciphered communications.
• Retrieve proper generation transaction payout splits from the pool for locally constructed templates
• Submit work to the pool with sufficient data to efficiently validate and accept the work for proper rewards
• Communicate minimal guardrails and requirements for a valid template to earn pooled rewards

With the current version of the protocol, the pool does block validation after coordinating with the miner. This is strictly to ensure miners are not accidentally creating invalid blocks while DATUM is still undergoing testing. In a future version of the protocol, the pool will not be in charge of this function and will be almost completely blinded to the contents of the miner's block template.

The protocol is not specific to a pooled reward system, as the Gateway coordinates the appropriate generation transaction with the pool. However, in the spirit of maximum decentralization, the pool should implement rewarding miners directly from generated payouts, such as with CONVOY's TIDES reward system.

Requirements

• 64-bit AMD, Intel, or Apple silicon system. Other systems may work, but at this time it is at your own risk.
• Linux, macOS, or FreeBSD operating system.
• Bitcoin full node (Bitcoin Knots recommended) fully synced with the Bitcoin network.
• Fast storage recommended for the Bitcoin node.
• Stable internet connection for both the Bitcoin node and Gateway's communication with the pool.
• CPU powerful enough to run the Bitcoin node without validation delays.
• Approximately 1GB/RAM, plus 1GB/RAM per 1000 Stratum clients, plus Bitcoin node RAM requirements.
• Bitcoin mining hardware able to reach the system running the DATUM Gateway.

This list is not extensive, but the main goal is the have a stable system for your Bitcoin node and the Gateway such that your node is processing new incoming blocks and getting templates to the Gateway as quickly as possible. While this may all work on relatively low end hardware, your mileage may vary.

No modifications to the Bitcoin node source code is required for the Gateway, as it uses the standard GBT mechanism for template fetch.

The following external libraries are required:

• libcurl
• libjansson
• libmicrohttpd
• libsodium

Node Configuration

Your Bitcoin node must be configured to construct blocks as you desire. Bitcoin Knots provides many options for configuring your node's policy and is highly recommended.

At this time, you must also reserve some block space for the pool's generation transaction. The following options are currently recommended:

blockmaxweight=785000

Note: This reservation requirement will be removed for Bitcoin Knots users in a future version of the DATUM Gateway thanks to support for on-the-fly specification of these metrics by the client in Knots.

To avoid mining stale work, you will need to ensure the DATUM Gateway receives new block notifications from your node. It is suggested you run the DATUM Gateway as the same user as your full node and utilize the following configuration line in your bitcoin.conf:

blocknotify=killall -USR1 datum_gateway

Ensure you have "killall" installed on your system (psmisc package on many OSs).

If the node and Gateway are on different systems, you may need to utilize the "NOTIFY" endpoint on the Gateway's dashboard/API instead.

Finally, the Gateway must have RPC access to your node, and you must add an RPC user to your configuration to facilitate this, as well as ensuring the service running the Gateway is whitelisted for RPC access (if not on the same machine).

Some additional recommendations:

maxmempool=1000

As a true miner, you'll most likely want as many valid transactions as possible in your mempool which meet your node's policies.

Installation

Install and fully sync your Bitcoin full node. Instructions for this are beyond the scope of this document.

Configure your node to create block templates as you desire. Be sure to reserve some space for the generation transaction, otherwise your work will not be able to fit a reward split. See node configuration recommendations above.

Install the required libraries and development packages for dependencies: cmake, pkgconf, libcurl, jansson, libsodium, and libmicrohttpd. You may also need psmisc for your node to send blocknotify signals to the DATUM Gateway.

For Debian/Ubuntu:

sudo apt install cmake pkgconf libcurl4-openssl-dev libjansson-dev libsodi...