Point Time Locked Contract는 포인트 잠금과 시간 제한 환불 경로를 결합한다. adaptor signature를 완성하면 대응하는 스칼라가 드러나 이전 참여자가 자신의 서명을 완성할 수 있고, timelock이 지나면 자금을 회수할 수 있다. 이는 프로토콜 구성 요소이며 현재 표준 Lightning 결제 유형은 아니다.
HTLC의 성공 경로는 공유 hash의 preimage를 아는 데 달렸지만 PTLC는 포인트 T = t·G와 스칼라 t가 있어야 완성되는 adaptor signature를 사용한다. 시간 경로는 남아 있어 결제가 완료되지 않으면 송신 측이 timeout 이후 자금을 회수한다. [1]
수신자는 비밀 스칼라를 고르고 대응 포인트를 공개한다. 인접 노드 쌍마다 포인트 잠금에 묶인 미완성 서명을 준비하며, 수신자가 마지막 서명을 완성하면 어댑터와 유효 서명의 차이에서 스칼라가 드러나 경로를 거꾸로 정산할 수 있다. [1]
송신자는 hop마다 다른 무작위 스칼라를 더하고 노드는 그 포인트를 차례로 뺄 수 있다. 공모하는 두 라우팅 노드는 일반 HTLC처럼 같은 payment hash를 보지 않지만 금액, timing, 만료, 토폴로지를 통한 상관관계는 여전히 남는다. [4]
BIP 340은 Schnorr 서명에 선형 방정식을 제공해 ECDSA보다 서명 어댑터를 자연스럽게 조합하게 한다. 집계 키를 쓰면 성공한 on-chain 지출이 일반 서명처럼 보일 수 있지만 실제 공간 절감은 채널 구조, multisignature 프로토콜, 비상 경로에 달려 있다. [2]
보안은 포인트와 timelock만으로 결정되지 않는다. 구현은 어댑터를 검증하고 서명을 메시지와 키에 정확히 묶고 nonce를 보호하며 스칼라를 안전하게 추출하고 환불 경로와 상대방 중단을 처리해야 한다. 오류는 키 유출이나 자금 손실을 초래할 수 있다. [1]
현재 기본 BOLT #2는 여전히 update_add_htlc, update_fulfill_htlc, htlc_signature를 규정한다. Taproot와 BIP 340이 Bitcoin에서 활성화됐다는 이유만으로 PTLC를 일반 Lightning Network의 상호운용 기능이라 할 수 없으며 합의된 메시지, 채널 상태, 호환 구현이 필요하다. [3]
2025년 개발자 논의는 MuSig2 adaptor signatures와 독립 Schnorr 어댑터를 위한 성숙하고 표준화된 도구가 일반 라이브러리에 없다고 지적한다. PTLC는 기술적으로 잘 발전한 제안이지만 공개 도구와 명세 상태는 광범위한 배포 주장을 뒷받침하지 않는다. [5]
PTLC는 라우팅 결제의 비상관화, proof of payment, 원자적 멀티패스 결제와 일부 swaps를 개선할 수 있다. 하지만 채널 가용성, 유동성, 상태 손실, 악의적 timing, 완전한 익명성을 혼자 해결하지 않으며 onion routing 및 채널 설계와 함께 평가해야 한다. [4]
더 정확히 이해하려면 이 항목과 함께 다음도 읽어 보세요 HTLC, Schnorr Signature, Lightning Network, Taproot, Payment Channel, Lightning Routing. 다음 항목에서도 이 글을 참조합니다 Trampoline Routing.
01일반 Lightning Network는 현재 HTLC 대신 PTLC를 사용하는가?+
공통 상호운용 기반으로는 사용하지 않는다. 현행 BOLT 명세는 여전히 HTLC 메시지와 서명을 정의한다. PTLC에는 추가 암호 도구, 프로토콜 메시지, 상태 전이와 구현 합의가 필요하며 Taproot 활성화만으로 전환되지 않는다.
02PTLC는 왜 HTLC보다 프라이버시가 좋은가?+
여러 HTLC hop이 같은 payment hash를 운반하면 공모 노드에 직접적인 상관값을 준다. PTLC에서는 각 hop이 로컬 포인트를 더해 잠금을 바꿀 수 있다. 금액, timing, 만료와 네트워크 위치는 여전히 결제를 연결할 수 있다.