(other candidates welcome: here & at upcoming CIP meeting)

@kozross I'm hoping it's OK to drop the word Digital here for the sake of generally required brevity because it's understood from the blockchain context (vs. "paper" signatures, "analog" signatures, etc.)... please correct me if wrong.

That seems fine to me. It's definitely clear from the context.

IMO; we need a CPS that covers and indexes all attack surfaces for when a QC hits the scene, so I do not think it is just a plutus problem. As an overview

• For Praos we have a KES key, which under the hood uses a tree of keys on the ed25519 curve
• The cold key that ultimately binds a stake pool also uses keys from the ed25519 curve.
• The VRF that we use for Praos leadership selection is also using the ed25519 curve
• Then we have in plutus various built-ins that use curves that will break (ecds/schnorr over Secp256k1, and bls pairing crypto).
• the security of our hash functions will also be halved (Grover's algorithm), so we would need to go from sha256 -> sha512 for example, in all places (probably the easiest fix, though block/tx hashes will get bigger)

As you can see, if we get a quantum computer, our consensus and settlement layer will probably be attacked first, so the problem is wider.

But from this overview we also see what kind of quantum tools and construction we will need (not only signature schemes); we will also need a VRF, KES construction, and most likely some quantum secure ZK scheme.

A complex problem with many open questions. And from a presentation that @hjeljeli32 gave once, I think the best we can do now, is redesign our code base that we can swap in and out our underlying crypto primitives (which is also probably not trivial). This way, we can adapt ourselves to new schemes that pop up, but research needs to drive this solution space.

Given this broader context, another open question is; given that QC has broken the above schemes, how can we ensure that bootstrapping nodes follow the right chain?

E.g, QC breaks the forward security of the KES keys that sign blocks

I don't disagree with any of this - in fact, I agree very strongly! However, the sheer magnitude of this problem means that no single CPS will cover it reasonably. In fact, the last one that tried got severely bogged down in details and ended up not progressing as a result.

The reasons behind why we (meaning 'MLabs') wanted to focus on a specific case of post-quantum security was to prevent exactly this kind of scope blowout and death by details. Specifically, we tried to make for a CPS such that:

• It addresses post-quantum security with regard to Cardano somehow;
• The scope is well-defined, allowing a CIP or at least an action plan without death by detail;
• Any potential solution could be used to inform further work, whether it's by choice of implementation, research required, resources expended, etc.

It's not that we feel this is necessarily the only, or even the most important, task or set of questions, merely the one we feel most able to tackle in future work (and want feedback on), and the one residing in the area we understand best (as MLabs are responsible for the implementation of quite a few builtins, including CIPs and working with Plutus Core maintainers).

Does this help answer your questions?