The protocol involves each side maintaining two sets of proposals, one for adding to their htlcs and another for removing from their htlcs. To add an HTLC, one sends a proposal, which can be declined or accepted. If accepted, it is added to the proposals. On the other hand, if one wants to close an HTLC, they send fulfill/timeout/fail, which cannot be declined, and add to their proposals.To simplify the protocol, one always tells the other side what the next revocation hash will be as part of finalizing a commit transaction. If there are no outstanding add requests, one can send commit messages, which include signature of current state, including proposals. If one receives commit_accept with signature and their old revocation preimage, it commits proposals and sends update_commit_complete with old revocation preimage. However, if it receives an update_commit message (conflict!), it commits proposals to the current state, re-sends update_commit with the current state plus proposals or commits proposals to the current state and sends update_commit_accept.Packets involved in the protocol include update_add_htlc, update_decline_htlc, update_accept_htlc, update_fulfill_htlc, update_timeout_htlc, update_fail_htlc, update_commit, update_commit_accept, and update_commit_complete. The author acknowledges that the protocol is complex and welcomes suggestions for improvement.