1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
|
Return-Path: <rsomsen@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 9A2FED4F
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 4 Jun 2019 11:28:39 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm1-f50.google.com (mail-wm1-f50.google.com
[209.85.128.50])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C3D9983A
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 4 Jun 2019 11:28:38 +0000 (UTC)
Received: by mail-wm1-f50.google.com with SMTP id t5so14325146wmh.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 04 Jun 2019 04:28:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:from:date:message-id:subject:to
:content-transfer-encoding;
bh=1SgacPahgxKZPiiCZDsw+rpYfE39H9B8ASc6YeWbfmA=;
b=QYS7kdsr56jfRfmgvMCfGfq5BBTC01d9dg0zH1bktZ3kwEW/L6R6PSA7r6lBHyBXQd
qa66U0s0d3cGp1KZQ7nNkGa0AqFAdapajznM9tHrl5kycp1h39OoV7cOZcmcZ1ZpQagx
H3pUTn1I7NmruWnos6uc5qFj13HY1A8m3JynOTj9gViIBXG6HAOVcBYErZpBCwzPlCZl
UjbtP/rJWX+YSuyRNzpzoXUB6M9owGeJxLXb0GHhuOTMPZpdHLqmf0ZvEG8Rr1wXfxFz
/wMMoJrpTYxPHH5iJN3B/6828oRehNkn6Yzn0muef7Y2qUtIFvIEiLqVyaXQdO9mr5wN
9ERg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:from:date:message-id:subject:to
:content-transfer-encoding;
bh=1SgacPahgxKZPiiCZDsw+rpYfE39H9B8ASc6YeWbfmA=;
b=Q9xXvhazPYcRz9n5YyD0A5sUkxUEVpUk1unNpykWcKw8PUt4BRkon0ih3B6fpdAKnY
HHidJlbYnspnby8nyE81FpIiUrXyKMeD7r7BHtq8Z7a40sscuxqvb1ukHXoJSf3bihR9
0bzD6lg8EPUelBmrQWR5ho3lTUD8tRsCZzHC1JldRGoGNv4iaQQuidaQwYW2jEyyzHmo
YnBCV5Umj6j1HJDpMFsll/6xr8HgfIf4igqtoIDmeSN77l2Z82rJAoFaGDX9UhHQIYAb
0rixeq0WtGbs0jsqpsSBe3id0YmaIZUEidqqieObdYQ7/sck/NcZr3jhhtYMbDfNZWne
n+xA==
X-Gm-Message-State: APjAAAV2s1aoQf6b/MMCd+LPouZaKPG7OPWgyh/vCt2kSwbvSuyB+Iyz
++ynnX3YIP+QIPbKA17AIBbG0IP82of7UgVoXZtSSjizIoY=
X-Google-Smtp-Source: APXvYqy4Z/CNXVHSdP5R/1kc3B7hvg9Zc87chyQ2EWnahjUEOMwLXXZi+Cu+j6PbLTpuqASNkZMMZYfSNM2EjKfGRGk=
X-Received: by 2002:a1c:2e09:: with SMTP id u9mr7754933wmu.137.1559647717071;
Tue, 04 Jun 2019 04:28:37 -0700 (PDT)
MIME-Version: 1.0
From: Ruben Somsen <rsomsen@gmail.com>
Date: Tue, 4 Jun 2019 13:28:26 +0200
Message-ID: <CAPv7Tjb11yRix4ts76Rqz08yj=SOA1LBzq5E7gkxcrS26Sp=Ng@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,URI_NOVOWEL
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Tue, 04 Jun 2019 11:39:10 +0000
Subject: [bitcoin-dev] Formalizing Blind Statechains as a minimalistic blind
signing server
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Jun 2019 11:28:39 -0000
Hi everyone,
For those who are unfamiliar, Statechains enable the transfer UTXOs
off-chain with the help of a Statechain entity (trusted server(s))
without giving them full custodial control over your coins [0]. At
Scaling Bitcoin =E2=80=9818 [1] I briefly mentioned utilizing blind signatu=
res
[2] to make the entity unaware of what it's signing. I now think this
is the more interesting approach. The functionality can be described
fairly elegantly as follows.
Blind signing server with two functions users can call:
// Start new signature chain
(1) requestNewKey(userPubkey) =3D> returns a new serverPubkey and
registers it to userPubkey
// Extend existing chain
(2) requestBlindSig(userSignature, blindedMessage, nextUserPubkey) =3D>
returns blindSignature, registers the serverPubkey to nextUserPubkey
The resulting output is a public ECC chain (one blindSignature per
user, one chain per serverPubkey) of blindly signed messages,
requested by users (1, 2, 3, etc.):
userSignature1(blindedMessage1, userPubkey2) =3D> blindSignature1
userSignature2(blindedMessage2, userPubkey3) =3D> blindSignature2
etc.
Assuming the server is honest (more on this below), we can use it to
transfer over the signing rights of a private key without actually
changing the key itself.
The functionality is general and therefore suitable for more than just
Bitcoin, but let's walk through the primary envisioned use case where
we transfer the ownership of a Bitcoin UTXO off-chain. Note that the
server is kept completely unaware that it's handling a BTC
transaction, since it's signing blindly:
- B uses function (1) with userPubkey =3D B to request serverPubkey A
- B then generates transitory key X, and creates a single MuSig key AX
(key X is called =E2=80=9Ctransitory=E2=80=9D because its private key will =
later be passed on)
- B prepares tx1: 1BTC to AX (he doesn't send it yet)
- B creates tx2: an eltoo tx [3] that assigns the 1BTC back to B (off-chain=
)
- B uses (2) with nextUserPubkey =3D B and blindedMessage =3D tx2
- B sends tx1 to the blockchain and waits for it to confirm
- B receives a key from C in order to prepare a payment
- B creates tx3: an eltoo tx (with higher priority) with 1BTC to C (off-cha=
in)
- B uses (2) with nextUserPubkey =3D C and blindedMessage =3D tx3
- B passes the private key of X (the transitory key) on to C
- C takes blinded tx2 and tx3 from the public server output and
unblinds them with X
- C only accepts the payment if everything is in order [4]
Even if the server goes offline, C can still get the money by sending
tx3 to the blockchain.
A and B can collude to take the money from C, but since all instances
of userSignature and blindSignature are published openly, cheating is
publicly detectable (e.g. the server signed two messages from B
instead of one).
Trust can be distributed by turning the server into a multisig
threshold key, so serverPubkey A becomes e.g. 8-of-12 multisig. This
means security can be on par with federated sidechains [5], and is
similar to how ZmnSCPxj replaced the escrow key with a federation in
=E2=80=9CSmart Contracts Unchained=E2=80=9D [6].
Lastly, by utilizing adaptor signatures [7], the userSignature can be
tied to the blindSignature. In fact, this can be done for any number
of signatures, allowing multiple signing sessions to take place
atomically [8]. This denies the server the ability to selectively
publish one signature and not the other, allowing safe atomic swaps
via the server.
Essentially, anything that requires UTXO ownership can be achieved
off-chain via Blind Statechains. Coinjoin, Lightning channel
opening/adjusting/closing, Discreet Log Contract style bets [9],
cross-chain atomic swaps, etc. Since the blind signing server
functionality is non-specific to Bitcoin, it'll be useful for
non-cryptocurrency related use cases as well, but I have not given
this a lot of thought.
I also recently published a more high-level overview of Statechains
here, which may be of interest:
https://medium.com/@RubenSomsen/statechains-non-custodial-off-chain-bitcoin=
-transfer-1ae4845a4a39
-- Ruben Somsen
[0] Statechains paper:
https://github.com/RubenSomsen/rubensomsen.github.io/blob/master/img/statec=
hains.pdf
[1] Statechains Scaling Bitcoin =E2=80=9818: http://youtu.be/FI9cwksTrQs?t=
=3D47m36s
Transcript:
http://diyhpl.us/wiki/transcripts/scalingbitcoin/tokyo-2018/statechains/
[2] Blind signatures, Jonas Nick:
http://diyhpl.us/wiki/transcripts/building-on-bitcoin/2018/blind-signatures=
-and-scriptless-scripts/
[3] eltoo: https://blockstream.com/eltoo.pdf
[4] Similar to client-side validation, Peter Todd:
https://diyhpl.us/wiki/transcripts/scalingbitcoin/milan/client-side-validat=
ion/
[5] Sidechains Appendix A, federated peg: https://blockstream.com/sidechain=
s.pdf
[6] Smart Contracts Unchained ,ZmnSCPxj:
https://zmnscpxj.github.io/bitcoin/unchained.html
[7] Adaptor signatures, Andrew Poelstra:
http://diyhpl.us/wiki/transcripts/layer2-summit/2018/scriptless-scripts/
[8] Adam Gibson (Waxwing) separately made a similar observation on his
blog: https://joinmarket.me/blog/blog/multiparty-s6/
[9] Discreet Log Contracts, Thaddeus Dryja: https://adiabat.github.io/dlc.p=
df
|
