クリプトノート v2.0

Introduction

« Bitcoin » [1] est une mise en œuvre réussie du concept de monnaie électronique p2p. Les deux les professionnels et le grand public en sont venus à apprécier la combinaison pratique de transactions publiques et proof-of-work comme modèle de confiance. Aujourd'hui, la base d'utilisateurs de la monnaie électronique croît à un rythme soutenu ; les clients sont attirés par les frais peu élevés et l’anonymat assuré par la monnaie électronique et les commerçants valorisent son émission prévue et décentralisée. Bitcoin a a prouvé que l’argent électronique peut être aussi simple que le papier-monnaie et aussi pratique que le papier-monnaie. cartes de crédit. Malheureusement, Bitcoin souffre de plusieurs déficiences. Par exemple, le système distribué la nature est inflexible, empêchant la mise en œuvre de nouvelles fonctionnalités jusqu'à ce que presque tous les utilisateurs du réseau mettent à jour leurs clients. Certaines failles critiques qui ne peuvent pas être corrigées rapidement découragent les Bitcoin propagation généralisée. Dans des modèles aussi inflexibles, il est plus efficace de déployer un nouveau projet plutôt que de réparer perpétuellement le projet original. Dans cet article, nous étudions et proposons des solutions aux principales déficiences de Bitcoin. Nous croyons qu'un système prenant en compte les solutions que nous proposons conduira à une saine concurrence entre les différents systèmes de monnaie électronique. Nous proposons également notre propre monnaie électronique, « CryptoNote », un nom qui souligne la prochaine avancée dans le domaine de la monnaie électronique.

Bitcoin Inconvénients et solutions possibles

2 Bitcoin inconvénients et quelques solutions possibles 2.1 Traçabilité des transactions La confidentialité et l’anonymat sont les aspects les plus importants de l’argent électronique. Paiements peer-to-peer cherchent à être cachés à la vue des tiers, une différence nette par rapport aux systèmes traditionnels. bancaire. En particulier, T. Okamoto et K. Ohta ont décrit six critères de la monnaie électronique idéale, qui incluait « la vie privée : la relation entre l'utilisateur et ses achats doit être introuvable par n’importe qui » [30]. De leur description, nous avons dérivé deux propriétés dont une personne totalement anonyme le modèle de monnaie électronique doit satisfaire afin de se conformer aux exigences décrites par Okamoto et Ohta : Intraçabilité : pour chaque transaction entrante, tous les expéditeurs possibles sont équiprobables. Inassociation : pour deux transactions sortantes, il est impossible de prouver qu'elles ont été envoyées à la même personne. Malheureusement, Bitcoin ne satisfait pas à l'exigence d'intracabilité. Puisque toutes les transactions qui ont lieu entre les participants du réseau sont publiques, toute transaction peut être 1 CryptoNote version 2.0 Nicolas van Saberhagen 17 octobre 2013 1 Introduction « Bitcoin » [1] est une mise en œuvre réussie du concept de monnaie électronique p2p. Les deux les professionnels et le grand public en sont venus à apprécier la combinaison pratique de transactions publiques et proof-of-work comme modèle de confiance. Aujourd'hui, la base d'utilisateurs de la monnaie électronique croît à un rythme soutenu ; les clients sont attirés par les frais peu élevés et l’anonymat assuré par la monnaie électronique et les commerçants valorisent son émission prévue et décentralisée. Bitcoin a a prouvé que l’argent électronique peut être aussi simple que le papier-monnaie et aussi pratique que le papier-monnaie. cartes de crédit. Malheureusement, Bitcoin souffre de plusieurs déficiences. Par exemple, le système distribué la nature est inflexible, empêchant la mise en œuvre de nouvelles fonctionnalités jusqu'à ce que presque tous les utilisateurs du réseau mettent à jour leurs clients. Certaines failles critiques qui ne peuvent pas être corrigées rapidement découragent les Bitcoin propagation généralisée. Dans des modèles aussi inflexibles, il est plus efficace de déployer un nouveau projet plutôt que de réparer perpétuellement le projet original. Dans cet article, nous étudions et proposons des solutions aux principales déficiences de Bitcoin. Nous croyons qu'un système prenant en compte les solutions que nous proposons conduira à une saine concurrence entre les différents systèmes de monnaie électronique. Nous proposons également notre propre monnaie électronique, « CryptoNote », un nom qui souligne la prochaine avancée dans le domaine de la monnaie électronique. 2 Bitcoin inconvénients et quelques solutions possibles 2.1 Traçabilité des transactions La confidentialité et l’anonymat sont les aspects les plus importants de l’argent électronique. Paiements peer-to-peer cherchent à être cachés à la vue des tiers, une différence nette par rapport aux systèmes traditionnels. bancaire. En particulier, T. Okamoto et K. Ohta ont décrit six critères de la monnaie électronique idéale, qui incluait « la vie privée : la relation entre l'utilisateur et ses achats doit être introuvable par n’importe qui » [30]. De leur description, nous avons dérivé deux propriétés dont une personne totalement anonyme le modèle de monnaie électronique doit satisfaire afin de se conformer aux exigences décrites par Okamoto et Ohta : Intraçabilité : pour chaque transaction entrante, tous les expéditeurs possibles sont équiprobables. Inassociation : pour deux transactions sortantes, il est impossible de prouver qu'elles ont été envoyées à la même personne. Malheureusement, Bitcoin ne satisfait pas à l'exigence d'intracabilité. Puisque toutes les transactions qui ont lieu entre les participants du réseau sont publiques, toute transaction peut être 1 3 Bitcoin échoue définitivement à l'« intraçabilité ». Quand je vous envoie du BTC, le portefeuille à partir duquel il est envoyé est irrévocablement estampillé sur le blockchain. Il n'y a aucun doute sur qui a envoyé ces fonds, car seul celui qui connaît les clés privées peut les envoyer.sans ambiguïté jusqu'à une origine et un destinataire final uniques. Même si deux participants échangent fonds de manière indirecte, une méthode de recherche de chemin correctement conçue révélera l’origine et destinataire final. On soupçonne également que Bitcoin ne satisfait pas à la deuxième propriété. Certains chercheurs a déclaré ([33, 35, 29, 31]) qu'une analyse minutieuse blockchain peut révéler un lien entre les utilisateurs du réseau Bitcoin et leurs transactions. Bien qu'un certain nombre de méthodes soient contesté [25], on soupçonne que de nombreuses informations personnelles cachées peuvent être extraites du base de données publique. L’incapacité de Bitcoin à satisfaire les deux propriétés décrites ci-dessus nous amène à conclure qu’il est il ne s'agit pas d'un système de monnaie électronique anonyme mais pseudo-anonyme. Les utilisateurs ont été rapides à développer solutions pour contourner cette lacune. Deux solutions directes étaient les « services de blanchiment » [2] et le développement de méthodes distribuées [3, 4]. Les deux solutions sont basées sur l'idée du mélange plusieurs transactions publiques et leur envoi via une adresse intermédiaire ; qui à son tour présente l’inconvénient de nécessiter un tiers de confiance. Récemment, un schéma plus créatif a été proposé par I. Miers et al. [28] : « Zérocoin ». Zérocoin utilise des accumulateurs cryptographiques unidirectionnels et des preuves sans connaissance qui permettent aux utilisateurs de « convertissez » les bitcoins en zerocoins et dépensez-les en utilisant une preuve de propriété anonyme au lieu de signatures numériques explicites basées sur une clé publique. Cependant, de telles preuves de connaissances ont une constante mais taille peu pratique - environ 30 Ko (sur la base des limites Bitcoin actuelles), ce qui fait la proposition peu pratique. Les auteurs admettent qu'il est peu probable que le protocole soit un jour accepté par la majorité des Bitcoin utilisateurs [5]. 2.2 La fonction proof-of-work Le créateur de Bitcoin, Satoshi Nakamoto, a décrit l'algorithme de prise de décision majoritaire comme « un processeur, un vote » et a utilisé une fonction de tarification liée au processeur (double SHA-256) pour son proof-of-work. schéma. Étant donné que les utilisateurs votent pour l'ordre d'historique unique des transactions [1], le caractère raisonnable et la cohérence de ce processus sont des conditions critiques pour l’ensemble du système. La sécurité de ce modèle souffre de deux inconvénients. Premièrement, cela nécessite 51 % du réseau la puissance minière doit être sous le contrôle d’utilisateurs honnêtes. Deuxièmement, la progression du système (corrections de bugs, correctifs de sécurité, etc...) nécessitent que l'écrasante majorité des utilisateurs soutiennent et acceptent le changements (cela se produit lorsque les utilisateurs mettent à jour leur logiciel de portefeuille) [6]. Enfin, ce même vote Le mécanisme est également utilisé pour les sondages collectifs sur la mise en œuvre de certaines fonctionnalités [7]. Cela nous permet de conjecturer les propriétés qui doivent être satisfaites par le proof-of-work fonction de tarification. Une telle fonction ne doit pas permettre à un participant au réseau d'avoir un avantage sur un autre participant ; cela nécessite une parité entre le matériel commun et le haut coût des appareils personnalisés. À partir des exemples récents [8], nous pouvons voir que la fonction SHA-256 utilisée dans l'architecture Bitcoin ne possède pas cette propriété car l'exploitation minière devient plus efficace sur GPU et périphériques ASIC par rapport aux processeurs haut de gamme. Par conséquent, Bitcoin crée des conditions favorables à un écart important entre le pouvoir de vote des participants car cela viole le principe « un CPU, une voix » puisque les propriétaires de GPU et d'ASIC possèdent un pouvoir de vote beaucoup plus important par rapport aux propriétaires de processeurs. C'est un exemple classique de Principe de Pareto selon lequel 20 % des participants d’un système contrôlent plus de 80 % des voix. On pourrait affirmer qu’une telle inégalité n’est pas pertinente pour la sécurité du réseau puisqu’elle n’est pas pertinente. le petit nombre de participants contrôlant la majorité des votes mais l'honnêteté de ceux-ci participants qui comptent. Cependant, un tel argument est quelque peu erroné puisqu’il s’agit plutôt du possibilité d’apparition de matériel spécialisé bon marché plutôt que l’honnêteté des participants qui constitue une menace. Pour le démontrer, prenons l’exemple suivant. Supposons qu'un malveillant L’individu acquiert un pouvoir minier significatif en créant sa propre ferme minière grâce à des prix bon marché. 2 sans ambiguïté jusqu'à une origine et un destinataire final uniques. Même si deux participants échangent fonds de manière indirecte, une méthode de recherche de chemin correctement conçue révélera l’origine et destinataire final. On soupçonne également que Bitcoin ne satisfait pas à la deuxième propriété. Certains chercheurs a déclaré ([33, 35, 29, 31]) qu'une analyse minutieuse blockchain peut révéler un lien entre les utilisateurs du réseau Bitcoin et leurs transactions. Bien qu'un certain nombre de méthodes soient réSelon le [25], on soupçonne que de nombreuses informations personnelles cachées peuvent être extraites du base de données publique. L’incapacité de Bitcoin à satisfaire les deux propriétés décrites ci-dessus nous amène à conclure qu’il est il ne s'agit pas d'un système de monnaie électronique anonyme mais pseudo-anonyme. Les utilisateurs ont été rapides à développer solutions pour contourner cette lacune. Deux solutions directes étaient les « services de blanchiment » [2] et le développement de méthodes distribuées [3, 4]. Les deux solutions sont basées sur l'idée du mélange plusieurs transactions publiques et leur envoi via une adresse intermédiaire ; qui à son tour présente l’inconvénient de nécessiter un tiers de confiance. Récemment, un schéma plus créatif a été proposé par I. Miers et al. [28] : « Zérocoin ». Zérocoin utilise des accumulateurs cryptographiques unidirectionnels et des preuves sans connaissance qui permettent aux utilisateurs de « convertissez » les bitcoins en zerocoins et dépensez-les en utilisant une preuve de propriété anonyme au lieu de signatures numériques explicites basées sur une clé publique. Cependant, de telles preuves de connaissances ont une constante mais taille peu pratique - environ 30 Ko (sur la base des limites Bitcoin actuelles), ce qui fait la proposition peu pratique. Les auteurs admettent qu'il est peu probable que le protocole soit un jour accepté par la majorité des Bitcoin utilisateurs [5]. 2.2 La fonction proof-of-work Le créateur de Bitcoin, Satoshi Nakamoto, a décrit l'algorithme de prise de décision majoritaire comme « un processeur, un vote » et a utilisé une fonction de tarification liée au processeur (double SHA-256) pour son proof-of-work. schéma. Étant donné que les utilisateurs votent pour l'ordre unique d'historique des transactions [1], le caractère raisonnable et la cohérence de ce processus sont des conditions critiques pour l’ensemble du système. La sécurité de ce modèle souffre de deux inconvénients. Premièrement, cela nécessite 51 % du réseau la puissance minière doit être sous le contrôle d’utilisateurs honnêtes. Deuxièmement, la progression du système (corrections de bugs, correctifs de sécurité, etc...) nécessitent que l'écrasante majorité des utilisateurs soutiennent et acceptent le changements (cela se produit lorsque les utilisateurs mettent à jour leur logiciel de portefeuille) [6]. Enfin, ce même vote Le mécanisme est également utilisé pour les sondages collectifs sur la mise en œuvre de certaines fonctionnalités [7]. Cela nous permet de conjecturer les propriétés qui doivent être satisfaites par le proof-of-work fonction de tarification. Une telle fonction ne doit pas permettre à un participant au réseau d'avoir un avantage sur un autre participant ; cela nécessite une parité entre le matériel commun et le haut coût des appareils personnalisés. À partir des exemples récents [8], nous pouvons voir que la fonction SHA-256 utilisée dans l'architecture Bitcoin ne possède pas cette propriété car l'exploitation minière devient plus efficace sur GPU et périphériques ASIC par rapport aux processeurs haut de gamme. Par conséquent, Bitcoin crée des conditions favorables à un écart important entre le pouvoir de vote des participants car cela viole le principe « un CPU, une voix » puisque les propriétaires de GPU et d'ASIC possèdent un pouvoir de vote beaucoup plus important par rapport aux propriétaires de processeurs. C'est un exemple classique de Principe de Pareto selon lequel 20 % des participants d’un système contrôlent plus de 80 % des voix. On pourrait affirmer qu’une telle inégalité n’est pas pertinente pour la sécurité du réseau puisqu’elle n’est pas pertinente. le petit nombre de participants contrôlant la majorité des votes mais l'honnêteté de ceux-ci participants qui comptent. Cependant, un tel argument est quelque peu erroné puisqu’il s’agit plutôt du possibilité d’apparition de matériel spécialisé bon marché plutôt que l’honnêteté des participants qui constitue une menace. Pour le démontrer, prenons l’exemple suivant. Supposons qu'un malveillant L’individu acquiert un pouvoir minier significatif en créant sa propre ferme minière grâce à des prix bon marché. 2 4 Vraisemblablement, si chaque utilisateur contribue à son propre anonymat en générant toujours une nouvelle adresse pour CHAQUE paiement reçu (ce qui est absurde mais techniquement la façon "correcte" de le faire), et si chaque utilisateur contribuait à l’anonymat des autres en insistant sur le fait qu’il n’envoie jamais de fonds à la même adresse BTC deux fois, alors Bitcoin ne transmettrait toujours que de manière circonstancielle le test de dissociation. Pourquoi? Les données sur les consommateurs peuvent être utilisées à tout moment pour déterminer une quantité étonnante de choses sur les gens. Voir, par exemple http://www.applieddatalabs.com/content/target-knows-it-shows Maintenant, imaginez que nous soyons dans 20 ans et imaginez encore plus que Target ne savait pas seulement sur vos habitudes d'achat chez Target, mais ils exploitaient le blockchain pendant TOUS VOS ACHATS PERSONNELS AVEC VOTRE PORTEFEUILLE COINBASE POUR LE PASSÉ DOUZE ANS. Ils diront "Hé mon pote, tu voudras peut-être acheter des médicaments contre la toux ce soir, tu ne le feras pas". je me sentirai bien demain." Cela peut ne pas être le cas si le tri multipartite est exploité correctement. Voir par exemple ceciarticle de blog : http://blog.ezyang.com/2012/07/secure-multiparty-bitcoin-anonymization/ Je ne suis pas totalement convaincu des calculs à ce sujet, mais... un article à la fois, n'est-ce pas ? Citation nécessaire. Alors que le protocole Zerocoin (standalone) peut s'avérer insuffisant, le Zerocash le protocole semble avoir implémenté des transactions de 1 Ko. Ce projet est soutenu par les militaires américains et israéliens, bien sûr, alors qui connaît sa robustesse. De l'autre D’un autre côté, personne ne veut plus pouvoir dépenser des fonds sans surveillance que l’armée. http://zerocash-project.org/ Je ne suis pas convaincu... voir, par exemple, http://fc14.ifca.ai/bitcoin/papers/bitcoin14_submission_12.pdf Citant un développeur de Cryptonote, Maurice Planck (vraisemblablement un pseudonyme) de la cryptonote forums : "Zérocoin, Zérocash. C’est la technologie la plus avancée, je dois l’admettre. Oui, la citation ci-dessus est issu de l’analyse de la version précédente du protocole. A ma connaissance, ce n'est pas le cas 288, mais 384 octets, mais c'est quand même une bonne nouvelle. Ils ont utilisé une toute nouvelle technique appelée SNARK, qui présente certains inconvénients : par exemple, grande base de données initiale de paramètres publics nécessaires à la création d'une signature (plus de 1 Go) et temps important nécessaire pour créer une transaction (plus d'une minute). Enfin, ils utilisent un jeune crypto, que j'ai mentionné comme étant une idée discutable : https://forum.cryptonote.org/viewtopic.php?f= " - Maurice P. jeu. 3 avril 2014 19:56 Une fonction exécutée dans le CPU et qui ne convient pas aux GPU, FPGA ou ASIC calcul. Le « puzzle » utilisé dans proof-of-work est appelé fonction de tarification, fonction de coût ou fonction de puzzle.

sans ambiguïté jusqu'à une origine et un destinataire final uniques. Même si deux participants échangent fonds de manière indirecte, une méthode de recherche de chemin correctement conçue révélera l’origine et destinataire final. On soupçonne également que Bitcoin ne satisfait pas à la deuxième propriété. Certains chercheurs a déclaré ([33, 35, 29, 31]) qu'une analyse minutieuse blockchain peut révéler un lien entre les utilisateurs du réseau Bitcoin et leurs transactions. Bien qu'un certain nombre de méthodes soient contesté [25], on soupçonne que de nombreuses informations personnelles cachées peuvent être extraites du base de données publique. L'incapacité de Bitcoin à satisfaire les deux propriétés décrites ci-dessus nous amène à conclure qu'il est il ne s'agit pas d'un système de monnaie électronique anonyme mais pseudo-anonyme. Les utilisateurs ont été rapides à développer solutions pour contourner cette lacune. Deux solutions directes étaient les « services de blanchiment » [2] et le développement de méthodes distribuées [3, 4]. Les deux solutions sont basées sur l'idée du mélange plusieurs transactions publiques et leur envoi via une adresse intermédiaire ; qui à son tour présente l’inconvénient de nécessiter un tiers de confiance. Récemment, un schéma plus créatif a été proposé par I. Miers et al. [28] : « Zérocoin ». Zérocoin utilise des accumulateurs cryptographiques unidirectionnels et des preuves sans connaissance qui permettent aux utilisateurs de « convertissez » les bitcoins en zerocoins et dépensez-les en utilisant une preuve de propriété anonyme au lieu de signatures numériques explicites basées sur une clé publique. Cependant, de telles preuves de connaissances ont une constante mais taille peu pratique - environ 30 Ko (sur la base des limites Bitcoin actuelles), ce qui fait la proposition peu pratique. Les auteurs admettent qu'il est peu probable que le protocole soit un jour accepté par la majorité des Bitcoin utilisateurs [5]. 2.2 La fonction proof-of-work Le créateur de Bitcoin, Satoshi Nakamoto, a décrit l'algorithme de prise de décision majoritaire comme « un processeur, un vote » et a utilisé une fonction de tarification liée au processeur (double SHA-256) pour son proof-of-work. schéma. Étant donné que les utilisateurs votent pour l'ordre d'historique unique des transactions [1], le caractère raisonnable et la cohérence de ce processus sont des conditions critiques pour l’ensemble du système. La sécurité de ce modèle souffre de deux inconvénients. Premièrement, cela nécessite 51 % du réseau la puissance minière doit être sous le contrôle d’utilisateurs honnêtes. Deuxièmement, la progression du système (corrections de bugs, correctifs de sécurité, etc...) nécessitent que l'écrasante majorité des utilisateurs soutiennent et acceptent le changements (cela se produit lorsque les utilisateurs mettent à jour leur logiciel de portefeuille) [6]. Finalement, ce même vote Le mécanisme est également utilisé pour les sondages collectifs sur la mise en œuvre de certaines fonctionnalités [7]. Cela nous permet de conjecturer les propriétés qui doivent être satisfaites par le proof-of-work fonction de tarification. Une telle fonction ne doit pas permettre à un participant au réseau d'avoir un avantage sur un autre participant ; cela nécessite une parité entre le matériel commun et le haut coût des appareils personnalisés. À partir d'exemples récents [8], nous pouvons voir que la fonction SHA-256 utilisée dans l'architecture Bitcoin ne possède pas cette propriété car l'exploitation minière devient plus efficace sur GPU et périphériques ASIC par rapport aux processeurs haut de gamme. Par conséquent, Bitcoin crée des conditions favorables à un écart important entre le pouvoir de vote des participants car cela viole le principe « un CPU, une voix » puisque les propriétaires de GPU et d'ASIC possèdent un pouvoir de vote beaucoup plus important par rapport aux propriétaires de processeurs. C'est un exemple classique de Principe de Pareto selon lequel 20 % des participants d’un système contrôlent plus de 80 % des voix. On pourrait affirmer qu’une telle inégalité n’est pas pertinente pour la sécurité du réseau puisqu’elle n’est pas pertinente. le petit nombre de participants contrôlant la majorité des votes mais l'honnêteté de ceux-ci participants qui comptent. Cependant, un tel argument est quelque peu erroné puisqu’il s’agit plutôt du possibilité d’apparition de matériel spécialisé bon marché plutôt que l’honnêteté des participants qui constitue une menace. Pour le démontrer, prenons l’exemple suivant. Supposons qu'un malveillant L’individu acquiert un pouvoir minier significatif en créant sa propre ferme minière grâce à des prix bon marché. 2 sans ambiguïté jusqu'à une origine et un destinataire final uniques. Même si deux participants échangent fonds de manière indirecte, une méthode de recherche de chemin correctement conçue révélera l’origine et destinataire final. On soupçonne également que Bitcoin ne satisfait pas à la deuxième propriété. Certains chercheurs a déclaré ([33, 35, 29, 31]) qu'une analyse minutieuse blockchain peut révéler un lien entre les utilisateurs du réseau Bitcoin et leurs transactions. Bien qu'un certain nombre de méthodes soient réSelon [25], on soupçonne que de nombreuses informations personnelles cachées peuvent être extraites du base de données publique. L'incapacité de Bitcoin à satisfaire les deux propriétés décrites ci-dessus nous amène à conclure qu'il est il ne s'agit pas d'un système de monnaie électronique anonyme mais pseudo-anonyme. Les utilisateurs ont été rapides à développer solutions pour contourner cette lacune. Deux solutions directes étaient les « services de blanchiment » [2] et le développement de méthodes distribuées [3, 4]. Les deux solutions sont basées sur l'idée du mélange plusieurs transactions publiques et leur envoi via une adresse intermédiaire ; qui à son tour présente l’inconvénient de nécessiter un tiers de confiance. Récemment, un schéma plus créatif a été proposé par I. Miers et al. [28] : « Zérocoin ». Zérocoin utilise des accumulateurs cryptographiques unidirectionnels et des preuves sans connaissance qui permettent aux utilisateurs de « convertissez » les bitcoins en zerocoins et dépensez-les en utilisant une preuve de propriété anonyme au lieu de signatures numériques explicites basées sur une clé publique. Cependant, de telles preuves de connaissances ont une constante mais taille peu pratique - environ 30 Ko (sur la base des limites Bitcoin actuelles), ce qui fait la proposition peu pratique. Les auteurs admettent qu'il est peu probable que le protocole soit un jour accepté par la majorité des Bitcoin utilisateurs [5]. 2.2 La fonction proof-of-work Le créateur de Bitcoin, Satoshi Nakamoto, a décrit l'algorithme de prise de décision majoritaire comme « un processeur, un vote » et a utilisé une fonction de tarification liée au processeur (double SHA-256) pour son proof-of-work. schéma. Étant donné que les utilisateurs votent pour l'ordre d'historique unique des transactions [1], le caractère raisonnable et la cohérence de ce processus sont des conditions critiques pour l’ensemble du système. La sécurité de ce modèle souffre de deux inconvénients. Premièrement, cela nécessite 51 % du réseau la puissance minière doit être sous le contrôle d’utilisateurs honnêtes. Deuxièmement, la progression du système (corrections de bugs, correctifs de sécurité, etc...) nécessitent que l'écrasante majorité des utilisateurs soutiennent et acceptent le changements (cela se produit lorsque les utilisateurs mettent à jour leur logiciel de portefeuille) [6]. Enfin, ce même vote Le mécanisme est également utilisé pour les sondages collectifs sur la mise en œuvre de certaines fonctionnalités [7]. Cela nous permet de conjecturer les propriétés qui doivent être satisfaites par le proof-of-work fonction de tarification. Une telle fonction ne doit pas permettre à un participant au réseau d'avoir un avantage sur un autre participant ; cela nécessite une parité entre le matériel commun et le haut coût des appareils personnalisés. À partir des exemples récents [8], nous pouvons voir que la fonction SHA-256 utilisée dans l'architecture Bitcoin ne possède pas cette propriété car l'exploitation minière devient plus efficace sur GPU et périphériques ASIC par rapport aux processeurs haut de gamme. Par conséquent, Bitcoin crée des conditions favorables à un écart important entre le pouvoir de vote des participants car cela viole le principe « un CPU, une voix » puisque les propriétaires de GPU et d'ASIC possèdent un pouvoir de vote beaucoup plus important par rapport aux propriétaires de processeurs. C'est un exemple classique de Principe de Pareto selon lequel 20 % des participants d’un système contrôlent plus de 80 % des voix. On pourrait affirmer qu’une telle inégalité n’est pas pertinente pour la sécurité du réseau puisqu’elle n’est pas pertinente. le petit nombre de participants contrôlant la majorité des votes mais l'honnêteté de ceux-ci participants qui comptent. Cependant, un tel argument est quelque peu erroné puisqu’il s’agit plutôt du possibilité d’apparition de matériel spécialisé bon marché plutôt que l’honnêteté des participants qui constitue une menace. Pour le démontrer, prenons l’exemple suivant. Supposons qu'un malveillant L’individu acquiert un pouvoir minier significatif en créant sa propre ferme minière grâce à des prix bon marché. 2 Commentaires à la page 2

La technologie CryptoNote

Maintenant que nous avons couvert les limites de la technologie Bitcoin, nous allons nous concentrer sur présentant les fonctionnalités de CryptoNote.

Transactions intraçables

Dans cette section, nous proposons un schéma de transactions totalement anonymes satisfaisant à la fois l'intracabilité et les conditions de non-liaison. Une caractéristique importante de notre solution est son autonomie : l'expéditeur n'est pas tenu de coopérer avec d'autres utilisateurs ou un tiers de confiance pour effectuer ses transactions ; chaque participant produit donc indépendamment un trafic de couverture. 4.1 Revue de la littérature Notre schéma repose sur la primitive cryptographique appelée signature de groupe. Présenté pour la première fois par D. Chaum et E. van Heyst [19], il permet à un utilisateur de signer son message au nom du groupe. Après avoir signé le message, l'utilisateur ne fournit (à des fins de vérification) pas son propre public. 1C'est ce qu'on appelle la « limite souple » — la restriction client de référence pour la création de nouveaux blocs. Dur maximum de la taille de bloc possible était de 1 Mo 4 si nécessaire, cela provoque les principaux inconvénients. Malheureusement, il est difficile de prédire quand les constantes devront peut-être être modifiées et leur remplacement peut avoir des conséquences terribles. Un bon exemple de changement de limite codé en dur conduisant à des conséquences désastreuses est le blocage limite de taille fixée à 250 Ko1. Cette limite était suffisante pour contenir environ 10 000 transactions standards. Dans début 2013, cette limite était presque atteinte et un accord a été trouvé pour augmenter le limite. Le changement a été implémenté dans la version 0.8 du portefeuille et s'est terminé par une division de chaîne de 24 blocs. et une attaque réussie de double dépense [9]. Bien que le bug ne soit pas dans le protocole Bitcoin, mais au contraire, dans le moteur de base de données, il aurait pu être facilement détecté par un simple test de résistance s'il y avait eu aucune limite de taille de bloc introduite artificiellement. Les constantes agissent également comme une forme de point de centralisation. Malgré la nature peer-to-peer de Bitcoin, une écrasante majorité de nœuds utilisent le client de référence officiel [10] développé par un petit groupe de personnes. Ce groupe prend la décision de mettre en œuvre des modifications au protocole et la plupart des gens acceptent ces changements indépendamment de leur « exactitude ». Certaines décisions ont provoqué discussions animées et même appels au boycott [11], ce qui indique que la communauté et le les développeurs peuvent être en désaccord sur certains points importants. Il semble donc logique d'avoir un protocole avec des variables configurables par l'utilisateur et auto-ajustables comme moyen possible d'éviter ces problèmes. 2.5 Scripts volumineux Le système de script de Bitcoin est une fonctionnalité lourde et complexe. Cela permet potentiellement de créer transactions sophistiquées [12], mais certaines de ses fonctionnalités sont désactivées en raison de problèmes de sécurité et certains n'ont même jamais été utilisés [13]. Le script (y compris les parties des expéditeurs et des destinataires) pour la transaction la plus populaire en Bitcoin ressemble à ceci : OP DUP OP HASH160 OP EQUALVERIFY OP CHECKSIG. Le script fait 164 octets alors que son seul but est de vérifier si le récepteur possède le clé secrète nécessaire pour vérifier sa signature. 3 La technologie CryptoNote Maintenant que nous avons couvert les limites de la technologie Bitcoin, nous allons nous concentrer sur présentant les fonctionnalités de CryptoNote. 4 Transactions intraçables Dans cette section, nous proposons un schéma de transactions totalement anonymes satisfaisant à la fois l'intracabilité et les conditions de non-liaison. Une caractéristique importante de notre solution est son autonomie : l'expéditeur n'est pas tenu de coopérer avec d'autres utilisateurs ou un tiers de confiance pour effectuer ses transactions ; chaque participant produit donc indépendamment un trafic de couverture. 4.1 Revue de la littérature Notre schéma repose sur la primitive cryptographique appelée signature de groupe. Présenté pour la première fois par D. Chaum et E. van Heyst [19], il permet à un utilisateur de signer son message au nom du groupe. Après avoir signé le message, l'utilisateur ne fournit (à des fins de vérification) pas son propre public. 1C'est ce qu'on appelle la « limite souple » — la restriction client de référence pour la création de nouveaux blocs. Dur maximum de la taille de bloc possible était de 1 Mo 4 7 Rétrospectivement, cela semble avoir été une grave erreur de faire de la taille des blocs une limite fixe dans le code. Visa et Mastercard peuvent traiter des milliers, voire des centaines de milliers de transactions par seconde. Cependant, les transactions s'effectuent selon un processus stochastique, parfois par rafales massives, parfois rester silencieux pendant des heures. Pensez au volume des échanges de bitcoins. Cela semble être une excellente idée de concevoir un système qui augmente dynamiquement la taille des blocs lorsque cela est nécessaire pour s'adapter à l'augmentation du trafic de transactions et le diminuer de manière dynamique si nécessaire pour augmenter l’efficacité de la bande passante. Maintenant, appliquez cette notion à tous les paramètres du système. Et tant que nous prenons soin de garder le système de queue de poisson hors de contrôle, ce shça marcherait très bien. https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki Comme mentionné précédemment, si les variables s'ajustent automatiquement, certains contrôles doivent être imposés afin de empêcher le système de devenir incontrôlable. Nous y reviendrons. S’il s’agissait d’un article Wikipédia, il serait intitulé « STUB ». Même si nous sommes certainement dans le section présentant les « Problèmes de Bitcoin », j'aimerais avoir quelques précisions ici. Pourquoi 164 octets inacceptables pour une simple tâche de « vérification de la clé secrète » ? Jusqu'à quel point peuvent-ils être petits pour un langage de script raisonnable ? Cependant, je ne suis pas informaticien. http://download.springer.com/static/pdf/412/chp%253A10.1007%252F3-540-46416-6_22.pdf?auth66=140 Les signatures de groupe, telles que décrites, nécessitent un gestionnaire de groupe. Le responsable du groupe est capable de révoquer l'anonymat de tout signataire. Il existe donc une centralisation intrinsèque au sein d’un groupe. schéma de signature.

clé, mais les clés de tous les utilisateurs de son groupe. Un vérificateur est convaincu que le véritable signataire est un membre du groupe, mais ne peut identifier exclusivement le signataire. Le protocole initial nécessitait un tiers de confiance (appelé le gestionnaire de groupe), et il était le seul à pouvoir retrouver le signataire. La version suivante appelée signature en anneau, introduite par Rivest et coll. en [34], était un système autonome sans gestionnaire de groupe et sans anonymat révocation. Diverses modifications de ce schéma sont apparues plus tard : signature en anneau connectable [26, 27, 17] a permis de déterminer si deux signatures ont été produites par le même membre du groupe, traçables la signature en anneau [24, 23] limitait l'anonymat excessif en offrant la possibilité de retrouver le signataire de deux messages concernant la même métainformation (ou « tag » en termes de [24]). Une construction cryptographique similaire est également connue sous le nom de signature de groupe ad hoc [16, 38]. Il met l'accent sur la formation arbitraire de groupes, alors que les schémas de signature de groupe/anneau impliquent plutôt une ensemble fixe de membres. Pour l’essentiel, notre solution s’appuie sur l’ouvrage « Traceable ring signature » de E. Fujisaki et K. Suzuki [24]. Afin de distinguer l'algorithme original de notre modification, nous allons appelons cette dernière une signature en anneau à usage unique, soulignant la capacité de l'utilisateur à produire une seule signature valide. signature sous sa clé privée. Nous avons affaibli la propriété de traçabilité et conservé la possibilité de liaison uniquement pour fournir un caractère unique : la clé publique peut apparaître dans de nombreux ensembles de vérification étrangers et le la clé privée peut être utilisée pour générer une signature anonyme unique. En cas de double dépense tentative, ces deux signatures seront liées entre elles, mais il n'est pas nécessaire de révéler le signataire à nos fins. 4.2 Définitions 4.2.1 Paramètres de courbe elliptique Comme algorithme de signature de base, nous avons choisi d'utiliser le schéma rapide EdDSA, qui est développé et mis en œuvre par D.J. Bernstein et coll. [18]. Comme l'ECDSA de Bitcoin, il est basé sur la courbe elliptique problème de logarithme discret, notre schéma pourrait donc également être appliqué à Bitcoin à l'avenir. Les paramètres courants sont : q : un nombre premier ; q = 2255 −19 ; d : un élément de Fq ; d = −121665/121666 ; E : une équation de courbe elliptique ; −x2 + y2 = 1 + dx2y2 ; G : un point de base ; G = (x, −4/5); l : un ordre premier du point de base ; l = 2252 + 27742317777372353535851937790883648493 ; Hs : une fonction cryptographique hash \(\{0, 1\}^* \to \mathbb{F}_q\) ; Hp : une fonction déterministe hash \(E(\mathbb{F}_q) \to E(\mathbb{F}_q)\). 4.2.2 Terminologie La confidentialité renforcée nécessite une nouvelle terminologie qui ne doit pas être confondue avec les entités Bitcoin. la clé ec privée est une clé privée à courbe elliptique standard : un nombre \(a \in [1, l - 1]\) ; la clé ec publique est une clé publique à courbe elliptique standard : un point A = aG ; une paire de clés à usage unique est une paire de clés électroniques privées et publiques ; 5 clé, mais les clés de tous les utilisateurs de son groupe. Un vérificateur est convaincu que le véritable signataire est un membre du groupe, mais ne peut identifier exclusivement le signataire. Le protocole initial nécessitait un tiers de confiance (appelé le gestionnaire de groupe), et il était le seul à pouvoir retrouver le signataire. La version suivante appelée signature en anneau, introduite par Rivest et coll. en [34], était un système autonome sans gestionnaire de groupe et sans anonymat révocation. Diverses modifications de ce schéma sont apparues plus tard : signature en anneau connectable [26, 27, 17] a permis de déterminer si deux signatures ont été produites par le même membre du groupe, traçables la signature en anneau [24, 23] limitait l'anonymat excessif en offrant la possibilité de retrouver le signataire de deux messages concernant la même métainformation (ou « tag » en termes de [24]). Une construction cryptographique similaire est également connue sous le nom de signature de groupe ad hoc [16, 38]. Il met l'accent sur la formation arbitraire de groupes, alors que les schémas de signature de groupe/anneau impliquent plutôt une ensemble fixe de membres. Pour l’essentiel, notre solution s’appuie sur l’ouvrage « Traceable ring signature » de E. Fujisaki et K. Suzuki [24]. Afin de distinguer l'algorithme original de notre modification, nous allons appelons cette dernière une signature en anneau à usage unique, soulignant la capacité de l'utilisateur à produire une seule signature valide. signature sous sa clé privée. Nous avons affaibli la propriété de traçabilité et conservé la possibilité de liaison uniquement pour fournir un caractère unique : la clé publique peut apparaître dans de nombreux ensembles de vérification étrangers et le la clé privée peut être utilisée pour générer une signature anonyme unique. En cas de double dépense tentative, ces deux signatures seront liées entre elles, mais il n'est pas nécessaire de révéler le signataire à nos fins. 4.2 Définitions 4.2.1 Paramètres de courbe elliptique Comme algorithme de signature de base, nous avons choisie d'utiliser le schéma rapide EdDSA, développé et mis en œuvre par D.J. Bernstein et coll. [18]. Comme l'ECDSA de Bitcoin, il est basé sur la courbe elliptique problème de logarithme discret, notre schéma pourrait donc également être appliqué à Bitcoin à l'avenir. Les paramètres courants sont : q : un nombre premier ; q = 2255 −19 ; d : un élément de Fq ; d = −121665/121666 ; E : une équation de courbe elliptique ; −x2 + y2 = 1 + dx2y2 ; G : un point de base ; G = (x, −4/5); l : un ordre premier du point de base ; l = 2252 + 27742317777372353535851937790883648493 ; Hs : une fonction cryptographique hash \(\{0, 1\}^* \to \mathbb{F}_q\) ; Hp : une fonction déterministe hash \(E(\mathbb{F}_q) \to E(\mathbb{F}_q)\). 4.2.2 Terminologie La confidentialité renforcée nécessite une nouvelle terminologie qui ne doit pas être confondue avec les entités Bitcoin. la clé ec privée est une clé privée à courbe elliptique standard : un nombre \(a \in [1, l - 1]\) ; la clé ec publique est une clé publique à courbe elliptique standard : un point A = aG ; une paire de clés à usage unique est une paire de clés électroniques privées et publiques ; 5 8 Une signature en anneau fonctionne comme ceci : Alex veut divulguer un message à WikiLeaks au sujet de son employeur. Chaque collaborateur de son entreprise dispose d'une paire de clés privée/publique (Ri, Ui). Elle compose sa signature avec l'entrée définie comme son message, m, sa clé privée, Ri et celle de TOUT LE MONDE clés publiques, (Ui;i=1...n). N'importe qui (sans connaître de clés privées) peut facilement vérifier que quelque couple (Rj, Uj) a dû être utilisé pour construire la signature... quelqu'un qui travaille pour l’employeur d’Alex… mais il s’agit essentiellement d’une estimation aléatoire pour déterminer de laquelle il s’agit. http://en.wikipedia.org/wiki/Ring_signature#Crypto-currencies http://link.springer.com/chapter/10.1007/3-540-45682-1_32#page-1 http://link.springer.com/chapter/10.1007/11424826_65 http://link.springer.com/chapter/10.1007/978-3-540-27800-9_28 http://link.springer.com/chapter/10.1007%2F11774716_9 Notez qu'une signature en anneau pouvant être liée décrite ici est un peu à l'opposé de "non liée". décrit ci-dessus. Ici, nous interceptons deux messages et nous pouvons déterminer si le même parti les a envoyés, même si nous ne devrions toujours pas être en mesure de déterminer qui est ce parti. Le La définition de « non-liable » utilisée pour construire Cryptonote signifie que nous ne pouvons pas déterminer si c'est le même parti qui les reçoit. Par conséquent, ce que nous avons réellement ici, ce sont QUATRE choses qui se passent. Un système peut être lié ou non associable, selon qu'il est possible ou non de déterminer si l'expéditeur du message deux messages sont identiques (que cela nécessite ou non la révocation de l'anonymat). Et un système peut être dissociable ou non, selon qu'il est possible ou non de déterminer si le destinataire de deux messages est le même (indépendamment du fait que cela nécessite la révocation de l'anonymat). S’il vous plaît, ne me blâmez pas pour cette terrible terminologie. Les théoriciens des graphes devraient probablement être content. Certains d'entre vous seront peut-être plus à l'aise avec « liaison entre le récepteur » et avec « liaison avec l'expéditeur ». http://link.springer.com/chapter/10.1007/978-3-540-71677-8_13 Quand j'ai lu ceci, cela m'a semblé une fonctionnalité idiote. Puis j'ai lu que cela pouvait être une fonctionnalité pour vote électronique, et cela semblait logique. Plutôt cool, de ce point de vue. Mais je suis pas totalement sûr de mettre en œuvre délibérément des signatures en anneau traçables. http://search.ieice.org/bin/summary.php?id=e95-a_1_151

clé, mais les clés de tous les utilisateurs de son groupe. Un vérificateur est convaincu que le véritable signataire est un membre du groupe, mais ne peut identifier exclusivement le signataire. Le protocole initial nécessitait un tiers de confiance (appelé le gestionnaire de groupe), et il était le seul à pouvoir retrouver le signataire. La version suivante appelée signature en anneau, introduite par Rivest et coll. en [34], était un système autonome sans gestionnaire de groupe et sans anonymat révocation. Diverses modifications de ce schéma sont apparues plus tard : signature en anneau connectable [26, 27, 17] a permis de déterminer si deux signatures ont été produites par le même membre du groupe, traçables la signature en anneau [24, 23] limitait l'anonymat excessif en offrant la possibilité de retrouver le signataire de deux messages concernant la même métainformation (ou « tag » en termes de [24]). Une construction cryptographique similaire est également connue sous le nom de signature de groupe ad hoc [16, 38]. Il met l'accent sur la formation arbitraire de groupes, alors que les schémas de signature de groupe/anneau impliquent plutôt une ensemble fixe de membres. Pour l’essentiel, notre solution s’appuie sur l’ouvrage « Traceable ring signature » de E. Fujisaki et K. Suzuki [24]. Afin de distinguer l'algorithme original de notre modification, nous allons appelons cette dernière une signature en anneau à usage unique, soulignant la capacité de l'utilisateur à produire une seule signature valide. signature sous sa clé privée. Nous avons affaibli la propriété de traçabilité et conservé la possibilité de liaison uniquement pour fournir un caractère unique : la clé publique peut apparaître dans de nombreux ensembles de vérification étrangers et le la clé privée peut être utilisée pour générer une signature anonyme unique. En cas de double dépense tentative, ces deux signatures seront liées entre elles, mais il n'est pas nécessaire de révéler le signataire à nos fins. 4.2 Définitions 4.2.1 Paramètres de courbe elliptique Comme algorithme de signature de base, nous avons choisi d'utiliser le schéma rapide EdDSA, qui est développé et mis en œuvre par D.J. Bernstein et coll. [18]. Comme l'ECDSA de Bitcoin, il est basé sur la courbe elliptique problème de logarithme discret, notre schéma pourrait donc également être appliqué à Bitcoin à l'avenir. Les paramètres courants sont : q : un nombre premier ; q = 2255 −19 ; d : un élément de Fq ; d = −121665/121666 ; E : une équation de courbe elliptique ; −x2 + y2 = 1 + dx2y2 ; G : un point de base ; G = (x, −4/5); l : un ordre premier du point de base ; l = 2252 + 27742317777372353535851937790883648493 ; Hs : une fonction cryptographique hash \(\{0, 1\}^* \to \mathbb{F}_q\) ; Hp : une fonction déterministe hash \(E(\mathbb{F}_q) \to E(\mathbb{F}_q)\). 4.2.2 Terminologie La confidentialité renforcée nécessite une nouvelle terminologie qui ne doit pas être confondue avec les entités Bitcoin. la clé ec privée est une clé privée à courbe elliptique standard : un nombre \(a \in [1, l - 1]\) ; la clé ec publique est une clé publique à courbe elliptique standard : un point A = aG ; une paire de clés à usage unique est une paire de clés électroniques privées et publiques ; 5 clé, mais les clés de tous les utilisateurs de son groupe. Un vérificateur est convaincu que le véritable signataire est un membre du groupe, mais ne peut identifier exclusivement le signataire. Le protocole initial nécessitait un tiers de confiance (appelé le gestionnaire de groupe), et il était le seul à pouvoir retrouver le signataire. La version suivante appelée signature en anneau, introduite par Rivest et coll. en [34], était un système autonome sans gestionnaire de groupe et sans anonymat révocation. Diverses modifications de ce schéma sont apparues plus tard : signature en anneau connectable [26, 27, 17] a permis de déterminer si deux signatures ont été produites par le même membre du groupe, traçables la signature en anneau [24, 23] limitait l'anonymat excessif en offrant la possibilité de retrouver le signataire de deux messages concernant la même métainformation (ou « tag » en termes de [24]). Une construction cryptographique similaire est également connue sous le nom de signature de groupe ad hoc [16, 38]. Il met l'accent sur la formation arbitraire de groupes, alors que les schémas de signature de groupe/anneau impliquent plutôt une ensemble fixe de membres. Pour l’essentiel, notre solution s’appuie sur l’ouvrage « Traceable ring signature » de E. Fujisaki et K. Suzuki [24]. Afin de distinguer l'algorithme original de notre modification, nous allons appelons cette dernière une signature en anneau à usage unique, soulignant la capacité de l'utilisateur à produire une seule signature valide. signature sous sa clé privée. Nous avons affaibli la propriété de traçabilité et conservé la possibilité de liaison uniquement pour fournir un caractère unique : la clé publique peut apparaître dans de nombreux ensembles de vérification étrangers et le la clé privée peut être utilisée pour générer une signature anonyme unique. En cas de double dépense tentative, ces deux signatures seront liées entre elles, mais il n'est pas nécessaire de révéler le signataire à nos fins. 4.2 Définitions 4.2.1 Paramètres de courbe elliptique Comme algorithme de signature de base, nous avons choisie d'utiliser le schéma rapide EdDSA, développé et mis en œuvre par D.J. Bernstein et coll. [18]. Comme l'ECDSA de Bitcoin, il est basé sur la courbe elliptique problème de logarithme discret, notre schéma pourrait donc également être appliqué à Bitcoin à l'avenir. Les paramètres courants sont : q : un nombre premier ; q = 2255 −19 ; d : un élément de Fq ; d = −121665/121666 ; E : une équation de courbe elliptique ; −x2 + y2 = 1 + dx2y2 ; G : un point de base ; G = (x, −4/5); l : un ordre premier du point de base ; l = 2252 + 27742317777372353535851937790883648493 ; Hs : une fonction cryptographique hash \(\{0, 1\}^* \to \mathbb{F}_q\) ; Hp : une fonction déterministe hash \(E(\mathbb{F}_q) \to E(\mathbb{F}_q)\). 4.2.2 Terminologie La confidentialité renforcée nécessite une nouvelle terminologie qui ne doit pas être confondue avec les entités Bitcoin. la clé ec privée est une clé privée à courbe elliptique standard : un nombre \(a \in [1, l - 1]\) ; la clé ec publique est une clé publique à courbe elliptique standard : un point A = aG ; une paire de clés à usage unique est une paire de clés électroniques privées et publiques ; 5 9 Mon Dieu, l’auteur de ce livre blanc aurait certainement pu mieux formuler cela ! Disons qu'un l'entreprise détenue par ses salariés souhaite procéder à un vote sur l'acquisition ou non de certains nouveaux actifs, et Alex et Brenda sont tous deux employés. La Société offre à chaque employé un message comme "Je vote oui sur la proposition A!" qui a le "problème" de métainformation [PROP A] et leur demande de le signer avec une signature en anneau traçable s'ils soutiennent la proposition. En utilisant une signature en anneau traditionnelle, un employé malhonnête peut signer le message plusieurs fois, probablement avec différents nonce, afin de voter autant de fois qu'ils le souhaitent. De l'autre D'un autre côté, dans un système de signature en anneau traçable, Alex ira voter et sa clé privée aura été utilisé sur la question [PROP A]. Si Alex essaie de signer un message comme "Moi, Brenda, j'approuve proposition A!" pour "cadrer" Brenda et doubler le vote, ce nouveau message aura aussi de l'enjeu [PROPRIÉTÉ A]. Puisque la clé privée d'Alex a déjà déclenché le problème [PROP A], l'identité d'Alex sera immédiatement révélé comme une fraude. Ce qui, avouons-le, est plutôt cool ! La cryptographie a imposé l’égalité des votes. http://link.springer.com/chapter/10.1007/978-3-540-71677-8_13 Cet article est intéressant, car il crée essentiellement une signature en anneau ad hoc mais sans aucun des le consentement de l’autre participant. La structure de la signature peut être différente ; je n'ai pas creusé profond, et je n’ai pas vu si c’est sécurisé. https://people.csail.mit.edu/rivest/AdidaHohenbergerRivest-AdHocGroupSignaturesFromHijackedKeypai Les signatures des groupes ad hoc sont : les signatures en anneau, qui sont des signatures de groupe sans groupe gestionnaires, pas de centralisation, mais permet à un membre d'un groupe ad hoc de prétendre de manière prouvée que il n'a (pas) émis la signature anonyme au nom du groupe. http://link.springer.com/chapter/10.1007/11908739_9 Ce n’est pas tout à fait exact, d’après ma compréhension. Et ma compréhension changera probablement à mesure que J'approfondis ce projet. Mais d'après ma compréhension, la hiérarchie ressemble à ceci. Signatures de groupe : les gestionnaires de groupe contrôlent la traçabilité et la possibilité d'ajouter ou de supprimer des membres d'être signataires. Ring sigs : Formation de groupe arbitraire sans chef de groupe. Pas de révocation de l'anonymat. Pas question de se répudier d'une signature particulière. Avec anneau traçable et connectable signatures, l'anonymat est quelque peu évolutif. Signatures de groupe ad hoc : comme les signatures en anneau, mais les membres peuvent prouver qu'ils n'ont pas créé une signature particulière. Ceci est important lorsque n’importe qui dans un groupe peut produire une signature. http://link.springer.com/chapter/10.1007/978-3-540-71677-8_13 L'algorithme de Fujisaki et Suzuki est modifié plus tard par l'auteur pour fournir un caractère unique. Alors nous analyserons l'algorithme de Fujisaki et Suzuki en même temps que le nouvel algorithme plutôt que de le parcourir ici.

clé, mais les clés de tous les utilisateurs de son groupe. Un vérificateur est convaincu que le véritable signataire est un membre du groupe, mais ne peut identifier exclusivement le signataire. Le protocole initial nécessitait un tiers de confiance (appelé le gestionnaire de groupe), et il était le seul à pouvoir retrouver le signataire. La version suivante appelée signature en anneau, introduite par Rivest et coll. en [34], était un système autonome sans gestionnaire de groupe et sans anonymat révocation. Diverses modifications de ce schéma sont apparues plus tard : signature en anneau connectable [26, 27, 17] a permis de déterminer si deux signatures ont été produites par le même membre du groupe, traçables la signature en anneau [24, 23] limitait l'anonymat excessif en offrant la possibilité de retrouver le signataire de deux messages concernant la même métainformation (ou « tag » en termes de [24]). Une construction cryptographique similaire est également connue sous le nom de signature de groupe ad hoc [16, 38]. Il met l'accent sur la formation arbitraire de groupes, alors que les schémas de signature de groupe/anneau impliquent plutôt une ensemble fixe de membres. Pour l’essentiel, notre solution s’appuie sur l’ouvrage « Traceable ring signature » de E. Fujisaki et K. Suzuki [24]. Afin de distinguer l'algorithme original de notre modification, nous allons appelons cette dernière une signature en anneau à usage unique, soulignant la capacité de l'utilisateur à produire une seule signature valide. signature sous sa clé privée. Nous avons affaibli la propriété de traçabilité et conservé la possibilité de liaison uniquement pour fournir un caractère unique : la clé publique peut apparaître dans de nombreux ensembles de vérification étrangers et le la clé privée peut être utilisée pour générer une signature anonyme unique. En cas de double dépense tentative, ces deux signatures seront liées entre elles, mais il n'est pas nécessaire de révéler le signataire à nos fins. 4.2 Définitions 4.2.1 Paramètres de courbe elliptique Comme algorithme de signature de base, nous avons choisi d'utiliser le schéma rapide EdDSA, qui est développé et mis en œuvre par D.J. Bernstein et coll. [18]. Comme l'ECDSA de Bitcoin, il est basé sur la courbe elliptique problème de logarithme discret, notre schéma pourrait donc également être appliqué à Bitcoin à l'avenir. Les paramètres courants sont : q : un nombre premier ; q = 2255 −19 ; d : un élément de Fq ; d = −121665/121666 ; E : une équation de courbe elliptique ; −x2 + y2 = 1 + dx2y2 ; G : un point de base ; G = (x, −4/5); l : un ordre premier du point de base ; l = 2252 + 27742317777372353535851937790883648493 ; Hs : une fonction cryptographique hash \(\{0, 1\}^* \to \mathbb{F}_q\) ; Hp : une fonction déterministe hash \(E(\mathbb{F}_q) \to E(\mathbb{F}_q)\). 4.2.2 Terminologie La confidentialité renforcée nécessite une nouvelle terminologie qui ne doit pas être confondue avec les entités Bitcoin. la clé ec privée est une clé privée à courbe elliptique standard : un nombre \(a \in [1, l - 1]\) ; la clé ec publique est une clé publique à courbe elliptique standard : un point A = aG ; une paire de clés à usage unique est une paire de clés électroniques privées et publiques ; 5 clé, mais les clés de tous les utilisateurs de son groupe. Un vérificateur est convaincu que le véritable signataire est un membre du groupe, mais ne peut identifier exclusivement le signataire. Le protocole initial nécessitait un tiers de confiance (appelé le gestionnaire de groupe), et il était le seul à pouvoir retrouver le signataire. La version suivante appelée signature en anneau, introduite par Rivest et coll. en [34], était un système autonome sans gestionnaire de groupe et sans anonymat révocation. Diverses modifications de ce schéma sont apparues plus tard : signature en anneau connectable [26, 27, 17] a permis de déterminer si deux signatures ont été produites par le même membre du groupe, traçables la signature en anneau [24, 23] limitait l'anonymat excessif en offrant la possibilité de retrouver le signataire de deux messages concernant la même métainformation (ou « tag » en termes de [24]). Une construction cryptographique similaire est également connue sous le nom de signature de groupe ad hoc [16, 38]. Il met l'accent sur la formation arbitraire de groupes, alors que les schémas de signature de groupe/anneau impliquent plutôt une ensemble fixe de membres. Pour l’essentiel, notre solution s’appuie sur l’ouvrage « Traceable ring signature » de E. Fujisaki et K. Suzuki [24]. Afin de distinguer l'algorithme original de notre modification, nous allons appelons cette dernière une signature en anneau à usage unique, soulignant la capacité de l'utilisateur à produire une seule signature valide. signature sous sa clé privée. Nous avons affaibli la propriété de traçabilité et conservé la possibilité de liaison uniquement pour fournir un caractère unique : la clé publique peut apparaître dans de nombreux ensembles de vérification étrangers et le la clé privée peut être utilisée pour générer une signature anonyme unique. En cas de double dépense tentative, ces deux signatures seront liées entre elles, mais il n'est pas nécessaire de révéler le signataire à nos fins. 4.2 Définitions 4.2.1 Paramètres de courbe elliptique Comme algorithme de signature de base, nous avons choisie d'utiliser le schéma rapide EdDSA, développé et mis en œuvre par D.J. Bernstein et coll. [18]. Comme l'ECDSA de Bitcoin, il est basé sur la courbe elliptique problème de logarithme discret, notre schéma pourrait donc également être appliqué à Bitcoin à l'avenir. Les paramètres courants sont : q : un nombre premier ; q = 2255 −19 ; d : un élément de Fq ; d = −121665/121666 ; E : une équation de courbe elliptique ; −x2 + y2 = 1 + dx2y2 ; G : un point de base ; G = (x, −4/5); l : un ordre premier du point de base ; l = 2252 + 27742317777372353535851937790883648493 ; Hs : une fonction cryptographique hash \(\{0, 1\}^* \to \mathbb{F}_q\) ; Hp : une fonction déterministe hash \(E(\mathbb{F}_q) \to E(\mathbb{F}_q)\). 4.2.2 Terminologie La confidentialité renforcée nécessite une nouvelle terminologie qui ne doit pas être confondue avec les entités Bitcoin. la clé ec privée est une clé privée à courbe elliptique standard : un nombre \(a \in [1, l - 1]\) ; la clé ec publique est une clé publique à courbe elliptique standard : un point A = aG ; une paire de clés à usage unique est une paire de clés électroniques privées et publiques ; 5 10 La liaison au sens de « signatures en anneau pouvant être liées » signifie que nous pouvons savoir si deux transactions sortantes proviennent de la même source sans révéler qui est la source. Les auteurs affaiblis possibilité de lien afin de (a) préserver la confidentialité, mais toujours (b) repérer toute transaction utilisant une clé privée une seconde fois comme invalide. D'accord, c'est donc une question d'ordre des événements. Considérez le scénario suivant. Mon exploitation minière l'ordinateur aura le blockchain actuel, il aura son propre bloc de transactions qu'il appelle légitime, il travaillera sur ce bloc dans un puzzle proof-of-work, et il aura un liste des transactions en attente à ajouter au bloc suivant. Il enverra également tout nouveau transactions dans ce pool de transactions en attente. Si je ne résous pas le bloc suivant, mais quelqu'un d'autre le fait, je reçois une copie mise à jour du blockchain. Le bloc sur lequel je travaillais et ma liste de transactions en attente peut contenir toutes deux des transactions qui sont maintenant incorporées dans le blockchain. Démêlez mon bloc en attente, combinez-le avec ma liste de transactions en attente et appelez-le mon pool de transactions en attente. Supprimez ceux qui se trouvent maintenant officiellement dans le blockchain. Maintenant, que dois-je faire ? Dois-je d'abord passer par « supprimer toutes les doubles dépenses » ? De l'autre D'autre part, dois-je parcourir la liste et m'assurer que chaque clé privée n'a pas encore été utilisé, et s'il a déjà été utilisé dans ma liste, alors j'ai reçu le premier exemplaire en premier, et donc toute autre copie est illégitime. Ainsi, je supprime simplement toutes les instances après la première de la même clé privée. La géométrie algébrique n’a jamais été mon point fort. http://en.wikipedia.org/wiki/EdDSA Une telle vitesse, vraiment wow. C'est la géométrie algébrique pour la victoire. Non pas que je sache quoi que ce soit à ce sujet. Problématique ou non, les journaux discrets deviennent très rapides. Et les ordinateurs quantiques les mangent pour le petit déjeuner. http://link.springer.com/article/10.1007/s13389-012-0027-1 Cela devient un nombre vraiment important, mais il n'y a aucune explication ni citation sur la manière dont il est obtenu. a été choisi. Choisir simplement un seul grand nombre premier connu serait bien, mais s'il y a des nombres premiers connus des faits sur ce grand nombre premier, qui pourraient influencer notre choix. Différentes variantes de cryptonote pourrait choisir différentes valeurs de eh bien, mais il n'y a aucune discussion dans cet article sur la façon dont cela Ce choix affectera nos choix d’autres paramètres globaux répertoriés à la page 5. Cet article nécessite une section sur le choix des valeurs des paramètres.

la clé d'utilisateur privée est une paire (a, b) de deux clés ec privées différentes ; la clé de suivi est une paire (a, B) de clés ec privées et publiques (où B = bG et a ̸ = b) ; la clé publique d'utilisateur est une paire (A, B) de deux clés ec publiques dérivées de (a, b) ; l'adresse standard est une représentation d'une clé d'utilisateur publique donnée dans une chaîne conviviale avec correction d'erreurs ; l'adresse tronquée est une représentation de la seconde moitié (point B) d'une clé d'utilisateur publique donnée en chaîne conviviale avec correction d’erreur. La structure de la transaction reste similaire à celle de Bitcoin : chaque utilisateur peut choisir plusieurs encaissements indépendants (sorties d'opérations), signez-les avec le code correspondant clés privées et les envoyer à différentes destinations. Contrairement au modèle de Bitcoin, où un utilisateur possède une clé privée et publique unique, dans le cas modèle proposé, un expéditeur génère une clé publique unique basée sur l'adresse du destinataire et quelques données aléatoires. En ce sens, une transaction entrante pour le même destinataire est envoyée à un clé publique unique (pas directement à une adresse unique) et seul le destinataire peut récupérer la partie privée correspondante pour racheter ses fonds (en utilisant sa clé privée unique). Le destinataire peut dépenser les fonds en utilisant une signature en anneau, en gardant anonymes sa propriété et ses dépenses réelles. Les détails du protocole sont expliqués dans les sous-sections suivantes. 4.3 Paiements non liés Les adresses classiques Bitcoin, une fois publiées, deviennent un identifiant sans ambiguïté pour les paiements, en les reliant entre eux et en les liant aux pseudonymes du destinataire. Si quelqu'un veut reçoit une transaction « déliée », il doit transmettre son adresse à l'expéditeur par un canal privé. \(S'\)il souhaite recevoir différentes transactions dont il ne peut être prouvé qu'elles appartiennent au même propriétaire il doit générer toutes les différentes adresses et ne jamais les publier sous son propre pseudonyme. Publique Privé Alice Carole Adresse de Bob 1 Adresse de Bob 2 La clé de Bob 1 La clé de Bob 2 Bob Fig. 2. Modèle traditionnel de clés/transactions Bitcoin. Nous proposons une solution permettant à un utilisateur de publier une adresse unique et de recevoir des paiements non liés. La destination de chaque sortie CryptoNote (par défaut) est une clé publique, dérivé de l’adresse du destinataire et des données aléatoires de l’expéditeur. Le principal avantage contre Bitcoin est que chaque clé de destination est unique par défaut (sauf si l'expéditeur utilise les mêmes données pour chaque clé). de ses transactions vers le même destinataire). Il n’existe donc pas de problème de « réutilisation des adresses » par conception et aucun observateur ne peut déterminer si des transactions ont été envoyées à une adresse ou un lien spécifique deux adresses ensemble. 6 la clé d'utilisateur privée est une paire (a, b) de deux clés ec privées différentes ; la clé de suivi est une paire (a, B) de clés ec privées et publiques (où B = bG et a ̸ = b) ; la clé publique d'utilisateur est une paire (A, B) de deux clés ec publiques dérivées de (a, b) ; l'adresse standard est une représentation d'une clé d'utilisateur publique donnée dans une chaîne conviviale avec correction d'erreurs ; l'adresse tronquée est une représentation de la seconde moitié (point B) d'une clé d'utilisateur publique donnée en chaîne conviviale avec correction d’erreur. La structure de la transaction reste similaire à celle de Bitcoin : chaque utilisateur peut choisir plusieurs encaissements indépendants (sorties d'opérations), signez-les avec le code correspondant clés privées et les envoyer à différentes destinations. Contrairement au modèle de Bitcoin, où un utilisateur possède une clé privée et publique unique, dans le cas modèle proposé, un expéditeur génère une clé publique unique basée sur l'adresse du destinataire et quelques données aléatoires. En ce sens, une transaction entrante pour le même destinataire est envoyée à un clé publique unique (pas directement à une adresse unique) et seul le destinataire peut récupérer la partie privée correspondante pour racheter ses fonds (en utilisant sa clé privée unique). Le destinataire peut dépenser les fonds en utilisant une signature en anneau, en gardant anonymes sa propriété et ses dépenses réelles. Les détails du protocole sont expliqués dans les sous-sections suivantes. 4.3 Paiements non liés Les adresses classiques Bitcoin, une fois publiées, deviennent un identifiant sans ambiguïté pour les paiements, en les reliant entre eux et en les liant aux pseudonymes du destinataire. Si quelqu'un veut reçoit une transaction « déliée », il doit transmettre son adresse à l'expéditeur par un canal privé. \(S'\)il souhaite recevoir différentes transactions dont il ne peut être prouvé qu'elles appartiennent au même propriétaire il doit générer toutes les différentes adresses et ne jamais les publier sous son propre pseudonyme. Publique Privé Alice Carole Adresse de Bob 1 Adresse de Bob 2 La clé de Bob 1 La clé de Bob 2 Bob Fig. 2. Mod traditionnel de clés/transactions Bitcoinél. Nous proposons une solution permettant à un utilisateur de publier une adresse unique et de recevoir des paiements non liés. La destination de chaque sortie CryptoNote (par défaut) est une clé publique, dérivé de l’adresse du destinataire et des données aléatoires de l’expéditeur. Le principal avantage contre Bitcoin est que chaque clé de destination est unique par défaut (sauf si l'expéditeur utilise les mêmes données pour chaque clé). de ses transactions vers le même destinataire). Il n’existe donc pas de problème de « réutilisation des adresses » par conception et aucun observateur ne peut déterminer si des transactions ont été envoyées à une adresse ou un lien spécifique deux adresses ensemble. 6 11 C'est donc comme Bitcoin, mais avec des boîtes postales infinies et anonymes, échangeables uniquement par le destinataire. générer une clé privée aussi anonyme qu'une signature en anneau peut l'être. Bitcoin fonctionne de cette façon. Si Alex a 0,112 Bitcoin dans son portefeuille qu'elle vient de recevoir de Frank, elle a en réalité un message "Je, [FRANK], envoie 0,112 Bitcoin à [alex] + H0 + N0" où 1) Frank a signé le message avec sa clé privée [FRANK], 2) Frank a signé le message avec la clé publique d'Alex clé, [alex], 3) Frank a inclus une certaine forme de l'histoire du bitcoin, H0, et 4) Frank comprend un bit de données aléatoire appelé nonce, N0. Si Alex veut alors envoyer 0,011 Bitcoin à Charlene, elle prendra le message de Frank, et elle définira cela sur H1 et signera deux messages : un pour sa transaction et un pour le changement. H1= "Je, [FRANK], envoie 0,112 Bitcoin à [alex] + H0 + N" "Je, [ALEX], envoie 0,011 Bitcoin à [charlene] + H1 + N1" "Je, [ALEX], envoie 0,101 Bitcoin comme changement à [alex] + H1 + N2." où Alex signe les deux messages avec sa clé privée [ALEX], le premier message avec celle de Charlene clé publique [charlene], le deuxième message avec la clé publique d'Alex [alex], et incluant la historiques et certains nonces N1 et N2 générés aléatoirement de manière appropriée. Cryptonote fonctionne de cette façon : Si Alex a 0,112 Cryptonote dans son portefeuille qu'elle vient de recevoir de Frank, elle a en réalité un message "Je, [quelqu'un dans un groupe ad hoc], envoie 0,112 Cryptonote à [une adresse unique] + H0 +N0." Alex a découvert qu'il s'agissait de son argent en vérifiant sa clé privée [ALEX] [une adresse unique] pour chaque message qui passe, et si elle souhaite le dépenser, elle le fait en de la manière suivante. Elle choisit un destinataire de l'argent, peut-être que Charlene a commencé à voter pour les frappes de drones, alors Alex veut plutôt envoyer de l'argent à Brenda. Alors Alex recherche la clé publique de Brenda, [brenda], et utilise sa propre clé privée, [ALEX], pour générer une adresse unique [ALEX+brenda]. Elle puis choisit une collection arbitraire C parmi le réseau d'utilisateurs de cryptonotes et elle construit une signature circulaire de ce groupe ad hoc. Nous définissons notre historique comme message précédent, ajoutons nonces, et procéder comme d'habitude ? H1 = "Je, [quelqu'un dans un groupe ad hoc], envoie 0,112 Cryptonote à [une adresse unique] + H0 +N0." "Moi, [quelqu'un dans la collection C], j'envoie 0,011 Cryptonote à [adresse unique-faite-à partir d'ALEX+brenda] + H1 + N1" "Moi, [quelqu'un dans la collection C], j'envoie 0,101 Cryptonote en guise de modification à [one-time-address-madefrom-ALEX+alex] + H1 + N2" Désormais, Alex et Brenda analysent tous les deux tous les messages entrants à la recherche d'adresses uniques qui étaient créé à l’aide de leur clé. \(S'\)ils en trouvent, alors ce message est leur propre marque. cryptonote! Et même dans ce cas, la transaction atteindra toujours le blockchain. Si les pièces entrant dans cette adresse sont connus pour être envoyés par des criminels, des contributeurs politiques ou des comités et des comptes avec des budgets stricts (c'est-à-dire détournement de fonds), ou si le nouveau propriétaire de ces pièces commet une erreur et envoie ces pièces à une adresse commune avec les pièces qu'il est connu pour posséder, le gabarit d'anonymat est en hausse en Bitcoin.

la clé d'utilisateur privée est une paire (a, b) de deux clés ec privées différentes ; la clé de suivi est une paire (a, B) de clés ec privées et publiques (où B = bG et a ̸ = b) ; la clé publique d'utilisateur est une paire (A, B) de deux clés ec publiques dérivées de (a, b) ; l'adresse standard est une représentation d'une clé d'utilisateur publique donnée dans une chaîne conviviale avec correction d'erreurs ; l'adresse tronquée est une représentation de la seconde moitié (point B) d'une clé d'utilisateur publique donnée en chaîne conviviale avec correction d’erreur. La structure de la transaction reste similaire à celle de Bitcoin : chaque utilisateur peut choisir plusieurs encaissements indépendants (sorties d'opérations), signez-les avec le code correspondant clés privées et les envoyer à différentes destinations. Contrairement au modèle de Bitcoin, où un utilisateur possède une clé privée et publique unique, dans le cas modèle proposé, un expéditeur génère une clé publique unique basée sur l'adresse du destinataire et quelques données aléatoires. En ce sens, une transaction entrante pour le même destinataire est envoyée à un clé publique unique (pas directement à une adresse unique) et seul le destinataire peut récupérer la partie privée correspondante pour racheter ses fonds (en utilisant sa clé privée unique). Le destinataire peut dépenser les fonds en utilisant une signature en anneau, en gardant anonymes sa propriété et ses dépenses réelles. Les détails du protocole sont expliqués dans les sous-sections suivantes. 4.3 Paiements non liés Les adresses classiques Bitcoin, une fois publiées, deviennent un identifiant sans ambiguïté pour les paiements, en les reliant entre eux et en les liant aux pseudonymes du destinataire. Si quelqu'un veut reçoit une transaction « déliée », il doit transmettre son adresse à l'expéditeur par un canal privé. \(S'\)il souhaite recevoir différentes transactions dont il ne peut être prouvé qu'elles appartiennent au même propriétaire il doit générer toutes les différentes adresses et ne jamais les publier sous son propre pseudonyme. Publique Privé Alice Carole Adresse de Bob 1 Adresse de Bob 2 La clé de Bob 1 La clé de Bob 2 Bob Fig. 2. Modèle traditionnel de clés/transactions Bitcoin. Nous proposons une solution permettant à un utilisateur de publier une adresse unique et de recevoir des paiements non liés. La destination de chaque sortie CryptoNote (par défaut) est une clé publique, dérivé de l’adresse du destinataire et des données aléatoires de l’expéditeur. Le principal avantage contre Bitcoin est que chaque clé de destination est unique par défaut (sauf si l'expéditeur utilise les mêmes données pour chaque clé). de ses transactions vers le même destinataire). Il n’existe donc pas de problème de « réutilisation des adresses » par conception et aucun observateur ne peut déterminer si des transactions ont été envoyées à une adresse ou un lien spécifique deux adresses ensemble. 6 la clé d'utilisateur privée est une paire (a, b) de deux clés ec privées différentes ; la clé de suivi est une paire (a, B) de clés ec privées et publiques (où B = bG et a ̸ = b) ; la clé publique d'utilisateur est une paire (A, B) de deux clés ec publiques dérivées de (a, b) ; l'adresse standard est une représentation d'une clé d'utilisateur publique donnée dans une chaîne conviviale avec correction d'erreurs ; l'adresse tronquée est une représentation de la seconde moitié (point B) d'une clé d'utilisateur publique donnée en chaîne conviviale avec correction d’erreur. La structure de la transaction reste similaire à celle de Bitcoin : chaque utilisateur peut choisir plusieurs encaissements indépendants (sorties d'opérations), signez-les avec le code correspondant clés privées et les envoyer à différentes destinations. Contrairement au modèle de Bitcoin, où un utilisateur possède une clé privée et publique unique, dans le cas modèle proposé, un expéditeur génère une clé publique unique basée sur l'adresse du destinataire et quelques données aléatoires. En ce sens, une transaction entrante pour le même destinataire est envoyée à un clé publique unique (pas directement à une adresse unique) et seul le destinataire peut récupérer la partie privée correspondante pour racheter ses fonds (en utilisant sa clé privée unique). Le destinataire peut dépenser les fonds en utilisant une signature en anneau, en gardant anonymes sa propriété et ses dépenses réelles. Les détails du protocole sont expliqués dans les sous-sections suivantes. 4.3 Paiements non liés Les adresses classiques Bitcoin, une fois publiées, deviennent un identifiant sans ambiguïté pour les paiements, en les reliant entre eux et en les liant aux pseudonymes du destinataire. Si quelqu'un veut reçoit une transaction « déliée », il doit transmettre son adresse à l'expéditeur par un canal privé. \(S'\)il souhaite recevoir différentes transactions dont il ne peut être prouvé qu'elles appartiennent au même propriétaire il doit générer toutes les différentes adresses et ne jamais les publier sous son propre pseudonyme. Publique Privé Alice Carole Adresse de Bob 1 Adresse de Bob 2 La clé de Bob 1 La clé de Bob 2 Bob Fig. 2. Mod traditionnel de clés/transactions Bitcoinél. Nous proposons une solution permettant à un utilisateur de publier une adresse unique et de recevoir des paiements non liés. La destination de chaque sortie CryptoNote (par défaut) est une clé publique, dérivé de l’adresse du destinataire et des données aléatoires de l’expéditeur. Le principal avantage contre Bitcoin est que chaque clé de destination est unique par défaut (sauf si l'expéditeur utilise les mêmes données pour chaque clé). de ses transactions vers le même destinataire). Il n’existe donc pas de problème de « réutilisation des adresses » par conception et aucun observateur ne peut déterminer si des transactions ont été envoyées à une adresse ou un lien spécifique deux adresses ensemble. 6 12 Par conséquent, plutôt que d’envoyer des pièces depuis une adresse (qui est en réalité une clé publique) vers une adresse (une autre clé publique) en utilisant leurs clés privées, les utilisateurs envoient des pièces depuis une boîte postale unique (qui génère en utilisant la clé publique de vos amis) vers une boîte postale unique (de la même manière) en utilisant votre propres clés privées. Dans un sens, nous disons : « D'accord, tout le monde ne met pas la main sur l'argent pendant qu'il est en cours. transféré! Il suffit simplement de savoir que nos clés peuvent ouvrir cette boîte et que nous savons combien d'argent il y a dans la boîte. Ne mettez jamais vos empreintes digitales sur la boîte postale ou Pour l'utiliser réellement, échangez simplement la boîte remplie d'argent liquide elle-même. De cette façon, nous ne savons pas qui a envoyé quoi, mais le contenu de ces discours publics est toujours sans friction, fongible, divisible et possèdent toujours toutes les autres belles qualités d’argent que nous désirons, comme le bitcoin. » Un ensemble infini de boîtes postales. Vous publiez une adresse, j'ai une clé privée. J'utilise ma clé privée et votre adresse, et quelques données aléatoires, pour générer une clé publique. L'algorithme est conçu de telle sorte que, puisque votre L'adresse a été utilisée pour générer la clé publique, seule VOTRE clé privée fonctionne pour déverrouiller le message. Une observatrice, Eve, vous voit publier votre adresse, et voit la clé publique que j'annonce. Cependant, elle ne sait pas si j'ai annoncé ma clé publique en fonction de votre adresse, de la sienne ou de celle de Brenda ou celui de Charlene, ou celui de qui que ce soit. Elle vérifie sa clé privée avec la clé publique que j'ai annoncée et voit que ça ne marche pas ; ce n'est pas son argent. Elle ne connaît la clé privée de personne d’autre, et seul le destinataire du message possède la clé privée permettant de déverrouiller le message. Donc personne écouter peut déterminer qui a reçu l’argent et encore moins prendre l’argent.

Publique Privé Alice Carole Clé à usage unique Clé à usage unique Clé à usage unique Bob La clé de Bob L'adresse de Bob Fig. 3. Modèle de clés/transactions CryptoNote. Tout d'abord, l'expéditeur effectue un échange Diffie-Hellman pour obtenir un secret partagé à partir de ses données et la moitié de l’adresse du destinataire. Il calcule ensuite une clé de destination unique, en utilisant la clé partagée secret et la seconde moitié de l'adresse. Deux clés EC différentes sont requises du destinataire pour ces deux étapes, une adresse CryptoNote standard est donc presque deux fois plus grande qu'un portefeuille Bitcoin adresse. Le récepteur effectue également un échange Diffie-Hellman pour récupérer le signal correspondant. clé secrète. Une séquence de transaction standard se déroule comme suit : 1. Alice souhaite envoyer un paiement à Bob, qui a publié son adresse standard. Elle décompresse l'adresse et obtient la clé publique de Bob (A, B). 2. Alice génère un \(r \in [1, l - 1]\) aléatoire et calcule une clé publique unique \(P = H_s(rA)G +\) B. 3. Alice utilise P comme clé de destination pour la sortie et regroupe également la valeur R = rG (dans le cadre d'une partie de la bourse Diffie-Hellman) quelque part dans la transaction. Notez qu'elle peut créer autres sorties avec des clés publiques uniques : les clés de différents destinataires (Ai, Bi) impliquent des Pi différents même avec le même r. Transaction Clé publique d'émission Sortie d'émission Montant Clé de destination R = rG P = Hs(rA)G + B Le récepteur clé publique Données aléatoires de l'expéditeur r (A, B) Figure 4. Structure de transaction standard. 4. Alice envoie la transaction. 5. Bob vérifie chaque transaction qui passe avec sa clé privée (a, b) et calcule P ′ = Hs(aR)G + B. Si la transaction d’Alice avec Bob comme destinataire en faisait partie, alors aR = arG = rA et P′ = P. 7 Publique Privé Alice Carole Clé à usage unique Clé à usage unique Clé à usage unique Bob La clé de Bob L'adresse de Bob Fig. 3. Modèle de clés/transactions CryptoNote. Tout d'abord, l'expéditeur effectue un échange Diffie-Hellman pour obtenir un secret partagé à partir de ses données et la moitié de l’adresse du destinataire. Il calcule ensuite une clé de destination unique, en utilisant la clé partagée secret et la seconde moitié de l'adresse. Deux clés EC différentes sont requises du destinataire pour ces deux étapes, une adresse CryptoNote standard est donc presque deux fois plus grande qu'un portefeuille Bitcoin adresse. Le récepteur effectue également un échange Diffie-Hellman pour récupérer le signal correspondant. clé secrète. Une séquence de transaction standard se déroule comme suit : 1. Alice souhaite envoyer un paiement à Bob, qui a publié son adresse standard. Elle décompresse l'adresse et obtient la clé publique de Bob (A, B). 2. Alice génère un \(r \in [1, l - 1]\) aléatoire et calcule une clé publique unique \(P = H_s(rA)G +\) B. 3. Alice utilise P comme clé de destination pour la sortie et regroupe également la valeur R = rG (dans le cadre d'une partie de la bourse Diffie-Hellman) quelque part dans la transaction. Notez qu'elle peut créer autres sorties avec des clés publiques uniques : les clés de différents destinataires (Ai, Bi) impliquent des Pi différents même avec le même r. Transaction Clé publique d'émission Sortie d'émission Montant Clé de destination R = rG P = Hs(rA)G + B Le récepteur clé publique Données aléatoires de l'expéditeur r (A, B) Figure 4. Structure de transaction standard. 4. Alice envoie la transaction. 5. Bob vérifie chaque transaction qui passe avec sa clé privée (a, b) et calcule P ′ = Hs(aR)G + B. Si la transaction d’Alice avec Bob comme destinataire en faisait partie, alors aR = arG = rA et P′ = P. 7 13 Je me demande à quel point ce serait pénible de mettre en œuvre un choix de cryptographie schéma. Elliptique ou autre. Ainsi, si un système est brisé à l'avenir, la devise change sans souci. Probablement un gros emmerdeur. D'accord, c'est exactement ce que je viens d'expliquer dans mon commentaire précédent. Le type Diffie-Hellman les échanges sont soignés. Disons qu'Alex et Brenda ont chacun un numéro secret, A et B, et un numéro ils ne se soucient pas de garder le secret, a et b. Ils souhaitent générer un secret partagé sans Eva le découvre. Diffie et Hellman ont trouvé un moyen pour qu'Alex et Brenda partagent les numéros publics a et b, mais pas les numéros privés A et B, et générer un secret partagé, K. En utilisant ce secret partagé, K, sans qu'aucune Eva ne l'écoute pour pouvoir générer le même K, Alex et Brenda peuvent désormais utiliser K comme clé de cryptage secrète et renvoyer des messages secrets et en avant. Voici comment cela PEUT fonctionner, même si cela devrait fonctionner avec des nombres beaucoup plus grands que 100. Nous utiliserons 100 car travailler sur les entiers modulo 100 équivaut à "jeter tout mais les deux derniers chiffres d'un nombre. Alex et Brenda choisissent chacun A, a, B et b. Ils gardent A et B secrets. Alex dit à Brenda sa valeur d'un modulo 100 (juste les deux derniers chiffres) et Brenda le dit à Alex. sa valeur de b modulo 100. Maintenant Eva connaît (a,b) modulo 100. Mais Alex sait (a,b,A) donc elle peut calculer x=abA modulo 100.Alex coupe tous les chiffres sauf le dernier parce qu'on travaille sous les entiers modulo 100 à nouveau. De même, Brenda connaît (a,b,B) donc elle peut calculer y=abB modulo 100. Alex peut désormais publier x et Brenda peut publier y. Mais maintenant, Alex peut calculer yA = abBA modulo 100, et Brenda peut calculer xB. = abBA modulo 100. Ils connaissent tous les deux le même numéro ! Mais tout ce qu'Eva a entendu, c'est (une,b,unebUNE,unebB). Elle n’a pas de moyen simple de calculer abA*B. C’est la manière la plus simple et la moins sûre d’envisager l’échange Diffie-Hellman. Des versions plus sécurisées existent. Mais la plupart des versions fonctionnent car la factorisation entière et discrète les logarithmes sont difficiles, et ces deux problèmes sont facilement résolus par les ordinateurs quantiques. Je vérifierai s’il existe des versions résistantes au quantique. http://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange Il manque tout un tas d'étapes dans la "séquence txn standard" répertoriée ici, comme les SIGNATURES. Ici, ils sont simplement tenus pour acquis. Ce qui est vraiment dommage, car l'ordre dans lequel nous les trucs de signature, les informations incluses dans le message signé, et ainsi de suite... tout cela est extrêmement important pour le protocole. Se tromper sur une ou deux étapes, même légèrement dans le désordre, tout en mettant en œuvre « le séquence de transactions standard" pourrait remettre en question la sécurité de l'ensemble du système. De plus, les preuves présentées plus loin dans cet article risquent de ne pas être suffisamment rigoureuses si le Le cadre dans lequel ils travaillent est aussi vaguement défini que dans cette section.

Publique Privé Alice Carole Clé à usage unique Clé à usage unique Clé à usage unique Bob La clé de Bob L'adresse de Bob Fig. 3. Modèle de clés/transactions CryptoNote. Tout d'abord, l'expéditeur effectue un échange Diffie-Hellman pour obtenir un secret partagé à partir de ses données et la moitié de l’adresse du destinataire. Il calcule ensuite une clé de destination unique, en utilisant la clé partagée secret et la seconde moitié de l'adresse. Deux clés EC différentes sont requises du destinataire pour ces deux étapes, une adresse CryptoNote standard est donc presque deux fois plus grande qu'un portefeuille Bitcoin adresse. Le récepteur effectue également un échange Diffie-Hellman pour récupérer le signal correspondant. clé secrète. Une séquence de transaction standard se déroule comme suit : 1. Alice souhaite envoyer un paiement à Bob, qui a publié son adresse standard. Elle décompresse l'adresse et obtient la clé publique de Bob (A, B). 2. Alice génère un \(r \in [1, l - 1]\) aléatoire et calcule une clé publique unique \(P = H_s(rA)G +\) B. 3. Alice utilise P comme clé de destination pour la sortie et regroupe également la valeur R = rG (dans le cadre d'une partie de la bourse Diffie-Hellman) quelque part dans la transaction. Notez qu'elle peut créer autres sorties avec des clés publiques uniques : les clés de différents destinataires (Ai, Bi) impliquent des Pi différents même avec le même r. Transaction Clé publique d'émission Sortie d'émission Montant Clé de destination R = rG P = Hs(rA)G + B Le récepteur clé publique Données aléatoires de l'expéditeur r (A, B) Figure 4. Structure de transaction standard. 4. Alice envoie la transaction. 5. Bob vérifie chaque transaction qui passe avec sa clé privée (a, b) et calcule P ′ = Hs(aR)G + B. Si la transaction d’Alice avec Bob comme destinataire en faisait partie, alors aR = arG = rA et P′ = P. 7 Publique Privé Alice Carole Clé à usage unique Clé à usage unique Clé à usage unique Bob La clé de Bob L'adresse de Bob Fig. 3. Modèle de clés/transactions CryptoNote. Tout d'abord, l'expéditeur effectue un échange Diffie-Hellman pour obtenir un secret partagé à partir de ses données et la moitié de l’adresse du destinataire. Il calcule ensuite une clé de destination unique, en utilisant la clé partagée secret et la seconde moitié de l'adresse. Deux clés EC différentes sont requises du destinataire pour ces deux étapes, une adresse CryptoNote standard est donc presque deux fois plus grande qu'un portefeuille Bitcoin adresse. Le récepteur effectue également un échange Diffie-Hellman pour récupérer le signal correspondant. clé secrète. Une séquence de transaction standard se déroule comme suit : 1. Alice souhaite envoyer un paiement à Bob, qui a publié son adresse standard. Elle décompresse l'adresse et obtient la clé publique de Bob (A, B). 2. Alice génère un \(r \in [1, l - 1]\) aléatoire et calcule une clé publique unique \(P = H_s(rA)G +\) B. 3. Alice utilise P comme clé de destination pour la sortie et regroupe également la valeur R = rG (dans le cadre d'une partie de la bourse Diffie-Hellman) quelque part dans la transaction. Notez qu'elle peut créer autres sorties avec des clés publiques uniques : les clés de différents destinataires (Ai, Bi) impliquent des Pi différents même avec le même r. Transaction Clé publique d'émission Sortie d'émission Montant Clé de destination R = rG P = Hs(rA)G + B Le récepteur clé publique Données aléatoires de l'expéditeur r (A, B) Figure 4. Structure de transaction standard. 4. Alice envoie la transaction. 5. Bob vérifie chaque transaction qui passe avec sa clé privée (a, b) et calcule P ′ = Hs(aR)G + B. Si la transaction d’Alice avec Bob comme destinataire en faisait partie, alors aR = arG = rA et P′ = P. 7 14 Notez que le(s) auteur(s ?) font un travail épouvantable en gardant leur terminologie claire tout au long le texte, mais surtout dans ce morceau suivant. La prochaine incarnation de cet article sera nécessairement beaucoup plus rigoureux. Dans le texte, ils font référence à P comme étant leur clé publique unique. Dans le diagramme, ils font référence à R comme leur « clé publique Tx » et P comme leur « clé de destination ». Si je devais réécrire ceci, je le ferais exposez très spécifiquement une certaine terminologie avant de discuter de ces sections. Cette aune est massive. Voir page 5. Qui les choisit ? Le diagramme illustre que la clé publique de transaction R = rG, qui est aléatoire et choisie par l'expéditeur, ne fait pas partie de la sortie Tx. C'est parce que cela pourrait être le même pour plusieurs transactions à plusieurs personnes et n’est pas utilisé * PLUS TARD * pour dépenser. Un nouveau R est généré chaque fois que vous souhaitez diffuser une nouvelle transaction CryptoNote. De plus, R n’est utilisé que pour vérifier si vous êtes le destinataire de la transaction. Ce ne sont pas des données indésirables, mais elles le sont pour tout le monde. sans les clés privées associées à (A,B). La clé de destination, en revanche, P = Hs(rA)G + B fait partie de la sortie Tx. Tout le monde qui fouille dans les données de chaque transaction en cours doit vérifier son propre P* généré par rapport à ce P pour voir s'ils possèdent cette transaction de passage. Toute personne disposant d'un résultat de transaction non dépensé (UTXO) aura un tas de ces P qui traînent avec des montants. Afin de dépenserd, ils signez un nouveau message incluant P. Alice doit signer cette transaction avec une ou plusieurs clés privées à usage unique associées à la ou aux clés de destination des sorties de transaction non dépensées. Chaque clé de destination appartenant à Alice est équipée avec une clé privée unique appartenant également (vraisemblablement) à Alice. Chaque fois qu'Alice veut m'envoyer le contenu d'une clé de destination, ou Bob, ou Brenda, ou Charlie ou Charlene, elle utilise sa clé privée pour signer la transaction. Dès réception de la transaction, je recevrai un nouveau Clé publique Tx, une nouvelle clé publique de destination, et je pourrai récupérer une nouvelle clé privée unique x. Combiner ma clé privée unique, x, avec la destination publique de la nouvelle transaction la ou les clés sont la façon dont nous envoyons une nouvelle transaction

1. Bob peut récupérer la clé privée unique correspondante : x = Hs(aR) + b, de sorte que P = xG. Il peut dépenser cette sortie à tout moment en signant une transaction avec x. Transaction Clé publique d'émission Sortie d'émission Montant Clé de destination P ′ = Hs(aR)G + bG clé publique unique x = Hs(aR) + b clé privée à usage unique Le récepteur clé privée (une, b) R. P' ?=P Fig. 5. Vérification des transactions entrantes. En conséquence, Bob reçoit des paiements entrants, associés à des clés publiques uniques qui sont inattaquable pour un spectateur. Quelques remarques complémentaires : • Lorsque Bob « reconnaît » ses transactions (voir étape 5), il n'utilise pratiquement que la moitié de ses informations privées : (a, B). Cette paire, également connue sous le nom de clé de suivi, peut être transmise à un tiers (Carol). Bob peut lui déléguer le traitement des nouvelles transactions. Bob n'a pas besoin de faire explicitement confiance à Carol, car elle ne peut pas récupérer la clé secrète à usage unique p sans la clé privée complète de Bob (a, b). Cette approche est utile lorsque Bob manque de bande passante ou la puissance de calcul (smartphones, portefeuilles matériels, etc.). • Si Alice souhaite prouver qu'elle a envoyé une transaction à l'adresse de Bob, elle peut soit divulguer r ou utiliser tout type de protocole de connaissance nulle pour prouver qu'elle connaît r (par exemple en signant la transaction avec r). • Si Bob souhaite avoir une adresse compatible avec l'audit où toutes les transactions entrantes sont connectable, il peut soit publier sa clé de suivi, soit utiliser une adresse tronquée. Cette adresse ne représentent qu'une seule clé ec publique B, et la partie restante requise par le protocole est en dérive comme suit : a = Hs(B) et A = Hs(B)G. Dans les deux cas, chaque personne est capable de « reconnaître » toutes les transactions entrantes de Bob, mais, bien sûr, personne ne peut dépenser les fonds qu'ils contiennent sans la clé secrète b. 4.4 Signatures de bague uniques Un protocole basé sur des signatures en anneau uniques permet aux utilisateurs d'obtenir une dissociation inconditionnelle. Malheureusement, les types ordinaires de signatures cryptographiques permettent de retracer les transactions jusqu'à leur émetteurs et récepteurs respectifs. Notre solution à cette lacune réside dans l’utilisation d’une signature différente type que ceux actuellement utilisés dans les systèmes de monnaie électronique. Nous fournirons dans un premier temps une description générale de notre algorithme sans référence explicite à monnaie électronique. Une signature en anneau unique contient quatre algorithmes : (GEN, SIG, VER, LNK) : GEN : prend des paramètres publics et génère une paire ec (P, x) et une clé publique I. SIG : prend un message m, un ensemble \(S'\) de clés publiques {Pi}i̸=s, une paire (Ps, xs) et génère une signature \(\sigma\) et un ensemble \(S = \)S'\( \cup \{P_s\}\). 8

2. Bob peut récupérer la clé privée unique correspondante : x = Hs(aR) + b, de sorte que P = xG. Il peut dépenser cette sortie à tout moment en signant une transaction avec x. Transaction Clé publique d'émission Sortie d'émission Montant Clé de destination P ′ = Hs(aR)G + bG clé publique unique x = Hs(aR) + b clé privée à usage unique Le récepteur clé privée (une, b) R. P' ?=P Fig. 5. Vérification des transactions entrantes. En conséquence, Bob reçoit des paiements entrants, associés à des clés publiques uniques qui sont inattaquable pour un spectateur. Quelques remarques complémentaires : • Lorsque Bob « reconnaît » ses transactions (voir étape 5), il n'utilise pratiquement que la moitié de ses informations privées : (a, B). Cette paire, également connue sous le nom de clé de suivi, peut être transmise à un tiers (Carol). Bob peut lui déléguer le traitement des nouvelles transactions. Bob n'a pas besoin de faire explicitement confiance à Carol, car elle ne peut pas récupérer la clé secrète à usage unique p sans la clé privée complète de Bob (a, b). Cette approche est utile lorsque Bob manque de bande passante ou la puissance de calcul (smartphones, portefeuilles matériels, etc.). • Si Alice souhaite prouver qu'elle a envoyé une transaction à l'adresse de Bob, elle peut soit divulguer r ou utiliser tout type de protocole de connaissance nulle pour prouver qu'elle connaît r (par exemple en signant la transaction avec r). • Si Bob souhaite avoir une adresse compatible avec l'audit où toutes les transactions entrantes sont connectable, il peut soit publier sa clé de suivi, soit utiliser une adresse tronquée. Cette adresse ne représentent qu'une seule clé ec publique B, et la partie restante requise par le protocole est en dérive comme suit : a = Hs(B) et A = Hs(B)G. Dans les deux cas, chaque personne est capable de « reconnaître » toutes les transactions entrantes de Bob, mais, bien sûr, personne ne peut dépenser les fonds qu'ils contiennent sans la clé secrète b. 4.4 Signatures de bague uniques Un protocole basé sur des signatures en anneau uniques permet aux utilisateurs d'obtenir une dissociation inconditionnelle. Malheureusement, les types ordinaires de signatures cryptographiques permettent de retracer les transactions jusqu'à leur émetteurs et récepteurs respectifs. Notre solution à cette lacune réside dans l’utilisation d’une signature différente type que ceux actuellement utilisés dans les systèmes de monnaie électronique. Nous fournirons dans un premier temps un générateural description de notre algorithme sans référence explicite à monnaie électronique. Une signature en anneau unique contient quatre algorithmes : (GEN, SIG, VER, LNK) : GEN : prend des paramètres publics et génère une paire ec (P, x) et une clé publique I. SIG : prend un message m, un ensemble \(S'\) de clés publiques {Pi}i̸=s, une paire (Ps, xs) et génère une signature \(\sigma\) et un ensemble \(S = \)S'\( \cup \{P_s\}\). 8 15 À quoi ressemble ici un résultat de transaction non dépensé ? Le diagramme suggère que le résultat de la transaction se compose uniquement de deux points de données : le montant et la clé de destination. Mais ce n'est pas suffisant car lorsque j'essaierai de dépenser cette "sortie", j'aurai toujours besoin de connaître R=rG. N'oubliez pas que r est choisi par l'expéditeur et R est a) utilisé pour reconnaître les cryptonotes entrantes comme votre propre et b) utilisé pour générer la clé privée unique utilisée pour « réclamer » votre cryptonote. La partie que je ne comprends pas à ce sujet ? En prenant le théorique "d'accord, nous avons ces signatures et transactions, et nous les transmettons" dans le monde de la programmation "D'accord, quelles informations spécifiquement constituent un individu UTXO ?" La meilleure façon de répondre à cette question est de fouiller dans le corps du code totalement non commenté. Bravo, équipe bytecoin. Rappel : la possibilité de lien signifie « la même personne a-t-elle envoyé ? » et l'indisponibilité signifie "a fait la même chose personne reçoit?". Ainsi, un système peut être lié ou non, impossible à relier ou non. Ennuyeux, je sais. Ainsi, lorsque Nic van Saberhagen dit ici : « ... les paiements entrants [sont] associés à des paiements ponctuels. des clés publiques qui ne peuvent être liées pour un spectateur", voyons ce qu'il veut dire. Tout d’abord, considérons une situation dans laquelle Alice envoie à Bob deux transactions distinctes à partir du même adresse à la même adresse. Dans l'univers Bitcoin, Alice a déjà commis l'erreur d'envoi à partir de la même adresse et la transaction a donc échoué à notre désir de limiter possibilité de liaison. De plus, comme elle a envoyé l’argent à la même adresse, elle a déçu notre désir. pour la non-liaison. Cette transaction Bitcoin était à la fois (totalement) liée et non dissociable. D’un autre côté, dans l’univers des cryptonotes, disons qu’Alice envoie à Bob une cryptonote, en utilisant l’adresse publique de Bob. Elle choisit comme ensemble de clés publiques obscurcissantes toutes les clés publiques connues. clés dans la région métropolitaine de Washington DC. Alex génère une clé publique unique en utilisant la sienne informations et informations publiques de Bob. Elle envoie l'argent, et tout observateur seulement pouvoir glaner "Quelqu'un de la région métropolitaine de Washington DC a envoyé 2,3 cryptonotes à l'adresse publique unique XYZ123." Nous avons ici un contrôle probabiliste sur la possibilité de lien, nous appellerons donc cela « presque non lien ». Nous ne voyons également que les clés publiques uniques auxquelles l’argent est envoyé. Même si on soupçonnait le récepteur était Bob, nous n'avons pas ses clés privées et nous ne pouvons donc pas tester si une transaction passe appartient à Bob et encore moins génère sa clé privée unique pour échanger sa cryptonote. Donc ça est, en fait, totalement « indiscutable ». C’est donc l’astuce la plus intéressante de toutes. Qui veut vraiment faire confiance à un autre MtGox ? Nous pouvons être à l'aise de stocker une certaine quantité de BTC sur Coinbase, mais le nec plus ultra en matière de sécurité Bitcoin est un portefeuille physique. Ce qui est gênant. Dans ce cas, vous pouvez donner en toute confiance la moitié de votre clé privée sans compromettre votre propre capacité à dépenser de l’argent. En faisant cela, tout ce que vous faites, c'est dire à quelqu'un comment briser l'indisponibilité. L'autre les propriétés du CN agissant comme une monnaie sont préservées, comme une preuve contre les doubles dépenses et que sais-je encore.

3. Bob peut récupérer la clé privée unique correspondante : x = Hs(aR) + b, de sorte que P = xG. Il peut dépenser cette sortie à tout moment en signant une transaction avec x. Transaction Clé publique d'émission Sortie d'émission Montant Clé de destination P ′ = Hs(aR)G + bG clé publique unique x = Hs(aR) + b clé privée à usage unique Le récepteur clé privée (une, b) R. P' ?=P Fig. 5. Vérification des transactions entrantes. En conséquence, Bob reçoit des paiements entrants, associés à des clés publiques uniques qui sont inattaquable pour un spectateur. Quelques remarques complémentaires : • Lorsque Bob « reconnaît » ses transactions (voir étape 5), il n'utilise pratiquement que la moitié de ses informations privées : (a, B). Cette paire, également connue sous le nom de clé de suivi, peut être transmise à un tiers (Carol). Bob peut lui déléguer le traitement des nouvelles transactions. Bob n'a pas besoin de faire explicitement confiance à Carol, car elle ne peut pas récupérer la clé secrète à usage unique p sans la clé privée complète de Bob (a, b). Cette approche est utile lorsque Bob manque de bande passante ou la puissance de calcul (smartphones, portefeuilles matériels, etc.). • Si Alice souhaite prouver qu'elle a envoyé une transaction à l'adresse de Bob, elle peut soit divulguer r ou utiliser tout type de protocole de connaissance nulle pour prouver qu'elle connaît r (par exemple en signant la transaction avec r). • Si Bob souhaite avoir une adresse compatible avec l'audit où toutes les transactions entrantes sont connectable, il peut soit publier sa clé de suivi, soit utiliser une adresse tronquée. Cette adresse ne représentent qu'une seule clé ec publique B, et la partie restante requise par le protocole est en dérive comme suit : a = Hs(B) et A = Hs(B)G. Dans les deux cas, chaque personne est capable de « reconnaître » toutes les transactions entrantes de Bob, mais, bien sûr, personne ne peut dépenser les fonds qu'ils contiennent sans la clé secrète b. 4.4 Signatures de bague uniques Un protocole basé sur des signatures en anneau uniques permet aux utilisateurs d'obtenir une dissociation inconditionnelle. Malheureusement, les types ordinaires de signatures cryptographiques permettent de retracer les transactions jusqu'à leur émetteurs et récepteurs respectifs. Notre solution à cette lacune réside dans l’utilisation d’une signature différente type que ceux actuellement utilisés dans les systèmes de monnaie électronique. Nous fournirons dans un premier temps une description générale de notre algorithme sans référence explicite à monnaie électronique. Une signature en anneau unique contient quatre algorithmes : (GEN, SIG, VER, LNK) : GEN : prend des paramètres publics et génère une paire ec (P, x) et une clé publique I. SIG : prend un message m, un ensemble \(S'\) de clés publiques {Pi}i̸=s, une paire (Ps, xs) et génère une signature \(\sigma\) et un ensemble \(S = \)S'\( \cup \{P_s\}\). 8

4. Bob peut récupérer la clé privée unique correspondante : x = Hs(aR) + b, de sorte que P = xG. Il peut dépenser cette sortie à tout moment en signant une transaction avec x. Transaction Clé publique d'émission Sortie d'émission Montant Clé de destination P ′ = Hs(aR)G + bG clé publique unique x = Hs(aR) + b clé privée à usage unique Le récepteur clé privée (une, b) R. P' ?=P Fig. 5. Vérification des transactions entrantes. En conséquence, Bob reçoit des paiements entrants, associés à des clés publiques uniques qui sont inattaquable pour un spectateur. Quelques remarques complémentaires : • Lorsque Bob « reconnaît » ses transactions (voir étape 5), il n'utilise pratiquement que la moitié de ses informations privées : (a, B). Cette paire, également connue sous le nom de clé de suivi, peut être transmise à un tiers (Carol). Bob peut lui déléguer le traitement des nouvelles transactions. Bob n'a pas besoin de faire explicitement confiance à Carol, car elle ne peut pas récupérer la clé secrète à usage unique p sans la clé privée complète de Bob (a, b). Cette approche est utile lorsque Bob manque de bande passante ou la puissance de calcul (smartphones, portefeuilles matériels, etc.). • Si Alice souhaite prouver qu'elle a envoyé une transaction à l'adresse de Bob, elle peut soit divulguer r ou utiliser tout type de protocole de connaissance nulle pour prouver qu'elle connaît r (par exemple en signant la transaction avec r). • Si Bob souhaite avoir une adresse compatible avec l'audit où toutes les transactions entrantes sont connectable, il peut soit publier sa clé de suivi, soit utiliser une adresse tronquée. Cette adresse ne représentent qu'une seule clé ec publique B, et la partie restante requise par le protocole est en dérive comme suit : a = Hs(B) et A = Hs(B)G. Dans les deux cas, chaque personne est capable de « reconnaître » toutes les transactions entrantes de Bob, mais, bien sûr, personne ne peut dépenser les fonds qu'ils contiennent sans la clé secrète b. 4.4 Signatures de bague uniques Un protocole basé sur des signatures en anneau uniques permet aux utilisateurs d'obtenir une dissociation inconditionnelle. Malheureusement, les types ordinaires de signatures cryptographiques permettent de retracer les transactions jusqu'à leur émetteurs et récepteurs respectifs. Notre solution à cette lacune réside dans l’utilisation d’une signature différente type que ceux actuellement utilisés dans les systèmes de monnaie électronique. Nous fournirons dans un premier temps un générateural description de notre algorithme sans référence explicite à monnaie électronique. Une signature en anneau unique contient quatre algorithmes : (GEN, SIG, VER, LNK) : GEN : prend des paramètres publics et génère une paire ec (P, x) et une clé publique I. SIG : prend un message m, un ensemble \(S'\) de clés publiques {Pi}i̸=s, une paire (Ps, xs) et génère une signature \(\sigma\) et un ensemble \(S = \)S'\( \cup \{P_s\}\). 8 16 Oui, nous avons maintenant a) une adresse de paiement et b) un identifiant de paiement. Un critique pourrait se demander « est-ce vraiment nécessaire de faire cela ? Après tout, si un commerçant reçoit le 112.00678952 CN exactement, et c'était ma commande, et j'ai une capture d'écran ou un reçu ou autre, n'est-ce pas un degré de précision insensé suffisant ? » La réponse est « peut-être que la plupart du temps, au quotidien, transactions en face à face. Cependant, la situation la plus courante (surtout dans le monde numérique) est la suivante : un commerçant vend un ensemble d'objets, chacun avec un prix fixe. Disons que l'objet A vaut 0,001 CN, l'objet B vaut 0,01 CN et l'objet C vaut 0,1 CN. Maintenant, si le commerçant reçoit une commande de 1,618 CN, il y a beaucoup de (nombreuses !) façons d’organiser une commande pour un client. Et donc sans une sorte d'identifiant de paiement, identifier la commande dite « unique » d'un client avec le coût dit « unique » de sa l'ordre devient impossible. Encore plus drôle : si tout dans ma boutique en ligne coûte exactement 1,0 CN, et je reçois 1000 clients par jour ? Et vous voulez prouver que vous avez acheté exactement 3 objets il y a deux semaines ? Sans identifiant de paiement ? Bonne chance, mon pote. Pour faire court : lorsque Bob publie une adresse de paiement, il peut finir par publier également une adresse de paiement. ainsi que l'identifiant de paiement (voir, par exemple, les dépôts Poloniex XMR). Ceci est différent de ce qui est décrit dans le texte ici où Alice est celle qui génère l'identifiant de paiement. Il doit également y avoir un moyen pour Bob de générer un identifiant de paiement. (une,B) Rappelons que la clé de suivi (a,B) peut être publiée ; perdre le secret de la valeur d’un testament ne pas violer votre capacité à dépenser ni permettre aux gens de vous voler (je pense... cela aurait à prouver), cela permettra simplement aux gens de voir toutes les transactions entrantes. Une adresse tronquée, comme décrit dans ce paragraphe, prend simplement la partie « privée » de la clé et le génère à partir de la partie "publique". Révéler la valeur de « a » supprimera la non-liabilité mais préservera le reste des transactions. L'auteur veut dire "non dissociable" car non dissociable fait référence au récepteur et pouvant être lié fait référence à l'expéditeur. Il est également clair que l’auteur n’avait pas réalisé qu’il y avait deux aspects différents dans la possibilité de lien. Puisque, après tout, la transaction est un objet orienté sur un graphe, deux questions se poseront : "Est-ce que ces deux transactions vont à la même personne ?" et "ces deux transactions arrivent-elles de la même personne ? » Il s'agit d'une politique de « non-retour » en vertu de laquelle la propriété de non-liaison de CryptoNote est conditionnel. C'est-à-dire que Bob peut choisir que ses transactions entrantes ne soient pas dissociables en utilisant cette politique. C’est une affirmation qu’ils prouvent sous le modèle Random Oracle. Nous y reviendrons ; le hasard Oracle a des avantages et des inconvénients.

VER : prend un message m, un ensemble S, une signature \(\sigma\) et renvoie « vrai » ou « faux ». LNK : prend un ensemble I = {Ii}, une signature \(\sigma\) et produit « linked » ou « indep ». L'idée derrière le protocole est assez simple : un utilisateur produit une signature qui peut être vérifié par un ensemble de clés publiques plutôt que par une clé publique unique. L'identité du signataire est impossible à distinguer des autres utilisateurs dont les clés publiques sont dans l'ensemble jusqu'à ce que le propriétaire produise une deuxième signature utilisant la même paire de clés. Clés privées x0 \(\cdots\) xi \(\cdots\) xn Clés publiques P0 \(\cdots\) Pi \(\cdots\) Pn Bague Signature signe vérifier Fig. 6. Anonymat de la signature en anneau. GEN : Le signataire choisit une clé secrète aléatoire \(x \in [1, l - 1]\) et calcule la clé correspondante clé publique P = xG. De plus, il calcule une autre clé publique I = xHp(P) que nous allons appelons « l’image clé ». SIG : le signataire génère une signature en anneau unique avec une connaissance nulle non interactive preuve en utilisant les techniques de [21]. Il sélectionne un sous-ensemble aléatoire \(S'\) de n parmi ceux des autres utilisateurs. clés publiques Pi, sa propre paire de clés (x, P) et l'image clé I. Soit \(0 \leq s \leq n\) l'index secret du signataire dans S (pour que sa clé publique soit Ps). Il choisit un {qi | je = 0 . . . n} et {wi | je = 0 . . . n, i ̸= s} de (1 . . . l) et applique la transformations suivantes : Li = ( qiG, si je = s qiG + wiPi, si je ̸= s Ri = ( qiHp(Pi), si je = s qiHp(Pi) + wiI, si je ̸= s La prochaine étape consiste à relever le défi non interactif : c = Hs(m, L1, . . . , Ln, R1, . . . , Rn) Finalement le signataire calcule la réponse : ci =    Wi, si je ̸= s c- nP je = 0 ci mod l, si je = s ri = ( qi, si je ̸= s qs −csx mod l, si je = s La signature résultante est \(\sigma\) = (I, c1, . . . , cn, r1, . . . , rn). 9 VER : prend un message m, un ensemble S, une signature \(\sigma\) et renvoie « vrai » ou « faux ». LNK : prend un ensemble I = {Ii}, une signature \(\sigma\) et produit « linked » ou « indep ». L'idée derrière le protocole est assez simple : un utilisateur produit une signature qui peut être vérifié par un ensemble de clés publiques plutôt que par une clé publique unique. L'identité du signataire est impossible à distinguer des autres utilisateurs dont les clés publiques sont dans l'ensemble jusqu'à ce que le propriétaire produise une deuxième signature utilisant la même paire de clés. Clés privées x0 \(\cdots\) xi \(\cdots\) xn Clés publiques P0 \(\cdots\) Pi \(\cdots\) Pn Bague Signature signe vérifier Fig. 6. Anonymat de la signature en anneau. GEN : Le signataire choisit une clé secrète aléatoire \(x \in [1, l - 1]\) et calcule la clé correspondante clé publique P = xG. De plus, il calcule une autre clé publique I = xHp(P) que nous allons appelons « l’image clé ». SIG : le signataire génère une signature en anneau unique avec une connaissance nulle non interactive preuve en utilisant les techniques de [21]. Il sélectionne un sous-ensemble aléatoire \(S'\) de n parmi ceux des autres utilisateurs. clés publiques Pi, sa propre paire de clés (x, P) et l'image clé I. Soit \(0 \leq s \leq n\) l'index secret du signataire dans S (pour que sa clé publique soit Ps). Il choisit un {qi | je = 0 . . . n} et {wi | je = 0 . . . n, i ̸= s} de (1 . . . l) et applique la transformations suivantes : Li = ( qiG, si je = s qiG + wiPi, si je ̸= s Ri = ( qiHp(Pi), si je = s qiHp(Pi) + wiI, si je ̸= s La prochaine étape consiste à relever le défi non interactif : c = Hs(m, L1, . . . , Ln, R1, . . . , Rn) Finalement le signataire calcule la réponse : ci =    Wi, si je ̸= s c- nP je = 0 ci mod l, si je = s ri = ( qi, si je ̸= s qs −csx mod l, si je = s La signature résultante est \(\sigma\) = (I, c1, . . . , cn, r1, . . . , rn). 9 17 C'est peut-être stupide, mais il faut être prudent lors de l'union de S et P_s. Si vous ajoutez simplement le dernière clé publique jusqu'à la fin, la dissociation est interrompue car quiconque vérifie les transactions en cours peut simplement vérifier la dernière clé publique répertoriée dans chaque transaction et boum. C'est la clé publique associé à l'expéditeur. Ainsi, après l'union, un générateur de nombres pseudo-aléatoires doit être utilisé pour permuter les clés publiques choisies. "...jusqu'à ce que le propriétaire produise une deuxième signature en utilisant la même paire de clés." Je souhaite au(x) auteur(s?) je développerais cela. Je crois que cela signifie "assurez-vous que chaque fois que vous choisissez un ensemble de clés publiques pour masquer vous-même, vous choisissez un jeu complètement nouveau, sans deux clés identiques. » Ce qui ressemble à un condition assez forte à placer en cas de dissociation. Peut-être que « vous choisissez un nouvel ensemble aléatoire parmi toutes les clés possibles" avec l'hypothèse que, même si des intersections non triviales seront inévitablement cela arrive, cela n’arrivera pas souvent. Quoi qu’il en soit, je dois approfondir cette déclaration. Cela génère la signature de l'anneau. Les preuves sans connaissance sont géniales : je vous mets au défi de me prouver que vous connaissez un secret sans révéler le secret. Par exemple, disons que nous sommes à l'entrée d'une grotte en forme de beignet, et au fond de la grotte (hors de vue depuis l'entrée) se trouve un oporte sans issue vers laquelle vous prétendez que vous avez la clé. Si vous allez dans une direction, cela vous laisse toujours passer, mais si vous allez dans la dans l'autre sens, vous avez besoin d'une clé. Mais tu ne veux même pas me MONTRER la clé, encore moins montre-moi que ça ouvre la porte. Mais tu veux me prouver que tu sais ouvrir le porte. Dans le cadre interactif, je lance une pièce de monnaie. Pile à gauche, pile à droite et vous descendez le grotte en forme de beignet, quelle que soit la direction dans laquelle la pièce vous dirige. Au fond, hors de ma vue, tu ouvrez la porte pour revenir de l'autre côté. Nous répétons l'expérience du tirage au sort jusqu'à ce que je sois convaincu que vous avez la clé. Mais c’est clairement la preuve INTERACTIVE de connaissance zéro. Il existe des versions non interactives dans lesquelles vous et moi n'avons jamais à communiquer ; de cette façon, aucune écoute indiscrète ne peut interférer. http://en.wikipedia.org/wiki/Zero-knowledge_proof Cette définition est inversée par rapport à la définition précédente.

VER : prend un message m, un ensemble S, une signature \(\sigma\) et renvoie « vrai » ou « faux ». LNK : prend un ensemble I = {Ii}, une signature \(\sigma\) et produit « linked » ou « indep ». L'idée derrière le protocole est assez simple : un utilisateur produit une signature qui peut être vérifié par un ensemble de clés publiques plutôt que par une clé publique unique. L'identité du signataire est impossible à distinguer des autres utilisateurs dont les clés publiques sont dans l'ensemble jusqu'à ce que le propriétaire produise une deuxième signature utilisant la même paire de clés. Clés privées x0 \(\cdots\) xi \(\cdots\) xn Clés publiques P0 \(\cdots\) Pi \(\cdots\) Pn Bague Signature signe vérifier Fig. 6. Anonymat de la signature en anneau. GEN : Le signataire choisit une clé secrète aléatoire \(x \in [1, l - 1]\) et calcule la clé correspondante clé publique P = xG. De plus, il calcule une autre clé publique I = xHp(P) que nous allons appelons « l’image clé ». SIG : le signataire génère une signature en anneau unique avec une connaissance nulle non interactive preuve en utilisant les techniques de [21]. Il sélectionne un sous-ensemble aléatoire \(S'\) de n parmi ceux des autres utilisateurs. clés publiques Pi, sa propre paire de clés (x, P) et l'image clé I. Soit \(0 \leq s \leq n\) l'index secret du signataire dans S (pour que sa clé publique soit Ps). Il choisit un {qi | je = 0 . . . n} et {wi | je = 0 . . . n, i ̸= s} de (1 . . . l) et applique la transformations suivantes : Li = ( qiG, si je = s qiG + wiPi, si je ̸= s Ri = ( qiHp(Pi), si je = s qiHp(Pi) + wiI, si je ̸= s La prochaine étape consiste à relever le défi non interactif : c = Hs(m, L1, . . . , Ln, R1, . . . , Rn) Finalement le signataire calcule la réponse : ci =    Wi, si je ̸= s c- nP je = 0 ci mod l, si je = s ri = ( qi, si je ̸= s qs −csx mod l, si je = s La signature résultante est \(\sigma\) = (I, c1, . . . , cn, r1, . . . , rn). 9 VER : prend un message m, un ensemble S, une signature \(\sigma\) et renvoie « vrai » ou « faux ». LNK : prend un ensemble I = {Ii}, une signature \(\sigma\) et produit « linked » ou « indep ». L'idée derrière le protocole est assez simple : un utilisateur produit une signature qui peut être vérifié par un ensemble de clés publiques plutôt que par une clé publique unique. L'identité du signataire est impossible à distinguer des autres utilisateurs dont les clés publiques sont dans l'ensemble jusqu'à ce que le propriétaire produise une deuxième signature utilisant la même paire de clés. Clés privées x0 \(\cdots\) xi \(\cdots\) xn Clés publiques P0 \(\cdots\) Pi \(\cdots\) Pn Bague Signature signe vérifier Fig. 6. Anonymat de la signature en anneau. GEN : Le signataire choisit une clé secrète aléatoire \(x \in [1, l - 1]\) et calcule la clé correspondante clé publique P = xG. De plus, il calcule une autre clé publique I = xHp(P) que nous allons appelons « l’image clé ». SIG : le signataire génère une signature en anneau unique avec une connaissance nulle non interactive preuve en utilisant les techniques de [21]. Il sélectionne un sous-ensemble aléatoire \(S'\) de n parmi ceux des autres utilisateurs. clés publiques Pi, sa propre paire de clés (x, P) et l'image clé I. Soit \(0 \leq s \leq n\) l'index secret du signataire dans S (pour que sa clé publique soit Ps). Il choisit un {qi | je = 0 . . . n} et {wi | je = 0 . . . n, i ̸= s} de (1 . . . l) et applique la transformations suivantes : Li = ( qiG, si je = s qiG + wiPi, si je ̸= s Ri = ( qiHp(Pi), si je = s qiHp(Pi) + wiI, si je ̸= s La prochaine étape consiste à relever le défi non interactif : c = Hs(m, L1, . . . , Ln, R1, . . . , Rn) Finalement le signataire calcule la réponse : ci =    Wi, si je ̸= s c- nP je = 0 ci mod l, si je = s ri = ( qi, si je ̸= s qs −csx mod l, si je = s La signature résultante est \(\sigma\) = (I, c1, . . . , cn, r1, . . . , rn). 9 18 Tout ce domaine est indépendant des cryptonotes, décrivant simplement l'algorithme de signature en anneau sans référence aux monnaies. Je soupçonne qu'une partie de la notation est cohérente avec le reste de l'article, cependant. Par exemple, x est la clé secrète « aléatoire » choisie dans GEN, qui donne la clé publique P et l'image de clé publique I. Cette valeur de x est la valeur que Bob calcule dans la partie 6 page 8. Voilà donc commence à dissiper une partie de la confusion de la description précédente. C'est plutôt cool ; l'argent n'est pas transféré de "l'adresse publique d'Alice vers l'adresse publique de Bob adresse." Il est transféré d'une adresse unique à une adresse unique. Donc, dans un sens, voici comment les choses fonctionnent. Si Alex a des cryptonotes parce que quelqu'un les lui a envoyées, cela signifie qu'elle dispose des clés privées nécessaires pour les envoyer à Bob. Elle utilise un échange Diffie-Hellman utilisant les informations publiques de Bob pour générer une nouvelle adresse unique et les cryptonotes sont transférées à cette adresse. Maintenant, puisqu'un échange DH (vraisemblablement sécurisé) a été utilisé pour générer la nouvelle adresse unique auquel Alex a envoyé son CN, Bob est le seul à disposer des clés privées nécessaires pour répéter le ci-dessus. Alors maintenant, Bob est Alex. http://en.wikipedia.org/wiki/Piecewise#Notation_and_interpretation La sommation doit être indexée sur j et non sur i. Chaque c_i est un déchet aléatoire (puisque w_i est aléatoire) sauf pour le cul de c_iassocié à la clé réelle impliquée dans cette signature. La valeur de c est un hash des informations précédentes. Je pense que cela peut contenir une faute de frappe pire que la réutilisation de l'index 'i', car c_s semble être implicitement, et non explicitement, défini. En effet, si l'on prend cette équation avec foi, alors on détermine que c_s = (1/2)c - (1/2) sum_i neq s c_i. Autrement dit, un hash moins tout un tas de nombres aléatoires. En revanche, si cette sommation est destinée à être lue "c_s = (c - sum_j neq s c_j) mod l", puis nous prenons le hash de nos informations précédentes, générons un tas de nombres aléatoires, soustrayez tous ces nombres aléatoires du hash, et cela nous donne c_s. Cela semble être ce qui "devrait" se produire compte tenu de mon intuition, et correspond à l'étape de vérification de la page 10. Mais l’intuition n’est pas mathématique. Je vais approfondir cela. Comme avant ; tous ces éléments seront des déchets aléatoires, à l'exception de celui associé au véritable clé publique du signataire x. Sauf que cette fois, c'est plus ce que j'attendrais de la structure : r_i est aléatoire pour i!=s et r_s est déterminé uniquement par le secret x et les valeurs s-indexées de q_i et c_i.

VER : Le vérificateur vérifie la signature en appliquant les transformations inverses : ( L' je = riG + ciPi R′ je = riHp(Pi) + ciI Enfin, le vérificateur vérifie si nP je = 0 ci ?= Hs(m, L′ 0, . . . , L' n, R′ 0, . . . , R' n) modèle l Si cette égalité est correcte, le vérificateur exécute l'algorithme LNK. Sinon, le vérificateur rejette la signature. LNK : le vérificateur vérifie si I a été utilisé dans des signatures antérieures (ces valeurs sont stockées dans le définir I). Des utilisations multiples impliquent que deux signatures ont été produites sous la même clé secrète. Le sens du protocole : en appliquant des L-transformations le signataire prouve qu'il sait tel x qu'au moins un Pi = xG. Pour rendre cette preuve non répétable, nous introduisons l'image clé comme je = xHp(P). Le signataire utilise les mêmes coefficients (ri, ci) pour prouver presque la même affirmation : il connaît x tel qu'au moins un \(H_p(P_i) = I \cdot x^{-1}\). Si l'application \(x \to I\) est une injection : 1. Personne ne peut récupérer la clé publique à partir de l’image de clé et identifier le signataire ; 2. Le signataire ne peut pas faire deux signatures avec des I différents et le même x. Une analyse de sécurité complète est fournie à l’Annexe A. 4.5 Transaction CryptoNote standard En combinant les deux méthodes (clés publiques non liées et signature en anneau introuvable), Bob obtient nouveau niveau de confidentialité par rapport au programme Bitcoin original. Cela lui impose de stocker uniquement une clé privée (a, b) et publier (A, B) pour commencer à recevoir et à envoyer des transactions anonymes. Lors de la validation de chaque transaction, Bob effectue en outre uniquement deux multiplications de courbes elliptiques et une addition par sortie pour vérifier si une transaction lui appartient. Pour chacun de ses sortie Bob récupère une paire de clés à usage unique (pi, Pi) et la stocke dans son portefeuille. Toutes les entrées peuvent être il est prouvé de manière circonstancielle qu'ils ont le même propriétaire seulement s'ils apparaissent dans une seule transaction. Dans En fait, cette relation est beaucoup plus difficile à établir en raison de la signature en anneau unique. Avec une signature en anneau, Bob peut efficacement cacher chaque entrée parmi celles de quelqu'un d'autre ; tout est possible les dépensiers seront équiprobables, même le propriétaire précédent (Alice) n'a pas plus d'informations que tout observateur. Lors de la signature de sa transaction, Bob précise n sorties étrangères du même montant que son sortie, en les mélangeant tous sans la participation d’autres utilisateurs. Bob lui-même (ainsi que quelqu'un d'autre) ne sait pas si l'un de ces paiements a été dépensé : un résultat peut être utilisé dans des milliers de signatures comme facteur d'ambiguïté et jamais comme cible de dissimulation. Le doublé Le contrôle des dépenses a lieu dans la phase LNK lors de la vérification par rapport à l'ensemble d'images clés utilisé. Bob peut choisir lui-même le degré d'ambiguïté : n = 1 signifie que la probabilité qu'il ait dépensé, la sortie est de 50 % de probabilité, n = 99 donne 1 %. La taille de la signature résultante augmente linéairement comme O(n+1), donc l'anonymat amélioré coûte à Bob des frais de transaction supplémentaires. Il peut aussi définissez n = 0 et faites en sorte que sa signature en anneau soit composée d'un seul élément, mais cela sera instantanément révélez-le comme un dépensier. 10 VER : Le vérificateur vérifie la signature en appliquant les transformations inverses : ( L' je = riG + ciPi R' je = riHp(Pi) + ciI Enfin, le vérificateur vérifie si nP je = 0 ci ?= Hs(m, L′ 0, . . . , L' n, R′ 0, . . . , R' n) modèle l Si cette égalité est correcte, le vérificateur exécute l'algorithme LNK. Sinon, le vérificateur rejette la signature. LNK : le vérificateur vérifie si I a été utilisé dans des signatures antérieures (ces valeurs sont stockées dans le définir I). Des utilisations multiples impliquent que deux signatures ont été produites sous la même clé secrète. Le sens du protocole : en appliquant des L-transformations le signataire prouve qu'il sait tel x qu'au moins un Pi = xG. Pour rendre cette preuve non répétable, nous introduisons l'image clé comme je = xHp(P). Le signataire utilise les mêmes coefficients (ri, ci) pour prouver presque la même affirmation : il connaît x tel qu'au moins un \(H_p(P_i) = I \cdot x^{-1}\). Si l'application \(x \to I\) est une injection : 1. Personne ne peut récupérer la clé publique à partir de l’image de clé et identifier le signataire ; 2. Le signataire ne peut pas faire deux signatures avec des I différents et le même x. Une analyse de sécurité complète est fournie à l’Annexe A. 4.5 Transaction CryptoNote standard En combinant les deux méthodes (clés publiques non liées et signature en anneau introuvable), Bob obtient nouveau niveau de confidentialité par rapport au programme Bitcoin original. Cela lui impose de stocker uniquement une clé privée (a, b) et publier (A, B) pour commencer à recevoir et à envoyer des transactions anonymes. Lors de la validation de chaque transaction, Bob effectue en outre uniquement deux multiplications de courbes elliptiques et une addition par sortie pour vérifier si une transaction lui appartient. Pour chacun de ses sortie Bob récupère une paire de clés unique (pi, Pi) et stil le met dans son portefeuille. Toutes les entrées peuvent être il est prouvé de manière circonstancielle qu'ils ont le même propriétaire seulement s'ils apparaissent dans une seule transaction. Dans En fait, cette relation est beaucoup plus difficile à établir en raison de la signature en anneau unique. Avec une signature en anneau, Bob peut efficacement cacher chaque entrée parmi celles de quelqu'un d'autre ; tout est possible les dépensiers seront équiprobables, même le propriétaire précédent (Alice) n'a pas plus d'informations que tout observateur. Lors de la signature de sa transaction, Bob précise n sorties étrangères du même montant que son sortie, en les mélangeant tous sans la participation d’autres utilisateurs. Bob lui-même (ainsi que quelqu'un d'autre) ne sait pas si l'un de ces paiements a été dépensé : un résultat peut être utilisé dans des milliers de signatures comme facteur d'ambiguïté et jamais comme cible de dissimulation. Le doublé Le contrôle des dépenses a lieu dans la phase LNK lors de la vérification par rapport à l'ensemble d'images clés utilisé. Bob peut choisir lui-même le degré d'ambiguïté : n = 1 signifie que la probabilité qu'il ait dépensé, la sortie est de 50 % de probabilité, n = 99 donne 1 %. La taille de la signature résultante augmente linéairement comme O(n+1), donc l'anonymat amélioré coûte à Bob des frais de transaction supplémentaires. Il peut aussi définissez n = 0 et faites en sorte que sa signature en anneau soit composée d'un seul élément, mais cela sera instantanément révélez-le comme un dépensier. 10 19 À ce stade, je suis terriblement confus. Alex reçoit un message M avec signature (I,c_1, ..., c_n, r_1, ..., r_n) et liste des publics touches S. et elle exécute VER. Cela calculera L_i' et R_i' Cela vérifie que c_s = c - sum_i neq s c_i sur la page précédente. Au début, j’étais TRÈS (ha) confus. N’importe qui peut calculer L_i’ et R_i’. En effet, chaque r_i et c_i ont été publiés dans la signature sigma avec la valeur de I. L'ensemble S = P_i de toutes les clés publiques a également été publié. Donc, quiconque a vu Sigma et l'ensemble des les clés S = P_i obtiendront les mêmes valeurs pour L_i' et R_i' et vérifieront donc la signature. Mais ensuite je me suis souvenu que cette section décrivait simplement un algorithme de signature, pas un « contrôle » si signé, vérifiez s'il M'EST ENVOYÉ, et si c'est le cas, allez dépenser l'argent." C'est SIMPLEMENT le partie emblématique du jeu. J’ai hâte de lire l’Annexe A lorsque j’y serai enfin. J'aimerais voir une comparaison opération par opération à grande échelle de Cryptonote à Bitcoin. Aussi, électricité/durabilité. Quels éléments des algorithmes constituent ici une « entrée » ? L'entrée de transaction, je crois, est un montant et un ensemble de UTXO dont la somme est supérieure à celle du montant. Montant. Ce n’est pas clair. « Cible de la cachette ? J'y réfléchis depuis quelques minutes maintenant et je n'ai toujours pas le idée la plus floue de ce que cela pourrait signifier. Une attaque à double dépense ne peut être exécutée qu’en manipulant la clé utilisée perçue par un nœud. ensemble d'images \(I\). "Degré d'ambiguïté" = n mais le nombre total de clés publiques incluses dans la transaction est n+1. C'est-à-dire que le degré d'ambiguïté serait "combien d'AUTRES personnes voulez-vous dans la foule ?" La réponse sera probablement, par défaut, « autant que possible ».

VER : Le vérificateur vérifie la signature en appliquant les transformations inverses : ( L' je = riG + ciPi R' je = riHp(Pi) + ciI Enfin, le vérificateur vérifie si nP je = 0 ci ?= Hs(m, L′ 0, . . . , L' n, R′ 0, . . . , R' n) modèle l Si cette égalité est correcte, le vérificateur exécute l'algorithme LNK. Sinon, le vérificateur rejette la signature. LNK : le vérificateur vérifie si I a été utilisé dans des signatures antérieures (ces valeurs sont stockées dans le définir I). Des utilisations multiples impliquent que deux signatures ont été produites sous la même clé secrète. Le sens du protocole : en appliquant des L-transformations le signataire prouve qu'il sait tel x qu'au moins un Pi = xG. Pour rendre cette preuve non répétable, nous introduisons l'image clé comme je = xHp(P). Le signataire utilise les mêmes coefficients (ri, ci) pour prouver presque la même affirmation : il connaît x tel qu'au moins un \(H_p(P_i) = I \cdot x^{-1}\). Si l'application \(x \to I\) est une injection : 1. Personne ne peut récupérer la clé publique à partir de l’image de clé et identifier le signataire ; 2. Le signataire ne peut pas faire deux signatures avec des I différents et le même x. Une analyse de sécurité complète est fournie à l’Annexe A. 4.5 Transaction CryptoNote standard En combinant les deux méthodes (clés publiques non liées et signature en anneau introuvable), Bob obtient nouveau niveau de confidentialité par rapport au programme Bitcoin original. Cela lui impose de stocker uniquement une clé privée (a, b) et publier (A, B) pour commencer à recevoir et à envoyer des transactions anonymes. Lors de la validation de chaque transaction, Bob effectue en outre uniquement deux multiplications de courbes elliptiques et une addition par sortie pour vérifier si une transaction lui appartient. Pour chacun de ses sortie Bob récupère une paire de clés à usage unique (pi, Pi) et la stocke dans son portefeuille. Toutes les entrées peuvent être il est prouvé de manière circonstancielle qu'ils ont le même propriétaire seulement s'ils apparaissent dans une seule transaction. Dans En fait, cette relation est beaucoup plus difficile à établir en raison de la signature en anneau unique. Avec une signature en anneau, Bob peut efficacement cacher chaque entrée parmi celles de quelqu'un d'autre ; tout est possible les dépensiers seront équiprobables, même le propriétaire précédent (Alice) n'a pas plus d'informations que tout observateur. Lors de la signature de sa transaction, Bob précise n sorties étrangères du même montant que son sortie, en les mélangeant tous sans la participation d’autres utilisateurs. Bob lui-même (ainsi que quelqu'un d'autre) ne sait pas si l'un de ces paiements a été dépensé : un résultat peut être utilisé dans des milliers de signatures comme facteur d'ambiguïté et jamais comme cible de dissimulation. Le doublé Le contrôle des dépenses a lieu dans la phase LNK lors de la vérification par rapport à l'ensemble d'images clés utilisé. Bob peut choisir lui-même le degré d'ambiguïté : n = 1 signifie que la probabilité qu'il ait dépensé, la sortie est de 50 % de probabilité, n = 99 donne 1 %. La taille de la signature résultante augmente linéairement comme O(n+1), donc l'anonymat amélioré coûte à Bob des frais de transaction supplémentaires. Il peut aussi définissez n = 0 et faites en sorte que sa signature en anneau soit composée d'un seul élément, mais cela sera instantanément révélez-le comme un dépensier. 10 VER : Le vérificateur vérifie la signature en appliquant les transformations inverses : ( L' je = riG + ciPi R' je = riHp(Pi) + ciI Enfin, le vérificateur vérifie si nP je = 0 ci ?= Hs(m, L′ 0, . . . , L' n, R′ 0, . . . , R' n) modèle l Si cette égalité est correcte, le vérificateur exécute l'algorithme LNK. Sinon, le vérificateur rejette la signature. LNK : le vérificateur vérifie si I a été utilisé dans des signatures antérieures (ces valeurs sont stockées dans le définir I). Des utilisations multiples impliquent que deux signatures ont été produites sous la même clé secrète. Le sens du protocole : en appliquant des L-transformations le signataire prouve qu'il sait tel x qu'au moins un Pi = xG. Pour rendre cette preuve non répétable, nous introduisons l'image clé comme je = xHp(P). Le signataire utilise les mêmes coefficients (ri, ci) pour prouver presque la même affirmation : il connaît x tel qu'au moins un \(H_p(P_i) = I \cdot x^{-1}\). Si l'application \(x \to I\) est une injection : 1. Personne ne peut récupérer la clé publique à partir de l’image de clé et identifier le signataire ; 2. Le signataire ne peut pas faire deux signatures avec des I différents et le même x. Une analyse de sécurité complète est fournie à l’Annexe A. 4.5 Transaction CryptoNote standard En combinant les deux méthodes (clés publiques non liées et signature en anneau introuvable), Bob obtient nouveau niveau de confidentialité par rapport au programme Bitcoin original. Cela lui impose de stocker uniquement une clé privée (a, b) et publier (A, B) pour commencer à recevoir et à envoyer des transactions anonymes. Lors de la validation de chaque transaction, Bob effectue en outre uniquement deux multiplications de courbes elliptiques et une addition par sortie pour vérifier si une transaction lui appartient. Pour chacun de ses sortie Bob récupère une paire de clés unique (pi, Pi) et stil le met dans son portefeuille. Toutes les entrées peuvent être il est prouvé de manière circonstancielle qu'ils ont le même propriétaire seulement s'ils apparaissent dans une seule transaction. Dans En fait, cette relation est beaucoup plus difficile à établir en raison de la signature en anneau unique. Avec une signature en anneau, Bob peut efficacement cacher chaque entrée parmi celles de quelqu'un d'autre ; tout est possible les dépensiers seront équiprobables, même le propriétaire précédent (Alice) n'a pas plus d'informations que tout observateur. Lors de la signature de sa transaction, Bob précise n sorties étrangères du même montant que son sortie, en les mélangeant tous sans la participation d’autres utilisateurs. Bob lui-même (ainsi que quelqu'un d'autre) ne sait pas si l'un de ces paiements a été dépensé : un résultat peut être utilisé dans des milliers de signatures comme facteur d'ambiguïté et jamais comme cible de dissimulation. Le doublé Le contrôle des dépenses a lieu dans la phase LNK lors de la vérification par rapport à l'ensemble d'images clés utilisé. Bob peut choisir lui-même le degré d'ambiguïté : n = 1 signifie que la probabilité qu'il ait dépensé, la sortie est de 50 % de probabilité, n = 99 donne 1 %. La taille de la signature résultante augmente linéairement comme O(n+1), donc l'anonymat amélioré coûte à Bob des frais de transaction supplémentaires. Il peut aussi définissez n = 0 et faites en sorte que sa signature en anneau soit composée d'un seul élément, mais cela sera instantanément révélez-le comme un dépensier. 10 20 C'est intéressant ; plus tôt, nous avons fourni un moyen pour un récepteur, Bob, de transmettre tous les messages ENTRANTS transactions non dissociables soit en choisissant la moitié de ses clés privées de manière déterministe, soit en publier la moitié de ses clés privées comme publiques. Il s’agit d’une politique de non-retour. Ici, nous voyons une façon pour un expéditeur, Alex, de choisir une seule transaction sortante comme pouvant être liée, mais en fait ceci révèle Alex comme l'expéditeur de l'ensemble du réseau. Il ne s’agit PAS d’une politique sans retour en arrière. Il s'agit d'une transaction par transaction. Existe-t-il une troisième politique ? Un destinataire, Bob, peut-il générer un identifiant de paiement unique pour Alex qui ne change jamais, peut-être en utilisant un échange Diffie-Hellman ? Si quelqu'un inclut ce paiement Une pièce d'identité fournie quelque part dans sa transaction à l'adresse de Bob, elle doit provenir d'Alex. De cette façon, Alex n'a pas besoin de se révéler à l'ensemble du réseau en choisissant de lier un transaction, mais elle peut toujours s'identifier auprès de la personne à qui elle envoie son argent. N'est-ce pas ce que fait Poloniex ?

Transaction Entrée d'émission Sortie0 . . . Sortiei . . . Sortie Image clé Signature Signature de la bague Clé de destination Sortie1 Clé de destination Sortie Opérations à l'étranger Résultat de l'expéditeur Clé de destination Paire de clés à usage unique Une fois clé privée je = xHp(P) P, x Fig. 7. Génération de signature en anneau dans une transaction standard. 5 Preuve de travail égalitaire Dans cette section, nous proposons et mettons à la terre le nouvel algorithme proof-of-work. Notre objectif premier est de réduire l’écart entre les mineurs CPU (majoritaires) et GPU/FPGA/ASIC (minoritaires). C'est Il est approprié que certains utilisateurs puissent avoir un certain avantage sur d'autres, mais leurs investissements devrait croître au moins linéairement avec la puissance. Plus généralement, produire des appareils spécialisés doit être le moins rentable possible. 5.1 Œuvres connexes Le protocole Bitcoin proof-of-work d'origine utilise la fonction de tarification gourmande en CPU SHA-256. Il se compose principalement d'opérateurs logiques de base et repose uniquement sur la vitesse de calcul de processeur, est donc parfaitement adapté à la mise en œuvre multicœur/convoyeur. Cependant, les ordinateurs modernes ne sont pas limités uniquement par le nombre d'opérations par seconde, mais aussi par taille de mémoire. Bien que certains processeurs puissent être nettement plus rapides que d'autres [8], les tailles de mémoire sont moins susceptibles de varier entre les machines. Les fonctions de prix liées à la mémoire ont été introduites pour la première fois par Abadi et al et ont été définies comme « fonctions dont le temps de calcul est dominé par le temps passé à accéder à la mémoire » [15]. L’idée principale est de construire un algorithme allouant un gros bloc de données (« scratchpad ») dans une mémoire accessible relativement lentement (par exemple, la RAM) et « l’accès à un séquence imprévisible d'emplacements »à l'intérieur. Un bloc doit être suffisamment grand pour permettre la conservation les données plus avantageuses que de les recalculer pour chaque accès. L'algorithme devrait également empêcher le parallélisme interne, donc N threads simultanés devraient nécessiter N fois plus de mémoire à la fois. Dwork et al [22] ont étudié et formalisé cette approche les amenant à suggérer une autre variante de la fonction de tarification : « Mbound ». Une autre œuvre appartient à F. Coelho [20], qui 11 Transaction Entrée d'émission Sortie0 . . . Sortiei . . . Sortie Image clé Signature Signature de la bague Clé de destination Sortie1 Clé de destination Sortie Opérations à l'étranger Résultat de l'expéditeur Clé de destination Paire de clés à usage unique Une fois clé privée je = xHp(P) P, x Fig. 7. Génération de signature en anneau dans une transaction standard. 5 Preuve de travail égalitaire Dans cette section, nous proposons et mettons à la terre le nouvel algorithme proof-of-work. Notre objectif premier est de réduire l’écart entre les mineurs CPU (majoritaires) et GPU/FPGA/ASIC (minoritaires). C'est Il est approprié que certains utilisateurs puissent avoir un certain avantage sur d'autres, mais leurs investissements devrait croître au moins linéairement avec la puissance. Plus généralement, produire des appareils spécialisés doit être le moins rentable possible. 5.1 Œuvres connexes Le protocole Bitcoin proof-of-work d'origine utilise la fonction de tarification gourmande en CPU SHA-256. Il se compose principalement d'opérateurs logiques de base et repose uniquement sur la vitesse de calcul de processeur, est donc parfaitement adapté à la mise en œuvre multicœur/convoyeur. Cependant, les ordinateurs modernes ne sont pas limités uniquement par le nombre d'opérations par seconde, mais aussi par taille de mémoire. Bien que certains processeurs puissent être nettement plus rapides que d'autres [8], les tailles de mémoire sont moins susceptibles de varier entre les machines. Les fonctions de prix liées à la mémoire ont été introduites pour la première fois par Abadi et al et ont été définies comme « fonctions dont le temps de calcul est dominé par le temps passé à accéder à la mémoire » [15]. L’idée principale est de construire un algorithme allouant un gros bloc de données (« scratchpad ») dans une mémoire accessible relativement lentement (par exemple, la RAM) et « l’accès à un séquence imprévisible d'emplacements »à l'intérieur. Un bloc doit être suffisamment grand pour permettre la conservation les données plus avantageuses que de les recalculer pour chaque accès. L'algorithme devrait également empêcher le parallélisme interne, donc N threads simultanés devraient nécessiter N fois plus de mémoire à la fois. Dwork et al [22] ont étudié et formalisé cette approche les amenant à suggérer une autre variante de la fonction de tarification : « Mbound ». Une autre œuvre appartient à F. Coelho [20], qui 11 21 Ce sont apparemment nos UTXO : montants et clés de destination. Si Alex est celui qui construit cette transaction standard et l'envoie à Bob, alors Alex possède également les clés privées à chacun d'eux. J'aime beaucoup ce diagramme, car il répond à certaines questions précédentes. Une entrée Txn consiste d'un ensemble de sorties Txn et d'un kevotre image. Il est ensuite signé d'une signature en anneau, comprenant tous des clés privées qu'Alex possède pour toutes les transactions étrangères incluses dans la transaction. Le La sortie Txn se compose d’un montant et d’une clé de destination. Le destinataire de la transaction peut, à volonté, génèrent leur clé privée unique comme décrit précédemment dans le document afin de dépenser l'argent. Ce sera ravi de découvrir à quel point cela correspond au code réel... Non, Nic van Saberhagen décrit vaguement certaines propriétés d'un algorithme de preuve de travail, sans réellement décrire cet algorithme. L'algorithme CryptoNight lui-même EXIGERA une analyse approfondie. Quand j'ai lu ceci, j'ai bégayé. Les investissements devraient-ils croître au moins de façon linéaire avec le pouvoir, ou les investissements augmentent au plus linéairement avec le pouvoir ? Et puis j'ai réalisé ; En tant que mineur ou investisseur, je pense généralement à « quelle puissance puis-je obtenir ? pour un investissement ?" et non « combien d'investissement est nécessaire pour une quantité d'énergie fixée ? » Bien sûr, on note l'investissement par I et le pouvoir par P. Si I(P) est l'investissement en fonction du pouvoir et P(I) est la puissance en fonction de l’investissement, ils seront inverses l’un de l’autre (partout où des inverses peuvent exister). Et si I(P) est plus rapide que linéaire, alors P(I) est plus lent que linéaire. Par conséquent, le taux de rendement pour les investisseurs sera réduit. C'est-à-dire que ce que dit ici l'auteur est : « bien sûr, plus vous investissez, plus vous obtiendrez plus ». pouvoir. Mais nous devrions essayer d’en faire un taux de rendement réduit. » Les investissements en CPU finiront par plafonner de manière sublinéaire ; la question est de savoir si les auteurs ont conçu un algorithme POW qui obligera les ASIC à le faire également. Une hypothétique « monnaie du futur » devrait-elle toujours exploiter les ressources les plus lentes/les plus limitées ? L'article d'Abadi et al (dont les auteurs sont des ingénieurs de Google et de Microsoft) est le suivant : essentiellement, en utilisant le fait que ces dernières années la taille de la mémoire a été beaucoup plus petite différence entre les machines que la vitesse du processeur, et avec un rapport investissement/puissance plus que linéaire. Dans quelques années, il faudra peut-être réévaluer cela ! Tout est une course aux armements... Construire une fonction hash est difficile ; construire une fonction hash satisfaisant ces contraintes semble plus difficile. Cet article ne semble contenir aucune explication sur la réalité hashing algorithme CryptoNight. Je pense que c'est une implémentation de SHA-3 gourmande en mémoire, basée sur sur les messages du forum mais je n'en ai aucune idée... et c'est le point. Il faut l'expliquer.

a proposé la solution la plus efficace : « Hokkaido ». A notre connaissance le dernier travail basé sur l'idée de recherches pseudo-aléatoires dans un grand tableau est l'algorithme dit « scrypt » de C. Percival [32]. Contrairement aux fonctions précédentes, il se concentre sur dérivation de clé, et non les systèmes proof-of-work. Malgré ce fait, scrypt peut servir notre objectif : cela fonctionne bien comme fonction de tarification dans le problème de conversion partiel hash tel que SHA-256 dans Bitcoin. À présent, scrypt a déjà été appliqué dans Litecoin [14] et dans quelques autres forks Bitcoin. Cependant, sa mise en œuvre n'est pas vraiment liée à la mémoire : le rapport « temps d'accès mémoire / global » time » n’est pas assez grand car chaque instance n’utilise que 128 Ko. Cela permet aux mineurs GPU être environ 10 fois plus efficace et continue de laisser la possibilité de créer relativement des appareils miniers bon marché mais très efficaces. De plus, la construction du scrypt elle-même permet un compromis linéaire entre la taille de la mémoire et Vitesse du processeur due au fait que chaque bloc du bloc-notes est dérivé uniquement du précédent. Par exemple, vous pouvez stocker un bloc sur deux et recalculer les autres de manière paresseuse, c'est-à-dire uniquement quand cela devient nécessaire. Les indices pseudo-aléatoires sont supposés être uniformément distribués, donc la valeur attendue des recalculs des blocs supplémentaires est 1 \(2 \cdot N\), où N est le nombre d'itérations. Le temps de calcul global augmente de moins de moitié car il y a aussi opérations indépendantes du temps (temps constant) telles que la préparation du bloc-notes et le hashing sur chaque itération. Économiser 2/3 des coûts de mémoire 1 \(3 \cdot N\) + 1 3 \(\cdot\) \(2 \cdot N\) = N recalculs supplémentaires ; 9/10 résultats en 1 \(10 \cdot N\) + . . . + 1 \(10 \cdot 9 \cdot N\) = 4,5N. Il est facile de montrer que stocker seulement 1 s de tous les blocs augmente le temps moins que d'un facteur s−1 2 . Cela implique à son tour qu'une machine dotée d'un processeur 200 fois plus rapide que les puces modernes, elles ne peuvent stocker que 320 octets du bloc-notes. 5.2 L'algorithme proposé Nous proposons un nouvel algorithme lié à la mémoire pour la fonction de tarification proof-of-work. Cela repose sur accès aléatoire à une mémoire lente et met l'accent sur la dépendance à la latence. Contrairement à crypter chaque le nouveau bloc (d’une longueur de 64 octets) dépend de tous les blocs précédents. En conséquence, une hypothétique « économiseur de mémoire » devrait augmenter sa vitesse de calcul de manière exponentielle. Notre algorithme nécessite environ 2 Mo par instance pour les raisons suivantes : 1. Il s'intègre dans le cache L3 (par cœur) des processeurs modernes, qui devraient devenir courants dans quelques années ; 2. Un mégaoctet de mémoire interne est une taille presque inacceptable pour un pipeline ASIC moderne ; 3. Les GPU peuvent exécuter des centaines d’instances simultanées, mais ils sont limités par d’autres moyens : La mémoire GDDR5 est plus lente que le cache CPU L3 et remarquable par sa bande passante, non vitesse d'accès aléatoire. 4. Une expansion significative du bloc-notes nécessiterait une augmentation du nombre d'itérations, ce qui en le tour implique une augmentation globale du temps. Les appels « lourds » dans un réseau p2p sans confiance peuvent conduire à de graves vulnérabilités, car les nœuds sont obligés de vérifier le proof-of-work de chaque nouveau bloc. Si un nœud passe beaucoup de temps sur chaque évaluation hash, il peut facilement être DDoSed par un flot de faux objets avec des données de travail arbitraires (valeurs nonce). 12 a proposé la solution la plus efficace : « Hokkaido ». A notre connaissance le dernier travail basé sur l'idée de recherches pseudo-aléatoires dans un grand tableau est l'algorithme dit « scrypt » de C. Percival [32]. Contrairement aux fonctions précédentes, il se concentre sur dérivation de clé, et non les systèmes proof-of-work. Malgré ce fait, scrypt peut servir notre objectif : cela fonctionne bien comme fonction de tarification dans le problème de conversion partiel hash tel que SHA-256 dans Bitcoin. À présent, scrypt a déjà été appliqué dans Litecoin [14] et dans quelques autres forks Bitcoin. Cependant, sa mise en œuvre n'est pas vraiment liée à la mémoire : le rapport « temps d'accès mémoire / global » time » n’est pas assez grand car chaque instance n’utilise que 128 Ko. Cela permet aux mineurs GPU être environ 10 fois plus efficace et continue de laisser la possibilité de créer relativement des appareils miniers bon marché mais très efficaces. De plus, la construction du scrypt elle-même permet un compromis linéaire entre la taille de la mémoire et Vitesse du processeur due au fait que chaque bloc du bloc-notes est dérivé uniquement du précédent. Par exemple, vous pouvez stocker un bloc sur deux et recalculer les autres de manière paresseuse, c'est-à-dire uniquement quand cela devient nécessaire. Les indices pseudo-aléatoires sont supposés être uniformément distribués, donc la valeur attendue des recalculs des blocs supplémentaires est 1 \(2 \cdot N\), oùN est le nombre d'itérations. Le temps de calcul global augmente de moins de moitié car il y a aussi opérations indépendantes du temps (temps constant) telles que la préparation du bloc-notes et le hashing sur chaque itération. Économiser 2/3 des coûts de mémoire 1 \(3 \cdot N\) + 1 3 \(\cdot\) \(2 \cdot N\) = N recalculs supplémentaires ; 9/10 résultats en 1 \(10 \cdot N\) + . . . + 1 \(10 \cdot 9 \cdot N\) = 4,5N. Il est facile de montrer que stocker seulement 1 s de tous les blocs augmente le temps moins que d'un facteur s−1 2 . Cela implique à son tour qu'une machine dotée d'un processeur 200 fois plus rapide que les puces modernes, elles ne peuvent stocker que 320 octets du bloc-notes. 5.2 L'algorithme proposé Nous proposons un nouvel algorithme lié à la mémoire pour la fonction de tarification proof-of-work. Cela repose sur accès aléatoire à une mémoire lente et met l'accent sur la dépendance à la latence. Contrairement à crypter chaque le nouveau bloc (d’une longueur de 64 octets) dépend de tous les blocs précédents. En conséquence, une hypothétique « économiseur de mémoire » devrait augmenter sa vitesse de calcul de manière exponentielle. Notre algorithme nécessite environ 2 Mo par instance pour les raisons suivantes : 1. Il s'intègre dans le cache L3 (par cœur) des processeurs modernes, qui devraient devenir courants dans quelques années ; 2. Un mégaoctet de mémoire interne est une taille presque inacceptable pour un pipeline ASIC moderne ; 3. Les GPU peuvent exécuter des centaines d’instances simultanées, mais ils sont limités par d’autres moyens : La mémoire GDDR5 est plus lente que le cache CPU L3 et remarquable par sa bande passante, non vitesse d'accès aléatoire. 4. Une expansion significative du bloc-notes nécessiterait une augmentation du nombre d'itérations, ce qui en le tour implique une augmentation globale du temps. Les appels « lourds » dans un réseau p2p sans confiance peuvent conduire à vulnérabilités graves, car les nœuds sont obligés de vérifier le proof-of-work de chaque nouveau bloc. Si un nœud passe beaucoup de temps sur chaque évaluation hash, il peut facilement être DDoSed par un flot de faux objets avec des données de travail arbitraires (valeurs nonce). 12 22 Peu importe, c’est une pièce secrète ? Où est l'algorithme ? Tout ce que je vois, c'est une publicité. C’est là que Cryptonote, si son algorithme PoW en vaut la peine, brillera vraiment. Ce n'est pas vraiment SHA-256, ce n'est pas vraiment un scrypt. C’est nouveau, lié à la mémoire et non récursif.

6 Autres avantages 6.1 Émission douce La limite supérieure du montant total des pièces numériques CryptoNote est : MSupply = 264 −1 unités atomiques. Il s'agit d'une restriction naturelle basée uniquement sur les limites de mise en œuvre, et non sur l'intuition. comme « Les pièces N devraient suffire à tout le monde ». Pour garantir la fluidité du processus d'émission, nous utilisons la formule suivante pour le bloc récompenses : BaseReward = (MSupply −A) ≫18, où A est le nombre de pièces précédemment générées. 6.2 Paramètres réglables 6.2.1 Difficulté CryptoNote contient un algorithme de ciblage qui modifie la difficulté de chaque bloc. Ceci diminue le temps de réaction du système lorsque le réseau hashrate croît ou diminue intensément, en préservant un taux de bloc constant. La méthode originale Bitcoin calcule la relation entre le réel et cibler l'intervalle de temps entre les derniers blocs de 2016 et l'utilise comme multiplicateur pour le courant difficulté. Cela ne convient évidemment pas aux recalculs rapides (en raison de la grande inertie) et entraîne des oscillations. L'idée générale derrière notre algorithme est de résumer tout le travail effectué par les nœuds et divisez-le par le temps qu'ils ont passé. La mesure du travail est constituée des valeurs de difficulté correspondantes dans chaque bloc. Mais en raison d'horodatages inexacts et peu fiables, nous ne pouvons pas déterminer l'heure exacte. intervalle de temps entre les blocs. Un utilisateur peut décaler son horodatage dans le futur et la prochaine fois les intervalles peuvent être incroyablement petits, voire négatifs. Vraisemblablement, il y aura peu d'incidents de ce type, nous pouvons donc simplement trier les horodatages et supprimer les valeurs aberrantes (c'est-à-dire 20 %). La gamme de les valeurs de repos sont le temps qui a été passé pour 80% des blocs correspondants. 6.2.2 Limites de taille Les utilisateurs paient pour stocker le blockchain et ont le droit de voter pour sa taille. Chaque mineur traite du compromis entre l'équilibrage des coûts et le profit des frais et fixe ses propres « soft-limit » pour créer des blocs. La règle de base concernant la taille maximale des blocs est également nécessaire pour empêchant le blockchain d'être inondé de fausses transactions, cependant cette valeur devrait ne pas être codé en dur. Soit MN la valeur médiane des N dernières tailles de blocs. Ensuite, la « limite stricte » pour la taille de blocs accepteurs est de \(2 \cdot M_N\). Il évite les ballonnements au blockchain tout en permettant à la limite de grandir lentement avec le temps si nécessaire. La taille des transactions n’a pas besoin d’être limitée explicitement. Il est délimité par la taille d’un bloc ; et si quelqu'un veut créer une énorme transaction avec des centaines d'entrées/sorties (ou avec le degré élevé d'ambiguïté des signatures en anneau), il peut le faire en payant des frais suffisants. 6.2.3 Pénalité de taille excédentaire Un mineur a toujours la possibilité de remplir un bloc de ses propres transactions sans frais jusqu'à son maximum. taille 2 \(\cdot\) Mo. Même si seule la majorité des mineurs peuvent modifier la valeur médiane, il existe toujours un 13 6 Autres avantages 6.1 Émission douce La limite supérieure du montant total des pièces numériques CryptoNote est : MSupply = 264 −1 unités atomiques. Il s'agit d'une restriction naturelle basée uniquement sur les limites de mise en œuvre, et non sur l'intuition. comme « Les pièces N devraient suffire à tout le monde ». Pour garantir la fluidité du processus d'émission, nous utilisons la formule suivante pour le bloc récompenses : BaseReward = (MSupply −A) ≫18, où A est le nombre de pièces précédemment générées. 6.2 Paramètres réglables 6.2.1 Difficulté CryptoNote contient un algorithme de ciblage qui modifie la difficulté de chaque bloc. Ceci diminue le temps de réaction du système lorsque le réseau hashrate croît ou diminue intensément, en préservant un taux de bloc constant. La méthode originale Bitcoin calcule la relation entre le réel et cibler l'intervalle de temps entre les derniers blocs de 2016 et l'utilise comme multiplicateur pour le courant difficulté. Cela ne convient évidemment pas aux recalculs rapides (en raison de la grande inertie) et entraîne des oscillations. L'idée générale derrière notre algorithme est de résumer tout le travail effectué par les nœuds et divisez-le par le temps qu'ils ont passé. La mesure du travail est constituée des valeurs de difficulté correspondantes dans chaque bloc. Mais en raison d'horodatages inexacts et peu fiables, nous ne pouvons pas déterminer l'heure exacte. intervalle de temps entre les blocs. Un utilisateur peut décaler son horodatage dans le futur et la prochaine fois les intervalles peuvent être incroyablement petits, voire négatifs. Vraisemblablement, il y aura peu d'incidents de ce type, nous pouvons donc simplement trier les horodatages et supprimer les valeurs aberrantes (c'est-à-dire 20 %). La gamme de les valeurs de repos sont le temps qui a été passé pour 80% des blocs correspondants. 6.2.2 Limites de taille Les utilisateurs paient pour stocker le blockchain et ont le droit de voter pour sa taille. Chaque mineur traite du compromis entre l’équilibrage dese coûte et profite des honoraires et fixe les siens « soft-limit » pour créer des blocs. La règle de base concernant la taille maximale des blocs est également nécessaire pour empêchant le blockchain d'être inondé de fausses transactions, cependant cette valeur devrait ne pas être codé en dur. Soit MN la valeur médiane des N dernières tailles de blocs. Ensuite, la « limite stricte » pour la taille de blocs accepteurs est de \(2 \cdot M_N\). Il évite les ballonnements au blockchain tout en permettant à la limite de grandir lentement avec le temps si nécessaire. La taille des transactions n’a pas besoin d’être limitée explicitement. Il est délimité par la taille d’un bloc ; et si quelqu'un veut créer une énorme transaction avec des centaines d'entrées/sorties (ou avec le degré élevé d'ambiguïté des signatures en anneau), il peut le faire en payant des frais suffisants. 6.2.3 Pénalité de taille excédentaire Un mineur a toujours la possibilité de remplir un bloc de ses propres transactions sans frais jusqu'à son maximum. taille 2 \(\cdot\) Mo. Même si seule la majorité des mineurs peuvent modifier la valeur médiane, il existe toujours un 13 23 Unités atomiques. J'aime ça. Est-ce l'équivalent des Satoshis ? Si tel est le cas, cela signifie qu’il y aura 185 milliards de cryptonotes. Je sais que cela doit éventuellement être modifié en quelques pages, ou peut-être y a-t-il une faute de frappe ? Si la récompense de base est « toutes les pièces restantes », alors un seul bloc suffit pour obtenir toutes les pièces. Instaminer. D'un autre côté, si l'on suppose que cela est proportionnel d'une manière ou d'une autre à la différence de temps entre maintenant et une date de fin de production de pièces de monnaie ? Ce serait avoir du sens. De plus, dans mon monde, deux signes plus grands que comme celui-ci signifient « bien plus grand que ». L'auteur est-il peut-être vouloir dire autre chose ? Si l'ajustement à la difficulté se produit à chaque bloc, alors un attaquant pourrait disposer d'une très grande ferme de ressources. les machines exploitent et s'éteignent à des intervalles de temps soigneusement choisis. Cela pourrait provoquer une explosion chaotique (ou un crash à zéro) en difficulté, si les formules d’ajustement de la difficulté ne sont pas correctement amorties. Sans doute que la méthode de Bitcoin est inadaptée aux recalculs rapides, mais la notion d'inertie dans ces systèmes devraient être prouvés et non tenus pour acquis. De plus, les oscillations Les difficultés de réseau ne constituent pas nécessairement un problème, à moins qu’elles n’entraînent des oscillations de paramètres ostensibles. l'approvisionnement en pièces de monnaie - et le fait d'avoir une difficulté évoluant très rapidement pourrait provoquer une « sur-correction ». Le temps passé, surtout sur un laps de temps court comme quelques minutes, sera proportionnel au « total nombre de blocs créés sur le réseau." La constante de proportionnalité va elle-même croître au fil du temps, probablement de façon exponentielle si le CN décolle. Il serait peut-être préférable d'ajuster simplement la difficulté pour conserver le "total des blocs créés sur le terrain". réseau depuis que le dernier bloc a été ajouté à la chaîne principale" dans une certaine valeur constante, ou avec variation limitée ou quelque chose comme ça. Si un algorithme adaptatif informatique facile à mettre en œuvre peut être déterminé, cela semblerait résoudre le problème. Mais ensuite, si nous utilisions cette méthode, quelqu'un possédant une grande ferme minière pourrait fermer sa ferme. pendant quelques heures, puis rallumez-le. Pendant les premiers blocs, cette ferme fera banque. Donc effectivement, cette méthode soulèverait un point intéressant : le minage devient (en moyenne) un perdre la partie sans retour sur investissement, d’autant plus que de plus en plus de personnes se connectent au réseau. Si la difficulté minière réseau très étroitement suivi hashrate, je doute d'une manière ou d'une autre que les gens exploiteraient autant qu'eux fais actuellement. Ou, d’un autre côté, au lieu de maintenir leurs fermes minières en activité 24 heures sur 24 et 7 jours sur 7, ils peuvent les transformer en allumé pendant 6 heures, éteint pendant 2, allumé pendant 6 heures, éteint pendant 2, ou quelque chose comme ça. Passez simplement à une autre pièce pendant quelques heures, attendez que les difficultés disparaissent, puis remontez à bord pour gagner ces quelques extras. des blocs de rentabilité à mesure que le réseau s’adapte. Et tu sais quoi ? C'est en fait probablement l'un des meilleurs scénarios miniers auxquels j'ai pensé... Cela pourrait être circulaire, mais si le temps de création du bloc est en moyenne d'environ une minute, pouvons-nous simplement utiliser le nombre de blocs comme indicateur du « temps passé ? »

6 Autres avantages 6.1 Émission douce La limite supérieure du montant total des pièces numériques CryptoNote est : MSupply = 264 −1 unités atomiques. Il s'agit d'une restriction naturelle basée uniquement sur les limites de mise en œuvre, et non sur l'intuition. comme « Les pièces N devraient suffire à tout le monde ». Pour garantir la fluidité du processus d'émission, nous utilisons la formule suivante pour le bloc récompenses : BaseReward = (MSupply −A) ≫18, où A est le nombre de pièces précédemment générées. 6.2 Paramètres réglables 6.2.1 Difficulté CryptoNote contient un algorithme de ciblage qui modifie la difficulté de chaque bloc. Ceci diminue le temps de réaction du système lorsque le réseau hashrate croît ou diminue intensément, en préservant un taux de bloc constant. La méthode originale Bitcoin calcule la relation entre le réel et cibler l'intervalle de temps entre les derniers blocs de 2016 et l'utilise comme multiplicateur pour le courant difficulté. Cela ne convient évidemment pas aux recalculs rapides (en raison de la grande inertie) et entraîne des oscillations. L'idée générale derrière notre algorithme est de résumer tout le travail effectué par les nœuds et divisez-le par le temps qu'ils ont passé. La mesure du travail est constituée des valeurs de difficulté correspondantes dans chaque bloc. Mais en raison d'horodatages inexacts et peu fiables, nous ne pouvons pas déterminer l'heure exacte. intervalle de temps entre les blocs. Un utilisateur peut décaler son horodatage dans le futur et la prochaine fois les intervalles peuvent être incroyablement petits, voire négatifs. Vraisemblablement, il y aura peu d'incidents de ce type, nous pouvons donc simplement trier les horodatages et supprimer les valeurs aberrantes (c'est-à-dire 20 %). La gamme de les valeurs de repos sont le temps qui a été passé pour 80% des blocs correspondants. 6.2.2 Limites de taille Les utilisateurs paient pour stocker le blockchain et ont le droit de voter pour sa taille. Chaque mineur traite du compromis entre l'équilibrage des coûts et le profit des frais et fixe ses propres « soft-limit » pour créer des blocs. La règle de base concernant la taille maximale des blocs est également nécessaire pour empêchant le blockchain d'être inondé de fausses transactions, cependant cette valeur devrait ne pas être codé en dur. Soit MN la valeur médiane des N dernières tailles de blocs. Ensuite, la « limite stricte » pour la taille de blocs accepteurs est de \(2 \cdot M_N\). Il évite les ballonnements au blockchain tout en permettant à la limite de grandir lentement avec le temps si nécessaire. La taille des transactions n’a pas besoin d’être limitée explicitement. Il est délimité par la taille d’un bloc ; et si quelqu'un veut créer une énorme transaction avec des centaines d'entrées/sorties (ou avec le degré élevé d'ambiguïté des signatures en anneau), il peut le faire en payant des frais suffisants. 6.2.3 Pénalité de taille excédentaire Un mineur a toujours la possibilité de remplir un bloc de ses propres transactions sans frais jusqu'à son maximum. taille 2 \(\cdot\) Mo. Même si seule la majorité des mineurs peuvent modifier la valeur médiane, il existe toujours un 13 6 Autres avantages 6.1 Émission douce La limite supérieure du montant total des pièces numériques CryptoNote est : MSupply = 264 −1 unités atomiques. Il s'agit d'une restriction naturelle basée uniquement sur les limites de mise en œuvre, et non sur l'intuition. comme « Les pièces N devraient suffire à tout le monde ». Pour garantir la fluidité du processus d'émission, nous utilisons la formule suivante pour le bloc récompenses : BaseReward = (MSupply −A) ≫18, où A est le nombre de pièces précédemment générées. 6.2 Paramètres réglables 6.2.1 Difficulté CryptoNote contient un algorithme de ciblage qui modifie la difficulté de chaque bloc. Ceci diminue le temps de réaction du système lorsque le réseau hashrate croît ou diminue intensément, en préservant un taux de bloc constant. La méthode originale Bitcoin calcule la relation entre le réel et cibler l'intervalle de temps entre les derniers blocs de 2016 et l'utilise comme multiplicateur pour le courant difficulté. Cela ne convient évidemment pas aux recalculs rapides (en raison de la grande inertie) et entraîne des oscillations. L'idée générale derrière notre algorithme est de résumer tout le travail effectué par les nœuds et divisez-le par le temps qu'ils ont passé. La mesure du travail est constituée des valeurs de difficulté correspondantes dans chaque bloc. Mais en raison d'horodatages inexacts et peu fiables, nous ne pouvons pas déterminer l'heure exacte. intervalle de temps entre les blocs. Un utilisateur peut décaler son horodatage dans le futur et la prochaine fois les intervalles peuvent être incroyablement petits, voire négatifs. Vraisemblablement, il y aura peu d'incidents de ce type, nous pouvons donc simplement trier les horodatages et supprimer les valeurs aberrantes (c'est-à-dire 20 %). La gamme de les valeurs de repos sont le temps qui a été passé pour 80% des blocs correspondants. 6.2.2 Limites de taille Les utilisateurs paient pour stocker le blockchain et ont le droit de voter pour sa taille. Chaque mineur traite du compromis entre l’équilibrage dese coûte et profite des honoraires et fixe les siens « soft-limit » pour créer des blocs. La règle de base concernant la taille maximale des blocs est également nécessaire pour empêchant le blockchain d'être inondé de fausses transactions, cependant cette valeur devrait ne pas être codé en dur. Soit MN la valeur médiane des N dernières tailles de blocs. Ensuite, la « limite stricte » pour la taille de blocs accepteurs est de \(2 \cdot M_N\). Il évite les ballonnements au blockchain tout en permettant à la limite de grandir lentement avec le temps si nécessaire. La taille des transactions n’a pas besoin d’être limitée explicitement. Il est délimité par la taille d’un bloc ; et si quelqu'un veut créer une énorme transaction avec des centaines d'entrées/sorties (ou avec le degré élevé d'ambiguïté des signatures en anneau), il peut le faire en payant des frais suffisants. 6.2.3 Pénalité de taille excédentaire Un mineur a toujours la possibilité de remplir un bloc de ses propres transactions sans frais jusqu'à son maximum. taille 2 \(\cdot\) Mo. Même si seule la majorité des mineurs peuvent modifier la valeur médiane, il existe toujours un 13 24 D'accord, nous avons donc un blockchain, et chaque bloc a des horodatages EN PLUS du simple fait d'être commandé. Cela a clairement été inséré simplement pour résoudre des difficultés d'ajustement, car les horodatages sont très peu fiable, comme mentionné. Sommes-nous autorisés à avoir des horodatages contradictoires dans la chaîne ? Si le bloc A précède le bloc B dans la chaîne et que tout est cohérent en termes de finances, mais le bloc A semble avoir été créé après le bloc B ? Parce que, peut-être, quelqu'un possédait une grande partie du réseau ? Est-ce que ça va ? Probablement parce que les finances ne sont pas en mauvais état. D'accord, donc je déteste cet arbitraire "seulement 80 % des blocages sont légitimes pour le blockchain principal" approche. C'était destiné à empêcher les menteurs de modifier leurs horodatages ? Mais maintenant, il ajoute une incitation pour tout le monde à mentir sur son horodatage et à simplement choisir la médiane. Veuillez définir. Cela signifie "pour ce bloc, n'inclure que les transactions qui incluent des frais supérieurs que p%, de préférence avec des frais supérieurs à 2p%" ou quelque chose comme ça ? Qu’entendent-ils par faux ? Si la transaction est conforme à l'historique du blockchain, et la transaction comprend des frais qui satisfont les mineurs, n'est-ce pas suffisant ? Eh bien, non, pas nécessairement. \(S'\)il n'existe aucune taille de bloc maximale, rien ne peut retenir un utilisateur malveillant du simple téléchargement d'un bloc massif de transactions sur lui-même en une seule fois juste pour ralentir le réseau. Une règle fondamentale concernant la taille maximale des blocs empêche les gens de mettre d'énormes quantités de déchets données sur le blockchain d'un seul coup juste pour ralentir les choses. Mais une telle règle doit certainement être adaptatif : pendant la période de Noël, par exemple, nous pourrions nous attendre à une augmentation du trafic, et la taille du bloc devient très grande, et immédiatement après, pour que la taille du bloc diminue par la suite encore une fois. Nous avons donc besoin soit a) d’une sorte de plafond adaptatif, soit b) d’un plafond suffisamment grand pour que 99 % des des pics de Noël raisonnables ne brisent pas le plafond. Bien sûr, ce deuxième est impossible à estimation – qui sait si une monnaie fera son chemin ? Mieux vaut le rendre adaptatif et ne pas s'inquiéter à ce sujet. Mais nous sommes alors confrontés à un problème de théorie du contrôle : comment rendre cela adaptatif sans vulnérabilité aux attaques ou oscillations sauvages et folles ? Notez qu'une méthode adaptative n'empêche pas les utilisateurs malveillants d'accumuler de petites sommes de données indésirables au fil du temps sur le blockchain pour provoquer un gonflement à long terme. C'est un problème différent dans l’ensemble et avec lequel les pièces cryptonotes ont de sérieux problèmes.

6 Autres avantages 6.1 Émission douce La limite supérieure du montant total des pièces numériques CryptoNote est : MSupply = 264 −1 unités atomiques. Il s'agit d'une restriction naturelle basée uniquement sur les limites de mise en œuvre, et non sur l'intuition. comme « Les pièces N devraient suffire à tout le monde ». Pour garantir la fluidité du processus d'émission, nous utilisons la formule suivante pour le bloc récompenses : BaseReward = (MSupply −A) ≫18, où A est le nombre de pièces précédemment générées. 6.2 Paramètres réglables 6.2.1 Difficulté CryptoNote contient un algorithme de ciblage qui modifie la difficulté de chaque bloc. Ceci diminue le temps de réaction du système lorsque le réseau hashrate croît ou diminue intensément, en préservant un taux de bloc constant. La méthode originale Bitcoin calcule la relation entre le réel et cibler l'intervalle de temps entre les derniers blocs de 2016 et l'utilise comme multiplicateur pour le courant difficulté. Cela ne convient évidemment pas aux recalculs rapides (en raison de la grande inertie) et entraîne des oscillations. L'idée générale derrière notre algorithme est de résumer tout le travail effectué par les nœuds et divisez-le par le temps qu'ils ont passé. La mesure du travail est constituée des valeurs de difficulté correspondantes dans chaque bloc. Mais en raison d'horodatages inexacts et peu fiables, nous ne pouvons pas déterminer l'heure exacte. intervalle de temps entre les blocs. Un utilisateur peut décaler son horodatage dans le futur et la prochaine fois les intervalles peuvent être incroyablement petits, voire négatifs. Vraisemblablement, il y aura peu d'incidents de ce type, nous pouvons donc simplement trier les horodatages et supprimer les valeurs aberrantes (c'est-à-dire 20 %). La gamme de les valeurs de repos sont le temps qui a été passé pour 80% des blocs correspondants. 6.2.2 Limites de taille Les utilisateurs paient pour stocker le blockchain et ont le droit de voter pour sa taille. Chaque mineur traite du compromis entre l'équilibrage des coûts et le profit des frais et fixe ses propres « soft-limit » pour créer des blocs. La règle de base concernant la taille maximale des blocs est également nécessaire pour empêchant le blockchain d'être inondé de fausses transactions, cependant cette valeur devrait ne pas être codé en dur. Soit MN la valeur médiane des N dernières tailles de blocs. Ensuite, la « limite stricte » pour la taille de blocs accepteurs est de \(2 \cdot M_N\). Il évite les ballonnements au blockchain tout en permettant à la limite de grandir lentement avec le temps si nécessaire. La taille des transactions n’a pas besoin d’être limitée explicitement. Il est délimité par la taille d’un bloc ; et si quelqu'un veut créer une énorme transaction avec des centaines d'entrées/sorties (ou avec le degré élevé d'ambiguïté des signatures en anneau), il peut le faire en payant des frais suffisants. 6.2.3 Pénalité de taille excédentaire Un mineur a toujours la possibilité de remplir un bloc de ses propres transactions sans frais jusqu'à son maximum. taille 2 \(\cdot\) Mo. Même si seule la majorité des mineurs peuvent modifier la valeur médiane, il existe toujours un 13 6 Autres avantages 6.1 Émission douce La limite supérieure du montant total des pièces numériques CryptoNote est : MSupply = 264 −1 unités atomiques. Il s'agit d'une restriction naturelle basée uniquement sur les limites de mise en œuvre, et non sur l'intuition. comme « Les pièces N devraient suffire à tout le monde ». Pour garantir la fluidité du processus d'émission, nous utilisons la formule suivante pour le bloc récompenses : BaseReward = (MSupply −A) ≫18, où A est le nombre de pièces précédemment générées. 6.2 Paramètres réglables 6.2.1 Difficulté CryptoNote contient un algorithme de ciblage qui modifie la difficulté de chaque bloc. Ceci diminue le temps de réaction du système lorsque le réseau hashrate augmente ou diminue intensément, en préservant un taux de bloc constant. La méthode originale Bitcoin calcule la relation entre le réel et cibler l'intervalle de temps entre les derniers blocs de 2016 et l'utilise comme multiplicateur pour le courant difficulté. Cela ne convient évidemment pas aux recalculs rapides (en raison de la grande inertie) et entraîne des oscillations. L'idée générale derrière notre algorithme est de résumer tout le travail effectué par les nœuds et divisez-le par le temps qu'ils ont passé. La mesure du travail est constituée des valeurs de difficulté correspondantes dans chaque bloc. Mais en raison d'horodatages inexacts et peu fiables, nous ne pouvons pas déterminer l'heure exacte. intervalle de temps entre les blocs. Un utilisateur peut décaler son horodatage dans le futur et la prochaine fois les intervalles peuvent être incroyablement petits, voire négatifs. Vraisemblablement, il y aura peu d'incidents de ce type, nous pouvons donc simplement trier les horodatages et supprimer les valeurs aberrantes (c'est-à-dire 20 %). La gamme de les valeurs de repos sont le temps qui a été passé pour 80% des blocs correspondants. 6.2.2 Limites de taille Les utilisateurs paient pour stocker le blockchain et ont le droit de voter pour sa taille. Chaque mineur traite du compromis entre l’équilibrage dese coûte et profite des honoraires et fixe les siens « soft-limit » pour créer des blocs. La règle de base concernant la taille maximale des blocs est également nécessaire pour empêchant le blockchain d'être inondé de fausses transactions, cependant cette valeur devrait ne pas être codé en dur. Soit MN la valeur médiane des N dernières tailles de blocs. Ensuite, la « limite stricte » pour la taille de blocs accepteurs est de \(2 \cdot M_N\). Il évite les ballonnements au blockchain tout en permettant à la limite de grandir lentement avec le temps si nécessaire. La taille des transactions n’a pas besoin d’être limitée explicitement. Il est délimité par la taille d’un bloc ; et si quelqu'un veut créer une énorme transaction avec des centaines d'entrées/sorties (ou avec le degré élevé d'ambiguïté des signatures en anneau), il peut le faire en payant des frais suffisants. 6.2.3 Pénalité de taille excédentaire Un mineur a toujours la possibilité de remplir un bloc de ses propres transactions sans frais jusqu'à son maximum. taille 2 \(\cdot\) Mo. Même si seule la majorité des mineurs peuvent modifier la valeur médiane, il existe toujours un 13 25 En redimensionnant le temps de sorte qu'une unité de temps corresponde à N blocs, la taille moyenne des blocs pourrait encore, en théorie, croître de manière exponentielle proportionnellement à 2 t . En revanche, un plafond plus général sur le bloc suivant serait M_nf(M_n) pour une fonction f. Quelles propriétés de f seraient choisissons-nous afin de garantir une certaine « croissance raisonnable » de la taille des blocs ? La progression de la taille des blocs (après le temps de redimensionnement) ressemblerait à ceci : M_n f(M_n)M_n f(f(M_n)M_n)f(M_n)M_n f(f(f(M_n)M_n)f(M_n)M_n)f(f(M_n)M_n)f( ... Et le but ici est de choisir f tel que cette suite ne croisse pas plus vite que, disons, linéairement, ou peut-être même comme Log(t). Bien sûr, si f(M_n) = a pour une constante a, cette séquence est en fait M_n aM_n aˆ2M_n aˆ3M_n ... Et, bien sûr, la seule façon de limiter cela à une croissance au plus linéaire est de choisir a=1. C’est évidemment irréalisable. Cela ne permet pas du tout la croissance. Si, par contre, f(M_n) est une fonction non constante, alors la situation est bien plus compliqué et peut permettre une solution élégante. Je vais y réfléchir pendant un moment. Ces frais devront être suffisamment élevés pour réduire la pénalité de taille excédentaire de la section suivante. Pourquoi un utilisateur général est-il supposé être un homme, hein ? Hein ?

possibilité de gonfler le blockchain et de produire une charge supplémentaire sur les nœuds. Décourager participants malveillants de créer de gros blocs, nous introduisons une fonction de pénalité : NouvelleRécompense = Récompense de Base \(\cdot\) Taille Noir MN −1 2 Cette règle s'applique uniquement lorsque BlkSize est supérieure à la taille minimale du bloc libre qui devrait être proche du maximum (10 Ko, \(M_N \cdot 110\%\)). Les mineurs sont autorisés à créer des blocs de « taille habituelle » et même dépassez-le avec profit lorsque les frais globaux dépassent la pénalité. Mais il est peu probable que les frais augmentent quadratiquement différent de la valeur de la pénalité, il y aura donc un équilibre. 6.3 Scripts de transactions CryptoNote possède un sous-système de script très minimaliste. Un expéditeur spécifie une expression Φ = f (x1, x2, . . . , xn), où n est le nombre de clés publiques de destination {Pi}n je = 1. Seulement cinq binaires les opérateurs sont pris en charge : min, max, sum, mul et cmp. Lorsque le destinataire dépense ce paiement, il produit \(0 \leq k \leq n\) signatures et les transmet à l'entrée de la transaction. Le processus de vérification évalue simplement Φ avec xi = 1 pour vérifier une signature valide pour la clé publique Pi, et xi = 0. Un vérificateur accepte la preuve si > 0. Malgré sa simplicité, cette approche couvre tous les cas possibles : • Signature multi-/seuil. Pour la multi-signature « M-out-of-N » de style Bitcoin (c.-à-d. le récepteur doit fournir au moins \(0 \leq M \leq N\) signatures valides) Φ = x1+x2+. . .+xN \(\geq M\) (pour plus de clarté, nous utilisons une notation algébrique commune). La signature seuil pondérée (certaines clés peuvent être plus importantes que d’autres) pourrait être exprimée sous la forme Φ = \(w_1 \cdot x_1\) + \(w_2 \cdot x_2\) + . . . + \(w_N \cdot x_N\) \(\geq wM\). Et scénario où le passe-partout correspond à Φ = max(\(M \cdot x\), x1 + x2 + . . . + xN) \(\geq M\). Il est facile de montrer que tout cas complexe peut être exprimés avec ces opérateurs, c'est-à-dire qu'ils constituent la base. • Protection par mot de passe. La possession d'un mot de passe secret équivaut à la connaissance de une clé privée, dérivée de manière déterministe du mot de passe : k = KDF(s). Donc un récepteur peut prouver qu'il connaît le mot de passe en fournissant une autre signature sous la clé k. L'expéditeur ajoute simplement la clé publique correspondante à sa propre sortie. Notez que ceci La méthode est beaucoup plus sécurisée que le « puzzle de transaction » utilisé dans Bitcoin [13], où le le mot de passe est explicitement transmis dans les entrées. • Cas dégénérés. Φ = 1 signifie que n’importe qui peut dépenser de l’argent ; Φ = 0 marque le la production n’est pas dépensable pour toujours. Dans le cas où le script de sortie combiné aux clés publiques est trop volumineux pour un expéditeur, il peut utiliser un type de sortie spécial, qui indique que le destinataire mettra ces données dans son entrée alors que l'expéditeur n'en fournit qu'un hash. Cette approche est similaire au « pay-to-hash » de Bitcoin. fonctionnalité, mais au lieu d'ajouter de nouvelles commandes de script, nous traitons ce cas au niveau de la structure des données niveau. 7 Conclusion Nous avons étudié les défauts majeurs de Bitcoin et proposé quelques solutions possibles. Ces fonctionnalités avantageuses et notre développement continu font du nouveau système de paiement électronique CryptoNote un sérieux rival de Bitcoin, surclassant toutes ses fourchettes. 14 possibilité de gonfler le blockchain et de produire une charge supplémentaire sur les nœuds. Décourager participants malveillants de créer de gros blocs, nous introduisons une fonction de pénalité : NouvelleRécompense = Récompense de Base \(\cdot\) Taille Noir MN −1 2 Cette règle s'applique uniquement lorsque BlkSize est supérieure à la taille minimale du bloc libre qui devrait être proche du maximum (10 Ko, \(M_N \cdot 110\%\)). Les mineurs sont autorisés à créer des blocs de « taille habituelle » et même dépassez-le avec profit lorsque les frais globaux dépassent la pénalité. Mais il est peu probable que les frais augmentent quadratiquement différent de la valeur de la pénalité, il y aura donc un équilibre. 6.3 Scripts de transactions CryptoNote possède un sous-système de script très minimaliste. Un expéditeur spécifie une expression Φ = f (x1, x2, . . . , xn), où n est le nombre de clés publiques de destination {Pi}n je = 1. Seulement cinq binaires les opérateurs sont pris en charge : min, max, sum, mul et cmp. Lorsque le destinataire dépense ce paiement, il produit \(0 \leq k \leq n\) signatures et les transmet à l'entrée de la transaction. Le processus de vérification évalue simplement Φ avec xi = 1 pour vérifier une signature valide pour la clé publique Pi, et xi = 0. Un vérificateur accepte la preuve si > 0. Malgré sa simplicité, cette approche couvre tous les cas possibles : • Signature multi-/seuil. Pour la multi-signature « M-out-of-N » de style Bitcoin (c.-à-d. le récepteur doit fournir au moins \(0 \leq M \leq N\) signatures valides) Φ = x1+x2+. . .+xN \(\geq M\) (pour plus de clarté, nous utilisons une notation algébrique commune). La signature seuil pondérée (certaines clés peuvent être plus importantes que d’autres) pourrait être exprimée sous la forme Φ = \(w_1 \cdot x_1\) + \(w_2 \cdot x_2\) + . . . + \(w_N \cdot x_N\) \(\geq wM\). Et le scénarioio où le passe-partout correspond à Φ = max(\(M \cdot x\), x1 + x2 + . . . + xN) \(\geq M\). Il est facile de montrer que tout cas complexe peut être exprimés avec ces opérateurs, c'est-à-dire qu'ils constituent la base. • Protection par mot de passe. La possession d'un mot de passe secret équivaut à la connaissance de une clé privée, dérivée de manière déterministe du mot de passe : k = KDF(s). Donc un récepteur peut prouver qu'il connaît le mot de passe en fournissant une autre signature sous la clé k. L'expéditeur ajoute simplement la clé publique correspondante à sa propre sortie. Notez que ceci La méthode est beaucoup plus sécurisée que le « puzzle de transaction » utilisé dans Bitcoin [13], où le le mot de passe est explicitement transmis dans les entrées. • Cas dégénérés. Φ = 1 signifie que n’importe qui peut dépenser de l’argent ; Φ = 0 marque le la production n’est pas dépensable pour toujours. Dans le cas où le script de sortie combiné aux clés publiques est trop volumineux pour un expéditeur, il peut utiliser un type de sortie spécial, qui indique que le destinataire mettra ces données dans son entrée alors que l'expéditeur n'en fournit qu'un hash. Cette approche est similaire au « pay-to-hash » de Bitcoin. fonctionnalité, mais au lieu d'ajouter de nouvelles commandes de script, nous traitons ce cas au niveau de la structure des données niveau. 7 Conclusion Nous avons étudié les défauts majeurs de Bitcoin et proposé quelques solutions possibles. Ces fonctionnalités avantageuses et notre développement continu font du nouveau système de paiement électronique CryptoNote un sérieux rival de Bitcoin, surclassant toutes ses fourchettes. 14 26 Cela peut être inutile si nous pouvons trouver un moyen de limiter la taille des blocs au fil du temps... Cela ne peut pas non plus être correct. Ils ont juste réglé "NewReward" sur une parabole orientée vers le haut où la taille du bloc est la variable indépendante. Ainsi une nouvelle récompense explose à l’infini. Si, d'autre part main, la nouvelle récompense est Max(0,Base Reward(1-(BlkSize/Mn - 1)ˆ2)), puis la nouvelle récompense serait une parabole orientée vers le bas avec un pic à la taille du bloc = Mn et avec des intersections à Taille du bloc = 0 et Taille du bloc = 2Mn. Et c’est apparemment ce qu’ils tentent de décrire. Toutefois, cela ne

Analyse

5 Cela n’a pas vraiment d’importance lorsqu’un milliard de personnes dans le monde vivent avec moins d’un dollar par an. jour et n'avons aucun espoir de participer un jour à une quelconque sorte de réseau minier... mais un avenir économique un monde piloté par un système monétaire p2p avec un processeur, une voix serait, vraisemblablement, plus plus juste qu’un système piloté par des banques à réserves fractionnaires. Mais le protocole de Cryptonote exige tout de même 51% d'utilisateurs honnêtes... voir par exemple le Cryptonote forums où l'un des développeurs, Pliskov, affirme qu'une attaque traditionnelle de remplacement des données sur leblockchain 51 % peut toujours fonctionner. https://forum.cryptonote.org/viewtopic.php?f=2&t=198 Notez que vous n’avez pas vraiment besoin de 51 % d’utilisateurs honnêtes. Vous avez juste vraiment besoin de "pas un seul malhonnête faction détenant plus de 51 % de la puissance hashing du réseau." Appelons ce soi-disant problème du Bitcoin « rigidité adaptative ». La solution de Cryptonote pour l'adaptation la rigidité est la flexibilité adaptative dans les valeurs des paramètres du protocole. Si vous avez besoin de blocs de plus grande taille, pas de problème, le réseau s'est ajusté en douceur tout le temps. C'est à dire, la façon dont Bitcoin ajuste la difficulté au fil du temps peut être reproduite dans l'ensemble de notre protocole paramètres de sorte qu’il n’est pas nécessaire d’obtenir un consensus du réseau pour mettre à jour le protocole. En apparence, cela semble être une bonne idée, mais sans une réflexion approfondie, un système d'auto-ajustement le système peut devenir assez imprévisible et chaotique. Nous y reviendrons plus en détail plus tard, à mesure que des opportunités se présentent. Les « bons » systèmes se situent quelque part entre la rigidité adaptative et le système adaptatif. flexible, et peut-être même la rigidité elle-même est adaptative. Si nous avions vraiment « un processeur, une voix », alors collaborer et développer des pools pour atteindre 51 % serait plus difficile. Nous nous attendrions à ce que tous les processeurs du monde exploitent le minage, depuis les téléphones au processeur intégré de votre Tesla pendant la charge. http://en.wikipedia.org/wiki/Pareto_principle Je prétends que l’équilibre de Pareto est quelque peu inévitable. Soit 20% du système sera possédera 80 % des processeurs, ou 20 % du système détiendra 80 % des ASIC. J'émets cette hypothèse parce que la répartition sous-jacente de la richesse dans la société présente déjà la distribution de Pareto, et à mesure que de nouveaux mineurs rejoignent, ils sont tirés de cette distribution sous-jacente. Cependant, je soutiens que les protocoles avec un processeur, un vote entraîneront un retour sur investissement sur le matériel. Bloquer la récompense par nœud sera plus étroitement proportionnelle au nombre de nœuds dans le réseau car la répartition des performances entre les nœuds sera beaucoup plus serrée. Bitcoin, d'autre part d’autre part, voit une récompense de bloc (par nœud) plus proportionnelle à la capacité de calcul de celui-ci. nœud. Autrement dit, seuls les « grands » sont encore dans le jeu minier. D'un autre côté, même si le principe de Pareto sera toujours en jeu, dans un monde à un processeur, une voix, tout le monde participe à la sécurité du réseau et gagne un peu de revenus miniers. Dans un monde ASIC, il n’est pas judicieux d’installer chaque XBox et téléphone portable sur le mien. Dans un monde à un processeur, à une voix, c’est très judicieux en termes de récompense minière. En conséquence délicieuse, obtenir 51 % des suffrages est plus difficile quand il y a de plus en plus de voix, ce qui donne un joli résultat. avantage pour la sécurité du réseau.matériel décrit précédemment. Supposons que le taux global de hash diminue de manière significative, même pour un instant, il peut désormais utiliser son pouvoir minier pour bifurquer la chaîne et doubler ses dépenses. Comme nous le verrons plus loin dans cet article, il n’est pas improbable que l’événement décrit précédemment se produise. 2.3 Émission irrégulière Bitcoin a un taux d'émission prédéterminé : chaque bloc résolu produit une quantité fixe de pièces. Environ tous les quatre ans, cette récompense est réduite de moitié. L'intention initiale était de créer un émission douce limitée avec décroissance exponentielle, mais en fait nous avons une émission linéaire par morceaux fonction dont les points d'arrêt peuvent causer des problèmes à l'infrastructure Bitcoin. Lorsque le point d'arrêt survient, les mineurs commencent à recevoir seulement la moitié de la valeur de leur précédent récompense. La différence absolue entre 12,5 et 6,25 BTC (projetée pour l'année 2020) pourrait semblent tolérables. Cependant, en examinant la baisse de 50 à 25 BTC survenue en novembre 28 2012, semblait inapproprié pour un nombre important de membres de la communauté minière. Chiffre 1 montre une baisse spectaculaire du hashtarif du réseau à la fin du mois de novembre, exactement au moment où le la réduction de moitié a eu lieu. Cet événement aurait pu être le moment idéal pour l'individu malveillant décrit dans la section fonction proof-of-work pour mener une attaque à double dépense [36]. Figure 1. Tableau des taux Bitcoin hash (source : http://bitcoin.sipa.be) 2.4 Constantes codées en dur Bitcoin comporte de nombreuses limites codées en dur, dont certaines sont des éléments naturels de la conception originale (par ex. fréquence de blocage, montant maximum de la masse monétaire, nombre de confirmations) alors que d'autres semblent être des contraintes artificielles. Ce ne sont pas tant les limites que l'incapacité de changer rapidement 3 matériel décrit précédemment. Supposons que le taux global de hash diminue de manière significative, même pour un instant, il peut désormais utiliser son pouvoir minier pour bifurquer la chaîne et doubler ses dépenses. Comme nous le verrons plus loin dans cet article, il n’est pas improbable que l’événement décrit précédemment se produise. 2.3 Émission irrégulière Bitcoin a un taux d'émission prédéterminé : chaque bloc résolu produit une quantité fixe de pièces. Environ tous les quatre ans, cette récompense est réduite de moitié. L'intention initiale était de créer un émission douce limitée avec décroissance exponentielle, mais en fait nous avons une émission linéaire par morceaux fonction dont les points d'arrêt peuvent causer des problèmes à l'infrastructure Bitcoin. Lorsque le point d'arrêt survient, les mineurs commencent à recevoir seulement la moitié de la valeur de leur précédent récompense. La différence absolue entre 12,5 et 6,25 BTC (projetée pour l'année 2020) pourrait semblent tolérables. Cependant, en examinant la baisse de 50 à 25 BTC survenue en novembre 28 2012, semblait inapproprié pour un nombre important de membres de la communauté minière. Chiffre 1 montre une baisse spectaculaire du hashtarif du réseau à la fin du mois de novembre, exactement au moment où le la réduction de moitié a eu lieu. Cet événement aurait pu être le moment idéal pour l'individu malveillant décrit dans la section fonction proof-of-work pour mener une attaque à double dépense [36]. Figure 1. Tableau des taux Bitcoin hash (source : http://bitcoin.sipa.be) 2.4 Constantes codées en dur Bitcoin comporte de nombreuses limites codées en dur, dont certaines sont des éléments naturels de la conception originale (par ex. fréquence de blocage, montant maximum de la masse monétaire, nombre de confirmations) alors que d'autres semblent être des contraintes artificielles. Ce ne sont pas tant les limites que l'incapacité de changer rapidement 3 6 Appelons cela comme ça, une attaque de zombies. Discutons de ce que peut être l'émission continue lié à un processeur, un vote dans un scénario d'attaque de zombies. Dans un monde à un processeur, une voix, chaque téléphone portable et chaque voiture, lorsqu'ils sont inutilisés, seraient exploités. Collecter des tas de matériel bon marché pour créer une ferme minière serait très très simple, car il suffit de à peu près tout contient un processeur. En revanche, à ce stade, le nombre de processeurs nécessaire pour lancer une attaque à 51% serait assez étonnant, je pense. De plus, précisément parce qu'il serait facile de collecter du matériel bon marché, nous pouvons raisonnablement nous attendre à un beaucoup de gens commencent à accumuler n'importe quoi avec un processeur. La course aux armements dans un monde « un processeur, une voix » est forcément plus égalitaire que dans un monde ASIC. D'où une discontinuité dans le réseau la sécurité due aux taux d'émission devrait être MOINS un problème dans un monde à un processeur, une voix. Cependant, deux faits demeurent : 1) la discontinuité du taux d'émission peut conduire à un effet de bégaiement dans l'économie et la sécurité des réseaux, ce qui est mauvais, et 2) même si une attaque de 51 % effectué par quelqu'un collectant du matériel bon marché peut toujours se produire dans un processeur unique-votez le monde, il semble que cela devrait être plus difficile. Vraisemblablement, la protection contre cela est que tous les acteurs malhonnêtes tenteront cela. simultanément, et nous revenons à la notion de sécurité précédente de Bitcoin : "nous n'exigeons aucun faction pour contrôler plus de 51% du réseau. L'auteur affirme ici que l'un des problèmes du Bitcoin est la discontinuité dans l'émission des pièces. Ce taux pourrait entraîner une baisse soudaine de la participation au réseau, et donc de la sécurité du réseau. Ainsi, un taux d’émission de pièces continu, différenciable et régulier est préférable. L’auteur n’a pas forcément tort. Toute sorte de diminution soudaine de la participation au réseau peut conduire à un tel problème, et si nous pouvons en supprimer une source, nous devrions le faire. Cela dit, c'est Il est possible que de longues périodes d'émission de pièces de monnaie « relativement constantes » ponctuées de changements soudains est la voie idéale à suivre d’un point de vue économique. Je ne suis pas économiste. Alors, peut-être que nous devons décider si nous allons échanger la sécurité des réseaux contre quelque chose d’économique – qu’est-ce qu’il y a ici ? http://arxiv.org/abs/1402.2009si nécessaire, cela provoque les principaux inconvénients. Malheureusement, il est difficile de prédire quand les constantes devront peut-être être modifiées et leur remplacement peut avoir des conséquences terribles. Un bon exemple de changement de limite codé en dur conduisant à des conséquences désastreuses est le blocage limite de taille fixée à 250 Ko1. Cette limite était suffisante pour contenir environ 10 000 transactions standards. Dans début 2013, cette limite était presque atteinte et un accord a été trouvé pour augmenter le limite. Le changement a été implémenté dans la version 0.8 du portefeuille et s'est terminé par une division de chaîne de 24 blocs. et une attaque réussie de double dépense [9]. Bien que le bug ne soit pas dans le protocole Bitcoin, mais au contraire, dans le moteur de base de données, il aurait pu être facilement détecté par un simple test de résistance s'il y avait eu aucune limite de taille de bloc introduite artificiellement. Les constantes agissent également comme une forme de point de centralisation. Malgré la nature peer-to-peer de Bitcoin, une écrasante majorité de nœuds utilisent le client de référence officiel [10] développé par un petit groupe de personnes. Ce groupe prend la décision de mettre en œuvre des modifications au protocole et la plupart des gens acceptent ces changements indépendamment de leur « exactitude ». Certaines décisions ont provoqué discussions animées et même appels au boycott [11], ce qui indique que la communauté et le les développeurs peuvent être en désaccord sur certains points importants. Il semble donc logique d'avoir un protocole avec des variables configurables par l'utilisateur et auto-ajustables comme moyen possible d'éviter ces problèmes. 2.5 Scripts volumineux Le système de script de Bitcoin est une fonctionnalité lourde et complexe. Cela permet potentiellement de créer transactions sophistiquées [12], mais certaines de ses fonctionnalités sont désactivées en raison de problèmes de sécurité et certains n'ont même jamais été utilisés [13]. Le script (y compris les parties des expéditeurs et des destinataires) pour la transaction la plus populaire en Bitcoin ressemble à ceci : OP DUP OP HASH160 OP EQUALVERIFY OP CHECKSIG. Le script fait 164 octets alors que son seul but est de vérifier si le récepteur possède le clé secrète nécessaire pour vérifier sa signature.