Parfois, je me surprends à penser que si je contrôle mon Bitcoin, je suis celui qui signe chaque transaction. C’est, apparemment, ainsi que fonctionne la self-custody (la conservation en propre). Vous détenez la clé, vous décidez quand les fonds bougent, et la chaîne confirme. Puis j’ai commencé à me pencher sur Babylon Labs, et j’ai réalisé que leurs Trustless Bitcoin Vaults reposent sur une autre hypothèse.
La partie intéressante n’est pas vraiment la création du coffre-fort elle-même. De nombreux protocoles vous permettent de verrouiller du Bitcoin. Ce qui m’a pris de court, c’est le processus de rachat. L’emprunteur rembourse son prêt. Puis plus rien. Le prestataire du coffre-fort soumet une preuve, et une fenêtre de contestation s’ouvre. La clé privée de l’utilisateur reste inactive. Aucun signature n’est requise. Si c’est toujours de la self-custody, pourquoi la personne qui serait censée posséder l’actif n’approuve-t-elle pas le mouvement final ?
J’ai dû remonter cette logique à rebours deux fois, parce que je pensais d’abord que le rachat devait impliquer une signature cachée quelque part. Ce n’est pas le cas. La réponse se trouve dans la création du coffre-fort. Avant que le coffre-fort n’active, l’utilisateur co-signe un script Taproot contenant chaque chemin de dépense possible : remboursement, liquidation, remboursement des fonds restitués. Tous sont pré-signés par l’ensemble des participants. Après l’activation, aucun nouveau chemin ne peut être introduit. Donc le rachat ne demande pas l’autorisation : l’autorisation a déjà été accordée. Possiblement des semaines plus tôt.
Cela change le moment où le contrôle s’exerce. Ce n’est pas le moment du mouvement. Il est intégré dans l’architecture du coffre-fort avant que quoi que ce soit ne bouge. L’utilisateur décide toujours de tout. Mais il le décide à l’avance, pas en réaction à des événements.
Bien sûr, cela signifie que le mécanisme de repli en cas de self-claim devient un autre point qui doit être correctement géré. Si le prestataire du coffre-fort disparaît, l’utilisateur peut toujours récupérer son BTC de manière unilatérale. Mais seulement s’il a conservé les artefacts du claimer créés lors de la mise en place du coffre-fort. S’ils les perdent, ce chemin se ferme. Je ne suis pas encore sûr de savoir si le problème le plus difficile est de concevoir les scripts pré-signés, ou d’amener les utilisateurs à garder un fichier en sécurité qu’ils n’auront peut-être pas besoin pendant des mois. C’est juste mon point de vue, pas un conseil en investissement.
#baby $BABY @BabylonLabs_io
La partie intéressante n’est pas vraiment la création du coffre-fort elle-même. De nombreux protocoles vous permettent de verrouiller du Bitcoin. Ce qui m’a pris de court, c’est le processus de rachat. L’emprunteur rembourse son prêt. Puis plus rien. Le prestataire du coffre-fort soumet une preuve, et une fenêtre de contestation s’ouvre. La clé privée de l’utilisateur reste inactive. Aucun signature n’est requise. Si c’est toujours de la self-custody, pourquoi la personne qui serait censée posséder l’actif n’approuve-t-elle pas le mouvement final ?
J’ai dû remonter cette logique à rebours deux fois, parce que je pensais d’abord que le rachat devait impliquer une signature cachée quelque part. Ce n’est pas le cas. La réponse se trouve dans la création du coffre-fort. Avant que le coffre-fort n’active, l’utilisateur co-signe un script Taproot contenant chaque chemin de dépense possible : remboursement, liquidation, remboursement des fonds restitués. Tous sont pré-signés par l’ensemble des participants. Après l’activation, aucun nouveau chemin ne peut être introduit. Donc le rachat ne demande pas l’autorisation : l’autorisation a déjà été accordée. Possiblement des semaines plus tôt.
Cela change le moment où le contrôle s’exerce. Ce n’est pas le moment du mouvement. Il est intégré dans l’architecture du coffre-fort avant que quoi que ce soit ne bouge. L’utilisateur décide toujours de tout. Mais il le décide à l’avance, pas en réaction à des événements.
Bien sûr, cela signifie que le mécanisme de repli en cas de self-claim devient un autre point qui doit être correctement géré. Si le prestataire du coffre-fort disparaît, l’utilisateur peut toujours récupérer son BTC de manière unilatérale. Mais seulement s’il a conservé les artefacts du claimer créés lors de la mise en place du coffre-fort. S’ils les perdent, ce chemin se ferme. Je ne suis pas encore sûr de savoir si le problème le plus difficile est de concevoir les scripts pré-signés, ou d’amener les utilisateurs à garder un fichier en sécurité qu’ils n’auront peut-être pas besoin pendant des mois. C’est juste mon point de vue, pas un conseil en investissement.
#baby $BABY @BabylonLabs_io
