Das Double Responsibility Problem
Warum Seed-Backups im Alltag scheitern und warum das kein Fehler von dir ist.
Das Double Responsibility Problem
Du hast eine Lösung. Irgendwo liegt ein Zettel, eine Metallplatte, ein Umschlag im Notfall-Ordner. Du hast dir dabei etwas gedacht. Und trotzdem ist da dieses Unbehagen, das sich nicht ganz abschütteln lässt. Das ist keine Frage von Intelligenz oder Sorgfalt. Es ist eine Frage von Belastbarkeit. Das Problem, das du lösen willst, hat zwei Gesichter. Und die arbeiten gegeneinander.
Zwei Ängste. Eine Quelle. Keine Lösung
Die meisten kennen die erste. Die zweite ist die gefährlichere.
Die erste ist offensichtlich:
Wenn das jetzt weg wäre — wirklich weg — das wäre echt schmerzhaft.
Feuer, Wasserschaden, Umzug, ein unaufmerksamer Moment. Seed Phrase weg, Bitcoin weg, keine Rückbuchung, kein Support-Ticket.
Die zweite ist leiser, aber sitzt tiefer:
Was wenn jemand schon dran war und ich werde es erst erfahren, wenn die Wallet leer ist?
Kein Alarm, kein Einbruchsbericht, kein Beweis. Nur die Frage, die sich irgendwann aufdrängt:
Bin ich vielleicht schon kompromittiert?
Beide Ängste sind real. Und beide zeigen auf dieselbe Quelle: 12 bis 24 Wörter im Klartext, die gleichzeitig auffindbar und unsichtbar sein sollen.
Denn ein Seed-Backup sichert keine Daten. Es sichert Handlungsfähigkeit. Der Schaden ist endgültig und oft merkst du ihn erst, wenn es zu spät ist.
Das nennt sich das Double Responsibility Problem.
Das strukturelle Dilemma
Jeder Bitcoiner mit dem Anspruch Bitcoin in Selbstverwahrung zu sichern, hat dasselbe Dilemma. Die Herausforderung desselben liegt darin, dass das Backup immer Zugreifbar, aber gleichzeitig vor Verlust oder unauthorisierten Zugriff geschützt sein muss. Du hast das vermutlich schon selbst gespürt, auch ohne es so zu benennen.
Also mehr Redundanz? Redundanz senkt das Verlustrisiko aber vergrößert die Angriffsfläche. Jede zusätzliche Kopie ist ein weiterer Ort, an dem jemand zufällig vorbeikommen kann - egal, ob analog oder digital.
Oder mehr Abschottung? Abschottung senkt das Zugriffsrisiko, erhöht aber die Chance, dass im Notfall, im Erbfall oder unter Stress das Backup nicht mehr auffindbar oder rekonstruierbar ist.
Du kannst eine Seite verbessern. Aber nur auf Kosten der anderen. Und mit jedem Jahr, mit jedem neuen Preis-Allzeithoch, mit jedem Freund der von einem Vorfall erzählt, wird das Gefühl schwerer:
Mein Stack wird immer wertvoller. Meine Verantwortung steigt. Ich muss handeln. Aber wie?
Dazu kommt eine dritte Frage, die fast niemand laut stellt:
Was passiert mit meinen Bitcoin, wenn ich nicht mehr erreichbar bin? Jemanden einweihen? Wen? Wie viel kann ich zeigen?
Die wenigsten haben darauf eine Antwort, die sich wirklich rund anfühlt.
Warum jede weitere Schicht das Problem verlagert
Also probiert man es mit mehr: mehr Redundanz, mehr Verstecken, mehr Absicherung.
Metallplatte? Überlebt Säuren, Feuer und Wasser, aber wer sie findet, liest sie genauso wie Papier. Das Verlustrisiko sinkt. Das Zugriffsrisiko bleibt.
Eigene Cipher-Tabelle? Grundsätzlich solid. Aber jetzt muss die Tabelle selbst irgendwo sicher liegen. Verlierst du sie, ist das Backup wertlos. Kopierst du sie, hast du dasselbe Problem eine Ebene tiefer.
Noch mehr Schichten? Passphrase, Splits, Hinweise, Referenzen. Jede neue Schicht schützt die darunter und ist eine weitere Sache, die in zehn Jahren noch stimmen muss. Unter Stress. Im Erbfall. Ohne dich.
Risiko wird nicht entfernt, sondern umgebaut — von Angriff zu Komplexität.
Das Setup wird theoretisch stärker. Praktisch fragiler. Weil Sicherheit, die auf dauerhafter Disziplin beruht, genau dann bricht, wenn sie gebraucht wird.
Die relevante Frage ist deshalb nicht: Ist mein Setup theoretisch sicher?
Sondern:
- » Ist es im Ernstfall wirklich verfügbar?
- » Funktioniert es noch in zehn oder zwanzig Jahren?
- » Und kann das jemand anderes nachvollziehen, wenn ich es nicht mehr kann?
Was passiert, wenn man das Dilemma nicht löst, sondern aufteilt
Was wäre, wenn du gar nicht mehr versuchst, beide Seiten des Dilemmas allein zu tragen?
Das Dilemma entsteht, weil du gleichzeitig für Verfügbarkeit und Vertraulichkeit zuständig bist. Das ist keine Frage der Disziplin. Es ist eine Frage der Struktur.
Die Antwort ist keine weitere Schicht. Sie ist eine andere Verteilung: zwei unabhängige Parteien, jede trägt genau eine Seite. Keine hat das vollständige Geheimnis. Und was keine Partei allein hat, kann keine Partei allein kompromittieren.
Ein einzelner Fund darf keinen ROI haben.
Das verändert die Logik des Angriffs grundlegend: Wer nur einen Teil findet, hat nichts Vollständiges. Der stille, spurlose Zugriff verliert seinen Wert.
So setzen wir dieses Prinzip um:
Wir (Fortego GmbH) sind ein Recovery-Service — wir nehmen dir nicht die Seed Phrase ab, sondern den Konflikt zwischen „niemals verlieren" und „niemals exponieren".
Du erstellst deine chiffrierte Backupkarte — deine 12 bis 24 Wörter als Ersatzwörter, basierend auf deiner persönlichen Chiffriertabelle, dem CodeBook. Ohne das CodeBook ist die Karte nichts wert und umgekehrt. Wir verwahren dein CodeBook verschlüsselt in eigenen Systemen — strukturell unmöglich zu entschlüsseln, auch im Fall eines Hacks. Wie wir unser System absichern, erklären wir in unserem Artikel zur Sicherheitsarchitektur.
Nur deine Backupkarte und dein CodeBook zusammen ermöglichen ein Recovery.
Was das konkret bedeutet: Du kannst die Backupkarte zehn Mal kopieren. Überall hinlegen. Für den Erbfall offen mitgeben. Das Verlustrisiko sinkt durch Redundanz, ohne dass die Angriffsfläche mitwächst.
Das Double Responsibility Problem bleibt bestehen. Aber es wird auf zwei unabhängige Schultern aufgeteilt:
- » Du trägst Verfügbarkeit.
- » Fortego trägt Vertraulichkeit.
Kein neues Setup. Kein Wechsel. Nur eine andere Struktur.
Fortego legt sich neben das, was du schon hast — egal ob Singlesig, Passphrase oder Multisig. Kein Wallet-Wechsel, kein Coin-Transfer. Einfach die Recovery-Schicht, die danebenexistiert.
Für den Fall, den niemand plant, aber immer eintritt.
Fragen? Sprich uns direkt an..