L’Entonnoir du Bitcoin – épisode #62

Sujet 1 : BIP OP-VAULT

Cette semaine, la formalisation en un BIP de la proposition OP_VAULT, que nous avions déjà traitée, a relancé l’éternel débat sur l’ossification du protocole et sur les différentes méthodes d’activation, le BIP incluant la méthode préconisée.

Pour rappel, OP_VAULT introduit le concept de Vaults directement au niveau du protocole Bitcoin : les fonds envoyés sur un Vault sont bloqués, et les retirer nécessite de les débloquer en passant par une transaction intermédiaire avec timelock. Il est nécessaire d’attendre un certain temps après la confirmation de cette transaction afin de dépenser les fonds vers une adresse externe. Cependant, il est possible de dépenser les fonds sortants immédiatement et sans signature vers des adresses de récupération préalablement configurées. Ainsi, si un transfert non autorisé est repéré, il suffit de renvoyer les fonds vers ces adresses avant la fin du temps d’attente et ainsi empêcher le transfert.

Pour plus de détails sur ce concept et son fonctionnement, vous pouvez réécouter l’épisode 58 de l’EDB.

Son créateur James O’Beirne a proposé de procéder via un Speedy Trial, le même mécanisme qui a été utilisé pour activer Taproot fin 2021, après de looongs mois de négociation et de réflexion. Le débat est parti de certains bitcoiners qui considèrent qu’un début d’abus de cette méthode de validation commence à voir le jour et craignent une augmentation trop forte du nombre de softforks sous Speedy Trial, à terme pouvant « casser Bitcoin » en rajoutant rapidement tout et n’importe quoi.

Néanmoins, d’après Pantamis, le qualificatif « Speedy » ne désigne pas une activation rapide, contrairement à ce que l’on pourrait penser. En effet, elle laisse au final plusieurs mois aux mineurs pour signaler leur connaissance de la mise à jour, une fois que les nœuds l’ont eux-même validé. Cela permet de limiter au maximum le risque de hardfork involontaire et donc un softfork plutôt sûr. Cette méthode d’activation semble être aujourd’hui la plus saine pour de futurs softforks.

Venant juste après la hype des inscriptions via les Ordinals, certains bitcoiners ont envie de prendre plus de temps et insistent donc sur le fait que le prochaine soft fork de Bitcoin devrait être davantage review et dans plus de temps.

Sujet 2 : BlueWallet

Cette semaine, BlueWallet a annoncé la fin de son service de custody qui permettait à n’importe qui de posséder un wallet Lightning en passant par leur noeud. Leur solution maison de gestion de multiples comptes sur un unique noeud, LndHub, semble atteindre ses limites de mise à l’échelle.

Bien que BlueWallet mette fin à ce service, ils n’abandonnent pas Lightning pour autant ! Une nouvelle fonctionnalité permettant de faire tourner un noeud directement sur votre téléphone (utilisant le Lightning Development Kit, implémentation d’un noeud Lightning écrite en Rust) est déjà disponible en bêta (il suffit d’appuyer 10 fois sur “Lightning” lors de la création d’un nouveau wallet, et l’option apparaîtra) 🔥 Rien à voir avec ce dont vous étiez sûrement habitués en utilisant Lightning sur BlueWallet : vous devrez maintenant gérer vos propres canaux et votre liquidité. Une toute autre histoire !

Pour tous ceux qui posséderaient un wallet Lightning sur BlueWallet, il est absolument nécessaire de transférer vos fonds vers une nouvelle application, custodial ou non, avant le 30 avril prochain. Développé par Acinq, Phoenix a l’avantage de gérer automatiquement vos canaux Lightning et vous en ouvre lorsque vos n’avez pas assez de liquidité entrante à disposition, en échange de maigres frais d’ouverture. Il s’agit pour nous de la solution le plus aboutie à l’heure actuelle, nous vous la recommandons donc chaudement !

Afin de réaliser un gros paiement sur Lightning, ou tout simplement pour limiter la liquidité déplacée dans des canaux individuels, il est possible de faire du atomic multipath payment (AMP) : diviser le paiement en plusieurs morceaux qui passent par des chemins différents. « Atomique » désigne la garantie du succès ou de l’échec total du paiement, sans entre deux : soit toutes les parties arrivent à bon port, dans ce cas le destinataire reçoit tout et le paiement est réussi, soit une ou plusieurs parties n’arrivent pas et le paiement échoue, le receveur ne recevant rien du tout.

AMP est déjà assez répandu, Phoenix l’utilise beaucoup. En voici un exemple : un paiement réussi d’un million de satoshis, divisé en 7 morceaux de montants plus ou moins équivalents.

Cela nous mène cependant au constat suivant : on dépend de la réussite individuelle de toutes les parties du paiement à la fois.

Les boomerang payments proposent de rajouter un certain montant supplémentaire en plus du montant initial de l’invoice, puis de diviser en plusieurs parties de telle sorte que le montant à payer puisse être atteint avec un certain nombre de parties parmi toutes. Certaines peuvent échouer, l’important est que dans la finalité, il en arrive le montant voulu. Le contrat utilisé est fait de telle sorte que le destinataire ne puisse récupérer que la quantité qu’il a le droit de recevoir, et pas plus, sinon il perd tout !

Par exemple pour un paiement de 0.05 BTC : avec AMP, on pourrait le diviser en 5 parties de 0.01 BTC, mais avec les boomerang payments, on peut choisir 7 parties de 0.01 BTC.

Vous pouvez aller voir ce lien : https://bitcoinops.org/en/newsletters/2020/02/26/#boomerang-redundancy-improves-latency-and-throughput-in-payment-channel-networks

Nos derniers articles