Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
37 changes: 16 additions & 21 deletions bip-0360.mediawiki
Original file line number Diff line number Diff line change
Expand Up @@ -622,47 +622,41 @@ using P2QRH outputs.
== Security ==

{| class="wikitable"
|+ Candidate quantum-resistant signature algorithms ordered by largest to smallest NIST Level V signature size
|+ Candidate quantum-resistant signature algorithms ordered by largest to smallest
|-
! Signature Algorithm !! Year First Introduced !! Signature Size !! Public Key Size !! Cryptographic Assumptions
! Algorithm !! Year Introduced !! NIST Level !! Signature Size !! Public Key Size !! Cryptographic Assumptions
|-
| [https://en.wikipedia.org/wiki/Lamport_signature Lamport signature] || 1977 || 8,192 bytes || 16,384 bytes ||
| [https://en.wikipedia.org/wiki/Lamport_signature Lamport signature] || 1977 || - || 8,192 bytes<ref name="lamport-calc">Calculated assuming a 256-bit hash function which results in a public key of 2*256*256/8=16,384 bytes and a signature of 256*256/8=8,192 bytes.</ref> || 16,384 bytes ||
Hash-based cryptography
|-
| [https://eprint.iacr.org/2011/191.pdf Winternitz signature] || 1982 || 2,368 bytes<ref name="winternitz">Winternitz
signatures are much smaller than Lamport signatures due to efficient chunking, but computation is much higher,
especially with high values for w. Winternitz values are for w of 4. It's worth noting that Winternitz signatures can
only safely be used one time per public key. If addresses are reused, private key information might be leaked, allowing
attackers to spend future outputs assigned to the same address.</ref> || 2,368 bytes || Hash-based cryptography
| [https://sphincs.org/data/sphincs+-r3.1-specification.pdf SPHINCS+ Rd. 3.1 (FIPS 205 - SLH-DSA - SHAKE-128s)] || 2015 || 1 || 32 bytes || 7,856 bytes || Hash-based cryptography
|-
| [https://sphincs.org/data/sphincs+-r3.1-specification.pdf SPHINCS+ Rd. 3.1 (FIPS 205 - SLH-DSA)] || 2015 || 29,792
bytes || 64 bytes || Hash-based cryptography
| [https://eprint.iacr.org/2011/191.pdf Winternitz OTS] || 1982 || - || 2,144 bytes<ref name="winternitz-calc">Winternitz OTS requires signing both the message digest and a checksum on the message. Assuming a 256-bit hash function and w=16 (chunk size), we get a signature on the message digest consisting of 256/log2(16) = 64 hashes and a signature on the checksum consisting log2(256/log2(16)*log2(16-1))/log2(16)+1=2.99 which rounded up is 3 hashes. This results in a combined signature size of (64+3)*256/8 = 2144-bytes. The WOTS public key is the same size as the signature.</ref> || 2,144 bytes || Hash-based cryptography
|-
| [https://eprint.iacr.org/2011/484.pdf XMSS]<ref name="xmss">XMSS, which is based on Winternitz, uses a value of 108
for its most compact signature size, with only a 4.6x (2.34/0.51) increase in verification time. Signing and key
generation are not considered a significant factor because they are not distributed throughout the entire Bitcoin
network, which take place only inside of wallets one time.</ref> || 2011 || 15,384 bytes || 13,568 bytes ||
network, which take place only inside of wallets one time.</ref> || 2011 || - || 15,384 bytes || 13,568 bytes ||
Hash-based cryptography (Winternitz OTS)
|-
| [https://pq-crystals.org/dilithium/ CRYSTALS-Dilithium (FIPS 204 - ML-DSA)] || 2017 || 4,595 bytes || 2,592 bytes ||
| [https://pq-crystals.org/dilithium/ CRYSTALS-Dilithium (FIPS 204 - ML-DSA)] || 2017 || 2 || 1,312 bytes || 2,420 bytes ||
Lattice cryptography
|-
| [https://eprint.iacr.org/2014/457.pdf pqNTRUsign] || 2016 || 1,814 bytes || 1,927 bytes || Lattice cryptography (NTRU)
| [https://eprint.iacr.org/2014/457.pdf pqNTRUsign] || 2016 || - || 1,814 bytes || 1,927 bytes || Lattice cryptography (NTRU)
|-
| [https://falcon-sign.info FALCON (FIPS 206 - FN-DSA)] || 2017 || 1,280 bytes || 1,793 bytes || Lattice cryptography
| [https://falcon-sign.info FALCON (FIPS 206 - FN-DSA)] || 2017 || 1 || 897 bytes || 666 bytes || Lattice cryptography
(NTRU)
|-
| [https://eprint.iacr.org/2022/1155.pdf HAWK] || 2022 || 1,261 bytes || 2,329 bytes || Lattice cryptography
| [https://eprint.iacr.org/2022/1155.pdf HAWK] || 2022 || 1 || 1,024 bytes || 555 bytes || Lattice cryptography
|-
| [https://sqisign.org SQIsign] || 2023 || 335 bytes || 128 bytes || Supersingular Elliptic Curve Isogeny
| [https://sqisign.org SQIsign] || 2023 || 1 || 65 bytes || 148 bytes || Supersingular Elliptic Curve Isogeny
|-
| [https://eprint.iacr.org/2024/760.pdf SQIsign2D-West] || 2024 || 294 bytes || 130 bytes || Supersingular Elliptic
Curve Isogeny
|-
| [https://eprint.iacr.org/2023/436.pdf SQIsignHD] || 2023 || 109 bytes (NIST Level I) || Not provided ||
Supersingular Elliptic Curve Isogeny
|}

Lamport and Winternitz OTS signatures can only securely be used one time per public key. If a one time signature scheme is
used more than once, an attacker can forge a signature for a different message. Winternitz signatures have smaller
public keys and signatures than Lamport signatures but require more computation to sign and verify.

As shown, supersingular elliptic curve quaternion isogeny signature algorithms represent the state of the art in
post-quantum cryptography, beyond lattice cryptography alone, especially when key and signature length are major
constraints. This makes inclusion of SQIsign attractive, however its performance is roughly 100,000 times slower than ECC,
Expand Down Expand Up @@ -714,6 +708,7 @@ seeds to act as the authoritative secret when signing. These measures are deemed

To help implementors understand updates to this BIP, we keep a list of substantial changes.

* 2025-07-20 - Updates PQ Signature Table
* 2025-03-18 - Correct inconsistencies in commitment and attestation structure. Switch from merkle tree commitment to sorted vector hash commitment. Update descriptor format.
* 2025-03-12 - Add verification times for each algorithm. 256 -> 128 (NIST V -> NIST I). Add key type bitmask. Clarify multisig semantics.
* 2025-02-23 - More points of clarification from review. Update dead link.
Expand Down