MIME-Version: 1.0
References: <GJgJhEIXm9MyKb_3kGCd2RdvkVQGHjJIE_lCHtp5hQUt7lHvYl1lXTfgyGwwVC0w9LfeZBf86XEbU694V0EdDrB0HwXa7dMhxD7m5MSUI-g=@protonmail.com>
	<6o-9VFKLR0h4CUf_fUN1rAqwTTZMlxk2CwwHSbuuvesIapG8ySj4KyHyUmHRh8rf7Lc2urCX8vw7tmlkP60SfvS3VyWnauD25_E8psrcx7I=@protonmail.com>
	<x1b18QXzxALwxxp8ehwcB7XORizrw5vOJ9BNXWpXbd2SJgUra-AFIyTgnM_yxKEtCg_frZcz916NLmm-pTsCD4Z7aOFprdQ_W87mHnn8vYg=@protonmail.com>
In-Reply-To: <x1b18QXzxALwxxp8ehwcB7XORizrw5vOJ9BNXWpXbd2SJgUra-AFIyTgnM_yxKEtCg_frZcz916NLmm-pTsCD4Z7aOFprdQ_W87mHnn8vYg=@protonmail.com>
From: Stefan Richter <richter@cs.rwth-aachen.de>
Date: Wed, 21 Aug 2019 11:33:24 +0200
Message-ID: <CAH+=Z+U8sGRtK7TwkGjAQ3yL4WYYnJMJjz9pm+9SOSrHReoerg@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000070434205909d4436"
Subject: Re: [bitcoin-dev] Storm: escrowed storage and messaging at L2/L3
Precedence: list

--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
> `<Alice> 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

<div dir=3D"ltr">Please see the github issues and the twitter discussion (e=
.g. here: <a href=3D"https://twitter.com/stefanwouldgo/status/1163801056423=
403520">https://twitter.com/stefanwouldgo/status/1163801056423403520</a>) 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</div><br><div class=3D"gmail_quote"=
><div dir=3D"ltr" class=3D"gmail_attr">Am Mi., 21. Aug. 2019 um 09:32=C2=A0=
Uhr schrieb ZmnSCPxj via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@list=
s.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt;:<br></=
div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left:1px solid rgb(204,204,204);padding-left:1ex">Good morning Maxim,<b=
r>
<br>
The Deaf Bob Attack<br>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>
<br>
It seems to me that Bob can promote the N3 problem to the N2 problem.<br>
<br>
Suppose Alice contacts Bob to get the data.<br>
However, Bob happens to have lost the data in a tragic boating accident.<br=
>
<br>
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.<br>
<br>
But this seems unworkable.<br>
<br>
* If Bob managed to sign the HTLC settlement transaction, what `SIGHASH` fl=
ags did Bob sign with?<br>
=C2=A0 * If it was `SIGHASH_ALL` or `SIGHASH_SINGLE`, then Bob already sele=
cted the decryption key at setup time.<br>
=C2=A0 * If it was `SIGHASH_NONE`, then Alice could put any SCRIPT, includi=
ng `&lt;Alice&gt; OP_CHECKSIG`.<br>
<br>
If Bob already selected the decryption key at setup time, then Bob can igno=
re Alice.<br>
<br>
* If Alice does not publish the HTLC settlement transaction, then Bob will =
eventually enter the N2 state and get the stake+reward.<br>
* 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.<br>
=C2=A0 * The decryption key is useless without the encrypted data!<br>
<br>
It seems this part is not workable?<br>
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).<br>
<br>
<br>
Regards,<br>
ZmnSCPxj<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--00000000000070434205909d4436--