Was mein Bild von Baxylon's trustlosen Bitcoin-Tresoren (TBV) verändert, ist, dass Selbstverwahrung nicht damit endet, den Bitcoin-Schlüssel zu halten.
Im aktuellen Design hängt das stärkste Fallback ebenfalls von Wiederherstellungsdateien ab, die erstellt werden, wenn der Tresor eingerichtet wird. Wenn ein Vault Provider die Auszahlung nicht startet, muss der Einleger möglicherweise die WOTS-Datei und lokale Claimer-Artefakte verwenden, um den bereits genehmigten Bitcoin-Anspruchspfad zu nutzen.
Dieser Punkt ist wichtig, weil der Tresor später nicht einfach eine neue Auszahlungsroute erstellen kann. Die gültigen Bitcoin-Ausgabewege sind im Voraus festgelegt. Die Kontrolle des Nutzers geht also nicht nur darum, den Schlüssel zu besitzen. Es geht auch darum, die Dateien aufzubewahren, die den Fallback-Pfad nutzbar machen.
Der Bitcoin-Schlüssel schützt die Signierautorität, während diese Artefakte die Daten bewahren, die nötig sind, um den vorab erstellten Wiederherstellungsprozess fortzusetzen. Sie lösen unterschiedliche Teile desselben Problems.
Ich lese das nicht als Beweis dafür, dass TBV nicht selbstverwahrend ist. Ich lese es als eine vollständigere Version von Selbstverwahrung: Schlüsselkontrolle plus Wiederherstellungsbereitschaft.
Für einen Testnet-User ist die sinnvolle Prüfung einfach. Bestätige nicht nur, dass der Tresor erstellt wurde und das Ausleihen funktioniert hat. Bestätige außerdem, dass die WOTS-Datei und die Claimer-Artefakte heruntergeladen, sicher gesichert und wiederherstellbar sind, wenn es nötig wird.
Das wäre die Einzelheit, die ich in @BabylonLabs_io current $BABY testnet nicht ignorieren würde. Die eigentliche Wiederherstellungsfrage lautet nicht nur „Wer hält den Schlüssel?“ Sie lautet auch „Kann der Eigentümer den Fallback-Pfad nutzen, wenn der normale Provider offline ist?“ #baby
Im aktuellen Design hängt das stärkste Fallback ebenfalls von Wiederherstellungsdateien ab, die erstellt werden, wenn der Tresor eingerichtet wird. Wenn ein Vault Provider die Auszahlung nicht startet, muss der Einleger möglicherweise die WOTS-Datei und lokale Claimer-Artefakte verwenden, um den bereits genehmigten Bitcoin-Anspruchspfad zu nutzen.
Dieser Punkt ist wichtig, weil der Tresor später nicht einfach eine neue Auszahlungsroute erstellen kann. Die gültigen Bitcoin-Ausgabewege sind im Voraus festgelegt. Die Kontrolle des Nutzers geht also nicht nur darum, den Schlüssel zu besitzen. Es geht auch darum, die Dateien aufzubewahren, die den Fallback-Pfad nutzbar machen.
Der Bitcoin-Schlüssel schützt die Signierautorität, während diese Artefakte die Daten bewahren, die nötig sind, um den vorab erstellten Wiederherstellungsprozess fortzusetzen. Sie lösen unterschiedliche Teile desselben Problems.
Ich lese das nicht als Beweis dafür, dass TBV nicht selbstverwahrend ist. Ich lese es als eine vollständigere Version von Selbstverwahrung: Schlüsselkontrolle plus Wiederherstellungsbereitschaft.
Für einen Testnet-User ist die sinnvolle Prüfung einfach. Bestätige nicht nur, dass der Tresor erstellt wurde und das Ausleihen funktioniert hat. Bestätige außerdem, dass die WOTS-Datei und die Claimer-Artefakte heruntergeladen, sicher gesichert und wiederherstellbar sind, wenn es nötig wird.
Das wäre die Einzelheit, die ich in @BabylonLabs_io current $BABY testnet nicht ignorieren würde. Die eigentliche Wiederherstellungsfrage lautet nicht nur „Wer hält den Schlüssel?“ Sie lautet auch „Kann der Eigentümer den Fallback-Pfad nutzen, wenn der normale Provider offline ist?“ #baby