WOTS kann nur einmal verwendet werden, und das Backup-Management muss genau bis auf jede einzelne Vault erfolgen
Jede Vault verpflichtet sich beim Peg-in, einen öffentlichen Schlüssel für eine Winternitz One-Time Signature (WOTS) bereitzustellen; der private Schlüssel wird für die Self-Claim-Autorisierung des Einzahlers verwendet. Das „Einmalige“ in Trustless Bitcoin Vaults (TBV) ist kein Marketing-Begriff: Ein und derselbe WOTS-Schlüssel kann nicht als allgemeiner Wiederherstellungs-Schlüssel für mehrere Vaults genutzt werden und lässt sich auch nicht – wie eine Seed-Phrase – beliebig oft wiederverwenden.
Das führt zu einer sehr konkreten operativen Last. Wenn Nutzer ihre Tresore aufteilen, verbessert das zwar die Abwicklungs-Granularität, erhöht aber zugleich die Anzahl der Schlüsseldateien; wenn Backups nur nach Datum benannt werden, ohne Vault-ID, ist es in einem Notfall-Levorgang leicht, die falsche Datei zu greifen. Falsche Dateien stehlen nicht BTC, können aber dazu führen, dass ein ursprünglich ausführbarer Backup-Pfad zum Stillstand kommt.
Praktischer ist es, in einen Offline-Index Dateinamen, Vault-ID, Ziel-Payout-Adresse und Erstellzeit zu schreiben und regelmäßig die Entschlüsselbarkeit zu verifizieren – statt die Schlüssel tatsächlich zu verbrauchen. Das Produkt sollte außerdem vor dem Self-Claim Konsistenzprüfungen durchführen und Fehlzuordnungen frühzeitig melden. Selbstverwahrung ist nicht „Datei heruntergeladen und fertig“, sondern bedeutet: Auch nach sechs Monaten muss noch immer die einzigartige Datei an die richtige Transaktion übergeben werden können. Beachtet @BabylonLabs_io , Projekt-Token $BABY ; nur TBV.“#baby
Jede Vault verpflichtet sich beim Peg-in, einen öffentlichen Schlüssel für eine Winternitz One-Time Signature (WOTS) bereitzustellen; der private Schlüssel wird für die Self-Claim-Autorisierung des Einzahlers verwendet. Das „Einmalige“ in Trustless Bitcoin Vaults (TBV) ist kein Marketing-Begriff: Ein und derselbe WOTS-Schlüssel kann nicht als allgemeiner Wiederherstellungs-Schlüssel für mehrere Vaults genutzt werden und lässt sich auch nicht – wie eine Seed-Phrase – beliebig oft wiederverwenden.
Das führt zu einer sehr konkreten operativen Last. Wenn Nutzer ihre Tresore aufteilen, verbessert das zwar die Abwicklungs-Granularität, erhöht aber zugleich die Anzahl der Schlüsseldateien; wenn Backups nur nach Datum benannt werden, ohne Vault-ID, ist es in einem Notfall-Levorgang leicht, die falsche Datei zu greifen. Falsche Dateien stehlen nicht BTC, können aber dazu führen, dass ein ursprünglich ausführbarer Backup-Pfad zum Stillstand kommt.
Praktischer ist es, in einen Offline-Index Dateinamen, Vault-ID, Ziel-Payout-Adresse und Erstellzeit zu schreiben und regelmäßig die Entschlüsselbarkeit zu verifizieren – statt die Schlüssel tatsächlich zu verbrauchen. Das Produkt sollte außerdem vor dem Self-Claim Konsistenzprüfungen durchführen und Fehlzuordnungen frühzeitig melden. Selbstverwahrung ist nicht „Datei heruntergeladen und fertig“, sondern bedeutet: Auch nach sechs Monaten muss noch immer die einzigartige Datei an die richtige Transaktion übergeben werden können. Beachtet @BabylonLabs_io , Projekt-Token $BABY ; nur TBV.“#baby