Skip to content

mining: Add HTTP notify support for DATUM Gateway#307

Open
pdath wants to merge 1 commit into
bitcoinknots:29.x-knotsfrom
pdath:blocknotify-http
Open

mining: Add HTTP notify support for DATUM Gateway#307
pdath wants to merge 1 commit into
bitcoinknots:29.x-knotsfrom
pdath:blocknotify-http

Conversation

@pdath

@pdath pdath commented Jun 2, 2026

Copy link
Copy Markdown

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. :-)

Comment thread src/init.cpp Outdated
Comment thread src/init.cpp
Comment thread src/init.cpp
@pdath pdath force-pushed the blocknotify-http branch 6 times, most recently from cbb5a51 to 265e8d6 Compare June 4, 2026 02:40
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.  :-)
@pdath pdath force-pushed the blocknotify-http branch from 265e8d6 to dab4401 Compare June 4, 2026 03:04
@pdath pdath requested a review from luke-jr June 10, 2026 01:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants