Liquidité entrante

Les portefeuilles Lightning récents peuvent dépenser et ne peuvent pas être payés, et voici pourquoi. Un canal que vous avez financé vous-même commence avec tous les satoshis de votre côté, ne laissant rien de l'autre côté pour circuler vers vous. Tant que de la valeur ne sort pas, ou que personne n'engage du capital pointant vers vous, les paiements entrants échouent avec une erreur de routage plutôt que d'être rejetés.

Comment cela fonctionne

La liquidité entrante n'est pas un paramètre ; c'est l'image inversée du solde de tous les autres dans vos canaux.

Imaginez un canal de 1 000 000 satoshis que vous avez financé entièrement. Votre liquidité sortante est proche du million complet et votre liquidité entrante est nulle, parce que votre pair ne détient rien à vous renvoyer. Dépensez 300 000 satoshis et le pair détient désormais 300 000, ce qui constitue exactement votre nouvelle limite de réception. Chaque paiement que vous effectuez augmente ce que vous pouvez recevoir ; chaque paiement que vous recevez le diminue. Le total reste fixe tant que le canal ne change pas de taille.

Parce qu'il s'agit d'un miroir, il n'existe que quelques façons honnêtes de la créer. Quelqu'un peut ouvrir un canal vers vous et le financer lui-même, ce que fait un fournisseur de services Lightning lorsqu'il vous vend un canal ou en ouvre un juste à temps pour capter votre premier paiement entrant. Vous pouvez payer pour un échange, en envoyant des satoshis Lightning et en recevant des satoshis on-chain en retour, ce qui déplace votre propre solde de l'autre côté sans le dépenser. Vous pouvez financer un canal à deux, où les deux pairs contribuent à l'ouverture. Ou vous pouvez simplement dépenser, ce qui est l'option gratuite et la plus lente.

La plus ancienne version packagée de la voie de l'échange est Lightning Loop, publiée en alpha par Lightning Labs le 20 mars 2019, et présentée dès le premier jour comme un moyen d'obtenir de la capacité entrante sans fermer de canaux. Le mécanisme sous-jacent est un échange sous-marin.

Où cela se voit

La liquidité entrante se manifeste comme un échec inexpliqué bien avant que quiconque ne la nomme pour vous.

Un nouveau portefeuille mobile vous laissera volontiers acheter et recevoir, parce que le fournisseur du portefeuille a ouvert un canal vers vous et en porte discrètement le coût. Puis la limite de réception apparaît : un portefeuille qui indique que vous pouvez envoyer 400 000 satoshis mais recevoir seulement 12 000 n'a presque plus de solde distant. Demandez à un ami de vous payer 50 000 et cela échoue.

Les commerçants sont les plus touchés. Une boutique qui accepte des paiements Lightning consomme de la liquidité entrante toute la journée et produit une liquidité sortante dont elle n'a pas besoin, si bien qu'elle finit avec des canaux pleins d'argent où elle ne peut plus être payée. La solution standard consiste à échanger périodiquement, en convertissant le solde Lightning en solde on-chain et en reconstituant le côté réception au passage, ou à sortir des fonds du canal par splice sans le fermer.

Le chiffre à vérifier avant de vous engager est le prix. Un canal ouvert vers vous coûte au fournisseur une transaction on-chain plus du capital immobilisé, et il répercute les deux, soit sous forme de frais visibles, soit sous forme d'une part de votre premier dépôt. C'est un coût réel de l'utilisation de Lightning pour recevoir, et c'est la principale raison pour laquelle de petits premiers dépôts dans des portefeuilles Lightning en auto-conservation peuvent perdre un pourcentage surprenant avant d'arriver.