PTLCs: Point Time Locked Contracts and Lightning's Privacy Future

Every payment routed through the Lightning Network today shares a single secret across every hop in its path. That secret, a payment hash, is identical whether a routing node sits one hop from the sender or six hops away. Any node that participates in two legs of the same payment can recognize the repeated hash and conclude they are part of one transaction. This is the correlation problem, and it has been known since Lightning's earliest days.

Point Time Locked Contracts (PTLCs) replace the shared hash with a construction where every hop sees a different cryptographic point. No two nodes in the route observe the same value, eliminating the most direct form of payment correlation. PTLCs are not a speculative idea: they follow directly from Taproot and Schnorr signatures, both of which have been active on Bitcoin since November 2021.

How HTLCs Work and Where They Fall Short

A Hash Time Locked Contract (HTLC) is the mechanism that makes multi-hop Lightning payments atomic. The receiver generates a random 32-byte preimage, hashes it with SHA-256 to produce a payment hash, and embeds that hash in an invoice. When the sender initiates payment, every forwarding node along the route locks funds with the same hash. The receiver reveals the preimage to claim the final HTLC, and that preimage propagates backward through the route, unlocking each hop in sequence.

This design achieves atomicity: either every hop settles or none do. But the identical hash at every hop creates several weaknesses.

Payment correlation

If an adversary operates two nodes on the same payment route, both nodes see the same payment hash. The adversary can link sender and receiver even if onion routing hides the full path from any single node. Research from Kappos et al. (2020) and Romiti et al. (2020) demonstrated that even a modest number of adversarial nodes can deanonymize a significant fraction of Lightning payments through hash correlation alone.

Wormhole attacks

A wormhole attack exploits hash reuse more aggressively. Two colluding nodes on the same route share the preimage through an out-of-band channel, allowing the downstream colluder to settle the payment directly with the upstream colluder. Intermediate honest nodes lose their routing fees because the preimage bypassed them. The payment still completes from the sender's perspective, but honest routing nodes are cheated out of compensation while the colluding pair collects fees for the entire intermediate segment.

Probing exposure

Payment probing allows an adversary to discover channel balances by sending payments designed to fail. With HTLCs, the payment hash provides a fingerprint: if the same hash appears in multiple probes, the target can correlate the activity. While probing is possible with any routing mechanism, hash reuse gives nodes additional metadata to work with.

The core issue: HTLCs use a single hash for atomicity, but that same hash becomes a global identifier visible to every participant. Privacy and atomicity are conflated into one value when they should be independent properties.

Adaptor Signatures: The Cryptographic Foundation

PTLCs replace hash-based locking with adaptor signatures, a technique that exploits the algebraic properties of Schnorr signatures. Understanding adaptor signatures requires a brief look at how Schnorr works.

Schnorr signature basics

A BIP 340 Schnorr signature over a message m with private key x and nonce r produces a pair (R, s) where R = r*G and s = r + e*x (with e derived from the message and public key). The critical property is linearity: given two valid signatures, you can add them together algebraically and get another valid signature. This linearity is absent in ECDSA, which is why PTLCs were not practical before Taproot activated Schnorr on Bitcoin.

Building an adaptor signature

An adaptor signature is an incomplete Schnorr signature that becomes valid only when a secret scalar is revealed. Here is the construction:

1. Alice wants to create a signature locked to a secret t with corresponding point T = t*G.
2. She computes an adaptor signature (R', s') where R' = R + T. This is not a valid signature because the nonce point is shifted by T.
3. Anyone with T (the public point) can verify the adaptor signature is well-formed, confirming it will become a valid signature once t (the secret) is applied.
4. When t is revealed, anyone can compute s = s' + t to complete the signature.
5. Crucially, once the complete signature s is published, anyone who knew s' can extract t = s - s'.

This extraction property replaces the role of the preimage in HTLCs. Instead of revealing a hash preimage to claim payment, the receiver reveals a secret scalar by completing an adaptor signature, and every upstream hop can extract the scalar from the published signature to unlock its own funds.

How PTLCs Break Payment Correlation

The breakthrough of PTLCs is that each hop uses a different locking point. Unlike HTLCs where the hash H(preimage) is identical at every hop, PTLC points are decorrelated through randomization at each forwarding step.

Per-hop point randomization

When constructing a PTLC-based payment, the sender includes a different blinding factor for each hop in the onion-encrypted routing payload. Each forwarding node adjusts the locking point by adding its blinding factor before creating the outgoing PTLC. The result: the locking point at hop 1 is cryptographically unrelated to the locking point at hop 3.

More precisely, if the base payment point is P, hop i sees a lock point P + b_1*G + b_2*G + ... + b_i*G where each b_j is a blinding factor known only to the sender and the corresponding hop. No single hop can compute the lock points seen by other hops, and no two hops observe the same value.

Settlement still works

Despite every hop seeing a different point, atomicity is preserved. The receiver knows the base secret p (corresponding to point P) plus all accumulated blinding factors, allowing it to complete the final adaptor signature. Each upstream hop then extracts the adapted secret from the completed signature and adjusts it to unlock its own incoming PTLC. The algebraic structure of Schnorr signatures makes this possible without any hop needing to know secrets beyond its own.

Why this matters: An adversary controlling two nodes on a PTLC payment route sees two completely different lock points. There is no shared value to correlate. The wormhole attack also fails because the downstream colluder cannot produce a valid signature for the upstream colluder's different lock point without the intermediate blinding factors.

HTLCs vs PTLCs: A Technical Comparison

Additional Benefits Beyond Privacy

While decorrelation is the headline improvement, PTLCs offer several other advantages that make them attractive for Lightning's future.

Smaller on-chain footprint

When an HTLC must be resolved on-chain (due to an uncooperative channel close), it reveals the hash and preimage in the script, producing a larger and more expensive transaction. PTLCs settled cooperatively via adaptor signatures are indistinguishable from regular Taproot key-path spends on chain. Even in the uncooperative case, PTLC scripts using OP_CHECKSIGADD in Tapscript (BIP 342) are smaller than HTLC scripts that require OP_HASH160 and explicit hash comparison opcodes.

Stuckless payments

With HTLCs, if a payment gets stuck at an intermediate node (the node goes offline after locking funds), the sender must wait for the full timelock to expire before retrying. This can lock capital for hours. PTLCs enable a technique called stuckless payments: the sender can safely attempt a second payment along a different route without risking a double-payment, because the locking point construction allows the sender to cancel the first attempt cryptographically if the second one succeeds first.

Improved multi-path payments

Atomic multipath payments split a single payment across multiple routes. With HTLCs, all paths use the same hash, making it trivial for a node present on two paths to identify them as fragments of the same payment. PTLCs naturally decorrelate each path because each uses distinct lock points, strengthening the privacy of multi-path payment splitting strategies.

Compatibility with advanced protocols

PTLCs compose well with other proposed Lightning improvements. Protocols like eltoo (which simplifies channel state management using SIGHASH_ANYPREVOUT) and blinded paths (which hide the receiver's position in the route) both benefit from moving to Schnorr-native constructions. PTLCs and blinded paths together address two orthogonal privacy problems: blinded paths prevent the sender from learning the receiver's node, while PTLCs prevent intermediate nodes from correlating payments.

Implementation Challenges

Despite the clear benefits, deploying PTLCs across the Lightning Network is a substantial engineering effort. The transition involves changes to multiple layers of the protocol stack.

Channel type upgrades

Existing Lightning channels use HTLC-based commitment transactions. Switching to PTLCs requires either opening new channels with PTLC-capable commitment formats or performing in-place upgrades via splicing. The BOLT specifications need new feature bits, message types, and commitment transaction formats.

Mixed network routing

During the transition period, the network will contain both HTLC-only and PTLC-capable channels. A payment routed through a mixed path requires conversion points where a PTLC-to-HTLC (or HTLC-to-PTLC) swap occurs. These conversion points reintroduce the correlation problem at the boundary, limiting privacy benefits until PTLC adoption reaches critical mass.

Revocation mechanism changes

Lightning's current penalty mechanism uses revocation keys to punish the broadcast of old channel states via justice transactions. Adapting this for PTLC-based commitments requires careful cryptographic engineering to ensure that revoked states remain punishable even when the locking mechanism has changed from hashes to points.

Proof of payment

HTLCs provide a natural proof of payment: the preimage. Merchants and payment processors rely on preimage verification to confirm that a payment was received. PTLCs produce a completed adaptor signature as proof instead, which requires changes to invoicing systems, payment verification workflows, and the BOLT 12 offers specification. The keysend protocol, which allows payments without invoices, also needs adaptation for point-based locking.

Implementation Progress and Dependencies

PTLC deployment depends on several layers of work, each at a different stage of maturity.

The critical path runs through Taproot channel adoption and MuSig2 integration. Once Lightning implementations have Taproot-native channels, the incremental step to PTLCs becomes more tractable. However, the PTLC routing specification itself requires cross-implementation consensus, and the three major Lightning implementations (LND, CLN, Eclair) have historically moved at different speeds on protocol upgrades.

Privacy in Context: What PTLCs Do and Do Not Solve

PTLCs address payment correlation through hash reuse, but they are one piece of a larger privacy puzzle. Understanding their scope requires distinguishing them from other privacy mechanisms.

What PTLCs solve

• Same hash visible at multiple hops (the primary correlation vector)
• Wormhole attacks that exploit preimage forwarding
• Multi-path payment linkage through shared hashes
• On-chain fingerprinting of HTLC scripts in force-close scenarios

What PTLCs do not solve

• Timing analysis: payments forwarded within milliseconds of each other are still linkable
• Amount correlation: if the same value (minus fees) appears at two hops, correlation remains possible
• Route length inference from CLTV delta patterns
• Channel balance probing via deliberate payment failures
• Network-level surveillance through IP address correlation

Full payment privacy requires PTLCs combined with techniques like blinded paths, trampoline routing, and timing obfuscation. No single mechanism is sufficient on its own.

Beyond Lightning: How Spark Sidesteps the Problem

The HTLC-vs-PTLC discussion is specific to routing-based payment networks. Spark, a Bitcoin Layer 2 built on statechain principles, takes a fundamentally different approach that avoids the correlation problem altogether.

Spark transfers do not route through intermediate nodes. There is no payment hash and no multi-hop path. When Alice sends to Bob on Spark, ownership of the underlying Bitcoin changes through a direct key rotation between the parties and the Spark Entity. No routing node observes the transfer, and there is no shared cryptographic value that could be used for correlation.

This architectural difference means Spark does not need PTLCs, blinded paths, or any of the privacy patches that routing networks require. The privacy properties come from the transfer model itself: direct ownership changes leave no trail of forwarded secrets across a network graph.

When Spark users do interact with Lightning (sending or receiving Lightning payments via Spark Service Providers), the SSP acts as the boundary between the two models. The SSP handles the Lightning-side routing, including any HTLC or future PTLC mechanics, while the Spark-side transfer is a separate, uncorrelatable ownership change.

The Road Ahead

PTLCs represent a meaningful upgrade to Lightning's privacy model, but their deployment is gated by infrastructure work that is still underway. The progression looks roughly like this:

1. Taproot channel support becomes standard across LND, CLN, and Eclair (in progress).
2. MuSig2 is integrated for cooperative closes, establishing Schnorr-native channel operations.
3. PTLC-specific BOLT extensions are drafted and reach cross-implementation consensus.
4. Mixed HTLC/PTLC routing is specified to handle the transition period.
5. PTLC adoption reaches sufficient network penetration that most payments can be routed entirely through PTLC-capable channels.

Each of these steps involves specification work, implementation across multiple codebases, and coordination among independent development teams. The Bitcoin development community tends toward conservative, deliberate progress on protocol changes, which means the full privacy benefits of PTLCs will materialize gradually rather than in a single release.

For a deeper look at the mechanics of payment channels that underpin both HTLCs and future PTLCs, or the liquidity dynamics that shape how Lightning routes payments in practice, see the related research.

Key takeaway: PTLCs fix Lightning's most significant privacy weakness by eliminating payment hash correlation. They are a direct consequence of Schnorr signatures and Taproot, and the foundational pieces are already live on Bitcoin. The remaining work is in Lightning-layer specification and implementation: substantial, but well understood. In the meantime, protocols like Spark demonstrate that alternative transfer models can avoid the correlation problem entirely by design.

This article is for educational purposes only. It does not constitute financial or investment advice. Bitcoin and Layer 2 protocols involve technical and financial risk. Always do your own research and understand the tradeoffs before using any protocol.