Thank you for limiting flood tests to the testnet.
Version 0.3.15 combines several features to help legitimate transactions jump the queue during a flood attack. The key was Gavin's idea for prioritising transactions based on the age of their dependencies. Every coin is entitled to turn over so often. The longer waited, the more priority accumulates. Priority is sum(valuein * age) / txsize. Transaction fee still takes precedence over priority, and priority determines the order of processing within a fee strata.
In support of the priority feature, SelectCoins only uses your own 0 conf transactions only as a last resort if that's all you have left. This helps keep you from turning your coins over rapidly unless you're forcing it by actually turning all your coins over rapidly.
Re: Some testing that I did on the testnetwork, my findings.
Of course, if the network is not being flooded and you're not overly concerned about the current transaction getting held up then it's probably worth preferring to use your 0 conf transactions so that you can "save" the higher priority coins for when the network is being flooded.
You should use at least some priority in case a flood comes along before the next block.As long as all dependencies have at least 1 conf, if the transaction doesn't have enough priority at first, the dependencies will age until it does.
Quote
Gaming the system by including 1000 or so recently turned over BTC to bump the priority as described in my post above still works of course!
Or managing how much priority you spend on a transaction. The software would have to know your future plans to know whether to spend your priority now or save it for later. I don't think we'll need to get into that much detail though. There's a wide enough difference between normal users and flooders.Priority doesn't have to do everything. Once you know there's a flood, you can add -paytxfee=0.01. Hopefully with priority, your transactions before that should be at worst slow, not stuck.