Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id D7A24C1C for ; Tue, 21 Nov 2017 19:00:31 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from bitcoin.jonasschnelli.ch (bitcoinsrv.jonasschnelli.ch [138.201.55.219]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id ADA4B8A for ; Tue, 21 Nov 2017 19:00:30 +0000 (UTC) Received: by bitcoin.jonasschnelli.ch (Postfix, from userid 1002) id A46D515E48DC; Tue, 21 Nov 2017 20:00:29 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD autolearn=ham version=3.3.1 Received: from [192.168.1.2] (cpe-66-91-52-81.hawaii.res.rr.com [66.91.52.81]) by bitcoin.jonasschnelli.ch (Postfix) with ESMTPSA id 7509115E275C; Tue, 21 Nov 2017 20:00:28 +0100 (CET) From: Jonas Schnelli 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: To: Sjors Provoost , Bitcoin Protocol Discussion In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3273) X-Virus-Scanned: clamav-milter 0.99.2 at bitcoinsrv.jonasschnelli.ch X-Virus-Status: Clean Subject: Re: [bitcoin-dev] BIP159 - NODE_NETWORK_LIMITED service bits, extendability X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Nov 2017 19:00:32 -0000 --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 [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 = : >=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--