Zehn Tresore in einer einzigen Bitcoin-Transaktion unterzubringen, wirkt so, als würde man die Gebühr direkt auf ein Zehntel herunterkürzen. Beim Zerlegen habe ich jedoch festgestellt: Die @BabylonLabs_io eingesparten Kosten sind nur ein gemeinsames Außengehäuse, keine neunfachen Sicherheitsprozesse.
Das aktuelle TBV-Testnetz erlaubt, dass eine Batch-Pre-PegIn-Transaktion bis zu 10 HTLC-Outputs enthält. Nehmen wir zwei Tresore als Beispiel: Die beiden Outputs teilen sich eine einzige Bitcoin-Transaktion und denselben Abschnitt der Bestätigungshistorie. Dadurch müssen die Parent-Transaktionen nicht separat ausgestrahlt werden. Aber jeder Output entspricht weiterhin einem unabhängigen Vault. Jeder Vault hat seinen eigenen UTXO, eine eigene Pre-Sign-Transaktionsgrafik und einen eigenen Exit-Pfad. Aus gemeinschaftlichen Geldern wird dadurch kein gemeinsamer Pool.
Was mich jedoch am meisten beschäftigt, ist, wo die Signaturen landen. Während der Erstellung sammelt VP die Signaturen der Teilnehmer für den PegIn-Input und übermittelt sie gebündelt an Ethereum. Sobald der Benutzer das aktivierte secret offenbart, können auch wenn VP plötzlich offline geht, die anderen die Signaturen on-chain abrufen, den finalen Witness zusammenbauen und den PegIn ausstrahlen. Hier geht es nicht darum, dass der Diebstahl eines privaten Schlüssels verhindert wird, sondern darum, dass VP die Signaturen auf einem Server „parkt“, sodass BTC unterwegs feststeckt.
Diese Schicht der Verfügbarkeit hat jedoch klare Grenzen. Die auf der Kette gespeicherten PegIn-Signaturen lösen das Problem „Kann der Einbuchungsprozess abgeschlossen werden?“ Wenn VP später die Rücknahme verweigert, müssen die Nutzer sich weiterhin auf die von ihnen selbst gespeicherten WOTS-Schlüssel und die zu jedem Vault gehörenden clai mer artifacts verlassen, um per Self-Claim zu beanspruchen. Eine Batch-Transaktion bedeutet außerdem: Mehrere Outputs teilen sich den Bestätigungsfortschritt der Parent-Transaktion. Das spart Gebühren, beseitigt aber nicht die Last für Off-Chain-Koordination und Backups.
Darum werde ich Batch-Peg-in nicht so verstehen, als würden „zehn Tresore nur mit einer einzigen Sicherheitsarbeit“ laufen. Es ist eher so, als würde man zehn unabhängige Policen in eine Versandtasche packen: Die Versandkosten sind geringer, aber jede Police muss weiterhin separat korrekt signiert werden. Nach dem Go-Live im Mainnet werde ich mir den durchschnittlichen Batch-Umfang, die Signatur-Completion-Rate und die Übernahmegeschwindigkeit ansehen, wenn VP offline ist, um zu beurteilen, ob die Gebühren durch operativen Reibungsverlust wieder aufgefressen werden.
Was ist dir wichtiger: wie viel Gebühren du durch Batch sparst, oder das Risiko, dass mehrere Vaults gleichzeitig auf die Bestätigung warten?
#baby $BABY
Das aktuelle TBV-Testnetz erlaubt, dass eine Batch-Pre-PegIn-Transaktion bis zu 10 HTLC-Outputs enthält. Nehmen wir zwei Tresore als Beispiel: Die beiden Outputs teilen sich eine einzige Bitcoin-Transaktion und denselben Abschnitt der Bestätigungshistorie. Dadurch müssen die Parent-Transaktionen nicht separat ausgestrahlt werden. Aber jeder Output entspricht weiterhin einem unabhängigen Vault. Jeder Vault hat seinen eigenen UTXO, eine eigene Pre-Sign-Transaktionsgrafik und einen eigenen Exit-Pfad. Aus gemeinschaftlichen Geldern wird dadurch kein gemeinsamer Pool.
Was mich jedoch am meisten beschäftigt, ist, wo die Signaturen landen. Während der Erstellung sammelt VP die Signaturen der Teilnehmer für den PegIn-Input und übermittelt sie gebündelt an Ethereum. Sobald der Benutzer das aktivierte secret offenbart, können auch wenn VP plötzlich offline geht, die anderen die Signaturen on-chain abrufen, den finalen Witness zusammenbauen und den PegIn ausstrahlen. Hier geht es nicht darum, dass der Diebstahl eines privaten Schlüssels verhindert wird, sondern darum, dass VP die Signaturen auf einem Server „parkt“, sodass BTC unterwegs feststeckt.
Diese Schicht der Verfügbarkeit hat jedoch klare Grenzen. Die auf der Kette gespeicherten PegIn-Signaturen lösen das Problem „Kann der Einbuchungsprozess abgeschlossen werden?“ Wenn VP später die Rücknahme verweigert, müssen die Nutzer sich weiterhin auf die von ihnen selbst gespeicherten WOTS-Schlüssel und die zu jedem Vault gehörenden clai mer artifacts verlassen, um per Self-Claim zu beanspruchen. Eine Batch-Transaktion bedeutet außerdem: Mehrere Outputs teilen sich den Bestätigungsfortschritt der Parent-Transaktion. Das spart Gebühren, beseitigt aber nicht die Last für Off-Chain-Koordination und Backups.
Darum werde ich Batch-Peg-in nicht so verstehen, als würden „zehn Tresore nur mit einer einzigen Sicherheitsarbeit“ laufen. Es ist eher so, als würde man zehn unabhängige Policen in eine Versandtasche packen: Die Versandkosten sind geringer, aber jede Police muss weiterhin separat korrekt signiert werden. Nach dem Go-Live im Mainnet werde ich mir den durchschnittlichen Batch-Umfang, die Signatur-Completion-Rate und die Übernahmegeschwindigkeit ansehen, wenn VP offline ist, um zu beurteilen, ob die Gebühren durch operativen Reibungsverlust wieder aufgefressen werden.
Was ist dir wichtiger: wie viel Gebühren du durch Batch sparst, oder das Risiko, dass mehrere Vaults gleichzeitig auf die Bestätigung warten?
#baby $BABY
