Date: Wed, 21 Aug 2019 12:48:16 +0000
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
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Storm: escrowed storage and messaging at L2/L3
Precedence: list

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