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"
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
Subject: Re: [bitcoin-dev] BIP Proposal: Compact Client Side Filtering for
 Light Clients
Precedence: list


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