Added local work generation via RPC and GridPool integration

[keegreil]

Adds initial GridPool Direct support for local Bitcoin RPC template fetching, ESP32 work generation, GridPool share submission, and direct
submitblock handling for found blocks.

Includes:

• GridPool Direct template builder and work path
• Bitcoin RPC getblocktemplate / submitblock integration
• GridPool reward split and Solo Yolo modes
• fallback behavior to Stratum or pure solo
• dashboard and pool settings UI updates
• OLED RPC display updates
• probe and measurement docs

Still draft; more cleanup and review expected.

[johnny9]

I don't fully understand this grid protocol yet but my intuition says it is vulnerable to cheaters on both sides.

Besides the gridpool stuff, Bitcoin rpc template support would be cool for pool-free solo mining using bitcoin core.

[warioishere]

Just dropping a friendly opinion, not blocking anything.

I see the Bitaxe as a deliberately minimal sovereign hashing device — open firmware, no vendor coupling, the user picks where their hashes go. The SV1 / SV2 layers in the firmware match that — speak a documented protocol, talk to whatever pool you choose.

This PR mixes two things into one. The first one is sovereign local template mining: Bitaxe pulls getblocktemplate from the user's own Bitcoin node, builds the coinbase and merkle path itself, mines, submitblocks back. No third party. That is genuinely useful for solo miners who don't want a Stratum proxy running alongside their node.

The second thing is GridPool Boot HTTP integration — polling a specific external service (gridpool.net, currently a developer preview run by a single operator) for payout lists and share advice, and submitting high-difficulty shares to that service's HTTP API.

The first part is on-mission imo. The second part isn't, really. It ties the firmware to one specific operator's experimental service, with code paths, settings, dashboard widgets and a 391-line OpenAPI extension all named after that vendor. The day GridPool changes its protocol, goes offline, or the dev-preview gets deprecated, that's ~4-5k lines of firmware code that ages out. Every Bitaxe user carries those paths in their flash, including users who'll never have heard of the service. That's maintenance and security surface paid by the whole user base for a vendor-specific feature.

It also kind of sets a precedent — if GridPool's HTTP API gets first-class firmware support, what's the principled answer when the next single-operator pool wants the same. The cleaner architectural place for vendor-specific HTTP layers feels like a small adapter daemon next to the user's Bitcoin node. Same trust model, zero firmware bloat, benefits non-Bitaxe miners too.

One thing to flag if anyone goes the "just extract the solo part" route: even though Solo Yolo doesn't make network calls to GridPool at runtime, all the code paths (file names, function namespace, NVS keys, REST API fields) are GridPool-branded. Splitting it out would require a refactor — renaming gridpool_direct_builder.c to something like local_template_builder.c, separating gridpool_status_client.c into a generic Bitcoin RPC client plus a GridPool-specific HTTP client, and renaming the NVS / REST namespaces. Probably worth it though — the local-template-from-own-node use case stands on its own and shouldn't be branded after a specific third-party service. The GridPool HTTP submission piece could then live as a follow-up to evaluate separately, or in a fork if it doesn't fit upstream.

Anyway, just my 2 sats.

[keegreil]

I don't fully understand this grid protocol yet but my intuition says it is vulnerable to cheaters on both sides.

Besides the gridpool stuff, Bitcoin rpc template support would be cool for pool-free solo mining using bitcoin core.

Thanks! For Gridpool, I really need to write a more succint description. You could start here if you are interested:
https://github.com/gridlabs-science/boot-protocol/tree/main

If you figure out a way to cheat please let me know!

[keegreil]

@warioishere Thanks for reviewing and for your thorough feedback! I think I agree with everything you said. This is just a few more explanations to fine tune the discussion:

First: this PR does mix two things, and in hindsight I agree they should be separated for all the reasons you mentioned and more. So I think I'll rip the Gridpool stuff out and resubmit at some point, including making sure the Gridpool branding isn't in the local work generation path, that's good feedback.

Local Work Generation:
I'm glad you think it's genuinely useful and on-mission. Before Stratum, all mining was done this way. The Stratum layer was only added to deal with scaling issues for industrial mining. For small setups like Bitaxe, Stratum isn't really needed. There's a couple of things we should make super clear to users, and this may impact whether/how it gets added to main

1. Doing work generation on the ESP32 is slow. About 7.4s delay by my measurements whenever it gets a full new template. That may impact how quickly the Bitaxe can update to new templates after the chain-tip advances. For solo lottery mining that may be acceptable, if the user prefers a minimalist setup. We may also be able to get some performance increases by fetching just the new header, and hash an empty block for 7s until the transactions can get streamed in again. Getting that data across the ESP32's wifi connection is the slow part. A sidecar stratum server running on the node with a real CPU will always be more performant.
2. There is some risk that the work it builds isn't always consensus valid, simply due to bugs/immaturity. Other mature Stratum servers like DATUM, CKPool, and Public pool all have dozens or hundreds of real blocks on the chain, so are more trustworthy. With this code, we wouldn't be really sure until someone actually gets a real block.
   If this gets included, it probably should not be the default, and should have some kind of "Experimental" note or warning attached.

Gridpool integration:
First to correct some things. Gridpool aims to be a simpler version of P2Pool that fixes some of the engineering defects of the first one. Right now, yes Gridpool is "single vendor, single operator", only because it hasn't launched yet, and I'm the only one working on it. The goal of the project is to be an open source decentralized reward sharing protocol, where any user can run their own node on the Gridpool network. Users could point their Bitaxe to their own Gridpool node. The only centralized part would be hard coded seed nodes to bootstrap new nodes onto the network, the same as Bitcoin uses. Whenever I can find more people than me to run those then these will have many options as well. The HTTP API was designed to make it trivial for any other pool software to interact with this reward sharing protocol (DATUM works now, Hydrapool is tested on a custom fork, CKPool and Public Pool are on the wishlist). The HTTP API is also how the individual Gridpool nodes talk to each other.
So, could this be run as an adapter daemon on the node? Definitely, that already exists and is working, it's called DATUM.
The principled answer for why Gridpool deserves special integration would be that Gridpool is an open source, decentralized reward sharing network. P2Pool would deserve the same treatment, if integrating that were technically possible (I'm not sure it is). Braidpool is nowhere close to finished yet. I don't know of any other such protocol in existance yet.

Certainly if we ever want to integrate Gridpool, it makes sense to wait until it's actually launched, and perhaps only included as an experimental feature until it's more mature.

[In the image below, this PR is related to the two dashed lines]

[keegreil]

I've separated out the two components of this PR, and submitted the first (local work generation only) in this separate PR:
PR #1719

Closing this PR as it's no longer recommended or needed.