Das dreitägige Challenge-Fenster wirkt zwar nicht zu kurz, aber sobald wirklich eine Ausnahme auftritt, wird die Zeit durch Materialrecherche, Statusprüfung und die Übergabe der Verantwortung schnell aufgezehrt. Nutzer können direkte Challenges gegen ungültige Anträge stellen – das zeigt nur, dass die Regeln einen Einstieg bieten, aber bedeutet nicht, dass dieser Einstieg jederzeit verfügbar ist.
In dem öffentlichen Testnetz von Trustless Bitcoin Vaults (TBV) mit der Nummer @BabylonLabs_io sind die registrierten Challenger dafür verantwortlich, die Rücknahmebeweise zu überwachen. Nach dem Speichern der notwendigen Materialien kann auch der Depositor eine Challenge gegen einen ungültigen Beweis anstoßen. Bitcoin-Skripte können Ethereum-Ereignisse nicht direkt verstehen, daher muss die Challenge weiterhin auf dem bestehenden Beweismechanismus und den korrekten Materialien beruhen. Das aktuelle Fenster umfasst 432 Bitcoin-Blöcke, also etwa 3 Tage. Nachdem der Antragsteller angegriffen wurde, bleiben ihm noch etwa 108 Blöcke, um zu widersprechen – alles sind lediglich Parameter des Testnetzes.
Was die Notfall-Fähigkeit wirklich beeinflusst, ist, ob Anomalien rechtzeitig sichtbar werden. Entscheidend ist, an wen das Monitoring geht, wie die Warnmeldung den Nutzer erreicht, ob die Materialien mit dem entsprechenden Vault übereinstimmen und wer nach Erhalt der Warnung für die Einreichung der Aktion verantwortlich ist. Wenn diese Verantwortlichkeiten im Alltag nicht verankert wurden, verlieren die On-Chain-Rechte im Countdown langsam ihre Bedeutung. Nutzer müssen nicht rund um die Uhr auf der Kette bleiben, aber sie dürfen nicht davon ausgehen, dass immer jemand anders das Problem für sie entdeckt.
Wenn das Protokoll watchtowers oder einen Warnmelde-Einstieg bereitstellt, sollte es den Nutzer außerdem darüber informieren, welche Abdeckung gilt und wo die Grenzen des Versagens liegen. Tools helfen bei der Reaktion, übernehmen aber nicht die endgültige Verantwortung. Das ist auch eine Ebene, die in der Sicherheits-Erzählung der #baby leicht übersehen wird: Das Challenge-Recht reduziert die völlige Abhängigkeit von den registrierten Rollen, gibt jedoch einen Teil des Monitorings und der Vorbereitungsaufgaben an die Nutzer zurück.
Wenn man die Sicherheitsdiskussion rund um $BABY nur nach der Anzahl der Rechte zählt, übersieht man dennoch, ob Tooling, Materialien und der Reaktionsablauf die Aufgabe wirklich übernehmen können. Derzeit gibt es keine Protokolle zu persönlichen Challenge-Aktionen, daher kann man die Wege auf Papier nicht als bereits verifiziert und ausgereift darstellen. Realistischer ist die Einschätzung: Kann man die Vorbereitung noch vor dem Notfall abschließen und, wenn die Anomalie auftritt, innerhalb des Fensters die Rechte in tatsächliche Aktionen umsetzen? Wenn die Materialien am falschen Ort liegen, niemand die Warnung abholt und die Regeln noch so schön formuliert sind, kann man dem Nutzer damit keine Zeit abtrotzen.
In dem öffentlichen Testnetz von Trustless Bitcoin Vaults (TBV) mit der Nummer @BabylonLabs_io sind die registrierten Challenger dafür verantwortlich, die Rücknahmebeweise zu überwachen. Nach dem Speichern der notwendigen Materialien kann auch der Depositor eine Challenge gegen einen ungültigen Beweis anstoßen. Bitcoin-Skripte können Ethereum-Ereignisse nicht direkt verstehen, daher muss die Challenge weiterhin auf dem bestehenden Beweismechanismus und den korrekten Materialien beruhen. Das aktuelle Fenster umfasst 432 Bitcoin-Blöcke, also etwa 3 Tage. Nachdem der Antragsteller angegriffen wurde, bleiben ihm noch etwa 108 Blöcke, um zu widersprechen – alles sind lediglich Parameter des Testnetzes.
Was die Notfall-Fähigkeit wirklich beeinflusst, ist, ob Anomalien rechtzeitig sichtbar werden. Entscheidend ist, an wen das Monitoring geht, wie die Warnmeldung den Nutzer erreicht, ob die Materialien mit dem entsprechenden Vault übereinstimmen und wer nach Erhalt der Warnung für die Einreichung der Aktion verantwortlich ist. Wenn diese Verantwortlichkeiten im Alltag nicht verankert wurden, verlieren die On-Chain-Rechte im Countdown langsam ihre Bedeutung. Nutzer müssen nicht rund um die Uhr auf der Kette bleiben, aber sie dürfen nicht davon ausgehen, dass immer jemand anders das Problem für sie entdeckt.
Wenn das Protokoll watchtowers oder einen Warnmelde-Einstieg bereitstellt, sollte es den Nutzer außerdem darüber informieren, welche Abdeckung gilt und wo die Grenzen des Versagens liegen. Tools helfen bei der Reaktion, übernehmen aber nicht die endgültige Verantwortung. Das ist auch eine Ebene, die in der Sicherheits-Erzählung der #baby leicht übersehen wird: Das Challenge-Recht reduziert die völlige Abhängigkeit von den registrierten Rollen, gibt jedoch einen Teil des Monitorings und der Vorbereitungsaufgaben an die Nutzer zurück.
Wenn man die Sicherheitsdiskussion rund um $BABY nur nach der Anzahl der Rechte zählt, übersieht man dennoch, ob Tooling, Materialien und der Reaktionsablauf die Aufgabe wirklich übernehmen können. Derzeit gibt es keine Protokolle zu persönlichen Challenge-Aktionen, daher kann man die Wege auf Papier nicht als bereits verifiziert und ausgereift darstellen. Realistischer ist die Einschätzung: Kann man die Vorbereitung noch vor dem Notfall abschließen und, wenn die Anomalie auftritt, innerhalb des Fensters die Rechte in tatsächliche Aktionen umsetzen? Wenn die Materialien am falschen Ort liegen, niemand die Warnung abholt und die Regeln noch so schön formuliert sind, kann man dem Nutzer damit keine Zeit abtrotzen.