Ich ging davon aus, dass ein Babylon Trustless Bitcoin Vaults (TBV) immer noch 1 Schlüssel hinter allen seinen Taproot-Skripten hatte.
Vielleicht hielt ihn der Einzahler. Vielleicht der Vault-Provider. Oder vielleicht konnten ihn mehrere Teilnehmer gemeinsam nutzen, wenn sie alle zustimmten.
Dann habe ich den Taproot-Interner Schlüssel überprüft.
Dabei handelt es sich um einen NUMS-öffentlichen Schlüssel ohne bekannten passenden privaten Schlüssel. Damit ist der Schlüsselpfad unbrauchbar.
Ein Taproot-Ausgang gibt BTC normalerweise auf zwei Arten frei. Eine Möglichkeit folgt einem festgeschriebenen Skript und muss dessen Bedingungen erfüllen. Der andere Weg nutzt den privaten Schlüssel, der zum internen Schlüssel passt. So kann der Ausgeber die Offenlegung dieser Skripte vermeiden.
TBV verzichtet bewusst auf diese zweite Route.
Kein Teilnehmer kann den Transaktionsgraphen mit einem Schlüsselpfad-Spend umgehen. Das BTC kann nur über Pfade abfließen, die vorbereitet wurden, bevor der Vault-Ausgang erstellt wurde.
Zunächst las ich das als eine einfache Anti-Backdoor-Entscheidung. Ich dachte, sie entfernt nur einen versteckten Hinterausgang.
Dann bemerkte ich, was diese Entscheidung wegnimmt.
Der Einzahler, der Vault Provider und andere Teilnehmer mögen später sich auf ein neues Ziel einigen. Diese Einigung kann aber immer noch keinen neuen Transaktionspfad erzeugen.
Wenn der Pfad nicht vorbereitet wurde, bevor das BTC verschoben wurde, ist er jetzt nicht verfügbar.
Der interne Schlüssel blockiert eine Art von Umgehung. Er beweist nicht, dass der Transaktionsgraph gut entworfen wurde. Er kann auch später keinen Rettungspfad hinzufügen.
Niemand kann improvisiert einen bösartigen Spend über den Schlüsselpfad durchführen. Niemand kann dort auch einen hilfreichen improvisieren.
Das veränderte, wie ich über Verwahrung (Custody) in TBV denke.
Das Protokoll wählt nicht die sicherste Person, um die letzte Entscheidungsgewalt zu halten. Es macht diese Entscheidungsgewalt über den Schlüsselpfad unbrauchbar.
Die eigentliche Entscheidung passiert früher. Die erlaubten Ausgabewege müssen gewählt werden, bevor das BTC in den Vault gelangt.
Die Frage ist nicht nur, wer die Bitcoin kontrolliert. Es ist auch, wofür der Vault gebaut wurde, bevor die Bitcoin verschoben wurde.
Macht es den Vault sicherer, wenn der Schlüsselpfad unbrauchbar ist, da niemand seine vorbereiteten Pfade umgehen kann? Oder macht es den Vault rigider, da niemand nach der Verschiebung der BTC einen neuen Pfad hinzufügen kann?
Kein finaler Schlüssel, oder keine zweite Chance?
@BabylonLabs_io $BANK $BABY #baby ✨
Vielleicht hielt ihn der Einzahler. Vielleicht der Vault-Provider. Oder vielleicht konnten ihn mehrere Teilnehmer gemeinsam nutzen, wenn sie alle zustimmten.
Dann habe ich den Taproot-Interner Schlüssel überprüft.
Dabei handelt es sich um einen NUMS-öffentlichen Schlüssel ohne bekannten passenden privaten Schlüssel. Damit ist der Schlüsselpfad unbrauchbar.
Ein Taproot-Ausgang gibt BTC normalerweise auf zwei Arten frei. Eine Möglichkeit folgt einem festgeschriebenen Skript und muss dessen Bedingungen erfüllen. Der andere Weg nutzt den privaten Schlüssel, der zum internen Schlüssel passt. So kann der Ausgeber die Offenlegung dieser Skripte vermeiden.
TBV verzichtet bewusst auf diese zweite Route.
Kein Teilnehmer kann den Transaktionsgraphen mit einem Schlüsselpfad-Spend umgehen. Das BTC kann nur über Pfade abfließen, die vorbereitet wurden, bevor der Vault-Ausgang erstellt wurde.
Zunächst las ich das als eine einfache Anti-Backdoor-Entscheidung. Ich dachte, sie entfernt nur einen versteckten Hinterausgang.
Dann bemerkte ich, was diese Entscheidung wegnimmt.
Der Einzahler, der Vault Provider und andere Teilnehmer mögen später sich auf ein neues Ziel einigen. Diese Einigung kann aber immer noch keinen neuen Transaktionspfad erzeugen.
Wenn der Pfad nicht vorbereitet wurde, bevor das BTC verschoben wurde, ist er jetzt nicht verfügbar.
Der interne Schlüssel blockiert eine Art von Umgehung. Er beweist nicht, dass der Transaktionsgraph gut entworfen wurde. Er kann auch später keinen Rettungspfad hinzufügen.
Niemand kann improvisiert einen bösartigen Spend über den Schlüsselpfad durchführen. Niemand kann dort auch einen hilfreichen improvisieren.
Das veränderte, wie ich über Verwahrung (Custody) in TBV denke.
Das Protokoll wählt nicht die sicherste Person, um die letzte Entscheidungsgewalt zu halten. Es macht diese Entscheidungsgewalt über den Schlüsselpfad unbrauchbar.
Die eigentliche Entscheidung passiert früher. Die erlaubten Ausgabewege müssen gewählt werden, bevor das BTC in den Vault gelangt.
Die Frage ist nicht nur, wer die Bitcoin kontrolliert. Es ist auch, wofür der Vault gebaut wurde, bevor die Bitcoin verschoben wurde.
Macht es den Vault sicherer, wenn der Schlüsselpfad unbrauchbar ist, da niemand seine vorbereiteten Pfade umgehen kann? Oder macht es den Vault rigider, da niemand nach der Verschiebung der BTC einen neuen Pfad hinzufügen kann?
Kein finaler Schlüssel, oder keine zweite Chance?
@BabylonLabs_io $BANK $BABY #baby ✨