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
|
Return-Path: <orlovsky@protonmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id CA253F83
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 21 Aug 2019 10:52:08 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail4.protonmail.ch (mail4.protonmail.ch [185.70.40.27])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7C0538A2
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 21 Aug 2019 10:52:06 +0000 (UTC)
Date: Wed, 21 Aug 2019 10:51:58 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=default; t=1566384723;
bh=hfseidE+YBejlyQIN/aByLlRznRbronMdYd7nGlBFgo=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:
Feedback-ID:From;
b=IqkQpNkDHqDFEJlnnq8467+Yyqf704NCv+SEjgeayJ9A9/aQZb7ui0akOncng8lir
U3FZsZXZ/PZ5r+BbKcDDZ3I5bgXTzIS2qljThyU2SQlQ//v73tlo8DC9cOeq61oKrk
L4JhE4kUrTmE0EmtLdQnoUdAahOkbKQCU0FNsynM=
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
From: Dr Maxim Orlovsky <orlovsky@protonmail.com>
Reply-To: Dr Maxim Orlovsky <orlovsky@protonmail.com>
Message-ID: <gzj3nFgqW8Tc2eV8WQRGrC6GYyAGEJiVLgG7KA5tmosZ5NJpz3k4cIgBH9KszySwe3pcQMtit_-hOb6JZzPjH5p4Mi9-xqyWCT6p8leSU8Q=@protonmail.com>
In-Reply-To: <6o-9VFKLR0h4CUf_fUN1rAqwTTZMlxk2CwwHSbuuvesIapG8ySj4KyHyUmHRh8rf7Lc2urCX8vw7tmlkP60SfvS3VyWnauD25_E8psrcx7I=@protonmail.com>
References: <GJgJhEIXm9MyKb_3kGCd2RdvkVQGHjJIE_lCHtp5hQUt7lHvYl1lXTfgyGwwVC0w9LfeZBf86XEbU694V0EdDrB0HwXa7dMhxD7m5MSUI-g=@protonmail.com>
<6o-9VFKLR0h4CUf_fUN1rAqwTTZMlxk2CwwHSbuuvesIapG8ySj4KyHyUmHRh8rf7Lc2urCX8vw7tmlkP60SfvS3VyWnauD25_E8psrcx7I=@protonmail.com>
Feedback-ID: xmJdeebsJuWeTYpeWGhs6GJbYVTPvqSSDf5BTIISdYkvPlii55JSNfQlNKs6wbT1AOA1a_vQLvS0p4JWgkwDsA==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM,
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: Wed, 21 Aug 2019 13:13:59 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Storm: escrowed storage and messaging at L2/L3
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: Wed, 21 Aug 2019 10:52:08 -0000
Hi ZmnSCPxj,
Thank you very much for spending your time on analysing my idea at such a d=
eep level =E2=80=93 and writing the detailed review proposing possible solu=
tions to the main found issues.
> Insufficient/unclear Description of Probabilistic Proof
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D
>
> <...>
> It might be that you imply this in your step 1 for Alice validation of th=
e probabilistically checkable proof though it may be better clarified that =
Alice has to keep the Merkle Tree root for the original data it originally =
requested:
>
>> With these data, Alice will be able to check with this zero-knowledge ar=
gument by:
>> 1. Checking Merkle tree paths leading to the chunks and resulting Merkle=
tree root hash to correspond to them
Correct, I forgot to put this step into the description, will fix, sorry fo=
r that. Indeed, Alice needs to take a "shot" from the data in a form of Mer=
kle tree and keep its root for herself, and Bob has to provide her with
* "PCP-selected" blocks of source
* "PCP-selected" blocks of encrypted data
* siblings of the Merkle root "leafs" for the selected source data (require=
d for Alice to check source data paths up to the Merkle root which she had =
kept for herself)
* Merkle paths for both of them
* public key used for the encryption, so Alice can re-encrypt received sour=
ce data blocks and make sure they are equal to the provided encrypted block=
s, so this public key is true
> Will the Real Decryption Key Please Stand Up?
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> Also, it seems to me that the encryption used must be an asymmetrical enc=
ryption.
> That is, the encryption and decryption keys must be different, with the e=
ncryption key being a "public" key Bob can safely share with Alice and the =
decryption key being a "private" key that Bob can share only once it has ac=
quired its funds.
Correct, it should be working like in PGP/GPG
> That is, Bob must prove:
>
> * The given hash h is the hash of the secret decryption key d whose equiv=
alent encryption key is e
>
> ...while revealing only h and e to Alice.
Yes, that is an important point, I've missed that out.
> If there exists some asymmetric encryption using EC (I know of no such, b=
ut that is only due to my ignorance), where the decryption key is a scalar =
and the encryption key is the scalar times the generator then it would be p=
ossible to use 2p-ECDSA / Schnorr Scriptless Script to atomically pay for k=
nowledge of the scalar / decryption key, while knowing the encryption key.
> Instead of a hash of the decryption key, Bob sends the encryption key dur=
ing setup and Alice and Bob use that in the pointlocked timelocked contract=
under Scriptless Script.
A very elegant solution, thank you! Yes, seems one can encrypt/decrypt with=
EC: https://developer.ibm.com/swift/2019/03/04/blueecc-elliptic-curve-cryp=
tography/ and this should work. I will include your solution to the proposa=
l.
It also might be possible to implement your solution with threshold ECDSA s=
ignatures, that will enable Storm before Schorr's will get to Bitcoin. I am=
not very good in understanding them yet, but it seems that multiparty ECDS=
A (or threshold ECDSA, t-ECDSA) unlock many of Schnorr=E2=80=99s signature =
features and benefits.
One may check https://github.com/KZen-networks/multi-party-ecdsa and papers=
:
* https://eprint.iacr.org/2019/114.pdf
* https://link.springer.com/chapter/10.1007/978-3-319-39555-5_9 https://twi=
tter.com/alexbosworth/status/1163116574238056448
I will investigate that in more details.
> Transporting Storm Over Lightning
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> Of note is that any mechanism that requires multiple participants to put =
up money into a contract (as in the case of Storm, which requires both the =
stake from Bob and the reward from Alice to be put into a single timebound =
HTLC) can only live inside a single LN channel and is not transportable acr=
oss intermediate nodes.
> This is because intermediate nodes potentially become subject to attack i=
n case of routing failure.
> (Though it *may* be possible to reuse the sketch I give here for HTLC-enf=
orced publication of combined HTLCs: https://lists.linuxfoundation.org/pip=
ermail/lightning-dev/2019-July/002055.html)
>
> This is part of what makes LN difficult to work with multiple asset types=
due to HTLCs naturally forming premium-free American Call Options.
> Avoiding premium-free American Call Options is possible by extracting the=
premium from the receiver and combining it with the money from the exchang=
e, but this again is doable only onchain, or in a single LN channel (meanin=
g receivers must centralize around exchanges).
> It may be possible to get around this, once Lightning supports payment po=
ints + scalars, by use of EC magic homomorphisms, though I lack the energy =
right now to go dig up the resources on lightning-dev.
> But the storage provider can route a payment to Alice to serve as stake, =
which can be claimed only if knowing some secret, then Alice routes the sta=
ke+reward to Bob, and use some of the EC magic homomorphism while keeping i=
ntermediate nodes unaware.
You are right, my solution is limited to a single LN channels, i.e. there m=
ust be a direct dually-funded channel between Alice and Bob (and we don't h=
ave dually-funded channels as a part of current LN BOLT's). I will add this=
disclaimer to the spec.
Your solution to the transporting problem is indeed very interesting, howev=
er, I need some time to analyze it in more details. Meanwhile, if you don't=
mind, I will open an issue on GitHub and will be copying the discussion to=
there as well, so others from outside of this mail list can also join.
Kind regards,
Maxim Orlovsky
https://github.com/dr-orlovsky
|
