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
|
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 262D9F16
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 14 Jun 2019 07:18:43 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm1-f43.google.com (mail-wm1-f43.google.com
[209.85.128.43])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 29681E5
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 14 Jun 2019 07:18:42 +0000 (UTC)
Received: by mail-wm1-f43.google.com with SMTP id z23so1155792wma.4
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 14 Jun 2019 00:18:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc:content-transfer-encoding;
bh=jSqb8H0reApalYxr1PxueWSeFBOR69kqTDCti3Z7Be0=;
b=B9HhDM3pgtQhZC+ZcW8qsKHWdPQH7a6MMV8hK467YjwvAAzVUxV6nTbDnThu6zzHhY
bPDZgzetTrOatabKjrV+KUIynkssBkiKQS1neoPy7vIheX0ddWzF/tFMC/Dr0Vu0ChFj
wKBjZSJX0SJFXmSriAlb+2Xxbxis8WS44x5ms0ejs1Q9gGua08flWHn8mlCgVN7dMjdo
eJ/YHUWRM1y9g9ZM3b/s/+toLuibFLo+A7p8BllMHDyuns3+6kme9csclMpah/B1GGud
tT+3OTX+ah97EL7gkZILlbA8TYP+MJLHvmRrlAtl8uxzmwqKhIs0weF95nmq8tR703BM
NU2A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:cc:content-transfer-encoding;
bh=jSqb8H0reApalYxr1PxueWSeFBOR69kqTDCti3Z7Be0=;
b=sTnBwVQshseI5cS8rA/4LsVLTsfzW+ZVWe+/x0D418DqJSda2c8JnDOCtEIXeTI0Zr
pGBnUombiz9kDrLMH99TtOWWUeO5dyOXEzL7gUPelIYTKTQ5jmpAcFl9WFPqtcfBvjDK
HfzKZFPXTGjhcJ3kGWII9I2J/80A9OoX0hoZ3NLu+2x3CO55X9M4AjdvSEaVxtH07NJ1
czbwCpYpqPmxkqMXnDVSXfVb7Cob9zIxB4YU/5rQmowj2Ob/QfEzs+GOjnFkNU9wau/N
N92uC9TpxmJqL++650Yuy7iozwqpOnzEGAzIiUFfwlxvbQtD4iMdQ/gyeDCLcYXx0JoZ
DPeQ==
X-Gm-Message-State: APjAAAW3ayv6ay89h1kvRuMBSwgF1QGetLWVwBGX3dcSqoNRVJjtBjDY
jtAUKNaafVSAl6Nkc1aTyjsozscvh40AF8RW8sot73uD
X-Google-Smtp-Source: APXvYqzrJf3h6/CfMxzXRyiFA5RG5zMQHndTG+hFaw08F2KlzUSY9UffujwPc9+GNJ8z0kQS5b6DpU9/55EQJORzIY8=
X-Received: by 2002:a1c:2e09:: with SMTP id u9mr6669908wmu.137.1560496720471;
Fri, 14 Jun 2019 00:18:40 -0700 (PDT)
MIME-Version: 1.0
References: <CAPv7Tjb11yRix4ts76Rqz08yj=SOA1LBzq5E7gkxcrS26Sp=Ng@mail.gmail.com>
<8XXMxGjO1b4bM90Khn3tl63lPEBVJ0at9iJa1gZrZbz7NMaA7ANITVbHOJkctvJlxDUwR6H6dhG34Ko8phlu4_h_GcSXvyuYzPyW4ukEdMY=@protonmail.com>
<CAPv7TjYXwr7BLtMqh09QV6b_EZGjBBHw+pdq=3k90KV4j1hNJQ@mail.gmail.com>
<L118b6Auac7OxL9DmyvXmFldcnSvb1xU807qtsPt6fGY0-fpg55U5VmEdAgC1T87r274UuqZ-iS0yDNBhZfvhsEW3ZHhdl1eb5Cg4I04ckE=@protonmail.com>
<CAPv7Tja9BCtzh=yjOX0nCK8E2K2JRpp7huCw_AwBXVM6J3+VfQ@mail.gmail.com>
<xc6X8fAM-1Aow8xjcyCFL7Z5r0s7Vmr_FFo1Mjoz5Hh12I0_6VAU-mlX9nj0aNZjJZ3qq5ehICalNeOqgEh1ziaZiF-Zvz7s42HGK-LXoM0=@protonmail.com>
In-Reply-To: <xc6X8fAM-1Aow8xjcyCFL7Z5r0s7Vmr_FFo1Mjoz5Hh12I0_6VAU-mlX9nj0aNZjJZ3qq5ehICalNeOqgEh1ziaZiF-Zvz7s42HGK-LXoM0=@protonmail.com>
From: Ruben Somsen <rsomsen@gmail.com>
Date: Fri, 14 Jun 2019 09:18:27 +0200
Message-ID: <CAPv7TjZhXBfUB7MBY=gnxoUr8r0fV_usOfiuEeVnDYSPL5xTGw@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=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM,
RCVD_IN_DNSWL_NONE 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: Fri, 14 Jun 2019 07:51:25 +0000
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: Fri, 14 Jun 2019 07:18:43 -0000
Hi ZmnSCPxj,
>Basically, the "Stale Factory" and "Broken Factory" problems.
I see, I'll have to read up on those.
>Combining it via MuSig is probably best, as the server is now unable to re=
cognize even the pubkey (assuming it never is informed `X`).
Yes, that's the current thinking. See also:
https://twitter.com/SomsenRuben/status/1138199578996555784 (sorry no
time to make a gist)
>As the server is blinded, it cannot determine anything about the message b=
eing signed.
Yes, you could build a non-blind variant with scripting, but that
would be quite different.
>a simple scripting that allows "if somebody provides x of H(x) plus signat=
ure A, sign a blinded message M1, else if after 2:30PM PST on Jun 24 2019 i=
f somebody provides signature of B, sign a blinded message M2" could still =
potentially be useful
I believe adaptor signatures are enough to replace hashing. A time
lock could potentially be added with some very basic scripting, but my
feeling is still that this is better avoided. We're essentially
relying on the Bitcoin blockchain for that, because the off-chain
transactions can be encumbered by any script you like.
>anything that can be done with a UTXO onchain, can also be done offchain v=
ia any updateable offchain cryptocurrency system
You're right that I didn't properly point to the key difference, which
is transfer of UTXO ownership. Other off-chain systems don't allow you
to go from e.g. 2-of-2 to 3-of-3, but of course we're adding a
federation in order to make this happen, so it's not exactly a fair
comparison.
>(I should probably look up the authors of the Statechains paper to make my=
naming convention consistent)
That would be "Somsen". I am the sole author.
>By presenting those "further transactions" to the offchain system, we can =
provide an argument that the offchain system can just "append" those "furth=
er transactions" to the existing unilateral-case transactions, then cut-thr=
ough the further transactions on its next update
That's an interesting way of looking at it. This is currently achieved
in Statechains by making the top-level on the Statechain N-of-N, so
all participants of the "further transactions" have to agree in order
to achieve full cut-through on the Statechain. In practice this would
mean that the final signature requested from the server is a
"cooperative close".
Cheers,
Ruben
On Thu, Jun 13, 2019 at 3:22 AM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:
>
> Good morning Ruben,
> > > an early draft
> >
> > I meant an early draft of Statechains, sorry if that was confusing.
> > But yes, it's essentially no different from channel factories without
> > eltoo.
>
> Sorry, I am referring to current issues with channel factories, which wer=
e not addressed in the original channel factories paper.
> Basically, the "Stale Factory" and "Broken Factory" problems.
> Broken factory seems unsolvable.
> Stale factory is fixable if the channels within the factory use `SIGHASH_=
NOINPUT` (assuming it gets into Bitcoin) for all unilateral paths (use `SIG=
HASH_ALL` for cooperative paths).
>
> >
> > > If `SIGHASH_ANYPREVOUT` ends up requiring a chaperone signature, it s=
eems this transitory/common key can be used for the chaperone.
> >
> > That is a good point. One thing I have not yet fully analysed are the
> > privacy considerations. Perhaps we don't want to reveal X on-chain.
>
> On reflection, probably best not to.
> It requires a script that reveals the pubkeys.
> And it now becomes possible for the server to monitor the blockchain for =
revelation of server pubkey in a spend path.
> This will let the server know, after-the-fact, that it was signing blockc=
hain transactions.
> This might not let it preemptively censor or otherwise disrupt, but it *c=
ould* sell the private fact that a statechain was used.
> Combining it via MuSig is probably best, as the server is now unable to r=
ecognize even the pubkey (assuming it never is informed `X`).
>
> >
> > > This would be nearer to my own Smart Contracts Unchained
> >
> > Adding scripting is not my preferred approach. The beauty of the
> > system is that the server doesn't evaluate any scripts whatsoever.
>
> On reflection, this is probably best.
> As the server is blinded, it cannot determine anything about the message =
being signed.
>
> On the other cognition sub-agent, however, a simple scripting that allows=
"if somebody provides x of H(x) plus signature A, sign a blinded message M=
1, else if after 2:30PM PST on Jun 24 2019 if somebody provides signature o=
f B, sign a blinded message M2" could still potentially be useful, and migh=
t allow "programmable escrow" like I imagine Smart Contracts Unchained coul=
d allow.
>
> >
> > That being said, Smart Contracts Unchained (SCU) can be inserted quite
> > elegantly as a separate smart contracting layer.
> >
> > The observation is that anything that can be done with a UTXO
> > on-chain, can also be done off-chain via Statechains, including SCU.
>
> The Real (TM) observation is that anything that can be done with a UTXO o=
nchain, can also be done offchain via any updateable offchain cryptocurrenc=
y system, whether Statechains, Spillman, Decker-Wattenhofer, Poon-Dryja, or=
Decker-Russell-Osuntokun.
> (I should probably look up the authors of the Statechains paper to make m=
y naming convention consistent)
>
> One might observe that any updateable offchain cryptocurrency system wort=
h its salt would have some way of unilaterally dropping transactions onchai=
n.
> Those transactions would create new UTXOs that can be spent by further tr=
ansactions.
> By presenting those "further transactions" to the offchain system, we can=
provide an argument that the offchain system can just "append" those "furt=
her transactions" to the existing unilateral-case transactions, then cut-th=
rough the further transactions on its next update (i.e. delete the current =
UTXOs spent and insert the new UTXOs introduced by the "further transaction=
s").
> (In the case of Statechains, you would present this argument to the signe=
rs of the latest `userPubKey`, not to the server, who is unaware of the sem=
antics of what it is signing)
>
>
> Regards,
> ZmnSCPxj
|
