From: scott beeker <devbythebay2@gmail•com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: [bitcoindev] Hardforking Bitcoin to SLH-DSA (Future Proofing)
Date: Wed, 16 Oct 2024 17:45:29 -0700 (PDT) [thread overview]
Message-ID: <0e40068e-6840-49a2-a800-a1f34a0ad9ccn@googlegroups.com> (raw)
[-- Attachment #1.1: Type: text/plain, Size: 4548 bytes --]
Hardforking Bitcoin to SLH-DSA
Bitcoin's transition to a post-quantum cryptographic algorithm like SLH-DSA
(Stateless Hash-Based Digital Signature Algorithm) would be a significant
and complex undertaking. Here's an analysis of the potential process and
implications:
Motivation for the Transition
The primary reason for considering a transition to SLH-DSA would be to
protect Bitcoin against potential threats from quantum computers. While
quantum computers capable of breaking Bitcoin's current elliptic curve
cryptography are not yet a reality, the cryptocurrency community is
increasingly aware of the need to prepare for this eventuality.
Technical Aspects of the Transition
Signature Scheme Replacement
The current Bitcoin protocol uses the Elliptic Curve Digital Signature
Algorithm (ECDSA) for transaction signatures. Replacing this with SLH-DSA
would require substantial changes to the core protocol[1].
Key and Signature Sizes
One of the main challenges in implementing SLH-DSA for Bitcoin would be
dealing with the increased key and signature sizes:
Algorithm
Public Key Size
Signature Size
ECDSA
33 bytes
71-73 bytes
SLH-DSA
32-64 bytes
7,856-49,216 bytes
The significantly larger signature sizes of SLH-DSA would have implications
for block size, transaction throughput, and network bandwidth
requirements[1].
Performance Considerations
SLH-DSA is known for its strong security properties but comes with
performance costs. It has longer signing times compared to ECDSA, which
could affect transaction processing speeds[1].
Implementation ChallengesConsensus Changes
Implementing SLH-DSA would require a hard fork of the Bitcoin network, as
it involves fundamental changes to the consensus rules. This would need
widespread agreement among miners, node operators, and users.
Backward Compatibility
The transition would need to address backward compatibility issues,
potentially requiring a period where both ECDSA and SLH-DSA signatures are
supported to allow users time to migrate their funds to new addresses.
Wallet Software Updates
All Bitcoin wallet software would need to be updated to support the new
signature scheme, including key generation, signing, and verification
processes.
Potential BenefitsQuantum Resistance
The primary benefit would be Bitcoin's resistance to attacks from quantum
computers, ensuring the long-term security of the network[1].
Conservative Security Approach
SLH-DSA is considered a conservative choice for post-quantum cryptography,
as it relies on the well-studied security of hash functions rather than
newer mathematical problems like lattices[1].
Potential DrawbacksIncreased Resource Requirements
The larger signature sizes would increase the storage and bandwidth
requirements for running Bitcoin nodes, potentially leading to increased
centralization.
Transaction Costs
Larger signatures could result in higher transaction fees, as more
blockchain space would be required for each transaction.
Complexity
The transition process itself would be complex and risky, potentially
introducing vulnerabilities if not executed correctly.
Conclusion
While transitioning Bitcoin to SLH-DSA is technically possible, it would be
a monumental undertaking requiring extensive planning, testing, and
community consensus. The cryptocurrency community would need to carefully
weigh the long-term security benefits against the short-term disruption and
increased resource requirements. As quantum computing advances, this topic
is likely to become increasingly relevant in discussions about Bitcoin's
future.
Citations:
[1] We wrote the code, and the code won | Trail of Bits Blog
https://blog.trailofbits.com/2024/08/15/we-wrote-the-code-and-the-code-won/
[2] SLotH -- An SLH-DSA/SPHINCS+ Hash-Based Signature Accelerator
https://github.com/slh-dsa/sloth
[3] Cryptographic Right Answers: Post Quantum Edition - Latacora
https://www.latacora.com/blog/2024/07/29/crypto-right-answers-pq/
Is your feature related to a problem, if so please describe it.
https://www.csoonline.com/article/3562701/chinese-researchers-break-rsa-encryption-with-a-quantum-computer.html/amp/
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/0e40068e-6840-49a2-a800-a1f34a0ad9ccn%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 17582 bytes --]
reply other threads:[~2024-10-17 0:55 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0e40068e-6840-49a2-a800-a1f34a0ad9ccn@googlegroups.com \
--to=devbythebay2@gmail$(echo .)com \
--cc=bitcoindev@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox