- Able to set a hard limit on the amount of confirmations needed (Unsafe but consistent.)
- Able to set a limit above or below the recommended amount of confirmations needed by a certain amount.
- Able to set a minimum confirmations needed, but also follow recommended amount.
- Adjust the amount of confirmations on the client for a transaction to be considered safe.
I'm not sure if most of this should be implemented through an API or not, but I think suggesting a recommended confirmation amount can be useful in the event of an attack, to avoid double spending.
As for detecting a possible attack, I'm not very sure. Perhaps monitor the hash rate for abnormal rises. Or use the same detection as Gavin suggested:
'Something like "ignore a longer chain orphaning the current best chain if the sum(priorities of transactions included in new chain) is much less than sum(priorities of transactions in the part of the current best chain that would be orphaned)" would mean a 51% attacker would have to have both lots of hashing power AND lots of old, high-priority bitcoins to keep up a transaction-denial-of-service attack. And they'd pretty quickly run out of old, high-priority bitcoins and would be forced to either include other people's transactions or have their chain rejected.'
