To avoid the problem of reverse-griefing, we introduce an extra round before intiating the locking phase along with an extra commitment.

gistfile2.txt

mitigate.pdf

Considering 2 deposits as 2 separate HTLC construct. Not sure whether they can be combined. I am still under doubt regarding this "If R broadcasts r, then C gets 1 msat and R gets 6 msat". Because if total deposit is 7 msat not sure if this can be redirected to two addresses.

Both cancellation round and payment round contract contain "x" and "H(x)". Will this create a problem? (With access to x, a party can now choose to encash any one of the available contracts) (Can't think of a practical attack, but need to think more about this)

Both cancellation round and payment round contract contain "x" and "H(x)". Will this create a problem? (With access to x, a party can now choose to encash any one of the available contracts) (Can't think of a practical attack, but need to think more about this)
Encash anyone as in either cancellation or payment?

Encash anyone as in either cancellation or payment?

Yes.

When a party goes-onchain, it will broadcast its output and all the unsolved HTLCs it has. So it is like if C and R has deposited each 50-50 msat as funding. Now C wants to transfer 1 msat to R. So first R locks 6 msat, the state of the channel is C: 50, R: 44 msat, HTLC: 6 msat. Next, when the payment round contract is established, the state of channel will be C: 49, R: 44 msat, HTLC: 6 msat, HTLC1: 1msat. So when R goes on-chain revealing x (vice versa for C): it can spend 44 msat, HTLC-output: 6msat and HTLC1-output: 1msat as well. Is this the case?

So it will be like for R commitment tx definition: Input : funding tx, output: output 0: 49 msat (to spend by C), output 1: 44 msat (to be spend by R after block relative time), output2: HTLC(the corresponding script with R), output 3-HTLC1(the corresponding script with R)