Good points. I like your suggestion for a SPHINCS+, just due to how mature it is in comparison to SQIsign. It's already in its third round and has several standards-compliant implementations, and it has an actual specification rather than just a research paper. One thing to consider is that NIST-I round 3 signatures are 982 bytes in size, according to what I was able to find in the documents hosted by the SPHINCS website. https://web.archive.org/web/20230711000109if_/http://sphincs.org/data/sphincs+-round3-submission-nist.zip One way to handle this is to introduce this as a separate address type than SQIsign. That won't require OP_CAT, and I do want to keep this soft fork limited in scope. If SQIsign does become significantly broken, in this hopefully far future scenario, I might be supportive of an increase in the witness discount. Also, I've made some additional changes based on your feedback on X. You can review them here if you so wish: https://github.com/cryptoquick/bips/pull/5/files?short_path=917a32a#diff-917a32a71b69bf62d7c85dfb13d520a0340a30a2889b015b82d36411ed45e754 On Friday, June 14, 2024 at 8:15:29 AM UTC-6 Pierre-Luc Dallaire-Demers wrote: > SQIsign is blockchain friendly but also very new, I would recommend adding > a hash-based backup key in case an attack on SQIsign is found in the future > (recall that SIDH broke over the span of a weekend > https://eprint.iacr.org/2022/975.pdf). > Backup keys can be added in the form of a Merkle tree where one branch > would contain the SQIsign public key and the other the public key of the > recovery hash-based scheme. For most transactions it would only add one bit > to specify the SQIsign branch. > The hash-based method could be Sphincs+, which is standardized by NIST but > requires adding extra code, or Lamport, which is not standardized but can > be verified on-chain with OP-CAT. > > On Sunday, June 9, 2024 at 12:07:16 p.m. UTC-4 Hunter Beast wrote: > >> The motivation for this BIP is to provide a concrete proposal for adding >> quantum resistance to Bitcoin. We will need to pick a signature algorithm, >> implement it, and have it ready in event of quantum emergency. There will >> be time to adopt it. Importantly, this first step is a more substantive >> answer to those with concerns beyond, "quantum computers may pose a threat, >> but we likely don't have to worry about that for a long time". Bitcoin >> development and activation is slow, so it's important that those with low >> time preference start discussing this as a serious possibility sooner >> rather than later. >> >> This is meant to be the first in a series of BIPs regarding a >> hypothetical "QuBit" soft fork. The BIP is intended to propose concrete >> solutions, even if they're early and incomplete, so that Bitcoin developers >> are aware of the existence of these solutions and their potential. >> >> This is just a rough draft and not the finished BIP. I'd like to validate >> the approach and hear if I should continue working on it, whether serious >> changes are needed, or if this truly isn't a worthwhile endeavor right now. >> >> The BIP can be found here: >> https://github.com/cryptoquick/bips/blob/p2qrh/bip-p2qrh.mediawiki >> >> Thank you for your time. >> >> -- 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/d78f5dc4-a72d-4da4-8a24-105963155e4dn%40googlegroups.com.