Documenting SV1/SV2 translator assumptions for a Bitcoin-derived testnet

[obtc-maintainer]

Hi, I maintain OBTC, a separate Bitcoin-derived PoW experiment. This is not a Bitcoin consensus proposal or a Stratum V2 protocol change request.

I am trying to document what matters for SV1/SV2 translator-style setups when the chain is Bitcoin-derived, uses ordinary SHA256d PoW, and has an extra coinbase commitment after activation.

Which assumptions should the docs state explicitly: template source, coinbase construction/mutation limits, job declaration expectations, or solved-block submission path?

Public refs:

• https://www.organicbitcoin.org/docs.html
• https://github.com/organicbitcoin/obtcd

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

[GitGab19]

I would suggest you to start from the protocol specification, which is the very first point to understand the protocol: https://github.com/stratum-mining/sv2-spec

[obtc-maintainer]

Thanks for the pointer. I went back to the Stratum V2 spec and added a short OBTC mapping section to the mining review checklist:

https://github.com/organicbitcoin/obtcd/blob/master/docs/mining-review-checklist.md#9-stratum-v2-mapping

This is not a Stratum V2 protocol change proposal or a request for OBTC support. It is just a documentation mapping for reviewers.

The mapping says, in short:

• OBTC still uses the ordinary SHA256d header search model;
• the upstream template source needs to be an OBTC node on the right network and activation state;
• coinbase prefix/suffix or output mutation must preserve OBTC-required expiry/REAP commitments and accounting;
• a solved block still has to reconstruct to a full valid OBTC block before submitblock or equivalent propagation;
• share acceptance remains pool-local accounting, not protocol validation.

The main thing I would like checked is whether that mapping misreads any Stratum V2 or translator assumption.