CryptoNote v2.0

作者 Nicolas van Saberhagen · 2013

本页面呈现的是 Nicolas van Saberhagen 于 2013 年发布的 CryptoNote v2.0 白皮书，该白皮书描述了 Monero 所基于的密码学基础。这并非 Monero 专属的白皮书——Monero 于 2014 年作为 CryptoNote 参考实现（Bytecoin）的分叉上线，此后已在原始协议基础上发展演进了许多。

🇺🇸 English (原文)

🇫🇷 Français (译文)

Introduction

"Bitcoin" [1] has been a successful implementation of the concept of p2p electronic cash. Both professionals and the general public have come to appreciate the convenient combination of public transactions and proof-of-work as a trust model. Today, the user base of electronic cash is growing at a steady pace; customers are attracted to low fees and the anonymity provided by electronic cash and merchants value its predicted and decentralized emission. Bitcoin has eﬀectively proved that electronic cash can be as simple as paper money and as convenient as credit cards. Unfortunately, Bitcoin suﬀers from several deﬁciencies. For example, the system's distributed nature is inﬂexible, preventing the implementation of new features until almost all of the network users update their clients. Some critical ﬂaws that cannot be ﬁxed rapidly deter Bitcoin's widespread propagation. In such inﬂexible models, it is more eﬃcient to roll-out a new project rather than perpetually ﬁx the original project. In this paper, we study and propose solutions to the main deﬁciencies of Bitcoin. We believe that a system taking into account the solutions we propose will lead to a healthy competition among diﬀerent electronic cash systems. We also propose our own electronic cash, "CryptoNote", a name emphasizing the next breakthrough in electronic cash.

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 eﬃcace 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 Drawbacks and Possible Solutions

2 Bitcoin drawbacks and some possible solutions 2.1 Traceability of transactions Privacy and anonymity are the most important aspects of electronic cash. Peer-to-peer payments seek to be concealed from third party’s view, a distinct diﬀerence when compared with traditional banking. In particular, T. Okamoto and K. Ohta described six criteria of ideal electronic cash, which included “privacy: relationship between the user and his purchases must be untraceable by anyone” [30]. From their description, we derived two properties which a fully anonymous electronic cash model must satisfy in order to comply with the requirements outlined by Okamoto and Ohta: Untraceability: for each incoming transaction all possible senders are equiprobable. Unlinkability: for any two outgoing transactions it is impossible to prove they were sent to the same person. Unfortunately, Bitcoin does not satisfy the untraceability requirement. Since all the transactions that take place between the network’s participants are public, any transaction can be 1 CryptoNote v 2.0 Nicolas van Saberhagen October 17, 2013 1 Introduction “Bitcoin” [1] has been a successful implementation of the concept of p2p electronic cash. Both professionals and the general public have come to appreciate the convenient combination of public transactions and proof-of-work as a trust model. Today, the user base of electronic cash is growing at a steady pace; customers are attracted to low fees and the anonymity provided by electronic cash and merchants value its predicted and decentralized emission. Bitcoin has eﬀectively proved that electronic cash can be as simple as paper money and as convenient as credit cards. Unfortunately, Bitcoin suﬀers from several deﬁciencies. For example, the system’s distributed nature is inﬂexible, preventing the implementation of new features until almost all of the network users update their clients. Some critical ﬂaws that cannot be ﬁxed rapidly deter Bitcoin’s widespread propagation. In such inﬂexible models, it is more eﬃcient to roll-out a new project rather than perpetually ﬁx the original project. In this paper, we study and propose solutions to the main deﬁciencies of Bitcoin. We believe that a system taking into account the solutions we propose will lead to a healthy competition among diﬀerent electronic cash systems. We also propose our own electronic cash, “CryptoNote”, a name emphasizing the next breakthrough in electronic cash. 2 Bitcoin drawbacks and some possible solutions 2.1 Traceability of transactions Privacy and anonymity are the most important aspects of electronic cash. Peer-to-peer payments seek to be concealed from third party’s view, a distinct diﬀerence when compared with traditional banking. In particular, T. Okamoto and K. Ohta described six criteria of ideal electronic cash, which included “privacy: relationship between the user and his purchases must be untraceable by anyone” [30]. From their description, we derived two properties which a fully anonymous electronic cash model must satisfy in order to comply with the requirements outlined by Okamoto and Ohta: Untraceability: for each incoming transaction all possible senders are equiprobable. Unlinkability: for any two outgoing transactions it is impossible to prove they were sent to the same person. Unfortunately, Bitcoin does not satisfy the untraceability requirement. Since all the transactions that take place between the network’s participants are public, any transaction can be 1 3 Bitcoin deﬁnitely fails "untraceability." When I send you BTC, the wallet from which it is sent is irrevocably stamped on the blockchain. There is no question about who sent those funds, because only the knower of the private keys can send them.

unambiguously traced to a unique origin and ﬁnal recipient. Even if two participants exchange funds in an indirect way, a properly engineered path-ﬁnding method will reveal the origin and ﬁnal recipient. It is also suspected that Bitcoin does not satisfy the second property. Some researchers stated ([33, 35, 29, 31]) that a careful blockchain analysis may reveal a connection between the users of the Bitcoin network and their transactions. Although a number of methods are disputed [25], it is suspected that a lot of hidden personal information can be extracted from the public database. Bitcoin’s failure to satisfy the two properties outlined above leads us to conclude that it is not an anonymous but a pseudo-anonymous electronic cash system. Users were quick to develop solutions to circumvent this shortcoming. Two direct solutions were “laundering services” [2] and the development of distributed methods [3, 4]. Both solutions are based on the idea of mixing several public transactions and sending them through some intermediary address; which in turn suﬀers the drawback of requiring a trusted third party. Recently, a more creative scheme was proposed by I. Miers et al. [28]: “Zerocoin”. Zerocoin utilizes a cryptographic one-way accumulators and zero-knoweldge proofs which permit users to “convert” bitcoins to zerocoins and spend them using anonymous proof of ownership instead of explicit public-key based digital signatures. However, such knowledge proofs have a constant but inconvenient size - about 30kb (based on today’s Bitcoin limits), which makes the proposal impractical. Authors admit that the protocol is unlikely to ever be accepted by the majority of Bitcoin users [5]. 2.2 The proof-of-work function Bitcoin creator Satoshi Nakamoto described the majority decision making algorithm as “oneCPU-one-vote” and used a CPU-bound pricing function (double SHA-256) for his proof-of-work scheme. Since users vote for the single history of transactions order [1], the reasonableness and consistency of this process are critical conditions for the whole system. The security of this model suﬀers from two drawbacks. First, it requires 51% of the network’s mining power to be under the control of honest users. Secondly, the system’s progress (bug ﬁxes, security ﬁxes, etc...) require the overwhelming majority of users to support and agree to the changes (this occurs when the users update their wallet software) [6].Finally this same voting mechanism is also used for collective polls about implementation of some features [7]. This permits us to conjecture the properties that must be satisﬁed by the proof-of-work pricing function. Such function must not enable a network participant to have a signiﬁcant advantage over another participant; it requires a parity between common hardware and high cost of custom devices. From recent examples [8], we can see that the SHA-256 function used in the Bitcoin architecture does not posses this property as mining becomes more eﬃcient on GPUs and ASIC devices when compared to high-end CPUs. Therefore, Bitcoin creates favourable conditions for a large gap between the voting power of participants as it violates the “one-CPU-one-vote” principle since GPU and ASIC owners posses a much larger voting power when compared with CPU owners. It is a classical example of the Pareto principle where 20% of a system’s participants control more than 80% of the votes. One could argue that such inequality is not relevant to the network’s security since it is not the small number of participants controlling the majority of the votes but the honesty of these participants that matters. However, such argument is somewhat ﬂawed since it is rather the possibility of cheap specialized hardware appearing rather than the participants’ honesty which poses a threat. To demonstrate this, let us take the following example. Suppose a malevolent individual gains signiﬁcant mining power by creating his own mining farm through the cheap 2 unambiguously traced to a unique origin and ﬁnal recipient. Even if two participants exchange funds in an indirect way, a properly engineered path-ﬁnding method will reveal the origin and ﬁnal recipient. It is also suspected that Bitcoin does not satisfy the second property. Some researchers stated ([33, 35, 29, 31]) that a careful blockchain analysis may reveal a connection between the users of the Bitcoin network and their transactions. Although a number of methods are disputed [25], it is suspected that a lot of hidden personal information can be extracted from the public database. Bitcoin’s failure to satisfy the two properties outlined above leads us to conclude that it is not an anonymous but a pseudo-anonymous electronic cash system. Users were quick to develop solutions to circumvent this shortcoming. Two direct solutions were “laundering services” [2] and the development of distributed methods [3, 4]. Both solutions are based on the idea of mixing several public transactions and sending them through some intermediary address; which in turn suﬀers the drawback of requiring a trusted third party. Recently, a more creative scheme was proposed by I. Miers et al. [28]: “Zerocoin”. Zerocoin utilizes a cryptographic one-way accumulators and zero-knoweldge proofs which permit users to “convert” bitcoins to zerocoins and spend them using anonymous proof of ownership instead of explicit public-key based digital signatures. However, such knowledge proofs have a constant but inconvenient size - about 30kb (based on today’s Bitcoin limits), which makes the proposal impractical. Authors admit that the protocol is unlikely to ever be accepted by the majority of Bitcoin users [5]. 2.2 The proof-of-work function Bitcoin creator Satoshi Nakamoto described the majority decision making algorithm as “oneCPU-one-vote” and used a CPU-bound pricing function (double SHA-256) for his proof-of-work scheme. Since users vote for the single history of transactions order [1], the reasonableness and consistency of this process are critical conditions for the whole system. The security of this model suﬀers from two drawbacks. First, it requires 51% of the network’s mining power to be under the control of honest users. Secondly, the system’s progress (bug ﬁxes, security ﬁxes, etc...) require the overwhelming majority of users to support and agree to the changes (this occurs when the users update their wallet software) [6].Finally this same voting mechanism is also used for collective polls about implementation of some features [7]. This permits us to conjecture the properties that must be satisﬁed by the proof-of-work pricing function. Such function must not enable a network participant to have a signiﬁcant advantage over another participant; it requires a parity between common hardware and high cost of custom devices. From recent examples [8], we can see that the SHA-256 function used in the Bitcoin architecture does not posses this property as mining becomes more eﬃcient on GPUs and ASIC devices when compared to high-end CPUs. Therefore, Bitcoin creates favourable conditions for a large gap between the voting power of participants as it violates the “one-CPU-one-vote” principle since GPU and ASIC owners posses a much larger voting power when compared with CPU owners. It is a classical example of the Pareto principle where 20% of a system’s participants control more than 80% of the votes. One could argue that such inequality is not relevant to the network’s security since it is not the small number of participants controlling the majority of the votes but the honesty of these participants that matters. However, such argument is somewhat ﬂawed since it is rather the possibility of cheap specialized hardware appearing rather than the participants’ honesty which poses a threat. To demonstrate this, let us take the following example. Suppose a malevolent individual gains signiﬁcant mining power by creating his own mining farm through the cheap 2 4 Presumably, if every user helps their own anonymity out by always generating a new address for EVERY received payment (which is absurd but technically the "correct" way to do it), and if every user helped out everyone else’s anonymity by insisting that they never send funds to the same BTC address twice, then Bitcoin would still only circumstantially pass the unlinkability test. Why? Consumer data can be used to ﬁgure an astonishing amount about people all the time. See, for example http://www.applieddatalabs.com/content/target-knows-it-shows Now, imagine this is 20 years in the future and further imagine that Target didn’t just know about your purchase habits at Target, but they had been mining the blockchain for ALL OF YOUR PERSONAL PURCHASES WITH YOUR COINBASE WALLET FOR THE PAST TWELVE YEARS. They’ll be like "hey buddy you might want to pick up some cough medicine tonight, you won’t feel well tomorrow." This may not be the case if multi-party sorting is exploited correctly. See, for example, this blog post: http://blog.ezyang.com/2012/07/secure-multiparty-bitcoin-anonymization/ I’m not totally convinced of the math on that, but ... one paper at a time, right? Citation needed. Whereas the Zerocoin protocol (standalone) may be insuﬃcient, the Zerocash protocol seems to have implemented a 1kb sized transactions. That project is supported by the US and Israeli militaries, of course, so who knows about it’s robustness. On the other hand, no one wants to be able to spend funds without oversight more than the military. http://zerocash-project.org/ I’m not convinced... see, for example, http://fc14.ifca.ai/bitcoin/papers/bitcoin14_submission_12.pdf Quoting a Cryptonote developer Maurice Planck (presumably a pseudonym) from the cryptonote fora: "Zerocoin, Zerocash. This is the most advanced technology, I must admit. Yes, the quote above is from the analysis of the previous version of the protocol. To my knowledge, it’s not 288, but 384 bytes, but anyway this is good news. They used a brand new technic called SNARK, which has certain downsides: for example, large initial database of public parameters required to create a signature (more than 1 GB) and signiﬁcant time required to create a transaction (more than a minute). Finally, they’re using a young crypto, which I’ve mentioned to be an arguable idea: https://forum.cryptonote.org/viewtopic.php?f= " - Maurice P. Thu Apr 03, 2014 7:56 pm A function that is performed in the CPU and is not suitable for GPU, FPGA, or ASIC computation. The "puzzle" used in proof-of-work is referred to as the pricing function, cost function, or puzzle function.

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 eﬃcace 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 ﬁnal 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 eﬃcace 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 ﬁnal 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 eﬃcace 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 insuﬃsant, 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 ﬁnal 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 eﬃcace 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 ﬁnal 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 eﬃcace 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

The CryptoNote Technology

Now that we have covered the limitations of the Bitcoin technology, we will concentrate on presenting the features of CryptoNote.

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.

Untraceable Transactions

In this section we propose a scheme of fully anonymous transactions satisfying both untraceability and unlinkability conditions. An important feature of our solution is its autonomy: the sender is not required to cooperate with other users or a trusted third party to make his transactions; hence each participant produces a cover traﬃc independently. 4.1 Literature review Our scheme relies on the cryptographic primitive called a group signature. First presented by D. Chaum and E. van Heyst [19], it allows a user to sign his message on behalf of the group. After signing the message the user provides (for veriﬁcation purposes) not his own single public 1This is so-called “soft limit” — the reference client restriction for creating new blocks. Hard maximum of possible blocksize was 1 MB 4 them if necessary that causes the main drawbacks. Unfortunately, it is hard to predict when the constants may need to be changed and replacing them may lead to terrible consequences. A good example of a hardcoded limit change leading to disastrous consequences is the block size limit set to 250kb1. This limit was suﬃcient to hold about 10000 standard transactions. In early 2013, this limit had almost been reached and an agreement was reached to increase the limit. The change was implemented in wallet version 0.8 and ended with a 24-blocks chain split and a successful double-spend attack [9]. While the bug was not in the Bitcoin protocol, but rather in the database engine it could have been easily caught by a simple stress test if there was no artiﬁcially introduced block size limit. Constants also act as a form of centralization point. Despite the peer-to-peer nature of Bitcoin, an overwhelming majority of nodes use the oﬃcial reference client [10] developed by a small group of people. This group makes the decision to implement changes to the protocol and most people accept these changes irrespective of their “correctness”. Some decisions caused heated discussions and even calls for boycott [11], which indicates that the community and the developers may disagree on some important points. It therefore seems logical to have a protocol with user-conﬁgurable and self-adjusting variables as a possible way to avoid these problems. 2.5 Bulky scripts The scripting system in Bitcoin is a heavy and complex feature. It potentially allows one to create sophisticated transactions [12], but some of its features are disabled due to security concerns and some have never even been used [13]. The script (including both senders’ and receivers’ parts) for the most popular transaction in Bitcoin looks like this: OP DUP OP HASH160 OP EQUALVERIFY OP CHECKSIG. The script is 164 bytes long whereas its only purpose is to check if the receiver possess the secret key required to verify his signature. 3 The CryptoNote Technology Now that we have covered the limitations of the Bitcoin technology, we will concentrate on presenting the features of CryptoNote. 4 Untraceable Transactions In this section we propose a scheme of fully anonymous transactions satisfying both untraceability and unlinkability conditions. An important feature of our solution is its autonomy: the sender is not required to cooperate with other users or a trusted third party to make his transactions; hence each participant produces a cover traﬃc independently. 4.1 Literature review Our scheme relies on the cryptographic primitive called a group signature. First presented by D. Chaum and E. van Heyst [19], it allows a user to sign his message on behalf of the group. After signing the message the user provides (for veriﬁcation purposes) not his own single public 1This is so-called “soft limit” — the reference client restriction for creating new blocks. Hard maximum of possible blocksize was 1 MB 4 7 In retrospect, it seems to have been a big mistake to make block size a ﬁxed limit in the code. Visa and Mastercard can process thousands, if not hundreds of thousands, of transactions per second. However, transactions come in a stochastic process, sometimes in massive bursts, sometimes being quiet for hours. Think of the volume of bitcoin exchange. Seems like a grand idea to design a system that increases block size dynamically when necessary to accommodate increased transaction traﬃc, and decrease it dynamically when necessary to increase bandwidth eﬃciency. Now, apply that notion to all system parameters. And as long as we’re careful to keep the system from ﬁshtailing out of control, this should work great. https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki As previously mentioned, if variables self-adjust, some controls must be imposed in order to keep the system from proceeding wildly out of control. We’ll get to that. If this were a wikipedia article, it’d be labeled "STUB." Although we are certainly in the section introducing the "Problems of Bitcoin," I would like some elaboration here. Why is 164 bytes unacceptable for a simple "check for secret key" task? How small can they get for a reasonable scripting language? I’m not a computer scientist, though. http://download.springer.com/static/pdf/412/chp%253A10.1007%252F3-540-46416-6_22.pdf?auth66=140 Group signatures, as described, require a group manager. The group manager is capable of revoking the anonymity of any signer. Hence, there is in-built centralization in a group signature scheme.

key, but the keys of all the users of his group. A veriﬁer is convinced that the real signer is a member of the group, but cannot exclusively identify the signer. The original protocol required a trusted third party (called the Group Manager), and he was the only one who could trace the signer. The next version called a ring signature, introduced by Rivest et al. in [34], was an autonomous scheme without Group Manager and anonymity revocation. Various modiﬁcations of this scheme appeared later: linkable ring signature [26, 27, 17] allowed to determine if two signatures were produced by the same group member, traceable ring signature [24, 23] limited excessive anonymity by providing possibility to trace the signer of two messages with respect to the same metainformation (or “tag” in terms of [24]). A similar cryptographic construction is also known as a ad-hoc group signature [16, 38]. It emphasizes the arbitrary group formation, whereas group/ring signature schemes rather imply a ﬁxed set of members. For the most part, our solution is based on the work “Traceable ring signature” by E. Fujisaki and K. Suzuki [24]. In order to distinguish the original algorithm and our modiﬁcation we will call the latter a one-time ring signature, stressing the user’s capability to produce only one valid signature under his private key. We weakened the traceability property and kept the linkability only to provide one-timeness: the public key may appear in many foreign verifying sets and the private key can be used for generating a unique anonymous signature. In case of a double spend attempt these two signatures will be linked together, but revealing the signer is not necessary for our purposes. 4.2 Deﬁnitions 4.2.1 Elliptic curve parameters As our base signature algorithm we chose to use the fast scheme EdDSA, which is developed and implemented by D.J. Bernstein et al. [18]. Like Bitcoin’s ECDSA it is based on the elliptic curve discrete logarithm problem, so our scheme could also be applied to Bitcoin in future. Common parameters are: \(q\): a prime number; \(q = 2^{255} - 19\); \(d\): an element of \(\mathbb{F}_q\); \(d = -121665/121666\); \(E\): an elliptic curve equation; \(-x^2 + y^2 = 1 + dx^2y^2\); \(G\): a base point; \(G = (x, -4/5)\); \(l\): a prime order of the base point; \(l = 2^{252} + 27742317777372353535851937790883648493\); \(H_s\): a cryptographic hash function \(\{0, 1\}^* \to \mathbb{F}_q\); \(H_p\): a deterministic hash function \(E(\mathbb{F}_q) \to E(\mathbb{F}_q)\). 4.2.2 Terminology Enhanced privacy requires a new terminology which should not be confused with Bitcoin entities. private ec-key is a standard elliptic curve private key: a number \(a \in [1, l - 1]\); public ec-key is a standard elliptic curve public key: a point \(A = aG\); one-time keypair is a pair of private and public ec-keys; 5 key, but the keys of all the users of his group. A veriﬁer is convinced that the real signer is a member of the group, but cannot exclusively identify the signer. The original protocol required a trusted third party (called the Group Manager), and he was the only one who could trace the signer. The next version called a ring signature, introduced by Rivest et al. in [34], was an autonomous scheme without Group Manager and anonymity revocation. Various modiﬁcations of this scheme appeared later: linkable ring signature [26, 27, 17] allowed to determine if two signatures were produced by the same group member, traceable ring signature [24, 23] limited excessive anonymity by providing possibility to trace the signer of two messages with respect to the same metainformation (or “tag” in terms of [24]). A similar cryptographic construction is also known as a ad-hoc group signature [16, 38]. It emphasizes the arbitrary group formation, whereas group/ring signature schemes rather imply a ﬁxed set of members. For the most part, our solution is based on the work “Traceable ring signature” by E. Fujisaki and K. Suzuki [24]. In order to distinguish the original algorithm and our modiﬁcation we will call the latter a one-time ring signature, stressing the user’s capability to produce only one valid signature under his private key. We weakened the traceability property and kept the linkability only to provide one-timeness: the public key may appear in many foreign verifying sets and the private key can be used for generating a unique anonymous signature. In case of a double spend attempt these two signatures will be linked together, but revealing the signer is not necessary for our purposes. 4.2 Deﬁnitions 4.2.1 Elliptic curve parameters As our base signature algorithm we chose to use the fast scheme EdDSA, which is developed and implemented by D.J. Bernstein et al. [18]. Like Bitcoin’s ECDSA it is based on the elliptic curve discrete logarithm problem, so our scheme could also be applied to Bitcoin in future. Common parameters are: \(q\): a prime number; \(q = 2^{255} - 19\); \(d\): an element of \(\mathbb{F}_q\); \(d = -121665/121666\); \(E\): an elliptic curve equation; \(-x^2 + y^2 = 1 + dx^2y^2\); \(G\): a base point; \(G = (x, -4/5)\); \(l\): a prime order of the base point; \(l = 2^{252} + 27742317777372353535851937790883648493\); \(H_s\): a cryptographic hash function \(\{0, 1\}^* \to \mathbb{F}_q\); \(H_p\): a deterministic hash function \(E(\mathbb{F}_q) \to E(\mathbb{F}_q)\). 4.2.2 Terminology Enhanced privacy requires a new terminology which should not be confused with Bitcoin entities. private ec-key is a standard elliptic curve private key: a number \(a \in [1, l - 1]\); public ec-key is a standard elliptic curve public key: a point \(A = aG\); one-time keypair is a pair of private and public ec-keys; 5 8 A ring signature works like this: Alex wants to leak a message to WikiLeaks about her employer. Every employee in her Company has a private/public key pair (Ri, Ui). She composes her signature with input set as her message, m, her private key, Ri, and EVERYBODY’s public keys, (Ui;i=1...n). Anyone (without knowing any private keys) can verify easily that some pair (Rj, Uj) must have been used to construct the signature... someone who works for Alex’s employer... but it’s essentially a random guess to ﬁgure out which one it could be. 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 Notice that a linkable ring signature described here is kind of the opposite of "unlinkable" described above. Here, we intercept two messages, and we can determine whether the same party sent them, although we should still be unable to determine who that party is. The deﬁnition of "unlinkable" used to construct Cryptonote means we cannot determine whether the same party is receiving them. Hence, what we really have here is FOUR things going on. A system can be linkable or non-linkable, depending on whether or not it’s possible to determine whether the sender of two messages are the same (regardless of whether this requires revoking anonymity). And a system can be unlinkable or non-unlinkable, depending on whether or not it’s possible to determine whether the receiver of two messages are the same (regardless of whether or not this requires revoking anonymity). Please don’t blame me for this terrible terminology. Graph theorists should probably be pleased. Some of you may be more comfortable with "receiver linkable" versus "sender linkable." http://link.springer.com/chapter/10.1007/978-3-540-71677-8_13 When I read this, this seemed like a silly feature. Then I read that it may be a feature for electronic voting, and that seemed to make sense. Kinda cool, from that perspective. But I’m not totally sure about purposely implementing traceable ring signatures. http://search.ieice.org/bin/summary.php?id=e95-a_1_151

key, but the keys of all the users of his group. A veriﬁer is convinced that the real signer is a member of the group, but cannot exclusively identify the signer. The original protocol required a trusted third party (called the Group Manager), and he was the only one who could trace the signer. The next version called a ring signature, introduced by Rivest et al. in [34], was an autonomous scheme without Group Manager and anonymity revocation. Various modiﬁcations of this scheme appeared later: linkable ring signature [26, 27, 17] allowed to determine if two signatures were produced by the same group member, traceable ring signature [24, 23] limited excessive anonymity by providing possibility to trace the signer of two messages with respect to the same metainformation (or “tag” in terms of [24]). A similar cryptographic construction is also known as a ad-hoc group signature [16, 38]. It emphasizes the arbitrary group formation, whereas group/ring signature schemes rather imply a ﬁxed set of members. For the most part, our solution is based on the work “Traceable ring signature” by E. Fujisaki and K. Suzuki [24]. In order to distinguish the original algorithm and our modiﬁcation we will call the latter a one-time ring signature, stressing the user’s capability to produce only one valid signature under his private key. We weakened the traceability property and kept the linkability only to provide one-timeness: the public key may appear in many foreign verifying sets and the private key can be used for generating a unique anonymous signature. In case of a double spend attempt these two signatures will be linked together, but revealing the signer is not necessary for our purposes. 4.2 Deﬁnitions 4.2.1 Elliptic curve parameters As our base signature algorithm we chose to use the fast scheme EdDSA, which is developed and implemented by D.J. Bernstein et al. [18]. Like Bitcoin’s ECDSA it is based on the elliptic curve discrete logarithm problem, so our scheme could also be applied to Bitcoin in future. Common parameters are: \(q\): a prime number; \(q = 2^{255} - 19\); \(d\): an element of \(\mathbb{F}_q\); \(d = -121665/121666\); \(E\): an elliptic curve equation; \(-x^2 + y^2 = 1 + dx^2y^2\); \(G\): a base point; \(G = (x, -4/5)\); \(l\): a prime order of the base point; \(l = 2^{252} + 27742317777372353535851937790883648493\); \(H_s\): a cryptographic hash function \(\{0, 1\}^* \to \mathbb{F}_q\); \(H_p\): a deterministic hash function \(E(\mathbb{F}_q) \to E(\mathbb{F}_q)\). 4.2.2 Terminology Enhanced privacy requires a new terminology which should not be confused with Bitcoin entities. private ec-key is a standard elliptic curve private key: a number \(a \in [1, l - 1]\); public ec-key is a standard elliptic curve public key: a point \(A = aG\); one-time keypair is a pair of private and public ec-keys; 5 key, but the keys of all the users of his group. A veriﬁer is convinced that the real signer is a member of the group, but cannot exclusively identify the signer. The original protocol required a trusted third party (called the Group Manager), and he was the only one who could trace the signer. The next version called a ring signature, introduced by Rivest et al. in [34], was an autonomous scheme without Group Manager and anonymity revocation. Various modiﬁcations of this scheme appeared later: linkable ring signature [26, 27, 17] allowed to determine if two signatures were produced by the same group member, traceable ring signature [24, 23] limited excessive anonymity by providing possibility to trace the signer of two messages with respect to the same metainformation (or “tag” in terms of [24]). A similar cryptographic construction is also known as a ad-hoc group signature [16, 38]. It emphasizes the arbitrary group formation, whereas group/ring signature schemes rather imply a ﬁxed set of members. For the most part, our solution is based on the work “Traceable ring signature” by E. Fujisaki and K. Suzuki [24]. In order to distinguish the original algorithm and our modiﬁcation we will call the latter a one-time ring signature, stressing the user’s capability to produce only one valid signature under his private key. We weakened the traceability property and kept the linkability only to provide one-timeness: the public key may appear in many foreign verifying sets and the private key can be used for generating a unique anonymous signature. In case of a double spend attempt these two signatures will be linked together, but revealing the signer is not necessary for our purposes. 4.2 Deﬁnitions 4.2.1 Elliptic curve parameters As our base signature algorithm we chose to use the fast scheme EdDSA, which is developed and implemented by D.J. Bernstein et al. [18]. Like Bitcoin’s ECDSA it is based on the elliptic curve discrete logarithm problem, so our scheme could also be applied to Bitcoin in future. Common parameters are: \(q\): a prime number; \(q = 2^{255} - 19\); \(d\): an element of \(\mathbb{F}_q\); \(d = -121665/121666\); \(E\): an elliptic curve equation; \(-x^2 + y^2 = 1 + dx^2y^2\); \(G\): a base point; \(G = (x, -4/5)\); \(l\): a prime order of the base point; \(l = 2^{252} + 27742317777372353535851937790883648493\); \(H_s\): a cryptographic hash function \(\{0, 1\}^* \to \mathbb{F}_q\); \(H_p\): a deterministic hash function \(E(\mathbb{F}_q) \to E(\mathbb{F}_q)\). 4.2.2 Terminology Enhanced privacy requires a new terminology which should not be confused with Bitcoin entities. private ec-key is a standard elliptic curve private key: a number \(a \in [1, l - 1]\); public ec-key is a standard elliptic curve public key: a point \(A = aG\); one-time keypair is a pair of private and public ec-keys; 5 9 Gosh, the author of this whitepaper sure could have worded this better! Let’s say that an employee-owned company wants to take a vote on whether or not to acquire certain new assets, and Alex and Brenda are both employees. The Company provides each employee a message like "I vote yes on Proposition A!" which has the metainformation "issue" [PROP A] and asks them to sign it with a traceable ring signature if they support the proposition. Using a traditional ring signature, a dishonest employee can sign the message multiple times, presumably with diﬀerent nonces, in order to vote as many times as they like. On the other hand, in a traceable ring signature scheme, Alex will go to vote, and her private key will have been used on the issue [PROP A]. If Alex tries to sign a message like "I, Brenda, approve of proposition A!" to "frame" Brenda and double vote, this new message will also have the issue [PROP A]. Since Alex’s private key has already tripped the [PROP A] issue, Alex’s identity will be immediately revealed as a fraud. Which, face it, is pretty cool! Cryptography enforced voting equality. http://link.springer.com/chapter/10.1007/978-3-540-71677-8_13 This paper is interesting, essentially creating an ad-hoc ring signature but without any of the other participant’s consent. The structure of the signature may be diﬀerent; I haven’t dug deep, and I haven’t seen whether it’s secure. https://people.csail.mit.edu/rivest/AdidaHohenbergerRivest-AdHocGroupSignaturesFromHijackedKeypai Ad-hoc group signatures are: ring signatures, which are group signatures with no group managers, no centralization, but allows a member in an ad-hoc group to provably claim that it has (not) issued the anonymous signature on behalf of the group. http://link.springer.com/chapter/10.1007/11908739_9 This isn’t quite correct, from my understanding. And my understanding will likely change as I get deeper into this project. But from my understanding, the hierarchy looks like this. Group sigs: group managers control traceability and the ability of adding or removing members from being signers. Ring sigs: Arbitrary group formation without a group manager. No anonymity revocation. No way to repudiate oneself from a particular signature. With traceable and linkable ring signatures, anonymity is somewhat scaleable. Ad-hoc group signatures: like ring signatures, but members can prove that they did not create a particular signature. This is important when anyone in a group can produce a signature. http://link.springer.com/chapter/10.1007/978-3-540-71677-8_13 Fujisaki and Suzuki’s algorithm is tweaked later by the author to provide one-time-ness. So we will analyze Fujisaki and Suzuki’s algorithm concurrently with the new algorithm rather than going over it here.

key, but the keys of all the users of his group. A veriﬁer is convinced that the real signer is a member of the group, but cannot exclusively identify the signer. The original protocol required a trusted third party (called the Group Manager), and he was the only one who could trace the signer. The next version called a ring signature, introduced by Rivest et al. in [34], was an autonomous scheme without Group Manager and anonymity revocation. Various modiﬁcations of this scheme appeared later: linkable ring signature [26, 27, 17] allowed to determine if two signatures were produced by the same group member, traceable ring signature [24, 23] limited excessive anonymity by providing possibility to trace the signer of two messages with respect to the same metainformation (or “tag” in terms of [24]). A similar cryptographic construction is also known as a ad-hoc group signature [16, 38]. It emphasizes the arbitrary group formation, whereas group/ring signature schemes rather imply a ﬁxed set of members. For the most part, our solution is based on the work “Traceable ring signature” by E. Fujisaki and K. Suzuki [24]. In order to distinguish the original algorithm and our modiﬁcation we will call the latter a one-time ring signature, stressing the user’s capability to produce only one valid signature under his private key. We weakened the traceability property and kept the linkability only to provide one-timeness: the public key may appear in many foreign verifying sets and the private key can be used for generating a unique anonymous signature. In case of a double spend attempt these two signatures will be linked together, but revealing the signer is not necessary for our purposes. 4.2 Deﬁnitions 4.2.1 Elliptic curve parameters As our base signature algorithm we chose to use the fast scheme EdDSA, which is developed and implemented by D.J. Bernstein et al. [18]. Like Bitcoin’s ECDSA it is based on the elliptic curve discrete logarithm problem, so our scheme could also be applied to Bitcoin in future. Common parameters are: \(q\): a prime number; \(q = 2^{255} - 19\); \(d\): an element of \(\mathbb{F}_q\); \(d = -121665/121666\); \(E\): an elliptic curve equation; \(-x^2 + y^2 = 1 + dx^2y^2\); \(G\): a base point; \(G = (x, -4/5)\); \(l\): a prime order of the base point; \(l = 2^{252} + 27742317777372353535851937790883648493\); \(H_s\): a cryptographic hash function \(\{0, 1\}^* \to \mathbb{F}_q\); \(H_p\): a deterministic hash function \(E(\mathbb{F}_q) \to E(\mathbb{F}_q)\). 4.2.2 Terminology Enhanced privacy requires a new terminology which should not be confused with Bitcoin entities. private ec-key is a standard elliptic curve private key: a number \(a \in [1, l - 1]\); public ec-key is a standard elliptic curve public key: a point \(A = aG\); one-time keypair is a pair of private and public ec-keys; 5 key, but the keys of all the users of his group. A veriﬁer is convinced that the real signer is a member of the group, but cannot exclusively identify the signer. The original protocol required a trusted third party (called the Group Manager), and he was the only one who could trace the signer. The next version called a ring signature, introduced by Rivest et al. in [34], was an autonomous scheme without Group Manager and anonymity revocation. Various modiﬁcations of this scheme appeared later: linkable ring signature [26, 27, 17] allowed to determine if two signatures were produced by the same group member, traceable ring signature [24, 23] limited excessive anonymity by providing possibility to trace the signer of two messages with respect to the same metainformation (or “tag” in terms of [24]). A similar cryptographic construction is also known as a ad-hoc group signature [16, 38]. It emphasizes the arbitrary group formation, whereas group/ring signature schemes rather imply a ﬁxed set of members. For the most part, our solution is based on the work “Traceable ring signature” by E. Fujisaki and K. Suzuki [24]. In order to distinguish the original algorithm and our modiﬁcation we will call the latter a one-time ring signature, stressing the user’s capability to produce only one valid signature under his private key. We weakened the traceability property and kept the linkability only to provide one-timeness: the public key may appear in many foreign verifying sets and the private key can be used for generating a unique anonymous signature. In case of a double spend attempt these two signatures will be linked together, but revealing the signer is not necessary for our purposes. 4.2 Deﬁnitions 4.2.1 Elliptic curve parameters As our base signature algorithm we chose to use the fast scheme EdDSA, which is developed and implemented by D.J. Bernstein et al. [18]. Like Bitcoin’s ECDSA it is based on the elliptic curve discrete logarithm problem, so our scheme could also be applied to Bitcoin in future. Common parameters are: \(q\): a prime number; \(q = 2^{255} - 19\); \(d\): an element of \(\mathbb{F}_q\); \(d = -121665/121666\); \(E\): an elliptic curve equation; \(-x^2 + y^2 = 1 + dx^2y^2\); \(G\): a base point; \(G = (x, -4/5)\); \(l\): a prime order of the base point; \(l = 2^{252} + 27742317777372353535851937790883648493\); \(H_s\): a cryptographic hash function \(\{0, 1\}^* \to \mathbb{F}_q\); \(H_p\): a deterministic hash function \(E(\mathbb{F}_q) \to E(\mathbb{F}_q)\). 4.2.2 Terminology Enhanced privacy requires a new terminology which should not be confused with Bitcoin entities. private ec-key is a standard elliptic curve private key: a number \(a \in [1, l - 1]\); public ec-key is a standard elliptic curve public key: a point \(A = aG\); one-time keypair is a pair of private and public ec-keys; 5 10 Linkability in the sense of "linkable ring signatures" means we can tell if two outgoing transactions came from the same source without revealing who the source is. The authors weakened linkability so as to (a) preserve privacy, but still (b) spot any transaction using a private key a second time as invalid. Okay, so this is an order-of-events question. Consider the following scenario. My mining computer will have the current blockchain, it will have it’s own block of transactions it calls legitimate, it will be working on that block in a proof-of-work puzzle, and it will have a list of pending transactions to be added to the next block. It will also be sending any new transactions into that pool of pending transactions. If I do not solve the next block, but someone else does, I get an updated copy of the blockchain. The block I was working on and my list of pending transactions both may have some transactions that are now incorporated into the blockchain. Unravel my pending block, combine that with my list of pending transactions, and call that my pool of pending transactions. Remove any that are now oﬃcially in the blockchain. Now, what do I do? Should I ﬁrst go through and "remove all double-spends"? On the other hand, should I search through the list and make sure that each private key has not yet been used, and if it has been used already in my list, then I received the ﬁrst copy ﬁrst, and hence any further copy is illegitimate. Thus I proceed to simply delete all instances after the ﬁrst of the the same private key. Algebraic geometry has never been my strong suit. http://en.wikipedia.org/wiki/EdDSA Such speed, much wow. THIS is algebraic geometry for the win. Not that I’d know anything about that. Problematically, or not, discrete logs are getting very fast. And quantum computers eat them for breakfast. http://link.springer.com/article/10.1007/s13389-012-0027-1 This becomes a really important number, but there is no explanation or citation to how it was chosen. Simply choosing a single known large prime would be ﬁne, but if there are known facts about this large prime, that could inﬂuence our choice. Diﬀerent variants of cryptonote could choose diﬀerent values of ell, but there is no discussion in this paper about how that choice will aﬀect our choices of other global parameters listed on page 5. This paper needs a section on choosing parameter values.

private user key is a pair \((a, b)\) of two diﬀerent private ec-keys; tracking key is a pair \((a, B)\) of private and public ec-key (where \(B = bG\) and \(a \neq b\)); public user key is a pair \((A, B)\) of two public ec-keys derived from \((a, b)\); standard address is a representation of a public user key given into human friendly string with error correction; truncated address is a representation of the second half (point \(B\)) of a public user key given into human friendly string with error correction. The transaction structure remains similar to the structure in Bitcoin: every user can choose several independent incoming payments (transactions outputs), sign them with the corresponding private keys and send them to diﬀerent destinations. Contrary to Bitcoin’s model, where a user possesses unique private and public key, in the proposed model a sender generates a one-time public key based on the recipient’s address and some random data. In this sense, an incoming transaction for the same recipient is sent to a one-time public key (not directly to a unique address) and only the recipient can recover the corresponding private part to redeem his funds (using his unique private key). The recipient can spend the funds using a ring signature, keeping his ownership and actual spending anonymous. The details of the protocol are explained in the next subsections. 4.3 Unlinkable payments Classic Bitcoin addresses, once being published, become unambiguous identiﬁer for incoming payments, linking them together and tying to the recipient’s pseudonyms. If someone wants to receive an “untied” transaction, he should convey his address to the sender by a private channel. If he wants to receive diﬀerent transactions which cannot be proven to belong to the same owner he should generate all the diﬀerent addresses and never publish them in his own pseudonym. Public Private Alice Carol Bob’s addr 1 Bob’s addr 2 Bob’s key 1 Bob’s key 2 Bob Fig. 2. Traditional Bitcoin keys/transactions model. We propose a solution allowing a user to publish a single address and receive unconditional unlinkable payments. The destination of each CryptoNote output (by default) is a public key, derived from recipient’s address and sender’s random data. The main advantage against Bitcoin is that every destination key is unique by default (unless the sender uses the same data for each of his transactions to the same recipient). Hence, there is no such issue as “address reuse” by design and no observer can determine if any transactions were sent to a speciﬁc address or link two addresses together. 6 private user key is a pair \((a, b)\) of two diﬀerent private ec-keys; tracking key is a pair \((a, B)\) of private and public ec-key (where \(B = bG\) and \(a \neq b\)); public user key is a pair \((A, B)\) of two public ec-keys derived from \((a, b)\); standard address is a representation of a public user key given into human friendly string with error correction; truncated address is a representation of the second half (point \(B\)) of a public user key given into human friendly string with error correction. The transaction structure remains similar to the structure in Bitcoin: every user can choose several independent incoming payments (transactions outputs), sign them with the corresponding private keys and send them to diﬀerent destinations. Contrary to Bitcoin’s model, where a user possesses unique private and public key, in the proposed model a sender generates a one-time public key based on the recipient’s address and some random data. In this sense, an incoming transaction for the same recipient is sent to a one-time public key (not directly to a unique address) and only the recipient can recover the corresponding private part to redeem his funds (using his unique private key). The recipient can spend the funds using a ring signature, keeping his ownership and actual spending anonymous. The details of the protocol are explained in the next subsections. 4.3 Unlinkable payments Classic Bitcoin addresses, once being published, become unambiguous identiﬁer for incoming payments, linking them together and tying to the recipient’s pseudonyms. If someone wants to receive an “untied” transaction, he should convey his address to the sender by a private channel. If he wants to receive diﬀerent transactions which cannot be proven to belong to the same owner he should generate all the diﬀerent addresses and never publish them in his own pseudonym. Public Private Alice Carol Bob’s addr 1 Bob’s addr 2 Bob’s key 1 Bob’s key 2 Bob Fig. 2. Traditional Bitcoin keys/transactions model. We propose a solution allowing a user to publish a single address and receive unconditional unlinkable payments. The destination of each CryptoNote output (by default) is a public key, derived from recipient’s address and sender’s random data. The main advantage against Bitcoin is that every destination key is unique by default (unless the sender uses the same data for each of his transactions to the same recipient). Hence, there is no such issue as “address reuse” by design and no observer can determine if any transactions were sent to a speciﬁc address or link two addresses together. 6 11 So this is like Bitcoin, but with inﬁnite, anonymous PO Boxes, redeemable only by the receiver generating a private key that is as anonymous as a ring signature can be. Bitcoin works this way. If Alex has 0.112 Bitcoin in her wallet she just received from Frank, she really has a signed message "I, [FRANK], send 0.112 Bitcoin to [alex] + H0 + N0" where 1) Frank has signed the message with his private key [FRANK], 2) Frank has signed the message with Alex’s public key, [alex], 3) Frank has included some form of the history of the bitcoin, H0, and 4) Frank includes a random bit of data called the nonce, N0. If Alex then wants to send 0.011 Bitcoin to Charlene, she will take Frank’s message, and she will set that to H1, and sign two messages: one for her transaction, and one for the change. H1= "I, [FRANK], send 0.112 Bitcoin to [alex] + H0 + N" "I, [ALEX], send 0.011 Bitcoin to [charlene] + H1 + N1" "I, [ALEX], send 0.101 Bitcoin as change to [alex] + H1 + N2." where Alex signs both messages with her private key [ALEX], the ﬁrst message with Charlene’s public key [charlene], the second message with Alex’s public key [alex], and including the histories and some randomly generated nonces N1 and N2 appropriately. Cryptonote works this way: If Alex has 0.112 Cryptonote in her wallet she just received from Frank, she really has a signed message "I, [someone in an ad-hoc group], send 0.112 Cryptonote to [a one-time address] + H0 + N0." Alex discovered that this was her money by checking her private key [ALEX] against [a one-time address] for every passing message, and if she wishes to spend it she does so in the following way. She chooses a recipient of the money, perhaps Charlene has started voting for drone-strikes so Alex wants to send money to Brenda instead. So Alex looks up Brenda’s public key, [brenda], and uses her own private key, [ALEX], to generate a one-time address [ALEX+brenda]. She then chooses an arbitrary collection C from the network of cryptonote users and she constructs a ring signature from this ad-hoc group. We set our history as the previous message, add nonces, and proceed as usual? H1 = "I, [someone in an ad-hoc group], send 0.112 Cryptonote to [a one-time address] + H0 + N0." "I, [someone in the collection C], send 0.011 Cryptonote to [one-time-address-made-fromALEX+brenda] + H1 + N1" "I, [someone in the collection C], send 0.101 Cryptonote as change to [one-time-address-madefrom-ALEX+alex] + H1 + N2" Now, Alex and Brenda both scan all incoming messages for any one-time-addresses that were created using their key. If they ﬁnd any, then that message is their very own brand new cryptonote! And even then, the transaction will still hit the blockchain. If the coins entering that address are known to be sent from criminals, political contributors, or from committees and accounts with strict budgets (i.e. embezzling), or if the new owner of these coins ever makes a mistake and sends these coins to a common address with coins he is known to own, the anonymity jig is up in bitcoin.

private user key is a pair \((a, b)\) of two diﬀerent private ec-keys; tracking key is a pair \((a, B)\) of private and public ec-key (where \(B = bG\) and \(a \neq b\)); public user key is a pair \((A, B)\) of two public ec-keys derived from \((a, b)\); standard address is a representation of a public user key given into human friendly string with error correction; truncated address is a representation of the second half (point \(B\)) of a public user key given into human friendly string with error correction. The transaction structure remains similar to the structure in Bitcoin: every user can choose several independent incoming payments (transactions outputs), sign them with the corresponding private keys and send them to diﬀerent destinations. Contrary to Bitcoin’s model, where a user possesses unique private and public key, in the proposed model a sender generates a one-time public key based on the recipient’s address and some random data. In this sense, an incoming transaction for the same recipient is sent to a one-time public key (not directly to a unique address) and only the recipient can recover the corresponding private part to redeem his funds (using his unique private key). The recipient can spend the funds using a ring signature, keeping his ownership and actual spending anonymous. The details of the protocol are explained in the next subsections. 4.3 Unlinkable payments Classic Bitcoin addresses, once being published, become unambiguous identiﬁer for incoming payments, linking them together and tying to the recipient’s pseudonyms. If someone wants to receive an “untied” transaction, he should convey his address to the sender by a private channel. If he wants to receive diﬀerent transactions which cannot be proven to belong to the same owner he should generate all the diﬀerent addresses and never publish them in his own pseudonym. Public Private Alice Carol Bob’s addr 1 Bob’s addr 2 Bob’s key 1 Bob’s key 2 Bob Fig. 2. Traditional Bitcoin keys/transactions model. We propose a solution allowing a user to publish a single address and receive unconditional unlinkable payments. The destination of each CryptoNote output (by default) is a public key, derived from recipient’s address and sender’s random data. The main advantage against Bitcoin is that every destination key is unique by default (unless the sender uses the same data for each of his transactions to the same recipient). Hence, there is no such issue as “address reuse” by design and no observer can determine if any transactions were sent to a speciﬁc address or link two addresses together. 6 private user key is a pair \((a, b)\) of two diﬀerent private ec-keys; tracking key is a pair \((a, B)\) of private and public ec-key (where \(B = bG\) and \(a \neq b\)); public user key is a pair \((A, B)\) of two public ec-keys derived from \((a, b)\); standard address is a representation of a public user key given into human friendly string with error correction; truncated address is a representation of the second half (point \(B\)) of a public user key given into human friendly string with error correction. The transaction structure remains similar to the structure in Bitcoin: every user can choose several independent incoming payments (transactions outputs), sign them with the corresponding private keys and send them to diﬀerent destinations. Contrary to Bitcoin’s model, where a user possesses unique private and public key, in the proposed model a sender generates a one-time public key based on the recipient’s address and some random data. In this sense, an incoming transaction for the same recipient is sent to a one-time public key (not directly to a unique address) and only the recipient can recover the corresponding private part to redeem his funds (using his unique private key). The recipient can spend the funds using a ring signature, keeping his ownership and actual spending anonymous. The details of the protocol are explained in the next subsections. 4.3 Unlinkable payments Classic Bitcoin addresses, once being published, become unambiguous identiﬁer for incoming payments, linking them together and tying to the recipient’s pseudonyms. If someone wants to receive an “untied” transaction, he should convey his address to the sender by a private channel. If he wants to receive diﬀerent transactions which cannot be proven to belong to the same owner he should generate all the diﬀerent addresses and never publish them in his own pseudonym. Public Private Alice Carol Bob’s addr 1 Bob’s addr 2 Bob’s key 1 Bob’s key 2 Bob Fig. 2. Traditional Bitcoin keys/transactions model. We propose a solution allowing a user to publish a single address and receive unconditional unlinkable payments. The destination of each CryptoNote output (by default) is a public key, derived from recipient’s address and sender’s random data. The main advantage against Bitcoin is that every destination key is unique by default (unless the sender uses the same data for each of his transactions to the same recipient). Hence, there is no such issue as “address reuse” by design and no observer can determine if any transactions were sent to a speciﬁc address or link two addresses together. 6 12 Hence, rather than users sending coins from address (which is really a public key) to address (another public key) using their private keys, users are sending coins from one-time PO-box (which is generating using your friends public key) to one-time PO-box (similarly) using your own private keys. In a sense, we’re saying "Okay, everyone take your hands oﬀthe money while it’s being transferred around! It’s simply enough to know that our keys can open that box and that we know how much money is in the box. Never put your ﬁngerprints on the PO Box or actually use it, just trade the box ﬁlled with cash itself. That way we don’t know who sent what, but the contents of these public addresses are still frictionless, fungible, divisible, and still possess all the other nice qualities of money we desire like bitcoin." An inﬁnite set of PO boxes. You publish an address, I have a private key. I use my private key and your address, and some random data, to generate a public key. The algorithm is designed such that, since your address was used to generate the public key, only YOUR private key works to unlock the message. An observer, Eve, sees you publish your address, and sees the public key I announce. However, she doesn’t know if I announced my public key based on your address or hers, or Brenda’s or Charlene’s, or whoever’s. She checks her private key against the public key I announced and sees it doesn’t work; it isn’t her money. She doens’t know anyone else’s private key, and only the recipient of the message has the private key that can unlock the message. So no one listening in can determine who received the money much less take the money.

Public Private Alice Carol One-time key One-time key One-time key Bob Bob’s Key Bob’s Address Fig. 3. CryptoNote keys/transactions model. First, the sender performs a Diﬃe-Hellman exchange to get a shared secret from his data and half of the recipient’s address. Then he computes a one-time destination key, using the shared secret and the second half of the address. Two diﬀerent ec-keys are required from the recipient for these two steps, so a standard CryptoNote address is nearly twice as large as a Bitcoin wallet address. The receiver also performs a Diﬃe-Hellman exchange to recover the corresponding secret key. A standard transaction sequence goes as follows: 1. Alice wants to send a payment to Bob, who has published his standard address. She unpacks the address and gets Bob’s public key \((A, B)\). 2. Alice generates a random \(r \in [1, l-1]\) and computes a one-time public key \(P = H_s(rA)G + B\). 3. Alice uses \(P\) as a destination key for the output and also packs value \(R = rG\) (as a part of the Diﬃe-Hellman exchange) somewhere into the transaction. Note that she can create other outputs with unique public keys: diﬀerent recipients’ keys \((A_i, B_i)\) imply diﬀerent \(P_i\) even with the same \(r\). Transaction Tx public key Tx output Amount Destination key \(R = rG\) \(P = H_s(rA)G + B\) Receiver’s public key Sender’s random data \(r\) \((A, B)\) Fig. 4. Standard transaction structure. 4. Alice sends the transaction. 5. Bob checks every passing transaction with his private key \((a, b)\), and computes \(P' = H_s(aR)G + B\). If Alice’s transaction for with Bob as the recipient was among them, then \(aR = arG = rA\) and \(P' = P\). 7 Public Private Alice Carol One-time key One-time key One-time key Bob Bob’s Key Bob’s Address Fig. 3. CryptoNote keys/transactions model. First, the sender performs a Diﬃe-Hellman exchange to get a shared secret from his data and half of the recipient’s address. Then he computes a one-time destination key, using the shared secret and the second half of the address. Two diﬀerent ec-keys are required from the recipient for these two steps, so a standard CryptoNote address is nearly twice as large as a Bitcoin wallet address. The receiver also performs a Diﬃe-Hellman exchange to recover the corresponding secret key. A standard transaction sequence goes as follows: 1. Alice wants to send a payment to Bob, who has published his standard address. She unpacks the address and gets Bob’s public key \((A, B)\). 2. Alice generates a random \(r \in [1, l-1]\) and computes a one-time public key \(P = H_s(rA)G + B\). 3. Alice uses \(P\) as a destination key for the output and also packs value \(R = rG\) (as a part of the Diﬃe-Hellman exchange) somewhere into the transaction. Note that she can create other outputs with unique public keys: diﬀerent recipients’ keys \((A_i, B_i)\) imply diﬀerent \(P_i\) even with the same \(r\). Transaction Tx public key Tx output Amount Destination key \(R = rG\) \(P = H_s(rA)G + B\) Receiver’s public key Sender’s random data \(r\) \((A, B)\) Fig. 4. Standard transaction structure. 4. Alice sends the transaction. 5. Bob checks every passing transaction with his private key \((a, b)\), and computes \(P' = H_s(aR)G + B\). If Alice’s transaction for with Bob as the recipient was among them, then \(aR = arG = rA\) and \(P' = P\). 7 13 I wonder how much of a pain in the neck it would be to implement a choice of cryptography scheme. Elliptic or otherwise. So if some scheme is broken in the future, the currency switches without concern. Probably a big pain in the ass. Okay, this is exactly what I just explained in my previous comment. The Diﬃe-Hellman-type exchanges are neato. Say Alex and Brenda each have a secret number, A and B, and a number they don’t care about keeping secret, a and b. They wish to generate a shared secret without Eva discovering it. Diﬃe and Hellman came up with a way for Alex and Brenda to share the public numbers a and b, but not the private numbers A and B, and generate a shared secret, K. Using this shared secret, K, without any Eva listening in being able to generate the same K, Alex and Brenda can now use K as a secret encryption key and pass secret messages back and forth. Here’s how it CAN work, although it should work with much larger numbers than 100. We’ll use 100 because working over the integers modulo 100 is equivalent to "throwing out all but the last two digit of a number." Alex and Brenda each choose A, a, B, and b. They keep A and B secret. Alex tells Brenda her value of a modulo 100 (just the last two digits) and Brenda tells Alex her value of b modulo 100. Now Eva knows (a,b) modulo 100. But Alex knows (a,b,A) so she can compute x=abA modulo 100. Alex chops oﬀall but the last digit because we’re working under the integers modulo 100 again. Similarly, Brenda knows (a,b,B) so she can compute y=abB modulo 100. Alex can now publish x and Brenda can publish y. But now Alex can compute yA = abBA modulo 100, and Brenda can compute xB = abBA modulo 100. They both know the same number! But all Eva has heard is (a,b,abA,abB). She has no easy way of computing abA*B. Now, this is the easiest and least secure way of thinking about the Diﬃe-Hellman exchange. More secure versions exist. But most versions work because integer factorization and discrete logarithms are diﬃcult, and both of those problems are easily solved by quantum computers. I will look into whether any versions that are resistant to quantum exist. http://en.wikipedia.org/wiki/Diﬃe%E2%80%93Hellman_key_exchange The "standard txn sequence" listed here is missing a whole bunch of steps, like SIGNATURES. They’re just taken for granted in here. Which is really bad, because the order in which we sign stuﬀ, the information included in the signed message, and so on... all of this is extremely important to the protocol. Getting one or two of the steps wrong, even slightly out of order, while implementing "the standard transaction sequence" could throw the security of the whole system into question. Furthermore, the proofs presented later in the paper may not be suﬃciently rigorous if the framework under which they work is as loosely deﬁned as in this section.

Public Private Alice Carol One-time key One-time key One-time key Bob Bob’s Key Bob’s Address Fig. 3. CryptoNote keys/transactions model. First, the sender performs a Diﬃe-Hellman exchange to get a shared secret from his data and half of the recipient’s address. Then he computes a one-time destination key, using the shared secret and the second half of the address. Two diﬀerent ec-keys are required from the recipient for these two steps, so a standard CryptoNote address is nearly twice as large as a Bitcoin wallet address. The receiver also performs a Diﬃe-Hellman exchange to recover the corresponding secret key. A standard transaction sequence goes as follows: 1. Alice wants to send a payment to Bob, who has published his standard address. She unpacks the address and gets Bob’s public key \((A, B)\). 2. Alice generates a random \(r \in [1, l-1]\) and computes a one-time public key \(P = H_s(rA)G + B\). 3. Alice uses \(P\) as a destination key for the output and also packs value \(R = rG\) (as a part of the Diﬃe-Hellman exchange) somewhere into the transaction. Note that she can create other outputs with unique public keys: diﬀerent recipients’ keys \((A_i, B_i)\) imply diﬀerent \(P_i\) even with the same \(r\). Transaction Tx public key Tx output Amount Destination key \(R = rG\) \(P = H_s(rA)G + B\) Receiver’s public key Sender’s random data \(r\) \((A, B)\) Fig. 4. Standard transaction structure. 4. Alice sends the transaction. 5. Bob checks every passing transaction with his private key \((a, b)\), and computes \(P' = H_s(aR)G + B\). If Alice’s transaction for with Bob as the recipient was among them, then \(aR = arG = rA\) and \(P' = P\). 7 Public Private Alice Carol One-time key One-time key One-time key Bob Bob’s Key Bob’s Address Fig. 3. CryptoNote keys/transactions model. First, the sender performs a Diﬃe-Hellman exchange to get a shared secret from his data and half of the recipient’s address. Then he computes a one-time destination key, using the shared secret and the second half of the address. Two diﬀerent ec-keys are required from the recipient for these two steps, so a standard CryptoNote address is nearly twice as large as a Bitcoin wallet address. The receiver also performs a Diﬃe-Hellman exchange to recover the corresponding secret key. A standard transaction sequence goes as follows: 1. Alice wants to send a payment to Bob, who has published his standard address. She unpacks the address and gets Bob’s public key \((A, B)\). 2. Alice generates a random \(r \in [1, l-1]\) and computes a one-time public key \(P = H_s(rA)G + B\). 3. Alice uses \(P\) as a destination key for the output and also packs value \(R = rG\) (as a part of the Diﬃe-Hellman exchange) somewhere into the transaction. Note that she can create other outputs with unique public keys: diﬀerent recipients’ keys \((A_i, B_i)\) imply diﬀerent \(P_i\) even with the same \(r\). Transaction Tx public key Tx output Amount Destination key \(R = rG\) \(P = H_s(rA)G + B\) Receiver’s public key Sender’s random data \(r\) \((A, B)\) Fig. 4. Standard transaction structure. 4. Alice sends the transaction. 5. Bob checks every passing transaction with his private key \((a, b)\), and computes \(P' = H_s(aR)G + B\). If Alice’s transaction for with Bob as the recipient was among them, then \(aR = arG = rA\) and \(P' = P\). 7 14 Note that the author(s?) do a terrible job of keeping their terminology straight throughout the text, but especially in this next bit. Next incarnation of this paper will necessarily be much more rigorous. In the text they refer to P as their one-time public key. In the diagram, they refer to R as their "Tx public key" and P as their "Destination key." If I were going to re-write this, I’d very speciﬁcally lay out some terminology before discussing these sections. This ell is massive. See page 5. Who chooses ell? Diagram illustrates that the transaction public key \(R = rG\), which is random and chosen by the sender, is not part of Tx output. This is because it could be the same for multiple transactions to multiple people, and isn’t used LATER to spend. A fresh R is generated every time you want to broadcast a new CryptoNote transaction. Furthermore, R is only used to check if you are the recipient of the transaction. It’s not junk data, but it’s junk to anyone without the private keys associated with (A,B). The Destination key, on the other hand, \(P = H_s(rA)G + B\) is part of Tx output. Everyone riﬂing through every passing transaction’s data must check their own generated P* against this P to see if they own this passing transaction. Anyone with an unspent transaction output (UTXO) will have a bunch of these Ps laying around with amounts. In order to spend, they sign some new message including P. Alice must sign this transaction with one-time private key(s) associated with the unspent transaction output(s) Destination Key(s). Each destination key owned by Alice comes equipped with a one-time private key also owned (presumably) by Alice. Every time Alice wants to send the contents of a destination key to me, or Bob, or Brenda, or Charlie or Charlene, she uses her private key to sign the transaction. Upon receipt of transaction, I will receive a new Tx public key, a new Destination public key, and I will be able to recover a new one-time private key x. Combining my one-time private key, x, with new transaction’s public Destination key(s) is how we send a new transaction

Bob can recover the corresponding one-time private key: \(x = H_s(aR) + b\), so as \(P = xG\). He can spend this output at any time by signing a transaction with \(x\). Transaction Tx public key Tx output Amount Destination key \(P' = H_s(aR)G + bG\) one-time public key \(x = H_s(aR) + b\) one-time private key Receiver’s private key \((a, b)\) \(R\) \(P'\) \(\stackrel{?}{=} P\) Fig. 5. Incoming transaction check. As a result Bob gets incoming payments, associated with one-time public keys which are unlinkable for a spectator. Some additional notes: • When Bob “recognizes” his transactions (see step 5) he practically uses only half of his private information: \((a, B)\). This pair, also known as the tracking key, can be passed to a third party (Carol). Bob can delegate her the processing of new transactions. Bob doesn’t need to explicitly trust Carol, because she can’t recover the one-time secret key \(p\) without Bob’s full private key \((a, b)\). This approach is useful when Bob lacks bandwidth or computation power (smartphones, hardware wallets etc.). • In case Alice wants to prove she sent a transaction to Bob’s address she can either disclose \(r\) or use any kind of zero-knowledge protocol to prove she knows \(r\) (for example by signing the transaction with \(r\)). • If Bob wants to have an audit compatible address where all incoming transaction are linkable, he can either publish his tracking key or use a truncated address. That address represent only one public ec-key \(B\), and the remaining part required by the protocol is derived from it as follows: \(a = H_s(B)\) and \(A = H_s(B)G\). In both cases every person is able to “recognize” all of Bob’s incoming transaction, but, of course, none can spend the funds enclosed within them without the secret key \(b\). 4.4 One-time ring signatures A protocol based on one-time ring signatures allows users to achieve unconditional unlinkability. Unfortunately, ordinary types of cryptographic signatures permit to trace transactions to their respective senders and receivers. Our solution to this deﬁciency lies in using a diﬀerent signature type than those currently used in electronic cash systems. We will ﬁrst provide a general description of our algorithm with no explicit reference to electronic cash. A one-time ring signature contains four algorithms: (GEN, SIG, VER, LNK): GEN: takes public parameters and outputs an ec-pair \((P, x)\) and a public key \(I\). SIG: takes a message \(m\), a set \(S'\) of public keys \(\{P_i\}_{i \neq s}\), a pair \((P_s, x_s)\) and outputs a signature \(\sigma\) and a set \(S = S' \cup \{P_s\}\). 8
Bob can recover the corresponding one-time private key: \(x = H_s(aR) + b\), so as \(P = xG\). He can spend this output at any time by signing a transaction with \(x\). Transaction Tx public key Tx output Amount Destination key \(P' = H_s(aR)G + bG\) one-time public key \(x = H_s(aR) + b\) one-time private key Receiver’s private key \((a, b)\) \(R\) \(P'\) \(\stackrel{?}{=} P\) Fig. 5. Incoming transaction check. As a result Bob gets incoming payments, associated with one-time public keys which are unlinkable for a spectator. Some additional notes: • When Bob “recognizes” his transactions (see step 5) he practically uses only half of his private information: \((a, B)\). This pair, also known as the tracking key, can be passed to a third party (Carol). Bob can delegate her the processing of new transactions. Bob doesn’t need to explicitly trust Carol, because she can’t recover the one-time secret key \(p\) without Bob’s full private key \((a, b)\). This approach is useful when Bob lacks bandwidth or computation power (smartphones, hardware wallets etc.). • In case Alice wants to prove she sent a transaction to Bob’s address she can either disclose \(r\) or use any kind of zero-knowledge protocol to prove she knows \(r\) (for example by signing the transaction with \(r\)). • If Bob wants to have an audit compatible address where all incoming transaction are linkable, he can either publish his tracking key or use a truncated address. That address represent only one public ec-key \(B\), and the remaining part required by the protocol is derived from it as follows: \(a = H_s(B)\) and \(A = H_s(B)G\). In both cases every person is able to “recognize” all of Bob’s incoming transaction, but, of course, none can spend the funds enclosed within them without the secret key \(b\). 4.4 One-time ring signatures A protocol based on one-time ring signatures allows users to achieve unconditional unlinkability. Unfortunately, ordinary types of cryptographic signatures permit to trace transactions to their respective senders and receivers. Our solution to this deﬁciency lies in using a diﬀerent signature type than those currently used in electronic cash systems. We will ﬁrst provide a general description of our algorithm with no explicit reference to electronic cash. A one-time ring signature contains four algorithms: (GEN, SIG, VER, LNK): GEN: takes public parameters and outputs an ec-pair \((P, x)\) and a public key \(I\). SIG: takes a message \(m\), a set \(S'\) of public keys \(\{P_i\}_{i \neq s}\), a pair \((P_s, x_s)\) and outputs a signature \(\sigma\) and a set \(S = S' \cup \{P_s\}\). 8 15 What does an unspent transaction output look like here? The diagram suggests that transaction output consists only of two data points: amount and destination key. But this isn’t suﬃcient because when I try to spend this "output" I will still need to know R=rG. Remember, r is chosen by the sender, and R is a) used to recognize incoming cryptonotes as your own and b) used to generate the one-time private key used to "claim" your cryptonote. The part about this that I don’t understand? Taking the theoretical "okay, we have these signatures and transactions, and we pass ’em back and forth" into the world of programming "okay what information speciﬁcally makes up an individual UTXO?" Best way to answer that question is to dig into the body of completely uncommented code. Way to go, bytecoin team. Recall: linkability means "did the same person send?" and unlinkability means "did the same person receive?". So a system can be linkable or non-linkable, unlinkable or non-unlinkable. Annoying, I know. So when Nic van Saberhagen here says "...incoming payments [are] associated with one-time public keys which are unlinkable for a spectator," let’s see what he means. First, consider a situation in which Alice sends Bob two separate transactions from the same address to the same address. In the Bitcoin universe, Alice has already made the mistake of sending from the same address and so the transaction has failed our desire for limited linkability. Furthermore, since she sent the money to the same address, she’s failed our desire for unlinkability. This bitcoin transaction was both (totally) linkable and non-unlinkable. On the other hand, in the cryptonote universe, let’s say that Alice sends Bob some cryptonote, using Bob’s public address. She chooses as her obfuscating set of public keys all known public keys in the Washington DC metro area. Alex generates a one-time public key using her own information and Bob’s public information. She sends the money oﬀ, and any observer will only be able to glean "Someone from the Washington DC metro area sent 2.3 cryptonotes to the one-time public address XYZ123." We have a probabilistic control over linkability here, so we’ll call this "almost non-linkable." We also only see the one-time public keys money is sent to. Even if we suspected the receiver was Bob, we don’t have his private keys and so we can’t test whether a passing transaction belongs to Bob let alone generate his one-time private key to redeem his cryptonote. So this is, in fact, totally "unlinkable." So, this is the neatest trick of all. Who wants to really trust another MtGox? We may be comfortable storing some amount of BTC on Coinbase, but the ultimate in bitcoin security is a physical wallet. Which is inconvenient. In this case, you can trustlessly give away half of your private key without compromising your own ability to spend money. When doing this, all you are doing is telling someone how to break unlinkability. The other properties of CN acting like a currency are preserved, like proof against double spending and whatnot.
Bob can recover the corresponding one-time private key: \(x = H_s(aR) + b\), so as \(P = xG\). He can spend this output at any time by signing a transaction with \(x\). Transaction Tx public key Tx output Amount Destination key \(P' = H_s(aR)G + bG\) one-time public key \(x = H_s(aR) + b\) one-time private key Receiver’s private key \((a, b)\) \(R\) \(P'\) \(\stackrel{?}{=} P\) Fig. 5. Incoming transaction check. As a result Bob gets incoming payments, associated with one-time public keys which are unlinkable for a spectator. Some additional notes: • When Bob “recognizes” his transactions (see step 5) he practically uses only half of his private information: \((a, B)\). This pair, also known as the tracking key, can be passed to a third party (Carol). Bob can delegate her the processing of new transactions. Bob doesn’t need to explicitly trust Carol, because she can’t recover the one-time secret key \(p\) without Bob’s full private key \((a, b)\). This approach is useful when Bob lacks bandwidth or computation power (smartphones, hardware wallets etc.). • In case Alice wants to prove she sent a transaction to Bob’s address she can either disclose \(r\) or use any kind of zero-knowledge protocol to prove she knows \(r\) (for example by signing the transaction with \(r\)). • If Bob wants to have an audit compatible address where all incoming transaction are linkable, he can either publish his tracking key or use a truncated address. That address represent only one public ec-key \(B\), and the remaining part required by the protocol is derived from it as follows: \(a = H_s(B)\) and \(A = H_s(B)G\). In both cases every person is able to “recognize” all of Bob’s incoming transaction, but, of course, none can spend the funds enclosed within them without the secret key \(b\). 4.4 One-time ring signatures A protocol based on one-time ring signatures allows users to achieve unconditional unlinkability. Unfortunately, ordinary types of cryptographic signatures permit to trace transactions to their respective senders and receivers. Our solution to this deﬁciency lies in using a diﬀerent signature type than those currently used in electronic cash systems. We will ﬁrst provide a general description of our algorithm with no explicit reference to electronic cash. A one-time ring signature contains four algorithms: (GEN, SIG, VER, LNK): GEN: takes public parameters and outputs an ec-pair \((P, x)\) and a public key \(I\). SIG: takes a message \(m\), a set \(S'\) of public keys \(\{P_i\}_{i \neq s}\), a pair \((P_s, x_s)\) and outputs a signature \(\sigma\) and a set \(S = S' \cup \{P_s\}\). 8
Bob can recover the corresponding one-time private key: \(x = H_s(aR) + b\), so as \(P = xG\). He can spend this output at any time by signing a transaction with \(x\). Transaction Tx public key Tx output Amount Destination key \(P' = H_s(aR)G + bG\) one-time public key \(x = H_s(aR) + b\) one-time private key Receiver’s private key \((a, b)\) \(R\) \(P'\) \(\stackrel{?}{=} P\) Fig. 5. Incoming transaction check. As a result Bob gets incoming payments, associated with one-time public keys which are unlinkable for a spectator. Some additional notes: • When Bob “recognizes” his transactions (see step 5) he practically uses only half of his private information: \((a, B)\). This pair, also known as the tracking key, can be passed to a third party (Carol). Bob can delegate her the processing of new transactions. Bob doesn’t need to explicitly trust Carol, because she can’t recover the one-time secret key \(p\) without Bob’s full private key \((a, b)\). This approach is useful when Bob lacks bandwidth or computation power (smartphones, hardware wallets etc.). • In case Alice wants to prove she sent a transaction to Bob’s address she can either disclose \(r\) or use any kind of zero-knowledge protocol to prove she knows \(r\) (for example by signing the transaction with \(r\)). • If Bob wants to have an audit compatible address where all incoming transaction are linkable, he can either publish his tracking key or use a truncated address. That address represent only one public ec-key \(B\), and the remaining part required by the protocol is derived from it as follows: \(a = H_s(B)\) and \(A = H_s(B)G\). In both cases every person is able to “recognize” all of Bob’s incoming transaction, but, of course, none can spend the funds enclosed within them without the secret key \(b\). 4.4 One-time ring signatures A protocol based on one-time ring signatures allows users to achieve unconditional unlinkability. Unfortunately, ordinary types of cryptographic signatures permit to trace transactions to their respective senders and receivers. Our solution to this deﬁciency lies in using a diﬀerent signature type than those currently used in electronic cash systems. We will ﬁrst provide a general description of our algorithm with no explicit reference to electronic cash. A one-time ring signature contains four algorithms: (GEN, SIG, VER, LNK): GEN: takes public parameters and outputs an ec-pair \((P, x)\) and a public key \(I\). SIG: takes a message \(m\), a set \(S'\) of public keys \(\{P_i\}_{i \neq s}\), a pair \((P_s, x_s)\) and outputs a signature \(\sigma\) and a set \(S = S' \cup \{P_s\}\). 8 16 Yes, so now we have a) a payment address and b) a payment ID. A critic could ask "do we really need to do this? After all, if a merchant receives 112.00678952 CN exactly, and that was my order, and I have a screenshot or a receipt or whatever, isn’t that insane degree of precision suﬃcient?" The answer is "maybe, most of the time, in day-to-day, face-to-face transactions." However, the more common situation (especially in the digial world) is this: a merchant sells a set of objects, each with a ﬁxed price. Say object A is 0.001 CN, object B is 0.01 CN and object C is 0.1 CN. Now, if the merchant receives an order for 1.618 CN, there are many many (many!) ways to arrange an order for a customer. And so without some sort of payment ID, identifying the so-called "unique" order of a customer with the so-called "unique" cost of their order becomes impossible. Even funnier: if everything in my online store costs exactly 1.0 CN, and I get 1000 customers a day? And you want to prove that you bought exactly 3 objects two weeks ago? Without a payment ID? Good luck, buddy. Long story short: When Bob publishes a payment address, he may end up also publishing a payment ID as well (see, e.g. Poloniex XMR deposits). This is diﬀerent than what is described in the text here where Alice is the one who generates the payment ID. There must be some way for Bob to generate a payment ID as well. \((a, B)\) Recall that the tracking key \((a, B)\) can be published; losing the secrecy of the value for ’a’ will not violate your ability to spend or allow folks to steal from you (I think... that would have to be proven), it will simply allow folks to see all incoming transactions. A truncated address, as described in this paragraph, simply takes the "private" part of the key and generates it from the "public" part. Revealing the value for ’a’ will remove non-linkability but will preserve the rest of the transactions. The author means "not unlinkable" because unlinkable refers to the receiver and linkable refers to the sender. It’s also clear the author didn’t realize that there were two diﬀerent aspects to linkability. Since, after all, the transaction is a directed object on a graph, there will be two questions: "are these two transactions going to the same person?" and "are these two transactions coming from the same person?" This is a "no-going-back" policy under which the unlinkability property of CryptoNote is conditional. That is to say, Bob can choose his incoming transactions to be not unlinkable using this policy. This is a claim they prove under the Random Oracle Model. We’ll get to that; the Random Oracle has pros and cons.

VER: takes a message \(m\), a set \(S\), a signature \(\sigma\) and outputs "true" or "false". LNK: takes a set \(I = \{I_i\}\), a signature \(\sigma\) and outputs "linked" or "indep". The idea behind the protocol is fairly simple: a user produces a signature which can be checked by a set of public keys rather than a unique public key. The identity of the signer is indistinguishable from the other users whose public keys are in the set until the owner produces a second signature using the same keypair. Private keys \(x_0\) \(\cdots\) \(x_i\) \(\cdots\) \(x_n\) Public keys \(P_0\) \(\cdots\) \(P_i\) \(\cdots\) \(P_n\) Ring Signature sign verify Fig. 6. Ring signature anonymity. GEN: The signer picks a random secret key \(x \in [1, l-1]\) and computes the corresponding public key \(P = xG\). Additionally he computes another public key \(I = xH_p(P)\) which we will call the “key image”. SIG: The signer generates a one-time ring signature with a non-interactive zero-knowledge proof using the techniques from [21]. He selects a random subset \(S'\) of \(n\) from the other users’ public keys \(P_i\), his own keypair \((x, P)\) and key image \(I\). Let \(0 \leq s \leq n\) be signer’s secret index in \(S\) (so that his public key is \(P_s\)). He picks a random \(\{q_i \mid i = 0, \ldots, n\}\) and \(\{w_i \mid i = 0, \ldots, n, i \neq s\}\) from \((1, \ldots, l)\) and applies the following transformations: \[L_i = \begin{cases} q_iG & \text{if } i = s \\ q_iG + w_iP_i & \text{if } i \neq s \end{cases}\] \[R_i = \begin{cases} q_iH_p(P_i) & \text{if } i = s \\ q_iH_p(P_i) + w_iI & \text{if } i \neq s \end{cases}\] The next step is getting the non-interactive challenge: \(c = H_s(m, L_1, \ldots, L_n, R_1, \ldots, R_n)\) Finally the signer computes the response: \(c_i =\)    wi, if i ̸= s c − nP i=0 ci mod l, if i = s ri = ( qi, if i ̸= s qs −csx mod l, if i = s The resulting signature is \(\sigma = (I, c_1, \ldots, c_n, r_1, \ldots, r_n)\). 9 VER: takes a message \(m\), a set \(S\), a signature \(\sigma\) and outputs “true” or “false”. LNK: takes a set \(\mathcal{I} = \{I_i\}\), a signature \(\sigma\) and outputs “linked” or “indep”. The idea behind the protocol is fairly simple: a user produces a signature which can be checked by a set of public keys rather than a unique public key. The identity of the signer is indistinguishable from the other users whose public keys are in the set until the owner produces a second signature using the same keypair. Private keys \(x_0\) \(\cdots\) \(x_i\) \(\cdots\) \(x_n\) Public keys \(P_0\) \(\cdots\) \(P_i\) \(\cdots\) \(P_n\) Ring Signature sign verify Fig. 6. Ring signature anonymity. GEN: The signer picks a random secret key \(x \in [1, l - 1]\) and computes the corresponding public key \(P = xG\). Additionally he computes another public key \(I = xH_p(P)\) which we will call the “key image”. SIG: The signer generates a one-time ring signature with a non-interactive zero-knowledge proof using the techniques from [21]. He selects a random subset \(S'\) of \(n\) from the other users’ public keys \(P_i\), his own keypair \((x, P)\) and key image \(I\). Let \(0 \leq s \leq n\) be signer’s secret index in \(S\) (so that his public key is \(P_s\)). He picks a random \(\{q_i \mid i = 0, \ldots, n\}\) and \(\{w_i \mid i = 0, \ldots, n, i \neq s\}\) from \((1, \ldots, l)\) and applies the following transformations: \[L_i = \begin{cases} q_i G, & \text{if } i = s \\\\ q_i G + w_i P_i, & \text{if } i \neq s \end{cases}\] \[R_i = \begin{cases} q_i H_p(P_i), & \text{if } i = s \\\\ q_i H_p(P_i) + w_i I, & \text{if } i \neq s \end{cases}\] The next step is getting the non-interactive challenge:

\[c = H_s(m, L_1, \ldots, L_n, R_1, \ldots, R_n)\] Finally the signer computes the response: \[c_i = \begin{cases} w_i, & \text{if } i \neq s \\\\ c - \sum_{i=0}^{n} c_i \mod l, & \text{if } i = s \end{cases}\] \[r_i = \begin{cases} q_i, & \text{if } i \neq s \\ q_s - c_s x \mod l, & \text{if } i = s \end{cases}\] The resulting signature is \(\sigma = (I, c_1, \ldots, c_n, r_1, \ldots, r_n)\). 9 17 Perhaps this is stupid, but care must be taken when unioning S and P_s. If you just append the last public key to the end, unlinkability is broken because anyone checking passing transactions can just check the last public key listed in each transaction and boom. That’s the public key associated with the sender. So after unioning, a pseudorandom number generator must be used to permute the public keys chosen. "...until the owner produces a second signature using the same keypair." I wish the author(s?) would elaborate on this. I believe this means "make sure that every time you choose a set of public keys to obfuscate yourself with, you pick a completely new set with no two keys alike." Which seems like a pretty strong condition to place upon unlinkability. Perhaps "you pick a new random set from all possible keys" with the assumption that, although nontrivial intersections will inevitably happen, they won’t happen often. Either way, I need to dig deeper into this statement. This is generating the ring signature. Zero-knowledge proofs are awesome: I challenge you to prove to me that you know a secret without revealing the secret. For example, say we are at the entrance of a donut-shaped cave, and at the back of the cave (beyond sight from the entrance) is a one-way door to which you claim you have the key. If you go one direction, it always lets you through, but if you go the other direction, you need a key. But you don’t even want to SHOW me the key, let alone show me that it opens the door. But you want to prove to me that you know how to open the door. In the interactive setting, I ﬂip a coin. Heads is left, tails is right, and you go down the donut-shaped cave whichever way the coin directs you. At the back, beyond my sight, you open the door to come back around the other side. We repeat the coin-ﬂipping experiment until I’m satisﬁed that you have the key. But that’s clearly the INTERACTIVE zero-knowledge proof. There are non-interactive versions in which you and I never have to communicate; this way, no eavesdroppers can interfere. http://en.wikipedia.org/wiki/Zero-knowledge_proof This is reversed from the previous deﬁnition.

VER: takes a message \(m\), a set \(S\), a signature \(\sigma\) and outputs “true” or “false”. LNK: takes a set \(\mathcal{I} = \{I_i\}\), a signature \(\sigma\) and outputs “linked” or “indep”. The idea behind the protocol is fairly simple: a user produces a signature which can be checked by a set of public keys rather than a unique public key. The identity of the signer is indistinguishable from the other users whose public keys are in the set until the owner produces a second signature using the same keypair. Private keys \(x_0\) \(\cdots\) \(x_i\) \(\cdots\) \(x_n\) Public keys \(P_0\) \(\cdots\) \(P_i\) \(\cdots\) \(P_n\) Ring Signature sign verify Fig. 6. Ring signature anonymity. GEN: The signer picks a random secret key \(x \in [1, l - 1]\) and computes the corresponding public key \(P = xG\). Additionally he computes another public key \(I = xH_p(P)\) which we will call the “key image”. SIG: The signer generates a one-time ring signature with a non-interactive zero-knowledge proof using the techniques from [21]. He selects a random subset \(S'\) of \(n\) from the other users’ public keys \(P_i\), his own keypair \((x, P)\) and key image \(I\). Let \(0 \leq s \leq n\) be signer’s secret index in \(S\) (so that his public key is \(P_s\)). He picks a random \(\{q_i \mid i = 0, \ldots, n\}\) and \(\{w_i \mid i = 0, \ldots, n, i \neq s\}\) from \((1, \ldots, l)\) and applies the following transformations: \[L_i = \begin{cases} q_i G, & \text{if } i = s \\\\ q_i G + w_i P_i, & \text{if } i \neq s \end{cases}\] \[R_i = \begin{cases} q_i H_p(P_i), & \text{if } i = s \\\\ q_i H_p(P_i) + w_i I, & \text{if } i \neq s \end{cases}\] The next step is getting the non-interactive challenge:

\[c = H_s(m, L_1, \ldots, L_n, R_1, \ldots, R_n)\] Finally the signer computes the response: \[c_i = \begin{cases} w_i, & \text{if } i \neq s \\\\ c - \sum_{i=0}^{n} c_i \mod l, & \text{if } i = s \end{cases}\] \[r_i = \begin{cases} q_i, & \text{if } i \neq s \\ q_s - c_s x \mod l, & \text{if } i = s \end{cases}\] The resulting signature is \(\sigma = (I, c_1, \ldots, c_n, r_1, \ldots, r_n)\). 9 VER: takes a message \(m\), a set \(S\), a signature \(\sigma\) and outputs “true” or “false”. LNK: takes a set \(\mathcal{I} = \{I_i\}\), a signature \(\sigma\) and outputs “linked” or “indep”. The idea behind the protocol is fairly simple: a user produces a signature which can be checked by a set of public keys rather than a unique public key. The identity of the signer is indistinguishable from the other users whose public keys are in the set until the owner produces a second signature using the same keypair. Private keys \(x_0\) \(\cdots\) \(x_i\) \(\cdots\) \(x_n\) Public keys \(P_0\) \(\cdots\) \(P_i\) \(\cdots\) \(P_n\) Ring Signature sign verify Fig. 6. Ring signature anonymity. GEN: The signer picks a random secret key \(x \in [1, l - 1]\) and computes the corresponding public key \(P = xG\). Additionally he computes another public key \(I = xH_p(P)\) which we will call the “key image”. SIG: The signer generates a one-time ring signature with a non-interactive zero-knowledge proof using the techniques from [21]. He selects a random subset \(S'\) of \(n\) from the other users’ public keys \(P_i\), his own keypair \((x, P)\) and key image \(I\). Let \(0 \leq s \leq n\) be signer’s secret index in \(S\) (so that his public key is \(P_s\)). He picks a random \(\{q_i \mid i = 0, \ldots, n\}\) and \(\{w_i \mid i = 0, \ldots, n, i \neq s\}\) from \((1, \ldots, l)\) and applies the following transformations: \[L_i = \begin{cases} q_i G, & \text{if } i = s \\\\ q_i G + w_i P_i, & \text{if } i \neq s \end{cases}\] \[R_i = \begin{cases} q_i H_p(P_i), & \text{if } i = s \\\\ q_i H_p(P_i) + w_i I, & \text{if } i \neq s \end{cases}\] The next step is getting the non-interactive challenge:

\[c = H_s(m, L_1, \ldots, L_n, R_1, \ldots, R_n)\] Finally the signer computes the response: \[c_i = \begin{cases} w_i, & \text{if } i \neq s \\\\ c - \sum_{i=0}^{n} c_i \mod l, & \text{if } i = s \end{cases}\] \[r_i = \begin{cases} q_i, & \text{if } i \neq s \\ q_s - c_s x \mod l, & \text{if } i = s \end{cases}\] The resulting signature is \(\sigma = (I, c_1, \ldots, c_n, r_1, \ldots, r_n)\). 9 18 This whole area is cryptonote agnostic, simply describing the ring signature algorithm without reference to currencies. I suspect some of the notation is consistent with the rest of the paper, though. For example, x is the "random" secret key chosen in GEN, which gives public key P and public key image I. This value of x is the value Bob computes in part 6 page 8. So this is starting to clear up some of the confusion from the previous description. This is kind of cool; money isn’t being transferred from "Alice’s public address to Bob’s public address." It’s being transferred from one-time address to one-time address. So, in a sense, here’s how stuﬀis working. If Alex has some cryptonotes because someone sent them to her, this means she has the private keys needed to send them to Bob. She uses a Diﬃe-Hellman exchange using Bob’s public information to generate a new one-time address and the cryptonotes are transferred to that address. Now, since a (presumably secure) DH exchange was used to generate the new one-time address to which Alex sent her CN, Bob is the only one with the private keys needed to repeat the above. So now, Bob is Alex. http://en.wikipedia.org/wiki/Piecewise#Notation_and_interpretation Summation should be indexed over j not i. Each c_i is random junk (since w_i is random) except for the c_i associated with the actual key involved in this signature. The value of c is a hash of the previous information. I think this may contain a typo worse than re-using the index ’i,’ though, because c_s seems to be implicitly, not explicitly, deﬁned. Indeed, if we take this equation on faith, then we determine that c_s = (1/2)c - (1/2) sum_i neq s c_i. That is, a hash minus a whole bunch of random numbers. On the other hand, if this summation is intended to be read "c_s = (c - sum_j neq s c_j) mod l", then we take the hash of our previous information, generate a bunch of random numbers, subtract all of those random numbers oﬀthe hash, and that gives us c_s. This seems to be what "should" be happening given my intuition, and matches the veriﬁcation step on page 10. But intuition is not mathematics. I’ll dig deeper into this. Same as before; all of these will be random junk except for the one associated with the actual signer’s public key x. Except this time, this is more what I would expect from the structure: r_i is random for i!=s and r_s is determined only by the secret x and the s-indexed values of q_i and c_i.

VER: The verifier checks the signature by applying the inverse transformations:

\[L'_i = r_i G + c_i P_i\]

\[R'_i = r_i H_p(P_i) + c_i I\] Finally, the verifier checks if

\[L'_i = r_i G + c_i P_i\]

\[R'_i = r_i H_p(P_i) + c_i I\] Finally, the verifier checks if

\[\sum_{i=0}^{n} c_i \stackrel{?}{=} H_s(m, L'_0, \ldots, L'_n, R'_0, \ldots, R'_n) \mod l\] If this equality is correct, the verifier runs the algorithm LNK. Otherwise the verifier rejects the signature. LNK: The verifier checks if \(I\) has been used in past signatures (these values are stored in the set \(\mathcal{I}\)). Multiple uses imply that two signatures were produced under the same secret key. The meaning of the protocol: by applying L-transformations the signer proves that he knows such \(x\) that at least one \(P_i = xG\). To make this proof non-repeatable we introduce the key image as \(I = xH_p(P)\). The signer uses the same coefficients \((r_i, c_i)\) to prove almost the same statement: he knows such \(x\) that at least one \(H_p(P_i) = I \cdot x^{-1}\). If the mapping \(x \to I\) is an injection: 1. Nobody can recover the public key from the key image and identify the signer; 2. The signer cannot make two signatures with different \(I\)'s and the same \(x\). A full security analysis is provided in Appendix A. 4.5 Standard CryptoNote transaction By combining both methods (unlinkable public keys and untraceable ring signature) Bob achieves new level of privacy in comparison with the original Bitcoin scheme. It requires him to store only one private key \((a, b)\) and publish \((A, B)\) to start receiving and sending anonymous transactions. While validating each transaction Bob additionally performs only two elliptic curve multiplications and one addition per output to check if a transaction belongs to him. For his every output Bob recovers a one-time keypair \((p_i, P_i)\) and stores it in his wallet. Any inputs can be circumstantially proved to have the same owner only if they appear in a single transaction. In fact this relationship is much harder to establish due to the one-time ring signature. With a ring signature Bob can effectively hide every input among somebody else’s; all possible spenders will be equiprobable, even the previous owner (Alice) has no more information than any observer. When signing his transaction Bob specifies \(n\) foreign outputs with the same amount as his output, mixing all of them without the participation of other users. Bob himself (as well as anybody else) does not know if any of these payments have been spent: an output can be used in thousands of signatures as an ambiguity factor and never as a target of hiding. The double spend check occurs in the LNK phase when checking against the used key images set. Bob can choose the ambiguity degree on his own: \(n = 1\) means that the probability he has spent the output is 50% probability, \(n = 99\) gives 1%. The size of the resulting signature increases linearly as \(O(n+1)\), so the improved anonymity costs to Bob extra transaction fees. He also can set \(n = 0\) and make his ring signature to consist of only one element, however this will instantly reveal him as a spender. 10 19 At this point, I’m terribly confused. Alex receives a message M with signature (I,c_1, ..., c_n, r_1, ..., r_n) and list of public keys S. and she runs VER. This will compute L_i’ and R_i’ This veriﬁes that c_s = c - sum_i neq s c_i on the previous page. At ﬁrst I was VERy (ha) confused. Anyone can compute L_i’ and R_i’. Indeed, each r_i and c_i have been published in the signature sigma together with the value for I. The set S = P_i of all public keys has also been published. So anyone who has seen sigma and the set of keys S = P_i will get the same values for L_i’ and R_i’ and hence check the signature. But then I remembered this section is simply describing a signature algorithm, not a "check if signed, check if SENT TO ME, and if so, then go spend the money." This is SIMPLY the signature part of the game. I’m interested to read Appendix A when I ﬁnally get there. I would like to see a full-scale operation-by-operation comparison of Cryptonote to Bitcoin. Also, electricity/sustainability. What pieces of the algorithms constitute "input" here? Transaction input, I believe, is an Amount and a set of UTXOs that sum to a greater amount than the Amount. This is unclear. "Target of hiding?" I have thought about this for a few minutes now and I still haven’t the foggiest idea of what it could mean. A double-spend attack can be executed only by manipulating a node’s perceived used-key images set \(I\). "Ambiguity degree" = n but the total number of public keys included in the transaction is n+1. That is to say, ambiguity degree would be "how many OTHER people do you want in the crowd?" The answer will probably be, by default "as many as possible."

VER: The verifier checks the signature by applying the inverse transformations:

\[L'_i = r_i G + c_i P_i\]

\[R'_i = r_i H_p(P_i) + c_i I\] Finally, the verifier checks if

\[L'_i = r_i G + c_i P_i\]

\[R'_i = r_i H_p(P_i) + c_i I\] Finally, the verifier checks if

\[\sum_{i=0}^{n} c_i \stackrel{?}{=} H_s(m, L'_0, \ldots, L'_n, R'_0, \ldots, R'_n) \mod l\] If this equality is correct, the verifier runs the algorithm LNK. Otherwise the verifier rejects the signature. LNK: The verifier checks if \(I\) has been used in past signatures (these values are stored in the set \(\mathcal{I}\)). Multiple uses imply that two signatures were produced under the same secret key. The meaning of the protocol: by applying L-transformations the signer proves that he knows such \(x\) that at least one \(P_i = xG\). To make this proof non-repeatable we introduce the key image as \(I = xH_p(P)\). The signer uses the same coefficients \((r_i, c_i)\) to prove almost the same statement: he knows such \(x\) that at least one \(H_p(P_i) = I \cdot x^{-1}\). If the mapping \(x \to I\) is an injection: 1. Nobody can recover the public key from the key image and identify the signer; 2. The signer cannot make two signatures with different \(I\)'s and the same \(x\). A full security analysis is provided in Appendix A. 4.5 Standard CryptoNote transaction By combining both methods (unlinkable public keys and untraceable ring signature) Bob achieves new level of privacy in comparison with the original Bitcoin scheme. It requires him to store only one private key \((a, b)\) and publish \((A, B)\) to start receiving and sending anonymous transactions. While validating each transaction Bob additionally performs only two elliptic curve multiplications and one addition per output to check if a transaction belongs to him. For his every output Bob recovers a one-time keypair \((p_i, P_i)\) and stores it in his wallet. Any inputs can be circumstantially proved to have the same owner only if they appear in a single transaction. In fact this relationship is much harder to establish due to the one-time ring signature. With a ring signature Bob can effectively hide every input among somebody else’s; all possible spenders will be equiprobable, even the previous owner (Alice) has no more information than any observer. When signing his transaction Bob specifies \(n\) foreign outputs with the same amount as his output, mixing all of them without the participation of other users. Bob himself (as well as anybody else) does not know if any of these payments have been spent: an output can be used in thousands of signatures as an ambiguity factor and never as a target of hiding. The double spend check occurs in the LNK phase when checking against the used key images set. Bob can choose the ambiguity degree on his own: \(n = 1\) means that the probability he has spent the output is 50% probability, \(n = 99\) gives 1%. The size of the resulting signature increases linearly as \(O(n+1)\), so the improved anonymity costs to Bob extra transaction fees. He also can set \(n = 0\) and make his ring signature to consist of only one element, however this will instantly reveal him as a spender. 10 20 This is interesting; earlier, we provided a way for a receiver, Bob, to make all INCOMING transactions non-unlinkable either by choosing half of his private keys deterministically or by publishing half his private keys as public. This is a no-going-back sort of policy. Here, we see a way of a sender, Alex, to choose a single outgoing transaction as linkable, but in fact this reveals Alex as the sender to the whole network. This is NOT a no-going-back sort of policy. This is transaction-by-transaction. Is there a third policy? Can a receiver, Bob, generate a unique payment ID for Alex that never changes, perhaps using a Diﬃe-Hellman exchange? If anyone includes that payment ID bundled somewhere in her transaction to Bob’s address, it must have come from Alex. This way, Alex need not reveal herself to the whole network by choosing to link a particular transaction, but she can still identify herself to the person to whom she sends her money. Isn’t this what Poloniex does?

Transaction Tx input \(\text{Output}_0\) \(\ldots\) \(\text{Output}_i\) \(\ldots\) \(\text{Output}_n\) Key image Signatures Ring Signature Destination key Output1 Destination key Outputn Foreign transactions Sender’s output Destination key One-time keypair One-time private key \(I = xH_p(P)\) \(P\), \(x\) Fig. 7. Ring signature generation in a standard transaction. 5 Egalitarian Proof-of-work In this section we propose and ground the new proof-of-work algorithm. Our primary goal is to close the gap between CPU (majority) and GPU/FPGA/ASIC (minority) miners. It is appropriate that some users can have a certain advantage over others, but their investments should grow at least linearly with the power. More generally, producing special-purpose devices has to be as less proﬁtable as possible. 5.1 Related works The original Bitcoin proof-of-work protocol uses the CPU-intensive pricing function SHA-256. It mainly consists of basic logical operators and relies solely on the computational speed of processor, therefore is perfectly suitable for multicore/conveyer implementation. However, modern computers are not limited by the number of operations per second alone, but also by memory size. While some processors can be substantially faster than others [8], memory sizes are less likely to vary between machines. Memory-bound price functions were ﬁrst introduced by Abadi et al and were deﬁned as “functions whose computation time is dominated by the time spent accessing memory” [15]. The main idea is to construct an algorithm allocating a large block of data (“scratchpad”) within memory that can be accessed relatively slowly (for example, RAM) and “accessing an unpredictable sequence of locations” within it. A block should be large enough to make preserving the data more advantageous than recomputing it for each access. The algorithm also should prevent internal parallelism, hence \(N\) simultaneous threads should require \(N\) times more memory at once. Dwork et al [22] investigated and formalized this approach leading them to suggest another variant of the pricing function: “Mbound”. One more work belongs to F. Coelho [20], who 11 Transaction Tx input \(\text{Output}_0\) \(\ldots\) \(\text{Output}_i\) \(\ldots\) \(\text{Output}_n\) Key image Signatures Ring Signature Destination key Output1 Destination key Outputn Foreign transactions Sender’s output Destination key One-time keypair One-time private key \(I = xH_p(P)\) \(P\), \(x\) Fig. 7. Ring signature generation in a standard transaction. 5 Egalitarian Proof-of-work In this section we propose and ground the new proof-of-work algorithm. Our primary goal is to close the gap between CPU (majority) and GPU/FPGA/ASIC (minority) miners. It is appropriate that some users can have a certain advantage over others, but their investments should grow at least linearly with the power. More generally, producing special-purpose devices has to be as less proﬁtable as possible. 5.1 Related works The original Bitcoin proof-of-work protocol uses the CPU-intensive pricing function SHA-256. It mainly consists of basic logical operators and relies solely on the computational speed of processor, therefore is perfectly suitable for multicore/conveyer implementation. However, modern computers are not limited by the number of operations per second alone, but also by memory size. While some processors can be substantially faster than others [8], memory sizes are less likely to vary between machines. Memory-bound price functions were ﬁrst introduced by Abadi et al and were deﬁned as “functions whose computation time is dominated by the time spent accessing memory” [15]. The main idea is to construct an algorithm allocating a large block of data (“scratchpad”) within memory that can be accessed relatively slowly (for example, RAM) and “accessing an unpredictable sequence of locations” within it. A block should be large enough to make preserving the data more advantageous than recomputing it for each access. The algorithm also should prevent internal parallelism, hence \(N\) simultaneous threads should require \(N\) times more memory at once. Dwork et al [22] investigated and formalized this approach leading them to suggest another variant of the pricing function: "Mbound". One more work belongs to F. Coelho [20], who 11 21 These are, ostensibly, our UTXO’s: amounts and destination keys. If Alex is the one constructing this standard transaction and is sending to Bob, then Alex also has the private keys to each of these. I like this diagram a whole lot, because it answers some earlier questions. A Txn input consists of a set of Txn outputs and a key image. It is then signed with a ring signature, including all of the private keys Alex owns to all of the foreign transactions wrapped up in the deal. The Txn output consists of an amount and a destination key. The receiver of the transaction may, at will, generate their one-time private key as described earlier in the paper in order to spend the money. It will be delightful to ﬁnd out how much this matches the actual code... No, Nic van Saberhagen describes loosely some properties of a proof of work algorithm, without actually describing that algorithm. The CryptoNight algorithm itself will REQUIRE a deep analysis. When I read this, I stuttered. Should investment grow at least linearly with power, or should investment grow at most linearly with power? And then I realized; I, as a miner, or an investor, usually think of "how much power can I get for an investment?" not "how much investment is required for a ﬁxed amount of power?" Of course, denote investment by \(I\) and power by \(P\). If \(I(P)\) is investment as a function of power and \(P(I)\) is power as a function of investment, they'll be inverses of each other (wherever inverses can exist). And if \(I(P)\) is faster-than-linear than \(P(I)\) is slower-than-linear. Hence, there will be a reduced rate of returns for investors. That is to say, what the author is saying here is: "sure, as you invest more, you’ll get more power. But we should try to make that a reduced rate of returns thing." CPU investments will cap out sub-linearly, eventually; the question is whether the authors have designed a POW algorithm that will force the ASICs to also do this. Should a hypothetical "future currency" always mine with the slowest/most limited resources? The paper by Abadi et al, (which has some Google and Microsoft engineers as authors) is, essentially, using the fact that for the past few years memory size has had a much smaller variance across machines than processor speed, and with a more-than-linear investment-forpower ratio. In a few years, this may have to be re-assessed! Everything is an arms race... Constructing a hash function is diﬃcult; constructing a hash function satisfying these constraints seems to be more diﬃcult. This paper seems to have no explanation of the actual hashing algorithm CryptoNight. I think it’s a memory-hard implementation of SHA-3, based on forum posts but I have no idea... and that’s the point. It must be explained.

proposed the most eﬀective solution: “Hokkaido”. To our knowledge the last work based on the idea of pseudo-random searches in a big array is the algorithm known as “scrypt” by C. Percival [32]. Unlike the previous functions it focuses on key derivation, and not proof-of-work systems. Despite this fact scrypt can serve our purpose: it works well as a pricing function in the partial hash conversion problem such as SHA-256 in Bitcoin. By now scrypt has already been applied in Litecoin [14] and some other Bitcoin forks. However, its implementation is not really memory-bound: the ratio “memory access time / overall time” is not large enough because each instance uses only 128 KB. This permits GPU miners to be roughly 10 times more eﬀective and continues to leave the possibility of creating relatively cheap but highly-eﬃcient mining devices. Moreover, the scrypt construction itself allows a linear trade-oﬀbetween memory size and CPU speed due to the fact that every block in the scratchpad is derived only from the previous. For example, you can store every second block and recalculate the others in a lazy way, i.e. only when it becomes necessary. The pseudo-random indexes are assumed to be uniformly distributed, hence the expected value of the additional blocks' recalculations is \(\frac{1}{2} \cdot N\), where \(N\) is the number of iterations. The overall computation time increases less than by half because there are also time independent (constant time) operations such as preparing the scratchpad and hashing on every iteration. Saving 2/3 of the memory costs \(\frac{1}{3} \cdot N + \frac{1}{3} \cdot 2 \cdot N = N\) additional recalculations; 9/10 results in \(\frac{1}{10} \cdot N + \ldots + \frac{1}{10} \cdot 9 \cdot N = 4.5N\). It is easy to show that storing only \(\frac{1}{s}\) of all blocks increases the time less than by a factor of \(\frac{s-1}{2}\). This in turn implies that a machine with a CPU 200 times faster than the modern chips can store only 320 bytes of the scratchpad. 5.2 The proposed algorithm We propose a new memory-bound algorithm for the proof-of-work pricing function. It relies on random access to a slow memory and emphasizes latency dependence. As opposed to scrypt every new block (64 bytes in length) depends on all the previous blocks. As a result a hypothetical "memory-saver" should increase his calculation speed exponentially. Our algorithm requires about 2 Mb per instance for the following reasons: 1. It ﬁts in the L3 cache (per core) of modern processors, which should become mainstream in a few years; 2. A megabyte of internal memory is an almost unacceptable size for a modern ASIC pipeline; 3. GPUs may run hundreds of concurrent instances, but they are limited in other ways: GDDR5 memory is slower than the CPU L3 cache and remarkable for its bandwidth, not random access speed. 4. Signiﬁcant expansion of the scratchpad would require an increase in iterations, which in turn implies an overall time increase. "Heavy" calls in a trust-less p2p network may lead to serious vulnerabilities, because nodes are obliged to check every new block's proof-of-work. If a node spends a considerable amount of time on each hash evaluation, it can be easily DDoSed by a ﬂood of fake objects with arbitrary work data (nonce values). 12 proposed the most eﬀective solution: "Hokkaido". To our knowledge the last work based on the idea of pseudo-random searches in a big array is the algorithm known as “scrypt” by C. Percival [32]. Unlike the previous functions it focuses on key derivation, and not proof-of-work systems. Despite this fact scrypt can serve our purpose: it works well as a pricing function in the partial hash conversion problem such as SHA-256 in Bitcoin. By now scrypt has already been applied in Litecoin [14] and some other Bitcoin forks. However, its implementation is not really memory-bound: the ratio “memory access time / overall time” is not large enough because each instance uses only 128 KB. This permits GPU miners to be roughly 10 times more eﬀective and continues to leave the possibility of creating relatively cheap but highly-eﬃcient mining devices. Moreover, the scrypt construction itself allows a linear trade-oﬀbetween memory size and CPU speed due to the fact that every block in the scratchpad is derived only from the previous. For example, you can store every second block and recalculate the others in a lazy way, i.e. only when it becomes necessary. The pseudo-random indexes are assumed to be uniformly distributed, hence the expected value of the additional blocks’ recalculations is \(\frac{1}{2} \cdot N\), where \(N\) is the number of iterations. The overall computation time increases less than by half because there are also time independent (constant time) operations such as preparing the scratchpad and hashing on every iteration. Saving 2/3 of the memory costs \(\frac{1}{3} \cdot N + \frac{1}{3} \cdot 2 \cdot N = N\) additional recalculations; 9/10 results in \(\frac{1}{10} \cdot N + \ldots + \frac{1}{10} \cdot 9 \cdot N = 4.5N\). It is easy to show that storing only \(\frac{1}{s}\) of all blocks increases the time less than by a factor of \(\frac{s-1}{2}\). This in turn implies that a machine with a CPU 200 times faster than the modern chips can store only 320 bytes of the scratchpad. 5.2 The proposed algorithm We propose a new memory-bound algorithm for the proof-of-work pricing function. It relies on random access to a slow memory and emphasizes latency dependence. As opposed to scrypt every new block (64 bytes in length) depends on all the previous blocks. As a result a hypothetical “memory-saver” should increase his calculation speed exponentially. Our algorithm requires about 2 Mb per instance for the following reasons: 1. It ﬁts in the L3 cache (per core) of modern processors, which should become mainstream in a few years; 2. A megabyte of internal memory is an almost unacceptable size for a modern ASIC pipeline; 3. GPUs may run hundreds of concurrent instances, but they are limited in other ways: GDDR5 memory is slower than the CPU L3 cache and remarkable for its bandwidth, not random access speed. 4. Signiﬁcant expansion of the scratchpad would require an increase in iterations, which in turn implies an overall time increase. “Heavy” calls in a trust-less p2p network may lead to serious vulnerabilities, because nodes are obliged to check every new block’s proof-of-work. If a node spends a considerable amount of time on each hash evaluation, it can be easily DDoSed by a ﬂood of fake objects with arbitrary work data (nonce values). 12 22 Nevermind, it’s a scrypt coin? Where is the algorithm? All I see is an advertisement. This is where Cryptonote, if their PoW algorithm is worthwhile, will really shine. It’s not really SHA-256, it’s not really scrypt. It’s new, memory bound, and non-recursive.

6 Further advantages 6.1 Smooth emission The upper bound for the overall amount of CryptoNote digital coins is: \(M_{Supply} = 2^{64} - 1\) atomic units. This is a natural restriction based only on implementation limits, not on intuition such as “N coins ought to be enough for anybody”. To ensure the smoothness of the emission process we use the following formula for block rewards: \(BaseReward = (M_{Supply} - A) \gg 18\), where \(A\) is amount of previously generated coins. 6.2 Adjustable parameters 6.2.1 Diﬃculty CryptoNote contains a targeting algorithm which changes the diﬃculty of every block. This decreases the system’s reaction time when the network hashrate is intensely growing or shrinking, preserving a constant block rate. The original Bitcoin method calculates the relation of actual and target time-span between the last 2016 blocks and uses it as the multiplier for the current diﬃculty. Obviously this is unsuitable for rapid recalculations (because of large inertia) and results in oscillations. The general idea behind our algorithm is to sum all the work completed by the nodes and divide it by the time they have spent. The measure of work is the corresponding diﬃculty values in each block. But due to inaccurate and untrusted timestamps we cannot determine the exact time interval between blocks. A user can shift his timestamp into the future and the next time intervals might be improbably small or even negative. Presumably there will be few incidents of this kind, so we can just sort the timestamps and cut-oﬀthe outliers (i.e. 20%). The range of the rest values is the time which was spent for 80% of the corresponding blocks. 6.2.2 Size limits Users pay for storing the blockchain and shall be entitled to vote for its size. Every miner deals with the trade-oﬀbetween balancing the costs and proﬁt from the fees and sets his own “soft-limit” for creating blocks. Also the core rule for the maximum block size is necessary for preventing the blockchain from being ﬂooded with bogus transaction, however this value should not be hard-coded. Let \(M_N\) be the median value of the last \(N\) blocks sizes. Then the “hard-limit” for the size of accepting blocks is \(2 \cdot M_N\). It averts the blockchain from bloating but still allows the limit to slowly grow with time if necessary. Transaction size does not need to be limited explicitly. It is bounded by the size of a block; and if somebody wants to create a huge transaction with hundreds of inputs/outputs (or with the high ambiguity degree in ring signatures), he can do so by paying suﬃcient fee. 6.2.3 Excess size penalty A miner still has the ability to stuﬀa block full of his own zero-fee transactions up to its maximum size \(2 \cdot M_b\). Even though only the majority of miners can shift the median value, there is still a 13 6 Further advantages 6.1 Smooth emission The upper bound for the overall amount of CryptoNote digital coins is: \(M_{Supply} = 2^{64} - 1\) atomic units. This is a natural restriction based only on implementation limits, not on intuition such as “N coins ought to be enough for anybody”. To ensure the smoothness of the emission process we use the following formula for block rewards: \(BaseReward = (M_{Supply} - A) \gg 18\), where \(A\) is amount of previously generated coins. 6.2 Adjustable parameters 6.2.1 Diﬃculty CryptoNote contains a targeting algorithm which changes the diﬃculty of every block. This decreases the system’s reaction time when the network hashrate is intensely growing or shrinking, preserving a constant block rate. The original Bitcoin method calculates the relation of actual and target time-span between the last 2016 blocks and uses it as the multiplier for the current diﬃculty. Obviously this is unsuitable for rapid recalculations (because of large inertia) and results in oscillations. The general idea behind our algorithm is to sum all the work completed by the nodes and divide it by the time they have spent. The measure of work is the corresponding diﬃculty values in each block. But due to inaccurate and untrusted timestamps we cannot determine the exact time interval between blocks. A user can shift his timestamp into the future and the next time intervals might be improbably small or even negative. Presumably there will be few incidents of this kind, so we can just sort the timestamps and cut-oﬀthe outliers (i.e. 20%). The range of the rest values is the time which was spent for 80% of the corresponding blocks. 6.2.2 Size limits Users pay for storing the blockchain and shall be entitled to vote for its size. Every miner deals with the trade-oﬀbetween balancing the costs and proﬁt from the fees and sets his own “soft-limit” for creating blocks. Also the core rule for the maximum block size is necessary for preventing the blockchain from being ﬂooded with bogus transaction, however this value should not be hard-coded. Let \(M_N\) be the median value of the last \(N\) blocks sizes. Then the “hard-limit” for the size of accepting blocks is \(2 \cdot M_N\). It averts the blockchain from bloating but still allows the limit to slowly grow with time if necessary. Transaction size does not need to be limited explicitly. It is bounded by the size of a block; and if somebody wants to create a huge transaction with hundreds of inputs/outputs (or with the high ambiguity degree in ring signatures), he can do so by paying suﬃcient fee. 6.2.3 Excess size penalty A miner still has the ability to stuﬀa block full of his own zero-fee transactions up to its maximum size \(2 \cdot M_b\). Even though only the majority of miners can shift the median value, there is still a 13 23 Atomic units. I like that. Is this the equivalent of Satoshis? If so, then that means there are going to be 185 billion cryptonote. I know this must be, eventually, tweaked in a few pages, or maybe there’s a typo? If the base reward is "all remaining coins" then only one block is suﬃcient to get all coins. Instamine. On the other hand, if this is supposed to be proportional in some way to the diﬀerence in time between now and some coin-production-termination-date? That would make sense. Also, in my world, two greater than signs like this means "much greater than." Did the author possibly mean something else? If adjustment to diﬃculty occurs every block then an attacker could have a very large farm of machines mine on and oﬀin carefully chosen time intervals. This could cause a chaotic explosion (or crash to zero) in diﬃculty, if diﬃculty adjustment formulas aren’t suitably damped. No doubt that Bitcoin’s method is unsuitable for rapid recalculations, but the idea of inertia in these systems would need to be proven, not taken for granted. Furthermore, oscillations in network diﬃculty isn’t necessarily a problem unless it results in oscillations of ostensible supply of coins - and having a very rapidly changing diﬃculty could cause "over-correction." Time spent, especially over a short time span like a few minutes, will be proportional to "total number of blocks created on the network." The constant of proportionality will, itself, grow over time, presumably exponentially if CN takes oﬀ. It may be a better idea to simply adjust the diﬃculty to keep "total blocks created on the network since the last block was added to the main chain" within some constant value, or with bounded variation or something like that. If an adaptive algorithm that is computationally easy to implement can be determined, this would seem to solve the problem. But then, if we used that method, someone with a big mining farm could shut their farm down for a few hours, and switch it back on again. For the ﬁrst few blocks, that farm will make bank. So, actually, this method would bring up an interesting point: mining becomes (on average) a losing game with no ROI, especially as more folks hop on the network. If the mining diﬃculty very closely tracked network hashrate, I somehow doubt people would mine as much as they currently do. Or, on the other hand, instead of keeping their mining farms going 24/7, they may turn them on for 6 hours, oﬀfor 2, on for 6, oﬀfor 2, or something like that. Just switch to another coin for a few hours, wait for diﬃculty to drop, then hop back on in order to gain those few extra blocks of proﬁtability as the network adapts. And you know what? This is actually probably one of the better mining scenarios I’ve put my mind into... This could be circular, but if block creation time averages to about a minute, can we just use the number of blocks as a proxy for "time spent?"

6 Further advantages 6.1 Smooth emission The upper bound for the overall amount of CryptoNote digital coins is: \(M_{Supply} = 2^{64} - 1\) atomic units. This is a natural restriction based only on implementation limits, not on intuition such as “N coins ought to be enough for anybody”. To ensure the smoothness of the emission process we use the following formula for block rewards: \(BaseReward = (M_{Supply} - A) \gg 18\), where \(A\) is amount of previously generated coins. 6.2 Adjustable parameters 6.2.1 Diﬃculty CryptoNote contains a targeting algorithm which changes the diﬃculty of every block. This decreases the system’s reaction time when the network hashrate is intensely growing or shrinking, preserving a constant block rate. The original Bitcoin method calculates the relation of actual and target time-span between the last 2016 blocks and uses it as the multiplier for the current diﬃculty. Obviously this is unsuitable for rapid recalculations (because of large inertia) and results in oscillations. The general idea behind our algorithm is to sum all the work completed by the nodes and divide it by the time they have spent. The measure of work is the corresponding diﬃculty values in each block. But due to inaccurate and untrusted timestamps we cannot determine the exact time interval between blocks. A user can shift his timestamp into the future and the next time intervals might be improbably small or even negative. Presumably there will be few incidents of this kind, so we can just sort the timestamps and cut-oﬀthe outliers (i.e. 20%). The range of the rest values is the time which was spent for 80% of the corresponding blocks. 6.2.2 Size limits Users pay for storing the blockchain and shall be entitled to vote for its size. Every miner deals with the trade-oﬀbetween balancing the costs and proﬁt from the fees and sets his own “soft-limit” for creating blocks. Also the core rule for the maximum block size is necessary for preventing the blockchain from being ﬂooded with bogus transaction, however this value should not be hard-coded. Let \(M_N\) be the median value of the last \(N\) blocks sizes. Then the “hard-limit” for the size of accepting blocks is \(2 \cdot M_N\). It averts the blockchain from bloating but still allows the limit to slowly grow with time if necessary. Transaction size does not need to be limited explicitly. It is bounded by the size of a block; and if somebody wants to create a huge transaction with hundreds of inputs/outputs (or with the high ambiguity degree in ring signatures), he can do so by paying suﬃcient fee. 6.2.3 Excess size penalty A miner still has the ability to stuﬀa block full of his own zero-fee transactions up to its maximum size \(2 \cdot M_b\). Even though only the majority of miners can shift the median value, there is still a 13 6 Further advantages 6.1 Smooth emission The upper bound for the overall amount of CryptoNote digital coins is: \(M_{Supply} = 2^{64} - 1\) atomic units. This is a natural restriction based only on implementation limits, not on intuition such as “N coins ought to be enough for anybody”. To ensure the smoothness of the emission process we use the following formula for block rewards: \(BaseReward = (M_{Supply} - A) \gg 18\), where \(A\) is amount of previously generated coins. 6.2 Adjustable parameters 6.2.1 Diﬃculty CryptoNote contains a targeting algorithm which changes the diﬃculty of every block. This decreases the system’s reaction time when the network hashrate is intensely growing or shrinking, preserving a constant block rate. The original Bitcoin method calculates the relation of actual and target time-span between the last 2016 blocks and uses it as the multiplier for the current diﬃculty. Obviously this is unsuitable for rapid recalculations (because of large inertia) and results in oscillations. The general idea behind our algorithm is to sum all the work completed by the nodes and divide it by the time they have spent. The measure of work is the corresponding diﬃculty values in each block. But due to inaccurate and untrusted timestamps we cannot determine the exact time interval between blocks. A user can shift his timestamp into the future and the next time intervals might be improbably small or even negative. Presumably there will be few incidents of this kind, so we can just sort the timestamps and cut-oﬀthe outliers (i.e. 20%). The range of the rest values is the time which was spent for 80% of the corresponding blocks. 6.2.2 Size limits Users pay for storing the blockchain and shall be entitled to vote for its size. Every miner deals with the trade-oﬀbetween balancing the costs and proﬁt from the fees and sets his own “soft-limit” for creating blocks. Also the core rule for the maximum block size is necessary for preventing the blockchain from being ﬂooded with bogus transaction, however this value should not be hard-coded. Let \(M_N\) be the median value of the last \(N\) blocks sizes. Then the “hard-limit” for the size of accepting blocks is \(2 \cdot M_N\). It averts the blockchain from bloating but still allows the limit to slowly grow with time if necessary. Transaction size does not need to be limited explicitly. It is bounded by the size of a block; and if somebody wants to create a huge transaction with hundreds of inputs/outputs (or with the high ambiguity degree in ring signatures), he can do so by paying suﬃcient fee. 6.2.3 Excess size penalty A miner still has the ability to stuﬀa block full of his own zero-fee transactions up to its maximum size \(2 \cdot M_b\). Even though only the majority of miners can shift the median value, there is still a 13 24 Okay, so we have a blockchain, and each block has timestamps IN ADDITION to simply being ordered. This was clearly inserted simply for diﬃculty adjustment, because timestamps are very unreliable, as mentioned. Are we allowed to have contradicting timestamps in the chain? If Block A comes before Block B in the chain, and everything is consistent in terms of ﬁnances, but Block A appears to have been created after Block B? Because, perhaps, someone owned a large part of the network? Is that ok? Probably, because the ﬁnances aren’t goofed up. Okay, so I hate this arbitrary "only 80% of the blocks are legitimate for the main blockchain" approach. It was intended to prevent liars from tweaking their timestamps? But now, it adds incentive for everyone to lie about their timestamps and just pick the median. Please deﬁne. Meaning "for this block, only include transactions that include fees greater than p%, preferentially with fees greater than 2p%" or something like that? What do they mean by bogus? If the transaction is consistent with past history of the blockchain, and the transaction includes fees that satisfy miners, is that not enough? Well, no, not necessarily. If no maximum block size exists, there is nothing to keep a malicious user from simply uploading a massive block of transactions to himself all at once just to slow down the network. A core rule for maximum block size prevents people from putting enormous amounts of junk data on the blockchain all at once just to slow things down. But such a rule certianly has to be adaptive - during the christmas season, for example, we could expect traﬃc to spike, and block size to get very big, and immediately afterward, for the block size to subsequently drop again. So we need either a) some sort of adaptive cap or b) a cap large enough so that 99% of reasonable christmas peaks don’t break the cap. Of course, that second one is impossible to estimate - who knows if a currency will catch on? Better to make it adaptive and not worry about it. But then we have a control theory problem: how to make this adaptive without vulnerability to attack or wild & crazy oscillations? Notice an adaptive method doesn’t stop malicious users from accumulating small amounts of junk data over time on the blockchain to cause long-term bloat. This is a diﬀerent issue altogether and one that cryptonote coins have serious problems with.

6 Further advantages 6.1 Smooth emission The upper bound for the overall amount of CryptoNote digital coins is: \(M_{Supply} = 2^{64} - 1\) atomic units. This is a natural restriction based only on implementation limits, not on intuition such as “N coins ought to be enough for anybody”. To ensure the smoothness of the emission process we use the following formula for block rewards: \(BaseReward = (M_{Supply} - A) \gg 18\), where \(A\) is amount of previously generated coins. 6.2 Adjustable parameters 6.2.1 Diﬃculty CryptoNote contains a targeting algorithm which changes the diﬃculty of every block. This decreases the system’s reaction time when the network hashrate is intensely growing or shrinking, preserving a constant block rate. The original Bitcoin method calculates the relation of actual and target time-span between the last 2016 blocks and uses it as the multiplier for the current diﬃculty. Obviously this is unsuitable for rapid recalculations (because of large inertia) and results in oscillations. The general idea behind our algorithm is to sum all the work completed by the nodes and divide it by the time they have spent. The measure of work is the corresponding diﬃculty values in each block. But due to inaccurate and untrusted timestamps we cannot determine the exact time interval between blocks. A user can shift his timestamp into the future and the next time intervals might be improbably small or even negative. Presumably there will be few incidents of this kind, so we can just sort the timestamps and cut-oﬀthe outliers (i.e. 20%). The range of the rest values is the time which was spent for 80% of the corresponding blocks. 6.2.2 Size limits Users pay for storing the blockchain and shall be entitled to vote for its size. Every miner deals with the trade-oﬀbetween balancing the costs and proﬁt from the fees and sets his own “soft-limit” for creating blocks. Also the core rule for the maximum block size is necessary for preventing the blockchain from being ﬂooded with bogus transaction, however this value should not be hard-coded. Let \(M_N\) be the median value of the last \(N\) blocks sizes. Then the “hard-limit” for the size of accepting blocks is \(2 \cdot M_N\). It averts the blockchain from bloating but still allows the limit to slowly grow with time if necessary. Transaction size does not need to be limited explicitly. It is bounded by the size of a block; and if somebody wants to create a huge transaction with hundreds of inputs/outputs (or with the high ambiguity degree in ring signatures), he can do so by paying suﬃcient fee. 6.2.3 Excess size penalty A miner still has the ability to stuﬀa block full of his own zero-fee transactions up to its maximum size \(2 \cdot M_b\). Even though only the majority of miners can shift the median value, there is still a 13 6 Further advantages 6.1 Smooth emission The upper bound for the overall amount of CryptoNote digital coins is: \(M_{Supply} = 2^{64} - 1\) atomic units. This is a natural restriction based only on implementation limits, not on intuition such as “N coins ought to be enough for anybody”. To ensure the smoothness of the emission process we use the following formula for block rewards: \(BaseReward = (M_{Supply} - A) \gg 18\), where \(A\) is amount of previously generated coins. 6.2 Adjustable parameters 6.2.1 Diﬃculty CryptoNote contains a targeting algorithm which changes the diﬃculty of every block. This decreases the system’s reaction time when the network hashrate is intensely growing or shrinking, preserving a constant block rate. The original Bitcoin method calculates the relation of actual and target time-span between the last 2016 blocks and uses it as the multiplier for the current diﬃculty. Obviously this is unsuitable for rapid recalculations (because of large inertia) and results in oscillations. The general idea behind our algorithm is to sum all the work completed by the nodes and divide it by the time they have spent. The measure of work is the corresponding diﬃculty values in each block. But due to inaccurate and untrusted timestamps we cannot determine the exact time interval between blocks. A user can shift his timestamp into the future and the next time intervals might be improbably small or even negative. Presumably there will be few incidents of this kind, so we can just sort the timestamps and cut-oﬀthe outliers (i.e. 20%). The range of the rest values is the time which was spent for 80% of the corresponding blocks. 6.2.2 Size limits Users pay for storing the blockchain and shall be entitled to vote for its size. Every miner deals with the trade-oﬀbetween balancing the costs and proﬁt from the fees and sets his own “soft-limit” for creating blocks. Also the core rule for the maximum block size is necessary for preventing the blockchain from being ﬂooded with bogus transaction, however this value should not be hard-coded. Let \(M_N\) be the median value of the last \(N\) blocks sizes. Then the “hard-limit” for the size of accepting blocks is \(2 \cdot M_N\). It averts the blockchain from bloating but still allows the limit to slowly grow with time if necessary. Transaction size does not need to be limited explicitly. It is bounded by the size of a block; and if somebody wants to create a huge transaction with hundreds of inputs/outputs (or with the high ambiguity degree in ring signatures), he can do so by paying suﬃcient fee. 6.2.3 Excess size penalty A miner still has the ability to stuﬀa block full of his own zero-fee transactions up to its maximum size \(2 \cdot M_b\). Even though only the majority of miners can shift the median value, there is still a 13 25 Rescaling time so that one unit of time is \(N\) blocks, the average block size could still, theoretically, grow exponentially proportionally to \(2^t\). On the other hand, a more general cap on the next block would be \(M_n \cdot f(M_n)\) for some function \(f\). What properties of \(f\) would we choose in order to guarantee some "reasonable growth" of block size? The progression of block sizes (after rescaling time) would go like this: \(M_n \quad f(M_n) \cdot M_n \quad f(f(M_n) \cdot M_n) \cdot f(M_n) \cdot M_n \quad f(f(f(M_n) \cdot M_n) \cdot f(M_n) \cdot M_n) \cdot f(f(M_n) \cdot M_n) \cdot f(\ldots)\) \(\ldots\) And the goal here is to choose \(f\) such that this sequence grows no faster than, say, linearly, or perhaps even as \(\log(t)\). Of course, if \(f(M_n) = a\) for some constant \(a\), this sequence is actually \(M_n \quad a \cdot M_n \quad a^2 \cdot M_n \quad a^3 \cdot M_n \quad \ldots\) And, of course, the only way this can be limited to at-most linear growth is by choosing \(a = 1\). This is, of course, infeasible. It does not allow growth at all. If, on the other hand, \(f(M_n)\) is a non-constant function, then the situation is much more complicated and may allow for an elegant solution. I’ll think on this for awhile. This fee will have to be large enough to discount the excess size penalty from the next section. Why is a general user assumed male, huh? Huh?

possibility to bloat the blockchain and produce an additional load on the nodes. To discourage malevolent participants from creating large blocks we introduce a penalty function: \[NewReward = BaseReward \cdot \left(\frac{BlkSize}{M_N} - 1\right)^2\] This rule is applied only when \(BlkSize\) is greater than minimal free block size which should be close to \(\max(10kb, M_N \cdot 110\%)\). Miners are permitted to create blocks of “usual size” and even exceed it with proﬁt when the overall fees surpass the penalty. But fees are unlikely to grow quadratically unlike the penalty value so there will be an equilibrium. 6.3 Transaction scripts CryptoNote has a very minimalistic scripting subsystem. A sender speciﬁes an expression \(\Phi = f(x_1, x_2, \ldots, x_n)\), where \(n\) is the number of destination public keys \(\{P_i\}_{i=1}^{n}\). Only ﬁve binary operators are supported: min, max, sum, mul and cmp. When the receiver spends this payment, he produces \(0 \leq k \leq n\) signatures and passes them to transaction input. The veriﬁcation process simply evaluates \(\Phi\) with \(x_i = 1\) to check for a valid signature for the public key \(P_i\), and \(x_i = 0\). A veriﬁer accepts the proof iff \(\Phi > 0\). Despite its simplicity this approach covers every possible case: • Multi-/Threshold signature. For the Bitcoin-style “M-out-of-N” multi-signature (i.e. the receiver should provide at least \(0 \leq M \leq N\) valid signatures) \(\Phi = x_1 + x_2 + \ldots + x_N \geq M\) (for clarity we are using common algebraic notation). The weighted threshold signature (some keys can be more important than other) could be expressed as \(\Phi = w_1 \cdot x_1 + w_2 \cdot x_2 + \ldots + w_N \cdot x_N \geq w_M\). And scenario where the master-key corresponds to \(\Phi = \max(M \cdot x, x_1 + x_2 + \ldots + x_N) \geq M\). It is easy to show that any sophisticated case can be expressed with these operators, i.e. they form basis. • Password protection. Possession of a secret password \(s\) is equivalent to the knowledge of a private key, deterministically derived from the password: \(k = KDF(s)\). Hence, a receiver can prove that he knows the password by providing another signature under the key \(k\). The sender simply adds the corresponding public key to his own output. Note that this method is much more secure than the “transaction puzzle” used in Bitcoin [13], where the password is explicitly passed in the inputs. • Degenerate cases. \(\Phi = 1\) means that anybody can spend the money; \(\Phi = 0\) marks the output as not spendable forever. In the case when the output script combined with public keys is too large for a sender, he can use special output type, which indicates that the recipient will put this data in his input while the sender provides only a hash of it. This approach is similar to Bitcoin’s “pay-to-hash” feature, but instead of adding new script commands we handle this case at the data structure level. 7 Conclusion We have investigated the major ﬂaws in Bitcoin and proposed some possible solutions. These advantageous features and our ongoing development make new electronic cash system CryptoNote a serious rival to Bitcoin, outclassing all its forks. 14 possibility to bloat the blockchain and produce an additional load on the nodes. To discourage malevolent participants from creating large blocks we introduce a penalty function: \[NewReward = BaseReward \cdot \left(\frac{BlkSize}{M_N} - 1\right)^2\] This rule is applied only when \(BlkSize\) is greater than minimal free block size which should be close to \(\max(10kb, M_N \cdot 110\%)\). Miners are permitted to create blocks of “usual size” and even exceed it with proﬁt when the overall fees surpass the penalty. But fees are unlikely to grow quadratically unlike the penalty value so there will be an equilibrium. 6.3 Transaction scripts CryptoNote has a very minimalistic scripting subsystem. A sender speciﬁes an expression \(\Phi = f(x_1, x_2, \ldots, x_n)\), where \(n\) is the number of destination public keys \(\{P_i\}_{i=1}^{n}\). Only ﬁve binary operators are supported: min, max, sum, mul and cmp. When the receiver spends this payment, he produces \(0 \leq k \leq n\) signatures and passes them to transaction input. The veriﬁcation process simply evaluates \(\Phi\) with \(x_i = 1\) to check for a valid signature for the public key \(P_i\), and \(x_i = 0\). A veriﬁer accepts the proof iff \(\Phi > 0\). Despite its simplicity this approach covers every possible case: • Multi-/Threshold signature. For the Bitcoin-style “M-out-of-N” multi-signature (i.e. the receiver should provide at least \(0 \leq M \leq N\) valid signatures) \(\Phi = x_1 + x_2 + \ldots + x_N \geq M\) (for clarity we are using common algebraic notation). The weighted threshold signature (some keys can be more important than other) could be expressed as \(\Phi = w_1 \cdot x_1 + w_2 \cdot x_2 + \ldots + w_N \cdot x_N \geq w_M\). And scenario where the master-key corresponds to \(\Phi = \max(M \cdot x, x_1 + x_2 + \ldots + x_N) \geq M\). It is easy to show that any sophisticated case can be expressed with these operators, i.e. they form basis. • Password protection. Possession of a secret password \(s\) is equivalent to the knowledge of a private key, deterministically derived from the password: \(k = KDF(s)\). Hence, a receiver can prove that he knows the password by providing another signature under the key \(k\). The sender simply adds the corresponding public key to his own output. Note that this method is much more secure than the “transaction puzzle” used in Bitcoin [13], where the password is explicitly passed in the inputs. • Degenerate cases. \(\Phi = 1\) means that anybody can spend the money; \(\Phi = 0\) marks the output as not spendable forever. In the case when the output script combined with public keys is too large for a sender, he can use special output type, which indicates that the recipient will put this data in his input while the sender provides only a hash of it. This approach is similar to Bitcoin’s “pay-to-hash” feature, but instead of adding new script commands we handle this case at the data structure level. 7 Conclusion We have investigated the major ﬂaws in Bitcoin and proposed some possible solutions. These advantageous features and our ongoing development make new electronic cash system CryptoNote a serious rival to Bitcoin, outclassing all its forks. 14 26 This may be unnecessary if we can ﬁgure out a way to bound block size over time... This also cannot be correct. They just set "NewReward" to an upward-facing parabola where block size is the independent variable. So new reward blows up to inﬁnity. If, on the other hand, the new reward is \(\max(0, BaseReward \cdot (1 - (BlkSize/M_n - 1)^2))\), then the new reward would be a downward facing parabola with peak at \(blocksize = M_n\), and with intercepts at \(Blocksize = 0\) and \(Blocksize = 2 \cdot M_n\). And that seems to be what they are trying to describe. However, this does not

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 suﬃsante 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 oﬃciel [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 ﬁxe 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 diﬀé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 Diﬃe-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 Diﬃe-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 Diﬃe-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 Diﬃe-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 Diﬃe-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 Diﬃe-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 Diﬃe-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. Diﬃe 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 Diﬃe-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/Diﬃe%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 Diﬃe-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 Diﬃe-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 Diﬃe-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 Diﬃe-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 Diﬃe-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 Diﬃe-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

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
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 suﬃsant 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.
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
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 ﬁxe. 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 diﬀé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 Diﬃe-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 Diﬃe-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 ﬁxé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 diﬃcile ; construire une fonction hash satisfaisant ces contraintes semble plus diﬃcile. 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 eﬀicace 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 eﬀicace 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 Diﬃculté 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 diﬃculté. 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 suﬃsants. 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 Diﬃculté 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 diﬃculté. 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 suﬃsants. 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 diﬃculté 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 diﬃculté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 Diﬃculté 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 diﬃculté. 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 suﬃsants. 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 Diﬃculté 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 diﬃculté. 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 suﬃsants. 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 ﬁnances, 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 Diﬃculté 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 diﬃculté. 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 suﬃsants. 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 Diﬃculté 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 diﬃculté. 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 suﬃsants. 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

Analysis

5 Not that it matters too much when a billion people in the world live on less than a dollar a day and have no hope in ever participating in any sort of mining network... but an economic world driven by a p2p currency system with one-cpu-one-vote would be, presumably, more fair than a system driven by fractional reserve banking. But Cryptonote’s protocol still requires 51% honest users... see, for example, the Cryptonote forums where one of the developers, Pliskov, says that a traditional replace-the-data-on-theblockchain 51% attack can still work. https://forum.cryptonote.org/viewtopic.php?f=2&t=198 Note that you don’t really need 51% honest users. You just really need "no single dishonest faction with more than 51% of the hashing power of the network." Let’s call this so-called problem of bitcoin "adaptive rigidity." Cryptonote’s solution to adaptive rigidity is adaptive ﬂexibility in the protocol parameter values. If you need block sizes bigger, no problem, the network will have been gently adjusting the whole time. That is to say, the way that Bitcoin adjusts diﬃculty over time can be replicated across all of our protocol parameters so that network consensus need not be obtained for updating the protocol. On the surface this seems like a good idea, but without careful forethought, a self-adjusting system can become quite unpredictable and chaotic. We’ll look further into this later as the opportunities arise. "Good" systems are somewhere between adaptively rigid and adaptively ﬂexible, and perhaps even the rigidity itself are adaptive. If we truly had "one-CPU-one-vote," then collaborating and developing pools to get to 51% would be more diﬃcult. We would expect every CPU in the world to be mining, from phones to the on-board CPU in your Tesla while it’s charging. http://en.wikipedia.org/wiki/Pareto_principle I claim that the Pareto equilibrium is somewhat unavoidable. Either 20% of the system will own 80% of the CPUs, or 20% of the system will own 80% of the ASICs. I hypothesize this because the underlying distribution of wealth in society already exhibits the Pareto distribution, and as new miners join up, they are drawn from that underlying distribution. However, I argue that protocols with one-cpu-one-vote will see ROI on hardware. Block reward per node will be more closely proportional to number of nodes in the network because distribution of performance across the nodes will be much more tight. Bitcoin, on the other hand, sees a block reward (per node) more proportional to the computational capacity of that node. That is to say, only the "big boys" are still in the mining game. On the other hand, even though the Pareto principle will still be in play, in a one-cpu-one-vote world, everyone participates in network security and gains a bit of mining income. In an ASIC world, it’s not sensible to rig every XBox and cell phone to mine. In a onecpu-one-vote world, it’s very sensible in terms of mining reward. As a delightful consequence, gaining 51% of the vote is more diﬃcult when there are more and more votes, yielding a lovely beneﬁt to network security..

Bitcoin network total computation speed chart showing hashrate and difficulty from 2012 to 2013

hardware described previously. Suppose that the global hashrate decreases signiﬁcantly, even for a moment, he can now use his mining power to fork the chain and double-spend. As we shall see later in this article, it is not unlikely for the previously described event to take place. 2.3 Irregular emission Bitcoin has a predetermined emission rate: each solved block produces a ﬁxed amount of coins. Approximately every four years this reward is halved. The original intention was to create a limited smooth emission with exponential decay, but in fact we have a piecewise linear emission function whose breakpoints may cause problems to the Bitcoin infrastructure. When the breakpoint occurs, miners start to receive only half of the value of their previous reward. The absolute diﬀerence between 12.5 and 6.25 BTC (projected for the year 2020) may seem tolerable. However, when examining the 50 to 25 BTC drop that took place on November 28 2012, felt inappropriate for a signiﬁcant number of members of the mining community. Figure 1 shows a dramatic decrease in the network’s hashrate in the end of November, exactly when the halving took place. This event could have been the perfect moment for the malevolent individual described in the proof-of-work function section to carry-out a double spending attack [36]. Fig. 1. Bitcoin hashrate chart (source: http://bitcoin.sipa.be) 2.4 Hardcoded constants Bitcoin has many hard-coded limits, where some are natural elements of the original design (e.g. block frequency, maximum amount of money supply, number of conﬁrmations) whereas other seem to be artiﬁcial constraints. It is not so much the limits, as the inability of quickly changing 3 hardware described previously. Suppose that the global hashrate decreases signiﬁcantly, even for a moment, he can now use his mining power to fork the chain and double-spend. As we shall see later in this article, it is not unlikely for the previously described event to take place. 2.3 Irregular emission Bitcoin has a predetermined emission rate: each solved block produces a ﬁxed amount of coins. Approximately every four years this reward is halved. The original intention was to create a limited smooth emission with exponential decay, but in fact we have a piecewise linear emission function whose breakpoints may cause problems to the Bitcoin infrastructure. When the breakpoint occurs, miners start to receive only half of the value of their previous reward. The absolute diﬀerence between 12.5 and 6.25 BTC (projected for the year 2020) may seem tolerable. However, when examining the 50 to 25 BTC drop that took place on November 28 2012, felt inappropriate for a signiﬁcant number of members of the mining community. Figure 1 shows a dramatic decrease in the network’s hashrate in the end of November, exactly when the halving took place. This event could have been the perfect moment for the malevolent individual described in the proof-of-work function section to carry-out a double spending attack [36]. Fig. 1. Bitcoin hashrate chart (source: http://bitcoin.sipa.be) 2.4 Hardcoded constants Bitcoin has many hard-coded limits, where some are natural elements of the original design (e.g. block frequency, maximum amount of money supply, number of conﬁrmations) whereas other seem to be artiﬁcial constraints. It is not so much the limits, as the inability of quickly changing 3 6 Let’s call this what it is, a zombie attack. Let’s discuss how continuous emission may be related to one-cpu-one-vote in a zombie attack scenario. In a one-cpu-one-vote world, every cell phone and car, whenever idle, would be mining. Collecting heaps of cheap hardware to create a mining farm would be very very easy, because just about everything has a CPU in it. On the other hand, at that point, the number of CPUs required to launch a 51% attack would be quite astonishing, I would think. Furthermore, precisely because it would be easy to collect cheap hardware, we can reasonably expect a lot of folks to start hoarding anything with a CPU. The arms race in a one-cpu-one-vote world is necessarily more egalitarian than in an ASIC world. Hence, a discontinuity in network security due to emission rates should be LESS of a problem in a one-cpu-one-vote world. However, two facts remain: 1) discontinuity in emission rate can lead to a stuttering eﬀect in the economy and in network security both, which is bad, and 2) even though a 51% attack performed by someone collecting cheap hardware can still occur in a one-cpu-one-vote world, it seems like it should be harder. Presumably, the safeguard against this is that all the dishonest actors will be trying this simultaneously, and we fall back to Bitcoin’s previous security notion: "we require no dishonest faction to control more than 51% of the network." The author is claiming here that one problem with bitcoin is that discontinuity in coin emission rate could lead to sudden drops in network participation, and hence network security. Thus, a continuous, diﬀerentiable, smooth coin emission rate is preferable. The author ain’t wrong, necessarily. Any sort of sudden decrease in network participation can lead to such a problem, and if we can remove one source of it, we should. Having said that, it’s possible that long periods of "relatively constant" coin emission punctuated by sudden changes is the ideal way to go from an economics point of view. I’m not an economist. So, perhaps we must decide if we are going to trade network security for economic something-whatsit here? http://arxiv.org/abs/1402.2009

them if necessary that causes the main drawbacks. Unfortunately, it is hard to predict when the constants may need to be changed and replacing them may lead to terrible consequences. A good example of a hardcoded limit change leading to disastrous consequences is the block size limit set to 250kb1. This limit was suﬃcient to hold about 10000 standard transactions. In early 2013, this limit had almost been reached and an agreement was reached to increase the limit. The change was implemented in wallet version 0.8 and ended with a 24-blocks chain split and a successful double-spend attack [9]. While the bug was not in the Bitcoin protocol, but rather in the database engine it could have been easily caught by a simple stress test if there was no artiﬁcially introduced block size limit. Constants also act as a form of centralization point. Despite the peer-to-peer nature of Bitcoin, an overwhelming majority of nodes use the oﬃcial reference client [10] developed by a small group of people. This group makes the decision to implement changes to the protocol and most people accept these changes irrespective of their “correctness”. Some decisions caused heated discussions and even calls for boycott [11], which indicates that the community and the developers may disagree on some important points. It therefore seems logical to have a protocol with user-conﬁgurable and self-adjusting variables as a possible way to avoid these problems. 2.5 Bulky scripts The scripting system in Bitcoin is a heavy and complex feature. It potentially allows one to create sophisticated transactions [12], but some of its features are disabled due to security concerns and some have never even been used [13]. The script (including both senders’ and receivers’ parts) for the most popular transaction in Bitcoin looks like this: OP DUP OP HASH160 OP EQUALVERIFY OP CHECKSIG. The script is 164 bytes long whereas its only purpose is to check if the receiver possess the secret key required to verify his signature.

Analyse

Bitcoin network total computation speed chart showing hashrate and difficulty from 2012 to 2013

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. ﬂexible, 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 diﬃcile. 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 diﬃcile 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é ﬁxe 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é ﬁxe 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 eﬀet 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 suﬃsante 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 oﬃciel [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.