Pool-design docs question for a Bitcoin-derived testnet

[obtc-maintainer]

Hi, I maintain OBTC, a separate Bitcoin-derived PoW experiment around expiry, renewal, and rule-bound reclaim. I have a narrow pool-design documentation question.

For reviewers who think in decentralized-pool or miner-selected-template terms, what should a Bitcoin-derived testnet document clearly around block-template construction, coinbase accounting, template mutation boundaries, and solved-block submission?

Public refs:

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

This is not a request for Braidpool support, endorsement, promotion, investment coverage, miner support, pool support, or hashrate, and there is no miner revenue claim. I am only trying to avoid misleading or incomplete mining-interface docs.

[mcelrath]

I'm not sure what this is about. It appears to be largely vibe coded and your README doesn't describe what the point is or what you're trying to do (a common vibe-coding problem...). That would help me understand and answer your question. What are you trying to create here and why?

[obtc-maintainer]

Thanks, this was useful feedback.

I updated the top of the obtcd README and added a short reviewer quick start so the project is easier to understand before getting into pool-design details:

• README: https://github.com/organicbitcoin/obtcd
• Reviewer Quick Start: https://github.com/organicbitcoin/obtcd/blob/master/docs/reviewer-quickstart.md

The short version is: OBTC is a separate Bitcoin-derived PoW experiment around UTXO lifecycle rules: expiry, renewal, REAP, refund/security-budget accounting, expiry commitments, and replay protection.

The experiment is about whether dormant UTXO state and long-term security-budget pressure can be handled with explicit lifecycle rules in a separate chain.

No endorsement, adoption, or pool support is being requested. The useful feedback at this point would simply be whether the "what / why / review ask" is now clear enough.