Empêcher un Payout n’est pas la même chose que pouvoir réécrire la destination du BTC
Dans les Trustless Bitcoin Vaults (TBV), il est facile de mal interpréter le Security Council comme un multi-signature qui contrôlerait le BTC. À l’heure actuelle, le testnet public utilise 5 clés publiques Bitcoin avec un quorum de 3 sur 5 : les clés publiques sont inscrites dans les paramètres hors-chaîne versionnés afin de co-signer CouncilNoPayout. Cela peut empêcher le Payout d’un Vault donné, mais ne peut pas rediriger les BTC vers une nouvelle adresse指定ة par le Council.
Les limites proviennent du schéma de dépenses Bitcoin fixé au moment de la création du Vault. Les déposants pré-signent le Payout et déterminent la destination légitime : une sortie normale ou le self-claim reviennent à l’adresse du déposant selon les conditions déjà établies, sans nécessiter l’approbation du Council ; quant au chemin de liquidation, il mène à l’adresse autorisée de l’Application Vault Keeper. Les clés du Council ne font pas partie de cet ensemble de destinations de paiement ; ainsi, même en atteignant le quorum, il n’y a qu’un pouvoir de blocage, pas un pouvoir de redirection des actifs.
Ceci diffère du No-Payout diffusé par un challenger dans le cadre du processus de contestation normal : celui-ci repose sur le fait qu’un Claim invalide est contesté et qu’aucune réfutation n’est possible. CouncilNoPayout, lui, est prévu pour les pannes extrêmes ou les récupérations particulières que le mécanisme standard ne peut pas traiter. Le pause côté Ethereum est une autre couche : il peut suspendre les actions de l’application, mais ne peut pas modifier les chemins déjà existants de Pre-PegIn refund et de WOTS self-claim.
CouncilNoPayout change mes critères d’évaluation : je ne demande plus seulement s’il existe un comité dans le système, mais ce qu’il peut faire comme résultat que Bitcoin accepte. S’il empêche les dépenses, cela entraîne aussi un risque de disponibilité réduite et de retard de sortie ; s’il ne peut pas créer de nouvelles destinations, les pires conséquences restent limitées au blocage, plutôt qu’à une redirection d’actifs. Si les droits du Council sont abusés, un Payout légitime pourrait tout de même être bloqué ; si le Council disparaît, la capacité de récupération d’urgence diminue aussi. On ne peut donc pas écrire ce design comme un risque nul.
@BabylonLabs_io définit le Security Council comme un filet de sécurité transitoire, avec l’objectif de retirer progressivement son pouvoir à mesure que le protocole mûrit. Ce qui mérite vraiment d’être surveillé n’est pas seulement l’existence d’un multi-signature, mais jusqu’où les droits d’urgence sont limités dans le chemin de dépense du Bitcoin.$BTC $ETH
$BABY
#baby
Dans les Trustless Bitcoin Vaults (TBV), il est facile de mal interpréter le Security Council comme un multi-signature qui contrôlerait le BTC. À l’heure actuelle, le testnet public utilise 5 clés publiques Bitcoin avec un quorum de 3 sur 5 : les clés publiques sont inscrites dans les paramètres hors-chaîne versionnés afin de co-signer CouncilNoPayout. Cela peut empêcher le Payout d’un Vault donné, mais ne peut pas rediriger les BTC vers une nouvelle adresse指定ة par le Council.
Les limites proviennent du schéma de dépenses Bitcoin fixé au moment de la création du Vault. Les déposants pré-signent le Payout et déterminent la destination légitime : une sortie normale ou le self-claim reviennent à l’adresse du déposant selon les conditions déjà établies, sans nécessiter l’approbation du Council ; quant au chemin de liquidation, il mène à l’adresse autorisée de l’Application Vault Keeper. Les clés du Council ne font pas partie de cet ensemble de destinations de paiement ; ainsi, même en atteignant le quorum, il n’y a qu’un pouvoir de blocage, pas un pouvoir de redirection des actifs.
Ceci diffère du No-Payout diffusé par un challenger dans le cadre du processus de contestation normal : celui-ci repose sur le fait qu’un Claim invalide est contesté et qu’aucune réfutation n’est possible. CouncilNoPayout, lui, est prévu pour les pannes extrêmes ou les récupérations particulières que le mécanisme standard ne peut pas traiter. Le pause côté Ethereum est une autre couche : il peut suspendre les actions de l’application, mais ne peut pas modifier les chemins déjà existants de Pre-PegIn refund et de WOTS self-claim.
CouncilNoPayout change mes critères d’évaluation : je ne demande plus seulement s’il existe un comité dans le système, mais ce qu’il peut faire comme résultat que Bitcoin accepte. S’il empêche les dépenses, cela entraîne aussi un risque de disponibilité réduite et de retard de sortie ; s’il ne peut pas créer de nouvelles destinations, les pires conséquences restent limitées au blocage, plutôt qu’à une redirection d’actifs. Si les droits du Council sont abusés, un Payout légitime pourrait tout de même être bloqué ; si le Council disparaît, la capacité de récupération d’urgence diminue aussi. On ne peut donc pas écrire ce design comme un risque nul.
@BabylonLabs_io définit le Security Council comme un filet de sécurité transitoire, avec l’objectif de retirer progressivement son pouvoir à mesure que le protocole mûrit. Ce qui mérite vraiment d’être surveillé n’est pas seulement l’existence d’un multi-signature, mais jusqu’où les droits d’urgence sont limités dans le chemin de dépense du Bitcoin.$BTC $ETH
$BABY
#baby