{"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:On 08/21/15 22:06, Peter Todd wrote:\n\u003e On Fri, Aug 21, 2015 at 05:55:58PM +0000, Matt Corallo wrote:\n\u003e\u003e Revised copy follows. re: mentioning the HTTP seeding stuff, I'm not\n\u003e\u003e sure we want to encourage more people aside from bitcoinj to use\n\u003e\u003e that...I thought about adding a DNS seed section to this bip, but\n\u003e\u003e decided against it...still, I think we should add the option to select\n\u003e\u003e service bits to DNS seeds ASAP.\n\u003e \n\u003e Well, in general relying on seeds every time you start your node is a\n\u003e really bad idea; doing so much be carefully weighed against the\n\u003e downsides and should be used only as a last resort. Nodes should be\n\u003e doing caching and proper gossip protocol participation whenever\n\u003e possible. (note how bitcoinj nodes *do* rely on centralized servers,\n\u003e implemented with an unauthenticated, unencrypted, protocol - the worst\n\u003e of all possible solutions with many possible MITM vectors and privacy\n\u003e security holes)\n\u003e\n\u003e To that end, I'd be inclined to leave the DNS seed protocol as it is and\n\u003e let others solve the centralized server use-case, for which Cartographer\n\u003e isn't all that bad of a load balancing mechanism. Also as gmaxwell noted\n\u003e on IRC, adding flag bits does have privacy implications.\n\nHad a discussion on IRC and with Pieter, and I kinda agree that the more\noptimal way is for DNS seeds to, instead of returning NODE_NETWORK\nnodes, return any node which responds to getaddr, allowing clients to\nconnect to a few DNS seeds by name, do a getaddr, then disconnect (like\nBitcoin Core does now if you're using Tor). They can then select the\npeers they want based on nServices.\n\n\u003e\u003e Re: need to \"shard\" the blockchain: not sure what you're referring to\n\u003e\u003e here. The bloom filter stuff requires you to download the chain\n\u003e\u003e in-order, sure, but you have to do that for headers anyway, and\n\u003e\u003e hopefully your total data isnt too much more than headers alone.\n\u003e \n\u003e Any protocol change that would split blocks themselves into multiples.\n\u003e Not an easy problem to solve, but given the inherent O(n^2) scaling of\n\u003e global consensus blockchains, it's the only kind of solution that could\n\u003e in the future make the blockchain itself have reasonable scalability.\n\nMeh, whatever, justification is already provided well enough without\nhaving to go into \"but if we did this long into the future\"  arguments.\n\n\u003e\u003e Anyone have the best reference for the DoS issues?\n\u003e \n\u003e Well actually, we can reference the DoS attacks that Bitcoin XT nodes\n\u003e are undergoing right now - part of the attack is repeated Bloom filter\n\u003e requests to soak up disk IO bandwidth. I've CC'd Gavin and Mike - as far\n\u003e as I know they haven't published details of those attacks - a write-up\n\u003e would be very helpful.\n\u003e \n\u003e While so far those are being directed only at XT nodes, obviously this\n\u003e is a potential issue for Core nodes as well. Like I mentioned last time\n\u003e around, it's critical that miners aren't affected by these attacks -\n\u003e nodes simply serving SPV wallet clients are much less latency sensitive,\n\u003e so a good DoS attack mitigation strategy would be to have the two\n\u003e classes of nodes out there \"in the wild\"\n\nEhh, I was going more for the oldest mention.\n\n\u003e\u003e BIP: ?\n\u003e\u003e Title: NODE_BLOOM service bit\n\u003e\u003e Author: Matt Corallo \u003cbip at bluematt.me\u003e, Peter Todd \u003cpete at petertodd.org\u003e\n\u003e\u003e Type: Standards Track (draft)\n\u003e\u003e Created: 20-08-2015\n\u003e\u003e\n\u003e\u003e Abstract\n\u003e\u003e ========\n\u003e\u003e\n\u003e\u003e This BIP extends BIP 37, Connection Bloom filtering, by defining a\n\u003e\u003e service bit to allow peers to advertise that they support bloom filters\n\u003e\u003e explicitly. It also bumps the protocol version to allow peers to\n\u003e\u003e identify old nodes which allow bloom filtering of the connection despite\n\u003e\u003e lacking the new service bit.\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e Motivation\n\u003e\u003e ==========\n\u003e\u003e\n\u003e\u003e BIP 37 did not specify a service bit for the bloom filter service, thus\n\u003e\u003e implicitly assuming that all nodes that serve peers data support it.\n\u003e\u003e However, the connection filtering algorithm proposed in BIP 37, and\n\u003e\u003e implemented in several clients today, has been shown to provide little\n\u003e\u003e to no privacy[1], as well as being a large DoS risk on some nodes[2].\n\u003e\u003e Thus, allowing node operators to disable connection bloom filtering is a\n\u003e\u003e much-needed feature.\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e Specification\n\u003e\u003e =============\n\u003e\u003e\n\u003e\u003e The following protocol bit is added:\n\u003e\u003e\n\u003e\u003e     NODE_BLOOM = (1 \u003c\u003c 2)\n\u003e\u003e\n\u003e\u003e Nodes which support bloom filters should set that protocol bit.\n\u003e\u003e Otherwise it should remain unset. In addition the protocol version is\n\u003e\u003e increased from 70002 to 70011 in the reference implementation. It is\n\u003e\u003e often the case that nodes which have a protocol version smaller than\n\u003e\u003e 70011, but larger than 70000 support bloom filtered connections without\n\u003e\u003e the NODE_BLOOM bit set, however clients which require bloom filtered\n\u003e\u003e connections should avoid making this assumption.\n\u003e\u003e\n\u003e\u003e NODE_BLOOM is distinct from NODE_NETWORK, and it is legal to advertise\n\u003e\u003e NODE_BLOOM but not NODE_NETWORK (eg for nodes running in pruned mode\n\u003e\u003e which, nonetheless, provide filtered access to the data which they do have).\n\u003e\u003e\n\u003e\u003e If a node does not support bloom filters but receives a \"filterload\",\n\u003e\u003e \"filteradd\", or \"filterclear\" message from a peer the node should\n\u003e\u003e disconnect that peer immediately. For backwards compatibility, in\n\u003e\u003e initial implementations, nodes may choose to only disconnect nodes which\n\u003e\u003e have the new protocol version set and attempt to send a filter command.\n\u003e\u003e\n\u003e\u003e While outside the scope of this BIP it is suggested that DNS seeds and\n\u003e\u003e other peer discovery mechanisms support the ability to specify the\n\u003e\u003e services required; current implementations simply check only that\n\u003e\u003e NODE_NETWORK is set.\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e Design rational\n\u003e\u003e ===============\n\u003e\u003e\n\u003e\u003e A service bit was chosen as applying a bloom filter is a service.\n\u003e\u003e\n\u003e\u003e The increase in protocol version is for backwards compatibility. In\n\u003e\u003e initial implementations, old nodes which are not yet aware of NODE_BLOOM\n\u003e\u003e and use a protocol version \u003c 70011 may still send filter* messages to a\n\u003e\u003e node without NODE_BLOOM. This feature may be removed after there are\n\u003e\u003e sufficient NODE_BLOOM nodes available and SPV clients have upgraded,\n\u003e\u003e allowing node operators to fully close the bloom-related DoS vectors.\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e Reference Implementation\n\u003e\u003e ========================\n\u003e\u003e\n\u003e\u003e https://github.com/bitcoin/bitcoin/pull/6579\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e Copyright\n\u003e\u003e =========\n\u003e\u003e\n\u003e\u003e This document is placed in the public domain.\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e References\n\u003e\u003e ==========\n\u003e\u003e\n\u003e\u003e [1] http://eprint.iacr.org/2014/763\n\u003e\u003e [2] ???? is one example where the issues were found, though others\n\u003e\u003e independently discovered issues as well. Sample DoS exploit code\n\u003e\u003e available at https://github.com/petertodd/bloom-io-attack.\n\u003e"}