Lightning Chronicles 1

by
Fanis Michalakis
My articles My books
Follow on:

Les disciples du Bitcoin transportant le Nœud Saint en Terre Promise, Vallée de Tor (2020)

Tout a commencé en octobre 2020 quand, après des semaines de discussions, nous avons décidé d’enfin participer pleinement au Lightning Network au travers de notre propre « nœud de routage ». Cette série d’articles a pour but de raconter notre histoire, nos échecs, mais aussi nos succès.

Si vous souhaitez suivre notre périple et nous faire part de vos retours, n’hésitez pas à nous contacter sur Twitter : GuerillaV2 & FanisMichalakis.

Inspirés par la décision de MicroStrategy d’investir une partie de sa trésorerie en bitcoins, nous avons lancé le process pour que notre association étudiante, KryptoSphere, puisse faire de même, et utiliser nos fonds pour être partie prenante de l’inévitable expansion du Lightning Network. Dès le commencement, nous avons établi quelques règles et grands principes pour notre futur nœud :

• La métrique la plus importante devrait toujours être le volume/le nombre de paiements routés plutôt que le montant des frais collectés. En effet, en tant que projet étudiant, mais aussi et surtout en tant que groupe d’amis convaincus de l’importance du LN, la dimension de profitabilité associée à un nœud de routage n’était pas notre sujet principal.
• Nous voulions faire notre part pour le développement du réseau. Pour ce faire, nous devions collecter des données qui pourraient éventuellement aider nos semblables (des noobs du LN) à comprendre les sous-jacents techniques et économiques associés avec le fait de maintenir son propre nœud de routage.
• Expérimenter avec tout ce qui est à notre disposition pour faire de notre nœud l’un des plus efficients d’Europe. (i.e. router autant que possible, avec aussi peu de capital que possible, et un coût aussi faible que possible)
• Faire notre entrée dans le Top 100 du BOS score.
• Have Fun (en espérant ne pas stay poor).

Dans la première partie de cette série d’articles, nous reviendrons sur nos humbles débuts. Les premières difficultés pour monter un nœud sécurisé (oui, notre routeur internet a presque brûlé), la quête constante de nouvelles liquidités (parfois je me demande si l’on peut boire un canal Lightning, car quelqu’un doit être soul), et les inestimables leçons que nous avons apprises tout au long du chemin (choisir et se connecter à des “bons” nœuds, établir une politique de frais soutenable sur le long terme, le Ratio de Girard, etc.). Enfin, nous terminerons sur une vue d’ensemble des performances de notre nœud depuis octobre. Cette partie sera illustrée par quelques données que nous avons collectées et que Fanis a transformées en magnifiques graphiques. Bon appétit !

I/ Les choix que nous avons fait pour notre nœud : hardware, sécurité et le coût de la complaisance. (Fanis)

Quand il s’agit de faire tourner son propre nœud de routage Lightning, et espérer ne rien faire exploser au passage, quelques compétences, assez accessibles, sont nécessaires. En particulier, il semble un peu présomptueux d’essayer de faire tourner son nœud de routage sans quelques connaissances préalables du fonctionnement des systèmes UNIX et du Lightning Network. Dans cette partie de l’article, nous donnerons quelques détails sur les étapes que nous avons suivies pour améliorer la sécurité et l’efficacité de notre nœud de routage. Il faut cependant garder à l’esprit que :

• nous restons des amateurs,
• dans ce domaine, on n’a jamais vraiment terminé le travail !

Assembler le hardware

Un nœud Lightning commence par le matériel. Nous sommes restés simples et avons opté pour un Raspberry Pi 4 avec 4 GB de RAM et un SSD de 1 TB. Si vous souhaitez construire votre propre nœud, nous recommandons fortement l’emploi d’un SSD qui, s’il coûte un peu plus cher qu’un disque dur (à taille égale) compense largement ce surcoût par sa vitesse de lecture/écriture, en particulier durant la synchronisation initiale avec la timechain.

Essuyant quelques difficultés avec notre nœud, qui s’éteignait de manière impromptue, nous avons ajouté une boîte en aluminium de chez Flirc, qui permet de rafraîchir passivement le Raspberry (de 70°C sans Flirc à 45°C avec) et changé l’alimentation pour utiliser l’alimentation officielle, pour faire bonne mesure. Nous avons également ajouté un script récupérant périodiquement l’état de santé du Raspberry Pi (température, bridage du CPU, etc.) pour pouvoir analyser la situation si le problème se reproduisait — ce qui n’est jamais arrivé par la suite.

Un peu de sécurité

Un autre point de vigilance, s’agissant de Lightning, est la sécurité. Actuellement, pour utiliser Lightning, il faut placer ses fonds sur un hot wallet, et il est donc d’autant plus important de bien sécuriser ce dernier. Le secret étant un ingrédient clé de la sécurité, nous n’entrerons pas dans trop de détails concernant notre procédure de génération de mot de passe, mais voici quelques éléments que nous souhaitions partager.

Nous avons opté pour une génération de mots de passe à partir de lancers de dés. En utilisant une très longue liste de mots et quelques dés, nous avons généré différents mots de passe (notamment un pour Lightning Terminal, et un autre pour accéder au Raspberry Pi). Avec un nombre raisonnablement élevé de mots par mot de passe (un compromis entre entropie et facilité d’utilisation au quotidien), une fréquence de changement suffisamment haute et l’utilisation de fail2ban, nous avons atteint un niveau de sécurité dans lequel nous étions confiant, vis-à-vis des fonds en jeu. Pour ceux qui ne seraient pas familier avec fail2ban, il s’agit d’un outil qui permet de bloquer une adresse IP lorsque celle-ci tente de se connecter avec un mauvais mot de passe plusieurs fois d’affilée, ce qui permet de réduire le risque d’attaque par force brute. De plus, nous avons également limité l’accès au Raspberry Pi aux seuls possesseurs de certaines clés RSA (les nôtres), ce qui signifie que quiconque désirant se connecter devra également connaître l’une des clés. Nous avons également désactivé l’accès root via SSH.

Lorsqu’un mot de passe doit être changé (au bout d’un certain temps), nous le faisons au travers d’un appel sécurisé en lançant des dés et en partageant le résultat des lancers oralement. Ainsi, rien n’est écrit sur support numérique et, puisque nous n’échangeons que des nombres, un intrus devrait également connaître la liste que nous utilisons pour générer le mot de passe à partir des lancers. Nous pensons que cela confère à notre installation une sécurité suffisante au regard des fonds en jeu, dans notre cas particulier. Nous encourageons vivement le lecteur à peser le pour et le contre de diverses solutions et à ajuster le niveau de sécurité à ses besoins spécifiques.

Sauvegardes

Un aspect crucial à comprendre à propos de Lightning est que la récupération des fonds (si le nœud cesse de fonctionner par exemple) n’est pas aussi “simple” que pour un wallet Bitcoin classique. En effet, sur Lightning, les 12 ou 24 mots de phrase de sauvegarde (et les chemins de dérivations) ne suffisent pas pour retrouver ses fonds. Il faut également disposer d’une sauvegarde de ses canaux Lightning (channel backup), pour pouvoir correctement fermer ses canaux et récupérer ses fonds sur Bitcoin.

Le fichier channel.backup généré par lnd est donc quelque chose à sauvegarder en lieu sûr (et même en plusieurs lieux sûrs). Il est construit de telle sorte que sa diffusion à des serveurs externes n’entraîne pas trop de compromis en terme de privacy, et une bonne pratique consiste donc à faire un backup régulier de ce fichier sur au moins un serveur distant (idéalement, à chaque fois que le fichier est modifié). Nous le savions. Et pourtant, nous avons trop attendu pour agir en conséquence, ce qui aurait pu nous coûter beaucoup d’argent.

Une nuit, un énorme orage a éclaté dans la zone où notre nœud est situé, allant jusqu’à couper le courant et la connexion internet. Le lendemain matin, quand tout fut revenu à la normale, nous ne pouvions plus nous connecter à notre nœud. Souvenez-vous, nous avions quelques dizaines de millions de satoshis sur ce nœud, la plupart déjà engagés dans des canaux. La perte de notre fichier channel.backup aurait signifié la perte de nos fonds.

Heureusement, nous avons rapidement découvert que le SSD et la carte SD n’étaient pas endommagés. Le Raspberry Pi en lui-même semblait également fonctionner, si ce n’est pour la connexion ethernet qui semblait ne pas opérer. Et c’est alors que nous avons compris : l’orage avait littéralement brûlé les ports ethernet de la box internet qui étaient connectés à d’autres appareils. Ou, pour le dire différemment, les ports ethernet de la box ont magnifiquement joué leur rôle, se sacrifiant pour éviter que la surtension n’atteigne les appareils de l’autre côté. Ouf ! Les fonds étaient en sécurité, et nous avons résolu le problème simplement en branchant le nœud à un port ethernet intact.

TL;DR: notre nœud *Lightning* a failli être détruit par un *orage* alors que nous n’avions pas encore de backup pour nos fonds. Donc le jour même, nous avons exporté manuellement le fichier channel.backup vers un serveur distant et commencé l’écriture d’un script qui le ferait automatiquement à chaque modification du fichier. Le soir du même jour, le script était prêt et tournait sur le nœud. (un lien vers le script est disponible à la fin de l’article)

II/ Routin’Omics 101: Gérer sa liquidité, choisir les bon partenaires, et définir une politique de frais soutenable. (Guillaume)

Cette partie propose un aperçu des décisions que nous avons prises relativement à trois paramètres de notre nœud : les canaux, les frais et la liquidité.

Tout au long du process de documentation de l’activité de notre nœud, nous avons identifié trois phases différentes, correspondant aux progrès que nous avons accompli depuis le début de notre aventure.

La première phase : L’Etat Sauvage

Oui, l’état sauvage était celui des commencements de notre nœud KryptoSphere. Nous n’avions pour ainsi dire aucune idée (ou presque) de ce que nous faisions, et avons payé le coût de notre incompréhension vis-à-vis de notre environnement direct.

La première étape fut d’établir une liste de nœuds potentiels auxquels nous connecter. Mais comment choisir une liste de candidats viables ? L’objectif est de router autant que possible, donc un choix évident est de se connecter à de gros nœuds, en bonne santé, et bien connectés. A moins que..? Il va sans dire que tous les acteurs rationnels du réseau s’efforcent d’adopter une stratégie permettant de maximiser leur profit/générer une certaine forme de revenu passif. Nous avons donc essayé d’identifier des nœuds « sous-évalués », avec le meilleur potentiel de routage sans être déjà complètement inondés de liquidités.

Pour ce faire, nous avons utilisé nos connaissances de l’écosystème et les quelques outils à notre disposition. Ayant suivi l’évolution du Lightning Network depuis 2018, nous avions une idée assez précise de ce vers quoi nous tourner en termes d’entreprises en croissance opérant un nœud Lightning. (si ce n’est pas encore fait, vous devriez d’ailleurs vous abonner aux newsletters de LightningLabs et LNMarkets, toutes deux en anglais, pour ne rien rater de l’actualité du LN).

Anticipant un nouveau bull market et la probable augmentation des frais de transactions sur le layer 1 qui en découlerait, nous avons décidé de nous concentrer sur les plateformes d’échange, pariant sur une augmentation de l’intégration de Lightning par ces acteurs, ce qui leur permettrait de réduire drastiquement les frais de retraits pour leurs utilisateurs. Personne, nous disions nous, n’acceptera des frais exorbitants de 20$ comme ce fut le cas en 2017. Nous avons également porté notre attention sur des entreprises émergentes sur le Lightning Network qui pourraient voir une augmentation significative de leur usage ou de la vente de leurs produits dans les mois à venir (in retrospect, it was inevitable).

Avec l’aide de 1ML, de l’explorateur Acinq, et de l’un des esprits les plus brillants de l’écosystème Bitcoin, M. Romain Rouphael (co-fondateur de LNMarkets), nous avons sélectionnés les entités suivantes :

• LNMarkets : un no-brainer. Pariant sur la croissance de LNMarkets, nous avons choisi d’y allouer 4 231 948 sats.
• Southxchange : nous avons identifié Southxchange sur Twitter et regardé les statistiques de leur nœud sur 1ML. Nous avons décidé d’allouer 5 302 384 sats. Leur nœud est très bien connecté, avec beaucoup de liquidité, mais plus important encore nous croyons que leur localisation géographique (en Argentine) est très prometteuse.
• Tippin.me : nous connaissions tous Tippin avant cette aventure, et connaissions sa renommé dans la communauté, ce qui nous a amené à estimer qu’il y avait de bonnes chances de voir du traffic sur ce nœud. 5 134 843 sats alloués.
• Fold : est-il vraiment utile de nous justifier ? Fold est une application financière très utilisée outre-atlantique et, bien que leur noœud soit déjà très bien connecté, nous avons estimé qu’ils avaient un potentiel de croissance suffisant pour justifier une allocation de 5 037 248 sats.
• BCash_Is_Trash : le nom de ce nœud en lui-même était assez pour nous convaincre. Avec 6 103 938 sats alloués, ce nœud était très haut dans le score BOS, bien connecté et semblait globalement très sain.
• WalletOfSatoshi.com [2] : Un wallet mobile Lightning respecté, sous-évalué à l’époque d’après notre analyse, justifiant une allocation de 5 024 814 sats. [MAINTENANT FERME].
• OpenNode : un compétiteur sous-évalué de BTCPay, nous pensions donc qu’OpenNode avait un grand potentiel dans la facilitation de l’adoption par les commerçants. 3 894 562 sats. [MAINTENANT FERME]
• JohnOnChain : un camarade français qui routait déjà beaucoup et accepté d’ouvrir un canal avec nous. 1 957 452 sats. [MAINTENANT FERME]

L’ouverture du canal avec River Financial a marqué le début d’une époque dorée pour notre nœud. Much routing, sats go up. Guillaume étant un admirateur de longue date de River (positionnement unique, excellente expérience client, et l’un des premiers exchanges à voir le potentiel et la supériorité du LN pour leurs clients), il a tenté de les contacter directement sur Twitter pour les convaincre d’ouvrir un canal avec nous, avec succès !

Nous avons également ouvert un canal de 5 millions de satoshis avec Zebedee. Zebedee est un processeur de paiements basé sur Lightning, avec un focus sur les jeux tirant parti du LN, en permettant par exemple aux joueurs de gagner des satoshis en jeu. Notre décision d’ouvrir un canal avec eux a été guidée par l’amour de Fanis pour les jeux infusés de Bitcoin et Lightning, dont certains utilisent les service de Zebedee pour envoyer des paiements à leurs utilisateurs. Nous avons également estimé qu’il s’agissait d’un bon partenaire auquel se connecter, avec beaucoup de trafic mais toujours un peu sous les radars (comparé à des gros nœuds comme Bitrefill par exemple).

A l’ouverture du canal, nous nous sommes aperçus que les frais de leur côté étaient assez élevés (1000 ppm). Suspectant que cela pouvait être dû à un simple réglage par défaut de leur côté concernant des canaux non-sollicités, nous avons contacté Zebedee et ils ont rapidement baissé les frais à 1ppm (merci Big Boss André !). Morale de l’histoire : surveillez bien les frais de vos partenaires !

Un aspect auquel il faut prêter attention est la notion de channel acceptor, qui permet de refuser automatiquement les canaux dont la capacité est inférieure à un certain seuil. Alors que le nôtre était initialement défini sur 1 millions de satoshis (à peu près la taille médiane des canaux sur le réseau à l’époque), nous avons ensuite décidé de l’abaisser à 500 000 sats pour ne pas manquer d’opportunité.

Politique de frais

La première décision que nous avons prise concernant nos frais fut de réduire aussi bien la part fixe (base fee) que la part variable (fee rate). Nous pensions sans doute être des génies, nous imaginant router beaucoup de paiements par ce moyen. Ce qui arriva, comme l’indique le nom que nous avons choisi de donner à cette période, est que nous avons été brutalisé. Les autres nœuds du réseau ont profité de notre nœud et de ses frais très bas pour faire d’énormes paiements, drainant toute notre liquidité en quelques jours.

Un enseignement que nous avons tiré de tout ça : si l’on veut router beaucoup de paiement mais sans épuiser sa liquidité, un moyen d’y parvenir peut être de mettre ses frais fixes à 0 et d’augmenter les frais variables, de sorte à rendre le passage par son nœud plus cher pour les plus gros paiements. En augmentant nos frais variables de 1 à 100 ppm, nous avons constaté un net déclin du volume routé, et avons donc ajusté nos frais à 20 ppm, puis 5 ppm, qui est depuis notre politique de frais. Nous envisageons d’augmenter ces frais dans le futur, mais pour le moments il semblent apporter de bons résultats.

Comment rééquilibrer ses canaux ?

• Rééquilibrage circulaire : avec l’outil Balance of Satoshi de Alex Bosworth, nous avons utilisé ce type de rééquilibrage off-chain assez tôt. Cette technique passe uniquement par le Lightning Network, et puisqu’elle implique de payer des frais à chaque intermédiaire sur la route, cela peut s’avérer relativement onéreux, surtout pour de gros montants. Toutefois, dans un environnement de frais élevés sur la timechain Bitcoin, le rééquilibrage circulaire peut s’avérer la méthode la plus économe. Dans ce cas, nous recommandons de tester différentes routes proposées et de choisir la moins chère. (https://github.com/alexbosworth/balanceofsatoshis)
• Loop : développé par Lightning Labs, Loop est un outil permettant de rééquilibrer ses canaux en passant par la timechain Bitcoin. Plus d’infos ici :https://lightning.engineering/loop/. Nous avons beaucoup utilisé Loop pour rééquilibrer nos canaux, car à l’époque les frais sur Bitcoin étaient moins élevés qu’aujourd’hui, rendant cette méthode compétitive par rapport au rééquilibrage circulaire. En utilisant la ligne de commande, il est de plus possible d’éviter d’utiliser le mode « fast », qui est celui par défaut sur l’interface graphique, et d’éviter ainsi de payer des frais plus élevés lorsqu’on n’est pas pressé. La plupart de nos Loops sont passés avec des frais de transactions de 3 sats/vByte ou moins.

NamsBreakEvenPoint (Seuil de rentabilité de Nams) :

Afin de mesurer l’efficacité de son nœud de routage, il est possible d’utiliser le NamsBreakEvenPoint. Durant la première partie de notre expérimentation, nous avons choisi de nous concentrer sur le volume plutôt que sur les frais prélevés, mais nous utiliserons cette métrique dans le futur. Il est absolument nécessaire de mesurer les coûts associés au rééquilibrage de ses canaux, et de s’assurer que ces coûts ne soient pas supérieurs aux frais collectés. Nous ne divulguerons pas notre NamsBreakEvenPoint dans cette publication, car ce serait embarrassant pour tout le monde…

Puis nous avons perdu notre mojo. Ce fut l’Ère du Désespoir.

Oui… Nous n’avons plus rien fait pendant un mois entier, laissant notre cher nœud à l’abandon. Voyant notre volume routé s’effondrer jusqu’à 0 après notre dernier ajustement, nous avons perdu la motivation. Pour nous, nous avions échoué et notre nœud était « mort ». Du moins, c’est ce que nous pensions …

En fait, nous étions juste des idiots. Nous ne voyions pas le nouveau volume routé à cause d’une erreur dans notre script de visualisation, et notre stratégie fonctionnait en fait du tonnerre ! Je vais laisser Fanis vous expliquer ce qui s’est passé (puisque c’est de sa faute de toute façon. Faire confiance aux grecs pour gérer l’argent, on aurait dû savoir depuis 2011 …)

Lisez le p***** de manuel

Afin de suivre l’évolution du volume de paiements routés par notre nœud, nous avons mis en place un script assez simple qui utilise la commande lnd fwdinghistory pour récupérer les informations sur les paiements routés et les afficher dans un joli tableau. Mais le nombre de paiements routés par notre nœud a subitement cessé d’augmenter à exactement 100 paiements. Au bout d’un certain temps, nous avons fini par nous rendre compte que la commande fwdinghistory affichait en fait par défaut les 100 premiers paiements routés seulement. En utilisant la même commande mais en spécifiant que nous voulions voir tous les paiements (ie les 50 000 derniers paiements routés, ce qui est dans notre cas largement suffisant pour tous les voir), nous avons découvert que notre noeud avait en fait routé bon nombre de paiements au cours du dernier mois (environ 800). Nous ne pouvions juste pas le voir.

Il y a une leçon assez simple et généralisable à apprendre ici : quand on utilise un outil, il faut lire sa documentation avec attention. Le fait que la commande fwdinghistory devait être complétée par un argument max_events et n’afficherait par défaut que 100 paiements routés, était visible dans la documentation depuis le début.

Vous savez tout. Vient maintenant la Phase de la Renaissance.

Une fois notre petite erreur découverte et comprise, nous avons repris confiance dans notre capacité à devenir des seigneurs du routage. Un peu de nettoyage (rééquilibrage de certains canaux et réévaluation de notre stratégie) devait être fait avant de continuer nos opérations. Pour évaluer notre stratégie actuelle, nous avons analysé la manière dont nous pouvions gérer notre liquidité. En effet, nous avons remarqué que pendant notre mois d’absence, certains canaux semblaient se rééquilibrer tout seul, tandis que d’autres sont restés complètement déséquilibrés après le passage d’un seul gros paiement.

Gestion de la liquidité :

Nous avons vite appris que maintenir un nœud de routage Lightning reposait assez largement sur la gestion de la liquidité, car sans liquidité au bon endroit, les canaux de paiements sont inutiles.

Un indicateur pertinent pour atténuer un peu le fardeau de la gestion de la liquidité est l’AutoRebalanceQualityRatio.

AutoRebalanceQualityRatio

Nous avons utilisé ce ratio afin de déterminer si un canal peut se rééquilibrer de lui-même au cours du temps, afin de réduire nos coûts sur le long terme. Plus le ratio est proche de 0, plus le canal a démontré une propension à se rééquilibrer seul. Une stratégie viable pour un opérateur de nœud Lightning pourrait être de n’allouer des fonds qu’à des canaux dont le ratio est proche de 0.

Par exemple : tandis que LN Markets est un canal très performant en terme de volume routé, avec un ratio de 0.30 quelques rééquilibrages peuvent s’avérer nécessaires de temps à autres. De l’autre côté, un canal comme celui avec Zebedee, comparable en terme de volume routé, a un bien meilleur ratio, avec seulement 0.037 (!). Il faut cependant garder à l’esprit qu’il s’agit seulement d’une moyenne au cours du temps, et que d’autres facteurs doivent être considérés quand on évalue l’efficacité d’un canal (un canal avec un ratio de 1, comme celui avec River Financial, peut toujours router beaucoup de paiements, il faudra simplement le rééquilibrer régulièrement).

Analyse de notre routage :

Une autre métrique que nous avons commencé à suivre est le Ratio de Girard (modestement nommé d’après votre serviteur). Le Ratio de Girard est une mesure de l’efficacité globale de routage d’un nœud (ou d’un canal) en comparant le nombre bitcoins bloqués sur Lightning au volume routé grâce à ce montant mis en séquestre. Plus ce ratio est grand, mieux c’est. Par exemple, un ratio de 3 signifie que pour 1000 satoshis déposés dans un canal, ce canal a permis de router plus de 3000 satoshis.

Girard Ratio :

Le Ratio de Girard actuel de notre nœud est de 5.97, ce qui signifie qu’en moyenne notre nœud a routé presque six fois le montant de bitcoins que nous y avons déposé.

Pour le Ratio de Girard d’un canal en particulier, le mode de calcul peut être légèrement différent. Le but est de comparer deux canaux au travers de leur Ratio de Girard respectif. Nous estimons qu’un pair qui reçoit beaucoup de paiements (i.e. avec un important montant de “forwarded out”) devrait être traité à égalité par rapport à un pair qui envoie beaucoup de paiements (i.e. avec un gros montant en “forwarded in”), tout simplement parce qu’ils ne sont en fait que les deux côtés d’une même transaction qui passe à travers notre nœud. Il semble donc approprié de comptabiliser la somme à la fois des volumes entrants (“forwarded in”) et sortants (“forwarded out”) de chaque canal, sous l’appellation “TotalForwardedVolume”, et de diviser par le nombre de satoshis bloqués sur le canal.

On peut ainsi utiliser ce ratio pour comparer deux canaux. Par exemple, notre canal avec LN Markets a un ratio de 8,85 tandis que celui avec Zebedee a un ratio de 3,02. Cet éclairage permet d’apprécier le fait que, même si le canal avec Zebedee est celui qui s’auto-équilibre le plus (moins de maintenance pour nous), celui avec LN Markets est clairement devant en terme de volume !

* * *

Durant cette période de la fin juin à la mi-mars, nous avons atteint quelques jalons pour le nœud KryptoSphere que nous aimerions partager.

Nous ne sommes pas tout à fait certains de ce qui a pu causer la rapide accélération dans notre volume routé en février. Nous pensons que cela peut être dû au moins en partie au bull run sur Bitcoin, et notre stratégie ciblant en bonne partie des exchanges pour tirer parti de ce bull run et des augmentations brutales dans les frais de transactions sur Bitcoin qui en découlent.

Des jalons qui nous rendent fiers :

• plus de 1 BTC routé
• plus de 1000 paiements routés (1008)
• 854 satoshis collectés (outch ! mais le but initial n’était pas le profit)
• plus de 50 millions de satoshis de capacité pour le nœud KryptoSphere
• pas de problème majeur ou de perte de fonds (malgré tous nos essais)
• la découverte de métriques pertinentes (Ratio de Girard, NamsBreakEvenPoint, notre stratégie de frais et de gestion de la liquidité, …)
• des échanges avec des personnes et des entreprises impliquées dans le Lightning Network
• tout ce que nous avons appris à mesure que nous descendions dans le terrier du lapin !

Merci d’avoir lu cet article à propos de nos aventures sur le Lightning Network. Une seconde partie sera publiée dans quelques mois pour décrire la suite de nos expérimentations. Nous apprécions tout feedback ou idée pour notre seconde partie. Les données et graphiques présentés dans cet article peuvent être trouvés ici : https://distracted-panini-514ebe.netlify.app/

Nous aimerions remercier tout particulièrement Sohomang, Zied Hagui pour son génie sur Photoshop, et Romain Rouphael pour son aide précieuse, et les membres de KryptoSphere pour leur confiance. Et un gros merci aussi à Bitcoin.fr pour la publication de la présente traduction de l’article original.

Twitter : GuerillaV2 ; FanisMichalakis

Enfin, voici quelques scripts que nous avons écrits et utilisés pour la maintenance et la supervision de notre nœud. Ils ne sont pas parfaits, mais n’hésitez pas à les utiliser s’ils vous sont utiles :

• Casey est un outil qui permet de visualiser ses statistiques de routage sous forme de tableaux depuis le terminal en ligne de commande. Nous avons l’intention d’étendre son usage dans le futur (et de réécrire certaines parties de l’existant) : https://github.com/fanismichalakis/casey
• un script pour automatiser l’export du fichier channel.backup vers un serveur distant à chaque fois que le fichier est modifié (services systemd requis) : https://gist.github.com/fanismichalakis/5d3e77601d357362b54c797638a9597b
• un script qui automatise le déverrouillage de lnd lors de l’allumage du nœud. Très utile pour réduire la période d’indisponibilité lorsque le nœud s’éteint et se rallume tout seul pour quelque raison que ce soit (comme une coupure par exemple). Plus de détails pour mettre en place ce script sur votre propre nœud ici : https://stadicus.github.io/RaspiBolt/raspibolt_6A_auto-unlock.html

A propos du traducteur (également coauteur de l’article)

Étudiant à l’Ecole Centrale de Marseille, Fanis Michalakis est le responsable IT de l’association KryptoSphere. Il est notamment l’auteur de la série « Comprendre le Lightning Network » disponible sur sa chaine Youtube.