Eight years later: the canary problem is still an incentive problem
Coming back to this eight years later because I ran into the same wall you and Nate were circling in the 2018 replies, but from a different angle.
I’ve been working on a mechanism, Geminis, where a chain can switch its own ruleset — including its signing primitive — when an on-chain trigger condition is met, without a vote or hard fork.
Structurally, it is close to what you propose here: a canary followed by an automatic switch to a pre-wired backup. But instead of putting a bounty on the deployed primitive, the canary is a deliberately weakened instance from the same primitive family, derived from a public seed. Nobody generates the instance, so nobody can privately hold the exploit. There is also nothing valuable behind that specific instance.
That addresses the specific problem nate raised with the bounty model:
Why would someone who can break the real primitive claim the reward instead of quietly draining accounts?
But I don’t think it closes the underlying problem. It relocates it.
The canary can tell you that the primitive family is weakening. It cannot guarantee that the real deployed instance will break on the same timeline as the deliberately weakened one.
I ended up writing this down formally because I think this distinction is worth being precise about.
A complete break is fundamentally different from a partial break. If an attacker can recover the secret key, their resulting signatures are not distinguishable from legitimate signatures: they are using the same signing relation as the legitimate signer. There is no second observable process that a bounty or penalty can condition on.
In incentive terms, this looks like a hidden-action problem with an unobservable type, in the same general family as moral hazard.
A partial break is different. Statistical biases or progressively cheaper attacks — the kind of pattern we saw with DES, MD5, and SHA-1 — can produce observable evidence before the primitive is completely compromised.
A complete break, by definition, removes much of that observability. And I think this limitation applies to the bounty construction as well, not only to my canary approach.
Where I think both mechanisms can still get useful signal is in how the canary is chosen.
Rather than selecting the most obscure candidate, choose the primitive that has received the most serious public cryptanalysis. Rainbow and SIKE are useful reminders here: both were serious NIST PQC candidates with substantial public scrutiny, yet both were broken completely in 2022 by attacks practical enough to run on a laptop.
Public scrutiny is not proof of security, obviously. But it may be one of the few external signals available for the proposition we’re actually trying to test: has someone already tried seriously to break this?
I also measured a complementary mitigation rather than assuming it was worthwhile: a composite signature combining lattice-based ML-DSA-44 with hash-based SLH-DSA-128s, with no shared cryptographic core.
My preliminary desktop measurement, across three execution engines, puts composite verification at roughly 4.2× the cost of a single verification, rather than the ~10× one might naively expect from adding native benchmark numbers. The reason is that the two primitives favor different execution engines.
I haven’t run the phone measurement yet, and this result alone doesn’t establish that the composite construction is worth adopting. That would depend on a velocity threshold I haven’t measured yet.
Full writeup and measurement code:
github.com
GitHub - cristiandkzk/Geminis
Contribute to cristiandkzk/Geminis development by creating an account on GitHub.
I’d be interested in your current view of the original proposal: do you still think the bounty is the right incentive lever, or does this framing of the complete-break case change how you see the problem seven years later?
| # | Наименование новости | Тональность | Информативность | Дата публикации |
|---|---|---|---|---|
| 1 | Public-mempool gas sponsorship needs escrow, a bond, or trust | 0 | 6.46 | 14-09-2026 |
| 2 | Same instruction count, 23x the wall clock: working-set effects in a deterministic RISC-V interpreter | 0 | 10.98 | 18-09-2026 |
| 3 | Exploring the Design Space for a Post-Quantum Public Key Registry for Ethereum Validators | 0 | 9.18 | 07-09-2026 |
| 4 | Mempool Account Transaction Capacity from Historical Activity (MATCHA) | 0 | 9.38 | 22-09-2026 |
| 5 | Etheorem update: the complete executable consensus specs written in Lean 4 | 0 | 4.8 | 21-09-2026 |
| 6 | Strict role alternation: reciprocal broadcast without relayers for EVM shielded pools (spec + population simulation, no code yet) | 0 | 12.48 | 19-09-2026 |
| 7 | Towards Encrypted Mempools from Threshold IBE without Batching | 0 | 11.77 | 20-09-2026 |
| 8 | Staking rewards as venture capital, governed by futarchy | 0 | 8.82 | 17-09-2026 |
| 9 | ERC-8354: Confidential Agent Policy Verdicts | 0 | 12.87 | 24-07-2026 |
| 10 | Deterministic Random Number in EVM for Independent Recomputability | 0 | 12.36 | 30-07-2026 |