Einen Wakir-Labs-Commit verifizieren

Commits in diesem Repository — und in unserer internen Governance-Historie — werden über OpenTimestamps gegen die Bitcoin-Blockchain zeitgestempelt. Der Beweis ist eine kleine .ots-Datei, die neben dem Commit-Hash eingecheckt wird. Mehr braucht es nicht: Mit einem Commit-Hash und der passenden .ots-Datei lässt sich ohne Vertrauen in uns belegen, dass der Commit spätestens zum Zeitpunkt eines bestimmten Bitcoin-Blocks existiert hat.

Das ist die öffentliche Seite von Proof-of-History in der Praxis. Genau das meinen wir, wenn wir sagen, unsere Dokumentation sei verankert.

Was abgedeckt ist

In diesem Repository tragen alle 60 Beweisdateien eine Bitcoin-Attestierung — einen Block, keine Kalender-Zusage. 46 davon haben diesen Stand erst am 2026-09-15 erreicht; sie lagen seit Mai unbestätigt auf den Calendar-Servern. Nachgeprüft am 2026-09-20.

Die drei Code-Repositories tragen keine. wakir-runtime, wakir-protocol und wakir-verify haben gar kein meta/timestamps/-Verzeichnis (gemessen am 2026-09-15). Eine frühere Fassung dieser Seite behauptete, jeder Commit in jedem Wakir-Labs-Repository sei zeitgestempelt. Das stimmte nicht. Ob die Stempelung auf diese Repositories ausgeweitet wird, ist offen; bis dahin beschreibt diese Seite, was es gibt.

Drei Schritte

1. OpenTimestamps-Client installieren

Der Referenz-Client heißt ots und kommt als Python-Paket. Auf jeder Plattform mit Python 3.8 oder neuer:

pip install opentimestamps-client

Installation prüfen:

ots --version

2. Commit und `.ots`-Beweis besorgen

Klone das Repository, das du prüfen willst. Die Beweisdateien liegen unter meta/timestamps/<short-hash>.ots:

git clone https://github.com/wakir-labs/site.git
cd site
ls meta/timestamps/

Jede Datei ist die Attestierung für genau einen Commit, benannt nach dessen Kurz-Hash.

Nicht jede Datei nennt einen Commit, den Du auschecken kannst. Gemessen am 2026-09-20: Von 60 Beweisdateien lösen 28 in einem einfachen Klon auf. Der Rest wurde auf Branch-Commits gestempelt, die der Squash-Merge ersetzt hat — der Hash überlebt im Dateinamen, nicht in der Historie von main. Nimm eine, die auflöst; das Beispiel unten gehört dazu:

for f in meta/timestamps/*.ots; do
  h=$(basename "$f" .ots)
  git rev-parse --verify --quiet "$h" >/dev/null && echo "$h"
done

3. `ots verify` ausführen

Als durchgerechnetes Beispiel der Commit 82d40f7 aus der Historie dieser Site ("feat(about): add EN+DE about pages"):

# Aus dem geklonten Repo heraus:
printf "%s\n" "$(git rev-parse 82d40f7)" > /tmp/commit.txt
ots verify -f /tmp/commit.txt meta/timestamps/82d40f7.ots

Gestempelt wird der 40-stellige Commit-Hash als ASCII-Text mit abschließendem Zeilenumbruch — genau das schreibt printf "%s\n". Zwei frühere Fassungen dieser Seite verlangten stattdessen die rohen Hash-Bytes (xxd -r -p). Das ist nicht, was gestempelt wurde, und ots weist es ab: File does not match original!. Aufgefallen ist es am 2026-09-15, als das Beispiel dieser Seite von vorne bis hinten ausgeführt wurde. Beide veröffentlichten Formen sind korrigiert.

Eine erfolgreiche Verifikation gibt etwa aus:

Success! Bitcoin block N attests existence as of YYYY-MM-DD

Das ist die Quittung. Der Commit existierte spätestens zum Zeitpunkt dieses Bitcoin-Blocks. Vertrauen in uns braucht es dafür nicht — nur in Bitcoin und in die OpenTimestamps-Calendar-Server, die selbst nur signieren und nicht rückdatieren.

Das Firmen-Repository

Das vollständige Firmen-Repository — ADRs, Aktivitätsprotokoll, Governance — liegt bislang nur beim Aufsichtsrat und ist nicht öffentlich. Öffentlich prüfbar sind deshalb heute die wakir-labs/*-Repositories auf GitHub (github.com/wakir-labs). Sobald das Firmen-Repository öffentlich wird, gilt dasselbe Rezept: klonen, ots verify auf Beweisdatei und Commit-Hash ansetzen, Quittung lesen.

Der Aufsichtsrat prüft seinen lokalen Klon auf genau demselben Weg.

Schritt 3 braucht einen Bitcoin-Node — oder einen zweiten Befehl

ots verify kommt ohne Node nicht zum Ende. Gemessen am 2026-09-20 gegen opentimestamps-client 0.7.2, also genau die Version aus dem pip install oben: Das Paket enthält keinerlei Block-Explorer-Pfad, und der Verify-Weg ruft setup_bitcoin() bedingungslos auf, was ohne antwortenden Node mit Exit 1 endet. Eine frühere Fassung dieser Seite behauptete einen Rückgriff auf einen Remote-Block-Explorer. Den gibt es nicht.

Ohne Node hilft ots info — der Befehl braucht keinen Chain-Zugriff und nennt den Bitcoin-Block, auf den sich der Beweis festlegt:

ots info meta/timestamps/82d40f7.ots | grep BitcoinBlockHeaderAttestation

Diese Blockhöhe in einem beliebigen Bitcoin-Explorer nachschlagen und den Zeitstempel des Blocks lesen. Das ist dieselbe Tatsache, die ots verify bestätigen würde — nur vertraust Du dabei dem Explorer statt selbst zu prüfen.

Mit eigenem Node macht der Client die ganze Kette selbst:

ots --bitcoin-node http://user:pass@127.0.0.1:8332 verify -f /tmp/commit.txt meta/timestamps/82d40f7.ots

Damit fällt die letzte Vertrauensannahme: Die Attestierung wird direkt aus einer Chain gelesen, die du selbst validierst.

Wenn die Verifikation fehlschlägt

Zwei normale Gründe:

Der Beweis ist noch "pending". Frische Commits liegen einige Stunden auf den Calendar-Servern, bevor sie in einen Bitcoin-Block einfließen. Nach ein paar Stunden ots upgrade meta/timestamps/<hash>.ots ausführen, dann erneut verifizieren.
Du hast das Falsche gehasht. Gestempelt wird der 40-stellige Commit-Hash als ASCII-Text mit abschließendem Zeilenumbruch. Erzeuge ihn mit printf "%s\n" "$(git rev-parse <commit>)" — nicht mit xxd -r -p. Frühere Fassungen dieser Seite empfahlen Letzteres; sie lagen falsch.

Greift keiner der beiden Gründe, öffne ein Issue. Eine fehlgeschlagene Verifikation an einem echten Commit ist ein Befund, den wir wissen wollen.

Read in English.