Bitcoin Lightning ou paiement on-chain : frais, confirmations et canaux

Les deux transfèrent une valeur libellée en bitcoin, mais n’utilisent pas la couche de base de la même façon. Un paiement on-chain crée une transaction que les nœuds Bitcoin relaient et que les mineurs peuvent inclure dans un bloc. Un paiement Lightning cherche une route à travers des canaux de paiement ; chaque paiement n’est pas publié comme une transaction Bitcoin distincte.

Cette différence joue sur les frais, la disponibilité, la confidentialité et les états affichés dans le portefeuille. Lightning n’est pas une autre monnaie, et « hors chaîne » ne signifie pas qu’un paiement échappe aux règles ou aux risques. Les participants utilisent des transactions Bitcoin pour ouvrir le canal et, si nécessaire, régler son solde.

Le portefeuille choisit des sorties disponibles, construit et signe une transaction, puis la diffuse aux nœuds Bitcoin. Ceux-ci peuvent la relayer et la conserver dans leur propre mempool jusqu’à ce qu’un mineur l’inclue dans un bloc. Les frais réseau dépendent de la taille de la transaction et du taux proposé, pas simplement de la quantité de bitcoins envoyée. Consultez le guide Bitcoin Developer sur le traitement des paiements.

Un identifiant permet de retrouver la transaction diffusée, mais sa visibilité ne signifie pas qu’elle est confirmée. Une confirmation indique qu’un bloc l’inclut ; les blocs suivants font augmenter ce nombre. Le service du destinataire ou sa politique de risque détermine le seuil attendu. Ni le rythme des blocs ni un objectif de confirmation ne garantissent que les fonds seront disponibles à une minute précise.

Le destinataire peut transmettre une facture Lightning qui encode une demande de paiement, souvent avec un montant, une destination, une description et une échéance. Le portefeuille du payeur la lit et cherche une route dont la capacité et les limites conviennent. La spécification BOLT 11 des factures décrit les champs ; BOLT 7 décrit les annonces de canaux et les mises à jour de routage.

Un paiement routé utilise des transferts conditionnels appelés HTLC. Chaque nœud intermédiaire reçoit le montant et les conditions temporelles du tronçon suivant ; le destinataire révèle le secret qui permet d’achever le paiement. La route peut échouer si la liquidité manque dans le bon sens, si une mise à jour est obsolète, si une limite est atteinte ou si un pair est indisponible. Un paiement Lightning réussi peut se terminer sans attendre un nouveau bloc, mais chaque facture n’est pas garantie d’aboutir.

Un canal de paiement commence par une transaction de financement on-chain et possède une capacité totale. Quand les participants se paient, le solde évolue sans publier une transaction Bitcoin pour chaque mise à jour. Ce qu’un côté peut envoyer à un instant donné dépend du solde dans cette direction, des réserves, des limites du paiement et de la route choisie. Le protocole pair à pair BOLT 2 décrit les paramètres de canal et les limites HTLC.

Un canal de grande capacité peut malgré tout manquer de liquidité sortante pour un paiement précis. Le destinataire peut également ne pas avoir de chemin entrant utilisable pour ce montant. Ouvrir un canal, déplacer la liquidité ou le fermer peut nécessiter des transactions et des frais on-chain. BOLT 5 sur le traitement on-chain détaille les fermetures coopératives et unilatérales. L’illustration distingue les paiements répétés par canal du financement et de la clôture réglés sur Bitcoin.

Les frais on-chain rémunèrent l’espace de bloc. Leur total dépend de la taille de la transaction et du taux choisi selon les conditions du moment ; une transaction plus grande peut coûter davantage même si elle envoie moins de bitcoins. Une estimation du portefeuille évolue avec le marché et ne réserve pas de place dans un futur bloc.

Les frais d’acheminement Lightning sont fixés par les opérateurs de canaux et peuvent combiner un montant de base et une part proportionnelle. La longueur de route, les politiques, la liquidité et le comportement du portefeuille modifient le coût. Certains portefeuilles peuvent ajouter leurs propres frais ou coûts de liquidité. Lightning peut coûter moins cher dans un cas particulier, mais n’est pas toujours gratuit ni moins cher qu’un paiement on-chain. Vérifiez le montant final, le détail des frais et les contraintes de route avant d’approuver.

Un portefeuille on-chain peut afficher les états diffusé, en attente ou confirmé. Les transactions et les blocs sont consultables publiquement sur la blockchain, et le destinataire peut appliquer le seuil de confirmation adapté au montant et au contexte. Une transaction peut rester en attente plus longtemps que prévu ; une estimation de frais ne décide pas du choix des mineurs.

Sur Lightning, la facture est réglée lorsque la route aboutit et que le portefeuille reçoit un résultat positif. Ce paiement n’est pas inscrit individuellement dans un bloc Bitcoin. Une tentative échouée n’est pas une confirmation, et un écran incertain ne prouve pas qu’un second paiement est sans risque. Avant de réessayer, vérifiez l’état final du portefeuille expéditeur et la facture ou le reçu du destinataire.

Les données on-chain sont publiques et analysables, même si une adresse ne révèle pas automatiquement le nom d’une personne. Le routage en oignon de Lightning vise à limiter les informations dont dispose chaque relais sur l’ensemble du parcours, sans rendre tous les paiements anonymes. La spécification BOLT 4 du routage en oignon et les annonces publiques de canaux décrites par BOLT 7 éclairent ce modèle.

Les portefeuilles diffèrent aussi par le contrôle des clés et la surveillance, la sauvegarde ou la récupération des canaux. Un portefeuille en auto-conservation et un compte Lightning custodial n’impliquent ni les mêmes responsabilités ni les mêmes risques de panne. La connexion internet, la disponibilité des pairs, l’état du canal, la récupération et les conditions du prestataire peuvent compter. Le mot « Lightning » ne suffit pas à connaître le modèle de garde ou la protection des sauvegardes.

L’on-chain peut convenir à un destinataire qui fournit une adresse Bitcoin et veut vérifier une transaction sur la blockchain. Lightning peut convenir entre portefeuilles compatibles si une facture et une route suffisamment liquide sont disponibles. Des paiements fréquents de faible montant peuvent réutiliser un canal, mais l’ouverture, la gestion et la fermeture ont leurs propres coûts et limites.

Avant l’envoi, vérifiez le type de paiement, le réseau, le montant, l’échéance de la facture, le destinataire, les frais affichés et les limites. Ne collez pas une facture Lightning dans un champ d’adresse on-chain et n’utilisez pas un parcours que le destinataire n’a pas demandé. N’employez une solution de repli on-chain que si la facture et le portefeuille la prennent explicitement en charge. À lire aussi : frais de transaction Bitcoin, confirmations des dépôts et liste de contrôle des transferts crypto.

Références techniques primaires : Bitcoin Developer Guide : traitement des paiements; BOLT 2 : protocole pair à pair; BOLT 4 : routage en oignon; BOLT 5 : transactions on-chain; BOLT 7 : annonces de routage; BOLT 11 : encodage des factures.