Ich nutze @BabylonLabs_io , die von mir selbst veröffentlichte SCRIPT-Risk-Framework, und habe die Parameter des TBV-Testnetzes einmal der Reihe nach gegengecheckt. Am interessantesten ist, dass es auf der einen Seite heißt: „Die Laufzeit von Sicherheiten soll ohne Erlaubnis erfolgen“, auf der anderen Seite aber eindeutig eine Notfall-Schwelle von 3/5 für den Security Council auflistet.
Das muss nicht zwingend ein Widerspruch sein, aber es ist genau der Spalt, an dem sich der echte Wert von „trustless“ überprüfen lässt.
SCRIPT verlangt sechs Dinge: Die Nutzer behalten die Souveränität, die Dispositionsregeln sind klar, ohne Zustimmung darf nicht erneut verpfändet werden, jede Position ist isoliert, Dritte können nicht überprüfen bzw. auslesen, und der Sicherheitenstatus ist transparent. Das ist wie bei einem Schließfach mit sechs Abnahmekriterien: Wem gehören die Schlüssel? Unter welchen Bedingungen darf man das Schließfach öffnen? Kann man es für eine zweite Verpfändung verwenden? Sind die Schließfächer gemischt? Wer kann dich aufhalten? Kann man von außen prüfen, ob man es erreichen/abfragen kann?
TBV ist bei Isolation und Transparenz sehr klar: Jeder Nutzer hat seinen BTC in einem eigenen „Bitcoin Vault“, die externe Anwendung verifiziert den Status, und es wird nichts in einen einzigen Custody-Pool vermischt. Und auch die öffentlich zugänglichen Testnetzparameter schreiben, dass der Security Council aus 5 Sitzen besteht: Mit 3 Unterschriften kann man eine Notfallmaßnahme ausführen, ähnlich wie CouncilNoPayout.
Hier muss man die Grenzen sauber ziehen: 3/5 sind Parameter des öffentlichen Testnetzes und lassen sich nicht direkt als Übernahme für das zukünftige Mainnet ableiten. Genau weil die Mainnet-Antwort noch nicht aus dieser Seite der Parameter feststeht, sollte man die Frage nach Bestand und Befugnissen des Gremiums als langfristigen Beobachtungspunkt behandeln – statt das Projekt mit vorgefertigten Schlussfolgerungen zu „ergänzen“.
Ich halte einen Notfall-Switch im Testzeitraum für realen Nutzen. Das neue System betrifft Bitcoin-Skripte, die Koordination off-chain und Ethereum-Contracts. Wenn ein schwerer Fehler auftritt, gibt es dann möglicherweise überhaupt keinen Not-Aus-Knopf – und nur weil es einen Knopf gibt, ist es nicht automatisch sicherer. Der Punkt ist: Sobald es einen Knopf gibt, muss man weiter nachfragen – wer die Mitglieder sind, unter welchen Bedingungen man drücken kann, ob die Auslösung verzögert ist und ob die Aktion on-chain nachvollziehbar und öffentlich protokolliert wird, und ob Nutzer einen Ausstiegsweg haben, der nicht vom Gremium abhängt.
Genau das ist es, worauf $BABY in der Governance wirklich achten sollte. Nicht, weil dort „Community Governance“ vier Wörter stehen, schon automatisch von verteilter Berechtigung ausgehen, sondern schauen: Welche Notfallrechte werden im Mainnet erhalten? Wer kann die Schwellen anpassen? Kann jede Aktion on-chain zurückverfolgt werden? #baby investiert keine abstrakten Visionen, sondern sehr konkrete Grenzen der Berechtigung.
Meine Haltung: Ein Notfallkomitee kann während der Bauphase wie ein Schutzgeländer sein, aber man kann sich nicht dauerhaft mit „für die Sicherheit“ jeglicher Prüfung entziehen. Erst selbst verifizieren. Akzeptierst du den 3/5-Notfall-„Bremsschalter“ als Tausch gegen die Reaktion auf Fehlfunktionen – oder meinst du, ein System ohne Erlaubnis sollte diese Hauptschaltung nicht behalten? Schreib dazu in die Kommentare und zerlege es gemeinsam.
Das muss nicht zwingend ein Widerspruch sein, aber es ist genau der Spalt, an dem sich der echte Wert von „trustless“ überprüfen lässt.
SCRIPT verlangt sechs Dinge: Die Nutzer behalten die Souveränität, die Dispositionsregeln sind klar, ohne Zustimmung darf nicht erneut verpfändet werden, jede Position ist isoliert, Dritte können nicht überprüfen bzw. auslesen, und der Sicherheitenstatus ist transparent. Das ist wie bei einem Schließfach mit sechs Abnahmekriterien: Wem gehören die Schlüssel? Unter welchen Bedingungen darf man das Schließfach öffnen? Kann man es für eine zweite Verpfändung verwenden? Sind die Schließfächer gemischt? Wer kann dich aufhalten? Kann man von außen prüfen, ob man es erreichen/abfragen kann?
TBV ist bei Isolation und Transparenz sehr klar: Jeder Nutzer hat seinen BTC in einem eigenen „Bitcoin Vault“, die externe Anwendung verifiziert den Status, und es wird nichts in einen einzigen Custody-Pool vermischt. Und auch die öffentlich zugänglichen Testnetzparameter schreiben, dass der Security Council aus 5 Sitzen besteht: Mit 3 Unterschriften kann man eine Notfallmaßnahme ausführen, ähnlich wie CouncilNoPayout.
Hier muss man die Grenzen sauber ziehen: 3/5 sind Parameter des öffentlichen Testnetzes und lassen sich nicht direkt als Übernahme für das zukünftige Mainnet ableiten. Genau weil die Mainnet-Antwort noch nicht aus dieser Seite der Parameter feststeht, sollte man die Frage nach Bestand und Befugnissen des Gremiums als langfristigen Beobachtungspunkt behandeln – statt das Projekt mit vorgefertigten Schlussfolgerungen zu „ergänzen“.
Ich halte einen Notfall-Switch im Testzeitraum für realen Nutzen. Das neue System betrifft Bitcoin-Skripte, die Koordination off-chain und Ethereum-Contracts. Wenn ein schwerer Fehler auftritt, gibt es dann möglicherweise überhaupt keinen Not-Aus-Knopf – und nur weil es einen Knopf gibt, ist es nicht automatisch sicherer. Der Punkt ist: Sobald es einen Knopf gibt, muss man weiter nachfragen – wer die Mitglieder sind, unter welchen Bedingungen man drücken kann, ob die Auslösung verzögert ist und ob die Aktion on-chain nachvollziehbar und öffentlich protokolliert wird, und ob Nutzer einen Ausstiegsweg haben, der nicht vom Gremium abhängt.
Genau das ist es, worauf $BABY in der Governance wirklich achten sollte. Nicht, weil dort „Community Governance“ vier Wörter stehen, schon automatisch von verteilter Berechtigung ausgehen, sondern schauen: Welche Notfallrechte werden im Mainnet erhalten? Wer kann die Schwellen anpassen? Kann jede Aktion on-chain zurückverfolgt werden? #baby investiert keine abstrakten Visionen, sondern sehr konkrete Grenzen der Berechtigung.
Meine Haltung: Ein Notfallkomitee kann während der Bauphase wie ein Schutzgeländer sein, aber man kann sich nicht dauerhaft mit „für die Sicherheit“ jeglicher Prüfung entziehen. Erst selbst verifizieren. Akzeptierst du den 3/5-Notfall-„Bremsschalter“ als Tausch gegen die Reaktion auf Fehlfunktionen – oder meinst du, ein System ohne Erlaubnis sollte diese Hauptschaltung nicht behalten? Schreib dazu in die Kommentare und zerlege es gemeinsam.
