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
|
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 CC0223EE
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 21 Aug 2019 07:32:36 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40130.protonmail.ch (mail-40130.protonmail.ch
[185.70.40.130])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 18CE089E
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 21 Aug 2019 07:32:35 +0000 (UTC)
Date: Wed, 21 Aug 2019 07:32:25 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=default; t=1566372753;
bh=tM3/JvFnHR9WZcpkhD0AIeMb6szJ+KTFwFg4gxUelKE=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:
Feedback-ID:From;
b=mbr9jHn1rAXN0TsZLD/UGfjbiTC/gc9bqNGZZxdRwGC7YSy9nc48+N+M566XSFHYb
sFW2tMs+RY+o1wV7dfDEklHrap4pt9HVkXv0Y5IE8dMKA4r66TYC5WDMVTw7pi69wE
HmDsSmmTN5Jkiwby+Kc6vEmlGPgEpUt35VDg6SlM=
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <x1b18QXzxALwxxp8ehwcB7XORizrw5vOJ9BNXWpXbd2SJgUra-AFIyTgnM_yxKEtCg_frZcz916NLmm-pTsCD4Z7aOFprdQ_W87mHnn8vYg=@protonmail.com>
In-Reply-To: <6o-9VFKLR0h4CUf_fUN1rAqwTTZMlxk2CwwHSbuuvesIapG8ySj4KyHyUmHRh8rf7Lc2urCX8vw7tmlkP60SfvS3VyWnauD25_E8psrcx7I=@protonmail.com>
References: <GJgJhEIXm9MyKb_3kGCd2RdvkVQGHjJIE_lCHtp5hQUt7lHvYl1lXTfgyGwwVC0w9LfeZBf86XEbU694V0EdDrB0HwXa7dMhxD7m5MSUI-g=@protonmail.com>
<6o-9VFKLR0h4CUf_fUN1rAqwTTZMlxk2CwwHSbuuvesIapG8ySj4KyHyUmHRh8rf7Lc2urCX8vw7tmlkP60SfvS3VyWnauD25_E8psrcx7I=@protonmail.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: Dr Maxim Orlovsky <orlovsky@protonmail.com>
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 07:32:36 -0000
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?
* 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
|
