Point Time Locked Contracts (PTLCs)
Point Time Locked Contracts (PTLCs) are conditional payments that can replace the use of HTLCs in LN payment channels, same-chain coinswaps, some cross-chain atomic swaps, and other contract protocols. Compared to HTLCs, they can be more private and use less block space.
PTLCs differ from HTLCs in their primary locking and unlocking method:
-
● HTLC hash locks: are locked using a hash digest and unlocked by providing the corresponding preimage. The most commonly used hash function is SHA256, which produces a 256-bit (32-byte) digest commonly generated from a 32-byte preimage.
When used to secure multiple payments (e.g. a routed LN payment or an atomic swap), all payments use the same preimage and hash lock. This creates a link between those payments if they’re published onchain or if they’re routed offchain though surveillance nodes.
-
● PTLC point locks: are locked using a public key (a point on Bitcoin’s elliptic curve) and unlocked by providing a corresponding signature from a satisfied signature adaptor. For a proposed schnorr signature construction, the key would be 32 bytes and the signature 64 bytes. However, using either multiparty ECDSA or schnorr key aggregation and signing, the keys and signature can be combined with other keys and signatures needed to authorize any spend, allowing point locks to use zero bytes of distinct block space.
Each point lock can use different keys and signatures, so there is nothing about the point lock that correlates different payments either onchain or when routed offchain through surveillance nodes.
Implementation of PTLCs in Bitcoin requires creating signature adaptors that will be easier to combine with digital signatures when schnorr signatures have been implemented on Bitcoin. For that reason, the development of PTLCs in Bitcoin has mostly been a discussion topic rather than something actively worked on. The unavailability of schnorr signatures in alternative cryptocurrencies may also prevent the use of PTLCs in some cross-chain contracts, though it is still technically possible to use PTLCs with just ECDSA pubkeys and signatures.
Primary code and documentation
Optech newsletter and website mentions
2024
2023
- Summary of proposed LN messaging changes for PTLCs
- Using signature adaptors with PTLCs to prove acceptance of an LN async payment
2021
- 2021 year-in-review: PTLCs for LN
- Discussion about LN protocol changes necessary to support PTLCs
- Summary of LN developer conference, including discussion of PTLCs
- Using PTLCs for non-custodial offline receiving
- Proposal to upgrade LN to use PTLCs
- Updating LN for taproot: from HTLCs to PTLCs
- Preparing for taproot: PTLCs
- Technique for implementing logical OR on LN using PTLCs
2020
- 2020 year in review: switching LN from HTLCs to PTLCs
- Updated witness asymmetric channels proposal for move from HTLCs to PTLCs
- Using witness asymmetric payment channels for move from HTLCs to PTLCs
- Simplified ECDSA adaptor signatures for PTLCs in LN channels
2018
See also
Previous Topic:
Partially signed bitcoin transactions
Next Topic:
Quantum resistance