State of the debate: does the layered model deliver what the base layer gave up?

Bitcoin's base layer broadcasts every transaction to every participant. That is what makes it verifiable without trusted parties, and it is also why it cannot be a high-volume payments network: everyone processes everything. The layered answer is to settle rarely on-chain and transact often off it — payment channels anchored by on-chain funding transactions, with proof-of-work serving as the dispute-resolution backstop rather than the payment rail.

This was not a neutral engineering choice. It was the resolution of the scaling war: the small-block position held that a fast, cheap payments network had no durable competitive advantage — incumbent card networks could always lower fees and speed up — while an unblockable new form of money was something the financial establishment could not compete with. Layer two was how you got both. That argument won. The open question, roughly a decade on, is whether the second layer has delivered the properties the first layer surrendered — and the corpus can now state both sides, because its two sources reach opposite practical conclusions.

Live questions

• Is a channel network's capacity genuinely unbounded, or does liquidity simply relocate the ceiling from block space to channel balances? (lightning-removes-the-practical-capacity-ceiling.)
• Does onion routing deliver real payment privacy, given that channel opens and closes are on-chain by construction and the sender knows the whole path? (lightning-materially-improves-payment-privacy.)
• If safety requires being online to punish a cheating counterparty, and services exist to watch on your behalf, has trust been removed or relocated? (lightning-preserves-trustless-operation.)
• What does the 2015 on-chain merchant wave — Expedia, Overstock, Dell, Microsoft, most of whom later stopped — actually establish about adoption, given that both the acceptance and the withdrawal are cited as evidence by opposite camps?
• Which trust model is a given "layer" actually offering: a channel network where you hold your own keys, or a federated sidechain where you do not? (sidechains-vs-lightning.)

Main positions (strongest forms)

1. The layered model is the design, working as intended. Base-layer scarcity and verifiability are the properties worth protecting at any cost, because they are the ones nothing else can provide. Everything else — throughput, latency, granularity — can be built above without touching them. Channels settle in milliseconds at sub-dust granularity with no block-space bound, and the cryptography makes cheating unprofitable rather than merely discouraged. Judging this by adoption curves mistakes a decade for the relevant timescale on a monetary network.
2. Layer two under-delivered on exactly the promises that mattered. The critiques raised at the time have not been retired: channels need liquidity, the receiver must be online, funds locked in a channel carry credit risk, and users must actively prevent theft from their own channels. The answer offered then was that third-party services would hide this from users — which concedes that usability requires a new intermediary. On the adoption record, more major merchants accepted on-chain bitcoin in 2015 than have meaningfully adopted lightning since.
3. "Layer two" is a category, not a guarantee, and the category conceals its own trust models. Channels and federated sidechains are both called layers, but one has you holding keys to your funds and the other has a federation holding them. Grouping them flatters the weaker case. The useful question is never "is it layer two" but "who can take my money, and under what conditions."

Related corpus entries

lightning-network-basics and lightning-mainnet-launch establish the mechanism and its timeline; sidechains-vs-lightning is the trust-model distinction position 3 rests on; ordinals-inscriptions and nostr-not-a-blockchain sit under the same layers tag but address what else gets built adjacent to the chain rather than payments. The three live claims are lightning-materially-improves-payment-privacy, lightning-removes-the-practical-capacity-ceiling and lightning-preserves-trustless-operation — all CONTESTED, and all resting on owner-research rather than primary sources. Reference points: bip-0112 (CSV, the relative timelock the punishment mechanism depends on), bip-0065 (CLTV, the HTLC refund path), bip-0141 (SegWit — malleability had to be fixed before channels were practical at all), and bip-0021/bip-0321 for payment-URI handling. Adjacent debates: long-term-security-budget (channel closes compete for the same block space that fee pressure prices) and op-return-and-arbitrary-data (the other contest over what base-layer capacity is for).

Open questions a debate could resolve

• Whether "lightning adoption" should be measured in nodes, channels, capacity, routed volume, or merchants — the camps have never agreed on the denominator, which is why both can cite the record.
• Whether delegated channel-watching is concentrated enough in practice to constitute a centralization risk, or is a commodity service with many providers.
• Whether the receiver-must-be-online constraint is a permanent property of the design or an artifact of an early era, and what evidence would settle that either way.
• Whether calling federated sidechains and channel networks both "layer two" helps anyone reason, or whether the corpus should retire the umbrella term in favour of naming the trust model directly.