Am I wrong until here? I'm sure I've said something that's not true.
I explained an uncooperative channel close in
this post. I think that you should read it before reading my reply further.
Otherwise, Alice can take the 10 coins if she broadcasts the transaction, in which she spends her coins and reveals her revocation key, acquires 432 confirmations.
An uncooperative channel close always involves at least two transactions. The first one is the commitment transaction and the other one spends the RSMC output. There might be more transactions; two for each in-flight HTLC.
Things get a little bit complicated when we are talking about unsettled payments. Bob asks Alice to sign a commitment transaction with the following outputs:
- a standard output; 8 BTC to Alice's address
- HTLC; 2 BTC that can be spent on the following conditions: Bob can spend this output using the payment preimage and HTLC signatures (HTLC-success transaction); Otherwise Alice can spend this output using revocations keys or HTLC-timeout transaction.
Note that this is what Bob's commitment transaction looks like. Alice's transaction looks like this:
- RSMC; 8 BTC that can be spent on the following conditions: if X blocks are mined since this transaction has been confirmed, Alice can spend these coins; otherwise Bob can use his and Alice's revocation key to unlock this output.
- HTLC; 2 BTC that can be spent on the following conditions: Bob can spend this output using the payment preimage and HTLC signatures (HTLC-success transaction) or using the revocation keys; otherwise Alice can spend it through the HTLC-timeout transaction.
Note: The HTLC-timeout transaction contains an absolute timelock (cltv_expiry) to give the other party time to claim the funds with the payment sercet. The outputs of HTLC-success and HTLC-timeout transactions contain another locking script with the same relative timelock as the RSMC output (to_self_delay).
Once all of the in-flight payments are settled, the final commitment transactions look like this:
Bob's commitment transaction:
- a standard output; 8 BTC to Alice's address
- RSMC; 2 BTC that can be spent on the following conditions: if X blocks are mined since this transaction has been confirmed, Bob can spend these coins; otherwise Alice can use hers and Bob's revocation key to unlock this output.
Alice's commitment transaction:
- a standard output; 2 BTC to Bob's address
- RSMC; 8 BTC that can be spent on the following conditions: if X blocks are mined since this transaction has been confirmed, Alice can spend these coins; otherwise Bob can use his and Alice's revocation key to unlock this output.
If Bob wants to send 1 coin back, Alice needs to make sure he'll not publish the previous state. So, she tells him to provide her the new commitment transaction signed, so that she gives him the revocation key of the previous state. (The one that if Bob tried to cheat her, she could sign a transaction with and take her 2 coins back)
Alice constructs a new commitment transaction and asks Bob to sign it. Bob signs Alice's commitment transaction. Then, Bob creates his own version of the latest commitment transaction and asks Alice to sign it and revoke her previous commitment transaction. Once Alice signs Bob's transaction, he can safely hand her over his revocation key for the previous transaction.