Kann Payout verhindern, aber nicht umschreiben, wohin BTC gehen
In Trustless Bitcoin Vaults (TBV) wird der Security Council leicht mit einer Multi-Signatur verwechselt, die BTC kontrolliert. Das aktuelle öffentlich verfügbare Testnetz verwendet 5 Bitcoin-Public-Keys und 3-of-5 als gesetzliche Anzahl. Die Public-Keys sind in versionierten Off-Chain-Protokollparametern festgeschrieben, um gemeinsam CouncilNoPayout zu signieren. Es kann das Payout für einen bestimmten Vault blockieren, aber nicht BTC zu einer von Council neu festgelegten Adresse umleiten.
Die Einschränkung rührt von der bei der Erstellung des Vault bereits festgelegten Bitcoin-Ausgaben-Grafik her. Einleger signieren Payouts im Voraus und legen den rechtmäßigen Bestimmungsort fest: ein regulärer Exit oder self-claim führt unter den bestehenden Bedingungen zur Einleger-Adresse zurück; der Liquidationspfad läuft dagegen auf die autorisierte Application Vault Keeper-Adresse hinaus. Die Council-Schlüssel sind nicht in dieser Menge der Empfangszwecke enthalten. Daher gibt es selbst bei Erreichen der Beschlussfähigkeit nur ein Sperrrecht, aber kein Recht zur Umleitung von Vermögenswerten.
Das ist anders als das No-Payout, das ein Challenger im normalen Streitbeilegungsprozess ausstrahlt: Letzteres basiert darauf, dass ein ungültiger Claim angefochten wird und anschließend keine Gegenbeweise möglich sind. CouncilNoPayout ist für extreme Ausfälle oder besondere Wiederherstellungen gedacht, die vom Standardmechanismus nicht verarbeitet werden können. Die Pause auf der Ethereum-Seite ist eine zusätzliche Ebene: Sie kann Anwendungsaktionen anhalten, aber nicht die bereits vorhandenen Pre-PegIn-Refund- und WOTS-self-claim-Pfade umschreiben.
CouncilNoPayout hat meinen Bewertungsmaßstab verändert: Ich frage nicht mehr nur, ob es in dem System ein Gremium gibt, sondern was es dazu befähigt, welche Ergebnisse mit Bitcoin akzeptiert werden. Es kann Auszahlungen verhindern – das bringt jedoch weiterhin Risiken hinsichtlich Verfügbarkeit und Exit-Verzögerung mit sich. Wenn es keine neuen Ziele schaffen kann, lässt sich das schlimmste Ergebnis auf die Blockierung begrenzen, statt auf eine Umleitung von Vermögenswerten.
Falls Council-Befugnisse missbraucht werden, können rechtmäßige Payouts trotzdem blockiert bleiben. Wenn Council aber abbricht/verloren geht, sinkt auch die Fähigkeit zur Notfallwiederherstellung. Man kann dieses Design nicht als risikofrei formulieren.
@BabylonLabs_io definiert den Security Council als vorübergehendes Sicherheitsnetz: Ziel ist, seine Macht schrittweise außer Kraft zu setzen, während das Protokoll reift. Das wirklich Beobachtenswerte ist nicht, ob eine Multi-Signatur existiert, sondern bis zu welchem Schritt die Notfallbefugnis in den Bitcoin-Ausgabenpfad hineingeschränkt ist. $BTC $ETH
$BABY
#baby
In Trustless Bitcoin Vaults (TBV) wird der Security Council leicht mit einer Multi-Signatur verwechselt, die BTC kontrolliert. Das aktuelle öffentlich verfügbare Testnetz verwendet 5 Bitcoin-Public-Keys und 3-of-5 als gesetzliche Anzahl. Die Public-Keys sind in versionierten Off-Chain-Protokollparametern festgeschrieben, um gemeinsam CouncilNoPayout zu signieren. Es kann das Payout für einen bestimmten Vault blockieren, aber nicht BTC zu einer von Council neu festgelegten Adresse umleiten.
Die Einschränkung rührt von der bei der Erstellung des Vault bereits festgelegten Bitcoin-Ausgaben-Grafik her. Einleger signieren Payouts im Voraus und legen den rechtmäßigen Bestimmungsort fest: ein regulärer Exit oder self-claim führt unter den bestehenden Bedingungen zur Einleger-Adresse zurück; der Liquidationspfad läuft dagegen auf die autorisierte Application Vault Keeper-Adresse hinaus. Die Council-Schlüssel sind nicht in dieser Menge der Empfangszwecke enthalten. Daher gibt es selbst bei Erreichen der Beschlussfähigkeit nur ein Sperrrecht, aber kein Recht zur Umleitung von Vermögenswerten.
Das ist anders als das No-Payout, das ein Challenger im normalen Streitbeilegungsprozess ausstrahlt: Letzteres basiert darauf, dass ein ungültiger Claim angefochten wird und anschließend keine Gegenbeweise möglich sind. CouncilNoPayout ist für extreme Ausfälle oder besondere Wiederherstellungen gedacht, die vom Standardmechanismus nicht verarbeitet werden können. Die Pause auf der Ethereum-Seite ist eine zusätzliche Ebene: Sie kann Anwendungsaktionen anhalten, aber nicht die bereits vorhandenen Pre-PegIn-Refund- und WOTS-self-claim-Pfade umschreiben.
CouncilNoPayout hat meinen Bewertungsmaßstab verändert: Ich frage nicht mehr nur, ob es in dem System ein Gremium gibt, sondern was es dazu befähigt, welche Ergebnisse mit Bitcoin akzeptiert werden. Es kann Auszahlungen verhindern – das bringt jedoch weiterhin Risiken hinsichtlich Verfügbarkeit und Exit-Verzögerung mit sich. Wenn es keine neuen Ziele schaffen kann, lässt sich das schlimmste Ergebnis auf die Blockierung begrenzen, statt auf eine Umleitung von Vermögenswerten.
Falls Council-Befugnisse missbraucht werden, können rechtmäßige Payouts trotzdem blockiert bleiben. Wenn Council aber abbricht/verloren geht, sinkt auch die Fähigkeit zur Notfallwiederherstellung. Man kann dieses Design nicht als risikofrei formulieren.
@BabylonLabs_io definiert den Security Council als vorübergehendes Sicherheitsnetz: Ziel ist, seine Macht schrittweise außer Kraft zu setzen, während das Protokoll reift. Das wirklich Beobachtenswerte ist nicht, ob eine Multi-Signatur existiert, sondern bis zu welchem Schritt die Notfallbefugnis in den Bitcoin-Ausgabenpfad hineingeschränkt ist. $BTC $ETH
$BABY
#baby