Posted by conduition
Jun 1, 2026/17:41 UTC
The recent proposal to introduce a new output type focusing solely on ML-DSA key commitment raises several important questions and concerns. Firstly, the decision to adopt an output type similar to P2WPKH, which lacks support for script trees or other complex spending conditions, seems to limit the cryptographic flexibility significantly. This approach restricts the ability to spend coins exclusively to ML-DSA, potentially compromising security. Particularly, if vulnerabilities in ML-DSA were exploited, coins could become highly susceptible to attacks, necessitating a rescue protocol via a soft fork, akin to the one needed for ECC locked coins post-Q Day.
Regarding the choice of using ML-DSA-65 over ML-DSA-44, despite the latter offering comparable classical security levels to secp256k1 and being more compact, the rationale provided appears insufficient. The selection of a 192-bit security level (ML-DSA-65) over a 128-bit level seems to be justified only by its intermediate position, without a clear explanation of why this added security is necessary considering the increase in resource consumption.
Additionally, the deployment of ML-DSA without any witness discounts would likely result in a significant reduction in transactions per second (TPS). This poses serious scalability issues for the network, suggesting that the current proposal may not adequately address the demands of higher transaction throughput.
Finally, comparing ML-DSA with alternative cryptographic schemes such as SLH-DSA or stateful hash-based signatures like XMSS highlights potential alternatives that could offer similar or enhanced security benefits with smaller and faster signatures, without introducing new cryptographic assumptions. The justification for favoring ML-DSA in light of these alternatives remains unclear, especially when considering their potential to provide more efficient and secure solutions.
TLDR
We’ll email you summaries of the latest discussions from high signal bitcoin sources, like bitcoin-dev, lightning-dev, and Delving Bitcoin.
We'd love to hear your feedback on this project.
Give Feedback