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
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 972B02F
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 6 Jun 2019 06:32:13 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40136.protonmail.ch (mail-40136.protonmail.ch
[185.70.40.136])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 64E6234F
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 6 Jun 2019 06:32:12 +0000 (UTC)
Date: Thu, 06 Jun 2019 06:31:45 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=default; t=1559802711;
bh=EFVEpMyZGMvSOG3+Hih/Ph+AQEpob3wcpiMOWSlO49c=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:
Feedback-ID:From;
b=AMhp/SUuBF2f7JpbXYNdmyCz9HC5hjz+lRnaM9+TzRiFKWGY86f3dI/iYSuGyl3h9
hoWYEpTygRvBsozfjYmhKqRczPkyFzNERnSSlOEL2JiJE0zytPBnSwuwI0MniWniie
n571SaTGzmFc1sv7b9HdzIsF8jnZm3fxcbYwf54Q=
To: Ruben Somsen <rsomsen@gmail.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <L118b6Auac7OxL9DmyvXmFldcnSvb1xU807qtsPt6fGY0-fpg55U5VmEdAgC1T87r274UuqZ-iS0yDNBhZfvhsEW3ZHhdl1eb5Cg4I04ckE=@protonmail.com>
In-Reply-To: <CAPv7TjYXwr7BLtMqh09QV6b_EZGjBBHw+pdq=3k90KV4j1hNJQ@mail.gmail.com>
References: <CAPv7Tjb11yRix4ts76Rqz08yj=SOA1LBzq5E7gkxcrS26Sp=Ng@mail.gmail.com>
<8XXMxGjO1b4bM90Khn3tl63lPEBVJ0at9iJa1gZrZbz7NMaA7ANITVbHOJkctvJlxDUwR6H6dhG34Ko8phlu4_h_GcSXvyuYzPyW4ukEdMY=@protonmail.com>
<CAPv7TjYXwr7BLtMqh09QV6b_EZGjBBHw+pdq=3k90KV4j1hNJQ@mail.gmail.com>
Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, FROM_LOCAL_NOVOWEL,
RCVD_IN_DNSWL_LOW 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: Thu, 06 Jun 2019 06:54:47 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [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: Thu, 06 Jun 2019 06:32:13 -0000
Good morning Ruben,
Sent with ProtonMail Secure Email.
=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me=
ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90
On Thursday, June 6, 2019 1:20 PM, Ruben Somsen <rsomsen@gmail.com> wrote:
> Hi ZmnSCPxj,
>
> Thank you for your comments.
>
> > Of note, is that a Decker-Russell-Osuntokun construction ("eltoo") is n=
ot strictly required. We can still make use of the Decker-Wattenhofer const=
ruction instead.
>
> Yes, an early draft (from before the eltoo paper) was using that
> construction, but it seemed quite unwieldy. Timelocks have to be long,
> nesting adds more transactions, channels expire faster with more use,
> and tx fee handling is more complex. But you make a good point that if
> SIGHASH_ANYPREVOUT turns out to be too controversial (or for
> supporting older altcoins), this would be a potential fallback.
The lack of `SIGHASH_ANYPREVOUT` does make it difficult to operate a channe=
l factory.
Factory operations would still require the signatures of all participants, =
but once a participant has released its signature, it cannot be sure whethe=
r its channels should be rooted on the previous factory state or the next (=
i.e. the [Stale Factory problem](https://lists.linuxfoundation.org/pipermai=
l/lightning-dev/2019-April/001974.html) ).
This is fixable if we use `SIGHASH_ANYPREVOUT` on channel update transactio=
ns.
Alternately without that flag we can run channels rooted on both the previo=
us and next factory states, which actually is similar to what we need to do=
for splice-in (so we could reuse that code, possibly).
>
> > This still admits the possibility of an exit scam once a few "big enoug=
h" swaps are in position to be stolen, trading off earned reputation for co=
ld-stored cash.
>
> That is correct. The worst case for security still comes down to
> having to trust the federation, but the transitory key, as well as the
> blind signature scheme, does add an interesting layer of separation
> that makes it essentially "non-custodial". The article I linked has
> more on this.
Of note is that this is roughly the same as the common key in my own Smart =
Contracts Unchained.
If `SIGHASH_ANYPREVOUT` ends up requiring a chaperone signature, it seems t=
his transitory/common key can be used for the chaperone.
Going further on Smart Contracts Unchained, I observe that the below:
> // Start new signature chain
> (1) requestNewKey(userPubkey) =3D> returns a new serverPubkey and registe=
rs it to userPubkey
> // Extend existing chain
> (2) requestBlindSig(userSignature, blindedMessage, nextUserPubkey) =3D> r=
eturns blindSignature, registers the serverPubkey to nextUserPubkey
Can be generalized, such that instead of pubKeys and their signatures, we h=
ave validation programs and their witnesses.
For example, instead of userPubkey and nextUserPubkey we have a userScript =
and nextUserScript, with userSignature replaced by a userWitness.
This would be nearer to my own Smart Contracts Unchained, though without co=
mmitting to the smart contract onchain, only offchain in the server.
>
> Cheers,
> Ruben
>
> On Thu, Jun 6, 2019 at 2:09 AM ZmnSCPxj ZmnSCPxj@protonmail.com wrote:
>
> > Good morning Ruben,
> >
> > > At
> > > Scaling Bitcoin =E2=80=9818 [1] I briefly mentioned utilizing blind s=
ignatures
> > > [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.
> >
> > I agree.
> > I had no interest in Statechains at all before, but now that you have b=
lind signing servers, this is significantly more interesting.
> >
> > > 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 jus=
t
> > > 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 (o=
ff-chain)
> > >
> >
> > Of note, is that a Decker-Russell-Osuntokun construction ("eltoo") is n=
ot strictly required.
> > We can still make use of the Decker-Wattenhofer construction instead.
> > The core of Decker-Wattenhofer is a sequence of decrementing-`nSequence=
` update systems.
> > Number of maximum updates is limited by the starting `nSequence`, howev=
er if we put an update system inside an update system, we can "reset" the `=
nSequence` of the inner update system by updating the outer update system.
> > We can chain this concept further and add more update systems nested in=
side update systems to gain more leverage from the maximum relative wait ti=
me.
> > As we expect fewer updates are needed for statechains than e.g. actual =
Lightning channels (your given CoinSwap protocol is "only" two updates, for=
instance) this is usually a good tradeoff,
> > It is thus possible to use statechains in case `SIGHASH_ANYPREVOUT` is =
too controversial to get into Bitcoin, provided Schnorr (definitely uncontr=
oversial) does get into Bitcoin.
> >
> > > A and B can collude to take the money from C, but since all insta=
nces
> > > of userSignature and blindSignature are published openly, cheatin=
g is
> > > publicly detectable (e.g. the server signed two messages from B
> > > instead of one).
> > >
> >
> > This still admits the possibility of an exit scam once a few "big enoug=
h" swaps are in position to be stolen, trading off earned reputation for co=
ld-stored cash.
> >
> > > Trust can be distributed by turning the server into a multisig
> > > threshold key, so serverPubkey A becomes e.g. 8-of-12 multisig. T=
his
> > > means security can be on par with federated sidechains [5], and i=
s
> > > similar to how ZmnSCPxj replaced the escrow key with a federation=
in
> > > =E2=80=9CSmart Contracts Unchained=E2=80=9D [6].
> > >
> >
> > This makes me happy.
> > Regards,
> > ZmnSCPxj
|
