Le lightning network et les payements réguliers

Ce matin, j’ai lu un court à article de Fanis Michalakis : Bitwage Annonce le Premier Paiement d’un Salaire via Lightning. Ses réflexions rejoignent les miennes concernant l’évolution de l’utilisation du réseau Lightning et de la gestion des canaux de payement. J’aimerais ici pousser un peu plus loin la réflexion en y englobant tous les payements réguliers.

Nos liens économiques structurés dans le LN

Si l’on imagine un monde où Bitcoin et sa surcouche protocolaire LN sont dominants, cela aura sans doute la conséquence d’augmenter le frais on-chain, c’est-à-dire que l’ouverture et la fermeture de canaux auraient des coûts non négligeables. Dans une telle situation, les ouvertures de canaux se feraient de manière réfléchie, selon une stratégie moyen à long terme. D’autre part, les frais de payement de transfert sur LN seront comparativement négligeable, c’est à dire qu’une transaction de “rebalance” des canaux existants sera très avantageuse comparativement au réagencement des canaux eux-mêmes.

Dans une telle situation, les pairs favoriseront des canaux stables avec des mouvements réguliers et importants. Fanis parle du salaire, mais il y a aura également : les loyers, le magasin où l’on fait ses achats toutes les semaines, les abonnements en tous genre. Fanis parle aussi de la possibilité de versement de salaire en continu plutôt qu’une fois par mois, cela peut aussi fonctionner pour un loyer ou un abonnement téléphonique. J’ajouterais même que l’ouverture d’un canal de payement (donc on-chain) pourrait faire partie du contrat, voir même utiliser l’OP_RETURN comme signature du contrat. Nous pourrions même imaginer que l’éventuelle caution soient intégrée avec des conditions de dépensées adaptées à la même transaction que l’ouverture de canal lightning. Imaginez qu’il soit possible de stopper votre abonnement fitness en refermant simplement un canal LN. On pourrait également imaginer que l’ouverture d’un channel puisse servir d’affiliation de fidélité pour une chaîne de magasin, avec un cash back en satoshis lors de chaque achat. Imaginez payer vos impôts grâce à un canal spécialement aménagé pour cela, sans compter les taxes comme la TVA qui pourraient être collectées en temps réel.

Dans une telle configuration, les gens lambda auraient 5-10 canaux actifs en permanence, les entités connectées et la taille des canaux changeraient en fonction des liens économiques qui évoluent au fil de la vie.

La question de la discrétion

Fanis l’évoque : Est-ce une bonne idée ? Cela signifierait zéro frais, mais cela signifierait aussi que l’employé devrait passer par le nœud de l’employeur pour dépenser son salaire.

Pour moi, il s’agit d’un faux problème. Il est toujours possible de brouiller les pistes en faisant de fausses transactions (quasiment gratuites sur LN) et faire de nombreuses rebalancements entre ses canaux. Cela pourra même être automatisé. Je pense qu’une part non négligeable des transactions LN ne seront pas de réels payements mais des rebalancements et des transactions qui destinées à tromper les analyses.

Bien entendu, il est impossible de réellement connaître de quoi le futur sera fait alors même que le protocole Lightning n’est pas encore cristallisé et que les autres couches protocolaires sur Bitcoin ne sont encore qu’à l’état de projets. Mais se projeter permet d’imaginer l’infinité des possibles qu’offre le payement avec Bitcoin et me permet de réaliser à quel point nous avons de la chance d’être au milieu d’un monde nouveau à construire.

***

Ces prochaines semaines, il ne faut pas s’attendre à beaucoup d’articles. Je suis en pleine écriture d’un livre et je vais y consacrer mon temps de cerveau disponible.

En attendant, je poursuis la publication hebdomadaire de nouveaux cahiers est disponible sur printathome.cc. Cette semaine, un nouveau cahier du roman Le sanctuaire des Renégats de Pascal Lovis. Dès la rentrée 2022, je commencerai à publier les cahiers des nouveautés de la collection Ludomire.

Author: Ludomire

Leave a Reply

Your email address will not be published. Required fields are marked *