The Lightning Network is a payment-channel network built around Bitcoin transactions. Its original paper describes how parties can update their allocation of funds without placing every payment on the base chain. Poon and Dryja’s paper.
The channel idea
A simplified channel starts with an on-chain funding transaction. Participants exchange signed commitments describing how the funds can be divided. A closing process settles the channel on-chain. Cooperative closing can be straightforward; disputed or unilateral closing can involve timelocks and additional transactions. The original design.
The shorthand “two transactions enable unlimited payments” leaves out those operational details.
Payments can travel through a route
A payer need not open a direct channel with every recipient. Linked channels can support routed payments, subject to available liquidity and protocol conditions. Routing is not the same as publishing every intermediate update to Bitcoin’s blockchain. Lightning’s BOLT specifications.
The trade-offs are practical
Payments can complete quickly, but a usable route is not guaranteed. Liquidity must be available in the appropriate direction. Channel management, routing fees, and on-chain fees for channel operations still matter. Protocol overview.
A non-custodial setup also needs a way to monitor relevant on-chain events and react within the protocol’s time limits. Different software and services handle that responsibility differently. Using a custodial wallet introduces trust in its operator; the existence of Lightning does not remove that custody distinction. Security model in the original paper.
Read proposals and specifications differently
The 2016 paper explains the design’s motivation. The BOLTs describe interoperability rules used by implementations and continue to evolve. For specific wallet behavior, check that implementation’s documentation rather than assuming every product works identically.