From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id CA253F83 for ; 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 ; 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 From: Dr Maxim Orlovsky Reply-To: Dr Maxim Orlovsky Message-ID: In-Reply-To: <6o-9VFKLR0h4CUf_fUN1rAqwTTZMlxk2CwwHSbuuvesIapG8ySj4KyHyUmHRh8rf7Lc2urCX8vw7tmlkP60SfvS3VyWnauD25_E8psrcx7I=@protonmail.com> References: <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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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