Rejoignez-Nous sur

Vous payer? L'auto-paiement pourrait être la clé de la confidentialité de Lightning

PaySwap Part 2 1 1200x630 cropped

News

Vous payer? L'auto-paiement pourrait être la clé de la confidentialité de Lightning

Le réseau Lightning est surtout connu pour ses paiements rapides et bon marché. Mais le protocole de couche 2 pourrait également offrir plus de confidentialité que les paiements en chaîne, puisque les transactions ne sont pas publiées sur la blockchain de Bitcoin, l'analyse de la blockchain est largement impossible.

Le Lightning Network présente cependant ses propres risques de confidentialité. Les paiements sont acheminés sur un réseau d'utilisateurs, et rien n'empêche les espions de participer à ce processus de transfert de transactions tout en surveillant le flux de fonds. Sur le réseau Lightning, l'analyse de la chaîne de blocs peut remplacer l'analyse du réseau.

Il existe des solutions pour limiter ces risques, comme Acheminement des oignons de style Tor. Ceux-ci aident, mais, selon la topologie du réseau et les types de paiements, des faiblesses peuvent subsister. Le développeur Bitcoin et Lightning sous le pseudonyme de ZmnSCPxj a, ces dernières semaines, publié une analyse approfondie des risques persistants sur le Liste de diffusion Lightning-dev (1, 2, 3).

Sur la base de son analyse, ZmnSCPxj a également proposé une solution. Semblable à Payswap – sa proposition de confidentialité sur la chaîne, couverte par Magazine Bitcoin il y a deux semaines – le développeur pense que les «auto-paiements» pourraient être une partie importante du puzzle de la confidentialité.

Compréhension Auto-paiement

Dans un article précédent, nous avons discuté de Payswap, une proposition de ZmnSCPxj visant à améliorer la confidentialité sur la chaîne en inversant apparemment la relation entre le payeur et le bénéficiaire. ZmnSCPxj a en fait initialement proposé cette idée dans le contexte du réseau Lightning. En fait, il serait probablement encore plus utile sur le réseau Lightning: certains des compromis intégrés dans l'alternative en chaîne ne s'appliquent pas au protocole de couche 2.

En bref, pour la version Lightning de Payswap, l'auto-paiement fait partie de la même voie de paiement.

Pour expliquer comment cela fonctionne, examinons une version extrêmement simplifiée d'un réseau Lightning. A (poux) a des canaux de paiement avec B (ob) et C (arol). Bob a des canaux avec Alice et D (ave). Carol a des canaux avec Alice et Dave. Et Dave a des chaînes avec Bob et Carol.

UN B

| |

| |

C – – D

Si Alice veut payer Dave 3 bitcoin, elle achemine normalement le paiement via Bob ou Carol. Bob ou Carol factureraient une somme modique pour le service, mais pour simplifier, nous allons ignorer les frais dans cet exemple. Cependant, le fait que, en réalité, les frais soient payés sera pertinent quelques paragraphes plus bas, alors gardez cela à l'esprit.

Pour l'instant, nous dirons qu'Alice opte pour l'itinéraire de Bob pour effectuer le paiement. Elle envoie 3 pièces à Bob, et Bob continue d'envoyer 3 pièces à Dave. Le paiement est un succès.

Mais malheureusement, dans cet exemple, il serait facile pour Bob de supposer correctement qu'Alice a payé à Dave 3 pièces. Il connaît le montant parce qu'il l'a transmis, alors que si Alice voulait payer Carol, ou Carol voulait payer Dave, ils auraient pu le faire directement, sans dépendre de Bob comme intermédiaire. Si Bob est un espion surveillant le trafic réseau, sa supposition correcte nuit à la vie privée d'Alice et de Dave.

ZmnSCPxj propose donc une alternative. Alice pourrait acheminer le paiement jusqu'à elle-même… un «auto-paiement», Dave prenant une très grosse «redevance». La redevance serait en réalité le véritable paiement.

Pour payer Dave comme auparavant, Alice achèterait, par exemple, 5 pièces cette fois. Tout d'abord, elle envoyait les 5 pièces à Bob, qui les transmettait à Dave. Ensuite – c'est l'astuce – Dave continuerait à transmettre le paiement, à Carol… mais il ne fait suivre que 2 pièces! Enfin, Carol transmettrait les 2 pièces à Alice. Au final, Alice est 3 pièces plus pauvre et Dave est 3 pièces plus riche. Par conséquent, Alice a payé 3 pièces à Dave.

Cet auto-paiement induirait en erreur Bob et Carol. Bob a transmis 5 pièces et peut logiquement mais à tort supposons qu'Alice ait payé 5 pièces à Dave. Pendant ce temps, Carol serait sans doute encore plus mal lotie: elle penserait que Dave a payé Alice 2 pièces. Du point de vue de Carol, la direction du paiement est inversée.

Si Bob ou Carol espionnaient secrètement l'activité du réseau, ils auraient été induits en erreur sur la taille et / ou la direction du paiement, bénéficiant à la confidentialité d'Alice et de Dave. Si les espions sont suffisamment induits en erreur, cela pourrait même rendre totalement inutile une telle activité d'espionnage.

PTLC, montants standard et plus

Tout dans l'exemple ci-dessus est simplifié, du graphique du réseau aux montants traités, tandis que les risques de confidentialité plus subtils tels que les montants des frais et les timelocks sont complètement ignorés. Pendant ce temps, on suppose que même si Bob et Carol sont des espions, ils ne coopèrent pas, ou pire: ils sont un espion prétendant être deux utilisateurs.

En réalité, les risques et les avantages du routage pour la vie privée sont à la fois plus grands et plus nuancés. Aborder toutes ces subtilités dépasse le cadre de cet article; Les soumissions de ZmnSCPxj à la liste de diffusion Lightning-dev sont une meilleure ressource pour une analyse plus approfondie. Et plus généralement, des recherches sur la confidentialité de Lightning sont en cours.

Néanmoins, il convient de souligner que les propositions de ZmnSCPxj pour améliorer la confidentialité de Lightning vont au-delà des auto-paiements – dans certains scénarios, des modifications de protocole supplémentaires seraient en fait plus ou moins nécessaires pour que les auto-paiements soient des améliorations efficaces de la confidentialité. Les deux changements les plus importants sont le passage des contrats de timelock hachés (HTLC) aux contrats de timelock à clé publique (PTLC) et l'adoption de montants standard. Voyons donc ces deux en bref.

À l'heure actuelle, les paiements Lightning sont acheminés à l'aide de HTLC. Tous les utilisateurs le long d'un itinéraire transmettent essentiellement un code qui garantit qu'ils peuvent réclamer des fonds d'une contrepartie si l'autre contrepartie réclame des fonds auprès d'eux (c'est ainsi que les fonds sont transférés sur le réseau). Malheureusement, si les espions coopérants font partie de la même route, ils peuvent utiliser les HTLC pour dire que différents sauts font en fait partie du même paiement, dans une certaine mesure, annulant les avantages du routage des oignons. Les PTLC exploiteraient des astuces cryptographiques pour empêcher les espions de relier différents sauts à la même route.

ZmnSCPxj propose également que les utilisateurs de Lightning adoptent des montants standard. Bien que facultatifs, les portefeuilles seraient encouragés à fractionner les paiements en paiements plus petits (mais liés), chaque paiement plus petit étant constitué de montants standard. Si les montants standard sont par exemple 1, 2 et 5 pièces, Alice dans l'exemple ci-dessus effectuerait deux paiements de 1 pièce et 2 pièces, au lieu d'un paiement de 3 (ou, si elle effectue un auto-paiement, elle pourrait envoyer 5 et route 2 vers elle-même).

Si suffisamment d'utilisateurs limitent leurs (fractions de) paiements à des montants standard, les espions ne peuvent pas compter sur des montants pour relier différents sauts au même paiement. Dans le contexte de l'auto-paiement, les utilisateurs peuvent même acheminer des montants non standard du bénéficiaire vers eux-mêmes, les faisant ressembler encore plus à des paiements réguliers.

Inconvénients d'auto-paiement

La version en chaîne de la proposition de ZmnSCPxj, ​​Payswap, comporte des compromis importants. Par rapport à un paiement régulier, davantage de transactions sont nécessaires, ce qui se traduit par des frais plus élevés. En plus de cela, les transactions Payswap nécessitent une interaction entre les utilisateurs en dehors du protocole Bitcoin; les transactions Bitcoin régulières ne le font pas.

Sur le réseau Lightning, ces inconvénients ne tiennent pas – ou ils tiennent dans une moindre mesure. Les paiements Lightning nécessitent une interaction dans les deux cas, donc un auto-paiement n'aggraverait pas la situation. Et bien que certains sauts de transaction supplémentaires soient nécessaires pour effectuer un auto-paiement, ces sauts se produisent hors chaîne, de sorte qu'ils ne nécessitent pas d'espace de blocage supplémentaire.

Cela dit, les paiements automatiques comportent toujours certains inconvénients, même sur Lightning. Bien que moins chers que les frais sur la chaîne, les sauts supplémentaires coûtent un peu plus cher en frais de routage. De plus, à mesure que davantage de sauts sont ajoutés à un paiement, le risque d'échec du paiement augmente et le risque qu'un espion fasse partie d'un itinéraire augmente également (si seulement Carol était une espionne dans l'exemple ci-dessus, l'auto-paiement serait lui ont donné plus d’informations qu’un simple itinéraire via Bob).

Enfin, bien sûr, il pourrait également y avoir d'autres compromis (encore imprévus); les auto-paiements sont une proposition relativement nouvelle. Comme ZmnSCPxj l'a conclu dans ses courriels, "Plus d'analyse sur l'utilisation des paiements circulaires lors du paiement peut être nécessaire."



Traduction de l’article de Aaron van Wirdum : Article Original

BlockBlog

Le Meilleur de l'Actualité Blockchain Francophone & Internationale | News, Guides, Avis & Tutoriels pour s'informer et démarrer facilement avec Bitcoin, les Crypto-Monnaies et le Blockchain. En Savoir Plus sur L'Équipe BlockBlog

Commenter cet Article

Commenter cet Article

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Plus dans News

Les Plus Populaires

Acheter des Bitcoin

Acheter des Alt-Coins

Sécuriser vos Cryptos

Vêtements et Produits Dérivés

Top
leo. dolor. ipsum leo in sit libero. eget porta.