path: root/56/8f06d1bf8433c191eabcb105261ef3191efcaf

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 3AA40F7C
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 21 Aug 2019 12:12:38 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40133.protonmail.ch (mail-40133.protonmail.ch
	[185.70.40.133])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id CF9F38A7
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 21 Aug 2019 12:12:36 +0000 (UTC)
Date: Wed, 21 Aug 2019 12:12:30 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
	s=default; t=1566389553;
	bh=XTIBhbBkGtxXbC8LRNcYoeDTXnZjROUmvnrK1NN5SQQ=;
	h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:
	Feedback-ID:From;
	b=XprdHW1q12buAJbF22P6K+Mokymz7KfsfKB+5CYDIqGeSwaMKsg+tCjhIVHyc3mj+
	vfabHMTfClLuBLW5guTl1cR1IufOC0RLLwCtipT4YY+2iT1dTbpE9uhKasUoHYxvF/
	+OF4LEn+KWATcoJOvr9MRK+jCdxfzm+ypsvPzs7Q=
To: Maxim Orlovsky <orlovsky@pandoraboxchain.ai>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <ZUfNKbb6WUnXsNZX-WYwkIDby7UcTuagwHFoay99gD39SnWLr26J7N1CtwXmdlrrwuvjpaGAt5IMyr0-flhrpGYpV0ChXsXFn00Qf6cEzPM=@protonmail.com>
In-Reply-To: <A733B8A1-2E88-47F4-A6CF-C56C84E8FF9A@pandoracore.com>
References: <GJgJhEIXm9MyKb_3kGCd2RdvkVQGHjJIE_lCHtp5hQUt7lHvYl1lXTfgyGwwVC0w9LfeZBf86XEbU694V0EdDrB0HwXa7dMhxD7m5MSUI-g=@protonmail.com>
	<6o-9VFKLR0h4CUf_fUN1rAqwTTZMlxk2CwwHSbuuvesIapG8ySj4KyHyUmHRh8rf7Lc2urCX8vw7tmlkP60SfvS3VyWnauD25_E8psrcx7I=@protonmail.com>
	<A733B8A1-2E88-47F4-A6CF-C56C84E8FF9A@pandoracore.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:12:38 -0000

Good morning Maxim,

I also sent another email with the below text, it seems to have gotten miss=
ed somehow or not sent properly or some other problem.

The Deaf Bob Attack
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

It seems to me that Bob can promote the N3 problem to the N2 problem.

Suppose Alice contacts Bob to get the data.
However, Bob happens to have lost the data in a tragic boating accident.

Now, supposedly what Alice does in this case would be to broadcast the HTLC=
 settlement transaction, whose signature was provided by Bob during protoco=
l setup.

But this seems unworkable.

* If Bob managed to sign the HTLC settlement transaction, what `SIGHASH` fl=
ags did Bob sign with?
  * If it was `SIGHASH_ALL` or `SIGHASH_SINGLE`, then Bob already selected =
the decryption key at setup time.
  * If it was `SIGHASH_NONE`, then Alice could put any SCRIPT, including `<=
Alice> OP_CHECKSIG`.

If Bob already selected the decryption key at setup time, then Bob can igno=
re Alice.

* If Alice does not publish the HTLC settlement transaction, then Bob will =
eventually enter the N2 state and get the stake+reward.
* If Alice *does* publish the HTLC settlement transaction, without Bob givi=
ng the encrypted data, then Bob can just use the hashlock and reveal the de=
cryption key.
  * The decryption key is useless without the encrypted data!

It seems this part is not workable?
As the decryption key is embedded in the HTLC, Alice cannot get a signature=
 from Bob without the decryption key already being selected by Bob (and thu=
s already claimable even without any data being returned by Bob).

Regards,
ZmnSCPxj

> Hi ZmnSCPxj,
>
> Thank you very much for spending your time on analysing my idea at such 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=3D
> >
> > <...>
> > It might be that you imply this in your step 1 for Alice validation of =
the probabilistic checkable proof though it may be better clarified that Al=
ice has to keep the Merkle Tree root for the original data it originally re=
quested:
> >
> > > With this data Alice will be able to check with this zero-knowledge a=
rgument 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, 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 (req=
uired 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 =
source data blocks and make sure they are equal to the provided encrypted b=
locks, 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=3D
> >
> > Also, it seems to me that the encryption used must be an asymmetrical e=
ncryption.
> > That is, the encryption and decryption keys must be different, with the=
 encryption key being a "public" key Bob can safely share with Alice and th=
e decryption key being a "private" key that Bob can share only once it has =
acquired 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 e=
quivalent 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,=
 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.
>
> Very elegant solution, thank you! Yes, seems one can encrypt/decrypt with=
 EC:https://developer.ibm.com/swift/2019/03/04/blueecc-elliptic-curve-crypt=
ography/ and this should work. I will include your solution into 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:
>
> -   https://eprint.iacr.org/2019/114.pdf
> -   https://link.springer.com/chapter/10.1007/978-3-319-39555-5_9 https:/=
/twitter.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=3D
> >
> > Of note is that any mechanism that requires multiple participants to pu=
t up money into a contract (as in the case of Storm, which requires both th=
e stake from Bob and the reward from Alice to be put into a single timeboun=
d HTLC) can only live inside a single LN channel and is not transportable a=
cross intermediate nodes.
> > This is because intermediate nodes potentially become subject to attack=
 in 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/pipe=
rmail/lightning-dev/2019-July/002055.html)
> > This is part of what makes LN difficult to work with multiple asset typ=
es due to HTLCs naturally forming premium-free American Call Options.
> > Avoiding premium-free American Call Options is possible by extracting t=
he premium from the receiver and combining it with the money from the excha=
nge, but this again is doable only onchain, or in a single LN channel (mean=
ing receivers must centralize around exchanges).
> > It may be possible to get around this, once Lightning supports payment =
points + scalars, by use of EC magic homomorphisms, though I lack the energ=
y 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 s=
take+reward to Bob, and use some of the EC magic homomorphism while keeping=
 intermediate nodes unaware.
>
> 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.
>
> Your solution to the transporting problem is indeed very interesting, how=
ever I need some time to analyze it in more details. Meanwhile, if you don'=
t mind, I will open an issue in GitHub and will be copying the discussion t=
o there as well, so others from outside of this mail list can also join.
>
> Kind regards,
> Maxim Orlovsky
> https://github.com/dr-orlovsky