{"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:2013-07-18\n📝 Original message:On Wed, Jul 17, 2013 at 02:29:26PM +0200, Mike Hearn wrote:\n\u003e Partial UTXO sets is a neat idea. Unfortunately my intuition is that many\n\u003e SPV wallets only remain open for \u003c1 minute at a time because the user wants\n\u003e to see they received money, or to send it. It'd be neat to get some\n\u003e telemetry from the Android wallet for this - I will ask Andreas to let\n\u003e users opt in to usage statistics.\n\nGood idea.\n\n\u003e So for anti-DoS I think smart prioritisation heuristics are the way to go\n\u003e again. Perhaps by letting clients have an \"identity\" that they provide to a\n\u003e node when it's load shedding. Clients that have been seen before, have a\n\u003e track record of not being abusive etc get priority and new clients that\n\u003e were never seen before get dropped. Coming up with a way to do that whilst\n\u003e preserving privacy sounds like an interesting cryptographic challenge.\n\nSPV clients behaving normally are highly abusive: they use up maximum\nnode resources with minimum cost to themselves. (nodes doing an initial\nblock download are similar now, although with partial mode they can\ncontribute back to the network sooner)\n\nWe can't win if the attacker has more upstream bandwidth than we have\ndownstream, but fortunately botnets are generally comprised of computers\non asymetric residential connections. Thus our goal is to prevent the\nattacker from using lots of downstream bandwidth, and more importantly,\nfrom consuming more memory and similar resources than we posess.\nAnnoyingly the raw # of TCP connections is very much a limited resource\ndue to constraints on the # of ports a process can handle, and\nconstraints imposed by stateful firewalls, and memory used by kernel\nbuffers.\n\nAnything that allows for more incoming connections with less memory\nusage is a good thing - bloom filters are limited to 32KiB and the\nper-peer test if a INV item needs to be relayed to a peer is fairly\ncheap, but we also have other buffers like pending INV messages and so\non. EC2 micro instances, as an example, often need -maxconnections\nlimited or they run out of memory - we've probably got room for\nimprovement; removing mapRelay and just grabbing relayed txs from the\nmempool comes to mind.\n\n\nMore generally a good thing to do would be to force incoming peers to\nuse up RAM to make a connection. We can do that with a proof-of-data\nposession engineered such that unless you store the data in high-speed\nmemory you will have your connection dropped. Per peer a node can pick a\nnonce k and define j_i=H(k+i), sending the peer a set J=(j_0...j_n) to\nstore in RAM. With f(k, n, i) as a pseudo-random sequence generator we\ncreate nonce x and ask our peer to compute J'(x, m) = j_f(x, n, 0) ^ ...\n^ j_f(x, n, m)) and give us the result. (^ as the XOR operator) Because\nwe know the nonce k we can do that cheaply, calculating it on the fly,\nbut our peers have no choice but to store J and retrieve it on demand.\nIf they store J in RAM they can do so quickly; if they store J on disk\nthey can't. We then prioritize peers by how fast they respond to these\nrequests, both measuring ping times, and forcing attackers trying to\nconnect to large numbers of peers to posess large amounts of relatively\nexpensive RAM. This is particularly nice because we've can make it\nsignificantly more expensive for anyone to peer to every node in the\nBitcoin network simultaneously to do things like watch transaction\npropagation in real-time.\n\nA more sophisticated approach would be possible if there existed a\nversion of H() with a computational trap-door - that is if there existed\nH'(s, i)=H(i) where H' had significantly faster running time than H(),\nbut required knowledge of a secret. Our peers would then be able to\nanswer our challenges quickly only if they stored the intermediate\nresults in a lookup table, while we could check those challenges cheaply\nwithout that table.\n\nAdam: you're our local crypto-expert, what can we use for H'? Seems that\nmaybe some kind of asymmetric crypto system would work by requiring the\npeer to crack weak secret keys that we generate deterministicly.\n\n-- \n'peter'[:-1]@petertodd.org\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 490 bytes\nDesc: Digital signature\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130718/edcced21/attachment.sig\u003e"}