Hi everyone,
I’m not a well-known contributor and I struggle with social skills, but several people suggested I share what I’ve been working on. I’m a hobbyist who has been building custom hash functions since the late 90s. In 2018 I experimented with base64 media hashes for a portable mesh network, then moved to IBS and built a working portable hashnet (PvtPpr-Newschains). Since 2022 I’ve been developing SPX , a three-part system for hashing, transferring, and heavily compressing data on deterministic systems using generatable lookup tables.
More recently I started exploring NIST picks for Post-Quantum Cryptography (PQC), to use for my own projects (including self-verifying coins for a Python game). I’ve been building practical pipelines that move from classical cryptography → hybrid-PQC → full PQC, with the ability to increase the “entropy envelope” simply by changing parameters. My system was made for a game and is not hardened like what would be needed but the process and results are still valid and worth reviewing for implementation refrence.
Below are two main concepts I’ve implemented (using public code references), plus the design principles I follow.
These are the rules I try to follow when creating outputs intended to be quantum-resistant:
- Decouple input from seed , Keep the original seed isolated.
- Use semi-orchestrated, well-distributed seed field generation, the seed is very important to be well distributed.
- Handle checksums with domain-separated techniques (e.g., sideways projection via double-SHAKE256) instead of relying only on classical methods.
- Move transaction-style processing toward Pedersen commitment templates with batch return/change addressing via OP_RETURN across multiple layers, while still returning change cleanly.
- Use hybrid master key material to enable a smooth transition: classical → PQC → Quantum-Resistant Crypto → (hypothetically) higher-range QRC.
- Focus on processing, output lengths, and setup more than classical vs PQC math differences.
- Explore Bulletproof-style template handling for Pedersen commitments.
- Role-based key systems appear to be one of the stronger practical levers for quantum resistance. Variant roles + multi-role signing could enable cryptographic DRM-like controls and signature-activated permissions.
- View keys through roles and verify via byte offset (using unused portions of the PQC hybrid public string for checksum/proof verification), a lightweight way to get quick verification data without leaking private material.
- No-secret derived role keys could enable verifiable key points or view-key functionality.
Most of these are just different processes. The underlying math isn’t radically different, (to a degree) it’s the orchestration that matters.
1. Manipulating SPHINCS+: Usable Key Material
The process uses heavily reduced custom SPHINCS+ parameters (tree height H=1, D=1, minimal Winternitz parameters, etc.). This produces very small signatures (~105 bytes). We extract the first 105 bytes (using the first ~93 bytes) and treat that slice as key material.
We then run it through domain-separated SHAKE-256 reduction to produce a 20-byte payload, from which we derive:
- Standard Bitcoin-style base58 addresses (double-SHA256 checksum)
- “PQ-style” base58 addresses using double-SHAKE256 checksum instead
It also supports simple role-based derivation (roles 0-9) from the same master material without elliptic curves.
Important disclaimers:
- This is not a cryptanalytic break of SPHINCS+. It is deliberate parameter reduction that significantly lowers the security level in exchange for tiny, embeddable outputs.
- The repository explicitly states it is example/discussion code only , do not use it with real funds or keys.
- The intent is to demonstrate migration patterns and hybrid derivation techniques that can later be upgraded by simply swapping in stronger parameter sets from custom_params.h.
This approach uses a hybrid signing flow (hybrid outer layer + PQC inner material) which can use an inverse (PQC putter Material + Hybrid or Classical inner layer). Both works conceptually with Kyber or Falcon as well.
Note: I have used the proposed system with the BCH Pipeline repo to generate bch addresses that can accept payments today but have a spend key that isn’t usable today. I do not recommend others doing this but perhaps playing with my hybrid signing method which attempts signing to PQC, maybe someone can find the best way.
2. PQCAssets: Layered Signed Containers (“PQC Folders")
PQCAssets wraps files or entire folders into signed .pqcasset containers. It supports Falcon , SPHINCS+ , or hybrid signatures. You can optionally add password-based encryption (strong KDF + symmetric cipher).
Key features:
- Nested manifests that can store references to derivation material (including the SPHINCS+ 93/105-byte slice) for controlled unlocking of later layers.
- Clean separation between the “unlock/derivation material” and the actual signing keys.
- Support for splitting containers, verification, and extraction.
- The SPHINCS+ slice can act as a portable derivation source or unlock token for nested layers without weakening the underlying Falcon or full SPHINCS+ keys (when used correctly [I say this because there’s a way to intentionally break Falcon with the SPHINCS+ 93-Material).
Potential uses:
- Contracts or layered data packages where base consensus rules live in one layer and extended rules live in outer layers.
- Passing private or access-controlled data over public channels via manifests.
- Split-consensus systems or cryptographic permission structures using role-based signing.
Security note: When using the SPHINCS+ slice for derivation, do not use the exact same material both as an unlock token and for key derivation in the same container. Proper key separation is maintained in the current implementation.
Relevance to Bitcoin Cash
These experiments may be useful to the current PQC discussions:
- Hybrid address derivation examples (base58 with alternative checksums) that could be adapted toward CashAddr-style or future PQC address formats.
- Role-based key hierarchies that don’t rely solely on elliptic curve math, potentially interesting alongside covenant/script-based approaches.
- Manifest + OP_RETURN patterns for embedding PQC metadata, derivation references, or layered proofs.
- Lightweight verification tricks (byte-offset proofs, role views) that might complement heavier on-chain PQC signatures.
- Concrete code showing a clean pipeline from today’s cryptography to future PQC that could help with transition planning (complements work like CHIP-2026-06 on hybrid/PQ signatures and Quantumroot-style vaults).
The heavy compression and deterministic generation aspects might also help keep on-chain data sizes manageable when PQC signatures are eventually used.
Repositories
All code is public:
- https://github.com/DigiMancer3D/sphincs-btc-pipeline (SPHINCS+ manipulation + address derivation)
- …/DigiMancer3D/sphincs_bch_hybrid (referenced bch key creation)
- https://github.com/DigiMancer3D/PQCAssets (layered containers + hybrid signing)
Thank you for reading, I may not have the skills to explain things but I am going to still try to answer questions you may have. Keep In Mind: My public versions are reference code for reference material. My versions are intended to use real public keys to prove value for video game play and not real spending so there are techniques in the repos I reference (my repos by the way) that seem odd becasue they are intended to be odd. I really look forward to hearing from you all on this input even if improper and unusual.
--3D (DigiMancer3D)