Spent transactions can be forgotten (though they currently aren’t). That would prevent your sending coins back and forth from having a big impact on block size.

The transaction inclusion issue is fixed by increasing fees and making non-generators aware of the current blocksize. The fees after 250KB should increase faster.

I think this attack would be more difficult on the real network because of the differing fee schedules. You’ll have half of the network including your transactions and half of the network not including them. Half of the network considers a block “filled” at 500KB, and half at the network-enforced maximum of 1MB.

Quote

Or maybe the entire size exceeded the 1 MB limit.

You’re right. That message is produced if fees bring a transaction over your balance, and the fee when the blocksize is over 500 KB is 21 million BTC. You wouldn’t have gotten that if you weren’t generating, since you wouldn’t have known the current blocksize.

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.

8,891 total views, 4 views today