This format is particularly focused on the interaction between two parties, referred to as A and B.

The first diagram showcases a class structure for the FundingTx, CommitmentTxB, and HTLCClaimB, illustrating the conditional outputs based on public keys and various conditions such as revocation, delays, and hash locks. The CommitmentTxB has an anchor, which is essential for relaying the transaction. If it is version 3 (v3), its ephemeral nature requires the output to be spent concurrently with the transaction relay. Bob can initiate different transactions (Tx1 or Tx2) depending on whether he wants to confirm the funding of CommitmentTxB alone or also wishes to lock in some HTLCs.

Two additional diagrams are presented to depict Bob's potential transactions, TxB1 and TxB2. These transactions include the commitment and conditional HTLC outputs, with their outcomes contingent on time delays and revocation keys. Party A has the option to counteract Bob's transactions by either posting her own conflicting CommitmentTxA or creating spends from CommitmentTxB that conflict with Bob's TxB1 or TxB2.

Moreover, Party A can use her channel balance to pay on-chain fees, eliminating the need for confirmed funds outside the channel. This suggests a strategy where she leverages the channel balance to ensure earlier confirmation of transactions without requiring additional external funds.

The diagrams and text collaborate to form a comprehensive overview of the transaction mechanics, highlighting the flexibility and strategic options available to both parties within this proposed commitment transaction framework.