Wow! I can't find an attack mode anymore! Thank you so much, Aakselrod! I'm so enthusiastic now; this might just work!! Some comments:
Is this a correct summary of your proposal?:
m is initially only known by final payee
hash(m) is sent together with promise
Promise = T2 update signed by payer; requires m for spending
Commit = publication of m
Abort = T2 update signed by payee
Every T2 update decreases nLockTime (unless it is not necessary, but generally it is)
Communication direction:
Promise: payer->payee ('against interest' direction)
Commit: final payee->all (broadcast)
Abort: payee->payer ('against interest' direction)
Channel status:
m unknown and no abort -> undecided (effectively ...? see below)
m known and no abort -> committed (promise T2 is more recent than old T2)
m unknown and abort -> aborted (abort T2 is more recent than promise T2 and old T2)
m known and abort -> aborted (abort T2 is more recent than promise T2 and old T2)
New idea 1: if a transaction stays undecided for too long, any node can put a bounty on publication of m, by making an (in-blockchain) Bitcoin transaction that can be spent with m; I think the scriptPubKey will be something like this:
SHA256 Hashm EQUALVERIFY
New idea 2: you don't have to put all bitcoins of a link at stake when performing a transaction. You can also make a "promise T2" with outputs like this:
1. 89.99 BTC to: PubkeyAlice CHECKSIGVERIFY
2. 00.01 BTC to: SHA256 Hashm EQUALVERIFY PubkeyCarol CHECKSIGVERIFY
3. 10.00 BTC to: PubkeyCarol CHECKSIGVERIFY
This can be generalized to allow multiple transactions happening simultaneously on the same channel, even in opposite directions.
Possible problem: What happens when nLockTime is reached on a channel that is in "undecided" state?
Scenario:
T2_old = (1BTC to payer, 0BTC to payee)
T2_promise = (0BTC to (payer,m), 1BTC to (payee,m), nLockTime = T2_old.nLockTime - 1 week)
m is not published
T2_promise.nLockTime is reached
payee broadcasts T2_promise
T2_promise is included into block chain
Result: link remains "undecided" forever, unless m is published
Disincentive: never let payee have 0BTC (so he would risk losing his own BTC by doing this)
Question to think about: What happens when nLockTime is different for different channels in a payment? What will be the incentive for different participants when it comes to commit/rollback/keep things undecided until nLockTime?