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 D9FC2C91 for ; Wed, 21 Aug 2019 17:04:45 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40132.protonmail.ch (mail-40132.protonmail.ch [185.70.40.132]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id EAE81E6 for ; Wed, 21 Aug 2019 17:04:44 +0000 (UTC) Date: Wed, 21 Aug 2019 17:04:35 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1566407082; bh=ZIeXs16tsQ2EJ1em04gU8sPPqFV7AkcujzC8NNZtH+E=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=Cn5Wr8s9YqAPzr/7RwBYkKrV8ltiifAf8UJJeQSAXyo8y14eoisHMJjoHccrGGl+Y CiwVPL1IGaWBMJRh7VUM8H2QDvN14Bw1oua+eza08BXa0uBikgcWjrOGc/WLEJAP0y oYHI0V2GwgwaFDm9P0GOoyjLleiQle8XvUnRAwkI= To: ZmnSCPxj From: Dr Maxim Orlovsky Reply-To: Dr Maxim Orlovsky Message-ID: In-Reply-To: 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 17:05:30 +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 17:04:46 -0000 Hi ZmnSCPxj, > The Deaf Bob Attack > =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 > - If Alice does not publish the HTLC settlement transaction, then Bob w= ill eventually enter the N2 state and get the stake+reward. > - If Alice does publish the HTLC settlement transaction, without Bob gi= ving the encrypted data, then Bob can just use the hashlock and reveal the = decryption key. > - The decryption key is useless without the encrypted data! That is the main attack already addressed by couple of other guys in differ= ent forms; and you have provided the most detailed explanation of it, thank= you. I was working for its solution over the last day and I'd like to prop= ose the following update: https://github.com/storm-org/storm-spec/issues/6#= issuecomment-523497555 Briefly, I introduce two new intermediary HTLC transactions (called confirm= ation and fallbacks). Alice has now a choice to sign HTLC fallback tx if sh= e didn't get the data, and in that case she will get her money (reward) bac= k and Bob's stake as a compensation. Bob can "appeal" to this by confirming= that he had hold the data for Alice. Bob does this by providing a "preimag= e" to the secret hashed by Alice. This secret is composed at setup time by Alice, and she uses her newly-deri= ved public key for both funding transaction output and deterministically de= finition of some small portion of the source data. This portion is double-h= ashed to 160-bit hash and included into HTLC fallback tx by Alice as a hash= lock. Later, when Bob wants to prove that he still has the data available,= he see the published HTLC transaction, extracts Alice public key and uses = it to get the same deterministic piece of the source data as Alice. Bob com= putes a single hash on the date, which gives him a preimage to unlock the h= ash lock from HTLC transaction output before Alice will spend it (Alice's o= utput is timelocked). This solution requires Bob to select decription key at setup time, when he = pre-signs the transaction, as you correctly have pointed out: > If Bob already selected the decryption key at setup time, then Bob can ig= nore Alice. Now, we need to aviod situation where by selecting the encryption/decryptio= n pair Bob knows which part of the data he needs to provide Alice in PCP pr= oof, and can discard the rest of the data. This can be mitigated by requiri= ng that the data have to be encrypted using EC multiplication with some fac= tor provided by Alice at the request time. The only case for possible cheating now is Alice not needing data anymore a= nd avoiding paying the full amount for the storage. However, this can be a = part of the Bob business risk and may be covered by some insurance + Alice'= s reputation & taken into account by Bob at setup time. Kind regards, Maxim Orlovsky