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
|
Return-Path: <tomas@tomasvdw.nl>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 4BEE8723
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 9 Jun 2017 08:26:54 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com
[66.111.4.25])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C367019B
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 9 Jun 2017 08:26:53 +0000 (UTC)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42])
by mailout.nyi.internal (Postfix) with ESMTP id BD2D420C0C;
Fri, 9 Jun 2017 04:26:52 -0400 (EDT)
Received: from web3 ([10.202.2.213])
by compute2.internal (MEProxy); Fri, 09 Jun 2017 04:26:52 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
messagingengine.com; h=content-transfer-encoding:content-type
:date:from:in-reply-to:message-id:mime-version:references
:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=QwUubI
2eL9FF8gkkZtoBLEfeSCXUJQTDekQbGYVOVr0=; b=oJjoi69rL7tJXKszIZG8ek
qyT00qCjcmZINliZzADOhgZ3cF05jedH2ZEuF9aMeqYCqrljB5RnZlmTjQs+NTMO
QLmlEsGXcyp+uMp+l+Rz6FHEj7rjmAsXtNj/JWb7+kXF0rz63fW3z6caM7geRfKx
0wtsPWj6ZzXG8oh06147qVk/5nETz5yZpAIG5yGfLbjEBtaYNWAQHezdn5XPWdVh
wOMxO2GXZQ58pmqDKPxtk+Ju7ACaFV34kpwlm7/gPzFUBQC2KgzVau+EMelrgFlH
OPMGBj96aeNN4O9rKWUFhtGnA7DxSOCgFNNztKV87jD+D4/4pufuP25fNs3BeSCg
==
X-ME-Sender: <xms:zFs6WXA6mTQnCFOFllYe6VryxRD-z8N8dUl0PU34FZqtqcnX57a4gw>
Received: by mailuser.nyi.internal (Postfix, from userid 99)
id 9BF9C9EDD7; Fri, 9 Jun 2017 04:26:52 -0400 (EDT)
Message-Id: <1496996812.1977682.1003827768.27236ACB@webmail.messagingengine.com>
From: Tomas <tomas@tomasvdw.nl>
To: Olaoluwa Osuntokun <laolu32@gmail.com>,
bitcoin-dev@lists.linuxfoundation.org
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"
X-Mailer: MessagingEngine.com Webmail Interface - ajax-72fcb609
References: <CAO3Pvs8ccTkgrecJG6KFbBW+9moHF-FTU+4qNfayeE3hM9uRrg@mail.gmail.com>
<1496915408.1583369.1002689000.641E8EAB@webmail.messagingengine.com>
<CAO3Pvs_0r1xOL9JMSXf7taG-vFcOanPEh7d4nuQKEPSNLZ6kXQ@mail.gmail.com>
In-Reply-To: <CAO3Pvs_0r1xOL9JMSXf7taG-vFcOanPEh7d4nuQKEPSNLZ6kXQ@mail.gmail.com>
Date: Fri, 09 Jun 2017 10:26:52 +0200
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,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: Fri, 09 Jun 2017 11:33:36 +0000
Subject: Re: [bitcoin-dev] BIP Proposal: Compact Client Side Filtering for
Light Clients
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: Fri, 09 Jun 2017 08:26:54 -0000
On Fri, Jun 9, 2017, at 05:50, Olaoluwa Osuntokun wrote:
> Tomas wrote:
> > I don't completely understand the benefit of making the outpoints and
> > pubkey hashes (weakly) verifiable. These only serve as notifications and
> > therefore do not seem to introduce an attack vector.
>=20
> Not sure what you mean by this. Care to elaborate?=C2=A0
>=20
I will rephrase. The BIP reads:
> Additionally, Full nodes can nearly undetectably lie by omission causing =
a denial of service which can=20
lead to undesirable failure modes in applications whose safety
critically relies on responding to certain
on-chain events.
I understand that the compact header chain is used to mitigate against
this, but I am unsure about the use=20
cases and trade-offs.
For a normal wallet, the only thing I can imagine an attacker could do
is pretending a transaction did not confirm=20
yet, causing nuisance.=20=20
An application critically depending on knowing what happens on-chain=20
surely is better off downloading=20
the TXIDs, providing PoW security? Gaining knowledge of incoming TXIDs
is nicely solved the payment protocol.
Are there enough use cases that critically depend on pub key hashes
being used on-chain, to make the compact header chain worth its costs?=20
Regards,
Tomas
|
