claude-dev-suite Adaptor Signatures
An adaptor signature is a modification of a Schnorr signing
protocol: instead of producing a complete signature, the signer
produces a pre-signature that is invalid on its own but becomes
valid once adapted with a secret value t.
Two key properties:
- Witness extractability — given a complete sig and the
pre-signature, anyone can compute
t. - Atomicity — observing one side of a swap reveals the secret needed for the other side.
Schnorr-based adaptor (BIP340)
Standard Schnorr sig:
e = challenge(R, P, m)
s = k + e*d (where R = k*G)
Adaptor variant with adaptor point T = t*G:
s' = k + e*d ← same as normal s
σ = (R, s') ← pre-signature
But the verifier checks against (R + T), not R. So σ alone fails
verification. To complete:
s = s' + t mod n
Now (R + T, s) verifies as a normal Schnorr sig under public key P.
Properties used
- Pre-sig verify — anyone can check that
σis "valid except for T" by checkings'*G - e*P == R. - Adapt — with
t, anyone can computes = s' + t. - Extract — with both
σands, computet = s - s'.
Scriptless atomic swap
Two parties Alice (BTC) and Bob (LTC) want to swap.
Alice creates Tx_A (BTC for Bob), with Alice's signature σ_A as adaptor
with adaptor point T = t*G (t known only to Alice)
σ_A: pre-sig — Bob CAN'T spend yet (verifier expects sig over R+T, not R)
Bob creates Tx_B (LTC for Alice), with Bob's signature σ_B as adaptor
with the SAME adaptor point T
Alice publishes Tx_B by adapting σ_B with t (Alice can do this because
she knows t)
→ publishing reveals s_B = σ_B + t
→ Bob extracts t = s_B - σ_B (he sees Tx_B on chain)
Bob now adapts σ_A with t to spend Tx_A
Both txs publish or neither. No HTLC, no script, no preimage. Just two adaptor sigs over the same secret.
PTLC (Point Time-Locked Contract)
Lightning's HTLC = "Hash Time-Locked Contract" — locks fund release
on revealing a preimage r such that hash(r) = H.
PTLC = "Point Time-Locked Contract" — locks fund release on revealing
a scalar t such that t*G = T. Same atomic guarantees, but:
- Better privacy: each hop in a routed payment uses a different
T(derived per-hop), defeating cross-hop correlation. - Smaller on chain — no preimage in script, just an adaptor sig.
- Compatible with Schnorr — needs Taproot adoption.
PTLC requires LN-spec updates (BOLT-PTLC drafts in flight).
DLC (Discreet Log Contract) integration
DLC oracles publish nonce commitments. Bettors construct adaptor sigs that adapt under specific oracle outcomes:
Oracle nonces: R_oracle for upcoming event, will publish (s_outcome, R_oracle)
where s_outcome = k_oracle + e_outcome * d_oracle
Bettor pre-signs CET (Contract Execution Tx) with adaptor point
T_outcome = R_oracle + (e_outcome * P_oracle)
When oracle publishes s_outcome for the actual outcome:
bettor extracts t_outcome = s_outcome
adapts pre-sig → publishes CET
Other applications
- Submarine swaps (LN ↔ on-chain) trustless variants.
- Cross-chain atomic swaps without HTLC.
- Coin-mixing with PTLC for privacy.
- Threshold escrow — n-of-m parties can adapt with their share of
t.
Implementations
secp256k1-zkp(Blockstream's libsecp256k1 fork) — has adaptor sig module.rust-bitcoin/adaptor-sigcrates.- DLC:
rust-dlc,dlc-rsfrom Crypto Garage / DLC.dev. - Some Lightning impls'
PTLCbranches (LDK research, not mainnet).
Security caveats
- Choice of
tmust be uniformly random in [1, n-1]. - Reuse of adaptor point across protocols → cross-protocol leak.
- Atomic timing: while atomicity is guaranteed, timing windows matter: refund paths must give honest party time to react.
- Fair-exchange impossibility is sidestepped because adaptor sig embeds the unforgeable signing operation.
Common bugs
- Forgetting parity flip when computing
R + T(Schnorr's even-y rule applies to the resulting point). - Storing
tin plaintext between adapt and reveal phases. - Failing to verify pre-signature before relying on it (someone could give you a completely random pre-sig that won't adapt).