Ein Point Time Locked Contract verbindet eine Punktsperre mit einem zeitgebundenen Rückzahlungspfad: Das Vervollständigen einer adaptor signature legt den zugehörigen Skalar offen, mit dem der vorherige Teilnehmer seine eigene Signatur vervollständigt; nach Ablauf des Timelocks können die Mittel zurückgeholt werden. Es ist ein Protokollbaustein und heute kein standardmäßiger Lightning-Zahlungstyp.
Bei einem HTLC hängt der Erfolgspfad von der Kenntnis der Preimage eines gemeinsamen Hashes ab; ein PTLC verwendet stattdessen einen Punkt T = t·G und eine adaptor signature, die nur mit dem Skalar t vervollständigt werden kann. Der Zeitpfad bleibt: Scheitert die Abwicklung, kann die sendende Seite die Mittel nach dem Timeout zurückholen. [1]
Der Empfänger wählt einen geheimen Skalar und veröffentlicht den zugehörigen Punkt. Jedes Paar benachbarter Nodes bereitet unvollständige Signaturen für seine Punktsperre vor; vervollständigt der Empfänger die letzte Signatur, legt die Differenz zwischen Adapter und gültiger Signatur den Skalar offen und ermöglicht die rückwärts laufende Abwicklung. [1]
Der Sender kann für jeden Hop einen anderen zufälligen Skalar addieren, dessen Punkt die Nodes schrittweise abziehen. Zwei zusammenarbeitende Routing-Nodes sehen dann nicht denselben payment hash wie bei einem gewöhnlichen HTLC; Korrelation über Betrag, Timing, Ablauf oder Topologie bleibt jedoch möglich. [4]
BIP 340 gibt Schnorr-Signaturen eine lineare Gleichung, mit der sich Signaturadapter natürlicher kombinieren lassen als mit ECDSA. Mit aggregiertem Schlüssel kann ein erfolgreicher On-chain-Spend wie eine normale Signatur aussehen; die tatsächliche Platzersparnis hängt aber von Kanalkonstruktion, Multisignature-Protokoll und Notfallpfad ab. [2]
Sicherheit beruht nicht nur auf Punkt und Timelock. Eine Implementierung muss den Adapter prüfen, die Signatur korrekt an Nachricht und Schlüssel binden, Nonces schützen, den Skalar sicher extrahieren, den Refund erhalten und einen Abbruch der Gegenpartei behandeln; ein Fehler kann Schlüssel offenlegen oder Mittel verlieren. [1]
Das aktuelle grundlegende BOLT #2 beschreibt weiterhin update_add_htlc, update_fulfill_htlc und htlc_signature. PTLC ist daher nicht allein deshalb eine interoperable Funktion gewöhnlicher Lightning-Nodes, weil Taproot und BIP 340 auf Bitcoin aktiv sind; nötig sind vereinbarte Nachrichten, Kanalzustände und kompatible Implementierungen. [3]
Die Entwicklerdiskussion von 2025 verweist auf fehlende standardisierte und ausgereifte Werkzeuge für Signaturadapter mit MuSig2 sowie eigenständige Schnorr-Adapter in üblichen Bibliotheken. PTLC ist technisch weit ausgearbeitet, doch der öffentliche Stand von Werkzeugen und Spezifikationen erlaubt keine Behauptung einer breiten Einführung. [5]
PTLC kann die Entkopplung gerouteter Zahlungen, Zahlungsnachweise, atomare Multipath-Zahlungen und bestimmte Swaps verbessern. Kanalverfügbarkeit, Liquiditätssteuerung, Zustandsverlust, böswilliges Timing oder vollständige Anonymität löst es allein nicht; der Nutzen ist mit Onion Routing und Kanaldesign zu bewerten. [4]
Für ein möglichst vollständiges Bild lies diesen Eintrag zusammen mit HTLC, Schnorr Signature, Lightning Network, Taproot, Payment Channel, Lightning Routing. Auf diesen Eintrag verweisen außerdem Trampoline Routing.
01Verwendet das gewöhnliche Lightning Network heute PTLC statt HTLC?+
Nicht als gemeinsame interoperable Grundlage. Die aktuellen BOLT-Spezifikationen definieren weiterhin HTLC-Nachrichten und -Signaturen. PTLC braucht zusätzliche Kryptowerkzeuge, Protokollnachrichten, Zustandsübergänge und Einigkeit der Implementierungen; die Aktivierung von Taproot allein führte diese Migration nicht aus.
02Warum ist ein PTLC privater als ein HTLC?+
Mehrere HTLC-Hops können denselben payment hash tragen und zusammenarbeitenden Nodes damit einen direkten Korrelationswert geben. Bei PTLC kann jeder Hop die Punktsperre durch Addition eines lokalen Punkts ändern. Betrag, Timing, Ablauf und Netzposition können die Zahlung weiterhin verbinden.