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
|
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 BAA18CAE
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 6 Jun 2019 00:09:34 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40135.protonmail.ch (mail-40135.protonmail.ch
[185.70.40.135])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BBCDA711
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 6 Jun 2019 00:09:33 +0000 (UTC)
Date: Thu, 06 Jun 2019 00:09:28 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=default; t=1559779771;
bh=aRDeJ4pIktwFveeKhMTnkDw5WK39Q3UokC5gY9E5aos=;
h=Date:To:From:Reply-To:Subject:In-Reply-To:References:Feedback-ID:
From;
b=v4sbaeGkTbpoIR12naiVxduhSXjRZch7iMNMTKpg2Q06DIbgRaXOvn1qfgqNDKRq3
JFnBL7hzlCMEIZUEiPmqiyK+2lMZnIEwUDsEcF3aGHP76FDBbIqS9k/kN/bt2SyrWp
wja9CsBqup9pqjsh2mX5pZkxYDNSsZY+458n0Zlc=
To: Ruben Somsen <rsomsen@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <8XXMxGjO1b4bM90Khn3tl63lPEBVJ0at9iJa1gZrZbz7NMaA7ANITVbHOJkctvJlxDUwR6H6dhG34Ko8phlu4_h_GcSXvyuYzPyW4ukEdMY=@protonmail.com>
In-Reply-To: <CAPv7Tjb11yRix4ts76Rqz08yj=SOA1LBzq5E7gkxcrS26Sp=Ng@mail.gmail.com>
References: <CAPv7Tjb11yRix4ts76Rqz08yj=SOA1LBzq5E7gkxcrS26Sp=Ng@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
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 00:09:34 -0000
Good morning Ruben,
> At
> Scaling Bitcoin =E2=80=9818 [1] I briefly mentioned utilizing blind signa=
tures
> [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 blind=
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 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-c=
hain)
Of note, is that a Decker-Russell-Osuntokun construction ("eltoo") is not *=
strictly* required.
We can still make use of the Decker-Wattenhofer construction instead.
The core of Decker-Wattenhofer is a sequence of decrementing-`nSequence` up=
date systems.
Number of maximum updates is limited by the starting `nSequence`, however i=
f we put an update system inside an update system, we can "reset" the `nSeq=
uence` of the inner update system by updating the outer update system.
We can chain this concept further and add more update systems nested inside=
update systems to gain more leverage from the maximum relative wait time.
As we expect fewer updates are needed for statechains than e.g. actual Ligh=
tning channels (your given CoinSwap protocol is "only" two updates, for ins=
tance) 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 uncontrover=
sial) does get into Bitcoin.
> 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).
This still admits the possibility of an exit scam once a few "big enough" s=
waps are in position to be stolen, trading off earned reputation for cold-s=
tored cash.
>
> 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].
This makes me happy.
Regards,
ZmnSCPxj
|
