I hate to get specific about potential attacks on a public mailing list, but I think the debate over what to do with non-standard transactions means we need to.
I agree with Gregory; if there are NO rules about what transactions peers can send at you, then an attacker can trivially get around other the DoS rules. I also agree we need to think hard about what will happen when new 'standard' transaction types are deployed. There are two significant DoS attacks I can imagine using transactions that will never be included in blocks. The "will never be included in blocks" bit is important, because if an attacker can make you do significant work at no cost to themselves then they win. And if the transactions will never be included in blocks the attacker can include lots of transaction fees that will never be spent. 1) Exhaust memory by filling up the transaction memory pool. I think another patch needs to be written to deal with that (keep the size of the transaction pool reasonable by evicting low-priority transactions). 2) Waste CPU time validating transactions They can make you use an arbitrary amount of CPU time just by flooding you with a stream of valid-but-won't-ever-get-into-a-block transactions. The code already refuses to relay non-standard transactions, and doesn't check their signatures or add them to the memory pool, so I think no DoS check is needed for them (and would be harmful when we do start supporting new standard transactions). It also drops transactions with "too few fees" before checking signatures or doing other CPU-intensive work, so no I think no DoS check is needed there, either (and again, would be harmful when transaction fee rules change). I'm ignoring bandwidth DoS attacks-- we already have the -maxreceivebuffer option to deal with those. PS: I'll add Gregory's comment: "There should be nothing I can give a node that it will forward on that will make that node's peers drop it. (and this needs to remain true while forwarding rules evolve)" ... as a comment in the code so hopefully we don't forget it. -- -- Gavin Andresen ------------------------------------------------------------------------------ Doing More with Less: The Next Generation Virtual Desktop What are the key obstacles that have prevented many mid-market businesses from deploying virtual desktops? How do next-generation virtual desktops provide companies an easier-to-deploy, easier-to-manage and more affordable virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/ _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
