summaryrefslogtreecommitdiff
path: root/01/296c4d936706d3b9ff3db0fc94800f5b9d0b54
blob: 556aceb978c52fd5e14f430638c16063d4811bc5 (plain)
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
233
234
235
236
237
238
239
240
241
242
243
244
245
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 09702C07FF
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  4 Apr 2020 12:07:38 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by whitealder.osuosl.org (Postfix) with ESMTP id EE92587C74
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  4 Apr 2020 12:07:37 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from whitealder.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id ppyM5UkcbcJK
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  4 Apr 2020 12:07:35 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40132.protonmail.ch (mail-40132.protonmail.ch
 [185.70.40.132])
 by whitealder.osuosl.org (Postfix) with ESMTPS id 67E1387C5C
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  4 Apr 2020 12:07:35 +0000 (UTC)
Date: Sat, 04 Apr 2020 12:07:28 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
 s=default; t=1586002052;
 bh=7d8ym44ss9L0fpOPRMFeAbX1AsDs054B/ZX6iy/Xd/8=;
 h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From;
 b=Uy89TeyTBLU2Ou5w80lODmk7IIJuKi+rq6H9KgIGOUCrZ4AdRxy3+hq7u7f7HrGc4
 Q/X6l4ujMRp3b8v0H+YLvaWPGxZk25SzQipaYIv3zO2sebQ+a6tiz5hxQt4VIHiOFA
 F+J+P4UYi4MNEJgTk7PvbR1POhG+Tn+UywPFcgUQ=
To: Nadav Kohen <nadav@suredbits.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <fTTGFnQW00u5V8SFA29RIMEsAPMS6MojiCdFDCXVHGCE5GRp31ilw5xXeuMoZVREDCWvm-N_KFvPvPZ1qfgnCE6hUT8O1Lh6FZIYzrmuOGM=@protonmail.com>
In-Reply-To: <CALGTLwOu+R6ZmzYb4ESc9kjgrpspmmdWogF_Z=msQB8dTqD0xQ@mail.gmail.com>
References: <CAJvkSseW9OZ50yQiS7e0zt9tQt4v9aoikgGs_54_kMN-ORkQgw@mail.gmail.com>
 <20200331103508.asvxujkhtifj6n7i@ganymede>
 <CAJvkSsfWoTTUOUYjQDrP-xrwB8FwAGUaDKSrYX3=-+wAE3yDLA@mail.gmail.com>
 <CAJvkSseMqFUJD7rj1AAZPMy0Hf6tufkvrHFgzsViPEirWMWx_A@mail.gmail.com>
 <CALGTLwOu+R6ZmzYb4ESc9kjgrpspmmdWogF_Z=msQB8dTqD0xQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Tom Trevethan <tom@commerceblock.com>
Subject: Re: [bitcoin-dev] Statechain implementations
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
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: Sat, 04 Apr 2020 12:07:38 -0000

Good morning Nadav,

Indeed.

It seems to me that practical deployments of statechains requires the state=
chain operator to be a trusted federation, possibly a k-of-n.
This is slightly better than a federated sidechain because the money can al=
ways be reclaimed on the blockchain layer very quickly in case of a loss of=
 trust in the federation.
If the k-of-n is arranged in such a way that the signers can be identified =
(such as by use of old `OP_CHECKMULTISIG` or some combination of the propos=
ed `OP_CHECKSIGADD`) then it has the same "auditability", i.e. you can iden=
tify the pseudonyms of the members who cheated (which is not worth much, as=
 getting a new pseudonym is trivial).

It is helpful to remember that a k-of-n federation can only be trusted if y=
ou have full trust in at least (n - k + 1) members of the federation.

Regards,
ZmnSCPxj

> Hey all,
>
> So my main concern with the proposal as written is that the Statechain En=
tity (SE) can untraceably=C2=A0scam its users with the following attack:
> 1) Buy the utxo (have it transferred to a key it knows), this first step =
can be skipped if the utxo was created by the SE.
> 2) Transfer the UTXO to someone else, let it be for however long
> 3) When it wishes to steal the UTXO, the SE now knows its own shard s_n a=
nd it=C2=A0 knows the full private key, x, from when it owned the UTXO (and=
 had both shards), and so it can compute x/s_n =3D the current users shard.=
 It can then sign for the current user, and forge a state transition to a k=
ey it owns before spending the UTXO on chain.
>
> The main problem here is that the user who had their funds stolen cannot =
prove to anyone that this has happened since the attack compromises their k=
ey.
> That said, I think this problem is easily fixed by adding a new user key =
to the protocol with which they must sign in order for the transfer to be c=
onsidered valid on the state chain. This way, if the SE wishes to steal the=
 funds (which they still can), at least it is traceable/provable that this =
SE is not trustworthy as there is no evidence of a valid transfer for the f=
unds that have been stolen.
>
> Best,
> Nadav
>
> On Thu, Apr 2, 2020 at 7:22 PM Tom Trevethan via bitcoin-dev <bitcoin-dev=
@lists.linuxfoundation.org> wrote:
>
> > Thanks for all of the input and comments - I do now think that the decr=
ementing nSequence relative locktime backup system with kick-off transactio=
n is the way to go, including a fee penalty via CPFP to disincentivise=
=C2=A0DoS, as suggested.=C2=A0
> > I have started a more detailed document specifying the proposed protoco=
l in more detail:=C2=A0https://github.com/commerceblock/mercury/blob/master=
/statechains.md=C2=A0which includes improvements to the transfer=C2=A0mecha=
nism (and an explanation of how this can be used to transfer/novate positio=
ns in DLCs). Always happy to get more feedback or PRs.=C2=A0
> >
> > Tom
> >
> > On Tue, Mar 31, 2020 at 12:41 PM Tom Trevethan <tom@commerceblock.com> =
wrote:
> >
> > > Hi David,
> > >
> > > Just for clarity, I left nChain over 2 years ago (having worked there=
 since 2016). While there, I (along with other researchers) were given free=
 rein to work on any ideas we wanted to. I had been interested in the scali=
ng of Bitcoin off-chain, and this was one of several things I spent time on=
 (including things like sidechains,=C2=A0pegs and threshold signatures). Th=
is patent application came out of an idea I had to transfer ownership of UT=
XOs off-chain that has some similarities to the statechains proposal, which=
 has shown there is interest and demand for this type of system.=C2=A0
> > >
> > > Although I think the existence of this application is something to be=
 mindful of, there are several important things to note:
> > >
> > > 1. Although there are similarities, the current ideas are significant=
ly different to those in the application.=C2=A0
> > > 2. The key transfer protocol as described in the application is not s=
ecure (for several reasons, including as discussed above, by Albert and Bob=
 etc.) - and a different mechanism is required.=C2=A0
> > > 3. Decrementing timelocks (as suggested in the application) are prior=
 art (Decker-Wattenhofer 2015), and in any case any implementation will mos=
t likely use an 'invalidation tree' relative locktime backup mechanism for =
open-ended UTXOs.=C2=A0
> > > 4. The patent application has not been granted (it was made in May 20=
17) and the international search report rejected it on the grounds of prior=
 art.=C2=A0
> > >
> > > Tom
> > >
> > > On Tue, Mar 31, 2020 at 11:36 AM David A. Harding <dave@dtrt.org> wro=
te:
> > >
> > > > On Wed, Mar 25, 2020 at 01:52:10PM +0000, Tom Trevethan via bitcoin=
-dev wrote:
> > > > > Hi all,
> > > > >
> > > > > We are starting to work on an implementation of the statechains c=
oncept (
> > > > > https://medium.com/@RubenSomsen/statechains-non-custodial-off-cha=
in-bitcoin-transfer-1ae4845a4a39),
> > > > >
> > > > > [...]
> > > > > There are two main modifications we are looking at:
> > > > > [...]
> > > > >
> > > > > 2. Replacing the 2-of-2 multisig output (paying to statechain ent=
ity SE key
> > > > > and transitory key) with a single P2(W)PKH output where the publi=
c key
> > > > > shared between the SE and the current owner. The SE and the curre=
nt owner
> > > > > can then sign with a 2-of-2 ECDSA MPC.
> > > >
> > > > Dr. Trevethan,
> > > >
> > > > Would you be able to explain how your proposal to use statechains w=
ith
> > > > 2P-ECDSA relates to your patent assigned to nChain Holdings for "Se=
cure
> > > > off-chain blockchain transactions"?[1]=C2=A0
> > > >
> > > > =C2=A0 =C2=A0 [1] https://patents.google.com/patent/US20200074464A1
> > > >
> > > > Here are some excerpts from the application that caught my attentio=
n in
> > > > the context of statechains in general and your proposal to this lis=
t in
> > > > particular:
> > > >
> > > > > an exchange platform that is trusted to implement and operate the
> > > > > transaction protocol, without requiring an on-chain transaction. =
The
> > > > > off-chain transactions enable one computer system to generate mul=
tiple
> > > > > transactions that are recordable to a blockchain in different
> > > > > circumstances
> > > > >
> > > > > [...]
> > > > >
> > > > > at least some of the off-chain transactions are valid for recordi=
ng on
> > > > > the blockchain even in the event of a catastrophic failure of the
> > > > > exchange (e.g., exchange going permanently off-line or loosing ke=
y
> > > > > shares).
> > > > >
> > > > > [...]
> > > > >
> > > > > there may be provided a computer readable storage medium includin=
g a
> > > > > two-party elliptic curve digital signature algorithm (two-party E=
CDSA)
> > > > > script comprising computer executable instructions which, when
> > > > > executed, configure a processor to perform functions of a two-par=
ty
> > > > > elliptic curve digital signature algorithm described herein.
> > > > >
> > > > > [...]
> > > > >
> > > > > In this instance the malicious actor would then also have to coll=
ude
> > > > > with a previous owner of the funds to recreate the full key. Beca=
use
> > > > > an attack requires either the simultaneous theft of both exchange=
 and
> > > > > depositor keys or collusion with previous legitimate owners of fu=
nds,
> > > > > the opportunities for a malicious attacker to compromise the exch=
ange
> > > > > platform are limited.
> > > >
> > > > Thank you,
> > > >
> > > > -Dave
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev