From: Sjors Provoost <sjors@sprovoost.nl>
Content-Type: multipart/signed;
	boundary="Apple-Mail=_B985A468-2BD4-4362-9B4F-EA5DFB10F153";
	protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
Message-Id: <BF359C7E-7FEF-43A6-8ED9-05BED8E0EB64@sprovoost.nl>
Date: Tue, 21 Nov 2017 15:03:46 +0100
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: [bitcoin-dev] BIP159 - NODE_NETWORK_LIMITED service bits,
	extendability
Precedence: list


--Apple-Mail=_B985A468-2BD4-4362-9B4F-EA5DFB10F153
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

I came across the proposed Bitcoin Core implementation of BIP159 [0] in =
this PR [1]. The goal is to allow pruned nodes to "serve a limited =
number of historical blocks" (as opposed to none at all).

It contains a counter-measure for peer fingerprinting. I'm trying to =
understand how that impacts extendibility.

> Peers may have different prune depths (depending on the peers =
configuration,
> disk space, etc.) which can result in a fingerprinting weakness =
(finding the
> prune depth through getdata requests). NODE_NETWORK_LIMITED
> supporting peers SHOULD avoid leaking the prune depth and therefore
> not serve blocks deeper then the signaled NODE_NETWORK_LIMITED
> thresholds.

This means pruned nodes can only serve the last 288 blocks:

> If signaled, the peer MUST be capable of serving at least the last 288 =
blocks (~2 day

As the blockchain keeps growing there will be ever more pruned nodes =
(perhaps offset by new nodes with more storage).  Although a strict =
improvement over todays situation, it seems a bit wasteful to have a =
node with 10-100 GB of storage only be able to share the most recent 288 =
blocks.

It would be nice if a future extension of this BIP allows more =
flexibility. To limit the ability to fingerprint nodes, we could limit =
the number of choices to e.g. 288 + 1000 * 2^n. That yields only 8 =
possibilities at the current chain size. A slightly better formula could =
take into account typical hard drive size increments, leaving enough =
space for the OS and other data. Node operators could opt-in to this if =
they think the increased fingerprint risk outweighs their desire to =
share archived blocks.

I can also imagine - but not implement :-) - a future scenario where =
nodes prune a random subset of their chain, meaning that even nodes with =
little storage can be of help during Initial Blockchain Download (IBD) =
of other nodes.


How would such extension be signaled for? Would we need a whole new =
version bit?

Would upgraded nodes need a new message type to communicate the chosen =
prune depth? Or can that information tag along some existing message?

Jonas Schnelli pointed out on the Github discussion that waiting for =
BIP150 would be appropriate. Can you explain how this is related? =
Although I can see why whitelisted peers can be exempted from the =
anti-fingerprinting measure, I would not want to restrict it to just =
those.


Some minor suggestions for improving the BIP itself:
* add link to mailinglist discussion(s) in reference section
* explain that 288 is not just the minimum limit for Bitcoin Core, but =
also the bulk of traffic (as I understand from earlier discussion [2])

Cheers,

Sjors

[0] https://github.com/bitcoin/bips/blob/master/bip-0159.mediawiki
[1] https://github.com/bitcoin/bitcoin/pull/10387
[2] =
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/thread.ht=
ml#14315

--Apple-Mail=_B985A468-2BD4-4362-9B4F-EA5DFB10F153
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE7ZvfetalXiMuhFJCV/+b28wwEAkFAloUMkIACgkQV/+b28ww
EAm/tg//R7myNx09WqsbGDpzJTPxr40Y4IBdc/BpTcWIWgAEW0l0JuTLQRJZLoMA
y9YSgRFCi4B26E3RgXLASA7pr2F9TczoyQGb9R2jzBl2lKTrCx6/EXWmx1JCeio0
7KdPVcFs3auc7V/NvJpHi1R6CnDYNkMpKctmwt6b1/IBIKCGeJWQ9LtiuudlKAl0
4Z/rJRJmbIxQDDYsa7B3Raqo79V351OamSyQ6LQft8/FXEpvv5BRg0ONtlIaHLBy
Ebegvr3e5sw7rJxi/uvQqkUTXkkWQ0M7/EvLdFMN/qlrFT4o7RafzQdg4GuIli8K
qkW29TDPSSWKO9B/gsIT6VooJfOs1PfoctaDZn2gMfEjxv+bVfpFYqOEtTrJ+xfR
ORgY5j75aaDfxYH5OdyWMltZJ+XFsqt1BegY905KuWJuT0HD/DnRSpwc2K85wOIS
qR3rnhGx4wIqm8FwpI6ZrJ8CyBvoMu12a7pxN661n9zxPjWFJnUdk1/6K5J4t9gL
9jFslsbS+1T+W2UKpmOIBUI/Ldw1pynjZF52bnDefjf73YWwDEV06UmoKcXvfa8H
qfAni6PwH2oGry0bsxuE3Vuv9Vp0yXv/2alsDhKKMKFS5e45+g5nnWZobzKQDFPE
/GJXlma2iCEas2tI9Nr4agUE3MiMqtELd4WTz7Vz9Lfqrf7Q8Ag=
=JAN4
-----END PGP SIGNATURE-----

--Apple-Mail=_B985A468-2BD4-4362-9B4F-EA5DFB10F153--