Technik & KryptografieTechnology & CryptographyTecnología & CriptografíaTecnologia & Criptografia技術 & 暗号学技术 & 密码学التقنية & التشفير
Timelock und CLTV: Wie Bitcoin-Transaktionen zeitlich gesperrt werden könnenTimelocks and CLTV: How Bitcoin Transactions Can Be Locked in TimeTimelock y CLTV: Cómo se pueden bloquear temporalmente las transacciones de BitcoinTimelock e CLTV: Como as transações Bitcoin podem ser bloqueadas no tempoTimelockとCLTV：Bitcoin取引を時間的にロックする方法Timelock与CLTV：比特币交易如何实现时间锁定Timelock وCLTV: كيف يمكن تأمين معاملات Bitcoin زمنياً
Bewertung durch automatisierten Mehrquellen-Abgleich des KI-Redaktionsteams; anschließend menschlich freigegeben.Assessed via the AI newsroom's automated multi-source cross-check, then approved by a human.Evaluado mediante la verificación automatizada multifuente de la redacción de IA y aprobado por una persona.Avaliado pela verificação automatizada multifonte da redação de IA e aprovado por uma pessoa.AI編集部による自動マルチソース照合で評価し、人による承認を経ています。由AI编辑部的自动多源交叉核查评估，并经人工审核。جرى التقييم عبر التدقيق الآلي متعدد المصادر من غرفة أخبار الذكاء الاصطناعي، ثم اعتُمد بشريًا.
Timelocks sind kein Allheilmittel: Wer einen CLTV-gesperrten Output erstellt und anschließend den privaten Schlüssel verliert, kann die Coins auch nach Ablauf der Sperre nicht mehr ausgeben – die zeitliche Bedingung schützt in diesem Fall niemanden. Ebenso wenig erwähnt der Artikel, dass falsch kombinierte nLockTime- und CLTV-Werte (z. B. gemischte Block-/Timestamp-Einheiten) zu dauerhaft unspendable UTXOs führen können. BIP 345 (OP_VAULT) ist zudem kein etabliertes Werkzeug, sondern ein Vorschlag ohne Aktivierungspfad – seine Nennung als Beleg für die Praxistauglichkeit von Timelock-Vaults ist verfrüht. Nutzerinnen und Nutzer, die auf Basis dieses Artikels eigene Erbschafts-Setups konstruieren, könnten durch die Vereinfachungen in echte Sicherheitslücken laufen.Timelocks are not a silver bullet: anyone who creates a CLTV-locked output and subsequently loses their private key cannot spend the coins even after the lock expires – the time condition protects no one in that scenario. The article also omits that incorrectly combined nLockTime and CLTV values (e.g. mixing block-height and timestamp units) can produce permanently unspendable UTXOs. BIP 345 (OP_VAULT) is furthermore a proposal without an activation path, not an established tool – citing it as evidence of practical vault viability is premature. Readers who attempt to build their own inheritance setups on the basis of this article's simplifications may inadvertently introduce serious security gaps.Los timelocks no son una solución mágica: quien cree un output bloqueado por CLTV y posteriormente pierda su clave privada no podrá gastar las monedas ni siquiera tras el vencimiento del bloqueo — en ese escenario, la condición temporal no protege a nadie. El artículo tampoco menciona que la combinación incorrecta de valores nLockTime y CLTV (por ejemplo, mezclar unidades de altura de bloque y de marca de tiempo) puede generar UTXOs permanentemente imposibles de gastar. Además, BIP 345 (OP_VAULT) es una propuesta sin ruta de activación, no una herramienta consolidada — citarla como evidencia de la viabilidad práctica de los vaults con timelock es prematuro. Los lectores que intenten construir sus propios esquemas de herencia basándose en las simplificaciones de este artículo podrían introducir inadvertidamente graves brechas de seguridad.Os timelocks não são uma solução milagrosa: quem cria um output bloqueado por CLTV e posteriormente perde a chave privada não conseguirá gastar as moedas mesmo após o término do bloqueio — nesse cenário, a condição temporal não protege ninguém. O artigo também omite que a combinação incorreta de valores nLockTime e CLTV (por exemplo, misturar unidades de altura de bloco e de timestamp) pode gerar UTXOs permanentemente impossíveis de gastar. Além disso, BIP 345 (OP_VAULT) é uma proposta sem caminho de ativação, não uma ferramenta estabelecida — citá-la como prova da viabilidade prática de vaults com timelock é precipitado. Leitores que tentarem construir seus próprios esquemas de herança com base nas simplificações deste artigo podem inadvertidamente introduzir graves falhas de segurança.Timelockは万能薬ではありません。CLTVでロックされたアウトプットを作成した後に秘密鍵を紛失した場合、ロックが解除された後でもコインを使用できなくなります。このシナリオでは、時間条件は誰も守ってくれません。また、nLockTimeとCLTVの値を誤って組み合わせた場合（例：ブロック高とタイムスタンプの単位を混在させた場合）、永久に使用不能なUTXOが生成される可能性があることも、記事では触れられていません。さらに、BIP 345（OP_VAULT）は有効化の経路がない提案であり、確立されたツールではありません。これをtimelock vaultの実用性の根拠として挙げるのは時期尚早です。この記事の簡略化をもとに独自の相続設定を構築しようとする読者は、意図せず深刻なセキュリティ上の欠陥を生み出してしまう可能性があります。时间锁并非万能良药：任何人创建了CLTV锁定的输出后若丢失私钥，即使锁定期满也无法花费这些币——在这种情况下，时间条件无法保护任何人。文章还遗漏了一点：错误组合的nLockTime与CLTV值（例如混用区块高度与时间戳单位）可能导致UTXO永久无法花费。此外，BIP 345（OP_VAULT）是一项尚无激活路径的提案，而非成熟的工具——将其作为时间锁保险库实用性的佐证为时尚早。读者若基于本文的简化内容尝试构建自己的继承方案，可能会在不知不觉中引入严重的安全漏洞。إن أقفال الوقت (Timelocks) ليست حلاً سحرياً شاملاً: فمن يُنشئ مخرجاً مقفلاً بـCLTV ثم يفقد مفتاحه الخاص لاحقاً، لن يتمكن من إنفاق العملات حتى بعد انتهاء مدة القفل — إذ لا تحمي الشرطُ الزمنية أحداً في هذه الحالة. كما يغفل المقال عن الإشارة إلى أن الجمع الخاطئ بين قيم nLockTime وCLTV (مثل خلط وحدات ارتفاع الكتلة والطوابع الزمنية) قد يُفضي إلى UTXOs غير قابلة للإنفاق بصفة دائمة. فضلاً عن ذلك، فإن BIP 345 (OP_VAULT) مجرد اقتراح لا يمتلك مساراً للتفعيل، وليس أداةً راسخة — ومن ثَمَّ يُعدّ الاستشهاد به دليلاً على الجدوى العملية لخزائن الوقت أمراً سابقاً لأوانه. والقراء الذين يحاولون بناء إعدادات الإرث الخاصة بهم استناداً إلى التبسيطات الواردة في هذا المقال قد يُدخلون ثغرات أمنية خطيرة دون أن يدركوا ذلك.
Video zum ArtikelVideo for this articleVídeo del artículoVídeo do artigo記事の動画本文视频فيديو المقال
Bitcoins Skriptsprache ist bewusst eingeschränkt – und genau diese Einschränkung macht jeden einzelnen Mechanismus umso wertvoller. Timelocks gehören zu den mächtigsten, aber am häufigsten unterschätzten Werkzeugen des Protokolls. Sie erlauben es, Transaktionen oder einzelne Outputs so zu sperren, dass sie erst ab einem definierten Zeitpunkt gültig werden. Das Ergebnis: zeitgesteuerte Smart Contracts auf einer Blockchain, die keinen globalen Zustand und keine Turing-Vollständigkeit benötigt.
Die vier Mechanismen im Überblick
Bitcoin kennt vier distinkte Timelock-Mechanismen, die sich nach zwei Dimensionen unterscheiden: nach Ebene (Transaktion vs. Script) und nach Typ (absolut vs. relativ). Das folgende Schema ist das didaktische Herzstück dieses Artikels:
- nLockTime – Transaktionsebene, absolut
- nSequence (BIP 68) – Input-Ebene, relativ
- CHECKLOCKTIMEVERIFY / CLTV (BIP 65) – Script-Ebene, absolut
- CHECKSEQUENCEVERIFY / CSV (BIP 112) – Script-Ebene, relativ
nLockTime: Der älteste Timelock
Das nLockTime-Feld ist 4 Byte groß und seit dem Genesis-Block Teil jeder Bitcoin-Transaktion. Ein Wert unter 500.000.000 wird als Blockhöhe interpretiert; ein Wert ab 500.000.000 als Unix-Timestamp. Eine Transaktion mit gesetztem nLockTime darf von keinem Miner vor Erreichen dieses Zeitpunkts in einen Block aufgenommen werden.
Der entscheidende Schwachpunkt: nLockTime ist eine Eigenschaft der ausgebenden Transaktion, nicht des UTXOs selbst. Niemand hindert den Empfänger eines Outputs daran, eine neue Transaktion ohne nLockTime zu erstellen – der Lock ist nicht UTXO-inhärent. Genau hier setzen CLTV und CSV an.
Median Time Past (MTP): Bitcoin-Nodes prüfen zeitbasierte Locks nicht gegen die aktuelle Systemzeit, sondern gegen den Median der Timestamps der letzten 11 Blöcke. Das verhindert Manipulation durch einzelne Miner, die ihre Blockzeit künstlich vorstellen könnten.
CHECKLOCKTIMEVERIFY (CLTV): Absoluter Lock auf Script-Ebene
BIP 65 führte den Opcode OP_CHECKLOCKTIMEVERIFY ein, aktiviert per Soft Fork am 22. November 2015 in Block 388.381. CLTV ist ein Script-Opcode: Er wird direkt in das Locking-Script eines UTXOs eingebettet und prüft zur Zeit der Ausgabe, ob das nLockTime-Feld der ausgebenden Transaktion mindestens so groß ist wie der im Script hinterlegte Wert. Der Output selbst trägt damit den Zeitlock – er ist UTXO-inhärent und kann von niemandem umgangen werden.
Beispielhafter Ablauf: Alice hinterlegt Coins in einem CLTV-Script, das Blockhöhe 900.000 als Grenze definiert. Kein Miner der Welt kann diese Coins vor Block 900.000 in einer gültigen Transaktion ausgeben – das Script würde fehlschlagen.
nSequence und CHECKSEQUENCEVERIFY (CSV): Relative Timelocks
Relative Timelocks messen Zeit nicht ab einem fixen Punkt, sondern ab der Bestätigung des finanzierten UTXOs selbst. BIP 68 redefinierte das 32-Bit-Feld nSequence pro Input: Bit 31 ist das Disable-Flag, Bit 22 schaltet zwischen Blöcken (0) und 512-Sekunden-Intervallen (1) um, die Bits 0–15 enthalten den eigentlichen Wert (maximal 65.535 Blöcke, entspricht ca. 455 Tagen).
BIP 112 ergänzte den Opcode OP_CHECKSEQUENCEVERIFY, der relative Timelocks auf Script-Ebene durchsetzt – analog zu CLTV, aber eben relativ. Beide BIPs wurden am 4. Juli 2016 in Block 419.328 aktiviert.
Anwendungsfall Lightning Network
Ohne CSV wäre das Lightning Network in seiner heutigen Form nicht sicher konstruierbar. Zwei Mechanismen sind zentral:
- HTLC (Hash Time-Locked Contracts): Kombinieren einen Hashlock (Zahlung nur gegen Preimage) mit einem Timelock (Rückforderung nach Ablauf). Sie ermöglichen atomares Routing über mehrere Hops.
- to_self_delay / Revocation Key: In Commitment-Transaktionen schützt ein CSV-Delay den ehrlichen Teilnehmer: Versucht ein Gegenüber, einen alten Channel-State zu broadcasten, hat der Betrogene Zeit, mit dem Revocation Key zu reagieren und alle Mittel zu beanspruchen. Der CLTV-Delta-Wert pro Hop variiert je nach Implementierung und Routing-Tiefe; typische Werte liegen Stand 2026 im Bereich von etwa 40 bis 144 Blöcken, ohne dass der BOLT-Standard einen festen Mindestwert vorschreibt.
Anwendungsfall Vaults und Erbschaft
CLTV und CSV ermöglichen nicht-verwahrende Erbschafts- und Notfall-Setups. Ein typisches Beispiel ist der Dead-Man's-Switch: Eine Transaktion, die Coins an Erben weitergibt, ist mit CLTV auf einen zukünftigen Zeitpunkt gesperrt. Solange der Eigentümer lebt, erneuert er die Sperre regelmäßig; bleibt die Erneuerung aus, wird die Transaktion gültig. Aktive Forschungsprojekte wie OP_VAULT (BIP 345) bauen auf diesen Primitiven auf, um noch robustere Vault-Konstruktionen zu ermöglichen.
Sicherheitsprimitive, kein Gimmick: Timelocks sind keine optionale Komfortfunktion. Sie sind kryptografisch erzwungene Zeitbedingungen, die ohne Vertrauen in Dritte auskommen – ein fundamentaler Baustein für selbstverwaltete Bitcoin-Sicherheit.
Zusammenfassung
Die vier Timelock-Mechanismen bilden eine aufeinander aufbauende Schicht: nLockTime und nSequence operieren auf Protokollebene und setzen Rahmenbedingungen; CLTV und CSV machen diese Bedingungen UTXO-inhärent und damit unumgehbar. Wer Bitcoin-Protokoll, Lightning-Sicherheit oder selbstverwaltete Verwahrungsstrategien verstehen will, kommt an Timelocks nicht vorbei.
Weiterführend
Bitcoin's scripting language is deliberately limited – and it is precisely this limitation that makes each individual mechanism all the more valuable. Timelocks are among the most powerful, yet most underrated tools in the protocol. They allow transactions or individual outputs to be locked so that they only become valid from a defined point in time. The result: time-controlled smart contracts on a blockchain that requires neither global state nor Turing-completeness.
The Four Mechanisms at a Glance
Bitcoin has four distinct timelock mechanisms, differentiated along two dimensions: level (transaction vs. script) and type (absolute vs. relative). This matrix is the didactic centrepiece of this article:
- nLockTime – transaction level, absolute
- nSequence (BIP 68) – input level, relative
- CHECKLOCKTIMEVERIFY / CLTV (BIP 65) – script level, absolute
- CHECKSEQUENCEVERIFY / CSV (BIP 112) – script level, relative
nLockTime: The Oldest Timelock
The nLockTime field is 4 bytes in size and has been part of every Bitcoin transaction since the genesis block. A value below 500,000,000 is interpreted as a block height; a value of 500,000,000 or above is treated as a Unix timestamp. A transaction with nLockTime set cannot be included in a block by any miner before that point in time is reached.
The critical weakness: nLockTime is a property of the spending transaction, not of the UTXO itself. Nothing prevents the recipient of an output from creating a new transaction without nLockTime – the lock is not UTXO-inherent. This is precisely where CLTV and CSV step in.
Median Time Past (MTP): Bitcoin nodes do not check time-based locks against the current system time, but against the median of the timestamps of the last 11 blocks. This prevents manipulation by individual miners who might artificially advance their block timestamp.
CHECKLOCKTIMEVERIFY (CLTV): Absolute Lock at Script Level
BIP 65 introduced the opcode OP_CHECKLOCKTIMEVERIFY, activated via soft fork on 22 November 2015 at block 388,381. CLTV is a script opcode: it is embedded directly into the locking script of a UTXO and, at spending time, verifies that the nLockTime field of the spending transaction is at least as large as the value encoded in the script. The output itself carries the time lock – it is UTXO-inherent and cannot be circumvented by anyone.
Example flow: Alice deposits coins into a CLTV script that defines block height 900,000 as the threshold. No miner in the world can spend these coins in a valid transaction before block 900,000 – the script would simply fail.
nSequence and CHECKSEQUENCEVERIFY (CSV): Relative Timelocks
Relative timelocks measure time not from a fixed point, but from the confirmation of the funded UTXO itself. BIP 68 redefined the 32-bit nSequence field per input: bit 31 is the disable flag, bit 22 toggles between blocks (0) and 512-second intervals (1), and bits 0–15 hold the actual value (maximum 65,535 blocks, roughly 455 days).
BIP 112 added the opcode OP_CHECKSEQUENCEVERIFY, which enforces relative timelocks at script level – analogous to CLTV, but relative. Both BIPs were activated on 4 July 2016 at block 419,328.
Use Case: Lightning Network
Without CSV, the Lightning Network as it exists today could not be built securely. Two mechanisms are central:
- HTLCs (Hash Time-Locked Contracts): Combine a hashlock (payment only against preimage) with a timelock (reclaim after expiry). They enable atomic routing across multiple hops.
- to_self_delay / Revocation Key: In commitment transactions, a CSV delay protects the honest participant: if a counterparty attempts to broadcast an old channel state, the defrauded party has time to respond with the revocation key and claim all funds. The CLTV delta value per hop varies by implementation and routing depth; typical values as of 2026 are roughly 40 to 144 blocks, without the BOLT standard prescribing a fixed minimum.
Use Case: Vaults and Inheritance
CLTV and CSV enable non-custodial inheritance and emergency setups. A classic example is the dead man's switch: a transaction transferring coins to heirs is locked with CLTV to a future point in time. As long as the owner is alive, they periodically renew the lock; if renewal stops, the transaction becomes valid. Active research projects such as OP_VAULT (BIP 345) build on these primitives to enable even more robust vault constructions.
Security primitive, not a gimmick: Timelocks are not an optional convenience feature. They are cryptographically enforced time conditions that require no trust in third parties – a fundamental building block for self-sovereign Bitcoin security.
Summary
The four timelock mechanisms form a layered architecture: nLockTime and nSequence operate at the protocol level and set the framework; CLTV and CSV make these conditions UTXO-inherent and thus inescapable. Anyone seeking to understand Bitcoin's protocol, Lightning security, or self-custodial strategies cannot afford to overlook timelocks.
Related
El lenguaje de scripting de Bitcoin es deliberadamente limitado, y es precisamente esta limitación lo que hace que cada mecanismo individual sea aún más valioso. Los timelocks se encuentran entre las herramientas más potentes y, a la vez, más subestimadas del protocolo. Permiten bloquear transacciones o outputs individuales de modo que solo sean válidos a partir de un momento definido. El resultado: contratos inteligentes controlados por tiempo en una blockchain que no requiere estado global ni completitud de Turing.
Los cuatro mecanismos de un vistazo
Bitcoin cuenta con cuatro mecanismos de timelock diferenciados según dos dimensiones: nivel (transacción vs. script) y tipo (absoluto vs. relativo). El siguiente esquema es el núcleo didáctico de este artículo:
- nLockTime – nivel de transacción, absoluto
- nSequence (BIP 68) – nivel de input, relativo
- CHECKLOCKTIMEVERIFY / CLTV (BIP 65) – nivel de script, absoluto
- CHECKSEQUENCEVERIFY / CSV (BIP 112) – nivel de script, relativo
nLockTime: El timelock más antiguo
El campo nLockTime ocupa 4 bytes y forma parte de cada transacción Bitcoin desde el bloque génesis. Un valor inferior a 500.000.000 se interpreta como altura de bloque; un valor igual o superior a 500.000.000, como Unix timestamp. Ningún minero puede incluir en un bloque una transacción con nLockTime establecido antes de que se alcance ese momento.
La debilidad crítica: nLockTime es una propiedad de la transacción gastadora, no del UTXO en sí. Nada impide que el receptor de un output cree una nueva transacción sin nLockTime — el bloqueo no es inherente al UTXO. Exactamente aquí es donde entran en juego CLTV y CSV.
Median Time Past (MTP): Los nodos Bitcoin no verifican los bloqueos temporales contra la hora actual del sistema, sino contra la mediana de los timestamps de los últimos 11 bloques. Esto evita la manipulación por parte de mineros individuales que pudieran adelantar artificialmente la marca de tiempo de su bloque.
CHECKLOCKTIMEVERIFY (CLTV): Bloqueo absoluto a nivel de script
BIP 65 introdujo el opcode OP_CHECKLOCKTIMEVERIFY, activado mediante soft fork el 22 de noviembre de 2015 en el bloque 388.381. CLTV es un opcode de script: se incrusta directamente en el locking script de un UTXO y, en el momento del gasto, verifica que el campo nLockTime de la transacción gastadora sea al menos tan grande como el valor codificado en el script. El propio output lleva el timelock — es inherente al UTXO y nadie puede eludirlo.
Ejemplo práctico: Alice deposita monedas en un script CLTV que define la altura de bloque 900.000 como límite. Ningún minero del mundo puede gastar esas monedas en una transacción válida antes del bloque 900.000 — el script simplemente fallaría.
nSequence y CHECKSEQUENCEVERIFY (CSV): Timelocks relativos
Los timelocks relativos no miden el tiempo desde un punto fijo, sino desde la confirmación del propio UTXO financiado. BIP 68 redefinió el campo de 32 bits nSequence por input: el bit 31 es el flag de desactivación, el bit 22 alterna entre bloques (0) e intervalos de 512 segundos (1), y los bits 0–15 contienen el valor real (máximo 65.535 bloques, equivalente a aproximadamente 455 días).
BIP 112 añadió el opcode OP_CHECKSEQUENCEVERIFY, que aplica timelocks relativos a nivel de script — análogo a CLTV, pero de forma relativa. Ambos BIPs fueron activados el 4 de julio de 2016 en el bloque 419.328.
Caso de uso: Lightning Network
Sin CSV, la Lightning Network tal como existe hoy no podría construirse de forma segura. Dos mecanismos son fundamentales:
- HTLCs (Hash Time-Locked Contracts): Combinan un hashlock (pago solo contra preimage) con un timelock (recuperación tras el vencimiento). Permiten el enrutamiento atómico a través de múltiples saltos.
- to_self_delay / Revocation Key: En las transacciones de compromiso, un retraso CSV protege al participante honesto: si una contraparte intenta difundir un estado antiguo del canal, la parte perjudicada tiene tiempo de responder con la clave de revocación y reclamar todos los fondos. El valor del delta CLTV por salto varía según la implementación y la profundidad de enrutamiento; los valores típicos a fecha de 2026 se sitúan en torno a 40–144 bloques, sin que el estándar BOLT prescriba un mínimo fijo.
Caso de uso: Vaults y herencias
CLTV y CSV permiten configuraciones de herencia y emergencia sin custodia. Un ejemplo clásico es el dead man's switch: una transacción que transfiere monedas a los herederos queda bloqueada con CLTV hasta un momento futuro. Mientras el propietario vive, renueva el bloqueo periódicamente; si la renovación cesa, la transacción se vuelve válida. Proyectos de investigación activos como OP_VAULT (BIP 345) se apoyan en estos primitivos para habilitar construcciones de vault aún más robustas.
Primitivo de seguridad, no un truco: Los timelocks no son una función de comodidad opcional. Son condiciones temporales impuestas criptográficamente que no requieren confianza en terceros — un componente fundamental para la seguridad Bitcoin autogestionada.
Resumen
Los cuatro mecanismos de timelock forman una arquitectura en capas: nLockTime y nSequence operan a nivel de protocolo y establecen el marco general; CLTV y CSV hacen que estas condiciones sean inherentes al UTXO y, por tanto, ineludibles. Quien quiera comprender el protocolo de Bitcoin, la seguridad de Lightning o las estrategias de custodia propia no puede ignorar los timelocks.
Más información
A linguagem de script do Bitcoin é deliberadamente limitada – e é precisamente essa limitação que torna cada mecanismo individual ainda mais valioso. Os timelocks estão entre as ferramentas mais poderosas, porém mais subestimadas do protocolo. Eles permitem bloquear transações ou outputs individuais de modo que só se tornem válidos a partir de um momento definido. O resultado: smart contracts controlados por tempo numa blockchain que não precisa de estado global nem de completude de Turing.
Os Quatro Mecanismos em Resumo
O Bitcoin possui quatro mecanismos de timelock distintos, diferenciados por duas dimensões: nível (transação vs. script) e tipo (absoluto vs. relativo). O esquema a seguir é o ponto didático central deste artigo:
- nLockTime – nível de transação, absoluto
- nSequence (BIP 68) – nível de input, relativo
- CHECKLOCKTIMEVERIFY / CLTV (BIP 65) – nível de script, absoluto
- CHECKSEQUENCEVERIFY / CSV (BIP 112) – nível de script, relativo
nLockTime: O Timelock Mais Antigo
O campo nLockTime ocupa 4 bytes e faz parte de toda transação Bitcoin desde o bloco genesis. Um valor abaixo de 500.000.000 é interpretado como altura de bloco; um valor a partir de 500.000.000 é tratado como Unix timestamp. Uma transação com nLockTime definido não pode ser incluída em um bloco por nenhum minerador antes que esse ponto no tempo seja atingido.
A fraqueza crítica: nLockTime é uma propriedade da transação gastadora, não do próprio UTXO. Nada impede o destinatário de um output de criar uma nova transação sem nLockTime – o bloqueio não é inerente ao UTXO. É exatamente aqui que CLTV e CSV entram em cena.
Median Time Past (MTP): Os nós Bitcoin não verificam bloqueios baseados em tempo contra a hora atual do sistema, mas contra a mediana dos timestamps dos últimos 11 blocos. Isso impede a manipulação por mineradores individuais que poderiam adiantar artificialmente o timestamp do seu bloco.
CHECKLOCKTIMEVERIFY (CLTV): Bloqueio Absoluto no Nível de Script
O BIP 65 introduziu o opcode OP_CHECKLOCKTIMEVERIFY, ativado via soft fork em 22 de novembro de 2015 no bloco 388.381. O CLTV é um opcode de script: é embutido diretamente no locking script de um UTXO e, no momento do gasto, verifica se o campo nLockTime da transação gastadora é pelo menos tão grande quanto o valor definido no script. O próprio output carrega o bloqueio temporal – ele é inerente ao UTXO e não pode ser contornado por ninguém.
Exemplo de fluxo: Alice deposita moedas num script CLTV que define a altura de bloco 900.000 como limite. Nenhum minerador no mundo pode gastar essas moedas em uma transação válida antes do bloco 900.000 – o script simplesmente falharia.
nSequence e CHECKSEQUENCEVERIFY (CSV): Timelocks Relativos
Os timelocks relativos não medem o tempo a partir de um ponto fixo, mas a partir da confirmação do próprio UTXO financiado. O BIP 68 redefiniu o campo de 32 bits nSequence por input: o bit 31 é o flag de desativação, o bit 22 alterna entre blocos (0) e intervalos de 512 segundos (1), e os bits 0–15 contêm o valor efetivo (máximo de 65.535 blocos, equivalente a aproximadamente 455 dias).
O BIP 112 adicionou o opcode OP_CHECKSEQUENCEVERIFY, que impõe timelocks relativos no nível de script – análogo ao CLTV, mas de forma relativa. Ambos os BIPs foram ativados em 4 de julho de 2016 no bloco 419.328.
Caso de Uso: Lightning Network
Sem o CSV, a Lightning Network na sua forma atual não poderia ser construída de forma segura. Dois mecanismos são centrais:
- HTLCs (Hash Time-Locked Contracts): Combinam um hashlock (pagamento apenas contra preimage) com um timelock (reembolso após expiração). Eles permitem roteamento atômico por múltiplos hops.
- to_self_delay / Revocation Key: Nas transações de compromisso, um atraso CSV protege o participante honesto: se uma contraparte tentar transmitir um estado antigo do canal, a parte lesada tem tempo para reagir com a chave de revogação e reivindicar todos os fundos. O valor do delta CLTV por hop varia conforme a implementação e a profundidade de roteamento; valores típicos em 2026 ficam na faixa de aproximadamente 40 a 144 blocos, sem que o padrão BOLT prescreva um mínimo fixo.
Caso de Uso: Vaults e Herança
CLTV e CSV possibilitam configurações de herança e emergência sem custódia. Um exemplo clássico é o dead man's switch: uma transação que transfere moedas para herdeiros é bloqueada com CLTV para um momento futuro. Enquanto o proprietário estiver vivo, ele renova periodicamente o bloqueio; se a renovação cessar, a transação se torna válida. Projetos de pesquisa ativos como OP_VAULT (BIP 345) constroem sobre esses primitivos para viabilizar construções de vault ainda mais robustas.
Primitivo de segurança, não um gimmick: Os timelocks não são uma funcionalidade de conveniência opcional. São condições temporais impostas criptograficamente que dispensam confiança em terceiros – um bloco fundamental para a segurança soberana do Bitcoin.
Resumo
Os quatro mecanismos de timelock formam uma arquitetura em camadas: nLockTime e nSequence operam no nível do protocolo e definem as condições gerais; CLTV e CSV tornam essas condições inerentes ao UTXO e, portanto, incontornáveis. Quem quiser compreender o protocolo Bitcoin, a segurança da Lightning ou estratégias de autocustódia não pode ignorar os timelocks.
Mais informação
Bitcoinのスクリプト言語は意図的に制限されている——そしてその制限こそが、個々のメカニズムをより一層価値あるものにしている。Timelockはプロトコル内で最も強力でありながら、最も過小評価されているツールのひとつだ。Timelockを使うと、トランザクションや個々のアウトプットを、指定した時点以降にのみ有効となるようにロックできる。その結果、グローバルな状態もチューリング完全性も必要としないブロックチェーン上で、時間制御型スマートコントラクトが実現する。
4つのメカニズム：概要
Bitcoinには4つの異なるTimelockメカニズムがあり、2つの軸で区別される：レベル（トランザクション vs. スクリプト）とタイプ（絶対 vs. 相対）だ。以下の分類は本記事の解説の核心をなす：
- nLockTime – トランザクションレベル、絶対
- nSequence (BIP 68) – インプットレベル、相対
- CHECKLOCKTIMEVERIFY / CLTV (BIP 65) – スクリプトレベル、絶対
- CHECKSEQUENCEVERIFY / CSV (BIP 112) – スクリプトレベル、相対
nLockTime：最も古いTimelock
nLockTimeフィールドは4バイトのサイズを持ち、ジェネシスブロック以来すべてのBitcoinトランザクションに含まれている。500,000,000未満の値はブロック高として解釈され、500,000,000以上の値はUnixタイムスタンプとして扱われる。nLockTimeが設定されたトランザクションは、その時点に達するまでいかなるマイナーもブロックに取り込むことができない。
決定的な弱点：nLockTimeは送信トランザクションのプロパティであり、UTXO自体のプロパティではない。アウトプットの受取人が、nLockTimeを持たない新しいトランザクションを作成することを誰も妨げられない——このロックはUTXO固有ではないのだ。まさにここでCLTVとCSVが機能する。
Median Time Past (MTP)：Bitcoinノードは時間ベースのロックを現在のシステム時刻に対して検証するのではなく、直近11ブロックのタイムスタンプの中央値に対して検証する。これにより、個々のマイナーがブロックタイムスタンプを人為的に進めることによる操作を防ぐ。
CHECKLOCKTIMEVERIFY (CLTV)：スクリプトレベルの絶対ロック
BIP 65はオペコードOP_CHECKLOCKTIMEVERIFYを導入し、2015年11月22日にブロック388,381でソフトフォークとして有効化された。CLTVはスクリプトオペコードであり、UTXOのロッキングスクリプトに直接埋め込まれる。支出時に、支出トランザクションのnLockTimeフィールドがスクリプトに記述された値以上であることを検証する。アウトプット自体がタイムロックを持つことになり、UTXO固有であるため誰にも回避できない。
具体的な流れ：Aliceがブロック高900,000を閾値として定義したCLTVスクリプトにコインを預けたとする。世界中のいかなるマイナーも、ブロック900,000より前にこのコインを有効なトランザクションで使うことはできない——スクリプトが失敗するためだ。
nSequenceとCHECKSEQUENCEVERIFY (CSV)：相対Timelock
相対Timelockは時間を固定の起点から測るのではなく、資金を受け取ったUTXO自体の承認時点から測る。BIP 68はインプットごとの32ビットフィールドnSequenceを再定義した：ビット31はDisableフラグ、ビット22はブロック単位（0）と512秒間隔（1）の切り替え、ビット0〜15が実際の値（最大65,535ブロック、約455日相当）を保持する。
BIP 112はオペコードOP_CHECKSEQUENCEVERIFYを追加し、スクリプトレベルで相対Timelockを強制する——CLTVと同様だが、相対的である点が異なる。両BIPは2016年7月4日にブロック419,328で有効化された。
ユースケース：Lightning Network
CSVなしでは、現在の形のLightning Networkを安全に構築することはできない。2つのメカニズムが中心的な役割を果たす：
- HTLC（Hash Time-Locked Contracts）：ハッシュロック（プリイメージと引き換えにのみ支払い）とTimelock（期限切れ後に返還）を組み合わせる。複数のホップをまたいだアトミックルーティングを可能にする。
- to_self_delay / Revocation Key：コミットメントトランザクションにおいて、CSVディレイが誠実な参加者を保護する：相手方が古いチャネル状態をブロードキャストしようとした場合、被害を受けた側はRevocation Keyで応答してすべての資金を請求する時間的余裕を持つ。ホップごとのCLTV deltaの値は実装やルーティングの深さによって異なる。2026年時点の典型的な値はおよそ40〜144ブロックの範囲であり、BOLT標準が固定の最小値を規定しているわけではない。
ユースケース：Vaultと相続
CLTVとCSVは、非カストディアル型の相続や緊急用セットアップを可能にする。典型的な例がデッドマンズスイッチだ：相続人にコインを移転するトランザクションが、CLTVで将来の時点にロックされる。所有者が生きている間は定期的にロックを更新し、更新が途絶えると、そのトランザクションが有効になる。OP_VAULT（BIP 345）などの活発な研究プロジェクトは、これらのプリミティブを基にさらに堅牢なVault構成の実現を目指している。
セキュリティのプリミティブであり、単なるギミックではない：Timelockはオプションの利便機能ではない。第三者への信頼を必要とせず、暗号的に強制された時間条件——自己管理型Bitcoinセキュリティの根本的な構成要素だ。
まとめ
4つのTimelockメカニズムは、積み重なる層構造をなしている：nLockTimeとnSequenceはプロトコルレベルで動作し、枠組みを設定する。CLTVとCSVはこれらの条件をUTXO固有のものにし、回避不可能にする。Bitcoinのプロトコル、Lightningのセキュリティ、あるいは自己管理型の保管戦略を理解したい人には、Timelockの理解が不可欠だ。
関連情報
Bitcoin 的脚本语言被刻意限制——而正是这种限制，使得每一种机制都愈发弥足珍贵。时间锁（Timelock）是协议中最强大却最容易被低估的工具之一。它们能够锁定交易或单个输出，使其只有在某个特定时间点之后才生效。由此实现了在无需全局状态、无需图灵完备性的区块链上运行的时间控制型智能合约。
四种机制概览
Bitcoin 拥有四种不同的时间锁机制，可从两个维度加以区分：层级（交易层 vs. 脚本层）与类型（绝对 vs. 相对）。以下分类是本文的核心框架：
- nLockTime – 交易层，绝对
- nSequence（BIP 68）– 输入层，相对
- CHECKLOCKTIMEVERIFY / CLTV（BIP 65）– 脚本层，绝对
- CHECKSEQUENCEVERIFY / CSV（BIP 112）– 脚本层，相对
nLockTime：最古老的时间锁
nLockTime 字段长 4 字节，自创世区块起便是每笔 Bitcoin 交易的组成部分。小于 500,000,000 的值被解释为区块高度；大于或等于 500,000,000 的值则被视为 Unix 时间戳。设置了 nLockTime 的交易，在该时间点到来之前，任何矿工都无法将其打包进区块。
关键弱点在于：nLockTime 是花费交易的属性，而非 UTXO 本身的属性。没有任何机制能阻止输出的接收方创建一笔不含 nLockTime 的新交易——这个锁并不内嵌于 UTXO 之中。CLTV 和 CSV 正是为此而生。
中位时间过去（Median Time Past，MTP）：Bitcoin 节点在验证基于时间的锁时，并不使用当前系统时间，而是使用最近 11 个区块时间戳的中位数。这可以防止个别矿工人为提前其区块时间戳而造成的操纵。
CHECKLOCKTIMEVERIFY（CLTV）：脚本层绝对锁
BIP 65 引入了操作码 OP_CHECKLOCKTIMEVERIFY，于 2015 年 11 月 22 日通过软分叉在区块 388,381 处激活。CLTV 是一种脚本操作码：它直接嵌入到 UTXO 的锁定脚本中，并在花费时验证花费交易的 nLockTime 字段是否不小于脚本中编码的值。输出本身因此携带了时间锁——它内嵌于 UTXO，任何人都无法绕过。
示例流程：Alice 将币存入一个 CLTV 脚本，该脚本将区块高度 900,000 设为解锁条件。全世界没有任何矿工能在区块 900,000 之前将这些币包含在有效交易中——脚本将直接失败。
nSequence 与 CHECKSEQUENCEVERIFY（CSV）：相对时间锁
相对时间锁衡量的不是从某个固定时间点起算的时间，而是从被花费 UTXO 本身得到确认起算的时间。BIP 68 重新定义了每个输入的 32 位 nSequence 字段：第 31 位为禁用标志，第 22 位在区块（0）和 512 秒间隔（1）之间切换，第 0–15 位存储实际值（最大 65,535 个区块，约合 455 天）。
BIP 112 新增了操作码 OP_CHECKSEQUENCEVERIFY，在脚本层强制执行相对时间锁——与 CLTV 类似，但采用相对方式。两个 BIP 均于 2016 年 7 月 4 日在区块 419,328 处激活。
应用场景：Lightning Network
没有 CSV，Lightning Network 就无法以当今的形式安全构建。其中两种机制至关重要：
- HTLC（哈希时间锁合约）：将哈希锁（仅凭原像付款）与时间锁（到期后可取回）相结合，实现跨多个跳点的原子路由。
- to_self_delay / 撤销密钥：在承诺交易中，CSV 延迟保护了诚实参与方：若对手方尝试广播旧的通道状态，受害方有时间以撤销密钥作出响应并索取全部资金。每跳的 CLTV delta 值因实现方式和路由深度而异；截至 2026 年，典型值约在 40 至 144 个区块之间，BOLT 标准并未规定固定的最低值。
应用场景：金库与遗产继承
CLTV 和 CSV 使非托管式遗产规划与紧急备用方案成为可能。一个典型案例是死人开关（Dead Man's Switch）：一笔将币转给继承人的交易通过 CLTV 锁定到未来某个时间点。只要所有者在世，便定期更新锁定；一旦停止更新，该交易即告生效。OP_VAULT（BIP 345）等活跃研究项目正是在这些原语之上构建，以实现更为稳健的金库方案。
安全原语，而非噱头：时间锁并非可选的便利功能，而是无需信任任何第三方、由密码学强制执行的时间条件——这是自主掌控 Bitcoin 安全的基础构建模块。
总结
四种时间锁机制构成了层层递进的架构：nLockTime 和 nSequence 在协议层运作，确立基本规则；CLTV 和 CSV 则将这些条件内嵌于 UTXO，使其无可规避。任何希望深入理解 Bitcoin 协议、Lightning 安全机制或自托管策略的人，都无法绕过时间锁这一主题。
延伸阅读
لغة البرمجة النصية في Bitcoin مقيّدة عن قصد – وهذا التقييد بالذات هو ما يجعل كل آلية من آلياتها أكثر قيمةً. تُعدّ Timelocks من أقوى الأدوات في البروتوكول وأكثرها استهانةً في آنٍ واحد. إذ تُتيح قفل المعاملات أو المخرجات الفردية بحيث لا تصبح صالحةً إلا ابتداءً من نقطة زمنية محددة. والنتيجة: عقود ذكية مضبوطة زمنياً على بلوكشين لا تحتاج إلى حالة عالمية ولا إلى اكتمال تورينغ.
الآليات الأربع في لمحة
يمتلك Bitcoin أربع آليات Timelock متمايزة، تتباين وفق بُعدين: المستوى (المعاملة مقابل النص البرمجي) والنوع (مطلق مقابل نسبي). والمخطط التالي هو محور هذا المقال التعليمي:
- nLockTime – مستوى المعاملة، مطلق
- nSequence (BIP 68) – مستوى المدخل، نسبي
- CHECKLOCKTIMEVERIFY / CLTV (BIP 65) – مستوى النص البرمجي، مطلق
- CHECKSEQUENCEVERIFY / CSV (BIP 112) – مستوى النص البرمجي، نسبي
nLockTime: أقدم Timelock
حقل nLockTime حجمه 4 بايت، وهو جزء من كل معاملة Bitcoin منذ كتلة النشأة. أي قيمة أقل من 500,000,000 تُفسَّر على أنها ارتفاع كتلة، وأي قيمة تساوي 500,000,000 أو أكثر تُعامَل باعتبارها طابعاً زمنياً بصيغة Unix. ولا يحق لأي مُعدِّن تضمين معاملة تحتوي على nLockTime في كتلة قبل بلوغ تلك النقطة الزمنية.
نقطة الضعف الجوهرية: إن nLockTime خاصية تتعلق بمعاملة الإنفاق لا بـ UTXO ذاته. فلا شيء يمنع مستلم المخرج من إنشاء معاملة جديدة خالية من nLockTime – فالقفل ليس متأصلاً في UTXO. وهنا تحديداً يأتي دور CLTV و CSV.
Median Time Past (MTP): لا تتحقق عُقد Bitcoin من الأقفال الزمنية بمقارنتها بالوقت الحالي للنظام، بل بمقارنتها بوسيط الطوابع الزمنية لآخر 11 كتلة. وهذا يحول دون التلاعب من قِبَل معدِّنين بعينهم الذين قد يقدِّمون توقيت كتلهم بصورة مصطنعة.
CHECKLOCKTIMEVERIFY (CLTV): قفل مطلق على مستوى النص البرمجي
قدَّم BIP 65 الـ opcode OP_CHECKLOCKTIMEVERIFY، الذي تم تفعيله عبر Soft Fork في 22 نوفمبر 2015 عند الكتلة 388,381. CLTV هو opcode نصي: يُضمَّن مباشرةً في نص القفل الخاص بـ UTXO، ويتحقق وقت الإنفاق من أن حقل nLockTime في معاملة الإنفاق لا يقل عن القيمة المُشفَّرة في النص البرمجي. وبهذا يحمل المخرج نفسه القفل الزمني – فهو متأصل في UTXO ولا يمكن لأحد تجاوزه.
مثال توضيحي: تودع Alice عملات في نص CLTV يحدد ارتفاع الكتلة 900,000 كحدٍّ فاصل. لا يستطيع أي مُعدِّن في العالم إنفاق هذه العملات في معاملة صالحة قبل الكتلة 900,000 – إذ سيفشل النص البرمجي حتماً.
nSequence و CHECKSEQUENCEVERIFY (CSV): Timelocks النسبية
لا تقيس Timelocks النسبية الوقت من نقطة ثابتة، بل من تأكيد UTXO الممول نفسه. أعاد BIP 68 تعريف حقل nSequence ذي 32 بتاً لكل مدخل: البت 31 هو علامة التعطيل، والبت 22 يُبدِّل بين الكتل (0) وفترات 512 ثانية (1)، والبتات من 0 إلى 15 تحمل القيمة الفعلية (بحد أقصى 65,535 كتلة، أي نحو 455 يوماً).
أضاف BIP 112 الـ opcode OP_CHECKSEQUENCEVERIFY، الذي يُطبِّق Timelocks النسبية على مستوى النص البرمجي – على غرار CLTV، لكن بصورة نسبية. وقد تم تفعيل كلا الـ BIP في 4 يوليو 2016 عند الكتلة 419,328.
حالة الاستخدام: شبكة Lightning
بدون CSV، لما أمكن بناء شبكة Lightning بشكلها الحالي بصورة آمنة. ثمة آليتان محوريتان:
- HTLC (Hash Time-Locked Contracts): تجمع بين hashlock (الدفع مقابل الـ preimage فقط) وtimelock (استرداد الأموال بعد انتهاء المهلة). وتُتيح التوجيه الذري عبر نقاط توصيل متعددة.
- to_self_delay / Revocation Key: في معاملات الالتزام، يحمي تأخير CSV المشارك الأمين: إن حاول الطرف المقابل بث حالة قناة قديمة، يتوفر للطرف المتضرر وقت كافٍ للرد باستخدام Revocation Key والمطالبة بكامل الأموال. تتفاوت قيمة CLTV delta لكل hop بحسب التطبيق وعمق التوجيه؛ وتتراوح القيم النموذجية اعتباراً من عام 2026 بين نحو 40 و144 كتلة، دون أن يفرض معيار BOLT حداً أدنى ثابتاً.
حالة الاستخدام: Vaults والميراث
يُتيح CLTV و CSV إعدادات ميراث وطوارئ غير حافظة (non-custodial). ومثال كلاسيكي على ذلك هو Dead-Man's-Switch: معاملة تنقل العملات إلى الورثة مقفلة بـ CLTV حتى نقطة زمنية مستقبلية. ما دام المالك حياً، يُجدِّد القفل بصفة دورية؛ فإن توقف التجديد، أصبحت المعاملة سارية. وتبني مشاريع بحثية نشطة كـ OP_VAULT (BIP 345) على هذه المفاهيم الأساسية لتمكين بنيات Vault أكثر متانة.
مبدأ أمني لا مجرد ميزة ترفيهية: Timelocks ليست وظيفة راحة اختيارية، بل هي شروط زمنية مُطبَّقة تشفيرياً لا تحتاج إلى الثقة بأطراف ثالثة – وهي لبنة أساسية للأمان الذاتي في Bitcoin.
خلاصة
تُشكِّل الآليات الأربع للـ Timelock بنيةً متراكبة: يعمل nLockTime و nSequence على مستوى البروتوكول ويضعان الإطار العام؛ فيما يجعل CLTV و CSV هذه الشروط متأصلة في UTXO وبالتالي لا يمكن تجاوزها. لا يمكن لأي شخص يسعى إلى فهم بروتوكول Bitcoin أو أمان Lightning أو استراتيجيات الحفظ الذاتي أن يتجاهل Timelocks.
مزيد من المعلومات
⚖️ Die stärksten GegenargumenteThe Strongest CounterargumentsLos contraargumentos más fuertesOs contra-argumentos mais fortes最も強力な反論最有力的反方观点أقوى الحجج المضادة
Jedes Gegenargument in seiner stärksten Form – geprüft und nach Datenlage entschieden, kein Wunschdenken.Each counterargument in its strongest form – scrutinized and adjudicated per the data, no wishful thinking.Cada contraargumento en su forma más fuerte: examinado y juzgado según los datos, sin ilusiones.Cada contra-argumento na sua forma mais forte – examinado e julgado segundo os dados, sem ilusões.各反論を最も強い形で提示し、データに基づいて検証・判定しています。希望的観測はありません。每个反方观点均以其最强形式呈现——依据数据审视并判定，绝不一厢情愿。كل حجة مضادة في أقوى صورها — مفحوصة ومحسومة وفق البيانات، لا وفق التمني.
Timelock-basierte Erbschafts-Setups wie der beschriebene Dead-Man's-Switch sind in der Praxis deutlich fragiler, als der Artikel suggeriert: Vorsignierte Transaktionen werden ungültig, sobald der zugrunde liegende UTXO bewegt wird, jahrelang im Voraus festgelegte Gebührensätze können zum Auslösezeitpunkt unzureichend sein, und ein Schlüsselverlust macht jede zeitliche Bedingung wertlos.Timelock-based inheritance setups like the described dead-man's switch are far more fragile in practice than the article suggests: pre-signed transactions become invalid the moment the underlying UTXO moves, fee rates fixed years in advance can be insufficient at trigger time, and key loss renders any time condition worthless.Los esquemas de herencia basados en timelocks, como el dead-man's switch descrito, son en la práctica mucho más frágiles de lo que sugiere el artículo: las transacciones prefirmadas se invalidan en cuanto se mueve el UTXO subyacente, las comisiones fijadas con años de antelación pueden ser insuficientes en el momento de activación, y la pérdida de la clave hace inútil cualquier condición temporal.Esquemas de herança baseados em timelocks, como o dead-man's switch descrito, são na prática bem mais frágeis do que o artigo sugere: transações pré-assinadas tornam-se inválidas assim que o UTXO subjacente é movido, taxas fixadas com anos de antecedência podem ser insuficientes no momento do acionamento, e a perda da chave torna qualquer condição temporal inútil.記事が紹介するデッドマンズスイッチのようなタイムロックベースの相続設計は、実際には記事が示唆するよりはるかに脆弱である。事前署名済みトランザクションは対象UTXOが動いた瞬間に無効になり、何年も前に固定した手数料率は発動時に不足しうるうえ、鍵を紛失すればいかなる時間条件も無価値になる。文中描述的「死人开关」这类基于时间锁的继承方案，实践中远比文章暗示的脆弱：一旦底层UTXO被移动，预签名交易即告失效；提前数年固定的手续费率在触发时可能不足；而私钥丢失会让任何时间条件形同虚设。ترتيبات التوريث القائمة على الأقفال الزمنية مثل مفتاح الرجل الميت الموصوف في المقال أهش عمليا بكثير مما يوحي به النص: المعاملات الموقعة مسبقا تصبح باطلة فور تحريك الـUTXO الأساسي، ورسوم محددة قبل سنوات قد تكون غير كافية وقت التفعيل، وفقدان المفتاح يجعل أي شرط زمني بلا قيمة.
Alle drei Fragilitäten folgen direkt aus den Protokollregeln, die der Artikel selbst korrekt beschreibt: Eine vorsignierte Transaktion referenziert eine konkrete txid und stirbt mit deren Ausgabe; Gebühren vorsignierter Transaktionen sind ohne Anchor-Outputs oder CPFP nicht nachträglich anpassbar; und CLTV prüft nur Zeit, nicht Schlüsselverfügbarkeit. Praxistaugliche Erbschaftslösungen erfordern deshalb regelmäßige Wartung oder Kollaborativ-Setups – der Artikel nennt die Erneuerungspflicht, verschweigt aber die übrigen Bruchstellen.All three fragilities follow directly from the protocol rules the article itself describes correctly: a pre-signed transaction references a specific txid and dies when that output is spent; fees of pre-signed transactions cannot be adjusted later without anchor outputs or CPFP; and CLTV checks time, not key availability. Practical inheritance solutions therefore require ongoing maintenance or collaborative setups – the article mentions the renewal duty but stays silent on the other breaking points.Las tres fragilidades se derivan directamente de las reglas del protocolo que el propio artículo describe correctamente: una transacción prefirmada referencia una txid concreta y muere cuando ese output se gasta; las comisiones de transacciones prefirmadas no pueden ajustarse después sin anchor outputs o CPFP; y CLTV verifica el tiempo, no la disponibilidad de la clave. Las soluciones de herencia prácticas requieren por tanto mantenimiento continuo o esquemas colaborativos; el artículo menciona el deber de renovación, pero calla los demás puntos de ruptura.As três fragilidades decorrem diretamente das regras de protocolo que o próprio artigo descreve corretamente: uma transação pré-assinada referencia uma txid concreta e morre quando esse output é gasto; taxas de transações pré-assinadas não podem ser ajustadas depois sem anchor outputs ou CPFP; e o CLTV verifica o tempo, não a disponibilidade da chave. Soluções práticas de herança exigem portanto manutenção contínua ou esquemas colaborativos – o artigo menciona o dever de renovação, mas silencia sobre os demais pontos de ruptura.三つの脆弱性はいずれも、記事自身が正しく説明しているプロトコルルールから直接導かれる。事前署名済みトランザクションは特定のtxidを参照しており、そのアウトプットが使用された時点で無効になる。事前署名済みトランザクションの手数料はアンカーアウトプットやCPFPなしには後から調整できない。CLTVは時間のみを検証し、鍵の可用性は検証しない。実用的な相続ソリューションには継続的なメンテナンスか協調型設計が必要である。記事は更新義務には触れるが、他の破綻点には沈黙している。这三处脆弱性都直接源于文章本身正确描述的协议规则：预签名交易引用特定txid，一旦该输出被花费即失效；预签名交易的手续费在没有anchor输出或CPFP的情况下无法事后调整；CLTV只验证时间，不验证私钥可用性。实用的继承方案因此需要持续维护或协作式架构——文章提到了定期更新义务，却对其他断裂点保持沉默。نقاط الهشاشة الثلاث تنبع مباشرة من قواعد البروتوكول التي يصفها المقال نفسه بشكل صحيح: المعاملة الموقعة مسبقا تشير إلى txid محدد وتبطل بمجرد إنفاق ذلك المخرج؛ ورسوم المعاملات الموقعة مسبقا لا يمكن تعديلها لاحقا دون مخرجات ربط أو CPFP؛ وCLTV يتحقق من الزمن فقط لا من توفر المفتاح. لذلك تتطلب حلول التوريث العملية صيانة مستمرة أو ترتيبات تعاونية - المقال يذكر واجب التجديد لكنه يصمت عن نقاط الانكسار الأخرى.
Die Lightning-Sicherheitsgarantien, die der Artikel auf CSV und HTLCs stützt, gelten nur unter der Annahme rechtzeitiger On-Chain-Reaktion: Bei massenhaften Channel-Schließungen oder gezielter Mempool-Überlastung können Timelock-Fenster ablaufen, bevor Strafttransaktionen bestätigt werden – ein in der Forschung dokumentierter Angriffsvektor.The Lightning security guarantees the article grounds in CSV and HTLCs hold only under the assumption of timely on-chain reaction: during mass channel closures or deliberate mempool congestion, timelock windows can expire before penalty transactions confirm – an attack vector documented in the research literature.Las garantías de seguridad de Lightning que el artículo basa en CSV y HTLC solo se sostienen bajo el supuesto de una reacción on-chain oportuna: durante cierres masivos de canales o congestión deliberada del mempool, las ventanas de timelock pueden expirar antes de que se confirmen las transacciones de penalización, un vector de ataque documentado en la literatura de investigación.As garantias de segurança da Lightning que o artigo fundamenta em CSV e HTLCs valem apenas sob a premissa de reação on-chain oportuna: durante fechamentos massivos de canais ou congestionamento deliberado do mempool, as janelas de timelock podem expirar antes que as transações de penalidade sejam confirmadas – um vetor de ataque documentado na literatura de pesquisa.記事がCSVとHTLCに根拠づけるLightningのセキュリティ保証は、オンチェーンでの迅速な対応という前提の下でのみ成立する。チャネルの大量クローズや意図的なメンプール混雑の際には、ペナルティトランザクションが承認される前にタイムロックの猶予期間が切れうる。これは研究文献に記録された攻撃ベクトルである。文章将Lightning的安全保障建立在CSV和HTLC之上，但这只有在及时进行链上反应的前提下才成立：在通道大规模关闭或蓄意制造内存池拥堵时，时间锁窗口可能在惩罚交易确认之前就已过期——这是研究文献中有记载的攻击向量。ضمانات أمان Lightning التي يبنيها المقال على CSV وعقود HTLC لا تصمد إلا بافتراض استجابة سريعة على السلسلة: أثناء الإغلاق الجماعي للقنوات أو الازدحام المتعمد لتجمع المعاملات قد تنقضي نوافذ الأقفال الزمنية قبل تأكيد معاملات العقوبة - وهو ناقل هجوم موثق في أدبيات البحث.
Die Forschung hat diese Angriffsklasse konkret beschrieben – etwa „Flood & Loot" (Harris/Zohar, 2020), das zeigt, wie ein Angreifer durch gleichzeitiges Erzwingen vieler HTLC-Abwicklungen die Blockraum-Konkurrenz so erhöht, dass Timelocks vor der Bestätigung der Gegenmaßnahmen ablaufen. Anchor Outputs und Watchtower mildern das Risiko, beseitigen es aber nicht. Der Artikel stellt die Timelock-Mechanik korrekt dar, überzeichnet jedoch die Unbedingtheit der daraus folgenden Sicherheit.Research has concretely described this attack class – notably 'Flood & Loot' (Harris/Zohar, 2020), which shows how an attacker forcing many simultaneous HTLC settlements can raise blockspace competition until timelocks expire before countermeasures confirm. Anchor outputs and watchtowers mitigate but do not eliminate the risk. The article presents the timelock mechanics correctly but overstates the unconditional nature of the resulting security.La investigación ha descrito concretamente esta clase de ataque, en particular «Flood & Loot» (Harris/Zohar, 2020), que muestra cómo un atacante que fuerza muchas liquidaciones simultáneas de HTLC puede elevar la competencia por el espacio de bloque hasta que los timelocks expiren antes de que se confirmen las contramedidas. Los anchor outputs y las watchtowers mitigan el riesgo, pero no lo eliminan. El artículo presenta correctamente la mecánica de los timelocks, pero exagera la incondicionalidad de la seguridad resultante.A pesquisa descreveu concretamente essa classe de ataque – notavelmente 'Flood & Loot' (Harris/Zohar, 2020), que mostra como um atacante que força muitas liquidações simultâneas de HTLC pode elevar a competição por espaço de bloco até que os timelocks expirem antes da confirmação das contramedidas. Anchor outputs e watchtowers mitigam, mas não eliminam o risco. O artigo apresenta corretamente a mecânica dos timelocks, mas exagera o caráter incondicional da segurança resultante.研究はこの攻撃クラスを具体的に記述している。特に「Flood & Loot」(Harris/Zohar、2020年)は、攻撃者が多数のHTLC決済を同時に強制することでブロックスペースの競争を激化させ、対抗手段が承認される前にタイムロックを失効させうることを示した。アンカーアウトプットやウォッチタワーはリスクを軽減するが除去はしない。記事はタイムロックの仕組みを正しく説明しているが、そこから得られるセキュリティの無条件性を誇張している。研究已具体描述了这类攻击——尤其是「Flood & Loot」（Harris/Zohar，2020年），它展示了攻击者如何通过同时强制大量HTLC结算来加剧区块空间竞争，使时间锁在反制交易确认前失效。Anchor输出和瞭望塔可以缓解但无法消除该风险。文章对时间锁机制的描述正确，但夸大了由此产生的安全性的无条件性。وصفت الأبحاث هذه الفئة من الهجمات بشكل ملموس - وأبرزها "Flood & Loot" (Harris/Zohar، 2020) الذي يبين كيف يمكن لمهاجم يجبر على تسوية عدد كبير من عقود HTLC في آن واحد أن يرفع المنافسة على مساحة الكتل حتى تنقضي الأقفال الزمنية قبل تأكيد الإجراءات المضادة. مخرجات الربط وأبراج المراقبة تخفف الخطر لكنها لا تزيله. المقال يعرض آلية الأقفال الزمنية بشكل صحيح لكنه يبالغ في إطلاقية الأمان الناتج عنها.
Der Artikel nennt OP_VAULT (BIP 345) im Kontext praxisrelevanter Vault-Konstruktionen – doch BIP 345 ist ein Entwurf ohne Aktivierungspfad und ohne absehbare Soft-Fork-Mehrheit. Robuste, benutzerfreundliche Vaults existieren auf Bitcoin Stand 2026 schlicht nicht; wer sie heute erwartet, wird enttäuscht oder weicht auf riskante Behelfskonstruktionen aus.The article cites OP_VAULT (BIP 345) in the context of practically relevant vault constructions – but BIP 345 is a draft with no activation path and no foreseeable soft-fork majority. Robust, user-friendly vaults simply do not exist on Bitcoin as of 2026; anyone expecting them today will be disappointed or resort to risky makeshift constructions.El artículo cita OP_VAULT (BIP 345) en el contexto de construcciones de vault con relevancia práctica, pero BIP 345 es un borrador sin ruta de activación ni mayoría previsible para un soft fork. Los vaults robustos y fáciles de usar simplemente no existen en Bitcoin en 2026; quien los espere hoy se decepcionará o recurrirá a construcciones improvisadas y arriesgadas.O artigo cita o OP_VAULT (BIP 345) no contexto de construções de vault com relevância prática – mas o BIP 345 é um rascunho sem caminho de ativação e sem maioria previsível para um soft fork. Vaults robustos e fáceis de usar simplesmente não existem no Bitcoin em 2026; quem os espera hoje se decepcionará ou recorrerá a construções improvisadas e arriscadas.記事は実用的なボールト構築の文脈でOP_VAULT(BIP 345)に言及しているが、BIP 345は有効化への道筋もソフトフォーク多数派の見通しもないドラフトにすぎない。2026年時点のBitcoinには、堅牢で使いやすいボールトは端的に存在しない。今日それを期待する者は失望するか、危険な間に合わせの構成に頼ることになる。文章在具有实践意义的保险库构建语境中引用了OP_VAULT（BIP 345）——但BIP 345只是一份草案，既无激活路径，也看不到软分叉多数支持的前景。截至2026年，比特币上根本不存在健壮且易用的保险库；今天就期待它的人要么失望，要么转向有风险的临时拼凑方案。يستشهد المقال بOP_VAULT (BIP 345) في سياق بنى الخزائن ذات الأهمية العملية - لكن BIP 345 مسودة بلا مسار تفعيل ولا أغلبية منظورة لتفريع ناعم. الخزائن المتينة سهلة الاستخدام غير موجودة ببساطة على Bitcoin حتى 2026؛ ومن يتوقعها اليوم سيصاب بخيبة أمل أو يلجأ إلى بنى مؤقتة محفوفة بالمخاطر.
Der Status ist öffentlich überprüfbar: BIP 345 trägt im BIP-Repository den Status „Draft", es existiert kein Aktivierungssignal von Minern oder Nodes, und die Covenant-Debatte (auch um Alternativen wie OP_CTV/BIP 119) war Stand 2026 ohne Konsens. Der Artikel formuliert vorsichtig („Forschungsprojekte"), erzeugt aber durch die Platzierung im Anwendungsfall-Abschnitt einen Praxisnähe-Eindruck, den die Faktenlage nicht deckt.The status is publicly verifiable: BIP 345 carries 'Draft' status in the BIP repository, there is no activation signaling from miners or nodes, and the covenant debate (including alternatives like OP_CTV/BIP 119) remained without consensus as of 2026. The article words this cautiously ('research projects'), but its placement in the use-case section creates an impression of practical proximity the facts do not support.El estado es verificable públicamente: BIP 345 figura como «Draft» en el repositorio de BIPs, no existe señalización de activación por parte de mineros o nodos, y el debate sobre covenants (incluidas alternativas como OP_CTV/BIP 119) seguía sin consenso en 2026. El artículo lo formula con cautela («proyectos de investigación»), pero su ubicación en la sección de casos de uso crea una impresión de cercanía práctica que los hechos no respaldan.O status é publicamente verificável: o BIP 345 tem status 'Draft' no repositório de BIPs, não há sinalização de ativação por mineradores ou nós, e o debate sobre covenants (incluindo alternativas como OP_CTV/BIP 119) permanecia sem consenso em 2026. O artigo formula com cautela ('projetos de pesquisa'), mas sua colocação na seção de casos de uso cria uma impressão de proximidade prática que os fatos não sustentam.このステータスは公開情報で検証できる。BIP 345はBIPリポジトリで「Draft」ステータスであり、マイナーやノードからの有効化シグナリングは存在せず、コベナント論争(OP_CTV/BIP 119などの代替案を含む)は2026年時点でコンセンサスに至っていない。記事は「研究プロジェクト」と慎重に表現しているが、ユースケースの節に配置したことで、事実が裏付けない実用性の印象を生んでいる。其状态可公开核实：BIP 345在BIP代码库中标注为「Draft」，矿工和节点均无激活信号，而契约（covenant）之争（包括OP_CTV/BIP 119等替代方案）截至2026年仍无共识。文章措辞谨慎（「研究项目」），但将其置于应用场景章节，营造出事实并不支持的实用性印象。الحالة قابلة للتحقق علنا: يحمل BIP 345 حالة "Draft" في مستودع BIP، ولا توجد إشارات تفعيل من المعدنين أو العقد، وظل نقاش الـCovenants (بما فيه بدائل مثل OP_CTV/BIP 119) بلا إجماع حتى 2026. صياغة المقال حذرة ("مشاريع بحثية") لكن وضعها في قسم حالات الاستخدام يخلق انطباعا بقرب عملي لا تدعمه الوقائع.
QuellenSourcesFuentesFontes出典来源المصادر
- BIP 65: OP_CHECKLOCKTIMEVERIFY – GitHub (bitcoin/bips) (github.com)
- BIP 112: CHECKSEQUENCEVERIFY – GitHub (bitcoin/bips) (github.com)
- BIP 68: Relative lock-time using consensus-enforced sequence numbers – GitHub (bitcoin/bips) (github.com)
- Bitcoin Developer Guide: Transactions (Timelocks) – bitcoin.org (developer.bitcoin.org)
- BOLT #3: Transactions – Lightning Network Specifications (lightning/bolts) (github.com)
- BIP 345: OP_VAULT – GitHub (bitcoin/bips) (github.com)