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 E2216F79 for ; Wed, 21 Aug 2019 09:33:37 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qt1-f170.google.com (mail-qt1-f170.google.com [209.85.160.170]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2F50C8A9 for ; Wed, 21 Aug 2019 09:33:37 +0000 (UTC) Received: by mail-qt1-f170.google.com with SMTP id b11so2182065qtp.10 for ; Wed, 21 Aug 2019 02:33:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=n5O3AtMCrKnlBz4oPiA/vUFXZHEdIkgdKEBzWN01gqM=; b=dk2p2pFAuVfsnPEs/6VLx2lfLBlpdY2B2Pw4jATZiVb9cUcogK0dhf9I2T077cTnS5 blHIU7FxU2QLkDYsc6ZUDVEkooXbter8Z1Ee+prGBpY8dfCrMau2Cm5C9c9e24RGz0Px K2W3Go2Xv8XMVFnj0kRKygyqih8lzBTXx5CLdh9HqOurffbINVUzOQBcA3UIcexeqsU/ MgWmnnB0s1tB2RB0FuSaJFDoK6NYBauQbkjY8/D9KURqJHh2/s0OL155Mu8TWBsdVLdh p1SKtaaAddiThAYRxg2Jf02INhflpYugB95oE8NwBB0D3K8nTaoDi7jbCR/phqJqnEWF CzMw== X-Gm-Message-State: APjAAAXJWsweGa2JQCiEMHUX8y7gYPRoi54YLSFJLSCnDIopqSQnok/Z PKUNsZ+BIK2D8DdGAhMWRDmCcGpEDNWPD1bt+rJrQNb+n7Y= X-Google-Smtp-Source: APXvYqwDGi0snniDAkiQVYgWTePrjtYItIcD6T1Can+0fZ4vytEjhVz/xkTcjWj2qwVKTVcr2nPwpWCDml2fdsIWVeA= X-Received: by 2002:ac8:5219:: with SMTP id r25mr31408277qtn.43.1566380016025; Wed, 21 Aug 2019 02:33:36 -0700 (PDT) MIME-Version: 1.0 References: <6o-9VFKLR0h4CUf_fUN1rAqwTTZMlxk2CwwHSbuuvesIapG8ySj4KyHyUmHRh8rf7Lc2urCX8vw7tmlkP60SfvS3VyWnauD25_E8psrcx7I=@protonmail.com> In-Reply-To: From: Stefan Richter Date: Wed, 21 Aug 2019 11:33:24 +0200 Message-ID: To: Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="00000000000070434205909d4436" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM, HTML_MESSAGE,RCVD_IN_DNSWL_NONE 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 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 09:33:38 -0000 --00000000000070434205909d4436 Content-Type: text/plain; charset="UTF-8" Please see the github issues and the twitter discussion (e.g. here: https://twitter.com/stefanwouldgo/status/1163801056423403520) for similar points other people including me have made. At this point I feel there are quite a few unclear points in the presentation and it is not clear to me if they can be salvaged. Am Mi., 21. Aug. 2019 um 09:32 Uhr schrieb ZmnSCPxj via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org>: > Good morning Maxim, > > The Deaf Bob Attack > =================== > > 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 > protocol setup. > > But this seems unworkable. > > * If Bob managed to sign the HTLC settlement transaction, what `SIGHASH` > flags 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 > ` OP_CHECKSIG`. > > If Bob already selected the decryption key at setup time, then Bob can > ignore 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 > giving the encrypted data, then Bob can just use the hashlock and reveal > the decryption 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 thus already claimable even without any data being returned by Bob). > > > Regards, > ZmnSCPxj > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --00000000000070434205909d4436 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Please see the github issues and the twitter discussion (e= .g. here: https://twitter.com/stefanwouldgo/status/1163801056423403520) f= or similar points other people including me have made. At this point I feel= there are quite a few unclear points in the presentation and it is not cle= ar to me if they can be salvaged.=C2=A0

Am Mi., 21. Aug. 2019 um 09:32=C2=A0= Uhr schrieb ZmnSCPxj via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>:
Good morning Maxim,
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?
=C2=A0 * If it was `SIGHASH_ALL` or `SIGHASH_SINGLE`, then Bob already sele= cted the decryption key at setup time.
=C2=A0 * If it was `SIGHASH_NONE`, then Alice could put any SCRIPT, includi= ng `<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.
=C2=A0 * 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
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--00000000000070434205909d4436--