BOLT 2: Channel Establishment and Management

The shift from single-funder to dual-funded channels requires a complete re-architecture of the channel opening flow. Implementers must replace the legacy funding_created and funding_signed messages with the interactive tx_signatures mechanism. This change breaks compatibility with older nodes and demands new logic for input selection, PSBT exchange, and fee negotiation. Action: Audit your opening state machine to ensure it can handle multiple inputs from both parties and validate the new commitment transaction signatures correctly.

The funding transaction output script and the minimum_depth confirmation policy are defined here. Incorrect implementation of the funding_satoshis or push_msat fields can lead to loss of funds or stuck channels. For exchanges and LSPs, the requirement to broadcast the funding transaction and monitor for its confirmation is a critical operational control. Action: Verify that your funding logic strictly enforces the dust_limit_satoshis and that your wallet can handle the edge case where the funding transaction is double-spent before reaching minimum_depth.

BOLT 2 specifies the structure of the initial commitment transaction and the exchange of commitment_signed and revoke_and_ack messages. The revocation key derivation scheme is the core security mechanism against counterparty fraud. Any error in storing revocation secrets or validating commitment signatures can be exploited by a malicious peer to steal funds. Action: Ensure your state machine correctly handles the asynchronous nature of signature and revocation exchange, and that your database atomically persists the revocation secret before releasing the old state.

The shutdown and closing_signed message flow enables a mutual close that is cheaper and faster than a unilateral force-close. The negotiation of the closing transaction fee, as defined by the fee_range in closing_signed, requires careful handling to avoid deadlocks where neither party agrees on a fee rate. Action: Implement a robust fee negotiation loop that respects the fee_range and includes a timeout to fall back to a unilateral close if an agreement cannot be reached, preventing indefinite channel lock-up.

The error message and the rules for its use are defined in BOLT 2. Sending a generic error versus a detailed one has privacy implications. More critically, the specification mandates how a node must react upon detecting a revoked commitment transaction on-chain—the penalty mechanism. Action: Your watchtower or node must be able to construct and broadcast a justice transaction spending the revoked output using the penalty private key derived from the breach remedy, as detailed in BOLT 3 but triggered by the monitoring rules in BOLT 2.

BOLT 2 defines the feature bits for option_static_remotekey, option_anchor_outputs, and option_dual_fund. A node's ability to signal and interpret these bits correctly during open_channel and accept_channel determines its compatibility with the broader network. Misinterpreting a feature bit can lead to a failed channel opening or, worse, a channel that opens but cannot be operated securely. Action: Conduct a feature-bit compatibility audit across your node versions and integration partners to ensure a clean upgrade path for new channel types.

Use the canonical BOLT 2 text to verify channel-opening messages, funding negotiation, commitment exchange, channel state transitions, shutdown, and cooperative closing behavior. Review feature requirements, message ordering, failure handling, and rules for ignoring or rejecting unexpected messages. Teams implementing dual-funded or interactive construction flows should compare the current specification with their target clients rather than assuming universal support. Pin reviews to a specific repository commit because merged specification changes may not yet be available in production releases.

Track the full specification repository for changes that affect BOLT 2 indirectly, including feature-bit negotiation, commitment transaction formats, gossip behavior, and extension proposals. Examine commit history and pull requests when assessing whether a channel workflow is stable, experimental, or still under review. Integration teams should record the exact specification revision used by their test suite and map each required behavior to the supporting client release. A merged document is evidence of specification consensus, not proof that every Lightning implementation has deployed the behavior.

BOLT 2 messages operate within the connection lifecycle and compatibility framework defined by BOLT 1. Use this source to validate message type handling, unknown-message behavior, feature-bit negotiation, and protocol failure semantics before testing channel establishment. Wallets, LSPs, and exchanges should ensure that optional and required feature bits are interpreted consistently across peers. A channel-opening implementation can fail before funding begins if initialization or feature negotiation is incorrect, so include malformed, unsupported, and asymmetric feature combinations in interoperability tests.

Consult BOLT 3 when BOLT 2 processing creates, signs, or validates funding and commitment transactions. It defines security-critical transaction structures, key derivations, output handling, and commitment rules that channel-management code must enforce. Review BOLT 2 and BOLT 3 together when adding a channel type or changing funding workflows; accepting a valid message sequence does not guarantee that the resulting transaction is safe or interoperable. Test signature validation, dust treatment, fee calculation, revocation state, and force-close recovery against the exact channel features being negotiated.

Search the BOLTs issue tracker for unresolved interoperability questions, ambiguous wording, security considerations, and implementation feedback related to channel establishment, interactive transaction construction, and closing. Before shipping a new workflow, determine whether behavior absent from the normative text is merely an implementation convention or the subject of active standardization. Link relevant issues to internal architecture decisions and preserve the selected interpretation in tests. Teams should not treat an issue discussion as an adopted rule unless the corresponding specification change has been merged.

Use Core Lightning as one implementation reference when translating BOLT 2 requirements into deployed node behavior. Inspect source, release notes, configuration, and tests for channel-opening and interactive funding paths relevant to your integration. Compare results with other target implementations because client policy, RPC abstractions, experimental flags, and release timing can differ even when wire behavior follows the same BOLT. Operators should validate channel negotiation on regtest or signet, including disconnect recovery, rejected inputs, fee disagreements, funding confirmation delays, shutdown scripts, and cooperative-close fallback handling.