{"type":"rich","version":"1.0","author_name":"npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2","author_url":"https://nostr.ae/npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-08-21\n📝 Original message:On Fri, Aug 21, 2015 at 05:55:58PM +0000, Matt Corallo 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\nWell, in general relying on seeds every time you start your node is a\nreally bad idea; doing so much be carefully weighed against the\ndownsides and should be used only as a last resort. Nodes should be\ndoing caching and proper gossip protocol participation whenever\npossible. (note how bitcoinj nodes *do* rely on centralized servers,\nimplemented with an unauthenticated, unencrypted, protocol - the worst\nof all possible solutions with many possible MITM vectors and privacy\nsecurity holes)\n\nTo that end, I'd be inclined to leave the DNS seed protocol as it is and\nlet others solve the centralized server use-case, for which Cartographer\nisn't all that bad of a load balancing mechanism. Also as gmaxwell noted\non IRC, adding flag bits does have privacy implications.\n\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\nAny protocol change that would split blocks themselves into multiples.\nNot an easy problem to solve, but given the inherent O(n^2) scaling of\nglobal consensus blockchains, it's the only kind of solution that could\nin the future make the blockchain itself have reasonable scalability.\n\n\u003e Anyone have the best reference for the DoS issues?\n\nWell actually, we can reference the DoS attacks that Bitcoin XT nodes\nare undergoing right now - part of the attack is repeated Bloom filter\nrequests to soak up disk IO bandwidth. I've CC'd Gavin and Mike - as far\nas I know they haven't published details of those attacks - a write-up\nwould be very helpful.\n\nWhile so far those are being directed only at XT nodes, obviously this\nis a potential issue for Core nodes as well. Like I mentioned last time\naround, it's critical that miners aren't affected by these attacks -\nnodes simply serving SPV wallet clients are much less latency sensitive,\nso a good DoS attack mitigation strategy would be to have the two\nclasses of nodes out there \"in the wild\"\n\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\n-- \n'peter'[:-1]@petertodd.org\n00000000000000000402fe6fb9ad613c93e12bddfc6ec02a2bd92f002050594d\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 650 bytes\nDesc: Digital signature\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150821/206f9582/attachment.sig\u003e"}