├── .gitignore ├── md └── atomic-swap.md └── slides └── 2017-05-milan-meetup ├── majorplayer.png └── slides.tex /.gitignore: -------------------------------------------------------------------------------- 1 | *.aux 2 | *.bbl 3 | *.log 4 | *.nav 5 | *.out 6 | *.pdf 7 | *.snm 8 | *.swp 9 | *.toc 10 | -------------------------------------------------------------------------------- /md/atomic-swap.md: -------------------------------------------------------------------------------- 1 | Adaptor Signatures and Atomic Swaps from Scriptless Scripts 2 | =========================== 3 | 4 | This document describes adaptor signatures and multisignatures, which are the 5 | original building blocks of scriptless scripts. It also describes an atomic 6 | swap protocol using these building blocks. 7 | 8 | ### Motivation 9 | 10 | On a high level the scheme works as follows. Suppose A is trying to send coins 11 | to B on one chain, while B is sending coins to A on the other. 12 | 13 | 1. Both parties A and B put their coins into multisignature outputs on each chain 14 | which require both parties' signatures to be spent. 15 | 2. A gives B auxiallary data "adaptor signatures" which allow A to extract a 16 | discrete logarithm from a signature on one chain, and conversely to extract a 17 | signature from the same discrete logarithm on the other chain. 18 | 3. B then signs to give A her coins on one chain. 19 | 4. When A signs to take her coins, B is able to extract a discrete logarithm 20 | from her signature. 21 | 5. He uses this to form a signature on the other chain, giving him A's coins. 22 | 23 | We see that this executes an atomic exchange: if A signs, then both transactions 24 | execute; if A does not sign, then the protocol times out and neither transaction 25 | executes. 26 | 27 | However, if each chain requires signatures which use different curves, it is 28 | impossible to use the same discrete logarithm in steps 4 and 5. To see this, 29 | we need to look at the adaptor signature protocol in more detail. 30 | 31 | #### Adaptor Signatures 32 | 33 | Consider a fixed prime-order group generated by a fixed generator `G`. Let `H` 34 | be a hash function mapping from the space of bitstrings to the scalar group (of 35 | integers modulo the order of `G`). Then a _Schnorr signature_ on a message `m` 36 | with public key `P` is a pair `(s, R)` satisfying the equation 37 | 38 | ``` 39 | sG = R + H(P || R || m)P 40 | ``` 41 | Closely related, an _adaptor signature_ is a triplet `(s', R, T)` satisfying 42 | ``` 43 | s'G = T + R + H(P || R || m)P 44 | ``` 45 | It is easy to see that given a Schnorr signature `(s, R)` and adaptor signature 46 | `(s', R, T)` (notice both `R`s are the same) that the discrete logarithm of `T` 47 | can be computed as `s' - s`, since subtracting the above equations reveals 48 | `(s' - s)G = T`. 49 | 50 | Similarly, given an adaptor signature `(s', R, T)` and `t` such that `T = tG`, 51 | it is easy to compute a Schnorr signature `(s, R)` by the equation `s = s' - t`. 52 | 53 | We conclude that given an adaptor signature `(s', R, T)` with public key `P`, 54 | knowledge of a Schnorr signature with same `P` and same `R` is equivalent to 55 | knowledge of the discrete logarithm of `T`. 56 | 57 | #### Schnorr Multisignatures 58 | 59 | It is possible for two parties with public keys `P` and `Q` to interactively 60 | create a multisignature on key `P` and `Q`. The components `(s, R)` of the 61 | signature are each the sum of both parties' contributions. Importantly, in 62 | the first step of the interaction the two parties agree on `R`, and in the 63 | second step each party reveals their contribution to `s`. 64 | 65 | #### Atomic Swaps Using Adaptor Signatures 66 | 67 | On a lower level, the above scheme works as follows. We assume first that both 68 | blockchains use the same group generated by the same fixed generator `G`, and 69 | that both blockchains support Schnorr signatures. 70 | 71 | 1. Each party puts their coins into a multisignature output. They agree on an 72 | `R` for each signature that they'll eventually use to move the coins to their 73 | final destinations. 74 | 2. A chooses a random `t`, sets `T = tG`, and produces adaptor signatures in place 75 | of her contributions to `s`. Each signature uses the same `T`. She sends these 76 | to B. 77 | 3. B reveals his contribution to `s` for the signature that sends his coins to A. 78 | 4. A reveals her contribution to `s` for that signature, completing it, and 79 | publishes it to take her coins. 80 | 5. Using the adaptor signature, B learns `t` from the output of step (4), and uses 81 | it to compute A's contribution to `s` for the signature that sends her coins to 82 | him. 83 | 6. B adds his contribution to `s`, completing the signature, and publishes it to 84 | take his coins. 85 | 86 | -------------------------------------------------------------------------------- /slides/2017-05-milan-meetup/majorplayer.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/jonasnick/scriptless-scripts/2be29b284c0057e4fe7e996c12e710415263adfd/slides/2017-05-milan-meetup/majorplayer.png -------------------------------------------------------------------------------- /slides/2017-05-milan-meetup/slides.tex: -------------------------------------------------------------------------------- 1 | \def\hs{\hspace{0.4 cm}} 2 | 3 | \documentclass{beamer} 4 | 5 | \usetheme{Berlin} 6 | \usecolortheme{wolverine} 7 | \setbeamertemplate{footline}[page number] 8 | \usefonttheme{structureitalicserif} 9 | \beamertemplatenavigationsymbolsempty 10 | \setbeamertemplate{footline}{ } 11 | 12 | \title{Scriptless Scripts} 13 | \author{Andrew Poelstra} 14 | \institute{\texttt{grindelwald@wpsoftware.net}} 15 | \date{May 10, 2017} 16 | 17 | \usepackage{amsfonts,amsmath,latexsym,color,epsfig,graphicx,multirow,rotating} 18 | 19 | \begin{document} 20 | \frame{ \maketitle } 21 | 22 | \section{Scriptless Scripts} %% unclear what effect this has, but is needed for the subsections to show up 23 | 24 | \subsection{Introduction} 25 | \frame 26 | { 27 | \frametitle{``Scriptless Scripts''?} 28 | \begin{itemize} 29 | \item Scriptless scripts: magicking digital signatures so that they can only 30 | be created by faithful execution of a smart contract.\\~\\ 31 | \item Limited in power, but not nearly as much as you might expect.\\~\\ 32 | \item Mimblewimble is a blockchain design that supports only scriptless scripts, 33 | and derives its privacy and scaling properties from this. 34 | \end{itemize} 35 | } 36 | 37 | \frame 38 | { 39 | \frametitle{Why use Scriptless Scripts?} 40 | \begin{itemize} 41 | \item Bitcoin (and Ethereum, etc.) uses a scripting language to describe smart 42 | contracts and enforce their execution.\\~\\ 43 | \item These scripts must be downloaded, parsed, validated by all full nodes on 44 | the network. Can't be compressed or aggregated.\\~\\ 45 | \item The details of the script are visible forever, compromising privacy and 46 | fungibility.\\~\\ 47 | \item With scriptless scripts, the only visible things are public keys (i.e. 48 | uniformly random curvepoints) and digital signatures.\\~\\ 49 | \end{itemize} 50 | } 51 | 52 | \frame 53 | { 54 | \frametitle{Schnorr Signatures Support Scriptless Scripts} 55 | \begin{itemize} 56 | \item Schnorr signatures: signer has a keypair $(x, P)$.\\~\\ 57 | \item A signature is the public half of an ``ephemeral keypair'' $(k, R)$ 58 | along with a linear equation in $x$ and $k$. Equation depends on the 59 | hash of a message.\\~\\ 60 | \item Signature can be verified because the key-derivation map $x\mapsto P$ 61 | is also linear.\\~\\ 62 | \item ECDSA signatures (used in Bitcoin) have the same basic shape but aren't 63 | linear in $x$ and $k$, so they are less useful. 64 | \end{itemize} 65 | } 66 | 67 | \subsection{Simple Scriptless Scripts} 68 | \frame 69 | { 70 | \frametitle{Simplest (Sorta) Scriptless Script} 71 | \begin{itemize} 72 | \item \texttt{OP\_RETURN} outputs are used in Bitcoin to encode data for purpose 73 | of timestamping.\\~\\ 74 | \item Alternate: replace a public key $P$ with $P + \texttt{Hash}(P\|m)G$.\\~\\ 75 | \item Replacing the signer's public key is called ``pay to contract'' and is used 76 | by Elements and Liquid to move coins onto a sidechain.\\~\\ 77 | \item Replacing the ephemeral key is called ``sign to contract''. Used to 78 | attach a timestamp to an unrelated transaction with zero network 79 | overhead. 80 | \end{itemize} 81 | } 82 | 83 | \frame 84 | { 85 | \frametitle{Schnorr multi-Signatures are Scriptless Scripts} 86 | \begin{itemize} 87 | \item By adding Schnorr signature keys, a new key is obtained which can only 88 | be signed with with the cooperation of all parties.\\~\\ 89 | \item Can be generalized to $m$-of-$n$ by all parties giving $m$-of-$n$ 90 | linear secret shares to all others so they can cooperatively replace 91 | missing parties.\\~\\ 92 | \item (Don't try this at home: some extra precautions are needed to prevent 93 | adversarial choice of keys.) 94 | \end{itemize} 95 | } 96 | 97 | \frame 98 | { 99 | \frametitle{moSt exSpressive Scriptless Script} 100 | \begin{itemize} 101 | \item Zero-Knowledge Contingent payments (Greg Maxwell): sending coins conditioned 102 | on the recipient providing the solution to some hard problem. 103 | \item Recipient provides a hash $H$ and a zk-proof that the preimage 104 | is the encryption key to a valid solution. Sender puts coins in a script 105 | that allows claimage by revealing the preimage. 106 | \item Use the signature hash $e$ in place of $H$ and now you have a scriptless 107 | script ZKCP: a single digital signature which cannot be created without 108 | the signer solving some arbitrary (but predetermined) problem for you. 109 | \item Alternate: Banasik, Dziembowski and Malinowski (2016/451) 110 | \end{itemize} 111 | } 112 | 113 | \subsection{Simultaneous Scriptless Scripts} 114 | \frame 115 | { 116 | \frametitle{Simultaneous Scriptless Scripts} 117 | \begin{itemize} 118 | \item Executing separate transactions in an atomic fashion is traditionally 119 | done with preimages: if two transactions require the preimage to the 120 | same hash, once one is executed, the preimage is exposed so that the 121 | other one can be too.\\~\\ 122 | \item Atomic Swaps (Tier Nolan) and Lightning channels (Poon/Dryja) use this construction.\\~\\ 123 | \item ``Use the message-hash as the hash'' doesn't work here to scriptless-scriptify 124 | this because message hashes can't be fixed before a signature is created. Worse, 125 | this would link the two transactions, 126 | violating the spirit of scriptless scripts. 127 | \end{itemize} 128 | } 129 | 130 | \frame 131 | { 132 | \frametitle{Adaptor Signatures} 133 | \begin{itemize} 134 | \item Instead use another ephemeral keypair $(t, T)$ and treat $T$ as the 135 | ``hash'' of $t$.\\~\\ 136 | \item When doing a multi-signature replace the old ephemeral key $R$ with $R + T$, 137 | and now the signature $s$ must be replaced by $s + t$ to be valid.\\~\\ 138 | \item Now the original $s$ is an ``adaptor signature''. Anyone with this can 139 | compute a valid signature from $t$ or vice-versa. They can verify 140 | that it is an adaptor signature for $T$, no trust needed.\\~\\ 141 | \item One can compute an adaptor signature without knowing $t$, but they 142 | will then be unable to produce a real signature. 143 | \end{itemize} 144 | } 145 | 146 | \frame 147 | { 148 | \frametitle{Atomic (Cross-chain) Swaps} 149 | 150 | \begin{itemize} 151 | \item Parties Alice and Bob send coins on their respective 152 | chains to 2-of-2 outputs. Bob thinks of a keypair $(t, T)$ and gives $T$ to 153 | Alice.\\~\\ 154 | \item Before Alice signs to give Bob his coins, she demands adaptor signatures with $T$ 155 | from him for \emph{both} his signatures: the one taking his coins and the one giving 156 | her coins.\\~\\ 157 | \item Now when Bob signs to take his coins, Alice learns $t$ from one adaptor signature, 158 | which she can combine with the other adaptor signature to take \emph{her} coins. 159 | \end{itemize} 160 | } 161 | 162 | \frame 163 | { 164 | \frametitle{Basic Lightning} 165 | 166 | \begin{itemize} 167 | \item Suppose Alice is paying David through Bob and Carol. She produces an onion-routed 168 | path 169 | \[ \textnormal{Alice} \to \textnormal{Bob} \to \textnormal{Carol} \to \textnormal{David} \] 170 | and asks for public keys $B$, $C$ and $D$ from each participant.\\~\\ 171 | \item She sends coins to a 2-of-2 between her and Bob. She asks Bob for an adaptor signature 172 | with $B + C + D$ before signing to send him the coins.\\~\\ 173 | \item Similarly Bob sends coins to Carol, first demanding an adaptor signature with $C + D$ 174 | from her. Carol sends to David, demanding an adaptor signature with $D$. 175 | \end{itemize} 176 | } 177 | 178 | \frame 179 | { 180 | \frametitle{Features of Adaptor Signatures} 181 | \begin{itemize} 182 | \item Adaptor signatures work across blockchains, even if they use different EC groups, 183 | though this requires a bit more work.\\~\\ 184 | \item After a signature hits the chain, anyone can make up a $(t, T)$ and 185 | compute a corresponding ``adaptor signature'' for it, so the scheme is deniable. 186 | It also does not link the signatures in any way.\\~\\ 187 | \item Adaptor signatures are re-blindable, as we saw in the Lightning example. This 188 | is also deniable and unlinkable. 189 | \end{itemize} 190 | } 191 | 192 | \subsection{Conclusion} 193 | \frame 194 | { 195 | \frametitle{Sorceror's Scriptless Script} 196 | 197 | \begin{itemize} 198 | \item Mimblewimble is the ultimate scriptless script.\\~\\ 199 | \item Every input and output has a key, and a transaction signature uses a multisignature 200 | of all these keys.\\~\\ 201 | \item Transaction validity is now contained in a scriptless script; further, 202 | the signature has be used with other scriptless script constructions 203 | (atomic swaps, ZKCP, etc.) to add additional validity requirements with 204 | zero overhead or even visibility to the network. 205 | \end{itemize} 206 | } 207 | 208 | \frame 209 | { 210 | \frametitle{Open Problems} 211 | \begin{itemize} 212 | \item Preserving scriptless scripts in multisig\\~\\ 213 | \item ECDSA support\\~\\ 214 | \item Locktimes and other extrospection\\~\\ 215 | \item Formalizing/understanding limits of scriptless scripts 216 | \end{itemize} 217 | } 218 | 219 | \frame 220 | { 221 | \frametitle{~} 222 | 223 | \begin{center} 224 | Thank You 225 | ~\\~\\ 226 | Andrew Poelstra \texttt{} 227 | \end{center} 228 | } 229 | 230 | \end{document} 231 | 232 | 233 | --------------------------------------------------------------------------------