Network Upgrades and Forks

Covers durable protocol-level changes that alter channel construction, commitment-transaction formats, anchor outputs, splicing, and the integration of Bitcoin base-layer upgrades such as Taproot, MuSig2, and PTLCs. Node operators, liquidity providers, and exchange teams rely on this group to plan upgrade sequencing, assess backward-compatibility risks, and understand how new script primitives affect channel security and privacy.

Anchor Outputs Upgrade

Technical impact page on the transition to anchor outputs in Lightning commitment transactions. Covers the shift to zero-fee HTLC transactions, new fee-bumping strategies using CPFP, mempool-pinning mitigation, and wallet implementation requirements. Node operators and exchange teams need to assess fee management changes and force-close security improvements.

Taproot Channel Adoption

Adoption-tracking page on integrating Bitcoin's Taproot soft fork into Lightning channels. Details the move to P2TR funding outputs, Schnorr-based cooperative closes, and the phased rollout across LND, Core Lightning, Eclair, and LDK. Liquidity providers and wallet teams must plan for privacy gains and reduced on-chain footprint.

MuSig2 Protocol Integration

Protocol upgrade page on replacing legacy OP_CHECKMULTISIG channel setups with MuSig2. Explains how cooperative closures become indistinguishable from singlesig spends, improving on-chain privacy and reducing fees. Node operators and exchange teams should evaluate implementation maturity and cross-compatibility before adoption.

PTLCs (Point Time Locked Contracts)

Forward-looking impact page on the shift from HTLCs to PTLCs using adaptor signatures and Schnorr. Covers stuckless payments, broken payment correlation heuristics, and routing privacy gains. Protocol architects and risk teams need to understand the trust-model changes and implementation sequencing with other Taproot upgrades.

Simple Taproot Channels

Technical specification page on channels using a single Taproot output for both cooperative and unilateral closes. Contrasts the new key-path spend and script-path fallback with the legacy funding_redeemscript model. Node operators and wallet developers need to plan migration paths and assess dispute-resolution changes.

Splicing (Dynamic Channel Resizing)

Operational upgrade page on splicing, enabling adding or removing funds from active channels without closing. Covers splice_init and splice_ack messages, on-chain fee interaction, and liquidity-management benefits. LSPs and routing node operators should assess capital-efficiency gains and implementation readiness.

Dual-Funding Channels

Protocol upgrade page on interactive dual-funded channel opening, where both peers contribute to initial balance. Details the RBF-enabled funding transaction flow and implications for inbound liquidity acquisition. Wallet teams and LSPs need to evaluate onboarding UX improvements and fee-management strategies.

Zero-Confirmation Channels

Risk-analysis page on channels usable before the funding transaction confirms. Covers trust assumptions, transaction-replacement risks, and the path toward trustless zero-conf. Exchange teams and wallet developers must assess the security trade-offs for instant onboarding versus double-spend exposure.

Channel Commitment Format Evolution

Comparative reference page tracking Lightning commitment transaction formats from the original design through option_static_remotekey, anchor outputs, and Taproot-based formats. Node operators and security auditors need to understand the security and complexity trade-offs when managing channels across different protocol eras.

Feature Bit Activation and Lifecycle

Operational guide on how protocol features are signaled and negotiated using feature bits in init and node_announcement messages. Covers optional versus required bits, upgrade gating, and compatibility analysis. Node operators and integration teams need to interpret feature bit vectors to avoid forced closures and connectivity loss.

TLV (Type-Length-Value) Extension Fields

Protocol-extension page on the TLV upgrade for core messages like update_add_htlc and open_channel. Explains how forward-compatible extension fields enable new features such as PTLCs and large HTLCs without breaking message structure. Implementation teams need to ensure their parsers handle unknown TLV fields correctly.

Gossip Protocol v2.0

Network-upgrade page on the transition to a more scalable and private gossip protocol. Details changes to channel_announcement and channel_update messages, rate-limiting improvements, and routing-table accuracy impacts. Routing node operators need to plan for gossip data management and pathfinding performance changes.

Route Blinding

Privacy-upgrade page on the route blinding protocol, allowing recipients to hide their node ID and final path segment. Explains blinded paths, ephemeral keys, and privacy gains for payment recipients. Wallet teams and payment processors should assess integration requirements for enhanced recipient privacy.

Onion Messaging

Protocol-upgrade page on asynchronous, payment-independent messaging between nodes using blinded paths. Covers the message format and how it underpins BOLT 12 offers and offline receiving. Wallet developers and LSPs need to evaluate how onion messaging changes their notification and invoice-delivery architecture.

BOLT 12 Offers Protocol

Standard-adoption page on BOLT 12 Offers replacing static BOLT 11 invoices with a dynamic invoice-request flow over onion messages. Details privacy improvements and the elimination of web-server dependencies for invoice handling. Exchange and payment-processor teams need to plan their invoice-infrastructure migration.

Backward-Compatibility Risk Assessment for Upgrades

Risk-framework page for node operators and liquidity providers evaluating protocol upgrade adoption. Covers impact on stale channels, interactions with older peers, and accidental force-closure potential during transition periods. Infrastructure teams should use this framework before activating new feature bits or commitment formats.

Upgrade Sequencing for Liquidity Providers

Operational-planning page for routing node operators and LSPs on sequencing complex multi-step upgrades such as Taproot plus MuSig2 plus PTLCs. Focuses on capital efficiency, minimizing downtime, and managing channels during commitment-format transitions. Large node operators need a phased rollout strategy to avoid liquidity disruption.

Cross-Implementation Compatibility Matrix

Reference page tracking real-world interoperability of protocol features across LND, Core Lightning, Eclair, and LDK. Documents supported feature bits by implementation version and known incompatibilities. Integration teams and wallet developers need this to set minimum version requirements and avoid interop failures.

Network Upgrades and Forks - Lightning Network | ChainScore Protocols