Threshold Signatures in Chainlink

Abstract: Threshold signatures offer a concise, cheap way to verify consensus over very large groups, and we plan to use them to scale Chainlink's security independently of Ethereum's throughput. In this post I (1) review how threshold signatures work, following Stinson & Strobl's 2001 paper; (2) describe a new Schnorr-like signature which is cheap to verify in solidity (just 15k gas, including input parameters); and (3) introduce the implementation I've developed of the threshold-signature construction, using the Schnorr-like signatures. Introduction What would the world be like if even strangers could be trusted to keep their commitments? How much collaboration and mutual aid go unrealized because it's simply too hard to trust our commitments to each other? At Chainlink, we aim to find out, because our goal is to help people craft secure smart contracts which faithfully respond to real-world outcomes. A smart contract on a blockchain like Ethereum's can reliably reward or punish a participant as soon as their behavior has been proven. When operating correctly, that's a much cheaper and safer form of enforcement than contract law. But to enforce commitments to real-world behavior which people actually care about, a smart contract needs trustworthy reports of relevant real-world events. For example, today you can make a smart contract reward solutions to certain math problems, but an insurance contract concerning real-world risks like drought needs to trust someone to tell it when the drought has happened. It's relatively easy to set up smart contract which responds when someone posts a transaction reporting a real-world event, but by itself that's an unreliable arrangement. As more and more value comes to depend on the outcome of that report, the incentive to corrupt it grows enormous. So we need a way to make it more expensive, ideally impossible, for any adversary to influence the report. In some sense, this can be seen as a generalization of the goals of Bitcoin's original consensus mechanism, and Bitcoin contains the kernel of the solution: To address the "double spend" problem, Bitcoin needs trustworthy observations of which Bitcoin transactions are valid, and the solution was a distributed consensus which weights participation by the "skin in the game" demonstrated by winning the proof-of-work lottery. Chainlink's current approach to real-world events is for a group of "oracles" to each report their observations to a smart contract which imputes an aggregate value. The more diverse this group is, the more observers an adversary has to suborn to corrupt the outcome, so the more secure the system becomes. The trouble is, having everyone report to the blockchain individually is quite expensive. Historically, on Ethereum, there have been 25 days when naive reports of this sort probably cost more than $1.50. So if you wanted confirmations from 2,000 participants, that might have cost over $3,000 on those days! A group committing to provide 2,000 verifications every day for a year could potentially face hundreds of thousands of dollars in gas costs, which would be feasible only for extremely high-margin contracts. Even at today's prices, the total gas for a year of such reports would cost thouands of dollars. At the same time, if you actually needed a specific group of 2,000 observers to confirm a report, any one of them could hold up the confirmation of a real-world observation by failing to send in their confirmation. So to ensure reports go through, we really want an arbitrary subset to confirm, say 2,000 out of 2,500. That way, 500 reports could fail, and the consensus value would still make it to the blockchain. If this sounds a lot like multisig contracts, it is, but the gas costs of confirming a transaction in existing multisig wallets scale linearly in the number of participants. In this post, I'm going describe threshold signatures, a cryptographic scheme where an arbitrary group of signers can construct one signature, as long as there are sufficiently many of them. This enables a huge efficiency gain, because almost all the calculation can be done by the signers before submitting to Ethereum, and what they actually end up submitting is very concise.. Our current best threshold signature scheme (described in this post) requires about 15k gas to confirm. This means, for instance, that the \$3,000 data point I mentioned earlier would only cost about \$2, a 1,500-fold savings (and at current gas/ETH prices, the cost would be a bit over one cent, vs about $17 for validation of a 2,000-strong quorum, using the current framework.) The fact that consensus between signature participants is established independently of Ethereum (with very concise on-chain verification) also means that Chainlink's security can scale with no improvement in Ethereum's throughput. This will allow contracts to depend on much larger observation sets, because any sufficiently large subgroup of participants can all agree on an observed value and collectively sign it, off-chain. The limiting factor will become the cost of off-chain communication between participants during constructions of the shared private key and the signatures (both of which grow as the square of the number of participants.) And it's likely possible to scale to an effective consensus even beyond that limit, using other methods we've been developing, and might discuss in a future blog post. Cryptographic preliminaries: Discrete Log, Pedersen Commitments, and all that Mathematicians love powerful abstractions, and they also love puns. We're going to be dealing with a number of mathematical objects which all have different notions of addition and multiplication on them. These arithmetic notions all relate to common abstractions known as a groups, rings, and fields, but it's important to keep in mind that the arithmetic operations over each is different. The beautiful thing about these abstractions is that your intuitions from regular arithmetic will mostly carry over. I will try to let you know when there are critical differences. The important thing is, if I say something like "$G+H$", don't necessarily assume that $G$ and $H$ must be numbers, just because I'm adding them. The "+" there is a kind of pun. Hopefully, the type of the objects will be clear from context. The mathematical object we'll be doing cryptography over is an elliptic curve. If you're not familiar with them or their use in cryptography, I recommend Andrea Corbellini's highly informative introduction. But my goal is that you shouldn't need to know all of that to follow along, here. All we really need to accept for now is that there's an operation on curve points which looks a lot like regular addition of whole numbers, in that We can add points to each other to get another curve point. This is the first of those puns: If $G$ and $H$ are curve points, we denote their sum by $G+H$. This does not look anything like numeric addition, but the following facts mean it has similar algebraic properties. There's a zero point which has no effect when you add it to other points. Every point has a negation, and when you add a point and its negation, you get the zero point. When you add a sequence of points together, it doesn't matter what order you do the additions in. There's a point G on the curve which generates the entire curve, in the sense that if you could compute $\{G, G+G=2G, G+2G=3G, G+3G=4G,...\}$ and so on, you would eventually get every point on the curve. Here $G$ is playing a similiar role to that of the number 1 when you're doing addition of whole numbers: Just as you can represent any positive whole number $m$ as a sum of $m$ ones, $1+\ldots+1$, you can in principle represent any curve point $H$ as a multiple of $G$, $mG$ for some number $m$. After running through every point on the curve, the sequence $(G, 2G, 3G,\ldots,)$ "wraps back around" to $G$. Let's call the number of points on the curve $q$ (For security reasons, $q$ needs to be an incomprehensibly large prime.) So we have $(q+1)G=G$. For this reason, it's useful to think about multiples of $G$ in terms of "clock arithmetic" on the elements $𝔽_q=\{0, \ldots, q-1\}$. Arithmetic in $𝔽_q$ is another mathematical pun: to compute $a+b$ or $a\times b$ on elements $a, b\in 𝔽_q$, first we do the operation as if they were regular numbers, then we take the Euclidean remainder from that, divided by $q$. E.g., suppose for a moment that $q$ was the (extremely cryptographically insecure) number 7. In $𝔽_7$, $6+6=12=1\times 7+5$, so we say $6+6\equiv 5\mod 7$, as if we started at 6 on a clock with seven ticks, moved 6 ticks forward, and looked at which tick we stopped on. Similarly, $6\times 6=36=5\times 7+1$, so we say $6\times 6\equiv 1\mod 7$. As long as $q$ is prime, every non-zero element of $a\in 𝔽_q$ has a multiplicative inverse $a^{-1}\in 𝔽_q$ such that $a\times a^{-1}\equiv 1\mod q.$ In $𝔽_7$, $6^{-1}$ is 6 itself. Because every non-zero element has an inverse, we can calculate quotients $a/b$ for $b\neq 0$ as $a\times b^{-1}$. One cryptographically important aspect of arithmetic on elliptic curves is that there is a concise representation of the value from adding $G$ to itself $m$ times, $mG=G+\ldots+G$, and $m$ is believed to be irretrievable from that representation. It's a widely accepted, foundational assumption of elliptic curve cryptography that if I just give you the value $mG$, you're very unlikely to be able to figure out what $m$ is, except more or less by random guessing. And since the curve has at least 100,000 times more points on it than the estimated number of atoms in the universe, random guessing is seen as hopelessly unlikely to succeed. The difficulty of guessing $m$ from $mG$ is known as the discrete-log hardness assumption. One interesting consequence of the difficulty of the discrete log problem is that you can use it to encode secret arithmetic. What you do is pick another random point on the curve $H$ such that no one can figure out its discrete log over $G$, then you can encode a value $\alpha$ as $C=\alpha G+\beta H$, for some random $\beta$. The point $C$ is what's known as a Pedersen commitment to the value $\alpha$, because if you've published $C$, the hardness of the discrete log problem makes it implausibly difficult to go back and figure out other values $\tilde{\alpha},\tilde{\beta}$ for which $C=\tilde{\alpha}G+\tilde{\beta}H$. In fact, knowing such $\tilde{\alpha},\tilde{\beta}$ would directly imply that you can compute $m$ for which $mG=H$, solving the discrete-log problem: just set $m=\frac{\alpha-\tilde{\alpha}}{\beta-\tilde{\beta}}$. $C$ is called a commitment because I can give it to you as part of some agreement we're entering into where I later reveal $\alpha$ and $\beta$, and we take some action based on $\alpha$ or $\alpha G$. You verify whatever $\alpha$ I reveal at that point by checking $C=\alpha G+\beta H$, and you're confident that it's the $\alpha$ I committed to with $C$ because it would be very hard for me to come up with alternative $\tilde{\alpha}$ and $\tilde{\beta}$ for which $C=\tilde{\alpha}G+\tilde{\beta}H$. At the same time, I can be confident that you won't be able to determine $\alpha$ or $\alpha G$ until I reveal it. You can do secret arithmetic with Pedersen commitments just by adding the points: If $C^\prime=\alpha^\prime G+\beta^\prime H$, then $C+C^\prime=(\alpha+\alpha^\prime)G+(\beta+\beta^\prime)H$ is a Pedersen commitment to $\alpha+\alpha^\prime$. Shamir Secret Sharing Now I'm going to lead you through the constructions we need for threshold signatures. This is mostly following Stinson and Strobl's paper, Provably Secure Distributed Schnorr Signatures and a $(t,n)$ Threshold Scheme for Implicit Certificates. For the foundational construct, Shamir Secret Sharing, we don't need an elliptic curve, we just operate over $𝔽_q$. The initial phase of Shamir Secret Sharing is not collaborative, though we'll see later that threshold signatures use it in a collaborative protocol. There is a single trusted dealer who creates (and knows) a secret, and gives enough information about it to $n$ other entities that any $t$ of them can reconstruct it. The key idea in Shamir Secret Sharing is very prettily described in this Wanchain blog post, but the gist of it is that the space of $(t-1)$-degree polynomials with coefficients in $𝔽_q$ form a $t$-dimensional vector space. So the dealer represents its secret as the constant term of a polynomial $f(x)=a_0+a_1x+\ldots+a_{t-1}x^{t-1}$, with the coefficients $\{a_i\}\subset 𝔽_q$ each uniformly and independently chosen from $𝔽_q$. We're actually going to share all of $f$'s coefficients, but only $a_0$ is used as the shared secret. Then the dealer assigns indices $1,\ldots,n$ to the recipients, in some arbitrary but fixed order. Finally, it sends the $i$th participant the values $(i, f(i))$. Because $f$ is a point in a $t$-dimensional vector space, $t$ of these evaluations are enough to reconstruct $f$. On the other hand (just ignore this sentence if you don't know about vector spaces), $t-1$ or fewer points can only constrain $f$ to a nontrivial vector subspace of polynomials over $𝔽_q$, so they can't reveal information about any specific coefficient (unless that coefficient is 0, which is overwhelmingly improbable.) It's sort of like how if you take the intersection of two planes in three-dimensional space, you get an entire line, but if you take the intersection of three planes, you get a single point. Let's say participants $i_1,\ldots i_t$ share their values $(i_j,f(i_j))$ with each other. Then they can construct the polynomial \[\begin{equation}g(x)=\sum_{j=1}^tf(i_j)\prod_{k\in\{1,\ldots,t\}\setminus\{j\}}\frac{x-i_k}{i_j-i_k}\label{lagrange}\end{equation}\] Here, the $\sum$ sign means "add these values, from $j=1$ up to $j=t$," and the $\prod$ sign means "multiply these values, for $k=1$ up to $k=t$, but not including $k=j$." If I wanted to express this in terms of python generator comprehensions, I might do it like sum(f(i[j])*np.prod([(x-i[k])/(i[j]-i[k]) for k in range(1, t+1) if k != j]) for j in range(1, t+1)) where np.prod is the numpy prod function, which computes the product of the elements in its first argument. Evaluating $g$ at any $i_j$ gives, separating out the $j$ term, $$\begin{align*} g(i_j)&=f(i_j)\prod_{k\neq i_j}\frac{i_j-k}{i_j-k}+\sum_{k\neq i_j}f(k)\prod_{l\neq k}\frac{i_j-l}{k-l} \\ &=f(i_j)\times 1 + \sum_{k\neq i_j}f(k)\times\frac{i_j-i_j}{k-i_j}\times\prod_{l\neq k,i_j}\frac{i_j-l}{k-l} \\ &=f(i_j)+0\\ &=f(i_j), \end{align*}$$ where for the first equality, I have taken the $j$th term out of the sum, and the for the second equality I have used the fact that $\frac{i_j-k}{i_j-k}=1$ for $k\neq j$, and taken the $j$th factor out of each remaining product. Since $f$ and $g$ agree on $t$ points, they are the same polynomial. This trick, for constructing a degree-$d$ polynomial from its value at $d+1$ points, is known as Lagrange interpolation. At least $t$ participants are necessary for this recovery of $f$. With fewer, you can only infer that $f$ lies on some non-trivial affine subspace (which has cardinality at least $q$, because it's at least one-dimensional over $𝔽_q$) of the vector space of $(t-1)$-degree polynomials. Verifiable Secret Sharing Cryptography isn't just about Mathematics. It's also important to think adversarially about how participants in a protocol like Shamir Secret Sharing could misbehave for personal gain. This leads to rounds of challenges and responses, to determine who's responsible for the collaboration going awry. Also, every message needs to be signed by its sender, so that it can be provided as evidence of their misbehavior if need be. In the above scheme, the dealer is trusted to provide consistent values $f(i)$ to each paarticipant. If the dealer isn't using a consistent $(t-1)$-degree polynomial to construct the values $f(i)$, different $t$-size subsets of the participants could construct different values for the secret. Verifiable secret sharing uses Pedersen commitments to constrain what the dealer can send the participants. The dealer constructs $f(x)=a_0+a_1x+\ldots+a_{t-1}x^{t-1}$ as before, but also constructs a second random polynomial, $h(x)=b_0+b_1x+\ldots+b_{t-1}x^{t-1}$, and uses this to form public Pedersen commitments to the coefficients of $f$, the curve points $C_c=a_cG+b_cH$. The messages from the dealer to the participants are now $(i,f(i),h(i))$. This allows each recipient to verify that the values come from the polynomials committed to by $\{C_c\}$, because it must be the case that $\sum_{c=0}^{t-1}C_ci^c=\left(\sum_{c=0}^{t-1}a_ci^c\right)G+\left(\sum_{c=0}^{t-1}b_ci^c\right)H=f(i)G+h(i)H$, which is a curve point they can calculate, knowing $f(i)$ and $h(i)$. If a recipient, say the $i$th, can't verify the information from dealer, it broadcasts a complaint publishing the dealer-provided values, which is signed by the dealer. Then all the other participants can verify for themselves, using the complaint, that the dealer sent values for which $\sum_{c=0}^{t-1}C_ci^c\neq f(i)G+h(i)H$. If that happens, the whole deal is off! Similarly if any participant broadcasts an invalid complaint (one with an incorrect dealer signature or with valid dealer values), they are marked as untrusted. Once everyone's content that they have the correct values from the dealer, any $t$ of them can construct the dealer's secret polynomial themselves using the same Lagrange-interpolation trick as in equation $(\ref{lagrange})$. Pedersen/Rabin Distributed Key Generation The goal in distributed key generation is to create a private value $m\in 𝔽_q$ which nobody knows, but any $t$ participants can work with to do public-key cryptography, with $m$ as the private key and $mG$ as the public key. The following scheme requires that $t\leq n/2$, i.e., that at least half of the participants are honest. It's kind of magical, in that it simulates Verifiable Secret Sharing, with a polynomial which no one knows. The first step is $n$ simultaneous Verifiable Secret Sharings of secret polynomials $f_i(x)=a_{i,0}+a_{i,1}x+\ldots+a_{i,t-1}x^{t-1}$, $h_i(x)=b_{i,0}+b_{i,1}x+\ldots+b_{i,t-1}x^{t-1}$, with the $i$th participant acting as the dealer for $(f_i,h_i)$ to all the other participants. They all have to agree on an ordering of the participants, and share deals using that ordering, so that the $i$th particiant gets $f_j(i)$ from any other $j$th participant, not some other $f_j(k)$. Roughly speaking, the unknown polynomial they'll be sharing is the sum of the $f_i$'s. If there are any valid complaints about a participant's dealing, or if a participant makes an invalid complaint against someone, they are removed from the collaboration. At the end of this, participant $i$ has $(f_j(i),h_j(i))$ from participant $j$, for all $j\neq i$. Denote by $Q$ (for "qualified") the set of participants who get through this sharing procedure without a legitimate complaint against them. Once all these shares are complete, any $t$ participants could reconstruct any other participant's secrets, but an implicit assumption of a $(t,n)$-threshold scheme is that at most $t-1$ participants are dishonest, so any dishonest coalition is too small to do that. At this point, the participants have enough information to simulate sharing of the sum of all the qualified participants' secret polynomials, $f(x)=\sum_{i\in Q}f_i(x)=$ $\sum_c(\sum_{i\in Q}a_{i,c})x^c$ and $h(x)=\sum_{i\in Q}h_i(x)=\sum_c(\sum_{i\in Q}b_{i,c})x^c$, even though none of them actually know $f$. Since participant $i\in Q$ has $(f_j(i),h_j(i))$ from every participant $j\in Q$, they can compute $f(i)=\sum_{j\in Q}f_j(i)$ and $h(i)=\sum_{j\in Q}h(i)$ , and verify the associated Pedersen commitments, so it's as if some notional dealer is sharing that secret with them. We're going to use these values to work with the distributed secret $m=\sum_ia_{i,0}$. Now each participant $i$ reveals the "public key" part of their share of the secret, by publishing $A_{i,k}=a_{i,k}G$ (recall that $(a_{i,k})_k$ are the coefficients of $i$'s secret polynomial, $f_i,$ and in some sense $A_{i,k}$ was already shared as the first term of $C_{i,k}=a_{i,k}G+b_{i,k}H$.) Every other participant can then verify that $f_i(j)G=\sum_{k=0}^{t-1}j^kA_{i,k}$. If $j$ reports an invalid, signed set of $A_{i,k}$s from $i$, the other participants (of which there must be at least $t-1$, for the protocol to work) resort to recovering $i$'s secret polynomial using the Lagrange interpolation trick. Because they're able to do that, a malicious coalition can't choose to abort the protocol or control the output in any way by choosing to publish or withold a valid complaint against one of its coalition. This is the reason we had to initially verify the shares using the Pedersen commitments $C_{i,k}$, rather than the straight "public key" values $A_{i,k}$: It's assumed to be impossible to infer $A_{i,k}$ from $C_{i,k}$, and we wanted to make sure everyone was committed to participating in the final construction of the secret, either by sharing properly, or by having their secrets forcibly reconstructed by the other honest parties, from their verified revelations during the Verifiable Secret Sharing phase. The above recovery step requires that $t\leq n/2$. As long as that's the case, there are always enough shares from honest participants to reconstruct shares from dishonest participants who withold the correct $A_{i,k}$s. Finally, now everyone knows the "public key" for the constant coefficient of any $i\in Q$, namely $A_{i,0}=a_{i,0}G$. The associated "private key" is just that coefficient, $a_{i,0}$. The distributed secret is then just the sum of everyone's constant coefficients, $z=\sum_{i\in Q}a_{i,0}$, and the associated public key (which we will be using in the threshold signature scheme) is the sum of everyone's public keys, $\sum_{i\in Q}A_{i,0}=\sum_{i\in Q}a_{i,0}G=(\sum_{i\in Q}a_{i,0})G=zG$. It's worth noting that if the protocol is forced to reconstruct $i$'s secrets because $i$'s published $A_{i,k}$ values were invalid, then from that point only $t-1$ other participants are necessary to work with the distributed secret $z$. But the important thing to keep in mind is the implicit assumption of this threshold scheme is that at most $t-1$ participants are dishonest. If $i$'s public $A_{i,k}$ values are wrong, that proves $i$ is dishonest, so based on that assumption there can be at most $t-2$ other dishonest parties. Threshold signatures We can do threshold signatures, now that we have a way to construct a $(t,n)$-distributed secret $z$ and the associated public key $zG$ from participant-level portions of the keys, $\{(z_i,z_iG)\}_{i\in Q}$. First, the participants construct such a public/private keypair, which they will use to sign messages, $(z, zG)$. Then for each message $M$ they want to sign, they'll run the distributed key generation process again to construct a nonce $k=\sum_{i\in Q^\prime}k_i$ (where $k_i$ is $i$'s part of the new secret), and associated public key $K=\sum_{i\in Q^\prime}K_i$, where $K_i=k_iG$. Each participant $i$ signs the message with their portion of $z$, using the Schnorr signature scheme: $$e=H(K‖M), s_i=k_i-z_ie,$$ where $H$ is an appropriate hash function, and the arithmetic is in $𝔽_q$. Finally, they add up their signatures to obtain $s=\sum_{i\in Q^\prime}s_i=\sum_{i\in Q^\prime}k_i-z_ie=k-ze$. The pair $(s,e)$ is a signature on M using the public/private key pair $(z, zG)$ and the nonce $k$. Anyone can verify that the signature matches the public key $zG$ by checking that $H(sG+e(zG)‖M)=e$, which holds for a correct signature because $sG+e(zG)=(s+ez)G=kG=K$. The linearity of the Schnorr-signature formula, $s=k-ze$, plays a critical role, here. Ethereum took its signature scheme from Bitcoin, which uses ECDSA signatures, not Schnorr, and while signing in ECDSA involves a somewhat similar formula, $s=(H(M)+K_xz)/k$ in $𝔽_q$, the non-linearity in $k$ means one can't just add up the participants' individual signatures like we can in Schnorr. Cheap on-chain verification of Schnorr signatures Schnorr signatures aren't that expensive to validate on-chain. There's a public implementation which takes about 85k gas, by using the Ethereum precompiled contracts for the pairing curve AltBN-128. Still, in the optimistic case where Chainlink and Ethereum become very popular, we're going to want to reduce that cost as much as possible in order to allow more data to be reported on-chain. With a small adjustment to the Schnorr signature formula, we are able to reduce the cost of on-chain verification to a mere 15k gas, using Vitalik Buterin's ecrecover trick for abusing Ethereum's authentication infrastructure to verify elliptic curve arithmetic. Ethereum has a precompiled contract, accessible through solidity via the ecrecover function, which for 3,000 gas will return the ethereum address for the public key which signed a message. When you compute ecrecover(z, v, r, s), you're effectively solving for $P$ in $$(s^{-1}zG+s^{-1}rP)=R,$$ where $R$ is the point specified by the $x$ ordinate $r$ and the parity of the $y$ ordinate from $v$, and all scalar arithmetic is in $𝔽_q$. It follows that $$P=(r^{-1}s)R+(-r^{-1}z)G.$$ On the other hand, to verify a Schnorr signature, we compute $K=sG+eP$, where $P$ is the public key, and then check that $e=H(K‖M)$. If we instead use $e=H(\mathrm{address}(K)‖M)$ in the signing and verification procedure, we can use ecrecover directly, to check that $\mathrm{address}(K)$ is ecrecover($-P_xs$,$P_v$,$P_x$,$P_xe$)$=\mathrm{address}(sG+eP)$, where $P_x$ is the $x$ ordinate of the public key, $P_v$ is 27 if $P$'s $y$ ordinate is even and 28 if it's odd, and $e=H(\mathrm{address}(K)‖M)$. As argued here, we could even truncate $e$ to 128 bits, to maintain the 128-bit security afforded by secp256k1. Due to verifying a hash of the curve point rather than the curve point itself, some adjustments to the proof in that paper are necessary, and I might discuss them in a future blog post. Implementation The excellent cryptography library kyber (which is a project of the academic EPFL DEDIS group, and to the best of my knowledge has no connection to the Kyber Network) already has an implementation of the threshold signature scheme I've described above. We've written a wrapper of btcd's secp256k1 arithmetic which is compatible with the kyber Group abstraction, a modification to kyber's threshold-signature construction, and also a smart contract which implements verification in the above signature scheme, along with an end-to-end test of the two systems. Once we've audited this implementation, we plan to set up a peer-to-peer network between oracles, through which they can negotiate and construct threshold signatures attesting to real-world data. We expect this will be a major advance for the integrity of smart contracts' connections to the real world, because it enables cheap on-chain verification of essentially arbitrary off-chain interactions between participating oracles. If you're interested in this kind of thing, we're hiring. Acknowledgements Thanks to Chris Blake, Steve Ellis, Ari Juels, Dimitri Roche and Holly White for feedback and suggestions on this post, and to Sergey Nazarov for suggesting I write it in the first place.