CryptoNote v2.0
El artículo presentado aquí es el whitepaper CryptoNote v2.0 de Nicolas van Saberhagen (2013), que describe los fundamentos criptográficos sobre los que se construye Monero. No es un whitepaper específico de Monero — Monero se lanzó en 2014 como una bifurcación de la implementación de referencia de CryptoNote (Bytecoin) y desde entonces ha evolucionado significativamente más allá del protocolo original.
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.
Introdução
“Bitcoin” [1] foi uma implementação bem-sucedida do conceito de dinheiro eletrônico p2p. Ambos profissionais e o público em geral passaram a apreciar a combinação conveniente de transações públicas e proof-of-work como modelo de confiança. Hoje, a base de usuários do dinheiro eletrônico está a crescer a um ritmo constante; os clientes são atraídos por taxas baixas e pelo anonimato fornecido pelo dinheiro eletrônico e os comerciantes valorizam sua emissão prevista e descentralizada. Bitcoin tem provou efetivamente que o dinheiro eletrônico pode ser tão simples quanto o papel-moeda e tão conveniente quanto cartões de crédito. Infelizmente, Bitcoin sofre de diversas deficiências. Por exemplo, o sistema é distribuído a natureza é inflexível, impedindo a implementação de novos recursos até que quase todos os usuários da rede atualizem seus clientes. Algumas falhas críticas que não podem ser corrigidas rapidamente impedem o Bitcoin propagação generalizada. Nesses modelos inflexíveis, é mais eficiente implementar um novo projeto em vez de consertar perpetuamente o projeto original. Neste artigo, estudamos e propomos soluções para as principais deficiências de Bitcoin. Nós acreditamos que um sistema que tenha em conta as soluções que propomos conduzirá a uma concorrência saudável entre diferentes sistemas de dinheiro eletrônico. Propomos também o nosso próprio dinheiro eletrônico, “CryptoNote”, um nome que enfatiza o próximo avanço no dinheiro eletrônico.
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 Desvantagens e possíveis soluções
2 Bitcoin desvantagens e algumas soluções possíveis 2.1 Rastreabilidade das transações Privacidade e anonimato são os aspectos mais importantes do dinheiro eletrônico. Pagamentos ponto a ponto procuram ser ocultados da visão de terceiros, uma diferença distinta quando comparado com o tradicional bancário. Em particular, T. Okamoto e K. Ohta descreveram seis critérios de dinheiro eletrônico ideal, que incluía “privacidade: a relação entre o usuário e suas compras deve ser indetectável por qualquer pessoa” [30]. A partir de sua descrição, derivamos duas propriedades que um relatório totalmente anônimo o modelo de dinheiro eletrônico deve satisfazer para cumprir os requisitos descritos por Okamoto e Ohta: Irrastreabilidade: para cada transação recebida todos os remetentes possíveis são equiprováveis. Desvinculação: para quaisquer duas transações de saída é impossível provar que foram enviadas para a mesma pessoa. Infelizmente, Bitcoin não atende ao requisito de não rastreabilidade. Como todas as transações que ocorrem entre os participantes da rede são públicas, qualquer transação pode ser 1 CriptoNote v 2.0 Nicolas van Saberhagen 17 de outubro de 2013 1 Introdução “Bitcoin” [1] foi uma implementação bem-sucedida do conceito de dinheiro eletrônico p2p. Ambos profissionais e o público em geral passaram a apreciar a combinação conveniente de transações públicas e proof-of-work como modelo de confiança. Hoje, a base de usuários do dinheiro eletrônico está a crescer a um ritmo constante; os clientes são atraídos por taxas baixas e pelo anonimato fornecido pelo dinheiro eletrônico e os comerciantes valorizam sua emissão prevista e descentralizada. Bitcoin tem provou efetivamente que o dinheiro eletrônico pode ser tão simples quanto o papel-moeda e tão conveniente quanto cartões de crédito. Infelizmente, Bitcoin sofre de diversas deficiências. Por exemplo, o sistema é distribuído a natureza é inflexível, impedindo a implementação de novos recursos até que quase todos os usuários da rede atualizem seus clientes. Algumas falhas críticas que não podem ser corrigidas rapidamente dissuadem Bitcoin de propagação generalizada. Nesses modelos inflexíveis, é mais eficiente implementar um novo projeto em vez de consertar perpetuamente o projeto original. Neste artigo, estudamos e propomos soluções para as principais deficiências de Bitcoin. Nós acreditamos que um sistema que tenha em conta as soluções que propomos conduzirá a uma concorrência saudável entre diferentes sistemas de dinheiro eletrônico. Propomos também o nosso próprio dinheiro eletrônico, “CryptoNote”, um nome que enfatiza o próximo avanço no dinheiro eletrônico. 2 Bitcoin desvantagens e algumas soluções possíveis 2.1 Rastreabilidade das transações Privacidade e anonimato são os aspectos mais importantes do dinheiro eletrônico. Pagamentos ponto a ponto procuram ser ocultados da visão de terceiros, uma diferença distinta quando comparado com o tradicional bancário. Em particular, T. Okamoto e K. Ohta descreveram seis critérios de dinheiro eletrônico ideal, que incluía “privacidade: a relação entre o usuário e suas compras deve ser indetectável por qualquer pessoa” [30]. A partir de sua descrição, derivamos duas propriedades que um relatório totalmente anônimo o modelo de dinheiro eletrônico deve satisfazer para cumprir os requisitos descritos por Okamoto e Ohta: Irrastreabilidade: para cada transação recebida todos os remetentes possíveis são equiprováveis. Desvinculação: para quaisquer duas transações de saída é impossível provar que foram enviadas para a mesma pessoa. Infelizmente, Bitcoin não atende ao requisito de não rastreabilidade. Como todas as transações que ocorrem entre os participantes da rede são públicas, qualquer transação pode ser 1 3 Bitcoin definitivamente falha em "não rastreabilidade". Quando eu te envio BTC, a carteira da qual ele é enviado está irrevogavelmente carimbado no blockchain. Não há dúvida sobre quem enviou esses fundos, porque somente quem conhece as chaves privadas pode enviá-las.inequivocamente atribuída a uma origem única e a um destinatário final. Mesmo que dois participantes troquem fundos de forma indireta, um método de descoberta de caminhos adequadamente projetado revelará a origem e destinatário final. Suspeita-se também que Bitcoin não satisfaz a segunda propriedade. Alguns pesquisadores afirmou ([33, 35, 29, 31]) que uma análise cuidadosa de blockchain pode revelar uma conexão entre os usuários da rede Bitcoin e suas transações. Embora vários métodos sejam contestado [25], suspeita-se que muitas informações pessoais ocultas podem ser extraídas do banco de dados público. A falha de Bitcoin em satisfazer as duas propriedades descritas acima nos leva a concluir que é não um sistema de dinheiro eletrônico anônimo, mas pseudo-anônimo. Os usuários foram rápidos em desenvolver soluções para contornar esta lacuna. Duas soluções diretas foram “serviços de lavagem” [2] e o desenvolvimento de métodos distribuídos [3, 4]. Ambas as soluções baseiam-se na ideia de misturar diversas transações públicas e envio através de algum endereço intermediário; que por sua vez sofre a desvantagem de exigir um terceiro confiável. Recentemente, um esquema mais criativo foi proposto por I. Miers et al. [28]: “Zerocoin”. Zerocoin utiliza acumuladores criptográficos unidirecionais e provas de conhecimento zero que permitem aos usuários “converter” bitcoins em zerocoins e gastá-los usando prova anônima de propriedade em vez de assinaturas digitais explícitas baseadas em chave pública. No entanto, tais provas de conhecimento têm uma constante mas tamanho inconveniente - cerca de 30kb (com base nos limites Bitcoin atuais), o que torna a proposta impraticável. Os autores admitem que é improvável que o protocolo seja aceito pela maioria dos Bitcoin usuários [5]. 2.2 A função proof-of-work O criador de Bitcoin, Satoshi Nakamoto, descreveu o algoritmo de tomada de decisão majoritária como “oneCPU-one-vote” e usou uma função de precificação vinculada à CPU (duplo SHA-256) para seu proof-of-work esquema. Como os usuários votam no pedido único de histórico de transações [1], a razoabilidade e a consistência deste processo são condições críticas para todo o sistema. A segurança deste modelo apresenta duas desvantagens. Primeiro, requer 51% da rede o poder de mineração esteja sob o controle de usuários honestos. Em segundo lugar, o progresso do sistema (correções de bugs, correções de segurança, etc...) exigem que a esmagadora maioria dos usuários apoie e concorde com o mudanças (isso ocorre quando os usuários atualizam seu software de carteira) [6].Finalmente esta mesma votação O mecanismo também é usado para pesquisas coletivas sobre a implementação de alguns recursos [7]. Isso nos permite conjecturar as propriedades que devem ser satisfeitas pelo proof-of-work função de precificação. Essa função não deve permitir que um participante da rede tenha um impacto significativo vantagem sobre outro participante; requer uma paridade entre hardware comum e alta custo de dispositivos personalizados. A partir de exemplos recentes [8], podemos ver que a função SHA-256 usada na arquitetura Bitcoin não possui esta propriedade à medida que a mineração se torna mais eficiente em GPUs e dispositivos ASIC em comparação com CPUs de última geração. Portanto, Bitcoin cria condições favoráveis para uma grande lacuna entre o poder de voto de participantes, pois viola o princípio “uma CPU um voto”, uma vez que os proprietários de GPU e ASIC possuem um poder de voto muito maior quando comparado aos proprietários de CPU. É um exemplo clássico do Princípio de Pareto onde 20% dos participantes de um sistema controlam mais de 80% dos votos. Pode-se argumentar que tal desigualdade não é relevante para a segurança da rede, uma vez que não é o pequeno número de participantes que controlam a maioria dos votos, mas a honestidade destes participantes que importa. No entanto, tal argumento é um tanto falho, uma vez que é antes o possibilidade de hardware especializado barato aparecer em vez da honestidade dos participantes que representa uma ameaça. Para demonstrar isso, tomemos o seguinte exemplo. Suponha que um malévolo indivíduo ganha poder de mineração significativo ao criar sua própria fazenda de mineração por meio de recursos baratos. 2 inequivocamente atribuída a uma origem única e a um destinatário final. Mesmo que dois participantes troquem fundos de forma indireta, um método de descoberta de caminhos adequadamente projetado revelará a origem e destinatário final. Suspeita-se também que Bitcoin não satisfaz a segunda propriedade. Alguns pesquisadores afirmou ([33, 35, 29, 31]) que uma análise cuidadosa de blockchain pode revelar uma conexão entre os usuários da rede Bitcoin e suas transações. Embora vários métodos sejam disputado [25], suspeita-se que muitas informações pessoais ocultas podem ser extraídas do banco de dados público. A falha de Bitcoin em satisfazer as duas propriedades descritas acima nos leva a concluir que é não um sistema de dinheiro eletrônico anônimo, mas pseudo-anônimo. Os usuários foram rápidos em desenvolver soluções para contornar esta lacuna. Duas soluções diretas foram “serviços de lavagem” [2] e o desenvolvimento de métodos distribuídos [3, 4]. Ambas as soluções baseiam-se na ideia de misturar diversas transações públicas e envio através de algum endereço intermediário; que por sua vez sofre a desvantagem de exigir um terceiro confiável. Recentemente, um esquema mais criativo foi proposto por I. Miers et al. [28]: “Zerocoin”. Zerocoin utiliza acumuladores criptográficos unidirecionais e provas de conhecimento zero que permitem aos usuários “converter” bitcoins em zerocoins e gastá-los usando prova anônima de propriedade em vez de assinaturas digitais explícitas baseadas em chave pública. No entanto, tais provas de conhecimento têm uma constante mas tamanho inconveniente - cerca de 30kb (com base nos limites Bitcoin atuais), o que torna a proposta impraticável. Os autores admitem que é improvável que o protocolo seja aceito pela maioria dos Bitcoin usuários [5]. 2.2 A função proof-of-work O criador de Bitcoin, Satoshi Nakamoto, descreveu o algoritmo de tomada de decisão majoritária como “oneCPU-one-vote” e usou uma função de precificação vinculada à CPU (duplo SHA-256) para seu proof-of-work esquema. Como os usuários votam no pedido único de histórico de transações [1], a razoabilidade e a consistência deste processo são condições críticas para todo o sistema. A segurança deste modelo apresenta duas desvantagens. Primeiro, requer 51% da rede o poder de mineração esteja sob o controle de usuários honestos. Em segundo lugar, o progresso do sistema (correções de bugs, correções de segurança, etc...) exigem que a esmagadora maioria dos usuários apoie e concorde com o mudanças (isso ocorre quando os usuários atualizam seu software de carteira) [6].Finalmente esta mesma votação O mecanismo também é usado para pesquisas coletivas sobre a implementação de alguns recursos [7]. Isso nos permite conjecturar as propriedades que devem ser satisfeitas pelo proof-of-work função de precificação. Essa função não deve permitir que um participante da rede tenha um impacto significativo vantagem sobre outro participante; requer uma paridade entre hardware comum e alta custo de dispositivos personalizados. A partir de exemplos recentes [8], podemos ver que a função SHA-256 usada na arquitetura Bitcoin não possui esta propriedade à medida que a mineração se torna mais eficiente em GPUs e dispositivos ASIC em comparação com CPUs de última geração. Portanto, Bitcoin cria condições favoráveis para uma grande lacuna entre o poder de voto de participantes, pois viola o princípio “uma CPU um voto”, uma vez que os proprietários de GPU e ASIC possuem um poder de voto muito maior quando comparado aos proprietários de CPU. É um exemplo clássico do Princípio de Pareto onde 20% dos participantes de um sistema controlam mais de 80% dos votos. Pode-se argumentar que tal desigualdade não é relevante para a segurança da rede, uma vez que não é o pequeno número de participantes que controlam a maioria dos votos, mas a honestidade destes participantes que importa. No entanto, tal argumento é um tanto falho, uma vez que é antes o possibilidade de hardware especializado barato aparecer em vez da honestidade dos participantes que representa uma ameaça. Para demonstrar isso, tomemos o seguinte exemplo. Suponha que um malévolo indivíduo ganha poder de mineração significativo ao criar sua própria fazenda de mineração por meio de recursos baratos. 2 4 Presumivelmente, se cada usuário ajudar seu próprio anonimato gerando sempre um novo endereço para CADA pagamento recebido (o que é absurdo, mas tecnicamente a maneira "correta" de fazer isso), e se cada usuário ajudasse o anonimato de todos, insistindo para que nunca enviassem fundos para o mesmo endereço BTC duas vezes, então Bitcoin ainda passaria apenas circunstancialmente o teste de desvinculação. Por que? Os dados do consumidor podem ser usados para descobrir uma quantidade surpreendente sobre as pessoas o tempo todo. Veja, por exemplo, http://www.applieddatalabs.com/content/target-knows-it-shows Agora, imagine que isso aconteça 20 anos no futuro e imagine ainda que a Target não apenas soubesse sobre seus hábitos de compra na Target, mas eles estavam explorando o blockchain para TODOS SUAS COMPRAS PESSOAIS COM SUA CARTEIRA COINBASE DO PASSADO DOZE ANOS. Eles vão ficar tipo "ei, amigo, você pode querer comprar um remédio para tosse esta noite, você não vai sinta-se bem amanhã." Este pode não ser o caso se a classificação multipartidária for explorada corretamente. Veja, por exemplo, estepostagem do blog: http://blog.ezyang.com/2012/07/secure-multiparty-bitcoin-anonymization/ Não estou totalmente convencido da matemática disso, mas... um trabalho de cada vez, certo? Citação necessária. Embora o protocolo Zerocoin (autônomo) possa ser insuficiente, o Zerocash protocolo parece ter implementado transações de tamanho de 1kb. Esse projeto é apoiado por os militares dos EUA e de Israel, claro, por isso quem sabe da sua robustez. Por outro Por outro lado, ninguém deseja poder gastar fundos sem supervisão mais do que os militares. http://zerocash-project.org/ Não estou convencido... veja, por exemplo, http://fc14.ifca.ai/bitcoin/papers/bitcoin14_submission_12.pdf Citando um desenvolvedor do Cryptonote, Maurice Planck (presumivelmente um pseudônimo) do cryptonote fora: "Zerocoin, Zerocash. Esta é a tecnologia mais avançada, devo admitir. Sim, a citação acima é da análise da versão anterior do protocolo. Que eu saiba, não é 288, mas 384 bytes, mas de qualquer forma, são boas notícias. Eles usaram uma técnica totalmente nova chamada SNARK, que tem algumas desvantagens: por exemplo, grande banco de dados inicial de parâmetros públicos necessários para criar uma assinatura (mais de 1 GB) e tempo significativo necessário para criar uma transação (mais de um minuto). Finalmente, eles estão usando um criptografia jovem, que mencionei ser uma ideia discutível: https://forum.cryptonote.org/viewtopic.php?f= " - Maurice P. Qui, 3 de abril de 2014, 19h56 Uma função que é executada na CPU e não é adequada para GPU, FPGA ou ASIC computação. O "quebra-cabeça" usado em proof-of-work é referido como função de preço, função de custo ou função de quebra-cabeça.
inequivocamente atribuída a uma origem única e a um destinatário final. Mesmo que dois participantes troquem fundos de forma indireta, um método de descoberta de caminhos adequadamente projetado revelará a origem e destinatário final. Suspeita-se também que Bitcoin não satisfaz a segunda propriedade. Alguns pesquisadores afirmou ([33, 35, 29, 31]) que uma análise cuidadosa de blockchain pode revelar uma conexão entre os usuários da rede Bitcoin e suas transações. Embora vários métodos sejam contestado [25], suspeita-se que muitas informações pessoais ocultas podem ser extraídas do banco de dados público. A falha de Bitcoin em satisfazer as duas propriedades descritas acima nos leva a concluir que é não um sistema de dinheiro eletrônico anônimo, mas pseudo-anônimo. Os usuários foram rápidos em desenvolver soluções para contornar esta lacuna. Duas soluções diretas foram “serviços de lavagem” [2] e o desenvolvimento de métodos distribuídos [3, 4]. Ambas as soluções baseiam-se na ideia de misturar diversas transações públicas e envio através de algum endereço intermediário; que por sua vez sofre a desvantagem de exigir um terceiro confiável. Recentemente, um esquema mais criativo foi proposto por I. Miers et al. [28]: “Zerocoin”. Zerocoin utiliza acumuladores criptográficos unidirecionais e provas de conhecimento zero que permitem aos usuários “converter” bitcoins em zerocoins e gastá-los usando prova anônima de propriedade em vez de assinaturas digitais explícitas baseadas em chave pública. No entanto, tais provas de conhecimento têm uma constante mas tamanho inconveniente - cerca de 30kb (com base nos limites Bitcoin atuais), o que torna a proposta impraticável. Os autores admitem que é improvável que o protocolo seja aceito pela maioria dos Bitcoin usuários [5]. 2.2 A função proof-of-work O criador de Bitcoin, Satoshi Nakamoto, descreveu o algoritmo de tomada de decisão majoritária como “oneCPU-one-vote” e usou uma função de precificação vinculada à CPU (duplo SHA-256) para seu proof-of-work esquema. Como os usuários votam no pedido único de histórico de transações [1], a razoabilidade e a consistência deste processo são condições críticas para todo o sistema. A segurança deste modelo apresenta duas desvantagens. Primeiro, requer 51% da rede o poder de mineração esteja sob o controle de usuários honestos. Em segundo lugar, o progresso do sistema (correções de bugs, correções de segurança, etc...) exigem que a esmagadora maioria dos usuários apoie e concorde com o mudanças (isso ocorre quando os usuários atualizam seu software de carteira) [6].Finalmente esta mesma votação O mecanismo também é usado para pesquisas coletivas sobre a implementação de alguns recursos [7]. Isso nos permite conjecturar as propriedades que devem ser satisfeitas pelo proof-of-work função de precificação. Essa função não deve permitir que um participante da rede tenha um impacto significativo vantagem sobre outro participante; requer uma paridade entre hardware comum e alta custo de dispositivos personalizados. A partir de exemplos recentes [8], podemos ver que a função SHA-256 usada na arquitetura Bitcoin não possui esta propriedade à medida que a mineração se torna mais eficiente em GPUs e dispositivos ASIC em comparação com CPUs de última geração. Portanto, Bitcoin cria condições favoráveis para uma grande lacuna entre o poder de voto de participantes, pois viola o princípio “uma CPU um voto”, uma vez que os proprietários de GPU e ASIC possuem um poder de voto muito maior quando comparado aos proprietários de CPU. É um exemplo clássico do Princípio de Pareto onde 20% dos participantes de um sistema controlam mais de 80% dos votos. Pode-se argumentar que tal desigualdade não é relevante para a segurança da rede, uma vez que não é o pequeno número de participantes que controlam a maioria dos votos, mas a honestidade destes participantes que importa. No entanto, tal argumento é um tanto falho, uma vez que é antes o possibilidade de hardware especializado barato aparecer em vez da honestidade dos participantes que representa uma ameaça. Para demonstrar isso, tomemos o seguinte exemplo. Suponha que um malévolo indivíduo ganha poder de mineração significativo ao criar sua própria fazenda de mineração por meio de recursos baratos. 2 inequivocamente atribuída a uma origem única e a um destinatário final. Mesmo que dois participantes troquem fundos de forma indireta, um método de descoberta de caminhos adequadamente projetado revelará a origem e destinatário final. Suspeita-se também que Bitcoin não satisfaz a segunda propriedade. Alguns pesquisadores afirmou ([33, 35, 29, 31]) que uma análise cuidadosa de blockchain pode revelar uma conexão entre os usuários da rede Bitcoin e suas transações. Embora vários métodos sejam disputado [25], suspeita-se que muitas informações pessoais ocultas podem ser extraídas do banco de dados público. A falha de Bitcoin em satisfazer as duas propriedades descritas acima nos leva a concluir que é não um sistema de dinheiro eletrônico anônimo, mas pseudo-anônimo. Os usuários foram rápidos em desenvolver soluções para contornar esta lacuna. Duas soluções diretas foram “serviços de lavagem” [2] e o desenvolvimento de métodos distribuídos [3, 4]. Ambas as soluções baseiam-se na ideia de misturar diversas transações públicas e envio através de algum endereço intermediário; que por sua vez sofre a desvantagem de exigir um terceiro confiável. Recentemente, um esquema mais criativo foi proposto por I. Miers et al. [28]: “Zerocoin”. Zerocoin utiliza acumuladores criptográficos unidirecionais e provas de conhecimento zero que permitem aos usuários “converter” bitcoins em zerocoins e gastá-los usando prova anônima de propriedade em vez de assinaturas digitais explícitas baseadas em chave pública. No entanto, tais provas de conhecimento têm uma constante mas tamanho inconveniente - cerca de 30kb (com base nos limites Bitcoin atuais), o que torna a proposta impraticável. Os autores admitem que é improvável que o protocolo seja aceito pela maioria dos Bitcoin usuários [5]. 2.2 A função proof-of-work O criador de Bitcoin, Satoshi Nakamoto, descreveu o algoritmo de tomada de decisão majoritária como “oneCPU-one-vote” e usou uma função de precificação vinculada à CPU (duplo SHA-256) para seu proof-of-work esquema. Como os usuários votam no pedido único de histórico de transações [1], a razoabilidade e a consistência deste processo são condições críticas para todo o sistema. A segurança deste modelo apresenta duas desvantagens. Primeiro, requer 51% da rede o poder de mineração esteja sob o controle de usuários honestos. Em segundo lugar, o progresso do sistema (correções de bugs, correções de segurança, etc...) exigem que a esmagadora maioria dos usuários apoie e concorde com o mudanças (isso ocorre quando os usuários atualizam seu software de carteira) [6].Finalmente esta mesma votação O mecanismo também é usado para pesquisas coletivas sobre a implementação de alguns recursos [7]. Isso nos permite conjecturar as propriedades que devem ser satisfeitas pelo proof-of-work função de precificação. Essa função não deve permitir que um participante da rede tenha um impacto significativo vantagem sobre outro participante; requer uma paridade entre hardware comum e alta custo de dispositivos personalizados. A partir de exemplos recentes [8], podemos ver que a função SHA-256 usada na arquitetura Bitcoin não possui esta propriedade à medida que a mineração se torna mais eficiente em GPUs e dispositivos ASIC em comparação com CPUs de última geração. Portanto, Bitcoin cria condições favoráveis para uma grande lacuna entre o poder de voto de participantes, pois viola o princípio “uma CPU um voto”, uma vez que os proprietários de GPU e ASIC possuem um poder de voto muito maior quando comparado aos proprietários de CPU. É um exemplo clássico do Princípio de Pareto onde 20% dos participantes de um sistema controlam mais de 80% dos votos. Pode-se argumentar que tal desigualdade não é relevante para a segurança da rede, uma vez que não é o pequeno número de participantes que controlam a maioria dos votos, mas a honestidade destes participantes que importa. No entanto, tal argumento é um tanto falho, uma vez que é antes o possibilidade de hardware especializado barato aparecer em vez da honestidade dos participantes que representa uma ameaça. Para demonstrar isso, tomemos o seguinte exemplo. Suponha que um malévolo indivíduo ganha poder de mineração significativo ao criar sua própria fazenda de mineração por meio de recursos baratos. 2 Comentários na página 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.
A tecnologia CryptoNote
Agora que cobrimos as limitações da tecnologia Bitcoin, nos concentraremos em apresentando os recursos do 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
Transações não rastreáveis
Nesta seção propomos um esquema de transações totalmente anônimas que satisfaça tanto a inrastreabilidade
e condições de desvinculação. Uma característica importante da nossa solução é a sua autonomia: o remetente
não é obrigado a cooperar com outros usuários ou terceiros de confiança para realizar suas transações;
portanto, cada participante produz um tráfego de cobertura de forma independente.
4.1
Revisão de literatura
Nosso esquema depende da primitiva criptográfica chamada assinatura de grupo. Apresentado pela primeira vez por
D. Chaum e E. van Heyst [19], permite que um usuário assine sua mensagem em nome do grupo.
Depois de assinar a mensagem, o usuário fornece (para fins de verificação) não seu próprio endereço público.
1Este é o chamado “limite flexível” – a restrição do cliente de referência para a criação de novos blocos. Difícil máximo de
o tamanho de bloco possível era de 1 MB
4
se necessário, o que causa as principais desvantagens. Infelizmente, é difícil prever quando
constantes podem precisar ser alteradas e substituí-las pode levar a consequências terríveis.
Um bom exemplo de alteração de limite codificada que leva a consequências desastrosas é o bloqueio
limite de tamanho definido para 250kb1. Este limite foi suficiente para realizar cerca de 10.000 transações padrão. Em
No início de 2013, esse limite estava quase alcançado e foi alcançado um acordo para aumentar o
limite. A mudança foi implementada na versão 0.8 da carteira e terminou com uma divisão da cadeia de 24 blocos
e um ataque de gasto duplo bem-sucedido [9]. Embora o bug não estivesse no protocolo Bitcoin, mas
em vez disso, no mecanismo de banco de dados, ele poderia ter sido facilmente detectado por um simples teste de estresse, se houvesse
nenhum limite de tamanho de bloco introduzido artificialmente.
As constantes também atuam como uma forma de ponto de centralização.
Apesar da natureza peer-to-peer
Bitcoin, a esmagadora maioria dos nós usa o cliente de referência oficial [10] desenvolvido por
um pequeno grupo de pessoas. Este grupo toma a decisão de implementar mudanças no protocolo
e a maioria das pessoas aceita estas mudanças independentemente da sua “correcção”. Algumas decisões causaram
discussões acaloradas e até apelos ao boicote [11], o que indica que a comunidade e o
os desenvolvedores podem discordar em alguns pontos importantes. Parece, portanto, lógico ter um protocolo
com variáveis configuráveis pelo usuário e autoajustáveis como uma possível forma de evitar esses problemas.
2,5
Scripts volumosos
O sistema de script em Bitcoin é um recurso pesado e complexo. Ele potencialmente permite criar
transações sofisticadas [12], mas alguns de seus recursos estão desativados devido a questões de segurança e
alguns nunca foram usados [13]. O script (incluindo as partes do remetente e do destinatário)
para a transação mais popular em Bitcoin fica assim:
chave, mas as chaves de todos os usuários de seu grupo. Um verificador está convencido de que o verdadeiro signatário é um membro do grupo, mas não pode identificar exclusivamente o signatário. O protocolo original exigia um terceiro de confiança (chamado Gerente de Grupo), e ele era o único que poderia rastrear o signatário. A próxima versão chamada assinatura de anel, introduzida por Rivest et al. em [34], era um esquema autônomo, sem Gerente de Grupo e anonimato revogação. Várias modificações deste esquema apareceram mais tarde: assinatura de anel vinculável [26, 27, 17] permitiu determinar se duas assinaturas foram produzidas pelo mesmo membro do grupo, rastreáveis a assinatura do anel [24, 23] limitou o anonimato excessivo, fornecendo a possibilidade de rastrear o signatário do duas mensagens relativas à mesma metainformação (ou “tag” em termos de [24]). Uma construção criptográfica semelhante também é conhecida como assinatura de grupo ad-hoc [16, 38]. Isso enfatiza a formação arbitrária de grupos, enquanto os esquemas de assinatura de grupo/anel implicam uma conjunto fixo de membros. Na maior parte, nossa solução é baseada no trabalho “Assinatura de anel rastreável” de E. Fujisaki e K. Suzuki [24]. Para distinguir o algoritmo original e nossa modificação, chame o último de assinatura de toque única, enfatizando a capacidade do usuário de produzir apenas uma assinatura válida. assinatura sob sua chave privada. Enfraquecemos a propriedade de rastreabilidade e mantivemos a vinculabilidade apenas para fornecer unicidade: a chave pública pode aparecer em muitos conjuntos de verificação estrangeiros e o a chave privada pode ser usada para gerar uma assinatura anônima exclusiva. Em caso de gasto duplo tentativa, essas duas assinaturas serão vinculadas, mas não é necessário revelar o signatário para nossos propósitos. 4.2 Definições 4.2.1 Parâmetros de curva elíptica Como nosso algoritmo de assinatura base optamos por utilizar o esquema rápido EdDSA, que é desenvolvido e implementado por D.J. Bernstein et al. [18]. Como o ECDSA de Bitcoin, é baseado na curva elíptica problema de logaritmo discreto, portanto nosso esquema também poderá ser aplicado a Bitcoin no futuro. Os parâmetros comuns são: q: um número primo; q = 2255 −19; d: um elemento de Fq; d = −121665/121666; E: uma equação de curva elíptica; −x2 + y2 = 1 + dx2y2; G: um ponto base; G = (x, −4/5); l: uma ordem prima do ponto base; eu = 2252 + 27742317777372353535851937790883648493; \(H_s\): uma função criptográfica hash \(\{0, 1\}^* \to \mathbb{F}_q\); \(H_p\): uma função determinística hash \(E(\mathbb{F}_q) \to E(\mathbb{F}_q)\). 4.2.2 Terminologia A privacidade aprimorada requer uma nova terminologia que não deve ser confundida com entidades Bitcoin. private ec-key é uma chave privada de curva elíptica padrão: um número \(a \in [1, l - 1]\); public ec-key é uma chave pública de curva elíptica padrão: um ponto A = aG; par de chaves único é um par de chaves eletrônicas privadas e públicas; 5 chave, mas as chaves de todos os usuários de seu grupo. Um verificador está convencido de que o verdadeiro signatário é um membro do grupo, mas não pode identificar exclusivamente o signatário. O protocolo original exigia um terceiro de confiança (chamado Gerente de Grupo), e ele era o único que poderia rastrear o signatário. A próxima versão chamada assinatura de anel, introduzida por Rivest et al. em [34], era um esquema autônomo, sem Gerente de Grupo e anonimato revogação. Várias modificações deste esquema apareceram mais tarde: assinatura de anel vinculável [26, 27, 17] permitiu determinar se duas assinaturas foram produzidas pelo mesmo membro do grupo, rastreáveis a assinatura do anel [24, 23] limitou o anonimato excessivo, fornecendo a possibilidade de rastrear o signatário do duas mensagens relativas à mesma metainformação (ou “tag” em termos de [24]). Uma construção criptográfica semelhante também é conhecida como assinatura de grupo ad-hoc [16, 38]. Isso enfatiza a formação arbitrária de grupos, enquanto os esquemas de assinatura de grupo/anel implicam uma conjunto fixo de membros. Na maior parte, nossa solução é baseada no trabalho “Assinatura de anel rastreável” de E. Fujisaki e K. Suzuki [24]. Para distinguir o algoritmo original e nossa modificação, chame o último de assinatura de toque única, enfatizando a capacidade do usuário de produzir apenas uma assinatura válida. assinatura sob sua chave privada. Enfraquecemos a propriedade de rastreabilidade e mantivemos a vinculabilidade apenas para fornecer unicidade: a chave pública pode aparecer em muitos conjuntos de verificação estrangeiros e o a chave privada pode ser usada para gerar uma assinatura anônima exclusiva. Em caso de gasto duplo tentativa, essas duas assinaturas serão vinculadas, mas não é necessário revelar o signatário para nossos propósitos. 4.2 Definições 4.2.1 Parâmetros de curva elíptica Como nosso algoritmo de assinatura base escolhemose utilizar o esquema rápido EdDSA, que é desenvolvido e implementado por D.J. Bernstein et al. [18]. Como o ECDSA de Bitcoin, é baseado na curva elíptica problema de logaritmo discreto, portanto nosso esquema também poderá ser aplicado a Bitcoin no futuro. Os parâmetros comuns são: q: um número primo; q = 2255 −19; d: um elemento de Fq; d = −121665/121666; E: uma equação de curva elíptica; −x2 + y2 = 1 + dx2y2; G: um ponto base; G = (x, −4/5); l: uma ordem prima do ponto base; eu = 2252 + 27742317777372353535851937790883648493; \(H_s\): uma função criptográfica hash \(\{0, 1\}^* \to \mathbb{F}_q\); \(H_p\): uma função determinística hash \(E(\mathbb{F}_q) \to E(\mathbb{F}_q)\). 4.2.2 Terminologia A privacidade aprimorada requer uma nova terminologia que não deve ser confundida com entidades Bitcoin. private ec-key é uma chave privada de curva elíptica padrão: um número \(a \in [1, l - 1]\); public ec-key é uma chave pública de curva elíptica padrão: um ponto A = aG; par de chaves único é um par de chaves eletrônicas privadas e públicas; 5 8 Uma assinatura de anel funciona assim: Alex quer vazar uma mensagem para o WikiLeaks sobre seu empregador. Cada funcionário de sua empresa possui um par de chaves privada/pública (Ri, Ui). Ela compõe sua assinatura com entrada definida como sua mensagem, m, sua chave privada, Ri e TODOS chaves públicas, (Ui;i=1...n). Qualquer pessoa (sem conhecer nenhuma chave privada) pode verificar facilmente que algum par (Rj, Uj) deve ter sido usado para construir a assinatura... alguém que trabalha para o empregador de Alex... mas é essencialmente um palpite aleatório para descobrir qual poderia ser. 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 Observe que uma assinatura de anel vinculável descrita aqui é o oposto de "desvinculável" descrito acima. Aqui, interceptamos duas mensagens e podemos determinar se a mesma parte os enviou, embora ainda não consigamos determinar quem é essa parte. O A definição de "desvinculável" usada para construir o Cryptonote significa que não podemos determinar se a mesma parte os está recebendo. Portanto, o que realmente temos aqui são QUATRO coisas acontecendo. Um sistema pode ser conectável ou não vinculável, dependendo se é ou não possível determinar se o remetente do duas mensagens são iguais (independentemente de isso exigir a revogação do anonimato). E um sistema pode ser desvinculável ou não desvinculável, dependendo se é ou não possível determinar se o receptor de duas mensagens é o mesmo (independentemente de ser ou não isso requer a revogação do anonimato). Por favor, não me culpe por esta terminologia terrível. Os teóricos dos grafos provavelmente deveriam estar satisfeito. Alguns de vocês podem se sentir mais confortáveis com “vinculável ao receptor” versus “vinculável ao remetente”. http://link.springer.com/chapter/10.1007/978-3-540-71677-8_13 Quando li isso, parecia um recurso bobo. Então li que pode ser um recurso para votação electrónica, e isso parecia fazer sentido. Muito legal, dessa perspectiva. Mas eu estou não tenho certeza sobre a implementação proposital de assinaturas de anel rastreáveis. http://search.ieice.org/bin/summary.php?id=e95-a_1_151
chave, mas as chaves de todos os usuários de seu grupo. Um verificador está convencido de que o verdadeiro signatário é um membro do grupo, mas não pode identificar exclusivamente o signatário. O protocolo original exigia um terceiro de confiança (chamado Gerente de Grupo), e ele era o único que poderia rastrear o signatário. A próxima versão chamada assinatura de anel, introduzida por Rivest et al. em [34], era um esquema autônomo, sem Gerente de Grupo e anonimato revogação. Várias modificações deste esquema apareceram mais tarde: assinatura de anel vinculável [26, 27, 17] permitiu determinar se duas assinaturas foram produzidas pelo mesmo membro do grupo, rastreáveis a assinatura do anel [24, 23] limitou o anonimato excessivo, fornecendo a possibilidade de rastrear o signatário do duas mensagens relativas à mesma metainformação (ou “tag” em termos de [24]). Uma construção criptográfica semelhante também é conhecida como assinatura de grupo ad-hoc [16, 38]. Isso enfatiza a formação arbitrária de grupos, enquanto os esquemas de assinatura de grupo/anel implicam uma conjunto fixo de membros. Na maior parte, nossa solução é baseada no trabalho “Assinatura de anel rastreável” de E. Fujisaki e K. Suzuki [24]. Para distinguir o algoritmo original e nossa modificação, chame o último de assinatura de toque única, enfatizando a capacidade do usuário de produzir apenas uma assinatura válida. assinatura sob sua chave privada. Enfraquecemos a propriedade de rastreabilidade e mantivemos a vinculabilidade apenas para fornecer unicidade: a chave pública pode aparecer em muitos conjuntos de verificação estrangeiros e o a chave privada pode ser usada para gerar uma assinatura anônima exclusiva. Em caso de gasto duplo tentativa, essas duas assinaturas serão vinculadas, mas não é necessário revelar o signatário para nossos propósitos. 4.2 Definições 4.2.1 Parâmetros de curva elíptica Como nosso algoritmo de assinatura base optamos por utilizar o esquema rápido EdDSA, que é desenvolvido e implementado por D.J. Bernstein et al. [18]. Assim como o ECDSA de Bitcoin, é baseado na curva elíptica problema de logaritmo discreto, portanto nosso esquema também poderá ser aplicado a Bitcoin no futuro. Os parâmetros comuns são: q: um número primo; q = 2255 −19; d: um elemento de Fq; d = −121665/121666; E: uma equação de curva elíptica; −x2 + y2 = 1 + dx2y2; G: um ponto base; G = (x, −4/5); l: uma ordem prima do ponto base; eu = 2252 + 27742317777372353535851937790883648493; \(H_s\): uma função criptográfica hash \(\{0, 1\}^* \to \mathbb{F}_q\); \(H_p\): uma função determinística hash \(E(\mathbb{F}_q) \to E(\mathbb{F}_q)\). 4.2.2 Terminologia A privacidade aprimorada requer uma nova terminologia que não deve ser confundida com entidades Bitcoin. private ec-key é uma chave privada de curva elíptica padrão: um número \(a \in [1, l - 1]\); public ec-key é uma chave pública de curva elíptica padrão: um ponto A = aG; par de chaves único é um par de chaves eletrônicas privadas e públicas; 5 chave, mas as chaves de todos os usuários de seu grupo. Um verificador está convencido de que o verdadeiro signatário é um membro do grupo, mas não pode identificar exclusivamente o signatário. O protocolo original exigia um terceiro de confiança (chamado Gerente de Grupo), e ele era o único que poderia rastrear o signatário. A próxima versão chamada assinatura de anel, introduzida por Rivest et al. em [34], era um esquema autônomo, sem Gerente de Grupo e anonimato revogação. Várias modificações deste esquema apareceram mais tarde: assinatura de anel vinculável [26, 27, 17] permitiu determinar se duas assinaturas foram produzidas pelo mesmo membro do grupo, rastreáveis a assinatura do anel [24, 23] limitou o anonimato excessivo, fornecendo a possibilidade de rastrear o signatário do duas mensagens relativas à mesma metainformação (ou “tag” em termos de [24]). Uma construção criptográfica semelhante também é conhecida como assinatura de grupo ad-hoc [16, 38]. Isso enfatiza a formação arbitrária de grupos, enquanto os esquemas de assinatura de grupo/anel implicam uma conjunto fixo de membros. Na maior parte, nossa solução é baseada no trabalho “Assinatura de anel rastreável” de E. Fujisaki e K. Suzuki [24]. Para distinguir o algoritmo original e nossa modificação, chame o último de assinatura de toque única, enfatizando a capacidade do usuário de produzir apenas uma assinatura válida. assinatura sob sua chave privada. Enfraquecemos a propriedade de rastreabilidade e mantivemos a vinculabilidade apenas para fornecer unicidade: a chave pública pode aparecer em muitos conjuntos de verificação estrangeiros e o a chave privada pode ser usada para gerar uma assinatura anônima exclusiva. Em caso de gasto duplo tentativa, essas duas assinaturas serão vinculadas, mas não é necessário revelar o signatário para nossos propósitos. 4.2 Definições 4.2.1 Parâmetros de curva elíptica Como nosso algoritmo de assinatura base escolhemose utilizar o esquema rápido EdDSA, que é desenvolvido e implementado por D.J. Bernstein et al. [18]. Como o ECDSA de Bitcoin, é baseado na curva elíptica problema de logaritmo discreto, portanto nosso esquema também poderá ser aplicado a Bitcoin no futuro. Os parâmetros comuns são: q: um número primo; q = 2255 −19; d: um elemento de Fq; d = −121665/121666; E: uma equação de curva elíptica; −x2 + y2 = 1 + dx2y2; G: um ponto base; G = (x, −4/5); l: uma ordem prima do ponto base; eu = 2252 + 27742317777372353535851937790883648493; \(H_s\): uma função criptográfica hash \(\{0, 1\}^* \to \mathbb{F}_q\); \(H_p\): uma função determinística hash \(E(\mathbb{F}_q) \to E(\mathbb{F}_q)\). 4.2.2 Terminologia A privacidade aprimorada requer uma nova terminologia que não deve ser confundida com entidades Bitcoin. private ec-key é uma chave privada de curva elíptica padrão: um número \(a \in [1, l - 1]\); public ec-key é uma chave pública de curva elíptica padrão: um ponto A = aG; par de chaves único é um par de chaves eletrônicas privadas e públicas; 5 9 Nossa, o autor deste whitepaper certamente poderia ter formulado isso melhor! Digamos que um empresa de propriedade de funcionários deseja votar sobre a aquisição ou não de determinados novos ativos, e Alex e Brenda são funcionários. A Empresa oferece a cada funcionário um mensagem como "Eu voto sim na Proposta A!" que tem o "problema" de metainformação [PROP A] e pede-lhes que assinem com uma assinatura rastreável se apoiarem a proposta. Usando uma assinatura tradicional, um funcionário desonesto pode assinar a mensagem várias vezes, presumivelmente com nonces diferentes, para votar quantas vezes quiserem. Por outro Por outro lado, em um esquema de assinatura de anel rastreável, Alex irá votar e sua chave privada terá foi usado na questão [PROP A]. Se Alex tentar assinar uma mensagem como "Eu, Brenda, aprovo proposição A!" para "enquadrar" Brenda e votar duas vezes, esta nova mensagem também terá o problema [PROP A]. Como a chave privada de Alex já acionou o problema [PROP A], a identidade de Alex será imediatamente revelado como uma fraude. O que, convenhamos, é muito legal! A criptografia impôs a igualdade de voto. http://link.springer.com/chapter/10.1007/978-3-540-71677-8_13 Este artigo é interessante, essencialmente criando uma assinatura de anel ad-hoc, mas sem nenhuma das consentimento do outro participante. A estrutura da assinatura pode ser diferente; eu não cavei profundo e não vi se é seguro. https://people.csail.mit.edu/rivest/AdidaHohenbergerRivest-AdHocGroupSignaturesFromHijackedKeypai As assinaturas de grupo ad-hoc são: assinaturas em anel, que são assinaturas de grupo sem grupo gerentes, sem centralização, mas permite que um membro de um grupo ad-hoc afirme comprovadamente que (não) emitiu a assinatura anônima em nome do grupo. http://link.springer.com/chapter/10.1007/11908739_9 Isso não está totalmente correto, no meu entendimento. E meu entendimento provavelmente mudará à medida que Eu me aprofundo neste projeto. Mas, pelo que entendi, a hierarquia é assim. Assinaturas de grupo: os gerentes de grupo controlam a rastreabilidade e a capacidade de adicionar ou remover membros de serem signatários. Ring assina: Formação arbitrária de grupo sem gerente de grupo. Sem revogação de anonimato. Não há como repudiar uma assinatura específica. Com anel rastreável e conectável assinaturas, o anonimato é um tanto escalonável. Assinaturas de grupo ad-hoc: como assinaturas de anel, mas os membros podem provar que não criaram uma assinatura específica. Isto é importante quando qualquer pessoa de um grupo pode produzir uma assinatura. http://link.springer.com/chapter/10.1007/978-3-540-71677-8_13 O algoritmo de Fujisaki e Suzuki é ajustado posteriormente pelo autor para fornecer unicidade. Então analisaremos o algoritmo de Fujisaki e Suzuki simultaneamente com o novo algoritmo, em vez do que repassar isso aqui.
chave, mas as chaves de todos os usuários de seu grupo. Um verificador está convencido de que o verdadeiro signatário é um membro do grupo, mas não pode identificar exclusivamente o signatário. O protocolo original exigia um terceiro de confiança (chamado Gerente de Grupo), e ele era o único que poderia rastrear o signatário. A próxima versão chamada assinatura de anel, introduzida por Rivest et al. em [34], era um esquema autônomo, sem Gerente de Grupo e anonimato revogação. Várias modificações deste esquema apareceram mais tarde: assinatura de anel vinculável [26, 27, 17] permitiu determinar se duas assinaturas foram produzidas pelo mesmo membro do grupo, rastreáveis a assinatura do anel [24, 23] limitou o anonimato excessivo, fornecendo a possibilidade de rastrear o signatário do duas mensagens relativas à mesma metainformação (ou “tag” em termos de [24]). Uma construção criptográfica semelhante também é conhecida como assinatura de grupo ad-hoc [16, 38]. Isso enfatiza a formação arbitrária de grupos, enquanto os esquemas de assinatura de grupo/anel implicam uma conjunto fixo de membros. Na maior parte, nossa solução é baseada no trabalho “Assinatura de anel rastreável” de E. Fujisaki e K. Suzuki [24]. Para distinguir o algoritmo original e nossa modificação, chame o último de assinatura de toque única, enfatizando a capacidade do usuário de produzir apenas uma assinatura válida. assinatura sob sua chave privada. Enfraquecemos a propriedade de rastreabilidade e mantivemos a vinculabilidade apenas para fornecer unicidade: a chave pública pode aparecer em muitos conjuntos de verificação estrangeiros e o a chave privada pode ser usada para gerar uma assinatura anônima exclusiva. Em caso de gasto duplo tentativa, essas duas assinaturas serão vinculadas, mas não é necessário revelar o signatário para nossos propósitos. 4.2 Definições 4.2.1 Parâmetros de curva elíptica Como nosso algoritmo de assinatura base optamos por utilizar o esquema rápido EdDSA, que é desenvolvido e implementado por D.J. Bernstein et al. [18]. Como o ECDSA de Bitcoin, é baseado na curva elíptica problema de logaritmo discreto, portanto nosso esquema também poderá ser aplicado a Bitcoin no futuro. Os parâmetros comuns são: q: um número primo; q = 2255 −19; d: um elemento de Fq; d = −121665/121666; E: uma equação de curva elíptica; −x2 + y2 = 1 + dx2y2; G: um ponto base; G = (x, −4/5); l: uma ordem prima do ponto base; eu = 2252 + 27742317777372353535851937790883648493; \(H_s\): uma função criptográfica hash \(\{0, 1\}^* \to \mathbb{F}_q\); \(H_p\): uma função determinística hash \(E(\mathbb{F}_q) \to E(\mathbb{F}_q)\). 4.2.2 Terminologia A privacidade aprimorada requer uma nova terminologia que não deve ser confundida com entidades Bitcoin. private ec-key é uma chave privada de curva elíptica padrão: um número \(a \in [1, l - 1]\); public ec-key é uma chave pública de curva elíptica padrão: um ponto A = aG; par de chaves único é um par de chaves eletrônicas privadas e públicas; 5 chave, mas as chaves de todos os usuários de seu grupo. Um verificador está convencido de que o verdadeiro signatário é um membro do grupo, mas não pode identificar exclusivamente o signatário. O protocolo original exigia um terceiro de confiança (chamado Gerente de Grupo), e ele era o único que poderia rastrear o signatário. A próxima versão chamada assinatura de anel, introduzida por Rivest et al. em [34], era um esquema autônomo, sem Gerente de Grupo e anonimato revogação. Várias modificações deste esquema apareceram mais tarde: assinatura de anel vinculável [26, 27, 17] permitiu determinar se duas assinaturas foram produzidas pelo mesmo membro do grupo, rastreáveis a assinatura do anel [24, 23] limitou o anonimato excessivo, fornecendo a possibilidade de rastrear o signatário do duas mensagens relativas à mesma metainformação (ou “tag” em termos de [24]). Uma construção criptográfica semelhante também é conhecida como assinatura de grupo ad-hoc [16, 38]. Isso enfatiza a formação arbitrária de grupos, enquanto os esquemas de assinatura de grupo/anel implicam uma conjunto fixo de membros. Na maior parte, nossa solução é baseada no trabalho “Assinatura de anel rastreável” de E. Fujisaki e K. Suzuki [24]. Para distinguir o algoritmo original e nossa modificação, chame o último de assinatura de toque única, enfatizando a capacidade do usuário de produzir apenas uma assinatura válida. assinatura sob sua chave privada. Enfraquecemos a propriedade de rastreabilidade e mantivemos a vinculabilidade apenas para fornecer unicidade: a chave pública pode aparecer em muitos conjuntos de verificação estrangeiros e o a chave privada pode ser usada para gerar uma assinatura anônima exclusiva. Em caso de gasto duplo tentativa, essas duas assinaturas serão vinculadas, mas não é necessário revelar o signatário para nossos propósitos. 4.2 Definições 4.2.1 Parâmetros de curva elíptica Como nosso algoritmo de assinatura base escolhemose utilizar o esquema rápido EdDSA, que é desenvolvido e implementado por D.J. Bernstein et al. [18]. Assim como o ECDSA de Bitcoin, é baseado na curva elíptica problema de logaritmo discreto, portanto nosso esquema também poderá ser aplicado a Bitcoin no futuro. Os parâmetros comuns são: q: um número primo; q = 2255 −19; d: um elemento de Fq; d = −121665/121666; E: uma equação de curva elíptica; −x2 + y2 = 1 + dx2y2; G: um ponto base; G = (x, −4/5); l: uma ordem prima do ponto base; eu = 2252 + 27742317777372353535851937790883648493; \(H_s\): uma função criptográfica hash \(\{0, 1\}^* \to \mathbb{F}_q\); \(H_p\): uma função determinística hash \(E(\mathbb{F}_q) \to E(\mathbb{F}_q)\). 4.2.2 Terminologia A privacidade aprimorada requer uma nova terminologia que não deve ser confundida com entidades Bitcoin. private ec-key é uma chave privada de curva elíptica padrão: um número \(a \in [1, l - 1]\); public ec-key é uma chave pública de curva elíptica padrão: um ponto A = aG; par de chaves único é um par de chaves eletrônicas privadas e públicas; 5 10 Linkability no sentido de “assinaturas de anel vinculáveis” significa que podemos dizer se duas transações de saída vieram da mesma fonte sem revelar quem é a fonte. Os autores enfraqueceram capacidade de vinculação de modo a (a) preservar a privacidade, mas ainda (b) detectar qualquer transação usando uma chave privada uma segunda vez como inválido. Ok, então esta é uma questão de ordem dos eventos. Considere o seguinte cenário. Minha mineração o computador terá o blockchain atual, terá seu próprio bloco de transações que chama legítimo, ele estará trabalhando nesse bloco em um quebra-cabeça proof-of-work e terá um lista de transações pendentes a serem adicionadas ao próximo bloco. Também enviará novos transações nesse conjunto de transações pendentes. Se eu não resolver o próximo bloco, mas outra pessoa fizer isso, recebo uma cópia atualizada do blockchain. O bloco em que eu estava trabalhando e minha lista de transações pendentes pode ter algumas transações que agora estão incorporadas no blockchain. Desvende meu bloco pendente, combine-o com minha lista de transações pendentes e chame isso meu conjunto de transações pendentes. Remova qualquer um que esteja agora oficialmente em blockchain. Agora, o que eu faço? Devo primeiro analisar e “remover todos os gastos duplos”? Por outro Por outro lado, devo pesquisar na lista e ter certeza de que cada chave privada ainda não foi usado, e se já tiver sido usado na minha lista, então recebi a primeira cópia primeiro e, portanto, qualquer cópia adicional é ilegítima. Assim, procedo simplesmente à exclusão de todas as instâncias após a primeira da mesma chave privada. A geometria algébrica nunca foi meu forte. http://en.wikipedia.org/wiki/EdDSA Tanta velocidade, muito uau. ESTA é geometria algébrica para a vitória. Não que eu saiba de alguma coisa sobre isso. Problematicamente ou não, os logs discretos estão ficando muito rápidos. E os computadores quânticos os comem para o café da manhã. http://link.springer.com/article/10.1007/s13389-012-0027-1 Este se torna um número realmente importante, mas não há explicação ou citação de como ele foi escolhido. Simplesmente escolher um único primo grande conhecido seria bom, mas se houver factos sobre este grande primo, que poderiam influenciar a nossa escolha. Diferentes variantes de cryptonote poderia escolher diferentes valores de tudo bem, mas não há discussão neste artigo sobre como isso escolha afetará nossas escolhas de outros parâmetros globais listados na página 5. Este artigo precisa de uma seção sobre como escolher valores de parâmetros.
a chave privada do usuário é um par (a, b) de duas ec-chaves privadas diferentes; chave de rastreamento é um par (a, B) de chave ec privada e pública (onde B = bG e a ̸= b); a chave pública do usuário é um par (A, B) de duas chaves públicas ec derivadas de (a, b); endereço padrão é uma representação de uma chave pública de usuário fornecida em uma string amigável com correção de erros; endereço truncado é uma representação da segunda metade (ponto B) de uma chave pública de usuário fornecida em uma string amigável com correção de erros. A estrutura da transação permanece semelhante à estrutura em Bitcoin: cada usuário pode escolher vários pagamentos recebidos independentes (saídas de transações), assine-os com o correspondente chaves privadas e enviá-las para diferentes destinos. Ao contrário do modelo de Bitcoin, onde um usuário possui uma chave privada e pública única, no modelo proposto, um remetente gera uma chave pública única com base no endereço do destinatário e alguns dados aleatórios. Neste sentido, uma transação de entrada para o mesmo destinatário é enviada para um chave pública única (não diretamente para um endereço exclusivo) e somente o destinatário pode recuperar a parte privada correspondente para resgatar seus fundos (usando sua chave privada exclusiva). O destinatário pode gastar os fundos usando uma assinatura, mantendo anônima sua propriedade e gastos reais. Os detalhes do protocolo são explicados nas próximas subseções. 4.3 Pagamentos não vinculáveis Os endereços Bitcoin clássicos, uma vez publicados, tornam-se identificadores inequívocos para entrada pagamentos, vinculando-os e vinculando-os aos pseudônimos do destinatário. Se alguém quiser receber uma transação “desamarrada”, ele deverá transmitir seu endereço ao remetente por um canal privado. Se ele quiser receber transações diferentes que não podem ser comprovadas como pertencentes ao mesmo proprietário ele deveria gerar todos os endereços diferentes e nunca publicá-los com seu próprio pseudônimo. Público Privado Alice Carol Endereço 1 de Bob Endereço 2 de Bob Chave 1 de Bob Chave 2 de Bob Bob Figura 2. Modelo tradicional de chaves/transações Bitcoin. Propomos uma solução que permite ao usuário publicar um único endereço e receber informações incondicionais pagamentos invinculáveis. O destino de cada saída do CryptoNote (por padrão) é uma chave pública, derivado do endereço do destinatário e dos dados aleatórios do remetente. A principal vantagem contra Bitcoin é que cada chave de destino é única por padrão (a menos que o remetente use os mesmos dados para cada de suas transações para o mesmo destinatário). Portanto, não existe tal questão como “reutilização de endereço” por design e nenhum observador pode determinar se alguma transação foi enviada para um endereço ou link específico dois endereços juntos. 6 a chave privada do usuário é um par (a, b) de duas ec-chaves privadas diferentes; chave de rastreamento é um par (a, B) de chave ec privada e pública (onde B = bG e a ̸= b); a chave pública do usuário é um par (A, B) de duas chaves públicas ec derivadas de (a, b); endereço padrão é uma representação de uma chave pública de usuário fornecida em uma string amigável com correção de erros; endereço truncado é uma representação da segunda metade (ponto B) de uma chave pública de usuário fornecida em uma string amigável com correção de erros. A estrutura da transação permanece semelhante à estrutura em Bitcoin: cada usuário pode escolher vários pagamentos recebidos independentes (saídas de transações), assine-os com o correspondente chaves privadas e enviá-las para diferentes destinos. Ao contrário do modelo de Bitcoin, onde um usuário possui uma chave privada e pública única, no modelo proposto, um remetente gera uma chave pública única com base no endereço do destinatário e alguns dados aleatórios. Neste sentido, uma transação de entrada para o mesmo destinatário é enviada para um chave pública única (não diretamente para um endereço exclusivo) e somente o destinatário pode recuperar a parte privada correspondente para resgatar seus fundos (usando sua chave privada exclusiva). O destinatário pode gastar os fundos usando uma assinatura, mantendo anônima sua propriedade e gastos reais. Os detalhes do protocolo são explicados nas próximas subseções. 4.3 Pagamentos não vinculáveis Os endereços Bitcoin clássicos, uma vez publicados, tornam-se identificadores inequívocos para entrada pagamentos, vinculando-os e vinculando-os aos pseudônimos do destinatário. Se alguém quiser receber uma transação “desamarrada”, ele deverá transmitir seu endereço ao remetente por um canal privado. Se ele quiser receber transações diferentes que não podem ser comprovadas como pertencentes ao mesmo proprietário ele deveria gerar todos os endereços diferentes e nunca publicá-los com seu próprio pseudônimo. Público Privado Alice Carol Endereço 1 de Bob Endereço 2 de Bob Chave 1 de Bob Chave 2 de Bob Bob Figura 2. Mod tradicional de chaves/transações Bitcoinel. Propomos uma solução que permite ao usuário publicar um único endereço e receber informações incondicionais pagamentos invinculáveis. O destino de cada saída do CryptoNote (por padrão) é uma chave pública, derivado do endereço do destinatário e dos dados aleatórios do remetente. A principal vantagem contra Bitcoin é que cada chave de destino é única por padrão (a menos que o remetente use os mesmos dados para cada de suas transações para o mesmo destinatário). Portanto, não existe tal questão como “reutilização de endereço” por design e nenhum observador pode determinar se alguma transação foi enviada para um endereço ou link específico dois endereços juntos. 6 11 Então é como Bitcoin, mas com caixas postais anônimas e infinitas, resgatáveis apenas pelo destinatário gerar uma chave privada que seja tão anônima quanto uma assinatura de anel pode ser. Bitcoin funciona desta forma. Se Alex tiver 0,112 Bitcoin em sua carteira que acabou de receber de Frank, ela realmente tem um documento assinado mensagem "Eu, [FRANK], envio 0,112 Bitcoin para [alex] + H0 + N0" onde 1) Frank assinou o mensagem com sua chave privada [FRANK], 2) Frank assinou a mensagem com a chave pública de Alex chave, [alex], 3) Frank incluiu alguma forma da história do bitcoin, H0, e 4) Frank inclui um bit aleatório de dados chamado nonce, N0. Se Alex quiser enviar 0.011 Bitcoin para Charlene, ela receberá a mensagem de Frank e definirá isso como H1 e assinará duas mensagens: uma para a transação dela e outra para a alteração. H1= "Eu, [FRANK], envio 0,112 Bitcoin para [alex] + H0 + N" "Eu, [ALEX], envio 0,011 Bitcoin para [charlene] + H1 + N1" "Eu, [ALEX], envio 0,101 Bitcoin como alteração para [alex] + H1 + N2." onde Alex assina ambas as mensagens com sua chave privada [ALEX], a primeira mensagem com a chave privada de Charlene chave pública [charlene], a segunda mensagem com a chave pública de Alex [alex], e incluindo a históricos e alguns nonces N1 e N2 gerados aleatoriamente de forma adequada. Cryptonote funciona desta maneira: Se Alex tiver 0,112 Cryptonote em sua carteira que acabou de receber de Frank, ela realmente tem um documento assinado mensagem "Eu, [alguém em um grupo ad-hoc], envio 0,112 Cryptonote para [um endereço único] + H0 +N0." Alex descobriu que esse era o dinheiro dela, verificando sua chave privada [ALEX] [um endereço único] para cada mensagem que passa, e se ela quiser gastá-lo, ela o faz em da seguinte maneira. Ela escolhe um destinatário do dinheiro, talvez Charlene tenha começado a votar a favor de ataques com drones, então Alex quer enviar dinheiro para Brenda. Então Alex procura a chave pública de Brenda, [brenda], e usa sua própria chave privada, [ALEX], para gerar um endereço único [ALEX+brenda]. Ela então escolhe uma coleção arbitrária C da rede de usuários de criptomoedas e ela constrói uma assinatura de anel deste grupo ad-hoc. Definimos nossa história como a mensagem anterior, adicionamos nonces e proceder normalmente? H1 = "Eu, [alguém em um grupo ad-hoc], envio 0,112 Cryptonote para [um endereço único] + H0 +N0." "Eu, [alguém da coleção C], envio 0,011 Cryptonote para [endereço único feito deALEX+brenda] + H1 + N1" "Eu, [alguém da coleção C], envio 0,101 Cryptonote como alteração para [endereço único feito de ALEX + alex] + H1 + N2" Agora, Alex e Brenda verificam todas as mensagens recebidas em busca de endereços únicos que foram criado usando sua chave. Se eles encontrarem alguma, então essa mensagem é sua própria e totalmente nova. criptonota! E mesmo assim, a transação ainda atingirá blockchain. Se as moedas entrando nesse endereço são conhecidos por serem enviados por criminosos, contribuintes políticos ou por comitês e contas com orçamentos rigorosos (ou seja, desfalque), ou se o novo proprietário dessas moedas cometer um erro e envia essas moedas para um endereço comum com moedas que ele possui, o gabarito do anonimato está em alta no bitcoin.
a chave privada do usuário é um par (a, b) de duas ec-chaves privadas diferentes; chave de rastreamento é um par (a, B) de chave ec privada e pública (onde B = bG e a ̸= b); a chave pública do usuário é um par (A, B) de duas chaves públicas ec derivadas de (a, b); endereço padrão é uma representação de uma chave pública de usuário fornecida em uma string amigável com correção de erros; endereço truncado é uma representação da segunda metade (ponto B) de uma chave pública de usuário fornecida em uma string amigável com correção de erros. A estrutura da transação permanece semelhante à estrutura em Bitcoin: cada usuário pode escolher vários pagamentos recebidos independentes (saídas de transações), assine-os com o correspondente chaves privadas e enviá-las para diferentes destinos. Ao contrário do modelo de Bitcoin, onde um usuário possui uma chave privada e pública única, no modelo proposto, um remetente gera uma chave pública única com base no endereço do destinatário e alguns dados aleatórios. Neste sentido, uma transação de entrada para o mesmo destinatário é enviada para um chave pública única (não diretamente para um endereço exclusivo) e somente o destinatário pode recuperar a parte privada correspondente para resgatar seus fundos (usando sua chave privada exclusiva). O destinatário pode gastar os fundos usando uma assinatura, mantendo anônima sua propriedade e gastos reais. Os detalhes do protocolo são explicados nas próximas subseções. 4.3 Pagamentos não vinculáveis Os endereços Bitcoin clássicos, uma vez publicados, tornam-se identificadores inequívocos para entrada pagamentos, vinculando-os e vinculando-os aos pseudônimos do destinatário. Se alguém quiser receber uma transação “desamarrada”, ele deverá transmitir seu endereço ao remetente por um canal privado. Se ele quiser receber transações diferentes que não podem ser comprovadas como pertencentes ao mesmo proprietário ele deveria gerar todos os endereços diferentes e nunca publicá-los com seu próprio pseudônimo. Público Privado Alice Carol Endereço 1 de Bob Endereço 2 de Bob Chave 1 de Bob Chave 2 de Bob Bob Figura 2. Modelo tradicional de chaves/transações Bitcoin. Propomos uma solução que permite ao usuário publicar um único endereço e receber informações incondicionais pagamentos invinculáveis. O destino de cada saída do CryptoNote (por padrão) é uma chave pública, derivado do endereço do destinatário e dos dados aleatórios do remetente. A principal vantagem contra Bitcoin é que cada chave de destino é única por padrão (a menos que o remetente use os mesmos dados para cada de suas transações para o mesmo destinatário). Portanto, não existe tal questão como “reutilização de endereço” por design e nenhum observador pode determinar se alguma transação foi enviada para um endereço ou link específico dois endereços juntos. 6 a chave privada do usuário é um par (a, b) de duas ec-chaves privadas diferentes; chave de rastreamento é um par (a, B) de chave ec privada e pública (onde B = bG e a ̸= b); a chave pública do usuário é um par (A, B) de duas chaves públicas ec derivadas de (a, b); endereço padrão é uma representação de uma chave pública de usuário fornecida em uma string amigável com correção de erros; endereço truncado é uma representação da segunda metade (ponto B) de uma chave pública de usuário fornecida em uma string amigável com correção de erros. A estrutura da transação permanece semelhante à estrutura em Bitcoin: cada usuário pode escolher vários pagamentos recebidos independentes (saídas de transações), assine-os com o correspondente chaves privadas e enviá-las para diferentes destinos. Ao contrário do modelo de Bitcoin, onde um usuário possui uma chave privada e pública única, no modelo proposto, um remetente gera uma chave pública única com base no endereço do destinatário e alguns dados aleatórios. Neste sentido, uma transação de entrada para o mesmo destinatário é enviada para um chave pública única (não diretamente para um endereço exclusivo) e somente o destinatário pode recuperar a parte privada correspondente para resgatar seus fundos (usando sua chave privada exclusiva). O destinatário pode gastar os fundos usando uma assinatura, mantendo anônima sua propriedade e gastos reais. Os detalhes do protocolo são explicados nas próximas subseções. 4.3 Pagamentos não vinculáveis Os endereços Bitcoin clássicos, uma vez publicados, tornam-se identificadores inequívocos para entrada pagamentos, vinculando-os e vinculando-os aos pseudônimos do destinatário. Se alguém quiser receber uma transação “desamarrada”, ele deverá transmitir seu endereço ao remetente por um canal privado. Se ele quiser receber transações diferentes que não podem ser comprovadas como pertencentes ao mesmo proprietário ele deveria gerar todos os endereços diferentes e nunca publicá-los com seu próprio pseudônimo. Público Privado Alice Carol Endereço 1 de Bob Endereço 2 de Bob Chave 1 de Bob Chave 2 de Bob Bob Figura 2. Mod tradicional de chaves/transações Bitcoinel. Propomos uma solução que permite ao usuário publicar um único endereço e receber informações incondicionais pagamentos invinculáveis. O destino de cada saída do CryptoNote (por padrão) é uma chave pública, derivado do endereço do destinatário e dos dados aleatórios do remetente. A principal vantagem contra Bitcoin é que cada chave de destino é única por padrão (a menos que o remetente use os mesmos dados para cada de suas transações para o mesmo destinatário). Portanto, não existe tal questão como “reutilização de endereço” por design e nenhum observador pode determinar se alguma transação foi enviada para um endereço ou link específico dois endereços juntos. 6 12 Portanto, em vez de os usuários enviarem moedas de um endereço (que na verdade é uma chave pública) para um endereço (outra chave pública) usando suas chaves privadas, os usuários estão enviando moedas de uma caixa postal única (que é gerado usando a chave pública de seus amigos) para uma caixa postal única (da mesma forma) usando seu próprias chaves privadas. De certa forma, estamos dizendo: "Ok, todos tirem as mãos do dinheiro enquanto ele está sendo transferido! Basta saber que nossas chaves podem abrir aquela caixa e aquela sabemos quanto dinheiro está na caixa. Nunca coloque suas impressões digitais na caixa postal ou realmente usá-lo, basta trocar a própria caixa cheia de dinheiro. Assim não sabemos quem enviou o quê, mas o conteúdo desses endereços públicos ainda é sem atrito, fungível, divisível e ainda possuímos todas as outras boas qualidades do dinheiro que desejamos, como o bitcoin." Um conjunto infinito de caixas postais. Você publica um endereço, eu tenho uma chave privada. Eu uso minha chave privada e seu endereço, e alguns dados aleatórios, para gerar uma chave pública. O algoritmo é projetado de tal forma que, desde o seu endereço foi usado para gerar a chave pública, apenas SUA chave privada funciona para desbloquear o mensagem. Uma observadora, Eva, vê você publicar seu endereço e vê a chave pública que anuncio. No entanto, ela não sabe se anunciei minha chave pública com base no seu endereço ou no dela, ou no de Brenda ou de Charlene, ou de quem quer que seja. Ela verifica sua chave privada com a chave pública que anunciei e vê que não funciona; não é o dinheiro dela. Ela não conhece a chave privada de mais ninguém e apenas o destinatário da mensagem possui a chave privada que pode desbloquear a mensagem. Então ninguém ouvir pode determinar quem recebeu o dinheiro e muito menos quem o recebeu.
Público Privado Alice Carol Chave única Chave única Chave única Bob Chave de Bob Endereço de Bob Figura 3. Modelo de chaves/transações do CryptoNote. Primeiro, o remetente realiza uma troca Diffie-Hellman para obter um segredo compartilhado de seus dados e metade do endereço do destinatário. Em seguida, ele calcula uma chave de destino única, usando o método compartilhado segredo e a segunda metade do endereço. Duas ec-keys diferentes são exigidas do destinatário para essas duas etapas, então um endereço CryptoNote padrão é quase duas vezes maior que uma carteira Bitcoin endereço. O receptor também realiza uma troca Diffie-Hellman para recuperar o correspondente chave secreta. Uma sequência de transação padrão é a seguinte: 1. Alice deseja enviar um pagamento para Bob, que publicou seu endereço padrão. Ela descompacta o endereço e obtém a chave pública de Bob (A, B). 2. Alice gera um \(r \in [1, l - 1]\) aleatório e calcula uma chave pública única \(P = H_s(rA)G +\) B. 3. Alice usa P como chave de destino para a saída e também empacota o valor R = rG (como parte da bolsa Diffie-Hellman) em algum ponto da transação. Observe que ela pode criar outras saídas com chaves públicas únicas: chaves de destinatários diferentes (Ai, Bi) implicam Pi diferentes mesmo com o mesmo r. Transação Chave pública Tx Saída de transmissão Quantidade Chave de destino R = rG P = Hs(rA)G + B Do receptor chave pública Dados aleatórios do remetente R (A, B) Figura 4. Estrutura de transação padrão. 4. Alice envia a transação. 5. Bob verifica cada transação que passa com sua chave privada (a, b) e calcula P ′ = Hs(aR)G + B. Se a transação de Alice com Bob como destinatário estivesse entre eles, então aR = arG = rA e P ′ = P. 7 Público Privado Alice Carol Chave única Chave única Chave única Bob Chave de Bob Endereço de Bob Figura 3. Modelo de chaves/transações do CryptoNote. Primeiro, o remetente realiza uma troca Diffie-Hellman para obter um segredo compartilhado de seus dados e metade do endereço do destinatário. Em seguida, ele calcula uma chave de destino única, usando o método compartilhado segredo e a segunda metade do endereço. Duas ec-keys diferentes são exigidas do destinatário para essas duas etapas, então um endereço CryptoNote padrão é quase duas vezes maior que uma carteira Bitcoin endereço. O receptor também realiza uma troca Diffie-Hellman para recuperar o correspondente chave secreta. Uma sequência de transação padrão é a seguinte: 1. Alice deseja enviar um pagamento para Bob, que publicou seu endereço padrão. Ela descompacta o endereço e obtém a chave pública de Bob (A, B). 2. Alice gera um \(r \in [1, l - 1]\) aleatório e calcula uma chave pública única \(P = H_s(rA)G +\) B. 3. Alice usa P como chave de destino para a saída e também empacota o valor R = rG (como parte da bolsa Diffie-Hellman) em algum ponto da transação. Observe que ela pode criar outras saídas com chaves públicas únicas: chaves de destinatários diferentes (Ai, Bi) implicam Pi diferentes mesmo com o mesmo r. Transação Chave pública Tx Saída de transmissão Quantidade Chave de destino R = rG P = Hs(rA)G + B Do receptor chave pública Dados aleatórios do remetente R (A, B) Figura 4. Estrutura de transação padrão. 4. Alice envia a transação. 5. Bob verifica cada transação que passa com sua chave privada (a, b) e calcula P ′ = Hs(aR)G + B. Se a transação de Alice com Bob como destinatário estivesse entre eles, então aR = arG = rA e P ′ = P. 7 13 Eu me pergunto o quanto seria doloroso implementar uma escolha de criptografia esquema. Elíptico ou não. Então, se algum esquema for quebrado no futuro, a moeda muda sem preocupação. Provavelmente um grande pé no saco. Ok, isso é exatamente o que acabei de explicar no meu comentário anterior. O tipo Diffie-Hellman as trocas são perfeitas. Digamos que Alex e Brenda tenham, cada um, um número secreto, A e B, e um número eles não se importam em manter segredo, a e b. Eles desejam gerar um segredo compartilhado sem Eva descobrindo isso. Diffie e Hellman encontraram uma maneira de Alex e Brenda compartilharem o números públicos a e b, mas não os números privados A e B, e geram um segredo compartilhado, K. Usando este segredo compartilhado, K, sem que Eva ouça para poder gerar o mesmo K, Alex e Brenda agora podem usar K como uma chave de criptografia secreta e repassar mensagens secretas e adiante. Veja como PODE funcionar, embora deva funcionar com números muito maiores que 100. Usaremos 100 porque trabalhar sobre os inteiros módulo 100 é equivalente a "jogar fora todos mas os dois últimos dígitos de um número." Alex e Brenda escolhem A, a, B e b. Eles mantêm A e B em segredo. Alex diz a Brenda seu valor de módulo 100 (apenas os dois últimos dígitos) e Brenda diz a Alex seu valor de b módulo 100. Agora Eva sabe (a,b) módulo 100. Mas Alex sabe (a,b,A) então ela pode calcular x=abA módulo 100.Alex corta todos, exceto o último dígito, porque estamos trabalhando sob o módulo inteiro 100 novamente. Da mesma forma, Brenda conhece (a,b,B) então ela pode calcular y=abB módulo 100. Alex agora pode publicar x e Brenda pode publicar y. Mas agora Alex pode calcular yA = abBA módulo 100, e Brenda pode calcular xB = abBA módulo 100. Ambos sabem o mesmo número! Mas tudo o que Eva ouviu foi (a,b,abA,abB). Ela não tem uma maneira fácil de calcular abA*B. Agora, esta é a maneira mais fácil e menos segura de pensar sobre a troca Diffe-Hellman. Existem versões mais seguras. Mas a maioria das versões funciona porque a fatoração inteira e a fatoração discreta logaritmos são difíceis e ambos os problemas são facilmente resolvidos por computadores quânticos. Vou verificar se existe alguma versão resistente ao quantum. http://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange A "sequência txn padrão" listada aqui está faltando várias etapas, como ASSINATURAS. Eles são considerados garantidos aqui. O que é muito ruim, porque a ordem em que assinar coisas, as informações incluídas na mensagem assinada e assim por diante... tudo isso é extremamente importante para o protocolo. Errar um ou dois passos, mesmo que ligeiramente fora de ordem, ao implementar "o sequência de transação padrão" poderia colocar em questão a segurança de todo o sistema. Além disso, as provas apresentadas posteriormente no artigo podem não ser suficientemente rigorosas se o A estrutura sob a qual eles trabalham é definida de forma tão vaga quanto nesta seção.
Público Privado Alice Carol Chave única Chave única Chave única Bob Chave de Bob Endereço de Bob Figura 3. Modelo de chaves/transações do CryptoNote. Primeiro, o remetente realiza uma troca Diffie-Hellman para obter um segredo compartilhado de seus dados e metade do endereço do destinatário. Em seguida, ele calcula uma chave de destino única, usando o método compartilhado segredo e a segunda metade do endereço. Duas ec-keys diferentes são exigidas do destinatário para essas duas etapas, então um endereço CryptoNote padrão é quase duas vezes maior que uma carteira Bitcoin endereço. O receptor também realiza uma troca Diffie-Hellman para recuperar o correspondente chave secreta. Uma sequência de transação padrão é a seguinte: 1. Alice deseja enviar um pagamento para Bob, que publicou seu endereço padrão. Ela descompacta o endereço e obtém a chave pública de Bob (A, B). 2. Alice gera um \(r \in [1, l - 1]\) aleatório e calcula uma chave pública única \(P = H_s(rA)G +\) B. 3. Alice usa P como chave de destino para a saída e também empacota o valor R = rG (como parte da bolsa Diffie-Hellman) em algum ponto da transação. Observe que ela pode criar outras saídas com chaves públicas únicas: chaves de destinatários diferentes (Ai, Bi) implicam Pi diferentes mesmo com o mesmo r. Transação Chave pública Tx Saída de transmissão Quantidade Chave de destino R = rG P = Hs(rA)G + B Do receptor chave pública Dados aleatórios do remetente R (A, B) Figura 4. Estrutura de transação padrão. 4. Alice envia a transação. 5. Bob verifica cada transação que passa com sua chave privada (a, b) e calcula P ′ = Hs(aR)G + B. Se a transação de Alice com Bob como destinatário estivesse entre eles, então aR = arG = rA e P ′ = P. 7 Público Privado Alice Carol Chave única Chave única Chave única Bob Chave de Bob Endereço de Bob Figura 3. Modelo de chaves/transações do CryptoNote. Primeiro, o remetente realiza uma troca Diffie-Hellman para obter um segredo compartilhado de seus dados e metade do endereço do destinatário. Em seguida, ele calcula uma chave de destino única, usando o método compartilhado segredo e a segunda metade do endereço. Duas ec-keys diferentes são exigidas do destinatário para essas duas etapas, então um endereço CryptoNote padrão é quase duas vezes maior que uma carteira Bitcoin endereço. O receptor também realiza uma troca Diffie-Hellman para recuperar o correspondente chave secreta. Uma sequência de transação padrão é a seguinte: 1. Alice deseja enviar um pagamento para Bob, que publicou seu endereço padrão. Ela descompacta o endereço e obtém a chave pública de Bob (A, B). 2. Alice gera um \(r \in [1, l - 1]\) aleatório e calcula uma chave pública única \(P = H_s(rA)G +\) B. 3. Alice usa P como chave de destino para a saída e também empacota o valor R = rG (como parte da bolsa Diffie-Hellman) em algum ponto da transação. Observe que ela pode criar outras saídas com chaves públicas únicas: chaves de destinatários diferentes (Ai, Bi) implicam Pi diferentes mesmo com o mesmo r. Transação Chave pública Tx Saída de transmissão Quantidade Chave de destino R = rG P = Hs(rA)G + B Do receptor chave pública Dados aleatórios do remetente R (A, B) Figura 4. Estrutura de transação padrão. 4. Alice envia a transação. 5. Bob verifica cada transação que passa com sua chave privada (a, b) e calcula P ′ = Hs(aR)G + B. Se a transação de Alice com Bob como destinatário estivesse entre eles, então aR = arG = rA e P ′ = P. 7 14 Observe que o(s) autor(es?) fazem um péssimo trabalho em manter sua terminologia correta ao longo do texto. o texto, mas especialmente nesta próxima parte. A próxima encarnação deste artigo será necessariamente muito mais rigoroso. No texto eles se referem a P como sua chave pública única. No diagrama, eles se referem a R como sua "chave pública Tx" e P como sua "chave de destino". Se eu fosse reescrever isso, eu muito especificamente, apresente alguma terminologia antes de discutir essas seções. Este ell é enorme. Consulte a página 5. Quem escolhe ell? O diagrama ilustra que a chave pública da transação R = rG, que é aleatória e escolhida pelo remetente, não faz parte da saída Tx. Isso ocorre porque pode ser o mesmo para vários transações para várias pessoas e não é usado DEPOIS para gastar. Um novo R é gerado toda vez que você quiser transmitir uma nova transação do CryptoNote. Além disso, R é usado apenas para verificar se você é o destinatário da transação. Não são dados inúteis, mas são lixo para qualquer pessoa sem as chaves privadas associadas a (A,B). A chave Destino, por outro lado, P = Hs(rA)G + B faz parte da saída Tx. Todos vasculhar os dados de cada transação passante deve verificar seu próprio P* gerado este P para ver se eles possuem esta transação de passagem. Qualquer pessoa com uma saída de transação não gasta (UTXO) terá um monte desses Ps com quantias. Para gastard, eles assinar alguma nova mensagem incluindo P. Alice deve assinar esta transação com chaves privadas únicas associadas à(s) saída(s) de transação não gasta(s) Chave(s) de destino. Cada chave de destino de propriedade de Alice vem equipada com uma chave privada única também de propriedade (presumivelmente) de Alice. Toda vez que Alice quer enviar o conteúdo de uma chave de destino para mim, ou Bob, ou Brenda, ou Charlie ou Charlene, ela usa sua chave privada para assinar a transação. Após o recebimento da transação, receberei um novo Chave pública Tx, uma nova chave pública de destino e poderei recuperar uma nova chave privada única x. Combinando minha chave privada única, x, com o destino público da nova transação chave(s) é como enviamos uma nova transação
- Bob pode recuperar a chave privada única correspondente: x = Hs(aR) + b, então P = xG. Ele pode gastar essa saída a qualquer momento assinando uma transação com x. Transação Chave pública Tx Saída de transmissão Quantidade Chave de destino P′ = Hs(aR)G + bG chave pública única x = Hs(aR) + b chave privada única Do receptor chave privada (a, b) R P' ?= P Figura 5. Verificação de transação recebida. Como resultado, Bob recebe pagamentos, associados a chaves públicas únicas que são invinculável para um espectador. Algumas notas adicionais: • Quando Bob “reconhece” suas transações (ver passo 5), ele praticamente usa apenas metade de suas informações privadas: (a, B). Este par, também conhecido como chave de rastreamento, pode ser passado a um terceiro (Carol). Bob pode delegar a ela o processamento de novas transações. Bob não precisa confiar explicitamente em Carol, porque ela não pode recuperar a chave secreta única p sem a chave privada completa de Bob (a, b). Esta abordagem é útil quando Bob não tem largura de banda ou poder de computação (smartphones, carteiras de hardware, etc.). • Caso Alice queira provar que enviou uma transação para o endereço de Bob, ela poderá divulgar r ou usar qualquer tipo de protocolo de conhecimento zero para provar que ela conhece r (por exemplo, assinando a transação com r). • Se Bob quiser ter um endereço compatível com auditoria onde todas as transações recebidas sejam vinculável, ele poderá publicar sua chave de rastreamento ou usar um endereço truncado. Esse endereço representam apenas uma chave ec pública B, e a parte restante exigida pelo protocolo é derivado dele da seguinte forma: a = Hs(B) e A = Hs(B)G. Em ambos os casos, cada pessoa é capaz de “reconhecer” todas as transações recebidas de Bob, mas, é claro, ninguém pode gastar o fundos contidos neles sem a chave secreta b. 4.4 Assinaturas de toque únicas Um protocolo baseado em assinaturas de anel únicas permite que os usuários obtenham desvinculação incondicional. Infelizmente, tipos comuns de assinaturas criptográficas permitem rastrear transações até o seu respectivos remetentes e destinatários. Nossa solução para essa deficiência reside no uso de uma assinatura diferente tipo diferente daqueles atualmente usados em sistemas de dinheiro eletrônico. Primeiro forneceremos uma descrição geral do nosso algoritmo sem nenhuma referência explícita a dinheiro eletrônico. Uma assinatura de anel única contém quatro algoritmos: (GEN, SIG, VER, LNK): GEN: pega parâmetros públicos e gera um par ec (P, x) e uma chave pública I. SIG: pega uma mensagem m, um conjunto \(S'\) de chaves públicas {Pi}i̸=s, um par (Ps, xs) e gera uma assinatura \(\sigma\) e um conjunto \(S = \)S'\( \cup \{P_s\}\). 8
-
Bob pode recuperar a chave privada única correspondente: x = Hs(aR) + b, então P = xG. Ele pode gastar essa saída a qualquer momento assinando uma transação com x. Transação Chave pública Tx Saída de transmissão Quantidade Chave de destino P′ = Hs(aR)G + bG chave pública única x = Hs(aR) + b chave privada única Do receptor chave privada (a,b) R P' ?=P Figura 5. Verificação de transação recebida. Como resultado, Bob recebe pagamentos, associados a chaves públicas únicas que são invinculável para um espectador. Algumas notas adicionais: • Quando Bob “reconhece” suas transações (ver passo 5), ele praticamente usa apenas metade de suas informações privadas: (a, B). Este par, também conhecido como chave de rastreamento, pode ser passado a um terceiro (Carol). Bob pode delegar a ela o processamento de novas transações. Bob não precisa confiar explicitamente em Carol, porque ela não pode recuperar a chave secreta única p sem a chave privada completa de Bob (a, b). Esta abordagem é útil quando Bob não tem largura de banda ou poder de computação (smartphones, carteiras de hardware, etc.). • Caso Alice queira provar que enviou uma transação para o endereço de Bob, ela poderá divulgar r ou usar qualquer tipo de protocolo de conhecimento zero para provar que ela conhece r (por exemplo, assinando a transação com r). • Se Bob quiser ter um endereço compatível com auditoria onde todas as transações recebidas sejam vinculável, ele poderá publicar sua chave de rastreamento ou usar um endereço truncado. Esse endereço representam apenas uma chave ec pública B, e a parte restante exigida pelo protocolo é derivado dele da seguinte forma: a = Hs(B) e A = Hs(B)G. Em ambos os casos, cada pessoa é capaz de “reconhecer” todas as transações recebidas de Bob, mas, é claro, ninguém pode gastar o fundos contidos neles sem a chave secreta b. 4.4 Assinaturas de toque únicas Um protocolo baseado em assinaturas de anel únicas permite que os usuários obtenham desvinculação incondicional. Infelizmente, tipos comuns de assinaturas criptográficas permitem rastrear transações até o seu respectivos remetentes e destinatários. Nossa solução para essa deficiência reside no uso de uma assinatura diferente tipo diferente daqueles atualmente usados em sistemas de dinheiro eletrônico. Primeiro forneceremos um geradordescrição geral do nosso algoritmo sem nenhuma referência explícita a dinheiro eletrônico. Uma assinatura de anel única contém quatro algoritmos: (GEN, SIG, VER, LNK): GEN: pega parâmetros públicos e gera um par ec (P, x) e uma chave pública I. SIG: pega uma mensagem m, um conjunto \(S'\) de chaves públicas {Pi}i̸=s, um par (Ps, xs) e gera uma assinatura \(\sigma\) e um conjunto \(S = \)S'\( \cup \{P_s\}\). 8 15 Qual é a aparência de uma saída de transação não gasta aqui? O diagrama sugere que a saída da transação consiste apenas em dois pontos de dados: valor e chave de destino. Mas isso não é suficiente porque quando eu tentar gastar essa “saída” ainda precisarei saber R=rG. Lembre-se, r é escolhido pelo remetente, e R é a) usado para reconhecer as notas criptográficas recebidas como suas próprio eb) usado para gerar a chave privada única usada para "reivindicar" sua criptonota. A parte disso que eu não entendo? Pegando o teórico "tudo bem, temos esses assinaturas e transações, e nós as repassamos "para o mundo da programação "ok, quais informações especificamente constituem um indivíduo UTXO?" A melhor maneira de responder a essa pergunta é se aprofundar no corpo do código completamente não comentado. Muito bem, equipe bytecoin. Lembre-se: linkabilidade significa "a mesma pessoa enviou?" e desvinculabilidade significa "fez o mesmo pessoa recebe?". Portanto, um sistema pode ser vinculável ou não vinculável, desvinculável ou não desvinculável. Irritante, eu sei. Então, quando Nic van Saberhagen diz aqui "...pagamentos recebidos [estão] associados a pagamentos únicos chaves públicas que não podem ser vinculadas ao espectador", vamos ver o que ele quer dizer. Primeiro, considere uma situação em que Alice envia a Bob duas transações separadas do mesmo endereço para o mesmo endereço. No universo Bitcoin, Alice já cometeu o erro de enviar do mesmo endereço e, portanto, a transação falhou em nosso desejo de limitação capacidade de ligação. Além disso, como ela enviou o dinheiro para o mesmo endereço, ela falhou em nosso desejo. para desvinculação. Esta transação de bitcoin era (totalmente) vinculável e não desvinculável. Por outro lado, no universo da criptonota, digamos que Alice envie alguma criptonota para Bob, usando o endereço público de Bob. Ela escolhe como seu conjunto ofuscante de chaves públicas todas as chaves públicas conhecidas. chaves na área metropolitana de Washington DC. Alex gera uma chave pública única usando sua própria informações e informações públicas de Bob. Ela envia o dinheiro, e qualquer observador irá só ser capaz de colher "Alguém da área metropolitana de Washington DC enviou 2,3 notas criptográficas para o endereço público único XYZ123." Temos um controle probabilístico sobre a vinculação aqui, então chamaremos isso de "quase não vinculável". Também vemos apenas as chaves públicas para as quais o dinheiro é enviado uma única vez. Mesmo se suspeitássemos do receptor era Bob, não temos suas chaves privadas e, portanto, não podemos testar se uma transação passageira pertence a Bob e muito menos gerar sua chave privada única para resgatar sua criptonota. Então isso é, na verdade, totalmente "invincável". Então, este é o truque mais legal de todos. Quem quer realmente confiar em outro MtGox? Nós podemos estar confortável armazenando alguma quantidade de BTC na Coinbase, mas o que há de mais moderno em segurança de bitcoin é uma carteira física. O que é inconveniente. Nesse caso, você pode doar metade de sua chave privada sem comprometer sua segurança. própria capacidade de gastar dinheiro. Ao fazer isso, tudo o que você está fazendo é dizer a alguém como quebrar a desvinculação. O outro propriedades do NC agindo como uma moeda são preservadas, como prova contra gastos duplos e tudo mais.
-
Bob pode recuperar a chave privada única correspondente: x = Hs(aR) + b, então P = xG. Ele pode gastar essa saída a qualquer momento assinando uma transação com x. Transação Chave pública Tx Saída de transmissão Quantidade Chave de destino P′ = Hs(aR)G + bG chave pública única x = Hs(aR) + b chave privada única Do receptor chave privada (a, b) R P' ?= P Figura 5. Verificação de transação recebida. Como resultado, Bob recebe pagamentos, associados a chaves públicas únicas que são invinculável para um espectador. Algumas notas adicionais: • Quando Bob “reconhece” suas transações (ver passo 5), ele praticamente usa apenas metade de suas informações privadas: (a, B). Este par, também conhecido como chave de rastreamento, pode ser passado a um terceiro (Carol). Bob pode delegar a ela o processamento de novas transações. Bob não precisa confiar explicitamente em Carol, porque ela não pode recuperar a chave secreta única p sem a chave privada completa de Bob (a, b). Esta abordagem é útil quando Bob não tem largura de banda ou poder de computação (smartphones, carteiras de hardware, etc.). • Caso Alice queira provar que enviou uma transação para o endereço de Bob, ela poderá divulgar r ou usar qualquer tipo de protocolo de conhecimento zero para provar que ela conhece r (por exemplo, assinando a transação com r). • Se Bob quiser ter um endereço compatível com auditoria onde todas as transações recebidas sejam vinculável, ele poderá publicar sua chave de rastreamento ou usar um endereço truncado. Esse endereço representam apenas uma chave ec pública B, e a parte restante exigida pelo protocolo é derivado dele da seguinte forma: a = Hs(B) e A = Hs(B)G. Em ambos os casos, cada pessoa é capaz de “reconhecer” todas as transações recebidas de Bob, mas, é claro, ninguém pode gastar o fundos contidos neles sem a chave secreta b. 4.4 Assinaturas de toque únicas Um protocolo baseado em assinaturas de anel únicas permite que os usuários obtenham desvinculação incondicional. Infelizmente, tipos comuns de assinaturas criptográficas permitem rastrear transações até o seu respectivos remetentes e destinatários. Nossa solução para essa deficiência reside no uso de uma assinatura diferente tipo diferente daqueles atualmente usados em sistemas de dinheiro eletrônico. Primeiro forneceremos uma descrição geral do nosso algoritmo sem nenhuma referência explícita a dinheiro eletrônico. Uma assinatura de anel única contém quatro algoritmos: (GEN, SIG, VER, LNK): GEN: pega parâmetros públicos e gera um par ec (P, x) e uma chave pública I. SIG: pega uma mensagem m, um conjunto \(S'\) de chaves públicas {Pi}i̸=s, um par (Ps, xs) e gera uma assinatura \(\sigma\) e um conjunto \(S = \)S'\( \cup \{P_s\}\). 8
- Bob pode recuperar a chave privada única correspondente: x = Hs(aR) + b, então P = xG. Ele pode gastar essa saída a qualquer momento assinando uma transação com x. Transação Chave pública Tx Saída de transmissão Quantidade Chave de destino P′ = Hs(aR)G + bG chave pública única x = Hs(aR) + b chave privada única Do receptor chave privada (a,b) R P' ?=P Figura 5. Verificação de transação recebida. Como resultado, Bob recebe pagamentos, associados a chaves públicas únicas que são invinculável para um espectador. Algumas notas adicionais: • Quando Bob “reconhece” suas transações (ver passo 5), ele praticamente usa apenas metade de suas informações privadas: (a, B). Este par, também conhecido como chave de rastreamento, pode ser passado a um terceiro (Carol). Bob pode delegar a ela o processamento de novas transações. Bob não precisa confiar explicitamente em Carol, porque ela não pode recuperar a chave secreta única p sem a chave privada completa de Bob (a, b). Esta abordagem é útil quando Bob não tem largura de banda ou poder de computação (smartphones, carteiras de hardware, etc.). • Caso Alice queira provar que enviou uma transação para o endereço de Bob, ela poderá divulgar r ou usar qualquer tipo de protocolo de conhecimento zero para provar que ela conhece r (por exemplo, assinando a transação com r). • Se Bob quiser ter um endereço compatível com auditoria onde todas as transações recebidas sejam vinculável, ele poderá publicar sua chave de rastreamento ou usar um endereço truncado. Esse endereço representam apenas uma chave ec pública B, e a parte restante exigida pelo protocolo é derivado dele da seguinte forma: a = Hs(B) e A = Hs(B)G. Em ambos os casos, cada pessoa é capaz de “reconhecer” todas as transações recebidas de Bob, mas, é claro, ninguém pode gastar o fundos contidos neles sem a chave secreta b. 4.4 Assinaturas de toque únicas Um protocolo baseado em assinaturas de anel únicas permite que os usuários obtenham desvinculação incondicional. Infelizmente, tipos comuns de assinaturas criptográficas permitem rastrear transações até o seu respectivos remetentes e destinatários. Nossa solução para essa deficiência reside no uso de uma assinatura diferente tipo diferente daqueles atualmente usados em sistemas de dinheiro eletrônico. Primeiro forneceremos um geradordescrição geral do nosso algoritmo sem nenhuma referência explícita a dinheiro eletrônico. Uma assinatura de anel única contém quatro algoritmos: (GEN, SIG, VER, LNK): GEN: pega parâmetros públicos e gera um par ec (P, x) e uma chave pública I. SIG: pega uma mensagem m, um conjunto \(S'\) de chaves públicas {Pi}i̸=s, um par (Ps, xs) e gera uma assinatura \(\sigma\) e um conjunto \(S = \)S'\( \cup \{P_s\}\). 8 16 Sim, agora temos a) um endereço de pagamento eb) um ID de pagamento. Um crítico poderia perguntar "será que realmente precisamos fazer isso? Afinal, se um comerciante receber 112.00678952 CN exatamente, e esse foi o meu pedido, e eu tenho uma captura de tela ou um recibo ou algo assim, não é? grau insano de precisão é suficiente?" A resposta é "talvez, na maioria das vezes, no dia-a-dia, transações presenciais." Contudo, a situação mais comum (especialmente no mundo digital) é esta: um comerciante vende um conjunto de objetos, cada um com um preço fixo. Digamos que o objeto A seja 0,001 CN, o objeto B seja 0,01 CN e o objeto C é 0,1 CN. Agora, se o comerciante receber um pedido de 1.618 CN, há muitos, muitos (muitas!) maneiras de organizar um pedido para um cliente. E assim, sem algum tipo de identificação de pagamento, identificar o chamado pedido “único” de um cliente com o chamado custo “único” de seu a ordem torna-se impossível. Ainda mais engraçado: se tudo na minha loja online custasse exatamente 1,0 CN, e recebo 1.000 clientes por dia? E você quer provar que comprou exatamente 3 objetos há duas semanas? Sem um ID de pagamento? Boa sorte, amigo. Resumindo: quando Bob publica um endereço de pagamento, ele pode acabar publicando também um ID de pagamento também (veja, por exemplo, depósitos Poloniex XMR). Isto é diferente do que está descrito no texto aqui onde Alice é quem gera o ID de pagamento. Deve haver alguma maneira de Bob gerar um ID de pagamento também. (a, B) Lembre-se de que a chave de rastreamento (a,B) pode ser publicada; perder o sigilo do valor de 'a' será não violar sua capacidade de gastar ou permitir que pessoas roubem de você (eu acho... isso teria a ser comprovado), simplesmente permitirá que as pessoas vejam todas as transações recebidas. Um endereço truncado, conforme descrito neste parágrafo, simplesmente ocupa a parte “privada” da chave e o gera a partir da parte "pública". Revelar o valor de 'a' removerá a não vinculabilidade mas preservará o restante das transações. O autor quer dizer “não desvinculável” porque desvinculável refere-se ao receptor e vinculável refere-se ao remetente. Também está claro que o autor não percebeu que havia dois aspectos diferentes na vinculabilidade. Como, afinal, a transação é um objeto direcionado em um gráfico, haverá duas questões: "essas duas transações vão para a mesma pessoa?" e "essas duas transações estão chegando da mesma pessoa?" Esta é uma política de "não retorno" sob a qual a propriedade de desvinculação do CryptoNote é condicional. Ou seja, Bob pode escolher que suas transações recebidas não sejam desvinculáveis usando esta política. Esta é uma afirmação que eles comprovam no Modelo Random Oracle. Chegaremos a isso; o aleatório A Oracle tem prós e contras.
VER: pega uma mensagem m, um conjunto S, uma assinatura \(\sigma\) e gera “verdadeiro” ou “falso”. LNK: pega um conjunto I = {Ii}, uma assinatura \(\sigma\) e gera “vinculado” ou “indep”. A ideia por trás do protocolo é bastante simples: um usuário produz uma assinatura que pode ser verificado por um conjunto de chaves públicas em vez de uma chave pública única. A identidade do signatário é indistinguível dos outros usuários cujas chaves públicas estão no conjunto até que o proprietário produza uma segunda assinatura usando o mesmo par de chaves. Chaves privadas x0 \(\cdots\) xii \(\cdots\) xn Chaves públicas P0 \(\cdots\) Pi \(\cdots\) Pn Anel Assinatura sinal verificar Figura 6. Anonimato da assinatura do anel. GEN: O signatário escolhe uma chave secreta aleatória \(x \in [1, l - 1]\) e calcula a chave correspondente chave pública P = xG. Além disso, ele calcula outra chave pública I = xHp(P) que iremos chamamos de “imagem chave”. SIG: O signatário gera uma assinatura de anel única com conhecimento zero não interativo prova usando as técnicas de [21]. Ele seleciona um subconjunto aleatório \(S'\) de n dos outros usuários chaves públicas Pi, seu próprio par de chaves (x, P) e imagem chave I. Seja \(0 \leq s \leq n\) o índice secreto do signatário em S (de modo que sua chave pública seja Ps). Ele escolhe um {qi | eu = 0. . . n} e {wi | eu = 0. . . n, i ̸= s} de (1 . . . l) e aplica o seguintes transformações: Li = ( qiG, se eu = s qiG + wiPi, se eu ̸= s Ri = ( qiHp(Pi), se eu = s qiHp(Pi) + wiI, se eu ̸= s A próxima etapa é obter o desafio não interativo: c = Hs(m, L1,..., Ln, R1,..., Rn) Finalmente, o signatário calcula a resposta: ci = eu, se eu ̸= s c- nP eu=0 ci mod eu, se eu = s ri = ( qi, se eu ̸= s qs-csx mod eu, se eu = s A assinatura resultante é \(\sigma\) = (I, c1, . . . , cn, r1, . . . , rn). 9 VER: pega uma mensagem m, um conjunto S, uma assinatura \(\sigma\) e gera “verdadeiro” ou “falso”. LNK: pega um conjunto I = {Ii}, uma assinatura \(\sigma\) e gera “vinculado” ou “indep”. A ideia por trás do protocolo é bastante simples: um usuário produz uma assinatura que pode ser verificado por um conjunto de chaves públicas em vez de uma chave pública única. A identidade do signatário é indistinguível dos outros usuários cujas chaves públicas estão no conjunto até que o proprietário produza uma segunda assinatura usando o mesmo par de chaves. Chaves privadas x0 \(\cdots\) xii \(\cdots\) xn Chaves públicas P0 \(\cdots\) Pi \(\cdots\) Pn Anel Assinatura sinal verificar Figura 6. Anonimato da assinatura do anel. GEN: O signatário escolhe uma chave secreta aleatória \(x \in [1, l - 1]\) e calcula a chave correspondente chave pública P = xG. Além disso, ele calcula outra chave pública I = xHp(P) que iremos chamamos de “imagem chave”. SIG: O signatário gera uma assinatura de anel única com conhecimento zero não interativo prova usando as técnicas de [21]. Ele seleciona um subconjunto aleatório \(S'\) de n dos outros usuários chaves públicas Pi, seu próprio par de chaves (x, P) e imagem chave I. Seja \(0 \leq s \leq n\) o índice secreto do signatário em S (de modo que sua chave pública seja Ps). Ele escolhe um {qi | eu = 0. . . n} e {wi | eu = 0. . . n, i ̸= s} de (1 . . . l) e aplica o seguintes transformações: Li = ( qiG, se eu = s qiG + wiPi, se eu ̸= s Ri = ( qiHp(Pi), se eu = s qiHp(Pi) + wiI, se eu ̸= s A próxima etapa é obter o desafio não interativo: c = Hs(m, L1,..., Ln, R1,..., Rn) Finalmente, o signatário calcula a resposta: ci = eu, se eu ̸= s c- nP eu=0 ci mod eu, se eu = s ri = ( qi, se eu ̸= s qs-csx mod eu, se eu = s A assinatura resultante é \(\sigma\) = (I, c1, . . . , cn, r1, . . . , rn). 9 17 Talvez isso seja estúpido, mas é preciso ter cuidado ao unir S e P_s. Se você apenas anexar o última chave pública até o fim, a desvinculação é quebrada porque qualquer pessoa que verifica as transações passadas pode apenas verificar a última chave pública listada em cada transação e boom. Essa é a chave pública associado ao remetente. Portanto, após a união, um gerador de números pseudoaleatórios deve ser usado para permutar as chaves públicas escolhidas. "...até que o proprietário produza uma segunda assinatura usando o mesmo par de chaves." Desejo que o(s) autor(es?) iria elaborar sobre isso. Acredito que isso significa "certifique-se de que toda vez que você escolher um conjunto de chaves públicas para ofuscar você mesmo, você escolhe um conjunto completamente novo, sem duas teclas iguais." O que parece um condição bastante forte a ser imposta à desvinculação. Talvez "você escolha um novo conjunto aleatório de todas as chaves possíveis" com a suposição de que, embora as interseções não triviais inevitavelmente acontecer, eles não acontecerão com frequência. De qualquer forma, preciso me aprofundar nessa afirmação. Isso está gerando a assinatura do anel. Provas de conhecimento zero são incríveis: eu desafio você a me provar que conhece um segredo sem revelar o segredo. Por exemplo, digamos que estamos na entrada de uma caverna em forma de donut, e na parte de trás da caverna (além da vista da entrada) há um oporta de mão única para a qual você afirme que você tem a chave. Se você for em uma direção, ela sempre deixará você passar, mas se você for na outra direção, você precisa de uma chave. Mas você nem quer me MOSTRAR a chave, muito menos mostre-me que isso abre a porta. Mas você quer me provar que sabe como abrir o porta. No ambiente interativo, jogo uma moeda. Cara é para a esquerda, coroa para a direita e você desce o caverna em forma de donut para qualquer direção que a moeda o direcione. Na parte de trás, além da minha vista, você abra a porta para voltar pelo outro lado. Repetimos o experimento de lançamento de moeda até que eu tenha certeza de que você tem a chave. Mas essa é claramente a prova INTERATIVA de conhecimento zero. Existem versões não interativas nas quais você e eu nunca precisamos nos comunicar; dessa forma, nenhum bisbilhoteiro poderá interferir. http://en.wikipedia.org/wiki/Zero-knowledge_proof Isto é inverso da definição anterior.
VER: pega uma mensagem m, um conjunto S, uma assinatura \(\sigma\) e gera “verdadeiro” ou “falso”. LNK: pega um conjunto I = {Ii}, uma assinatura \(\sigma\) e gera “vinculado” ou “indep”. A ideia por trás do protocolo é bastante simples: um usuário produz uma assinatura que pode ser verificado por um conjunto de chaves públicas em vez de uma chave pública única. A identidade do signatário é indistinguível dos outros usuários cujas chaves públicas estão no conjunto até que o proprietário produza uma segunda assinatura usando o mesmo par de chaves. Chaves privadas x0 \(\cdots\) xii \(\cdots\) xn Chaves públicas P0 \(\cdots\) Pi \(\cdots\) Pn Anel Assinatura sinal verificar Figura 6. Anonimato da assinatura do anel. GEN: O signatário escolhe uma chave secreta aleatória \(x \in [1, l - 1]\) e calcula a chave correspondente chave pública P = xG. Além disso, ele calcula outra chave pública I = xHp(P) que iremos chamamos de “imagem chave”. SIG: O signatário gera uma assinatura de anel única com conhecimento zero não interativo prova usando as técnicas de [21]. Ele seleciona um subconjunto aleatório \(S'\) de n dos outros usuários chaves públicas Pi, seu próprio par de chaves (x, P) e imagem chave I. Seja \(0 \leq s \leq n\) o índice secreto do signatário em S (de modo que sua chave pública seja Ps). Ele escolhe um {qi | eu = 0. . . n} e {wi | eu = 0. . . n, i ̸= s} de (1 . . . l) e aplica o seguintes transformações: Li = ( qiG, se eu = s qiG + wiPi, se eu ̸= s Ri = ( qiHp(Pi), se eu = s qiHp(Pi) + wiI, se eu ̸= s A próxima etapa é obter o desafio não interativo: c = Hs(m, L1,..., Ln, R1,..., Rn) Finalmente, o signatário calcula a resposta: ci = eu, se eu ̸= s c- nP eu=0 ci mod eu, se eu = s ri = ( qi, se eu ̸= s qs-csx mod eu, se eu = s A assinatura resultante é \(\sigma\) = (I, c1, . . . , cn, r1, . . . , rn). 9 VER: pega uma mensagem m, um conjunto S, uma assinatura \(\sigma\) e gera “verdadeiro” ou “falso”. LNK: pega um conjunto I = {Ii}, uma assinatura \(\sigma\) e gera “vinculado” ou “indep”. A ideia por trás do protocolo é bastante simples: um usuário produz uma assinatura que pode ser verificado por um conjunto de chaves públicas em vez de uma chave pública única. A identidade do signatário é indistinguível dos outros usuários cujas chaves públicas estão no conjunto até que o proprietário produza uma segunda assinatura usando o mesmo par de chaves. Chaves privadas x0 \(\cdots\) xii \(\cdots\) xn Chaves públicas P0 \(\cdots\) Pi \(\cdots\) Pn Anel Assinatura sinal verificar Figura 6. Anonimato da assinatura do anel. GEN: O signatário escolhe uma chave secreta aleatória \(x \in [1, l - 1]\) e calcula a chave correspondente chave pública P = xG. Além disso, ele calcula outra chave pública I = xHp(P) que iremos chamamos de “imagem chave”. SIG: O signatário gera uma assinatura de anel única com conhecimento zero não interativo prova usando as técnicas de [21]. Ele seleciona um subconjunto aleatório \(S'\) de n dos outros usuários chaves públicas Pi, seu próprio par de chaves (x, P) e imagem chave I. Seja \(0 \leq s \leq n\) o índice secreto do signatário em S (de modo que sua chave pública seja Ps). Ele escolhe um {qi | eu = 0. . . n} e {wi | eu = 0. . . n, i ̸= s} de (1 . . . l) e aplica o seguintes transformações: Li = ( qiG, se eu = s qiG + wiPi, se eu ̸= s Ri = ( qiHp(Pi), se eu = s qiHp(Pi) + wiI, se eu ̸= s A próxima etapa é obter o desafio não interativo: c = Hs(m, L1,..., Ln, R1,..., Rn) Finalmente, o signatário calcula a resposta: ci = eu, se eu ̸= s c- nP eu=0 ci mod eu, se eu = s ri = ( qi, se eu ̸= s qs-csx mod eu, se eu = s A assinatura resultante é \(\sigma\) = (I, c1, . . . , cn, r1, . . . , rn). 9 18 Toda esta área é agnóstica em relação às criptomoedas, simplesmente descrevendo o algoritmo de assinatura do anel sem referência a moedas. Suspeito que parte da notação seja consistente com o restante do artigo, embora. Por exemplo, x é a chave secreta “aleatória” escolhida em GEN, que fornece a chave pública P e imagem de chave pública I. Este valor de x é o valor que Bob calcula na parte 6, página 8. Portanto, este é começando a esclarecer parte da confusão da descrição anterior. Isso é legal; o dinheiro não está sendo transferido do "endereço público de Alice para o endereço público de Bob endereço." Ele está sendo transferido de endereço único para endereço único. Então, de certa forma, é assim que as coisas funcionam. Se Alex tiver algumas criptomoedas porque alguém os enviou para ela, isso significa que ela possui as chaves privadas necessárias para enviá-los a Bob. Ela usa uma troca Diffie-Hellman usando informações públicas de Bob para gerar um novo endereço único e as criptomoedas são transferidas para esse endereço. Agora, como uma troca DH (presumivelmente segura) foi usada para gerar o novo endereço único para o qual Alex enviou seu CN, Bob é o único com as chaves privadas necessárias para repetir o acima. Então agora, Bob é Alex. http://en.wikipedia.org/wiki/Piecewise#Notation_and_interpretation A soma deve ser indexada em j e não em i. Cada c_i é lixo aleatório (já que w_i é aleatório) exceto a bunda c_iassociada à chave real envolvida nesta assinatura. O valor de c é a hash das informações anteriores. Acho que isso pode conter um erro de digitação pior do que reutilizar o índice 'i', porque c_s parece ser implicitamente, e não explicitamente, definido. Na verdade, se considerarmos esta equação com fé, então determinaremos que c_s = (1/2)c - (1/2) soma_i neq s c_i. Ou seja, hash menos um monte de números aleatórios. Por outro lado, se este somatório se destina a ser lido "c_s = (c - sum_j neq s c_j) mod l", então pegamos o hash de nossas informações anteriores, geramos um monte de números aleatórios, subtraia todos esses números aleatórios de hash e isso nos dá c_s. Isto parece ser o que "deveria" estar acontecendo, dada minha intuição, e corresponde à etapa de verificação na página 10. Mas a intuição não é matemática. Vou me aprofundar nisso. O mesmo que antes; tudo isso será lixo aleatório, exceto aquele associado ao real chave pública do signatário x. Só que desta vez é mais o que eu esperaria da estrutura: r_i é aleatório para i!=s e r_s é determinado apenas pelo segredo x e pelos valores indexados em s de q_i e c_i.
VER: O verificador verifica a assinatura aplicando as transformações inversas: ( eu' i = riG + ciPi R′ i = riHp(Pi) + ciI Finalmente, o verificador verifica se nP eu=0 ci ?= Hs(m, L′ 0, . . . , eu' n, R′ 0, . . . , R′ n) mod l Se esta igualdade estiver correta, o verificador executa o algoritmo LNK. Caso contrário, o verificador rejeita a assinatura. LNK: O verificador verifica se I foi usado em assinaturas anteriores (esses valores são armazenados no conjunto I). Usos múltiplos implicam que duas assinaturas foram produzidas sob a mesma chave secreta. O significado do protocolo: ao aplicar transformações L, o signatário prova que conhece tal x que pelo menos um Pi = xG. Para tornar esta prova não repetível, introduzimos a imagem chave como I = xHp(P). O signatário usa os mesmos coeficientes (ri, ci) para provar quase a mesma afirmação: ele conhece tal x que pelo menos um \(H_p(P_i) = I \cdot x^{-1}\). Se o mapeamento \(x \to I\) for uma injeção: 1. Ninguém pode recuperar a chave pública da imagem chave e identificar o signatário; 2. O signatário não pode fazer duas assinaturas com I’s diferentes e o mesmo x. Uma análise completa de segurança é fornecida no Apêndice A. 4,5 Transação CryptoNote padrão Ao combinar ambos os métodos (chaves públicas não vinculáveis e assinatura de anel não rastreável), Bob consegue novo nível de privacidade em comparação com o esquema Bitcoin original. Requer que ele armazene apenas uma chave privada (a, b) e publicação (A, B) para começar a receber e enviar transações anônimas. Ao validar cada transação, Bob realiza adicionalmente apenas duas multiplicações de curva elíptica e uma adição por saída para verificar se uma transação pertence a ele. Para todos os seus saída Bob recupera um par de chaves único (pi, Pi) e o armazena em sua carteira. Quaisquer entradas podem ser provaram circunstancialmente ter o mesmo proprietário apenas se aparecerem em uma única transação. Em na verdade, esse relacionamento é muito mais difícil de estabelecer devido à assinatura única do anel. Com uma assinatura de anel, Bob pode efetivamente ocultar todas as entradas entre as de outra pessoa; tudo possível gastadores serão equiprováveis, mesmo a proprietária anterior (Alice) não tem mais informações do que qualquer observador. Ao assinar sua transação, Bob especifica n saídas estrangeiras com o mesmo valor que seu saída, misturando todos eles sem a participação de outros usuários. O próprio Bob (assim como qualquer outra pessoa) não sabe se algum desses pagamentos foi gasto: uma saída pode ser usada em milhares de assinaturas como fator de ambiguidade e nunca como alvo de ocultação. O duplo a verificação de gastos ocorre na fase LNK ao verificar o conjunto de imagens-chave usadas. Bob pode escolher o grau de ambigüidade sozinho: n = 1 significa que a probabilidade que ele tem gasto, a saída tem 50% de probabilidade, n = 99 dá 1%. O tamanho da assinatura resultante aumenta linearmente como O (n + 1), portanto, o anonimato aprimorado custa para Bob taxas de transação extras. Ele também pode defina n = 0 e faça com que sua assinatura de anel consista em apenas um elemento, no entanto, isso irá instantaneamente revelá-lo como um gastador. 10 VER: O verificador verifica a assinatura aplicando as transformações inversas: ( eu' i = riG + ciPi R′ i = riHp(Pi) + ciI Finalmente, o verificador verifica se nP eu=0 ci ?= Hs(m, L′ 0, . . . , eu' n, R' 0, . . . , R' n) mod l Se esta igualdade estiver correta, o verificador executa o algoritmo LNK. Caso contrário, o verificador rejeita a assinatura. LNK: O verificador verifica se I foi usado em assinaturas anteriores (esses valores são armazenados no conjunto I). Usos múltiplos implicam que duas assinaturas foram produzidas sob a mesma chave secreta. O significado do protocolo: ao aplicar transformações L, o signatário prova que conhece tal x que pelo menos um Pi = xG. Para tornar esta prova não repetível, introduzimos a imagem chave como I = xHp(P). O signatário usa os mesmos coeficientes (ri, ci) para provar quase a mesma afirmação: ele conhece tal x que pelo menos um \(H_p(P_i) = I \cdot x^{-1}\). Se o mapeamento \(x \to I\) for uma injeção: 1. Ninguém pode recuperar a chave pública da imagem chave e identificar o signatário; 2. O signatário não pode fazer duas assinaturas com I’s diferentes e o mesmo x. Uma análise completa de segurança é fornecida no Apêndice A. 4,5 Transação CryptoNote padrão Ao combinar ambos os métodos (chaves públicas não vinculáveis e assinatura de anel não rastreável), Bob consegue novo nível de privacidade em comparação com o esquema Bitcoin original. Requer que ele armazene apenas uma chave privada (a, b) e publicação (A, B) para começar a receber e enviar transações anônimas. Ao validar cada transação, Bob realiza adicionalmente apenas duas multiplicações de curva elíptica e uma adição por saída para verificar se uma transação pertence a ele. Para todos os seus saída Bob recupera um par de chaves único (pi, Pi) e sto guarda em sua carteira. Quaisquer entradas podem ser provaram circunstancialmente ter o mesmo proprietário apenas se aparecerem em uma única transação. Em na verdade, esse relacionamento é muito mais difícil de estabelecer devido à assinatura única do anel. Com uma assinatura de anel, Bob pode efetivamente ocultar todas as entradas entre as de outra pessoa; tudo possível gastadores serão equiprováveis, mesmo a proprietária anterior (Alice) não tem mais informações do que qualquer observador. Ao assinar sua transação, Bob especifica n saídas estrangeiras com o mesmo valor que seu saída, misturando todos eles sem a participação de outros usuários. O próprio Bob (assim como qualquer outra pessoa) não sabe se algum desses pagamentos foi gasto: uma saída pode ser usada em milhares de assinaturas como fator de ambiguidade e nunca como alvo de ocultação. O duplo a verificação de gastos ocorre na fase LNK ao verificar o conjunto de imagens-chave usadas. Bob pode escolher o grau de ambigüidade sozinho: n = 1 significa que a probabilidade que ele tem gasto, a saída tem 50% de probabilidade, n = 99 dá 1%. O tamanho da assinatura resultante aumenta linearmente como O (n + 1), portanto, o anonimato aprimorado custa para Bob taxas de transação extras. Ele também pode defina n = 0 e faça com que sua assinatura de anel consista em apenas um elemento, no entanto, isso irá instantaneamente revelá-lo como um gastador. 10 19 Neste ponto, estou terrivelmente confuso. Alex recebe uma mensagem M com assinatura (I,c_1, ..., c_n, r_1, ..., r_n) e lista de públicos teclas S. e ela executa VER. Isso irá calcular L_i’ e R_i’ Isso verifica que c_s = c - sum_i neq s c_i na página anterior. No começo eu estava MUITO (ha) confuso. Qualquer um pode calcular L_i’ e R_i’. Na verdade, cada r_i e c_i foram publicados na assinatura sigma junto com o valor de I. O conjunto S = P_i de todas as chaves públicas também foi publicado. Então, qualquer um que tenha visto o sigma e o conjunto de as chaves S = P_i obterão os mesmos valores para L_i’ e R_i’ e, portanto, verificarão a assinatura. Mas então me lembrei que esta seção descreve simplesmente um algoritmo de assinatura, não uma "verificação se assinado, verifique se ENVIADO PARA MIM e, em caso afirmativo, vá gastar o dinheiro." Este é SIMPLESMENTE o parte de assinatura do jogo. Estou interessado em ler o Apêndice A quando finalmente chegar lá. Eu gostaria de ver uma comparação completa operação por operação do Cryptonote com Bitcoin. Além disso, eletricidade/sustentabilidade. Quais partes dos algoritmos constituem a “entrada” aqui? A entrada da transação, acredito, é um Valor e um conjunto de UTXOs que somam um valor maior que o Quantidade. Isto não está claro. “Alvo de esconderijo?” Pensei nisso por alguns minutos e ainda não consegui idéia mais nebulosa do que isso poderia significar. Um ataque de gasto duplo pode ser executado apenas manipulando a chave usada percebida de um nó conjunto de imagens \(I\). "Grau de ambiguidade" = n mas o número total de chaves públicas incluídas na transação é n+1. Ou seja, o grau de ambiguidade seria “quantas OUTRAS pessoas você quer em a multidão?" A resposta provavelmente será, por padrão, “tantas quanto possível”.
VER: O verificador verifica a assinatura aplicando as transformações inversas: ( eu' i = riG + ciPi R′ i = riHp(Pi) + ciI Finalmente, o verificador verifica se nP eu=0 ci ?= Hs(m, L′ 0, . . . , eu' n, R' 0, . . . , R' n) mod l Se esta igualdade estiver correta, o verificador executa o algoritmo LNK. Caso contrário, o verificador rejeita a assinatura. LNK: O verificador verifica se I foi usado em assinaturas anteriores (esses valores são armazenados no conjunto I). Usos múltiplos implicam que duas assinaturas foram produzidas sob a mesma chave secreta. O significado do protocolo: ao aplicar transformações L, o signatário prova que conhece tal x que pelo menos um Pi = xG. Para tornar esta prova não repetível, introduzimos a imagem chave como I = xHp(P). O signatário usa os mesmos coeficientes (ri, ci) para provar quase a mesma afirmação: ele conhece tal x que pelo menos um \(H_p(P_i) = I \cdot x^{-1}\). Se o mapeamento \(x \to I\) for uma injeção: 1. Ninguém pode recuperar a chave pública da imagem chave e identificar o signatário; 2. O signatário não pode fazer duas assinaturas com I’s diferentes e o mesmo x. Uma análise completa de segurança é fornecida no Apêndice A. 4,5 Transação CryptoNote padrão Ao combinar ambos os métodos (chaves públicas não vinculáveis e assinatura de anel não rastreável), Bob consegue novo nível de privacidade em comparação com o esquema Bitcoin original. Requer que ele armazene apenas uma chave privada (a, b) e publicação (A, B) para começar a receber e enviar transações anônimas. Ao validar cada transação, Bob realiza adicionalmente apenas duas multiplicações de curva elíptica e uma adição por saída para verificar se uma transação pertence a ele. Para todos os seus saída Bob recupera um par de chaves único (pi, Pi) e o armazena em sua carteira. Quaisquer entradas podem ser provaram circunstancialmente ter o mesmo proprietário apenas se aparecerem em uma única transação. Em na verdade, esse relacionamento é muito mais difícil de estabelecer devido à assinatura única do anel. Com uma assinatura de anel, Bob pode efetivamente ocultar todas as entradas entre as de outra pessoa; tudo possível gastadores serão equiprováveis, mesmo a proprietária anterior (Alice) não tem mais informações do que qualquer observador. Ao assinar sua transação, Bob especifica n saídas estrangeiras com o mesmo valor que seu saída, misturando todos eles sem a participação de outros usuários. O próprio Bob (assim como qualquer outra pessoa) não sabe se algum desses pagamentos foi gasto: uma saída pode ser usada em milhares de assinaturas como fator de ambiguidade e nunca como alvo de ocultação. O duplo a verificação de gastos ocorre na fase LNK ao verificar o conjunto de imagens-chave usadas. Bob pode escolher o grau de ambigüidade sozinho: n = 1 significa que a probabilidade que ele tem gasto, a saída tem 50% de probabilidade, n = 99 dá 1%. O tamanho da assinatura resultante aumenta linearmente como O (n + 1), portanto, o anonimato aprimorado custa para Bob taxas de transação extras. Ele também pode defina n = 0 e faça com que sua assinatura de anel consista em apenas um elemento, no entanto, isso irá instantaneamente revelá-lo como um gastador. 10 VER: O verificador verifica a assinatura aplicando as transformações inversas: ( eu' i = riG + ciPi R′ i = riHp(Pi) + ciI Finalmente, o verificador verifica se nP eu=0 ci ?= Hs(m, L′ 0, . . . , eu' n, R' 0, . . . , R' n) mod l Se esta igualdade estiver correta, o verificador executa o algoritmo LNK. Caso contrário, o verificador rejeita a assinatura. LNK: O verificador verifica se I foi usado em assinaturas anteriores (esses valores são armazenados no conjunto I). Usos múltiplos implicam que duas assinaturas foram produzidas sob a mesma chave secreta. O significado do protocolo: ao aplicar transformações L, o signatário prova que conhece tal x que pelo menos um Pi = xG. Para tornar esta prova não repetível, introduzimos a imagem chave como I = xHp(P). O signatário usa os mesmos coeficientes (ri, ci) para provar quase a mesma afirmação: ele conhece tal x que pelo menos um \(H_p(P_i) = I \cdot x^{-1}\). Se o mapeamento \(x \to I\) for uma injeção: 1. Ninguém pode recuperar a chave pública da imagem chave e identificar o signatário; 2. O signatário não pode fazer duas assinaturas com I’s diferentes e o mesmo x. Uma análise completa de segurança é fornecida no Apêndice A. 4,5 Transação CryptoNote padrão Ao combinar ambos os métodos (chaves públicas não vinculáveis e assinatura de anel não rastreável), Bob consegue novo nível de privacidade em comparação com o esquema Bitcoin original. Requer que ele armazene apenas uma chave privada (a, b) e publicação (A, B) para começar a receber e enviar transações anônimas. Ao validar cada transação, Bob realiza adicionalmente apenas duas multiplicações de curva elíptica e uma adição por saída para verificar se uma transação pertence a ele. Para todos os seus saída Bob recupera um par de chaves único (pi, Pi) e sto guarda em sua carteira. Quaisquer entradas podem ser provaram circunstancialmente ter o mesmo proprietário apenas se aparecerem em uma única transação. Em na verdade, esse relacionamento é muito mais difícil de estabelecer devido à assinatura única do anel. Com uma assinatura de anel, Bob pode efetivamente ocultar todas as entradas entre as de outra pessoa; tudo possível gastadores serão equiprováveis, mesmo a proprietária anterior (Alice) não tem mais informações do que qualquer observador. Ao assinar sua transação, Bob especifica n saídas estrangeiras com o mesmo valor que seu saída, misturando todos eles sem a participação de outros usuários. O próprio Bob (assim como qualquer outra pessoa) não sabe se algum desses pagamentos foi gasto: uma saída pode ser usada em milhares de assinaturas como fator de ambiguidade e nunca como alvo de ocultação. O duplo a verificação de gastos ocorre na fase LNK ao verificar o conjunto de imagens-chave usadas. Bob pode escolher o grau de ambigüidade sozinho: n = 1 significa que a probabilidade que ele tem gasto, a saída tem 50% de probabilidade, n = 99 dá 1%. O tamanho da assinatura resultante aumenta linearmente como O (n + 1), portanto, o anonimato aprimorado custa para Bob taxas de transação extras. Ele também pode defina n = 0 e faça com que sua assinatura de anel consista em apenas um elemento, no entanto, isso irá instantaneamente revelá-lo como um gastador. 10 20 Isso é interessante; anteriormente, fornecemos uma maneira para um receptor, Bob, fazer todas as entradas transações não desvinculáveis, seja escolhendo metade de suas chaves privadas de forma determinística ou publicando metade de suas chaves privadas como públicas. Este é um tipo de política sem retorno. Aqui, vemos uma maneira de um remetente, Alex, escolher uma única transação de saída como vinculável, mas na verdade isso revela Alex como o remetente de toda a rede. Este NÃO é um tipo de política sem retorno. Isso é transação por transação. Existe uma terceira política? Um destinatário, Bob, pode gerar um ID de pagamento exclusivo para Alex que nunca muda, talvez usando uma troca Diffe-Hellman? Se alguém incluir esse pagamento ID empacotado em algum lugar de sua transação para o endereço de Bob, deve ter vindo de Alex. Dessa forma, Alex não precisa se revelar para toda a rede ao optar por vincular um determinado transação, mas ela ainda pode se identificar perante a pessoa para quem envia seu dinheiro. Não é isso que a Poloniex faz?
Transação Entrada de transmissão Saída0 . . . Saída . . . Saída Imagem principal Assinaturas Assinatura do anel Chave de destino Saída1 Chave de destino Saída Transações estrangeiras Saída do remetente Chave de destino Par de chaves único Único chave privada Eu = xHp(P) P,x Figura 7. Geração de assinatura de anel em uma transação padrão. 5 Prova de trabalho igualitária Nesta seção propomos e fundamentamos o novo algoritmo proof-of-work. Nosso objetivo principal é fechar a lacuna entre os mineradores de CPU (maioria) e GPU/FPGA/ASIC (minoria). É apropriado que alguns usuários possam ter uma certa vantagem sobre outros, mas seus investimentos deve crescer pelo menos linearmente com a potência. De forma mais geral, a produção de dispositivos para fins especiais tem que ser o menos lucrativo possível. 5.1 Trabalhos relacionados O protocolo Bitcoin proof-of-work original usa a função de precificação com uso intensivo de CPU SHA-256. Consiste principalmente em operadores lógicos básicos e depende exclusivamente da velocidade computacional de processador, portanto, é perfeitamente adequado para implementação multicore/conveyer. No entanto, os computadores modernos não estão limitados apenas pelo número de operações por segundo, mas também pelo tamanho da memória. Embora alguns processadores possam ser substancialmente mais rápidos que outros [8], os tamanhos de memória são menos propensos a variar entre as máquinas. As funções de preço ligadas à memória foram introduzidas pela primeira vez por Abadi et al e foram definidas como “funções cujo tempo de computação é dominado pelo tempo gasto no acesso à memória” [15]. A ideia principal é construir um algoritmo alocando um grande bloco de dados (“scratchpad”) dentro da memória que pode ser acessada de forma relativamente lenta (por exemplo, RAM) e “acessando um sequência imprevisível de locais” dentro dele. Um bloco deve ser grande o suficiente para fazer a preservação os dados mais vantajosos do que recalculá-los para cada acesso. O algoritmo também deve evita o paralelismo interno, portanto, N threads simultâneos devem exigir N vezes mais memória de uma vez. Dwork et al [22] investigaram e formalizaram esta abordagem levando-os a sugerir outra variante da função de precificação: “Mbound”. Mais uma obra pertence a F. Coelho [20], que 11 Transação Entrada de transmissão Saída0 . . . Saída . . . Saída Imagem principal Assinaturas Assinatura do anel Chave de destino Saída1 Chave de destino Saída Transações estrangeiras Saída do remetente Chave de destino Par de chaves único Único chave privada Eu = xHp(P) P,x Figura 7. Geração de assinatura de anel em uma transação padrão. 5 Prova de trabalho igualitária Nesta seção propomos e fundamentamos o novo algoritmo proof-of-work. Nosso objetivo principal é fechar a lacuna entre os mineradores de CPU (maioria) e GPU/FPGA/ASIC (minoria). É apropriado que alguns usuários possam ter uma certa vantagem sobre outros, mas seus investimentos deve crescer pelo menos linearmente com a potência. De forma mais geral, a produção de dispositivos para fins especiais tem que ser o menos lucrativo possível. 5.1 Trabalhos relacionados O protocolo Bitcoin proof-of-work original usa a função de precificação com uso intensivo de CPU SHA-256. Consiste principalmente em operadores lógicos básicos e depende exclusivamente da velocidade computacional de processador, portanto, é perfeitamente adequado para implementação multicore/conveyer. No entanto, os computadores modernos não estão limitados apenas pelo número de operações por segundo, mas também pelo tamanho da memória. Embora alguns processadores possam ser substancialmente mais rápidos que outros [8], os tamanhos de memória são menos propensos a variar entre as máquinas. As funções de preço ligadas à memória foram introduzidas pela primeira vez por Abadi et al e foram definidas como “funções cujo tempo de computação é dominado pelo tempo gasto no acesso à memória” [15]. A ideia principal é construir um algoritmo alocando um grande bloco de dados (“scratchpad”) dentro da memória que pode ser acessada de forma relativamente lenta (por exemplo, RAM) e “acessando um sequência imprevisível de locais” dentro dele. Um bloco deve ser grande o suficiente para fazer a preservação os dados mais vantajosos do que recalculá-los para cada acesso. O algoritmo também deve evita o paralelismo interno, portanto, N threads simultâneos devem exigir N vezes mais memória de uma vez. Dwork et al [22] investigaram e formalizaram esta abordagem levando-os a sugerir outra variante da função de precificação: “Mbound”. Mais uma obra pertence a F. Coelho [20], que 11 21 Estes são, aparentemente, nossos UTXO: valores e chaves de destino. Se Alex é quem está construindo esta transação padrão e está enviando para Bob, então Alex também possui as chaves privadas para cada um deles. Gosto muito deste diagrama, porque ele responde a algumas perguntas anteriores. Uma entrada Txn consiste de um conjunto de saídas Txn e um keminha imagem. Em seguida, é assinado com uma assinatura circular, incluindo todos das chaves privadas que Alex possui para todas as transações estrangeiras envolvidas no negócio. O A saída Txn consiste em um valor e uma chave de destino. O destinatário da transação pode, à vontade, gere sua chave privada única, conforme descrito anteriormente no artigo, para gastar o dinheiro. Será um prazer descobrir o quanto isso corresponde ao código real... Não, Nic van Saberhagen descreve vagamente algumas propriedades de um algoritmo de prova de trabalho, sem realmente descrever esse algoritmo. O próprio algoritmo CryptoNight EXIGIRÁ uma análise profunda. Quando li isso, gaguejei. Deveria o investimento crescer pelo menos linearmente com o poder, ou deveria o investimento cresce no máximo linearmente com a potência? E então eu percebi; Eu, como minerador ou investidor, geralmente penso em "quanto poder posso obter para um investimento?" e não "quanto investimento é necessário para uma quantidade fixa de energia?" Claro, denote investimento por I e poder por P. Se I(P) é investimento em função do poder e P(I) é o poder em função do investimento, eles serão inversos um do outro (onde quer que podem existir inversos). E se I(P) for mais rápido que linear, então P(I) será mais lento que linear. Portanto, haverá uma taxa de retorno reduzida para os investidores. Ou seja, o que o autor está dizendo aqui é: "com certeza, à medida que você investe mais, você vai conseguir mais poder. Mas deveríamos tentar fazer disso uma taxa de retorno reduzida." Os investimentos em CPU acabarão sendo sublineares, eventualmente; a questão é se os autores projetaram um algoritmo POW que forçará os ASICs a fazer isso também. Uma hipotética “moeda futura” deveria sempre minerar com os recursos mais lentos/mais limitados? O artigo de Abadi et al (que tem como autores alguns engenheiros do Google e da Microsoft) é, essencialmente, usando o fato de que nos últimos anos o tamanho da memória teve um tamanho muito menor variação entre máquinas do que a velocidade do processador e com uma relação investimento-potência mais do que linear. Em alguns anos, isso poderá ter que ser reavaliado! Tudo é uma corrida armamentista... Construir uma função hash é difícil; construir uma função hash que satisfaça essas restrições parece ser mais difícil. Este artigo parece não ter nenhuma explicação sobre o real hashalgoritmo CryptoNight. Eu acho que é uma implementação do SHA-3 com muita memória, baseada nas postagens do fórum, mas não tenho ideia... e esse é o ponto. Deve ser explicado.
propôs a solução mais eficaz: “Hokkaido”. Até onde sabemos, o último trabalho baseado na ideia de pesquisas pseudo-aleatórias em um grande array é o algoritmo conhecido como “scrypt” por C. Percival [32]. Ao contrário das funções anteriores, ele se concentra em derivação de chave, e não sistemas proof-of-work. Apesar deste fato, o scrypt pode servir ao nosso propósito: funciona bem como uma função de precificação no problema de conversão parcial hash, como SHA-256 em Bitcoin. Até agora, o scrypt já foi aplicado em Litecoin [14] e em alguns outros forks Bitcoin. No entanto, a sua implementação não está realmente limitada à memória: a relação “tempo de acesso à memória / time” não é grande o suficiente porque cada instância usa apenas 128 KB. Isso permite que mineradores de GPU ser cerca de 10 vezes mais eficaz e continua a deixar a possibilidade de criar relativamente dispositivos de mineração baratos, mas altamente eficientes. Além disso, a própria construção do scrypt permite uma troca linear entre tamanho de memória e Velocidade da CPU devido ao fato de que cada bloco do scratchpad é derivado apenas do anterior. Por exemplo, você pode armazenar cada segundo bloco e recalcular os outros de forma preguiçosa, ou seja, apenas quando for necessário. Os índices pseudo-aleatórios são considerados uniformemente distribuídos, portanto, o valor esperado dos recálculos dos blocos adicionais é 1 \(2 \cdot N\), onde N é o número de iterações. O tempo total de cálculo aumenta menos da metade porque também há operações independentes de tempo (tempo constante), como preparar o scratchpad e hashing em cada iteração. Economizar 2/3 da memória custa 1 \(3 \cdot N\) + 1 3 \(\cdot\) \(2 \cdot N\) = N recálculos adicionais; 9/10 resulta em 1 \(10 \cdot N\) + . . . + 1 \(10 \cdot 9 \cdot N\) = 4,5N. É fácil mostrar que armazenar apenas 1 s de todos os blocos aumenta o tempo menos que por um fator de s−1 2. Isto, por sua vez, implica que uma máquina com uma CPU 200 vezes mais rápido que os chips modernos podem armazenar apenas 320 bytes do scratchpad. 5.2 O algoritmo proposto Propomos um novo algoritmo limitado à memória para a função de precificação proof-of-work. Depende de acesso aleatório a uma memória lenta e enfatiza a dependência da latência. Ao contrário de criptografar cada novo bloco (64 bytes de comprimento) depende de todos os blocos anteriores. Como resultado, uma hipótese “economizador de memória” deve aumentar exponencialmente sua velocidade de cálculo. Nosso algoritmo requer cerca de 2 Mb por instância pelos seguintes motivos: 1. Cabe no cache L3 (por núcleo) dos processadores modernos, que deve se tornar mainstream em alguns anos; 2. Um megabyte de memória interna é um tamanho quase inaceitável para um pipeline ASIC moderno; 3. As GPUs podem executar centenas de instâncias simultâneas, mas são limitadas de outras maneiras: A memória GDDR5 é mais lenta que o cache L3 da CPU e notável por sua largura de banda, não velocidade de acesso aleatório. 4. Uma expansão significativa do scratchpad exigiria um aumento nas iterações, o que em turno implica um aumento geral do tempo. Chamadas “pesadas” em uma rede p2p sem confiança podem levar a vulnerabilidades graves, porque os nós são obrigados a verificar o proof-of-work de cada novo bloco. Se um nó gastar uma quantidade considerável de tempo em cada avaliação hash, ele poderá ser facilmente DDoS causado por uma enxurrada de objetos falsos com dados de trabalho arbitrários (valores nonce). 12 propôs a solução mais eficaz: “Hokkaido”. Até onde sabemos, o último trabalho baseado na ideia de pesquisas pseudo-aleatórias em um grande array é o algoritmo conhecido como “scrypt” por C. Percival [32]. Ao contrário das funções anteriores, ele se concentra em derivação de chave, e não sistemas proof-of-work. Apesar deste fato, o scrypt pode servir ao nosso propósito: funciona bem como uma função de precificação no problema de conversão parcial hash, como SHA-256 em Bitcoin. Até agora, o scrypt já foi aplicado em Litecoin [14] e em alguns outros forks Bitcoin. No entanto, a sua implementação não está realmente limitada à memória: a relação “tempo de acesso à memória / time” não é grande o suficiente porque cada instância usa apenas 128 KB. Isso permite que mineradores de GPU ser cerca de 10 vezes mais eficaz e continua a deixar a possibilidade de criar relativamente dispositivos de mineração baratos, mas altamente eficientes. Além disso, a própria construção do scrypt permite uma troca linear entre tamanho de memória e Velocidade da CPU devido ao fato de que cada bloco do scratchpad é derivado apenas do anterior. Por exemplo, você pode armazenar cada segundo bloco e recalcular os outros de forma preguiçosa, ou seja, apenas quando for necessário. Os índices pseudo-aleatórios são considerados uniformemente distribuídos, portanto, o valor esperado dos recálculos dos blocos adicionais é 1 \(2 \cdot N\), ondeN é o número de iterações. O tempo total de cálculo aumenta menos da metade porque também há operações independentes de tempo (tempo constante), como preparar o scratchpad e hashing em cada iteração. Economizar 2/3 da memória custa 1 \(3 \cdot N\) + 1 3 \(\cdot\) \(2 \cdot N\) = N recálculos adicionais; 9/10 resulta em 1 \(10 \cdot N\) + . . . + 1 \(10 \cdot 9 \cdot N\) = 4,5N. É fácil mostrar que armazenar apenas 1 s de todos os blocos aumenta o tempo menos que por um fator de s−1 2. Isto, por sua vez, implica que uma máquina com uma CPU 200 vezes mais rápido que os chips modernos podem armazenar apenas 320 bytes do scratchpad. 5.2 O algoritmo proposto Propomos um novo algoritmo limitado à memória para a função de precificação proof-of-work. Depende de acesso aleatório a uma memória lenta e enfatiza a dependência da latência. Ao contrário de criptografar cada novo bloco (64 bytes de comprimento) depende de todos os blocos anteriores. Como resultado, uma hipótese “economizador de memória” deve aumentar exponencialmente sua velocidade de cálculo. Nosso algoritmo requer cerca de 2 Mb por instância pelos seguintes motivos: 1. Cabe no cache L3 (por núcleo) dos processadores modernos, que deve se tornar mainstream em alguns anos; 2. Um megabyte de memória interna é um tamanho quase inaceitável para um pipeline ASIC moderno; 3. As GPUs podem executar centenas de instâncias simultâneas, mas são limitadas de outras maneiras: A memória GDDR5 é mais lenta que o cache L3 da CPU e notável por sua largura de banda, não velocidade de acesso aleatório. 4. Uma expansão significativa do scratchpad exigiria um aumento nas iterações, o que em turno implica um aumento geral do tempo. Chamadas “pesadas” em uma rede p2p sem confiança podem levar a vulnerabilidades graves, porque os nós são obrigados a verificar o proof-of-work de cada novo bloco. Se um nó gastar uma quantidade considerável de tempo em cada avaliação hash, ele poderá ser facilmente DDoS causado por uma enxurrada de objetos falsos com dados de trabalho arbitrários (valores nonce). 12 22 Deixa pra lá, é uma moeda criptografada? Onde está o algoritmo? Tudo o que vejo é um anúncio. É aqui que o Cryptonote, se seu algoritmo PoW valer a pena, realmente brilhará. Não é realmente SHA-256, não é realmente criptografado. É novo, vinculado à memória e não recursivo.
6 Outras vantagens 6.1 Emissão suave O limite superior para a quantidade total de moedas digitais CryptoNote é: MSupply = 264 −1 unidades atômicas. Esta é uma restrição natural baseada apenas nos limites de implementação, não na intuição como “N moedas deveriam ser suficientes para qualquer pessoa”. Para garantir a suavidade do processo de emissão, usamos a seguinte fórmula para bloco recompensas: BaseReward = (MSupply −A) ≫18, onde A é a quantidade de moedas geradas anteriormente. 6.2 Parâmetros ajustáveis 6.2.1 Dificuldade CryptoNote contém um algoritmo de segmentação que altera a dificuldade de cada bloco. Isto diminui o tempo de reação do sistema quando a taxa de rede hash está crescendo ou diminuindo intensamente, preservando uma taxa de bloqueio constante. O método Bitcoin original calcula a relação do valor real e intervalo de tempo alvo entre os últimos blocos de 2016 e usa-o como multiplicador para o atual dificuldade. Obviamente isto é inadequado para recálculos rápidos (devido à grande inércia) e resulta em oscilações. A ideia geral por trás do nosso algoritmo é somar todo o trabalho concluído pelos nós e divida pelo tempo que gastaram. A medida do trabalho são os valores de dificuldade correspondentes em cada bloco. Mas devido a carimbos de data/hora imprecisos e não confiáveis, não podemos determinar a data exata intervalo de tempo entre blocos. Um usuário pode mudar seu carimbo de data/hora para o futuro e para a próxima vez intervalos podem ser improvavelmente pequenos ou até negativos. Presumivelmente, haverá poucos incidentes de desse tipo, para que possamos apenas classificar os carimbos de data e hora e eliminar os valores discrepantes (ou seja, 20%). A gama de os valores restantes são o tempo gasto em 80% dos blocos correspondentes. 6.2.2 Limites de tamanho Os usuários pagam pelo armazenamento do blockchain e terão direito a votar no seu tamanho. Cada mineiro lida com a compensação entre equilibrar os custos e o lucro das taxas e define seu próprio “soft-limit” para criação de blocos. Além disso, a regra básica para o tamanho máximo do bloco é necessária para evitando que blockchain seja inundado com transações falsas, no entanto, este valor deve não ser codificado. Seja MN o valor mediano dos últimos N tamanhos de blocos. Então o “limite rígido” para o tamanho de aceitar blocos é \(2 \cdot M_N\). Ele evita o inchaço do blockchain, mas ainda permite que o limite crescer lentamente com o tempo, se necessário. O tamanho da transação não precisa ser limitado explicitamente. É limitado pelo tamanho de um bloco; e se alguém quiser criar uma transação enorme com centenas de entradas/saídas (ou com (o elevado grau de ambiguidade nas assinaturas de anéis), ele pode fazê-lo pagando uma taxa suficiente. 6.2.3 Penalidade por excesso de tamanho Um minerador ainda tem a capacidade de encher um bloco com suas próprias transações sem taxa até o limite máximo. tamanho 2 \(\cdot\) MB. Embora apenas a maioria dos mineradores possa alterar o valor mediano, ainda há uma 13 6 Outras vantagens 6.1 Emissão suave O limite superior para a quantidade total de moedas digitais CryptoNote é: MSupply = 264 −1 unidades atômicas. Esta é uma restrição natural baseada apenas nos limites de implementação, não na intuição como “N moedas deveriam ser suficientes para qualquer pessoa”. Para garantir a suavidade do processo de emissão, usamos a seguinte fórmula para bloco recompensas: BaseReward = (MSupply −A) ≫18, onde A é a quantidade de moedas geradas anteriormente. 6.2 Parâmetros ajustáveis 6.2.1 Dificuldade CryptoNote contém um algoritmo de segmentação que altera a dificuldade de cada bloco. Isto diminui o tempo de reação do sistema quando a taxa de rede hash está crescendo ou diminuindo intensamente, preservando uma taxa de bloqueio constante. O método Bitcoin original calcula a relação do valor real e intervalo de tempo alvo entre os últimos blocos de 2016 e usa-o como multiplicador para o atual dificuldade. Obviamente isto é inadequado para recálculos rápidos (devido à grande inércia) e resulta em oscilações. A ideia geral por trás do nosso algoritmo é somar todo o trabalho concluído pelos nós e divida pelo tempo que gastaram. A medida do trabalho são os valores de dificuldade correspondentes em cada bloco. Mas devido a carimbos de data/hora imprecisos e não confiáveis, não podemos determinar a data exata intervalo de tempo entre blocos. Um usuário pode mudar seu carimbo de data/hora para o futuro e para a próxima vez intervalos podem ser improvavelmente pequenos ou até negativos. Presumivelmente, haverá poucos incidentes de desse tipo, para que possamos apenas classificar os carimbos de data e hora e eliminar os valores discrepantes (ou seja, 20%). A gama de os valores restantes são o tempo gasto em 80% dos blocos correspondentes. 6.2.2 Limites de tamanho Os usuários pagam pelo armazenamento do blockchain e terão direito a votar no seu tamanho. Cada mineiro lida com o trade-off entre o equilíbrioe custa e lucra com as taxas e define seu próprio “soft-limit” para criação de blocos. Além disso, a regra básica para o tamanho máximo do bloco é necessária para evitando que blockchain seja inundado com transações falsas, no entanto, este valor deve não ser codificado. Seja MN o valor mediano dos últimos N tamanhos de blocos. Então o “limite rígido” para o tamanho de aceitar blocos é \(2 \cdot M_N\). Ele evita o inchaço do blockchain, mas ainda permite que o limite crescer lentamente com o tempo, se necessário. O tamanho da transação não precisa ser limitado explicitamente. É limitado pelo tamanho de um bloco; e se alguém quiser criar uma transação enorme com centenas de entradas/saídas (ou com (o elevado grau de ambiguidade nas assinaturas de anéis), ele pode fazê-lo pagando uma taxa suficiente. 6.2.3 Penalidade por excesso de tamanho Um minerador ainda tem a capacidade de encher um bloco com suas próprias transações sem taxa até o limite máximo. tamanho 2 \(\cdot\) MB. Embora apenas a maioria dos mineradores possa alterar o valor mediano, ainda há uma 13 23 Unidades atômicas. Eu gosto disso. Isso é equivalente a Satoshis? Se sim, então isso significa que haverá 185 bilhões de criptomoedas. Eu sei que isso deve ser, eventualmente, ajustado em algumas páginas, ou talvez haja um erro de digitação? Se a recompensa base for “todas as moedas restantes”, então apenas um bloco será suficiente para obter todas as moedas. Instamine. Por outro lado, se isto for supostamente proporcional de alguma forma ao diferença de tempo entre agora e alguma data de término da produção de moedas? Isso seria faz sentido. Além disso, no meu mundo, dois sinais de maior que este significam "muito maior que". Será que o autor possivelmente significa outra coisa? Se o ajuste à dificuldade ocorrer a cada bloco, um invasor poderá ter um conjunto muito grande de as máquinas mineram e desligam em intervalos de tempo cuidadosamente escolhidos. Isso pode causar uma explosão caótica (ou cair para zero) na dificuldade, se as fórmulas de ajuste de dificuldade não forem amortecidas adequadamente. Não há dúvida de que o método de Bitcoin é inadequado para recálculos rápidos, mas a ideia de inércia nestes sistemas precisaria ser provada, e não tomada como certa. Além disso, oscilações na dificuldade da rede não é necessariamente um problema, a menos que resulte em oscilações de fornecimento de moedas - e ter uma dificuldade que muda muito rapidamente pode causar "correção excessiva". O tempo gasto, especialmente em um curto espaço de tempo como alguns minutos, será proporcional ao "total número de blocos criados na rede." A constante de proporcionalidade irá, por si só, crescer ao longo do tempo, presumivelmente exponencialmente se o CN decolar. Pode ser uma ideia melhor simplesmente ajustar a dificuldade para manter o "total de blocos criados no rede desde que o último bloco foi adicionado à cadeia principal" dentro de algum valor constante, ou com variação limitada ou algo parecido. Se um algoritmo adaptativo que seja computacionalmente fácil de implementar, isso pareceria resolver o problema. Mas então, se usássemos esse método, alguém com uma grande exploração mineira poderia encerrar a sua exploração. por algumas horas e ligue-o novamente. Nos primeiros quarteirões, aquela fazenda fará banco. Então, na verdade, esse método traria um ponto interessante: a mineração se torna (em média) um perder jogo sem ROI, especialmente à medida que mais pessoas acessam a rede. Se a dificuldade de mineração rede monitorada de perto hashrate, de alguma forma duvido que as pessoas mineriam tanto quanto atualmente faço. Ou, por outro lado, em vez de manterem as suas explorações mineiras a funcionar 24 horas por dia, 7 dias por semana, podem transformá-las ligado por 6 horas, desligado por 2, ligado por 6, desligado por 2 ou algo parecido. Basta mudar para outra moeda por algumas horas, espere a dificuldade diminuir e depois volte para ganhar alguns extras blocos de lucratividade à medida que a rede se adapta. E você sabe o que? Na verdade, isso é provavelmente um dos melhores cenários de mineração em que pensei... Isso poderia ser circular, mas se o tempo de criação do bloco média for cerca de um minuto, podemos simplesmente usar o número de blocos como proxy para "tempo gasto?"
6 Outras vantagens 6.1 Emissão suave O limite superior para a quantidade total de moedas digitais CryptoNote é: MSupply = 264 −1 unidades atômicas. Esta é uma restrição natural baseada apenas nos limites de implementação, não na intuição como “N moedas deveriam ser suficientes para qualquer pessoa”. Para garantir a suavidade do processo de emissão, usamos a seguinte fórmula para bloco recompensas: BaseReward = (MSupply −A) ≫18, onde A é a quantidade de moedas geradas anteriormente. 6.2 Parâmetros ajustáveis 6.2.1 Dificuldade CryptoNote contém um algoritmo de segmentação que altera a dificuldade de cada bloco. Isto diminui o tempo de reação do sistema quando a taxa de rede hash está crescendo ou diminuindo intensamente, preservando uma taxa de bloqueio constante. O método Bitcoin original calcula a relação do valor real e intervalo de tempo alvo entre os últimos blocos de 2016 e usa-o como multiplicador para o atual dificuldade. Obviamente isto é inadequado para recálculos rápidos (devido à grande inércia) e resulta em oscilações. A ideia geral por trás do nosso algoritmo é somar todo o trabalho concluído pelos nós e divida pelo tempo que gastaram. A medida do trabalho são os valores de dificuldade correspondentes em cada bloco. Mas devido a carimbos de data/hora imprecisos e não confiáveis, não podemos determinar a data exata intervalo de tempo entre blocos. Um usuário pode mudar seu carimbo de data/hora para o futuro e para a próxima vez intervalos podem ser improvavelmente pequenos ou até negativos. Presumivelmente, haverá poucos incidentes de desse tipo, para que possamos apenas classificar os carimbos de data e hora e eliminar os valores discrepantes (ou seja, 20%). A gama de os valores restantes são o tempo gasto em 80% dos blocos correspondentes. 6.2.2 Limites de tamanho Os usuários pagam pelo armazenamento do blockchain e terão direito a votar no seu tamanho. Cada mineiro lida com a compensação entre equilibrar os custos e o lucro das taxas e define seu próprio “soft-limit” para criação de blocos. Além disso, a regra básica para o tamanho máximo do bloco é necessária para evitando que blockchain seja inundado com transações falsas, no entanto, este valor deve não ser codificado. Seja MN o valor mediano dos últimos N tamanhos de blocos. Então o “limite rígido” para o tamanho de aceitar blocos é \(2 \cdot M_N\). Ele evita o inchaço do blockchain, mas ainda permite que o limite crescer lentamente com o tempo, se necessário. O tamanho da transação não precisa ser limitado explicitamente. É limitado pelo tamanho de um bloco; e se alguém quiser criar uma transação enorme com centenas de entradas/saídas (ou com (o elevado grau de ambiguidade nas assinaturas de anéis), ele pode fazê-lo pagando uma taxa suficiente. 6.2.3 Penalidade por excesso de tamanho Um minerador ainda tem a capacidade de encher um bloco com suas próprias transações sem taxa até o limite máximo. tamanho 2 \(\cdot\) MB. Embora apenas a maioria dos mineradores possa alterar o valor mediano, ainda há uma 13 6 Outras vantagens 6.1 Emissão suave O limite superior para a quantidade total de moedas digitais CryptoNote é: MSupply = 264 −1 unidades atômicas. Esta é uma restrição natural baseada apenas nos limites de implementação, não na intuição como “N moedas deveriam ser suficientes para qualquer pessoa”. Para garantir a suavidade do processo de emissão, usamos a seguinte fórmula para bloco recompensas: BaseReward = (MSupply −A) ≫18, onde A é a quantidade de moedas geradas anteriormente. 6.2 Parâmetros ajustáveis 6.2.1 Dificuldade CryptoNote contém um algoritmo de segmentação que altera a dificuldade de cada bloco. Isto diminui o tempo de reação do sistema quando a taxa de rede hash está crescendo ou diminuindo intensamente, preservando uma taxa de bloqueio constante. O método Bitcoin original calcula a relação do valor real e intervalo de tempo alvo entre os últimos blocos de 2016 e usa-o como multiplicador para o atual dificuldade. Obviamente isto é inadequado para recálculos rápidos (devido à grande inércia) e resulta em oscilações. A ideia geral por trás do nosso algoritmo é somar todo o trabalho concluído pelos nós e divida pelo tempo que gastaram. A medida do trabalho são os valores de dificuldade correspondentes em cada bloco. Mas devido a carimbos de data/hora imprecisos e não confiáveis, não podemos determinar a data exata intervalo de tempo entre blocos. Um usuário pode mudar seu carimbo de data/hora para o futuro e para a próxima vez intervalos podem ser improvavelmente pequenos ou até negativos. Presumivelmente, haverá poucos incidentes de desse tipo, para que possamos apenas classificar os carimbos de data e hora e eliminar os valores discrepantes (ou seja, 20%). A gama de os valores restantes são o tempo gasto em 80% dos blocos correspondentes. 6.2.2 Limites de tamanho Os usuários pagam pelo armazenamento do blockchain e terão direito a votar no seu tamanho. Cada mineiro lida com o trade-off entre o equilíbrioe custa e lucra com as taxas e define seu próprio “soft-limit” para criação de blocos. Além disso, a regra básica para o tamanho máximo do bloco é necessária para evitando que blockchain seja inundado com transações falsas, no entanto, este valor deve não ser codificado. Seja MN o valor mediano dos últimos N tamanhos de blocos. Então o “limite rígido” para o tamanho de aceitar blocos é \(2 \cdot M_N\). Ele evita o inchaço do blockchain, mas ainda permite que o limite crescer lentamente com o tempo, se necessário. O tamanho da transação não precisa ser limitado explicitamente. É limitado pelo tamanho de um bloco; e se alguém quiser criar uma transação enorme com centenas de entradas/saídas (ou com (o elevado grau de ambiguidade nas assinaturas de anéis), ele pode fazê-lo pagando uma taxa suficiente. 6.2.3 Penalidade por excesso de tamanho Um minerador ainda tem a capacidade de encher um bloco com suas próprias transações sem taxa até o limite máximo. tamanho 2 \(\cdot\) MB. Embora apenas a maioria dos mineradores possa alterar o valor mediano, ainda há uma 13 24 Ok, então temos um blockchain, e cada bloco tem carimbos de data e hora ALÉM de simplesmente ser ordenado. Isto foi claramente inserido simplesmente para ajuste de dificuldade, porque os carimbos de data e hora são muito pouco confiável, como mencionado. Podemos ter carimbos de data/hora contraditórios na cadeia? Se o Bloco A vier antes do Bloco B na cadeia e tudo for consistente em termos financeiros, mas o Bloco A parece ter sido criado depois do Bloco B? Porque, talvez, alguém possuísse uma grande parte da rede? Tudo bem? Provavelmente porque as finanças não estão bagunçadas. Ok, então eu odeio esse arbitrário "apenas 80% dos blocos são legítimos para o blockchain principal" abordagem. A intenção era evitar que mentirosos ajustassem seus carimbos de data e hora? Mas agora, acrescenta incentivo para que todos mintam sobre seus carimbos de data e hora e apenas escolham a mediana. Por favor, defina. Significando "para este bloco, inclua apenas transações que incluam taxas maiores que p%, preferencialmente com taxas maiores que 2p%" ou algo parecido? O que eles querem dizer com falso? Se a transação for consistente com o histórico passado do blockchain, e a transação inclui taxas que satisfazem os mineiros, isso não é suficiente? Bem, não, não necessariamente. Se não existir tamanho máximo de bloco, não há nada que possa manter um usuário mal-intencionado desde simplesmente enviar um enorme bloco de transações para si mesmo de uma só vez apenas para desacelerar a rede. Uma regra básica para o tamanho máximo do bloco evita que as pessoas coloquem enormes quantidades de lixo dados no blockchain de uma só vez, apenas para desacelerar as coisas. Mas tal regra certamente tem que ser adaptativo - durante a época de Natal, por exemplo, podemos esperar que o tráfego aumente, e o tamanho do bloco fique muito grande e, imediatamente depois, o tamanho do bloco diminua posteriormente novamente. Portanto, precisamos de a) algum tipo de limite adaptativo ou b) um limite grande o suficiente para que 99% dos picos de Natal razoáveis não quebram o limite. Claro, esse segundo é impossível de estimativa - quem sabe se uma moeda vai pegar? Melhor torná-lo adaptativo e não se preocupar sobre isso. Mas então temos um problema de teoria de controle: como tornar isso adaptativo sem vulnerabilidade a ataques ou oscilações selvagens e malucas? Observe que um método adaptativo não impede que usuários mal-intencionados acumulem pequenas quantias de dados inúteis ao longo do tempo no blockchain para causar inchaço a longo prazo. Esta é uma questão diferente no geral e com o qual as moedas criptográficas têm sérios problemas.
6 Outras vantagens 6.1 Emissão suave O limite superior para a quantidade total de moedas digitais CryptoNote é: MSupply = 264 −1 unidades atômicas. Esta é uma restrição natural baseada apenas nos limites de implementação, não na intuição como “N moedas deveriam ser suficientes para qualquer pessoa”. Para garantir a suavidade do processo de emissão, usamos a seguinte fórmula para bloco recompensas: BaseReward = (MSupply −A) ≫18, onde A é a quantidade de moedas geradas anteriormente. 6.2 Parâmetros ajustáveis 6.2.1 Dificuldade CryptoNote contém um algoritmo de segmentação que altera a dificuldade de cada bloco. Isto diminui o tempo de reação do sistema quando a taxa de rede hash está crescendo ou diminuindo intensamente, preservando uma taxa de bloqueio constante. O método Bitcoin original calcula a relação do valor real e intervalo de tempo alvo entre os últimos blocos de 2016 e usa-o como multiplicador para o atual dificuldade. Obviamente isto é inadequado para recálculos rápidos (devido à grande inércia) e resulta em oscilações. A ideia geral por trás do nosso algoritmo é somar todo o trabalho concluído pelos nós e divida pelo tempo que gastaram. A medida do trabalho são os valores de dificuldade correspondentes em cada bloco. Mas devido a carimbos de data/hora imprecisos e não confiáveis, não podemos determinar a data exata intervalo de tempo entre blocos. Um usuário pode mudar seu carimbo de data/hora para o futuro e para a próxima vez intervalos podem ser improvavelmente pequenos ou até negativos. Presumivelmente, haverá poucos incidentes de desse tipo, para que possamos apenas classificar os carimbos de data e hora e eliminar os valores discrepantes (ou seja, 20%). A gama de os valores restantes são o tempo gasto em 80% dos blocos correspondentes. 6.2.2 Limites de tamanho Os usuários pagam pelo armazenamento do blockchain e terão direito a votar no seu tamanho. Cada mineiro lida com a compensação entre equilibrar os custos e o lucro das taxas e define seu próprio “soft-limit” para criação de blocos. Além disso, a regra básica para o tamanho máximo do bloco é necessária para evitando que blockchain seja inundado com transações falsas, no entanto, este valor deve não ser codificado. Seja MN o valor mediano dos últimos N tamanhos de blocos. Então o “limite rígido” para o tamanho de aceitar blocos é \(2 \cdot M_N\). Ele evita o inchaço do blockchain, mas ainda permite que o limite crescer lentamente com o tempo, se necessário. O tamanho da transação não precisa ser limitado explicitamente. É limitado pelo tamanho de um bloco; e se alguém quiser criar uma transação enorme com centenas de entradas/saídas (ou com (o elevado grau de ambiguidade nas assinaturas de anéis), ele pode fazê-lo pagando uma taxa suficiente. 6.2.3 Penalidade por excesso de tamanho Um minerador ainda tem a capacidade de encher um bloco com suas próprias transações sem taxa até o limite máximo. tamanho 2 \(\cdot\) MB. Embora apenas a maioria dos mineradores possa alterar o valor mediano, ainda há uma 13 6 Outras vantagens 6.1 Emissão suave O limite superior para a quantidade total de moedas digitais CryptoNote é: MSupply = 264 −1 unidades atômicas. Esta é uma restrição natural baseada apenas nos limites de implementação, não na intuição como “N moedas deveriam ser suficientes para qualquer pessoa”. Para garantir a suavidade do processo de emissão, usamos a seguinte fórmula para bloco recompensas: BaseReward = (MSupply −A) ≫18, onde A é a quantidade de moedas geradas anteriormente. 6.2 Parâmetros ajustáveis 6.2.1 Dificuldade CryptoNote contém um algoritmo de segmentação que altera a dificuldade de cada bloco. Isto diminui o tempo de reação do sistema quando a taxa de rede hash está crescendo ou diminuindo intensamente, preservando uma taxa de bloqueio constante. O método Bitcoin original calcula a relação do valor real e intervalo de tempo alvo entre os últimos blocos de 2016 e usa-o como multiplicador para o atual dificuldade. Obviamente isto é inadequado para recálculos rápidos (devido à grande inércia) e resulta em oscilações. A ideia geral por trás do nosso algoritmo é somar todo o trabalho concluído pelos nós e divida pelo tempo que gastaram. A medida do trabalho são os valores de dificuldade correspondentes em cada bloco. Mas devido a carimbos de data/hora imprecisos e não confiáveis, não podemos determinar a data exata intervalo de tempo entre blocos. Um usuário pode mudar seu carimbo de data/hora para o futuro e para a próxima vez intervalos podem ser improvavelmente pequenos ou até negativos. Presumivelmente, haverá poucos incidentes de desse tipo, para que possamos apenas classificar os carimbos de data e hora e eliminar os valores discrepantes (ou seja, 20%). A gama de os valores restantes são o tempo gasto em 80% dos blocos correspondentes. 6.2.2 Limites de tamanho Os usuários pagam pelo armazenamento do blockchain e terão direito a votar no seu tamanho. Cada mineiro lida com o trade-off entre o equilíbrioe custa e lucra com as taxas e define seu próprio “soft-limit” para criação de blocos. Além disso, a regra básica para o tamanho máximo do bloco é necessária para evitando que blockchain seja inundado com transações falsas, no entanto, este valor deve não ser codificado. Seja MN o valor mediano dos últimos N tamanhos de blocos. Então o “limite rígido” para o tamanho de aceitar blocos é \(2 \cdot M_N\). Ele evita o inchaço do blockchain, mas ainda permite que o limite crescer lentamente com o tempo, se necessário. O tamanho da transação não precisa ser limitado explicitamente. É limitado pelo tamanho de um bloco; e se alguém quiser criar uma transação enorme com centenas de entradas/saídas (ou com (o elevado grau de ambiguidade nas assinaturas de anéis), ele pode fazê-lo pagando uma taxa suficiente. 6.2.3 Penalidade por excesso de tamanho Um minerador ainda tem a capacidade de encher um bloco com suas próprias transações sem taxa até o limite máximo. tamanho 2 \(\cdot\) MB. Embora apenas a maioria dos mineradores possa alterar o valor mediano, ainda há uma 13 25 Redimensionando o tempo para que uma unidade de tempo seja N blocos, o tamanho médio do bloco ainda poderia, teoricamente, crescer exponencialmente proporcionalmente a 2ˆt. Por outro lado, um limite mais geral no próximo bloco seria M_nf(M_n) para alguma função f. Quais propriedades de f seriam escolhemos para garantir algum “crescimento razoável” do tamanho do bloco? A progressão de os tamanhos dos blocos (após o tempo de redimensionamento) seriam assim: 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( ... E o objetivo aqui é escolher f tal que esta sequência não cresça mais rápido do que, digamos, linearmente, ou talvez até como Log(t). Claro, se f(M_n) = a para alguma constante a, esta sequência é na verdade M_n aM_n aˆ2M_n aˆ3M_n ... E, claro, a única maneira de limitar isso ao crescimento no máximo linear é escolhendo a=1. Isto é, obviamente, inviável. Não permite o crescimento de forma alguma. Se, por outro lado, f(M_n) for uma função não constante, então a situação é muito mais complicado e pode permitir uma solução elegante. Vou pensar nisso por um tempo. Esta taxa deverá ser grande o suficiente para descontar a penalidade de excesso de tamanho da próxima seção. Por que um usuário geral é considerado homem, hein? Hein?
possibilidade de inchar o blockchain e produzir uma carga adicional nos nós. Para desencorajar participantes malévolos criem grandes blocos, introduzimos uma função de penalidade: NovaRecompensa = BaseRecompensa \(\cdot\) TamanhoPreto Minnesota −1 2 Esta regra é aplicada somente quando BlkSize é maior que o tamanho mínimo do bloco livre, que deve estar próximo do máximo (10kb, \(M_N \cdot 110\%\)). Os mineiros estão autorizados a criar blocos de “tamanho normal” e até mesmo excedê-lo com lucro quando as taxas gerais ultrapassarem a penalidade. Mas é improvável que as taxas aumentem quadraticamente diferente do valor da penalidade, então haverá um equilíbrio. 6.3 Scripts de transação CryptoNote possui um subsistema de script muito minimalista. Um remetente especifica uma expressão Φ = f (x1, x2, . . . , xn), onde n é o número de chaves públicas de destino {Pi}n eu=1. Apenas cinco binários operadores são suportados: min, max, sum, mul e cmp. Quando o destinatário gasta esse pagamento, ele produz \(0 \leq k \leq n\) assinaturas e as passa para a entrada da transação. O processo de verificação simplesmente avalia Φ com xi = 1 para verificar uma assinatura válida para a chave pública Pi e xi = 0. Um verificador aceita a prova se Φ > 0. Apesar da sua simplicidade, esta abordagem cobre todos os casos possíveis: • Assinatura Multi/Limiar. Para a assinatura múltipla “M-out-of-N” estilo Bitcoin (ou seja, o receptor deve fornecer pelo menos \(0 \leq M \leq N\) assinaturas válidas) Φ = x1+x2+. . .+xN \(\geq M\) (para maior clareza, estamos usando notação algébrica comum). A assinatura de limite ponderado (algumas chaves podem ser mais importantes que outras) poderia ser expressa como Φ = \(w_1 \cdot x_1\) + \(w_2 \cdot x_2\) + . . . + \(w_N \cdot x_N\) \(\geq wM\). E cenário onde a chave mestra corresponde a Φ = máx(\(M \cdot x\), x1 + x2 +. . . + xN) \(\geq M\). É fácil mostrar que qualquer caso sofisticado pode ser expresso com esses operadores, ou seja, eles formam a base. • Proteção por senha. A posse de uma senha secreta equivale ao conhecimento de uma chave privada, derivada deterministicamente da senha: k = KDF(s). Portanto, um receptor pode provar que conhece a senha fornecendo outra assinatura sob a chave k. O remetente simplesmente adiciona a chave pública correspondente à sua própria saída. Observe que isso método é muito mais seguro do que o “quebra-cabeça de transação” usado em Bitcoin [13], onde o a senha é passada explicitamente nas entradas. • Casos degenerados. Φ = 1 significa que qualquer pessoa pode gastar o dinheiro; Φ = 0 marca o produção como não gastável para sempre. No caso em que o script de saída combinado com as chaves públicas for muito grande para um remetente, ele pode usar um tipo de saída especial, que indica que o destinatário colocará esses dados em sua entrada enquanto o remetente fornece apenas hash dele. Esta abordagem é semelhante ao “pagar para-hash” de Bitcoin recurso, mas em vez de adicionar novos comandos de script, tratamos desse caso na estrutura de dados nível. 7 Conclusão Investigamos as principais falhas em Bitcoin e propusemos algumas soluções possíveis. Esses recursos vantajosos e nosso desenvolvimento contínuo tornam o novo sistema de dinheiro eletrônico CryptoNote um sério rival do Bitcoin, superando todos os seus garfos. 14 possibilidade de inchar o blockchain e produzir uma carga adicional nos nós. Para desencorajar participantes malévolos criem grandes blocos, introduzimos uma função de penalidade: NovaRecompensa = BaseRecompensa \(\cdot\) TamanhoPreto Minnesota −1 2 Esta regra é aplicada somente quando BlkSize é maior que o tamanho mínimo do bloco livre, que deve estar próximo do máximo (10kb, \(M_N \cdot 110\%\)). Os mineiros estão autorizados a criar blocos de “tamanho normal” e até mesmo excedê-lo com lucro quando as taxas gerais ultrapassarem a penalidade. Mas é improvável que as taxas aumentem quadraticamente diferente do valor da penalidade, então haverá um equilíbrio. 6.3 Scripts de transação CryptoNote possui um subsistema de script muito minimalista. Um remetente especifica uma expressão Φ = f (x1, x2, . . . , xn), onde n é o número de chaves públicas de destino {Pi}n eu=1. Apenas cinco binários operadores são suportados: min, max, sum, mul e cmp. Quando o destinatário gasta esse pagamento, ele produz \(0 \leq k \leq n\) assinaturas e as passa para a entrada da transação. O processo de verificação simplesmente avalia Φ com xi = 1 para verificar uma assinatura válida para a chave pública Pi e xi = 0. Um verificador aceita a prova se Φ > 0. Apesar da sua simplicidade, esta abordagem cobre todos os casos possíveis: • Assinatura Multi/Limiar. Para a assinatura múltipla “M-out-of-N” estilo Bitcoin (ou seja, o receptor deve fornecer pelo menos \(0 \leq M \leq N\) assinaturas válidas) Φ = x1+x2+. . .+xN \(\geq M\) (para maior clareza, estamos usando notação algébrica comum). A assinatura de limite ponderado (algumas chaves podem ser mais importantes que outras) poderia ser expressa como Φ = \(w_1 \cdot x_1\) + \(w_2 \cdot x_2\) + . . . + \(w_N \cdot x_N\) \(\geq wM\). E cenárioio onde a chave mestra corresponde a Φ = máx(\(M \cdot x\), x1 + x2 +. . . + xN) \(\geq M\). É fácil mostrar que qualquer caso sofisticado pode ser expresso com esses operadores, ou seja, eles formam a base. • Proteção por senha. A posse de uma senha secreta equivale ao conhecimento de uma chave privada, derivada deterministicamente da senha: k = KDF(s). Portanto, um receptor pode provar que conhece a senha fornecendo outra assinatura sob a chave k. O remetente simplesmente adiciona a chave pública correspondente à sua própria saída. Observe que isso método é muito mais seguro do que o “quebra-cabeça de transação” usado em Bitcoin [13], onde o a senha é passada explicitamente nas entradas. • Casos degenerados. Φ = 1 significa que qualquer pessoa pode gastar o dinheiro; Φ = 0 marca o produção como não gastável para sempre. No caso em que o script de saída combinado com as chaves públicas for muito grande para um remetente, ele pode usar um tipo de saída especial, que indica que o destinatário colocará esses dados em sua entrada enquanto o remetente fornece apenas hash dele. Esta abordagem é semelhante ao “pagar para-hash” de Bitcoin recurso, mas em vez de adicionar novos comandos de script, tratamos desse caso na estrutura de dados nível. 7 Conclusão Investigamos as principais falhas em Bitcoin e propusemos algumas soluções possíveis. Esses recursos vantajosos e nosso desenvolvimento contínuo tornam o novo sistema de dinheiro eletrônico CryptoNote um sério rival de Bitcoin, superando todos os seus garfos. 14 26 Isso pode ser desnecessário se pudermos descobrir uma maneira de limitar o tamanho do bloco ao longo do tempo... Isso também não pode estar correto. Eles apenas definiram "NewReward" como uma parábola voltada para cima onde o tamanho do bloco é a variável independente. Assim, a nova recompensa explode até o infinito. Se, por outro Por outro lado, a nova recompensa é Max(0,Base Reward(1-(BlkSize/Mn - 1)ˆ2)), então a nova recompensa seria uma parábola voltada para baixo com pico no tamanho do bloco = Mn, e com interceptações em Tamanho do bloco = 0 e Tamanho do bloco = 2Mn. E parece ser isso que eles estão tentando descrever. No entanto, isso não
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:
Análise
5
Não que isso importe muito quando um bilhão de pessoas no mundo vivem com menos de um dólar por
dia e não tenho esperança de participar de qualquer tipo de rede de mineração... mas uma economia
mundo impulsionado por um sistema monetário p2p com uma CPU-um-voto seria, presumivelmente, mais
justo do que um sistema impulsionado por reservas bancárias fracionárias.
Mas o protocolo do Cryptonote ainda exige 51% de usuários honestos... veja, por exemplo, o Cryptonote
fóruns onde um dos desenvolvedores, Pliskov, diz que um ataque tradicional de substituição de dados noblockchain 51% ainda pode funcionar. https://forum.cryptonote.org/viewtopic.php?f=2&t=198
Observe que você realmente não precisa de 51% de usuários honestos. Você realmente precisa de "nenhum desonesto
facção com mais de 51% do poder hashing da rede."
Vamos chamar esse chamado problema do bitcoin de “rigidez adaptativa”. A solução da Cryptonote para adaptação
rigidez é flexibilidade adaptativa nos valores dos parâmetros do protocolo. Se você precisar de tamanhos de bloco maiores,
não tem problema, a rede terá se ajustado suavemente o tempo todo.
Quer dizer,
a maneira como Bitcoin ajusta a dificuldade ao longo do tempo pode ser replicada em todo o nosso protocolo
parâmetros para que o consenso da rede não precise ser obtido para atualizar o protocolo.
Superficialmente, isso parece uma boa ideia, mas sem uma reflexão cuidadosa, um sistema auto-ajustável
sistema pode se tornar bastante imprevisível e caótico. Veremos isso mais adiante, pois o
surgem oportunidades. Os “bons” sistemas estão em algum lugar entre adaptativamente rígidos e adaptativamente
flexíveis e talvez até a própria rigidez sejam adaptativas.
Se realmente tivéssemos “uma CPU-um-voto”, então colaborando e desenvolvendo pools para chegar a 51%
seria mais difícil. Esperaríamos que todas as CPUs do mundo minerassem, a partir de telefones
à CPU integrada do seu Tesla enquanto ele está carregando.
http://en.wikipedia.org/wiki/Pareto_principle
Afirmo que o equilíbrio de Pareto é um tanto inevitável. Ou 20% do sistema
possuirá 80% das CPUs, ou 20% do sistema possuirá 80% dos ASICs. Coloco a hipótese disto porque a distribuição subjacente da riqueza na sociedade já apresenta a distribuição de Pareto,
e à medida que novos mineradores se juntam, eles são retirados dessa distribuição subjacente.
No entanto, argumento que os protocolos com uma CPU e um voto terão ROI no hardware.
Bloquear
a recompensa por nó será mais proporcional ao número de nós na rede porque
a distribuição do desempenho entre os nós será muito mais restrita. Bitcoin, por outro
Por outro lado, vê uma recompensa de bloco (por nó) mais proporcional à capacidade computacional daquele
nó. Ou seja, apenas os “grandes” ainda estão no jogo da mineração. Por outro lado,
mesmo que o princípio de Pareto ainda esteja em jogo, em um mundo de uma CPU, um voto, todos
participa da segurança da rede e ganha um pouco da receita da mineração.
Em um mundo ASIC, não é sensato equipar todos os XBox e celulares aos meus.
Em um mundo de uma CPU, um voto, é muito sensato em termos de recompensa de mineração. Como uma deliciosa consequência,
ganhar 51% dos votos é mais difícil quando há cada vez mais votos, rendendo um resultado adorável
benefício para a segurança da rede.hardware descrito anteriormente. Suponha que a taxa global hash diminua significativamente, mesmo para
por um momento, ele agora pode usar seu poder de mineração para bifurcar a corrente e gastar o dobro. Como veremos
mais adiante neste artigo, não é improvável que o evento descrito anteriormente ocorra.
2.3
Emissão irregular
Bitcoin possui uma taxa de emissão pré-determinada: cada bloco resolvido produz uma quantidade fixa de moedas.
Aproximadamente a cada quatro anos esta recompensa é reduzida pela metade. A intenção original era criar um
emissão suave limitada com decaimento exponencial, mas na verdade temos uma emissão linear por partes
função cujos pontos de interrupção podem causar problemas à infraestrutura Bitcoin.
Quando ocorre o breakpoint, os mineradores passam a receber apenas metade do valor do seu valor anterior.
recompensa. A diferença absoluta entre 12,5 e 6,25 BTC (projetada para o ano de 2020) pode
parecem toleráveis. No entanto, ao examinar a queda de 50 para 25 BTC que ocorreu em novembro
28 de 2012, pareceu inapropriado para um número significativo de membros da comunidade mineira. Figura
1 mostra uma diminuição dramática na taxa hashda rede no final de novembro, exatamente quando o
ocorreu a redução pela metade. Este evento poderia ter sido o momento perfeito para o indivíduo malévolo
descrito na seção de função proof-of-work para realizar um ataque de gastos duplos [36].
Figura 1. Bitcoin hashgráfico de taxas
(fonte: http://bitcoin.sipa.be)
2.4
Constantes codificadas
Bitcoin tem muitos limites codificados, onde alguns são elementos naturais do design original (por exemplo,
frequência de bloqueio, quantidade máxima de oferta monetária, número de confirmações), enquanto outros
parecem ser restrições artificiais. Não são tanto os limites, mas a incapacidade de mudar rapidamente
3
hardware descrito anteriormente. Suponha que a taxa global hash diminua significativamente, mesmo para
por um momento, ele agora pode usar seu poder de mineração para bifurcar a corrente e gastar o dobro. Como veremos
mais adiante neste artigo, não é improvável que o evento descrito anteriormente ocorra.
2.3
Emissão irregular
Bitcoin possui uma taxa de emissão pré-determinada: cada bloco resolvido produz uma quantidade fixa de moedas.
Aproximadamente a cada quatro anos esta recompensa é reduzida pela metade. A intenção original era criar um
emissão suave limitada com decaimento exponencial, mas na verdade temos uma emissão linear por partes
função cujos pontos de interrupção podem causar problemas à infraestrutura Bitcoin.
Quando ocorre o breakpoint, os mineradores passam a receber apenas metade do valor do seu valor anterior.
recompensa. A diferença absoluta entre 12,5 e 6,25 BTC (projetada para o ano de 2020) pode
parecem toleráveis. No entanto, ao examinar a queda de 50 para 25 BTC que ocorreu em novembro
28 de 2012, pareceu inapropriado para um número significativo de membros da comunidade mineira. Figura
1 mostra uma diminuição dramática na taxa hashda rede no final de novembro, exatamente quando o
ocorreu a redução pela metade. Este evento poderia ter sido o momento perfeito para o indivíduo malévolo
descrito na seção de função proof-of-work para realizar um ataque de gastos duplos [36].
Figura 1. Bitcoin hashgráfico de taxas
(fonte: http://bitcoin.sipa.be)
2.4
Constantes codificadas
Bitcoin tem muitos limites codificados, onde alguns são elementos naturais do design original (por exemplo,
frequência de bloqueio, quantidade máxima de oferta monetária, número de confirmações), enquanto outros
parecem ser restrições artificiais. Não são tanto os limites, mas a incapacidade de mudar rapidamente
3
6
Vamos chamar isso do que realmente é, um ataque de zumbis.
Vamos discutir como a emissão contínua pode ser
relacionado a um-cpu-um-voto em um cenário de ataque zumbi.
Em um mundo de uma CPU, um voto, todos os celulares e carros, sempre que ociosos, estariam minerando. Coletar montes de hardware barato para criar uma fazenda de mineração seria muito fácil, porque bastaria
quase tudo tem uma CPU. Por outro lado, nesse ponto, o número de CPUs
necessário para lançar um ataque de 51% seria bastante surpreendente, eu acho.
Além disso,
precisamente porque seria fácil coletar hardware barato, podemos razoavelmente esperar um
muita gente começa a acumular qualquer coisa com uma CPU. A corrida armamentista em um mundo de uma CPU, um voto
é necessariamente mais igualitário do que em um mundo ASIC.
Portanto, uma descontinuidade na rede
a segurança devido às taxas de emissão deveria ser um problema MENOS em um mundo de uma CPU, um voto.
Contudo, dois fatos permanecem: 1) a descontinuidade na taxa de emissão pode levar a um efeito de gagueira em
na economia e na segurança da rede, o que é ruim, e 2) mesmo que um ataque de 51%
executado por alguém coletando hardware barato ainda pode ocorrer em uma CPU-uma-votar mundo,
parece que deveria ser mais difícil.
Presumivelmente, a salvaguarda contra isso é que todos os atores desonestos tentarão fazer isso
simultaneamente, e voltamos à noção de segurança anterior de Bitcoin: "não exigimos nenhum comportamento desonesto
facção para controlar mais de 51% da rede."
O autor está afirmando aqui que um problema com o bitcoin é a descontinuidade na emissão de moedas
taxa poderia levar a quedas repentinas na participação na rede e, portanto, na segurança da rede. Assim,
é preferível uma taxa de emissão de moedas contínua, diferenciável e suave.
O autor não está errado, necessariamente. Qualquer tipo de diminuição repentina na participação na rede pode
levar a esse problema, e se pudermos remover uma fonte dele, deveríamos fazê-lo. Dito isto, é
possível que longos períodos de emissão de moedas "relativamente constantes" pontuados por mudanças repentinas
é o caminho ideal a seguir do ponto de vista económico. Eu não sou economista. Então, talvez nós
devemos decidir se vamos trocar a segurança da rede por algo econômico – o que há aqui?
http://arxiv.org/abs/1402.2009se necessário, o que causa as principais desvantagens. Infelizmente, é difícil prever quando
constantes podem precisar ser alteradas e substituí-las pode levar a consequências terríveis.
Um bom exemplo de alteração de limite codificada que leva a consequências desastrosas é o bloqueio
limite de tamanho definido para 250kb1. Este limite foi suficiente para realizar cerca de 10.000 transações padrão. Em
No início de 2013, esse limite estava quase alcançado e foi alcançado um acordo para aumentar o
limite. A mudança foi implementada na versão 0.8 da carteira e terminou com uma divisão da cadeia de 24 blocos
e um ataque de gasto duplo bem-sucedido [9]. Embora o bug não estivesse no protocolo Bitcoin, mas
em vez disso, no mecanismo de banco de dados, ele poderia ter sido facilmente detectado por um simples teste de estresse, se houvesse
nenhum limite de tamanho de bloco introduzido artificialmente.
As constantes também atuam como uma forma de ponto de centralização.
Apesar da natureza peer-to-peer
Bitcoin, a esmagadora maioria dos nós usa o cliente de referência oficial [10] desenvolvido por
um pequeno grupo de pessoas. Este grupo toma a decisão de implementar mudanças no protocolo
e a maioria das pessoas aceita estas mudanças independentemente da sua “correcção”. Algumas decisões causaram
discussões acaloradas e até apelos ao boicote [11], o que indica que a comunidade e o
os desenvolvedores podem discordar em alguns pontos importantes. Parece, portanto, lógico ter um protocolo
com variáveis configuráveis pelo usuário e autoajustáveis como uma possível forma de evitar esses problemas.
2,5
Scripts volumosos
O sistema de script em Bitcoin é um recurso pesado e complexo. Ele potencialmente permite criar
transações sofisticadas [12], mas alguns de seus recursos estão desativados devido a questões de segurança e
alguns nunca foram usados [13]. O script (incluindo as partes do remetente e do destinatário)
para a transação mais popular em Bitcoin é assim: