Point Time Locked Contract はポイントロックと時間制限付き返金経路を組み合わせる。adaptor signature を完成すると対応するスカラーが明らかになり、前の参加者が自身の署名を完成できる一方、timelock 後は資金を回収できる。これはプロトコル部品であり、現在標準の Lightning 支払い形式ではない。
HTLC の成功経路は共有ハッシュの 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、期限、ネットワーク位置による関連付けは残る。