cjp, thanks, this is exactly the kind of discussion I was hoping for.
Obviously I'd considered rollback, but not deeply enough. I also didn't think to include rollback mechanisms in the draft I wrote, despite having thought about them. And you're right: in a scenario where a payment gets stuck, not only does a micropayment channel get locked until nLockTime expires but the entire chain of micropayment channels involved in the payment gets locked.
Since we now have reversible micropayment channels, we can roll back fairly simply: in reverse order to the payment flow (from the payee node all the way back to the payer node), each micropayment channel is reversed for one payment back to the sender.
For example, Alice wants to pay Bob. Alice has a micropayment channel to Carol and Carol has one to Bob. Bob generates a random number, hashes it to get the payment's commitment hash and gives the commitment hash to Alice. Alice signs a new transaction version, with nLockTime 50 weeks in the future, to Carol. Carol signs a new transaction version, with nLockTime 50 weeks in the future, to Bob.
For whatever reason, Bob changes his mind and says "Alice, I'd rather get paid in silver dime cards, so I'm going to roll back this transaction instead of fully committing it." Bob reverses his micropayment channel to Carol by signing and sending her a new version of T2 in which the amounts allocated to Carol and Bob are the same as they were prior to the transaction Bob is rolling back; however, the nLockTime is set to 49 weeks in the future. Carol then does the same to Alice, and the transaction is considered rolled back. Even if Bob at some point publishes the preimage, nothing bad can happen as the new version of T2 for each micropayment channel can be committed to the block chain a week before the version of T2 that has the preimage.
I believe this mechanism would stop Mallory from being able to take someone else's money in a scenario like yours, where she generates the preimage and tries to trick intermediaries into halfway rolling back a payment flow in order to extract money from one of them. Since Mallory would initiate the payment, if one of Mallory's nodes refuses to roll back to an earlier node in the path hoping to profit from a half-rolled-back transaction, the initial micropayment channel through which she initiated the payment would also not be rolled back and she'd be paying herself when she eventually published the preimage.
If Mallory is just after DoS and wants to lock micropayment channels, she would need only a node that participates in a payment flow. If Alice tries to pay Bob through Carol, which is really Mallory, and Mallory doesn't forward the payment to Bob, then Mallory has locked the micropayment channel between her and Alice. Mallory can't redeem the money, nor her risk deposit, without the preimage of the payment's commitment hash. She can either publish the transaction after nLockTime expires and lock Alice's - but also her own - money permanently, or she can wait until Alice publishes the initial version of T2 and lose whatever money was previously spent through the micropayment channel that should be hers. The solution is to have risk deposits on both sides of the micropayment channel to provide disincentive to locking money permanently, and never spend so much in one direction on a micropayment channel that it reduces the other peer's risk deposit. This way, it's expensive to perform DoS. Beyond the risk deposit loss, Mallory would have to spend enough time and money on establishing connections that would put her in the middle of payment flows to even make a DoS possible, and then she would have to sacrifice her risk deposits to actually perform it.
One more possibility is to make each output of T2 redeemable EITHER with the recipient's key AND the preimage of the payment commitment hash, OR with BOTH of the keys for the micropayment channel. This would make it possible to unlock money that would otherwise have been permanently locked, but may open the concept to ransom-driven DoS. I'm not sure it's a great solution, but it could be useful depending on the desired trade-offs. In either case, there's nothing wrong with implementing it as an option and letting individual nodes decide whether they want to use it or not. In such a case, it'd be possible to tell whether an output was redeemed with both keys or with a key and a hash preimage, so that data could be used for reputation purposes. Note that rollback versions of T2 transactions wouldn't need payment commitment hashes in them as the rollback doesn't need to happen atomically, so we can tell post-rollback versions of T2 from post-payment versions of T2 in the block chain and use that for reputation as well.
One more thought: if this concept stands up to further analysis, it'd be best to implement it for a distributed instant micropayment solution first. This way, each micropayment channel could be about 1 BTC in size, which could handle hundreds of nickel-sized (in USD terms) transactions before having to switch directions, and thousands before having to roll over on the blockchain. Instead of using bigger channels between peers, we should use more channels between more peers so that we can route around DoS attempts and other bottlenecks. As the value of a BTC grows and the block size's upward pressure on transaction fees increases, the network could evolve from a micropayment network to a retail payment network without having to increase the channel size.
jgarzik, I won't have any time to code one until at least June. If no one else does it before I do, I will do my best this summer to come up with something.
Obviously I'd considered rollback, but not deeply enough. I also didn't think to include rollback mechanisms in the draft I wrote, despite having thought about them. And you're right: in a scenario where a payment gets stuck, not only does a micropayment channel get locked until nLockTime expires but the entire chain of micropayment channels involved in the payment gets locked.
Since we now have reversible micropayment channels, we can roll back fairly simply: in reverse order to the payment flow (from the payee node all the way back to the payer node), each micropayment channel is reversed for one payment back to the sender.
For example, Alice wants to pay Bob. Alice has a micropayment channel to Carol and Carol has one to Bob. Bob generates a random number, hashes it to get the payment's commitment hash and gives the commitment hash to Alice. Alice signs a new transaction version, with nLockTime 50 weeks in the future, to Carol. Carol signs a new transaction version, with nLockTime 50 weeks in the future, to Bob.
For whatever reason, Bob changes his mind and says "Alice, I'd rather get paid in silver dime cards, so I'm going to roll back this transaction instead of fully committing it." Bob reverses his micropayment channel to Carol by signing and sending her a new version of T2 in which the amounts allocated to Carol and Bob are the same as they were prior to the transaction Bob is rolling back; however, the nLockTime is set to 49 weeks in the future. Carol then does the same to Alice, and the transaction is considered rolled back. Even if Bob at some point publishes the preimage, nothing bad can happen as the new version of T2 for each micropayment channel can be committed to the block chain a week before the version of T2 that has the preimage.
I believe this mechanism would stop Mallory from being able to take someone else's money in a scenario like yours, where she generates the preimage and tries to trick intermediaries into halfway rolling back a payment flow in order to extract money from one of them. Since Mallory would initiate the payment, if one of Mallory's nodes refuses to roll back to an earlier node in the path hoping to profit from a half-rolled-back transaction, the initial micropayment channel through which she initiated the payment would also not be rolled back and she'd be paying herself when she eventually published the preimage.
If Mallory is just after DoS and wants to lock micropayment channels, she would need only a node that participates in a payment flow. If Alice tries to pay Bob through Carol, which is really Mallory, and Mallory doesn't forward the payment to Bob, then Mallory has locked the micropayment channel between her and Alice. Mallory can't redeem the money, nor her risk deposit, without the preimage of the payment's commitment hash. She can either publish the transaction after nLockTime expires and lock Alice's - but also her own - money permanently, or she can wait until Alice publishes the initial version of T2 and lose whatever money was previously spent through the micropayment channel that should be hers. The solution is to have risk deposits on both sides of the micropayment channel to provide disincentive to locking money permanently, and never spend so much in one direction on a micropayment channel that it reduces the other peer's risk deposit. This way, it's expensive to perform DoS. Beyond the risk deposit loss, Mallory would have to spend enough time and money on establishing connections that would put her in the middle of payment flows to even make a DoS possible, and then she would have to sacrifice her risk deposits to actually perform it.
One more possibility is to make each output of T2 redeemable EITHER with the recipient's key AND the preimage of the payment commitment hash, OR with BOTH of the keys for the micropayment channel. This would make it possible to unlock money that would otherwise have been permanently locked, but may open the concept to ransom-driven DoS. I'm not sure it's a great solution, but it could be useful depending on the desired trade-offs. In either case, there's nothing wrong with implementing it as an option and letting individual nodes decide whether they want to use it or not. In such a case, it'd be possible to tell whether an output was redeemed with both keys or with a key and a hash preimage, so that data could be used for reputation purposes. Note that rollback versions of T2 transactions wouldn't need payment commitment hashes in them as the rollback doesn't need to happen atomically, so we can tell post-rollback versions of T2 from post-payment versions of T2 in the block chain and use that for reputation as well.
One more thought: if this concept stands up to further analysis, it'd be best to implement it for a distributed instant micropayment solution first. This way, each micropayment channel could be about 1 BTC in size, which could handle hundreds of nickel-sized (in USD terms) transactions before having to switch directions, and thousands before having to roll over on the blockchain. Instead of using bigger channels between peers, we should use more channels between more peers so that we can route around DoS attempts and other bottlenecks. As the value of a BTC grows and the block size's upward pressure on transaction fees increases, the network could evolve from a micropayment network to a retail payment network without having to increase the channel size.
Good stuff. Let's see a demo 
jgarzik, I won't have any time to code one until at least June. If no one else does it before I do, I will do my best this summer to come up with something.