In technischen Dokumenten lese ich solche stark einschränkenden Wörter wie „solely controlled“; ich bin es gewohnt, zuerst das Objekt nachzuliefern. Welche Ausgabe wird denn einzeln kontrolliert – welche genau? Und wer kontrolliert sie? Beim Lesen wirkt es wie beim Blick in einen Vertrag: Die Nomina, die nach dem Einschränkungsausdruck folgen, bestimmen, auf wessen Pflichten die Verpflichtung tatsächlich fällt.
Peg-in erzeugt eine kleine „depositor claim“-Ausgabe, die von dem Bitcoin-Key des Depositor einzeln kontrolliert wird. Der Betrag ist sehr klein, aber der Zweck ist speziell: Sie dient als Anker für den „self-claim“-Eingang, also für genau jene Stelle, die der Depositor in der gesamten Prozesskette wirklich in der Hand hat.
Aber diese Stelle zu beherrschen heißt nicht, die ganze Schatzkammer zu beherrschen. Diese Ausgabe verankert den Eingang von self-claim, nicht den Ausgang. Um den self-claim wirklich abzuschließen, braucht es die entsprechenden Ereignisse, die WOTS und die „artifacts“ dieser Vault – danach folgt der vorgeschriebene Ablauf samt der Challenge-Periode. Wenn der Eingang in der Hand ist, sind die folgenden Schritte dennoch jeweils Variablen. Das Ankern bedeutet lediglich, die Position festzulegen; Material, Ereignisse und die Challenge-Periode bleiben weiterhin Variablen.#baby
Das BTC der Hauptvault ist ohnehin eine andere Geschichte. Es ist an das vorab signierte Transaktionsdiagramm gebunden: Die Route ist im Voraus festgeschrieben und kann nicht vom Depositor nach Belieben umgeleitet, vorzeitig ausbezahlt oder durch vorab festgelegte Bedingungen umgangen werden. Das vorab signierte Diagramm legt den gesamten Ausstiegsweg fest – es ist kein Entwurf, den man jederzeit ändern könnte. Das heißt: In den TBV unter @BabylonLabs_io erhält der Key des Depositor die Kontrolle über diese kleine Ausgabe, nicht aber über den festgelegten Pfad der Haupt-Assets.
Zurück zur ursprünglichen technischen Beschreibung: „solely controlled“ lügt nicht. Das Problem entsteht eher durch das weggelassene Objekt.$BABY In jedem Dokument, in dem solche stark einschränkenden Ausdrücke vorkommen, lohnt es sich, das Objekt zu ergänzen, um abzugleichen: Was wird kontrolliert und was nicht. Entscheidend für den Umfang der Berechtigungen ist nie, wie stark das Wort „solely“ formuliert ist, sondern eindeutig, wer genau das Objekt ist, das es modifiziert.
Das Abgleichen des Objekts ist näher an der tatsächlichen Sache als die Diskussion über den Ausdruck selbst – und dieser Satz sollte neben jeder Erklärung zu einem Protokoll stehen.
Peg-in erzeugt eine kleine „depositor claim“-Ausgabe, die von dem Bitcoin-Key des Depositor einzeln kontrolliert wird. Der Betrag ist sehr klein, aber der Zweck ist speziell: Sie dient als Anker für den „self-claim“-Eingang, also für genau jene Stelle, die der Depositor in der gesamten Prozesskette wirklich in der Hand hat.
Aber diese Stelle zu beherrschen heißt nicht, die ganze Schatzkammer zu beherrschen. Diese Ausgabe verankert den Eingang von self-claim, nicht den Ausgang. Um den self-claim wirklich abzuschließen, braucht es die entsprechenden Ereignisse, die WOTS und die „artifacts“ dieser Vault – danach folgt der vorgeschriebene Ablauf samt der Challenge-Periode. Wenn der Eingang in der Hand ist, sind die folgenden Schritte dennoch jeweils Variablen. Das Ankern bedeutet lediglich, die Position festzulegen; Material, Ereignisse und die Challenge-Periode bleiben weiterhin Variablen.#baby
Das BTC der Hauptvault ist ohnehin eine andere Geschichte. Es ist an das vorab signierte Transaktionsdiagramm gebunden: Die Route ist im Voraus festgeschrieben und kann nicht vom Depositor nach Belieben umgeleitet, vorzeitig ausbezahlt oder durch vorab festgelegte Bedingungen umgangen werden. Das vorab signierte Diagramm legt den gesamten Ausstiegsweg fest – es ist kein Entwurf, den man jederzeit ändern könnte. Das heißt: In den TBV unter @BabylonLabs_io erhält der Key des Depositor die Kontrolle über diese kleine Ausgabe, nicht aber über den festgelegten Pfad der Haupt-Assets.
Zurück zur ursprünglichen technischen Beschreibung: „solely controlled“ lügt nicht. Das Problem entsteht eher durch das weggelassene Objekt.$BABY In jedem Dokument, in dem solche stark einschränkenden Ausdrücke vorkommen, lohnt es sich, das Objekt zu ergänzen, um abzugleichen: Was wird kontrolliert und was nicht. Entscheidend für den Umfang der Berechtigungen ist nie, wie stark das Wort „solely“ formuliert ist, sondern eindeutig, wer genau das Objekt ist, das es modifiziert.
Das Abgleichen des Objekts ist näher an der tatsächlichen Sache als die Diskussion über den Ausdruck selbst – und dieser Satz sollte neben jeder Erklärung zu einem Protokoll stehen.