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 B5505FC8 for ; 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 ; 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 From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: <-88WqEQyIbOd9y51ewaYLJwIbxCxCUQZKPD7zd3KhaCVw8Tknts8zKLmqGRZBJBQzGYbUVLgW4RZny6eQu-rGof5yImn7MLEKsNi5T0GOnI=@protonmail.com> In-Reply-To: References: <6o-9VFKLR0h4CUf_fUN1rAqwTTZMlxk2CwwHSbuuvesIapG8ySj4KyHyUmHRh8rf7Lc2urCX8vw7tmlkP60SfvS3VyWnauD25_E8psrcx7I=@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 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 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