Clarity check for OBTC testnet docs on ESP-Miner-style setups

[obtc-maintainer]

Hi, I maintain OBTC, a separate Bitcoin-derived PoW experiment around expiry, renewal, and rule-bound reclaim.

This is not a firmware change request. I am checking what our public testnet/operator docs should spell out for Bitaxe / ESP-Miner-style Stratum setups: pool URL/user format, ordinary SHA256d mining path, and what logs/errors a reviewer should capture.

Public refs:

• https://www.organicbitcoin.org/docs.html
• https://github.com/organicbitcoin/obtcd/blob/master/docs/testnet-join.md

This is not a request for endorsement, promotion, investment coverage, miner support, pool support, or hashrate, and there is no miner revenue claim.

Is this a reasonable Q&A thread for that kind of documentation-clarity question, or should it be asked somewhere else?

[mutatrum]

I'm not sure what you're asking here, to be honest. Bitaxe can handle Stratum and Stratum V2 connections, they follow the industry. So if you have a pool instance running, it should just work?

[obtc-maintainer]

Thanks, that helps clarify the boundary.

My question is about documentation, not firmware support. I am not asking Bitaxe or ESP-Miner to understand OBTC-specific rules.

The assumption I am trying to document is that an ordinary SHA256d device should receive normal work from a pool or local gateway. The OBTC-specific part is upstream of the device: whether the pool or gateway uses a valid OBTC template, preserves required coinbase commitments, and can submit a solved block to an OBTC node.

I added a mining review checklist to make that scope more explicit:

https://github.com/organicbitcoin/obtcd/blob/master/docs/mining-review-checklist.md

The useful feedback would be whether this describes the device/pool boundary clearly enough, especially around standard Stratum setup, logs, pool URL / worker examples, and what should not be expected from firmware.