{"type":"rich","version":"1.0","author_name":"npub1s4lj77xuzcu7wy04afcr487f0r3za0f8n2775xrpkld2sv639mjqsd44kw","author_url":"https://nostr.ae/npub1s4lj77xuzcu7wy04afcr487f0r3za0f8n2775xrpkld2sv639mjqsd44kw","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2011-09-14\n🗒️ Summary of this message: The pull request proposes a system to punish peers sending wrong information by dropping the connection and banning their IP address. Misbehavior information is stored in memory, and peers are not warned or given a reason for disconnection. The system aims to prevent potential denial-of-service attacks and could be a framework for responding to other attacks. The danger is that an attacker could leverage the system to split or shatter the network, but the author believes that relying on TCP, penalizing only non-relayable messages, and not punishing peers for double-spends should prevent this.\n📝 Original message:I'm looking for review of this pull request:\n  https://github.com/bitcoin/bitcoin/pull/517\n\nThe big idea: if a peer is sending you obviously wrong information,\npunish it by maybe dropping your connection to it, and ban it's IP\naddress so it cannot immediately re-connect.\n\nThe probability of dropping the connection, and the length of the ban,\ndepend on how how potentially wasteful/damaging the peer is behaving.\nSo sending an extra 'version' message is a minor transgression that is\nusually tolerated, sending a more-than MAX_BLOCK_SIZE block is a major\ntransgression that gets the peer disconnected immediately.\n\nDetailed how-it-works, using \"I got a version message I wasn't\nexpecting\" as the specific example:\n\nGetting an unexpected version message from a peer increases that\npeer's 'misbehaving' score by 10, and (assuming that is the peer's\nfirst bad behavior) gives it a 10% chance of being disconnected.  If\nit is disconnected, then that peer's IP address is banned from\nconnecting for a couple of hours.  If it is not disconnected, then\nnothing happens unless the peer misbehaves again; if it does, then its\nchances of being disconnected go up, and the length of time it will be\nbanned increases.\n\nMisbehavior/ban information is stored only in memory, and information\nabout misbehaving peers is never broadcast. Also, peers that are\ndisconnected/banned are just dropped, there is no warning or reason\nsent.\n\nI think this will eliminate a lot of potential denial-of-service\nattacks, and could be a good framework for responding to other\npotential attacks. \"We\" should still look through the code and limit\nthe potential size of any data structures that an attacker might\ntarget (transaction pool, orphan block pool); the DoSprevention\nchanges are meant to make it harder for an attacker to stay connected\nlong enough to pull off an attack.\n\nThe danger is that I got something wrong; what if an attacker can\nleverage the DoSprevention code to split or shatter the network?\nHere's my thinking on that, please help check my work:\n\n+ I'm relying on TCP to prevent IP address spoofing (otherwise an\nattacker could force you to disconnect from your peers by pretending\nto be them and sending you a bad block).\n\n+ Peers are only penalized for sending messages that won't, and\nshouldn't, get relayed. So an attacker shouldn't be able to poison the\nnetwork with a bad message that is propogated and then causes\neverybody to disconnect from everybody else.\n\n+ I specifically do not punish peers for relaying what look like\ndouble-spend transactions. If I did, then an attacker could try to\nsegment the network into two pieces by broadcasting a series of\ndouble-spends from two halves of the network, and waiting until the\nnodes \"in the middle\" disconnected/banned across the 'seam'.\n\nSo: please let me know if or how I'm being an idiot.\n\n-- \n--\nGavin Andresen"}