{"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:Revised copy follows. re: mentioning the HTTP seeding stuff, I'm not\nsure we want to encourage more people aside from bitcoinj to use\nthat...I thought about adding a DNS seed section to this bip, but\ndecided against it...still, I think we should add the option to select\nservice bits to DNS seeds ASAP.\n\nRe: need to \"shard\" the blockchain: not sure what you're referring to\nhere. The bloom filter stuff requires you to download the chain\nin-order, sure, but you have to do that for headers anyway, and\nhopefully your total data isnt too much more than headers alone.\n\nAnyone have the best reference for the DoS issues?\n\nBIP: ?\nTitle: NODE_BLOOM service bit\nAuthor: Matt Corallo \u003cbip at bluematt.me\u003e, Peter Todd \u003cpete at petertodd.org\u003e\nType: Standards Track (draft)\nCreated: 20-08-2015\n\nAbstract\n========\n\nThis BIP extends BIP 37, Connection Bloom filtering, by defining a\nservice bit to allow peers to advertise that they support bloom filters\nexplicitly. It also bumps the protocol version to allow peers to\nidentify old nodes which allow bloom filtering of the connection despite\nlacking the new service bit.\n\n\nMotivation\n==========\n\nBIP 37 did not specify a service bit for the bloom filter service, thus\nimplicitly assuming that all nodes that serve peers data support it.\nHowever, the connection filtering algorithm proposed in BIP 37, and\nimplemented in several clients today, has been shown to provide little\nto no privacy[1], as well as being a large DoS risk on some nodes[2].\nThus, allowing node operators to disable connection bloom filtering is a\nmuch-needed feature.\n\n\nSpecification\n=============\n\nThe following protocol bit is added:\n\n    NODE_BLOOM = (1 \u003c\u003c 2)\n\nNodes which support bloom filters should set that protocol bit.\nOtherwise it should remain unset. In addition the protocol version is\nincreased from 70002 to 70011 in the reference implementation. It is\noften the case that nodes which have a protocol version smaller than\n70011, but larger than 70000 support bloom filtered connections without\nthe NODE_BLOOM bit set, however clients which require bloom filtered\nconnections should avoid making this assumption.\n\nNODE_BLOOM is distinct from NODE_NETWORK, and it is legal to advertise\nNODE_BLOOM but not NODE_NETWORK (eg for nodes running in pruned mode\nwhich, nonetheless, provide filtered access to the data which they do have).\n\nIf a node does not support bloom filters but receives a \"filterload\",\n\"filteradd\", or \"filterclear\" message from a peer the node should\ndisconnect that peer immediately. For backwards compatibility, in\ninitial implementations, nodes may choose to only disconnect nodes which\nhave the new protocol version set and attempt to send a filter command.\n\nWhile outside the scope of this BIP it is suggested that DNS seeds and\nother peer discovery mechanisms support the ability to specify the\nservices required; current implementations simply check only that\nNODE_NETWORK is set.\n\n\nDesign rational\n===============\n\nA service bit was chosen as applying a bloom filter is a service.\n\nThe increase in protocol version is for backwards compatibility. In\ninitial implementations, old nodes which are not yet aware of NODE_BLOOM\nand use a protocol version \u003c 70011 may still send filter* messages to a\nnode without NODE_BLOOM. This feature may be removed after there are\nsufficient NODE_BLOOM nodes available and SPV clients have upgraded,\nallowing node operators to fully close the bloom-related DoS vectors.\n\n\nReference Implementation\n========================\n\nhttps://github.com/bitcoin/bitcoin/pull/6579\n\n\nCopyright\n=========\n\nThis document is placed in the public domain.\n\n\nReferences\n==========\n\n[1] http://eprint.iacr.org/2014/763\n[2] ???? is one example where the issues were found, though others\nindependently discovered issues as well. Sample DoS exploit code\navailable at https://github.com/petertodd/bloom-io-attack.\n\n\n\nOn 08/21/15 05:42, Peter Todd wrote:\n\u003e On Thu, Aug 20, 2015 at 10:38:19PM -0700, Peter Todd via bitcoin-dev wrote:\n\u003e\u003e\u003e Motivation\n\u003e\u003e\u003e ==========\n\u003e\u003e\u003e\n\u003e\u003e\u003e BIP 37 did not specify a service bit for the bloom filter service, thus\n\u003e\u003e\u003e implicitly assuming that all nodes that serve peers data support it.\n\u003e\u003e\u003e However, the connection filtering algorithm proposed in BIP 37, and\n\u003e\u003e\u003e implemented in several clients today, has been shown to provide little\n\u003e\u003e\u003e to no privacy, as well as being a large DoS risk on some nodes. Thus,\n\u003e\u003e\u003e allowing node operators to disable connection bloom filtering is a\n\u003e\u003e\u003e much-needed feature.\n\u003e\u003e\n\u003e\u003e I'd reference that paper on bloom filters re: the \"little to no privacy\"\n\u003e\u003e issue. There's also a post in the bitcoinj mailing list somewhere IIRC\n\u003e\u003e talking about the default settings, and how they don't provide any\n\u003e\u003e privacy.\n\u003e \n\u003e Oh, and we should also point out that Bloom filters have scaling issues,\n\u003e as each application of the filter has to scan the whole blockchain -\n\u003e with future blocksize increases these issues increase, in some proposals\n\u003e quite dramatically. The underlying idea also conflicts with some\n\u003e proposals to \"shard\" the blockchain, again suggesting that we need a bit\n\u003e to handle future upgrades to more scalable designs.\n\u003e"}