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
|
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 B5505FC8
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 21 Aug 2019 12:48:24 +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 9014189E
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 21 Aug 2019 12:48:23 +0000 (UTC)
Date: Wed, 21 Aug 2019 12:48:16 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=default; t=1566391700;
bh=S0SEhLWsogRmhTu/cn72vsKKkoHZVylR6Hr9hMz6kHs=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:
Feedback-ID:From;
b=Vx16hxtl71R/r3alwltCDzVOwsLKTNa2OSBz952yAPIFZCFvH0epJGKjG0qTPJC2Y
9IQWToC+rJ/Jz3ARg5dLxWJQdiz5cUb44J/2YleXVo1ECtpNKEM+JWQTVJ+CKxu91o
jUT8Nxa1n8BWUT38SwKRRsybkJv1qMPLtiKzvEDI=
To: Dr Maxim Orlovsky <orlovsky@protonmail.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <-88WqEQyIbOd9y51ewaYLJwIbxCxCUQZKPD7zd3KhaCVw8Tknts8zKLmqGRZBJBQzGYbUVLgW4RZny6eQu-rGof5yImn7MLEKsNi5T0GOnI=@protonmail.com>
In-Reply-To: <gzj3nFgqW8Tc2eV8WQRGrC6GYyAGEJiVLgG7KA5tmosZ5NJpz3k4cIgBH9KszySwe3pcQMtit_-hOb6JZzPjH5p4Mi9-xqyWCT6p8leSU8Q=@protonmail.com>
References: <GJgJhEIXm9MyKb_3kGCd2RdvkVQGHjJIE_lCHtp5hQUt7lHvYl1lXTfgyGwwVC0w9LfeZBf86XEbU694V0EdDrB0HwXa7dMhxD7m5MSUI-g=@protonmail.com>
<6o-9VFKLR0h4CUf_fUN1rAqwTTZMlxk2CwwHSbuuvesIapG8ySj4KyHyUmHRh8rf7Lc2urCX8vw7tmlkP60SfvS3VyWnauD25_E8psrcx7I=@protonmail.com>
<gzj3nFgqW8Tc2eV8WQRGrC6GYyAGEJiVLgG7KA5tmosZ5NJpz3k4cIgBH9KszySwe3pcQMtit_-hOb6JZzPjH5p4Mi9-xqyWCT6p8leSU8Q=@protonmail.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
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 12:48:24 -0000
Good morning Maxim,
> > <...>
> > It might be that you imply this in your step 1 for Alice validation of =
the probabilistically checkable proof though it may be better clarified tha=
t Alice has to keep the Merkle Tree root for the original data it originall=
y requested:
> >
> > > With these data, Alice will be able to check with this zero-knowledge=
argument by:
> > >
> > > 1. Checking Merkle tree paths leading to the chunks and resulting Me=
rkle tree root hash to correspond to them
>
> Correct, I forgot to put this step into the description, will fix, sorry =
for that. Indeed, Alice needs to take a "shot" from the data in a form of M=
erkle tree and keep its root for herself
Thank you for the clarification, indeed it is better to explicit this step.
> > If there exists some asymmetric encryption using EC (I know of no such,=
but that is only due to my ignorance), where the decryption key is a scala=
r and the encryption key is the scalar times the generator then it would be=
possible to use 2p-ECDSA / Schnorr Scriptless Script to atomically pay for=
knowledge of the scalar / decryption key, while knowing the encryption key=
.
> > Instead of a hash of the decryption key, Bob sends the encryption key d=
uring setup and Alice and Bob use that in the pointlocked timelocked contra=
ct under Scriptless Script.
>
> A very elegant solution, thank you! Yes, seems one can encrypt/decrypt wi=
th EC:https://developer.ibm.com/swift/2019/03/04/blueecc-elliptic-curve-cry=
ptography/ and this should work. I will include your solution to the propos=
al.
>
> It also might be possible to implement your solution with threshold ECDSA=
signatures, 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 EC=
DSA (or threshold ECDSA, t-ECDSA) unlock many of Schnorr=E2=80=99s signatur=
e features and benefits.
> One may check https://github.com/KZen-networks/multi-party-ecdsa and pape=
rs
I did mention 2p-ECDSA, which the last time I checked, was the "best" avail=
able multiparty ECDSA.
I have not checked in detail the relative security details of 2p-ECDSA comp=
ared to the various multiparty ECDSAs.
In this particular case this is only between two parties, thus 2p-ECDSA sho=
uld be sufficient.
https://eprint.iacr.org/2011/494.pdf
https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-April/001221=
.html
I have not checked your links and it is possible we are referring to the ex=
act same thing, or your t-ECDSA is a strict improvement over 2p-ECDSA.
> You are right, my solution is limited to a single LN channels, i.e. there=
must be a direct dually-funded channel between Alice and Bob (and we don't=
have dually-funded channels as a part of current LN BOLT's). I will add th=
is disclaimer to the spec.
Strictly speaking, dual-funding is completely and totally unnecessary.
As submarine swaps / off-to-onchain swaps are already possible, a simple ri=
tual like the below can emulate dual-funding (at the cost that one side mus=
t own the total they agree on onchain):
1. Alice and Bob agree to each put 10mBTC each to form 20mBTC channel.
2. Alice happens to have 20mBTC onchain in her pocket, while Bob has 10mBT=
C.
3. Bob puts his 10mBTC into an onchain 10mBTC HTLC with locktime 2*L payin=
g to Bob, hashlock paying to Alice (with a preimage known only by Bob).
4. Alice sets up the 20mBTC channel using her 20mBTC onchain.
5. After the channel funding tx is deeply confirmed, Alice forwards a 10mB=
TC HTLC over that channel with locktime L paying to Alice, hashlock paying =
to Bob (with the same hash as the above).
6. Bob claims the payment offchain.
7. Alice can now claim the onchain payment.
8. Alice and Bob now have a perfectly balanced channel (as all channels sh=
ould be), while Alice is now in possession of an extra 10mBTC onchain.
So Alice has 10mBTC offchain, 10mBTC onchain, while Bob has 10mBTC offc=
hain on the same channel.
Dual-funding simply makes the above *much* more efficient, but is not stric=
tly necessary in a world where atomic cross-system swaps are already possib=
le.
From this point of view, every distinct channel is a unique cryptocurrency =
system, and if atomic cross-system swaps are possible at all, it is immater=
ial if one system is a blockchain and the other is a payment channel, etc.
You may also be interested in Fulgurite.
This is a project to "split" a channel into Lightning part and DLC (discree=
t log contract) part.
The reason for splitting is because LN is expected to have much more state =
updates than DLC (you forward payments all the time, but set up only a few =
DLCs with direct counterparties).
DLCs require a lot of signatures if they are reanchored to a new state upda=
te transaction, so splitting the channel into an LN part with many updates =
and a DLC part with few updates is sensible to reduce processing and bandwi=
dth.
Similar reasoning may hold for Storm.
Regards,
ZmnSCPxj
|
