Published on: 2011-09-16T12:57:20+00:00
In a discussion about protecting Bitcoin's connection, there is a debate between failing hard and failing soft. Failing hard would immediately alert people to the problem and allow for quick fixes, while failing soft could lead to network and blockchain issues. The preference is for failing hard with detection and notification if a GUI is connected. Gavin Andresen removes a snarky comment from a list on bitcoin-dev and requests that comments stay on-topic. This response was prompted by a 0-day exploit.In an email conversation, Gavin Andresen responds to criticism of ignoring bandwidth DoS attacks. Another participant claims that the current implementation is a memory exhaustion DoS waiting to happen and does nothing to prevent flooding. When asked if they submitted a patch, they explain that it would require significant changes to the p2p network code, which are not accepted. This issue has been acknowledged multiple times on IRC.A user discusses transaction patterns on a network, noting that most transactions follow a standard pattern. If a transaction deviates from this pattern, it may raise suspicion, but it's not necessarily a cause for concern. However, emitting dozens or hundreds of non-standard transactions may warrant further investigation. Another user points out that disconnecting the emitting node may not be effective if they are simply relaying transactions from other sources.Laszlo Hanyecz expresses disapproval of peer disconnection in the reference client implementation and suggests implementing filtering in a separate bitcoin proxy. They believe built-in filtering limits future innovation and that people's policies will differ.The author questions why they should be nice to someone suspected of a DoS attack but acknowledges that sometimes it may not be an actual attack. They argue against sending response messages, as it could give attackers another vector for attack. Debug.log is suggested as a clear way to indicate ban triggers, but it may only be clear to the node owner. The author suggests that protocols can return useful errors even in DoS conditions, proposing more effective ways to handle suspected DoS attacks without compromising security or transparency.A mailing list conversation discusses potential DoS attacks on non-standard transactions and the challenges of dealing with new standard transaction types. The code already refuses to relay non-standard transactions and those with insufficient fees. Luke-Jr argues against penalizing these transactions and suggests they should be considered relay/miner policy decisions instead.The post debates automatically disabling DoS protection for Bitcoin nodes with fewer connections and whether to send a message indicating the reason for banning. Concerns are raised about potential attack vectors. Chris proposes a BitTorrent-like protocol for handling misbehaving peers but advises against sharing blacklist decisions. He suggests incorporating choking/unchoking to warn peers of potential dropping if they continue misbehaving. Conservative rules initially are recommended to avoid hindering future development.In response to a pull request by Gavin Andresen, Luke-Jr argues that non-standard transactions or those with insufficient fees are relay/miner policy decisions, not protocol violations. Luke-Jr suggests making them easily configurable instead of penalizing them, enhancing the overall protocol.Gavin Andresen's review in September 2011 involves a pull request related to punishing peers providing incorrect information. The proposed action is to drop the connection and ban their IP address, severity depending on potential harm. TCP is relied upon to prevent IP address spoofing, and peers are only penalized for messages that should not be relayed to avoid network fragmentation.The email concludes with a link to an article discussing challenges faced by mid-market businesses when deploying virtual desktops and how next-generation virtual desktops offer a cost-effective and manageable solution.
Updated on: 2023-08-01T02:28:17.460947+00:00