Falcon
Falcon is Tidecoin’s original post-quantum signature family. Falcon-512 has secured mainnet since genesis, and Falcon-1024 is implemented for the post-AuxPoW ruleset. Falcon gives Tidecoin compact post-quantum signatures compared with most lattice signature schemes, which matters because every spend carries a public key and signature on chain.
This page explains the Falcon schemes and their implementation tradeoffs. For the canonical prefix registry, see Scheme Registry. For byte-level transaction encoding, see Signature Encoding.
Activation status
| Scheme | Prefix | Mainnet status | Activation rule | Security category |
|---|---|---|---|---|
| Falcon-512 | 0x07 | Live since genesis | Always allowed | 1 |
| Falcon-1024 | 0x08 | Built, not active on mainnet | Allowed at and after AuxPoW activation | 5 |
Before AuxPoW activation, consensus only allows Falcon-512. At and after the configured AuxPoW activation height, Tidecoin’s scheme gate allows all known schemes: Falcon-512, Falcon-1024, ML-DSA-44, ML-DSA-65, and ML-DSA-87.
Sizes
| Parameter | Falcon-512 | Falcon-1024 |
|---|---|---|
| Public key bytes | 897 | 1,793 |
| Public key bytes in script | 898 | 1,794 |
| Secret key bytes | 1,281 | 2,305 |
| Maximum signature bytes | 752 | 1,462 |
| Padded signature bytes | 666 | 1,280 |
| Script signature bytes, padded plus sighash | 667 | 1,281 |
Tidecoin serializes the scheme prefix with the public key. The signature itself is verified according to the scheme selected by that prefixed public key. In standard script spend paths, one extra byte is present for the sighash type.
Construction
Falcon is a hash-and-sign lattice signature scheme over NTRU lattices. Its public key is an NTRU-style value derived from short secret polynomials, and signing uses a GPV-style sampling framework.
At a high level:
- Key generation samples short polynomials, computes the public NTRU relation, and keeps a short secret basis for signing.
- Signing samples a 40-byte nonce, hashes the nonce and message into a lattice target, and uses fast Fourier sampling to produce a short signature vector.
- Verification recomputes the target from the nonce and message, recovers the corresponding vector component from the public key, and checks that the signature norm is within the allowed bound.
Falcon’s advantage is size. Its cost is implementation complexity: signing involves Gaussian-style sampling and traditionally uses floating-point arithmetic.
Integer-emulated implementation
Tidecoin uses the PQClean clean Falcon implementation with integer emulation for floating-point operations. This avoids depending on native C floating-point behavior for signing and keeps the implementation closer to constant-time expectations across platforms.
The tradeoff is performance. Integer-emulated Falcon signing is slower than a native floating-point implementation, but the smaller signature and public-key sizes are valuable for on-chain use.
Legacy and strict verification
Falcon-512 has a legacy verification mode because it has been live since
genesis. Legacy mode preserves the historical acceptance rule for
pre-AuxPoW spends. Strict mode uses the standard PQClean verification
path and is enabled by SCRIPT_VERIFY_PQ_STRICT at AuxPoW activation.
The key point: keys do not migrate. Public and private key formats remain the same. What changes is which signatures a new spend may use under the active consensus flags.
See Verification Modes for the exact flag boundary.
Falcon formats
Falcon supports multiple internal signature encodings:
| Format | Code | Size behavior | Tidecoin relevance |
|---|---|---|---|
| Compressed | 1 | Variable length | Current Falcon-1024 signing path uses the compressed PQClean API. |
| Padded | 2 | Fixed 666 bytes for Falcon-512, 1,280 bytes for Falcon-1024 | Used as the fixed-size verification target. |
| Constant-time | 3 | Fixed larger representation | Relevant to implementation analysis, not the normal on-chain size target. |
Falcon-512 legacy signatures use the legacy Falcon header byte 0x39.
Falcon-1024 has the corresponding header byte 0x3A.
FN-DSA compatibility note
Falcon is the NIST PQC winner standardized as FN-DSA. Tidecoin’s current implementation follows the PQClean Falcon implementation used by the node. Future FN-DSA naming or encoding changes should not be treated as automatic wire-format changes for Tidecoin. Any consensus-visible change must be explicitly gated and documented.
Sampler bug history
The public Falcon ecosystem had a known sampler bug before Tidecoin genesis. Tidecoin uses the post-fix PQClean implementation, and Falcon-512 has been the live mainnet signature scheme since December 27, 2020.
Source of truth
| Topic | Source |
|---|---|
| Scheme prefixes, key sizes, signature sizes, activation gate | ../tidecoin/src/pq/pq_scheme.h |
| Falcon-512 API constants | ../tidecoin/src/pq/falcon-512/api.h |
| Falcon-1024 API constants | ../tidecoin/src/pq/falcon-1024/api.h |
| Wallet signing and public-key verification dispatch | ../tidecoin/src/key.cpp, ../tidecoin/src/pubkey.cpp |
| Whitepaper rationale and cryptographic background | ../tidecoin/doc/whitepaper.md |
See also: ML-DSA, Scheme Registry, Signature Encoding, Verification Modes.