From: Jonas Schnelli <dev@jonasschnelli.ch>
Content-Type: multipart/signed;
	boundary="Apple-Mail=_CB141DF2-A87E-44D5-A067-BB787ED66146";
	protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Tue, 21 Nov 2017 09:00:21 -1000
References: <BF359C7E-7FEF-43A6-8ED9-05BED8E0EB64@sprovoost.nl>
To: Sjors Provoost <sjors@sprovoost.nl>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <BF359C7E-7FEF-43A6-8ED9-05BED8E0EB64@sprovoost.nl>
Message-Id: <A226065E-A9FE-4BDC-BE4F-1D205D298C0F@jonasschnelli.ch>
Subject: Re: [bitcoin-dev] BIP159 - NODE_NETWORK_LIMITED service bits,
 extendability
Precedence: list


--Apple-Mail=_CB141DF2-A87E-44D5-A067-BB787ED66146
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi Sjors

Thanks for picking this up.

There where some previous discussions about this [1] [2].
Initially, the idea was to have two service bits to signal (up to three) =
states.
But, since it is not clear what use-cases the bits signalling >288 =
blocks would fulfil, I have limited BIP159 to a single =
288blocks-available signalling.

Therefore, BIP159 aims to improve the block relay state around the tip =
(24h) which seems to be the most significant request peak (peers out of =
IBD).
Also, it takes an acceptable transition for pruned node operators into =
account. Once BIP159 gets active on the network, pruned peer operators =
may see an increase in CPU and bandwidth usage.

SPV peers may also connect to BIP159 nodes, scan the mempool and wait =
for unconfirmed transactions (they don=E2=80=99t do this now because =
pruned nodes don't signal any service).

Future extensions are possible. Maybe a p2p command that could tell more =
infos about the pruning state would be useful.

BIP159 also recommends to fix the fingerprinting weakness by fix =
limiting it to 288 blocks, making it impossible for an attacker to =
fingerprint your peer by scanning how deep the peer can serve blocks. =
This may be a reduction for possible use cases with todays pruned peers =
and an idea would be to relax this limit for whitelisted peers (or peers =
connecting via BIP150 [not implemented], and this is the only connection =
between BIP150 and BIP159).

However, I think the scope of BIP159 should be kept as it is. More =
flexibility can be added later when we have gathered more information =
during BIP159 deployment.
Also, the implementations is an advanced stage [3][4]

=E2=80=94
</jonas>

[1] =
https://botbot.me/freenode/bitcoin-core-dev/2017-04-27/?msg=3D84827228&pag=
e=3D3
[2] =
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/thread.ht=
ml#14314
[3] https://github.com/bitcoin/bitcoin/pull/10387
[4] https://github.com/bitcoin/bitcoin/pull/11740


> Am 21.11.2017 um 04:03 schrieb Sjors Provoost via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org>:
>=20
> 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).
>=20
> It contains a counter-measure for peer fingerprinting. I'm trying to =
understand how that impacts extendibility.
>=20
>> 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.
>=20
> This means pruned nodes can only serve the last 288 blocks:
>=20
>> If signaled, the peer MUST be capable of serving at least the last =
288 blocks (~2 day
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
>=20
> How would such extension be signaled for? Would we need a whole new =
version bit?
>=20
> Would upgraded nodes need a new message type to communicate the chosen =
prune depth? Or can that information tag along some existing message?
>=20
> 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.
>=20
>=20
> 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])
>=20
> Cheers,
>=20
> Sjors
>=20
> [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
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


--Apple-Mail=_CB141DF2-A87E-44D5-A067-BB787ED66146
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-----

iQIzBAEBCAAdFiEEyhopCNzi8TB0xizeHrd2uwPHki0FAloUd8UACgkQHrd2uwPH
ki3iEhAAsLOdnALu5zoLHjR5NCI9inXxJQgfrpVnouOYRsHs21GwDGYJt/0zxiVt
wyKim9+K9CnDLPQU0Bo/1FmZALtKj2I050AYkG/ypMndDJ8zoqk0qqZR0pHeh2BY
+iIm2+Ksc7fzi81KeWadSgreJWHZU6Xa0JmVp3/w8mdG76zC+r7Re98rCKcGdQ5x
s+rQ+kmb51WVNxrVPCnXVjVgFRkivfcUGOR+uS7stJNZE8S4rQyLHPJasMMlc2gI
lbSwk69YCT5KvY7Bco3pWKYvpDWJAEn85MuLoNHJZ3IMcju57kR0gcFE88ltrQir
at8rsL9g409sSY5CHGnfb4edBA6ll0zP+vxUpe+B+ZeHV5Wtx95Xtu6IVgYsj0MQ
UE1GfmlBDZy2CbI4jlikWmnv/dW2z7/kQZx5jS4riu8b70Frf42PFot4eL/8WM2K
+FA4tV6FHevStvDtH5TMxQ5jiEuh48DliL834NC2QDbUpQ7dMuTD9Wcq4iIJmiSC
oqf6tcvG4knbbfGeu5MqvBROELojQ7tmQqL5fI3nOnYCC3GY4vKces7SRCw07NPf
gI6078rxA+6pw5WdVvPyh5Xq5p/7CG0/wrtHxZ2sdxSSwAm71BAO47wGcy2c/GQn
Ns91hIhvppWSSSLDKX5foSXyVPfVoB8Ub4MdTo7bU4r+Rs3HCZ8=
=+bPi
-----END PGP SIGNATURE-----

--Apple-Mail=_CB141DF2-A87E-44D5-A067-BB787ED66146--