BitcoinMachine
TERM_DEF // LIGHTNING_NETWORK / PTLC_POINT_TIME_LOCKED_CONTRACT
PTLC (POINT TIME
LOCKED CONTRACT)
PTLC (Point Time Locked Contract). HTLC's Schnorr/adaptor-signature successor; no on-chain payment hash, better privacy.

This page sits in the Lightning Network section — Off-chain payment channels and routed micropayments built on top of Bitcoin. Read on for what it is, why it exists, how it works under the hood, and what to watch out for.
PTLC (Point Time Locked Contract) — at a glance
LIGHTNING NETWORK
PTLC (Point Time Locked Contract) is part of the PTLC sub-area of the Lightning Network. Point-Time-Locked Contract — Schnorr-based replacement for HTLCs using elliptic-curve points instead of hashes. HTLC's Schnorr/adaptor-signature successor; no on-chain payment hash, better privacy.
Why it exists
DESIGN
Bitcoin's base layer settles a few hundred thousand transactions per day — far fewer than a global payment network would need. Lightning solves the scaling problem by keeping most payments off-chain in two-party channels secured by the base layer, with the ability to settle on-chain at any time. Payments inside the network are routed atomically via HTLCs (Hash-Time-Locked Contracts), so a sender pays a receiver many hops away without trusting any intermediate.
Mechanism
HOW IT WORKS
Two parties open a channel by locking BTC into a 2-of-2 multisig output on-chain. They then update the channel state off-chain by exchanging signed transactions — each new state revokes the previous one with a punishment mechanism. To pay someone far away, the sender constructs an HTLC payment that hops through several channels; each hop is cryptographically bound to the same preimage, so all hops succeed or none do.
1. Alice and Bob open a channel: 2-of-2 multisig funding tx on-chain, agreed initial state with their balances. 2. Alice pays Bob 100 sats → both sign a new state with the updated balances (state #2), revoking state #1. 3. Repeat: thousands of payments back and forth, all off-chain, instant, fees in millisats. 4. To pay Carol (no direct channel), Alice routes through Bob: HTLC #1 Alice→Bob, HTLC #2 Bob→Carol, both locked to the same preimage hash. 5. Carol reveals the preimage to claim from Bob → Bob uses it to claim from Alice. Atomic, trustless, all-or-nothing. 6. At any time either party can close the channel by broadcasting the latest signed state on-chain — the network settles to base-layer Bitcoin.
PTLC (Point Time Locked Contract) — PTLC
EXAMPLE
Hash → point: instead of preimage(H), reveal scalar s such that s·G = P Advantages: - probing-resistant (every hop sees a different point) - same atomicity guarantees - smaller on-chain footprint via Schnorr aggregation Status: drafted on top of Taproot; not yet widely deployed
OFF-CHAIN
Updates happen between two parties only. The base chain settles disputes if either party tries to cheat.
TRUST-MINIMISED
Each state revokes the previous one with a penalty mechanism; cheating loses you the entire channel balance.
INSTANT
~100–500 ms end-to-end, even across many hops. Compared to 10-minute on-chain confirmations, Lightning feels like a card payment.
PAY-TO-INVOICE
Senders pay BOLT-11 invoices: a destination, amount, preimage hash, and a route hint. The receiver can pre-commit to the payment.
Things that catch people out
PITFALLS
  • PTLCs require Taproot + Schnorr; full deployment depends on the Lightning ecosystem adopting Taproot channels.
  • Channels need liquidity/">inbound liquidity to receive payments. New nodes often struggle to receive until they swap or pay an LSP for capacity.
  • Force-closes spam the on-chain mempool with extra transactions and incur larger fees than cooperative closes.
  • Routing fails silently — many implementations retry with different paths, but a payment can simply not find a route at high volumes.

TERMINOLOGY
PTLC (Point Time Locked Contract)
HTLC's Schnorr/adaptor-signature successor; no on-chain payment hash, better privacy.
Lightning Network
A network of payment channels enabling instant, cheap Bitcoin payments off-chain.
Payment Channel
A 2-of-2 multisig output funded by both parties; balance is rewritten off-chain via signed commitment txs.
Channel Open Transaction
The transaction/">funding transaction creating the channel's on-chain anchor UTXO.
Channel Close Transaction
Any on-chain transaction spending the channel UTXO, ending the channel.
Cooperative Close
Both parties sign a fresh tx splitting the current balance; lowest-fee close path.
Force Close
One party broadcasts the latest commitment tx unilaterally; pays higher fees and triggers timelocks.
Commitment Transaction
A pre-signed off-chain tx representing the current channel balance; spendable but penalized if old.