From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id B1651BF2 for ; Tue, 21 Nov 2017 14:03:51 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E0CF51AE for ; Tue, 21 Nov 2017 14:03:50 +0000 (UTC) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id F022620D27 for ; Tue, 21 Nov 2017 09:03:49 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Tue, 21 Nov 2017 09:03:49 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sprovoost.nl; h= content-type:date:from:message-id:mime-version:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=wYxPPE0R+6rCZpZlU RZxpDNnD70FM7E2Tt/PBCGl2pQ=; b=BEwFMo1Zb7mRP/l0X/iJQg25VGXPXkZPX EkUBLfywITkZxnSl4eirq3gE2Pp4lkz06t4uRlqHclfoeZqDm03+SbNrQqL/Jw6i s8jmSPUhFNS0CubSYDdVGQ5gPZibYMrzSmOwCDSEY1QadhhVKD6of1JauSTOL96F 0UXe2tyO0Ym1bRn75v161Z/W4FkWyw1ibq2HTwDMLyYmWtuADiY3vXCIrvQzr6rh tNhYqNWcJ5e/plt8tTpnSMA8X+ieS8uzChk4P00lxLH7Zyn7uRqFmwgOU9FWP+HV rGjxyf1+bGSBMrByjr6p1q1UryLzG2iWNIl3BV+giEQW1caVoSg5Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=wYxPPE0R+6rCZpZlURZxpDNnD70FM7E2Tt/PBCGl2pQ=; b=JZNu4RvB EB3XuYTKxQogMw/te4UW9U8Xo028t+XnYAFryt6UY3but+UVimX8Gp5pGmKhgdiN IfRSsWsI80n1mWvAmfOFrOfZK43syuRWwrtMs16mSSpQr2z7iFGW7R7fFUY8o2gT PJrT7Ri88YfKxnee+NA/zekqn4anXtbzRFNMcZukbuhrBhfK0rtuigWndmSo5MQP Zq0gDEuQi2/frD0Ekq9L5NLIk8GKOmBhh8MtzDeXsprG5M61z2KsK+GWWiYDArAy VAo94+PVqHj308+yTKCgfwsWHRyUQf6Hi30epy04e/8tmdlhI8JJ+QvsKcF1nYqR aAqUQb+43UUVSA== X-ME-Sender: Received: from [192.168.178.108] (54693d0f.cm-12-2a.dynamic.ziggo.nl [84.105.61.15]) by mail.messagingengine.com (Postfix) with ESMTPA id A285924B36 for ; Tue, 21 Nov 2017 09:03:48 -0500 (EST) From: Sjors Provoost 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: Date: Tue, 21 Nov 2017 15:03:46 +0100 To: Bitcoin Dev X-Mailer: Apple Mail (2.3445.4.7) X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, 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: Tue, 21 Nov 2017 14:58:46 +0000 Subject: [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 14:03:51 -0000 --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--