Bitcoin Timelocks erklärt: nLockTime, CLTV und CSV sicher verstehen

Bitcoin Timelocks erklärt: nLockTime, CLTV und CSV sicher verstehen

Bitcoin ist nicht nur ein digitales Zahlungsmittel. Sein Regelwerk erlaubt auch, Bedingungen für den Zeitpunkt einer Ausgabe festzulegen. Solche Zeitsperren heissen Timelocks. Sie können verhindern, dass eine bestimmte Transaktion zu früh bestätigt wird, oder einen bestimmten Ausgabepfad erst nach einer Wartefrist freigeben. Gerade bei Sicherheitskonzepten, Zahlungskanälen und der langfristigen Verwahrung lohnt es sich, diese Unterscheidung zu verstehen. Denn eine Timelock ist weder ein Sparkonto mit Kündigungsfrist noch ein automatischer Überweisungsauftrag.

In diesem Fachartikel lernst Du, was absolute und relative Bitcoin-Timelocks voneinander unterscheidet, wie nLockTime, OP_CHECKLOCKTIMEVERIFY (CLTV) und OP_CHECKSEQUENCEVERIFY (CSV) technisch zusammenhängen und wo die Grenzen liegen. Wir arbeiten mit Blockhöhen, Zeitstempeln und nachvollziehbaren Beispielen. Die Erklärung richtet sich an fortgeschrittene Einsteiger und an Menschen, die ihre Bitcoin-Sicherheit nicht allein auf Werbeversprechen stützen wollen.

Was bedeutet eine Timelock bei Bitcoin?

Eine Timelock ist eine durch das Bitcoin-Protokoll durchgesetzte zeitliche Bedingung. Vereinfacht gesagt: Ein bestimmter Transaktionsvorgang oder Ausgabepfad darf erst gültig werden, wenn eine definierte Blockhöhe oder Zeitbedingung erreicht ist. Anders als bei einer Bank entscheidet dabei kein Sachbearbeiter, wann eine Sperre endet. Vollständig validierende Bitcoin-Nodes prüfen die einschlägigen Konsensregeln selbst.

Dabei musst Du zwei Ebenen auseinanderhalten. Auf Transaktionsebene kann nLockTime festlegen, ab wann eine Transaktion grundsätzlich in einen gültigen Block aufgenommen werden darf. Auf Skriptebene können CLTV und CSV einzelne Ausgabepfade einer Bitcoin-Ausgabe (UTXO) zeitlich einschränken. Bei komplexeren Skripten kann es gleichzeitig einen sofortigen Pfad und einen späteren Wiederherstellungspfad geben. Das ist der Kern vieler fortgeschrittener Konstruktionen.

Ein wichtiges Gegenbeispiel: Wenn Du heute Bitcoin in eine normale Wallet sendest, existiert nicht automatisch eine Timelock. Und wenn Du bloss eine Transaktion mit nLockTime vorbereitest, sind die zugrunde liegenden Coins dadurch nicht dauerhaft eingefroren. Solange der Schlüsselbesitzer eine andere gültige Transaktion signieren kann, bleibt eine alternative Ausgabe möglich. Genau deshalb sind Transaktionssperren und Skriptsperren nicht austauschbar.

Absolute und relative Timelocks im Vergleich

Eine absolute Timelock bezieht sich auf einen festen Zielwert: beispielsweise eine konkrete Blockhöhe. Eine relative Timelock bezieht sich dagegen auf das Alter eines bestimmten UTXO beziehungsweise dessen bestätigenden Blocks. Die Uhr beginnt bei relativen Sperren also nicht notwendigerweise am Tag, an dem Du den Vertrag vorbereitest.

Nehmen wir ein gedankliches Beispiel. Ein absoluter Ausgabepfad könnte erst ab einer festgelegten Höhe H nutzbar werden. Eine relative Sperre über 144 Blöcke orientiert sich hingegen an der Bestätigung der Ausgabe, die später verwendet werden soll. Wird diese Ausgabe erst morgen bestätigt, verschiebt sich der frühestmögliche spätere Ausgabepunkt entsprechend. Die Zahl 144 steht häufig als grobe Orientierung für einen Tag, weil Bitcoin im langfristigen Mittel ungefähr alle zehn Minuten einen Block anstrebt. Sie ist keine Garantie für exakt 24 Stunden.

Merkmal	Absolute Timelock	Relative Timelock
Bezugspunkt	Feste Blockhöhe oder Zeitgrenze	Alter der zu verwendenden Ausgabe
Typische Mechanismen	nLockTime und CLTV	BIP 68 und CSV
Beginn	Vorgegebener Grenzwert	Bestätigung der vorherigen Ausgabe
Beispiel	Ausgabeweg erst ab Höhe H	Ausgabeweg nach 144 Blöcken
Häufiger Einsatzzweck	Späterer Rückfallpfad	Warte- und Reaktionsfristen

Werbung / Affiliate-Link: Wenn Du Bitcoin erwerben möchtest, ist Relai eine mögliche Option. Bei Nutzung unseres Codes AUSWANDERNSCHWEIZ kann eine Provision für unsere Website entstehen. Ein Bitcoin-Kauf ist mit Kurs- und Verwahrungsrisiken verbunden.

nLockTime: Die Sperre auf Transaktionsebene

Jede klassische Bitcoin-Transaktion besitzt ein Feld namens nLockTime. Der Wert kann eine Blockhöhe oder eine Zeitgrenze ausdrücken. Werte unter 500'000'000 werden als Blockhöhen interpretiert; Werte ab dieser Schwelle als Unix-Zeitstempel. Für die Wirksamkeit der Sperre spielen ausserdem die nSequence-Felder der Inputs eine Rolle. Sind sämtliche Input-Sequenzen auf den finalen Maximalwert gesetzt, wird nLockTime für die Finalitätsprüfung wirkungslos.

Die häufige Aussage «nLockTime sperrt meine Bitcoin bis zum Datum X» ist daher irreführend. Es ist zunächst die konkrete Transaktion, die vor der vorgesehenen Grenze nicht in einen gültigen Block darf. Die Ausgabe selbst bleibt unter Umständen mit einer anderen Transaktion verwendbar. Das ist relevant, wenn Du vorab eine Rückzahlung signierst: Eine vorab signierte Transaktion kann eine zeitliche Option schaffen, ersetzt aber nicht die Prüfung sämtlicher alternativer Ausgabemöglichkeiten.

Auch der Grenzwert selbst ist wichtig. Bei der Konsensprüfung gilt die Finalitätsbedingung nicht einfach als erfüllt, wenn die relevante Blockhöhe exakt dem nLockTime-Wert entspricht. Für die frühestmögliche Aufnahme ist die genaue Vergleichslogik entscheidend. Eine Wallet oder Bibliothek sollte diese Details korrekt implementieren; bei eigenen Skripten darfst Du nicht bloss eine ungefähre Kalenderrechnung verwenden.

Beispiel mit einer Blockhöhe

Angenommen, eine vorbereitete Transaktion trägt nLockTime = 950'000 und mindestens ein Input ist nicht final. Bei einer für den nächsten Block relevanten Vergleichshöhe von 950'000 ist sie nach der strikten Vergleichsregel noch nicht final. Bei einer Vergleichshöhe von 950'001 ist diese Bedingung erfüllt. Das Beispiel illustriert nur die nLockTime-Regel; Signaturen, verfügbare Inputs, Gebühren und andere Konsensregeln müssen ebenfalls passen.

Zeitstempel sind keine präzisen Wecker

Bei zeitbasiertem nLockTime verwendet das Bitcoin-Netzwerk seit BIP 113 die Median Time Past (MTP) als massgebliche Zeitreferenz. Sie beruht auf dem Median der Zeitstempel der vorherigen elf Blöcke. Damit wird eine einzelne willkürliche Blockzeit weniger einflussreich. Für Dich bedeutet das: Eine zeitbasierte Sperre lässt sich nicht seriös auf die Sekunde einer Schweizer Wanduhr terminieren. Blockproduktion, MTP und die Aufnahme durch Miner können die tatsächliche Ausführung verschieben.

CLTV: Eine feste Zeitbedingung direkt im Bitcoin-Skript

OP_CHECKLOCKTIMEVERIFY, kurz CLTV, wurde in BIP 65 beschrieben. CLTV erlaubt es, innerhalb eines Bitcoin-Skripts einen Ausgabepfad an eine absolute Sperre zu binden. Die Prüfung betrachtet unter anderem den Locktime-Typ, den nLockTime-Wert der ausgebenden Transaktion und die Sequenz des betreffenden Inputs. Die Bedingung ist nicht dadurch erfüllt, dass irgendeine Wallet «das Datum anzeigt».

Der praktische Unterschied zu nLockTime ist erheblich: Bei einem entsprechend konstruierten UTXO kann ein Skript erzwingen, dass ein bestimmter Pfad vor der Grenze nicht verwendet wird. Allerdings kann dasselbe Skript bewusst andere, frühere Pfade vorsehen. Wer von «gesperrten Bitcoin» spricht, muss deshalb immer erklären, welcher Pfad gesperrt ist und welche Schlüssel andere Pfade öffnen können.

Stell Dir ein Sicherheitskonzept mit zwei Bedingungen vor. Ein Hauptschlüssel darf jederzeit ausgeben. Ein separater Wiederherstellungsschlüssel wird erst ab einer bestimmten Blockhöhe zugelassen. Damit lässt sich ein späterer Rückfallweg schaffen, ohne die reguläre Nutzung zu blockieren. Die Sicherheit hängt dann aber stark davon ab, ob beide Schlüssel wirklich getrennt verwahrt werden und ob das Skript sowie die Wallet den späteren Pfad zuverlässig unterstützen.

Warum CLTV kein automatischer Zahlungsauftrag ist

CLTV verschickt keine Bitcoin, wenn eine Frist abläuft. Nach Erreichen der Grenze muss weiterhin jemand eine passende Transaktion erstellen, korrekt signieren und an das Netzwerk übertragen. Auch Gebühren müssen berücksichtigt werden. Die Sperre ist eine Gültigkeitsbedingung, kein Hintergrunddienst. Wenn der notwendige Schlüssel fehlt oder die Wallet das Skript nicht rekonstruieren kann, hilft Dir das blosse Verstreichen der Zeit nicht.

CSV: Relative Fristen über OP_CHECKSEQUENCEVERIFY

OP_CHECKSEQUENCEVERIFY (CSV) ist in BIP 112 spezifiziert und arbeitet mit den relativen Locktime-Regeln aus BIP 68 zusammen. Während CLTV auf einen festen Zeitpunkt oder eine feste Höhe abstellt, kann CSV einen Skriptpfad erst nach einer bestimmten Alterungsfrist einer Ausgabe zulassen. Dazu werden die Versions- und Sequenzregeln der ausgebenden Transaktion ausgewertet.

Bei relativen Sperren gibt es zwei relevante Einheiten. Blockbasierte Fristen zählen Blöcke. Zeitbasierte relative Fristen arbeiten mit Einheiten von 512 Sekunden und beziehen sich auf die Median-Zeit der Blockchain. Ein Beispiel: 12 Zeiteinheiten entsprechen rechnerisch 6'144 Sekunden, also einer Stunde, 42 Minuten und 24 Sekunden. Das ist der kodierte Mindestabstand in der entsprechenden Konsenslogik, nicht eine Zusicherung, dass die Transaktion nach exakt dieser Dauer bestätigt wird.

Ein häufiges Missverständnis betrifft die Zahl im nSequence-Feld: Sie ist nicht immer einfach eine Wartezeit in Minuten. Bestimmte Bits bestimmen, ob relative Sperren aktiv sind und ob eine Zeit- oder Blockeinheit verwendet wird. Wer ein Rohtransaktionsfeld ohne diese Bitmasken interpretiert, kann die Wirkung vollständig falsch lesen.

Beispiel: 144 Blöcke als Rückfallfrist

Eine Ausgabe wird in Blockhöhe 900'000 bestätigt. Ein Skriptpfad fordert eine relative Sperre von 144 Blöcken. Die entsprechende relative Reifebedingung orientiert sich an der bestätigten Ausgabe; vereinfacht kann der Pfad ab der späteren Vergleichshöhe 900'144 die Altersschranke erfüllen. Ob eine konkrete Transaktion in einem bestimmten Block final ist, hängt zusätzlich von den exakten BIP-68-Regeln, ihrer Version, den Input-Sequenzen und allen anderen Bedingungen ab.

Bei durchschnittlich zehn Minuten pro Block entsprächen 144 Blöcke rechnerisch 1'440 Minuten oder 24 Stunden. In der Realität schwanken die Blockintervalle stark. Darum sind 144 Blöcke ein protokollbezogener Zeitraum, kein verlässlicher 24-Stunden-Timer für dringende Zahlungen.

BIP 68, 112 und 113: Warum drei Regeln zusammengehören

BIP 68 beschreibt, wie nSequence für relative Locktime-Konsensregeln verwendet werden kann. BIP 112 führt CSV als Skriptoperation ein, die eine solche relative Bedingung im gewählten Ausgabepfad prüft. BIP 113 stellt für absolute zeitbasierte Finalität auf die Median Time Past ab. Die Vorschläge ergänzen sich, haben aber unterschiedliche Aufgaben. CLTV wiederum ist separat in BIP 65 geregelt.

Diese Unterscheidung verhindert einen verbreiteten Denkfehler: CSV und BIP 68 sind nicht zwei Namen für dieselbe Prüfung. CSV ist ein Skriptoperator. BIP 68 beschreibt Transaktionsfinalität bei relativ gesperrten Inputs. Ein Skript kann eine relative Bedingung verlangen; die Transaktion muss gleichzeitig den einschlägigen Konsensregeln genügen. Es reicht also nicht, einen beliebigen Opcode in einen Text zu schreiben und darauf zu vertrauen, dass das Netzwerk eine Sicherheitsgarantie daraus macht.

Warum Timelocks für das Lightning Network wichtig sind

Das Lightning Network verwendet Zahlungskanäle und zeitliche Bedingungen, um Zahlungen ausserhalb der Bitcoin-Hauptchain abzuwickeln und Konflikte abzusichern. In verschiedenen Lightning-Konstruktionen spielen relative Verzögerungen und Hash Time-Locked Contracts (HTLCs) eine Rolle. Sie ermöglichen unter anderem, dass Parteien auf bestimmte Kanalzustände reagieren können, bevor ein anderer Pfad endgültig ausgegeben werden darf.

Eine solche Reaktionsfrist ist keine Garantie, dass Du ohne Überwachung oder verlässliche Dienstleistung jederzeit sicher bist. Wer eine eigene Lightning-Node betreibt, muss verstehen, welche Überwachungs-, Backup- und Wiederherstellungsmechanismen die verwendete Software tatsächlich anbietet. Besonders bei längerer Offline-Zeit oder fehlerhaften Backups kann das Sicherheitsmodell komplex werden. Eine einfache Bitcoin-Wallet und eine Lightning-Node haben daher unterschiedliche Betriebsanforderungen.

HTLCs kombinieren zeitliche Bedingungen mit kryptografischen Bedingungen. Sie erlauben beispielsweise einen Pfad bei Offenlegung eines bestimmten Geheimnisses und einen alternativen Rückfallpfad nach Ablauf einer Frist. Die genaue Umsetzung ist komplexer als ein gewöhnlicher Überweisungstermin. Timelocks sind hier ein Baustein eines Protokolls, nicht die ganze Lösung.

Timelocks, Multisig und sichere Wiederherstellung

Bei Bitcoin Multisig werden mehrere Schlüssel oder Signaturen kombiniert. Timelocks können zusätzliche Bedingungen für alternative Ausgabepfade schaffen. Ein Konzept könnte vorsehen, dass zwei Schlüssel sofort gemeinsam signieren müssen, während ein anders geschützter Wiederherstellungspfad erst später verfügbar wird. Solche Konstruktionen erfordern eine präzise Beschreibung des Skripts und aller möglichen Ausgabepfade.

Das hat Folgen für die Aufbewahrung. Ein Backup nur der Seed Phrase kann bei komplexen Skripten unzureichend sein, wenn Informationen über Skript, Ableitungspfade, Deskriptoren oder beteiligte Schlüssel fehlen. Umgekehrt kann eine unverschlüsselte Dokumentation mit sämtlichen Geheimnissen die Sicherheit zerstören. Die richtige Balance besteht aus reproduzierbaren technischen Informationen und strikt getrennten Geheimnissen.

Für langfristige Konzepte ist der Beitrag Bitcoin vererben in der Schweiz eine sinnvolle Ergänzung. Eine Timelock ersetzt weder eine Nachlassregelung noch die Schulung der berechtigten Personen. Erben müssen wissen, welche Unterlagen vorhanden sind, wann welcher Ausgabepfad zulässig wird und wie sie die nötige Wallet-Software ohne riskante Experimente verwenden.

Kann man Bitcoin mit einer Timelock vor Diebstahl schützen?

Teilweise können zeitlich verzögerte Pfade einem Sicherheitskonzept helfen. Die einfache Formel «Timelock = Diebstahlschutz» stimmt jedoch nicht. Ein Angreifer mit einem sofort gültigen Schlüssel oder einem früheren Skriptpfad kann gegebenenfalls sofort ausgeben. Auch ein falsch entworfener Rückfallpfad, ein verlorener Schlüssel oder eine unzureichend getestete Wiederherstellung können zu Verlusten führen.

Eine sinnvolle Sicherheitsarchitektur prüft zuerst das Bedrohungsmodell: Gegen wen willst Du Dich schützen? Gegen einen gestohlenen Hot-Wallet-Schlüssel, einen defekten Hardware-Signer, den Ausfall eines Mitunterzeichners oder eine falsche Transaktion? Unterschiedliche Risiken brauchen unterschiedliche Massnahmen. Manchmal ist eine sauber eingerichtete Hardware Wallet mit getrenntem Backup praktischer und sicherer als eine selbst gebaute Timelock-Konstruktion.

Selbst ein technisch gültiges Skript schützt nicht vor Social Engineering. Wenn jemand Dich zur Herausgabe Deiner Seed Phrase verleitet, kann er unter Umständen denjenigen Ausgabepfad verwenden, für den diese Schlüssel genügen. Und wenn ein Anbieter eine «garantierte Sperre» verspricht, solltest Du prüfen, ob die Sperre wirklich auf Bitcoin-Konsensebene existiert oder bloss in dessen eigener Datenbank.

Praxisbeispiel: Ein Wiederherstellungspfad nach einer Wartefrist

Betrachten wir ein abstraktes Zwei-Pfade-Modell ohne konkrete ausführbare Skriptanweisung. Pfad A benötigt zwei autorisierte Schlüssel und ist sofort nutzbar. Pfad B benötigt einen separat verwahrten Wiederherstellungsschlüssel, wird aber erst nach einer definierten relativen Frist seit Bestätigung des UTXO gültig. Ein solches Konzept könnte bei Ausfall eines Signierers eine zusätzliche Option bieten.

Die technische Schwierigkeit liegt nicht im Satz «warte 144 Blöcke», sondern in den Randbedingungen. Was passiert, wenn der UTXO vor Ablauf der Frist über Pfad A ausgegeben wird? Dann existiert die betreffende Ausgabe nicht mehr; Pfad B kann sie nicht später nochmals verwenden. Was passiert, wenn das Wallet-Backup die Skriptbeschreibung nicht enthält? Dann kann der rechtmässige Besitzer trotz vorhandenem Schlüssel den richtigen Pfad eventuell nicht ohne Weiteres rekonstruieren. Und was passiert, wenn die Gebühren stark steigen? Dann muss der spätere Transaktionsweg genügend flexibel bleiben.

Deshalb sollten solche Konstruktionen nur mit überprüfter Software, dokumentierten Wiederherstellungsprozessen und fachkundiger Prüfung produktiv verwendet werden. Eine Testumgebung und kleine Beträge helfen, Fehler früh zu erkennen, ersetzen aber keine unabhängige Sicherheitsanalyse. Wer diese Technik bloss wegen eines Blogartikels auf grosse Vermögenswerte anwendet, übernimmt unnötige Risiken.

Gebühren, Mempool und die Zeit nach Ablauf der Sperre

Eine abgelaufene Timelock bedeutet nicht, dass die Transaktion sofort bestätigt wird. Nach Erfüllung aller Konsensbedingungen muss sie noch verbreitet und von einem Miner in einen Block aufgenommen werden. Dabei beeinflussen Transaktionsgrösse, Gebührenrate und Netzwerkauslastung die Wahrscheinlichkeit einer schnellen Bestätigung. Ein längerer oder komplexerer Skriptpfad kann andere Transaktionsgewichte verursachen als ein einfacher Standardpfad.

Wenn Du die Kosten nachvollziehen willst, lies den Beitrag über Bitcoin-Transaktionsgebühren, sat/vB und Mempool. Dort werden Gebühren und Methoden zur Beschleunigung erklärt. Beachte jedoch: Eine Ersatztransaktion oder eine Gebührenstrategie kann eine Konsenssperre nicht übergehen. Höhere Gebühren helfen nicht, eine vorzeitig ungültige Transaktion gültig zu machen.

Auch die Zahl der Bitcoin-Bestätigungen ist ein anderes Thema. Die Timelock bestimmt die frühestmögliche Gültigkeit. Bestätigungen beschreiben die Einbettung einer bereits aufgenommenen Transaktion in die Blockchain und die darauf aufbauende Arbeit. Diese beiden Zeitdimensionen solltest Du nicht verwechseln.

Bitcoin kaufen in der Schweiz: Wo Relai ins Bild passt

Eine normale Kauf-App muss keine Timelock unterstützen, damit Du Bitcoin erwerben kannst. Für die meisten Käuferinnen und Käufer ist zunächst entscheidend, dass Kaufbetrag, Kosten, Wallet-Kontrolle und Sicherung verständlich sind. Die fortgeschrittene Skriptgestaltung kommt erst später, wenn ein konkreter Anwendungsfall besteht. Ein normaler Bitcoin-Kauf über Relai richtet nicht automatisch eine CLTV- oder CSV-Sperre ein.

Relai ist eine mögliche Option für den Kauf von Bitcoin in der Schweiz. Laut der am 1. Oktober 2026 aktualisierten Relai-Anleitung kannst Du einen Einmalkauf oder Sparplan wählen und gegebenenfalls direkt an eine externe Wallet kaufen. Prüfe vor jeder Zahlung die angezeigten Konditionen, die Verfügbarkeit für Deinen Wohnsitz und die Empfangsadresse. Wenn Du später eine Timelock-Konstruktion verwenden möchtest, muss die externe Wallet diese technisch unterstützen; das ist keine Eigenschaft, die Du allein durch den Kauf erwirbst.

Werbung / Affiliate-Link: Wenn Du Relai ausprobieren möchtest, verwende in der App ausdrücklich den Code AUSWANDERNSCHWEIZ. Bei einer qualifizierten Nutzung kann unsere Website eine Provision erhalten. Die veröffentlichten Relai-Informationen vom 15. Juli 2026 beschreiben einen Empfehlungscode-Rabatt auf die reguläre Servicegebühr; Bedingungen und zusätzliche Kosten können sich ändern. Die konkrete Bestellübersicht ist massgeblich. Bitcoin kann erheblich an Wert verlieren, und bei Selbstverwahrung trägst Du Verantwortung für Deine Schlüssel.

Bitcoin mit Relai kaufen – Code AUSWANDERNSCHWEIZ nutzen

Die Grenzen von Timelocks im Alltag

Timelocks können eine wichtige Funktion erfüllen, doch sie lösen keine allgemeinen Probleme der Geldanlage. Sie schützen Dich nicht vor Kurseinbrüchen, fehlerhaften Preisannahmen oder einem unseriösen Verkäufer. Sie verhindern auch nicht, dass Du aus Versehen an eine falsche Adresse sendest. Für normale Überweisungen bleiben die Bitcoin-Adressformate und die sorgfältige Kontrolle der Zieladresse wesentlich.

Hinzu kommt die technische Wartbarkeit. Eine heute funktionierende Konstruktion muss in einigen Jahren noch nachvollziehbar sein. Dazu gehören Wallet-Kompatibilität, Software-Updates, Dokumentation und eine klare Trennung zwischen Schlüsselmaterial und öffentlichen Skriptinformationen. Bei sehr langen Fristen ist es besonders wichtig, keine Scheingenauigkeit über die spätere Kalenderzeit oder Gebührenlage zu suggerieren.

Wenn Du noch am Anfang stehst, lies zuerst Bitcoin einfach erklärt. Wer die UTXO-Grundlagen, Signaturen und Wallet-Sicherung versteht, kann Timelocks wesentlich besser einordnen. Der direkte Weg vom ersten Kauf zu einer komplexen Skriptkonstruktion ist dagegen selten die vernünftigste Reihenfolge.

Häufige Fragen zu Bitcoin-Timelocks

Kann ich meine Bitcoin bis zu einem bestimmten Datum sperren?

Mit einem passend konstruierten Bitcoin-Skript lässt sich ein Ausgabepfad an eine absolute Zeitbedingung binden. Das bedeutet aber nicht automatisch, dass sämtliche möglichen Ausgabepfade gesperrt sind. Bei nLockTime allein wird nur die konkrete Transaktion zeitlich beschränkt. Für einen tatsächlich erzwungenen Sperrpfad muss das gesamte Skript geprüft werden.

Ist CLTV dasselbe wie nLockTime?

Nein. nLockTime ist ein Feld der Transaktion. CLTV ist eine Skriptoperation, die einen absoluten Locktime-Wert mit Eigenschaften der ausgebenden Transaktion verknüpft. Beide können zusammenwirken, sind aber technisch verschiedene Mechanismen.

Was ist der Unterschied zwischen CLTV und CSV?

CLTV arbeitet mit einer absoluten Grenze, CSV mit einer relativen Altersbedingung. Die relative Variante ist besonders nützlich, wenn eine Frist erst mit der Bestätigung einer bestimmten Ausgabe beginnen soll. Beide verlangen eine korrekte Skript- und Transaktionsgestaltung.

Sind 144 Blöcke immer genau ein Tag?

Nein. Bei einer durchschnittlichen Zielzeit von zehn Minuten ergibt sich rechnerisch ein Tag. Tatsächliche Blockabstände sind zufällig und schwanken. Eine auf Blockhöhe beruhende Sperre ist deshalb nicht mit einer garantierten Uhrzeit gleichzusetzen.

Überweist Bitcoin nach Ablauf einer Timelock automatisch?

Nein. Die Frist öffnet nur einen zuvor definierten Ausgabepfad beziehungsweise erlaubt die Finalität einer vorbereiteten Transaktion. Eine gültige Transaktion muss weiterhin übertragen und bestätigt werden. Bei Bedarf muss jemand Gebühren und die passende Signatur bereitstellen.

Kann ich eine Timelock durch eine höhere Gebühr umgehen?

Nein. Gebühren beeinflussen die Priorisierung gültiger Transaktionen, nicht die Konsensgültigkeit. Solange eine relevante Sperrbedingung nicht erfüllt ist, kann eine höhere Gebührenrate sie nicht aufheben.

Kann ich eine Timelock mit einer Hardware Wallet verwenden?

Das hängt von Wallet-Software, unterstützten Skripttypen und Signiergerät ab. Die blosse Bezeichnung «Hardware Wallet» beweist keine CLTV- oder CSV-Unterstützung. Prüfe die konkrete Implementierung und die Wiederherstellbarkeit, bevor Du Beträge überweist.

Brauche ich Timelocks, um Bitcoin langfristig zu halten?

Nein. Für gewöhnliches langfristiges Halten sind eine verlässliche Wallet, sorgfältige Backups, passende Schlüsselverwaltung und ein realistisches Risikobewusstsein die Grundlagen. Timelocks sind ein Spezialwerkzeug für besondere Sicherheits- oder Vertragsanforderungen, keine Pflicht für Bitcoin-Besitzer.

Zusammenfassung: Was Du Dir merken solltest

Bitcoin-Timelocks machen zeitliche Bedingungen ohne zentrale Freigabestelle möglich. nLockTime begrenzt die frühestmögliche Aufnahme einer bestimmten Transaktion; CLTV kann einen absoluten Skriptpfad einschränken; CSV arbeitet mit relativen Bedingungen im Zusammenspiel mit BIP 68. BIP 113 liefert mit Median Time Past eine robustere Zeitreferenz für absolute zeitbasierte Sperren. Blockhöhe und Kalenderzeit bleiben dennoch unterschiedliche Grössen.

Der praktische Nutzen liegt in durchdachten Zahlungskanälen, Rückfallwegen und spezialisierten Sicherheitskonstruktionen. Die Risiken liegen in falschen Skripten, fehlenden Backups, ungeprüfter Wallet-Unterstützung und der Annahme, eine Sperre würde Geld automatisch verschieben oder vor jedem Angriff schützen. Wer Bitcoin sicher verwahren will, sollte zuerst Schlüssel, UTXOs und Transaktionsfinalität verstehen und Timelocks erst dann einsetzen, wenn ein klarer, fachlich geprüfter Bedarf besteht.

Quellen und weiterführende Literatur

Bitcoin Improvement Proposal 65: OP_CHECKLOCKTIMEVERIFY – Original-Spezifikation der absoluten Skript-Zeitsperre und ihrer Konsensbedingungen.

Bitcoin Improvement Proposal 68: Relative lock-time using consensus-enforced sequence numbers – Definition der relativen Finalitätsbedingungen und der nSequence-Semantik.

Bitcoin Improvement Proposal 112: CHECKSEQUENCEVERIFY – Spezifikation der relativen Skript-Zeitsperre und Beispiele aus Zahlungskanälen.

Bitcoin Improvement Proposal 113: Median time-past as endpoint for lock-time calculations – Erklärung der Zeitreferenz aus den vorherigen elf Blöcken.

Bitcoin Developer Guide: Transactions – Hintergrund zu Transaktionsaufbau, Inputs, Sequenzen und Locktime.

Relai Hilfe: Wie kaufe ich Bitcoin mit Relai? – Produktanleitung, Stand 1. Oktober 2026.

Relai Hilfe: Wie hoch sind die Gebühren? – Anbieterangaben, Stand 15. Juli 2026; vor Kauf aktuelle Bedingungen prüfen.

Hinweis: Dieser Artikel dient der technischen und allgemeinen finanziellen Bildung. Er ist keine persönliche Anlage-, Rechts- oder Sicherheitsberatung. Bitcoin ist volatil; fehlerhafte Schlüsselverwaltung oder Skripte können zum unwiederbringlichen Verlust führen.