mining: Add HTTP notify support for DATUM Gateway#307
Open
pdath wants to merge 2 commits into
Open
Conversation
luke-jr
requested changes
Jun 4, 2026
pdath
force-pushed
the
blocknotify-http
branch
6 times, most recently
from
June 4, 2026 02:40
cbb5a51 to
265e8d6
Compare
When using the DATUM gateway you can use the blocknotify command in Bitcoin Knots. An example is: blocknotify=wget -q -O /dev/null http://localhost:7152/NOTIFY This works by shelling out and running wget. I have been profiling the performance of this, and on my slow hardware (Odroid M2 16GB), this takes about 75ms. I expect a lot of home miners running DATUM Gateway will also have low-spec hardware. This is a problem because from the moment that Bitcoin Knots has accepted a new block, any energy spent by a hasher is wasted until DATUM Gateway can get the notification of the new block, issue a getblocktemplate() RPC-JSON call to Bitcoin Knots, get the result, and send a new work unit to the hasher to start working on a new job. Another issue is that the longer it takes for a hasher to get the new block template the more it reduces their chance of solving that block template, simply because of the reduced hashing time working on it. To resolve the latency issue of shelling out I proposed to add a native http notifier in this discussion: bitcoinknots#305 I took onboard the feedback and have changed NotifyBlockTip to check the blocknotify configuration option to see if it starts with http:// and if it does, use the new code in http_notify.cpp (and http_notify.h) to make a single-shot attempt to retrieve the URL, otherwise it runs the existing code which shells out to run the command. Just like normal blocknotify it is run in a thread so is non-blocking. A sample notify command for DATUM Gateway is: blocknotify=http://localhost:7152/NOTIFY When I timed the native http notification I found it was generated in the same microsecond (note, microsecond) that Bitcoin Knots detected the new block tip (compared to 75ms when using the shell method). I have created a unit test httpnotify_test.cpp. I have kept the changes to init.cpp minimal to help reviewers see the structure of the change easier. I have tried to make the changes to the central Bitcoin Knots code minimal. I normally work in C, and have used AI to convert the concepts I wanted to implement into C++. I have access to an Ubuntu build environment and have tested it there. I have not been able to test this on MacOS or Windows. This is my first contribution to Bitcoin Knots. Take it easy on me. :-)
Ari4ka
approved these changes
Jun 21, 2026
kwsantiago
reviewed
Jul 3, 2026
kwsantiago
left a comment
kwsantiago
left a comment
There was a problem hiding this comment.
Two robustness blockers in the socket path, plus a gating inconsistency. The URL parser itself is solid (bounds-checked, no OOB). Details inline.
This addresses four issues in the HTTP block-notification feature: - Fix unbounded connect() on Linux by using non-blocking connect with nConnectTimeout (via Sock::SetNonBlocking, Sock::Wait) - Try all addrinfo entries in order instead of only the first, allowing fallback from IPv6 to IPv4 when the first address family is unavailable - Clarify -blocknotify help text to indicate http:// support is independent of shell command availability on HAVE_SYSTEM builds, and is the only supported form on builds without system() - Add Doxygen documentation for all public functions in httpnotify.h and socket-level tests (loopback listener, connection refused) to httpnotify_tests.cpp Additionally: - Clean up implementation comments to be more descriptive - Generated man page updated to reflect help text changes
Ari4ka
approved these changes
Jul 19, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When using the DATUM gateway you can use the blocknotify command in Bitcoin Knots. An example is:
blocknotify=wget -q -O /dev/null http://localhost:7152/NOTIFY
This works by shelling out and running wget. I have been profiling the performance of this, and on my slow hardware (Odroid M2 16GB), this takes about 75ms. I expect a lot of home miners running DATUM Gateway will also have low-spec hardware.
This is a problem because from the moment that Bitcoin Knots has accepted a new block, any energy spent by a hasher is wasted until DATUM Gateway can get the notification of the new block, issue a getblocktemplate() RPC-JSON call to Bitcoin Knots, get the result, and send a new work unit to the hasher to start working on a new job.
Another issue is that the longer it takes for a hasher to get the new block template the more it reduces their chance of solving that block template, simply because of the reduced hashing time working on it.
To resolve the latency issue of shelling out I proposed to add a native http notifier in this discussion:
#305
I took onboard the feedback and have changed NotifyBlockTip to check the blocknotify configuration option to see if it starts with http:// and if it does, use the new code in http_notify.cpp (and http_notify.h) to make a single-shot attempt to retrieve the URL, otherwise it runs the existing code which shells out to run the command. Just like normal blocknotify it is run in a thread so is non-blocking.
A sample notify command for DATUM Gateway is:
blocknotify=http://localhost:7152/NOTIFY
When I timed the native http notification I found it was generated in the same microsecond (note, microsecond) that Bitcoin Knots detected the new block tip (compared to 75ms when using the shell method).
I have created a unit test httpnotify_test.cpp.
I have kept the changes to init.cpp minimal to help reviewers see the structure of the change easier. I have tried to make the changes to the central Bitcoin Knots code minimal.
I normally work in C, and have used AI to convert the concepts I wanted to implement into C++. I have access to an Ubuntu build environment and have tested it there. I have not been able to test this on MacOS or Windows.
This is my first contribution to Bitcoin Knots. Take it easy on me. :-)