[PRE-ANN] BitcoinQE (Quantum Evolution) — Quantum-ready, Taproot-only (PQ), dual extensions, 256-block rolling window, PoW-of-VerificationStatus: brainstorming / concept. Development has NOT started. This pre-announcement exists to shape the spec together.Leader — Quantum Doomsday ClockThe clock is ticking; the deadline to reach full post-quantum protection is short.
Project name: Bitcoin QE (Quantum Evolution)
Ticker: BQE
Base unit: 1 BQE
Smallest unit: bitgrain (bgr) — 1 bitgrain = 0.00000001 BQE
Conversion: 1 BQE = 100,000,000 bgr
A bitgrain plays the same role for BQE as a satoshi does for Bitcoin: it is the smallest indivisible unit of value.Proposed parameters (Bitcoin-like)– Supply cap: 21,000,000 BQE
– Genesis subsidy: 50 BQE per block (classic halvings)
– Halving interval: 210,000 blocks (~4 years at 10 min)
– Target block interval: 10 minutes
– Difficulty retarget: every 2,016 blocks (~2 weeks)
– Address/tx format: Taproot-only with PQ keys/signatures (no ECDSA/Schnorr)
– Rolling validation window: 256 blocks (extensions kept; raw data older than this is purged)
– Claim maturity (after a root becomes Active): 256 blocks
– VoterPot: 1% of each 256-block epoch’s subsidy (claimable by voting miners)
What is this?BitcoinQE is a Bitcoin-style chain that supports Taproot only while removing legacy baggage. Taproot leaves use post-quantum (PQ) keys and signatures from day one.
Vision (fluid, up for discussion)- PQ-only under Taproot: no EC fallback. (Algorithm TBA, e.g., Dilithium/Falcon.)
- Two extensions per block:
PQ-signature extension — all transaction public keys and signatures (root: PQExtRoot)
Hashgraph-mining extension — witness events as a DAG layered across 256 blocks (root: HGExtRoot) - Short main block: the main block carries PQExtRoot, HGExtRoot and minimal digests; details live in the extensions.
- 256-block rolling window: full PQ data is available inside the window; beyond it, raw data is purged and only compact commitments remain.
- Simple FraudProof: one invalid signature plus a Merkle branch invalidates a false witness; the miner becomes ineligible for the voter bonus for that window.
Mining (outline) — PoW-of-Verification (CPU-oriented)Goal: the “work” is actual PQ signature verification over the rolling dataset. Designed for general-purpose CPUs; ASIC/GPU advantage is something we aim to minimize (never guaranteed).
- Seed. Derived from the previous block hash, previous PQExtRoot and HGExtRoot, the coinbase address, and the voted root.
- Pick a block inside the window. Deterministically select one height within the 256-block window.
- Full PQ verify on that block. Verify all signatures in that block’s PQ extension; produce a local digest; emit a signed witness event into the hashgraph referencing its parents.
- Window-wide random checks. From the seed and a nonce, sample K additional signatures scattered across the entire 256-block window; verify each with its Merkle proof; fold into a digest.
- Hashgraph checks. Validate selected parent/ancestor links and their signatures; fold into a digest.
- Work digest. Hash the three digests plus nonce; the block is valid if the result meets the difficulty target.
- Block contents. Main header: PQExtRoot, HGExtRoot, coinbase, vote. Hashgraph extension: the witness event and references. Work attachment: sampled indices and Merkle branches so validators can re-check.
Why CPU-friendly? The working set spans 256 blocks of PQ leaves plus the DAG; access is data-dependent and seed-driven; PQ verification uses large key/signature objects and branching control flow — all unfavorable to rigid pipelines.
Issuance & distribution (Bitcoin feel, developer treasury)- Subsidy goes to TreasuryPool, not to miners. Miners earn fees (plus the voter bonus below).
- MERIT-based eligibility: the community maintains an off-chain, auditable MERIT log. Periodically a closed Claim-Merkle is published listing addresses with their MERIT points (reflecting actual contributions). This is not a payment promise.
- Claim (opt-in): eligible contributors may, at their discretion, claim a proportional share from the TreasuryPool based on their MERIT points, via Merkle proof. There is no automatic payout.
- RootAnchor + miner voting: after a Claim-Merkle root is published, miners vote for it in every block. Voting window: 256 blocks. If a root gathers at least two-thirds support within the window, it becomes Active. While Active, every new block must reference it; otherwise the block is invalid.
- Claim maturity: claims open 256 blocks after activation.
- Miner VoterPot: 1% of the subsidy accrued in each 256-block epoch; allocated pro-rata to coinbase addresses of blocks that voted for the winning root within the window; claimable with a Merkle proof.
Extensions & purge (state control)- PQ-signature extension: outside the 256-block window, raw PQ signatures are purged; headers and PQExtRoot remain.
- Hashgraph-mining extension: events older than the window are purged; required linking digests remain in block headers.
- Past blocks are validated against the surviving roots/commitments; raw PQ data is not retained beyond the window.
Open questions (seeking input)– PQ algorithm and parameters (key/signature sizes, costs)
– Hashgraph extension format, parent selection, finality thresholds (tied to 256)
– FraudProof mechanics (challenge process, invalidation rules)
– Mining parameters: sample size K, target rule, per-block verification cost
– MERIT scoring practice: off-chain, community-approved rubric and review
Roadmap (very early, subject to change)- M0: community spec draft (Taproot+PQ, dual extensions, 256-window, RootAnchor+Vote, TreasuryClaim, VoterPot, PoW-of-Verification)
- M1: local POC (ledger/merkle, coinbase-vote, PoV verification, invalidity rules, claim path) — no value
- M2: devnet (fee-only mining, VoterPot, simple FraudProof scaffold)
- M3: testnet (parameter tuning, audits)
- M4: audits + mainnet proposal
Communication / Socials- In parallel with forming the socials team: public repo, spec draft, minimal build/test notes.
- Until a team is in place: I will post weekly technical summaries in this topic (changelogs, measurements, open items).
- When there is a small team behind the project (not just one developer): we will open Discord/Telegram with separate #announcements and #dev-updates channels, with responsible moderation.
Contribute– C / C++ engineers (consensus, Merkle/DAG, networking)
– PQ cryptographers (algorithm choice, implementation risks)
– Node operators & testers (measurements, telemetry)
– Documentation / translation / comms
We’re looking for
volunteer, project-committed team members and a team covering the essential
leadership, project management, communication, engineering and other key roles not exhaustively listed here.
FAQ — “Why use ‘Bitcoin’ in the name?”A: To signal Taproot-only, Bitcoin-style design lineage and keep amounts familiar.
It is not affiliated with Bitcoin (BTC) or Bitcoin Core.Legal notice– No ICO, no token sale, no yield, no automatic payouts. The protocol directs block subsidy to the TreasuryPool; community-published, closed Claim-Merkle lists record MERIT points. Holders of MERIT may, at their discretion, claim proportionally from the TreasuryPool. This is not a payment promise or entitlement; participation is voluntary.
– Developers/contributors accept no liability for any loss or harm arising from bugs, faulty code, network issues, configuration errors, or user mistakes. Only participate (development, operation, or use) if you agree to these terms.
– All details are fluid and subject to discussion. Feedback welcome.[/list]
