Je pensais que l’autoconservation était principalement une question :
« Qui détient les clés ? »
En creusant dans Trustless Bitcoin Vaults (TBV) depuis @BabylonLabs_io , je pense qu’il y a un test plus difficile :
Qui contrôle la sortie quand quelque chose se casse ?
Alors j’ai cherché le scénario d’échec dans la documentation de Babylon.
Que se passe-t-il si un peg-in de TBV ne se termine pas ?
Sur le testnet actuel, Babylon documente un parcours de remboursement avec un délai de 3 jours. Une fois ce délai expiré, le déposant peut utiliser sa clé Bitcoin pour récupérer le BTC sans nécessiter la coopération du Fournisseur de Vault ou d’un autre acteur.
Je me suis arrêté aux trois jours.
Honnêtement, ça sonnait lent.
Puis j’ai remarqué ce qui vient après l’attente :
aucune autorisation n’est requise.
Cela a changé ma façon de lire le chiffre.
Trois jours, c’est un coût UX.
Avoir besoin de l’approbation de quelqu’un d’autre pour récupérer mon Bitcoin, c’est un coût de garde.
Ce ne sont pas le même problème.
Et je ne pense pas que la bonne conclusion soit que trois jours deviennent soudain « bons » parce que le système est sans confiance. L’attente reste un compromis, et les Trustless Bitcoin Vaults (TBV) présentent toujours des risques d’application et de transferts inter-chaînes que les utilisateurs doivent comprendre.
Mais ça m’a donné un meilleur test pour l’autoconservation.
Un dépôt me montre comment fonctionne un protocole quand tout se passe bien.
Le scénario d’échec me montre qui a réellement le contrôle quand ça ne se passe pas bien.
C’est la partie des TBV à laquelle je fais désormais davantage attention.
Si le choix vous appartenait, accepteriez-vous un parcours de récupération plus lent en échange d’une sortie qui ne dépend pas de l’autorisation de quelqu’un d’autre ?
$BABY #baby
$BANK $DEXE
« Qui détient les clés ? »
En creusant dans Trustless Bitcoin Vaults (TBV) depuis @BabylonLabs_io , je pense qu’il y a un test plus difficile :
Qui contrôle la sortie quand quelque chose se casse ?
Alors j’ai cherché le scénario d’échec dans la documentation de Babylon.
Que se passe-t-il si un peg-in de TBV ne se termine pas ?
Sur le testnet actuel, Babylon documente un parcours de remboursement avec un délai de 3 jours. Une fois ce délai expiré, le déposant peut utiliser sa clé Bitcoin pour récupérer le BTC sans nécessiter la coopération du Fournisseur de Vault ou d’un autre acteur.
Je me suis arrêté aux trois jours.
Honnêtement, ça sonnait lent.
Puis j’ai remarqué ce qui vient après l’attente :
aucune autorisation n’est requise.
Cela a changé ma façon de lire le chiffre.
Trois jours, c’est un coût UX.
Avoir besoin de l’approbation de quelqu’un d’autre pour récupérer mon Bitcoin, c’est un coût de garde.
Ce ne sont pas le même problème.
Et je ne pense pas que la bonne conclusion soit que trois jours deviennent soudain « bons » parce que le système est sans confiance. L’attente reste un compromis, et les Trustless Bitcoin Vaults (TBV) présentent toujours des risques d’application et de transferts inter-chaînes que les utilisateurs doivent comprendre.
Mais ça m’a donné un meilleur test pour l’autoconservation.
Un dépôt me montre comment fonctionne un protocole quand tout se passe bien.
Le scénario d’échec me montre qui a réellement le contrôle quand ça ne se passe pas bien.
C’est la partie des TBV à laquelle je fais désormais davantage attention.
Si le choix vous appartenait, accepteriez-vous un parcours de récupération plus lent en échange d’une sortie qui ne dépend pas de l’autorisation de quelqu’un d’autre ?
$BABY #baby
$BANK $DEXE