Pourquoi se tatouer un QR code Lightning Network est une mauvaise idée ?

Le fondement même le contre-indique formellement, à l’heure actuelle. – L’idée n’est pas nouvelle : appeler aux dons en donnant un simple QR code Bitcoin, renvoyant vers une adresse de réception tout ce qu’elle a de plus classique. Nombreux ont été les aficionados du Bitcoin à s’afficher avec pareils tatouages pendant la folle année 2017, même si l’on pourra plus sobrement se souvenir de l’exemple de l’artiste Pascal Boyart, apposant, en plus de sa griffe, de tels QR codes sur certaines de ses oeuvres.

Merci pour vos premiers dons en #bitcoin ! Ça fait chaud au cœur de voir votre soutien 🙏.

"Rembrandt dos au mur", détail du qr code Bitcoin. Paris 2018.#pboy #pascalboyart #streetart #parisstreetart #streetartparis #rembrandt #btc #cryptoart #cryptocurrency pic.twitter.com/csd3PgsP1W

— Pascal Boyart 🎨 (@pascalboyart) May 6, 2018

Mais aujourd’hui, et alors que le Lightning Network poursuit son extension, posons-nous la question suivante : si l’envie nous en prenait, pourrions-nous nous partager aussi simplement de tels QR codes intemporels, mais renvoyant vers des “adresses Lightning” ?

Voyons ensemble pourquoi, en l’état, ce parallèle commis par votre serviteur n’a pas (encore) de réel sens.

Un rappel fugace : wallet Bitcoin classique et adresses associées

Intéressons-nous d’abord au pourquoi du comment de ces QR codes dans le cadre des bitcoins on-chain.

Pour rappel, les adresses publiques Bitcoin, comme des adresses mail, peuvent être partagées sans risques pour recevoir des paiements. Elles commencent par un 1 ou un 3, et elles sont chacune dérivées d’une clé privée. Il est donc possible d’agréger le contrôle de ces multiples adresses publiques au sein d’un wallet unique, centralisant ce contrôle par leurs clés privées associées.

Le point important nous concernant est le suivant : si des paramètres spécifiques peuvent être précisés par le payeur pour une transaction, notamment avec un QR code représentant une demande de paiement limitée dans le temps (par convenance pour le taux de change BTC/fiat lors d’une transaction), du point de vue du bénéficiaire d’un paiement en bitcoins, son adresse de réception est bien intemporellement valide une fois générée.

Aucun risque donc à littéralement se tatouer le QR code représentant cette adresse de réception, puisqu’elle continuera à pouvoir recevoir des fonds tant que le réseau Bitcoin vivra. La question du contrôle effectif de cette adresse par le bénéficiaire est une toute autre question, comme pourraient en témoigner un certain nombre de malheureux.

Lightning Network : le sablier empli de satoshis

Dans le cadre relativement nouveau du Lightning Network, le fonctionnement sous-jacent aux transactions en bitcoins transitant par ce réseau dit en seconde couche est un peu différent.

Pour pouvoir utiliser des soldes de bitcoins sur ledit réseau Lightning, il est nécessaire de les “transférer” vers ce réseau. Mais comment faire ?

Construit sur les règles protocolaires de Bitcoin, le réseau Lightning repose sur des noeuds spécifiques, déployés en parallèle et au-dessus de nœuds Bitcoin complets, sur lesquels nous ne reviendrons pas dans le cadre de cet article.

Pour pouvoir transférer des bitcoins on-chain vers ce réseau off-chain d’une manière souveraine, il faut donc à l’heure actuelle être capable de créer des canaux de connexion depuis son propre nœud LN vers d’autres nœuds LN.

À l’échelle de la blockchain Bitcoin, le payment channel en question revient à mettre sous séquestre des soldes de bitcoins à l’aide de transactions multisignatures impliquant les deux nœuds en question.

L’utilité de ce système est qu’il permet ensuite, une fois que de plus en plus de nœuds sont interconnectés, d’envoyer des paiements transitant par cette multitude de canaux jusqu’au destinataire final, en s’affranchissant du temps de confirmation classique lié aux transactions on-chain, puisque la disponibilité des fonds a déjà été validée en amont lors de cette mise sous séquestre.

[arve model= »gif » url= »https://journalducoin.com/app/uploads/2019/02/video-orage-lightning-nuages.mp4″ align= »center » promote_link= »no » autoplay= »yes » maxwidth= »480″ controlslist= »nodownload » controls= »no » loop= »yes » muted= »yes » /]

Le réseau Lightning, pour permettre cette prouesse, repose donc sur les HTLC, pour Hash Time-locked Contracts. Dans un tel système, les paiements se font via des promesses conditionnelles, qui ne sont validées qu’à l’arrivée.

Ainsi, si Alice veut payer Dave via le Lightning Network, elle va en résumé répondre à une demande de paiement de Dave. Cette demande de paiement, comme nous allons le voir, comprendra un secret (R) formaté à l’état de hash (H), secret que seule Alice détiendra, et qu’elle démontrera détenir ensuite pour délivrer son paiement.

Les joies de la facturation débridée

Pour pouvoir soutenir ce système de paiements par promesses conditionnées au secret, les paiements d’un nœud vers un autre, transitant par des nœuds intermédiaires, sont donc des paiements envoyés en réponse à une facture. C’est cette facture qui, entre autres informations, contient le secret en question.

Pour résumer, le Lightning Network permet au payeur de recevoir la facture de son récipiendaire, pour faire transiter des fonds déjà mis sous séquestre sur la blockchain Bitcoin sous-jacente, à l’aide d’intermédiaires prélevant leurs parts de frais de routage, et ne libérant chacun leur tour les fonds qu’une fois que chacun a prouvé qu’il a bien pris part à la chaîne du secret partagé, le tout dans une limite de temps imparti.

C’est maintenant le moment de revenir à la question du contenu de cette facture Lightning.

Ces dernières peuvent bien évidemment se présenter également sous la forme d’un QR code, mais incluent un nombre d’infos conséquentes spécifiques, à savoir :

• destination : à quel nœud doit arriver le paiement final,
• paiement_hash : hash de l’antécédent (préimage) qui verrouille ainsi le paiement en réel,
• num_satoshi : montant du paiement
• timestamp : moment de la création de la facture, important puisque pour le moment, ces factures doivent préciser des durées de validité,
• expiry : un délai maximum d’expiration, paramétrable, mais d’une durée standard de 1h.

Le temps, c’est de l’argent

C’est à ce point de l’article que nous arrivons à la composante temporelle actuelle des transactions via le Lightning Network.

Comme l’ont assez bien démontré les soucis de paiement rencontrés sur les premiers wallets custodial LN dans l’épisode de la Lightning Torch sur Twitter, cette nécessité de passer exclusivement par un système de factures à la validité limitée dans le temps a posé problème puisque certaines demandes de paiement déposées sur Twitter expiraient avant que le payeur n’arrive à temps pour les régler dans le délai imparti.

Nous n’entrerons pas non plus dans le détail des wallets LN compatibles, puisqu’ils sont assez principalement tous custodial dans leur ensemble pour le moment, c’est-à-dire que les clés privées associées aux adresses et aux nœuds des utilisateurs sont gérées par les développeurs de ces solutions.

L’on peut noter cependant par exemple les développements en cours d’Eclair Mobile à ce sujet, ou la relative possibilité laissée par certains de ces wallets aux utilisateurs les plus à l’aise techniquement de potentiellement se connecter à leurs propres noeuds LN.

S’il n’est ainsi pas directement possible à l’heure actuelle d’effectuer des paiements en dehors du système de facturation dans les diverses implémentations du Lightning Network, des solutions intermédiaires se développent pour autant.

La plus visible de ces nouveautés a ainsi récemment agité la twittosphère, avec l’arrivée du service Tippin.me, dont nous vous parlions tout récemment.

Interfaçant de manière tout à fait centralisée la possibilité de demander des paiements, le service s’occupe de générer des factures à mesure que ces dernières expirent. L’utilisateur peut ensuite gérer depuis un dashboard dédié les pourboires et dons divers reçus.
Mais qui reçoit ces paiements en définitive pour l’heure ?

Tout simplement Tippin.me, sur un nœud propriétaire, recevant ces divers dons là encore en votre nom.

Si le principe est sympathique à titre d’expérience et de relative praticité dans le contexte particulier de Twitter, au delà, il risque de se heurter ici aussi assez vite au refrain classique du “Not your keys, not your coins”.

Solutions pour permettre des paiements directs sans facture

Concluons en citant trois autres solutions disponibles ou en développement qui peuvent venir mitiger les difficultés évoquées ci-avant.

Si vous avez bien observé les différentes informations contenues dans la facture LN présenté plus tôt, vous aurez aperçu le champ dit fallback_addr : ce dernier permet de préciser une adresse Bitcoin classique on-chain vers laquelle envoyer classiquement les fonds si jamais la transaction sous sa forme électrisée et instantanée n’aboutissait pas, pour une raison ou pour une autre. Une solution de repli, à n’en pas douter, mais qui a le mérite d’exister.

De manière bien plus anecdotique, il est possible pour un utilisateur pour le moins à l’aise techniquement de se générer une facture à destination de lui-même, en orientant le paiement via une boucle transitant à un moment par le nœud destinataire final réel. Ainsi, l’on se paie cette facture, minimale, mais en incluant le montant final à payer à titre de routing fees pour le nœud final. Là encore, on est bien loin d’une utilisation mainstream, mais la démonstration en a bien été faite par René Pickhardt, développeur.

Enfin, et ce sera sans doute un des futurs développements à suivre avec attention, un travail en cours disponible sur le client LND vise à permettre le paiement LN sans facture, à l’aide de Sphinx : en somme, le secret est partagé différemment entre payeur et récipiendaire, à l’aide d’un routage en oignon spécifique.

[arve model= »gif » url= »https://journalducoin.com/app/uploads/2019/02/video-jim-carrey-mache-regard.mp4″ align= »center » promote_link= »no » autoplay= »yes » maxwidth= »480″ controlslist= »nodownload » controls= »no » loop= »yes » muted= »yes » /]

En somme, vous l’aurez compris, à se tatouer un QR Code Bitcoin sur le fondement, autant en rester aux bons vieux QR-code on-chain. Les progrès techniques en cours et le déploiement d’une infrastructure Lightning Network progressivement de moins en moins reckless n’interdisent cependant pas de rêver : les paiements spontanés Lightning sont de toute façon bien en chemin.