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

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