КриптоНота v2.0
Das hier präsentierte Paper ist das CryptoNote v2.0 Whitepaper von Nicolas van Saberhagen (2013), das die kryptografischen Grundlagen beschreibt, auf denen Monero aufbaut. Es handelt sich nicht um ein Monero-spezifisches Whitepaper – Monero startete 2014 als Fork der CryptoNote-Referenzimplementierung (Bytecoin) und hat sich seitdem erheblich über das ursprüngliche Protokoll hinaus weiterentwickelt.
Introduction
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 effectively proved that electronic cash can be as simple as paper money and as convenient as credit cards. Unfortunately, Bitcoin suffers from several deficiencies. For example, the system's distributed nature is inflexible, preventing the implementation of new features until almost all of the network users update their clients. Some critical flaws that cannot be fixed rapidly deter Bitcoin's widespread propagation. In such inflexible models, it is more efficient to roll-out a new project rather than perpetually fix the original project. In this paper, we study and propose solutions to the main deficiencies of Bitcoin. We believe that a system taking into account the solutions we propose will lead to a healthy competition among different electronic cash systems. We also propose our own electronic cash, "CryptoNote", a name emphasizing the next breakthrough in electronic cash.
Введение
«Bitcoin» [1] представляет собой успешную реализацию концепции электронных денег p2p. оба профессионалы и широкая общественность оценили удобное сочетание публичные транзакции и proof-of-work как модель доверия. Сегодня пользовательская база электронных денег растет устойчивыми темпами; клиентов привлекают низкие комиссии и обеспечиваемая анонимность электронными деньгами, и торговцы ценят ее прогнозируемую и децентрализованную эмиссию. Bitcoin имеет эффективно доказал, что электронные деньги могут быть такими же простыми, как бумажные деньги, и такими же удобными, как кредитные карты. К сожалению, Bitcoin имеет несколько недостатков. Например, распределенная система природа негибка и не позволяет внедрять новые функции до тех пор, пока почти все пользователи сети не обновят свои клиенты. Некоторые критические недостатки, которые невозможно быстро исправить, отпугивают Bitcoin. широкое распространение. В таких негибких моделях эффективнее развернуть новый проект. вместо того, чтобы постоянно исправлять первоначальный проект. В этой статье мы изучаем и предлагаем решения основных недостатков Bitcoin. Мы верим что система, учитывающая предлагаемые нами решения, приведет к здоровой конкуренции среди различных электронных денежных систем. Мы также предлагаем собственные электронные деньги «CryptoNote», имя, подчеркивающее следующий прорыв в области электронных денег.
Bitcoin Drawbacks and Possible Solutions
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 difference 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 effectively proved that electronic cash can be as simple as paper money and as convenient as credit cards. Unfortunately, Bitcoin suffers from several deficiencies. For example, the system’s distributed nature is inflexible, preventing the implementation of new features until almost all of the network users update their clients. Some critical flaws that cannot be fixed rapidly deter Bitcoin’s widespread propagation. In such inflexible models, it is more efficient to roll-out a new project rather than perpetually fix the original project. In this paper, we study and propose solutions to the main deficiencies of Bitcoin. We believe that a system taking into account the solutions we propose will lead to a healthy competition among different 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 difference 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 definitely 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 final recipient. Even if two participants exchange funds in an indirect way, a properly engineered path-finding method will reveal the origin and final 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 suffers 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 suffers 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 fixes, security fixes, 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 satisfied by the proof-of-work pricing function. Such function must not enable a network participant to have a significant 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 efficient 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 flawed 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 significant mining power by creating his own mining farm through the cheap 2 unambiguously traced to a unique origin and final recipient. Even if two participants exchange funds in an indirect way, a properly engineered path-finding method will reveal the origin and final 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 suffers 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 suffers 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 fixes, security fixes, 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 satisfied by the proof-of-work pricing function. Such function must not enable a network participant to have a significant 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 efficient 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 flawed 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 significant 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 figure 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 insufficient, 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 significant 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.
unambiguously traced to a unique origin and final recipient. Even if two participants exchange funds in an indirect way, a properly engineered path-finding method will reveal the origin and final 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 suffers 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 suffers 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 fixes, security fixes, 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 satisfied by the proof-of-work pricing function. Such function must not enable a network participant to have a significant 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 efficient 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 flawed 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 significant mining power by creating his own mining farm through the cheap 2 unambiguously traced to a unique origin and final recipient. Even if two participants exchange funds in an indirect way, a properly engineered path-finding method will reveal the origin and final 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 suffers 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 suffers 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 fixes, security fixes, 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 satisfied by the proof-of-work pricing function. Such function must not enable a network participant to have a significant 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 efficient 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 flawed 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 significant mining power by creating his own mining farm through the cheap 2 Comments on page 2
Bitcoin Недостатки и возможные решения
2 Bitcoin недостатки и некоторые возможные решения 2.1 Отслеживаемость транзакций Конфиденциальность и анонимность являются наиболее важными аспектами электронных денег. Одноранговые платежи стремятся быть скрытыми от взглядов третьих лиц, что является явной разницей по сравнению с традиционными банковское дело. В частности, Т. Окамото и К. Охта описали шесть критериев идеальных электронных денег: который включал «конфиденциальность: связь между пользователем и его покупками должна быть неотслеживаемой». кем угодно» [30]. Из их описания мы получили два свойства, которые полностью анонимны. Модель электронных денег должна удовлетворять требованиям, изложенным Окамото. и Охта: Неотслеживаемость: для каждой входящей транзакции все возможные отправители равновероятны. Несвязываемость: для любых двух исходящих транзакций невозможно доказать, что они были отправлены на тот же человек. К сожалению, Bitcoin не удовлетворяет требованию неотслеживаемости. Поскольку все транзакции, происходящие между участниками сети, являются публичными, любая транзакция может быть 1 КриптоНота v 2.0 Николас ван Саберхаген 17 октября 2013 г. 1 Введение «Bitcoin» [1] представляет собой успешную реализацию концепции электронных денег p2p. оба профессионалы и широкая общественность оценили удобное сочетание публичные транзакции и proof-of-work как модель доверия. Сегодня пользовательская база электронных денег растет устойчивыми темпами; клиентов привлекают низкие комиссии и обеспечиваемая анонимность электронными деньгами, и торговцы ценят ее прогнозируемую и децентрализованную эмиссию. Bitcoin имеет эффективно доказал, что электронные деньги могут быть такими же простыми, как бумажные деньги, и такими же удобными, как кредитные карты. К сожалению, Bitcoin имеет несколько недостатков. Например, распределенная система природа негибка и не позволяет внедрять новые функции до тех пор, пока почти все пользователи сети не обновят свои клиенты. Некоторые критические недостатки, которые невозможно быстро исправить, отпугивают Bitcoin. широкое распространение. В таких негибких моделях эффективнее развернуть новый проект. вместо того, чтобы постоянно исправлять первоначальный проект. В этой статье мы изучаем и предлагаем решения основных недостатков Bitcoin. Мы верим что система, учитывающая предлагаемые нами решения, приведет к здоровой конкуренции среди различных электронных денежных систем. Мы также предлагаем собственные электронные деньги «CryptoNote», имя, подчеркивающее следующий прорыв в области электронных денег. 2 Bitcoin недостатки и некоторые возможные решения 2.1 Отслеживаемость транзакций Конфиденциальность и анонимность являются наиболее важными аспектами электронных денег. Одноранговые платежи стремятся быть скрытыми от взглядов третьих лиц, что является явной разницей по сравнению с традиционными банковское дело. В частности, Т. Окамото и К. Охта описали шесть критериев идеальных электронных денег: который включал «конфиденциальность: связь между пользователем и его покупками должна быть неотслеживаемой». кем угодно» [30]. Из их описания мы получили два свойства, которые полностью анонимны. Модель электронных денег должна удовлетворять требованиям, изложенным Окамото. и Охта: Неотслеживаемость: для каждой входящей транзакции все возможные отправители равновероятны. Несвязываемость: для любых двух исходящих транзакций невозможно доказать, что они были отправлены на тот же человек. К сожалению, Bitcoin не удовлетворяет требованию неотслеживаемости. Поскольку все транзакции, происходящие между участниками сети, являются публичными, любая транзакция может быть 1 3 Bitcoin определенно не обеспечивает «неотслеживаемость». Когда я отправляю вам BTC, указывается кошелек, с которого он отправляется. безвозвратно проштамповано на blockchain. Вопроса о том, кто отправил эти средства, не возникает. потому что их может отправить только тот, кто знает секретные ключи.однозначно прослеживается уникальное происхождение и конечный получатель. Даже если два участника поменяются средства косвенным путем, правильно разработанный метод поиска пути выявит происхождение и конечный получатель. Также есть подозрение, что Bitcoin не удовлетворяет второму свойству. Некоторые исследователи заявил ([33, 35, 29, 31]), что тщательный анализ blockchain может выявить связь между пользователи сети Bitcoin и их транзакции. Хотя ряд методов оспаривается [25], есть подозрение, что из него можно извлечь много скрытой личной информации. общедоступная база данных. Неспособность Bitcoin удовлетворять двум свойствам, изложенным выше, приводит нас к выводу, что это не анонимная, а псевдоанонимная электронная кассовая система. Пользователи быстро развивались решения, позволяющие обойти этот недостаток. Двумя прямыми решениями были «услуги по отмыванию денег» [2] и развитие распределенных методов [3, 4]. Оба решения основаны на идее смешивания несколько публичных транзакций и отправка их через какой-то промежуточный адрес; что в свою очередь имеет тот недостаток, что требует доверенной третьей стороны. Недавно более креативную схему предложили И. Майерс с соавт. [28]: «Нулевая монета». Зерокойн использует криптографические односторонние аккумуляторы и доказательства с нулевым разглашением, которые позволяют пользователям «конвертируйте» биткойны в зерокоины и тратьте их, используя анонимное доказательство владения вместо явные цифровые подписи на основе открытого ключа. Однако такие доказательства знаний имеют постоянную но неудобный размер - около 30кб (исходя из сегодняшних лимитов Bitcoin), что делает предложение непрактично. Авторы признают, что протокол вряд ли когда-либо будет принят большинством стран. Bitcoin пользователей [5]. 2.2 Функция proof-of-work Создатель Bitcoin Сатоши Накамото описал алгоритм принятия решений большинством как «один ЦП-один голос» и использовал функцию ценообразования с привязкой к ЦП (двойной SHA-256) для своего proof-of-work схема. Поскольку пользователи голосуют за единый заказ истории транзакций [1], разумность и последовательность этого процесса является важнейшим условием для всей системы. Безопасность этой модели имеет два недостатка. Во-первых, для этого требуется 51% ресурсов сети. мощность майнинга должна находиться под контролем честных пользователей. Во-вторых, прогресс системы (исправление ошибок, исправления безопасности и т. д.) требуют, чтобы подавляющее большинство пользователей поддерживало и соглашалось с изменения (это происходит, когда пользователи обновляют программное обеспечение своего кошелька) [6].Наконец, это же голосование Механизм также используется для коллективных опросов о реализации некоторых функций [7]. Это позволяет нам предположить, каким свойствам должен удовлетворять proof-of-work. функция ценообразования. Такая функция не должна позволять участнику сети иметь существенное влияние. преимущество перед другим участником; это требует паритета между общим оборудованием и высоким Стоимость нестандартных устройств. Из недавних примеров [8] мы видим, что используемая функция SHA-256 в архитектуре Bitcoin этим свойством не обладает, поскольку майнинг становится более эффективным на Графические процессоры и устройства ASIC по сравнению с высокопроизводительными процессорами. Таким образом, Bitcoin создает благоприятные условия для большого разрыва между количеством голосов участников, так как это нарушает принцип «один процессор — один голос», поскольку владельцы графических процессоров и ASIC обладают гораздо большее количество голосов по сравнению с владельцами процессоров. Это классический пример Принцип Парето, согласно которому 20% участников системы контролируют более 80% голосов. Можно утверждать, что такое неравенство не имеет отношения к безопасности сети, поскольку оно не небольшое количество участников, контролирующих большинство голосов, но честность этих участников, что имеет значение. Однако такой аргумент несколько ошибочен, поскольку он скорее является вероятность появления дешевого специализированного оборудования, а не честность участников, которая представляет угрозу. Чтобы продемонстрировать это, возьмем следующий пример. Предположим, злонамеренный человек получает значительную майнинговую мощь, создавая свою собственную майнинг-ферму за счет дешевых 2 однозначно прослеживается уникальное происхождение и конечный получатель. Даже если два участника поменяются средства косвенным путем, правильно разработанный метод поиска пути выявит происхождение и конечный получатель. Также есть подозрение, что Bitcoin не удовлетворяет второму свойству. Некоторые исследователи заявил ([33, 35, 29, 31]), что тщательный анализ blockchain может выявить связь между пользователи сети Bitcoin и их транзакции. Хотя ряд методов доспаривается [25], есть подозрение, что много скрытой личной информации может быть извлечено из общедоступная база данных. Неспособность Bitcoin удовлетворять двум свойствам, изложенным выше, приводит нас к выводу, что это не анонимная, а псевдоанонимная электронная кассовая система. Пользователи быстро развивались решения, позволяющие обойти этот недостаток. Двумя прямыми решениями были «услуги по отмыванию денег» [2] и развитие распределенных методов [3, 4]. Оба решения основаны на идее смешивания несколько публичных транзакций и отправка их через какой-то промежуточный адрес; что в свою очередь имеет тот недостаток, что требует доверенной третьей стороны. Недавно более креативную схему предложили И. Майерс с соавт. [28]: «Нулевая монета». Зерокойн использует криптографические односторонние аккумуляторы и доказательства с нулевым разглашением, которые позволяют пользователям «конвертируйте» биткойны в зерокоины и тратьте их, используя анонимное доказательство владения вместо явные цифровые подписи на основе открытого ключа. Однако такие доказательства знаний имеют постоянную но неудобный размер - около 30кб (исходя из сегодняшних лимитов Bitcoin), что делает предложение непрактично. Авторы признают, что протокол вряд ли когда-либо будет принят большинством стран. Bitcoin пользователей [5]. 2.2 Функция proof-of-work Создатель Bitcoin Сатоши Накамото описал алгоритм принятия решений большинством как «один ЦП-один голос» и использовал функцию ценообразования с привязкой к ЦП (двойной SHA-256) для своего proof-of-work схема. Поскольку пользователи голосуют за единый заказ истории транзакций [1], разумность и последовательность этого процесса является важнейшим условием для всей системы. Безопасность этой модели имеет два недостатка. Во-первых, для этого требуется 51% ресурсов сети. мощность майнинга должна находиться под контролем честных пользователей. Во-вторых, прогресс системы (исправление ошибок, исправления безопасности и т. д.) требуют, чтобы подавляющее большинство пользователей поддерживало и соглашалось с изменения (это происходит, когда пользователи обновляют программное обеспечение своего кошелька) [6].Наконец, это же голосование Механизм также используется для коллективных опросов о реализации некоторых функций [7]. Это позволяет нам предположить, каким свойствам должен удовлетворять proof-of-work. функция ценообразования. Такая функция не должна позволять участнику сети иметь существенное влияние. преимущество перед другим участником; это требует паритета между общим оборудованием и высоким Стоимость нестандартных устройств. Из недавних примеров [8] мы видим, что используемая функция SHA-256 в архитектуре Bitcoin этим свойством не обладает, поскольку майнинг становится более эффективным на Графические процессоры и устройства ASIC по сравнению с высокопроизводительными процессорами. Таким образом, Bitcoin создает благоприятные условия для большого разрыва между количеством голосов участников, так как это нарушает принцип «один процессор — один голос», поскольку владельцы графических процессоров и ASIC обладают гораздо большее количество голосов по сравнению с владельцами процессоров. Это классический пример Принцип Парето, согласно которому 20% участников системы контролируют более 80% голосов. Можно утверждать, что такое неравенство не имеет отношения к безопасности сети, поскольку оно не небольшое количество участников, контролирующих большинство голосов, но честность этих участников, что имеет значение. Однако такой аргумент несколько ошибочен, поскольку он скорее является вероятность появления дешевого специализированного оборудования, а не честность участников, которая представляет угрозу. Чтобы продемонстрировать это, возьмем следующий пример. Предположим, злонамеренный человек получает значительную майнинговую мощь, создавая свою собственную майнинг-ферму за счет дешевых 2 4 Предположительно, если каждый пользователь сохранит свою анонимность, всегда генерируя новый адрес за КАЖДЫЙ полученный платеж (что абсурдно, но технически «правильный» способ сделать это), и если бы каждый пользователь поддерживал анонимность всех остальных, настаивая на том, чтобы они никогда не отправляли средства на один и тот же адрес BTC дважды, то Bitcoin всё равно лишь случайно передаст тест на несвязность. Почему? Данные о потребителях можно использовать для того, чтобы постоянно получать поразительные сведения о людях. См., например, http://www.applieddatalabs.com/content/target-knows-it-shows. Теперь представьте, что это произойдет через 20 лет, и представьте, что Target не просто знал о ваших покупательских привычках в Target, но они добыли blockchain для ВСЕХ ВАШИ ЛИЧНЫЕ ПОКУПКИ С ВАШИМ КОШЕЛЬКОМ COINBASE В ПРОШЛОМ ДВЕНАДЦАТЬ ЛЕТ. Они скажут: «Эй, приятель, возможно, ты захочешь сегодня вечером купить лекарство от кашля, но ты не будешь». завтра почувствуй себя хорошо». Это может быть не так, если многосторонняя сортировка используется правильно. См., например, этосообщение в блоге: http://blog.ezyang.com/2012/07/secure-multiparty-bitcoin-anonymization/ Я не совсем уверен в математических расчетах, но... по одной статье за раз, верно? Требуется цитирование. Хотя протокол Zerocoin (автономный) может оказаться недостаточным, протокол Zerocash Протокол, похоже, реализовал транзакции размером 1 КБ. Этот проект поддерживается конечно, американские и израильские военные, так что кто знает, насколько он надежен. С другой стороны С другой стороны, никто не хочет иметь возможность тратить средства без надзора больше, чем военные. http://zerocash-project.org/ Я не уверен... см., например, http://fc14.ifca.ai/bitcoin/papers/bitcoin14_submission_12.pdf Цитирую разработчика Cryptonote Мориса Планка (предположительно псевдоним) из cryptonote форум: «Зерокоин, Зеркэш. Это самая передовая технология, надо признать. Да, цитата выше взято из анализа предыдущей версии протокола. Насколько мне известно, это не 288, а 384 байта, но в любом случае это хорошая новость. Они использовали совершенно новую технологию под названием SNARK, у которой есть определенные недостатки: например, большая исходная база публичных параметров, необходимых для создания подписи (более 1 ГБ) и значительное время, необходимое для создания транзакции (более минуты). Наконец, они используют молодая криптовалюта, о которой я упомянул как о спорной идее: https://forum.cryptonote.org/viewtopic.php?f= » — Морис П. Четверг, 3 апреля 2014 г., 19:56 Функция, выполняемая в ЦП и не подходящая для графического процессора, FPGA или ASIC. расчет. «Загадка», используемая в proof-of-work, называется функцией ценообразования, функцией затрат или функция головоломки.
однозначно прослеживается уникальное происхождение и конечный получатель. Даже если два участника поменяются средства косвенным путем, правильно разработанный метод поиска пути выявит происхождение и конечный получатель. Также есть подозрение, что Bitcoin не удовлетворяет второму свойству. Некоторые исследователи заявил ([33, 35, 29, 31]), что тщательный анализ blockchain может выявить связь между пользователи сети Bitcoin и их транзакции. Хотя ряд методов оспариваемый [25], есть подозрение, что из него можно извлечь много скрытой личной информации. общедоступная база данных. Неспособность Bitcoin удовлетворить двум свойствам, изложенным выше, приводит нас к выводу, что это не анонимная, а псевдоанонимная электронная кассовая система. Пользователи быстро развивались решения, позволяющие обойти этот недостаток. Двумя прямыми решениями были «услуги по отмыванию денег» [2] и развитие распределенных методов [3, 4]. Оба решения основаны на идее смешивания несколько публичных транзакций и отправка их через какой-то промежуточный адрес; что в свою очередь имеет тот недостаток, что требует доверенной третьей стороны. Недавно более креативную схему предложили И. Майерс с соавт. [28]: «Нулевая монета». Зерокойн использует криптографические односторонние аккумуляторы и доказательства с нулевым разглашением, которые позволяют пользователям «конвертируйте» биткойны в зерокоины и тратьте их, используя анонимное доказательство владения вместо явные цифровые подписи на основе открытого ключа. Однако такие доказательства знаний имеют постоянную но неудобный размер - около 30кб (исходя из сегодняшних лимитов Bitcoin), что делает предложение непрактично. Авторы признают, что протокол вряд ли когда-либо будет принят большинством стран. Bitcoin пользователей [5]. 2.2 Функция proof-of-work Создатель Bitcoin Сатоши Накамото описал алгоритм принятия решений большинством голосов как «один ЦП-один голос» и использовал функцию ценообразования с привязкой к ЦП (двойной SHA-256) для своего proof-of-work схема. Поскольку пользователи голосуют за единый заказ истории транзакций [1], разумность и последовательность этого процесса является важнейшим условием для всей системы. Безопасность этой модели имеет два недостатка. Во-первых, для этого требуется 51% ресурсов сети. мощность майнинга должна находиться под контролем честных пользователей. Во-вторых, прогресс системы (исправление ошибок, исправления безопасности и т. д.) требуют, чтобы подавляющее большинство пользователей поддерживало и соглашалось с изменения (это происходит, когда пользователи обновляют программное обеспечение своего кошелька) [6].Наконец то же самое голосование Механизм также используется для коллективных опросов о реализации некоторых функций [7]. Это позволяет нам предположить, каким свойствам должен удовлетворять proof-of-work. функция ценообразования. Такая функция не должна позволять участнику сети иметь существенное влияние. преимущество перед другим участником; это требует паритета между общим оборудованием и высоким Стоимость нестандартных устройств. Из недавних примеров [8] мы видим, что используемая функция SHA-256 в архитектуре Bitcoin этим свойством не обладает, поскольку майнинг становится более эффективным на Графические процессоры и устройства ASIC по сравнению с высокопроизводительными процессорами. Следовательно, Bitcoin создает благоприятные условия для большого разрыва между количеством голосов участников, так как это нарушает принцип «один процессор — один голос», поскольку владельцы графических процессоров и ASIC обладают гораздо большее количество голосов по сравнению с владельцами процессоров. Это классический пример Принцип Парето, согласно которому 20% участников системы контролируют более 80% голосов. Можно утверждать, что такое неравенство не имеет отношения к безопасности сети, поскольку оно не небольшое количество участников, контролирующих большинство голосов, но честность этих участников, что имеет значение. Однако такой аргумент несколько ошибочен, поскольку он скорее является вероятность появления дешевого специализированного оборудования, а не честность участников, которая представляет угрозу. Чтобы продемонстрировать это, возьмем следующий пример. Предположим, злонамеренный человек получает значительную майнинговую мощь, создавая свою собственную майнинг-ферму за счет дешевых 2 однозначно прослеживается уникальное происхождение и конечный получатель. Даже если два участника поменяются средства косвенным путем, правильно разработанный метод поиска пути выявит происхождение и конечный получатель. Также есть подозрение, что Bitcoin не удовлетворяет второму свойству. Некоторые исследователи заявил ([33, 35, 29, 31]), что тщательный анализ blockchain может выявить связь между пользователи сети Bitcoin и их транзакции. Хотя ряд методов доспаривается [25], есть подозрение, что много скрытой личной информации может быть извлечено из общедоступная база данных. Неспособность Bitcoin удовлетворять двум свойствам, изложенным выше, приводит нас к выводу, что это не анонимная, а псевдоанонимная электронная кассовая система. Пользователи быстро развивались решения, позволяющие обойти этот недостаток. Двумя прямыми решениями были «услуги по отмыванию денег» [2] и развитие распределенных методов [3, 4]. Оба решения основаны на идее смешивания несколько публичных транзакций и отправка их через какой-то промежуточный адрес; что в свою очередь имеет тот недостаток, что требует доверенной третьей стороны. Недавно более креативную схему предложили И. Майерс с соавт. [28]: «Нулевая монета». Зерокойн использует криптографические односторонние аккумуляторы и доказательства с нулевым разглашением, которые позволяют пользователям «конвертируйте» биткойны в зерокоины и тратьте их, используя анонимное доказательство владения вместо явные цифровые подписи на основе открытого ключа. Однако такие доказательства знаний имеют постоянную но неудобный размер - около 30кб (исходя из сегодняшних лимитов Bitcoin), что делает предложение непрактично. Авторы признают, что протокол вряд ли когда-либо будет принят большинством стран. Bitcoin пользователей [5]. 2.2 Функция proof-of-work Создатель Bitcoin Сатоши Накамото описал алгоритм принятия решений большинством как «один ЦП-один голос» и использовал функцию ценообразования с привязкой к ЦП (двойной SHA-256) для своего proof-of-work схема. Поскольку пользователи голосуют за единый заказ истории транзакций [1], разумность и последовательность этого процесса является важнейшим условием для всей системы. Безопасность этой модели имеет два недостатка. Во-первых, для этого требуется 51% ресурсов сети. мощность майнинга должна находиться под контролем честных пользователей. Во-вторых, прогресс системы (исправление ошибок, исправления безопасности и т. д.) требуют, чтобы подавляющее большинство пользователей поддерживало и соглашалось с изменения (это происходит, когда пользователи обновляют программное обеспечение своего кошелька) [6].Наконец то же самое голосование Механизм также используется для коллективных опросов о реализации некоторых функций [7]. Это позволяет нам предположить, каким свойствам должен удовлетворять proof-of-work. функция ценообразования. Такая функция не должна позволять участнику сети иметь существенное влияние. преимущество перед другим участником; это требует паритета между общим оборудованием и высоким Стоимость нестандартных устройств. Из недавних примеров [8] мы видим, что используемая функция SHA-256 в архитектуре Bitcoin этим свойством не обладает, поскольку майнинг становится более эффективным на Графические процессоры и устройства ASIC по сравнению с высокопроизводительными процессорами. Таким образом, Bitcoin создает благоприятные условия для большого разрыва между количеством голосов участников, так как это нарушает принцип «один процессор — один голос», поскольку владельцы графических процессоров и ASIC обладают гораздо большее количество голосов по сравнению с владельцами процессоров. Это классический пример Принцип Парето, согласно которому 20% участников системы контролируют более 80% голосов. Можно утверждать, что такое неравенство не имеет отношения к безопасности сети, поскольку оно не небольшое количество участников, контролирующих большинство голосов, но честность этих участников, что имеет значение. Однако такой аргумент несколько ошибочен, поскольку он скорее является вероятность появления дешевого специализированного оборудования, а не честность участников, которая представляет угрозу. Чтобы продемонстрировать это, возьмем следующий пример. Предположим, злонамеренный человек получает значительную майнинговую мощь, создавая свою собственную майнинг-ферму за счет дешевых 2 Комментарии на странице 2
The CryptoNote Technology
The CryptoNote Technology
Now that we have covered the limitations of the Bitcoin technology, we will concentrate on presenting the features of CryptoNote.
Технология CryptoNote
Теперь, когда мы рассмотрели ограничения технологии PH_0000, мы сосредоточимся на представление возможностей CryptoNote.
Untraceable Transactions
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 traffic 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 verification 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 sufficient 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 artificially 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 official 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-configurable 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:
key, but the keys of all the users of his group. A verifier 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 modifications 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 fixed 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 modification 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 Definitions 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 verifier 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 modifications 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 fixed 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 modification 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 Definitions 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 figure 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 definition 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 verifier 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 modifications 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 fixed 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 modification 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 Definitions 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 verifier 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 modifications 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 fixed 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 modification 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 Definitions 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 different 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 different; 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 verifier 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 modifications 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 fixed 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 modification 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 Definitions 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 verifier 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 modifications 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 fixed 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 modification 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 Definitions 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 officially in the blockchain. Now, what do I do? Should I first 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 first copy first, and hence any further copy is illegitimate. Thus I proceed to simply delete all instances after the first 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 fine, but if there are known facts about this large prime, that could influence our choice. Different variants of cryptonote could choose different values of ell, but there is no discussion in this paper about how that choice will affect 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 different 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 different 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 identifier 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 different transactions which cannot be proven to belong to the same owner he should generate all the different 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 specific address or link two addresses together. 6 private user key is a pair \((a, b)\) of two different 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 different 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 identifier 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 different transactions which cannot be proven to belong to the same owner he should generate all the different 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 specific address or link two addresses together. 6 11 So this is like Bitcoin, but with infinite, 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 first 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 find 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 different 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 different 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 identifier 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 different transactions which cannot be proven to belong to the same owner he should generate all the different 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 specific address or link two addresses together. 6 private user key is a pair \((a, b)\) of two different 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 different 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 identifier 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 different transactions which cannot be proven to belong to the same owner he should generate all the different 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 specific 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 offthe 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 fingerprints on the PO Box or actually use it, just trade the box filled 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 infinite 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 Diffie-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 different 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 Diffie-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 Diffie-Hellman exchange) somewhere into the transaction. Note that she can create other outputs with unique public keys: different recipients’ keys \((A_i, B_i)\) imply different \(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 Diffie-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 different 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 Diffie-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 Diffie-Hellman exchange) somewhere into the transaction. Note that she can create other outputs with unique public keys: different recipients’ keys \((A_i, B_i)\) imply different \(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 Diffie-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. Diffie 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 offall 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 Diffie-Hellman exchange. More secure versions exist. But most versions work because integer factorization and discrete logarithms are difficult, 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/Diffie%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 stuff, 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 sufficiently rigorous if the framework under which they work is as loosely defined 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 Diffie-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 different 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 Diffie-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 Diffie-Hellman exchange) somewhere into the transaction. Note that she can create other outputs with unique public keys: different recipients’ keys \((A_i, B_i)\) imply different \(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 Diffie-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 different 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 Diffie-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 Diffie-Hellman exchange) somewhere into the transaction. Note that she can create other outputs with unique public keys: different recipients’ keys \((A_i, B_i)\) imply different \(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 specifically 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 rifling 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 deficiency lies in using a different signature type than those currently used in electronic cash systems. We will first 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 deficiency lies in using a different signature type than those currently used in electronic cash systems. We will first 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 sufficient 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 specifically 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 off, 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 deficiency lies in using a different signature type than those currently used in electronic cash systems. We will first 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 deficiency lies in using a different signature type than those currently used in electronic cash systems. We will first 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 sufficient?" 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 fixed 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 different 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 different 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 flip 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-flipping experiment until I’m satisfied 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 definition.
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 stuffis 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 Diffie-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, defined. 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 offthe hash, and that gives us c_s. This seems to be what "should" be happening given my intuition, and matches the verification 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
\[\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 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
\[\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 verifies that c_s = c - sum_i neq s c_i on the previous page. At first 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 finally 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
\[\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 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
\[\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 Diffie-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 profitable 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 first introduced by Abadi et al and were defined 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 profitable 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 first introduced by Abadi et al and were defined 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 find 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 fixed 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 difficult; constructing a hash function satisfying these constraints seems to be more difficult. 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 effective 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 effective and continues to leave the possibility of creating relatively cheap but highly-efficient mining devices. Moreover, the scrypt construction itself allows a linear trade-offbetween 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 fits 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. Significant 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 flood of fake objects with arbitrary work data (nonce values). 12 proposed the most effective 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 effective and continues to leave the possibility of creating relatively cheap but highly-efficient mining devices. Moreover, the scrypt construction itself allows a linear trade-offbetween 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 fits 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. Significant 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 flood 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 Difficulty CryptoNote contains a targeting algorithm which changes the difficulty 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 difficulty. 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 difficulty 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-offthe 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-offbetween balancing the costs and profit 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 flooded 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 sufficient fee. 6.2.3 Excess size penalty A miner still has the ability to stuffa 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 Difficulty CryptoNote contains a targeting algorithm which changes the difficulty 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 difficulty. 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 difficulty 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-offthe 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-offbetween balancing the costs and profit 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 flooded 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 sufficient fee. 6.2.3 Excess size penalty A miner still has the ability to stuffa 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 sufficient to get all coins. Instamine. On the other hand, if this is supposed to be proportional in some way to the difference 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 difficulty occurs every block then an attacker could have a very large farm of machines mine on and offin carefully chosen time intervals. This could cause a chaotic explosion (or crash to zero) in difficulty, if difficulty 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 difficulty isn’t necessarily a problem unless it results in oscillations of ostensible supply of coins - and having a very rapidly changing difficulty 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 off. It may be a better idea to simply adjust the difficulty 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 first 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 difficulty 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, offfor 2, on for 6, offfor 2, or something like that. Just switch to another coin for a few hours, wait for difficulty to drop, then hop back on in order to gain those few extra blocks of profitability 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 Difficulty CryptoNote contains a targeting algorithm which changes the difficulty 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 difficulty. 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 difficulty 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-offthe 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-offbetween balancing the costs and profit 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 flooded 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 sufficient fee. 6.2.3 Excess size penalty A miner still has the ability to stuffa 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 Difficulty CryptoNote contains a targeting algorithm which changes the difficulty 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 difficulty. 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 difficulty 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-offthe 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-offbetween balancing the costs and profit 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 flooded 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 sufficient fee. 6.2.3 Excess size penalty A miner still has the ability to stuffa 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 difficulty 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 finances, 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 finances 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 define. 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 traffic 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 different 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 Difficulty CryptoNote contains a targeting algorithm which changes the difficulty 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 difficulty. 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 difficulty 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-offthe 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-offbetween balancing the costs and profit 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 flooded 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 sufficient fee. 6.2.3 Excess size penalty A miner still has the ability to stuffa 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 Difficulty CryptoNote contains a targeting algorithm which changes the difficulty 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 difficulty. 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 difficulty 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-offthe 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-offbetween balancing the costs and profit 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 flooded 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 sufficient fee. 6.2.3 Excess size penalty A miner still has the ability to stuffa 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 profit 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 specifies 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 five 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 verification 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 verifier 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 flaws 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 profit 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 specifies 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 five 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 verification 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 verifier 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 flaws 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 figure 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 infinity. 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
Неотслеживаемые транзакции
В этом разделе мы предлагаем схему полностью анонимных транзакций, обеспечивающую как неотслеживаемость, так и невозможность отслеживания.
и условия несвязности. Важной особенностью нашего решения является его автономность: отправитель
не обязан сотрудничать с другими пользователями или доверенной третьей стороной для совершения своих транзакций;
следовательно, каждый участник производит прикрывающий трафик независимо.
4.1
Обзор литературы
Наша схема основана на криптографическом примитиве, называемом групповой подписью. Впервые представлено
Д. Чаум и Э. ван Хейст [19], позволяет пользователю подписать свое сообщение от имени группы.
После подписания сообщения пользователь предоставляет (в целях проверки) не свой единственный публичный
1Это так называемый «мягкий лимит» — ограничение эталонного клиента на создание новых блоков. Жесткий максимум
возможный размер блока составлял 1 МБ
4
их при необходимости, что вызывает основные недостатки. К сожалению, трудно предсказать, когда
константы, возможно, придется изменить, а их замена может привести к ужасным последствиям.
Хорошим примером жестко запрограммированного изменения лимита, приводящего к катастрофическим последствиям, является блок
ограничение размера установлено на 250 КБ1. Этого лимита было достаточно для проведения около 10 000 стандартных транзакций. В
В начале 2013 года этот предел был почти достигнут, и было достигнуто соглашение об увеличении
предел. Изменение было реализовано в версии кошелька 0.8 и закончилось разделением цепочки на 24 блока.
и успешная атака двойной траты [9]. Хотя ошибка была не в протоколе Bitcoin, а
скорее, в ядре базы данных его можно было бы легко обнаружить с помощью простого стресс-теста, если бы было
отсутствие искусственно введенного ограничения размера блока.
Константы также действуют как форма точки централизации.
Несмотря на одноранговый характер
Bitcoin, подавляющее большинство узлов используют официальный эталонный клиент [10], разработанный
небольшая группа людей. Эта группа принимает решение о внесении изменений в протокол.
и большинство людей принимают эти изменения независимо от их «правильности». Некоторые решения вызвали
бурные дискуссии и даже призывы к бойкоту [11], что свидетельствует о том, что сообщество и
разработчики могут расходиться во мнениях по некоторым важным моментам. Поэтому кажется логичным иметь протокол
с настраиваемыми пользователем и самонастраивающимися переменными как возможный способ избежать этих проблем.
2,5
Громоздкие скрипты
Система сценариев в Bitcoin — сложная и тяжелая функция. Потенциально это позволяет создавать
сложные транзакции [12], но некоторые из его функций отключены из соображений безопасности и
некоторые даже никогда не использовались [13]. Скрипт (включая часть отправителя и получателя)
для самой популярной транзакции в Bitcoin выглядит так:
ключ, а ключи всех пользователей его группы. Подтверждающее лицо убеждено, что настоящим подписывающим лицом является член группы, но не может однозначно идентифицировать подписавшего. Исходный протокол требовал доверенной третьей стороны (называемой менеджером группы), и он был единственный, кто мог отследить подписавшего. Следующая версия, названная кольцевой подписью, представила Ривест и др. в [34] была автономная схема без менеджера группы и анонимности. отзыв. Позднее появились различные модификации этой схемы: связываемая кольцевая подпись [26, 27, 17] позволило определить, были ли две подписи созданы одним и тем же членом группы, прослеживаемые Кольцевая подпись [24, 23] ограничивала чрезмерную анонимность, предоставляя возможность отследить подписавшего два сообщения относительно одной и той же метаинформации (или «тега» в терминах [24]). Подобная криптографическая конструкция известна также как подпись специальной группы [16, 38]. Это подчеркивает произвольное формирование группы, тогда как схемы групповой/кольцевой подписи скорее предполагают фиксированный набор членов. По большей части наше решение основано на работе «Прослеживаемая кольцевая подпись» Э. Фудзисаки. и К. Сузуки [24]. Чтобы отличить оригинальный алгоритм от нашей модификации, будем назовем последнюю одноразовой кольцевой подписью, подчеркивая возможность пользователя создать только одну действительную подпись. подпись под своим секретным ключом. Мы ослабили свойство прослеживаемости и сохранили возможность связывания. только для обеспечения одноразовости: открытый ключ может появляться во многих иностранных проверочных наборах, а закрытый ключ можно использовать для создания уникальной анонимной подписи. В случае двойной траты попытка эти две подписи будут связаны друг с другом, но раскрытие подписавшего не требуется для наших целей. 4.2 Определения 4.2.1 Параметры эллиптической кривой В качестве базового алгоритма подписи мы выбрали быструю схему EdDSA, которая разработана и реализованный Д.Дж. Бернштейн и др. [18]. Как и ECDSA Bitcoin, он основан на эллиптической кривой. задача дискретного логарифма, поэтому нашу схему можно будет применить и к Bitcoin в будущем. Общие параметры: q: простое число; q = 2255 −19; d: элемент Fq; д = -121665/121666; E: уравнение эллиптической кривой; −x2 + y2 = 1 + dx2y2; G: базовая точка; Г = (х, −4/5); l: простой порядок базовой точки; л = 2252 + 27742317777372353535851937790883648493; \(H_s\): криптографическая hash функция \(\{0, 1\}^* \to \mathbb{F}_q\); \(H_p\): детерминированная hash функция \(E(\mathbb{F}_q) \to E(\mathbb{F}_q)\). 4.2.2 Терминология Повышенная конфиденциальность требует новой терминологии, которую не следует путать с сущностями Bitcoin. приватный ec-ключ — стандартный приватный ключ в виде эллиптической кривой: число \(a \in [1, l - 1]\); публичный ec-ключ — стандартный публичный ключ эллиптической кривой: точка A = aG; одноразовая пара ключей — пара приватных и публичных электронных ключей; 5 ключ, а ключи всех пользователей его группы. Подтверждающее лицо убеждено, что настоящим подписывающим лицом является член группы, но не может однозначно идентифицировать подписавшего. Исходный протокол требовал доверенной третьей стороны (называемой менеджером группы), и он был единственный, кто мог отследить подписавшего. Следующая версия, названная кольцевой подписью, представила Ривест и др. в [34] была автономная схема без менеджера группы и анонимности. отзыв. Позднее появились различные модификации этой схемы: связываемая кольцевая подпись [26, 27, 17] позволило определить, были ли две подписи созданы одним и тем же членом группы, прослеживаемые Кольцевая подпись [24, 23] ограничивала чрезмерную анонимность, предоставляя возможность отследить подписавшего два сообщения относительно одной и той же метаинформации (или «тега» в терминах [24]). Подобная криптографическая конструкция известна также как подпись специальной группы [16, 38]. Это подчеркивает произвольное формирование группы, тогда как схемы групповой/кольцевой подписи скорее предполагают фиксированный набор членов. По большей части наше решение основано на работе «Прослеживаемая кольцевая подпись» Э. Фудзисаки. и К. Сузуки [24]. Чтобы отличить оригинальный алгоритм от нашей модификации, будем назовем последнюю одноразовой кольцевой подписью, подчеркивая возможность пользователя создать только одну действительную подпись. подпись под своим секретным ключом. Мы ослабили свойство прослеживаемости и сохранили возможность связывания. только для обеспечения одноразовости: открытый ключ может появляться во многих иностранных проверочных наборах, а закрытый ключ можно использовать для создания уникальной анонимной подписи. В случае двойной траты попытка эти две подписи будут связаны друг с другом, но раскрытие подписавшего не требуется для наших целей. 4.2 Определения 4.2.1 Параметры эллиптической кривой В качестве базового алгоритма подписи мы выбралие использовать быструю схему EdDSA, которая разработана и реализованный Д.Дж. Бернштейн и др. [18]. Как и ECDSA Bitcoin, он основан на эллиптической кривой. задача дискретного логарифма, поэтому нашу схему можно будет применить и к Bitcoin в будущем. Общие параметры: q: простое число; q = 2255 −19; d: элемент Fq; д = -121665/121666; E: уравнение эллиптической кривой; −x2 + y2 = 1 + dx2y2; G: базовая точка; Г = (х, −4/5); l: простой порядок базовой точки; л = 2252 + 27742317777372353535851937790883648493; \(H_s\): криптографическая hash функция \(\{0, 1\}^* \to \mathbb{F}_q\); \(H_p\): детерминированная hash функция \(E(\mathbb{F}_q) \to E(\mathbb{F}_q)\). 4.2.2 Терминология Повышенная конфиденциальность требует новой терминологии, которую не следует путать с сущностями Bitcoin. приватный ec-ключ — стандартный приватный ключ в виде эллиптической кривой: число \(a \in [1, l - 1]\); публичный ec-ключ — стандартный публичный ключ эллиптической кривой: точка A = aG; одноразовая пара ключей — пара приватных и публичных электронных ключей; 5 8 Кольцевая подпись работает следующим образом: Алекс хочет передать WikiLeaks сообщение о своем работодателе. У каждого сотрудника в ее компании есть пара частного/открытого ключей (Ri, Ui). Она сочиняет ее подпись с набором входных данных в качестве ее сообщения, m, ее секретный ключ, Ri, и ВСЕХ открытые ключи (Ui;i=1...n). Любой (не зная приватных ключей) может легко убедиться в том, что какая-то пара (Rj, Uj), должно быть, использовалась для создания подписи... кто-то, кто работает для работодателя Алекса... но, по сути, это случайная догадка, чтобы выяснить, кто бы это мог быть. 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 Обратите внимание, что описанная здесь связываемая кольцевая подпись является своего рода противоположностью «несвязываемой». описано выше. Здесь мы перехватываем два сообщения и можем определить, одно и то же ли их послала партия, хотя мы все равно не сможем определить, кто эта партия.
определение «несвязываемого», используемое для создания Cryptonote, означает, что мы не можем определить, является ли их получает одна и та же сторона. Следовательно, на самом деле здесь происходят ЧЕТЫРЕ вещи. Система может быть связной или несвязываемый, в зависимости от того, можно ли определить, является ли отправитель два сообщения одинаковы (независимо от того, требует ли это отмены анонимности). И система может быть несвязной или несвязной, в зависимости от того, возможно ли ее определить, является ли получатель двух сообщений одним и тем же (независимо от того, для этого требуется отзыв анонимности). Пожалуйста, не обвиняйте меня за эту ужасную терминологию. Теоретикам графов, вероятно, следует доволен. Некоторым из вас может быть удобнее использовать «связь с получателем», а не «связь с отправителем». http://link.springer.com/chapter/10.1007/978-3-540-71677-8_13 Когда я это прочитал, мне это показалось глупой особенностью. Потом я прочитал, что это может быть особенность для электронное голосование, и это, казалось, имело смысл. Это круто, с этой точки зрения. Но я не совсем уверен в намеренном внедрении отслеживаемых кольцевых подписей. http://search.ieice.org/bin/summary.php?id=e95-a_1_151
ключ, а ключи всех пользователей его группы. Подтверждающее лицо убеждено, что настоящим подписывающим лицом является член группы, но не может однозначно идентифицировать подписавшего. Исходный протокол требовал доверенной третьей стороны (называемой менеджером группы), и он был единственный, кто мог отследить подписавшего. Следующая версия, названная кольцевой подписью, представила Ривест и др. в [34] была автономная схема без менеджера группы и анонимности. отзыв. Позднее появились различные модификации этой схемы: связываемая кольцевая подпись [26, 27, 17] позволило определить, были ли две подписи созданы одним и тем же членом группы, прослеживаемые Кольцевая подпись [24, 23] ограничивала чрезмерную анонимность, предоставляя возможность отследить подписавшего два сообщения относительно одной и той же метаинформации (или «тега» в терминах [24]). Подобная криптографическая конструкция известна также как подпись специальной группы [16, 38]. Это подчеркивает произвольное формирование группы, тогда как схемы групповой/кольцевой подписи скорее предполагают фиксированный набор членов. По большей части наше решение основано на работе «Прослеживаемая кольцевая подпись» Э. Фудзисаки. и К. Сузуки [24]. Чтобы отличить оригинальный алгоритм от нашей модификации, будем назовем последнюю одноразовой кольцевой подписью, подчеркивая возможность пользователя создать только одну действительную подпись. подпись под своим секретным ключом. Мы ослабили свойство прослеживаемости и сохранили возможность связывания. только для обеспечения одноразовости: открытый ключ может появляться во многих иностранных проверочных наборах, а закрытый ключ можно использовать для создания уникальной анонимной подписи. В случае двойной траты попытка эти две подписи будут связаны друг с другом, но раскрытие подписавшего не требуется для наших целей. 4.2 Определения 4.2.1 Параметры эллиптической кривой В качестве базового алгоритма подписи мы выбрали быструю схему EdDSA, которая разработана и реализованный Д.Дж. Бернштейн и др. [18]. Как и ECDSA Bitcoin, он основан на эллиптической кривой. задача дискретного логарифма, поэтому нашу схему можно будет применить и к Bitcoin в будущем. Общие параметры: q: простое число; q = 2255 −19; d: элемент Fq; д = -121665/121666; E: уравнение эллиптической кривой; −x2 + y2 = 1 + dx2y2; G: базовая точка; Г = (х, −4/5); l: простой порядок базовой точки; л = 2252 + 27742317777372353535851937790883648493; \(H_s\): криптографическая hash функция \(\{0, 1\}^* \to \mathbb{F}_q\); \(H_p\): детерминированная hash функция \(E(\mathbb{F}_q) \to E(\mathbb{F}_q)\). 4.2.2 Терминология Повышенная конфиденциальность требует новой терминологии, которую не следует путать с сущностями Bitcoin. приватный ec-ключ — стандартный приватный ключ в виде эллиптической кривой: число \(a \in [1, l - 1]\); публичный ec-ключ — стандартный публичный ключ эллиптической кривой: точка A = aG; одноразовая пара ключей — пара приватных и публичных электронных ключей; 5 ключ, а ключи всех пользователей его группы. Подтверждающее лицо убеждено, что настоящим подписывающим лицом является член группы, но не может однозначно идентифицировать подписавшего. Исходный протокол требовал доверенной третьей стороны (называемой менеджером группы), и он был единственный, кто мог отследить подписавшего. Следующая версия, названная кольцевой подписью, представила Ривест и др. в [34] была автономная схема без менеджера группы и анонимности. отзыв. Позднее появились различные модификации этой схемы: связываемая кольцевая подпись [26, 27, 17] позволило определить, были ли две подписи созданы одним и тем же членом группы, прослеживаемые Кольцевая подпись [24, 23] ограничивала чрезмерную анонимность, предоставляя возможность отследить подписавшего два сообщения относительно одной и той же метаинформации (или «тега» в терминах [24]). Подобная криптографическая конструкция известна также как подпись специальной группы [16, 38]. Это подчеркивает произвольное формирование группы, тогда как схемы групповой/кольцевой подписи скорее предполагают фиксированный набор членов. По большей части наше решение основано на работе «Прослеживаемая кольцевая подпись» Э. Фудзисаки. и К. Сузуки [24]. Чтобы отличить оригинальный алгоритм от нашей модификации, будем назовем последнюю одноразовой кольцевой подписью, подчеркивая возможность пользователя создать только одну действительную подпись. подпись под своим секретным ключом. Мы ослабили свойство прослеживаемости и сохранили возможность связывания. только для обеспечения одноразовости: открытый ключ может появляться во многих иностранных проверочных наборах, а закрытый ключ можно использовать для создания уникальной анонимной подписи. В случае двойной траты попытка эти две подписи будут связаны друг с другом, но раскрытие подписавшего не требуется для наших целей. 4.2 Определения 4.2.1 Параметры эллиптической кривой В качестве базового алгоритма подписи мы выбралие использовать быструю схему EdDSA, которая разработана и реализованный Д.Дж. Бернштейн и др. [18]. Как и ECDSA Bitcoin, он основан на эллиптической кривой. задача дискретного логарифма, поэтому нашу схему можно будет применить и к Bitcoin в будущем. Общие параметры: q: простое число; q = 2255 −19; d: элемент Fq; д = -121665/121666; E: уравнение эллиптической кривой; −x2 + y2 = 1 + dx2y2; G: базовая точка; Г = (х, −4/5); l: простой порядок базовой точки; л = 2252 + 27742317777372353535851937790883648493; \(H_s\): криптографическая hash функция \(\{0, 1\}^* \to \mathbb{F}_q\); \(H_p\): детерминированная hash функция \(E(\mathbb{F}_q) \to E(\mathbb{F}_q)\). 4.2.2 Терминология Повышенная конфиденциальность требует новой терминологии, которую не следует путать с сущностями Bitcoin. приватный ec-ключ — стандартный приватный ключ в виде эллиптической кривой: число \(a \in [1, l - 1]\); публичный ec-ключ — стандартный публичный ключ эллиптической кривой: точка A = aG; одноразовая пара ключей — пара приватных и публичных электронных ключей; 5 9 Черт возьми, автор этого документа наверняка мог бы сформулировать это лучше! Скажем, компания, принадлежащая сотрудникам, хочет проголосовать за то, приобретать или нет определенные новые активы, а Алекс и Бренда являются сотрудниками. Компания предоставляет каждому сотруднику сообщение типа «Я голосую за предложение А!» который имеет метаинформационную «проблему» [ПРОП А] и просит их подписать его отслеживаемой кольцевой подписью, если они поддерживают это предложение. Используя традиционную кольцевую подпись, недобросовестный сотрудник может подписать сообщение несколько раз. предположительно с разными nonce, чтобы голосовать столько раз, сколько захотят. С другой стороны С другой стороны, в схеме отслеживаемой кольцевой подписи Алекс пойдет голосовать, и ее закрытый ключ будет иметь был использован по вопросу [ПРОП А]. Если Алекс попытается подписать сообщение типа «Я, Бренда, одобряю предложение А!» чтобы «подставить» Бренду и провести двойное голосование, в этом новом сообщении также будет проблема [ПРОП А]. Поскольку закрытый ключ Алекса уже вызвал проблему [PROP A], личность Алекса будет сразу же раскрыто как мошенничество. Что, согласитесь, очень круто! Криптография обеспечивала равенство голосов. http://link.springer.com/chapter/10.1007/978-3-540-71677-8_13 Эта статья интересна тем, что по сути создает специальную кольцевую подпись, но без каких-либо согласие другого участника. Структура подписи может быть различной; я не копал глубоко, и я не видел, безопасно ли оно. https://people.csail.mit.edu/rivest/AdidaHohenbergerRivest-AdHocGroupSignaturesFromHijackedKeypai Подписи специальных групп: кольцевые подписи, которые представляют собой групповые подписи без группы. менеджеров, никакой централизации, но позволяет члену специальной группы доказуемо утверждать, что он (не) выдал анонимную подпись от имени группы. http://link.springer.com/chapter/10.1007/11908739_9 Это не совсем правильно, насколько я понимаю. И мое понимание, вероятно, изменится по мере того, как Я углубляюсь в этот проект. Но насколько я понимаю, иерархия выглядит так. Подписи группы: менеджеры группы контролируют отслеживаемость и возможность добавления или удаления участников. от подписантов. Сигналы звонка: произвольное формирование группы без менеджера группы. Никакого отзыва анонимности. Нет возможности отречься от той или иной подписи. С отслеживаемым и подключаемым кольцом подписи, анонимность в некоторой степени масштабируема. Подписи специальных групп: аналогично кольцевым подписям, но участники могут доказать, что они не создавали конкретная подпись. Это важно, когда любой член группы может поставить подпись. http://link.springer.com/chapter/10.1007/978-3-540-71677-8_13 Алгоритм Фудзисаки и Сузуки позже был доработан автором для обеспечения единовременности. Итак мы будем анализировать алгоритм Фудзисаки и Сузуки одновременно с новым алгоритмом, а не чем рассматривать это здесь.
ключ, а ключи всех пользователей его группы. Подтверждающее лицо убеждено, что настоящим подписывающим лицом является член группы, но не может однозначно идентифицировать подписавшего. Исходный протокол требовал доверенной третьей стороны (называемой менеджером группы), и он был единственный, кто мог отследить подписавшего. Следующая версия, названная кольцевой подписью, представила Ривест и др. в [34] была автономная схема без менеджера группы и анонимности. отзыв. Позднее появились различные модификации этой схемы: связываемая кольцевая подпись [26, 27, 17] позволило определить, были ли две подписи созданы одним и тем же членом группы, прослеживаемые Кольцевая подпись [24, 23] ограничивала чрезмерную анонимность, предоставляя возможность отследить подписавшего два сообщения относительно одной и той же метаинформации (или «тега» в терминах [24]). Подобная криптографическая конструкция известна также как подпись специальной группы [16, 38]. Это подчеркивает произвольное формирование группы, тогда как схемы групповой/кольцевой подписи скорее предполагают фиксированный набор членов. По большей части наше решение основано на работе «Прослеживаемая кольцевая подпись» Э. Фудзисаки. и К. Сузуки [24]. Чтобы отличить оригинальный алгоритм от нашей модификации, будем назовем последнюю одноразовой кольцевой подписью, подчеркивая возможность пользователя создать только одну действительную подпись. подпись под своим секретным ключом. Мы ослабили свойство прослеживаемости и сохранили возможность связывания. только для обеспечения одноразовости: открытый ключ может появляться во многих иностранных проверочных наборах, а закрытый ключ можно использовать для создания уникальной анонимной подписи. В случае двойной траты попытка эти две подписи будут связаны друг с другом, но раскрытие подписавшего не требуется для наших целей. 4.2 Определения 4.2.1 Параметры эллиптической кривой В качестве базового алгоритма подписи мы выбрали быструю схему EdDSA, которая разработана и реализованный Д.Дж. Бернштейн и др. [18]. Как и ECDSA Bitcoin, он основан на эллиптической кривой. задача дискретного логарифма, поэтому нашу схему можно будет применить и к Bitcoin в будущем. Общие параметры: q: простое число; q = 2255 −19; d: элемент Fq; д = -121665/121666; E: уравнение эллиптической кривой; −x2 + y2 = 1 + dx2y2; G: базовая точка; Г = (х, −4/5); l: простой порядок базовой точки; л = 2252 + 27742317777372353535851937790883648493; \(H_s\): криптографическая hash функция \(\{0, 1\}^* \to \mathbb{F}_q\); \(H_p\): детерминированная hash функция \(E(\mathbb{F}_q) \to E(\mathbb{F}_q)\). 4.2.2 Терминология Повышенная конфиденциальность требует новой терминологии, которую не следует путать с сущностями Bitcoin. приватный ec-ключ — стандартный приватный ключ в виде эллиптической кривой: число \(a \in [1, l - 1]\); публичный ec-ключ — стандартный публичный ключ эллиптической кривой: точка A = aG; одноразовая пара ключей — пара приватных и публичных электронных ключей; 5 ключ, а ключи всех пользователей его группы. Подтверждающее лицо убеждено, что настоящим подписывающим лицом является член группы, но не может однозначно идентифицировать подписавшего. Исходный протокол требовал доверенной третьей стороны (называемой менеджером группы), и он был единственный, кто мог отследить подписавшего. Следующая версия, названная кольцевой подписью, представила Ривест и др. в [34] была автономная схема без менеджера группы и анонимности. отзыв. Позднее появились различные модификации этой схемы: связываемая кольцевая подпись [26, 27, 17] позволило определить, были ли две подписи созданы одним и тем же членом группы, прослеживаемые Кольцевая подпись [24, 23] ограничивала чрезмерную анонимность, предоставляя возможность отследить подписавшего два сообщения относительно одной и той же метаинформации (или «тега» в терминах [24]). Подобная криптографическая конструкция известна также как подпись специальной группы [16, 38]. Это подчеркивает произвольное формирование группы, тогда как схемы групповой/кольцевой подписи скорее предполагают фиксированный набор членов. По большей части наше решение основано на работе «Прослеживаемая кольцевая подпись» Э. Фудзисаки. и К. Сузуки [24]. Чтобы отличить оригинальный алгоритм от нашей модификации, будем назовем последнюю одноразовой кольцевой подписью, подчеркивая возможность пользователя создать только одну действительную подпись. подпись под своим секретным ключом. Мы ослабили свойство прослеживаемости и сохранили возможность связывания. только для обеспечения одноразовости: открытый ключ может появляться во многих иностранных проверочных наборах, а закрытый ключ можно использовать для создания уникальной анонимной подписи. В случае двойной траты попытка эти две подписи будут связаны друг с другом, но раскрытие подписавшего не требуется для наших целей. 4.2 Определения 4.2.1 Параметры эллиптической кривой В качестве базового алгоритма подписи мы выбралие использовать быструю схему EdDSA, которая разработана и реализованный Д.Дж. Бернштейн и др. [18]. Как и ECDSA Bitcoin, он основан на эллиптической кривой. задача дискретного логарифма, поэтому нашу схему можно будет применить и к Bitcoin в будущем. Общие параметры: q: простое число; q = 2255 −19; d: элемент Fq; д = -121665/121666; E: уравнение эллиптической кривой; −x2 + y2 = 1 + dx2y2; G: базовая точка; Г = (х, −4/5); l: простой порядок базовой точки; л = 2252 + 27742317777372353535851937790883648493; \(H_s\): криптографическая hash функция \(\{0, 1\}^* \to \mathbb{F}_q\); \(H_p\): детерминированная hash функция \(E(\mathbb{F}_q) \to E(\mathbb{F}_q)\). 4.2.2 Терминология Повышенная конфиденциальность требует новой терминологии, которую не следует путать с сущностями Bitcoin. приватный ec-ключ — стандартный приватный ключ в виде эллиптической кривой: число \(a \in [1, l - 1]\); публичный ec-ключ — стандартный публичный ключ эллиптической кривой: точка A = aG; одноразовая пара ключей — пара приватных и публичных электронных ключей; 5 10 Возможность связывания в смысле «связываемых кольцевых подписей» означает, что мы можем определить, пришли ли две исходящие транзакции из одного и того же источника, не раскрывая, кто является источником. Авторы ослабили возможность связывания, чтобы (а) сохранить конфиденциальность, но при этом (б) обнаружить любую транзакцию с использованием закрытого ключа второй раз как недействительный. Хорошо, это вопрос порядка событий. Рассмотрим следующий сценарий. Мой майнинг компьютер будет иметь текущий blockchain, у него будет собственный блок транзакций, который он вызывает законно, он будет работать над этим блоком в головоломке proof-of-work и у него будет список ожидающих транзакций, которые будут добавлены в следующий блок. Он также будет отправлять любые новые транзакции в этот пул ожидающих транзакций. Если я не решу следующий блок, но кто-то другой делает, я получаю обновленную копию blockchain. Блок, над которым я работал, и в моем списке ожидающих транзакций могут быть некоторые транзакции, которые сейчас включены в blockchain. Разгадайте мой ожидающий блок, объедините его со списком ожидающих транзакций и назовите его мой пул ожидающих транзакций. Удалите все, что сейчас официально находится в каталоге blockchain. Что мне делать? Должен ли я сначала пройти процедуру и «убрать все двойные траты»? С другой стороны С другой стороны, следует ли мне просмотреть список и убедиться, что каждый закрытый ключ еще не был используется, и если он уже использовался в моем списке, то я получил первый экземпляр первым и, следовательно, любая дальнейшая копия является незаконной. Поэтому я просто удаляю все экземпляры после первого того же закрытого ключа. Алгебраическая геометрия никогда не была моей сильной стороной. http://en.wikipedia.org/wiki/EdDSA Такая скорость, ничего себе. ЭТО алгебраическая геометрия для победы. Не то чтобы я что-то знал об этом. Проблематично или нет, но дискретные журналы становятся очень быстрыми. И квантовые компьютеры их едят на завтрак. http://link.springer.com/article/10.1007/s13389-012-0027-1 Это становится действительно важным числом, но нет никаких объяснений или ссылок на то, как оно был выбран. Было бы неплохо просто выбрать одно известное большое простое число, но если известны факты об этом большом простом числе, которые могут повлиять на наш выбор. Различные варианты криптоноты можно было выбрать разные значения э, но в этой статье нет обсуждения того, как это Выбор повлияет на наш выбор других глобальных параметров, перечисленных на странице 5. В этой статье необходим раздел, посвященный выбору значений параметров.
приватный ключ пользователя — это пара (a, b) двух разных приватных ec-ключей; ключ отслеживания — пара (a, B) частного и публичного ec-ключа (где B = bG и a ̸= b); открытый ключ пользователя — это пара (A, B) двух открытых электронных ключей, полученных из (a, b); стандартный адрес — это представление открытого ключа пользователя, представленного в удобной для человека строке. с исправлением ошибок; усеченный адрес представляет собой представление второй половины (точка B) открытого ключа пользователя, заданного в удобную для человека строку с коррекцией ошибок. Структура транзакции остается аналогичной структуре в Bitcoin: каждый пользователь может выбрать несколько независимых входящих платежей (выходов транзакций), подпишите их соответствующими секретные ключи и отправлять их в разные места назначения. В отличие от модели Bitcoin, где пользователь обладает уникальными закрытым и открытым ключами, в предлагаемая модель: отправитель генерирует одноразовый открытый ключ на основе адреса получателя и некоторые случайные данные. В этом смысле входящая транзакция для того же получателя отправляется одноразовый открытый ключ (не напрямую к уникальному адресу), и только получатель может восстановить соответствующую частную часть для выкупа его средств (с использованием его уникального закрытого ключа). Получатель может тратить средства, используя кольцевую подпись, сохраняя анонимность своего владельца и фактических расходов. Подробности протокола описаны в следующих подразделах. 4.3 Непривязываемые платежи Классические адреса Bitcoin после публикации становятся однозначным идентификатором для входящих платежи, связывая их между собой и привязывая к псевдонимам получателя. Если кто-то хочет получить «несвязанную» транзакцию, он должен передать свой адрес отправителю по частному каналу. Если он хочет получать разные транзакции, принадлежность которых не может быть доказано одному и тому же владельцу он должен генерировать все разные адреса и никогда не публиковать их под своим псевдонимом. Общественный Частный Алиса Кэрол Адрес Боба 1 Адрес Боба 2 Ключ Боба 1 Ключ Боба 2 Боб Рис. 2. Традиционная модель ключей/транзакций Bitcoin. Мы предлагаем решение, позволяющее пользователю публиковать один адрес и получать безоговорочную несвязанные платежи. Назначением каждого вывода CryptoNote (по умолчанию) является открытый ключ. получается на основе адреса получателя и случайных данных отправителя. Основное преимущество против Bitcoin заключается в том, что каждый ключ назначения по умолчанию уникален (если только отправитель не использует одни и те же данные для каждого его транзакций одному и тому же получателю). Следовательно, не существует такой проблемы, как «повторное использование адреса» дизайн, и ни один наблюдатель не может определить, были ли какие-либо транзакции отправлены на определенный адрес или ссылку. два адреса вместе. 6 приватный ключ пользователя — это пара (a, b) двух разных приватных ec-ключей; ключ отслеживания — пара (a, B) частного и публичного ec-ключа (где B = bG и a ̸= b); открытый ключ пользователя — это пара (A, B) двух открытых электронных ключей, полученных из (a, b); стандартный адрес — это представление открытого ключа пользователя, представленного в удобной для человека строке. с исправлением ошибок; усеченный адрес представляет собой представление второй половины (точка B) открытого ключа пользователя, заданного в удобную для человека строку с коррекцией ошибок. Структура транзакции остается аналогичной структуре в Bitcoin: каждый пользователь может выбрать несколько независимых входящих платежей (выходов транзакций), подпишите их соответствующими секретные ключи и отправлять их в разные места назначения. В отличие от модели Bitcoin, где пользователь обладает уникальными закрытым и открытым ключами, в предлагаемая модель: отправитель генерирует одноразовый открытый ключ на основе адреса получателя и некоторые случайные данные. В этом смысле входящая транзакция для того же получателя отправляется одноразовый открытый ключ (не напрямую к уникальному адресу), и только получатель может восстановить соответствующую частную часть для выкупа его средств (с использованием его уникального закрытого ключа). Получатель может тратить средства, используя кольцевую подпись, сохраняя анонимность своего владельца и фактических расходов. Подробности протокола описаны в следующих подразделах. 4.3 Непривязываемые платежи Классические адреса Bitcoin после публикации становятся однозначным идентификатором для входящих платежи, связывая их между собой и привязывая к псевдонимам получателя. Если кто-то хочет получить «несвязанную» транзакцию, он должен передать свой адрес отправителю по частному каналу. Если он хочет получать разные транзакции, принадлежность которых не может быть доказано одному и тому же владельцу он должен генерировать все разные адреса и никогда не публиковать их под своим псевдонимом. Общественный Частный Алиса Кэрол Адрес Боба 1 Адрес Боба 2 Ключ Боба 1 Ключ Боба 2 Боб Рис. 2. Традиционный мод Bitcoin ключей/транзакцийэл. Мы предлагаем решение, позволяющее пользователю публиковать один адрес и получать безоговорочную несвязанные платежи. Назначением каждого вывода CryptoNote (по умолчанию) является открытый ключ. получается на основе адреса получателя и случайных данных отправителя. Основное преимущество против Bitcoin заключается в том, что каждый ключ назначения по умолчанию уникален (если только отправитель не использует одни и те же данные для каждого его транзакций одному и тому же получателю). Следовательно, не существует такой проблемы, как «повторное использование адреса» дизайн, и ни один наблюдатель не может определить, были ли какие-либо транзакции отправлены на определенный адрес или ссылку. два адреса вместе. 6 11 Это похоже на Bitcoin, но с бесконечным количеством анонимных почтовых ящиков, погашать которые может только получатель. создание закрытого ключа, который настолько же анонимен, насколько это возможно при использовании кольцевой подписи. Bitcoin работает следующим образом. Если у Алекс в кошельке есть 0,112 Bitcoin, который она только что получила от Фрэнка, у нее действительно есть подписанный сообщение «Я, [ФРАНК], отправлю 0.112 Bitcoin на [alex] + H0 + N0», где 1) Фрэнк подписал сообщение своим секретным ключом [FRANK], 2) Фрэнк подписал сообщение открытым ключом Алекса. ключ, [алекс], 3) Фрэнк включил некоторую форму истории биткойна, H0, и 4) Фрэнк включает случайный бит данных, называемый nonce, N0. Если затем Алекс захочет отправить 0,011 Bitcoin Шарлин, она примет сообщение Фрэнка и установит для него значение H1 и подпишет два сообщения: одно для ее транзакции и одно для изменения. H1= "Я, [ФРАНК], отправь 0,112 Bitcoin на [alex] + H0 + N" "Я, [ALEX], отправь 0,011 Bitcoin на [charlene] + H1 + N1" "Я, [ALEX], отправляю 0,101 Bitcoin в качестве изменения на [alex] + H1 + N2." где Алекс подписывает оба сообщения своим секретным ключом [ALEX], первое сообщение с именем Шарлин открытый ключ [charlene], второе сообщение с открытым ключом Алекса [alex], включая истории и некоторые случайно сгенерированные nonce N1 и N2 соответственно. Cryptonote работает следующим образом: Если у Алекс в кошельке есть криптовалюта 0,112, которую она только что получила от Фрэнка, значит, у нее действительно есть подписанная сообщение «Я, [кто-то из специальной группы], отправляю 0,112 Cryptonote на [одноразовый адрес] + H0 +Н0." Алекс обнаружила, что это ее деньги, сверив свой закрытый ключ [ALEX] с [одноразовый адрес] для каждого проходящего сообщения, и если она желает его потратить, она делает это в следующим образом. Она выбирает получателя денег, возможно, Шарлин начала голосовать за удары дронов, поэтому Вместо этого Алекс хочет отправить деньги Бренде. Итак, Алекс ищет открытый ключ Бренды, [brenda], и использует свой собственный секретный ключ [ALEX] для создания одноразового адреса [ALEX+brenda]. Она затем выбирает произвольную коллекцию C из сети пользователей криптонот и строит кольцевая подпись из этой специальной группы. Устанавливаем нашу историю как предыдущее сообщение, добавляем nonces, и действовать как обычно? H1 = «Я, [кто-то из специальной группы], отправляю 0,112 Cryptonote на [одноразовый адрес] + H0 +Н0." «Я, [кто-то из коллекции C], отправляю 0,011 Cryptonote на [одноразовый адрес, созданный из ALEX+brenda] + H1 + N1» «Я, [кто-то из коллекции C], отправляю 0,101 Cryptonote в качестве изменения на [одноразовый адрес-сделанный из-ALEX+alex] + H1 + N2» Теперь Алекс и Бренда сканируют все входящие сообщения на наличие одноразовых адресов, которые были созданный с использованием их ключа. Если они его найдут, то это будет их собственное, совершенно новое сообщение. криптонота! И даже в этом случае транзакция все равно достигнет blockchain. Если монеты, поступающие по этому адресу известно, что они отправляются от преступников, политических деятелей или от комитетов и счетов. со строгим бюджетом (т. е. хищением), или если новый владелец этих монет когда-либо совершит ошибку и отправляет эти монеты на общий адрес с монетами, которыми он, как известно, владеет, приспособление для анонимности в биткойнах.
приватный ключ пользователя — это пара (a, b) двух разных приватных ec-ключей; ключ отслеживания — пара (a, B) частного и публичного ec-ключа (где B = bG и a ̸= b); открытый ключ пользователя — это пара (A, B) двух открытых электронных ключей, полученных из (a, b); стандартный адрес — это представление открытого ключа пользователя, представленного в удобной для человека строке. с исправлением ошибок; усеченный адрес представляет собой представление второй половины (точка B) открытого ключа пользователя, заданного в удобную для человека строку с коррекцией ошибок. Структура транзакции остается аналогичной структуре в Bitcoin: каждый пользователь может выбрать несколько независимых входящих платежей (выходов транзакций), подпишите их соответствующими секретные ключи и отправлять их в разные места назначения. В отличие от модели Bitcoin, где пользователь обладает уникальными закрытым и открытым ключами, в предлагаемая модель: отправитель генерирует одноразовый открытый ключ на основе адреса получателя и некоторые случайные данные. В этом смысле входящая транзакция для того же получателя отправляется одноразовый открытый ключ (не напрямую к уникальному адресу), и только получатель может восстановить соответствующую частную часть для выкупа его средств (с использованием его уникального закрытого ключа). Получатель может тратить средства, используя кольцевую подпись, сохраняя анонимность своего владельца и фактических расходов. Подробности протокола описаны в следующих подразделах. 4.3 Непривязываемые платежи Классические адреса Bitcoin после публикации становятся однозначным идентификатором для входящих платежи, связывая их между собой и привязывая к псевдонимам получателя. Если кто-то хочет получить «несвязанную» транзакцию, он должен передать свой адрес отправителю по частному каналу. Если он хочет получать разные транзакции, принадлежность которых не может быть доказано одному и тому же владельцу он должен генерировать все разные адреса и никогда не публиковать их под своим псевдонимом. Общественный Частный Алиса Кэрол Адрес Боба 1 Адрес Боба 2 Ключ Боба 1 Ключ Боба 2 Боб Рис. 2. Традиционная модель ключей/транзакций Bitcoin. Мы предлагаем решение, позволяющее пользователю публиковать один адрес и получать безоговорочную несвязанные платежи. Назначением каждого вывода CryptoNote (по умолчанию) является открытый ключ. получается на основе адреса получателя и случайных данных отправителя. Основное преимущество против Bitcoin заключается в том, что каждый ключ назначения по умолчанию уникален (если только отправитель не использует одни и те же данные для каждого его транзакций одному и тому же получателю). Следовательно, не существует такой проблемы, как «повторное использование адреса» дизайн, и ни один наблюдатель не может определить, были ли какие-либо транзакции отправлены на определенный адрес или ссылку. два адреса вместе. 6 приватный ключ пользователя — это пара (a, b) двух разных приватных ec-ключей; ключ отслеживания — пара (a, B) частного и публичного ec-ключа (где B = bG и a ̸= b); открытый ключ пользователя — это пара (A, B) двух открытых электронных ключей, полученных из (a, b); стандартный адрес — это представление открытого ключа пользователя, представленного в удобной для человека строке. с исправлением ошибок; усеченный адрес представляет собой представление второй половины (точка B) открытого ключа пользователя, заданного в удобную для человека строку с коррекцией ошибок. Структура транзакции остается аналогичной структуре в Bitcoin: каждый пользователь может выбрать несколько независимых входящих платежей (выходов транзакций), подпишите их соответствующими секретные ключи и отправлять их в разные места назначения. В отличие от модели Bitcoin, где пользователь обладает уникальными закрытым и открытым ключами, в предлагаемая модель: отправитель генерирует одноразовый открытый ключ на основе адреса получателя и некоторые случайные данные. В этом смысле входящая транзакция для того же получателя отправляется одноразовый открытый ключ (не напрямую к уникальному адресу), и только получатель может восстановить соответствующую частную часть для выкупа его средств (с использованием его уникального закрытого ключа). Получатель может тратить средства, используя кольцевую подпись, сохраняя анонимность своего владельца и фактических расходов. Подробности протокола описаны в следующих подразделах. 4.3 Непривязываемые платежи Классические адреса Bitcoin после публикации становятся однозначным идентификатором для входящих платежи, связывая их между собой и привязывая к псевдонимам получателя. Если кто-то хочет получить «несвязанную» транзакцию, он должен передать свой адрес отправителю по частному каналу. Если он хочет получать разные транзакции, принадлежность которых не может быть доказано одному и тому же владельцу он должен генерировать все разные адреса и никогда не публиковать их под своим псевдонимом. Общественный Частный Алиса Кэрол Адрес Боба 1 Адрес Боба 2 Ключ Боба 1 Ключ Боба 2 Боб Рис. 2. Традиционный мод Bitcoin ключей/транзакцийэл. Мы предлагаем решение, позволяющее пользователю публиковать один адрес и получать безоговорочную несвязанные платежи. Назначением каждого вывода CryptoNote (по умолчанию) является открытый ключ. получается на основе адреса получателя и случайных данных отправителя. Основное преимущество против Bitcoin заключается в том, что каждый ключ назначения по умолчанию уникален (если только отправитель не использует одни и те же данные для каждого его транзакций одному и тому же получателю). Следовательно, не существует такой проблемы, как «повторное использование адреса» дизайн, и ни один наблюдатель не может определить, были ли какие-либо транзакции отправлены на определенный адрес или ссылку. два адреса вместе. 6 12 Следовательно, вместо того, чтобы пользователи отправляли монеты с адреса (который на самом деле является открытым ключом) на адрес (еще один открытый ключ) используя свои приватные ключи, пользователи отправляют монеты из одноразового почтового ящика (который генерируется с использованием открытого ключа вашего друга) на одноразовый почтовый ящик (аналогично) с использованием вашего собственные секретные ключи. В каком-то смысле мы говорим: «Хорошо, уберите руки от денег, пока они находятся в обороте». перенесено! Достаточно просто знать, что наши ключи могут открыть этот ящик и что мы знаем, сколько денег в коробке. Никогда не оставляйте отпечатки пальцев на почтовом ящике или на самом деле используйте его, просто продайте саму коробку, наполненную деньгами. Таким образом, мы не знаем, кто отправил что, но содержание этих публичных обращений по-прежнему остается гладким, взаимозаменяемым, делимым и по-прежнему обладают всеми другими приятными качествами денег, которые мы желаем, например, биткойнами». Бесконечный набор почтовых ящиков. Вы публикуете адрес, у меня есть закрытый ключ. Я использую свой закрытый ключ и ваш адрес, и некоторые случайные данные для генерации открытого ключа. Алгоритм разработан таким образом, что, поскольку ваш адрес использовался для генерации открытого ключа, только ВАШ закрытый ключ работает для разблокировки сообщение. Наблюдатель, Ева, видит, что вы публикуете свой адрес, и видит открытый ключ, который я объявляю. Однако, она не знает, объявил ли я свой открытый ключ на основе вашего адреса, ее адреса или адреса Бренды. или Шарлин, или кто бы то ни было. Она сверяет свой закрытый ключ с открытым ключом, который я объявил. и видит, что это не работает; это не ее деньги. Она не знает чужого закрытого ключа, и только получатель сообщения имеет закрытый ключ, который может разблокировать сообщение. Так что никто Прослушивание может определить, кто получил деньги, а тем более взять деньги.
Общественный Частный Алиса Кэрол Одноразовый ключ Одноразовый ключ Одноразовый ключ Боб Ключ Боба Адрес Боба Рис. 3. Модель ключей/транзакций CryptoNote. Сначала отправитель выполняет обмен Диффи-Хеллмана, чтобы получить общий секрет из своих данных и половина адреса получателя. Затем он вычисляет одноразовый ключ назначения, используя общий секрет и вторая половина адреса. От получателя требуются два разных электронных ключа. для этих двух шагов, поэтому стандартный адрес CryptoNote почти в два раза больше, чем адрес Bitcoin кошелька. адрес. Получатель также выполняет обмен Диффи-Хеллмана для восстановления соответствующего сообщения. секретный ключ. Стандартная последовательность транзакций выглядит следующим образом: 1. Алиса хочет отправить платеж Бобу, который опубликовал свой стандартный адрес. Она распаковывает адрес и получает открытый ключ Боба (A, B). 2. Алиса генерирует случайное число \(r \in [1, l - 1]\) и вычисляет одноразовый открытый ключ \(P = H_s(rA)G +\). Б. 3. Алиса использует P в качестве ключа назначения для вывода, а также упаковывает значение R = rG (как часть обмена Диффи-Хеллмана) где-то в транзакции. Обратите внимание, что она может создавать другие выходные данные с уникальными открытыми ключами: разные ключи получателей (Ai, Bi) подразумевают разные Pi даже с тем же р. Транзакция Открытый ключ передачи Выход передачи Сумма Ключ назначения Р = гГ P = Hs(rA)G + B Получателя открытый ключ Случайные данные отправителя р (А, Б) Рис. 4. Стандартная структура транзакции. 4. Алиса отправляет транзакцию. 5. Боб проверяет каждую проходящую транзакцию своим секретным ключом (a, b) и вычисляет P ′ = Hs(aR)G + Б. Если среди них была транзакция Алисы с Бобом в качестве получателя, тогда aR = arG = rA и P ′ = P. 7 Общественный Частный Алиса Кэрол Одноразовый ключ Одноразовый ключ Одноразовый ключ Боб Ключ Боба Адрес Боба Рис. 3. Модель ключей/транзакций CryptoNote. Сначала отправитель выполняет обмен Диффи-Хеллмана, чтобы получить общий секрет из своих данных и половина адреса получателя. Затем он вычисляет одноразовый ключ назначения, используя общий секрет и вторая половина адреса. От получателя требуются два разных электронных ключа. для этих двух шагов, поэтому стандартный адрес CryptoNote почти в два раза больше, чем адрес Bitcoin кошелька. адрес. Получатель также выполняет обмен Диффи-Хеллмана для восстановления соответствующего сообщения. секретный ключ. Стандартная последовательность транзакций выглядит следующим образом: 1. Алиса хочет отправить платеж Бобу, который опубликовал свой стандартный адрес. Она распаковывает адрес и получает открытый ключ Боба (A, B). 2. Алиса генерирует случайное число \(r \in [1, l - 1]\) и вычисляет одноразовый открытый ключ \(P = H_s(rA)G +\). Б. 3. Алиса использует P в качестве ключа назначения для вывода, а также упаковывает значение R = rG (как часть обмена Диффи-Хеллмана) где-то в транзакции. Обратите внимание, что она может создавать другие выходные данные с уникальными открытыми ключами: разные ключи получателей (Ai, Bi) подразумевают разные Pi даже с тем же р. Транзакция Открытый ключ передачи Выход передачи Сумма Ключ назначения Р = гГ P = Hs(rA)G + B Получателя открытый ключ Случайные данные отправителя р (А, Б) Рис. 4. Стандартная структура транзакции. 4. Алиса отправляет транзакцию. 5. Боб проверяет каждую проходящую транзакцию своим секретным ключом (a, b) и вычисляет P ′ = Hs(aR)G + Б. Если среди них была транзакция Алисы с Бобом в качестве получателя, тогда aR = arG = rA и P ′ = P. 7 13 Интересно, какой головной болью будет реализовать выбор криптографии? схема. Эллиптический или другой. Поэтому, если какая-то схема в будущем сломается, валюта поменяется. без беспокойства. Наверное, это большая заноза в заднице. Хорошо, это именно то, что я только что объяснил в своем предыдущем комментарии. Тип Диффе-Хеллмана обмены аккуратные. Скажем, у Алекса и Бренды есть секретный номер A и B, а также номер они не заботятся о сохранении тайны, а и б. Они хотят создать общий секрет без Ева обнаруживает это. Дайфф и Хеллман придумали, как Алекс и Бренда могли поделиться общедоступные номера a и b, но не частные номера A и B, и сгенерировать общий секрет, К. Используя этот общий секрет, К., без какой-либо подслушивающей Евы, смог создать тот же самый К, Алекс и Бренда теперь могут использовать К в качестве секретного ключа шифрования и передавать секретные сообщения обратно. и вперед. Вот как это МОЖЕТ работать, хотя оно должно работать и с числами, гораздо большими, чем 100. Мы будем использовать 100, потому что работа с целыми числами по модулю 100 эквивалентна «выбрасыванию всех но последние две цифры числа». Алекс и Бренда выбирают A, a, B и b. Они держат А и Б в секрете. Алекс сообщает Бренде свое значение по модулю 100 (только две последние цифры), а Бренда сообщает Алексу. ее значение b по модулю 100. Теперь Ева знает (a,b) по модулю 100. Но Алекс знает (a,b,A), поэтому она может вычислить x=abA по модулю 100.Алекс отсекает все, кроме последней цифры, потому что мы работаем снова под целыми числами по модулю 100. Точно так же Бренда знает (a,b,B), поэтому она может вычислить y=abB по модулю 100. Теперь Алекс может публиковать x, а Бренда может публиковать y. Но теперь Алекс может вычислить yA = abBA по модулю 100, а Бренда может вычислить xB. = абВА по модулю 100. Они оба знают одно и то же число! Но все, что слышала Ева, это (а,б,абА,абВ). У нее нет простого способа вычислить abA*B. Это самый простой и наименее безопасный способ рассмотрения обмена Диффи-Хеллмана. Существуют более безопасные версии. Но большинство версий работают, поскольку целочисленная факторизация и дискретная логарифмы сложны, и обе эти проблемы легко решаются квантовыми компьютерами. Я проверю, существуют ли какие-либо версии, устойчивые к квантовому воздействию. http://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange В приведенной здесь «стандартной последовательности txn» отсутствует целый ряд шагов, например ПОДПИСЕЙ. Здесь они воспринимаются как нечто само собой разумеющееся. Что очень плохо, потому что порядок, в котором мы подписываемые материалы, информация, содержащаяся в подписанном сообщении, и так далее... все это чрезвычайно важно для протокола. Если сделать один или два шага неправильно, даже немного не по порядку, при реализации « стандартная последовательность транзакций» может поставить под вопрос безопасность всей системы. Более того, доказательства, представленные далее в статье, могут оказаться недостаточно строгими, если Структура, в которой они работают, определена так же свободно, как и в этом разделе.
Общественный Частный Алиса Кэрол Одноразовый ключ Одноразовый ключ Одноразовый ключ Боб Ключ Боба Адрес Боба Рис. 3. Модель ключей/транзакций CryptoNote. Сначала отправитель выполняет обмен Диффи-Хеллмана, чтобы получить общий секрет из своих данных и половина адреса получателя. Затем он вычисляет одноразовый ключ назначения, используя общий секрет и вторая половина адреса. От получателя требуются два разных электронных ключа. для этих двух шагов, поэтому стандартный адрес CryptoNote почти в два раза больше, чем адрес кошелька Bitcoin. адрес. Получатель также выполняет обмен Диффи-Хеллмана для восстановления соответствующего сообщения. секретный ключ. Стандартная последовательность транзакций выглядит следующим образом: 1. Алиса хочет отправить платеж Бобу, который опубликовал свой стандартный адрес. Она распаковывает адрес и получает открытый ключ Боба (A, B). 2. Алиса генерирует случайное число \(r \in [1, l - 1]\) и вычисляет одноразовый открытый ключ \(P = H_s(rA)G +\). Б. 3. Алиса использует P в качестве ключа назначения для вывода, а также упаковывает значение R = rG (как часть обмена Диффи-Хеллмана) где-то в транзакции. Обратите внимание, что она может создавать другие выходные данные с уникальными открытыми ключами: разные ключи получателей (Ai, Bi) подразумевают разные Pi даже с тем же р. Транзакция Открытый ключ передачи Выход передачи Сумма Ключ назначения Р = гГ P = Hs(rA)G + B Получателя открытый ключ Случайные данные отправителя р (А, Б) Рис. 4. Стандартная структура транзакции. 4. Алиса отправляет транзакцию. 5. Боб проверяет каждую проходящую транзакцию своим секретным ключом (a, b) и вычисляет P ′ = Hs(aR)G + Б. Если среди них была транзакция Алисы с Бобом в качестве получателя, тогда aR = arG = rA и P ′ = P. 7 Общественный Частный Алиса Кэрол Одноразовый ключ Одноразовый ключ Одноразовый ключ Боб Ключ Боба Адрес Боба Рис. 3. Модель ключей/транзакций CryptoNote. Сначала отправитель выполняет обмен Диффи-Хеллмана, чтобы получить общий секрет из своих данных и половина адреса получателя. Затем он вычисляет одноразовый ключ назначения, используя общий секрет и вторая половина адреса. От получателя требуются два разных электронных ключа. для этих двух шагов, поэтому стандартный адрес CryptoNote почти в два раза больше, чем адрес кошелька Bitcoin. адрес. Получатель также выполняет обмен Диффи-Хеллмана для восстановления соответствующего сообщения. секретный ключ. Стандартная последовательность транзакций выглядит следующим образом: 1. Алиса хочет отправить платеж Бобу, который опубликовал свой стандартный адрес. Она распаковывает адрес и получает открытый ключ Боба (A, B). 2. Алиса генерирует случайное число \(r \in [1, l - 1]\) и вычисляет одноразовый открытый ключ \(P = H_s(rA)G +\). Б. 3. Алиса использует P в качестве ключа назначения для вывода, а также упаковывает значение R = rG (как часть обмена Диффи-Хеллмана) где-то в транзакции. Обратите внимание, что она может создавать другие выходные данные с уникальными открытыми ключами: разные ключи получателей (Ai, Bi) подразумевают разные Pi даже с тем же р. Транзакция Открытый ключ передачи Выход передачи Сумма Ключ назначения Р = гГ P = Hs(rA)G + B Получателя открытый ключ Случайные данные отправителя р (А, Б) Рис. 4. Стандартная структура транзакции. 4. Алиса отправляет транзакцию. 5. Боб проверяет каждую проходящую транзакцию своим секретным ключом (a, b) и вычисляет P ′ = Hs(aR)G + Б. Если среди них была транзакция Алисы с Бобом в качестве получателя, тогда aR = arG = rA и P ′ = P. 7 14 Обратите внимание, что автор(ы?) ужасно стараются придерживаться четкой терминологии. текст, но особенно в следующем фрагменте. Следующим воплощением этой статьи обязательно будет гораздо более строгий. В тексте они называют P своим одноразовым открытым ключом. На диаграмме они обозначают R как их «открытый ключ Tx» и P в качестве «ключа назначения». Если бы я собирался переписать это, я бы Прежде чем обсуждать эти разделы, очень подробно изложите некоторую терминологию. Этот эл огромен. См. стр. 5. Кто выбирает Эл? Диаграмма показывает, что открытый ключ транзакции R = rG, который является случайным и выбранным. отправителем, не является частью вывода Tx. Это потому, что оно может быть одинаковым для нескольких транзакции нескольким людям и не используются ПОЗЖЕ для расходов. Генерируется новый R каждый раз, когда вы хотите транслировать новую транзакцию CryptoNote. Кроме того, R используется только чтобы проверить, являетесь ли вы получателем транзакции. Это не мусорные данные, но это мусор для всех без закрытых ключей, связанных с (A,B). С другой стороны, ключ назначения P = Hs(rA)G + B является частью вывода Tx. Все просматривая данные каждой проходящей транзакции, необходимо сверять свои собственные сгенерированные P* с этот P, чтобы узнать, владеют ли они этой проходящей транзакцией. Любой, у кого есть неизрасходованный вывод транзакции (UTXO) будет лежать куча этих P с суммами. Чтобы потратитьд, они подпишите какое-нибудь новое сообщение, включая P. Алиса должна подписать эту транзакцию с помощью одноразового закрытого ключа(ов), связанного с неизрасходованными выходными транзакцией (ключами назначения). Каждый ключ назначения, принадлежащий Алисе, оснащен с одноразовым закрытым ключом, также принадлежащим (предположительно) Алисе. Каждый раз, когда Алисе хочется отправьте содержимое ключа назначения мне, или Бобу, или Бренде, или Чарли, или Шарлин, она использует свой закрытый ключ для подписи транзакции. После получения транзакции я получу новый Открытый ключ Tx, новый открытый ключ назначения, и я смогу восстановить новый одноразовый закрытый ключ x. Объединение моего одноразового закрытого ключа x с общедоступным местом назначения новой транзакции. ключ(и) — это то, как мы отправляем новую транзакцию
- Боб может восстановить соответствующий одноразовый закрытый ключ: x = Hs(aR) + b, так что P = xG. Он может потратить этот выход в любое время, подписав транзакцию с помощью x. Транзакция Открытый ключ передачи Выход передачи Сумма Ключ назначения P ′ = Hs(aR)G + bG одноразовый открытый ключ х = Hs(aR) + b одноразовый закрытый ключ Получателя закрытый ключ (а, б) Р П ' ?= П Рис. 5. Проверка входящей транзакции. В результате Боб получает входящие платежи, связанные с одноразовыми открытыми ключами, которые непередаваемо для зрителя. Некоторые дополнительные примечания: • Когда Боб «узнаёт» свои транзакции (см. шаг 5), он практически использует только половину своих средств. личная информация: (a, B). Эту пару, также известную как ключ отслеживания, можно передать третьему лицу (Кэрол). Боб может делегировать ей обработку новых транзакций. Боб ей не нужно явно доверять Кэрол, потому что она не может восстановить одноразовый секретный ключ p без полного закрытого ключа Боба (a, b). Этот подход полезен, когда Бобу не хватает пропускной способности. или вычислительная мощность (смартфоны, аппаратные кошельки и т. д.). • В случае, если Алиса хочет доказать, что она отправила транзакцию на адрес Боба, она может либо раскрыть r или использовать любой протокол с нулевым разглашением, чтобы доказать, что она знает r (например, подписав транзакция с r). • Если Боб хочет иметь адрес, совместимый с аудитом, по которому будут связанный, он может либо опубликовать свой ключ отслеживания, либо использовать усеченный адрес. Этот адрес представляют только один открытый ec-ключ B, а оставшаяся часть, требуемая протоколом, получены из него следующим образом: a = Hs(B) и A = Hs(B)G. В обоих случаях каждый человек способен «распознать» все входящие транзакции Боба, но, конечно, никто не может потратить средства, заключенные в них без секретного ключа b. 4.4 Одноразовые кольцевые подписи Протокол, основанный на одноразовых кольцевых подписях, позволяет пользователям добиться безусловной несвязности. К сожалению, обычные типы криптографических подписей позволяют отслеживать транзакции до их соответствующие отправители и получатели. Наше решение этого недостатка заключается в использовании другой сигнатуры. типа, чем те, которые в настоящее время используются в электронных денежных системах. Сначала мы дадим общее описание нашего алгоритма без явного упоминания о нем. электронные деньги. Одноразовая кольцевая подпись содержит четыре алгоритма: (GEN, SIG, VER, LNK): GEN: принимает общедоступные параметры и выводит ec-пару (P, x) и открытый ключ I. SIG: принимает сообщение m, набор \(S'\) открытых ключей {Pi}i̸=s, пару (Ps, xs) и выводит подпись \(\sigma\). и множество \(S = \)S'\( \cup \{P_s\}\). 8
-
Боб может восстановить соответствующий одноразовый закрытый ключ: x = Hs(aR) + b, так что P = xG. Он может потратить этот выход в любое время, подписав транзакцию с помощью x. Транзакция Открытый ключ передачи Выход передачи Сумма Ключ назначения P ′ = Hs(aR)G + bG одноразовый открытый ключ х = Hs(aR) + b одноразовый закрытый ключ Получателя закрытый ключ (а, б) Р П ' ?= П Рис. 5. Проверка входящей транзакции. В результате Боб получает входящие платежи, связанные с одноразовыми открытыми ключами, которые непередаваемо для зрителя. Некоторые дополнительные примечания: • Когда Боб «узнаёт» свои транзакции (см. шаг 5), он практически использует только половину своих средств. личная информация: (a, B). Эту пару, также известную как ключ отслеживания, можно передать третьему лицу (Кэрол). Боб может делегировать ей обработку новых транзакций. Боб ей не нужно явно доверять Кэрол, потому что она не может восстановить одноразовый секретный ключ p без полного закрытого ключа Боба (a, b). Этот подход полезен, когда Бобу не хватает пропускной способности. или вычислительная мощность (смартфоны, аппаратные кошельки и т. д.). • В случае, если Алиса хочет доказать, что она отправила транзакцию на адрес Боба, она может либо раскрыть r или использовать любой протокол с нулевым разглашением, чтобы доказать, что она знает r (например, подписав транзакция с r). • Если Боб хочет иметь адрес, совместимый с аудитом, по которому будут связанный, он может либо опубликовать свой ключ отслеживания, либо использовать усеченный адрес. Этот адрес представляют только один открытый ec-ключ B, а оставшаяся часть, требуемая протоколом, получены из него следующим образом: a = Hs(B) и A = Hs(B)G. В обоих случаях каждый человек способен «распознать» все входящие транзакции Боба, но, конечно, никто не может потратить средства, заключенные в них без секретного ключа b. 4.4 Одноразовые кольцевые подписи Протокол, основанный на одноразовых кольцевых подписях, позволяет пользователям добиться безусловной несвязности. К сожалению, обычные типы криптографических подписей позволяют отслеживать транзакции до их соответствующие отправители и получатели. Наше решение этого недостатка заключается в использовании другой сигнатуры. типа, чем те, которые в настоящее время используются в электронных денежных системах. Сначала мы предоставим генераторполное описание нашего алгоритма без явной ссылки на электронные деньги. Одноразовая кольцевая подпись содержит четыре алгоритма: (GEN, SIG, VER, LNK): GEN: принимает общедоступные параметры и выводит ec-пару (P, x) и открытый ключ I. SIG: принимает сообщение m, набор \(S'\) открытых ключей {Pi}i̸=s, пару (Ps, xs) и выводит подпись \(\sigma\). и множество \(S = \)S'\( \cup \{P_s\}\). 8 15 Как здесь выглядит неизрасходованный вывод транзакции? На диаграмме видно, что выходные данные транзакции состоят только из двух точек данных: суммы и ключа назначения. Но это не достаточно, потому что, когда я попытаюсь потратить этот «выход», мне все равно нужно будет знать R=rG. Помните, r выбирается отправителем, а R а) используется для распознавания входящих криптонот как ваших собственный и б) используемый для генерации одноразового закрытого ключа, используемого для «заявки» на вашу криптоноту. Та часть, которую я не понимаю? Если принять теоретическое «хорошо, у нас есть эти подписи и транзакции, и мы передаем их туда и обратно» в мир программирования "хорошо, какая информация конкретно составляет личность UTXO?" Лучший способ ответить на этот вопрос — покопаться в теле полностью некомментированного кода. Так держать, команда bytecoin. Напомним: возможность связывания означает «отправил один и тот же человек?» а несвязность означает «сделал то же самое» человек получит?». Таким образом, система может быть подключаемой или несвязываемой, несвязываемой или несвязываемой. Раздражает, я знаю. Поэтому, когда Ник ван Саберхаген говорит здесь: «...входящие платежи [связаны] с единовременными открытые ключи, которые невозможно связать со зрителем», давайте посмотрим, что он имеет в виду. Во-первых, рассмотрим ситуацию, в которой Алиса отправляет Бобу две отдельные транзакции из одной и той же транзакции. обращение по тому же адресу. Во вселенной Bitcoin Алиса уже совершила ошибку. отправки с того же адреса, и поэтому транзакция не удалась, наше желание ограничить возможность связывания. Более того, поскольку она отправила деньги на тот же адрес, наше желание ей не удалось. для несвязности. Эта биткойн-транзакция была одновременно (полностью) привязываемой и неотключаемой. С другой стороны, предположим, что во вселенной криптонот Алиса отправляет Бобу некоторую криптоноту: используя публичный адрес Боба. В качестве своего запутанного набора открытых ключей она выбирает все известные общедоступные ключи. ключи в районе метро Вашингтона. Алекс генерирует одноразовый открытый ключ, используя свой собственный информация и общедоступная информация Боба. Она отсылает деньги, и любой наблюдатель это заметит. только смогу узнать: «Кто-то из района метро Вашингтона отправил 2,3 криптоноты на одноразовый публичный адрес XYZ123». Здесь у нас есть вероятностный контроль над возможностью связывания, поэтому мы назовем это «почти не связанным». Мы также видим только те одноразовые открытые ключи, на которые отправляются деньги. Даже если бы мы заподозрили получателя был Боб, у нас нет его закрытых ключей, поэтому мы не можем проверить, прошла ли транзакция принадлежит Бобу, не говоря уже о том, чтобы сгенерировать его одноразовый закрытый ключ для выкупа его криптоноты. Итак, это на самом деле совершенно «несовместимо». Итак, это самый изящный трюк из всех. Кто хочет по-настоящему доверять другому MtGox? Мы можем быть удобно хранить некоторое количество BTC на Coinbase, но максимальная безопасность биткойнов — это физический кошелек. Что неудобно. В этом случае вы можете без доверия отдать половину своего закрытого ключа, не ставя под угрозу свои собственная способность тратить деньги. При этом все, что вы делаете, — это рассказываете кому-то, как преодолеть несвязность. Другой свойства CN, действующие как валюта, сохраняются, например, защита от двойных расходов и еще много чего.
-
Боб может восстановить соответствующий одноразовый закрытый ключ: x = Hs(aR) + b, так что P = xG. Он может потратить этот выход в любое время, подписав транзакцию с помощью x. Транзакция Открытый ключ передачи Выход передачи Сумма Ключ назначения P ′ = Hs(aR)G + bG одноразовый открытый ключ х = Hs(aR) + b одноразовый закрытый ключ Получателя закрытый ключ (а, б) Р П ' ?= П Рис. 5. Проверка входящей транзакции. В результате Боб получает входящие платежи, связанные с одноразовыми открытыми ключами, которые непередаваемо для зрителя. Некоторые дополнительные примечания: • Когда Боб «узнаёт» свои транзакции (см. шаг 5), он практически использует только половину своих средств. личная информация: (a, B). Эту пару, также известную как ключ отслеживания, можно передать третьему лицу (Кэрол). Боб может делегировать ей обработку новых транзакций. Боб ей не нужно явно доверять Кэрол, потому что она не может восстановить одноразовый секретный ключ p без полного закрытого ключа Боба (a, b). Этот подход полезен, когда Бобу не хватает пропускной способности. или вычислительная мощность (смартфоны, аппаратные кошельки и т. д.). • В случае, если Алиса хочет доказать, что она отправила транзакцию на адрес Боба, она может либо раскрыть r или использовать любой протокол с нулевым разглашением, чтобы доказать, что она знает r (например, подписав транзакция с r). • Если Боб хочет иметь адрес, совместимый с аудитом, по которому будут связанный, он может либо опубликовать свой ключ отслеживания, либо использовать усеченный адрес. Этот адрес представляют только один открытый ec-ключ B, а оставшаяся часть, требуемая протоколом, получены из него следующим образом: a = Hs(B) и A = Hs(B)G. В обоих случаях каждый человек способен «распознать» все входящие транзакции Боба, но, конечно, никто не может потратить средства, заключенные в них без секретного ключа b. 4.4 Одноразовые кольцевые подписи Протокол, основанный на одноразовых кольцевых подписях, позволяет пользователям добиться безусловной несвязности. К сожалению, обычные типы криптографических подписей позволяют отслеживать транзакции до их соответствующие отправители и получатели. Наше решение этого недостатка заключается в использовании другой сигнатуры. типа, чем те, которые в настоящее время используются в электронных денежных системах. Сначала мы дадим общее описание нашего алгоритма без явного упоминания о нем. электронные деньги. Одноразовая кольцевая подпись содержит четыре алгоритма: (GEN, SIG, VER, LNK): GEN: принимает общедоступные параметры и выводит ec-пару (P, x) и открытый ключ I. SIG: принимает сообщение m, набор \(S'\) открытых ключей {Pi}i̸=s, пару (Ps, xs) и выводит подпись \(\sigma\). и множество \(S = \)S'\( \cup \{P_s\}\). 8
- Боб может восстановить соответствующий одноразовый закрытый ключ: x = Hs(aR) + b, так что P = xG. Он может потратить этот выход в любое время, подписав транзакцию с помощью x. Транзакция Открытый ключ передачи Выход передачи Сумма Ключ назначения P ′ = Hs(aR)G + bG одноразовый открытый ключ х = Hs(aR) + b одноразовый закрытый ключ Получателя закрытый ключ (а, б) Р П ' ?= П Рис. 5. Проверка входящей транзакции. В результате Боб получает входящие платежи, связанные с одноразовыми открытыми ключами, которые непередаваемо для зрителя. Некоторые дополнительные примечания: • Когда Боб «узнаёт» свои транзакции (см. шаг 5), он практически использует только половину своих средств. личная информация: (a, B). Эту пару, также известную как ключ отслеживания, можно передать третьему лицу (Кэрол). Боб может делегировать ей обработку новых транзакций. Боб ей не нужно явно доверять Кэрол, потому что она не может восстановить одноразовый секретный ключ p без полного закрытого ключа Боба (a, b). Этот подход полезен, когда Бобу не хватает пропускной способности. или вычислительная мощность (смартфоны, аппаратные кошельки и т. д.). • В случае, если Алиса хочет доказать, что она отправила транзакцию на адрес Боба, она может либо раскрыть r или использовать любой протокол с нулевым разглашением, чтобы доказать, что она знает r (например, подписав транзакция с r). • Если Боб хочет иметь адрес, совместимый с аудитом, по которому будут связанный, он может либо опубликовать свой ключ отслеживания, либо использовать усеченный адрес. Этот адрес представляют только один открытый ec-ключ B, а оставшаяся часть, требуемая протоколом, получены из него следующим образом: a = Hs(B) и A = Hs(B)G. В обоих случаях каждый человек способен «распознать» все входящие транзакции Боба, но, конечно, никто не может потратить средства, заключенные в них без секретного ключа b. 4.4 Одноразовые кольцевые подписи Протокол, основанный на одноразовых кольцевых подписях, позволяет пользователям добиться безусловной несвязности. К сожалению, обычные типы криптографических подписей позволяют отслеживать транзакции до их соответствующие отправители и получатели. Наше решение этого недостатка заключается в использовании другой сигнатуры. типа, чем те, которые в настоящее время используются в электронных денежных системах. Сначала мы предоставим генераторполное описание нашего алгоритма без явной ссылки на электронные деньги. Одноразовая кольцевая подпись содержит четыре алгоритма: (GEN, SIG, VER, LNK): GEN: принимает общедоступные параметры и выводит ec-пару (P, x) и открытый ключ I. SIG: принимает сообщение m, набор \(S'\) открытых ключей {Pi}i̸=s, пару (Ps, xs) и выводит подпись \(\sigma\). и множество \(S = \)S'\( \cup \{P_s\}\). 8 16 Да, теперь у нас есть а) платежный адрес и б) идентификатор платежа. Критик мог бы спросить: «А действительно ли нам нужно это делать? В конце концов, если торговец получает 112.00678952 Точно CN, и это был мой заказ, и у меня есть скриншот, или чек, или что-то еще, не так ли? безумной степени точности достаточно?" Ответ: «Может быть, большую часть времени, в повседневной жизни, личные сделки». Однако более распространенная ситуация (особенно в цифровом мире) такова: продавец продает набор объектов, каждый из которых имеет фиксированную цену. Скажем, объект A имеет плотность 0,001 CN, объект B — 0,01 CN и объект C равен 0,1 CN. Теперь, если продавец получит заказ на 1,618 CN, его будет много-много (много!) способов оформить заказ для клиента. И поэтому без какого-либо идентификатора платежа, отождествление так называемого «уникального» заказа клиента с так называемой «уникальной» стоимостью его порядок становится невозможным. Еще смешнее: если в моем интернет-магазине все стоит ровно 1,0 CN, а у меня 1000 клиентов в день? И вы хотите доказать, что купили ровно 3 объекта две недели назад? Без идентификатора платежа? Удачи, приятель. Короче говоря: когда Боб публикует платежный адрес, он может в конечном итоге также опубликовать также идентификатор платежа (см., например, депозиты Poloniex XMR). Это отличается от того, что описано в тексте здесь, где Алиса генерирует идентификатор платежа. У Боба также должен быть какой-то способ сгенерировать идентификатор платежа. (а, Б) Напомним, что ключ отслеживания (a,B) может быть опубликован; потеря тайны значения «а» будет не нарушать вашу способность тратить и не позволять людям воровать у вас (я думаю... это было бы чтобы быть доказанным), это просто позволит людям видеть все входящие транзакции. Усеченный адрес, как описано в этом параграфе, просто берет «частную» часть ключа. и генерирует его из «публичной» части. Раскрытие значения «a» устранит невозможность связывания. но сохранит остальные транзакции. Автор имеет в виду «не несвязываемый», потому что «несвязываемый» относится к получателю, а «связываемый» относится к отправителю. Также очевидно, что автор не осознавал, что существует два разных аспекта возможности связывания. Поскольку все-таки транзакция — это направленный объект на графе, то возникнет два вопроса: «Эти две транзакции отправляются одному и тому же человеку?» и «придут ли эти две транзакции от одного и того же человека?" Это политика «без возврата», согласно которой свойство отсутствия связи CryptoNote условный. То есть Боб может выбрать, чтобы его входящие транзакции были неотключаемыми. используя эту политику. Это утверждение они доказывают в рамках модели случайного оракула. Мы доберемся до этого; Случайный У Oracle есть плюсы и минусы.
VER: принимает сообщение m, набор S, подпись \(\sigma\) и выводит «истина» или «ложь». LNK: принимает набор I = {Ii}, подпись \(\sigma\) и выводит «связанный» или «независимый». Идея протокола довольно проста: пользователь создает подпись, которую можно проверяется набором открытых ключей, а не уникальным открытым ключом. Личность подписывающего лица неотличимы от других пользователей, чьи открытые ключи находятся в наборе, пока владелец не предоставит вторая подпись с использованием той же пары ключей. Закрытые ключи х0 \(\cdots\) xi \(\cdots\) хн Открытые ключи Р0 \(\cdots\) Пи \(\cdots\) пн Кольцо Подпись знак проверить Рис. 6. Анонимность кольцевой подписи. ОБЩ: подписывающая сторона выбирает случайный секретный ключ \(x \in [1, l - 1]\) и вычисляет соответствующий открытый ключ P = xG. Дополнительно он вычисляет еще один открытый ключ I = xHp(P), который мы и будем использовать. назвать «ключевым изображением». SIG: подписывающая сторона генерирует одноразовую кольцевую подпись с неинтерактивной подписью с нулевым разглашением. доказательство с использованием методов из [21]. Он выбирает случайное подмножество \(S'\) из n из числа других пользователей. открытые ключи Pi, его собственная пара ключей (x, P) и образ ключа I. Пусть \(0 \leq s \leq n\) — секретный индекс подписывающего лица. в S (так что его открытый ключ — Ps). Он выбирает случайное {ци | я = 0. . . n} и {wi | я = 0. . . n, i ̸= s} из (1 . . . l) и применяет следующие преобразования: Ли = ( циГ, если я = с киГ + вайПи, если я ̸= s Ри = ( qiHp(Пи), если я = с qiHp(Pi) + wiI, если я ̸= s Следующий шаг — получение неинтерактивного задания: c = Hs(m, L1,...,Ln, R1,...,Rn) Наконец подписывающая сторона вычисляет ответ: ци = ви, если я ̸= s с — НП я = 0 ци мод л, если я = с ри = ( ци, если я ̸= s qs -csx мод л, если я = с Результирующая сигнатура имеет вид \(\sigma = (I, c_1, \ldots, c_n, r_1, \ldots, r_n)\). 9 VER: принимает сообщение m, набор S, подпись \(\sigma\) и выводит «истина» или «ложь». LNK: принимает набор I = {Ii}, подпись \(\sigma\) и выводит «связанный» или «независимый». Идея протокола довольно проста: пользователь создает подпись, которую можно проверяется набором открытых ключей, а не уникальным открытым ключом. Личность подписывающего лица неотличимы от других пользователей, чьи открытые ключи находятся в наборе, пока владелец не предоставит вторая подпись с использованием той же пары ключей. Закрытые ключи х0 \(\cdots\) xi \(\cdots\) хн Открытые ключи Р0 \(\cdots\) Пи \(\cdots\) пн Кольцо Подпись знак проверить Рис. 6. Анонимность кольцевой подписи. ОБЩ: подписывающая сторона выбирает случайный секретный ключ \(x \in [1, l - 1]\) и вычисляет соответствующий открытый ключ P = xG. Дополнительно он вычисляет еще один открытый ключ I = xHp(P), который мы и будем использовать. назвать «ключевым изображением». SIG: подписывающая сторона генерирует одноразовую кольцевую подпись с неинтерактивной подписью с нулевым разглашением. доказательство с использованием методов из [21]. Он выбирает случайное подмножество \(S'\) из n из числа других пользователей. открытые ключи Pi, его собственная пара ключей (x, P) и образ ключа I. Пусть \(0 \leq s \leq n\) — секретный индекс подписывающего лица. в S (так что его открытый ключ — Ps). Он выбирает случайное {ци | я = 0. . . n} и {wi | я = 0. . . n, i ̸= s} из (1 . . . l) и применяет следующие преобразования: Ли = ( циГ, если я = с киГ + вайПи, если я ̸= s Ри = ( qiHp(Пи), если я = с qiHp(Pi) + wiI, если я ̸= s Следующий шаг — получение неинтерактивного задания: c = Hs(m, L1,...,Ln, R1,...,Rn) Наконец подписывающая сторона вычисляет ответ: ци = ви, если я ̸= s с — НП я = 0 ци мод л, если я = с ри = ( ци, если я ̸= s qs -csx мод л, если я = с Результирующая сигнатура имеет вид \(\sigma = (I, c_1, \ldots, c_n, r_1, \ldots, r_n)\). 9 17 Возможно, это глупо, но при объединении S и P_s нужно соблюдать осторожность. Если вы просто добавите последний открытый ключ до конца, невозможность связывания нарушена, поскольку любой проверяет проходящие транзакции можно просто проверить последний открытый ключ, указанный в каждой транзакции, и бум. Это открытый ключ связанный с отправителем. Таким образом, после объединения необходимо использовать генератор псевдослучайных чисел. используется для перестановки выбранных открытых ключей. «...пока владелец не создаст вторую подпись, используя ту же пару ключей». Желаю автору(ам?) подробнее об этом. Я считаю, что это означает: «Убедитесь, что каждый раз, когда вы выбираете набор открытых ключей для запутывания самостоятельно, вы выбираете совершенно новый набор, в котором нет двух одинаковых ключей». довольно сильное условие для невозможности соединения. Возможно, «вы выбираете новый случайный набор из все возможные ключи» с предположением, что хотя и нетривиальные пересечения неизбежно случаются, они случаются не часто. В любом случае, мне нужно углубиться в это утверждение. Это генерирует кольцевую подпись. Доказательства с нулевым разглашением — это потрясающе: я призываю вас доказать мне, что вы знаете секрет не раскрывая тайны. Например, предположим, что мы находимся у входа в пещеру в форме пончика. а в задней части пещеры (вне поля зрения входа) находится одверь, к которой ты утверждайте, что у вас есть ключ. Если ты пойдешь в одном направлении, тебя всегда пропустят, но если ты пойдешь в другом в другом направлении, вам нужен ключ. Но ты даже не хочешь ПОКАЗАТЬ мне ключ, не говоря уже о покажи мне, что он открывает дверь. Но ты хочешь доказать мне, что знаешь, как открыть дверь. В интерактивной обстановке я подбрасываю монетку. Орел слева, решка справа, и вы идете вниз по пещера в форме пончика, куда бы вас ни направила монета. Сзади, вне моего поля зрения, ты откройте дверь, чтобы вернуться с другой стороны. Повторяем эксперимент с подбрасыванием монеты. пока я не удостоверюсь, что у вас есть ключ. Но это явно ИНТЕРАКТИВНОЕ доказательство с нулевым разглашением. Есть неинтерактивные версии, в которых нам с вами никогда не придется общаться; таким образом, никакие подслушивающие устройства не смогут вмешаться. http://en.wikipedia.org/wiki/Zero-knowledge_proof Это противоположное предыдущему определению.
VER: принимает сообщение m, набор S, подпись \(\sigma\) и выводит «истина» или «ложь». LNK: принимает набор I = {Ii}, подпись \(\sigma\) и выводит «связанный» или «независимый». Идея протокола довольно проста: пользователь создает подпись, которую можно проверяется набором открытых ключей, а не уникальным открытым ключом. Личность подписывающего лица неотличимы от других пользователей, чьи открытые ключи находятся в наборе, пока владелец не предоставит вторая подпись с использованием той же пары ключей. Закрытые ключи х0 \(\cdots\) xi \(\cdots\) хн Открытые ключи Р0 \(\cdots\) Пи \(\cdots\) пн Кольцо Подпись знак проверить Рис. 6. Анонимность кольцевой подписи. ОБЩ: подписывающая сторона выбирает случайный секретный ключ \(x \in [1, l - 1]\) и вычисляет соответствующий открытый ключ P = xG. Дополнительно он вычисляет еще один открытый ключ I = xHp(P), который мы и будем использовать. назвать «ключевым изображением». SIG: подписывающая сторона генерирует одноразовую кольцевую подпись с неинтерактивной подписью с нулевым разглашением. доказательство с использованием методов из [21]. Он выбирает случайное подмножество \(S'\) из n из числа других пользователей. открытые ключи Pi, его собственная пара ключей (x, P) и образ ключа I. Пусть \(0 \leq s \leq n\) — секретный индекс подписывающего лица. в S (так что его открытый ключ — Ps). Он выбирает случайное {ци | я = 0. . . n} и {wi | я = 0. . . n, i ̸= s} из (1 . . . l) и применяет следующие преобразования: Ли = ( циГ, если я = с киГ + вайПи, если я ̸= s Ри = ( qiHp(Пи), если я = с qiHp(Pi) + wiI, если я ̸= s Следующий шаг — получение неинтерактивного задания: c = Hs(m, L1,...,Ln, R1,...,Rn) Наконец подписывающая сторона вычисляет ответ: ци = ви, если я ̸= s с — НП я = 0 ци мод л, если я = с ри = ( ци, если я ̸= s qs -csx мод л, если я = с Результирующая сигнатура имеет вид \(\sigma = (I, c_1, \ldots, c_n, r_1, \ldots, r_n)\). 9 VER: принимает сообщение m, набор S, подпись \(\sigma\) и выводит «истина» или «ложь». LNK: принимает набор I = {Ii}, подпись \(\sigma\) и выводит «связанный» или «независимый». Идея протокола довольно проста: пользователь создает подпись, которую можно проверяется набором открытых ключей, а не уникальным открытым ключом. Личность подписывающего лица неотличимы от других пользователей, чьи открытые ключи находятся в наборе, пока владелец не предоставит вторая подпись с использованием той же пары ключей. Закрытые ключи х0 \(\cdots\) xi \(\cdots\) хн Открытые ключи Р0 \(\cdots\) Пи \(\cdots\) пн Кольцо Подпись знак проверить Рис. 6. Анонимность кольцевой подписи. ОБЩ: подписывающая сторона выбирает случайный секретный ключ \(x \in [1, l - 1]\) и вычисляет соответствующий открытый ключ P = xG. Дополнительно он вычисляет еще один открытый ключ I = xHp(P), который мы и будем использовать. назвать «ключевым изображением». SIG: подписывающая сторона генерирует одноразовую кольцевую подпись с неинтерактивной подписью с нулевым разглашением. доказательство с использованием методов из [21]. Он выбирает случайное подмножество \(S'\) из n из числа других пользователей. открытые ключи Pi, его собственная пара ключей (x, P) и образ ключа I. Пусть \(0 \leq s \leq n\) — секретный индекс подписывающего лица. в S (так что его открытый ключ — Ps). Он выбирает случайное {ци | я = 0. . . n} и {wi | я = 0. . . n, i ̸= s} из (1 . . . l) и применяет следующие преобразования: Ли = ( циГ, если я = с киГ + вайПи, если я ̸= s Ри = ( qiHp(Пи), если я = с qiHp(Pi) + wiI, если я ̸= s Следующий шаг — получение неинтерактивного задания: c = Hs(m, L1,...,Ln, R1,...,Rn) Наконец подписывающая сторона вычисляет ответ: ци = ви, если я ̸= s с — НП я = 0 ци мод л, если я = с ри = ( ци, если я ̸= s qs -csx мод л, если я = с Результирующая сигнатура имеет вид \(\sigma = (I, c_1, \ldots, c_n, r_1, \ldots, r_n)\). 9 18 Вся эта область не зависит от криптонот, просто описывая алгоритм кольцевой подписи без ссылка на валюты. Я подозреваю, что некоторые обозначения совпадают с остальной частью статьи. хотя. Например, x — это «случайный» секретный ключ, выбранный в GEN, который дает открытый ключ P. и изображение открытого ключа I. Это значение x — это значение, которое Боб вычисляет в части 6 на странице 8. Итак, это начинаю прояснять некоторую путаницу из предыдущего описания. Это круто; деньги не переводятся с публичного адреса Алисы на публичный адрес Боба. адрес." Он пересылается с одноразового адреса на одноразовый адрес. В каком-то смысле вот как все работает. Если у Алекса есть криптоноты, потому что кто-то отправила их ей, это означает, что у нее есть секретные ключи, необходимые для отправки их Бобу. Она использует обмен Диффе-Хеллманом с использованием общедоступной информации Боба для создания нового одноразового адреса и криптоноты передаются на этот адрес. Теперь, поскольку для генерации нового одноразового адреса использовался (предположительно безопасный) обмен DH на который Алекс отправила свой CN, Боб — единственный, у кого есть закрытые ключи, необходимые для повторения выше. Итак, теперь Боб — это Алекс. http://en.wikipedia.org/wiki/Piecewise#Notation_and_interpretation Суммирование должно индексироваться по j, а не по i. Каждый c_i является случайным мусором (поскольку w_i является случайным) кроме задницы c_iсвязан с фактическим ключом, включенным в эту подпись. Значение c равно hash предыдущей информации. Я думаю, что это может содержать опечатку, более серьезную, чем повторное использование индекса «i», потому что c_s кажется определяться имплицитно, а не эксплицитно. Действительно, если принять это уравнение на веру, то мы определим, что c_s = (1/2)c - (1/2) sum_i neq s c_i. То есть hash минус целая куча случайных чисел. С другой стороны, если это суммирование предназначено для чтения «c_s = (c — sum_j neq s c_j) mod l", затем мы берем hash нашей предыдущей информации, генерируем группу случайных чисел, вычтите все эти случайные числа из hash, и это даст нам c_s. Кажется, это то, что «должно» происходить, исходя из моей интуиции, и соответствует шагу проверки на странице 10. Но интуиция – это не математика. Я углублюсь в это. То же, что и раньше; все это будет случайным мусором, за исключением того, что связано с настоящим открытый ключ подписывающего лица x. За исключением этого раза, это больше, чем я ожидал от структуры: r_i является случайным для i!=s, а r_s определяется только секретным x и индексированными значениями s q_i и c_i.
VER: Верификатор проверяет подпись, применяя обратные преобразования: ( Л' я = riG + ciPi Р' я = riHp(Pi) + ciI Наконец, проверяющий проверяет, НП я = 0 ци ?= Hs(m, L′ 0, . . . , Л' п, Р' 0, . . . , Р' п) мод л Если это равенство верно, верификатор запускает алгоритм LNK. В противном случае проверяющий отклоняет подпись. LNK: верификатор проверяет, использовалось ли I в прошлых подписях (эти значения хранятся в набор И). Многократное использование подразумевает, что две подписи были созданы под одним и тем же секретным ключом. Смысл протокола: применяя L-преобразования, подписывающий доказывает, что он знает такой x, что хотя бы один Pi = xG. Чтобы сделать это доказательство неповторяемым, введем ключевой образ поскольку I = xHp(P). Подписавшийся использует те же коэффициенты (ri, ci), чтобы доказать почти одно и то же утверждение: он знает такой x, что хотя бы один \(H_p(P_i) = I \cdot x^{-1}\). Если отображение \(x \to I\) является инъекцией: 1. Никто не может восстановить открытый ключ по образу ключа и идентифицировать подписавшего; 2. Подписавшийся не может поставить две подписи с разными I и одним и тем же x. Полный анализ безопасности представлен в Приложении А. 4,5 Стандартная транзакция CryptoNote Комбинируя оба метода (непривязываемые открытые ключи и неотслеживаемую кольцевую подпись), Боб достигает новый уровень конфиденциальности по сравнению с исходной схемой Bitcoin. Требуется, чтобы он хранил только один закрытый ключ (a, b) и публикацию (A, B), чтобы начать получать и отправлять анонимные транзакции. При проверке каждой транзакции Боб дополнительно выполняет только два умножения эллиптической кривой и одно сложение на каждый выход, чтобы проверить, принадлежит ли ему транзакция. Для каждого его вывод Боб восстанавливает одноразовую пару ключей (pi, Pi) и сохраняет ее в своем кошельке. Любые входы могут быть косвенно доказано, что они принадлежат одному и тому же владельцу только в том случае, если они фигурируют в одной сделке. В На самом деле эту связь гораздо сложнее установить из-за одноразовой кольцевой подписи. С помощью кольцевой подписи Боб может эффективно скрыть все вводимые данные среди чужих; все возможно потратители будут равновероятны, даже предыдущий владелец (Алиса) располагает не большей информацией, чем любой наблюдатель. Подписывая свою транзакцию, Боб указывает n зарубежных выходов на ту же сумму, что и его вывод, смешивая их все без участия других пользователей. Сам Боб (а также кто-либо еще) не знает, были ли потрачены какие-либо из этих платежей: результат можно использовать в тысячах подписей как фактор двусмысленности, а не как цель сокрытия. Двойной Проверка расходов происходит на этапе LNK при проверке по используемому набору ключевых изображений. Боб может выбрать степень неоднозначности самостоятельно: n = 1 означает, что вероятность, которую он имеет потраченный выход имеет вероятность 50%, n = 99 дает 1%. Размер полученной подписи увеличивается линейно как O(n+1), поэтому улучшение анонимности обходится Бобу дополнительными комиссиями за транзакцию. Он также может установите n = 0 и сделайте его кольцевую подпись состоящей только из одного элемента, однако это мгновенно раскрыть его как транжиру. 10 VER: Верификатор проверяет подпись, применяя обратные преобразования: ( Л' я = riG + ciPi Р' я = riHp(Pi) + ciI Наконец, проверяющий проверяет, НП я = 0 ци ?= Hs(m, L′ 0, . . . , Л' п, Р' 0, . . . , Р' п) мод л Если это равенство верно, верификатор запускает алгоритм LNK. В противном случае проверяющий отклоняет подпись. LNK: верификатор проверяет, использовалось ли I в прошлых подписях (эти значения хранятся в набор И). Многократное использование подразумевает, что две подписи были созданы под одним и тем же секретным ключом. Смысл протокола: применяя L-преобразования, подписывающий доказывает, что он знает такой x, что хотя бы один Pi = xG. Чтобы сделать это доказательство неповторяемым, введем ключевой образ поскольку I = xHp(P). Подписавшийся использует те же коэффициенты (ri, ci), чтобы доказать почти одно и то же утверждение: он знает такой x, что хотя бы один \(H_p(P_i) = I \cdot x^{-1}\). Если отображение \(x \to I\) является инъекцией: 1. Никто не может восстановить открытый ключ по образу ключа и идентифицировать подписавшего; 2. Подписавшийся не может поставить две подписи с разными I и одним и тем же x. Полный анализ безопасности представлен в Приложении А. 4,5 Стандартная транзакция CryptoNote Комбинируя оба метода (непривязываемые открытые ключи и неотслеживаемую кольцевую подпись), Боб достигает новый уровень конфиденциальности по сравнению с исходной схемой Bitcoin. Требуется, чтобы он хранил только один закрытый ключ (a, b) и публикацию (A, B), чтобы начать получать и отправлять анонимные транзакции. При проверке каждой транзакции Боб дополнительно выполняет только два умножения эллиптической кривой и одно сложение на каждый выход, чтобы проверить, принадлежит ли ему транзакция. Для каждого его вывод Боб восстанавливает одноразовую пару ключей (pi, Pi) и stхранит это в своем кошельке. Любые входы могут быть косвенно доказано, что они принадлежат одному и тому же владельцу только в том случае, если они фигурируют в одной сделке. В На самом деле эту связь гораздо сложнее установить из-за одноразовой кольцевой подписи. С помощью кольцевой подписи Боб может эффективно скрыть все вводимые данные среди чужих; все возможно потратители будут равновероятны, даже предыдущий владелец (Алиса) располагает не большей информацией, чем любой наблюдатель. Подписывая свою транзакцию, Боб указывает n зарубежных выходов на ту же сумму, что и его вывод, смешивая их все без участия других пользователей. Сам Боб (а также кто-либо еще) не знает, были ли потрачены какие-либо из этих платежей: результат можно использовать в тысячах подписей как фактор двусмысленности, а не как цель сокрытия. Двойной Проверка расходов происходит на этапе LNK при проверке по используемому набору ключевых изображений. Боб может выбрать степень неоднозначности самостоятельно: n = 1 означает, что вероятность, которую он имеет потраченный выход имеет вероятность 50%, n = 99 дает 1%. Размер полученной подписи увеличивается линейно как O(n+1), поэтому улучшение анонимности обходится Бобу дополнительными комиссиями за транзакцию. Он также может установите n = 0 и сделайте его кольцевую подпись состоящей только из одного элемента, однако это мгновенно раскрыть его как транжиру. 10 19 В этот момент я ужасно запутался. Алекс получает сообщение M с подписью (I,c_1, ..., c_n, r_1, ..., r_n) и списком публичных клавиши S. и она запускает VER. Это вычислит L_i’ и R_i’ Это подтверждает, что c_s = c - sum_i neq s c_i на предыдущей странице. Сначала я был ОЧЕНЬ (ха) в замешательстве. Любой может вычислить L_i’ и R_i’. Действительно, каждый r_i и c_i опубликовано в подписи сигма вместе со значением I. Набор S = P_i всех открытых ключей также был опубликован. Так что любой, кто видел Сигму и набор ключи S = P_i получат одинаковые значения для L_i’ и R_i’ и, следовательно, проверят подпись. Но потом я вспомнил, что этот раздел просто описывает алгоритм подписи, а не «проверку». если подписано, проверьте, ОТПРАВЛЕНО МНЕ, и если да, то идите тратить деньги». Это ПРОСТО фирменная часть игры. Мне интересно прочитать Приложение А, когда я наконец туда доберусь. Я хотел бы увидеть полномасштабное сравнение Cryptonote по операциям с Bitcoin. А также электричество/устойчивое развитие. Какие части алгоритмов здесь представляют собой «входные данные»? Я полагаю, что входные данные транзакции представляют собой сумму и набор UTXO, сумма которых превышает сумму Сумма. Это неясно. «Цель спряталась?» Я думал об этом уже несколько минут, но до сих пор не понял. смутное представление о том, что это могло означать. Атака двойного расходования может быть выполнена только путем манипулирования предполагаемым используемым ключом узла. набор изображений \(I\). «Степень неоднозначности» = n, но общее количество открытых ключей, включенных в транзакцию, равно п+1. Другими словами, степень двусмысленности будет такой: «Сколько ДРУГИХ людей вы хотите видеть в группе?» толпа?" Ответ, вероятно, будет по умолчанию «как можно больше».
VER: Верификатор проверяет подпись, применяя обратные преобразования: ( Л' я = riG + ciPi Р' я = riHp(Pi) + ciI Наконец, проверяющий проверяет, НП я = 0 ци ?= Hs(m, L′ 0, . . . , Л' п, Р' 0, . . . , Р' п) мод л Если это равенство верно, верификатор запускает алгоритм LNK. В противном случае проверяющий отклоняет подпись. LNK: верификатор проверяет, использовалось ли I в прошлых подписях (эти значения хранятся в набор И). Многократное использование подразумевает, что две подписи были созданы под одним и тем же секретным ключом. Смысл протокола: применяя L-преобразования, подписывающий доказывает, что он знает такой x, что хотя бы один Pi = xG. Чтобы сделать это доказательство неповторяемым, введем ключевой образ поскольку I = xHp(P). Подписавшийся использует те же коэффициенты (ri, ci), чтобы доказать почти одно и то же утверждение: он знает такой x, что хотя бы один \(H_p(P_i) = I \cdot x^{-1}\). Если отображение \(x \to I\) является инъекцией: 1. Никто не может восстановить открытый ключ по образу ключа и идентифицировать подписавшего; 2. Подписавшийся не может поставить две подписи с разными I и одним и тем же x. Полный анализ безопасности представлен в Приложении А. 4,5 Стандартная транзакция CryptoNote Комбинируя оба метода (непривязываемые открытые ключи и неотслеживаемую кольцевую подпись), Боб достигает новый уровень конфиденциальности по сравнению с исходной схемой Bitcoin. Требуется, чтобы он хранил только один закрытый ключ (a, b) и публикацию (A, B), чтобы начать получать и отправлять анонимные транзакции. При проверке каждой транзакции Боб дополнительно выполняет только два умножения эллиптической кривой и одно сложение на каждый выход, чтобы проверить, принадлежит ли ему транзакция. Для каждого его вывод Боб восстанавливает одноразовую пару ключей (pi, Pi) и сохраняет ее в своем кошельке. Любые входы могут быть косвенно доказано, что они принадлежат одному и тому же владельцу только в том случае, если они фигурируют в одной сделке. В На самом деле эту связь гораздо сложнее установить из-за одноразовой кольцевой подписи. С помощью кольцевой подписи Боб может эффективно скрыть все вводимые данные среди чужих; все возможно потратители будут равновероятны, даже предыдущий владелец (Алиса) располагает не большей информацией, чем любой наблюдатель. Подписывая свою транзакцию, Боб указывает n зарубежных выходов на ту же сумму, что и его вывод, смешивая их все без участия других пользователей. Сам Боб (а также кто-либо еще) не знает, были ли потрачены какие-либо из этих платежей: результат можно использовать в тысячах подписей как фактор двусмысленности, а не как цель сокрытия. Двойной Проверка расходов происходит на этапе LNK при проверке по используемому набору ключевых изображений. Боб может выбрать степень неоднозначности самостоятельно: n = 1 означает, что вероятность, которую он имеет потраченный выход имеет вероятность 50%, n = 99 дает 1%. Размер полученной подписи увеличивается линейно как O(n+1), поэтому улучшение анонимности обходится Бобу дополнительными комиссиями за транзакцию. Он также может установите n = 0 и сделайте его кольцевую подпись состоящей только из одного элемента, однако это мгновенно раскрыть его как транжиру. 10 VER: Верификатор проверяет подпись, применяя обратные преобразования: ( Л' я = riG + ciPi Р' я = riHp(Pi) + ciI Наконец, проверяющий проверяет, НП я = 0 ци ?= Hs(m, L′ 0, . . . , Л' п, Р' 0, . . . , Р' п) мод л Если это равенство верно, верификатор запускает алгоритм LNK. В противном случае проверяющий отклоняет подпись. LNK: верификатор проверяет, использовалось ли I в прошлых подписях (эти значения хранятся в набор И). Многократное использование подразумевает, что две подписи были созданы под одним и тем же секретным ключом. Смысл протокола: применяя L-преобразования, подписывающий доказывает, что он знает такой x, что хотя бы один Pi = xG. Чтобы сделать это доказательство неповторяемым, введем ключевой образ поскольку I = xHp(P). Подписавшийся использует те же коэффициенты (ri, ci), чтобы доказать почти одно и то же утверждение: он знает такой x, что хотя бы один \(H_p(P_i) = I \cdot x^{-1}\). Если отображение \(x \to I\) является инъекцией: 1. Никто не может восстановить открытый ключ по образу ключа и идентифицировать подписавшего; 2. Подписавшийся не может поставить две подписи с разными I и одним и тем же x. Полный анализ безопасности представлен в Приложении А. 4,5 Стандартная транзакция CryptoNote Комбинируя оба метода (непривязываемые открытые ключи и неотслеживаемую кольцевую подпись), Боб достигает новый уровень конфиденциальности по сравнению с исходной схемой Bitcoin. Требуется, чтобы он хранил только один закрытый ключ (a, b) и публикацию (A, B), чтобы начать получать и отправлять анонимные транзакции. При проверке каждой транзакции Боб дополнительно выполняет только два умножения эллиптической кривой и одно сложение на каждый выход, чтобы проверить, принадлежит ли ему транзакция. Для каждого его вывод Боб восстанавливает одноразовую пару ключей (pi, Pi) и stхранит это в своем кошельке. Любые входы могут быть косвенно доказано, что они принадлежат одному и тому же владельцу только в том случае, если они фигурируют в одной сделке. В На самом деле эту связь гораздо сложнее установить из-за одноразовой кольцевой подписи. С помощью кольцевой подписи Боб может эффективно скрыть все вводимые данные среди чужих; все возможно потратители будут равновероятны, даже предыдущий владелец (Алиса) располагает не большей информацией, чем любой наблюдатель. Подписывая свою транзакцию, Боб указывает n зарубежных выходов на ту же сумму, что и его вывод, смешивая их все без участия других пользователей. Сам Боб (а также кто-либо еще) не знает, были ли потрачены какие-либо из этих платежей: результат можно использовать в тысячах подписей как фактор двусмысленности, а не как цель сокрытия. Двойной Проверка расходов происходит на этапе LNK при проверке по используемому набору ключевых изображений. Боб может выбрать степень неоднозначности самостоятельно: n = 1 означает, что вероятность, которую он имеет потраченный выход имеет вероятность 50%, n = 99 дает 1%. Размер полученной подписи увеличивается линейно как O(n+1), поэтому улучшение анонимности обходится Бобу дополнительными комиссиями за транзакцию. Он также может установите n = 0 и сделайте его кольцевую подпись состоящей только из одного элемента, однако это мгновенно раскрыть его как транжиру. 10 20 Это интересно; ранее мы предоставили получателю Бобу возможность отправлять все ВХОДЯЩИЕ транзакции не могут быть отсоединены либо путем детерминированного выбора половины его закрытых ключей, либо путем опубликовав половину своих личных ключей как публичные. Это своего рода политика без пути назад. Здесь мы видим способ отправителя Алекса выбрать одну исходящую транзакцию как связанную, но на самом деле это раскрывает Алекса как отправителя всей сети. Это НЕ политика безвозвратного пути. Это транзакция за транзакцией. Есть ли третья политика? Может ли получатель, Боб, создать для Алекса уникальный идентификатор платежа, который никогда не меняется, возможно, используя обмен Диффе-Хеллмана? Если кто-нибудь включит этот платеж Идентификатор, указанный где-то в ее транзакции на адрес Боба, он, должно быть, исходил от Алекса. Таким образом, Алексу не нужно раскрывать себя всей сети, выбирая ссылку на конкретный транзакцию, но она все равно может идентифицировать себя с человеком, которому она отправляет свои деньги. Разве не это делает Poloniex?
Транзакция Вход передачи Выход0 . . . Выходные данные . . . Выходной Ключевое изображение Подписи Кольцевая подпись Ключ назначения Выход1 Ключ назначения Выходной Зарубежные операции Вывод отправителя Ключ назначения Одноразовая пара ключей Одноразовый закрытый ключ Я = хГП(П) П, х Рис. 7. Генерация кольцевой подписи в стандартной транзакции. 5 Эгалитарное доказательство работы В этом разделе мы предлагаем и обосновываем новый алгоритм proof-of-work. Наша основная цель заключается в сокращении разрыва между майнерами CPU (большинство) и GPU/FPGA/ASIC (меньшинство). Это уместно, что некоторые пользователи могут иметь определенное преимущество перед другими, но их инвестиции должно расти по крайней мере линейно с мощностью. В более общем смысле, производство устройств специального назначения. должна быть как можно менее прибыльной. 5.1 Связанные работы Исходный протокол Bitcoin proof-of-work использует функцию ценообразования с интенсивным использованием ЦП SHA-256. Он в основном состоит из основных логических операторов и полагается исключительно на скорость вычислений. процессор, поэтому идеально подходит для многоядерной/конвейерной реализации. Однако современные компьютеры ограничены не только количеством операций в секунду. но и по размеру памяти. Хотя некоторые процессоры могут быть значительно быстрее других [8], размеры памяти вряд ли будут различаться между машинами. Ценовые функции, связанные с памятью, были впервые введены Абади и др. и определены как «функции, время вычисления которых во многом зависит от времени, затрачиваемого на доступ к памяти» [15]. Основная идея заключается в построении алгоритма, выделяющего большой блок данных («блокнот»). в памяти, доступ к которой возможен относительно медленно (например, ОЗУ) и «доступ к непредсказуемая последовательность локаций» внутри него. Блок должен быть достаточно большим, чтобы можно было сохранить данные более выгодны, чем пересчитывать их для каждого доступа. Алгоритм также должен предотвратить внутренний параллелизм, следовательно, N одновременных потоков должны требовать в N раз больше памяти сразу. Дворк и др. [22] исследовали и формализовали этот подход, что привело их к предложению другого вариант функции ценообразования: «Mbound». Еще одна работа принадлежит Ф. Коэльо [20], который 11 Транзакция Вход передачи Выход0 . . . Выходные данные . . . Выходной Ключевое изображение Подписи Кольцевая подпись Ключ назначения Выход1 Ключ назначения Выходной Зарубежные сделки Вывод отправителя Ключ назначения Одноразовая пара ключей Одноразовый закрытый ключ Я = хГП(П) П, х Рис. 7. Генерация кольцевой подписи в стандартной транзакции. 5 Эгалитарное доказательство работы В этом разделе мы предлагаем и обосновываем новый алгоритм proof-of-work. Наша основная цель заключается в сокращении разрыва между майнерами CPU (большинство) и GPU/FPGA/ASIC (меньшинство). Это уместно, что некоторые пользователи могут иметь определенное преимущество перед другими, но их инвестиции должно расти по крайней мере линейно с мощностью. В более общем смысле, производство устройств специального назначения. должна быть как можно менее прибыльной. 5.1 Связанные работы Исходный протокол Bitcoin proof-of-work использует функцию ценообразования с интенсивным использованием ЦП SHA-256. Он в основном состоит из основных логических операторов и полагается исключительно на скорость вычислений. процессор, поэтому идеально подходит для многоядерной/конвейерной реализации. Однако современные компьютеры ограничены не только количеством операций в секунду. но и по размеру памяти. Хотя некоторые процессоры могут быть значительно быстрее других [8], размеры памяти вряд ли будут различаться между машинами. Ценовые функции, связанные с памятью, были впервые введены Абади и др. и определены как «функции, время вычислений которых во многом зависит от времени, затрачиваемого на доступ к памяти» [15]. Основная идея заключается в построении алгоритма, выделяющего большой блок данных («блокнот»). в памяти, доступ к которой возможен относительно медленно (например, ОЗУ) и «доступ к непредсказуемая последовательность локаций» внутри него. Блок должен быть достаточно большим, чтобы можно было сохранить данные более выгодны, чем пересчитывать их для каждого доступа. Алгоритм также должен предотвратить внутренний параллелизм, следовательно, N одновременных потоков должны требовать в N раз больше памяти сразу. Дворк и др. [22] исследовали и формализовали этот подход, что привело их к предложению другого вариант функции ценообразования: «Mbound». Еще одна работа принадлежит Ф. Коэльо [20], который 11 21 Это, якобы, наши UTXO: суммы и ключи назначения. Если Алекс создает эту стандартную транзакцию и отправляет ее Бобу, то у Алекса также есть закрытые ключи. каждому из них. Мне очень нравится эта диаграмма, потому что она отвечает на некоторые предыдущие вопросы. Вход Txn состоит из набора выходов Txn и key изображение. Затем он подписывается кольцевой подписью, включая все личных ключей, которыми владеет Алекс, ко всем зарубежным транзакциям, включенным в сделку. Вывод Txn состоит из суммы и ключа назначения. Получатель транзакции может: по своему желанию генерировать свой одноразовый закрытый ключ, как описано ранее в статье, чтобы потратить деньги. Будет приятно узнать, насколько это соответствует реальному коду... Нет, Ник ван Саберхаген в общих чертах описывает некоторые свойства алгоритма доказательства работы: без фактического описания этого алгоритма. Сам алгоритм CryptoNight ТРЕБУЕТ глубокого анализа. Когда я это прочитал, я заикался. Должны ли инвестиции расти хотя бы линейно с ростом власти, или же следует инвестиции растут максимум линейно с ростом мощности? И тогда я понял; Я, как майнер или инвестор, обычно думаю о том, «сколько энергии я могу получить». для инвестиций?» а не «сколько инвестиций требуется для фиксированного количества энергии?» Конечно, обозначим инвестиции через I, а мощность через P. Если I(P) — это инвестиции как функция мощности а P(I) — мощность как функция инвестиций, они будут обратными друг другу (где бы то ни было). обратные могут существовать). И если I(P) быстрее линейного, чем P(I) медленнее линейного. Следовательно, будет снижена норма прибыли для инвесторов. То есть автор здесь говорит следующее: «конечно, чем больше вы вкладываете, тем больше и получаете». мощность. Но мы должны попытаться добиться снижения нормы прибыли». В конечном итоге инвестиции в процессоры окажутся сублинейными; вопрос в том, являются ли авторы разработали алгоритм POW, который заставит ASIC также делать это. Должна ли гипотетическая «валюта будущего» всегда майнить с использованием самых медленных/наиболее ограниченных ресурсов? Статья Абади и др. (авторами которой являются несколько инженеров Google и Microsoft): по сути, используя тот факт, что за последние несколько лет объем памяти был намного меньше разница между машинами превышает скорость процессора, а соотношение инвестиций к мощности более чем линейное. Через несколько лет, возможно, придется переоценить это! Всё это гонка вооружений... Создать функцию hash сложно; создание функции hash, удовлетворяющей этим ограничениям, кажется более сложной задачей. Эта статья, похоже, не содержит объяснения фактического hashалгоритм CryptoNight. Я думаю, что это реализация SHA-3 с жесткими требованиями к памяти, основанная в сообщениях на форуме, но я понятия не имею... и в этом вся суть. Это необходимо объяснить.
предложил наиболее эффективное решение: «Хоккайдо». Насколько нам известно, последней работой, основанной на идее псевдослучайного поиска в большом массиве, является алгоритм, известный как «scrypt» К. Персиваля [32]. В отличие от предыдущих функций, он фокусируется на получение ключа, а не системы proof-of-work. Несмотря на этот факт, скрипт может служить нашей цели: она хорошо работает как функция ценообразования в задаче частичного преобразования hash, такой как SHA-256 в Bitcoin. На данный момент scrypt уже применяется в Litecoin [14] и некоторых других ветвях Bitcoin. Однако его реализация на самом деле не привязана к памяти: соотношение «время доступа к памяти/общее time» недостаточно велик, поскольку каждый экземпляр использует только 128 КБ. Это позволяет майнерам с графическим процессором быть примерно в 10 раз более эффективным и продолжает оставлять возможность создания относительно дешевые, но высокоэффективные устройства для майнинга. Более того, сама конструкция сценария допускает линейный компромисс между размером памяти и Скорость процессора обусловлена тем, что каждый блок в блокноте является производным только от предыдущего. Например, вы можете хранить каждый второй блок и пересчитывать остальные ленивым способом, т.е. только когда это станет необходимым. Предполагается, что псевдослучайные индексы распределены равномерно. следовательно, ожидаемое значение пересчетов дополнительных блоков равно 1 \(2 \cdot N\), где N – число итераций. Общее время вычислений увеличивается менее чем вдвое, поскольку имеются также независимые от времени (постоянное время) операции, такие как подготовка блокнота и hashвключение каждую итерацию. Сохранение 2/3 памяти стоит 1 3 \(\cdot\) Н + 1 3 \(\cdot\) \(2 \cdot N\) = N дополнительных пересчетов; 9/10 в результате 1 10 \(\cdot\) Н + . . . + 1 10 \(\cdot\) 9 \(\cdot\) Н = 4,5 Н. Легко показать, что сохранение только 1 s всех блоков увеличивает время менее чем в с−1 раз. 2 . Это, в свою очередь, означает, что машина с процессором В 200 раз быстрее, чем современные чипы могут хранить всего 320 байт блокнота. 5.2 Предлагаемый алгоритм Мы предлагаем новый алгоритм с привязкой к памяти для функции ценообразования proof-of-work. Это зависит от произвольный доступ к медленной памяти и подчеркивает зависимость от задержки. В отличие от сценария каждого новый блок (длиной 64 байта) зависит от всех предыдущих блоков. В результате гипотетический «Экономия памяти» должна увеличить скорость вычислений в геометрической прогрессии. Наш алгоритм требует около 2 Мб на экземпляр по следующим причинам: 1. Он помещается в кэш L3 (на ядро) современных процессоров, которые должны стать массовыми. через несколько лет; 2. Мегабайт внутренней памяти — практически неприемлемый размер для современного ASIC-конвейера; 3. На графических процессорах могут одновременно работать сотни экземпляров, но они ограничены в других отношениях: Память GDDR5 медленнее кэша CPU L3 и отличается своей пропускной способностью, а не Скорость произвольного доступа. 4. Значительное расширение блокнота потребует увеличения количества итераций, что в ход подразумевает общее увеличение времени. «Тяжелые» вызовы в ненадежной p2p-сети могут привести к серьезные уязвимости, поскольку узлы обязаны проверять proof-of-work каждого нового блока. Если узел тратит значительное количество времени на каждую оценку hash, его можно легко DDoS-атака вызвана потоком поддельных объектов с произвольными рабочими данными (значения nonce). 12 предложил наиболее эффективное решение: «Хоккайдо». Насколько нам известно, последней работой, основанной на идее псевдослучайного поиска в большом массиве, является алгоритм, известный как «scrypt» К. Персиваля [32]. В отличие от предыдущих функций, он фокусируется на получение ключа, а не системы proof-of-work. Несмотря на этот факт, скрипт может служить нашей цели: она хорошо работает как функция ценообразования в задаче частичного преобразования hash, такой как SHA-256 в Bitcoin. На данный момент scrypt уже применяется в Litecoin [14] и некоторых других ветвях Bitcoin. Однако его реализация на самом деле не привязана к памяти: соотношение «время доступа к памяти/общее time» недостаточно велик, поскольку каждый экземпляр использует только 128 КБ. Это позволяет майнерам с графическим процессором быть примерно в 10 раз более эффективным и продолжает оставлять возможность создания относительно дешевые, но высокоэффективные устройства для майнинга. Более того, сама конструкция сценария допускает линейный компромисс между размером памяти и Скорость процессора обусловлена тем, что каждый блок в блокноте является производным только от предыдущего. Например, вы можете хранить каждый второй блок и пересчитывать остальные ленивым способом, т.е. только когда это станет необходимым. Предполагается, что псевдослучайные индексы распределены равномерно. следовательно, ожидаемое значение пересчетов дополнительных блоков равно 1 \(2 \cdot N\), гдеN - число итераций. Общее время вычислений увеличивается менее чем вдвое, поскольку имеются также независимые от времени (постоянное время) операции, такие как подготовка блокнота и hashвключение каждую итерацию. Сохранение 2/3 памяти стоит 1 3 \(\cdot\) Н + 1 3 \(\cdot\) \(2 \cdot N\) = N дополнительных пересчетов; 9/10 в результате 1 10 \(\cdot\) Н + . . . + 1 10 \(\cdot\) 9 \(\cdot\) Н = 4,5 Н. Легко показать, что сохранение только 1 s всех блоков увеличивает время менее чем в с−1 раз. 2 . Это, в свою очередь, означает, что машина с процессором В 200 раз быстрее, чем современные чипы могут хранить всего 320 байт блокнота. 5.2 Предлагаемый алгоритм Мы предлагаем новый алгоритм с привязкой к памяти для функции ценообразования proof-of-work. Это зависит от произвольный доступ к медленной памяти и подчеркивает зависимость от задержки. В отличие от сценария каждого новый блок (длиной 64 байта) зависит от всех предыдущих блоков. В результате гипотетический «Экономия памяти» должна увеличить скорость вычислений в геометрической прогрессии. Наш алгоритм требует около 2 Мб на экземпляр по следующим причинам: 1. Он помещается в кэш L3 (на ядро) современных процессоров, которые должны стать массовыми. через несколько лет; 2. Мегабайт внутренней памяти — практически неприемлемый размер для современного ASIC-конвейера; 3. На графических процессорах могут одновременно работать сотни экземпляров, но они ограничены в других отношениях: Память GDDR5 медленнее кэша CPU L3 и отличается своей пропускной способностью, а не Скорость произвольного доступа. 4. Значительное расширение блокнота потребует увеличения количества итераций, что в ход подразумевает общее увеличение времени. «Тяжелые» вызовы в ненадежной p2p-сети могут привести к серьезные уязвимости, поскольку узлы обязаны проверять proof-of-work каждого нового блока. Если узел тратит значительное количество времени на каждую оценку hash, его можно легко DDoS-атака вызвана потоком поддельных объектов с произвольными рабочими данными (значения nonce). 12 22 Неважно, это скрипт-монета? Где алгоритм? Я вижу только рекламу. Именно здесь Cryptonote, если их алгоритм PoW того стоит, действительно проявит себя. Это не на самом деле SHA-256, это не совсем скрипт. Он новый, привязан к памяти и нерекурсивный.
6 Дополнительные преимущества 6.1 Плавное излучение Верхняя граница общего количества цифровых монет CryptoNote составляет: MSupply = 264 −1. атомные единицы. Это естественное ограничение, основанное только на ограничениях реализации, а не на интуиции. например: «N монет должно хватить всем». Для обеспечения плавности процесса эмиссии воспользуемся следующей формулой для блока награды: Базовое вознаграждение = (MSupply −A) ≫18, где A — количество ранее сгенерированных монет. 6.2 Регулируемые параметры 6.2.1 Сложность CryptoNote содержит алгоритм таргетинга, который меняет сложность каждого блока. Это уменьшает время реакции системы при интенсивном росте или сокращении сети hashrate, сохранение постоянной скорости блокировки. Исходный метод Bitcoin вычисляет отношение фактических и целевой промежуток времени между последними блоками 2016 года и использует его в качестве множителя для текущего сложность. Очевидно, что для быстрых пересчетов это непригодно (из-за большой инерционности) и приводит к колебаниям. Общая идея нашего алгоритма заключается в суммировании всей работы, выполненной узлами, и разделите его на время, которое они потратили. Мерой работы являются соответствующие значения сложности. в каждом блоке. Но из-за неточных и ненадежных временных меток мы не можем определить точную дату. интервал времени между блоками. Пользователь может перенести свою временную метку в будущее и в следующий раз. интервалы могут быть невероятно малыми или даже отрицательными. Вероятно, таких инцидентов будет немного. такого рода, поэтому мы можем просто отсортировать временные метки и отсечь выбросы (т. е. 20%). Диапазон остальные значения — это время, затраченное на 80% соответствующих блоков. 6.2.2 Ограничения по размеру Пользователи платят за хранение blockchain и имеют право голосовать за его размер. Каждый шахтер имеет дело с компромиссом между балансом затрат и прибыли от комиссий и устанавливает свои собственные «мягкий лимит» для создания блоков. Также основное правило максимального размера блока необходимо для предотвращая заполнение blockchain фиктивной транзакцией, однако это значение должно не быть жестко закодированным. Пусть MN — медианное значение размеров последних N блоков. Тогда «жесткое ограничение» на размер приема блоков составляет 2 \(\cdot\) МН. Это предотвращает раздувание blockchain, но при этом позволяет ограничить лимит. при необходимости медленно расти со временем. Размер транзакции не обязательно ограничивать явно. Он ограничен размером блока; и если кто-то захочет создать огромную транзакцию с сотнями входов/выходов (или с высокая степень двусмысленности кольцевых подписей), он может сделать это, заплатив достаточную плату. 6.2.3 Штраф за превышение размера Майнер по-прежнему имеет возможность наполнить блок своими собственными транзакциями с нулевой комиссией до максимального уровня. размер 2 \(\cdot\) Мб. Несмотря на то, что только большинство майнеров могут изменить медианное значение, все же существует 13 6 Дополнительные преимущества 6.1 Плавное излучение Верхняя граница общего количества цифровых монет CryptoNote составляет: MSupply = 264 −1. атомные единицы. Это естественное ограничение, основанное только на ограничениях реализации, а не на интуиции. например: «N монет должно хватить всем». Для обеспечения плавности процесса эмиссии воспользуемся следующей формулой для блока награды: Базовое вознаграждение = (MSupply −A) ≫18, где A — количество ранее сгенерированных монет. 6.2 Регулируемые параметры 6.2.1 Сложность CryptoNote содержит алгоритм таргетинга, который меняет сложность каждого блока. Это уменьшает время реакции системы при интенсивном росте или уменьшении скорости сети hash, сохранение постоянной скорости блокировки. Исходный метод Bitcoin вычисляет отношение фактических и целевой промежуток времени между последними блоками 2016 года и использует его в качестве множителя для текущего сложность. Очевидно, что для быстрых пересчетов это непригодно (из-за большой инерционности) и приводит к колебаниям. Общая идея нашего алгоритма заключается в суммировании всей работы, выполненной узлами, и разделите его на время, которое они потратили. Мерой работы являются соответствующие значения сложности. в каждом блоке. Но из-за неточных и ненадежных временных меток мы не можем определить точную дату. интервал времени между блоками. Пользователь может перенести свою временную метку в будущее и в следующий раз. интервалы могут быть невероятно малыми или даже отрицательными. Вероятно, таких инцидентов будет немного. такого рода, поэтому мы можем просто отсортировать временные метки и отсечь выбросы (т. е. 20%). Диапазон остальные значения — это время, затраченное на 80% соответствующих блоков. 6.2.2 Ограничения по размеру Пользователи платят за хранение blockchain и имеют право голосовать за его размер. Каждый шахтер имеет дело с компромиссом между балансировкойОн тратит и получает прибыль от гонораров и устанавливает свои собственные «мягкий лимит» для создания блоков. Также основное правило максимального размера блока необходимо для предотвращая заполнение blockchain фиктивной транзакцией, однако это значение должно не быть жестко закодированным. Пусть MN — медианное значение размеров последних N блоков. Тогда «жесткое ограничение» на размер приема блоков составляет 2 \(\cdot\) МН. Это предотвращает раздувание blockchain, но при этом позволяет ограничить при необходимости медленно расти со временем. Размер транзакции не обязательно ограничивать явно. Он ограничен размером блока; и если кто-то захочет создать огромную транзакцию с сотнями входов/выходов (или с высокая степень двусмысленности кольцевых подписей), он может сделать это, заплатив достаточную плату. 6.2.3 Штраф за превышение размера Майнер по-прежнему имеет возможность наполнить блок своими собственными транзакциями с нулевой комиссией до максимального уровня. размер 2 \(\cdot\) Мб. Несмотря на то, что только большинство майнеров могут изменить медианное значение, все же существует 13 23 Атомные единицы. Мне нравится, что. Это эквивалент сатоши? Если это так, то это означает, что будет 185 миллиардов криптонот. Я знаю, что со временем это нужно будет подправить на нескольких страницах, или, может быть, это опечатка? Если базовая награда — «все оставшиеся монеты», то для получения всех монет достаточно только одного блока. Инстамин. С другой стороны, если предполагается, что это каким-то образом пропорционально разница во времени между настоящим моментом и какой-то датой прекращения производства монет? Это бы имеет смысл. Кроме того, в моем мире два знака «больше» означают «намного больше». Автор возможно, имеется в виду что-то другое? Если корректировка сложности происходит в каждом блоке, то у злоумышленника может быть очень большая ферма машины работают время от времени в тщательно выбранные промежутки времени. Это может привести к хаотическому взрыву (или падению до нуля) сложности, если формулы корректировки сложности не будут должным образом демпфированы. Несомненно, метод Bitcoin непригоден для быстрых пересчетов, но идея инерции в этих системах необходимо будет доказать, а не считать само собой разумеющимся. Кроме того, колебания в сети сложность не обязательно является проблемой, если только она не приводит к колебаниям мнимых запас монет, а очень быстро меняющаяся сложность может привести к «чрезмерной коррекции». Затраченное время, особенно в течение короткого промежутка времени, например нескольких минут, будет пропорционально «общему количеству количество блоков, созданных в сети». Константа пропорциональности сама будет расти. с течением времени, предположительно экспоненциально, если CN взлетит. Возможно, было бы лучше просто отрегулировать сложность, чтобы сохранить «общее количество блоков, созданных на сети с момента добавления последнего блока в основную цепочку» в пределах некоторого постоянного значения или с ограниченная вариация или что-то в этом роде. Если адаптивный алгоритм, который является вычислительным Легко реализовать, может показаться, что это решит проблему. Но если бы мы использовали этот метод, кто-то с большой майнинговой фермой мог бы закрыть свою ферму. на несколько часов и снова включите его. За первые несколько кварталов эта ферма будет производить банк. Итак, на самом деле этот метод поднимает интересный вопрос: майнинг становится (в среднем) проигрышная игра без рентабельности инвестиций, особенно по мере того, как все больше людей подключаются к сети. Если сложность майнинга очень внимательно отслеживаемая сеть hashrate, я почему-то сомневаюсь, что люди будут майнить столько, сколько они в настоящее время делаю. Или, с другой стороны, вместо того, чтобы поддерживать круглосуточную работу своих майнинг-ферм, они могут превратить их включен на 6 часов, выключен на 2, включен на 6, выключен на 2 или что-то в этом роде. Просто переключитесь на другую монету в течение нескольких часов, подождите, пока сложность упадет, затем запрыгивайте обратно, чтобы получить эти несколько дополнительных очков. блоков прибыльности по мере адаптации сети. И знаешь что? Это на самом деле, наверное один из лучших сценариев добычи полезных ископаемых, которые я придумал... Это могло бы быть циклично, но если время создания блока в среднем составляет около минуты, можем ли мы просто использовать количество блоков в качестве показателя «затраченного времени?»
6 Дополнительные преимущества 6.1 Плавное излучение Верхняя граница общего количества цифровых монет CryptoNote составляет: MSupply = 264 −1. атомные единицы. Это естественное ограничение, основанное только на ограничениях реализации, а не на интуиции. например: «N монет должно хватить всем». Для обеспечения плавности процесса эмиссии воспользуемся следующей формулой для блока награды: Базовое вознаграждение = (MSupply −A) ≫18, где A — количество ранее сгенерированных монет. 6.2 Регулируемые параметры 6.2.1 Сложность CryptoNote содержит алгоритм таргетинга, который меняет сложность каждого блока. Это уменьшает время реакции системы при интенсивном росте или сокращении сети hashrate, сохранение постоянной скорости блокировки. Исходный метод Bitcoin вычисляет отношение фактических и целевой промежуток времени между последними блоками 2016 года и использует его в качестве множителя для текущего сложность. Очевидно, что для быстрых пересчетов это непригодно (из-за большой инерционности) и приводит к колебаниям. Общая идея нашего алгоритма заключается в суммировании всей работы, выполненной узлами, и разделите его на время, которое они потратили. Мерой работы являются соответствующие значения сложности. в каждом блоке. Но из-за неточных и ненадежных временных меток мы не можем определить точную дату. интервал времени между блоками. Пользователь может перенести свою временную метку в будущее и в следующий раз. интервалы могут быть невероятно малыми или даже отрицательными. Вероятно, таких инцидентов будет немного. такого рода, поэтому мы можем просто отсортировать временные метки и отсечь выбросы (т. е. 20%). Диапазон остальные значения — это время, затраченное на 80% соответствующих блоков. 6.2.2 Ограничения по размеру Пользователи платят за хранение blockchain и имеют право голосовать за его размер. Каждый шахтер имеет дело с компромиссом между балансом затрат и прибыли от комиссий и устанавливает свои собственные «мягкий лимит» для создания блоков. Также основное правило максимального размера блока необходимо для предотвращая заполнение blockchain фиктивной транзакцией, однако это значение должно не быть жестко закодированным. Пусть MN — медианное значение размеров последних N блоков. Тогда «жесткое ограничение» на размер приема блоков составляет 2 \(\cdot\) МН. Это предотвращает раздувание blockchain, но при этом позволяет ограничить лимит. при необходимости медленно расти со временем. Размер транзакции не обязательно ограничивать явно. Он ограничен размером блока; и если кто-то захочет создать огромную транзакцию с сотнями входов/выходов (или с высокая степень двусмысленности кольцевых подписей), он может сделать это, заплатив достаточную плату. 6.2.3 Штраф за превышение размера Майнер по-прежнему имеет возможность наполнить блок своими собственными транзакциями с нулевой комиссией до максимального уровня. размер 2 \(\cdot\) Мб. Несмотря на то, что только большинство майнеров могут изменить медианное значение, все же существует 13 6 Дополнительные преимущества 6.1 Плавное излучение Верхняя граница общего количества цифровых монет CryptoNote составляет: MSupply = 264 −1. атомные единицы. Это естественное ограничение, основанное только на ограничениях реализации, а не на интуиции. например: «N монет должно хватить всем». Для обеспечения плавности процесса эмиссии воспользуемся следующей формулой для блока награды: Базовое вознаграждение = (MSupply −A) ≫18, где A — количество ранее сгенерированных монет. 6.2 Регулируемые параметры 6.2.1 Сложность CryptoNote содержит алгоритм таргетинга, который меняет сложность каждого блока. Это уменьшает время реакции системы, когда скорость сети hash интенсивно растет или сокращается, сохранение постоянной скорости блокировки. Исходный метод Bitcoin вычисляет отношение фактических и целевой промежуток времени между последними блоками 2016 года и использует его в качестве множителя для текущего сложность. Очевидно, что для быстрых пересчетов это непригодно (из-за большой инерционности) и приводит к колебаниям. Общая идея нашего алгоритма заключается в суммировании всей работы, выполненной узлами, и разделите его на время, которое они потратили. Мерой работы являются соответствующие значения сложности. в каждом блоке. Но из-за неточных и ненадежных временных меток мы не можем определить точную дату. интервал времени между блоками. Пользователь может перенести свою временную метку в будущее и в следующий раз. интервалы могут быть невероятно малыми или даже отрицательными. Вероятно, таких инцидентов будет немного. такого рода, поэтому мы можем просто отсортировать временные метки и отсечь выбросы (т. е. 20%). Диапазон остальные значения — это время, затраченное на 80% соответствующих блоков. 6.2.2 Ограничения по размеру Пользователи платят за хранение blockchain и имеют право голосовать за его размер. Каждый шахтер имеет дело с компромиссом между балансировкойОн тратит и получает прибыль от гонораров и устанавливает свои собственные «мягкий лимит» для создания блоков. Также основное правило максимального размера блока необходимо для предотвращая заполнение blockchain фиктивной транзакцией, однако это значение должно не быть жестко закодированным. Пусть MN — медианное значение размеров последних N блоков. Тогда «жесткое ограничение» на размер приема блоков составляет 2 \(\cdot\) МН. Это предотвращает раздувание blockchain, но при этом позволяет ограничить при необходимости медленно расти со временем. Размер транзакции не обязательно ограничивать явно. Он ограничен размером блока; и если кто-то захочет создать огромную транзакцию с сотнями входов/выходов (или с высокая степень двусмысленности кольцевых подписей), он может сделать это, заплатив достаточную плату. 6.2.3 Штраф за превышение размера Майнер по-прежнему имеет возможность наполнить блок своими собственными транзакциями с нулевой комиссией до максимального уровня. размер 2 \(\cdot\) Мб. Несмотря на то, что только большинство майнеров могут изменить медианное значение, все же существует 13 24 Хорошо, у нас есть blockchain, и каждый блок имеет временные метки, ДОПОЛНИТЕЛЬНО к тому, что он просто заказал. Это было явно вставлено просто для сложности настройки, потому что временные метки Как уже упоминалось, очень ненадежно. Разрешено ли нам иметь противоречивые временные метки в цепочке? Если в цепочке блок А предшествует блоку Б и с финансами все в порядке, но Блок А, похоже, был создан после Блока Б? Потому что, возможно, кто-то владел большая часть сети? Это нормально? Наверное, потому, что с финансами не все в порядке. Хорошо, я ненавижу это произвольное «только 80% блоков являются законными для основного blockchain». подход. Это было сделано для того, чтобы лжецы не могли изменить свои временные метки? Но теперь он добавляет стимул для всех лгать о своих временных метках и просто выбирать медиану. Пожалуйста, определите. Это означает «для этого блока включать только транзакции, включающие более высокие комиссии». чем p%, предпочтительно с комиссией выше 2p%» или что-то в этом роде? Что они подразумевают под словом фальшивка? Если транзакция соответствует прошлой истории blockchain, и транзакция включает комиссию, удовлетворяющую майнеров, разве этого недостаточно? Ну, нет, не обязательно. Если максимальный размер блока не существует, злоумышленнику нечего удерживать. от простой загрузки огромного блока транзакций себе сразу, просто чтобы замедлить сеть. Основное правило максимального размера блока не позволяет людям размещать огромное количество мусора. данные на blockchain все сразу, просто чтобы замедлить процесс. Но такое правило, безусловно, должно быть адаптивными: например, во время рождественского сезона можно ожидать резкого увеличения трафика, и размер блока становится очень большим, и сразу после этого размер блока впоследствии уменьшается снова. Поэтому нам нужно либо а) какое-то адаптивное ограничение, либо б) достаточно большое ограничение, чтобы 99% разумные рождественские пики не выходят за рамки ограничений. Конечно, второе невозможно. оценка - кто знает, приживется ли валюта? Лучше сделать адаптивным и не париться об этом. Но тогда у нас возникает проблема теории управления: как сделать это адаптивным без уязвимость к атакам или диким и сумасшедшим колебаниям? Обратите внимание, что адаптивный метод не мешает злоумышленникам накапливать небольшие суммы. ненужных данных с течением времени на blockchain, что приводит к долгосрочному раздуванию. Это другая проблема в целом и тот, с которым у криптоноут есть серьезные проблемы.
6 Дополнительные преимущества 6.1 Плавное излучение Верхняя граница общего количества цифровых монет CryptoNote составляет: MSupply = 264 −1. атомные единицы. Это естественное ограничение, основанное только на ограничениях реализации, а не на интуиции. например: «N монет должно хватить всем». Для обеспечения плавности процесса эмиссии воспользуемся следующей формулой для блока награды: Базовое вознаграждение = (MSupply −A) ≫18, где A — количество ранее сгенерированных монет. 6.2 Регулируемые параметры 6.2.1 Сложность CryptoNote содержит алгоритм таргетинга, который меняет сложность каждого блока. Это уменьшает время реакции системы при интенсивном росте или сокращении сети hashrate, сохранение постоянной скорости блокировки. Исходный метод Bitcoin вычисляет отношение фактических и целевой промежуток времени между последними блоками 2016 года и использует его в качестве множителя для текущего сложность. Очевидно, что для быстрых пересчетов это непригодно (из-за большой инерционности) и приводит к колебаниям. Общая идея нашего алгоритма заключается в суммировании всей работы, выполненной узлами, и разделите его на время, которое они потратили. Мерой работы являются соответствующие значения сложности. в каждом блоке. Но из-за неточных и ненадежных временных меток мы не можем определить точную дату. интервал времени между блоками. Пользователь может перенести свою временную метку в будущее и в следующий раз. интервалы могут быть невероятно малыми или даже отрицательными. Вероятно, таких инцидентов будет немного. такого рода, поэтому мы можем просто отсортировать временные метки и отсечь выбросы (т. е. 20%). Диапазон остальные значения — это время, затраченное на 80% соответствующих блоков. 6.2.2 Ограничения по размеру Пользователи платят за хранение blockchain и имеют право голосовать за его размер. Каждый шахтер имеет дело с компромиссом между балансом затрат и прибыли от комиссий и устанавливает свои собственные «мягкий лимит» для создания блоков. Также основное правило максимального размера блока необходимо для предотвращение заполнения blockchain фиктивной транзакцией, однако это значение должно не быть жестко закодированным. Пусть MN — медианное значение размеров последних N блоков. Тогда «жесткое ограничение» на размер приема блоков составляет 2 \(\cdot\) МН. Это предотвращает раздувание blockchain, но при этом позволяет ограничить при необходимости медленно расти со временем. Размер транзакции не обязательно ограничивать явно. Он ограничен размером блока; и если кто-то захочет создать огромную транзакцию с сотнями входов/выходов (или с высокая степень двусмысленности кольцевых подписей), он может сделать это, заплатив достаточную плату. 6.2.3 Штраф за превышение размера Майнер по-прежнему имеет возможность наполнить блок своими собственными транзакциями с нулевой комиссией до максимального уровня. размер 2 \(\cdot\) Мб. Несмотря на то, что только большинство майнеров могут изменить медианное значение, все же существует 13 6 Дополнительные преимущества 6.1 Плавное излучение Верхняя граница общего количества цифровых монет CryptoNote составляет: MSupply = 264 −1. атомные единицы. Это естественное ограничение, основанное только на ограничениях реализации, а не на интуиции. например: «N монет должно хватить всем». Для обеспечения плавности процесса эмиссии воспользуемся следующей формулой для блока награды: Базовое вознаграждение = (MSupply −A) ≫18, где A — количество ранее сгенерированных монет. 6.2 Регулируемые параметры 6.2.1 Сложность CryptoNote содержит алгоритм таргетинга, который меняет сложность каждого блока. Это уменьшает время реакции системы при интенсивном росте или сокращении сети hashrate, сохранение постоянной скорости блокировки. Исходный метод Bitcoin вычисляет отношение фактических и целевой промежуток времени между последними блоками 2016 года и использует его в качестве множителя для текущего сложность. Очевидно, что для быстрых пересчетов это непригодно (из-за большой инерционности) и приводит к колебаниям. Общая идея нашего алгоритма заключается в суммировании всей работы, выполненной узлами, и разделите его на время, которое они потратили. Мерой работы являются соответствующие значения сложности. в каждом блоке. Но из-за неточных и ненадежных временных меток мы не можем определить точную дату. интервал времени между блоками. Пользователь может перенести свою временную метку в будущее и в следующий раз. интервалы могут быть невероятно малыми или даже отрицательными. Вероятно, таких инцидентов будет немного. такого рода, поэтому мы можем просто отсортировать временные метки и отсечь выбросы (т. е. 20%). Диапазон остальные значения — это время, затраченное на 80% соответствующих блоков. 6.2.2 Ограничения по размеру Пользователи платят за хранение blockchain и имеют право голосовать за его размер. Каждый шахтер имеет дело с компромиссом между балансировкойОн тратит и получает прибыль от гонораров и устанавливает свои собственные «мягкий лимит» для создания блоков. Также основное правило максимального размера блока необходимо для предотвращая заполнение blockchain фиктивной транзакцией, однако это значение должно не быть жестко закодированным. Пусть MN — медианное значение размеров последних N блоков. Тогда «жесткое ограничение» на размер приема блоков составляет 2 \(\cdot\) МН. Это предотвращает раздувание blockchain, но при этом позволяет ограничить при необходимости медленно расти со временем. Размер транзакции не обязательно ограничивать явно. Он ограничен размером блока; и если кто-то захочет создать огромную транзакцию с сотнями входов/выходов (или с высокая степень двусмысленности кольцевых подписей), он может сделать это, заплатив достаточную плату. 6.2.3 Штраф за превышение размера Майнер по-прежнему имеет возможность наполнить блок своими собственными транзакциями с нулевой комиссией до максимального уровня. размер 2 \(\cdot\) Мб. Несмотря на то, что только большинство майнеров могут изменить медианное значение, все же существует 13 25 При изменении масштаба времени так, чтобы одна единица времени составляла N блоков, средний размер блока теоретически мог бы расти экспоненциально пропорционально 2ˆt. С другой стороны, более общий предел в следующем блоке будет M_nf(M_n) для некоторой функции f. Какие свойства f будут мы выбираем, чтобы гарантировать некоторый «разумный рост» размера блока? Прогрессирование размеры блоков (после масштабирования времени) будут такими: 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( ... И цель здесь — выбрать f так, чтобы эта последовательность росла не быстрее, чем, скажем, линейно: или, возможно, даже как Log(t). Конечно, если f(M_n) = a для некоторой константы a, эта последовательность будет на самом деле М_н аМ_н аˆ2М_н аˆ3М_н ... И, конечно же, единственный способ ограничить максимально линейный рост — это выбрать a=1. Это, конечно, неосуществимо. Это вообще не дает возможности роста. Если же, с другой стороны, f(M_n) — непостоянная функция, то ситуация гораздо сложнее. сложен и может позволить найти элегантное решение. Я подумаю над этим некоторое время. Этот сбор должен быть достаточно большим, чтобы исключить штраф за превышение размера, предусмотренный в следующем разделе. Почему обычный пользователь считается мужчиной, а? А?
возможность раздуть blockchain и создать дополнительную нагрузку на узлы. Препятствовать злонамеренным участникам от создания крупных блоков вводим штрафную функцию: Новая награда = Базовая награда \(\cdot\) БлкСизе Миннесота −1 2 Это правило применяется только тогда, когда BlkSize превышает минимальный размер свободного блока, который должен быть близким к max(10kb, \(M_N \cdot 110\%\)). Майнерам разрешено создавать блоки «обычного размера» и даже превысить его с прибылью, когда общие сборы превысят штраф. Но сборы вряд ли вырастут квадратично отличается от значения штрафа, поэтому будет равновесие. 6.3 Скрипты транзакций CryptoNote имеет очень минималистическую подсистему сценариев. Отправитель указывает выражение Φ = f (x1, x2,..., xn), где n — количество открытых ключей назначения {Pi}n я = 1. Всего пять двоичных поддерживаются операторы: min, max, sum, mul и cmp. Когда получатель тратит этот платеж, он создает \(0 \leq k \leq n\) подписей и передает их на вход транзакции. Процесс проверки просто оценивает Φ с xi = 1, чтобы проверить действительную подпись для открытого ключа Pi и xi = 0. Верификатор принимает доказательство, если Φ > 0. Несмотря на свою простоту, этот подход охватывает все возможные случаи: • Многопороговая сигнатура. Для мультиподписи в стиле Bitcoin «M-из-N» (т. е. получатель должен предоставить как минимум \(0 \leq M \leq N\) действительных подписей) Φ = x1+x2+. . .+xN \(\geq M\) (для ясности мы используем общепринятые алгебраические обозначения). Взвешенная пороговая сигнатура (некоторые ключи могут быть более важными, чем другие) можно выразить как Φ = \(w_1 \cdot x_1\) + ш2 \(\cdot\) х2 + . . . + \(w_N \cdot x_N\) \(\geq wM\). И сценарий, в котором мастер-ключ соответствует Φ = max(\(M \cdot x\), x1 + x2 +... + xN) \(\geq M\). Легко показать, что любой сложный случай может быть рассмотрен. выражаются с помощью этих операторов, т.е. они образуют основу. • Защита паролем. Владение секретным паролем эквивалентно знанию закрытый ключ, детерминированно полученный из пароля: k = KDF(s). Следовательно, приемник может доказать, что он знает пароль, предоставив еще одну подпись под ключом k. Отправитель просто добавляет соответствующий открытый ключ к своим выводам. Обратите внимание, что это метод гораздо более безопасен, чем «транзакционная головоломка», использованная в Bitcoin [13], где пароль явно передается на входе. • Вырожденные случаи. Φ = 1 означает, что деньги может потратить кто угодно; Φ = 0 отмечает вывод как не подлежащий расходованию навсегда. В случае, когда выходной скрипт в сочетании с открытыми ключами слишком велик для отправителя, он может использовать специальный тип вывода, который указывает, что получатель поместит эти данные в свои входные данные. в то время как отправитель предоставляет только hash этого сообщения. Этот подход аналогичен подходу Bitcoin «оплата-hash». функция, но вместо добавления новых команд сценария мы обрабатываем этот случай в структуре данных уровень. 7 Заключение Мы исследовали основные недостатки Bitcoin и предложили некоторые возможные решения. Эти выгодные особенности и наше постоянное развитие делают новую систему электронных денег CryptoNote серьезный конкурент Bitcoin, превосходящий все его форки. 14 возможность раздуть blockchain и создать дополнительную нагрузку на узлы. Препятствовать злонамеренным участникам от создания крупных блоков вводим штрафную функцию: Новая награда = Базовая награда \(\cdot\) БлкСизе Миннесота −1 2 Это правило применяется только тогда, когда BlkSize превышает минимальный размер свободного блока, который должен быть близким к max(10kb, \(M_N \cdot 110\%\)). Майнерам разрешено создавать блоки «обычного размера» и даже превысить его с прибылью, когда общие сборы превысят штраф. Но сборы вряд ли вырастут квадратично отличается от значения штрафа, поэтому будет равновесие. 6.3 Скрипты транзакций CryptoNote имеет очень минималистическую подсистему сценариев. Отправитель указывает выражение Φ = f (x1, x2,..., xn), где n — количество открытых ключей назначения {Pi}n я = 1. Всего пять двоичных поддерживаются операторы: min, max, sum, mul и cmp. Когда получатель тратит этот платеж, он создает \(0 \leq k \leq n\) подписей и передает их на вход транзакции. Процесс проверки просто оценивает Φ с xi = 1, чтобы проверить действительную подпись для открытого ключа Pi и xi = 0. Верификатор принимает доказательство, если Φ > 0. Несмотря на свою простоту, этот подход охватывает все возможные случаи: • Многопороговая сигнатура. Для мультиподписи в стиле Bitcoin «M-из-N» (т. е. получатель должен предоставить как минимум \(0 \leq M \leq N\) действительных подписей) Φ = x1+x2+. . .+xN \(\geq M\) (для ясности мы используем общепринятые алгебраические обозначения). Взвешенная пороговая сигнатура (некоторые ключи могут быть более важными, чем другие) можно выразить как Φ = \(w_1 \cdot x_1\) + ш2 \(\cdot\) х2 + . . . + \(w_N \cdot x_N\) \(\geq wM\). И скэнарio, где мастер-ключ соответствует Φ = max(\(M \cdot x\), x1 + x2 +... + xN) \(\geq M\). Легко показать, что любой сложный случай может быть рассмотрен. выражаются с помощью этих операторов, т.е. они образуют основу. • Защита паролем. Владение секретным паролем эквивалентно знанию закрытый ключ, детерминированно полученный из пароля: k = KDF(s). Следовательно, приемник может доказать, что он знает пароль, предоставив еще одну подпись под ключом k. Отправитель просто добавляет соответствующий открытый ключ к своим выводам. Обратите внимание, что это метод гораздо более безопасен, чем «транзакционная головоломка», использованная в Bitcoin [13], где пароль явно передается на входе. • Вырожденные случаи. Φ = 1 означает, что деньги может потратить кто угодно; Φ = 0 отмечает вывод как не подлежащий расходованию навсегда. В случае, когда выходной скрипт в сочетании с открытыми ключами слишком велик для отправителя, он может использовать специальный тип вывода, который указывает, что получатель поместит эти данные в свои входные данные. в то время как отправитель предоставляет только hash этого сообщения. Этот подход аналогичен подходу Bitcoin «оплата-hash». функция, но вместо добавления новых команд сценария мы обрабатываем этот случай в структуре данных уровень. 7 Заключение Мы исследовали основные недостатки Bitcoin и предложили некоторые возможные решения. Эти выгодные особенности и наше постоянное развитие делают новую систему электронных денег CryptoNote серьезный конкурент Bitcoin, превосходящий все его форки. 14 26 В этом может не оказаться необходимости, если мы сможем найти способ ограничить размер блока с течением времени... Это также не может быть правильным. Они просто установили «NewReward» на параболу, обращенную вверх, где размер блока является независимой переменной. Таким образом, новая награда раздувается до бесконечности. Если, с другой стороны, новая награда равна Max(0,Base Reward(1-(BlkSize/Mn - 1)ˆ2)), затем новая награда будет обращенной вниз параболой с пиком при размере блока = Mn и точками пересечения в точке Размер блока = 0 и Размер блока = 2Mn. И, кажется, именно это они пытаются описать. Однако это не
Analysis
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 flexibility 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 difficulty 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 flexible, 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 difficult. 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 difficult when there are more and more votes, yielding a lovely benefit to network security..
hardware described previously. Suppose that the global hashrate decreases significantly, 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 fixed 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 difference 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 significant 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 confirmations) whereas other seem to be artificial constraints. It is not so much the limits, as the inability of quickly changing 3 hardware described previously. Suppose that the global hashrate decreases significantly, 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 fixed 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 difference 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 significant 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 confirmations) whereas other seem to be artificial 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 effect 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, differentiable, 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 sufficient 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 artificially 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 official 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-configurable 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:
Анализ
5
Не то чтобы это имело большое значение, когда миллиард человек в мире живут менее чем на доллар в год.
и у меня нет никакой надежды когда-либо участвовать в какой-либо горнодобывающей сети... кроме экономической
мир, управляемый валютной системой p2p с принципом «один процессор – один голос», по-видимому, был бы более
справедливее, чем система, основанная на частичном банковском резервировании.
Но протокол Cryptonote по-прежнему требует 51% честных пользователей... см., например, Cryptonote
форумы, где один из разработчиков, Плишков, говорит, что традиционная атака 51% с заменой данных на blockchain все еще может работать. https://forum.cryptonote.org/viewtopic.php?f=2&t=198
Обратите внимание: на самом деле вам не нужен 51% честных пользователей. Вам просто очень не нужно «ни одного нечестного
фракция, владеющая более чем 51% hash мощи сети."
Давайте назовем эту так называемую проблему Биткойна «адаптивной жесткостью». Решение Cryptonote для адаптивного
жесткость – это адаптивная гибкость значений параметров протокола. Если вам нужны блоки большего размера,
нет проблем, сеть все это время будет плавно настраиваться.
То есть,
способ, которым Bitcoin регулирует сложность с течением времени, можно воспроизвести во всем нашем протоколе.
параметры, чтобы не требовалось достижение сетевого консенсуса для обновления протокола.
На первый взгляд это кажется хорошей идеей, но без тщательного обдумывания это саморегулирующаяся идея.
система может стать совершенно непредсказуемой и хаотичной. Мы рассмотрим это подробнее позже, поскольку
возможности возникают. «Хорошие» системы находятся где-то между адаптивно-жесткими и адаптивно-гибкими.
гибки, и, возможно, даже сама жесткость адаптивна.
Если бы у нас действительно был принцип «один процессор — один голос», то совместная работа и разработка пулов позволили бы достичь 51 %.
было бы сложнее. Мы ожидаем, что каждый процессор в мире будет заниматься майнингом с телефонов.
к встроенному процессору вашей Tesla во время зарядки.
http://en.wikipedia.org/wiki/Pareto_principle
Я утверждаю, что равновесие Парето в некоторой степени неизбежно. Либо 20% системы
владеть 80% процессоров, или 20% системы будет владеть 80% ASIC. Я предполагаю это, потому что основное распределение богатства в обществе уже демонстрирует распределение Парето:
и по мере того, как присоединяются новые майнеры, они выбираются из этого базового распределения.
Тем не менее, я утверждаю, что протоколы с принципом «один процессор — один голос» принесут окупаемость инвестиций в аппаратное обеспечение.
Блокировать
вознаграждение за узел будет более точно пропорционально количеству узлов в сети, поскольку
распределение производительности по узлам будет гораздо более плотным. Bitcoin, с другой
стороны, видит вознаграждение за блок (за узел), более пропорциональное вычислительной мощности этого узла.
узел. То есть в горнодобывающей отрасли все еще участвуют только «большие мальчики». С другой стороны,
хотя принцип Парето по-прежнему будет действовать, в мире «один процессор — один голос» каждый
участвует в сетевой безопасности и получает небольшой доход от майнинга.
В мире ASIC нецелесообразно привязывать к себе каждый XBox и мобильный телефон.
В мире «один процессор — один голос» это очень разумно с точки зрения вознаграждения за майнинг. Как приятное последствие,
набрать 51% голосов труднее, когда голосов становится все больше и больше, что дает прекрасный
польза для сетевой безопасности..оборудование, описанное ранее. Предположим, что глобальная скорость hash значительно снижается, даже для
мгновение, теперь он может использовать свою мощность майнинга, чтобы разветвить цепочку и удвоить расходы. Как мы увидим
далее в этой статье вполне вероятно, что ранее описанное событие имело место.
2.3
Нерегулярная эмиссия
Bitcoin имеет заранее определенную скорость эмиссии: каждый решенный блок производит фиксированное количество монет.
Примерно каждые четыре года эта награда уменьшается вдвое. Первоначальное намерение состояло в том, чтобы создать
ограниченное плавное излучение с экспоненциальным затуханием, но по факту мы имеем кусочно-линейное излучение
функция, точки останова которой могут вызвать проблемы в инфраструктуре Bitcoin.
Когда происходит точка останова, майнеры начинают получать только половину стоимости своих предыдущих
награда. Абсолютная разница между 12,5 и 6,25 BTC (прогноз на 2020 год) может
кажутся терпимыми. Однако при рассмотрении падения BTC с 50 до 25, произошедшего в ноябре
28 2012 года, посчитали его неприемлемым для значительного числа членов горнодобывающего сообщества. Рисунок
1 показано резкое снижение скорости hash сети в конце ноября, как раз тогда, когда
произошло халвинг. Это событие могло стать идеальным моментом для злонамеренного человека.
описано в разделе функции proof-of-work для проведения атаки двойных расходов [36].
Рис. 1. График курса Bitcoin hash
(источник: http://bitcoin.sipa.be)
2.4
Жестко запрограммированные константы
Bitcoin имеет множество жестко запрограммированных ограничений, некоторые из которых являются естественными элементами исходного дизайна (например,
частота блоков, максимальная сумма денежной массы, количество подтверждений), тогда как другие
кажутся искусственными ограничениями. Дело не столько в ограничениях, сколько в невозможности быстро меняться.
3
оборудование, описанное ранее. Предположим, что глобальная скорость hash значительно снижается, даже для
мгновение, теперь он может использовать свою мощность майнинга, чтобы разветвить цепочку и удвоить расходы. Как мы увидим
далее в этой статье вполне вероятно, что ранее описанное событие имело место.
2.3
Нерегулярная эмиссия
Bitcoin имеет заранее определенную скорость эмиссии: каждый решенный блок производит фиксированное количество монет.
Примерно каждые четыре года эта награда уменьшается вдвое. Первоначальное намерение состояло в том, чтобы создать
ограниченное плавное излучение с экспоненциальным затуханием, но по факту мы имеем кусочно-линейное излучение
функция, точки останова которой могут вызвать проблемы в инфраструктуре Bitcoin.
Когда происходит точка останова, майнеры начинают получать только половину стоимости своих предыдущих
награда. Абсолютная разница между 12,5 и 6,25 BTC (прогноз на 2020 год) может
кажутся терпимыми. Однако при рассмотрении падения BTC с 50 до 25, произошедшего в ноябре
28 2012 года, посчитали его неприемлемым для значительного числа членов горнодобывающего сообщества. Рисунок
1 показано резкое снижение скорости hash сети в конце ноября, как раз тогда, когда
произошло халвинг. Это событие могло стать идеальным моментом для злонамеренного человека.
описано в разделе функции proof-of-work для проведения атаки двойных расходов [36].
Рис. 1. График курса Bitcoin hash
(источник: http://bitcoin.sipa.be)
2.4
Жестко запрограммированные константы
Bitcoin имеет множество жестко запрограммированных ограничений, некоторые из которых являются естественными элементами исходного дизайна (например,
частота блоков, максимальная сумма денежной массы, количество подтверждений), тогда как другие
кажутся искусственными ограничениями. Дело не столько в ограничениях, сколько в невозможности быстро меняться.
3
6
Давайте назовем это тем, чем оно является, атакой зомби.
Давайте обсудим, каким может быть непрерывное излучение.
Это связано с принципом «один процессор — один голос» в сценарии атаки зомби.
В мире «один процессор – один голос» каждый сотовый телефон и каждый автомобиль, когда бы они ни находились в режиме ожидания, будут заниматься майнингом. Собрать кучу дешевого оборудования для создания майнинг-фермы было бы очень-очень легко, потому что всего лишь
почти во всем есть процессор. С другой стороны, в этот момент количество процессоров
Я думаю, что необходимое для запуска атаки 51% было бы весьма удивительным.
Кроме того,
именно поскольку было бы легко собрать дешевое оборудование, мы можем разумно ожидать
многие люди начинают копить что-нибудь с процессором. Гонка вооружений в мире «один процессор – один голос»
обязательно более эгалитарен, чем в мире ASIC.
Следовательно, разрыв в сети
безопасность из-за уровня выбросов должна быть МЕНЬШЕЙ проблемой в мире «один процессор – один голос».
Однако остаются два факта: 1) скачок в скорости выбросов может привести к эффекту заикания в
и в экономике, и в сетевой безопасности, что плохо, и 2) хоть и атака 51%
выполненный кем-то, кто собирает дешевое оборудование, все еще может происходить в однопроцессорном процессоре-голосуйте за мир,
кажется, должно быть сложнее.
Предположительно, защита от этого состоит в том, что все нечестные актеры будут пытаться это сделать.
одновременно, и мы возвращаемся к предыдущему понятию безопасности Bitcoin: «мы не требуем нечестных действий».
фракция будет контролировать более 51% сети».
Автор утверждает здесь, что одна из проблем с биткойнами заключается в том, что
может привести к внезапному снижению участия в сети и, следовательно, к снижению безопасности сети. Таким образом,
Предпочтительна непрерывная, дифференцируемая и плавная скорость эмиссии монет.
Автор не ошибается, это факт. Любое внезапное снижение участия в сети может
привести к такой проблеме, и если мы можем устранить один из ее источников, мы должны это сделать. Сказав это, это
возможно, что длительные периоды «относительно постоянной» эмиссии монет, перемежающиеся внезапными изменениями
Это идеальный путь с экономической точки зрения. Я не экономист. Так что, возможно, мы
должны решить, собираемся ли мы обменивать сетевую безопасность на что-то экономическое — что здесь?
http://arxiv.org/abs/1402.2009их при необходимости, что вызывает основные недостатки. К сожалению, трудно предсказать, когда
константы, возможно, придется изменить, а их замена может привести к ужасным последствиям.
Хорошим примером жестко запрограммированного изменения лимита, приводящего к катастрофическим последствиям, является блок
ограничение размера установлено на 250 КБ1. Этого лимита было достаточно для проведения около 10 000 стандартных транзакций. В
В начале 2013 года этот предел был почти достигнут, и было достигнуто соглашение об увеличении
предел. Изменение было реализовано в версии кошелька 0.8 и закончилось разделением цепочки на 24 блока.
и успешная атака двойной траты [9]. Хотя ошибка была не в протоколе Bitcoin, а
скорее, в ядре базы данных его можно было бы легко обнаружить с помощью простого стресс-теста, если бы было
отсутствие искусственно введенного ограничения размера блока.
Константы также действуют как форма точки централизации.
Несмотря на одноранговый характер
Bitcoin, подавляющее большинство узлов используют официальный эталонный клиент [10], разработанный
небольшая группа людей. Эта группа принимает решение о внесении изменений в протокол.
и большинство людей принимают эти изменения независимо от их «правильности». Некоторые решения вызвали
бурные дискуссии и даже призывы к бойкоту [11], что свидетельствует о том, что сообщество и
разработчики могут расходиться во мнениях по некоторым важным моментам. Поэтому кажется логичным иметь протокол
с настраиваемыми пользователем и самонастраивающимися переменными как возможный способ избежать этих проблем.
2,5
Громоздкие скрипты
Система сценариев в Bitcoin — сложная и тяжелая функция. Потенциально это позволяет создавать
сложные транзакции [12], но некоторые из его функций отключены из соображений безопасности и
некоторые даже никогда не использовались [13]. Скрипт (включая часть отправителя и получателя)
для самой популярной транзакции в Bitcoin выглядит так: