[DEV] QProof (QPF) Building a Post-Quantum CPU-Mined Cryptocurrency | 0 Premine

[Qproof]

QPROOF (QPF)
Post-Quantum Proof-of-Work Cryptocurrency

https://www.talkimg.com/images/2026/08/24/U5PNR9.png

Currently in development — no ICO, no presale, no premine, no coins for sale.

What is QProof?

QProof (QPF) is a proof-of-work cryptocurrency being developed around a simple idea:

If we're designing a new cryptocurrency today, why build its long-term security around cryptography we already know will eventually need replacing?

QProof is being designed from the protocol level around post-quantum cryptography rather than trying to bolt PQ security onto a legacy protocol later.

This is NOT a launch announcement.

There is currently:

• no public QProof mainnet
• no QPF for sale
• no ICO
• no presale
• no premine
• no founder allocation
• no developer allocation
• no official public mining pool accepting public miners

I'm posting development publicly because I'd rather have experienced cryptocurrency developers, miners and security people criticize the design BEFORE genesis/mainnet launch than discover fundamental problems afterward.

Ticker note:

Early development posts used QPR.

The canonical current human-facing QProof asset symbol is now:

QPF

That is a terminology cleanup. Existing protocol/network identity bytes are not being casually renamed merely because their byte values resemble earlier lettering.


Design Goals

• Post-quantum security by design

Post-quantum signatures and key encapsulation are designed into the protocol from the beginning.

• CPU-oriented Proof of Work

RandomX is currently the active proof-of-work algorithm, with the goal of keeping commodity CPUs relevant.

RandomX is NOT being advertised as mathematically "quantum-proof."

• Fair launch

0 premine.
0 founder allocation.
0 developer allocation.
0 spendable genesis allocation.
No ICO.
No presale.

Development funding, if any, should come from optional infrastructure/services rather than privileged consensus issuance.

• Conservative consensus development

Consensus rules are being designed, attacked, tested and reviewed before mainnet rather than casually changed after miners and users have committed resources.

• Native IPv4 + IPv6 networking

The node has explicit IPv4 and IPv6 networking support rather than relying on IPv4-only operation.

• Decentralized mining infrastructure

QProof is developing a P2Pool-style decentralized sharechain so pool coordination does not require making a single conventional pool operator part of consensus.

• Cryptographic migration

Transaction/key formats include explicit versions and algorithm identifiers so future cryptographic migration can be handled deliberately rather than by redesigning the entire protocol.

• Automation / agent-safe interfaces

Wallet/API work is being designed around explicit capabilities, policy boundaries and human-controlled authorization rather than handing software or AI agents unrestricted spending keys.

QProof consensus itself remains application-neutral.


Post-Quantum Architecture

The currently implemented cryptographic foundation includes:

• ML-DSA-65 transaction authorization
• ML-KEM-768 encrypted-payload key establishment
• AES-256-GCM authenticated encryption
• HKDF-SHA256 key derivation
• SHA-256 protocol hashing / commitments
• RandomX proof of work
• separate signing and encryption/KEM identities
• versioned cryptographic algorithm identifiers
• versioned address/key formats
• network/chain replay protection
• deterministic consensus activation boundaries
• hash-agility boundaries
• reserved/versioned merge-mining representation

Current algorithm registry includes:

• Signature ID 1: ML-DSA-65 — active
• Signature ID 2: SLH-DSA-SHA2-192s — recognized/reserved, inactive
• KEM ID 1: ML-KEM-768
• Hash ID 1: SHA-256
• Symmetric cipher ID 1: AES-256-GCM
• KDF ID 1: HKDF-SHA256

An independent SLH-DSA family is reserved as a possible future post-quantum alternative but is NOT active.

Recognizing an algorithm in software does not automatically activate it in consensus.

Signing and KEM/encryption identities are kept separate rather than reusing one cryptographic secret for unrelated purposes.

Important:

QProof is not being advertised as "unbreakable" or permanently immune to future cryptanalytic advances.

Cryptographic assumptions can fail.

The goal is an end-to-end post-quantum-oriented architecture with an engineered migration path if today's preferred algorithms eventually need replacement.


Consensus / Network Parameters

Current reviewed pre-mainnet development parameters include:

• Target block spacing: 120 seconds
• Maximum block size: 2 MiB
• Active proof of work: RandomX
• Coinbase maturity: 100 blocks

Difficulty adjustment uses:

per-block genesis-anchored ASERT

after the initial three-block bootstrap.

Current ASERT half-life:

14,400 seconds / 4 hours

The older development description of a 120-block retarget interval is obsolete.

The longer 120-second production target was retained after considering:

• full-block propagation
• bandwidth
• stale-block / short-reorg risk
• current lack of compact-block relay
• difficulty response behavior
• new-network hashrate volatility

Difficulty settings cannot guarantee miner participation. Actual network security will depend on observed hashrate, energy/hardware economics, coin value, fees and miner behavior.


Monetary Policy

Current reviewed pre-mainnet schedule:

• Initial scheduled subsidy: 25 QPF/block
• Subsidy epoch: 262,800 blocks
• Nominal epoch length at 120 seconds: approximately one year
• Reduction: floor(previous subsidy × 4 / 5)
• Permanent tail emission: 1 QPF/block
• Tail begins: height 3,942,000
• Transaction fees are paid in addition to subsidy

Launch allocation:

0 QPF premine
0 QPF founder allocation
0 QPF developer allocation
0 QPF spendable genesis allocation

There is intentionally no finite maximum-supply claim because QProof uses permanent tail emission.

The tail avoids an eventual hard transition to fee-only proof-of-work security.

The internal MAX_MONEY-style amount bound is an arithmetic/transaction safety bound.

It is NOT a claim that lifetime QPF issuance stops at that number.


Genesis / Fair Launch

The currently pinned mainnet object in the development tree is a:

PROVISIONAL DEVELOPMENT GENESIS

It is NOT the finalized launch genesis.

Normal mainnet startup refuses to operate with the provisional mainnet configuration unless the operator explicitly enables the development-only provisional-mainnet option.

The current development checkpoint contains:

Coinbase value:
0 QPF

Premine:
0 QPF

Founder allocation:
0 QPF

Developer allocation:
0 QPF

Current provisional development genesis hash:

Code:

0ba820b2800bc89351ab71a0ee134dd148ba42fa0461231410f3ba3970f21845

Current provisional merkle root:

Code:

c6eaa0681e8ddf9166cdcf4d4be1e117270ff6559a29f5cb43ecf6e7dbf8dc1f

Current provisional nonce:

Code:

1

These values are development/checkpoint evidence.

They are NOT being advertised as immutable launch values.

The final launch timestamp and initial difficulty/target will be selected near actual launch using measured RandomX hashrate and launch conditions.

A final launch genesis will then be generated/mined through the canonical genesis builder and reviewed as new golden vectors.

There will be no secret early mining period.

Correctness takes priority over preserving a pre-launch development hash.


Consensus Activation / Future Cryptography

Each network has static consensus deployment parameters.

Future features can be recognized by software while remaining inactive.

Current recognized-but-unscheduled future items include areas such as:

• merge-mining v1
• SLH-DSA-SHA2-192s
• future hash-suite migration

There is currently no:

• miner-voting shortcut
• remote developer activation key
• RPC activation override
• GUI activation switch

A future consensus activation must arrive through reviewed software with explicit deterministic consensus parameters.

Historical blocks/transactions remain governed by the rules applicable to their format and branch height.


Addresses / Replay Protection

QProof addresses encode information including:

• address format version
• signing-key type
• commitment-hash type
• ownership commitment
• network identity

Mainnet, testnet and regtest have distinct identities.

Signed transaction data binds the chain/network identity to prevent cross-network transaction replay.

Canonical QProof addresses are lowercase.


Encrypted Application Payloads

QProof transactions support a small bounded encrypted application payload.

The blockchain does NOT need to understand the meaning of the application message.

The generic path is:

Code:

application data
      |
      v
ML-KEM encrypted payload
      |
      v
QProof transaction
      |
      v
canonical signing preimage
      |
      v
ML-DSA transaction authorization
      |
      v
transaction validation
      |
      v
mempool / block
      |
      v
LMDB persistence
      |
      v
intended recipient decrypt

Development testing has exercised this path using:

• a real isolated qproofd process
• real RPC transport
• real mempool admission
• real block-template selection
• real RandomX mining
• real block submission
• LMDB persistence
• node restart/recovery
• recipient decryption
• wrong-recipient rejection
• maximum-size payload boundary tests

Possible application uses could include:

• private receipt references
• invoice/order metadata
• bookkeeping context
• warranty/tracking references
• document hashes
• application-to-application messages
• machine-to-machine payment workflows

These examples do NOT become QProof consensus semantics.

The payload remains a bounded generic application primitive.


Mining / RPC / Mempool

The node-side mining path is implemented far beyond the original early-development state.

Current development includes:

• mempool transaction admission
• fee-aware transaction handling
• mining-template generation
• canonical block submission
• RandomX proof validation
• reference external miner
• Stratum-facing P2Pool path
• stale-work handling
• persistent block acceptance/recovery

Native mining and decentralized P2Pool mining are both intended to remain supported.


Decentralized P2Pool Sharechain

QProof's decentralized P2Pool sharechain foundation is implemented and checkpointed.

Current foundation includes:

• parent-linked proof-of-work shares
• independent share difficulty
• sharechain identity
• cumulative-work fork choice
• locator/batch synchronization
• share gossip
• late-peer synchronization
• reconnect/resync
• malformed peer-data rejection
• oversized frame rejection
• invalid-share rejection
• Stratum integration
• real QProof block submission

Development testing has run two independent qproof-p2pool processes with an actual established share-peer connection.

A reference miner connected through the second pool and produced a real block accepted by qproofd.

Important distinction:

The decentralized sharechain foundation is NOT the same thing as finished production pool economics.

Still unfinished/review-required areas include:

• actual decentralized miner payout accounting
• PPLNS or reviewed alternative payout-window rules
• miner balances
• payout rounding/dust rules
• persistent sharechain storage
• public peer discovery/bootstrap
• production pool operation
• finalized multi-recipient coinbase payout semantics

No P2Pool operator/development fee is intended to become a mandatory QProof consensus tax.


Merge Mining

QProof is designed with a reserved/versioned merge-mining capability.

Native mining currently uses the normal active proof-of-work representation.

Merge-mining v1 is recognized by the protocol architecture but is NOT currently activated.

No parent cryptocurrency has been selected.

Future parent-chain decisions will need to consider:

• PoW compatibility
• available hashrate/security
• miner ecosystem
• implementation complexity
• pool compatibility
• decentralization effects
• long-term viability
• real economic incentive for miners

Merge-mining support will not be activated merely because an identifier exists in the code.

It requires a complete reviewed design and deterministic activation decision.


Persistent Node / Chain Recovery

QProof uses LMDB for node persistence.

The node has a single authoritative persisted-chain recovery path rather than separate competing recovery implementations.

Development testing has covered areas including:

• clean restart/recovery
• block persistence
• reorganization persistence
• competing branches
• commit/write failure behavior
• already-known blocks
• synchronization
• disconnect/reconnect
• persistent recovery after mined blocks

Existing rollback/atomicity guarantees are being treated as important invariants.

Storage hardening is NOT finished.

A fixed long-term map size is not acceptable for production, and synchronized bounded live LMDB map growth remains an upcoming hardening task.


IPv4 / IPv6 Networking

QProof networking has been developed with both IPv4 and IPv6 operation in mind.

Testing has exercised:

• IPv4 listeners
• IPv6 listeners
• outbound address resolution
• synchronization
• disconnect/reconnect
• peer restart
• fork-aware synchronization
• malformed network input rejection

The next network-hardening phase is increasingly about hostile-resource behavior rather than simply establishing connectivity.

That includes areas such as:

• peer-count bounds
• per-IP/subnet policy
• inflight synchronization limits
• slow peers
• connection churn
• malformed/unsolicited traffic
• backpressure
• expensive post-quantum verification floods
• RPC resource limits


Wallet / Agent-Safe Architecture

QProof wallet work separates:

• transaction preparation
• authorization
• submission
• spending keys
• automation authority

The intended rule is simple:

Software may read, explain and prepare.
Human policy controls authorization.
Automation does not receive unrestricted spending keys.

Unix/Linux Agent-Safe IPC/client work has been developed and tested.

Windows secure Agent-Safe IPC is NOT being claimed complete.

A security-equivalent Windows implementation needs a properly reviewed native local-IPC / ACL / identity model.

Unsupported secure IPC paths are intended to fail closed rather than silently falling back to a weaker mechanism.


Cross-Platform Validation

QProof has completed expanded portable validation on:

Linux / GCC

and:

Windows / MSVC

The QPVECTOR10 deterministic comparison passed:

10/10 Linux
10/10 Windows

The portable harness exercises real QProof protocol/consensus and runtime components rather than a separate mock protocol.

Validated areas include portions of:

• protocol/consensus behavior
• serialization
• wallet behavior
• endpoint/network client behavior
• LMDB node core
• qproofd
• mining
• P2Pool
• reference external miner

macOS and Android portability are still separate unfinished validation areas.

Legacy macOS compatibility work exists, but that is not being presented as complete modern macOS platform certification.


Recent Three-Machine Fleet Testing

A recent development fleet used:

• Linux Lappy2 — node / P2Pool / integration command center
• Windows Lappy1 — external reference-miner lane
• Windows Mini — independent observer / secondary test machine

Lappy2 evidence included:

• 8-hour long-soak window
• 23 integration gates
• 7 recovery restarts
• older IPv4 soak: 6179 PASS rounds
• Release checkpoint suite: 39/39
• Debug checkpoint suite: 39/39

Mini observer evidence included:

• 393 sampled observations
• 393 RUNNING observations
• 0 explicit failed/down/dead states
• 0 ERROR/FATAL/CRASH lines

The historical Windows miner lane produced substantial accepted work, followed later by a separate degraded/rejection regime.

Rather than guessing at the cause from the historical log, the old runtime was retired and the path was reproduced from fresh aligned current code.

Fresh reproduction result:

100 sequential miner runs
100 accepted
0 stale
0 rejected
0 nonzero exits

The historical rejection regime therefore did NOT reproduce under the fresh current node -> P2Pool -> Windows reference-miner path.

Its historical root cause remains unassigned.

That distinction is deliberate.


Development Testing Philosophy

The rule is basically:

Don't launch it until we've abused it enough that testing becomes boring.

Testing has already exposed implementation and test-harness problems before launch, which is exactly what it is supposed to do.

For example, a recent Debug integration run exposed an encrypted-payload restart test whose RPC-readiness allowance was too short for Debug startup on the development machine.

The production node restarted successfully; measured Debug RPC readiness was roughly eight seconds while the test allowed about five.

The test-only readiness allowance was increased and the previously failing test passed.

No production consensus/node/crypto behavior was changed by that fix.

Current test organization includes tiers such as:

• fast
• normal
• crypto
• integration
• soak
• checkpoint

There is still no mainnet.

That's intentional.


What QProof Is NOT

There is currently:

NO ICO
NO PRESALE
NO PREMINE
NO FOUNDER ALLOCATION
NO DEVELOPER ALLOCATION
NO PUBLIC MAINNET
NO PUBLIC TESTNET CLAIM
NO QPF FOR SALE
NO FINAL LAUNCH GENESIS
NO PRODUCTION-READINESS CLAIM

If someone offers to sell you "QProof" or QPF right now, it is not coming from this project.

There is currently no official public QProof mining pool accepting public miners and no public mainnet mining.


Why post this before launch?

Because I'd like criticism.

Seriously.

I'm particularly interested in technical feedback concerning:

• post-quantum cryptocurrency architecture
• ML-DSA / ML-KEM integration
• crypto agility
• address/key versioning
• domain separation
• deterministic consensus activation
• RandomX / CPU mining
• ASERT difficulty adjustment
• merge-mining design
• decentralized pool/sharechain design
• P2Pool payout design
• tail-emission/security-budget design
• chain synchronization
• fork/reorg behavior
• hostile-network/resource testing
• LMDB long-term durability
• mempool design
• mining-template/RPC architecture
• wallet/key-custody security
• agent-safe wallet/API security
• encrypted application payloads
• long-term miner incentives
• anything we've overlooked before mainnet

If something fundamental is wrong, NOW is when I want to hear about it.

There is considerably less ego involved in changing pre-mainnet software than discovering after launch that something should have been designed differently.


Current Development Priorities

The project is deliberately trying to strengthen its weakest dimensions rather than adding consensus features for novelty.

Current high-level priority is approximately:

1. consensus/economic correctness before freeze
2. hostile-network/resource-exhaustion resistance
3. storage durability / long-lived node operation
4. multi-node convergence and restart/recovery evidence
5. wallet/key-custody/security boundaries
6. fuzzing / sanitizers / static analysis / external audit preparation
7. decentralization/bootstrap/operator tooling
8. mining/P2Pool economic interoperability
9. broader platform portability

Public testnet comes only after the prerequisite protocol/security work earns it.


Current Stage

Consensus/economics pre-freeze review:
CHECKPOINTED

Canonical asset ticker:
QPF

RandomX proof of work:
WORKING

Per-block ASERT:
WORKING

Post-quantum transaction foundation:
WORKING

ML-KEM encrypted application payload:
WORKING / TESTED

Mempool:
IMPLEMENTED / HARDENING CONTINUES

Mining-template / submit-block RPC:
IMPLEMENTED / HARDENING CONTINUES

Reference external miner:
WORKING

IPv4 + IPv6 networking:
WORKING / HARDENING CONTINUES

Persistent LMDB chain recovery:
WORKING / STORAGE HARDENING CONTINUES

Decentralized P2Pool sharechain foundation:
WORKING

P2Pool production payout economics:
NOT FINALIZED

Linux portable validation:
PASS

Windows portable validation:
PASS

Windows secure Agent-Safe IPC:
NOT IMPLEMENTED — FAIL CLOSED

macOS complete portability validation:
NOT YET

Android NDK validation:
NOT YET

Final mainnet genesis:
NOT YET

Public testnet:
NOT YET

Mainnet:
NOT YET

That distinction matters.

I'd rather publish exactly where the project stands than advertise unfinished components as completed features.


Links

Primary project domain:

qproof.dev

DNS / HTTPS activation pending.

Temporary development homepage:

https://qproof-coin.github.io/

Discord:

https://discord.gg/hEgPpPzg

Development discussion, testing coordination and project updates.

The temporary GitHub Pages site is being used while the permanent qproof.dev domain is brought online.

Source repository and technical documentation will be linked publicly when they are prepared for public presentation.

This thread will continue to be updated as meaningful development milestones are completed.

QProof (QPF)

Built first. Launched later.

[Qproof]

Reserved  

[Seikar]

• Merge mining
Merge mining is being designed as a first-class, versioned consensus capability. The parent chain has NOT been selected yet.

Versioned consensus means, I am guessing, not merge mining at the very start but later after a future version.  Arguably that is better than at the start.  Large merge miners may aid 51% attack resistance, energy efficiency, and sometimes visibility (if I haven't missed any other reasons for merge mining?) but also can threaten what especially helps a new coin: small miners caring about the particular coin.

Source repository and technical documentation will be linked here as they are prepared for public presentation.

Indeed quite need.

I like the announcement before launch and so on, though.

[Qproof]

• Merge mining
Merge mining is being designed as a first-class, versioned consensus capability. The parent chain has NOT been selected yet.

Versioned consensus means, I am guessing, not merge mining at the very start but later after a future version.  Arguably that is better than at the start.  Large merge miners may aid 51% attack resistance, energy efficiency, and sometimes visibility (if I haven't missed any other reasons for merge mining?) but also can threaten what especially helps a new coin: small miners caring about the particular coin.

Source repository and technical documentation will be linked here as they are prepared for public presentation.

Indeed quite need.

I like the announcement before launch and so on, though.

Merge mining should be available when binaries are released at mainnet launch. Preliminary testing is in progress...


2026-08-26 clarification:

Thanks — that's basically the tradeoff I'm thinking about.

Merge mining can potentially bring useful hashrate, energy reuse and additional visibility, but I also don't want QProof's early security model to depend on one or two huge external miners who have little reason to care about the network itself.

The QProof-side protocol architecture reserves a versioned merge-mining capability, but native RandomX mining remains a complete path of its own.

One correction to my original reply here:

I previously said merge mining should be available when binaries are released at mainnet launch.

That was too definite.

Current QProof status is:

• merge-mining v1 is recognized by the protocol architecture
• it is NOT active
• no parent cryptocurrency has been selected
• no production activation height has been assigned
• mainnet release is NOT being made contingent on merge mining being enabled

Before merge mining can be activated it still needs a complete reviewed parent-proof design, deterministic consensus rules, miner/pool integration, cross-platform test vectors and security review.

If that work is not ready when native QProof is otherwise ready, native mining comes first and merge mining can remain inactive.

I'd rather leave an intentionally designed activation seam in the protocol than rush an external-chain dependency just to check a feature box.

And yes — source and technical documentation still need to be public before a real launch. The development repository is being kept private while the protocol/security boundaries are still moving, but public review is part of the path before mainnet.

[Qproof]

QProof Development Update — Wallet / Agent-Safe Backend Milestone

Another substantial QProof development milestone is complete and checkpointed.

Development is currently being kept in a private repository while the protocol, wallet architecture and security boundaries are still being hardened. I'll continue posting concrete development results and screenshots here as milestones are reached.

The focus of this phase was not adding flashy features.

It was building a wallet architecture that can eventually support both normal desktop users and software/AI agents without simply handing unrestricted wallet authority to whatever application happens to be calling it.

Current implemented and tested work includes:

• Persistent node/database and chain recovery infrastructure
• Dual-stack IPv4 + IPv6 P2P networking
• Block synchronization and fork-aware chain handling
• Bounded mempool and transaction relay
• Mining-template and canonical block-submission path
• Standalone reference miner
• Encrypted persistent wallet
• Wallet transaction creation and signing
• Wallet history, rescan and reorg handling
• ML-DSA-65 transaction signatures
• Standalone wallet CLI
• Ownership-scoped wallet RPC interfaces

Agent-Safe wallet architecture

The newest milestone is the Agent-Safe wallet architecture.

The Unix/Linux wallet agent runs as a separate local process over AF_UNIX rather than exposing wallet keys directly to qproofd or another client.

Capabilities are separated into:

Code:

READ
PREPARE
AUTHORIZE
SUBMIT
ADMIN

Transaction authorization is deliberately split into stages:

Code:

prepare -> authorize -> submit

The wallet password is only accepted during authorization.

After authorization, the wallet immediately relocks and creates a passwordless, single-use authorized submission artifact.

That means the later submission step does not require the wallet password or private key material to remain exposed.

SubmissionUncertain

One failure case received special treatment.

If a transaction has been accepted by the network but the local wallet-history commit subsequently fails, the proposal enters a terminal:

Code:

SubmissionUncertain

state.

The software is specifically prevented from blindly replaying that transaction.

For an automated client or future AI agent, that distinction matters:

"I don't know whether this transaction was submitted"

must never silently become:

"send it again."

Additional Agent-Safe hardening implemented in the Unix/Linux IPC path:

• Local AF_UNIX IPC only
• Same-UID peer enforcement
• Owner-restricted socket, token and audit permissions
• Capability-scoped bearer sessions
• Restart-safe token bootstrap
• Token rotation and revocation
• Atomic token replacement
• Durable bounded audit history
• Atomic audit rewriting and fsync handling
• Stable machine-readable IPC error codes
• Strict bounded request/response framing
• Bounded JSON parsing
• Duplicate-field rejection
• Malformed/trailing-data rejection
• Request-ID validation
• Bearer-token leak suppression
• Reusable local C++ IPC client for GUI integration
• No automatic reconnect/replay of tx.submit

The IPC client was exercised against real local UNIX sockets for:

• Normal request/response round trips
• Short/chunked socket reads and writes
• Truncated response headers
• Truncated response bodies
• Zero-length frames
• Oversized frames
• Incorrect request IDs
• Unsupported response versions
• Malformed JSON
• Duplicate/spoofed fields
• Unsafe socket paths
• Symlink/non-socket paths
• Malicious bearer-token echo
• SubmissionUncertain handling
• Verification that tx.submit is not automatically replayed

Checkpoint results at the time of this milestone:

Code:

Agent-Safe focused tests: 4/4 passed
Fast checkpoint suite:    11/11 passed
Normal regression suite:  27/27 passed
git diff --check:          clean

Latest checkpoint:
5696b89 — Add reusable agent wallet IPC client

Development / test screenshot:

https://www.talkimg.com/images/2026/08/21/U5A5Mz.png

Click image for full-size test output.

Platform clarification — 2026-08-26

The Agent-Safe IPC milestone described in this post is specifically the Unix/Linux AF_UNIX implementation.

Secure Windows Agent-Safe local IPC is NOT currently implemented.

The Windows path remains excluded / fail-closed until a security-equivalent native local-IPC implementation using appropriate Windows identity, ACL and named-pipe controls is implemented and reviewed.

The capability model, authorization artifacts, prepare -> authorize -> submit separation, wallet relocking and anti-replay policy remain architectural parts of Agent-Safe.

This clarification concerns the secure local IPC transport — it is not a claim that the Windows transport already exists.

QProof is still under active development.

This is not a claim that the software is production-ready, and provisional development parameters should not be interpreted as finalized mainnet parameters.

Consensus/security work is deliberately being kept separate from wallet and interface work so UI development does not quietly redefine protocol rules.

The backend work was intentionally done first so desktop interfaces can sit on top of tested wallet and authorization boundaries instead of becoming the place where those security rules are invented.

Built first. Launched later.

[Qproof]

QProof Development Update — Encrypted AI/Application Payload Proof

https://www.talkimg.com/images/2026/08/22/U5ZpzH.png

[o_o] < encrypted QProof transaction > [o_o]

Today QProof hit a fun milestone.

We completed a test-only end-to-end proof showing that structured application data can travel inside QProof's existing encrypted transaction payload while still passing the normal transaction cryptography, serialization and validation path.

For this test:

Sender: Codex
Recipient: Quill

The plaintext was a small structured receipt-style message:

Code:

{"type":"qproof.agent.message.v1","from":"codex","to":"quill","purpose":"receipt","text":"Order 8472 paid. Receipt: https://example.com/r/8472"}

The example schema above is only test data. It is NOT being declared as a permanent QProof application protocol.

https://www.talkimg.com/images/2026/08/22/U5ZDcg.png

What the test exercised:

Code:

AI/application message
        |
        v
ML-KEM encrypted payload
        |
        v
QProof Transaction::payload
        |
        v
canonical signing preimage
        |
        v
ML-DSA transaction signature
        |
        v
transaction validation
        |
        v
canonical serialize / deserialize
        |
        v
intended recipient decrypt

Results:

Code:

Sender: Codex
Recipient: Quill
Plaintext bytes: 144
Encrypted payload: OK
Transaction serialized: OK
Transaction validated: OK
Recipient decrypt: OK
Wrong recipient decrypt: REJECTED
Payload boundary: 512 bytes accepted; 513 bytes rejected

The intended recipient recovered the original 144-byte message exactly.

An unrelated recipient key could not decrypt it.

The transaction ID and authentication hash remained unchanged after serialization/deserialization, and signature verification and transaction validation passed both before and after the round trip.

The URL inside the example message was treated only as opaque application data. Nothing automatically opened or fetched it.

Why this may be useful beyond AI

The encrypted payload does not have to contain an "AI message."

The same bounded field could eventually support ordinary user and merchant workflows such as:

• private receipt or invoice references
• order numbers
• bookkeeping metadata
• warranty or tracking references
• document/content hashes
• application-to-application messages
• authorized AI and machine-to-machine workflows

In other words, a QProof payment could potentially carry some of its own private bookkeeping context along with it.

The blockchain itself does not need to understand what those bytes mean. QProof validates the bounded encrypted payload while wallets and applications decide how to interpret the decrypted data.

The wallet is coming along too:

https://www.talkimg.com/images/2026/08/22/U5Z89b.png

The current desktop wallet is connected to the development node and includes the normal wallet/dashboard flow, transaction preparation, and the Agent-Safe architecture we've been building around explicit human authorization.

Important clarification:

This was a local development proof-of-concept exercising QProof's real encryption, signing, transaction-validation and serialization code.

It was not yet a mined/broadcast on-chain AI message, and QProof is still development software.

A full live-chain demonstration is one of the next steps.

Looking for testers and builders

As the project develops, I'd especially like to hear from:

• AI-agent users interested in machine-to-machine workflow testing
• C++ / Qt developers
• miners and pool operators
• cryptography and security reviewers
• merchant / accounting / wallet integration people
• testers who enjoy finding weird edge cases
• people with strange-but-useful ideas

The idea is to break these things in development before the real world gets a chance to.

"Hello world — but the wrong robot can't read it."

QProof Follow-Up — The Encrypted AI Payload Was Actually Mined

A follow-up to the encrypted AI/application payload proof I posted earlier.

The first test proved that the encrypted payload survived QProof's real transaction cryptography, signing, validation and serialization path.

The next question was obvious:

Can we actually submit it to qproofd, get it into the mempool, mine it into a block, restart the node, recover the transaction from persistent storage, and decrypt the exact same message again?

Answer: yes.

https://www.talkimg.com/images/2026/08/22/U5nw0D.png

Live development-chain test path:

Code:

Codex message
     |
     v
ML-KEM encrypted payload
     |
     v
signed QProof transaction
     |
     v
qproofd sendrawtransaction RPC
     |
     v
mempool acceptance
     |
     v
getblocktemplate
     |
     v
RandomX mining
     |
     v
submitblock
     |
     v
persisted LMDB block
     |
     v
node shutdown / restart
     |
     v
block + transaction recovered
     |
     v
Quill decrypts exact original message

Result:

Code:

QProof LIVE encrypted AI payload test

Sender: Codex
Recipient: Quill

RPC submission: OK
Mempool acceptance: OK
Block mined: OK

Block height: 101
Block hash:
aecf26ff308778ccbe03ea9011ff231305c0c8e057bdf00c333041386ac11cfb

Transaction ID:
f88249c27da648f3ce681a0cb6590097c533deb220e670153cbbd12732b99a92

Transaction recovered from block: OK
Recipient decrypt: OK
Wrong recipient decrypt: REJECTED
Node restart/recovery: OK

After the node was restarted:

• chain height recovered at 101
• the recovered tip matched the mined block
• the persisted block was found again
• the same transaction was found again
• transaction ID, authentication hash and canonical transaction bytes were unchanged
• the intended recipient decrypted the exact original 144-byte message again
• the unrelated key still could not decrypt it

Recovered message:

Code:

{"type":"qproof.agent.message.v1","from":"codex","to":"quill","purpose":"receipt","text":"Order 8472 paid. Receipt: https://example.com/r/8472"}

The URL is just test data. Nothing automatically opened or fetched it.

What changed from the previous demo?

This was no longer just an in-memory transaction round trip.

The test used:

• a real isolated qproofd process
• real RPC transport
• real mempool admission
• real block-template selection
• real RandomX proof-of-work
• real block submission
• real LMDB persistence
• an actual node restart and chain recovery

It was still a disposable local development chain, not public mainnet.

But the encrypted payload really did make the trip:

message -> transaction -> mempool -> mined block -> disk -> restart -> decrypt

That opens up some interesting possibilities beyond AI as well:

• private receipt references
• invoice/order metadata
• bookkeeping context
• warranty/tracking references
• document hashes
• application-to-application messages
• machine-to-machine payment workflows

The blockchain does not have to understand the application message itself. It only carries and validates the bounded encrypted payload.

Looking for people who want to kick the tires

AI-agent users, C++/Qt developers, miners, pool operators, security reviewers, merchant/accounting people and creative testers are welcome.

I'm especially interested in people who can think of legitimate weird uses for a small encrypted payload attached to a payment — and people who enjoy trying to break systems before users do.

[o_o] < encrypted payload < mined block < restart > decrypted payload > [o_o]

"Hello world — but the wrong robot still can't read it."

[Qproof]

QProof Development Update — Decentralized P2Pool Sharechain Foundation

QProof has now reached another P2Pool milestone.

The decentralized sharechain foundation is implemented and checkpointed.

Live Development Test

Live testing on the QProof node confirmed:

• Two separate qproof-p2pool processes established a sharechain peer connection.
• Mining through the second pool successfully produced an accepted QProof block.
• The node advanced from height 274 to 275.
• The existing node and original pool were left running independently during testing.

Current Sharechain Foundation

The current layer includes:

• Parent-linked proof-of-work shares
• Independent share difficulty
• Bounded peer synchronization
• Share gossip
• Fork-aware cumulative-work selection
• Reconnect / resynchronization behavior

This is still foundation work.

Payout accounting, PPLNS, persistence, discovery, and the broader multi-pool architecture are intentionally being kept separate until the core sharechain is hardened.

Development Evidence

https://www.talkimg.com/images/2026/08/24/U5PTE8.png

https://www.talkimg.com/images/2026/08/24/U5PRAZ.png

https://www.talkimg.com/images/2026/08/24/U5P68f.png

Decentralized pool foundation: checkpointed and live-tested.


QProof Development Update — 8-Hour P2P Soak + Encrypted Payload Stress Testing

Another long-duration QProof validation checkpoint is complete.

8-Hour IPv4 P2P Soak

The IPv4 P2P soak ran continuously for approximately 8 hours and completed:

Code:

PASS rounds=6179 Mon Aug 24 10:33:51 AM EDT 2026

That is 6,179 complete test rounds.

Each round repeatedly exercised:

• Initial peer connection and block propagation
• Repeated peer churn
• Restart while behind and catch-up
• Disconnect -> persistent restart -> reconnect -> catch-up
• Competing-chain / fork handling
• Persisted competing branches and active-chain selection
• Thread and file-descriptor lifecycle checks

Final round result:

Code:

SOAK IPv4 linear PASS lifecycle-phases=4 churn-cycles=8 blocks=12
SOAK IPv4 fork PASS active-height=3 persisted-branches=2
SOAK IPv4 ALL PASS

The soak controller exited naturally and no soak-test process remained running.

A separate Windows Mini was used as a remote observer during the run, watching the Linux host for round progress, controller state, active tests, memory use and failure markers.

Encrypted Application Payload Stress Testing

The encrypted transaction-payload work also moved beyond the earlier single-message demonstration.

At this checkpoint the stress slice exercised 20 distinct encrypted application-payload transactions, each using the then-current 512-byte maximum plaintext payload size.

The path exercised was:

Code:

distinct 512-byte payload
        |
        v
encrypt
        |
        v
signed QProof transaction
        |
        v
RPC submission
        |
        v
mempool
        |
        v
block template
        |
        v
RandomX mining
        |
        v
block acceptance
        |
        v
LMDB persistence
        |
        v
node restart / recovery
        |
        v
payload recovered and decrypted

The stress coverage explicitly checked the payload boundary:

Code:

512-byte payload: accepted
513-byte plaintext: rejected
513-byte ciphertext through RPC: rejected
wrong-recipient decrypt: rejected
node restart/recovery: verified

The purpose here is not to define an application protocol for the blockchain.

QProof treats the encrypted payload as bounded application data.

Wallets, merchants, authorized agents or other applications may eventually decide what the decrypted bytes mean.

The important part for the chain is that bounded encrypted data survives the normal transaction, mempool, mining, persistence and recovery path without creating an alternate validation path.

Evidence Preservation

After the P2P soak completed, the full soak log, final status, watcher script and final completion snapshot were archived.

The preserved evidence was SHA-256 checked:

Code:

qproof-mini-watch.sh: OK
qproof-overnight-soak.log: OK
qproof-overnight-soak.pid: OK
qproof-overnight-soak.status: OK
final-snapshot.txt: OK

This is still development software.

This is not a mainnet-readiness claim.

The objective remains to exercise failure cases before launch: disconnect peers, restart nodes, force catch-up, compete forks, push bounded payloads to their limits, persist them, recover them, and keep running long enough for lifecycle bugs to have a chance to appear.

8 hours. 6,179 P2P rounds. Payload boundaries exercised. Keep testing.

Built first. Launched later.


QProof Development Update — Windows + Linux Portable Validation

Another QProof portability checkpoint was completed.

At this historical checkpoint, the portable build/test harness had been exercised successfully on:

• Windows 11 x86_64
• Ubuntu 26.04 LTS x86_64

Results at that checkpoint were:

Code:

Windows 11 x86_64:      9/9 portable tests PASS
Linux x86_64:           9/9 portable tests PASS
Linux portable build:   98/98 build steps completed

The portable harness exercises actual QProof components rather than a stub-only compatibility layer.

Validated targets included:

• qproofd
• QProof miner
• qproof-p2pool
• external reference miner
• platform/socket handling
• endpoint parsing
• core protocol behavior
• canonical serialization
• subsidy rules
• RandomX proof-of-work
• address handling
• wallet functionality
• LMDB node database behavior

Linux Validation Environment

Code:

OS:       Ubuntu 26.04 LTS x86_64
CPU:      Intel Core i9-9880H
Cores:    8 / 16 threads
RAM:      76 GiB
Compiler: GCC/G++ 15.2.0
CMake:    4.2.3
Ninja:    1.13.2
OpenSSL:  3.5.5
liboqs:   0.16.0
LMDB:     0.9.31

The Linux validation was performed in an isolated worktree so the active QProof development/runtime environment did not need to be disturbed.

What This Did — and Did Not — Prove

The same portable test sources contained fixed serialization, genesis, transaction/hash, Merkle-root, difficulty and RandomX vectors used by both Windows and Linux.

At this point in the development timeline I was not yet calling the dedicated cross-platform deterministic comparison finished.

That work was completed afterward and is recorded in the supersession note below.

macOS and Android/arm64 validation were also still pending at this checkpoint.

This was portability evidence — not a production or mainnet-readiness claim.

Historical checkpoint:

Code:

Windows: 9/9
Linux:   9/9

Built first. Launched later.


QProof Development Update — Cross-Platform Validation + Future PoW Preparedness

Another QProof readiness checkpoint followed.

This work focused on two things that are easy to postpone until they become painful:

• proving that the portable QProof boundary builds and runs on more than one operating system
• preparing the proof-of-work architecture so QProof is not permanently boxed into one algorithm implementation

Windows + Linux Portable Validation

At that checkpoint the current portable build/test harness was running successfully on:

• Windows 11 x86_64
• Ubuntu 26.04 LTS x86_64

The then-current result remained:

Code:

Windows 11 x86_64:      9/9 portable tests PASS
Linux x86_64:           9/9 portable tests PASS
Linux portable build:   98/98 build steps completed

The portable harness used actual QProof components rather than a separate mock implementation.

Validated targets included:

• qproofd
• QProof miner
• qproof-p2pool
• external reference miner
• platform/socket handling
• endpoint parsing
• core protocol behavior
• canonical serialization
• subsidy rules
• RandomX proof-of-work
• address handling
• wallet functionality
• LMDB node database behavior

Cross-Platform Determinism

The same portable test sources contain fixed vectors covering deterministic behavior including:

• serialization
• genesis
• transaction/hash behavior
• Merkle roots
• difficulty calculations
• RandomX proof-of-work

Both Windows and Linux were passing the suite available at that stage.

A dedicated expanded deterministic comparison was still the next step at the time this section was originally posted.

That step has since been completed — see the supersession below.

Future Proof-of-Work Algorithm Preparedness

A separate architecture-readiness change was completed to avoid permanently hard-wiring QProof to a single proof-of-work implementation.

RandomX remains the current and only active QProof proof-of-work algorithm.

The change introduced a narrow algorithm-dispatch boundary so a future PoW algorithm could be added deliberately without first dismantling the existing RandomX validation path.

Current behavior remains:

Code:

Algorithm 0: RandomX — supported / active
Other algorithm IDs: rejected

Compatibility coverage verifies that:

• existing RandomX behavior is preserved
• the algorithm-dispatch path reaches the same RandomX implementation
• unsupported algorithm identifiers fail closed
• no unimplemented second algorithm is accidentally accepted

No second proof-of-work algorithm has been activated.

What Did NOT Change

This preparedness work did not change:

• current RandomX proof-of-work behavior
• block-header serialization
• genesis
• current monetary rules
• current difficulty semantics
• P2Pool economics
• the current active mining algorithm

This is architectural preparedness — not a multi-algorithm launch announcement.

If another proof-of-work algorithm is ever introduced, it will still require its own:

• specification
• activation/version rules
• difficulty handling
• chain-work treatment
• deterministic test vectors
• cross-platform verification
• miner support
• P2Pool integration review
• consensus/security testing

Nothing becomes valid network work merely because a dispatcher exists.

Why Do This Now?

Some future changes are much safer when the architectural seam exists before it is urgently needed.

The goal is to preserve today's tested RandomX behavior while giving QProof a controlled path to evolve later if cryptography, hardware, mining economics or security requirements change.

That same philosophy is being applied across the project:

keep today's consensus narrow, but avoid unnecessary architectural dead ends.


2026-08-26 Portability Supersession

The 9/9 Windows and 9/9 Linux figures above are intentionally retained because they were the correct results for those historical checkpoints.

The portable deterministic suite was subsequently expanded through QPVECTOR10.

Current validated result:

Code:

Windows / MSVC: 10/10 PASS
Linux / GCC:    10/10 PASS
QPVECTOR10:     PASS

The expanded harness continues to exercise real QProof protocol/consensus, wallet, endpoint/network-client, LMDB node-core, qproofd, mining, P2Pool and reference-miner components.

RandomX remains the only active proof-of-work algorithm.

No fake or placeholder second algorithm has been activated.

Full macOS portable validation is still incomplete.

Legacy macOS compatibility work has been merged, but that is not being presented as complete macOS platform validation.

Android / GrapheneOS arm64 NDK validation is also still incomplete.

Windows secure Agent-Safe IPC is outside the Windows portable harness and remains unimplemented / fail-closed pending a security-equivalent Windows transport.

This remains portability/readiness evidence.

It is NOT:

• a production-readiness claim
• a security-audit completion claim
• a public-testnet readiness claim
• a mainnet-readiness claim

Windows: 10/10.
Linux: 10/10.
QPVECTOR10: PASS.
RandomX today.

Built first. Launched later.

[Qproof]

QProof Development Update — Fleet Closure + Pre-Freeze Validation

A fairly large QProof validation/cleanup pass is now complete.

This one was mostly about doing the boring work before starting another feature phase:

• reconcile the public development record
• retire old test runtime cleanly
• align the three-machine test fleet
• investigate a historical Windows mining failure regime
• reproduce the current mining path from fresh code
• run another current-head verification pass
• fix what testing actually found instead of explaining it away

Public specification cleanup

The QProof thread OP has been updated to match the current pre-freeze design.

The canonical human-facing ticker is now:

QPF

Older QPR references remain in historical posts where they were accurate at the time.

The current OP also now reflects:

• 120-second target spacing
• per-block genesis-anchored ASERT after the three-block bootstrap
• 4-hour ASERT half-life
• 25 QPF starting subsidy
• floor(previous × 4/5) subsidy epochs
• permanent 1 QPF tail
• zero premine / founder / developer allocation
• current mainnet object explicitly described as a provisional development genesis
• merge-mining v1 recognized but inactive
• Windows secure Agent-Safe IPC explicitly not implemented / fail-closed

The point of that cleanup was to stop old development-era wording from looking like current consensus policy.

Current cross-platform checkpoint

The expanded portable deterministic suite currently reports:

Code:

Windows / MSVC: 10/10 PASS
Linux / GCC:    10/10 PASS
QPVECTOR10:     PASS

The harness exercises real QProof protocol/consensus and runtime components rather than maintaining a separate compatibility mock.

macOS full portable validation and Android/arm64 NDK validation remain unfinished.

RandomX remains the only active proof-of-work algorithm.

Three-machine fleet review

The recent fleet consisted of:

• Linux Lappy2 — qproofd / P2Pool / integration host
• Windows Lappy1 — external reference-miner lane
• Windows Mini — observer / independent secondary machine

Historical Lappy2 evidence included:

Code:

8-hour long-soak window
23 integration gates
7 recovery restarts
6179 older IPv4 soak PASS rounds
39/39 Release checkpoint tests
39/39 Debug checkpoint tests

The Mini observer recorded:

Code:

393 observations
393 RUNNING
0 explicit failed/down/dead
0 ERROR/FATAL/CRASH

All known runtime from that exercise was deliberately retired afterward rather than being left around and confused with later tests.

Historical Windows miner anomaly

The interesting part was Lappy1.

The old long-running miner controller produced substantial valid work and then entered a sharply different degraded/rejection regime.

Historical evidence:

Code:

starts:              40,319
accepted:            20,646
explicit rejected:   15,062
EXIT=0:              20,646
EXIT=1:              19,673

The last accepted / EXIT=0 result was around 21:13 EDT on August 25.

The old logs did not establish a root cause.

Rather than pick a favorite theory, I rebuilt the Windows reference miner from fresh aligned current foundation code and repeated the node -> P2Pool -> Windows miner path.

One-shot result:

Code:

mining.result status=accepted
exit=0

Then a bounded 100-run churn reproduction:

Code:

runs=100
accepted-runs=100
stale-runs=0
rejected-runs=0
nonzero-exits=0
no-accepted-runs=0

So:

The historical degraded/rejection regime did NOT reproduce under the fresh aligned current node -> P2Pool -> Windows reference-miner path.

That clears the reproduction task.

It does NOT identify the historical root cause, and I'm not assigning one without evidence.

Latest current-head verification

After the fleet work was closed, I ran another current Linux verification before this post.

Release:

Code:

65/65 tests PASS

The Debug suite found one repeatable failure in the live encrypted application-payload integration test during node restart.

The failure occurred while waiting for RPC readiness.

Rather than increasing the timeout immediately, I preserved the failed test database and manually restarted the Debug qproofd against it.

The preserved database recovered successfully.

Measured full RPC readiness:

Code:

first Debug start:          ~8190 ms
immediate same-port restart: ~8040 ms

Both processes remained healthy.

The integration test's readiness loop only allowed 100 polling attempts with a 50 ms sleep between attempts, which was too short for this Debug startup/recovery workload.

The test-only allowance was increased from:

Code:

100 attempts

to:

Code:

400 attempts

No consensus, wallet, networking, storage or cryptographic production behavior was changed.

The exact previously failing test was rebuilt and rerun:

Code:

qproof_live_encrypted_ai_payload_tests: PASS
Test time: 25.95 sec

The test-only fix is checkpointed as:

Code:

e718707 — Relax live payload RPC readiness timeout

I have not rerun the entire Debug suite after that one-line test-harness change, so I'm not claiming a new full 62/62 Debug result here.

What I can claim is narrower:

• Release current-head run: 65/65 PASS
• Debug failure reproduced and isolated
• preserved node database recovered successfully
• same-port restart worked
• root cause of this Debug test failure was insufficient test readiness allowance
• exact previously failing test now passes

P2Pool status remains deliberately bounded

The decentralized P2Pool sharechain foundation remains working and tested:

• parent-linked PoW shares
• independent share target
• cumulative-work fork choice
• share synchronization/gossip
• reconnect/resync
• Stratum external miners
• real QProof block submission

Production payout accounting, PPLNS rules, persistent sharechain storage and public discovery remain separate unfinished work.

Where this leaves QProof

This closes the current cleanup/reproduction phase.

It does NOT mean:

• production ready
• security audited
• hostile-network hardened
• public-testnet ready
• final genesis selected
• P2Pool economics finalized
• mainnet ready

The next hardening work is intentionally less glamorous:

hostile-network / resource-exhaustion resistance

followed by long-lived storage/LMDB lifecycle hardening and additional adversarial testing.

Still trying to make the boring failures happen here instead of after launch.

Built first. Launched later.