{"type":"rich","version":"1.0","author_name":"npub1e46n428mcyfwznl7nlsf6d3s7rhlwm9x3cmkuqzt3emmdpadmkaqqjxmcu","author_url":"https://nostr.ae/npub1e46n428mcyfwznl7nlsf6d3s7rhlwm9x3cmkuqzt3emmdpadmkaqqjxmcu","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-08-21\n📝 Original message:BIP Editor: Can I get a BIP # for this?\n\nOn 08/21/15 17:55, Matt Corallo via bitcoin-dev wrote:\n\u003e Revised copy follows. re: mentioning the HTTP seeding stuff, I'm not\n\u003e sure we want to encourage more people aside from bitcoinj to use\n\u003e that...I thought about adding a DNS seed section to this bip, but\n\u003e decided against it...still, I think we should add the option to select\n\u003e service bits to DNS seeds ASAP.\n\u003e \n\u003e Re: need to \"shard\" the blockchain: not sure what you're referring to\n\u003e here. The bloom filter stuff requires you to download the chain\n\u003e in-order, sure, but you have to do that for headers anyway, and\n\u003e hopefully your total data isnt too much more than headers alone.\n\u003e \n\u003e Anyone have the best reference for the DoS issues?\n\u003e \n\u003e BIP: ?\n\u003e Title: NODE_BLOOM service bit\n\u003e Author: Matt Corallo \u003cbip at bluematt.me\u003e, Peter Todd \u003cpete at petertodd.org\u003e\n\u003e Type: Standards Track (draft)\n\u003e Created: 20-08-2015\n\u003e \n\u003e Abstract\n\u003e ========\n\u003e \n\u003e This BIP extends BIP 37, Connection Bloom filtering, by defining a\n\u003e service bit to allow peers to advertise that they support bloom filters\n\u003e explicitly. It also bumps the protocol version to allow peers to\n\u003e identify old nodes which allow bloom filtering of the connection despite\n\u003e lacking the new service bit.\n\u003e \n\u003e \n\u003e Motivation\n\u003e ==========\n\u003e \n\u003e BIP 37 did not specify a service bit for the bloom filter service, thus\n\u003e implicitly assuming that all nodes that serve peers data support it.\n\u003e However, the connection filtering algorithm proposed in BIP 37, and\n\u003e implemented in several clients today, has been shown to provide little\n\u003e to no privacy[1], as well as being a large DoS risk on some nodes[2].\n\u003e Thus, allowing node operators to disable connection bloom filtering is a\n\u003e much-needed feature.\n\u003e \n\u003e \n\u003e Specification\n\u003e =============\n\u003e \n\u003e The following protocol bit is added:\n\u003e \n\u003e     NODE_BLOOM = (1 \u003c\u003c 2)\n\u003e \n\u003e Nodes which support bloom filters should set that protocol bit.\n\u003e Otherwise it should remain unset. In addition the protocol version is\n\u003e increased from 70002 to 70011 in the reference implementation. It is\n\u003e often the case that nodes which have a protocol version smaller than\n\u003e 70011, but larger than 70000 support bloom filtered connections without\n\u003e the NODE_BLOOM bit set, however clients which require bloom filtered\n\u003e connections should avoid making this assumption.\n\u003e \n\u003e NODE_BLOOM is distinct from NODE_NETWORK, and it is legal to advertise\n\u003e NODE_BLOOM but not NODE_NETWORK (eg for nodes running in pruned mode\n\u003e which, nonetheless, provide filtered access to the data which they do have).\n\u003e \n\u003e If a node does not support bloom filters but receives a \"filterload\",\n\u003e \"filteradd\", or \"filterclear\" message from a peer the node should\n\u003e disconnect that peer immediately. For backwards compatibility, in\n\u003e initial implementations, nodes may choose to only disconnect nodes which\n\u003e have the new protocol version set and attempt to send a filter command.\n\u003e \n\u003e While outside the scope of this BIP it is suggested that DNS seeds and\n\u003e other peer discovery mechanisms support the ability to specify the\n\u003e services required; current implementations simply check only that\n\u003e NODE_NETWORK is set.\n\u003e \n\u003e \n\u003e Design rational\n\u003e ===============\n\u003e \n\u003e A service bit was chosen as applying a bloom filter is a service.\n\u003e \n\u003e The increase in protocol version is for backwards compatibility. In\n\u003e initial implementations, old nodes which are not yet aware of NODE_BLOOM\n\u003e and use a protocol version \u003c 70011 may still send filter* messages to a\n\u003e node without NODE_BLOOM. This feature may be removed after there are\n\u003e sufficient NODE_BLOOM nodes available and SPV clients have upgraded,\n\u003e allowing node operators to fully close the bloom-related DoS vectors.\n\u003e \n\u003e \n\u003e Reference Implementation\n\u003e ========================\n\u003e \n\u003e https://github.com/bitcoin/bitcoin/pull/6579\n\u003e \n\u003e \n\u003e Copyright\n\u003e =========\n\u003e \n\u003e This document is placed in the public domain.\n\u003e \n\u003e \n\u003e References\n\u003e ==========\n\u003e \n\u003e [1] http://eprint.iacr.org/2014/763\n\u003e [2] ???? is one example where the issues were found, though others\n\u003e independently discovered issues as well. Sample DoS exploit code\n\u003e available at https://github.com/petertodd/bloom-io-attack.\n\u003e \n\u003e \n\u003e \n\u003e On 08/21/15 05:42, Peter Todd wrote:\n\u003e\u003e On Thu, Aug 20, 2015 at 10:38:19PM -0700, Peter Todd via bitcoin-dev wrote:\n\u003e\u003e\u003e\u003e Motivation\n\u003e\u003e\u003e\u003e ==========\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e BIP 37 did not specify a service bit for the bloom filter service, thus\n\u003e\u003e\u003e\u003e implicitly assuming that all nodes that serve peers data support it.\n\u003e\u003e\u003e\u003e However, the connection filtering algorithm proposed in BIP 37, and\n\u003e\u003e\u003e\u003e implemented in several clients today, has been shown to provide little\n\u003e\u003e\u003e\u003e to no privacy, as well as being a large DoS risk on some nodes. Thus,\n\u003e\u003e\u003e\u003e allowing node operators to disable connection bloom filtering is a\n\u003e\u003e\u003e\u003e much-needed feature.\n\u003e\u003e\u003e\n\u003e\u003e\u003e I'd reference that paper on bloom filters re: the \"little to no privacy\"\n\u003e\u003e\u003e issue. There's also a post in the bitcoinj mailing list somewhere IIRC\n\u003e\u003e\u003e talking about the default settings, and how they don't provide any\n\u003e\u003e\u003e privacy.\n\u003e\u003e\n\u003e\u003e Oh, and we should also point out that Bloom filters have scaling issues,\n\u003e\u003e as each application of the filter has to scan the whole blockchain -\n\u003e\u003e with future blocksize increases these issues increase, in some proposals\n\u003e\u003e quite dramatically. The underlying idea also conflicts with some\n\u003e\u003e proposals to \"shard\" the blockchain, again suggesting that we need a bit\n\u003e\u003e to handle future upgrades to more scalable designs.\n\u003e\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e"}