Einen Wakir-Labs-Commit verifizieren

Jeder Commit in den Wakir-Labs-Repositories wird per OpenTimestamps gegen die Bitcoin-Blockchain zeitgestempelt. Der Beweis ist eine kleine .ots-Datei, die zusammen mit dem Commit-Hash eingecheckt wird. Mit diesen beiden Dingen — einem beliebigen Commit-Hash aus unserer Historie und der zugehörigen .ots-Datei — kann jede:r ohne Vertrauen in uns nachweisen, dass der Commit zum Zeitpunkt eines bestimmten Bitcoin-Blocks bereits existierte.

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

Drei Schritte

1. OpenTimestamps-Client installieren

Der Referenz-Client ist ots, ausgeliefert als Python-Paket. Auf jeder Plattform mit Python 3.8+:

pip install opentimestamps-client

Installation prüfen:

ots --version

2. Commit und `.ots`-Beweis besorgen

Klone das zu verifizierende Repository. Die Proof-Dateien 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 .ots-Attestierung für genau einen Commit, benannt nach dem Short-Hash.

3. `ots verify` ausführen

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

# Aus dem geklonten Repo heraus:
git rev-parse 82d40f7 | xxd -r -p > /tmp/commit.bin
ots verify -f /tmp/commit.bin meta/timestamps/82d40f7.ots

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 ist nicht nötig — nur in Bitcoin und in die OpenTimestamps-Calendar-Server (die selbst nur signieren, nicht rückdatieren können).

Wo die Quelle der Wahrheit liegt

Das vollständige Corporate-Repository — ADRs, Activity-Log, Governance — liegt aktuell lokal beim Aufsichtsrat und ist noch nicht öffentlich. Öffentliche Verifikation umfasst deshalb heute die wakir-labs/*-Repositories auf GitHub (github.com/wakir-labs). Sobald das Corporate-Repository öffentlich wird, gilt dasselbe Rezept: klonen, ots verify auf .ots-Datei und Commit-Hash anwenden, Quittung lesen.

Mitglieder des Aufsichtsrats verifizieren gegen ihren lokalen Klon des Corporate-Repository auf dieselbe Weise.

Fortgeschritten: Verifikation gegen eigenen Bitcoin-Node

Standardmäßig sprechen die OpenTimestamps-Tools mit öffentlichen Calendar-Servern und, für die Bitcoin-Attestierung, mit einem Remote-Block-Explorer. Mit eigenem Bitcoin-Node lässt sich der Proof Ende-zu-Ende gegen die selbst validierte Chain prüfen:

ots --bitcoin-node http://user:pass@127.0.0.1:8332 verify -f /tmp/commit.bin 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 Proof ist "pending". Frische Commits liegen einige Stunden in den Calendar-Servern, bevor sie in einem Bitcoin-Block aggregiert werden. Nach ein paar Stunden ots upgrade meta/timestamps/<hash>.ots ausführen, dann erneut verifizieren.
Falsches Eingangs-Hashing. Unser Hook stempelt den rohen 32-Byte-Commit-Hash. Es müssen Binär-Bytes übergeben werden (xxd -r -p), nicht der ASCII-Hex-String.

Wenn keiner der beiden Gründe greift, öffne ein Issue. Eine fehlgeschlagene Verifikation auf einem echten Commit ist ein Finding, das wir wissen wollen.

Read in English.