Bitcoin Forum
September 21, 2025, 11:28:45 AM *
News: Latest Bitcoin Core release: 29.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1]
1  Alternate cryptocurrencies / Altcoin Discussion / Starting up BioCoin: Useful Proof of Work on: September 12, 2025, 05:22:42 PM
【Interest Check】 BioCoin — Proof-of-Useful-Biology (PoUB) you can verify on-chain

Preemptive TL;DR: I'm prototyping a coin where miners do verifiable “useful work” for biomedical research (e.g., docking/screening and other deterministic workloads). Each batch of work is committed via Merkle roots; verifiers sample audits; the best-scoring, fully audited batch becomes the block candidate. No token sale; just gauging community interest, security review, and early testers.



What is BioCoin?
A PoW-style chain where the “work” is real compute for bio/chem research but remains verifiable, deterministic, and permissionless. The design goal is to keep the things Bitcoin got right (open competition for block production, simple verification) while swapping hash-churn for audited, reproducible tasks with compact on-chain commitments.

Why now?
  • GPU/CPU cycles are abundant, but most PoW cycles aren’t useful to anyone else.
  • Many bio workloads can be run deterministically with public test harnesses, producing verifiable results.
  • With proper commitments and auditing, we can have both open mining and trustless verification.



How the prototype works (today)
  • Miners pull a public task seed (epoch/job ID).
    • They compute a large batch of candidate results (e.g., 100k attempts).
    • They commit the full outputs to a Merkle tree and publish only the root in the header.
    • A verifier samples a fixed number of audits from the batch (e.g., 192 random indices), recomputes them deterministically, and checks the Merkle proofs.
    • A scoring rule ranks batches (e.g., top docking scores / objective values); the best fully-audited batch at or under target becomes the block candidate.
    • Cryptography: fast hash (BLAKE3) for tree/commit; deterministic PRF/PRP for task scheduling; compact proofs for audits.

    Status: We have a working local prototype that:
    • Builds on standard C (portable),
    • Runs batched mining with fixed audit sampling,
    • Emits Merkle roots and per-index proofs,
    • Verifies “best of batch” against the audits and the declared score.
    Example (prototype CLI, subject to change):
Code:

mine batches of 100k attempts with 192 audits; expect ~1 block per N batches

miner e001 ffee 100000 192 32 out

verify the winning batch

biocoin_verify e001 ffee out



What we’re not doing
  • No ICO/IDO/“raise.” No promises of profit.
  • Not asking you to trust any lab’s private data. Early tasks are public, deterministic test harnesses; private workloads would require additional privacy work (see “Roadmap”).
  • Not reinventing consensus complexity for its own sake. Verification must stay cheap and deterministic.


Roadmap ideas (looking for pushback/eyes):

Public testnet with open miner + verifier binaries and source.

Job format v1: strictly deterministic workloads, public inputs, fixed audit policy, compact proofs.

Fairness & hardware neutrality: tune tasks so CPUs/GPUs both participate; document where specialized hardware helps and where it doesn’t.

Economics: base block subsidy + small market fee per accepted job; fees routed permissionlessly (no allowlists).

Security reviews: adversarial strategies (overfitting, precomputation, audit gaming), Sybil resistance, orphan-race dynamics, censorship risk.

Privacy tracks (optional, later): methods for private inputs (e.g., commit-and-reveal with public test harnesses, multi-party spot checks, or ZK-style attestations)—only if we can keep verification simple.



What we want from Bitcointalk right now
  • Miners: Would you point spare CPU/GPU at a useful-work testnet if payouts were similar to alt-PoW? What would you need to see first?
  • Verifiers/Dev reviewers: Eyes on the audit policy, Merkle commitment design, and header fields. What’s brittle? What’s gameable?
  • Researchers: Do you have deterministic workloads suitable for public test harnesses (no private data) that still reflect real utility?
  • Everyone: Rank these concerns 1–5 in order of importance to you: Security, Fair miner fairness, Open source licensing, Wallet/UX, Research usefulness.

Quick poll (reply with letters):

A) I’d mine this on testnet.
B) I’d run a verifier/help with audits.
C) I can provide deterministic workloads.
D) I want to review code/specs.
E) Not interested (say why).



FAQs (pre-emptive)

Q: How do you prevent “fake” useful work?
A: Only deterministic jobs with public test harnesses are allowed in v1. Miners commit the whole batch via a Merkle root; verifiers sample audits and recompute outputs. If any audited leaf fails, the block is invalid. Scoring is a pure function of the committed outputs.

Q: Can miners cherry-pick or overfit?
A: Audit indices are unpredictable at commit time, and enough audits are sampled to make cheating irrational. We’re tuning audit counts vs. batch size to keep verification cheap but economically secure; feedback welcome.

Q: Is this a token sale?
A: No. No sale, no promises, no investment pitch. This is an interest check + technical discussion before we open a public testnet.

Q: What about ASICs?
A: We’re designing tasks that map well to general-purpose hardware first. If a specialized accelerator emerges for useful kernels, that’s a good problem to have; the verification path must remain simple for everyone.



Who’s behind this?
A small, doxxed team building the prototype in C with an emphasis on open verification and simple cryptographic commitments. We’re sharing the repos/spec drafts in case there’s genuine interest here first, so the review can start where it matters: security and verification.



Next steps
If this gets traction, we’ll:
  • Post the minimal spec and reference code,
  • Spin up a public testnet,
  • Publish a shortlist of deterministic bio workloads for v1,
  • Invite security reviews before changing anything consensus-critical.
Thanks for reading. Shoot holes in it. If you care about open verification, miner fairness, and actually useful compute, I’d love your feedback. Additionally, if you'd like to contribute to its development, that would be great too. Since the purpose of BioCoin is useful hashing to advance medical research at a level accessible to everyone, I'd love to get more biologists, cryptocurrency experts, investors, etc, to think about useful hashes.

I would have posted the full white paper, but I don't think I can attach it directly here. The white paper can be found in the repo.
You can find a full version of it here: https://github.com/Joe-You-Know/BioCoin/blob/main/BioCoin.pdf

Donations for this are also welcome! It will be used for BioCoin funding. Feel free to pass it to anyone you think is interested, if inclined to do so.
Bio-Coin BTC: 15o5LUur6fw1qvuiHt7ynQ9fQoABeSfq3h
Bio-Coin ETH: 0xB10C6d0578a689Be8b61426A9E0AC1a40235fb1E
Bio-Coin XMR: 47cuBA71sPZTUmmq5nojLf3AMfPuLRyYNGLuBcpd6VPSZgvHySfB8Ka3DxYTi3AFSKi685Mu1NiC2E2 WhQES7T7oL8eT1zF
Pages: [1]
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!