Hash-Based Signatures for Bitcoin's Post-Quantum Future

In the discourse surrounding the implementation of cryptographic schemes within Bitcoin's ecosystem, significant attention has been given to optimizing these for efficiency and privacy. One such exploration involves modifications to SPHINCS-alpha and SPHINCS+C schemes, as detailed through experimental Rust code implementations available on GitHub (see SPHINCS+C experiment and balanced parameter set experiment). These modifications suggest the potential for enhanced performance through parallelism and fine-tuning of parameters.

The discussion also touches upon the implications of using hash-based signature schemes like SLH-DSA for user privacy. It is pointed out that employing such a scheme without careful consideration could inadvertently link public keys together, thereby compromising anonymity. To counter this, the utilization of hardened derivation for child SLH-DSA keys is proposed as a solution to preserve privacy in most practical scenarios. Moreover, the introduction of a pseudorandom nonce in the SLH-DSA tap leaf script is recommended to ensure the uniqueness of each tap leaf hash, further safeguarding against linkage between addresses unless a key is explicitly used to sign a transaction.

However, concerns arise regarding the loss of compatibility with standardized schemes when deviating through parameter adjustments or additional modifications aimed at saving data space. The correspondence differentiates between algorithmic and parametric compatibility, suggesting that while full departure from SLH-DSA standards (in favor of variants like SPHINCS+) would sever ties with existing and future compliant hardware and software, minor parameter adjustments could be more manageable. This approach would retain some level of interoperability, especially if changes are confined to constants rather than algorithms.

The potential benefits of adapting Bitcoin’s SLH-DSA implementation to a new parameter set are highlighted, including increased integration incentives for current and future software and hardware without necessitating extensive redevelopment. Such a strategy could transform High-Security Modules (HSMs) into high-security bitcoin signing devices and expand the application of open-source libraries with minimal code adjustments. This perspective advocates for prioritizing broader compatibility and integration possibilities over marginal improvements in signature size, emphasizing the strategic value in maintaining a degree of standard compliance.