Thanks, k99 and Vitalik, that helps clear it up. I've put "On Transaction Fees, And The Fallacy of Market-Based Solutions" on my to-think-about-deeply list.
I'm curious about this, though:
Precisely; although with the proviso that the first 16 computational steps in contract execution are free, so if a contract is decently written you can't involuntarily send transactions to it to bankrupt it.
If my contract needs more than 16 computational steps to execute, then other people CAN send transactions to it to intentionally bankrupt it? That is what I was worrying about when I said "publish the attacker's transaction and take the fee but ignore any other effects of the transaction, but you'd have to be careful to design THAT mechanism so it couldn't be abused."
As Vitalik mentioned a 0 Ether tx could be sent to a contract to activate it and cause some cost for the contract if it runs more then 16 steps. If the contract balance is 0 it will stop there.
A flooding with 0 Ether tx is protected due the tx fee.
As far as I understand a contract gets feeded by the tx activating it. So if a contract has been run out of its own contract funds, only tx with sufficient tx value will cause the contract to run (> 16 steps).
For me it is not clear why a contract holds balance on its own and why the tx value is not enough to control the contract execution. If a contract is funded (contract balance >0) there is no incentive to send a tx with a value there (paying for the execution).