Published on: 2011-09-27T20:39:32+00:00
The code in question contains a function called "AcceptBlock()" that has a "belt-and-suspenders just in case" check to prevent potential bugs or edge cases from being exploited. This check ensures that the previous block index is found using a map iterator, and if it isn't found, a DoS error with the message "prev block not found" is returned.Luke-Jr raised a question about whether it is possible for a peer with more blocks than you to trigger this error. It was suggested that a global flag be created to indicate when the node believes it is current with the network, and this flag could be used to determine when to enforce the check. The currency of the node could be determined by factors such as height, last checkpoint, top timestamp, and a safe amount. The safe amount should be set high enough to avoid falsely triggering the error due to an unlikely long gap.In a conversation, Gavin Andresen confirmed that relaying transactions with fewer than 99 confirmations is currently allowed in blocks. However, the decision to relay or accept such transactions is up to individual discretion. He acknowledged making an error in his previous thoughts on the matter, where he mistakenly considered blocks instead of transactions. He expressed a desire to be perfect for the rest of the week, indicating that he has learned from this mistake.In an email exchange between Luke-Jr and an unknown recipient, they discussed the allowance of certain transactions in blocks and the limit on these transactions. Luke-Jr argued that there should be no punishment for relaying these transactions, as the limit seems pointless and people will simply add more data. He also expressed his belief that the coinbase maturity DoS limit should not immediately kick a node, as this could occur naturally in rare cases. Rejecting these transactions would be relatively inexpensive. However, Luke-Jr suggested that a small DoS score would be reasonable.Gavin Andresen discussed the validity of transactions with "non-standard" signature operation counts and the issue of nodes banning each other. The code checks for the number of SigOps in a transaction to avoid denial-of-service attacks and rejects transactions with more than one SigOp per 34 bytes. Although currently allowed in blocks, Gavin had difficulty imagining a scenario where there would be more than one SigOp per 34 bytes. However, he acknowledged that it is presently valid and should not be punished. He explained that rejecting a transaction from someone who has 100 blocks since the coinbase while you only see 99 blocks is appropriate until the next block is obtained. Punishing them only makes sense if they are on a blockchain fork of more than 99 blocks.The context also discusses a transaction with a "non-standard" signature operation count that is allowed in blocks but not accepted by the mainline rules. This restriction is in place to prevent denial-of-service attacks, as checking ECDSA signatures is a CPU bottleneck. If the SigOp count exceeds a certain threshold or the size of the transaction is below a certain limit, a DoS command can remove either the sender or receiver from the network. An attacker could exploit this to get nodes to ban each other. If someone spends a transaction after it has matured beyond 100 confirmations while you only see 99, it indicates a blockchain fork of more than 99 blocks and could lead to further damage, triggering the DoS command.In an email exchange between Gavin Andresen and Luke-Jr, they discussed the DoS rules in bitcoin. Luke-Jr argued against DoS-ing transactions with out-of-bounds SigOpCount and spending coinbase at depth, stating that it could deny service to legitimate nodes. However, Gavin disagreed, explaining that denying service to nodes running old versions of Bitcoin might be necessary during a scheduled change to acceptable block rules. He also mentioned that the third DoS rule in AcceptBlock() is a "should be impossible" case. The first transaction mentioned was a non-standard sig op count, allowed in blocks but not accepted by mainline rules, while the second transaction was not tied to a specific block. An attacker could potentially exploit these transactions to get nodes to ban each other.Overall, the context highlights the importance of carefully implementing DoS commands in order to avoid unintended consequences for legitimate transactions and blocks. While DoS protection is necessary to maintain the integrity of the blockchain, it must be done thoughtfully and with consideration for the potential impact on the network.
Updated on: 2023-08-01T02:30:16.058422+00:00