[PRE-ANN] BitcoinQE (Quantum Evolution) — Quantum-ready, Taproot-only (PQ)

[nicovoss]

[PRE-ANN] BitcoinQE (Quantum Evolution)
Quantum-ready • PQMTree-only (PQ) • dual extensions • 256-block rolling window

Status: Development in progress.


Important notice (read first)
This post is a technical pre-announcement for discussion purposes only. It is not a crypto-asset white paper and does not constitute marketing communication for any offer to the public or admission to trading. It does not set out the terms of any offer and is not intended to enable, and should not be relied upon for, any purchase decision.

No crypto-assets are being offered, no admission to trading is being sought, and no funds are being raised. Units would only exist if and when a network is launched; no distribution is occurring. No allocation plan, presale, airdrop, or bounty program is described in this post.


Motivation and time-sensitive research context

• Quantum Doomsday Clock
• The clock is ticking; the deadline to reach full post-quantum protection is short.

Protocol codename
BitcoinQE (Quantum Evolution) (working name)

Network identifiers (draft)

• HRP (bech32 prefix): bqe
• Chain/Network ID: bqe-main (TBD)

Denomination label: 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. These are notation conventions for the protocol; they do not imply issuance or availability.


Proposed parameters (research default Bitcoin-like consensus constants; subject to change)

• MAX_UNITS: 21,000,000 units
• INITIAL_SUBSIDY: 50 units per block (geometric emission schedule)
• GES_INTERVAL: 210,000 blocks
• TARGET_BLOCK_INTERVAL: 600s
• UTXO model: Bitcoin-like UTXO set, PQMTree outputs
• Address/output encoding: BECH32M-style encoding for PQMTree roots (no legacy scriptPubKey)
• Signatures: Post-quantum only (no ECDSA/Schnorr)
• Rolling validation window: 256 blocks (extensions kept; raw data older than this is purged)

What is BitcoinQE?
BitcoinQE is a Bitcoin-style chain that aims to reduce legacy complexity and is post-quantum from day one, but it is PQMTree-only. 
PQMTree (Post-Quantum Merkle Tree) — the core spending model.

What is PQMTree?
PQMTree is a UTXO-compatible construction where the output “address” is not a classical script/key. Instead, each output commits to a Merkle-root hash (the PQMTree root).


Block production and verification workflow
Bonded PoS + PoW-of-Verification (CPU-oriented) 
Goal: the “work” is actual PQ signature verification over the rolling dataset. Bonded PoS denotes a validator security deposit; no staking program or returns are offered.


Communication / Socials

• In parallel with forming the socials team: public repo, design notes, 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

Contributions are voluntary; no compensation is promised. 
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 Bitcoin-style UTXO 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.
• 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.

[taras588]

Socials? Discord tg? When launch?

[nicovoss]

Socials? Discord tg? When launch?

Short answer: We’re at the very beginning. No mainnet date yet, and Discord/Telegram aren’t open—there’s no point spinning up empty servers before we have a core spec and an active group.

Where we are

• Pre-ANN / M0: shaping the spec (Taproot-only + PQ, dual extensions, PoW-of-Verification).
• Next steps: M1 local PoC → M2 public devnet → M3 testnet → audits → mainnet proposal.

Socials (Discord / TG)
We’ll open channels once there’s a steady development cadence (ideally around devnet)—or earlier if enough volunteers come forward to set up and moderate.

Volunteers needed (not only coders)

• Community ops & moderation
• Technical writing & documentation
• Translations
• Comms/updates & channel setup
• Infra/testing once devnet is live

We’ll publish clear contribution instructions in the OP (intake form / contact details) when ready. Until then, feel free to watch the topic for updates.

[taras588]

Socials? Discord tg? When launch?

Short answer: We’re at the very beginning. No mainnet date yet, and Discord/Telegram aren’t open—there’s no point spinning up empty servers before we have a core spec and an active group.

Where we are

• Pre-ANN / M0: shaping the spec (Taproot-only + PQ, dual extensions, PoW-of-Verification).
• Next steps: M1 local PoC → M2 public devnet → M3 testnet → audits → mainnet proposal.

Socials (Discord / TG)
We’ll open channels once there’s a steady development cadence (ideally around devnet)—or earlier if enough volunteers come forward to set up and moderate.

Volunteers needed (not only coders)

• Community ops & moderation
• Technical writing & documentation
• Translations
• Comms/updates & channel setup
• Infra/testing once devnet is live

We’ll publish clear contribution instructions in the OP (intake form / contact details) when ready. Until then, feel free to watch the topic for updates.

Socials are needed to ask dev everyday how its going. Otherwise what a sense in re anns if the project will come in the next life

[nicovoss]

Socials? Discord tg? When launch?

Short answer: We’re at the very beginning. No mainnet date yet, and Discord/Telegram aren’t open—there’s no point spinning up empty servers before we have a core spec and an active group.

Where we are

• Pre-ANN / M0: shaping the spec (Taproot-only + PQ, dual extensions, PoW-of-Verification).
• Next steps: M1 local PoC → M2 public devnet → M3 testnet → audits → mainnet proposal.

Socials (Discord / TG)
We’ll open channels once there’s a steady development cadence (ideally around devnet)—or earlier if enough volunteers come forward to set up and moderate.

Volunteers needed (not only coders)

• Community ops & moderation
• Technical writing & documentation
• Translations
• Comms/updates & channel setup
• Infra/testing once devnet is live

We’ll publish clear contribution instructions in the OP (intake form / contact details) when ready. Until then, feel free to watch the topic for updates.

Socials are needed to ask dev everyday how its going. Otherwise what a sense in re anns if the project will come in the next life

Fair point — socials matter, but we’ll open them at the right time and in the right way.

Where we are (tech / project view)

• Stage: very early (pre-ANN / M0). The concept exists and I’m the initial developer, but a project of this size needs a core team to run reliably.
• Short-term focus: close the minimal spec (Taproot-only with PQ, dual extensions, 256-block window, PoW-of-Verification) and produce the first code artifacts.

Why not open Discord/TG “right now”?
Empty channels generate noise and pull time from engineering. We will open them when daily, factual updates (builds, commits, milestones) are realistic, and when there is at least one–two competent leads per domain plus a small helper subgroup to operate channels responsibly.

Communication plan (phased)

• In parallel with forming the socials team: public repo + spec draft + minimal build/test notes; I’ll post technical summaries here (changelogs, measurements, open items).
• When a small team stands behind the project (not just one dev): open Discord/TG with read-only #announcements and a dedicated #dev-updates feed, with responsible moderation.
• Release cadence: once there’s a larger, stronger dev team and socials that can support the community: daily commit feed + weekly rollups — no hype, only tangible results.

Resources & scaling
Right now I’m looking for committed volunteer team members and a team that covers the essential leadership, project management, communication, engineering and other key roles not exhaustively listed here. One person cannot build a community and the core code at the same time; socials add real value once a backbone team exists.

Bottom line
I agree: social channels are key for daily visibility and attracting supporters and developers. We’ll open them as soon as there is a stable development rhythm and a team behind the project. Until then, I’ll provide transparent technical updates here with real progress and measurable checkpoints. Later — when the team is in place — the OP will include team contacts and responsibilities.

[SomeOne@o@]

wait for it

[nicovoss]

wait for it

Status update (where I am right now)

• Base code: the latest bitcoin-30.0 tree.
• Target: a Taproot-only (with PQ keys) chain. I’m actively removing legacy/compat layers that are only needed to preserve Bitcoin backward-compatibility.
• First focus: clean up legacy address/key encodings so the system relies purely on modern formats.

What I’m removing/turning off now

• Base58Check addresses (P2PKH, P2SH) — not part of modern Taproot-based addressing.
• WIF (Base58 private key export) — PQ keypairs will need a different, modern encoding.
• BIP32 xpub/xprv (Base58) — extended keys will move to a bech32m-style or otherwise PQ-friendly scheme (TBA).
• ECDSA/legacy signature paths — Taproot in Bitcoin uses Schnorr; here these paths will be replaced by post-quantum signatures (algo TBA), so DER/low-S logic and related checks are being removed.

What stays / what replaces it

• Taproot-only addresses (bech32m logic) with a project HRP (e.g. bqe1… — exact HRP TBA).
• Post-quantum keys and signatures in Taproot leaves (algorithm/parameters TBA; e.g., Dilithium/Falcon family under evaluation).
• New extended-key format (non-Base58) for wallets/backups.
• Networking, mempool and block plumbing remain as the base, while script policy becomes Taproot-only.

[nicovoss]

Quick status update on the taproot-only madness 😄

In short: we’re through the “big surgery”.
The codebase is now basically a taproot-only, hex-based protocol core. Most of the classic Bitcoin baggage (WIF, Base58 addresses, P2PKH/P2SH/P2WPKH, etc.) has been thrown overboard.

Keys & addresses
The whole WIF / Base58 key & address world is gone.
Private keys and xpub/xprv-style things are now plain binary structures that we import/export as hex strings.
No more Base58Type, no WIF prefixes, no legacy Base58 addresses. Instead we have a cleaned-up, own prefix+payload scheme that actually fits a modern taproot-centric system.
Address handling is also much simpler now:

Only Bech32m Only taproot (v1, 32-byte witness program)
Plus an “unknown witness” path reserved for future versions.

All the old stuff (P2PKH / P2SH / P2WPKH / P2WSH / multisig / OP_RETURN) is either fully removed or effectively unused.
In practice: if this node considers something an address, it’s basically taproot.
Scripts, policy, descriptors
Script and policy logic has been aligned with this: we focus only on taproot outputs.
Plain pubkey/pkhash/scripthash/multisig/NULL_DATA types are out. Standardness checks no longer juggle datacarrier limits or bare multisig special cases.
The descriptor language got a big cleanup too. We kept the taproot building blocks:


tr(...), rawtr(...) taproot pk(...)
Miniscript in Tapscript context …and we dropped the classical stuff:
pkh(...), wpkh(...) sh(...), wsh(...) multi(...), sortedmulti(...) combo(...), addr(...), etc.

Address derivation is written with the assumption that it ends up with a taproot address, not picking from a mixed legacy zoo.
Wallet side
Same philosophy on the wallet layer:

Legacy ScriptPubKeyMan is gone

LEGACY / P2SH_SEGWIT / “old” BECH32 output types are gone

All those “implicit P2WPKH / P2SH-P2WPKH” tricks have been removed

The wallet is now focused on the descriptor-based, taproot-centric path.
The old HD chain loading model was also removed – this environment simply doesn’t need it anymore.
Signatures & quantum stuff
Right now, the signing logic is still using the Schnorr/Taproot path – but this is only temporary.
The idea is: Use the existing, well-tested Taproot signing mechanism

Get the new core stable and well tested on top of it

Then move on to redesign the whole signing / block / transaction handling stack to be truly quantum-safe.

On the PSBT side we’re already taproot-oriented (we care about v1, 32-byte witness programs), but the underlying cryptography is still the same curve family as Bitcoin today.
So to be very clear: This is NOT quantum-safe yet. Compared to original Bitcoin, it’s not more secure (cryptographically) at this moment – what changed is the structure, not the curve.

Key parsing reflects this as well: we parse hex (compressed/x-only pubkeys, new hex-format extended keys), without Base58 – but the signing primitive itself is still classical, not quantum-safe.
Where we are now
The important part: The code compiles The big structural refactor is done This is a working, taproot-only core, not just a design document

The signing layer is still not quantum-safe, so right now this system is not more secure than Bitcoin originally was, from a post-quantum perspective.

What we’ve actually done is: Deleted tons of very old, unnecessary legacy code that only held us back Consciously refused to keep compatibility with a bunch of old paths Opened up clean space to build something new on top of a much simpler, modern core

This isn’t a cosmetic patch – it’s a full taproot-only protocol core.
On top of it we’re still using the old (non-quantum-safe) signature layer for now, but the foundations are finally in a shape where we can realistically build a brand-new, quantum-safe signing + block + transaction model without being chained to a decade of legacy compatibility code.

[nicovoss]

Bitcoin QE (Quantum Evolution) — PoS Bootstrap Stake-Weight (Protocol Specification)

For Bitcoin QE (Quantum Evolution), the purpose of the PoS consensus bootstrap phase is to deterministically anchor the initial validation weights (stake-weight) from an external reference distribution that is broadly dispersed. To that end, the protocol uses the Bitcoin network’s UTXO state as the input dataset: snapshot selection, UTXO eligibility filtering, stake-weight derivation, and the time-bounded sunset of bootstrap weights are all consensus rules, not a distribution mechanism.

The protocol does not define a token allocation and does not create any pre-mined supply: BQE tokens are created only after PoS activation, exclusively as validation rewards under protocol rules. The bootstrap output is solely a set of non-transferable stake-weight assignments (stake key → weight), which the protocol treats as consensus voting/validation weight during PoS start-up and an initial transition period.

The binding between a Bitcoin UTXO and a BQE stake/validator key is expressed via a two-part proof object (StakeProof). StakeProof consists of two Bitcoin-like serialized raw transactions (CommitTxHex + SpendTxHex), where the CommitTx is data-only and provably invalid by construction (fictive prevout), and the SpendTx authenticates the binding under Bitcoin script rules in a way that neither element can be interpreted as an actual spend on the Bitcoin network. The protocol does not require KYC, registration, or the submission of personal data; the consensus state contains only key identifiers and stake-weights.

Concrete parameters (the snapshot selection predicate, supported UTXO classes and value ranges, script size caps, the StakeProof size cap, the legacy-stake sunset window, and the exact verification/mapping algorithms) are fixed in the reference implementation as auditable public source code. The detailed, consensus-normative description is defined by reference to the Bootstrap StakeProof pseudocode https://github.com/nicovossdev/bitcoinqe/blob/main/BootstrapStakeProof.pseudocode published on GitHub (Commit/Spend construction, verification steps, genesis stake-state construction); this pseudocode is the primary specification reference for the protocol.

[nicovoss]

PoS Bootstrap Address-Linking JSON Envelope

As we reach the end of the year and we know the last block hash and height, the JSON envelope used for the PoS consensus bootstrap phase (address linking) can be finalized and distributed immediately.

The protocol is anchored to a fixed block height so that identical conditions apply throughout the entire bootstrap period—on day 0 and on the closing day alike. This ensures that early participants receive no special advantage, and late participants are not disadvantaged.

The protocol does not define a token allocation and does not create any pre-mined supply. The bootstrap output is solely a set of non-transferable stake-weight assignments (stake key → weight).


How to create the JSON envelope required for bootstrap


1) Run the Wallet CLI (via Docker) to generate a BQE address

The following command downloads the required components and starts the wallet CLI so you can generate an address:

Code:

docker run --rm -it debian:latest bash -lc '
apt-get update
apt-get install -y --no-install-recommends ca-certificates curl libstdc++6
curl -L "https://github.com/nicovossdev/bitcoinqe/raw/refs/heads/main/bin/bcqe_wallet_cli
" -o /usr/local/bin/bcqe_wallet_cli
chmod +x /usr/local/bin/bcqe_wallet_cli
ldd /usr/local/bin/bcqe_wallet_cli || true
/usr/local/bin/bcqe_wallet_cli --version || true
'

After that, you will get a wallet CLI prompt with the list of available commands, like this:

Code:

Wallet CLI (MVP)
Commands (REPL):
help
exit
create --db <path> --name <wallet_name> --network <main|test> [--kdf-iters N]
load --db <path>
unload
unlock
lock
info
newaddress [--label <text>] [--change]
address --root <root_hex>
addresses list
addresses show <hrp_address>
dumpprivkey --spend-key-id <hex>

Here is an example of how to create a new address and display the corresponding private key:

Code:

create --db /home/bqcwallet --name miner --network main
Passphrase:
Confirm passphrase:
created wallet
name: miner
network: main
db: /home/bqcwallet
locked: false
newaddress
new address
address: bqe1tcymj7tssd57hdg67d3ml0hgxf53dtfjs556ls3vtfemm3dvy80rvgy2dq
root: de21acc5bd735a2cc2af298532ad166932e8bebf63f31ab5eb69837079b9095e
spend_key_id: d5435d087144e02e5f7631bc71970e8b94951eacaf6ae1d2972713f382d0d68a
pvm_namespace_id: 6867239910006149456
pvm_type: 1
pvm_leaf_schema_version: 0
is_change: false
dumpprivkey --spend-key-id d5435d087144e02e5f7631bc71970e8b94951eacaf6ae1d2972713f382d0d68a
6c1710510d87b0bcae7ba9da70da24b8939d807202ffd709a4a703e35446d41cc8e34e157c19d64edeb7337a4c2c4e822d3bbd3543b5e98497e93fa8b4fd59e59acf4c53961ecc423649e68cab3540dc0361178f0ff45cd9bf95fddd48ffb7df23563630b43c516ec4e815c3bcb660e9b7e6e4f66affc59fb6594af14bb9dd03
exit

Important (save and keep secret): Store this private key securely and do not share it with anyone. After the bootstrap phase is closed, you will need this key if you want to use your stake-weight assignment to participate in mining/producing the genesis block.

2) Determine the BTC scriptPubKey for the BTC address you want to link

In this example, assume the BTC address whose balance you want to bind (as initial PoS value) to the BQE address above is:

BTC address: bc1q6z5a9mz06g7qgj6ddpw0aty79x63rvld54xj5n

You will need its scriptPubKey, which you can obtain as follows:

Code:

bitcoin-cli getaddressinfo bc1q6z5a9mz06g7qgj6ddpw0aty79x63rvld54xj5n
{
"address": "bc1q6z5a9mz06g7qgj6ddpw0aty79x63rvld54xj5n",
"scriptPubKey": "0014d0a9d2ec4fd23c044b4d685cfeac9e29b511b3ed",
"ismine": true,
"solvable": true,
…
}

You will get many lines, but you only need the scriptPubKey value.


3) Create the address-linking transaction (BQE ↔ BTC) using the helper script

A helper script can be downloaded from GitHub here:

Code:

https://github.com/nicovossdev/bitcoinqe/raw/refs/heads/main/script/bqe_btc_link.sh

Run it and provide the inputs:

Code:

./bqe_btc_link.sh
Enter BQE address: bqe1tcymj7tssd57hdg67d3ml0hgxf53dtfjs556ls3vtfemm3dvy80rvgy2dq
Enter BTC address: bc1q6z5a9mz06g7qgj6ddpw0aty79x63rvld54xj5n
Enter scriptPubKey (hex): 0014d0a9d2ec4fd23c044b4d685cfeac9e29b511b3ed
bitcoin-cli signrawtransactionwithwallet "0000000001464523e4e4e92667d13c2441cae4e864982bc0635a97e7e6b3ba36bbb2c709ad000000000000000000010000000000000000016a00000000"
"[{"txid":"ad09c7b2bb36bab3e6e7975a63c02b9864e8e4ca41243cd16726e9e4e4234546","vout":0,"scriptPubKey":"0014d0a9d2ec4fd23c044b4d685cfeac9e29b511b3ed","amount":0}]"

Now execute the command generated by the script. This will sign the transaction that proves the owner of the BTC address intentionally links it to the given BQE address.

Code:

bitcoin-cli signrawtransactionwithwallet "0000000001464523e4e4e92667d13c2441cae4e864982bc0635a97e7e6b3ba36bbb2c709ad000000000000000000010000000000000000016a00000000"
"[{"txid":"ad09c7b2bb36bab3e6e7975a63c02b9864e8e4ca41243cd16726e9e4e4234546","vout":0,"scriptPubKey":"0014d0a9d2ec4fd23c044b4d685cfeac9e29b511b3ed","amount":0}]"
{
"hex": "00000000000101464523e4e4e92667d13c2441cae4e864982bc0635a97e7e6b3ba36bbb2c709ad000000000000000000010000000000000000016a024730440220599cd4745b8129546a2074671c5668665a045c714557565132cebb71fe5ebfca022002955458f66144bcfb30468492031092db98025d548abfb1fa630991b8c97998012102e76035c6c822d9fe7e923cb1beae46c16f64f4b87c233543033d9882697cf7af00000000",
"complete": true
}

4) Verify the signed transaction

Decode the signed transaction:

Code:

bitcoin-cli decoderawtransaction 00000000000101464523e4e4e92667d13c2441cae4e864982bc0635a97e7e6b3ba36bbb2c709ad000000000000000000010000000000000000016a024730440220599cd4745b8129546a2074671c5668665a045c714557565132cebb71fe5ebfca022002955458f66144bcfb30468492031092db98025d548abfb1fa630991b8c97998012102e76035c6c822d9fe7e923cb1beae46c16f64f4b87c233543033d9882697cf7af00000000
{
"txid": "cd8434d97bc52305a3362fa6a21110dc8b225dd6bff2cbac84c855872ff37af4",
"hash": "3cefd09dc65fe3e55f2d5ac2c74b62d2e9dacb2f9df864f3bc98dc2f64c31c85",
"version": 0,
"size": 170,
"vsize": 89,
"weight": 353,
"locktime": 0,
"vin": [
{
"txid": "ad09c7b2bb36bab3e6e7975a63c02b9864e8e4ca41243cd16726e9e4e4234546",
"vout": 0,
"scriptSig": {
"asm": "",
"hex": ""
},
"txinwitness": [
"30440220599cd4745b8129546a2074671c5668665a045c714557565132cebb71fe5ebfca022002955458f66144bcfb30468492031092db98025d548abfb1fa630991b8c9799801",
"02e76035c6c822d9fe7e923cb1beae46c16f64f4b87c233543033d9882697cf7af"
],
"sequence": 0
}
],
"vout": [
{
"value": 0.00000000,
"n": 0,
"scriptPubKey": {
"asm": "OP_RETURN",
"desc": "raw(6a)#4mhr9ur5",
"hex": "6a",
"type": "nulldata"
}
}
]
}

It is visible that the transaction is invalid not only because it spends a non-existent UTXO, but also because the output has

Code:

"value": 0.00000000

. However, the signature itself is correct, so the authenticity and intent of the BQE↔BTC link is verifiable.


5) JSON envelope template (based on the example above)

Code:

{
"v": 1,
"target_height": 840000,
"target_blockhash": "000000... (64 hex)",

"bqe": "bqe1tcymj7tssd57hdg67d3ml0hgxf53dtfjs556ls3vtfemm3dvy80rvgy2dq",
"btc": "bc1q6z5a9mz06g7qgj6ddpw0aty79x63rvld54xj5n",
"btc_scriptpubkey": "0014d0a9d2ec4fd23c044b4d685cfeac9e29b511b3ed",

"tx1_raw": "0000000001464523e4e4e92667d13c2441cae4e864982bc0635a97e7e6b3ba36bbb2c709ad000000000000000000010000000000000000016a00000000",
"tx2_signed_raw": "00000000000101464523e4e4e92667d13c2441cae4e864982bc0635a97e7e6b3ba36bbb2c709ad000000000000000000010000000000000000016a024730440220599cd4745b8129546a2074671c5668665a045c714557565132cebb71fe5ebfca022002955458f66144bcfb30468492031092db98025d548abfb1fa630991b8c97998012102e76035c6c822d9fe7e923cb1beae46c16f64f4b87c233543033d9882697cf7af00000000",

"created_at": 1766862434
}