Abstract In order to provide forward security in Cardano, we are in the process of implementing KES (Key Evolving Signatures). This CPS describes the practical challenges that result from two conflicting requirements: secure deletion of old keys ("secure forgetting"), and reasonable availability of current KES keys in the case of process restarts. Problem

Abstract Implement a KES Agent service to provide complete forward security for block-forging signatures. Motivation: why is this CIP necessary? As outlined in CPS-???? (KES Forward Security), Key Evolving Signatures in Cardano dictate two seemingly conflicting requirements: KES Sign Keys must never be written to persistent storage, in order to guarantee secure deletion ("forgetting")

In this document we make some back-of-the-envelope computations to see how feasible it is to verify SNARKs on main-net. We have some preliminary benchmarks made by Kenneth that show how expensive each function is. The goal of this document is to use those values and estimate SNARK verification on-chain. Similarly, we will estimate how much data the script needs to process, to understand if we are within the script data budget. We analyse two SNARKs systems, Groth16 and vanilla-Plonk. Preliminary benchmarks The current limit for on-chain scripts is 10,000,000,000 of the units in the file, but the basic Plutus stuff will add a lot on top of the costs of executing the builtins. The values of interest for this analysis are the following (were x is the size of the input in bits divided by 64): bls12_381_G1_compress : 3341914

Goal: We will have one curve or cycle of curves chosen for Midnight Goal of being rollup friendly There are sidechain constraints and there are plutus constraints Came up from weekly executive meeting. We need to justify the decision. If we make changes soon enough (before handing the keys over), we are the ones taking the decision (rather than convincing the community). Nonetheless, we should justify/motivate this decision as if we had to convince the community (we should have ADRs for this decision). The discussion here concerns (cycle of) curves that will be used in midnight. However, the mid/long-term goal is to be able to verify midnight proofs on main-net. This is why Cardano also has weight on this decision (as Plutus will need built-in functions for efficient verification on main-net). Seems to be clear that there is not one perfect curve that solves all our problems. So we have to understand the trade-offs:

ideas to discuss on a internal presentation about OS: external collaboration, fastening the development code auditing and participation of experts across the industry to resolve bugs why does it work with plonk? (list some ideas here such as new technology, few people that have the expertise to work in this, a lot of interest for a new tech, etc)

In this document we present a list of different multisignature constructions in order to compare them, and further select which construction fits best the protocol requirements. We study different constructions which might be contestants for such functionality, and determine whether there exists implementations. For self-containedness we include the formal definitions and security properties of multisignature schemes in Appendix A and Appendix B respectively. Diferent constructions In the Hydra paper, there are a few referenced works. In particular, those cited references are: [BN06] Multi-signatures in the plain public-key model and a general forking lemma. [Bol03] Threshold signatures, multisignatures and blind signatures based on the gap-Diffie-Hellman-group signature scheme (used in simulations). [BDN18] Compact multi-signatures for smaller blockchains. [MOR01] Accountable-subgroup multisignatures.