Als ich zum ersten Mal Local Challengers und Universal Challengers in Babylons Trustless Bitcoin Vaults (TBV)-Toolkit sah, wirkten sie wie Arrays. Füge einen öffentlichen Schlüssel hinzu, füge noch einen Watcher hinzu. Fast kostenlos.
Dann habe ich verfolgt, was der Code für jeden Challenger erstellt.
Ein Challenger ist an drei ChallengeAssert-Transaktionen und ein eindeutiges NoPayout-Script gebunden. Das Hinzufügen eines Challengers vergrößert nicht nur eine Off-Chain-Liste. Es schafft mehr Bitcoin-Ausführungspfade, bevor überhaupt ein Disput beginnt.
Also ließ ich das lokale Set unverändert und variierte nur die Universal Challengers: 1, 3 und 5. Dann kombinierte ich jede Einrichtung mit Fee-Rates von 5, 20 und 100 sat/vB.
9 Szenarien.
Keine Reserven erfinden. Die Inputs zeigen bereits, wo die Kosten hineinfließen.
computeMinClaimValue nimmt die Anzahl der lokalen und universellen Challenger sowie die Größe des Rates, das Quorum und die Fee-Rate. Seine Ausgabe muss Reserven für den nachgelagerten Claim-, Assert- und Payout-Graph bereitstellen. Bei 100 sat/vB kostet jede zukünftige virtuelle Byte zwanzigmal mehr als bei 5 sat/vB. Mehr Challenger hinzufügen heißt: Unter dieser Fee-Umgebung müssen mehr Disputpfade vorbereitet werden.
Bevor jemand lügt. Bevor jemand challengt.
Die meisten dieser Transaktionen erreichen möglicherweise nie Bitcoin. Sie müssen trotzdem korrekt abgeleitet, gespeichert und finanziert werden, damit sie nutzbar bleiben, falls ein falscher Claim auftaucht. Babylon bepreist die Möglichkeit eines Konflikts, noch bevor ein Konflikt existiert.
Beim PegIn gilt die gleiche Logik aus einem anderen Blickwinkel. Die vorhergesagte Witness-Form hängt von den Zählerständen des Vault Keepers und des Universal-Challenger-Signers ab. Erhöhe das universelle Set, und die Sicherheitsentscheidung hinterlässt Gewicht im Transaktionsplan, bevor das Vault aktiv ist.
Das ist der Teil, den Dashboards verstecken.
Fünf Challenger mögen wie fünf Namen aussehen. In Babylon TBV werden daraus Scripts, Signaturen, zukünftige Transaktionen und Kapital, das für einen Disput reserviert wird, der möglicherweise nie passiert.
Mehr Challenger können die Wahrscheinlichkeit verringern, dass Betrug unbemerkt durchrutscht. Sie können aber auch jedes Vault schwerer machen, noch bevor überhaupt Betrug passiert.
Wie viel Disput-Maschinerie sollte jeder TBV-Depositor nur dafür finanzieren, dass sie betriebsbereit bleibt?8$BANK $BABY #baby @BabylonLabs_io
Dann habe ich verfolgt, was der Code für jeden Challenger erstellt.
Ein Challenger ist an drei ChallengeAssert-Transaktionen und ein eindeutiges NoPayout-Script gebunden. Das Hinzufügen eines Challengers vergrößert nicht nur eine Off-Chain-Liste. Es schafft mehr Bitcoin-Ausführungspfade, bevor überhaupt ein Disput beginnt.
Also ließ ich das lokale Set unverändert und variierte nur die Universal Challengers: 1, 3 und 5. Dann kombinierte ich jede Einrichtung mit Fee-Rates von 5, 20 und 100 sat/vB.
9 Szenarien.
Keine Reserven erfinden. Die Inputs zeigen bereits, wo die Kosten hineinfließen.
computeMinClaimValue nimmt die Anzahl der lokalen und universellen Challenger sowie die Größe des Rates, das Quorum und die Fee-Rate. Seine Ausgabe muss Reserven für den nachgelagerten Claim-, Assert- und Payout-Graph bereitstellen. Bei 100 sat/vB kostet jede zukünftige virtuelle Byte zwanzigmal mehr als bei 5 sat/vB. Mehr Challenger hinzufügen heißt: Unter dieser Fee-Umgebung müssen mehr Disputpfade vorbereitet werden.
Bevor jemand lügt. Bevor jemand challengt.
Die meisten dieser Transaktionen erreichen möglicherweise nie Bitcoin. Sie müssen trotzdem korrekt abgeleitet, gespeichert und finanziert werden, damit sie nutzbar bleiben, falls ein falscher Claim auftaucht. Babylon bepreist die Möglichkeit eines Konflikts, noch bevor ein Konflikt existiert.
Beim PegIn gilt die gleiche Logik aus einem anderen Blickwinkel. Die vorhergesagte Witness-Form hängt von den Zählerständen des Vault Keepers und des Universal-Challenger-Signers ab. Erhöhe das universelle Set, und die Sicherheitsentscheidung hinterlässt Gewicht im Transaktionsplan, bevor das Vault aktiv ist.
Das ist der Teil, den Dashboards verstecken.
Fünf Challenger mögen wie fünf Namen aussehen. In Babylon TBV werden daraus Scripts, Signaturen, zukünftige Transaktionen und Kapital, das für einen Disput reserviert wird, der möglicherweise nie passiert.
Mehr Challenger können die Wahrscheinlichkeit verringern, dass Betrug unbemerkt durchrutscht. Sie können aber auch jedes Vault schwerer machen, noch bevor überhaupt Betrug passiert.
Wie viel Disput-Maschinerie sollte jeder TBV-Depositor nur dafür finanzieren, dass sie betriebsbereit bleibt?8$BANK $BABY #baby @BabylonLabs_io