I mean when one tries to cheat by broadcasting an outdated commitment transaction. As far as I've understood, the cheater needs both signatures to spend from the force-closed multi-sig address.
The sender needs both signatures to spend the output of the funding transaction. That output is spent by every commitment transaction or a transaction that is signed during cooperative close. Commitment transactions lock each output differently.
"to_local":
OP_IF
# Penalty transaction
OP_ELSE
`to_self_delay`
OP_CHECKSEQUENCEVERIFY
OP_DROP
OP_ENDIF
OP_CHECKSIG
If we assume that "to_local" output belongs to A, they can spend it once the CSV timelock expires using "local_delayedprivkey". B can spend this output at any time using their "revocationprivkey". There is no multisig here; just a bunch of conditions.
"to_remote" is usually a simple P2WPKH address.
Commitment transactions can also include HTLC outputs which we haven't talked about yet. They are used while the payment is being routed through a channel. They are also used for direct payments (to keep the protocol simple).
Offered HTLCs:
# To remote node with revocation key
OP_DUP OP_HASH160 OP_EQUAL
OP_IF
OP_CHECKSIG
OP_ELSE
OP_SWAP OP_SIZE 32 OP_EQUAL
OP_NOTIF
# To local node via HTLC-timeout transaction (timelocked).
OP_DROP 2 OP_SWAP 2 OP_CHECKMULTISIG
OP_ELSE
# To remote node with preimage.
OP_HASH160 OP_EQUALVERIFY
OP_CHECKSIG
OP_ENDIF
OP_ENDIF
In your case, A has this output in their first commitment transaction. This output can be spent using either the payment preimage + B's HTLC signature, or A's and B's HTLC signatures (HTLC-timeout transaction) which it timelocked.
Received HTLCs:
# To remote node with revocation key
OP_DUP OP_HASH160 OP_EQUAL
OP_IF
OP_CHECKSIG
OP_ELSE
OP_SWAP OP_SIZE 32 OP_EQUAL
OP_IF
# To local node via HTLC-success transaction.
OP_HASH160 OP_EQUALVERIFY
2 OP_SWAP 2 OP_CHECKMULTISIG
OP_ELSE
# To remote node after timeout.
OP_DROP OP_CHECKLOCKTIMEVERIFY OP_DROP
OP_CHECKSIG
OP_ENDIF
OP_ENDIF
In your case, B has this output in their first commitment transaction. It requires either payment preimage and A's and B's HTLC signatures (HTLC-success transaction), or A's HTLC signature once the CSV timelock expires.
A and B include signatures for HTLC-success/timeout transaction in a "commitment_signed" message ("num_htlcs*signature:htlc_signature" field). If you want to learn why these outputs must be spent using another pre-signed transactions, see
this answer.
2. Alice wants to send him 0.02 BTC, so she signs a transaction with two outputs: A) to_local (that can be spent by her after x blocks) and B) to_remote that can be spent by Bob instantly.
It's slightly more complicated than that. We have to assume that they have already signed a commitment transaction with HLTC outputs. Every Lightning transaction involves two commitment updates.
Here's an example that I wrote some time ago. I assume that (A)lice wanted to pay (E)ric through B, C, D.
Here's my current understanding of how the system works:
0) Lightning nodes constantly use the gossip protocol (bolt07) to forward/receive "node_announcement", "channel_announcement", "channel_update" messages and maintain a local view of the whole network.
1) Alice receives a payment invoice from Eric which includes information like: Eric node's public key, payment hash, amount, expiry (date) and cltv expiry.
2) Alice constructs a path to Eric using her local map of the network. She tries to find the cheapest and the shortest route. The longer the route, the higher the risk that funds will get stuck during routing.
2a) She prepares "onion_routing_packet" which includes encrypted routing information for each hop.
3) Alice sends "update_add_htlc" message to Bob, which includes the "onion_routing_packet" (which is the same for all peers), the amount, the payment hash and cltv expiry.
4) Alice and Bob sign a new commitment transaction with an HTLC output.
5) Bob sends "update_add_htlc" to Carol with the same "onion_routing_packet".
6) Carol and Diana, Diana and Eric do the same.
7) Eric sends "update_fullfil_htlc" message to Diana, which includes the payment secret.
8) Eric and Diana remove the HTLC output and update balances by signing a new commitment transaction.
9) Diana sends "update_fullfil_htlc" to Carol with the same payment secret and they update the commitment transaction.
10) Carol and Bob, Bob and Alice do the same.
Comments:
3) The amount Alice sends is actually bigger than the one in the invoice as she must account for the fees. Each hop forwards the HTLC with a smaller amount and keeps the difference. If some hop tries to claim higher fees than Alice expected, the next node in the route will fail the payment as the routing instructions say how much one's node is supposed to forward.
If Bob doesn't have enough coins to forward the payment on his side of the channel with Carol, he must send "update_fail_htlc" message and Alice needs to try sending the payment through another route.
All channels use the same payment hash. It is safe because HTLC outputs require both the payment secret and HTLC signatures, which can be produced only by channel partners, to be spent. See
this post for explanation.
In your case, A starts with "update_add_htlc" and then everything goes as you described. Afterwards, Bob sends "update_fullfil_hltc" and the commitment transaction is updated again in the same way.
