Adaptor signature concept (simplified math):

14. PTLC Scripts: The Taproot Upgrade to HTLC

The Problem with HTLCs: Payment Correlation

HTLCs have a significant privacy flaw: the same payment hash H is used across every hop in a Lightning payment route. An intermediary node can correlate payments by recognizing the same hash appearing in multiple HTLCs, effectively allowing them to link the sender and receiver of a payment.

Additionally, on-chain HTLC scripts are visually distinctive — they contain a hash preimage check and a timelock, making them easy to identify as Lightning-related transactions, even through P2SH/P2WSH wrapping.

Point Time-Locked Contracts (PTLCs) solve both problems by replacing hash locks with Schnorr signature adaptors, leveraging Bitcoin's Taproot upgrade (BIP 340/341, activated November 2021).

Schnorr Signatures and Adaptor Signatures

The key primitive enabling PTLCs is the adaptor signature (also called "signature adaptor" or "scriptless script"):

# Adaptor signature concept (simplified math):
# Normal Schnorr signature: s = r + H(R, P, m) * x
#   where: r = nonce, R = G*r, P = pubkey, m = message, x = privkey

# Adaptor signature: s' = r + H(R + T, P, m) * x
#   where T = G*t (a public "tweak point", like a public key for the secret)
# s' is an "adaptor signature": valid only if you know t (the scalar secret)

# To verify an adaptor signature, the verifier checks:
#   s' * G == R + T + H(R + T, P, m) * P
# This verifies WITHOUT knowing t.

# To finalize (convert adaptor → real signature):
#   s = s' + t   (add the scalar secret t)
# Now s is a valid Schnorr signature for R + T, P, m

# Key insight for PTLCs:
# t plays the role that the preimage played in HTLCs.
# Revealing t (by finalizing the signature) is like revealing the preimage.
# But t is a scalar, not a hash preimage — it's unlinkable across hops!

PTLC vs HTLC Comparison

| Feature | HTLC | PTLC | |