Bitcoin ecosystem design — Lightning Network, sidechains, and L1 extensions

Introduction

This page is L2 #10 — Ecosystem design (Layer 2, sidechains) in the design-document series. It covers the ecosystem that has grown around Bitcoin’s base chain: payment-channel networks, federated sidechains, on-chain envelope structures, and collaborative mining architectures. These systems share a single dependency — the most-work chain maintained by Bitcoin’s consensus rules — but they differ fundamentally in where they execute, what trust model they assume, and how they settle back to L1.

A critical classification note. Ordinals and Inscriptions are sometimes grouped with “Layer 2” in popular discussion. They are not. They are L1 envelope structures — data embedded directly in on-chain witness space, validated by every full node (and retained by any node that has not pruned old block data), and subject to L1 consensus rules. This page maintains the distinction throughout. An Inscription occupies block weight in the same way a payment output does; a Lightning payment does not.

Where behavior differs between the Satoshi-era implementation (v0.1, January 2009) and modern Bitcoin Core (v27+ baseline), both are noted.

1. Ecosystem layer map

The diagram below classifies the major ecosystem components by their relationship to Bitcoin’s base chain. The vertical axis represents trust and settlement distance: systems higher in the stack settle less frequently on L1 and may introduce additional trust assumptions.

2. Lightning Network design

The Lightning Network is a routed payment-channel network. Two parties lock funds in a shared on-chain output and then exchange signed-but-unbroadcast transactions to update their balances without touching the blockchain. Payments route across multiple channels using hash-time-locked contracts (HTLCs), enabling any Lightning user to pay any other Lightning user without a direct channel between them.

Channel lifecycle

In protocol terms: funding is a 2-of-2 multisig transaction; every balance update exchanges a new commitment transaction and revokes the previous one; and the forced-close path only reaches dispute if the counterparty broadcasts a revoked (already-superseded) commitment state.

Multi-hop payment routing (HTLC)

When Alice pays Carol through an intermediary (Bob), the payment uses a chain of HTLCs that lock atomically: either every hop settles or none does.

In protocol terms: the invoice carries H = SHA-256(R), each HTLC script hashlocks its output to R with a decreasing timelock toward the payee (40 blocks for Alice-to-Bob, 20 for Bob-to-Carol) so the outer hop can never be a shorter fuse than the inner one. Revealing R (on-chain or off-chain, cooperatively) is the only way to claim a hop’s output on the success path; if R never surfaces, each hop instead falls back to its own HTLC-timeout refund once its timelock expires.

Lightning Network properties

L1 prerequisites

The Lightning Network could not operate on Satoshi’s v0.1 implementation. It depends on three post-launch additions to Bitcoin’s base chain:

CLTV was not devised specifically for Lightning — see Peter Todd’s BIP 65 proposal for the original specification of OP_CHECKLOCKTIMEVERIFY, later adopted as the timelock primitive non-interactive payment channels depend on.

Every channel open, cooperative close, and forced close is still an on-chain transaction competing for block space on the fee market described there — Lightning moves payment volume off-chain, not the settlement transactions that bookend a channel’s life.

3. Sidechains: Liquid and federated pegs

A sidechain is a separate blockchain that is pegged to Bitcoin: coins move from the main chain to the sidechain (peg-in) and back (peg-out) through a bridge mechanism. The sidechain can define its own block time, transaction format, and feature set while using BTC-denominated value.

Peg-in / peg-out flow (Liquid)

Sidechain comparison

Why not trustless two-way pegs? Bitcoin’s script system cannot verify another chain’s proof of work or state transitions. A fully trustless two-way peg would require a soft fork adding validation logic for the sidechain’s consensus rules — a proposal that has been discussed (Drivechain / BIP 300) but not activated. Existing sidechains therefore rely on federated multisig as the bridge, introducing a trust assumption absent from L1.

4. L1 extensions: Ordinals and Inscriptions

Ordinals and Inscriptions are not Layer 2. They operate entirely within Bitcoin’s L1 consensus rules, using existing witness space to embed arbitrary data into individual satoshis. Every full node processes and validates this data as part of the canonical block; a non-pruning node also stores it indefinitely.

How Inscriptions use witness space

In script terms: the envelope is an unexecuted OP_FALSE OP_IF … OP_ENDIF branch inside the Tapscript witness, so it never runs as code, but every byte of it is still part of the witness the node deserializes, validates, and counts toward block weight.

Ordinal theory: satoshi-level identity

The Ordinal protocol assigns a sequential number to every satoshi based on the order in which it was mined. This numbering is a convention layer — the Bitcoin protocol itself does not distinguish individual satoshis. Ordinal-aware software tracks satoshi movement through transactions using a first-in-first-out (FIFO) mapping of input satoshis to output satoshis.

Why Ordinals/Inscriptions are not L2

5. Mining pools

Solo mining has been impractical for individual participants since approximately 2011. Mining pools allow miners to combine hash rate, find blocks collectively, and split rewards proportionally. The pool is an infrastructure-layer participant — it does not change consensus rules, but it concentrates block-template construction authority in pool operators. This is the technical machinery behind the drift the design-vs-current-reality analysis tracks on its mining axis — “one-CPU-one-vote” concentrating into a handful of pools running the Stratum and payout protocols described below. The template itself — which transactions get included, and in what fee-rate order — is built from the same fee-market auction the monetary design page describes; pools change who assembles it, not the underlying rules.

Pool architecture

In practice, a share’s difficulty target is set far below the network’s real target — easy enough that miners submit many per minute, giving the coordinator a steady stream of proof to measure hash rate by, while the real block-solving target is only cleared rarely across the whole pool.

Pool protocols: Stratum v1 vs Stratum v2

Reward distribution methods

6. Ecosystem layer comparison

The table below provides a structural comparison across the four ecosystem categories covered in this page, evaluated against a consistent set of design properties.

7. Limits of this page

This page covers ecosystem-layer systems at the design level. The following topics are out of scope and addressed in their respective domain pages within the design-document series:

• Transaction structure and UTXO model — the L1 primitives that Lightning channels and sidechain pegs build upon. Covered in the transaction design page.
• Taproot and Tapscript mechanics — how witness programs and script-path spends work at the opcode level. Covered in the transaction design page.
• P2P gossip and block relay — how transactions and blocks propagate across the network before reaching miners or Lightning nodes. Covered in the P2P network design page.
• Proof-of-work and difficulty adjustment — the consensus mechanism that secures the base chain on which all ecosystem layers depend. Covered in the consensus design page.
• Fee market and block-template construction — the economic dynamics that determine transaction inclusion priority. Covered in the monetary design page.