CryptoNote v2.0

저자 Nicolas van Saberhagen · 2013

여기에 제시된 논문은 Nicolas van Saberhagen의 CryptoNote v2.0 백서(2013)로, Monero가 구축된 암호학적 기반을 설명합니다. 이는 Monero 전용 백서가 아니며, Monero는 2014년 CryptoNote 참조 구현체(Bytecoin)의 포크로 출시되어 이후 원본 프로토콜을 훨씬 넘어 진화했습니다.

🇺🇸 English (원문)

🇩🇪 Deutsch (번역)

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.

Einführung

„Bitcoin“ [1] ist eine erfolgreiche Umsetzung des Konzepts des P2P-E-Cash. Beides Fachleute und die breite Öffentlichkeit haben die praktische Kombination von zu schätzen gelernt öffentliche Transaktionen und proof-of-work als Vertrauensmodell. Heute ist die Benutzerbasis von elektronischem Bargeld wächst stetig; Kunden werden von niedrigen Gebühren und der gebotenen Anonymität angezogen durch elektronisches Bargeld und Händler schätzen seine vorhergesagte und dezentrale Ausgabe. Bitcoin hat hat effektiv bewiesen, dass elektronisches Bargeld so einfach wie Papiergeld und so bequem sein kann Kreditkarten. Leider weist Bitcoin mehrere Mängel auf. Beispielsweise ist das System verteilt Die Natur ist unflexibel und verhindert die Implementierung neuer Funktionen, bis fast alle Netzwerkbenutzer ihre Clients aktualisieren. Einige kritische Mängel, die nicht schnell behoben werden können, schrecken Bitcoin ab weite Verbreitung. In solchen unflexiblen Modellen ist es effizienter, ein neues Projekt umzusetzen anstatt das ursprüngliche Projekt ständig zu reparieren. In diesem Artikel untersuchen und schlagen wir Lösungen für die Hauptmängel von Bitcoin vor. Wir glauben dass ein System, das die von uns vorgeschlagenen Lösungen berücksichtigt, zu einem gesunden Wettbewerb führen wird zwischen verschiedenen elektronischen Geldsystemen. Wir bieten auch unser eigenes elektronisches Bargeld „CryptoNote“ an. ein Name, der den nächsten Durchbruch im Bereich des elektronischen Geldes unterstreicht.

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 Nachteile und mögliche Lösungen

2 Bitcoin Nachteile und einige mögliche Lösungen 2.1 Rückverfolgbarkeit von Transaktionen Privatsphäre und Anonymität sind die wichtigsten Aspekte von elektronischem Bargeld. Peer-to-Peer-Zahlungen Sie streben danach, vor der Sicht Dritter verborgen zu bleiben, was einen deutlichen Unterschied zu herkömmlichen Verfahren darstellt Bankwesen. Insbesondere beschrieben T. Okamoto und K. Ohta sechs Kriterien für ideales elektronisches Bargeld: Dazu gehörte „Datenschutz: Die Beziehung zwischen dem Benutzer und seinen Einkäufen muss nicht nachvollziehbar sein.“ von irgendjemandem“ [30]. Aus ihrer Beschreibung haben wir zwei Eigenschaften abgeleitet, die völlig anonym sind Das elektronische Bargeldmodell muss den von Okamoto dargelegten Anforderungen genügen und Ohta: Unverfolgbarkeit: Für jede eingehende Transaktion sind alle möglichen Absender gleichwahrscheinlich. Unverknüpfbarkeit: Für zwei beliebige ausgehende Transaktionen lässt sich nicht nachweisen, dass sie an sie gesendet wurden die gleiche Person. Leider erfüllt Bitcoin nicht die Anforderung der Unauffindbarkeit. Da alle Transaktionen, die zwischen den Netzwerkteilnehmern stattfinden, öffentlich sind, kann jede Transaktion öffentlich sein 1 CryptoNote v 2.0 Nicolas van Saberhagen 17. Oktober 2013 1 Einführung „Bitcoin“ [1] ist eine erfolgreiche Umsetzung des Konzepts des P2P-E-Cash. Beides Fachleute und die breite Öffentlichkeit haben die praktische Kombination von zu schätzen gelernt öffentliche Transaktionen und proof-of-work als Vertrauensmodell. Heute ist die Benutzerbasis von elektronischem Bargeld wächst stetig; Kunden werden von niedrigen Gebühren und der gebotenen Anonymität angezogen durch elektronisches Bargeld und Händler schätzen seine vorhergesagte und dezentrale Ausgabe. Bitcoin hat hat effektiv bewiesen, dass elektronisches Bargeld so einfach wie Papiergeld und so bequem sein kann Kreditkarten. Leider weist Bitcoin mehrere Mängel auf. Beispielsweise ist das System verteilt Die Natur ist unflexibel und verhindert die Implementierung neuer Funktionen, bis fast alle Netzwerkbenutzer ihre Clients aktualisieren. Einige kritische Mängel, die nicht schnell behoben werden können, schrecken Bitcoin ab weite Verbreitung. In solchen unflexiblen Modellen ist es effizienter, ein neues Projekt umzusetzen anstatt das ursprüngliche Projekt ständig zu reparieren. In diesem Artikel untersuchen und schlagen wir Lösungen für die Hauptmängel von Bitcoin vor. Wir glauben dass ein System, das die von uns vorgeschlagenen Lösungen berücksichtigt, zu einem gesunden Wettbewerb führen wird zwischen verschiedenen elektronischen Geldsystemen. Wir bieten auch unser eigenes elektronisches Bargeld „CryptoNote“ an. ein Name, der den nächsten Durchbruch im Bereich des elektronischen Geldes unterstreicht. 2 Bitcoin Nachteile und einige mögliche Lösungen 2.1 Rückverfolgbarkeit von Transaktionen Privatsphäre und Anonymität sind die wichtigsten Aspekte von elektronischem Bargeld. Peer-to-Peer-Zahlungen Sie streben danach, vor der Sicht Dritter verborgen zu bleiben, was einen deutlichen Unterschied zu herkömmlichen Verfahren darstellt Bankwesen. Insbesondere beschrieben T. Okamoto und K. Ohta sechs Kriterien für ideales elektronisches Bargeld: Dazu gehörte „Datenschutz: Die Beziehung zwischen dem Benutzer und seinen Einkäufen muss nicht nachvollziehbar sein.“ von irgendjemandem“ [30]. Aus ihrer Beschreibung haben wir zwei Eigenschaften abgeleitet, die völlig anonym sind Das elektronische Bargeldmodell muss den von Okamoto dargelegten Anforderungen genügen und Ohta: Unverfolgbarkeit: Für jede eingehende Transaktion sind alle möglichen Absender gleichwahrscheinlich. Unverknüpfbarkeit: Für zwei beliebige ausgehende Transaktionen lässt sich nicht nachweisen, dass sie an sie gesendet wurden die gleiche Person. Leider erfüllt Bitcoin nicht die Anforderung der Unauffindbarkeit. Da alle Transaktionen, die zwischen den Netzwerkteilnehmern stattfinden, öffentlich sind, kann jede Transaktion öffentlich sein 1 3 Bitcoin scheitert definitiv an der „Unauffindbarkeit“. Wenn ich Ihnen BTC sende, das Wallet, von dem es gesendet wird ist unwiderruflich auf blockchain gestempelt. Es besteht kein Zweifel darüber, wer diese Gelder geschickt hat. denn nur wer die privaten Schlüssel kennt, kann sie versenden.eindeutig auf einen eindeutigen Ursprung und Endempfänger zurückgeführt werden. Auch wenn sich zwei Teilnehmer austauschen Mittel auf indirektem Weg, eine richtig entwickelte Wegfindungsmethode wird den Ursprung aufdecken und Endempfänger. Es besteht außerdem der Verdacht, dass Bitcoin die zweite Eigenschaft nicht erfüllt. Einige Forscher gab an ([33, 35, 29, 31]), dass eine sorgfältige blockchain-Analyse einen Zusammenhang zwischen aufdecken könnte die Benutzer des Netzwerks Bitcoin und ihre Transaktionen. Obwohl es eine Reihe von Methoden gibt umstritten [25], es besteht der Verdacht, dass viele versteckte persönliche Informationen daraus extrahiert werden können öffentliche Datenbank. Dass Bitcoin die beiden oben genannten Eigenschaften nicht erfüllt, lässt uns zu dem Schluss kommen, dass dies der Fall ist kein anonymes, sondern ein pseudoanonymes elektronisches Bargeldsystem. Die Benutzer entwickelten sich schnell Lösungen, um diesen Mangel zu umgehen. Zwei direkte Lösungen waren „Wäschedienste“ [2] und die Entwicklung verteilter Methoden [3, 4]. Beide Lösungen basieren auf der Idee des Mischens mehrere öffentliche Transaktionen und deren Versand über eine Zwischenadresse; was wiederum hat den Nachteil, dass eine vertrauenswürdige dritte Partei erforderlich ist. Kürzlich wurde von I. Miers et al. ein kreativeres Schema vorgeschlagen. [28]: „Zerocoin“. Zerocoin verwendet kryptografische Einwegakkumulatoren und wissensfreie Beweise, die es Benutzern ermöglichen „Umwandeln“ Sie Bitcoins in Zerocoins und geben Sie sie stattdessen mit einem anonymen Eigentumsnachweis aus explizite, auf öffentlichen Schlüsseln basierende digitale Signaturen. Allerdings haben solche Wissensbeweise eine Konstante aber unpraktische Größe – etwa 30 KB (basierend auf den heutigen Bitcoin-Grenzwerten), was den Vorschlag ausmacht unpraktisch. Die Autoren geben zu, dass das Protokoll wahrscheinlich nie von der Mehrheit akzeptiert werden wird Bitcoin Benutzer [5]. 2.2 Die Funktion proof-of-work Der Erfinder von Bitcoin, Satoshi Nakamoto, beschrieb den Mehrheitsentscheidungsalgorithmus als „oneCPU-one-vote“ und verwendete für seinen proof-of-work eine CPU-gebundene Preisfunktion (double SHA-256). Schema. Da Benutzer für die einzelne Historie der Transaktionsreihenfolge [1] stimmen, ist die Angemessenheit und Konsistenz dieses Prozesses sind kritische Bedingungen für das gesamte System. Die Sicherheit dieses Modells leidet unter zwei Nachteilen. Erstens benötigt es 51 % des Netzwerks Die Mining-Leistung muss unter der Kontrolle ehrlicher Benutzer stehen. Zweitens der Fortschritt des Systems (Fehlerbehebungen, Sicherheitsupdates usw.) erfordern, dass die überwältigende Mehrheit der Benutzer dies unterstützt und ihnen zustimmt Änderungen (dies geschieht, wenn die Benutzer ihre Wallet-Software aktualisieren) [6].Endlich die gleiche Abstimmung Der Mechanismus wird auch für kollektive Umfragen zur Implementierung einiger Funktionen verwendet [7]. Dies ermöglicht es uns, die Eigenschaften zu vermuten, die von proof-of-work erfüllt werden müssen. Preisfunktion. Eine solche Funktion darf es einem Netzwerkteilnehmer nicht ermöglichen, eine signifikante Bedeutung zu erlangen Vorteil gegenüber einem anderen Teilnehmer; es erfordert eine Parität zwischen gemeinsamer Hardware und hoher Hardware Kosten für kundenspezifische Geräte. Aus den aktuellen Beispielen [8] können wir ersehen, dass die Funktion SHA-256 verwendet wird in der Bitcoin-Architektur besitzt diese Eigenschaft nicht, da der Bergbau effizienter wird GPUs und ASIC-Geräte im Vergleich zu High-End-CPUs. Daher schafft Bitcoin günstige Bedingungen für eine große Lücke zwischen der Stimmmacht von Teilnehmer, da dies gegen das „Eine-CPU-eine-Stimme“-Prinzip verstößt, da GPU- und ASIC-Besitzer Eigentümer sind eine viel größere Stimmmacht im Vergleich zu CPU-Besitzern. Es ist ein klassisches Beispiel dafür Pareto-Prinzip, bei dem 20 % der Teilnehmer eines Systems mehr als 80 % der Stimmen kontrollieren. Man könnte argumentieren, dass eine solche Ungleichheit für die Sicherheit des Netzwerks nicht relevant ist, da dies nicht der Fall ist Die geringe Anzahl der Teilnehmer kontrolliert die Mehrheit der Stimmen, aber die Ehrlichkeit dieser Stimmen Teilnehmer, worauf es ankommt. Dieses Argument ist jedoch etwas fehlerhaft, da es eher das ist Möglichkeit, dass billige Spezialhardware auftaucht, und nicht die Ehrlichkeit der Teilnehmer stellt eine Bedrohung dar. Um dies zu demonstrieren, nehmen wir das folgende Beispiel. Angenommen, ein Böswilliger Der Einzelne erlangt beträchtliche Mining-Power, indem er billig seine eigene Mining-Farm gründet 2 eindeutig auf einen eindeutigen Ursprung und Endempfänger zurückgeführt werden. Auch wenn sich zwei Teilnehmer austauschen Mittel auf indirektem Weg, eine richtig entwickelte Wegfindungsmethode wird den Ursprung aufdecken und Endempfänger. Es wird außerdem vermutet, dass Bitcoin die zweite Eigenschaft nicht erfüllt. Einige Forscher gab an ([33, 35, 29, 31]), dass eine sorgfältige blockchain-Analyse einen Zusammenhang zwischen aufdecken könnte die Benutzer des Netzwerks Bitcoin und ihre Transaktionen. Obwohl es eine Reihe von Methoden gibt dMit der Bezeichnung [25] besteht der Verdacht, dass viele versteckte persönliche Informationen daraus extrahiert werden können öffentliche Datenbank. Dass Bitcoin die beiden oben genannten Eigenschaften nicht erfüllt, lässt uns zu dem Schluss kommen, dass dies der Fall ist kein anonymes, sondern ein pseudoanonymes elektronisches Bargeldsystem. Die Benutzer entwickelten sich schnell Lösungen, um diesen Mangel zu umgehen. Zwei direkte Lösungen waren „Wäschedienste“ [2] und die Entwicklung verteilter Methoden [3, 4]. Beide Lösungen basieren auf der Idee des Mischens mehrere öffentliche Transaktionen und deren Versand über eine Zwischenadresse; was wiederum hat den Nachteil, dass eine vertrauenswürdige dritte Partei erforderlich ist. Kürzlich wurde von I. Miers et al. ein kreativeres Schema vorgeschlagen. [28]: „Zerocoin“. Zerocoin verwendet kryptografische Einwegakkumulatoren und wissensfreie Beweise, die es Benutzern ermöglichen „Umwandeln“ Sie Bitcoins in Zerocoins und geben Sie sie stattdessen mit einem anonymen Eigentumsnachweis aus explizite, auf öffentlichen Schlüsseln basierende digitale Signaturen. Allerdings haben solche Wissensbeweise eine Konstante aber unpraktische Größe – etwa 30 KB (basierend auf den heutigen Bitcoin-Grenzwerten), was den Vorschlag ausmacht unpraktisch. Die Autoren geben zu, dass das Protokoll wahrscheinlich nie von der Mehrheit akzeptiert werden wird Bitcoin Benutzer [5]. 2.2 Die Funktion proof-of-work Der Erfinder von Bitcoin, Satoshi Nakamoto, beschrieb den Mehrheitsentscheidungsalgorithmus als „oneCPU-one-vote“ und verwendete für seinen proof-of-work eine CPU-gebundene Preisfunktion (double SHA-256). Schema. Da Benutzer für die einzelne Transaktionsverlaufsreihenfolge [1] stimmen, ist die Angemessenheit und Konsistenz dieses Prozesses sind kritische Bedingungen für das gesamte System. Die Sicherheit dieses Modells leidet unter zwei Nachteilen. Erstens benötigt es 51 % des Netzwerks Die Mining-Leistung muss unter der Kontrolle ehrlicher Benutzer stehen. Zweitens der Fortschritt des Systems (Fehlerbehebungen, Sicherheitsupdates usw.) erfordern, dass die überwältigende Mehrheit der Benutzer dies unterstützt und ihnen zustimmt Änderungen (dies geschieht, wenn die Benutzer ihre Wallet-Software aktualisieren) [6].Endlich die gleiche Abstimmung Der Mechanismus wird auch für kollektive Umfragen zur Implementierung einiger Funktionen verwendet [7]. Dies ermöglicht es uns, die Eigenschaften zu vermuten, die von proof-of-work erfüllt werden müssen. Preisfunktion. Eine solche Funktion darf es einem Netzwerkteilnehmer nicht ermöglichen, eine signifikante Bedeutung zu erlangen Vorteil gegenüber einem anderen Teilnehmer; es erfordert eine Parität zwischen gemeinsamer Hardware und hoher Hardware Kosten für kundenspezifische Geräte. Aus den aktuellen Beispielen [8] können wir ersehen, dass die Funktion SHA-256 verwendet wird in der Bitcoin-Architektur besitzt diese Eigenschaft nicht, da der Bergbau effizienter wird GPUs und ASIC-Geräte im Vergleich zu High-End-CPUs. Daher schafft Bitcoin günstige Bedingungen für eine große Kluft zwischen der Stimmmacht von Teilnehmer, da dies gegen das „Eine-CPU-eine-Stimme“-Prinzip verstößt, da GPU- und ASIC-Besitzer Eigentümer sind eine viel größere Stimmmacht im Vergleich zu CPU-Besitzern. Es ist ein klassisches Beispiel dafür Pareto-Prinzip, bei dem 20 % der Teilnehmer eines Systems mehr als 80 % der Stimmen kontrollieren. Man könnte argumentieren, dass eine solche Ungleichheit für die Sicherheit des Netzwerks nicht relevant ist, da dies nicht der Fall ist Die geringe Anzahl der Teilnehmer kontrolliert die Mehrheit der Stimmen, aber die Ehrlichkeit dieser Stimmen Teilnehmer, worauf es ankommt. Dieses Argument ist jedoch etwas fehlerhaft, da es eher das ist Möglichkeit, dass billige Spezialhardware auftaucht, und nicht die Ehrlichkeit der Teilnehmer stellt eine Bedrohung dar. Um dies zu demonstrieren, nehmen wir das folgende Beispiel. Angenommen, ein Böswilliger Der Einzelne erlangt beträchtliche Mining-Power, indem er billig seine eigene Mining-Farm gründet 2 4 Vermutlich, wenn jeder Nutzer seiner eigenen Anonymität dadurch gerecht wird, dass er immer eine neue Adresse generiert für JEDE erhaltene Zahlung (was absurd, aber technisch gesehen die „richtige“ Vorgehensweise ist), und wenn jeder Benutzer die Anonymität aller anderen dadurch schützen würde, dass er darauf besteht, niemals Geld zu senden zweimal an dieselbe BTC-Adresse senden, dann würde Bitcoin immer noch nur umständlich das übergeben Unverknüpfbarkeitstest. Warum? Verbraucherdaten können genutzt werden, um jederzeit erstaunlich viel über Menschen herauszufinden. Siehe zum Beispiel http://www.applieddatalabs.com/content/target-knows-it-shows Stellen Sie sich nun vor, dass dies 20 Jahre in der Zukunft liegt, und stellen Sie sich außerdem vor, dass Target es nicht einfach wusste über Ihre Kaufgewohnheiten bei Target, aber sie haben die blockchain für ALLES durchsucht IHRE PERSÖNLICHEN EINKÄUFE MIT IHREM COINBASE WALLET FÜR DIE VERGANGENHEIT ZWÖLF JAHRE. Sie werden sagen: „Hey Kumpel, vielleicht möchtest du dir heute Abend ein Hustenmittel besorgen, das wirst du nicht.“ Fühlen Sie sich morgen gut. Dies ist möglicherweise nicht der Fall, wenn die Mehrparteiensortierung korrekt ausgenutzt wird. Siehe zum Beispiel diesBlogbeitrag: http://blog.ezyang.com/2012/07/secure-multiparty-bitcoin-anonymization/ Ich bin von der Rechnung nicht ganz überzeugt, aber ... ein Papier nach dem anderen, oder? Zitat erforderlich. Während das Zerocoin-Protokoll (Standalone) möglicherweise unzureichend ist, ist das Zerocash Das Protokoll scheint Transaktionen mit einer Größe von 1 KB implementiert zu haben. Dieses Projekt wird unterstützt von natürlich die US-amerikanischen und israelischen Streitkräfte, also wer weiß schon, wie robust es ist. Auf der anderen Seite Andererseits möchte niemand mehr Geld ohne Aufsicht ausgeben können als das Militär. http://zerocash-project.org/ Ich bin nicht überzeugt... siehe zum Beispiel http://fc14.ifca.ai/bitcoin/papers/bitcoin14_submission_12.pdf Zitat eines Cryptonote-Entwicklers Maurice Planck (vermutlich ein Pseudonym) aus der Cryptonote Foren: „Zerocoin, Zerocash. Das ist die fortschrittlichste Technologie, das muss ich zugeben. Ja, das Zitat Das Obige stammt aus der Analyse der vorherigen Version des Protokolls. Meines Wissens nach ist das nicht der Fall 288, aber 384 Bytes, aber das sind trotzdem gute Nachrichten. Sie nutzten eine brandneue Technik namens SNARK, die gewisse Nachteile hat: zum Beispiel große anfängliche Datenbank öffentlicher Parameter, die zum Erstellen einer Signatur erforderlich sind (mehr als 1 GB) und Erheblicher Zeitaufwand für die Erstellung einer Transaktion (mehr als eine Minute). Schließlich verwenden sie a junge Krypto, die ich als umstrittene Idee erwähnt habe: https://forum.cryptonote.org/viewtopic.php?f= " - Maurice P. Do 3. April 2014 19:56 Uhr Eine Funktion, die in der CPU ausgeführt wird und nicht für GPU, FPGA oder ASIC geeignet ist Berechnung. Das in proof-of-work verwendete „Puzzle“ wird als Preisfunktion, Kostenfunktion oder bezeichnet Puzzle-Funktion.

eindeutig auf einen eindeutigen Ursprung und Endempfänger zurückgeführt werden. Auch wenn sich zwei Teilnehmer austauschen Mittel auf indirektem Weg, eine richtig entwickelte Wegfindungsmethode wird den Ursprung aufdecken und Endempfänger. Es wird auch vermutet, dass Bitcoin die zweite Eigenschaft nicht erfüllt. Einige Forscher gab an ([33, 35, 29, 31]), dass eine sorgfältige blockchain-Analyse einen Zusammenhang zwischen aufdecken könnte die Benutzer des Netzwerks Bitcoin und ihre Transaktionen. Obwohl es eine Reihe von Methoden gibt umstritten [25], es besteht der Verdacht, dass viele versteckte persönliche Informationen daraus extrahiert werden können öffentliche Datenbank. Dass Bitcoin die beiden oben genannten Eigenschaften nicht erfüllt, lässt uns zu dem Schluss kommen, dass dies der Fall ist kein anonymes, sondern ein pseudoanonymes elektronisches Bargeldsystem. Die Benutzer entwickelten sich schnell Lösungen, um diesen Mangel zu umgehen. Zwei direkte Lösungen waren „Wäschedienste“ [2] und die Entwicklung verteilter Methoden [3, 4]. Beide Lösungen basieren auf der Idee des Mischens mehrere öffentliche Transaktionen und deren Versand über eine Zwischenadresse; was wiederum hat den Nachteil, dass eine vertrauenswürdige dritte Partei erforderlich ist. Kürzlich wurde von I. Miers et al. ein kreativeres Schema vorgeschlagen. [28]: „Zerocoin“. Zerocoin verwendet kryptografische Einwegakkumulatoren und wissensfreie Beweise, die es Benutzern ermöglichen „Umwandeln“ Sie Bitcoins in Zerocoins und geben Sie sie stattdessen mit einem anonymen Eigentumsnachweis aus explizite, auf öffentlichen Schlüsseln basierende digitale Signaturen. Allerdings haben solche Wissensbeweise eine Konstante aber unpraktische Größe – etwa 30 KB (basierend auf den heutigen Bitcoin-Grenzwerten), was den Vorschlag ausmacht unpraktisch. Die Autoren geben zu, dass das Protokoll wahrscheinlich nie von der Mehrheit akzeptiert werden wird Bitcoin Benutzer [5]. 2.2 Die Funktion proof-of-work Der Erfinder von Bitcoin, Satoshi Nakamoto, beschrieb den Mehrheitsentscheidungsalgorithmus als „oneCPU-one-vote“ und verwendete für seinen proof-of-work eine CPU-gebundene Preisfunktion (double SHA-256). Schema. Da Benutzer für die einzelne Transaktionsverlaufsreihenfolge [1] stimmen, ist die Angemessenheit und Konsistenz dieses Prozesses sind kritische Bedingungen für das gesamte System. Die Sicherheit dieses Modells leidet unter zwei Nachteilen. Erstens benötigt es 51 % des Netzwerks Die Mining-Leistung muss unter der Kontrolle ehrlicher Benutzer stehen. Zweitens der Fortschritt des Systems (Fehlerbehebungen, Sicherheitsupdates usw.) erfordern, dass die überwältigende Mehrheit der Benutzer dies unterstützt und ihnen zustimmt Änderungen (dies geschieht, wenn die Benutzer ihre Wallet-Software aktualisieren) [6]. Endlich die gleiche Abstimmung Der Mechanismus wird auch für kollektive Umfragen zur Implementierung einiger Funktionen verwendet [7]. Dies ermöglicht es uns, die Eigenschaften zu vermuten, die von proof-of-work erfüllt werden müssen. Preisfunktion. Eine solche Funktion darf es einem Netzwerkteilnehmer nicht ermöglichen, eine signifikante Bedeutung zu erlangen Vorteil gegenüber einem anderen Teilnehmer; es erfordert eine Parität zwischen gemeinsamer Hardware und hoher Hardware Kosten für kundenspezifische Geräte. Aus den aktuellen Beispielen [8] können wir ersehen, dass die Funktion SHA-256 verwendet wird in der Bitcoin-Architektur besitzt diese Eigenschaft nicht, da der Bergbau effizienter wird GPUs und ASIC-Geräte im Vergleich zu High-End-CPUs. Daher schafft Bitcoin günstige Bedingungen für eine große Kluft zwischen der Stimmmacht von Teilnehmer, da dies gegen das „Eine-CPU-eine-Stimme“-Prinzip verstößt, da GPU- und ASIC-Besitzer Eigentümer sind eine viel größere Stimmmacht im Vergleich zu CPU-Besitzern. Es ist ein klassisches Beispiel dafür Pareto-Prinzip, bei dem 20 % der Teilnehmer eines Systems mehr als 80 % der Stimmen kontrollieren. Man könnte argumentieren, dass eine solche Ungleichheit für die Sicherheit des Netzwerks nicht relevant ist, da dies nicht der Fall ist Die geringe Anzahl der Teilnehmer kontrolliert die Mehrheit der Stimmen, aber die Ehrlichkeit dieser Stimmen Teilnehmer, worauf es ankommt. Dieses Argument ist jedoch etwas fehlerhaft, da es eher das ist Möglichkeit, dass billige Spezialhardware auftaucht, und nicht die Ehrlichkeit der Teilnehmer stellt eine Bedrohung dar. Um dies zu demonstrieren, nehmen wir das folgende Beispiel. Angenommen, ein Böswilliger Der Einzelne erlangt beträchtliche Mining-Power, indem er billig seine eigene Mining-Farm gründet 2 eindeutig auf einen eindeutigen Ursprung und Endempfänger zurückgeführt werden. Auch wenn sich zwei Teilnehmer austauschen Mittel auf indirektem Weg, eine richtig entwickelte Wegfindungsmethode wird den Ursprung aufdecken und Endempfänger. Es wird auch vermutet, dass Bitcoin die zweite Eigenschaft nicht erfüllt. Einige Forscher gab an ([33, 35, 29, 31]), dass eine sorgfältige blockchain-Analyse einen Zusammenhang zwischen aufdecken könnte die Benutzer des Netzwerks Bitcoin und ihre Transaktionen. Obwohl es eine Reihe von Methoden gibt dMit der Bezeichnung [25] besteht der Verdacht, dass viele versteckte persönliche Informationen daraus extrahiert werden können öffentliche Datenbank. Dass Bitcoin die beiden oben genannten Eigenschaften nicht erfüllt, lässt uns zu dem Schluss kommen, dass dies der Fall ist kein anonymes, sondern ein pseudoanonymes elektronisches Bargeldsystem. Die Benutzer entwickelten sich schnell Lösungen, um diesen Mangel zu umgehen. Zwei direkte Lösungen waren „Wäschedienste“ [2] und die Entwicklung verteilter Methoden [3, 4]. Beide Lösungen basieren auf der Idee des Mischens mehrere öffentliche Transaktionen und deren Versand über eine Zwischenadresse; was wiederum hat den Nachteil, dass eine vertrauenswürdige dritte Partei erforderlich ist. Kürzlich wurde von I. Miers et al. ein kreativeres Schema vorgeschlagen. [28]: „Zerocoin“. Zerocoin verwendet kryptografische Einwegakkumulatoren und wissensfreie Beweise, die es Benutzern ermöglichen „Umwandeln“ Sie Bitcoins in Zerocoins und geben Sie sie stattdessen mit einem anonymen Eigentumsnachweis aus explizite, auf öffentlichen Schlüsseln basierende digitale Signaturen. Allerdings haben solche Wissensbeweise eine Konstante aber unpraktische Größe – etwa 30 KB (basierend auf den heutigen Bitcoin-Grenzwerten), was den Vorschlag ausmacht unpraktisch. Die Autoren geben zu, dass das Protokoll wahrscheinlich nie von der Mehrheit akzeptiert werden wird Bitcoin Benutzer [5]. 2.2 Die Funktion proof-of-work Der Erfinder von Bitcoin, Satoshi Nakamoto, beschrieb den Mehrheitsentscheidungsalgorithmus als „oneCPU-one-vote“ und verwendete für seinen proof-of-work eine CPU-gebundene Preisfunktion (double SHA-256). Schema. Da Benutzer für die einzelne Historie der Transaktionsreihenfolge [1] stimmen, ist die Angemessenheit und Konsistenz dieses Prozesses sind kritische Bedingungen für das gesamte System. Die Sicherheit dieses Modells leidet unter zwei Nachteilen. Erstens benötigt es 51 % des Netzwerks Die Mining-Leistung muss unter der Kontrolle ehrlicher Benutzer stehen. Zweitens der Fortschritt des Systems (Fehlerbehebungen, Sicherheitsupdates usw.) erfordern, dass die überwältigende Mehrheit der Benutzer dies unterstützt und ihnen zustimmt Änderungen (dies geschieht, wenn die Benutzer ihre Wallet-Software aktualisieren) [6].Endlich die gleiche Abstimmung Der Mechanismus wird auch für kollektive Umfragen zur Implementierung einiger Funktionen verwendet [7]. Dies ermöglicht es uns, die Eigenschaften zu vermuten, die von proof-of-work erfüllt werden müssen. Preisfunktion. Eine solche Funktion darf es einem Netzwerkteilnehmer nicht ermöglichen, eine signifikante Bedeutung zu erlangen Vorteil gegenüber einem anderen Teilnehmer; es erfordert eine Parität zwischen gemeinsamer Hardware und hoher Hardware Kosten für kundenspezifische Geräte. Aus den aktuellen Beispielen [8] können wir ersehen, dass die Funktion SHA-256 verwendet wird in der Bitcoin-Architektur besitzt diese Eigenschaft nicht, da der Bergbau effizienter wird GPUs und ASIC-Geräte im Vergleich zu High-End-CPUs. Daher schafft Bitcoin günstige Bedingungen für eine große Kluft zwischen der Stimmmacht von Teilnehmer, da dies gegen das „Eine-CPU-eine-Stimme“-Prinzip verstößt, da GPU- und ASIC-Besitzer Eigentümer sind eine viel größere Stimmmacht im Vergleich zu CPU-Besitzern. Es ist ein klassisches Beispiel dafür Pareto-Prinzip, bei dem 20 % der Teilnehmer eines Systems mehr als 80 % der Stimmen kontrollieren. Man könnte argumentieren, dass eine solche Ungleichheit für die Sicherheit des Netzwerks nicht relevant ist, da dies nicht der Fall ist Die geringe Anzahl der Teilnehmer kontrolliert die Mehrheit der Stimmen, aber die Ehrlichkeit dieser Stimmen Teilnehmer, worauf es ankommt. Dieses Argument ist jedoch etwas fehlerhaft, da es eher das ist Möglichkeit, dass billige Spezialhardware auftaucht, und nicht die Ehrlichkeit der Teilnehmer stellt eine Bedrohung dar. Um dies zu demonstrieren, nehmen wir das folgende Beispiel. Angenommen, ein Böswilliger Der Einzelne erlangt beträchtliche Mining-Power, indem er billig seine eigene Mining-Farm gründet 2 Kommentare auf Seite 2

The CryptoNote Technology

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

Die CryptoNote-Technologie

Nachdem wir uns nun mit den Einschränkungen der Bitcoin-Technologie befasst haben, konzentrieren wir uns auf Vorstellung der Funktionen von 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

Nicht nachvollziehbare Transaktionen

In diesem Abschnitt schlagen wir ein Schema vollständig anonymer Transaktionen vor, das beide Anforderungen an die Rückverfolgbarkeit erfüllt und Unverknüpfbarkeitsbedingungen. Ein wichtiges Merkmal unserer Lösung ist ihre Autonomie: der Absender ist nicht verpflichtet, mit anderen Benutzern oder einem vertrauenswürdigen Dritten zusammenzuarbeiten, um seine Transaktionen durchzuführen; somit erzeugt jeder Teilnehmer selbstständig einen Deckungsverkehr. 4.1 Literaturübersicht Unser Schema basiert auf dem kryptografischen Grundelement, das als Gruppensignatur bezeichnet wird. Erstmals präsentiert von D. Chaum und E. van Heyst [19] ermöglicht es einem Benutzer, seine Nachricht im Namen der Gruppe zu signieren. Nach dem Signieren der Nachricht stellt der Benutzer (zu Verifizierungszwecken) nicht seine eigene Einzelöffentlichkeit zur Verfügung 1Dies ist das sogenannte „Soft Limit“ – die Referenz-Client-Einschränkung für die Erstellung neuer Blöcke. Hartes Maximum von Die mögliche Blockgröße betrug 1 MB 4 wenn nötig, verursacht das die Hauptnachteile. Leider ist es schwer vorherzusagen, wann Konstanten müssen möglicherweise geändert werden, und ihre Ersetzung kann schreckliche Folgen haben. Ein gutes Beispiel für eine hartcodierte Grenzwertänderung, die katastrophale Folgen hat, ist der Block Größenbeschränkung auf 250 KB1 festgelegt. Dieses Limit reichte aus, um etwa 10.000 Standardtransaktionen aufzunehmen. In Anfang 2013 war diese Grenze fast erreicht und man einigte sich auf eine Erhöhung Grenze. Die Änderung wurde in Wallet-Version 0.8 implementiert und endete mit einer 24-Block-Chain-Aufteilung und ein erfolgreicher Double-Spend-Angriff [9]. Der Fehler lag zwar nicht im Protokoll Bitcoin, aber Vielmehr hätte es in der Datenbank-Engine leicht durch einen einfachen Stresstest erkannt werden können, wenn dies der Fall gewesen wäre keine künstlich eingeführte Blockgrößenbeschränkung. Konstanten fungieren auch als eine Art Zentralisierungspunkt. Trotz des Peer-to-Peer-Charakters von Bitcoin, eine überwältigende Mehrheit der Knoten verwendet den offiziellen Referenzclient [10], der von entwickelt wurde eine kleine Gruppe von Menschen. Diese Gruppe trifft die Entscheidung, Änderungen am Protokoll umzusetzen und die meisten Menschen akzeptieren diese Änderungen unabhängig von ihrer „Richtigkeit“. Einige Entscheidungen verursachten hitzige Diskussionen und sogar Boykottaufrufe [11], was darauf hindeutet, dass die Community und die Entwickler können in einigen wichtigen Punkten anderer Meinung sein. Daher erscheint es logisch, ein Protokoll zu haben mit vom Benutzer konfigurierbaren und selbstanpassenden Variablen als mögliche Möglichkeit, diese Probleme zu vermeiden. 2.5 Umfangreiche Skripte Das Skriptsystem in Bitcoin ist eine umfangreiche und komplexe Funktion. Es ermöglicht einem möglicherweise, etwas zu erschaffen ausgefeilte Transaktionen [12], aber einige seiner Funktionen sind aus Sicherheitsgründen deaktiviert und einige wurden noch nie verwendet [13]. Das Skript (einschließlich der Teile des Senders und des Empfängers) für die beliebteste Transaktion in Bitcoin sieht das so aus: OP DUP OP HASH160 OP EQUALVERIFY OP CHECKSIG. Das Skript ist 164 Bytes lang, wobei sein einziger Zweck darin besteht, zu überprüfen, ob der Empfänger über das Skript verfügt geheimer Schlüssel, der zur Überprüfung seiner Signatur erforderlich ist. 3 Die CryptoNote-Technologie Nachdem wir uns nun mit den Einschränkungen der Bitcoin-Technologie befasst haben, konzentrieren wir uns darauf Vorstellung der Funktionen von CryptoNote. 4 Nicht nachvollziehbare Transaktionen In diesem Abschnitt schlagen wir ein Schema vollständig anonymer Transaktionen vor, das beide Anforderungen an die Rückverfolgbarkeit erfüllt und Unverknüpfbarkeitsbedingungen. Ein wichtiges Merkmal unserer Lösung ist ihre Autonomie: der Absender ist nicht verpflichtet, mit anderen Benutzern oder einem vertrauenswürdigen Dritten zusammenzuarbeiten, um seine Transaktionen durchzuführen; somit erzeugt jeder Teilnehmer selbstständig einen Deckungsverkehr. 4.1 Literaturübersicht Unser Schema basiert auf dem kryptografischen Grundelement, das als Gruppensignatur bezeichnet wird. Erstmals präsentiert von D. Chaum und E. van Heyst [19] ermöglicht es einem Benutzer, seine Nachricht im Namen der Gruppe zu signieren. Nach dem Signieren der Nachricht stellt der Benutzer (zu Verifizierungszwecken) nicht seine eigene Einzelöffentlichkeit zur Verfügung 1Dies ist das sogenannte „Soft Limit“ – die Referenz-Client-Einschränkung für die Erstellung neuer Blöcke. Hartes Maximum von Die mögliche Blockgröße betrug 1 MB 4 7 Rückblickend scheint es ein großer Fehler gewesen zu sein, die Blockgröße im Code als feste Grenze festzulegen. Visa und Mastercard können Tausende, wenn nicht Hunderttausende Transaktionen verarbeiten pro Sekunde. Allerdings erfolgen Transaktionen in einem stochastischen Prozess, manchmal in großen Schüben. manchmal stundenlang still sein. Denken Sie an das Volumen des Bitcoin-Umtauschs. Scheint eine großartige Idee zu sein, ein System zu entwerfen, das die Blockgröße bei Bedarf dynamisch erhöht um den erhöhten Transaktionsverkehr zu bewältigen und ihn bei Bedarf dynamisch zu verringern Erhöhen Sie die Bandbreiteneffizienz. Wenden Sie diesen Gedanken nun auf alle Systemparameter an. Und solange wir darauf achten, das zu behalten System davor, außer Kontrolle zu geraten, dieses SchiffWürde großartig funktionieren. https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki Wie bereits erwähnt, müssen für die Selbstanpassung von Variablen einige Kontrollen vorgenommen werden verhindern, dass das System völlig außer Kontrolle gerät. Wir werden darauf zurückkommen. Wenn dies ein Wikipedia-Artikel wäre, würde er mit „STUB“ gekennzeichnet sein. Obwohl wir uns sicherlich in der befinden Im Abschnitt „Probleme von Bitcoin“ würde ich hier gerne etwas näher darauf eingehen. Warum ist 164 Bytes sind für eine einfache Aufgabe „Auf geheimen Schlüssel prüfen“ inakzeptabel? Für wie wenig können sie denn bekommen eine vernünftige Skriptsprache? Allerdings bin ich kein Informatiker. http://download.springer.com/static/pdf/412/chp%253A10.1007%252F3-540-46416-6_22.pdf?auth66=140 Für Gruppensignaturen ist, wie beschrieben, ein Gruppenmanager erforderlich. Der Gruppenleiter ist kompetent die Anonymität eines Unterzeichners zu widerrufen. Daher gibt es eine eingebaute Zentralisierung in einer Gruppe Signaturschema.

Schlüssel, sondern die Schlüssel aller Benutzer seiner Gruppe. Ein Prüfer ist überzeugt, dass der wahre Unterzeichner ein ist Mitglied der Gruppe, kann den Unterzeichner jedoch nicht ausschließlich identifizieren. Das ursprüngliche Protokoll erforderte einen vertrauenswürdigen Dritten (den sogenannten Group Manager), und das war er auch der Einzige, der den Unterzeichner ausfindig machen konnte. Die nächste Version namens Ringsignatur wurde eingeführt von Rivest et al. in [34], war ein autonomes Schema ohne Gruppenmanager und Anonymität Widerruf. Später erschienen verschiedene Modifikationen dieses Schemas: verknüpfbare Ringsignatur [26, 27, 17] erlaubte nachvollziehbar festzustellen, ob zwei Unterschriften von demselben Gruppenmitglied stammten Die Ringsignatur [24, 23] schränkte die übermäßige Anonymität ein, indem sie die Möglichkeit bot, den Unterzeichner zu ermitteln zwei Nachrichten in Bezug auf dieselbe Metainformation (oder „Tag“ im Sinne von [24]). Eine ähnliche kryptografische Konstruktion wird auch als Ad-hoc-Gruppensignatur bezeichnet [16, 38]. Es betont die willkürliche Gruppenbildung, während Gruppen-/Ringsignaturschemata eher a implizieren fester Satz von Mitgliedern. Unsere Lösung basiert größtenteils auf der Arbeit „Traceable ring signatur“ von E. Fujisaki und K. Suzuki [24]. Um den ursprünglichen Algorithmus und unsere Modifikation zu unterscheiden, werden wir Folgendes tun Letzteres wird als einmalige Ringsignatur bezeichnet und betont die Fähigkeit des Benutzers, nur eine gültige Signatur zu erstellen Signatur unter seinem privaten Schlüssel. Wir haben die Rückverfolgbarkeitseigenschaft abgeschwächt und die Verknüpfbarkeit beibehalten Nur um die Einmaligkeit zu gewährleisten: Der öffentliche Schlüssel kann in vielen ausländischen Verifizierungssätzen erscheinen und die Der private Schlüssel kann zum Generieren einer eindeutigen anonymen Signatur verwendet werden. Im Falle einer doppelten Ausgabe Beim ersten Versuch werden diese beiden Signaturen miteinander verknüpft, eine Offenlegung des Unterzeichners ist jedoch nicht erforderlich für unsere Zwecke. 4.2 Definitionen 4.2.1 Parameter der elliptischen Kurve Als Basis-Signaturalgorithmus haben wir uns für das schnelle Schema EdDSA entschieden, das entwickelt und entwickelt wurde umgesetzt von D.J. Bernstein et al. [18]. Wie der ECDSA von Bitcoin basiert er auf der elliptischen Kurve Da es sich hierbei um ein diskretes Logarithmusproblem handelt, könnte unser Schema in Zukunft auch auf Bitcoin angewendet werden. Gemeinsame Parameter sind: q: eine Primzahl; q = 2255 −19; d: ein Element von Fq; d = −121665/121666; E: eine elliptische Kurvengleichung; −x2 + y2 = 1 + dx2y2; G: ein Basispunkt; G = (x, −4/5); l: eine Primzahlordnung des Basispunkts; l = 2252 + 27742317777372353535851937790883648493; \(H_s\): eine kryptografische hash-Funktion \(\{0, 1\}^* \to \mathbb{F}_q\); \(H_p\): eine deterministische hash Funktion \(E(\mathbb{F}_q) \to E(\mathbb{F}_q)\). 4.2.2 Terminologie Für eine verbesserte Privatsphäre ist eine neue Terminologie erforderlich, die nicht mit Bitcoin-Entitäten verwechselt werden sollte. Der private ec-Schlüssel ist ein standardmäßiger privater Schlüssel mit elliptischer Kurve: eine Zahl \(a \in [1, l - 1]\); Der öffentliche ec-Schlüssel ist ein standardmäßiger öffentlicher Schlüssel mit elliptischer Kurve: ein Punkt A = aG; Ein einmaliges Schlüsselpaar ist ein Paar privater und öffentlicher EC-Schlüssel. 5 Schlüssel, sondern die Schlüssel aller Benutzer seiner Gruppe. Ein Prüfer ist überzeugt, dass der wahre Unterzeichner ein ist Mitglied der Gruppe, kann den Unterzeichner jedoch nicht ausschließlich identifizieren. Das ursprüngliche Protokoll erforderte einen vertrauenswürdigen Dritten (den sogenannten Group Manager), und das war er auch der Einzige, der den Unterzeichner ausfindig machen konnte. Die nächste Version namens Ringsignatur wurde eingeführt von Rivest et al. in [34], war ein autonomes System ohne Gruppenmanager und Anonymität Widerruf. Später erschienen verschiedene Modifikationen dieses Schemas: verknüpfbare Ringsignatur [26, 27, 17] erlaubte nachvollziehbar festzustellen, ob zwei Unterschriften von demselben Gruppenmitglied stammten Die Ringsignatur [24, 23] schränkte die übermäßige Anonymität ein, indem sie die Möglichkeit bot, den Unterzeichner zu ermitteln zwei Nachrichten in Bezug auf dieselbe Metainformation (oder „Tag“ im Sinne von [24]). Eine ähnliche kryptografische Konstruktion wird auch als Ad-hoc-Gruppensignatur bezeichnet [16, 38]. Es betont die willkürliche Gruppenbildung, während Gruppen-/Ringsignaturschemata eher a implizieren fester Satz von Mitgliedern. Unsere Lösung basiert größtenteils auf der Arbeit „Traceable ring signatur“ von E. Fujisaki und K. Suzuki [24]. Um den ursprünglichen Algorithmus und unsere Modifikation zu unterscheiden, werden wir Folgendes tun Letzteres wird als einmalige Ringsignatur bezeichnet und betont die Fähigkeit des Benutzers, nur eine gültige Signatur zu erstellen Signatur unter seinem privaten Schlüssel. Wir haben die Rückverfolgbarkeitseigenschaft abgeschwächt und die Verknüpfbarkeit beibehalten Nur um die Einmaligkeit zu gewährleisten: Der öffentliche Schlüssel kann in vielen ausländischen Verifizierungssätzen erscheinen und die Der private Schlüssel kann zum Generieren einer eindeutigen anonymen Signatur verwendet werden. Im Falle einer doppelten Ausgabe Beim ersten Versuch werden diese beiden Signaturen miteinander verknüpft, eine Offenlegung des Unterzeichners ist jedoch nicht erforderlich für unsere Zwecke. 4.2 Definitionen 4.2.1 Parameter der elliptischen Kurve Als unseren Basissignaturalgorithmus wählen wire, um das schnelle Schema EdDSA zu verwenden, das entwickelt wurde und umgesetzt von D.J. Bernstein et al. [18]. Wie der ECDSA von Bitcoin basiert er auf der elliptischen Kurve Problem des diskreten Logarithmus, daher könnte unser Schema in Zukunft auch auf Bitcoin angewendet werden. Gemeinsame Parameter sind: q: eine Primzahl; q = 2255 −19; d: ein Element von Fq; d = −121665/121666; E: eine elliptische Kurvengleichung; −x2 + y2 = 1 + dx2y2; G: ein Basispunkt; G = (x, −4/5); l: eine Primzahlordnung des Basispunkts; l = 2252 + 27742317777372353535851937790883648493; \(H_s\): eine kryptografische hash-Funktion \(\{0, 1\}^* \to \mathbb{F}_q\); \(H_p\): eine deterministische hash Funktion \(E(\mathbb{F}_q) \to E(\mathbb{F}_q)\). 4.2.2 Terminologie Für eine verbesserte Privatsphäre ist eine neue Terminologie erforderlich, die nicht mit Bitcoin-Entitäten verwechselt werden sollte. Der private ec-Schlüssel ist ein standardmäßiger privater Schlüssel mit elliptischer Kurve: eine Zahl \(a \in [1, l - 1]\); Der öffentliche ec-Schlüssel ist ein standardmäßiger öffentlicher Schlüssel mit elliptischer Kurve: ein Punkt A = aG; Ein einmaliges Schlüsselpaar ist ein Paar privater und öffentlicher EC-Schlüssel. 5 8 Eine Ringsignatur funktioniert so: Alex möchte eine Nachricht über ihren Arbeitgeber an WikiLeaks weitergeben. Jeder Mitarbeiter in seinem Unternehmen verfügt über ein privates/öffentliches Schlüsselpaar (Ri, Ui). Sie komponiert ihre Signatur mit Eingaben wie ihre Nachricht, m, ihr privater Schlüssel, Ri und EVERYBODY’s öffentliche Schlüssel, (Ui;i=1...n). Jeder (ohne private Schlüssel zu kennen) kann dies leicht überprüfen irgendein Paar (Rj, Uj) muss zum Erstellen der Signatur verwendet worden sein ... jemand, der funktioniert für Alex‘ Arbeitgeber ... aber es ist im Wesentlichen eine zufällige Vermutung, um herauszufinden, welcher es sein könnte. 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 Beachten Sie, dass eine hier beschriebene verknüpfbare Ringsignatur sozusagen das Gegenteil von „nicht verknüpfbar“ ist. oben beschrieben. Hier fangen wir zwei Nachrichten ab und können feststellen, ob sie identisch sind Die Partei hat sie geschickt, obwohl wir immer noch nicht in der Lage sein sollten, festzustellen, wer diese Partei ist. Die Die zur Erstellung von Cryptonote verwendete Definition von „nicht verknüpfbar“ bedeutet, dass wir nicht feststellen können, ob dieselbe Partei empfängt sie. Was wir hier also wirklich haben, sind VIER Dinge, die vor sich gehen. Ein System kann verknüpfbar sein oder nicht verlinkbar, je nachdem, ob festgestellt werden kann, ob der Absender von zwei Nachrichten sind gleich (unabhängig davon, ob dies einen Widerruf der Anonymität erfordert). Und Ein System kann nicht verknüpfbar oder nicht verknüpfbar sein, je nachdem, ob dies möglich ist oder nicht Bestimmen Sie, ob die Empfänger zweier Nachrichten identisch sind (unabhängig davon, ob oder nicht). dies erfordert den Widerruf der Anonymität). Bitte machen Sie mir nicht die Schuld für diese schreckliche Terminologie. Graphentheoretiker sollten es wahrscheinlich sein erfreut. Einige von Ihnen sind möglicherweise mit „Empfänger verknüpfbar“ im Vergleich zu „Sender verknüpfbar“ zufriedener. http://link.springer.com/chapter/10.1007/978-3-540-71677-8_13 Als ich das las, kam mir das wie eine alberne Funktion vor. Dann habe ich gelesen, dass es eine Funktion für sein könnte elektronische Abstimmung, und das schien Sinn zu machen. Irgendwie cool, aus dieser Perspektive. Aber ich bin Ich bin mir nicht ganz sicher, ob ich absichtlich nachverfolgbare Ringsignaturen implementieren soll. http://search.ieice.org/bin/summary.php?id=e95-a_1_151

Schlüssel, sondern die Schlüssel aller Benutzer seiner Gruppe. Ein Prüfer ist überzeugt, dass der wahre Unterzeichner ein ist Mitglied der Gruppe, kann den Unterzeichner jedoch nicht ausschließlich identifizieren. Das ursprüngliche Protokoll erforderte einen vertrauenswürdigen Dritten (den sogenannten Group Manager), und das war er auch der Einzige, der den Unterzeichner ausfindig machen konnte. Die nächste Version namens Ringsignatur wurde eingeführt von Rivest et al. in [34], war ein autonomes System ohne Gruppenmanager und Anonymität Widerruf. Später erschienen verschiedene Modifikationen dieses Schemas: verknüpfbare Ringsignatur [26, 27, 17] erlaubte nachvollziehbar festzustellen, ob zwei Unterschriften von demselben Gruppenmitglied stammten Die Ringsignatur [24, 23] schränkte die übermäßige Anonymität ein, indem sie die Möglichkeit bot, den Unterzeichner zu ermitteln zwei Nachrichten in Bezug auf dieselbe Metainformation (oder „Tag“ im Sinne von [24]). Eine ähnliche kryptografische Konstruktion wird auch als Ad-hoc-Gruppensignatur bezeichnet [16, 38]. Es betont die willkürliche Gruppenbildung, während Gruppen-/Ringsignaturschemata eher a implizieren fester Satz von Mitgliedern. Unsere Lösung basiert größtenteils auf der Arbeit „Traceable ring signatur“ von E. Fujisaki und K. Suzuki [24]. Um den ursprünglichen Algorithmus und unsere Modifikation zu unterscheiden, werden wir Folgendes tun Letzteres wird als einmalige Ringsignatur bezeichnet und betont die Fähigkeit des Benutzers, nur eine gültige Signatur zu erstellen Signatur unter seinem privaten Schlüssel. Wir haben die Rückverfolgbarkeitseigenschaft abgeschwächt und die Verknüpfbarkeit beibehalten Nur um die Einmaligkeit zu gewährleisten: Der öffentliche Schlüssel kann in vielen ausländischen Verifizierungssätzen erscheinen und die Der private Schlüssel kann zum Generieren einer eindeutigen anonymen Signatur verwendet werden. Im Falle einer doppelten Ausgabe Beim ersten Versuch werden diese beiden Signaturen miteinander verknüpft, eine Offenlegung des Unterzeichners ist jedoch nicht erforderlich für unsere Zwecke. 4.2 Definitionen 4.2.1 Parameter der elliptischen Kurve Als Basis-Signaturalgorithmus haben wir uns für das schnelle Schema EdDSA entschieden, das entwickelt und entwickelt wurde umgesetzt von D.J. Bernstein et al. [18]. Wie der ECDSA von Bitcoin basiert er auf der elliptischen Kurve Problem des diskreten Logarithmus, daher könnte unser Schema in Zukunft auch auf Bitcoin angewendet werden. Gemeinsame Parameter sind: q: eine Primzahl; q = 2255 −19; d: ein Element von Fq; d = −121665/121666; E: eine elliptische Kurvengleichung; −x2 + y2 = 1 + dx2y2; G: ein Basispunkt; G = (x, −4/5); l: eine Primzahlordnung des Basispunkts; l = 2252 + 27742317777372353535851937790883648493; \(H_s\): eine kryptografische hash-Funktion \(\{0, 1\}^* \to \mathbb{F}_q\); \(H_p\): eine deterministische hash Funktion \(E(\mathbb{F}_q) \to E(\mathbb{F}_q)\). 4.2.2 Terminologie Für eine verbesserte Privatsphäre ist eine neue Terminologie erforderlich, die nicht mit Bitcoin-Entitäten verwechselt werden sollte. Der private ec-Schlüssel ist ein standardmäßiger privater Schlüssel mit elliptischer Kurve: eine Zahl \(a \in [1, l - 1]\); Der öffentliche ec-Schlüssel ist ein standardmäßiger öffentlicher Schlüssel mit elliptischer Kurve: ein Punkt A = aG; Ein einmaliges Schlüsselpaar ist ein Paar privater und öffentlicher EC-Schlüssel. 5 Schlüssel, sondern die Schlüssel aller Benutzer seiner Gruppe. Ein Prüfer ist überzeugt, dass der wahre Unterzeichner ein ist Mitglied der Gruppe, kann den Unterzeichner jedoch nicht ausschließlich identifizieren. Das ursprüngliche Protokoll erforderte einen vertrauenswürdigen Dritten (den sogenannten Group Manager), und das war er auch der Einzige, der den Unterzeichner ausfindig machen konnte. Die nächste Version namens Ringsignatur wurde eingeführt von Rivest et al. in [34], war ein autonomes System ohne Gruppenmanager und Anonymität Widerruf. Später erschienen verschiedene Modifikationen dieses Schemas: verknüpfbare Ringsignatur [26, 27, 17] erlaubte nachvollziehbar festzustellen, ob zwei Unterschriften von demselben Gruppenmitglied stammten Die Ringsignatur [24, 23] schränkte die übermäßige Anonymität ein, indem sie die Möglichkeit bot, den Unterzeichner zu ermitteln zwei Nachrichten in Bezug auf dieselbe Metainformation (oder „Tag“ im Sinne von [24]). Eine ähnliche kryptografische Konstruktion wird auch als Ad-hoc-Gruppensignatur bezeichnet [16, 38]. Es betont die willkürliche Gruppenbildung, während Gruppen-/Ringsignaturschemata eher a implizieren fester Satz von Mitgliedern. Unsere Lösung basiert größtenteils auf der Arbeit „Traceable ring signatur“ von E. Fujisaki und K. Suzuki [24]. Um den ursprünglichen Algorithmus und unsere Modifikation zu unterscheiden, werden wir Folgendes tun Letzteres wird als einmalige Ringsignatur bezeichnet und betont die Fähigkeit des Benutzers, nur eine gültige Signatur zu erstellen Signatur unter seinem privaten Schlüssel. Wir haben die Rückverfolgbarkeitseigenschaft abgeschwächt und die Verknüpfbarkeit beibehalten Nur um die Einmaligkeit zu gewährleisten: Der öffentliche Schlüssel kann in vielen ausländischen Verifizierungssätzen erscheinen und die Der private Schlüssel kann zum Generieren einer eindeutigen anonymen Signatur verwendet werden. Im Falle einer doppelten Ausgabe Beim ersten Versuch werden diese beiden Signaturen miteinander verknüpft, eine Offenlegung des Unterzeichners ist jedoch nicht erforderlich für unsere Zwecke. 4.2 Definitionen 4.2.1 Parameter der elliptischen Kurve Als unseren Basissignaturalgorithmus wählen wire, um das schnelle Schema EdDSA zu verwenden, das entwickelt wurde und umgesetzt von D.J. Bernstein et al. [18]. Wie ECDSA von Bitcoin basiert es auf der elliptischen Kurve Da es sich hierbei um ein diskretes Logarithmusproblem handelt, könnte unser Schema in Zukunft auch auf Bitcoin angewendet werden. Gemeinsame Parameter sind: q: eine Primzahl; q = 2255 −19; d: ein Element von Fq; d = −121665/121666; E: eine elliptische Kurvengleichung; −x2 + y2 = 1 + dx2y2; G: ein Basispunkt; G = (x, −4/5); l: eine Primzahlordnung des Basispunkts; l = 2252 + 27742317777372353535851937790883648493; \(H_s\): eine kryptografische hash-Funktion \(\{0, 1\}^* \to \mathbb{F}_q\); \(H_p\): eine deterministische hash Funktion \(E(\mathbb{F}_q) \to E(\mathbb{F}_q)\). 4.2.2 Terminologie Für eine verbesserte Privatsphäre ist eine neue Terminologie erforderlich, die nicht mit Bitcoin-Entitäten verwechselt werden sollte. Der private ec-Schlüssel ist ein standardmäßiger privater Schlüssel mit elliptischer Kurve: eine Zahl \(a \in [1, l - 1]\); Der öffentliche ec-Schlüssel ist ein standardmäßiger öffentlicher Schlüssel mit elliptischer Kurve: ein Punkt A = aG; Ein einmaliges Schlüsselpaar ist ein Paar privater und öffentlicher EC-Schlüssel. 5 9 Meine Güte, der Autor dieses Whitepapers hätte das sicher besser formulieren können! Nehmen wir an, dass ein Das von Mitarbeitern geführte Unternehmen möchte darüber abstimmen, ob bestimmte neue Unternehmen erworben werden sollen oder nicht Vermögenswerte, und Alex und Brenda sind beide Angestellte. Das Unternehmen stellt jedem Mitarbeiter a Nachricht wie „Ich stimme für Vorschlag A mit Ja!“ welches die Metainformation „issue“ hat [PROP A] und bittet sie, es mit einer nachvollziehbaren Ringsignatur zu unterzeichnen, wenn sie den Vorschlag unterstützen. Mithilfe einer herkömmlichen Ringsignatur kann ein unehrlicher Mitarbeiter die Nachricht mehrmals unterschreiben. vermutlich mit verschiedenen nonces, um so oft abzustimmen, wie sie möchten. Auf der anderen Seite Andererseits wird Alex in einem nachverfolgbaren Ringsignaturschema abstimmen und ihren privaten Schlüssel haben zu dem Thema verwendet wurde [PROP A]. Wenn Alex versucht, eine Nachricht wie „Ich, Brenda, stimme zu Vorschlag A!" Um Brenda zu „verleumden“ und doppelt abzustimmen, wird diese neue Nachricht auch das Problem haben [Stütze A]. Da Alex‘ privater Schlüssel das [PROP A]-Problem bereits gelöst hat, ist Alex‘ Identität nicht mehr bekannt wird sofort als Betrug entlarvt. Was, ehrlich gesagt, ziemlich cool ist! Die Kryptographie erzwang die Wahlgleichheit. http://link.springer.com/chapter/10.1007/978-3-540-71677-8_13 Dieses Papier ist interessant und erstellt im Wesentlichen eine Ad-hoc-Ringsignatur, jedoch ohne jegliches Zustimmung des anderen Teilnehmers. Der Aufbau der Signatur kann unterschiedlich sein; Ich habe nicht gegraben tief, und ich habe nicht gesehen, ob es sicher ist. https://people.csail.mit.edu/rivest/AdidaHohenbergerRivest-AdHocGroupSignaturesFromHijackedKeypai Ad-hoc-Gruppensignaturen sind: Ringsignaturen, bei denen es sich um Gruppensignaturen ohne Gruppe handelt Manager, keine Zentralisierung, aber ein Mitglied einer Ad-hoc-Gruppe kann dies nachweislich behaupten es hat die anonyme Unterschrift (nicht) im Namen der Gruppe ausgestellt. http://link.springer.com/chapter/10.1007/11908739_9 Das ist nach meinem Verständnis nicht ganz richtig. Und mein Verständnis wird sich wahrscheinlich ändern Ich vertiefe mich in dieses Projekt. Aber nach meinem Verständnis sieht die Hierarchie so aus. Gruppensignaturen: Gruppenmanager kontrollieren die Rückverfolgbarkeit und die Möglichkeit, Mitglieder hinzuzufügen oder zu entfernen davon, Unterzeichner zu sein. Ringzeichen: Willkürliche Gruppenbildung ohne Gruppenleiter. Kein Widerruf der Anonymität. Es gibt keine Möglichkeit, sich von einer bestimmten Signatur zu distanzieren. Mit rückverfolgbarem und verbindbarem Ring Signaturen ist die Anonymität einigermaßen skalierbar. Ad-hoc-Gruppensignaturen: wie Ringsignaturen, aber Mitglieder können nachweisen, dass sie sie nicht erstellt haben eine bestimmte Signatur. Dies ist wichtig, wenn jeder in einer Gruppe eine Unterschrift leisten kann. http://link.springer.com/chapter/10.1007/978-3-540-71677-8_13 Der Algorithmus von Fujisaki und Suzuki wird später vom Autor optimiert, um Einmaligkeit zu gewährleisten. Also Wir werden vielmehr den Algorithmus von Fujisaki und Suzuki gleichzeitig mit dem neuen Algorithmus analysieren als es hier durchzugehen.

Schlüssel, sondern die Schlüssel aller Benutzer seiner Gruppe. Ein Prüfer ist überzeugt, dass der wahre Unterzeichner ein ist Mitglied der Gruppe, kann den Unterzeichner jedoch nicht ausschließlich identifizieren. Das ursprüngliche Protokoll erforderte einen vertrauenswürdigen Dritten (den sogenannten Group Manager), und das war er auch der Einzige, der den Unterzeichner ausfindig machen konnte. Die nächste Version namens Ringsignatur wurde eingeführt von Rivest et al. in [34], war ein autonomes Schema ohne Gruppenmanager und Anonymität Widerruf. Später erschienen verschiedene Modifikationen dieses Schemas: verknüpfbare Ringsignatur [26, 27, 17] erlaubte nachvollziehbar festzustellen, ob zwei Unterschriften von demselben Gruppenmitglied stammten Die Ringsignatur [24, 23] schränkte die übermäßige Anonymität ein, indem sie die Möglichkeit bot, den Unterzeichner zu ermitteln zwei Nachrichten in Bezug auf dieselbe Metainformation (oder „Tag“ im Sinne von [24]). Eine ähnliche kryptografische Konstruktion wird auch als Ad-hoc-Gruppensignatur bezeichnet [16, 38]. Es betont die willkürliche Gruppenbildung, während Gruppen-/Ringsignaturschemata eher a implizieren fester Satz von Mitgliedern. Unsere Lösung basiert größtenteils auf der Arbeit „Traceable ring signatur“ von E. Fujisaki und K. Suzuki [24]. Um den ursprünglichen Algorithmus und unsere Modifikation zu unterscheiden, werden wir Folgendes tun Letzteres wird als einmalige Ringsignatur bezeichnet und betont die Fähigkeit des Benutzers, nur eine gültige Signatur zu erstellen Signatur unter seinem privaten Schlüssel. Wir haben die Rückverfolgbarkeitseigenschaft abgeschwächt und die Verknüpfbarkeit beibehalten Nur um die Einmaligkeit zu gewährleisten: Der öffentliche Schlüssel kann in vielen ausländischen Verifizierungssätzen erscheinen und die Der private Schlüssel kann zum Generieren einer eindeutigen anonymen Signatur verwendet werden. Im Falle einer doppelten Ausgabe Beim ersten Versuch werden diese beiden Signaturen miteinander verknüpft, eine Offenlegung des Unterzeichners ist jedoch nicht erforderlich für unsere Zwecke. 4.2 Definitionen 4.2.1 Parameter der elliptischen Kurve Als Basis-Signaturalgorithmus haben wir uns für das schnelle Schema EdDSA entschieden, das entwickelt und entwickelt wurde umgesetzt von D.J. Bernstein et al. [18]. Wie ECDSA von Bitcoin basiert es auf der elliptischen Kurve Da es sich hierbei um ein diskretes Logarithmusproblem handelt, könnte unser Schema in Zukunft auch auf Bitcoin angewendet werden. Gemeinsame Parameter sind: q: eine Primzahl; q = 2255 −19; d: ein Element von Fq; d = −121665/121666; E: eine elliptische Kurvengleichung; −x2 + y2 = 1 + dx2y2; G: ein Basispunkt; G = (x, −4/5); l: eine Primzahlordnung des Basispunkts; l = 2252 + 27742317777372353535851937790883648493; \(H_s\): eine kryptografische hash-Funktion \(\{0, 1\}^* \to \mathbb{F}_q\); \(H_p\): eine deterministische hash Funktion \(E(\mathbb{F}_q) \to E(\mathbb{F}_q)\). 4.2.2 Terminologie Für eine verbesserte Privatsphäre ist eine neue Terminologie erforderlich, die nicht mit Bitcoin-Entitäten verwechselt werden sollte. Der private ec-Schlüssel ist ein standardmäßiger privater Schlüssel mit elliptischer Kurve: eine Zahl \(a \in [1, l - 1]\); Der öffentliche ec-Schlüssel ist ein standardmäßiger öffentlicher Schlüssel mit elliptischer Kurve: ein Punkt A = aG; Ein einmaliges Schlüsselpaar ist ein Paar privater und öffentlicher EC-Schlüssel. 5 Schlüssel, sondern die Schlüssel aller Benutzer seiner Gruppe. Ein Prüfer ist überzeugt, dass der wahre Unterzeichner ein ist Mitglied der Gruppe, kann den Unterzeichner jedoch nicht ausschließlich identifizieren. Das ursprüngliche Protokoll erforderte einen vertrauenswürdigen Dritten (den sogenannten Group Manager), und das war er auch der Einzige, der den Unterzeichner ausfindig machen konnte. Die nächste Version namens Ringsignatur wurde eingeführt von Rivest et al. in [34], war ein autonomes Schema ohne Gruppenmanager und Anonymität Widerruf. Später erschienen verschiedene Modifikationen dieses Schemas: verknüpfbare Ringsignatur [26, 27, 17] erlaubte nachvollziehbar festzustellen, ob zwei Unterschriften von demselben Gruppenmitglied stammten Die Ringsignatur [24, 23] schränkte die übermäßige Anonymität ein, indem sie die Möglichkeit bot, den Unterzeichner zu ermitteln zwei Nachrichten in Bezug auf dieselbe Metainformation (oder „Tag“ im Sinne von [24]). Eine ähnliche kryptografische Konstruktion wird auch als Ad-hoc-Gruppensignatur bezeichnet [16, 38]. Es betont die willkürliche Gruppenbildung, während Gruppen-/Ringsignaturschemata eher a implizieren fester Satz von Mitgliedern. Unsere Lösung basiert größtenteils auf der Arbeit „Traceable ring signatur“ von E. Fujisaki und K. Suzuki [24]. Um den ursprünglichen Algorithmus und unsere Modifikation zu unterscheiden, werden wir Folgendes tun Letzteres wird als einmalige Ringsignatur bezeichnet und betont die Fähigkeit des Benutzers, nur eine gültige Signatur zu erstellen Signatur unter seinem privaten Schlüssel. Wir haben die Rückverfolgbarkeitseigenschaft abgeschwächt und die Verknüpfbarkeit beibehalten Nur um die Einmaligkeit zu gewährleisten: Der öffentliche Schlüssel kann in vielen ausländischen Verifizierungssätzen erscheinen und die Der private Schlüssel kann zum Generieren einer eindeutigen anonymen Signatur verwendet werden. Im Falle einer doppelten Ausgabe Beim ersten Versuch werden diese beiden Signaturen miteinander verknüpft, eine Offenlegung des Unterzeichners ist jedoch nicht erforderlich für unsere Zwecke. 4.2 Definitionen 4.2.1 Parameter der elliptischen Kurve Als unseren Basissignaturalgorithmus wählen wire, um das schnelle Schema EdDSA zu verwenden, das entwickelt wurde und umgesetzt von D.J. Bernstein et al. [18]. Wie ECDSA von Bitcoin basiert es auf der elliptischen Kurve Da es sich hierbei um ein diskretes Logarithmusproblem handelt, könnte unser Schema in Zukunft auch auf Bitcoin angewendet werden. Gemeinsame Parameter sind: q: eine Primzahl; q = 2255 −19; d: ein Element von Fq; d = −121665/121666; E: eine elliptische Kurvengleichung; −x2 + y2 = 1 + dx2y2; G: ein Basispunkt; G = (x, −4/5); l: eine Primzahlordnung des Basispunkts; l = 2252 + 27742317777372353535851937790883648493; \(H_s\): eine kryptografische hash-Funktion \(\{0, 1\}^* \to \mathbb{F}_q\); \(H_p\): eine deterministische hash Funktion \(E(\mathbb{F}_q) \to E(\mathbb{F}_q)\). 4.2.2 Terminologie Für eine verbesserte Privatsphäre ist eine neue Terminologie erforderlich, die nicht mit Bitcoin-Entitäten verwechselt werden sollte. Der private ec-Schlüssel ist ein standardmäßiger privater Schlüssel mit elliptischer Kurve: eine Zahl \(a \in [1, l - 1]\); Der öffentliche ec-Schlüssel ist ein standardmäßiger öffentlicher Schlüssel mit elliptischer Kurve: ein Punkt A = aG; Ein einmaliges Schlüsselpaar ist ein Paar privater und öffentlicher EC-Schlüssel. 5 10 Verknüpfbarkeit im Sinne von „verknüpfbaren Ringsignaturen“ bedeutet, dass wir erkennen können, ob zwei ausgehende Transaktionen von derselben Quelle stammen, ohne preiszugeben, wer die Quelle ist. Die Autoren wurden geschwächt Verknüpfbarkeit, um (a) die Privatsphäre zu wahren, aber dennoch (b) jede Transaktion mithilfe eines privaten Schlüssels zu erkennen ein zweites Mal als ungültig erklärt. Okay, das ist also eine Frage der Reihenfolge der Ereignisse. Betrachten Sie das folgende Szenario. Mein Bergbau Wenn der Computer über den aktuellen blockchain verfügt, verfügt er über einen eigenen Transaktionsblock, den er aufruft legitim, es wird an diesem Block in einem proof-of-work-Puzzle gearbeitet, und es wird eine haben Liste der ausstehenden Transaktionen, die dem nächsten Block hinzugefügt werden sollen. Es werden auch keine neuen verschickt Transaktionen in diesen Pool ausstehender Transaktionen. Wenn ich den nächsten Block nicht löse, aber Wenn jemand anderes dies tut, erhalte ich eine aktualisierte Kopie von blockchain. Der Block, an dem ich gearbeitet habe und Meine Liste der ausstehenden Transaktionen enthält möglicherweise einige Transaktionen, die jetzt integriert sind in den blockchain. Lösen Sie meinen ausstehenden Block auf, kombinieren Sie ihn mit meiner Liste ausstehender Transaktionen und rufen Sie ihn auf mein Pool an ausstehenden Transaktionen. Entfernen Sie alle, die sich jetzt offiziell im blockchain befinden. Was soll ich nun tun? Sollte ich zunächst alle Doppelausgaben entfernen? Auf der anderen Seite Andererseits sollte ich die Liste durchsuchen und sicherstellen, dass jeder private Schlüssel noch nicht vorhanden ist verwendet wurde, und wenn es bereits in meiner Liste verwendet wurde, dann habe ich das erste Exemplar zuerst erhalten, und daher jede weitere Kopie ist unzulässig. Deshalb lösche ich einfach alle Instanzen nach der ersten des gleichen privaten Schlüssels. Algebraische Geometrie war noch nie meine Stärke. http://en.wikipedia.org/wiki/EdDSA So eine Geschwindigkeit, wirklich wow. DAS ist algebraische Geometrie für den Sieg. Nicht, dass ich etwas wüsste darüber. Ob problematisch oder nicht, diskrete Protokolle werden sehr schnell. Und Quantencomputer fressen sie zum Frühstück. http://link.springer.com/article/10.1007/s13389-012-0027-1 Dies wird zu einer wirklich wichtigen Zahl, aber es gibt keine Erklärung oder Quelle dafür, wie es dazu kommt wurde gewählt. Es wäre in Ordnung, einfach eine einzelne bekannte große Primzahl zu wählen, aber wenn es solche gibt, dann ist das kein Problem Fakten über diese große Primzahl, die unsere Wahl beeinflussen könnten. Verschiedene Varianten von Kryptonote könnte verschiedene Werte von wählen Nun ja, aber in diesem Artikel wird nicht darüber diskutiert, wie das funktioniert Die Auswahl wirkt sich auf unsere Auswahl anderer globaler Parameter aus, die auf Seite 5 aufgeführt sind. Dieses Dokument benötigt einen Abschnitt zur Auswahl von Parameterwerten.

Der private Benutzerschlüssel ist ein Paar (a, b) aus zwei verschiedenen privaten EC-Schlüsseln. Der Tracking-Schlüssel ist ein Paar (a, B) aus privatem und öffentlichem EC-Schlüssel (wobei B = bG und a ̸= b); Der öffentliche Benutzerschlüssel ist ein Paar (A, B) aus zwei öffentlichen EC-Schlüsseln, die von (a, b) abgeleitet sind. Die Standardadresse ist eine Darstellung eines öffentlichen Benutzerschlüssels, der in einer benutzerfreundlichen Zeichenfolge angegeben wird mit Fehlerkorrektur; Die verkürzte Adresse ist eine Darstellung der zweiten Hälfte (Punkt B) eines angegebenen öffentlichen Benutzerschlüssels in eine benutzerfreundliche Zeichenfolge mit Fehlerkorrektur umgewandelt. Die Transaktionsstruktur ähnelt der Struktur in Bitcoin: Jeder Benutzer kann wählen mehrere unabhängige Zahlungseingänge (Transaktionsausgänge), signieren Sie diese mit den entsprechenden private Schlüssel und senden sie an verschiedene Ziele. Im Gegensatz zum Modell von Bitcoin, bei dem ein Benutzer über einen eindeutigen privaten und öffentlichen Schlüssel verfügt Bei dem vorgeschlagenen Modell generiert ein Absender einen einmaligen öffentlichen Schlüssel basierend auf der Adresse des Empfängers und einige zufällige Daten. In diesem Sinne wird eine eingehende Transaktion für denselben Empfänger an a gesendet Einmaliger öffentlicher Schlüssel (nicht direkt an eine eindeutige Adresse) und nur der Empfänger kann ihn wiederherstellen entsprechenden privaten Teil, um sein Geld einzulösen (unter Verwendung seines einzigartigen privaten Schlüssels). Der Empfänger kann Verwenden Sie eine Ringsignatur, um die Gelder auszugeben, wobei sein Eigentum und seine tatsächlichen Ausgaben anonym bleiben. Die Einzelheiten des Protokolls werden in den nächsten Unterabschnitten erläutert. 4.3 Nicht verknüpfbare Zahlungen Klassische Bitcoin-Adressen werden nach der Veröffentlichung zu einer eindeutigen Kennung für eingehende E-Mails Zahlungen, deren Verknüpfung und Verknüpfung mit den Pseudonymen des Empfängers. Wenn jemand möchte Wenn er eine „ungebundene“ Transaktion erhält, sollte er dem Absender seine Adresse über einen privaten Kanal mitteilen. Wenn er verschiedene Transaktionen erhalten möchte, bei denen nicht nachgewiesen werden kann, dass sie demselben Eigentümer gehören Er sollte alle verschiedenen Adressen generieren und sie niemals unter seinem eigenen Pseudonym veröffentlichen. Öffentlich Privat Alice Carol Bobs Adresse 1 Bobs Adresse 2 Bobs Schlüssel 1 Bobs Schlüssel 2 Bob Abb. 2. Traditionelles Bitcoin-Schlüssel-/Transaktionsmodell. Wir schlagen eine Lösung vor, die es einem Benutzer ermöglicht, eine einzelne Adresse zu veröffentlichen und bedingungslos zu empfangen nicht verknüpfbare Zahlungen. Das Ziel jeder CryptoNote-Ausgabe ist (standardmäßig) ein öffentlicher Schlüssel. abgeleitet aus Empfängeradresse und Zufallsdaten des Absenders. Der Hauptvorteil gegenüber Bitcoin ist, dass jeder Zielschlüssel standardmäßig eindeutig ist (es sei denn, der Absender verwendet für jeden die gleichen Daten). seiner Transaktionen an denselben Empfänger). Daher gibt es kein Problem wie die „Wiederverwendung von Adressen“. Design und kein Beobachter kann feststellen, ob Transaktionen an eine bestimmte Adresse oder einen bestimmten Link gesendet wurden zwei Adressen zusammen. 6 Der private Benutzerschlüssel ist ein Paar (a, b) aus zwei verschiedenen privaten EC-Schlüsseln. Der Tracking-Schlüssel ist ein Paar (a, B) aus privatem und öffentlichem EC-Schlüssel (wobei B = bG und a ̸= b); Der öffentliche Benutzerschlüssel ist ein Paar (A, B) aus zwei öffentlichen EC-Schlüsseln, die von (a, b) abgeleitet sind. Die Standardadresse ist eine Darstellung eines öffentlichen Benutzerschlüssels, der in einer benutzerfreundlichen Zeichenfolge angegeben wird mit Fehlerkorrektur; Die verkürzte Adresse ist eine Darstellung der zweiten Hälfte (Punkt B) eines angegebenen öffentlichen Benutzerschlüssels in eine benutzerfreundliche Zeichenfolge mit Fehlerkorrektur umgewandelt. Die Transaktionsstruktur ähnelt der Struktur in Bitcoin: Jeder Benutzer kann wählen mehrere unabhängige Zahlungseingänge (Transaktionsausgänge), signieren Sie diese mit den entsprechenden private Schlüssel und senden sie an verschiedene Ziele. Im Gegensatz zum Modell von Bitcoin, bei dem ein Benutzer über einen eindeutigen privaten und öffentlichen Schlüssel verfügt Bei dem vorgeschlagenen Modell generiert ein Absender einen einmaligen öffentlichen Schlüssel basierend auf der Adresse des Empfängers und einige zufällige Daten. In diesem Sinne wird eine eingehende Transaktion für denselben Empfänger an a gesendet Einmaliger öffentlicher Schlüssel (nicht direkt an eine eindeutige Adresse) und nur der Empfänger kann ihn wiederherstellen entsprechenden privaten Teil, um sein Geld einzulösen (unter Verwendung seines einzigartigen privaten Schlüssels). Der Empfänger kann Verwenden Sie eine Ringsignatur, um die Gelder auszugeben, wobei sein Eigentum und seine tatsächlichen Ausgaben anonym bleiben. Die Einzelheiten des Protokolls werden in den nächsten Unterabschnitten erläutert. 4.3 Nicht verknüpfbare Zahlungen Klassische Bitcoin-Adressen werden nach der Veröffentlichung zu einer eindeutigen Kennung für eingehende E-Mails Zahlungen, deren Verknüpfung und Verknüpfung mit den Pseudonymen des Empfängers. Wenn jemand möchte Wenn er eine „ungebundene“ Transaktion erhält, sollte er dem Absender seine Adresse über einen privaten Kanal mitteilen. Wenn er verschiedene Transaktionen erhalten möchte, bei denen nicht nachgewiesen werden kann, dass sie demselben Eigentümer gehören Er sollte alle verschiedenen Adressen generieren und sie niemals unter seinem eigenen Pseudonym veröffentlichen. Öffentlich Privat Alice Carol Bobs Adresse 1 Bobs Adresse 2 Bobs Schlüssel 1 Bobs Schlüssel 2 Bob Abb. 2. Traditionelle Bitcoin-Schlüssel/Transaktionen-Model. Wir schlagen eine Lösung vor, die es einem Benutzer ermöglicht, eine einzelne Adresse zu veröffentlichen und bedingungslos zu empfangen nicht verknüpfbare Zahlungen. Das Ziel jeder CryptoNote-Ausgabe ist (standardmäßig) ein öffentlicher Schlüssel. abgeleitet aus Empfängeradresse und Zufallsdaten des Absenders. Der Hauptvorteil gegenüber Bitcoin ist, dass jeder Zielschlüssel standardmäßig eindeutig ist (es sei denn, der Absender verwendet für jeden die gleichen Daten). seiner Transaktionen an denselben Empfänger). Daher gibt es kein Problem wie die „Wiederverwendung von Adressen“. Design und kein Beobachter kann feststellen, ob Transaktionen an eine bestimmte Adresse oder einen bestimmten Link gesendet wurden zwei Adressen zusammen. 6 11 Das ist also wie Bitcoin, aber mit unbegrenzten, anonymen Postfächern, die nur vom Empfänger eingelöst werden können Generieren eines privaten Schlüssels, der so anonym ist wie eine Ringsignatur. Bitcoin funktioniert auf diese Weise. Wenn Alex 0,112 Bitcoin in ihrer Brieftasche hat, die sie gerade von Frank erhalten hat, hat sie wirklich eine unterschriebene Karte Nachricht „Ich, [FRANK], sende 0,112 Bitcoin an [alex] + H0 + N0“, wobei 1) Frank das unterschrieben hat Nachricht mit seinem privaten Schlüssel [FRANK], 2) Frank hat die Nachricht mit Alex‘ öffentlichem Schlüssel signiert Schlüssel, [Alex], 3) Frank hat eine Form der Geschichte des Bitcoin, H0, eingefügt und 4) Frank enthält ein zufälliges Datenbit namens nonce, N0. Wenn Alex dann 0,011 Bitcoin an Charlene senden möchte, nimmt sie Franks Nachricht entgegen und sie wird das auf H1 setzen und zwei Nachrichten signieren: eine für ihre Transaktion und eine für die Änderung. H1= „Ich, [FRANK], sende 0,112 Bitcoin an [alex] + H0 + N“ „Ich, [ALEX], sende 0,011 Bitcoin an [charlene] + H1 + N1“ „Ich, [ALEX], sende 0,101 Bitcoin als Änderung an [alex] + H1 + N2.“ wo Alex beide Nachrichten mit ihrem privaten Schlüssel [ALEX] signiert, die erste Nachricht mit dem von Charlene öffentlicher Schlüssel [charlene], die zweite Nachricht mit Alex‘ öffentlichem Schlüssel [alex] und einschließlich der Historien und einige zufällig generierte nonces N1 und N2 entsprechend. Cryptonote funktioniert so: Wenn Alex 0,112 Cryptonote in ihrer Brieftasche hat, die sie gerade von Frank erhalten hat, hat sie wirklich eine unterschriebene Münze Nachricht „Ich, [jemand in einer Ad-hoc-Gruppe], sende 0,112 Cryptonote an [eine einmalige Adresse] + H0 + N0.“ Alex entdeckte, dass es sich dabei um ihr Geld handelte, indem sie ihren privaten Schlüssel [ALEX] überprüfte [eine einmalige Adresse] für jede vorbeigehende Nachricht, und wenn sie diese ausgeben möchte, tut sie dies in auf folgende Weise. Sie wählt einen Empfänger des Geldes aus, vielleicht hat Charlene damit begonnen, für Drohnenangriffe zu stimmen Alex möchte stattdessen Geld an Brenda schicken. Also sucht Alex nach Brendas öffentlichem Schlüssel, [brenda], und verwendet ihren eigenen privaten Schlüssel, [ALEX], um eine einmalige Adresse [ALEX+brenda] zu generieren. Sie Dann wählt sie eine beliebige Sammlung C aus dem Netzwerk der Cryptonote-Benutzer aus und erstellt sie eine Ringsignatur dieser Ad-hoc-Gruppe. Wir legen unseren Verlauf wie in der vorherigen Nachricht fest, fügen hinzu nonces und wie gewohnt fortfahren? H1 = „Ich, [jemand in einer Ad-hoc-Gruppe], sende 0,112 Cryptonote an [eine einmalige Adresse] + H0 + N0.“ „Ich, [jemand in der Sammlung C], sende 0,011 Cryptonote an [one-time-address-made-fromALEX+brenda] + H1 + N1“ „Ich, [jemand in der Sammlung C], sende 0,101 Cryptonote als Änderung an [one-time-address-madefrom-ALEX+alex] + H1 + N2“ Jetzt scannen Alex und Brenda beide alle eingehenden Nachrichten nach eventuell vorhandenen Einmaladressen mit ihrem Schlüssel erstellt. Wenn sie welche finden, dann ist diese Nachricht ganz neu für sie Kryptonote! Und selbst dann wird die Transaktion immer noch den blockchain erreichen. Wenn die Münzen diese Adresse eingeben Es ist bekannt, dass sie von Kriminellen, politischen Mitwirkenden oder von Komitees und Konten gesendet werden bei strengen Budgets (z. B. Unterschlagung) oder wenn der neue Besitzer dieser Münzen jemals einen Fehler macht und sendet diese Münzen an eine gemeinsame Adresse mit Münzen, von denen bekannt ist, dass sie sie besitzen, die Anonymitätsvorrichtung ist in Bitcoin gestiegen.

Der private Benutzerschlüssel ist ein Paar (a, b) aus zwei verschiedenen privaten EC-Schlüsseln. Der Tracking-Schlüssel ist ein Paar (a, B) aus privatem und öffentlichem EC-Schlüssel (wobei B = bG und a ̸= b); Der öffentliche Benutzerschlüssel ist ein Paar (A, B) aus zwei öffentlichen EC-Schlüsseln, die von (a, b) abgeleitet sind. Die Standardadresse ist eine Darstellung eines öffentlichen Benutzerschlüssels, der in einer benutzerfreundlichen Zeichenfolge angegeben wird mit Fehlerkorrektur; Die verkürzte Adresse ist eine Darstellung der zweiten Hälfte (Punkt B) eines angegebenen öffentlichen Benutzerschlüssels in eine benutzerfreundliche Zeichenfolge mit Fehlerkorrektur umgewandelt. Die Transaktionsstruktur ähnelt der Struktur in Bitcoin: Jeder Benutzer kann wählen mehrere unabhängige Zahlungseingänge (Transaktionsausgänge), signieren Sie diese mit den entsprechenden private Schlüssel und senden sie an verschiedene Ziele. Im Gegensatz zum Modell von Bitcoin, bei dem ein Benutzer über einen eindeutigen privaten und öffentlichen Schlüssel verfügt Bei dem vorgeschlagenen Modell generiert ein Absender einen einmaligen öffentlichen Schlüssel basierend auf der Adresse des Empfängers und einige zufällige Daten. In diesem Sinne wird eine eingehende Transaktion für denselben Empfänger an a gesendet Einmaliger öffentlicher Schlüssel (nicht direkt an eine eindeutige Adresse) und nur der Empfänger kann ihn wiederherstellen entsprechenden privaten Teil, um sein Geld einzulösen (unter Verwendung seines einzigartigen privaten Schlüssels). Der Empfänger kann Verwenden Sie eine Ringsignatur, um die Gelder auszugeben, wobei sein Eigentum und seine tatsächlichen Ausgaben anonym bleiben. Die Einzelheiten des Protokolls werden in den nächsten Unterabschnitten erläutert. 4.3 Nicht verknüpfbare Zahlungen Klassische Bitcoin-Adressen werden nach der Veröffentlichung zu einer eindeutigen Kennung für eingehende E-Mails Zahlungen, deren Verknüpfung und Verknüpfung mit den Pseudonymen des Empfängers. Wenn jemand möchte Wenn er eine „ungebundene“ Transaktion erhält, sollte er dem Absender seine Adresse über einen privaten Kanal mitteilen. Wenn er verschiedene Transaktionen erhalten möchte, bei denen nicht nachgewiesen werden kann, dass sie demselben Eigentümer gehören Er sollte alle verschiedenen Adressen generieren und sie niemals unter seinem eigenen Pseudonym veröffentlichen. Öffentlich Privat Alice Carol Bobs Adresse 1 Bobs Adresse 2 Bobs Schlüssel 1 Bobs Schlüssel 2 Bob Abb. 2. Traditionelles Bitcoin-Schlüssel-/Transaktionsmodell. Wir schlagen eine Lösung vor, die es einem Benutzer ermöglicht, eine einzelne Adresse zu veröffentlichen und bedingungslos zu empfangen nicht verknüpfbare Zahlungen. Das Ziel jeder CryptoNote-Ausgabe ist (standardmäßig) ein öffentlicher Schlüssel. abgeleitet aus Empfängeradresse und Zufallsdaten des Absenders. Der Hauptvorteil gegenüber Bitcoin ist, dass jeder Zielschlüssel standardmäßig eindeutig ist (es sei denn, der Absender verwendet für jeden die gleichen Daten). seiner Transaktionen an denselben Empfänger). Daher gibt es kein Problem wie die „Wiederverwendung von Adressen“. Design und kein Beobachter kann feststellen, ob Transaktionen an eine bestimmte Adresse oder einen bestimmten Link gesendet wurden zwei Adressen zusammen. 6 Der private Benutzerschlüssel ist ein Paar (a, b) aus zwei verschiedenen privaten EC-Schlüsseln. Der Tracking-Schlüssel ist ein Paar (a, B) aus privatem und öffentlichem EC-Schlüssel (wobei B = bG und a ̸= b); Der öffentliche Benutzerschlüssel ist ein Paar (A, B) aus zwei öffentlichen EC-Schlüsseln, die von (a, b) abgeleitet sind. Die Standardadresse ist eine Darstellung eines öffentlichen Benutzerschlüssels, der in einer benutzerfreundlichen Zeichenfolge angegeben wird mit Fehlerkorrektur; Die verkürzte Adresse ist eine Darstellung der zweiten Hälfte (Punkt B) eines angegebenen öffentlichen Benutzerschlüssels in eine benutzerfreundliche Zeichenfolge mit Fehlerkorrektur umgewandelt. Die Transaktionsstruktur ähnelt der Struktur in Bitcoin: Jeder Benutzer kann wählen mehrere unabhängige Zahlungseingänge (Transaktionsausgänge), signieren Sie diese mit den entsprechenden private Schlüssel und senden sie an verschiedene Ziele. Im Gegensatz zum Modell von Bitcoin, bei dem ein Benutzer über einen eindeutigen privaten und öffentlichen Schlüssel verfügt Bei dem vorgeschlagenen Modell generiert ein Absender einen einmaligen öffentlichen Schlüssel basierend auf der Adresse des Empfängers und einige zufällige Daten. In diesem Sinne wird eine eingehende Transaktion für denselben Empfänger an a gesendet Einmaliger öffentlicher Schlüssel (nicht direkt an eine eindeutige Adresse) und nur der Empfänger kann ihn wiederherstellen entsprechenden privaten Teil, um sein Geld einzulösen (unter Verwendung seines einzigartigen privaten Schlüssels). Der Empfänger kann Verwenden Sie eine Ringsignatur, um die Gelder auszugeben, wobei sein Eigentum und seine tatsächlichen Ausgaben anonym bleiben. Die Einzelheiten des Protokolls werden in den nächsten Unterabschnitten erläutert. 4.3 Nicht verknüpfbare Zahlungen Klassische Bitcoin-Adressen werden nach der Veröffentlichung zu einer eindeutigen Kennung für eingehende E-Mails Zahlungen, deren Verknüpfung und Verknüpfung mit den Pseudonymen des Empfängers. Wenn jemand möchte Wenn er eine „ungebundene“ Transaktion erhält, sollte er dem Absender seine Adresse über einen privaten Kanal mitteilen. Wenn er verschiedene Transaktionen erhalten möchte, bei denen nicht nachgewiesen werden kann, dass sie demselben Eigentümer gehören Er sollte alle verschiedenen Adressen generieren und sie niemals unter seinem eigenen Pseudonym veröffentlichen. Öffentlich Privat Alice Carol Bobs Adresse 1 Bobs Adresse 2 Bobs Schlüssel 1 Bobs Schlüssel 2 Bob Abb. 2. Traditioneller Bitcoin-Schlüssel/Transaktionen-Model. Wir schlagen eine Lösung vor, die es einem Benutzer ermöglicht, eine einzelne Adresse zu veröffentlichen und bedingungslos zu empfangen nicht verknüpfbare Zahlungen. Das Ziel jeder CryptoNote-Ausgabe ist (standardmäßig) ein öffentlicher Schlüssel. abgeleitet aus Empfängeradresse und Zufallsdaten des Absenders. Der Hauptvorteil gegenüber Bitcoin ist, dass jeder Zielschlüssel standardmäßig eindeutig ist (es sei denn, der Absender verwendet für jeden die gleichen Daten). seiner Transaktionen an denselben Empfänger). Daher gibt es kein Problem wie die „Wiederverwendung von Adressen“. Design und kein Beobachter kann feststellen, ob Transaktionen an eine bestimmte Adresse oder einen bestimmten Link gesendet wurden zwei Adressen zusammen. 6 12 Anstatt also Münzen von einer Adresse (die eigentlich ein öffentlicher Schlüssel ist) an eine Adresse zu senden (ein weiterer öffentlicher Schlüssel) Mit ihren privaten Schlüsseln senden Benutzer Münzen aus einem einmaligen Postfach (der mit dem öffentlichen Schlüssel Ihres Freundes generiert wird) an ein einmaliges Postfach (ähnlich) mit Ihrem eigene private Schlüssel. In gewisser Weise sagen wir: „Okay, lasst alle die Finger vom Geld, während es in Umlauf ist.“ herumgetragen! Es reicht einfach zu wissen, dass unsere Schlüssel diese und jene Kiste öffnen können Wir wissen, wie viel Geld in der Box ist. Legen Sie niemals Ihre Fingerabdrücke auf das Postfach oder Um es tatsächlich zu nutzen, tauschen Sie einfach die mit Bargeld gefüllte Box selbst aus. Auf diese Weise wissen wir nicht, wer gesendet hat Was, aber der Inhalt dieser öffentlichen Adressen ist immer noch reibungslos, fungibel, teilbar und besitzen immer noch all die anderen schönen Eigenschaften von Geld, die wir uns wünschen, wie Bitcoin.“ Eine unendliche Menge an Postfächern. Sie veröffentlichen eine Adresse, ich habe einen privaten Schlüssel. Ich verwende meinen privaten Schlüssel und Ihre Adresse und einige zufällige Daten, um einen öffentlichen Schlüssel zu generieren. Der Algorithmus ist so konzipiert, dass, da Ihr Adresse zum Generieren des öffentlichen Schlüssels verwendet wurde, funktioniert nur IHR privater Schlüssel zum Entsperren Nachricht. Eine Beobachterin, Eve, sieht, wie Sie Ihre Adresse veröffentlichen, und sieht den öffentlichen Schlüssel, den ich bekannt gebe. Allerdings Sie weiß nicht, ob ich meinen öffentlichen Schlüssel basierend auf Ihrer Adresse oder ihrer oder der von Brenda bekannt gegeben habe oder Charlenes, oder wer auch immer. Sie vergleicht ihren privaten Schlüssel mit dem öffentlichen Schlüssel, den ich angekündigt habe und sieht, dass es nicht funktioniert; es ist nicht ihr Geld. Sie kennt den privaten Schlüssel von niemand anderem und Nur der Empfänger der Nachricht verfügt über den privaten Schlüssel, der die Nachricht entsperren kann. Also niemand Wenn man zuhört, kann man feststellen, wer das Geld erhalten hat, geschweige denn, das Geld annehmen.

Öffentlich Privat Alice Carol Einmalschlüssel Einmalschlüssel Einmalschlüssel Bob Bobs Schlüssel Bobs Adresse Abb. 3. CryptoNote-Schlüssel-/Transaktionsmodell. Zunächst führt der Absender einen Diﬃe-Hellman-Austausch durch, um ein gemeinsames Geheimnis aus seinen Daten zu erhalten die Hälfte der Adresse des Empfängers. Anschließend berechnet er mithilfe der gemeinsamen Daten einen einmaligen Zielschlüssel Geheimnis und die zweite Hälfte der Adresse. Vom Empfänger werden zwei verschiedene ec-Schlüssel benötigt Für diese beiden Schritte ist eine Standard-CryptoNote-Adresse also fast doppelt so groß wie eine Bitcoin-Wallet Adresse. Der Empfänger führt außerdem einen Diﬃe-Hellman-Austausch durch, um die entsprechenden Daten wiederherzustellen geheimer Schlüssel. Eine Standardtransaktionssequenz sieht wie folgt aus: 1. Alice möchte eine Zahlung an Bob senden, der seine Standardadresse veröffentlicht hat. Sie entpackt die Adresse und erhält Bobs öffentlichen Schlüssel (A, B). 2. Alice generiert ein zufälliges \(r \in [1, l - 1]\) und berechnet einen einmaligen öffentlichen Schlüssel \(P = H_s(rA)G +\) B. 3. Alice verwendet P als Zielschlüssel für die Ausgabe und packt auch den Wert R = rG (als Teil der Diﬃe-Hellman-Börse) irgendwo in die Transaktion einfließen. Beachten Sie, dass sie erstellen kann andere Ausgaben mit eindeutigen öffentlichen Schlüsseln: Die Schlüssel verschiedener Empfänger (Ai, Bi) implizieren unterschiedliche Pi sogar mit dem gleichen r. Transaktion Öffentlicher Tx-Schlüssel Tx-Ausgang Betrag Zielschlüssel R = rG P = Hs(rA)G + B Empfänger öffentlicher Schlüssel Zufallsdaten des Absenders r (A, B) Abb. 4. Standard-Transaktionsstruktur. 4. Alice sendet die Transaktion. 5. Bob überprüft jede durchlaufende Transaktion mit seinem privaten Schlüssel (a, b) und berechnet P ′ = Hs(aR)G + B. Wenn Alices Transaktion mit Bob als Empfänger darunter war, dann ist aR = arG = rA und P′ = P. 7 Öffentlich Privat Alice Carol Einmalschlüssel Einmalschlüssel Einmalschlüssel Bob Bobs Schlüssel Bobs Adresse Abb. 3. CryptoNote-Schlüssel-/Transaktionsmodell. Zunächst führt der Absender einen Diﬃe-Hellman-Austausch durch, um ein gemeinsames Geheimnis aus seinen Daten zu erhalten die Hälfte der Adresse des Empfängers. Anschließend berechnet er mithilfe der gemeinsamen Daten einen einmaligen Zielschlüssel Geheimnis und die zweite Hälfte der Adresse. Vom Empfänger werden zwei verschiedene ec-Schlüssel benötigt Für diese beiden Schritte ist eine Standard-CryptoNote-Adresse also fast doppelt so groß wie eine Bitcoin-Wallet Adresse. Der Empfänger führt außerdem einen Diﬃe-Hellman-Austausch durch, um die entsprechenden Daten wiederherzustellen geheimer Schlüssel. Eine Standardtransaktionssequenz sieht wie folgt aus: 1. Alice möchte eine Zahlung an Bob senden, der seine Standardadresse veröffentlicht hat. Sie entpackt die Adresse und erhält Bobs öffentlichen Schlüssel (A, B). 2. Alice generiert ein zufälliges \(r \in [1, l - 1]\) und berechnet einen einmaligen öffentlichen Schlüssel \(P = H_s(rA)G +\) B. 3. Alice verwendet P als Zielschlüssel für die Ausgabe und packt auch den Wert R = rG (als Teil der Diﬃe-Hellman-Börse) irgendwo in die Transaktion einfließen. Beachten Sie, dass sie erstellen kann andere Ausgaben mit eindeutigen öffentlichen Schlüsseln: Die Schlüssel verschiedener Empfänger (Ai, Bi) implizieren unterschiedliche Pi sogar mit dem gleichen r. Transaktion Öffentlicher Tx-Schlüssel Tx-Ausgang Betrag Zielschlüssel R = rG P = Hs(rA)G + B Empfänger öffentlicher Schlüssel Zufallsdaten des Absenders r (A, B) Abb. 4. Standard-Transaktionsstruktur. 4. Alice sendet die Transaktion. 5. Bob überprüft jede durchlaufende Transaktion mit seinem privaten Schlüssel (a, b) und berechnet P ′ = Hs(aR)G + B. Wenn Alices Transaktion mit Bob als Empfänger darunter war, dann ist aR = arG = rA und P′ = P. 7 13 Ich frage mich, wie mühsam es wäre, eine Wahl der Kryptographie zu implementieren Schema. Elliptisch oder anders. Wenn also in Zukunft ein Plan gebrochen wird, wechselt die Währung ohne Bedenken. Wahrscheinlich eine große Nervensäge. Okay, das ist genau das, was ich gerade in meinem vorherigen Kommentar erklärt habe. Der Diﬃe-Hellman-Typ Der Austausch ist ordentlich. Angenommen, Alex und Brenda haben jeweils eine Geheimnummer A und B und eine Nummer Es geht ihnen nicht darum, Geheimnisse zu bewahren, a und b. Sie möchten ein gemeinsames Geheimnis generieren, ohne dies zu tun Eva entdeckt es. Diﬃe und Hellman haben eine Möglichkeit gefunden, wie Alex und Brenda das teilen können öffentliche Nummern a und b, nicht jedoch die privaten Nummern A und B, und generieren ein gemeinsames Geheimnis, K. Unter Verwendung dieses gemeinsamen Geheimnisses, K, ohne dass Eva zuhört, um dasselbe zu generieren K, Alex und Brenda können K nun als geheimen Verschlüsselungsschlüssel verwenden und geheime Nachrichten zurückgeben und her. So KANN es funktionieren, obwohl es mit viel größeren Zahlen als 100 funktionieren sollte. Wir verwenden 100, da das Bearbeiten der ganzen Zahlen Modulo 100 gleichbedeutend mit „Alle wegwerfen“ ist sondern die letzten beiden Ziffern einer Zahl.“ Alex und Brenda wählen jeweils A, a, B und b. Sie halten A und B geheim. Alex teilt Brenda ihren Wert eines Modulo 100 mit (nur die letzten beiden Ziffern) und Brenda teilt es Alex mit ihr Wert von b Modulo 100. Jetzt kennt Eva (a,b) Modulo 100. Aber Alex kennt (a,b,A) also sie kann x=abA modulo 100 berechnen.Alex schneidet alles bis auf die letzte Ziffer ab, weil wir arbeiten unter den ganzen Zahlen Modulo 100 wieder. Ebenso kennt Brenda (a,b,B), sodass sie berechnen kann y=abB Modulo 100. Alex kann jetzt x veröffentlichen und Brenda kann y veröffentlichen. Aber jetzt kann Alex yA = abBA modulo 100 berechnen, und Brenda kann xB berechnen = abBA modulo 100. Sie kennen beide die gleiche Nummer! Aber alles, was Eva gehört hat, ist (a,b,abA,abB). Sie hat keine einfache Möglichkeit, abA*B zu berechnen. Dies ist nun die einfachste und unsicherste Art, über den Diﬃe-Hellman-Austausch nachzudenken. Es gibt sicherere Versionen. Die meisten Versionen funktionieren jedoch aufgrund der ganzzahligen und diskreten Faktorisierung Logarithmen sind schwierig, und beide Probleme können von Quantencomputern leicht gelöst werden. Ich werde prüfen, ob es quantenresistente Versionen gibt. http://en.wikipedia.org/wiki/Diﬃe%E2%80%93Hellman_key_exchange Der hier aufgeführten „Standard-TXN-Sequenz“ fehlen eine ganze Reihe von Schritten, wie z. B. SIGNATUREN. Sie werden hier einfach als selbstverständlich angesehen. Was wirklich schlimm ist, denn die Reihenfolge, in der wir Signieren, die in der signierten Nachricht enthaltenen Informationen und so weiter ... das alles ist extrem wichtig für das Protokoll. Bei der Umsetzung von „the Standard-Transaktionssequenz“ könnte die Sicherheit des gesamten Systems in Frage stellen. Darüber hinaus sind die später in der Arbeit vorgelegten Beweise möglicherweise nicht streng genug, wenn die Der Rahmen, in dem sie arbeiten, ist genauso locker definiert wie in diesem Abschnitt.

Öffentlich Privat Alice Carol Einmalschlüssel Einmalschlüssel Einmalschlüssel Bob Bobs Schlüssel Bobs Adresse Abb. 3. CryptoNote-Schlüssel-/Transaktionsmodell. Zunächst führt der Absender einen Diﬃe-Hellman-Austausch durch, um ein gemeinsames Geheimnis aus seinen Daten zu erhalten die Hälfte der Adresse des Empfängers. Anschließend berechnet er mithilfe der gemeinsamen Daten einen einmaligen Zielschlüssel Geheimnis und die zweite Hälfte der Adresse. Vom Empfänger werden zwei verschiedene ec-Schlüssel benötigt Für diese beiden Schritte ist eine Standard-CryptoNote-Adresse also fast doppelt so groß wie eine Bitcoin-Wallet Adresse. Der Empfänger führt außerdem einen Diﬃe-Hellman-Austausch durch, um die entsprechenden Daten wiederherzustellen geheimer Schlüssel. Eine Standardtransaktionssequenz sieht wie folgt aus: 1. Alice möchte eine Zahlung an Bob senden, der seine Standardadresse veröffentlicht hat. Sie entpackt die Adresse und erhält Bobs öffentlichen Schlüssel (A, B). 2. Alice generiert ein zufälliges \(r \in [1, l - 1]\) und berechnet einen einmaligen öffentlichen Schlüssel \(P = H_s(rA)G +\) B. 3. Alice verwendet P als Zielschlüssel für die Ausgabe und packt auch den Wert R = rG (als Teil der Diﬃe-Hellman-Börse) irgendwo in die Transaktion einfließen. Beachten Sie, dass sie erstellen kann andere Ausgaben mit eindeutigen öffentlichen Schlüsseln: Die Schlüssel verschiedener Empfänger (Ai, Bi) implizieren unterschiedliche Pi sogar mit dem gleichen r. Transaktion Öffentlicher Tx-Schlüssel Tx-Ausgang Betrag Zielschlüssel R = rG P = Hs(rA)G + B Empfänger öffentlicher Schlüssel Zufallsdaten des Absenders r (A, B) Abb. 4. Standard-Transaktionsstruktur. 4. Alice sendet die Transaktion. 5. Bob überprüft jede durchlaufende Transaktion mit seinem privaten Schlüssel (a, b) und berechnet P ′ = Hs(aR)G + B. Wenn Alices Transaktion mit Bob als Empfänger darunter war, dann ist aR = arG = rA und P′ = P. 7 Öffentlich Privat Alice Carol Einmalschlüssel Einmalschlüssel Einmalschlüssel Bob Bobs Schlüssel Bobs Adresse Abb. 3. CryptoNote-Schlüssel-/Transaktionsmodell. Zunächst führt der Absender einen Diﬃe-Hellman-Austausch durch, um ein gemeinsames Geheimnis aus seinen Daten zu erhalten die Hälfte der Adresse des Empfängers. Anschließend berechnet er mithilfe der gemeinsamen Daten einen einmaligen Zielschlüssel Geheimnis und die zweite Hälfte der Adresse. Vom Empfänger werden zwei verschiedene ec-Schlüssel benötigt Für diese beiden Schritte ist eine Standard-CryptoNote-Adresse also fast doppelt so groß wie eine Bitcoin-Wallet Adresse. Der Empfänger führt außerdem einen Diﬃe-Hellman-Austausch durch, um die entsprechenden Daten wiederherzustellen geheimer Schlüssel. Eine Standardtransaktionssequenz sieht wie folgt aus: 1. Alice möchte eine Zahlung an Bob senden, der seine Standardadresse veröffentlicht hat. Sie entpackt die Adresse und erhält Bobs öffentlichen Schlüssel (A, B). 2. Alice generiert ein zufälliges \(r \in [1, l - 1]\) und berechnet einen einmaligen öffentlichen Schlüssel \(P = H_s(rA)G +\) B. 3. Alice verwendet P als Zielschlüssel für die Ausgabe und packt auch den Wert R = rG (als Teil der Diﬃe-Hellman-Börse) irgendwo in die Transaktion einfließen. Beachten Sie, dass sie erstellen kann andere Ausgaben mit eindeutigen öffentlichen Schlüsseln: Die Schlüssel verschiedener Empfänger (Ai, Bi) implizieren unterschiedliche Pi sogar mit dem gleichen r. Transaktion Öffentlicher Tx-Schlüssel Tx-Ausgang Betrag Zielschlüssel R = rG P = Hs(rA)G + B Empfänger öffentlicher Schlüssel Zufallsdaten des Absenders r (A, B) Abb. 4. Standard-Transaktionsstruktur. 4. Alice sendet die Transaktion. 5. Bob überprüft jede durchlaufende Transaktion mit seinem privaten Schlüssel (a, b) und berechnet P ′ = Hs(aR)G + B. Wenn Alices Transaktion mit Bob als Empfänger darunter war, dann ist aR = arG = rA und P′ = P. 7 14 Beachten Sie, dass es den Autoren schlecht gelingt, ihre Terminologie durchgehend klar zu halten den Text, aber vor allem in diesem nächsten Teil. Die nächste Inkarnation dieses Papiers wird notwendigerweise sein viel strenger. Im Text bezeichnen sie P als ihren einmaligen öffentlichen Schlüssel. Im Diagramm bezeichnen sie R als ihren „öffentlichen Tx-Schlüssel“ und P als ihren „Zielschlüssel“. Wenn ich das umschreiben würde, würde ich es tun Legen Sie einige Begriffe ganz konkret dar, bevor Sie diese Abschnitte besprechen. Diese Elle ist riesig. Siehe Seite 5. Wer wählt ell? Das Diagramm zeigt, dass der öffentliche Transaktionsschlüssel R = rG ist, der zufällig und ausgewählt ist B. vom Absender, ist nicht Teil der Tx-Ausgabe. Dies liegt daran, dass es für mehrere gleich sein könnte Transaktionen an mehrere Personen und wird SPÄTER nicht für Ausgaben verwendet. Ein neues R wird generiert jedes Mal, wenn Sie eine neue CryptoNote-Transaktion übertragen möchten. Darüber hinaus wird nur R verwendet um zu prüfen, ob Sie der Empfänger der Transaktion sind. Es handelt sich nicht um Junk-Daten, aber für jeden ist es Junk-Daten ohne die mit (A,B) verbundenen privaten Schlüssel. Der Zielschlüssel hingegen, P = Hs(rA)G + B, ist Teil der Tx-Ausgabe. Jeder Beim Durchsuchen der Daten jeder laufenden Transaktion müssen sie ihr eigenes generiertes P* vergleichen dieses P, um zu sehen, ob ihnen diese vorübergehende Transaktion gehört. Jeder mit einer nicht ausgegebenen Transaktionsausgabe (UTXO) wird einen Haufen dieser Ps mit Beträgen herumliegen haben. Um zu verbringend, sie Unterschreiben Sie eine neue Nachricht, einschließlich P. Alice muss diese Transaktion mit einmaligen privaten Schlüsseln signieren, die mit den Zielschlüsseln der nicht ausgegebenen Transaktionsausgabe(n) verknüpft sind. Jeder Zielschlüssel im Besitz von Alice ist ausgestattet mit einem einmaligen privaten Schlüssel, der (vermutlich) auch Alice gehört. Jedes Mal, wenn Alice es will Schicken Sie mir oder Bob oder Brenda oder Charlie oder Charlene den Inhalt eines Zielschlüssels verwendet ihren privaten Schlüssel, um die Transaktion zu signieren. Nach Eingang der Transaktion erhalte ich ein neues Tx öffentlichen Schlüssel, einen neuen öffentlichen Zielschlüssel, und ich werde in der Lage sein, einen neuen einmaligen privaten Schlüssel x wiederherzustellen. Ich kombiniere meinen einmaligen privaten Schlüssel x mit dem öffentlichen Ziel der neuen Transaktion Mit den Schlüsseln senden wir eine neue Transaktion

Bob kann den entsprechenden einmaligen privaten Schlüssel wiederherstellen: x = Hs(aR) + b, also P = xG. Er kann diese Ausgabe jederzeit ausgeben, indem er eine Transaktion mit x unterzeichnet. Transaktion Öffentlicher Tx-Schlüssel Tx-Ausgang Betrag Zielschlüssel P ′ = Hs(aR)G + bG einmaliger öffentlicher Schlüssel x = Hs(aR) + b einmaliger privater Schlüssel Empfänger privater Schlüssel (a, b) R P′ ?= P Abb. 5. Eingangstransaktionsprüfung. Als Ergebnis erhält Bob eingehende Zahlungen, die mit einmaligen öffentlichen Schlüsseln verknüpft sind Für einen Zuschauer nicht verlinkbar. Einige zusätzliche Hinweise: • Wenn Bob seine Transaktionen „erkennt“ (siehe Schritt 5), nutzt er praktisch nur die Hälfte seiner private Informationen: (a, B). Dieses Paar, auch Tracking-Schlüssel genannt, kann übergeben werden an einen Dritten (Carol). Bob kann ihr die Bearbeitung neuer Transaktionen delegieren. Bob muss Carol nicht ausdrücklich vertrauen, da sie den einmaligen geheimen Schlüssel p nicht wiederherstellen kann ohne Bobs vollständigen privaten Schlüssel (a, b). Dieser Ansatz ist nützlich, wenn es Bob an Bandbreite mangelt oder Rechenleistung (Smartphones, Hardware-Wallets etc.). • Falls Alice nachweisen möchte, dass sie eine Transaktion an Bobs Adresse gesendet hat, kann sie dies entweder offenlegen r oder verwenden Sie ein Zero-Knowledge-Protokoll, um zu beweisen, dass sie r kennt (z. B. durch Unterschreiben). die Transaktion mit r). • Wenn Bob eine revisionssichere Adresse haben möchte, an der sich alle eingehenden Transaktionen befinden verknüpfbar ist, kann er entweder seinen Tracking-Key veröffentlichen oder eine gekürzte Adresse verwenden. Diese Adresse stellt nur einen öffentlichen EC-Schlüssel B dar, und der verbleibende Teil ist für das Protokoll erforderlich daraus wie folgt abgeleitet: a = Hs(B) und A = Hs(B)G. In beiden Fällen ist es jeder Mensch ist in der Lage, alle eingehenden Transaktionen von Bob zu „erkennen“, aber natürlich kann niemand diese ausgeben darin eingeschlossene Gelder ohne geheimen Schlüssel b. 4.4 Einmalige Ringsignaturen Ein auf einmaligen Ringsignaturen basierendes Protokoll ermöglicht es Benutzern, eine bedingungslose Unverknüpfbarkeit zu erreichen. Leider ermöglichen gewöhnliche Arten von kryptografischen Signaturen die Rückverfolgung von Transaktionen jeweiligen Sender und Empfänger. Unsere Lösung für dieses Manko liegt in der Verwendung einer anderen Signatur als diejenigen, die derzeit in elektronischen Kassensystemen verwendet werden. Wir werden zunächst eine allgemeine Beschreibung unseres Algorithmus ohne expliziten Verweis darauf geben elektronisches Bargeld. Eine einmalige Ringsignatur enthält vier Algorithmen: (GEN, SIG, VER, LNK): GEN: nimmt öffentliche Parameter und gibt ein EC-Paar (P, x) und einen öffentlichen Schlüssel I aus. SIG: Nimmt eine Nachricht m, eine Menge \(S'\) öffentlicher Schlüssel {Pi}i̸=s, ein Paar (Ps, xs) und gibt eine Signatur \(\sigma\) aus und eine Menge \(S = \)S'\( \cup \{P_s\}\). 8
Bob kann den entsprechenden einmaligen privaten Schlüssel wiederherstellen: x = Hs(aR) + b, also P = xG. Er kann diese Ausgabe jederzeit ausgeben, indem er eine Transaktion mit x unterzeichnet. Transaktion Öffentlicher Tx-Schlüssel Tx-Ausgang Betrag Zielschlüssel P ′ = Hs(aR)G + bG einmaliger öffentlicher Schlüssel x = Hs(aR) + b einmaliger privater Schlüssel Empfänger privater Schlüssel (a, b) R P′ ?= P Abb. 5. Eingangstransaktionsprüfung. Als Ergebnis erhält Bob eingehende Zahlungen, die mit einmaligen öffentlichen Schlüsseln verknüpft sind Für einen Zuschauer nicht verlinkbar. Einige zusätzliche Hinweise: • Wenn Bob seine Transaktionen „erkennt“ (siehe Schritt 5), nutzt er praktisch nur die Hälfte seiner private Informationen: (a, B). Dieses Paar, auch Tracking-Schlüssel genannt, kann übergeben werden an einen Dritten (Carol). Bob kann ihr die Bearbeitung neuer Transaktionen delegieren. Bob muss Carol nicht ausdrücklich vertrauen, da sie den einmaligen geheimen Schlüssel p nicht wiederherstellen kann ohne Bobs vollständigen privaten Schlüssel (a, b). Dieser Ansatz ist nützlich, wenn es Bob an Bandbreite mangelt oder Rechenleistung (Smartphones, Hardware-Wallets etc.). • Falls Alice nachweisen möchte, dass sie eine Transaktion an Bobs Adresse gesendet hat, kann sie dies entweder offenlegen r oder verwenden Sie ein Zero-Knowledge-Protokoll, um zu beweisen, dass sie r kennt (z. B. durch Unterschreiben). die Transaktion mit r). • Wenn Bob eine revisionssichere Adresse haben möchte, an der sich alle eingehenden Transaktionen befinden verknüpfbar ist, kann er entweder seinen Tracking-Key veröffentlichen oder eine gekürzte Adresse verwenden. Diese Adresse stellt nur einen öffentlichen EC-Schlüssel B dar, und der verbleibende Teil ist für das Protokoll erforderlich daraus wie folgt abgeleitet: a = Hs(B) und A = Hs(B)G. In beiden Fällen ist es jeder Mensch ist in der Lage, alle eingehenden Transaktionen von Bob zu „erkennen“, aber natürlich kann niemand diese ausgeben darin eingeschlossene Gelder ohne geheimen Schlüssel b. 4.4 Einmalige Ringsignaturen Ein auf einmaligen Ringsignaturen basierendes Protokoll ermöglicht es Benutzern, eine bedingungslose Unverknüpfbarkeit zu erreichen. Leider ermöglichen gewöhnliche Arten von kryptografischen Signaturen die Rückverfolgung von Transaktionen jeweiligen Sender und Empfänger. Unsere Lösung für dieses Manko liegt in der Verwendung einer anderen Signatur als diejenigen, die derzeit in elektronischen Kassensystemen verwendet werden. Wir werden zunächst ein Gen bereitstellenEine vollständige Beschreibung unseres Algorithmus ohne expliziten Verweis darauf elektronisches Bargeld. Eine einmalige Ringsignatur enthält vier Algorithmen: (GEN, SIG, VER, LNK): GEN: nimmt öffentliche Parameter und gibt ein EC-Paar (P, x) und einen öffentlichen Schlüssel I aus. SIG: Nimmt eine Nachricht m, eine Menge \(S'\) öffentlicher Schlüssel {Pi}i̸=s, ein Paar (Ps, xs) und gibt eine Signatur \(\sigma\) aus und eine Menge \(S = \)S'\( \cup \{P_s\}\). 8 15 Wie sieht hier eine nicht ausgegebene Transaktionsausgabe aus? Das Diagramm legt nahe, dass die Transaktionsausgabe nur aus zwei Datenpunkten besteht: Betrag und Zielschlüssel. Aber das ist nicht der Fall ausreichend, denn wenn ich versuche, diese „Ausgabe“ auszugeben, muss ich immer noch R=rG wissen. Denken Sie daran, dass r vom Absender ausgewählt wird und R a) verwendet wird, um eingehende Kryptonoten als Ihre zu erkennen besitzen und b) zur Generierung des einmaligen privaten Schlüssels verwendet werden, mit dem Sie Ihre Kryptonote „beanspruchen“. Der Teil daran, den ich nicht verstehe? Nehmen wir das theoretische „Okay, wir haben diese.“ Signaturen und Transaktionen, und wir geben sie hin und her“ in die Welt der Programmierung „Okay, welche Informationen konkret machen eine Person UTXO aus?“ Der beste Weg, diese Frage zu beantworten, besteht darin, in den Körper des völlig unkommentierten Codes einzutauchen. Gut gemacht, Bytecoin-Team. Zur Erinnerung: Verlinkbarkeit bedeutet „Hat die gleiche Person gesendet?“ und Unverknüpfbarkeit bedeutet „dasselbe getan.“ Person erhalten?". Ein System kann also verknüpfbar oder nicht verknüpfbar, nicht verknüpfbar oder nicht verknüpfbar sein. Ärgerlich, ich weiß. Wenn also Nic van Saberhagen hier sagt: „…eingehende Zahlungen [sind] mit Einmalzahlungen verbunden.“ öffentliche Schlüssel, die für einen Zuschauer nicht verknüpfbar sind“, schauen wir mal, was er meint. Stellen Sie sich zunächst eine Situation vor, in der Alice Bob zwei separate Transaktionen derselben sendet Adresse an die gleiche Adresse. Im Bitcoin-Universum hat Alice den Fehler bereits gemacht des Versands von der gleichen Adresse aus und daher hat die Transaktion unseren Wunsch nach einer Begrenzung verfehlt Verknüpfbarkeit. Da sie außerdem das Geld an dieselbe Adresse geschickt hat, hat sie unseren Wunsch verfehlt wegen Unverknüpfbarkeit. Diese Bitcoin-Transaktion war sowohl (vollständig) verknüpfbar als auch nicht nicht verknüpfbar. Nehmen wir andererseits im Kryptonoten-Universum an, dass Alice Bob eine Kryptonote schickt. unter Verwendung von Bobs öffentlicher Adresse. Sie wählt als ihren verschleierenden Satz öffentlicher Schlüssel alle bekannten öffentlichen Schlüssel Schlüssel im Großraum Washington DC. Alex generiert mit ihrem eigenen einen einmaligen öffentlichen Schlüssel Informationen und Bobs öffentliche Informationen. Sie schickt das Geld ab, und jeder Beobachter wird es tun Ich konnte nur herausfinden: „Jemand aus der Metropolregion Washington DC hat 2,3 Kryptonoten an geschickt.“ die einmalige öffentliche Adresse XYZ123.“ Wir haben hier eine probabilistische Kontrolle über die Verknüpfbarkeit, daher nennen wir dies „fast nicht verknüpfbar“. Wir sehen auch nur die einmaligen öffentlichen Schlüssel, an die Geld gesendet wird. Auch wenn wir den Empfänger vermuteten War Bob, wir haben seine privaten Schlüssel nicht und können daher nicht testen, ob eine Transaktion erfolgreich war gehört Bob, geschweige denn, dass er seinen einmaligen privaten Schlüssel generiert, um seine Kryptonote einzulösen. Also das hier ist in der Tat völlig „unverknüpfbar“. Das ist also der netteste Trick von allen. Wer möchte einem anderen MtGox wirklich vertrauen? Vielleicht sind wir es Es ist bequem, eine gewisse Menge an BTC auf Coinbase zu speichern, aber die ultimative Bitcoin-Sicherheit ist es eine physische Geldbörse. Was unbequem ist. In diesem Fall können Sie die Hälfte Ihres privaten Schlüssels vertrauensvoll weitergeben, ohne Ihren privaten Schlüssel zu gefährden eigene Fähigkeit, Geld auszugeben. Wenn Sie dies tun, erklären Sie lediglich jemandem, wie er die Unverknüpfbarkeit aufheben kann. Der andere Eigenschaften von CN, die wie eine Währung wirken, bleiben erhalten, wie z. B. der Schutz vor Doppelausgaben und was nicht.
Bob kann den entsprechenden einmaligen privaten Schlüssel wiederherstellen: x = Hs(aR) + b, also P = xG. Er kann diese Ausgabe jederzeit ausgeben, indem er eine Transaktion mit x unterzeichnet. Transaktion Öffentlicher Tx-Schlüssel Tx-Ausgang Betrag Zielschlüssel P ′ = Hs(aR)G + bG einmaliger öffentlicher Schlüssel x = Hs(aR) + b einmaliger privater Schlüssel Empfänger privater Schlüssel (a, b) R P′ ?= P Abb. 5. Eingangstransaktionsprüfung. Als Ergebnis erhält Bob eingehende Zahlungen, die mit einmaligen öffentlichen Schlüsseln verknüpft sind Für einen Zuschauer nicht verlinkbar. Einige zusätzliche Hinweise: • Wenn Bob seine Transaktionen „erkennt“ (siehe Schritt 5), nutzt er praktisch nur die Hälfte seiner private Informationen: (a, B). Dieses Paar, auch Tracking-Schlüssel genannt, kann übergeben werden an einen Dritten (Carol). Bob kann ihr die Bearbeitung neuer Transaktionen delegieren. Bob muss Carol nicht ausdrücklich vertrauen, da sie den einmaligen geheimen Schlüssel p nicht wiederherstellen kann ohne Bobs vollständigen privaten Schlüssel (a, b). Dieser Ansatz ist nützlich, wenn es Bob an Bandbreite mangelt oder Rechenleistung (Smartphones, Hardware-Wallets etc.). • Falls Alice nachweisen möchte, dass sie eine Transaktion an Bobs Adresse gesendet hat, kann sie dies entweder offenlegen r oder verwenden Sie ein Zero-Knowledge-Protokoll, um zu beweisen, dass sie r kennt (z. B. durch Unterschreiben). die Transaktion mit r). • Wenn Bob eine revisionssichere Adresse haben möchte, an der sich alle eingehenden Transaktionen befinden verknüpfbar ist, kann er entweder seinen Tracking-Key veröffentlichen oder eine gekürzte Adresse verwenden. Diese Adresse stellt nur einen öffentlichen EC-Schlüssel B dar, und der verbleibende Teil ist für das Protokoll erforderlich daraus wie folgt abgeleitet: a = Hs(B) und A = Hs(B)G. In beiden Fällen ist es jeder Mensch ist in der Lage, alle eingehenden Transaktionen von Bob zu „erkennen“, aber natürlich kann niemand diese ausgeben darin eingeschlossene Gelder ohne geheimen Schlüssel b. 4.4 Einmalige Ringsignaturen Ein auf einmaligen Ringsignaturen basierendes Protokoll ermöglicht es Benutzern, eine bedingungslose Unverknüpfbarkeit zu erreichen. Leider ermöglichen gewöhnliche Arten von kryptografischen Signaturen die Rückverfolgung von Transaktionen jeweiligen Sender und Empfänger. Unsere Lösung für dieses Manko liegt in der Verwendung einer anderen Signatur als diejenigen, die derzeit in elektronischen Kassensystemen verwendet werden. Wir werden zunächst eine allgemeine Beschreibung unseres Algorithmus ohne expliziten Verweis darauf geben elektronisches Bargeld. Eine einmalige Ringsignatur enthält vier Algorithmen: (GEN, SIG, VER, LNK): GEN: nimmt öffentliche Parameter und gibt ein EC-Paar (P, x) und einen öffentlichen Schlüssel I aus. SIG: Nimmt eine Nachricht m, eine Menge \(S'\) öffentlicher Schlüssel {Pi}i̸=s, ein Paar (Ps, xs) und gibt eine Signatur \(\sigma\) aus und eine Menge \(S = \)S'\( \cup \{P_s\}\). 8
Bob kann den entsprechenden einmaligen privaten Schlüssel wiederherstellen: x = Hs(aR) + b, also P = xG. Er kann diese Ausgabe jederzeit ausgeben, indem er eine Transaktion mit x unterzeichnet. Transaktion Öffentlicher Tx-Schlüssel Tx-Ausgang Betrag Zielschlüssel P ′ = Hs(aR)G + bG einmaliger öffentlicher Schlüssel x = Hs(aR) + b einmaliger privater Schlüssel Empfänger privater Schlüssel (a, b) R P′ ?= P Abb. 5. Eingangstransaktionsprüfung. Als Ergebnis erhält Bob eingehende Zahlungen, die mit einmaligen öffentlichen Schlüsseln verknüpft sind Für einen Zuschauer nicht verlinkbar. Einige zusätzliche Hinweise: • Wenn Bob seine Transaktionen „erkennt“ (siehe Schritt 5), nutzt er praktisch nur die Hälfte seiner private Informationen: (a, B). Dieses Paar, auch Tracking-Schlüssel genannt, kann übergeben werden an einen Dritten (Carol). Bob kann ihr die Bearbeitung neuer Transaktionen delegieren. Bob muss Carol nicht ausdrücklich vertrauen, da sie den einmaligen geheimen Schlüssel p nicht wiederherstellen kann ohne Bobs vollständigen privaten Schlüssel (a, b). Dieser Ansatz ist nützlich, wenn es Bob an Bandbreite mangelt oder Rechenleistung (Smartphones, Hardware-Wallets etc.). • Falls Alice nachweisen möchte, dass sie eine Transaktion an Bobs Adresse gesendet hat, kann sie dies entweder offenlegen r oder verwenden Sie ein Zero-Knowledge-Protokoll, um zu beweisen, dass sie r kennt (z. B. durch Unterschreiben). die Transaktion mit r). • Wenn Bob eine revisionssichere Adresse haben möchte, an der sich alle eingehenden Transaktionen befinden verknüpfbar ist, kann er entweder seinen Tracking-Key veröffentlichen oder eine gekürzte Adresse verwenden. Diese Adresse stellt nur einen öffentlichen EC-Schlüssel B dar, und der verbleibende Teil ist für das Protokoll erforderlich daraus wie folgt abgeleitet: a = Hs(B) und A = Hs(B)G. In beiden Fällen ist es jeder Mensch ist in der Lage, alle eingehenden Transaktionen von Bob zu „erkennen“, aber natürlich kann niemand diese ausgeben darin eingeschlossene Gelder ohne geheimen Schlüssel b. 4.4 Einmalige Ringsignaturen Ein auf einmaligen Ringsignaturen basierendes Protokoll ermöglicht es Benutzern, eine bedingungslose Unverknüpfbarkeit zu erreichen. Leider ermöglichen gewöhnliche Arten von kryptografischen Signaturen die Rückverfolgung von Transaktionen jeweiligen Sender und Empfänger. Unsere Lösung für dieses Manko liegt in der Verwendung einer anderen Signatur als diejenigen, die derzeit in elektronischen Kassensystemen verwendet werden. Wir werden zunächst ein Gen bereitstellenEine vollständige Beschreibung unseres Algorithmus ohne expliziten Verweis darauf elektronisches Bargeld. Eine einmalige Ringsignatur enthält vier Algorithmen: (GEN, SIG, VER, LNK): GEN: nimmt öffentliche Parameter und gibt ein EC-Paar (P, x) und einen öffentlichen Schlüssel I aus. SIG: Nimmt eine Nachricht m, eine Menge \(S'\) öffentlicher Schlüssel {Pi}i̸=s, ein Paar (Ps, xs) und gibt eine Signatur \(\sigma\) aus und eine Menge \(S = \)S'\( \cup \{P_s\}\). 8 16 Ja, jetzt haben wir a) eine Zahlungsadresse und b) eine Zahlungs-ID. Ein Kritiker könnte fragen: „Müssen wir das wirklich tun? Wenn ein Händler schließlich 112.00678952 erhält.“ Genau CN, und das war meine Bestellung, und ich habe einen Screenshot oder eine Quittung oder was auch immer, nicht wahr? wahnsinniges Maß an Präzision ausreichend?“ Die Antwort lautet: „Vielleicht, meistens im Alltag, persönliche Transaktionen.“ Die häufigere Situation (insbesondere in der digitalen Welt) ist jedoch folgende: Ein Händler verkauft eine Reihe von Objekten mit jeweils einem festen Preis. Angenommen, Objekt A hat 0,001 CN, Objekt B hat 0,01 CN und Objekt C ist 0,1 CN. Wenn der Händler nun eine Bestellung über 1,618 CN erhält, sind es viele, viele (viele!) Möglichkeiten, eine Bestellung für einen Kunden zu arrangieren. Und so ohne irgendeine Zahlungs-ID, Identifizierung der sogenannten „einzigartigen“ Bestellung eines Kunden mit den sogenannten „einzigartigen“ Kosten für ihn Ordnung wird unmöglich. Noch lustiger: Wenn alles in meinem Online-Shop genau 1,0 kostet CN, und ich bekomme 1000 Kunden pro Tag? Und Sie möchten nachweisen, dass Sie genau 3 Objekte gekauft haben vor zwei Wochen? Ohne Zahlungsausweis? Viel Glück, Kumpel. Lange Rede, kurzer Sinn: Wenn Bob eine Zahlungsadresse veröffentlicht, veröffentlicht er möglicherweise auch eine Zahlungs-ID ebenfalls (siehe z. B. Poloniex XMR-Einzahlungen). Das ist anders als beschrieben im Text hier, wobei Alice diejenige ist, die die Zahlungs-ID generiert. Für Bob muss es auch eine Möglichkeit geben, eine Zahlungs-ID zu generieren. (a,B) Denken Sie daran, dass der Tracking-Schlüssel (a,B) veröffentlicht werden kann; Verlust der Geheimhaltung des Wertes für „ein“ Testament Ihre Fähigkeit, Geld auszugeben, nicht verletzen oder zulassen, dass andere Sie bestehlen (ich denke... das hätte es getan). noch bewiesen werden muss), wird es den Leuten lediglich ermöglichen, alle eingehenden Transaktionen zu sehen. Eine verkürzte Adresse, wie in diesem Absatz beschrieben, übernimmt einfach den „privaten“ Teil des Schlüssels und generiert es aus dem „öffentlichen“ Teil. Durch das Offenlegen des Werts für „a“ wird die Nichtverknüpfbarkeit entfernt Der Rest der Transaktionen bleibt jedoch erhalten. Der Autor meint „nicht unlinkbar“, weil sich „unlinkable“ auf den Empfänger und „linkable“ bezieht bezieht sich auf den Absender. Es ist auch klar, dass der Autor nicht erkannte, dass es zwei verschiedene Aspekte der Verknüpfbarkeit gibt. Da die Transaktion schließlich ein gerichtetes Objekt in einem Diagramm ist, stellen sich zwei Fragen: „Gehen diese beiden Transaktionen an dieselbe Person?“ und „Kommen diese beiden Transaktionen?“ von derselben Person?“ Dabei handelt es sich um eine „No-going-back“-Richtlinie, der die Unlinkability-Eigenschaft von CryptoNote unterliegt bedingt. Das heißt, Bob kann festlegen, dass die Verknüpfung seiner eingehenden Transaktionen nicht aufgehoben werden kann Nutzung dieser Richtlinie. Dies ist eine Behauptung, die sie anhand des Random Oracle Model beweisen. Wir werden darauf zurückkommen; der Zufall Oracle hat Vor- und Nachteile.

VER: Nimmt eine Nachricht m, eine Menge S, eine Signatur \(\sigma\) und gibt „wahr“ oder „falsch“ aus. LNK: Nimmt eine Menge I = {Ii}, eine Signatur \(\sigma\) und gibt „linked“ oder „indep“ aus. Die Idee hinter dem Protokoll ist ziemlich einfach: Ein Benutzer erstellt eine Signatur, die sein kann wird durch einen Satz öffentlicher Schlüssel und nicht durch einen eindeutigen öffentlichen Schlüssel überprüft. Die Identität des Unterzeichners ist nicht von den anderen Benutzern zu unterscheiden, deren öffentliche Schlüssel im Set enthalten sind, bis der Eigentümer sie erstellt eine zweite Signatur mit demselben Schlüsselpaar. Private Schlüssel x0 \(\cdots\) xi \(\cdots\) xn Öffentliche Schlüssel P0 \(\cdots\) Pi \(\cdots\) Pn Klingeln Unterschrift Zeichen verifizieren Abb. 6. Anonymität der Ringsignatur. GEN: Der Unterzeichner wählt einen zufälligen geheimen Schlüssel \(x \in [1, l - 1]\) und berechnet den entsprechenden öffentlicher Schlüssel P = xG. Zusätzlich berechnet er einen weiteren öffentlichen Schlüssel I = xHp(P), den wir verwenden werden nennen wir es „Schlüsselbild“. SIG: Der Unterzeichner generiert eine einmalige Ringsignatur mit einem nicht interaktiven Zero-Knowledge Beweis mit den Techniken aus [21]. Er wählt eine zufällige Teilmenge \(S'\) von n aus den anderen Benutzern aus. öffentliche Schlüssel Pi, sein eigenes Schlüsselpaar (x, P) und Schlüsselbild I. Sei \(0 \leq s \leq n\) der geheime Index des Unterzeichners in S (so dass sein öffentlicher Schlüssel Ps ist). Er wählt ein zufälliges {qi | ich = 0 . . . n} und {wi | ich = 0 . . . n, i ̸= s} aus (1 . . . l) und wendet die an folgende Transformationen: Li = ( QiG, wenn i = s QiG + WiPi, wenn i ̸= s Ri = ( qiHp(Pi), wenn i = s qiHp(Pi) + wiI, wenn i ̸= s Der nächste Schritt besteht darin, die nicht interaktive Herausforderung zu meistern: c = Hs(m, L1, . . . , Ln, R1, . . . , Rn) Schließlich berechnet der Unterzeichner die Antwort: ci =    Wi, wenn i ̸= s c − nP i=0 ci mod l, wenn i = s ri = ( Qi, wenn i ̸= s qs −csx mod l, wenn i = s Die resultierende Signatur ist \(\sigma\) = (I, c1, . . . , cn, r1, . . . , rn). 9 VER: Nimmt eine Nachricht m, eine Menge S, eine Signatur \(\sigma\) und gibt „wahr“ oder „falsch“ aus. LNK: Nimmt eine Menge I = {Ii}, eine Signatur \(\sigma\) und gibt „linked“ oder „indep“ aus. Die Idee hinter dem Protokoll ist ziemlich einfach: Ein Benutzer erstellt eine Signatur, die sein kann wird durch einen Satz öffentlicher Schlüssel und nicht durch einen eindeutigen öffentlichen Schlüssel überprüft. Die Identität des Unterzeichners ist nicht von den anderen Benutzern zu unterscheiden, deren öffentliche Schlüssel im Set enthalten sind, bis der Eigentümer sie erstellt eine zweite Signatur mit demselben Schlüsselpaar. Private Schlüssel x0 \(\cdots\) xi \(\cdots\) xn Öffentliche Schlüssel P0 \(\cdots\) Pi \(\cdots\) Pn Klingeln Unterschrift Zeichen verifizieren Abb. 6. Anonymität der Ringsignatur. GEN: Der Unterzeichner wählt einen zufälligen geheimen Schlüssel \(x \in [1, l - 1]\) und berechnet den entsprechenden öffentlicher Schlüssel P = xG. Zusätzlich berechnet er einen weiteren öffentlichen Schlüssel I = xHp(P), den wir verwenden werden nennen wir es „Schlüsselbild“. SIG: Der Unterzeichner generiert eine einmalige Ringsignatur mit einem nicht interaktiven Zero-Knowledge Beweis mit den Techniken aus [21]. Er wählt eine zufällige Teilmenge \(S'\) von n aus den anderen Benutzern aus. öffentliche Schlüssel Pi, sein eigenes Schlüsselpaar (x, P) und Schlüsselbild I. Sei \(0 \leq s \leq n\) der geheime Index des Unterzeichners in S (so dass sein öffentlicher Schlüssel Ps ist). Er wählt ein zufälliges {qi | ich = 0 . . . n} und {wi | ich = 0 . . . n, i ̸= s} aus (1 . . . l) und wendet die an folgende Transformationen: Li = ( QiG, wenn i = s QiG + WiPi, wenn i ̸= s Ri = ( qiHp(Pi), wenn i = s qiHp(Pi) + wiI, wenn i ̸= s Der nächste Schritt besteht darin, die nicht interaktive Herausforderung zu meistern: c = Hs(m, L1, . . . , Ln, R1, . . . , Rn) Schließlich berechnet der Unterzeichner die Antwort: ci =    Wi, wenn i ̸= s c − nP i=0 ci mod l, wenn i = s ri = ( Qi, wenn i ̸= s qs −csx mod l, wenn i = s Die resultierende Signatur ist \(\sigma\) = (I, c1, . . . , cn, r1, . . . , rn). 9 17 Vielleicht ist das dumm, aber bei der Vereinigung von S und P_s ist Vorsicht geboten. Wenn Sie einfach das anhängen Letzten öffentlichen Schlüssel bis zum Ende, die Unverknüpfbarkeit ist unterbrochen, da jeder die laufenden Transaktionen überprüft Sie können einfach den letzten in jeder Transaktion aufgeführten öffentlichen Schlüssel überprüfen und loslegen. Das ist der öffentliche Schlüssel dem Absender zugeordnet. Nach der Vereinigung muss also ein Pseudozufallszahlengenerator vorhanden sein Wird verwendet, um die ausgewählten öffentlichen Schlüssel zu permutieren. „...bis der Besitzer eine zweite Signatur mit demselben Schlüsselpaar erstellt.“ Ich wünsche dem/den Autor(en?) würde das näher erläutern. Ich glaube, das bedeutet: „Stellen Sie sicher, dass Sie jedes Mal, wenn Sie einen Satz öffentlicher Schlüssel auswählen, diese verschleiern möchten.“ Du wählst ein völlig neues Set, bei dem kein Schlüssel gleich ist Ziemlich starke Bedingung für die Unverknüpfbarkeit. Vielleicht „wählen Sie ein neues zufälliges Set aus.“ alle möglichen Schlüssel“ mit der Annahme, dass, obwohl nichttriviale Schnittpunkte unvermeidlich sind passieren, sie werden nicht oft passieren. In jedem Fall muss ich mich eingehender mit dieser Aussage befassen. Dadurch wird die Ringsignatur generiert. Wissensfreie Beweise sind großartig: Ich fordere Sie auf, mir zu beweisen, dass Sie ein Geheimnis kennen ohne das Geheimnis preiszugeben. Angenommen, wir stehen am Eingang einer Donut-förmigen Höhle. und auf der Rückseite der Höhle (vom Eingang aus nicht zu sehen) befindet sich ein oNe-Weg-Tür, zu der du Behaupte, du hättest den Schlüssel. Wenn du in eine Richtung gehst, lässt es dich immer durch, aber wenn du in die gleiche Richtung gehst In die andere Richtung benötigen Sie einen Schlüssel. Aber du willst mir nicht einmal den Schlüssel zeigen, geschweige denn Zeig mir, dass es die Tür öffnet. Aber Sie wollen mir beweisen, dass Sie wissen, wie man das öffnet Tür. Im interaktiven Setting werfe ich eine Münze. Kopf ist links, Zahl ist rechts und Sie gehen nach unten Donut-förmige Höhle, wohin auch immer die Münze Sie weist. Hinten, außerhalb meiner Sichtweite, du Öffne die Tür, um auf die andere Seite zurückzukehren. Wir wiederholen das Münzwurfexperiment bis ich überzeugt bin, dass du den Schlüssel hast. Aber das ist eindeutig der INTERAKTIVE Zero-Knowledge-Beweis. Es gibt nicht-interaktive Versionen, in denen Sie und ich nie kommunizieren müssen; Auf diese Weise können keine Lauscher eingreifen. http://en.wikipedia.org/wiki/Zero-knowledge_proof Dies ist die Umkehrung der vorherigen Definition.

VER: Nimmt eine Nachricht m, eine Menge S, eine Signatur \(\sigma\) und gibt „wahr“ oder „falsch“ aus. LNK: Nimmt eine Menge I = {Ii}, eine Signatur \(\sigma\) und gibt „linked“ oder „indep“ aus. Die Idee hinter dem Protokoll ist ziemlich einfach: Ein Benutzer erstellt eine Signatur, die sein kann wird durch einen Satz öffentlicher Schlüssel und nicht durch einen eindeutigen öffentlichen Schlüssel überprüft. Die Identität des Unterzeichners ist nicht von den anderen Benutzern zu unterscheiden, deren öffentliche Schlüssel im Set enthalten sind, bis der Eigentümer sie erstellt eine zweite Signatur mit demselben Schlüsselpaar. Private Schlüssel x0 \(\cdots\) xi \(\cdots\) xn Öffentliche Schlüssel P0 \(\cdots\) Pi \(\cdots\) Pn Klingeln Unterschrift Zeichen verifizieren Abb. 6. Anonymität der Ringsignatur. GEN: Der Unterzeichner wählt einen zufälligen geheimen Schlüssel \(x \in [1, l - 1]\) und berechnet den entsprechenden öffentlicher Schlüssel P = xG. Zusätzlich berechnet er einen weiteren öffentlichen Schlüssel I = xHp(P), den wir verwenden werden nennen wir es „Schlüsselbild“. SIG: Der Unterzeichner generiert eine einmalige Ringsignatur mit einem nicht interaktiven Zero-Knowledge Beweis mit den Techniken aus [21]. Er wählt eine zufällige Teilmenge \(S'\) von n aus den anderen Benutzern aus. öffentliche Schlüssel Pi, sein eigenes Schlüsselpaar (x, P) und Schlüsselbild I. Sei \(0 \leq s \leq n\) der geheime Index des Unterzeichners in S (so dass sein öffentlicher Schlüssel Ps ist). Er wählt ein zufälliges {qi | ich = 0 . . . n} und {wi | ich = 0 . . . n, i ̸= s} aus (1 . . . l) und wendet die an folgende Transformationen: Li = ( QiG, wenn i = s QiG + WiPi, wenn i ̸= s Ri = ( qiHp(Pi), wenn i = s qiHp(Pi) + wiI, wenn i ̸= s Der nächste Schritt besteht darin, die nicht interaktive Herausforderung zu meistern: c = Hs(m, L1, . . . , Ln, R1, . . . , Rn) Schließlich berechnet der Unterzeichner die Antwort: ci =    Wi, wenn i ̸= s c − nP i=0 ci mod l, wenn i = s ri = ( Qi, wenn i ̸= s qs −csx mod l, wenn i = s Die resultierende Signatur ist \(\sigma\) = (I, c1, . . . , cn, r1, . . . , rn). 9 VER: Nimmt eine Nachricht m, eine Menge S, eine Signatur \(\sigma\) und gibt „wahr“ oder „falsch“ aus. LNK: Nimmt eine Menge I = {Ii}, eine Signatur \(\sigma\) und gibt „linked“ oder „indep“ aus. Die Idee hinter dem Protokoll ist ziemlich einfach: Ein Benutzer erstellt eine Signatur, die sein kann wird durch einen Satz öffentlicher Schlüssel und nicht durch einen eindeutigen öffentlichen Schlüssel überprüft. Die Identität des Unterzeichners ist nicht von den anderen Benutzern zu unterscheiden, deren öffentliche Schlüssel im Set enthalten sind, bis der Eigentümer sie erstellt eine zweite Signatur mit demselben Schlüsselpaar. Private Schlüssel x0 \(\cdots\) xi \(\cdots\) xn Öffentliche Schlüssel P0 \(\cdots\) Pi \(\cdots\) Pn Klingeln Unterschrift Zeichen verifizieren Abb. 6. Anonymität der Ringsignatur. GEN: Der Unterzeichner wählt einen zufälligen geheimen Schlüssel \(x \in [1, l - 1]\) und berechnet den entsprechenden öffentlicher Schlüssel P = xG. Zusätzlich berechnet er einen weiteren öffentlichen Schlüssel I = xHp(P), den wir verwenden werden nennen wir es „Schlüsselbild“. SIG: Der Unterzeichner generiert eine einmalige Ringsignatur mit einem nicht interaktiven Zero-Knowledge Beweis mit den Techniken aus [21]. Er wählt eine zufällige Teilmenge \(S'\) von n aus den anderen Benutzern aus. öffentliche Schlüssel Pi, sein eigenes Schlüsselpaar (x, P) und Schlüsselbild I. Sei \(0 \leq s \leq n\) der geheime Index des Unterzeichners in S (so dass sein öffentlicher Schlüssel Ps ist). Er wählt ein zufälliges {qi | ich = 0 . . . n} und {wi | ich = 0 . . . n, i ̸= s} aus (1 . . . l) und wendet die an folgende Transformationen: Li = ( QiG, wenn i = s QiG + WiPi, wenn i ̸= s Ri = ( qiHp(Pi), wenn i = s qiHp(Pi) + wiI, wenn i ̸= s Der nächste Schritt besteht darin, die nicht interaktive Herausforderung zu meistern: c = Hs(m, L1, . . . , Ln, R1, . . . , Rn) Schließlich berechnet der Unterzeichner die Antwort: ci =    Wi, wenn i ̸= s c − nP i=0 ci mod l, wenn i = s ri = ( Qi, wenn i ̸= s qs −csx mod l, wenn i = s Die resultierende Signatur ist \(\sigma\) = (I, c1, . . . , cn, r1, . . . , rn). 9 18 Dieser gesamte Bereich ist kryptonotenunabhängig und beschreibt lediglich den Ringsignaturalgorithmus ohne Verweis auf Währungen. Ich vermute, dass ein Teil der Notation mit dem Rest des Artikels übereinstimmt. allerdings. Beispielsweise ist x der in GEN gewählte „zufällige“ geheime Schlüssel, der den öffentlichen Schlüssel P ergibt und öffentliches Schlüsselbild I. Dieser Wert von x ist der Wert, den Bob in Teil 6, Seite 8, berechnet. Das ist also so Ich fange an, einige der Verwirrungen aus der vorherigen Beschreibung aufzuklären. Das ist irgendwie cool; Es wird kein Geld von Alices öffentlicher Adresse an Bobs öffentliche Adresse überwiesen Adresse.“ Es wird von Einmaladresse zu Einmaladresse übertragen. In gewisser Weise sehen wir also hier, wie das Zeug funktioniert. Wenn Alex ein paar Kryptonoten hat, weil jemand Wenn Sie sie ihr geschickt haben, bedeutet dies, dass sie über die privaten Schlüssel verfügt, die sie benötigt, um sie an Bob zu senden. Sie nutzt ein Diﬃe-Hellman-Austausch, der Bobs öffentliche Informationen nutzt, um eine neue einmalige Adresse zu generieren und die Kryptonoten werden an diese Adresse übertragen. Nun wurde ein (vermutlich sicherer) DH-Austausch verwendet, um die neue Einmaladresse zu generieren an den Alex ihre CN geschickt hat, ist Bob der Einzige mit den privaten Schlüsseln, die zum Wiederholen des Befehls erforderlich sind oben. Jetzt ist Bob also Alex. http://en.wikipedia.org/wiki/Piecewise#Notation_and_interpretation Die Summierung sollte über j und nicht über i indiziert werden. Jedes c_i ist zufälliger Müll (da w_i zufällig ist) bis auf den c_i Arschist mit dem eigentlichen Schlüssel verknüpft, der in dieser Signatur enthalten ist. Der Wert von c ist ein hash der vorherigen Informationen. Ich denke jedoch, dass dies einen Tippfehler enthält, der schlimmer ist als die Wiederverwendung des Index „i“, denn c_s scheint implizit und nicht explizit definiert werden. Wenn wir diese Gleichung tatsächlich glauben, dann stellen wir fest, dass c_s = (1/2)c - (1/2) sum_i neq s c_i. Das heißt, ein hash minus eine ganze Reihe von Zufallszahlen. Wenn diese Summation hingegen lauten soll: „c_s = (c – sum_j neq s c_j) mod l“, dann nehmen wir die hash unserer vorherigen Informationen und generieren eine Reihe von Zufallszahlen. Subtrahieren Sie alle diese Zufallszahlen von hash, und das ergibt c_s. Das scheint so zu sein was meiner Intuition nach passieren „sollte“ und entspricht dem Verifizierungsschritt auf Seite 10. Aber Intuition ist keine Mathematik. Ich werde näher darauf eingehen. Das Gleiche wie zuvor; All dies wird zufälliger Müll sein, mit Ausnahme desjenigen, der mit dem tatsächlichen verbunden ist Öffentlicher Schlüssel des Unterzeichners x. Allerdings ist dies dieses Mal eher das, was ich von der Struktur erwarten würde: r_i ist zufällig für i!=s und r_s wird nur durch das geheime x und die s-indizierten Werte von bestimmt q_i und c_i.

VER: Der Verifizierer prüft die Signatur, indem er die inversen Transformationen anwendet: ( L′ i = riG + ciPi R′ i = riHp(Pi) + ciI Abschließend prüft der Verifizierer, ob nP i=0 ci ?= Hs(m, L′ 0, . . . , L′ n, R′ 0, . . . , R′ n) mod l Wenn diese Gleichheit korrekt ist, führt der Verifizierer den Algorithmus LNK aus. Andernfalls lehnt der Prüfer ab die Unterschrift. LNK: Der Verifizierer prüft, ob I in früheren Signaturen verwendet wurde (diese Werte werden im gespeichert Satz I). Bei Mehrfachnutzungen handelt es sich um zwei Signaturen, die unter demselben geheimen Schlüssel erstellt wurden. Die Bedeutung des Protokolls: Durch die Anwendung von L-Transformationen beweist der Unterzeichner, dass er es weiß so x, dass mindestens ein Pi = xG. Um diesen Beweis nicht wiederholbar zu machen, führen wir das Schlüsselbild ein als I = xHp(P). Der Unterzeichner verwendet dieselben Koeffizienten (ri, ci), um fast dieselbe Aussage zu beweisen: er kennt solche x, dass mindestens ein \(H_p(P_i) = I \cdot x^{-1}\). Wenn die Abbildung \(x \to I\) eine Injektion ist: 1. Niemand kann den öffentlichen Schlüssel aus dem Schlüsselbild wiederherstellen und den Unterzeichner identifizieren; 2. Der Unterzeichner kann nicht zwei Signaturen mit unterschiedlichen Ien und demselben x erstellen. Eine vollständige Sicherheitsanalyse finden Sie in Anhang A. 4.5 Standard-CryptoNote-Transaktion Durch die Kombination beider Methoden (nicht verknüpfbare öffentliche Schlüssel und nicht nachvollziehbare Ringsignatur) erreicht Bob Neues Maß an Privatsphäre im Vergleich zum ursprünglichen Bitcoin-Schema. Es verlangt von ihm lediglich das Lagern einen privaten Schlüssel (a, b) und veröffentlichen (A, B), um mit dem Empfangen und Senden anonymer Transaktionen zu beginnen. Bei der Validierung jeder Transaktion führt Bob zusätzlich nur zwei elliptische Kurvenmultiplikationen und eine Addition pro Ausgabe durch, um zu prüfen, ob eine Transaktion ihm gehört. Für jeden Ausgabe Bob stellt ein einmaliges Schlüsselpaar (pi, Pi) wieder her und speichert es in seiner Brieftasche. Es können beliebige Eingaben erfolgen nachweislich nur dann denselben Eigentümer, wenn sie in einer einzigen Transaktion auftauchen. In Tatsächlich ist diese Beziehung aufgrund der einmaligen Ringsignatur viel schwieriger herzustellen. Mit einer Ringsignatur kann Bob jede Eingabe effektiv vor der einer anderen Person verbergen; alles möglich Es ist ebenso wahrscheinlich, dass Geld ausgegeben wird, selbst der Vorbesitzer (Alice) hat nicht mehr Informationen als jeder Beobachter. Bei der Unterzeichnung seiner Transaktion gibt Bob n Auslandsausgänge mit dem gleichen Betrag wie er an Ausgabe und mischt sie alle ohne Beteiligung anderer Benutzer. Bob selbst (sowie (jemand anderes) weiß nicht, ob eine dieser Zahlungen ausgegeben wurde: Es kann ein Output verwendet werden in Tausenden von Unterschriften als Unklarheitsfaktor und nie als Versteckziel. Das Doppelte Die Ausgabenprüfung erfolgt in der LNK-Phase bei der Prüfung anhand des Satzes verwendeter Schlüsselbilder. Bob kann den Grad der Mehrdeutigkeit selbst wählen: n = 1 bedeutet, dass die Wahrscheinlichkeit, die er hat Die ausgegebene Ausgabe beträgt 50 % Wahrscheinlichkeit, n = 99 ergibt 1 %. Die Größe der resultierenden Signatur nimmt zu linear wie O(n+1), daher kostet die verbesserte Anonymität Bob zusätzliche Transaktionsgebühren. Er kann es auch Setzen Sie n = 0 und sorgen Sie dafür, dass seine Ringsignatur nur aus einem Element besteht. Dies geschieht jedoch sofort entlarven ihn als Spender. 10 VER: Der Verifizierer prüft die Signatur, indem er die inversen Transformationen anwendet: ( L′ i = riG + ciPi R′ i = riHp(Pi) + ciI Abschließend prüft der Verifizierer, ob nP i=0 ci ?= Hs(m, L′ 0, . . . , L′ n, R′ 0, . . . , R′ n) mod l Wenn diese Gleichheit korrekt ist, führt der Verifizierer den Algorithmus LNK aus. Andernfalls lehnt der Prüfer ab die Unterschrift. LNK: Der Verifizierer prüft, ob I in früheren Signaturen verwendet wurde (diese Werte werden im gespeichert Satz I). Bei Mehrfachnutzungen handelt es sich um zwei Signaturen, die unter demselben geheimen Schlüssel erstellt wurden. Die Bedeutung des Protokolls: Durch die Anwendung von L-Transformationen beweist der Unterzeichner, dass er es weiß so x, dass mindestens ein Pi = xG. Um diesen Beweis nicht wiederholbar zu machen, führen wir das Schlüsselbild ein als I = xHp(P). Der Unterzeichner verwendet dieselben Koeffizienten (ri, ci), um fast dieselbe Aussage zu beweisen: er kennt solche x, dass mindestens ein \(H_p(P_i) = I \cdot x^{-1}\). Wenn die Abbildung \(x \to I\) eine Injektion ist: 1. Niemand kann den öffentlichen Schlüssel aus dem Schlüsselbild wiederherstellen und den Unterzeichner identifizieren. 2. Der Unterzeichner kann nicht zwei Signaturen mit unterschiedlichen Ien und demselben x erstellen. Eine vollständige Sicherheitsanalyse finden Sie in Anhang A. 4.5 Standard-CryptoNote-Transaktion Durch die Kombination beider Methoden (nicht verknüpfbare öffentliche Schlüssel und nicht nachvollziehbare Ringsignatur) erreicht Bob Neues Maß an Privatsphäre im Vergleich zum ursprünglichen Bitcoin-Schema. Es verlangt von ihm lediglich das Lagern einen privaten Schlüssel (a, b) und veröffentlichen (A, B), um mit dem Empfangen und Senden anonymer Transaktionen zu beginnen. Bei der Validierung jeder Transaktion führt Bob zusätzlich nur zwei elliptische Kurvenmultiplikationen und eine Addition pro Ausgabe durch, um zu prüfen, ob eine Transaktion ihm gehört. Für jeden Ausgabe Bob stellt ein einmaliges Schlüsselpaar (pi, Pi) und st wieder herEr steckt es in seine Brieftasche. Es können beliebige Eingaben erfolgen nachweislich nur dann denselben Eigentümer, wenn sie in einer einzigen Transaktion auftauchen. In Tatsächlich ist diese Beziehung aufgrund der einmaligen Ringsignatur viel schwieriger herzustellen. Mit einer Ringsignatur kann Bob jede Eingabe effektiv vor der einer anderen Person verbergen; alles möglich Es ist ebenso wahrscheinlich, dass Geld ausgegeben wird, selbst der Vorbesitzer (Alice) hat nicht mehr Informationen als jeder Beobachter. Bei der Unterzeichnung seiner Transaktion gibt Bob n Auslandsausgänge mit dem gleichen Betrag wie er an Ausgabe und mischt sie alle ohne Beteiligung anderer Benutzer. Bob selbst (sowie (jemand anderes) weiß nicht, ob eine dieser Zahlungen ausgegeben wurde: Es kann ein Output verwendet werden in Tausenden von Unterschriften als Unklarheitsfaktor und nie als Versteckziel. Das Doppelte Die Ausgabenprüfung erfolgt in der LNK-Phase bei der Prüfung anhand des Satzes verwendeter Schlüsselbilder. Bob kann den Grad der Mehrdeutigkeit selbst wählen: n = 1 bedeutet, dass die Wahrscheinlichkeit, die er hat Die ausgegebene Ausgabe beträgt 50 % Wahrscheinlichkeit, n = 99 ergibt 1 %. Die Größe der resultierenden Signatur nimmt zu linear wie O(n+1), daher kostet die verbesserte Anonymität Bob zusätzliche Transaktionsgebühren. Er kann es auch Setzen Sie n = 0 und sorgen Sie dafür, dass seine Ringsignatur nur aus einem Element besteht. Dies geschieht jedoch sofort entlarven ihn als Spender. 10 19 Zu diesem Zeitpunkt bin ich furchtbar verwirrt. Alex erhält eine Nachricht M mit Signatur (I,c_1, ..., c_n, r_1, ..., r_n) und Liste der öffentlichen Tasten S. und sie führt VER aus. Dadurch werden L_i‘ und R_i‘ berechnet. Dies bestätigt, dass c_s = c - sum_i neq s c_i auf der vorherigen Seite ist. Zuerst war ich SEHR (ha) verwirrt. Jeder kann L_i‘ und R_i‘ berechnen. In der Tat, jeder r_i und c_i wurden in der Signatur veröffentlicht Sigma zusammen mit dem Wert für I. Die Menge S = P_i aller öffentlichen Schlüssel wurde ebenfalls veröffentlicht. Also jeder, der Sigma und das Set gesehen hat Schlüssel S = P_i erhalten die gleichen Werte für L_i’ und R_i’ und überprüfen daher die Signatur. Aber dann fiel mir ein, dass es in diesem Abschnitt lediglich um die Beschreibung eines Signaturalgorithmus und nicht um eine „Prüfung“ geht Wenn es unterschrieben ist, prüfen Sie, ob es an mich gesendet wurde, und wenn ja, geben Sie das Geld aus. Das ist EINFACH das charakteristischer Teil des Spiels. Ich bin daran interessiert, Anhang A zu lesen, wenn ich endlich dort ankomme. Ich würde gerne einen vollständigen Operation-by-Operation-Vergleich von Cryptonote mit Bitcoin sehen. Auch Strom/Nachhaltigkeit. Welche Teile der Algorithmen stellen hier „Eingabe“ dar? Ich glaube, dass die Transaktionseingabe ein Betrag und eine Reihe von UTXOs ist, deren Summe einen größeren Betrag ergibt als der Betrag. Das ist unklar. „Ziel des Verstecks?“ Ich habe jetzt ein paar Minuten darüber nachgedacht und es ist mir immer noch nicht gelungen Die unklarste Vorstellung davon, was es bedeuten könnte. Ein Double-Spend-Angriff kann nur durch Manipulation des vermeintlichen verwendeten Schlüssels eines Knotens ausgeführt werden Bildersatz \(I\). „Mehrdeutigkeitsgrad“ = n, aber die Gesamtzahl der in der Transaktion enthaltenen öffentlichen Schlüssel beträgt n+1. Das heißt, der Grad der Unklarheit wäre: „Wie viele ANDERE Personen möchten Sie haben?“ die Menge?" Die Antwort wird wahrscheinlich standardmäßig „so viele wie möglich“ lauten.

VER: Der Verifizierer prüft die Signatur, indem er die inversen Transformationen anwendet: ( L′ i = riG + ciPi R′ i = riHp(Pi) + ciI Abschließend prüft der Verifizierer, ob nP i=0 ci ?= Hs(m, L′ 0, . . . , L′ n, R′ 0, . . . , R′ n) mod l Wenn diese Gleichheit korrekt ist, führt der Verifizierer den Algorithmus LNK aus. Andernfalls lehnt der Prüfer ab die Unterschrift. LNK: Der Verifizierer prüft, ob I in früheren Signaturen verwendet wurde (diese Werte werden im gespeichert Satz I). Bei Mehrfachnutzungen handelt es sich um zwei Signaturen, die unter demselben geheimen Schlüssel erstellt wurden. Die Bedeutung des Protokolls: Durch die Anwendung von L-Transformationen beweist der Unterzeichner, dass er es weiß so x, dass mindestens ein Pi = xG. Um diesen Beweis nicht wiederholbar zu machen, führen wir das Schlüsselbild ein als I = xHp(P). Der Unterzeichner verwendet dieselben Koeffizienten (ri, ci), um fast dieselbe Aussage zu beweisen: er kennt solche x, dass mindestens ein \(H_p(P_i) = I \cdot x^{-1}\). Wenn die Abbildung \(x \to I\) eine Injektion ist: 1. Niemand kann den öffentlichen Schlüssel aus dem Schlüsselbild wiederherstellen und den Unterzeichner identifizieren. 2. Der Unterzeichner kann nicht zwei Signaturen mit unterschiedlichen Ien und demselben x erstellen. Eine vollständige Sicherheitsanalyse finden Sie in Anhang A. 4.5 Standard-CryptoNote-Transaktion Durch die Kombination beider Methoden (nicht verknüpfbare öffentliche Schlüssel und nicht nachvollziehbare Ringsignatur) erreicht Bob Neues Maß an Privatsphäre im Vergleich zum ursprünglichen Bitcoin-Schema. Es verlangt von ihm lediglich das Lagern einen privaten Schlüssel (a, b) und veröffentlichen (A, B), um mit dem Empfangen und Senden anonymer Transaktionen zu beginnen. Bei der Validierung jeder Transaktion führt Bob zusätzlich nur zwei elliptische Kurvenmultiplikationen und eine Addition pro Ausgabe durch, um zu prüfen, ob eine Transaktion ihm gehört. Für jeden Ausgabe Bob stellt ein einmaliges Schlüsselpaar (pi, Pi) wieder her und speichert es in seiner Brieftasche. Es können beliebige Eingaben erfolgen nachweislich nur dann denselben Eigentümer, wenn sie in einer einzigen Transaktion auftauchen. In Tatsächlich ist diese Beziehung aufgrund der einmaligen Ringsignatur viel schwieriger herzustellen. Mit einer Ringsignatur kann Bob jede Eingabe effektiv vor der einer anderen Person verbergen; alles möglich Es ist ebenso wahrscheinlich, dass Geld ausgegeben wird, selbst der Vorbesitzer (Alice) hat nicht mehr Informationen als jeder Beobachter. Bei der Unterzeichnung seiner Transaktion gibt Bob n Auslandsausgänge mit dem gleichen Betrag wie er an Ausgabe und mischt sie alle ohne Beteiligung anderer Benutzer. Bob selbst (sowie (jemand anderes) weiß nicht, ob eine dieser Zahlungen ausgegeben wurde: Es kann ein Output verwendet werden in Tausenden von Unterschriften als Unklarheitsfaktor und nie als Versteckziel. Das Doppelte Die Ausgabenprüfung erfolgt in der LNK-Phase bei der Prüfung anhand des Satzes verwendeter Schlüsselbilder. Bob kann den Grad der Mehrdeutigkeit selbst wählen: n = 1 bedeutet, dass die Wahrscheinlichkeit, die er hat Die ausgegebene Ausgabe beträgt 50 % Wahrscheinlichkeit, n = 99 ergibt 1 %. Die Größe der resultierenden Signatur nimmt zu linear wie O(n+1), daher kostet die verbesserte Anonymität Bob zusätzliche Transaktionsgebühren. Er kann es auch Setzen Sie n = 0 und sorgen Sie dafür, dass seine Ringsignatur nur aus einem Element besteht. Dies geschieht jedoch sofort entlarven ihn als Spender. 10 VER: Der Verifizierer prüft die Signatur, indem er die inversen Transformationen anwendet: ( L′ i = riG + ciPi R′ i = riHp(Pi) + ciI Abschließend prüft der Verifizierer, ob nP i=0 ci ?= Hs(m, L′ 0, . . . , L′ n, R′ 0, . . . , R′ n) mod l Wenn diese Gleichheit korrekt ist, führt der Verifizierer den Algorithmus LNK aus. Andernfalls lehnt der Prüfer ab die Unterschrift. LNK: Der Verifizierer prüft, ob I in früheren Signaturen verwendet wurde (diese Werte werden im gespeichert Satz I). Bei Mehrfachnutzungen handelt es sich um zwei Signaturen, die unter demselben geheimen Schlüssel erstellt wurden. Die Bedeutung des Protokolls: Durch die Anwendung von L-Transformationen beweist der Unterzeichner, dass er es weiß so x, dass mindestens ein Pi = xG. Um diesen Beweis nicht wiederholbar zu machen, führen wir das Schlüsselbild ein als I = xHp(P). Der Unterzeichner verwendet dieselben Koeffizienten (ri, ci), um fast dieselbe Aussage zu beweisen: er kennt solche x, dass mindestens ein \(H_p(P_i) = I \cdot x^{-1}\). Wenn die Abbildung \(x \to I\) eine Injektion ist: 1. Niemand kann den öffentlichen Schlüssel aus dem Schlüsselbild wiederherstellen und den Unterzeichner identifizieren. 2. Der Unterzeichner kann nicht zwei Signaturen mit unterschiedlichen Ien und demselben x erstellen. Eine vollständige Sicherheitsanalyse finden Sie in Anhang A. 4.5 Standard-CryptoNote-Transaktion Durch die Kombination beider Methoden (nicht verknüpfbare öffentliche Schlüssel und nicht nachvollziehbare Ringsignatur) erreicht Bob Neues Maß an Privatsphäre im Vergleich zum ursprünglichen Bitcoin-Schema. Es verlangt von ihm lediglich das Lagern einen privaten Schlüssel (a, b) und veröffentlichen (A, B), um mit dem Empfangen und Senden anonymer Transaktionen zu beginnen. Bei der Validierung jeder Transaktion führt Bob zusätzlich nur zwei elliptische Kurvenmultiplikationen und eine Addition pro Ausgabe durch, um zu prüfen, ob eine Transaktion ihm gehört. Für jeden Ausgabe Bob stellt ein einmaliges Schlüsselpaar (pi, Pi) und st wieder herEr steckt es in seine Brieftasche. Es können beliebige Eingaben erfolgen nachweislich nur dann denselben Eigentümer, wenn sie in einer einzigen Transaktion auftauchen. In Tatsächlich ist diese Beziehung aufgrund der einmaligen Ringsignatur viel schwieriger herzustellen. Mit einer Ringsignatur kann Bob jede Eingabe effektiv vor der einer anderen Person verbergen; alles möglich Es ist ebenso wahrscheinlich, dass Geld ausgegeben wird, selbst der Vorbesitzer (Alice) hat nicht mehr Informationen als jeder Beobachter. Bei der Unterzeichnung seiner Transaktion gibt Bob n Auslandsausgänge mit dem gleichen Betrag wie er an Ausgabe und mischt sie alle ohne Beteiligung anderer Benutzer. Bob selbst (sowie (jemand anderes) weiß nicht, ob eine dieser Zahlungen ausgegeben wurde: Es kann ein Output verwendet werden in Tausenden von Unterschriften als Unklarheitsfaktor und nie als Versteckziel. Das Doppelte Die Ausgabenprüfung erfolgt in der LNK-Phase bei der Prüfung anhand des Satzes verwendeter Schlüsselbilder. Bob kann den Grad der Mehrdeutigkeit selbst wählen: n = 1 bedeutet, dass die Wahrscheinlichkeit, die er hat Die ausgegebene Ausgabe beträgt 50 % Wahrscheinlichkeit, n = 99 ergibt 1 %. Die Größe der resultierenden Signatur nimmt zu linear wie O(n+1), daher kostet die verbesserte Anonymität Bob zusätzliche Transaktionsgebühren. Er kann es auch Setzen Sie n = 0 und sorgen Sie dafür, dass seine Ringsignatur nur aus einem Element besteht. Dies geschieht jedoch sofort entlarven ihn als Spender. 10 20 Das ist interessant; Zuvor haben wir einem Empfänger, Bob, die Möglichkeit gegeben, alle EINGÄNGE zu tätigen Transaktionen können nicht aufgehoben werden, entweder durch deterministische Auswahl der Hälfte seiner privaten Schlüssel oder durch die Hälfte seiner privaten Schlüssel als öffentlich veröffentlichen. Dabei handelt es sich um eine Art No-Go-Back-Politik. Hier sehen wir Eine Möglichkeit eines Absenders, Alex, eine einzelne ausgehende Transaktion als verknüpfbar auszuwählen, aber tatsächlich diese verrät dem gesamten Netzwerk, dass Alex der Absender ist. Dabei handelt es sich NICHT um eine No-going-back-Politik. Dies geschieht von Transaktion zu Transaktion. Gibt es eine dritte Richtlinie? Kann ein Empfänger, Bob, eine eindeutige Zahlungs-ID für Alex generieren? ändert sich nie, vielleicht mithilfe eines Diﬃe-Hellman-Austauschs? Wenn jemand diese Zahlung einbezieht Der Ausweis, der irgendwo in ihrer Transaktion an Bobs Adresse gebündelt war, muss von Alex stammen. Auf diese Weise muss sich Alex nicht dem gesamten Netzwerk offenbaren, indem sie sich für die Verlinkung einer bestimmten Person entscheidet Transaktion, kann sich aber dennoch gegenüber der Person, an die sie ihr Geld sendet, identifizieren. Ist das nicht das, was Poloniex macht?

Transaktion Tx-Eingang Ausgabe0 . . . Ausgabei . . . Ausgaben Schlüsselbild Unterschriften Ringsignatur Zielschlüssel Ausgang1 Zielschlüssel Ausgaben Auslandsgeschäfte Ausgabe des Absenders Zielschlüssel Einmaliges Schlüsselpaar Einmalig privater Schlüssel I = xHp(P) P, x Abb. 7. Generierung einer Ringsignatur in einer Standardtransaktion. 5 Egalitärer Arbeitsnachweis In diesem Abschnitt schlagen wir den neuen proof-of-work-Algorithmus vor und begründen ihn. Unser oberstes Ziel besteht darin, die Lücke zwischen CPU- (Mehrheit) und GPU/FPGA/ASIC-Minern (Minderheit) zu schließen. Es ist angemessen, dass einige Benutzer einen gewissen Vorteil gegenüber anderen haben können, aber ihre Investitionen sollte mindestens linear mit der Leistung wachsen. Im Allgemeinen handelt es sich um die Herstellung von Spezialgeräten muss möglichst wenig profitabel sein. 5.1 Verwandte Werke Das ursprüngliche Protokoll Bitcoin proof-of-work verwendet die CPU-intensive Preisfunktion SHA-256. Es besteht hauptsächlich aus grundlegenden logischen Operatoren und basiert ausschließlich auf der Rechengeschwindigkeit von Prozessor und eignet sich daher hervorragend für die Multicore-/Conveyer-Implementierung. Allerdings sind moderne Computer nicht nur durch die Anzahl der Operationen pro Sekunde begrenzt, sondern auch nach Speichergröße. Während einige Prozessoren wesentlich schneller sein können als andere [8], Es ist weniger wahrscheinlich, dass die Speichergröße zwischen den Computern variiert. Speichergebundene Preisfunktionen wurden erstmals von Abadi et al. eingeführt und als definiert „Funktionen, deren Rechenzeit von der Zeit dominiert wird, die für den Zugriff auf den Speicher aufgewendet wird“ [15]. Die Hauptidee besteht darin, einen Algorithmus zu konstruieren, der einen großen Datenblock („Scratchpad“) zuweist. innerhalb des Speichers, auf den relativ langsam zugegriffen werden kann (z. B. RAM) und „Zugriff auf eine „unvorhersehbare Abfolge von Orten“ darin enthalten. Ein Block sollte groß genug sein, um das Einkochen zu ermöglichen Die Daten sind vorteilhafter, als sie bei jedem Zugriff neu zu berechnen. Der Algorithmus sollte auch Verhindern Sie interne Parallelität, daher sollten N gleichzeitige Threads N-mal mehr Speicher benötigen auf einmal. Dwork et al. [22] untersuchten und formalisierten diesen Ansatz und schlugen einen anderen vor Variante der Preisfunktion: „Mbound“. Ein weiteres Werk gehört F. Coelho [20], der 11 Transaktion Tx-Eingang Ausgabe0 . . . Ausgabei . . . Ausgaben Schlüsselbild Unterschriften Ringsignatur Zielschlüssel Ausgang1 Zielschlüssel Ausgaben Auslandsgeschäfte Ausgabe des Absenders Zielschlüssel Einmaliges Schlüsselpaar Einmalig privater Schlüssel I = xHp(P) P, x Abb. 7. Generierung einer Ringsignatur in einer Standardtransaktion. 5 Egalitärer Arbeitsnachweis In diesem Abschnitt schlagen wir den neuen proof-of-work-Algorithmus vor und begründen ihn. Unser oberstes Ziel besteht darin, die Lücke zwischen CPU- (Mehrheit) und GPU/FPGA/ASIC-Minern (Minderheit) zu schließen. Es ist angemessen, dass einige Benutzer einen gewissen Vorteil gegenüber anderen haben können, aber ihre Investitionen sollte mindestens linear mit der Leistung wachsen. Im Allgemeinen handelt es sich um die Herstellung von Spezialgeräten muss möglichst wenig profitabel sein. 5.1 Verwandte Werke Das ursprüngliche Protokoll Bitcoin proof-of-work verwendet die CPU-intensive Preisfunktion SHA-256. Es besteht hauptsächlich aus grundlegenden logischen Operatoren und basiert ausschließlich auf der Rechengeschwindigkeit von Prozessor und eignet sich daher hervorragend für die Multicore-/Conveyer-Implementierung. Allerdings sind moderne Computer nicht nur durch die Anzahl der Operationen pro Sekunde begrenzt, sondern auch nach Speichergröße. Während einige Prozessoren wesentlich schneller sein können als andere [8], Es ist weniger wahrscheinlich, dass die Speichergröße zwischen den Computern variiert. Speichergebundene Preisfunktionen wurden erstmals von Abadi et al. eingeführt und als definiert „Funktionen, deren Rechenzeit von der Zeit dominiert wird, die für den Zugriff auf den Speicher aufgewendet wird“ [15]. Die Hauptidee besteht darin, einen Algorithmus zu konstruieren, der einen großen Datenblock („Scratchpad“) zuweist. innerhalb des Speichers, auf den relativ langsam zugegriffen werden kann (z. B. RAM) und „Zugriff auf eine „unvorhersehbare Abfolge von Orten“ darin enthalten. Ein Block sollte groß genug sein, um das Einkochen zu ermöglichen Die Daten sind vorteilhafter, als sie bei jedem Zugriff neu zu berechnen. Der Algorithmus sollte auch Verhindern Sie interne Parallelität, daher sollten N gleichzeitige Threads N-mal mehr Speicher benötigen auf einmal. Dwork et al [22] untersuchten und formalisierten diesen Ansatz und schlugen einen anderen vor Variante der Preisfunktion: „Mbound“. Ein weiteres Werk gehört F. Coelho [20], der 11 21 Dies sind angeblich unsere UTXO: Beträge und Zielschlüssel. Wenn Alex derjenige ist, der diese Standardtransaktion erstellt und an Bob sendet, dann verfügt Alex auch über die privaten Schlüssel zu jedem von diesen. Mir gefällt dieses Diagramm sehr gut, weil es einige frühere Fragen beantwortet. Ein Txn-Eingang besteht aus einer Reihe von Txn-Ausgängen und einem key Bild. Anschließend wird es mit einer Ringsignatur signiert, inklusive aller der privaten Schlüssel, die Alex für alle in den Deal einbezogenen Auslandstransaktionen besitzt. Die Die Txn-Ausgabe besteht aus einem Betrag und einem Zielschlüssel. Der Empfänger der Transaktion kann, Generieren Sie nach Belieben ihren einmaligen privaten Schlüssel, wie weiter oben in diesem Artikel beschrieben, um ihn auszugeben das Geld. Es wird eine Freude sein herauszufinden, inwieweit dies mit dem tatsächlichen Code übereinstimmt ... Nein, Nic van Saberhagen beschreibt nur lose einige Eigenschaften eines Proof-of-Work-Algorithmus. ohne diesen Algorithmus tatsächlich zu beschreiben. Der CryptoNight-Algorithmus selbst ERFORDERT eine gründliche Analyse. Als ich das las, stotterte ich. Sollten die Investitionen zumindest linear mit der Macht wachsen oder sollten? Wachsen die Investitionen höchstens linear mit der Leistung? Und dann wurde mir klar; Als Bergmann oder Investor frage ich mich normalerweise: „Wie viel Strom kann ich bekommen?“ für eine Investition?“ nicht „Wie viel Investition ist für eine feste Strommenge erforderlich?“ Natürlich bezeichne ich die Investition mit I und die Macht mit P. Wenn I(P) die Investition als Funktion der Macht ist und P(I) die Leistung als Funktion der Investition ist, werden sie das Gegenteil voneinander sein (wo auch immer). Es können Umkehrungen existieren). Und wenn I(P) schneller als linear ist, ist P(I) langsamer als linear. Daher, Es wird eine reduzierte Rendite für Anleger geben. Das heißt, was der Autor hier sagt ist: „Klar, je mehr man investiert, desto mehr bekommt man.“ Macht. Aber wir sollten versuchen, daraus eine Sache mit reduzierten Renditen zu machen.“ Die CPU-Investitionen werden letztendlich sublinear begrenzt; Die Frage ist, ob die Autoren haben einen POW-Algorithmus entwickelt, der die ASICs dazu zwingt, dies ebenfalls zu tun. Sollte eine hypothetische „zukünftige Währung“ immer mit den langsamsten/begrenztesten Ressourcen abbauen? Das Papier von Abadi et al. (das einige Google- und Microsoft-Ingenieure als Autoren hat) lautet: im Wesentlichen unter Ausnutzung der Tatsache, dass die Speichergröße in den letzten Jahren viel kleiner geworden ist Die Unterschiede zwischen den Maschinen sind größer als die Prozessorgeschwindigkeit und das Verhältnis von Investition zu Leistung ist mehr als linear. In einigen Jahren muss dies möglicherweise neu bewertet werden! Alles ist ein Wettrüsten... Das Konstruieren einer hash-Funktion ist schwierig; Das Konstruieren einer hash-Funktion, die diese Einschränkungen erfüllt, scheint schwieriger zu sein. Dieses Papier scheint keine Erklärung für das Tatsächliche zu haben hashing-Algorithmus CryptoNight. Ich denke, es handelt sich um eine speicherintensive Implementierung von SHA-3 in Forenbeiträgen, aber ich habe keine Ahnung ... und das ist der Punkt. Es muss erklärt werden.

schlug die effektivste Lösung vor: „Hokkaido“. Nach unserem Kenntnisstand ist dies die letzte Arbeit, die auf der Idee der pseudozufälligen Suche in einem großen Array basiert der von C. Percival als „scrypt“ bekannte Algorithmus [32]. Im Gegensatz zu den vorherigen Funktionen konzentriert es sich auf Schlüsselableitung und nicht proof-of-work Systeme. Trotz dieser Tatsache kann scrypt unseren Zweck erfüllen: Es eignet sich gut als Preisfunktion beim partiellen hash-Konvertierungsproblem wie SHA-256 in Bitcoin. Mittlerweile wurde Scrypt bereits in Litecoin, [14] und einigen anderen Bitcoin-Forks angewendet. Allerdings ist seine Implementierung nicht wirklich speichergebunden: Das Verhältnis „Speicherzugriffszeit / insgesamt“. Zeit“ ist nicht groß genug, da jede Instanz nur 128 KB verwendet. Dies ermöglicht GPU-Miner ist ungefähr zehnmal effektiver und lässt weiterhin die Möglichkeit, relativ viel zu schaffen billige, aber hocheffiziente Bergbaugeräte. Darüber hinaus ermöglicht die Verschlüsselungskonstruktion selbst einen linearen Kompromiss zwischen Speichergröße und CPU-Geschwindigkeit aufgrund der Tatsache, dass jeder Block im Scratchpad nur vom vorherigen abgeleitet ist. Sie können beispielsweise jeden zweiten Block speichern und die anderen nur verzögert, also nur, neu berechnen wenn es notwendig wird. Es wird angenommen, dass die Pseudozufallsindizes gleichmäßig verteilt sind. Daher beträgt der erwartete Wert der Neuberechnungen der zusätzlichen Blöcke 1 \(2 \cdot N\), wobei N die Zahl ist von Iterationen. Die Gesamtrechenzeit erhöht sich weniger als um die Hälfte, weil es auch solche gibt Zeitunabhängige (zeitkonstante) Vorgänge wie das Vorbereiten des Notizblocks und das Weitermachen jede Iteration. Das Einsparen von 2/3 des Speichers kostet 1 \(3 \cdot N\) + 1 3 \(\cdot\) \(2 \cdot N\) = N zusätzliche Neuberechnungen; 9/10 ergibt 1 \(10 \cdot N\) + . . . + 1 \(10 \cdot 9 \cdot N\) = 4,5N. Es ist leicht zu zeigen, dass die Speicherung von nur 1 s aller Blöcke erhöht die Zeit weniger als um den Faktor s−1 2 . Dies wiederum impliziert, dass eine Maschine mit einer CPU ausgestattet ist 200-mal schneller als die modernen Chips können nur 320 Bytes des Notizblocks speichern. 5.2 Der vorgeschlagene Algorithmus Wir schlagen einen neuen speichergebundenen Algorithmus für die Preisfunktion proof-of-work vor. Es verlässt sich darauf Direktzugriff auf einen langsamen Speicher und betont die Latenzabhängigkeit. Im Gegensatz zu „jedem verschlüsseln“. Der neue Block (64 Byte lang) hängt von allen vorherigen Blöcken ab. Im Ergebnis eine Hypothese „Speichersparer“ sollte seine Rechengeschwindigkeit exponentiell steigern. Unser Algorithmus benötigt aus folgenden Gründen etwa 2 MB pro Instanz: 1. Es passt in den L3-Cache (pro Kern) moderner Prozessoren, die zum Mainstream werden sollten in ein paar Jahren; 2. Ein Megabyte interner Speicher ist für eine moderne ASIC-Pipeline eine nahezu inakzeptable Größe; 3. GPUs können Hunderte von Instanzen gleichzeitig ausführen, sie sind jedoch in anderer Hinsicht eingeschränkt: Der GDDR5-Speicher ist langsamer als der L3-Cache der CPU und zeichnet sich durch seine Bandbreite aus, nicht jedoch Direktzugriffsgeschwindigkeit. 4. Eine erhebliche Erweiterung des Scratchpads würde eine Zunahme der Iterationen erfordern, was in Umdrehung impliziert eine Gesamtzeitverlängerung. „Schwere“ Anrufe in einem vertrauenswürdigen P2P-Netzwerk können dazu führen schwerwiegende Schwachstellen, da Knoten verpflichtet sind, den proof-of-work jedes neuen Blocks zu überprüfen. Wenn ein Knoten viel Zeit für jede hash-Auswertung aufwendet, kann dies leicht der Fall sein DDoSed durch eine Flut gefälschter Objekte mit willkürlichen Arbeitsdaten (nonce Werte). 12 schlug die effektivste Lösung vor: „Hokkaido“. Nach unserem Kenntnisstand ist dies die letzte Arbeit, die auf der Idee der pseudozufälligen Suche in einem großen Array basiert der von C. Percival als „scrypt“ bekannte Algorithmus [32]. Im Gegensatz zu den vorherigen Funktionen konzentriert es sich auf Schlüsselableitung und nicht proof-of-work Systeme. Trotz dieser Tatsache kann scrypt unseren Zweck erfüllen: Es eignet sich gut als Preisfunktion beim partiellen hash-Konvertierungsproblem wie SHA-256 in Bitcoin. Mittlerweile wurde Scrypt bereits in Litecoin, [14] und einigen anderen Bitcoin-Forks angewendet. Allerdings ist seine Implementierung nicht wirklich speichergebunden: Das Verhältnis „Speicherzugriffszeit / insgesamt“. Zeit“ ist nicht groß genug, da jede Instanz nur 128 KB verwendet. Dies ermöglicht GPU-Miner ist ungefähr zehnmal effektiver und lässt weiterhin die Möglichkeit, relativ viel zu schaffen billige, aber hocheffiziente Bergbaugeräte. Darüber hinaus ermöglicht die Verschlüsselungskonstruktion selbst einen linearen Kompromiss zwischen Speichergröße und CPU-Geschwindigkeit aufgrund der Tatsache, dass jeder Block im Scratchpad nur vom vorherigen abgeleitet ist. Sie können beispielsweise jeden zweiten Block speichern und die anderen nur verzögert, also nur, neu berechnen wenn es notwendig wird. Es wird angenommen, dass die Pseudozufallsindizes gleichmäßig verteilt sind. Daher beträgt der erwartete Wert der Neuberechnungen der zusätzlichen Blöcke 1 \(2 \cdot N\), woN ist die Zahl von Iterationen. Die Gesamtrechenzeit erhöht sich weniger als um die Hälfte, weil es auch solche gibt Zeitunabhängige (zeitkonstante) Vorgänge wie das Vorbereiten des Notizblocks und das Weitermachen jede Iteration. Das Einsparen von 2/3 des Speichers kostet 1 \(3 \cdot N\) + 1 3 \(\cdot\) \(2 \cdot N\) = N zusätzliche Neuberechnungen; 9/10 ergibt 1 \(10 \cdot N\) + . . . + 1 \(10 \cdot 9 \cdot N\) = 4,5N. Es ist leicht zu zeigen, dass die Speicherung von nur 1 s aller Blöcke erhöht die Zeit weniger als um den Faktor s−1 2 . Dies wiederum impliziert, dass eine Maschine mit einer CPU ausgestattet ist 200-mal schneller als die modernen Chips können nur 320 Bytes des Notizblocks speichern. 5.2 Der vorgeschlagene Algorithmus Wir schlagen einen neuen speichergebundenen Algorithmus für die Preisfunktion proof-of-work vor. Es verlässt sich darauf Direktzugriff auf einen langsamen Speicher und betont die Latenzabhängigkeit. Im Gegensatz zu „jedem verschlüsseln“. Der neue Block (64 Byte lang) hängt von allen vorherigen Blöcken ab. Im Ergebnis eine Hypothese „Speichersparer“ sollte seine Rechengeschwindigkeit exponentiell steigern. Unser Algorithmus benötigt aus folgenden Gründen etwa 2 MB pro Instanz: 1. Es passt in den L3-Cache (pro Kern) moderner Prozessoren, die zum Mainstream werden sollten in ein paar Jahren; 2. Ein Megabyte interner Speicher ist für eine moderne ASIC-Pipeline eine nahezu inakzeptable Größe; 3. GPUs können Hunderte von Instanzen gleichzeitig ausführen, sie sind jedoch in anderer Hinsicht eingeschränkt: Der GDDR5-Speicher ist langsamer als der L3-Cache der CPU und zeichnet sich durch seine Bandbreite aus, nicht jedoch Direktzugriffsgeschwindigkeit. 4. Eine erhebliche Erweiterung des Scratchpads würde eine Zunahme der Iterationen erfordern, was in Umdrehung impliziert eine Gesamtzeitverlängerung. „Schwere“ Anrufe in einem vertrauenswürdigen P2P-Netzwerk können dazu führen schwerwiegende Schwachstellen, da Knoten verpflichtet sind, den proof-of-work jedes neuen Blocks zu überprüfen. Wenn ein Knoten viel Zeit für jede hash-Auswertung aufwendet, kann dies leicht der Fall sein DDoSed durch eine Flut gefälschter Objekte mit willkürlichen Arbeitsdaten (nonce-Werten). 12 22 Egal, es ist eine Kryptomünze? Wo ist der Algorithmus? Ich sehe nur eine Werbung. Hier wird Cryptonote, wenn sich sein PoW-Algorithmus lohnt, wirklich glänzen. Das ist es nicht wirklich SHA-256, es ist nicht wirklich verschlüsselt. Es ist neu, speichergebunden und nicht rekursiv.

6 Weitere Vorteile 6.1 Sanfte Emission Die Obergrenze für die Gesamtmenge der digitalen CryptoNote-Münzen beträgt: MSupply = 264 −1 atomare Einheiten. Dies ist eine natürliche Einschränkung, die nur auf Implementierungsgrenzen und nicht auf Intuition basiert wie zum Beispiel „N Münzen sollten für jeden reichen“. Um einen reibungslosen Emissionsprozess sicherzustellen, verwenden wir die folgende Blockformel Belohnungen: BaseReward = (MSupply −A) ≫18, wobei A die Menge der zuvor generierten Münzen ist. 6.2 Einstellbare Parameter 6.2.1 Schwierigkeit CryptoNote enthält einen Targeting-Algorithmus, der die Schwierigkeit jedes Blocks ändert. Dies verringert die Reaktionszeit des Systems, wenn die Netzwerkrate stark wächst oder sinkt, Beibehaltung einer konstanten Blockrate. Die ursprüngliche Methode Bitcoin berechnet das tatsächliche Verhältnis und Zielzeitspanne zwischen den letzten 2016-Blöcken und verwendet sie als Multiplikator für den aktuellen Schwierigkeit. Offensichtlich ist dies für schnelle Neuberechnungen ungeeignet (aufgrund der großen Trägheit) und führt zu Schwingungen. Die allgemeine Idee unseres Algorithmus besteht darin, die gesamte von den Knoten und geleistete Arbeit zu summieren Teilen Sie es durch die Zeit, die sie verbracht haben. Als Maß für die Arbeit dienen die entsprechenden Schwierigkeitswerte in jedem Block. Aufgrund ungenauer und nicht vertrauenswürdiger Zeitstempel können wir den genauen Zeitpunkt jedoch nicht ermitteln Zeitintervall zwischen Blöcken. Ein Benutzer kann seinen Zeitstempel in die Zukunft und zum nächsten Zeitpunkt verschieben Die Intervalle könnten unwahrscheinlich klein oder sogar negativ sein. Vermutlich wird es nur wenige Vorfälle geben Auf diese Weise können wir einfach die Zeitstempel sortieren und die Ausreißer (d. h. 20 %) abschneiden. Die Reichweite von Der Restwert ist die Zeit, die für 80 % der entsprechenden Blöcke aufgewendet wurde. 6.2.2 Größenbeschränkungen Benutzer zahlen für die Speicherung des blockchain und sind berechtigt, über dessen Größe abzustimmen. Jeder Bergmann befasst sich mit dem Zielkonflikt zwischen dem Ausgleich der Kosten und dem Gewinn aus den Gebühren und legt seine eigenen fest „Soft-Limit“ zum Erstellen von Blöcken. Auch die Kernregel für die maximale Blockgröße ist notwendig Dieser Wert sollte jedoch verhindern, dass blockchain mit gefälschten Transaktionen überflutet wird nicht fest codiert sein. Sei MN der Medianwert der letzten N Blockgrößen. Dann die „harte Grenze“ für die Größe der Aufnahmeblöcke beträgt \(2 \cdot M_N\). Es verhindert ein Aufblähen des blockchain, ermöglicht aber dennoch die Begrenzung bei Bedarf langsam mit der Zeit wachsen. Die Transaktionsgröße muss nicht explizit begrenzt werden. Sie ist durch die Größe eines Blocks begrenzt; und wenn jemand eine riesige Transaktion mit Hunderten von Ein-/Ausgaben (oder mit (z. B. aufgrund des hohen Mehrdeutigkeitsgrads der Ringsignaturen) kann er dies tun, indem er eine entsprechende Gebühr entrichtet. 6.2.3 Strafe für Übergröße Ein Miner hat immer noch die Möglichkeit, einen Block bis zum Maximum mit seinen eigenen gebührenfreien Transaktionen zu füllen Größe 2 \(\cdot\) MB. Auch wenn nur die Mehrheit der Bergleute den Medianwert verschieben kann, gibt es dennoch einen 13 6 Weitere Vorteile 6.1 Sanfte Emission Die Obergrenze für die Gesamtmenge der digitalen CryptoNote-Münzen beträgt: MSupply = 264 −1 atomare Einheiten. Dies ist eine natürliche Einschränkung, die nur auf Implementierungsgrenzen und nicht auf Intuition basiert wie zum Beispiel „N Münzen sollten für jeden reichen“. Um einen reibungslosen Emissionsprozess sicherzustellen, verwenden wir die folgende Blockformel Belohnungen: BaseReward = (MSupply −A) ≫18, wobei A die Menge der zuvor generierten Münzen ist. 6.2 Einstellbare Parameter 6.2.1 Schwierigkeit CryptoNote enthält einen Targeting-Algorithmus, der die Schwierigkeit jedes Blocks ändert. Dies verringert die Reaktionszeit des Systems, wenn die Netzwerkrate stark wächst oder sinkt, Beibehaltung einer konstanten Blockrate. Die ursprüngliche Methode Bitcoin berechnet das tatsächliche Verhältnis und Zielzeitspanne zwischen den letzten 2016-Blöcken und verwendet sie als Multiplikator für den aktuellen Schwierigkeit. Offensichtlich ist dies für schnelle Neuberechnungen ungeeignet (aufgrund der großen Trägheit) und führt zu Schwingungen. Die allgemeine Idee unseres Algorithmus besteht darin, die gesamte von den Knoten und geleistete Arbeit zu summieren Teilen Sie es durch die Zeit, die sie verbracht haben. Als Maß für die Arbeit dienen die entsprechenden Schwierigkeitswerte in jedem Block. Aufgrund ungenauer und nicht vertrauenswürdiger Zeitstempel können wir den genauen Zeitpunkt jedoch nicht ermitteln Zeitintervall zwischen Blöcken. Ein Benutzer kann seinen Zeitstempel in die Zukunft und zum nächsten Zeitpunkt verschieben Die Intervalle könnten unwahrscheinlich klein oder sogar negativ sein. Vermutlich wird es nur wenige Vorfälle geben Auf diese Weise können wir einfach die Zeitstempel sortieren und die Ausreißer (d. h. 20 %) abschneiden. Die Reichweite von Der Restwert ist die Zeit, die für 80 % der entsprechenden Blöcke aufgewendet wurde. 6.2.2 Größenbeschränkungen Benutzer zahlen für die Speicherung des blockchain und sind berechtigt, über dessen Größe abzustimmen. Jeder Bergmann befasst sich mit dem Kompromiss zwischen dem Ausgleich von thEr erwirtschaftet Kosten und Gewinn aus den Gebühren und legt seine eigenen fest „Soft-Limit“ zum Erstellen von Blöcken. Auch die Kernregel für die maximale Blockgröße ist notwendig Dieser Wert sollte jedoch verhindern, dass blockchain mit gefälschten Transaktionen überflutet wird nicht fest codiert sein. Sei MN der Medianwert der letzten N Blockgrößen. Dann die „harte Grenze“ für die Größe der Aufnahmeblöcke beträgt \(2 \cdot M_N\). Es verhindert ein Aufblähen des blockchain, ermöglicht aber dennoch die Begrenzung bei Bedarf langsam mit der Zeit wachsen. Die Transaktionsgröße muss nicht explizit begrenzt werden. Sie ist durch die Größe eines Blocks begrenzt; und wenn jemand eine riesige Transaktion mit Hunderten von Ein-/Ausgaben (oder mit (z. B. aufgrund des hohen Mehrdeutigkeitsgrads der Ringsignaturen) kann er dies tun, indem er eine entsprechende Gebühr entrichtet. 6.2.3 Strafe für Übergröße Ein Miner hat immer noch die Möglichkeit, einen Block bis zum Maximum mit seinen eigenen gebührenfreien Transaktionen zu füllen Größe 2 \(\cdot\) MB. Auch wenn nur die Mehrheit der Bergleute den Medianwert verschieben kann, gibt es dennoch einen 13 23 Atomare Einheiten. Ich mag es. Ist das das Äquivalent von Satoshis? Wenn ja, dann bedeutet das, dass es 185 Milliarden Kryptonoten geben wird. Ich weiß, dass dies irgendwann auf ein paar Seiten optimiert werden muss, oder liegt vielleicht ein Tippfehler vor? Wenn die Basisbelohnung „alle verbleibenden Münzen“ beträgt, reicht nur ein Block aus, um alle Münzen zu erhalten. Instamin. Andererseits, wenn dies in irgendeiner Weise proportional zum sein soll Gibt es einen zeitlichen Unterschied zwischen jetzt und einem Datum, an dem die Münzproduktion endet? Das würde Sinn ergeben. Außerdem bedeuten in meiner Welt zwei Größer-als-Zeichen wie dieses „viel größer als“. Hat der Autor möglicherweise etwas anderes bedeuten? Wenn die Anpassung an den Schwierigkeitsgrad bei jedem Block erfolgt, könnte ein Angreifer über eine sehr große Farm verfügen Maschinen schalten den Bergbau in sorgfältig ausgewählten Zeitintervallen ein und aus. Dies könnte zu einer chaotischen Explosion (oder einem Absturz auf Null) des Schwierigkeitsgrads führen, wenn die Schwierigkeitsanpassungsformeln nicht angemessen gedämpft werden. Zweifellos ist die Methode von Bitcoin für schnelle Neuberechnungen ungeeignet, aber die Idee der Trägheit in diesen Systemen müssten nachgewiesen und nicht als selbstverständlich angesehen werden. Darüber hinaus Schwingungen Im Netzwerk sind Schwierigkeiten nicht unbedingt ein Problem, es sei denn, sie führen zu scheinbaren Schwankungen Angebot an Münzen - und ein sich sehr schnell ändernder Schwierigkeitsgrad könnte zu einer „Überkorrektur“ führen. Die aufgewendete Zeit, insbesondere über einen kurzen Zeitraum wie ein paar Minuten, ist proportional zur „Gesamtzeit“. Anzahl der im Netzwerk erstellten Blöcke. Die Proportionalitätskonstante selbst wird wachsen im Laufe der Zeit, vermutlich exponentiell, wenn CN abhebt. Möglicherweise ist es eine bessere Idee, einfach die Schwierigkeit anzupassen, um die „Gesamtzahl der erstellten Blöcke“ beizubehalten Netzwerk, seit der letzte Block zur Hauptkette hinzugefügt wurde“ innerhalb eines konstanten Werts oder mit begrenzte Variation oder so ähnlich. Wenn es sich um einen adaptiven Algorithmus handelt, der rechnerisch ist Wenn festgestellt werden kann, dass die Implementierung einfach ist, scheint dies das Problem zu lösen. Aber wenn wir diese Methode anwenden würden, könnte jemand mit einer großen Mining-Farm seine Farm schließen für ein paar Stunden und schalten Sie es dann wieder ein. Für die ersten paar Blöcke wird diese Farm reichen Bank. Tatsächlich würde diese Methode einen interessanten Punkt ansprechen: Bergbau wird (im Durchschnitt) zu einem Verliererspiel ohne ROI, insbesondere da immer mehr Leute auf das Netzwerk zugreifen. Wenn der Bergbau schwierig ist Ich bezweifle irgendwie, dass die Leute so viel abbauen würden wie sie derzeit tun. Oder sie halten ihre Mining-Farmen andererseits nicht rund um die Uhr am Laufen, sondern drehen sie um 6 Stunden an, 2 Stunden aus, 6 Stunden an, 2 Stunden aus oder so ähnlich. Wechseln Sie einfach zu einer anderen Münze Warten Sie ein paar Stunden, bis die Schwierigkeit nachlässt, und steigen Sie dann wieder ein, um die paar Extras zu gewinnen Rentabilitätsblöcke, wenn sich das Netzwerk anpasst. Und wissen Sie was? Das ist tatsächlich wahrscheinlich Eines der besseren Mining-Szenarien, an die ich gedacht habe ... Dies könnte kreisförmig sein, aber wenn die Blockerstellungszeit durchschnittlich etwa eine Minute beträgt, können wir das einfach tun Verwenden Sie die Anzahl der Blöcke als Proxy für die „aufgewendete Zeit“?

6 Weitere Vorteile 6.1 Sanfte Emission Die Obergrenze für die Gesamtmenge der digitalen CryptoNote-Münzen beträgt: MSupply = 264 −1 atomare Einheiten. Dies ist eine natürliche Einschränkung, die nur auf Implementierungsgrenzen und nicht auf Intuition basiert wie zum Beispiel „N Münzen sollten für jeden reichen“. Um einen reibungslosen Emissionsprozess sicherzustellen, verwenden wir die folgende Blockformel Belohnungen: BaseReward = (MSupply −A) ≫18, wobei A die Menge der zuvor generierten Münzen ist. 6.2 Einstellbare Parameter 6.2.1 Schwierigkeit CryptoNote enthält einen Targeting-Algorithmus, der die Schwierigkeit jedes Blocks ändert. Dies verringert die Reaktionszeit des Systems, wenn die Netzwerkrate stark wächst oder sinkt, Beibehaltung einer konstanten Blockrate. Die ursprüngliche Methode Bitcoin berechnet das tatsächliche Verhältnis und Zielzeitspanne zwischen den letzten 2016-Blöcken und verwendet sie als Multiplikator für den aktuellen Schwierigkeit. Offensichtlich ist dies für schnelle Neuberechnungen ungeeignet (aufgrund der großen Trägheit) und führt zu Schwingungen. Die allgemeine Idee unseres Algorithmus besteht darin, die gesamte von den Knoten und geleistete Arbeit zu summieren Teilen Sie es durch die Zeit, die sie verbracht haben. Als Maß für die Arbeit dienen die entsprechenden Schwierigkeitswerte in jedem Block. Aufgrund ungenauer und nicht vertrauenswürdiger Zeitstempel können wir den genauen Zeitpunkt jedoch nicht ermitteln Zeitintervall zwischen Blöcken. Ein Benutzer kann seinen Zeitstempel in die Zukunft und zum nächsten Zeitpunkt verschieben Die Intervalle könnten unwahrscheinlich klein oder sogar negativ sein. Vermutlich wird es nur wenige Vorfälle geben Auf diese Weise können wir einfach die Zeitstempel sortieren und die Ausreißer (d. h. 20 %) abschneiden. Die Reichweite von Der Restwert ist die Zeit, die für 80 % der entsprechenden Blöcke aufgewendet wurde. 6.2.2 Größenbeschränkungen Benutzer zahlen für die Speicherung des blockchain und sind berechtigt, über dessen Größe abzustimmen. Jeder Bergmann befasst sich mit dem Zielkonflikt zwischen dem Ausgleich der Kosten und dem Gewinn aus den Gebühren und legt seine eigenen fest „Soft-Limit“ zum Erstellen von Blöcken. Auch die Kernregel für die maximale Blockgröße ist notwendig Dieser Wert sollte jedoch verhindern, dass blockchain mit gefälschten Transaktionen überflutet wird nicht fest codiert sein. Sei MN der Medianwert der letzten N Blockgrößen. Dann die „harte Grenze“ für die Größe der Aufnahmeblöcke beträgt \(2 \cdot M_N\). Es verhindert ein Aufblähen des blockchain, ermöglicht aber dennoch die Begrenzung bei Bedarf langsam mit der Zeit wachsen. Die Transaktionsgröße muss nicht explizit begrenzt werden. Sie ist durch die Größe eines Blocks begrenzt; und wenn jemand eine riesige Transaktion mit Hunderten von Ein-/Ausgaben (oder mit (z. B. aufgrund des hohen Mehrdeutigkeitsgrads der Ringsignaturen) kann er dies tun, indem er eine entsprechende Gebühr entrichtet. 6.2.3 Strafe für Übergröße Ein Miner hat immer noch die Möglichkeit, einen Block bis zum Maximum mit seinen eigenen gebührenfreien Transaktionen zu füllen Größe 2 \(\cdot\) MB. Auch wenn nur die Mehrheit der Bergleute den Medianwert verschieben kann, gibt es dennoch einen 13 6 Weitere Vorteile 6.1 Sanfte Emission Die Obergrenze für die Gesamtmenge der digitalen CryptoNote-Münzen beträgt: MSupply = 264 −1 atomare Einheiten. Dies ist eine natürliche Einschränkung, die nur auf Implementierungsgrenzen und nicht auf Intuition basiert wie zum Beispiel „N Münzen sollten für jeden reichen“. Um einen reibungslosen Emissionsprozess sicherzustellen, verwenden wir die folgende Blockformel Belohnungen: BaseReward = (MSupply −A) ≫18, wobei A die Menge der zuvor generierten Münzen ist. 6.2 Einstellbare Parameter 6.2.1 Schwierigkeit CryptoNote enthält einen Targeting-Algorithmus, der die Schwierigkeit jedes Blocks ändert. Dies verringert die Reaktionszeit des Systems, wenn die Netzwerkrate stark wächst oder sinkt, Beibehaltung einer konstanten Blockrate. Die ursprüngliche Methode Bitcoin berechnet das tatsächliche Verhältnis und Zielzeitspanne zwischen den letzten 2016-Blöcken und verwendet sie als Multiplikator für den aktuellen Schwierigkeit. Offensichtlich ist dies für schnelle Neuberechnungen ungeeignet (aufgrund der großen Trägheit) und führt zu Schwingungen. Die allgemeine Idee unseres Algorithmus besteht darin, die gesamte von den Knoten und geleistete Arbeit zu summieren Teilen Sie es durch die Zeit, die sie verbracht haben. Als Maß für die Arbeit dienen die entsprechenden Schwierigkeitswerte in jedem Block. Aufgrund ungenauer und nicht vertrauenswürdiger Zeitstempel können wir den genauen Zeitpunkt jedoch nicht ermitteln Zeitintervall zwischen Blöcken. Ein Benutzer kann seinen Zeitstempel in die Zukunft und zum nächsten Zeitpunkt verschieben Die Intervalle könnten unwahrscheinlich klein oder sogar negativ sein. Vermutlich wird es nur wenige Vorfälle geben Auf diese Weise können wir einfach die Zeitstempel sortieren und die Ausreißer (d. h. 20 %) abschneiden. Die Reichweite von Der Restwert ist die Zeit, die für 80 % der entsprechenden Blöcke aufgewendet wurde. 6.2.2 Größenbeschränkungen Benutzer zahlen für die Speicherung des blockchain und sind berechtigt, über dessen Größe abzustimmen. Jeder Bergmann befasst sich mit dem Kompromiss zwischen dem Ausgleich von thEr erwirtschaftet Kosten und Gewinn aus den Gebühren und legt seine eigenen fest „Soft-Limit“ zum Erstellen von Blöcken. Auch die Kernregel für die maximale Blockgröße ist notwendig Dieser Wert sollte jedoch verhindern, dass blockchain mit gefälschten Transaktionen überflutet wird nicht fest codiert sein. Sei MN der Medianwert der letzten N Blockgrößen. Dann die „harte Grenze“ für die Größe der Aufnahmeblöcke beträgt \(2 \cdot M_N\). Es verhindert ein Aufblähen des blockchain, ermöglicht aber dennoch die Begrenzung bei Bedarf langsam mit der Zeit wachsen. Die Transaktionsgröße muss nicht explizit begrenzt werden. Sie ist durch die Größe eines Blocks begrenzt; und wenn jemand eine riesige Transaktion mit Hunderten von Ein-/Ausgaben (oder mit (z. B. aufgrund des hohen Mehrdeutigkeitsgrads der Ringsignaturen) kann er dies tun, indem er eine entsprechende Gebühr entrichtet. 6.2.3 Strafe für Übergröße Ein Miner hat immer noch die Möglichkeit, einen Block bis zum Maximum mit seinen eigenen gebührenfreien Transaktionen zu füllen Größe 2 \(\cdot\) MB. Auch wenn nur die Mehrheit der Bergleute den Medianwert verschieben kann, gibt es dennoch einen 13 24 Okay, wir haben also einen blockchain, und jeder Block hat ZUSÄTZLICH zum bloßen Sein Zeitstempel bestellt. Dies wurde offensichtlich nur aus Gründen der Schwierigkeitsanpassung eingefügt, da dies bei Zeitstempeln der Fall ist wie gesagt sehr unzuverlässig. Dürfen wir widersprüchliche Zeitstempel in der Kette haben? Wenn Block A in der Kette vor Block B steht und finanziell alles stimmig ist, aber Block A scheint nach Block B erstellt worden zu sein? Weil es vielleicht jemand besaß ein großer Teil des Netzwerks? Ist das in Ordnung? Wahrscheinlich, weil die Finanzen nicht vermasselt sind. Okay, also ich hasse dieses willkürliche „nur 80 % der Blöcke sind für den Hauptblock blockchain legitim“ Ansatz. Es sollte verhindern, dass Lügner ihre Zeitstempel manipulieren? Aber jetzt fügt es hinzu Anreiz für alle, über ihre Zeitstempel zu lügen und einfach den Median zu wählen. Bitte definieren. Bedeutung: „Berücksichtigen Sie für diesen Block nur Transaktionen, die höhere Gebühren beinhalten.“ als p%, vorzugsweise mit Gebühren über 2p% oder so ähnlich? Was meinen sie mit Schwindel? Wenn die Transaktion mit der bisherigen Geschichte des übereinstimmt blockchain, und die Transaktion beinhaltet Gebühren, die die Bergleute zufriedenstellen, ist das nicht genug? Nun, nein, nicht unbedingt. Wenn es keine maximale Blockgröße gibt, gibt es nichts, was einen böswilligen Benutzer abhalten könnte vom einfachen Hochladen eines riesigen Transaktionsblocks auf einmal auf sich selbst, nur um langsamer zu werden das Netzwerk. Eine Kernregel für die maximale Blockgröße verhindert, dass Menschen große Mengen an Müll ablegen Daten auf dem blockchain auf einmal, nur um die Dinge zu verlangsamen. Aber eine solche Regel muss es auf jeden Fall tun Seien Sie anpassungsfähig – während der Weihnachtszeit können wir beispielsweise mit einem Anstieg des Verkehrsaufkommens rechnen Die Blockgröße wird sehr groß, und unmittelbar danach sinkt die Blockgröße wieder. Wir brauchen also entweder a) eine Art adaptive Obergrenze oder b) eine Obergrenze, die groß genug ist, dass 99 % davon Vernünftige Weihnachtsgipfel sprengen nicht die Obergrenze. Das zweite ist natürlich unmöglich Schätzung – wer weiß, ob sich eine Währung durchsetzen wird? Es ist besser, es anpassungsfähig zu machen und sich keine Sorgen zu machen darüber. Aber dann haben wir ein kontrolltheoretisches Problem: Wie kann man das adaptiv machen, ohne Anfälligkeit für Angriffe oder wilde und verrückte Schwankungen? Beachten Sie, dass eine adaptive Methode böswillige Benutzer nicht davon abhält, kleine Beträge anzuhäufen Im Laufe der Zeit entstehen auf dem blockchain Junk-Daten, die zu einer langfristigen Aufblähung führen. Das ist ein anderes Problem insgesamt und eines, mit dem Kryptonote-Münzen ernsthafte Probleme haben.

6 Weitere Vorteile 6.1 Sanfte Emission Die Obergrenze für die Gesamtmenge der digitalen CryptoNote-Münzen beträgt: MSupply = 264 −1 atomare Einheiten. Dies ist eine natürliche Einschränkung, die nur auf Implementierungsgrenzen und nicht auf Intuition basiert wie zum Beispiel „N Münzen sollten für jeden reichen“. Um einen reibungslosen Emissionsprozess sicherzustellen, verwenden wir die folgende Blockformel Belohnungen: BaseReward = (MSupply −A) ≫18, wobei A die Menge der zuvor generierten Münzen ist. 6.2 Einstellbare Parameter 6.2.1 Schwierigkeit CryptoNote enthält einen Targeting-Algorithmus, der die Schwierigkeit jedes Blocks ändert. Dies verringert die Reaktionszeit des Systems, wenn die Netzwerkrate stark wächst oder sinkt, Beibehaltung einer konstanten Blockrate. Die ursprüngliche Methode Bitcoin berechnet das tatsächliche Verhältnis und Zielzeitspanne zwischen den letzten 2016-Blöcken und verwendet sie als Multiplikator für den aktuellen Schwierigkeit. Offensichtlich ist dies für schnelle Neuberechnungen ungeeignet (aufgrund der großen Trägheit) und führt zu Schwingungen. Die allgemeine Idee unseres Algorithmus besteht darin, die gesamte von den Knoten und geleistete Arbeit zu summieren Teilen Sie es durch die Zeit, die sie verbracht haben. Als Maß für die Arbeit dienen die entsprechenden Schwierigkeitswerte in jedem Block. Aufgrund ungenauer und nicht vertrauenswürdiger Zeitstempel können wir den genauen Zeitpunkt jedoch nicht ermitteln Zeitintervall zwischen Blöcken. Ein Benutzer kann seinen Zeitstempel in die Zukunft und zum nächsten Zeitpunkt verschieben Die Intervalle könnten unwahrscheinlich klein oder sogar negativ sein. Vermutlich wird es nur wenige Vorfälle geben Auf diese Weise können wir einfach die Zeitstempel sortieren und die Ausreißer (d. h. 20 %) abschneiden. Die Reichweite von Der Restwert ist die Zeit, die für 80 % der entsprechenden Blöcke aufgewendet wurde. 6.2.2 Größenbeschränkungen Benutzer zahlen für die Speicherung des blockchain und sind berechtigt, über dessen Größe abzustimmen. Jeder Bergmann befasst sich mit dem Zielkonflikt zwischen dem Ausgleich der Kosten und dem Gewinn aus den Gebühren und legt seine eigenen fest „Soft-Limit“ zum Erstellen von Blöcken. Auch die Kernregel für die maximale Blockgröße ist notwendig Dieser Wert sollte jedoch verhindern, dass blockchain mit gefälschten Transaktionen überflutet wird nicht fest codiert sein. Sei MN der Medianwert der letzten N Blockgrößen. Dann die „harte Grenze“ für die Größe der Aufnahmeblöcke beträgt \(2 \cdot M_N\). Es verhindert ein Aufblähen des blockchain, ermöglicht aber dennoch eine Begrenzung bei Bedarf langsam mit der Zeit wachsen. Die Transaktionsgröße muss nicht explizit begrenzt werden. Sie ist durch die Größe eines Blocks begrenzt; und wenn jemand eine riesige Transaktion mit Hunderten von Ein-/Ausgaben (oder mit (z. B. aufgrund des hohen Mehrdeutigkeitsgrads der Ringsignaturen) kann er dies tun, indem er eine entsprechende Gebühr entrichtet. 6.2.3 Strafe für Übergröße Ein Miner hat immer noch die Möglichkeit, einen Block bis zum Maximum mit seinen eigenen gebührenfreien Transaktionen zu füllen Größe 2 \(\cdot\) MB. Auch wenn nur die Mehrheit der Bergleute den Medianwert verschieben kann, gibt es dennoch einen 13 6 Weitere Vorteile 6.1 Sanfte Emission Die Obergrenze für die Gesamtmenge der digitalen CryptoNote-Münzen beträgt: MSupply = 264 −1 atomare Einheiten. Dies ist eine natürliche Einschränkung, die nur auf Implementierungsgrenzen und nicht auf Intuition basiert wie zum Beispiel „N Münzen sollten für jeden reichen“. Um einen reibungslosen Emissionsprozess sicherzustellen, verwenden wir die folgende Blockformel Belohnungen: BaseReward = (MSupply −A) ≫18, wobei A die Menge der zuvor generierten Münzen ist. 6.2 Einstellbare Parameter 6.2.1 Schwierigkeit CryptoNote enthält einen Targeting-Algorithmus, der die Schwierigkeit jedes Blocks ändert. Dies verringert die Reaktionszeit des Systems, wenn die Netzwerkrate stark wächst oder sinkt, Beibehaltung einer konstanten Blockrate. Die ursprüngliche Methode Bitcoin berechnet das tatsächliche Verhältnis und Zielzeitspanne zwischen den letzten 2016-Blöcken und verwendet sie als Multiplikator für den aktuellen Schwierigkeit. Offensichtlich ist dies für schnelle Neuberechnungen ungeeignet (aufgrund der großen Trägheit) und führt zu Schwingungen. Die allgemeine Idee unseres Algorithmus besteht darin, die gesamte von den Knoten und geleistete Arbeit zu summieren Teilen Sie es durch die Zeit, die sie verbracht haben. Als Maß für die Arbeit dienen die entsprechenden Schwierigkeitswerte in jedem Block. Aufgrund ungenauer und nicht vertrauenswürdiger Zeitstempel können wir den genauen Zeitpunkt jedoch nicht ermitteln Zeitintervall zwischen Blöcken. Ein Benutzer kann seinen Zeitstempel in die Zukunft und zum nächsten Zeitpunkt verschieben Die Intervalle könnten unwahrscheinlich klein oder sogar negativ sein. Vermutlich wird es nur wenige Vorfälle geben Auf diese Weise können wir einfach die Zeitstempel sortieren und die Ausreißer (d. h. 20 %) abschneiden. Die Reichweite von Der Restwert ist die Zeit, die für 80 % der entsprechenden Blöcke aufgewendet wurde. 6.2.2 Größenbeschränkungen Benutzer zahlen für die Speicherung des blockchain und sind berechtigt, über dessen Größe abzustimmen. Jeder Bergmann befasst sich mit dem Kompromiss zwischen dem Ausgleich von thEr erwirtschaftet Kosten und Gewinn aus den Gebühren und legt seine eigenen fest „Soft-Limit“ zum Erstellen von Blöcken. Auch die Kernregel für die maximale Blockgröße ist notwendig Dieser Wert sollte jedoch verhindern, dass blockchain mit gefälschten Transaktionen überflutet wird nicht fest codiert sein. Sei MN der Medianwert der letzten N Blockgrößen. Dann die „harte Grenze“ für die Größe der Aufnahmeblöcke beträgt \(2 \cdot M_N\). Es verhindert ein Aufblähen des blockchain, ermöglicht aber dennoch eine Begrenzung bei Bedarf langsam mit der Zeit wachsen. Die Transaktionsgröße muss nicht explizit begrenzt werden. Sie ist durch die Größe eines Blocks begrenzt; und wenn jemand eine riesige Transaktion mit Hunderten von Ein-/Ausgaben (oder mit (z. B. aufgrund des hohen Mehrdeutigkeitsgrads der Ringsignaturen) kann er dies tun, indem er eine entsprechende Gebühr entrichtet. 6.2.3 Strafe für Übergröße Ein Miner hat immer noch die Möglichkeit, einen Block bis zum Maximum mit seinen eigenen gebührenfreien Transaktionen zu füllen Größe 2 \(\cdot\) MB. Auch wenn nur die Mehrheit der Bergleute den Medianwert verschieben kann, gibt es dennoch einen 13 25 Wenn man die Zeit neu skaliert, sodass eine Zeiteinheit aus N Blöcken besteht, könnte die durchschnittliche Blockgröße theoretisch immer noch exponentiell proportional zu 2ˆt wachsen. Andererseits eine allgemeinere Obergrenze im nächsten Block wäre M_nf(M_n) für eine Funktion f. Welche Eigenschaften von f würden die wir wählen, um ein „angemessenes Wachstum“ der Blockgröße zu gewährleisten? Der Fortschritt von Blockgrößen (nach der Neuskalierungszeit) würden wie folgt aussehen: 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( ... Und das Ziel hier ist, f so zu wählen, dass diese Folge nicht schneller wächst als beispielsweise linear, oder vielleicht sogar als Log(t). Wenn f(M_n) = a für eine Konstante a ist, ist diese Sequenz natürlich eigentlich M_n aM_n aˆ2M_n aˆ3M_n ... Und die einzige Möglichkeit, dies auf höchstens lineares Wachstum zu beschränken, besteht natürlich darin, a=1 zu wählen. Das ist natürlich undurchführbar. Es lässt überhaupt kein Wachstum zu. Wenn f(M_n) hingegen eine nicht konstante Funktion ist, dann ist die Situation viel schwieriger kompliziert und kann eine elegante Lösung ermöglichen. Ich werde eine Weile darüber nachdenken. Diese Gebühr muss hoch genug sein, um die Übergrößenstrafe aus dem nächsten Abschnitt abzurechnen. Warum wird bei einem allgemeinen Benutzer davon ausgegangen, dass er männlich ist? Hä?

Möglichkeit, den blockchain aufzublähen und eine zusätzliche Belastung der Knoten zu erzeugen. Entmutigen Um böswillige Teilnehmer davon abzuhalten, große Blöcke zu erstellen, führen wir eine Straffunktion ein: NewReward = BaseReward \(\cdot\) BlkSize MN −1 2 Diese Regel wird nur angewendet, wenn BlkSize größer als die minimale freie Blockgröße ist, die erforderlich ist in der Nähe von max(10kb, \(M_N \cdot 110\%\)) liegen. Minern ist es erlaubt, Blöcke „normaler Größe“ und gerader Größe zu erstellen Übersteigen Sie es mit Gewinn, wenn die Gesamtgebühren die Strafe übersteigen. Es ist jedoch unwahrscheinlich, dass die Gebühren steigen quadratisch ungleich dem Strafwert, sodass ein Gleichgewicht herrscht. 6.3 Transaktionsskripte CryptoNote verfügt über ein sehr minimalistisches Skript-Subsystem. Ein Absender gibt einen Ausdruck Φ = an f (x1, x2, . . , xn), wobei n die Anzahl der öffentlichen Zielschlüssel {Pi}n ist i=1. Nur fünf Binärdateien Unterstützte Operatoren: min, max, sum, mul und cmp. Wenn der Empfänger diese Zahlung ausgibt, Er erzeugt \(0 \leq k \leq n\) Signaturen und übergibt sie an die Transaktionseingabe. Der Verifizierungsprozess wertet einfach Φ mit xi = 1 aus, um zu prüfen, ob eine gültige Signatur für den öffentlichen Schlüssel Pi vorhanden ist, und xi = 0. Ein Prüfer akzeptiert den Beweis, wenn Φ > 0. Trotz seiner Einfachheit deckt dieser Ansatz jeden möglichen Fall ab: • Multi-/Threshold-Signatur. Für die „M-aus-N“-Mehrfachsignatur im Bitcoin-Stil (d. h. der Empfänger sollte mindestens \(0 \leq M \leq N\) gültige Signaturen bereitstellen) Φ = x1+x2+. . .+xN \(\geq M\) (Der Übersichtlichkeit halber verwenden wir die übliche algebraische Notation). Die gewichtete Schwellenwertsignatur (einige Schlüssel können wichtiger sein als andere) könnte ausgedrückt werden als Φ = \(w_1 \cdot x_1\) + \(w_2 \cdot x_2\) + . . . + \(w_N \cdot x_N\) \(\geq wM\). Und Szenario, in dem der Hauptschlüssel Φ = entspricht max(\(M \cdot x\), x1 + x2 + . . . + xN) \(\geq M\). Es ist leicht zu zeigen, dass jeder anspruchsvolle Fall möglich ist werden mit diesen Operatoren ausgedrückt, d. h. sie bilden die Basis. • Passwortschutz. Der Besitz eines geheimen Passwortes steht der Kenntnis davon gleich ein privater Schlüssel, der deterministisch aus dem Passwort abgeleitet wird: k = KDF(s). Daher ein Empfänger kann nachweisen, dass er das Passwort kennt, indem er eine weitere Signatur unter dem Schlüssel k hinterlegt. Der Absender fügt einfach den entsprechenden öffentlichen Schlüssel zu seiner eigenen Ausgabe hinzu. Beachten Sie, dass dies Die Methode ist viel sicherer als das in Bitcoin [13] verwendete „Transaktionsrätsel“, bei dem die Das Passwort wird in den Eingaben explizit übergeben. • Entartete Fälle. Φ = 1 bedeutet, dass jeder das Geld ausgeben kann; Φ = 0 markiert die Ausgabe als nicht für immer auszugeben. Für den Fall, dass das Ausgabeskript in Kombination mit öffentlichen Schlüsseln für einen Absender zu groß ist, wird er kann einen speziellen Ausgabetyp verwenden, der angibt, dass der Empfänger diese Daten in seine Eingabe einfügt während der Absender nur eine hash davon bereitstellt. Dieser Ansatz ähnelt dem „Pay-to-hash“ von Bitcoin. Feature, aber anstatt neue Skriptbefehle hinzuzufügen, behandeln wir diesen Fall an der Datenstruktur Ebene. 7 Fazit Wir haben die größten Mängel in Bitcoin untersucht und einige mögliche Lösungen vorgeschlagen. Diese vorteilhaften Funktionen und unsere kontinuierliche Weiterentwicklung machen das neue elektronische Bargeldsystem CryptoNote aus ein ernstzunehmender Konkurrent von Bitcoin, der alle seine Forks übertrifft. 14 Möglichkeit, den blockchain aufzublähen und eine zusätzliche Belastung der Knoten zu erzeugen. Entmutigen Um böswillige Teilnehmer davon abzuhalten, große Blöcke zu erstellen, führen wir eine Straffunktion ein: NewReward = BaseReward \(\cdot\) BlkSize MN −1 2 Diese Regel wird nur angewendet, wenn BlkSize größer als die minimale freie Blockgröße ist, die erforderlich ist in der Nähe von max(10kb, \(M_N \cdot 110\%\)) liegen. Minern ist es erlaubt, Blöcke „normaler Größe“ und gerader Größe zu erstellen Übersteigen Sie es mit Gewinn, wenn die Gesamtgebühren die Strafe übersteigen. Es ist jedoch unwahrscheinlich, dass die Gebühren steigen quadratisch ungleich dem Strafwert, sodass ein Gleichgewicht herrscht. 6.3 Transaktionsskripte CryptoNote verfügt über ein sehr minimalistisches Skript-Subsystem. Ein Absender gibt einen Ausdruck Φ = an f (x1, x2, . . , xn), wobei n die Anzahl der öffentlichen Zielschlüssel {Pi}n ist i=1. Nur fünf Binärdateien Unterstützte Operatoren: min, max, sum, mul und cmp. Wenn der Empfänger diese Zahlung ausgibt, Er erzeugt \(0 \leq k \leq n\) Signaturen und übergibt sie an die Transaktionseingabe. Der Verifizierungsprozess wertet einfach Φ mit xi = 1 aus, um zu prüfen, ob eine gültige Signatur für den öffentlichen Schlüssel Pi vorhanden ist, und xi = 0. Ein Prüfer akzeptiert den Beweis, wenn Φ > 0. Trotz seiner Einfachheit deckt dieser Ansatz jeden möglichen Fall ab: • Multi-/Threshold-Signatur. Für die „M-aus-N“-Mehrfachsignatur im Bitcoin-Stil (d. h. der Empfänger sollte mindestens \(0 \leq M \leq N\) gültige Signaturen bereitstellen) Φ = x1+x2+. . .+xN \(\geq M\) (Der Übersichtlichkeit halber verwenden wir die übliche algebraische Notation). Die gewichtete Schwellenwertsignatur (einige Schlüssel können wichtiger sein als andere) könnte ausgedrückt werden als Φ = \(w_1 \cdot x_1\) + \(w_2 \cdot x_2\) + . . . + \(w_N \cdot x_N\) \(\geq wM\). Und Szenarioio wobei der Hauptschlüssel Φ = entspricht max(\(M \cdot x\), x1 + x2 + . . . + xN) \(\geq M\). Es ist leicht zu zeigen, dass jeder anspruchsvolle Fall möglich ist werden mit diesen Operatoren ausgedrückt, d. h. sie bilden die Basis. • Passwortschutz. Der Besitz eines geheimen Passwortes steht der Kenntnis davon gleich ein privater Schlüssel, der deterministisch aus dem Passwort abgeleitet wird: k = KDF(s). Daher ein Empfänger kann nachweisen, dass er das Passwort kennt, indem er eine weitere Signatur unter dem Schlüssel k hinterlegt. Der Absender fügt einfach den entsprechenden öffentlichen Schlüssel zu seiner eigenen Ausgabe hinzu. Beachten Sie, dass dies Die Methode ist viel sicherer als das in Bitcoin [13] verwendete „Transaktionsrätsel“, bei dem die Das Passwort wird in den Eingaben explizit übergeben. • Entartete Fälle. Φ = 1 bedeutet, dass jeder das Geld ausgeben kann; Φ = 0 markiert die Ausgabe als nicht für immer auszugeben. Für den Fall, dass das Ausgabeskript in Kombination mit öffentlichen Schlüsseln für einen Absender zu groß ist, wird er kann einen speziellen Ausgabetyp verwenden, der angibt, dass der Empfänger diese Daten in seine Eingabe einfügt während der Absender nur eine hash davon bereitstellt. Dieser Ansatz ähnelt dem „Pay-to-hash“ von Bitcoin. Feature, aber anstatt neue Skriptbefehle hinzuzufügen, behandeln wir diesen Fall an der Datenstruktur Ebene. 7 Fazit Wir haben die größten Mängel in Bitcoin untersucht und einige mögliche Lösungen vorgeschlagen. Diese vorteilhaften Funktionen und unsere kontinuierliche Weiterentwicklung machen das neue elektronische Bargeldsystem CryptoNote aus ein ernstzunehmender Konkurrent von Bitcoin, der alle seine Forks übertrifft. 14 26 Dies kann unnötig sein, wenn wir einen Weg finden können, die Blockgröße im Laufe der Zeit zu begrenzen ... Auch das kann nicht richtig sein. Sie haben „NewReward“ einfach auf eine nach oben gerichtete Parabel gesetzt, wo Die Blockgröße ist die unabhängige Variable. Die neue Belohnung explodiert also bis ins Unendliche. Wenn andererseits Andererseits ist die neue Belohnung Max(0,Base Reward(1-(BlkSize/Mn - 1)ˆ2)), dann die neue Belohnung wäre eine nach unten gerichtete Parabel mit einer Spitze bei Blockgröße = Mn und Schnittpunkten bei Blockgröße = 0 und Blockgröße = 2Mn. Und das scheint es zu sein, was sie zu beschreiben versuchen. Dies ist jedoch nicht der Fall

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

5 Es spielt keine allzu große Rolle, wenn eine Milliarde Menschen auf der Welt von weniger als einem Dollar pro Jahr leben müssen Tag und haben keine Hoffnung, jemals an irgendeinem Bergbaunetzwerk teilzunehmen ... aber an einem wirtschaftlichen Welt, die von einem P2P-Währungssystem mit einer CPU und einer Stimme angetrieben wird, wäre vermutlich mehr fairer als ein System, das auf Teilreservebanken basiert. Aber das Protokoll von Cryptonote erfordert immer noch 51 % ehrliche Benutzer ... siehe zum Beispiel das Cryptonote Foren, in denen einer der Entwickler, Pliskov, sagt, dass ein traditioneller „Replace-the-Data-on-theblockchain“-51-%-Angriff immer noch funktionieren kann. https://forum.cryptonote.org/viewtopic.php?f=2&t=198 Beachten Sie, dass Sie nicht wirklich 51 % ehrliche Benutzer benötigen. Man braucht einfach wirklich „keinen einzigen Unehrlichen“. Fraktion mit mehr als 51 % der Macht des Netzwerks.“ Nennen wir dieses sogenannte Problem von Bitcoin „adaptive Starrheit“. Die Lösung von Cryptonote für Adaptive Steifigkeit ist die adaptive Flexibilität der Protokollparameterwerte. Wenn Sie größere Blockgrößen benötigen, Kein Problem, das Netzwerk hat sich die ganze Zeit über sanft angepasst. Das heißt, Die Art und Weise, wie Bitcoin den Schwierigkeitsgrad im Laufe der Zeit anpasst, kann in unserem gesamten Protokoll reproduziert werden Parameter, so dass für die Aktualisierung des Protokolls kein Netzwerkkonsens eingeholt werden muss. Oberflächlich betrachtet scheint dies eine gute Idee zu sein, aber ohne sorgfältige Voraussicht eine Selbstanpassung Das System kann ziemlich unvorhersehbar und chaotisch werden. Wir werden später näher darauf eingehen Chancen ergeben sich. „Gute“ Systeme liegen irgendwo zwischen adaptiv starr und adaptiv Flexibilität und vielleicht sogar die Starrheit selbst sind anpassungsfähig. Wenn wir wirklich „eine CPU, eine Stimme“ hätten, dann müssten wir zusammenarbeiten und Pools entwickeln, um 51 % zu erreichen. wäre schwieriger. Wir würden erwarten, dass jede CPU auf der Welt von Telefonen aus Mining durchführt an die integrierte CPU Ihres Tesla während des Ladevorgangs. http://en.wikipedia.org/wiki/Pareto_principle Ich behaupte, dass das Pareto-Gleichgewicht einigermaßen unvermeidbar ist. Entweder 20 % des Systems werden es tun 80 % der CPUs besitzen, oder 20 % des Systems besitzen 80 % der ASICs. Ich vermute dies, weil die zugrunde liegende Vermögensverteilung in der Gesellschaft bereits die Pareto-Verteilung aufweist. und wenn neue Miner beitreten, werden sie aus dieser zugrunde liegenden Verteilung gezogen. Ich behaupte jedoch, dass Protokolle mit einer CPU und einer Stimme einen ROI auf der Hardware erzielen werden. Blockieren Die Belohnung pro Knoten wird eher proportional zur Anzahl der Knoten im Netzwerk sein, weil Die Leistungsverteilung zwischen den Knoten wird viel enger sein. Bitcoin, andererseits Andererseits sieht er eine Blockbelohnung (pro Knoten), die proportionaler zur Rechenkapazität dieses Knotens ist Knoten. Das heißt, nur noch die „großen Jungs“ sind im Mining-Geschäft aktiv. Andererseits, Auch wenn das Pareto-Prinzip weiterhin im Spiel sein wird, gilt in einer Welt mit einer CPU und einer Stimme jeder beteiligt sich an der Netzwerksicherheit und erzielt einen Teil der Mining-Einnahmen. In einer ASIC-Welt ist es nicht sinnvoll, jede XBox und jedes Mobiltelefon an meine anzupassen. In einer One-CPU-One-Vote-Welt ist das im Hinblick auf die Mining-Belohnung sehr sinnvoll. Als erfreuliche Konsequenz Es ist schwieriger, 51 % der Stimmen zu erreichen, wenn es immer mehr Stimmen gibt, was zu einem schönen Ergebnis führt Vorteile für die Netzwerksicherheit.Hardware wie zuvor beschrieben. Nehmen wir an, dass die globale hashrate deutlich abnimmt, sogar für Einen Moment lang kann er nun seine Mining-Kraft nutzen, um die Kette zu verzweigen und doppelte Ausgaben zu tätigen. Wie wir sehen werden Später in diesem Artikel ist es nicht unwahrscheinlich, dass das zuvor beschriebene Ereignis eintritt. 2.3 Unregelmäßige Emission Bitcoin hat eine vorgegebene Emissionsrate: Jeder gelöste Block produziert eine feste Menge an Münzen. Etwa alle vier Jahre wird diese Belohnung halbiert. Die ursprüngliche Absicht bestand darin, eine zu schaffen begrenzte glatte Emission mit exponentiellem Abfall, aber tatsächlich haben wir eine stückweise lineare Emission Funktion, deren Haltepunkte Probleme in der Bitcoin-Infrastruktur verursachen können. Wenn der Haltepunkt erreicht wird, erhalten die Miner nur noch die Hälfte ihres vorherigen Wertes Belohnung. Der absolute Unterschied zwischen 12,5 und 6,25 BTC (prognostiziert für das Jahr 2020) kann scheinen erträglich. Betrachtet man jedoch den Rückgang von 50 auf 25 BTC, der im November stattfand 28 2012, erschien für eine beträchtliche Anzahl von Mitgliedern der Bergbaugemeinschaft unangemessen. Abbildung 1 zeigt einen dramatischen Rückgang der hashRate des Netzwerks Ende November, genau zu dem Zeitpunkt es kam zu einer Halbierung. Dieses Ereignis hätte der perfekte Moment für die böswillige Person sein können beschrieben im Funktionsabschnitt proof-of-work zur Durchführung eines Double-Spending-Angriffs [36]. Abb. 1. Bitcoin hashKursdiagramm (Quelle: http://bitcoin.sipa.be) 2.4 Hartcodierte Konstanten Bitcoin hat viele fest codierte Grenzwerte, von denen einige natürliche Elemente des ursprünglichen Designs sind (z. B. Blockhäufigkeit, maximale Geldmenge, Anzahl der Bestätigungen) und andere scheinen künstliche Zwänge zu sein. Es sind nicht so sehr die Grenzen, sondern vielmehr die Unfähigkeit, sich schnell zu verändern 3 Hardware wie zuvor beschrieben. Nehmen wir an, dass die globale hash-Rate deutlich abnimmt, sogar für Einen Moment lang kann er nun seine Mining-Kraft nutzen, um die Kette zu verzweigen und doppelte Ausgaben zu tätigen. Wie wir sehen werden Später in diesem Artikel ist es nicht unwahrscheinlich, dass das zuvor beschriebene Ereignis eintritt. 2.3 Unregelmäßige Emission Bitcoin hat eine vorgegebene Emissionsrate: Jeder gelöste Block produziert eine feste Menge an Münzen. Etwa alle vier Jahre wird diese Belohnung halbiert. Die ursprüngliche Absicht bestand darin, eine zu schaffen begrenzte glatte Emission mit exponentiellem Abfall, aber tatsächlich haben wir eine stückweise lineare Emission Funktion, deren Haltepunkte Probleme in der Bitcoin-Infrastruktur verursachen können. Wenn der Haltepunkt erreicht wird, erhalten die Miner nur noch die Hälfte ihres vorherigen Wertes Belohnung. Der absolute Unterschied zwischen 12,5 und 6,25 BTC (prognostiziert für das Jahr 2020) kann scheinen erträglich. Betrachtet man jedoch den Rückgang von 50 auf 25 BTC, der im November stattfand 28 2012, erschien für eine beträchtliche Anzahl von Mitgliedern der Bergbaugemeinschaft unangemessen. Abbildung 1 zeigt einen dramatischen Rückgang der hashRate des Netzwerks Ende November, genau zu dem Zeitpunkt es kam zu einer Halbierung. Dieses Ereignis hätte der perfekte Moment für die böswillige Person sein können beschrieben im Funktionsabschnitt proof-of-work zur Durchführung eines Double-Spending-Angriffs [36]. Abb. 1. Bitcoin hashKursdiagramm (Quelle: http://bitcoin.sipa.be) 2.4 Hartcodierte Konstanten Bitcoin hat viele fest codierte Grenzwerte, von denen einige natürliche Elemente des ursprünglichen Designs sind (z. B. Blockhäufigkeit, maximale Geldmenge, Anzahl der Bestätigungen) und andere scheinen künstliche Zwänge zu sein. Es sind nicht so sehr die Grenzen, sondern vielmehr die Unfähigkeit, sich schnell zu verändern 3 6 Nennen wir es das, was es ist: einen Zombie-Angriff. Lassen Sie uns diskutieren, wie kontinuierlich die Emission sein kann im Zusammenhang mit „Eine CPU, eine Stimme“ in einem Zombie-Angriffsszenario. In einer Welt mit einer CPU und einer Stimme würde jedes Mobiltelefon und jedes Auto, wann immer es inaktiv ist, schürfen. Es wäre sehr, sehr einfach, haufenweise billige Hardware zu sammeln, um eine Mining-Farm zu erstellen, denn einfach In fast allem steckt eine CPU. Andererseits, zu diesem Zeitpunkt, die Anzahl der CPUs Ich würde meinen, dass es ziemlich erstaunlich wäre, wenn man einen 51-Prozent-Angriff starten müsste. Darüber hinaus Gerade weil es einfach wäre, billige Hardware zu sammeln, können wir vernünftigerweise erwarten, dass a Viele Leute fangen an, irgendetwas mit einer CPU zu horten. Das Wettrüsten in einer Welt mit einer CPU und einer Stimme ist notwendigerweise egalitärer als in einer ASIC-Welt. Daher eine Diskontinuität im Netzwerk Sicherheit aufgrund von Emissionsraten sollte in einer Welt mit einer CPU und einer Stimme WENIGER ein Problem darstellen. Es bleiben jedoch zwei Tatsachen bestehen: 1) Eine Diskontinuität der Emissionsrate kann zu einem Stottereffekt führen sowohl für die Wirtschaft als auch für die Netzwerksicherheit, was schlecht ist, und 2) obwohl es sich um einen 51-prozentigen Angriff handelt Fehler, die von jemandem durchgeführt werden, der billige Hardware sammelt, können auch bei Ein-CPU-Geräten auftreten-Abstimmung Welt, Es scheint, als ob es schwieriger sein sollte. Vermutlich besteht der Schutz davor darin, dass alle unehrlichen Akteure dies versuchen werden Gleichzeitig greifen wir auf den früheren Sicherheitsgedanken von Bitcoin zurück: „Wir fordern keine Unehrlichkeit.“ Fraktion soll mehr als 51 % des Netzwerks kontrollieren. Der Autor behauptet hier, dass ein Problem bei Bitcoin die Diskontinuität bei der Ausgabe von Münzen sei Die Rate könnte zu einem plötzlichen Rückgang der Netzwerkbeteiligung und damit der Netzwerksicherheit führen. So, Eine kontinuierliche, differenzierbare und gleichmäßige Münzausgaberate ist vorzuziehen. Der Autor hat nicht unbedingt Unrecht. Jede Art von plötzlichem Rückgang der Netzwerkbeteiligung kann dazu führen zu einem solchen Problem führen, und wenn wir eine Ursache dafür beseitigen können, sollten wir das tun. Trotzdem ist es so Es ist möglich, dass lange Zeiträume „relativ konstanter“ Münzausgabe mit plötzlichen Änderungen unterbrochen werden ist aus ökonomischer Sicht der ideale Weg. Ich bin kein Ökonom. Also vielleicht wir Wir müssen uns entscheiden, ob wir die Netzwerksicherheit gegen etwas Wirtschaftliches eintauschen – was steht hier? http://arxiv.org/abs/1402.2009wenn nötig, verursacht das die Hauptnachteile. Leider ist es schwer vorherzusagen, wann Konstanten müssen möglicherweise geändert werden, und ihre Ersetzung kann schreckliche Folgen haben. Ein gutes Beispiel für eine hartcodierte Grenzwertänderung, die katastrophale Folgen hat, ist der Block Größenbeschränkung auf 250 KB1 festgelegt. Dieses Limit reichte aus, um etwa 10.000 Standardtransaktionen aufzunehmen. In Anfang 2013 war diese Grenze fast erreicht und man einigte sich auf eine Erhöhung Grenze. Die Änderung wurde in Wallet-Version 0.8 implementiert und endete mit einer 24-Block-Chain-Aufteilung und ein erfolgreicher Double-Spend-Angriff [9]. Der Fehler lag zwar nicht im Protokoll Bitcoin, aber Vielmehr hätte es in der Datenbank-Engine leicht durch einen einfachen Stresstest erkannt werden können, wenn dies der Fall gewesen wäre keine künstlich eingeführte Blockgrößenbeschränkung. Konstanten fungieren auch als eine Art Zentralisierungspunkt. Trotz des Peer-to-Peer-Charakters von Bitcoin, eine überwältigende Mehrheit der Knoten verwendet den offiziellen Referenzclient [10], der von entwickelt wurde eine kleine Gruppe von Menschen. Diese Gruppe trifft die Entscheidung, Änderungen am Protokoll umzusetzen und die meisten Menschen akzeptieren diese Änderungen unabhängig von ihrer „Richtigkeit“. Einige Entscheidungen verursachten hitzige Diskussionen und sogar Boykottaufrufe [11], was darauf hindeutet, dass die Community und die Entwickler können in einigen wichtigen Punkten anderer Meinung sein. Daher erscheint es logisch, ein Protokoll zu haben mit vom Benutzer konfigurierbaren und selbstanpassenden Variablen als mögliche Möglichkeit, diese Probleme zu vermeiden. 2.5 Umfangreiche Skripte Das Skriptsystem in Bitcoin ist eine umfangreiche und komplexe Funktion. Es ermöglicht einem möglicherweise, etwas zu erschaffen ausgefeilte Transaktionen [12], aber einige seiner Funktionen sind aus Sicherheitsgründen deaktiviert und einige wurden noch nie verwendet [13]. Das Skript (einschließlich der Teile des Senders und des Empfängers) für die beliebteste Transaktion in Bitcoin sieht das so aus: OP DUP OP HASH160 OP EQUALVERIFY OP CHECKSIG. Das Skript ist 164 Bytes lang, wobei sein einziger Zweck darin besteht, zu überprüfen, ob der Empfänger über das Skript verfügt geheimer Schlüssel, der zur Überprüfung seiner Signatur erforderlich ist.

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