Lightning preserves trustless operation

Lightning delivers its capacity, speed and privacy gains without introducing trust in intermediaries: routing nodes cannot steal a payment in transit, and a channel counterparty cannot profit by cheating.

For (strongest version as argued): The construction is designed so that dishonesty is unprofitable rather than merely discouraged. A transaction cannot be cancelled, so commitment transactions are built to make using a stale one undesirable: each party holds a revocation key that punishes the other for broadcasting a revoked state, and before signing a new commitment each party revokes the previous one. Routing is secured by hash time-locked contracts — an intermediary who forwards a payment knows that if the next hop claims its HTLC it must reveal the preimage, which the intermediary can then use to claim the incoming HTLC inside its own longer timeout window. If the secret is never revealed, the payer recovers the funds by absolute timelock. At no point does an intermediary hold funds it can abscond with, and either party can close a channel unilaterally by submitting the last commitment transaction to the blockchain.

Against (strongest version as argued): The guarantees hold only for a participant who is watching. Punishment for a revoked broadcast is not automatic — it must be exercised, within the timelock window, by someone online to notice; the same relative timelock (the notes' example is 1,000 blocks) that makes the scheme work also defines a window in which an inattentive party can be robbed. Unilateral close is likewise a right that must be exercised, and exercising it means landing an on-chain transaction, which is not guaranteed to confirm promptly under fee pressure — precisely when a cheating counterparty would choose to try. So the honest statement is that trust in the intermediary is replaced by a liveness and fee-market requirement on the user.

This is not a hypothetical objection, and it was conceded at the time. A second, independent account (The Blocksize War) records the contemporaneous critique — credit risk on funds locked in channels, liquidity requirements, the receiver having to be online and interact with the sender, and users having to prevent theft from their own channels — and records the small-block camp's answer: that in the long term these burdens "would eventually be hidden away from the user by third-party services." That answer concedes the structure of the objection. A design whose usability depends on third-party services absorbing the vigilance requirement has relocated the trusted role rather than removed it, however sound the cryptography underneath. The large-block critique in the same source goes further, calling such designs technically elegant but impractical.

Nuance: "Trustless" is doing two jobs. Against routing intermediaries, the HTLC argument is strong and largely structural — an intermediary genuinely cannot take the money. Against a channel counterparty, safety is conditional on monitoring, and the cost of that monitoring is where centralization pressure would appear if it appears at all. A speaker who proves the first has not proved the second. Note that the second source's concession is about usability, not about cryptographic soundness: "hidden away by third-party services" is compatible with the punishment mechanism working exactly as designed. The open question is whether a service that watches on your behalf is a convenience or a new dependency, and neither source settles it.

Sourcing: two independent owner-research files by different authors — the mechanism from one, the contemporaneous critique and its answer from the other — which is why this sits at medium rather than low confidence. Neither is a primary source, so INGEST_PLAYBOOK.md caps the status at CONTESTED. Both describe an early protocol era and state no edition or date. Whether delegated watching is concentrated in practice today, and how often stale-state broadcasts are actually attempted, remain unaddressed by either.

Common misstatements: "Lightning is trustless, full stop" (the mechanism removes trust in intermediaries; it substitutes a liveness requirement on the participant). "A routing node can steal your payment" (the HTLC construction is specifically designed to prevent this, and this is the strongest part of the claim). "You can always just close the channel" (closing requires an on-chain transaction to confirm, which is a fee-market dependency, not a certainty).