> to deal with cryptographic breaks in its chosen cipher suite Interestingly, this is actually almost doable in the context of a decentralized contract/computi

> to deal with cryptographic breaks in its chosen cipher suite Interestingly, this is actually almost doable in the context of a decentralized contract/computing system (with bug bounties to incentivise reporting[1]). You can include in the contract a interface where someone provides a proof[0] that a given cryptographic primitive is broken (eg a pair of colliding messages for a hash function), and the contract self-modifies to no longer trust that hash function. The other half of the process - adding new primitives - is harder, since you want to prevent the addition of deliberately broken primitives. Obvious ideas include requiring a machine-checkable proof of hardness from some reasonable axioms (eg ZFC + P!=NP + whatever else), although most primitives don't have such proofs, and that doesn't look likely to change. Or requiring a quorum of reliable-seeming cryptographers to vouch for it (refutation: NIST endorsed Dual_EC_DRBG). A escrow period, where a new primitive is accompanied by a deposit that's paid out to anyone who breaks it, might help, but you'd need a seperate mechanism to prevent NOBUS backdoors (again, see Dual_EC_DRBG). 0: Ideally, you want a semi-zero-knowledge proof such that someone who has the option of putting in a tractable but significant amount of work to prove it (eg hash collision in 2^64 operations) will expect to be able to recoup their losses without getting sniped by front-runners, but once such a proof has been used, it's only a matter of time before front runners recover it and warn every contract. For hash collisions, probably the easiest design is a two-phase model, where the reporter provides a zero-knowledge proof to commit to a particular hash collision, but then has to provide the actual collision to get the bounty. This can also work for preimages of a Schelling point like all-bits-zero. I'm not sure what a good Schelling point for typical public-key cryptography like curve25519 would be though; zero is almost always algebraicly special. 1: Cryptographic primitives are generally broken incrementally, so this incentivises even malicious parties to report a not-yet-exploitable break immediately (and thereby neuter it), rather than spend time trying to develop a working exploit (and risk both the large and small rewards disappearing out from under them because someone else was either honest or just less patient).