The Lightning channels recap
Key steps summary for opening and closing channels on the Lightning Network
In this article we are summarizing the procedure for opening and closing channels on the Lightning Network. Below how Alice and Bob (with their nodes) will start opening a channel and then closing it either cooperatively or forced.
Opening a Lightning Channel
Establishing a Connection and Initial Communication
Peer-to-Peer Connection: To initiate the channel opening process, two Lightning nodes first need to establish a direct connection over the internet, often via TCP/IP or the Tor network. This connection enables them to exchange messages and negotiate the terms of the channel.
Node Identification: Each Lightning node is uniquely identified by its node public key. This key serves as the node's identity within the network and is crucial for secure communication and authentication.
Negotiating Channel Parameters and Creating the Funding Transaction
open_channel Message: The node initiating the channel (Alice) sends an open_channel message to the other node (Bob). This message contains:
The desired channel capacity (funding_satoshis).
An optional initial payment to the other node (push_msat).
Parameters related to fees, timelocks, and other channel features.
accept_channel Message: If Bob agrees to the proposed terms, he responds with an accept_channel message, confirming the parameters and including his own node public key.
Funding Transaction Construction: Alice then constructs the funding transaction, which is a special Bitcoin transaction that will anchor the Lightning channel on the blockchain. This transaction sends the specified channel capacity to a 2-of-2 multisignature address generated from Alice and Bob's funding public keys.
funding_created Message: Alice sends the funding_created message to Bob, providing him with details of the funding transaction. This message includes the transaction ID (funding_txid) and the output index where the channel funds are located.
funding_signed Message: Bob verifies the funding transaction details and sends back the funding_signed message, which contains his signature for the transaction.
Broadcasting the Funding Transaction and Finalising the Channel
Blockchain Broadcast: Alice broadcasts the now fully signed funding transaction to the Bitcoin network. This transaction becomes publicly visible and serves as the foundation of the Lightning channel.
Confirmation Wait: Alice and Bob must wait for the funding transaction to be confirmed on the blockchain, typically requiring a certain number of confirmations. This process ensures the transaction is considered valid and secure.
funding_locked Messages: Once the funding transaction is confirmed, both Alice and Bob exchange funding_locked messages, signaling the channel is now officially open and ready for use.
Privacy Considerations
Public Funding Transaction: The funding transaction, while not immediately identifiable as a Lightning channel, is publicly visible on the Bitcoin blockchain. Anyone can see the amount of bitcoin sent to the multisig address, revealing the channel's capacity.
Unannounced Channels: To enhance privacy, channel partners can choose not to announce their channel to the broader network. Unannounced channels are not readily discoverable and cannot be used for routing payments by other nodes. However, their existence may still be inferable through blockchain analysis or routing hints in invoices.
Channel Closing: Even with unannounced channels, the final balance distribution becomes public when the channel is closed and the closing transaction is broadcast on the blockchain.
Structure of the Opening Transaction
The opening transaction, also known as the funding transaction, has the following key features:
2-of-2 Multisignature Output: The transaction output sends the channel funds to a multisig address that requires both Alice and Bob's signatures to spend. This ensures neither party can unilaterally control or steal the funds.
No Explicit Identification: The transaction itself does not explicitly reveal that it is a Lightning channel funding transaction. Unless specifically advertised through the gossip protocol, it appears as a regular Bitcoin multisig transaction.
Taproot Enhancements: Taproot upgrade to Bitcoin further enhances the privacy of Lightning channel transactions by making them indistinguishable from ordinary payments.
Cooperative Channel Closing on the Lightning Network
1. Initiating the Closure:
shutdown Message: One channel partner (e.g., Alice) initiates the closing process by sending a shutdown message to the other partner (Bob). This message includes:
channel_id: The unique identifier of the channel to be closed.
scriptpubkey: A Bitcoin script specifying the address where Alice wants to receive her funds. This could be any standard Bitcoin address format (P2PKH, P2WPKH, etc.).
Acknowledgement: Bob responds with his own shutdown message, indicating his agreement to close the channel and providing the scriptpubkey for his chosen receiving address.
2. Negotiating Closing Fees:
closing_signed Message (Alice): Alice, as the channel funder, initiates the fee negotiation by sending a closing_signed message to Bob. This message proposes a transaction fee for the on-chain closing transaction and includes Alice's signature for the transaction.
closing_signed Message (Bob): Bob can either:
Accept: If Bob agrees with the proposed fee, he responds with a closing_signed message echoing the same fee and his own signature for the transaction.
Propose a Different Fee: If Bob disagrees, he responds with a closing_signed message containing a different fee_satoshis value.
Fee Negotiation: This back-and-forth exchange of closing_signed messages continues until both parties agree on a suitable fee for the closing transaction.
3. Constructing and Broadcasting the Closing Transaction:
Final Agreement: Once Alice receives a closing_signed message from Bob with the same fee she proposed, the negotiation concludes.
Transaction Construction: Both nodes construct the final closing transaction, which is similar to a commitment transaction but without timelocks or penalty mechanisms. The outputs of this transaction directly pay Alice and Bob their respective balances at the specified addresses.
Transaction Broadcast: Alice, as the initiator, broadcasts the signed closing transaction to the Bitcoin network.
4. Channel Closure Confirmation:
Transaction Confirmation: The closing transaction is confirmed on the Bitcoin blockchain, effectively closing the channel.
Fund Availability: Alice and Bob can now spend their received funds as desired.
Key Points:
Cooperative Nature: Both channel partners actively participate in the closing process, agreeing on the final balance distribution and the transaction fee.
On-Chain Fees: Closing a channel incurs on-chain transaction fees, which are paid by the channel funder (Alice, in this example).
Efficiency: A cooperative close generally results in lower fees and faster fund availability compared to a unilateral force close.
Finality: The confirmed closing transaction provides a definitive record of the final channel balance on the Bitcoin blockchain.
Up-Front Shutdown Script (Optional): An optional feature where parties can pre-specify a "delivery address" for their funds during the channel opening. This enhances security by restricting the destination of funds upon closure, mitigating risks in case of a compromise.
Forced Channel Closure on the Lightning Network
The force close as a method of closing a Lightning Network channel without the consent or cooperation of the other channel partner. This scenario typically arises when one partner becomes unreachable or unresponsive, making a mutual close impossible. While effective in reclaiming funds, a force close comes with disadvantages, including higher fees and potential delays in accessing the funds.
1. Triggering a Force Close:
Unilateral Action: The party initiating the force close (e.g., Alice) acts independently, without requiring Bob's involvement.
Broadcasting the Commitment Transaction: Alice broadcasts the latest signed commitment transaction she possesses to the Bitcoin network. This commitment transaction, as discussed in the channel opening procedure, contains the latest agreed-upon channel balance.
2. Blockchain Confirmation and Timelock Enforcement:
Confirmation Wait: Alice waits for the commitment transaction to be confirmed on the Bitcoin blockchain.
Asymmetric Timelocks: The outputs in the commitment transaction are subject to asymmetric timelocks, meaning:
Initiator's Output (Alice): Alice's output is encumbered by a timelock (to_self_delay), requiring her to wait for a specified number of blocks before spending her funds. This delay is intended to provide Bob a window to contest the closure if Alice attempted to use an older, revoked commitment transaction.
Non-Initiator's Output (Bob): Bob's output is immediately spendable upon confirmation of the transaction.
3. Potential for Dispute and Penalty:
Monitoring for Fraud: Bob, even if offline initially, can monitor the blockchain for transactions spending from the channel's funding output.
Detecting an Old Commitment: If Bob discovers that Alice broadcast an older commitment transaction (reflecting a balance more favourable to her), he can use the revocation secret associated with that older commitment to claim all the funds in the channel. This mechanism acts as a penalty against dishonest attempts to force close with outdated information.
4. Higher Fees and Delays:
Overestimated Fees: Commitment transactions are designed with generous fee rates to accommodate potential future fee increases at the time of broadcast. This overestimation results in higher on-chain fees for the force closing party compared to a mutual close.
Timelock Delay: The timelock on Alice's output creates a delay in accessing her funds. This delay can range from a few hours to weeks, depending on the to_self_delay value negotiated during channel opening and the current state of the Bitcoin network.
Key Points:
Last Resort: A force close is generally considered a last resort due to its drawbacks.
Security Trade-Off: The timelock mechanism provides a layer of security by allowing the non-initiating party to respond to a potentially fraudulent force close.
Fund Reclamability: Even in the absence of the other party's cooperation, a force close ensures the initiating party can eventually reclaim their funds from the channel.
Communication is Preferred: If possible, attempting to contact the unresponsive channel partner to pursue a mutual close is always recommended before resorting to a force close.