pull down to refresh

OTS-PC: OTS-based Payment Channels for the Lightning Networkarxiv.org/abs/2511.04021
100 sats \ 1 comment \ @jakoyoh629 19h lightning
We present a new type of bidirectional payment channel based on One-Time Signatures on state sequence numbers. This new construction is simpler than the Poon-Dryja construction, but provides a number of benefits such as storage per channel, minimal information leakage, and compatibility with Lightning Network routing.
write
preview
related posts
0 sats \ 0 replies \ @supratic 5h
This is all good in theory, until someone take the leap and implement it somewhere. Overall it make sense, LN today is complex and UX isn't ideal. Truth is, it's not for everyone, and probably is better this way...
Anyhow, I took the time to dig a bit on the main differences to try to figure out how it suppose to work. From a UX perspective nothing changes, look's to me a simplification on the structure and keys managements when opening/closing channels. What happens under the hood is significantly more elegant.
When opening a Lightning channel (Poon-Dryja) today:
  1. Exchange Multiple Keys to connect peers and share multiple types of keys:
      1. Base keys for signing
      1. Revocation keys (to punish cheating)
      1. Delayed payment keys
      1. HTLC keys (for routing payments)
  2. Create Complex Transactions pre-signing several interconnected transactions:
      1. Funding transaction (goes on blockchain)
      1. Commitment transactions (one for each party)
      1. HTLC transactions (for routing)
      1. Penalty transactions (to punish old states)
  3. Storage: Each peer node stores a growing tree of revocation secrets for each channel status update.
Now, considering the assumptions above are correct, the process look's much more complex when compared with opening an OTS channel:
  1. Exchange Fewer Keys:
      1. Secret hashes (H_a and H_b): Used for timeout protection
      1. One-Time Signature keys: One key pair per person for signing state numbers
    • That's it - no complex key derivation trees
  2. Create Fewer Initial Transactions:
      1. Funding transaction (Setup) - goes on blockchain
      1. Initial exit path transactions
    • All following the same simple pattern
  3. Storage: Fixed amount - doesn't grow with channel updates

Key Differences from Taproot Channels

Taproot Channels (current Lightning with Taproot) mainly improve:
  • Privacy (looks like regular transactions)
  • Efficiency (smaller, cheaper transactions)
  • But keep the same complex Poon-Dryja structure underneath
OTS-PC with Taproot uses Taproot differently:
  • Uses Taproot's script tree for multiple spending paths (cooperative close, disputes, timeouts)
  • Leverages Taproot addresses but with a fundamentally different channel structure
  • Can use MuSig2 for even better privacy (2-of-2 multisig looks like single signature)

The Visual Difference

Current Lightning Opening:
Alice & Bob exchange:
→ 8+ different key types
→ Create 4+ transaction templates
→ Store revocation secret #1 (will grow to #2, #3, #4...)
→ Complex penalty mechanism setup
OTS-PC Opening:
Alice & Bob exchange:
→ 2 secret hashes
→ 2 one-time signature keys
→ Create 3 simple transaction templates
→ Store fixed data (never grows)
→ Simple sequence number mechanism

What's different in practice?

For Users: Opening feels nearly identical
  • Same waiting time for blockchain confirmation
  • Same balance displays in wallet
  • Same ability to start making payments immediately after
For Developers: Much easier
  • Fewer edge cases to handle during setup
  • Less complex key management
  • Simpler testing and debugging

The "One-Time Signature" part

This is the clever innovation:
  • Instead of complex revocation keys, OTS offers one key that peers use to sign sequence numbers
  • It's "one-time" because signing an old sequence number (to cheat) gives peers proof to sanction
  • Like writing a check number - when trying to cash an old check and a newer ones exist, peer get caught.
reply