Builder's Guide
  • Welcome to the Builder's Guide to the LND Galaxy!
  • The Lightning Network
    • Overview
    • Payment Channels
      • Lifecycle of a Payment Channel
      • Watchtowers
      • Understanding Sweeping
      • Etymology
    • The Gossip Network
      • Identifying Good Peers on the Lightning Network
    • Pathfinding
      • Finding routes in the Lightning Network
      • Channel Fees
      • Multipath Payments (MPP)
    • Lightning Network Invoices
      • Understanding Lightning Invoices
    • Making Payments
      • The Payment Cycle
      • Timelocks
      • ⭐Hashed Timelock Contract (HTLC)
      • Payment Etymology
      • ⭐What Makes a Good Routing Node
      • Understanding Submarine Swaps
      • Instant Submarine Swaps
    • Liquidity
      • ⭐Understanding Liquidity
      • Managing Liquidity on the Lightning Network
      • Liquidity Management for Lightning Merchants
      • How to Get Inbound Capacity on the Lightning Network
      • Lightning Service Provider
    • L402: Lightning HTTP 402 Protocol
      • Macaroons
      • L402
      • 📋Protocol Specification
      • Implementations and Links
    • Taproot Assets
      • Taproot Assets Protocol
      • Taproot Assets on Lightning
      • Edge Nodes
      • Taproot Assets Trustless Swap
      • FAQ
      • Glossary
  • Lightning Network Tools
    • LND
      • 🛠️Get Started
      • lnd.conf
      • First Steps With LND
      • Wallet Management
      • Sending Payments
      • Atomic Multi-path Payments (AMP)
      • Receiving Payments
      • Unconfirmed Bitcoin Transactions
      • Channel Fees
      • Inbound Channel Fees
      • Macaroons
      • Configuring Watchtowers
      • Pathfinding
      • Blinded Paths
      • Key Import
      • Secure Your Lightning Network Node
      • Configuration of a Routing Node
      • Quick Tor Setup
      • Configuring Tor
      • Enable ‘Neutrino mode’ in Bitcoin Core
      • Send Messages With Keysend
      • Partially Signed Bitcoin Transactions
      • Bulk onchain actions with PSBTs
      • Sweeper
      • Debugging LND
      • Fuzzing LND
      • LND API documentation
      • Channel Acceptor
      • RPC Middleware Interceptor
      • HTLC Interceptor
      • NAT Traversal
      • Recovery: Planning for Failure
      • Migrating LND
      • Disaster recovery
      • Contribute to LND
    • Lightning Terminal
      • What is Lightning Terminal?
      • 🛠️Get litd
      • Run litd
      • Integrating litd
      • Demo: Litd Speed Run
      • Connect to Terminal
      • Recommended Channels
      • Rankings
      • Health Checks
      • Liquidity Report
      • Opening Lightning Network Channels
      • Managing Channel Liquidity
      • Autofees
      • AutoOpen
      • LND Accounts
      • Loop and Lightning Terminal
      • Loop Fees
      • Pool and Lightning Terminal
      • Command Line Interface
      • Troubleshooting
      • Lightning Node Connect: Under the hood
      • LNC Node Package
      • LITD API Documentation
      • Privacy and Security
      • Privacy Policy
      • Terms of Use
    • Loop
      • 🛠️Get Started
      • The Loop CLI
      • Autoloop
      • Static Loop In Addresses
      • Instant Loop Outs
      • Peer with Loop
      • Loop API Documentation
    • Pool
      • Overview
      • Quickstart
      • 🛠️Installation
      • First Steps
      • Accounts
      • Orders and Asks
      • Sidecar Channels
      • Zero-confirmation Channels
      • Channel Leases
      • Batch Execution
      • Account Recovery
      • Pool API Documentation
      • FAQs
    • Taproot Assets
      • Get Started
      • First Steps
      • Taproot Assets Channels
      • Asset Decimal Display
      • Become an Edge Node
      • RFQ
      • Collectibles
      • Universes
      • Asset Loop
      • Debugging Tapd
      • Multisignature
      • Minting Assets With an External Signer
      • Lightning Polar
      • Operational Safety Guidelines
      • Taproot Assets API Documentation
    • Aperture
      • ⚒️Get Aperture
      • LNC Backend
      • LNC Mailbox
      • Pricing
    • Faraday
      • 🛠️Get Started
      • The Faraday CLI
      • Faraday API Documentation
  • LAPPs
    • Guides
      • Use Polar to Build Your First LAPP
        • Setup: Local Cluster with Polar
        • Setup: Run the Completed App
        • Setup: Run the App Without LND
      • Add Features
        • Feature 1: Connect to LND
        • Feature 2: Display Node Alias and Balance
        • Feature 3: Sign and Verify Posts
        • Feature 4: Modify Upvote Action
      • Make Your own LNC-powered Application
    • Next Steps
  • Community Resources
    • Resource List
    • Lightning Bulb 💡
    • Glossary
    • FAQ
Powered by GitBook
On this page
  • Opening a channel
  • Sending funds through a payment channel
  • Closing a channel
  • Cooperatively
  • Non-cooperatively

Was this helpful?

  1. The Lightning Network
  2. Payment Channels

Lifecycle of a Payment Channel

PreviousPayment ChannelsNextWatchtowers

Last updated 2 years ago

Was this helpful?

At its core, a payment channel is a 2-of-2 multisignature contract between two parties holding bitcoin. While this bitcoin is held cooperatively by the two parties from the perspective of the Blockchain, each party owns a portion of it, and maintains a record of this ownership locally.

For example, a payment channel of over 1 million satoshis can represent 100,000 satoshis in the hands of Alice, and 900,000 satoshis in the hands of Bob. The two can cooperate to update their balances as frequently as they like, without the need for making an on-chain Bitcoin transaction or incurring costs beyond the electricity and bandwidth they consume.

To ensure that Alice and Bob do not have to trust each other, each payment channel is secured by a commitment transaction signed by both Alice and Bob that allows each of them to unilaterally exit the agreement at any time, spending their respective share of the funds back to their own wallet. Such an event is called a “force close.”

Opening a channel

To open a channel to Alice, her node needs to be reachable over the internet. Alice may also place restrictions on new channels, such as a minimum channel size or gating for specific peers.

For Bob to open such a channel, he also needs funds in the form of bitcoin on-chain, either in his Lightning node or another wallet he controls. Upon his command, his node will connect to Alice and offer a channel. Alice and Bob will combine their keys to generate a 2-of-2 multisignature contract, which will act as the channel’s address.

To ensure that at no point Bob finds his funds stuck in this contract, he creates his funding transaction, but does not broadcast it to the network. He creates an additional transaction, the commitment transaction, that spends his funds back to him, and asks Alice to co-sign it.

Now Bob may broadcast his first transaction and fund the payment channel, and keep the second refund transaction in memory. Alice cannot take his funds without his cooperation, and if she were to become unresponsive, he could then broadcast the commitment transaction. The payment channel is now open and available for use.

Sending funds through a payment channel

The latest commitment transaction always represents the channel balances between Alice and Bob. They can transfer this balance to each other by updating their commitment transaction. They can do this as frequently as needed in increments of one millisatoshi.

These updates can be made in both directions, and there is no upper limit to how many updates can be made inside a single payment channel. As these payments are not announced to the network and the funds never move on-chain, they are only known to each party.

At each payment, Alice and Bob invalidate each other’s previous commitment transaction, ensuring that only the most recent transaction can be used to recover their balance in the event of a non-cooperative channel closure.

Closing a channel

There are two ways of closing a channel: Cooperatively and non-cooperatively

Cooperatively

In a cooperative close, both Alice and Bob are online, agree on their balance and on the terms of a channel closure (e.g. fees) proposed by either party. They will both sign a new transaction that spends the funds back to their respective wallets immediately and no longer process transactions between them.

As soon as their closure transaction is confirmed on the blockchain, they can use it to open new channels, move the funds elsewhere or leave them in their wallet.

Cooperative channel closures are the norm in the Lightning Network.

Non-cooperatively

Either Alice or Bob may not be available, or may for other reasons be unable or unwilling to sign their closure transaction. In this case, the party aiming to close the channel will have to publish their commitment transaction. This will result in a non-cooperative close, also called a force close.

These commitment transactions are asymmetrical, as they spend the balance of the peer initiating the force close to an arbitration contract, while the funds of the other party are sent to their wallet immediately. This allows the peer that is not initiating the force closure to contest it.

In the event that one party were to attempt to “cheat” by publishing an older commitment transaction, their peer is able to use the previously exchanged revocation secret to claim the funds of the malicious actor, providing a valuable incentive to remain honest, securing the network overall.

Read more: Hash Time-lock Contracts (HTLC)