{"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 Sat, Aug 22, 2015 at 01:08:13AM +0000, Matt Corallo wrote:\n\u003e \u003e Well actually, we can reference the DoS attacks that Bitcoin XT nodes\n\u003e \u003e are undergoing right now - part of the attack is repeated Bloom filter\n\u003e \u003e requests to soak up disk IO bandwidth. I've CC'd Gavin and Mike - as far\n\u003e \u003e as I know they haven't published details of those attacks - a write-up\n\u003e \u003e would be very helpful.\n\u003e \u003e \n\u003e \u003e While so far those are being directed only at XT nodes, obviously this\n\u003e \u003e is a potential issue for Core nodes as well. Like I mentioned last time\n\u003e \u003e around, it's critical that miners aren't affected by these attacks -\n\u003e \u003e nodes simply serving SPV wallet clients are much less latency sensitive,\n\u003e \u003e so a good DoS attack mitigation strategy would be to have the two\n\u003e \u003e classes of nodes out there \"in the wild\"\n\u003e \n\u003e Ehh, I was going more for the oldest mention.\n\nOne of the oldest mentions is the to-be-published-later portion of my\nLitecoin Audit report; attached.\n\n(see http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-July/003044.html\nfor the original report/timestamping/verification)\n\n-- \n'peter'[:-1]@petertodd.org\n00000000000000000939524874a2896a46ea96bf59776ed869ccff95679cb087\n-------------- next part --------------\nSecurity vulnerabilities related to the Litecoin v0.8.3.6 release\n=================================================================\n\nNonce: c0854ae01b1ed8526af3bb6fb82550ff\nDate:  Jul 29 2013\n\nTo be released in full on January 29, 2014 to the public.\n\n\nLevelDB\n=======\n\nSomething not well appreciated outside of the Bitcoin developers is that the\ntemporary limits on block size and complexity introduced in response to the\nfork, automatically removed on May 15th, were simply voluntary measures to\nprotect against accidental triggering of the fork. The measures did not protect\nagainst malicious attempts to trigger the the fork.\n\nLitecoin is no different. Because of that I strongly recomend that miners be\nencouraged to transition to v0.8.3.6 as soon as possible to ensure as much\nhashing power as possible is consolidated on one version. Transitioning for\nusers/merchants is also important, however with sufficient mining power on the\nnew version it would be difficult to pull off a double-spend attack against an\nolder version simply because it would take so long to get the required number\nof confirmations.\n\nThe development team may want to clarify this point to the Litecoin community\nand encourage users to be suspicious if it takes an especially long time to get\nconfirmations. Merchants with automatic systems should use fail-safes triggered\nby unusually long confirmation times, and as always ensure that total possible\nlosses are limited. It would be good if popular \"blockchain information\" sites\nupgraded to v0.8.3.6 along with miners to give users accurate information on\nthe state of the blockchain. In any case users and merchants should take this\nadvice in general regardless of specific threats.\n\nI would not be surprised to see someone deliberately attempt to fork Litecoin\nby exploiting the issue; there is a lot of hostility torwards and within the\nalt-coins.\n\n\nSPV and network-wide DoS attacks\n================================\n\nBitcoin is quite vulnerable currently to network-wide DoS attacks due to the\nmaximum connections limits; we do not have any form of filtering on incoming\nconnections so an attack can be made simply by making sufficient connections to\nall nodes that they hit that incoming connections limit. This is public\nknowledge, as is the suggestion to stop the attack by having concepts of peer\n\"usefullness\" so that \"useless\" peers can be dropped. Of course SPV nodes are\nbadly impacted by such measures.\n\nWhat isn't as well-known publicly is that Litecoin will make this attack\nsignificantly less costly to the attacker in v0.8.3.6 by adding support for\nbloom filters. That support allows the attacker to reduce their bandwidth\nconsumption to a minimum, making the attack easier to pull off on a wide scale.\n\nThe Bitcoin team is aware of the issue. Our plans in the event of an attack are\nto ensure that large pools and merchants connect to each other via a private\n\"darknet\" while fixes are implemented. These plans are also useful in the event\nof an attack exploiting the vulnerability discussed below.\n\n\nBloom filters and disk IO\n=========================\n\nHowever it gets worse: there is nothing limiting peers from requesting blocks.\nWithout bloom filters bandwidth is a natural limit, however with bloom filters\na malicious peer can simply set the filter to match almost nothing and simply\nsubmit getdata messages to the target requesting all blocks. The target will do\nan extremely large amount of disk IO at almost no cost to the attacker.\n\nTo quote one core developer in a private conversation regarding bloom filtering\n\"I think we didn't think hard enough before implementing this\"\n\nA good first measure would be to assign a service bit to advertise bloom filter\nsupport:\n\n /** nServices flags */\n enum\n {\n     NODE_NETWORK = (1 \u003c\u003c 0),\n+    NODE_BLOOM_FILTER = (1 \u003c\u003c 1),\n };\n\nSecondly add a command line switch that allows bloom filtering to be turned on\nor off entirely. I would suggest that the next version of Litecoin be released\nsoon and have bloom filters *disabled* by default unless the user specifically\nturns them on.\n\nThere is a *very* good chance of an attack being launched targetting this\nvulnerability by people using it as a way to show their opinion of Mike Hearn;\nlots of people strongly dislike him for what they regard as very poor judgement\non security and scalability issues and would be happy to show that a design he\npromoted is flawed.\n\nDisabling bloom filering does of course cause problems for SPV clients, however\nin the Litecoin realm such clients are non-existent. In the long run DNS seeds\nshould allow for the specification of desired service bits and rate limiting of\ngetdata operations implemented. However given that attacks are likely imminent\nI strongly suggest a quick solution.\n\nBitcoin should have done bloom filtering as a service bit on day one; not doing\nso was a mistake.\n\nThe Bitcoin team is aware of this issue. Please contact me to discuss the\nrelease process for a fix; I will also be happy to review it. Unfortunately due\nto the impact on SPV clients this issue is political as well as technical on\nthe Bitcoin side of things.\n\n\nCHECKMULTISIG dummy value\n=========================\n\nThe AreInputsStandard() test does not check the contents of the dummy value\nrequired to spend a BIP11 CHECKMULTISIG scriptPubKey; anything that be put in\nthat space as a way to get data into the blockchain. Less well appreciated is\nthat because scriptSigs are unsigned any node, even a non-miner, can change the\ntxid of a CHECKMULTISIG transaction by modifying the dummy value.\n\nThis issue will probably be fixed in Bitcoin soon, not to mention revealed\npublically; I'm only including it for the sake of completeness.\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/d43573b7/attachment.sig\u003e"}