Skip to content

Commit 2be29b2

Browse files
apoelstraapoelstra
committed
initial commit
0 parents  commit 2be29b2

File tree

4 files changed

+326
-0
lines changed

4 files changed

+326
-0
lines changed

‎.gitignore‎

Lines changed: 9 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,9 @@
1+
*.aux
2+
*.bbl
3+
*.log
4+
*.nav
5+
*.out
6+
*.pdf
7+
*.snm
8+
*.swp
9+
*.toc

‎md/atomic-swap.md‎

Lines changed: 85 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,85 @@
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+

‎slides/2017-05-milan-meetup/majorplayer.png‎

16.3 KB
Loading

‎slides/2017-05-milan-meetup/slides.tex‎

Lines changed: 232 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,232 @@
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{[email protected]}}
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{<[email protected]>}
227+
\end{center}
228+
}
229+
230+
\end{document}
231+
232+

0 commit comments

Comments
 (0)