1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
|
Return-Path: <stefan.sblbs@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id E2216F79
for <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 21 Aug 2019 09:33:37 +0000 (UTC)
Received: by mail-qt1-f170.google.com with SMTP id b11so2182065qtp.10
for <bitcoin-dev@lists.linuxfoundation.org>;
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: <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"
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 <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 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
> `<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 <<a href=3D"mailto:bitcoin-dev@list=
s.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>>:<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 `<Alice> 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--
|
