Koch Laboratory

Zeit als Beweis, zum dritten Mal: Mitunterzeichner mit eigener Uhr und die Grenzen der Regel „2 aus 3“

Setzt den Eintrag vom 2026-10-01 fort und korrigiert ihn. Seit dem 6. Oktober bestätigen zwei Mitunterzeichner den Zustand des Logs, die Kette, Baum und Zeit der Einträge selbst prüfen, und seit dem 19. Oktober berechnen die Prüfseite und die PHP-Bibliothek die Regel „2 aus 3“ selbst. Die Grenze ist offen benannt: Zwei der drei Schlüssel hält der Betreiber, die Regel schützt also vor einem Einbruch und vor Fehlkonfiguration. Dazu eine Stempelsperre bei unbekanntem Uhrenfehler, zwei negative Ergebnisse und ein Nachweis verstrichener Mindestzeit in der Messphase.

Koch Laboratory - Zeit als Beweis, zum dritten Mal: Mitunterzeichner mit eigener Uhr und die Grenzen der Regel „2 aus 3“

Der Eintrag vom 2026-10-01 („Zeit als Beweis, neu betrachtet“) schloss Richtung 1 mit einer offenen Frage ab: ob den Zustand des Logs unabhängige Parteien signieren sollten, damit der Schlüssel des Betreibers allein - kompromittiert oder falsch konfiguriert - nicht genügt, um eine überzeugende alternative Geschichte vorzulegen. Fünf Tage später liefen zwei Mitunterzeichner. Dieser Eintrag beschreibt, was sie prüfen und wo die Grenzen der Regel „2 aus 3“ liegen, wie der Dienst aufhörte, bei unbekanntem Uhrenfehler zu stempeln, was sich seither als Fehler erwiesen hat und welche Aussagen des Eintrags vom 2026-10-01 inzwischen veraltet sind. Die vollständige Beschreibung des Aufbaus und das Verfahren, das ein Sachverständiger selbst durchführt, enthält der technische Bericht vom 9. Oktober 2026 (doi.org/10.5281/zenodo.23265547).

Was hier Forschung ist und was nicht. Signaturen von Zeugen über dem Zustand des Logs sind ein ausgereiftes Muster der Transparenz-Logs; authentifizierte Zeitsynchronisation (NTS, RFC 8915), der Grundsatz, die Ausgabe von Zeitstempeln nach einem Verlust der Synchronisation auszusetzen, und der Nachweis sequenzieller Arbeit aus Richtung 4 stammen ebenfalls nicht von uns. Forschungsgegenstand sind die Grenzen - was genau die Signatur eines Mitunterzeichners bezeugt, wie viel Schutz die Regel „2 aus 3“ bietet, wenn der Betreiber zwei der drei Schlüssel hält, und was davon eine Person sieht, die einen Stempel prüft - sowie das, was versagt hat. Die Beweisaussage bleibt unverändert: Ein Stempel zeigt, dass eine Datei mit einem gegebenen Fingerabdruck zum Zeitpunkt des Stempels bereits existierte - nicht, dass sie vorher nicht existierte, und nicht, wer ihr Urheber ist.

Methodik. Wie im übrigen Labor: Problem → Stand der Technik → falsifizierbares Kriterium → Methode → Ergebnis (bestätigt, widerlegt oder teilweise, mit Randbedingungen) → nächster Schritt. Ein negatives Ergebnis ist ein Ergebnis. Zahlen aus Tests sind als solche gekennzeichnet.

1. Richtung 1 - Mitunterzeichner, die die Zeit der Einträge prüfen und nicht nur die Konsistenz des Logs

Problem. Nach dem Schlüsselvorfall (Eintrag vom 2026-10-01, Richtung 1) verlagerte sich das Vertrauen von der Signatur auf die Kopien und die Anker. Die Kopien sind jedoch passiv - sie bewahren auf, prüfen aber vor der Annahme nichts -, und zwischen einem Stempel und dem nächsten Anker in Bitcoin vergeht bis zu etwa ein Tag. In diesem Fenster war die Zeit eines Eintrags allein das Wort des Betreibers: Niemand außer ihm beobachtete das Log laufend. Stand der Technik (veröffentlicht). Zeugen, die in Transparenz-Logs den Baumzustand gegenzeichnen (die C2SP-Spezifikationen tlog-cosignature und tlog-witness, die Prüfsummendatenbank der Go-Module, Sigstore), und kollektive Zeugensignaturen (CoSi; Syta et al., IEEE S&P 2016). Schwellenanalyse für Zeugen (N. Möller, Projekt Sigsum, 2023): Eine Regel k aus n schützt bei f unredlichen Unterzeichnern nur dann vor voneinander abweichenden Versionen der Geschichte, wenn 2k > n + f. Ein Zeuge bezeugt in diesem Muster vor allem die Konsistenz aufeinanderfolgender Baumzustände und den Zeitpunkt, zu dem er sie gesehen hat; die in den einzelnen Einträgen erfasste Zeit prüft er in der Regel nicht. Kriterium (falsifizierbar). (1) Ein Mitunterzeichner signiert nur, was er selbst geprüft hat: die Hash-Kette, den von Grund auf nachgerechneten globalen Baum und die Zeit jedes neuen Eintrags gegenüber seiner eigenen Uhr - mit einer Toleranz von ±30 s, wobei ein Eintrag nicht älter sein darf als die vorige Beobachtung des Mitunterzeichners; (2) der Server des Dienstes kann weder selbst eine Signatur eines Mitunterzeichners erzeugen noch ihm etwas zum Signieren unterschieben; (3) ein Prüfprogramm zeigt einen Stempel nur dann als bestätigt an, wenn es selbst mindestens zwei der drei Signaturen geprüft hat. Widerlegt wird das Kriterium durch die Signatur eines Mitunterzeichners über einem Zustand, den er nicht geprüft hat, durch einen signierten Eintrag, der über die Toleranz hinaus zurückdatiert ist, oder durch eine Bestätigung, die ohne zwei geprüfte Signaturen angezeigt wird. Methode. Seit dem 6. Oktober 2026 laufen zwei Mitunterzeichner-Programme auf getrennten Maschinen und Konten: eines bei AWS (eine Lambda-Funktion in Frankfurt, der Schlüssel in einem Hardwaremodul von AWS KMS), betrieben vom Sigelith-Betreiber, das andere bei Konveria - einem unabhängigen Unternehmen in Krakau ohne personelle oder kapitalmäßige Verbindungen zum Betreiber, das auch die Android-Apps von Sigelith veröffentlicht. Jede Minute lädt jeder Mitunterzeichner das öffentliche Log selbst herunter, prüft die Kette und die Zeit neuer Einträge, berechnet den RFC-9162-Baum neu und signiert, was er gesehen hat (sigelith-cosign-v1: Größe und Wurzel des Baums, letzter Eintrag, eigene Zeit und Zeit der vorigen Beobachtung). Ein Mitunterzeichner nimmt keinerlei Eingaben von außen entgegen. Der Server hat keine Schlüssel der Mitunterzeichner - er speichert ihre Signaturen und stellt sie bereit, und eine Signatur, die nicht zu seinem eigenen Baum passt, erfasst er als nicht übereinstimmend. Jede Unregelmäßigkeit - eine unterbrochene Kette, eine zurücklaufende Zeit, ein zurückdatierter oder in die Zukunft datierter Eintrag - hält den Mitunterzeichner bis zu einer manuellen Entscheidung seines Betreibers an; ein Mitunterzeichner signiert nie „trotzdem“, und die letzte Signatur jedes Mitunterzeichners ist öffentlich, sodass eine Unterbrechung sichtbar ist. Ein Stempel gilt als bestätigt, wenn ihn zwei beliebige der drei Signaturen stützen: die des Log-Schlüssels (die Quittung) und die der beiden Mitunterzeichner. Das Mitunterzeichner-Programm ist öffentlich, mit reproduzierbarem Build, Protokollbeschreibung, Testvektor und Tests für diese Stopps (github.com/DeiFlagellum/sigelith-cosigner, Apache-2.0). Seit dem 19. Oktober werten die Prüfseite (/proof/) und die PHP-Bibliothek für Plugins die Regel „2 aus 3“ selbst aus: die Quittung, den RFC-9162-Pfad zu einer signierten Wurzel und die Signaturen der Mitunterzeichner, mit im Code hinterlegten Schlüsseln; die Seite zeigt „N von 3 Signaturen in diesem Browser geprüft“ ausschließlich auf Grundlage eigener Berechnungen an und eine nicht übereinstimmende Signatur immer in Rot. Seit dem 26. Oktober schreibt Sigelith Backup die Signaturen der Mitunterzeichner auf eine Archiv-Disc und prüft sie ohne Netz; sein Prüfprogramm ist eine Portierung des Moduls der Seite und nutzt dieselben Testvektoren. Ergebnis. Im Rahmen des Kriteriums bestätigt. Am 6. Oktober um 20:13 UTC hatte Eintrag Nr. 300 drei von drei Signaturen, jede einzeln geprüft; am 19. Oktober zeigten die Seite im Browser und die PHP-Bibliothek an der Live-API drei von drei (Tests an gemeinsamen Vektoren: 14 Fälle in JavaScript, 1724 Prüfungen in PHP 7.4 und 8.3). Das Zeitfenster eines Eintrags schrumpfte von etwa einem Tag (Anker) auf etwa eine Minute (Beobachtungen der Mitunterzeichner) - z. B. sah der Mitunterzeichner bei AWS den Eintrag Nr. 320, erfasst um 18:48:03,213 UTC, zwischen 18:47:05 und 18:48:05 und der Mitunterzeichner von Konveria zwischen 18:47:31 und 18:48:31. Randbedingungen: (a) Zwei der drei signierenden Systeme werden vom Betreiber betrieben - der Log-Schlüssel und der Mitunterzeichner bei AWS; der Server des Dienstes hat keinen Zugriff auf das AWS-Konto, der Betreiber als dessen Inhaber aber schon. Für die Anordnung 2 aus 3 ergibt sich aus der Bedingung 2k > n + f der Wert f = 0: Die Regel toleriert keinen Unterzeichner, der sich mit anderen abspricht, und der Betreiber erfüllt sie allein. „2 aus 3“ schützt also vor einem Einbruch in ein einzelnes System und vor einem Konfigurationsfehler wie dem im September; vom Betreiber unabhängig sind der Mitunterzeichner von Konveria, Bitcoin, die Bank und die Archive; (b) dass Konveria unabhängig ist und dass sich der Schlüssel nicht aus AWS KMS kopieren lässt, sind Angaben, die sich kryptografisch nicht prüfen lassen; (c) das Fenster eines Mitunterzeichners stammt von seiner eigenen Uhr - es ist so gut wie diese Uhr und keine unabhängige Zeitquelle; (d) die Seite /proof/ rechnet im Browser, ihren Code liefert aber der Server des Betreibers - die unabhängige Prüfung bleibt das Verfahren aus dem Bericht, und der Desktop-Client, der Beweise ohne den Server prüft, prüft die Signaturen der Mitunterzeichner noch nicht; (e) Einträge vor dem 6. Oktober haben kein Fenster der Mitunterzeichner; (f) ein Mitunterzeichner hält nach jeder Unregelmäßigkeit an, und die Verfügbarkeit der Mitunterzeichner haben wir bisher nicht gemessen. Nächster Schritt. Messung der Verfügbarkeit der Mitunterzeichner anhand ihrer öffentlichen Signaturen; Prüfung der Signaturen der Mitunterzeichner im Desktop-Client. Offen bleibt, ob und wann weitere unabhängige Mitunterzeichner hinzukommen: Aus derselben Bedingung folgt (eigene Berechnung), dass ein Betreiber mit zwei Schlüsseln die Regel nicht mehr allein erfüllt, wenn es mindestens drei unabhängige Mitunterzeichner gibt und die Schwelle bei 4 aus 5 liegt. Status: umgesetzt seit dem 6. Oktober 2026; Prüfung „2 aus 3“ im Browser und in PHP seit dem 19. Oktober, in Sigelith Backup seit dem 26. Oktober; die Grenzen (a)-(f) gelten.

2. Richtung 2 - der Dienst stellt das Stempeln ein, wenn er den Fehler seiner Uhr nicht kennt

Problem. Die erfasste Zeit eines Eintrags ist die Angabe der Serveruhr. Der Eintrag vom 2026-10-01 stellte richtig, dass die bisherige Messung der Abweichung eine einzelne, nicht authentifizierte SNTP-Abfrage an einen einzigen Server war - ein Zustandssignal, kein Beweis. Bis zum 6. Oktober hielt zudem nichts das Stempeln an, wenn die Uhr abwich: Einen Eintrag mit falscher Zeit hätten höchstens die Anker erkannt, auf Stunden genau. Stand der Technik (veröffentlicht). Authentifizierte Zeitsynchronisation mit NTS (RFC 8915); die Norm ETSI EN 319 421 sieht vor, die Ausgabe von Zeitstempeln nach einem Verlust der Synchronisation mit UTC auszusetzen (Sigelith unterliegt dieser Norm nicht und erklärt keine Konformität mit ihr); RFC 3161 - die Zeit eines Zeitstempels ist so viel wert wie die Uhr der Stelle. Kriterium (falsifizierbar). Ein neuer Eintrag und ein neuer Checkpoint entstehen nur dann, wenn die letzte erfolgreiche Messung der Uhr höchstens 15 Minuten alt ist und die Abweichung 0,25 s nicht überschreitet; andernfalls lehnt der Dienst ab (Code 503, clock_untrusted) und erfasst nichts. Widerlegt wird es durch einen einzigen Eintrag, der außerhalb dieser Bedingungen erfasst wurde. Methode. Seit dem 6. Oktober 2026 misst der Dienst alle 5 Minuten selbst die Abweichung seiner Uhr über NTS gegenüber den Servern der PTB (Physikalisch-Technische Bundesanstalt, das nationale Metrologieinstitut Deutschlands), und wenn beide nicht erreichbar sind - gegenüber Netnod. Jeder Versuch wird erfasst; die letzte Messung ist öffentlich (/api/health/, Seite /evidence/), und das PDF-Zertifikat eines Eintrags nennt die letzte Messung vor dem Eintrag („Server clock“). Früher erfasste Einträge ändert die Sperre nicht. Ergebnis. Umgesetzt; punktuelle Messungen: am 6. Oktober eine Abweichung unter 0,1 ms bei einer Verzögerung von 9 ms, am 9. Oktober 0,2 ms. Randbedingungen: (a) Die Messung ist eine Angabe des Betreibers über seine eigene Messung, keine Bestätigung der PTB - die PTB weist selbst darauf hin, dass NTS keine rechtsverbindliche Zeitinformation liefert; (b) die Historie der Messungen ist nicht öffentlich, und dass die Sperre funktioniert, ist das Wort des Betreibers - einen öffentlichen Indikator ihres Zustands gibt es nicht; (c) ein Angreifer auf dem Übertragungsweg kann die Messung höchstens um die Hälfte der Umlaufzeit verschieben, in der Praxis um Millisekunden; (d) unabhängig von dieser Messung prüfen die Mitunterzeichner (Richtung 1, mit einer Toleranz von ±30 s) und die Anker die Zeit eines Eintrags. Nächster Schritt. Klären, ob und wie die Historie der Messungen und der Zustand der Sperre veröffentlicht werden sollen, sodass sie sich ohne Rückfrage beim Betreiber prüfen lassen. Status: umgesetzt seit dem 6. Oktober 2026.

3. Richtung 3 - negative Ergebnisse und Korrekturen seit dem 1. Oktober

(a) Das Zugriffsprotokoll erlaubte es, einen Stempel mit einem Netz und einem Browser zu verknüpfen. Die Zeit eines Eintrags ist auf die Mikrosekunde genau öffentlich, und das Zugriffsprotokoll des Webservers erfasste die Zeit der Anfrage, das /24-Netz und den User-Agent-Header; der Anwendungsserver erfasste zusätzlich die vollständigen Anfrage-URLs samt Fingerabdrücken. Im Nachhinein ließ sich ein Stempel also dem Netz und dem Browser der Person zuordnen, die ihn ausgeführt hatte. Negatives Ergebnis: Das Fehlen eines Kontos und einer E-Mail-Adresse reichte nicht aus, um zu verhindern, dass sich ein Stempel mit jemandem verknüpfen ließ. Korrektur vom 9. Oktober 2026: Zugriffsprotokoll ohne IP-Adresse, Port und Anfrage-Header (von der verweisenden Seite bleibt nur die Domain), Anwendungsserver ohne Zugriffsprotokoll, ein Filter, der jeden 64-stelligen Fingerabdruck aus Meldungen herausschneidet, Zähler der Anfragelimits ausschließlich im Prozessspeicher; nach der Umsetzung geprüft. Randbedingung: Der Betreiber, der den Server kontrolliert, kann diese Einstellungen jederzeit ändern - wer Anonymität auch ihm gegenüber braucht, sollte über Tor stempeln (Verbindungen über Tor landen in keinem Zugriffsprotokoll). (b) Die PHP-Bibliothek hielt eine Ablehnung für einen Stempel. Die PHP-Bibliothek für Plugins prüfte den HTTP-Statuscode nicht: Antworten mit 400, 429 und 503 ergaben ein Ergebnis, das wie ein erfolgreicher Stempel aussah. Der Fehler wog umso schwerer, als der Dienst seit dem 6. Oktober bewusst mit dem Code 503 antwortet, wenn er seiner Uhr nicht traut (Richtung 2). Gefunden bei einer internen Durchsicht am 6. Oktober, behoben am 19. Oktober: Jede Antwort mit 4xx und 5xx wird als Fehler mit dem HTTP-Code gemeldet. Das ist dieselbe Fehlerklasse wie bei der Durchsicht des Desktop-Clients (Eintrag vom 2026-10-01, Richtung 5) - etwas als ausgeführt anzuzeigen, was nicht ausgeführt wurde. (c) Sätze, die stärker waren als das System - korrigiert nach der externen Begutachtung vom 7. Oktober. Der externe Gutachter reproduzierte den kryptografischen Kern allein anhand der öffentlichen Spezifikation und wies zugleich auf Sätze hin, die mehr versprachen, als das System gewährleistet. Am selben Tag korrigiert: (1) „Überprüfbar, ohne jemandem vertrauen zu müssen - auch uns nicht“ wurde durch „Überprüfbar, ohne uns aufs Wort glauben zu müssen“ ersetzt: Das Prüfprogramm im Browser kommt von unserem Server, unabhängig prüft man mit dem quelloffenen Programm Sigelith Desktop oder mit dem Verfahren für Sachverständige; (2) Bitcoin und die Archive kann jeder ohne uns prüfen, die Bestätigung der Überweisung mit der Wurzel geben wir aber auf Anfrage heraus, und die Bank bestätigt sie auf Ersuchen eines Gerichts; (3) GitHub steht nicht mehr auf der Liste der „Parteien, die wir nicht kontrollieren“ - die Releases liegen in unserem Konto; (4) bei Konveria wurde ergänzt, dass es sich um ein unabhängiges Unternehmen ohne personelle oder kapitalmäßige Verbindungen zum Betreiber handelt; (5) die Spezifikation sagt ausdrücklich, dass sich die Erfassung eines Eintrags nur zu einem späteren Zeitpunkt hin verzögern kann, nie zu einem früheren, und dass der Server keine Schlüssel der Mitunterzeichner hat. Status: Korrekturen umgesetzt.

4. Richtung 4 - Hourglass: ein Nachweis der mindestens verstrichenen Zeit (in Arbeit)

Problem. Die Anker liefern eine Obergrenze der Zeit, der in einem Checkpoint genannte Bitcoin-Block eine Untergrenze. Nichts belegt dagegen, wie viel Zeit zwischen zwei Ereignissen im Log verstrichen ist, unabhängig von Uhren - weder von unserer noch von denen der Mitunterzeichner. Stand der Technik (veröffentlicht). Nachweise sequenzieller Arbeit (B. Cohen, K. Pietrzak, Simple Proofs of Sequential Work, EUROCRYPT 2018). Verifizierbare Verzögerungsfunktionen (VDF) lassen sich im Random-Oracle-Modell nicht allein aus Hashfunktionen konstruieren; der Preis einer Konstruktion, die ausschließlich auf Hashes beruht, besteht darin, dass die Prüfung nur die Ausführung eines Teils der Arbeit garantiert. Kriterium (falsifizierbar). Zwischen zwei Ereignissen ist mindestens die Zeit verstrichen, die sich aus der Zahl der ausgeführten Schritte ergibt - unter der offen genannten Annahme k, dass niemand diese Arbeit mehr als k-mal schneller berechnet als der gemessene Prover. Widerlegt wird es durch Hardware, die schneller rechnet als das angenommene k. Methode. Seit dem 19. Oktober 2026 berechnet der Server des Dienstes Sigelith Hourglass - einen Nachweis sequenzieller Arbeit nach Cohen und Pietrzak auf SHA-256, in Abschnitten, auf einem einzigen Prozessorkern. In den Startwert jedes Abschnitts fließen ein frischer Bitcoin-Block und der letzte Checkpoint von Sigelith ein, und jeder Abschnitt knüpft an die Wurzel des vorigen an; der Datensatz des Abschnitts wird im Log gestempelt und von den Mitunterzeichnern bestätigt. Die Konstruktion von Cohen und Pietrzak setzen wir getreu um; neu sind das System und die Messungen. Spezifikation, Referenzimplementierung und Code sind öffentlich (github.com/DeiFlagellum/sigelith-hourglass, Apache-2.0). Ergebnis. Noch keines - Phase 0 ist eine 30-tägige Messung auf dem Produktivserver (Genesis gestempelt als Eintrag Nr. 453, Ende am 18. November 2026). Bis zu ihrem Ende ist k = 20 eine Annahme, und nichts aus Phase 0 gelangt auf die Zertifikate. Vorab genannte Randbedingungen: (a) ausschließlich Untergrenzen, und zwar bescheidene - bei k = 20 würde eine Woche an Abschnitten etwa 6 Stunden belegen; (b) Hourglass wird von einem einzigen Betreiber berechnet - die Uhr lässt sich anhalten; eine unbemerkte Fälschung schließen erst öffentlich zugängliche Abschnitte aus, weil dann jeder zwei verschiedene Wurzeln eines Abschnitts sehen würde; (c) die Dateien der Abschnitte werden noch nicht veröffentlicht, sodass ein Dritter heute nur prüfen kann, dass im Log die Fingerabdrücke der Abschnittsdatensätze erfasst wurden, nicht aber den Nachweis der Arbeit selbst. Nächster Schritt. Nach dem 18. November: Auswertung der Messung, eine öffentliche Notiz, Parameter und Genesis der Version 1 - in einem eigenen Eintrag. Status: in Arbeit (Phase 0).

Stand der Schritte, die am 1. Oktober angekündigt wurden

Korrekturen zum Eintrag vom 2026-10-01

Der Eintrag vom 2026-10-01 bleibt unverändert. Im Folgenden seine Aussagen, die veraltet sind oder nicht genau waren.

Richtung 1, „Nächster Schritt“: Signaturen unabhängiger Zeugen als offene Frage. Veraltet seit dem 6. Oktober 2026 (Richtung 1 dieses Eintrags).

Richtung 1, Randbedingungen: „eine Rotation verlangt heute die Änderung der Schlüsselliste an drei Stellen“. Veraltet: Die öffentlichen Schlüssel sind heute auch im Modul der Seite /proof/, in der PHP-Bibliothek und in Sigelith Backup hinterlegt, sodass eine Rotation Änderungen an mehr Stellen und neue Versionen verlangt.

Richtung 2, Methode und „Status der Richtung“: GitHub unter den Kopien bei Dritten. Ungenau: Die Releases bei GitHub sind unveränderlich, liegen aber im Konto des Betreibers, und das ganze Repository lässt sich löschen. GitHub bewahrt eine Kopie außerhalb unserer Infrastruktur auf, nicht außerhalb unserer Kontrolle.

Richtung 2, Randbedingung (c): „gegenzeichnende Zeugen gibt es nicht“. Veraltet seit dem 6. Oktober 2026.

Richtung 2, Randbedingung (f): Browserseiten übernehmen den Log-Teil aus der Serverantwort. Veraltet für die Seite /proof/: Seit dem 19. Oktober berechnet sie die Quittung, den Pfad zur signierten Wurzel und die Signaturen der Mitunterzeichner selbst.

Richtung 3, Methode: „der Dienst misst außerdem alle fünf Minuten seinen Offset gegenüber einem externen Server und veröffentlicht das Ergebnis“. Ungenau seit dem 6. Oktober: Das veröffentlichte Ergebnis ist heute die letzte authentifizierte Messung gegenüber der PTB, die neue Einträge sperrt (Richtung 2 dieses Eintrags); die Historie der Messungen ist nicht öffentlich.

„Status der Richtung“: „Nächste Schritte: ein eigenständiges Prüfskript für Dritte und die Entscheidungen aus Richtung 4“. Das Skript wurde durch das Verfahren für Sachverständige ersetzt (siehe „Stand der Schritte“); die Entscheidungen aus Richtung 4 bleiben offen. Zeitkapseln und das Protokoll für Zustellnachweise warten weiterhin auf einen eigenen Eintrag.

Status der Richtung. Den Zustand des Logs bestätigen seit dem 6. Oktober zwei Mitunterzeichner mit eigener Uhr, und seit dem 19. Oktober werten die Prüfseite und die PHP-Bibliothek die Regel „2 aus 3“ selbst aus. Der Dienst stellt das Stempeln ein, wenn er den Fehler seiner Uhr nicht kennt. Nächste Schritte: Messung der Verfügbarkeit der Mitunterzeichner, Prüfung ihrer Signaturen im Desktop-Client, die Ergebnisse der Phase 0 von Hourglass (nach dem 18. November 2026) und eine Entscheidung über die Veröffentlichung der Messhistorie der Uhr.

Zeitnachweis

Dieser Text wurde bei der Veröffentlichung gehasht und gestempelt. Zur Prüfung sind beide Dateien nötig: der Stempel belegt, dass genau eine Bytefolge zu diesem Zeitpunkt existierte, und nur die Quelle unten ist diese Bytefolge. Jede spätere Änderung verschiebt den Hash und bricht die Übereinstimmung — genau das ist der Zweck.

· @390.24 · 2026-W46

SHA-256 des gestempelten Textes: 98f9b984c9299515d216ba8ace32d5d2460e38f30d498c60672fef9a51070fa4

Prüfen mit: ots verify <Nachweis> --file <Quelle>