CriptoNota v2.0

CryptoNote v2.0

โดย Nicolas van Saberhagen · 2013

บทความที่นำเสนอที่นี่คือ CryptoNote v2.0 whitepaper โดย Nicolas van Saberhagen (2013) ซึ่งอธิบายรากฐานการเข้ารหัสที่ Monero สร้างขึ้นมาบน มันไม่ใช่ whitepaper เฉพาะของ Monero โดย Monero เปิดตัวในปี 2014 ในฐานะ fork ของการใช้งานอ้างอิง CryptoNote (Bytecoin) และได้พัฒนาอย่างมีนัยสำคัญเกินกว่าโปรโตคอลต้นฉบับนับแต่นั้น

🇺🇸 English (ต้นฉบับ)

🇪🇸 Español (คำแปล)

Introduction

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

Introducción

“Bitcoin” [1] ha sido una implementación exitosa del concepto de efectivo electrónico p2p. ambos Los profesionales y el público en general han llegado a apreciar la conveniente combinación de transacciones públicas y proof-of-work como modelo de confianza. Hoy en día, la base de usuarios de efectivo electrónico está creciendo a un ritmo constante; Los clientes se sienten atraídos por las tarifas bajas y el anonimato proporcionado. por el dinero electrónico y los comerciantes valoran su emisión prevista y descentralizada. Bitcoin tiene demostrado efectivamente que el efectivo electrónico puede ser tan simple como el papel moneda y tan conveniente como tarjetas de crédito. Desafortunadamente, Bitcoin sufre varias deficiencias. Por ejemplo, el sistema distribuido La naturaleza es inflexible, impidiendo la implementación de nuevas funciones hasta que casi todos los usuarios de la red actualicen sus clientes. Algunas fallas críticas que no se pueden solucionar rápidamente disuaden a Bitcoin propagación generalizada. En modelos tan inflexibles, es más eficiente implementar un nuevo proyecto en lugar de arreglar perpetuamente el proyecto original. En este artículo estudiamos y proponemos soluciones a las principales deﬁciencias de Bitcoin. creemos que un sistema que tenga en cuenta las soluciones que proponemos conducirá a una competencia sana entre diferentes sistemas de efectivo electrónico. También proponemos nuestro propio efectivo electrónico, “CryptoNote”, un nombre que enfatiza el próximo avance en efectivo electrónico.

Bitcoin Drawbacks and Possible Solutions

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

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

Bitcoin Inconvenientes y posibles soluciones

2 Bitcoin inconvenientes y algunas posibles soluciones 2.1 Trazabilidad de transacciones La privacidad y el anonimato son los aspectos más importantes del efectivo electrónico. Pagos entre pares buscan ocultarse de la vista de terceros, una clara diferencia en comparación con los tradicionales banca. En particular, T. Okamoto y K. Ohta describieron seis criterios para el efectivo electrónico ideal, que incluía “privacidad: la relación entre el usuario y sus compras debe ser imposible de rastrear por cualquiera” [30]. De su descripción, derivamos dos propiedades que un totalmente anónimo El modelo de efectivo electrónico debe cumplir para cumplir con los requisitos descritos por Okamoto. y Ohta: Irrastreabilidad: para cada transacción entrante todos los posibles remitentes son equiprobables. Desvinculación: para dos transacciones salientes es imposible demostrar que fueron enviadas a la misma persona. Desafortunadamente, Bitcoin no cumple con el requisito de imposible trazabilidad. Dado que todas las transacciones que tienen lugar entre los participantes de la red son públicas, cualquier transacción puede ser 1 CriptoNota v 2.0 Nicolas van Saberhagen 17 de octubre de 2013 1 Introducción “Bitcoin” [1] ha sido una implementación exitosa del concepto de efectivo electrónico p2p. ambos Los profesionales y el público en general han llegado a apreciar la conveniente combinación de transacciones públicas y proof-of-work como modelo de confianza. Hoy en día, la base de usuarios de efectivo electrónico está creciendo a un ritmo constante; Los clientes se sienten atraídos por las tarifas bajas y el anonimato proporcionado. por el dinero electrónico y los comerciantes valoran su emisión prevista y descentralizada. Bitcoin tiene demostrado efectivamente que el efectivo electrónico puede ser tan simple como el papel moneda y tan conveniente como tarjetas de crédito. Desafortunadamente, Bitcoin sufre varias deficiencias. Por ejemplo, el sistema distribuido La naturaleza es inflexible, impidiendo la implementación de nuevas funciones hasta que casi todos los usuarios de la red actualicen sus clientes. Algunas fallas críticas que no se pueden solucionar rápidamente disuaden a Bitcoin propagación generalizada. En modelos tan inflexibles, es más eficiente implementar un nuevo proyecto en lugar de arreglar perpetuamente el proyecto original. En este artículo estudiamos y proponemos soluciones a las principales deﬁciencias de Bitcoin. creemos que un sistema que tenga en cuenta las soluciones que proponemos conducirá a una competencia sana entre diferentes sistemas de efectivo electrónico. También proponemos nuestro propio efectivo electrónico, “CryptoNote”, un nombre que enfatiza el próximo avance en efectivo electrónico. 2 Bitcoin inconvenientes y algunas posibles soluciones 2.1 Trazabilidad de transacciones La privacidad y el anonimato son los aspectos más importantes del efectivo electrónico. Pagos entre pares buscan ocultarse de la vista de terceros, una clara diferencia en comparación con los tradicionales banca. En particular, T. Okamoto y K. Ohta describieron seis criterios para el efectivo electrónico ideal, que incluía “privacidad: la relación entre el usuario y sus compras debe ser imposible de rastrear por cualquiera” [30]. De su descripción, derivamos dos propiedades que un totalmente anónimo El modelo de efectivo electrónico debe cumplir para cumplir con los requisitos descritos por Okamoto. y Ohta: Irrastreabilidad: para cada transacción entrante todos los posibles remitentes son equiprobables. Desvinculación: para dos transacciones salientes es imposible demostrar que fueron enviadas a la misma persona. Desafortunadamente, Bitcoin no cumple con el requisito de imposible trazabilidad. Dado que todas las transacciones que tienen lugar entre los participantes de la red son públicas, cualquier transacción puede ser 1 3 Bitcoin definitivamente falla en "irrastreabilidad". Cuando te envío BTC, la billetera desde donde se envía está irrevocablemente estampado en el blockchain. No hay dudas sobre quién envió esos fondos, porque sólo el conocedor de las claves privadas puede enviarlas.rastreado inequívocamente hasta un origen único y un destinatario final. Incluso si dos participantes intercambian fondos de manera indirecta, un método de búsqueda de caminos diseñado adecuadamente revelará el origen y destinatario final. También se sospecha que Bitcoin no satisface la segunda propiedad. Algunos investigadores declaró ([33, 35, 29, 31]) que un análisis cuidadoso de blockchain puede revelar una conexión entre los usuarios de la red Bitcoin y sus transacciones. Aunque existen varios métodos en disputa [25], se sospecha que se puede extraer mucha información personal oculta del base de datos pública. El hecho de que Bitcoin no cumpla con las dos propiedades descritas anteriormente nos lleva a concluir que es no es un sistema de efectivo electrónico anónimo sino pseudoanónimo. Los usuarios desarrollaron rápidamente soluciones para superar esta deficiencia. Dos soluciones directas fueron los “servicios de lavado” [2] y el desarrollo de métodos distribuidos [3, 4]. Ambas soluciones se basan en la idea de mezclar varias transacciones públicas y enviarlas a través de alguna dirección intermediaria; que a su vez sufre el inconveniente de requerir un tercero de confianza. Recientemente, I. Miers et al. propusieron un esquema más creativo. [28]: “Ceromoneda”. Cerocoin utiliza acumuladores criptográficos unidireccionales y pruebas de conocimiento cero que permiten a los usuarios “convertir” bitcoins en zerocoins y gastarlos usando prueba anónima de propiedad en lugar de firmas digitales explícitas basadas en clave pública. Sin embargo, tales pruebas de conocimiento tienen una constante pero tamaño inconveniente: alrededor de 30 kb (según los límites actuales Bitcoin), lo que hace que la propuesta poco práctico. Los autores admiten que es poco probable que el protocolo sea aceptado alguna vez por la mayoría de los Bitcoin usuarios [5]. 2.2 La función proof-of-work El creador de Bitcoin, Satoshi Nakamoto, describió el algoritmo de toma de decisiones por mayoría como “una CPU, un voto” y utilizó una función de fijación de precios vinculada a la CPU (doble SHA-256) para su proof-of-work esquema. Dado que los usuarios votan por el historial único de transacciones orden [1], la razonabilidad y La coherencia de este proceso son condiciones críticas para todo el sistema. La seguridad de este modelo adolece de dos inconvenientes. En primer lugar, requiere el 51% de la capacidad de la red. el poder minero esté bajo el control de usuarios honestos. En segundo lugar, el progreso del sistema (corrección de errores, correcciones de seguridad, etc.) requieren que la inmensa mayoría de los usuarios apoyen y acepten las cambios (esto ocurre cuando los usuarios actualizan su software de billetera) [6]. Finalmente esta misma votación El mecanismo también se utiliza para encuestas colectivas sobre la implementación de algunas características [7]. Esto nos permite conjeturar las propiedades que debe satisfacer el proof-of-work función de fijación de precios. Esta función no debe permitir que un participante de la red tenga una influencia significativa ventaja sobre otro participante; requiere una paridad entre hardware común y alta costo de los dispositivos personalizados. De los ejemplos recientes [8], podemos ver que la función SHA-256 usó en la arquitectura Bitcoin no posee esta propiedad a medida que la minería se vuelve más eficiente en GPU y dispositivos ASIC en comparación con CPU de gama alta. Por lo tanto, Bitcoin crea condiciones favorables para una gran brecha entre el poder de voto de participantes, ya que viola el principio de "una CPU, un voto", ya que los propietarios de GPU y ASIC poseen un poder de voto mucho mayor en comparación con los propietarios de CPU. Es un ejemplo clásico de la Principio de Pareto donde el 20% de los participantes de un sistema controlan más del 80% de los votos. Se podría argumentar que tal desigualdad no es relevante para la seguridad de la red ya que no es el pequeño número de participantes controla la mayoría de los votos, pero la honestidad de estos participantes que importan. Sin embargo, tal argumento es algo defectuoso ya que es más bien la posibilidad de que aparezca hardware especializado barato en lugar de la honestidad de los participantes, que representa una amenaza. Para demostrar esto, tomemos el siguiente ejemplo. Supongamos que un malévolo El individuo obtiene un poder minero significativo al crear su propia granja minera a través del método barato. 2 rastreado inequívocamente hasta un origen único y un destinatario final. Incluso si dos participantes intercambian fondos de manera indirecta, un método de búsqueda de caminos diseñado adecuadamente revelará el origen y destinatario final. También se sospecha que Bitcoin no satisface la segunda propiedad. Algunos investigadores declaró ([33, 35, 29, 31]) que un análisis cuidadoso de blockchain puede revelar una conexión entre los usuarios de la red Bitcoin y sus transacciones. Aunque existen varios métodos recuestionado [25], se sospecha que se puede extraer mucha información personal oculta del base de datos pública. El hecho de que Bitcoin no cumpla con las dos propiedades descritas anteriormente nos lleva a concluir que es no es un sistema de efectivo electrónico anónimo sino pseudoanónimo. Los usuarios desarrollaron rápidamente soluciones para superar esta deficiencia. Dos soluciones directas fueron los “servicios de lavado” [2] y el desarrollo de métodos distribuidos [3, 4]. Ambas soluciones se basan en la idea de mezclar varias transacciones públicas y enviarlas a través de alguna dirección intermediaria; que a su vez sufre el inconveniente de requerir un tercero de confianza. Recientemente, I. Miers et al. propusieron un esquema más creativo. [28]: “Ceromoneda”. Cerocoin utiliza acumuladores criptográficos unidireccionales y pruebas de conocimiento cero que permiten a los usuarios “convertir” bitcoins en zerocoins y gastarlos usando prueba anónima de propiedad en lugar de firmas digitales explícitas basadas en clave pública. Sin embargo, tales pruebas de conocimiento tienen una constante pero tamaño inconveniente: alrededor de 30 kb (según los límites actuales Bitcoin), lo que hace que la propuesta poco práctico. Los autores admiten que es poco probable que el protocolo sea aceptado alguna vez por la mayoría de los Bitcoin usuarios [5]. 2.2 La función proof-of-work El creador de Bitcoin, Satoshi Nakamoto, describió el algoritmo de toma de decisiones por mayoría como “una CPU, un voto” y utilizó una función de fijación de precios vinculada a la CPU (doble SHA-256) para su proof-of-work esquema. Dado que los usuarios votan por el historial único de transacciones orden [1], la razonabilidad y La coherencia de este proceso son condiciones críticas para todo el sistema. La seguridad de este modelo adolece de dos inconvenientes. En primer lugar, requiere el 51% de la capacidad de la red. el poder minero esté bajo el control de usuarios honestos. En segundo lugar, el progreso del sistema (corrección de errores, correcciones de seguridad, etc.) requieren que la inmensa mayoría de los usuarios apoyen y acepten las cambios (esto ocurre cuando los usuarios actualizan su software de billetera) [6]. Finalmente esta misma votación El mecanismo también se utiliza para encuestas colectivas sobre la implementación de algunas características [7]. Esto nos permite conjeturar las propiedades que debe satisfacer el proof-of-work función de fijación de precios. Esta función no debe permitir que un participante de la red tenga una influencia significativa ventaja sobre otro participante; requiere una paridad entre hardware común y alta costo de los dispositivos personalizados. De los ejemplos recientes [8], podemos ver que la función SHA-256 usó en la arquitectura Bitcoin no posee esta propiedad a medida que la minería se vuelve más eficiente en GPU y dispositivos ASIC en comparación con CPU de gama alta. Por lo tanto, Bitcoin crea condiciones favorables para una gran brecha entre el poder de voto de participantes, ya que viola el principio de "una CPU, un voto", ya que los propietarios de GPU y ASIC poseen un poder de voto mucho mayor en comparación con los propietarios de CPU. Es un ejemplo clásico de la Principio de Pareto donde el 20% de los participantes de un sistema controlan más del 80% de los votos. Se podría argumentar que tal desigualdad no es relevante para la seguridad de la red ya que no es el pequeño número de participantes controla la mayoría de los votos, pero la honestidad de estos participantes que importan. Sin embargo, tal argumento es algo defectuoso ya que es más bien la posibilidad de que aparezca hardware especializado barato en lugar de la honestidad de los participantes, que representa una amenaza. Para demostrar esto, tomemos el siguiente ejemplo. Supongamos que un malévolo El individuo obtiene un poder minero significativo al crear su propia granja minera a través del método barato. 2 4 Presumiblemente, si cada usuario contribuye a su propio anonimato generando siempre una nueva dirección por CADA pago recibido (lo cual es absurdo pero técnicamente es la forma "correcta" de hacerlo), y si cada usuario ayudara al anonimato de los demás insistiendo en que nunca envíen fondos a la misma dirección BTC dos veces, entonces Bitcoin seguiría solo circunstancialmente pasando el prueba de desvinculación. ¿Por qué? Los datos de los consumidores se pueden utilizar para calcular una cantidad asombrosa sobre las personas todo el tiempo. Véase, por ejemplo, http://www.applieddatalabs.com/content/target-knows-it-shows Ahora, imaginemos que esto ocurre dentro de 20 años y además imaginemos que Target no sólo supiera sobre sus hábitos de compra en Target, pero habían estado extrayendo el blockchain para TODO TUS COMPRAS PERSONALES CON TU COINBASE WALLET DEL PASADO DOCE AÑOS. Dirán: "oye amigo, quizás quieras comprar un medicamento para la tos esta noche, no lo harás". Me sentiré bien mañana." Es posible que este no sea el caso si la clasificación multipartita se aprovecha correctamente. Véase, por ejemplo, estepublicación de blog: http://blog.ezyang.com/2012/07/secure-multiparty-bitcoin-anonymization/ No estoy totalmente convencido de las matemáticas de eso, pero... un papel a la vez, ¿verdad? Se necesita cita. Mientras que el protocolo Zerocoin (independiente) puede ser insuficiente, el protocolo Zerocash El protocolo parece haber implementado transacciones de 1 kb. Ese proyecto cuenta con el apoyo de los ejércitos estadounidense e israelí, por supuesto, así que quién sabe acerca de su solidez. por el otro Por otro lado, nadie quiere más que los militares poder gastar fondos sin supervisión. http://zerocash-project.org/ No estoy convencido... ver, por ejemplo, http://fc14.ifca.ai/bitcoin/papers/bitcoin14_submission_12.pdf Citando a un desarrollador de Cryptonote, Maurice Planck (presumiblemente un seudónimo) de Cryptonote foros: "Cerocoin, Zerocash. Esta es la tecnología más avanzada, debo admitir. Si, la cita Lo anterior proviene del análisis de la versión anterior del protocolo. Que yo sepa, no es 288, pero 384 bytes, pero de todos modos esta es una buena noticia. Usaron una técnica completamente nueva llamada SNARK, que tiene ciertas desventajas: por ejemplo, Gran base de datos inicial de parámetros públicos necesarios para crear una firma (más de 1 GB) y Tiempo significativo requerido para crear una transacción (más de un minuto). Finalmente, están usando un criptografía joven, que he mencionado como una idea discutible: https://forum.cryptonote.org/viewtopic.php?f= " - Maurice P. jueves 03 de abril de 2014 7:56 pm Una función que se realiza en la CPU y no es adecuada para GPU, FPGA o ASIC cálculo. El "rompecabezas" utilizado en proof-of-work se conoce como función de fijación de precios, función de costos o función de rompecabezas.

rastreado inequívocamente hasta un origen único y un destinatario final. Incluso si dos participantes intercambian fondos de manera indirecta, un método de búsqueda de caminos diseñado adecuadamente revelará el origen y destinatario final. También se sospecha que Bitcoin no satisface la segunda propiedad. Algunos investigadores declaró ([33, 35, 29, 31]) que un análisis cuidadoso de blockchain puede revelar una conexión entre los usuarios de la red Bitcoin y sus transacciones. Aunque existen varios métodos en disputa [25], se sospecha que se puede extraer mucha información personal oculta del base de datos pública. El hecho de que Bitcoin no cumpla con las dos propiedades descritas anteriormente nos lleva a concluir que es no es un sistema de efectivo electrónico anónimo sino pseudoanónimo. Los usuarios desarrollaron rápidamente soluciones para superar esta deficiencia. Dos soluciones directas fueron “servicios de lavado” [2] y el desarrollo de métodos distribuidos [3, 4]. Ambas soluciones se basan en la idea de mezclar varias transacciones públicas y enviarlas a través de alguna dirección intermediaria; que a su vez sufre el inconveniente de requerir un tercero de confianza. Recientemente, I. Miers et al. propusieron un esquema más creativo. [28]: “Ceromoneda”. Cerocoin utiliza acumuladores criptográficos unidireccionales y pruebas de conocimiento cero que permiten a los usuarios “convertir” bitcoins en zerocoins y gastarlos usando prueba anónima de propiedad en lugar de firmas digitales explícitas basadas en clave pública. Sin embargo, tales pruebas de conocimiento tienen una constante pero tamaño inconveniente: alrededor de 30 kb (según los límites actuales de Bitcoin), lo que hace que la propuesta poco práctico. Los autores admiten que es poco probable que el protocolo sea aceptado alguna vez por la mayoría de los Bitcoin usuarios [5]. 2.2 La función proof-of-work El creador de Bitcoin, Satoshi Nakamoto, describió el algoritmo de toma de decisiones por mayoría como “una CPU, un voto” y utilizó una función de fijación de precios vinculada a la CPU (doble SHA-256) para su proof-of-work esquema. Dado que los usuarios votan por el historial único de transacciones orden [1], la razonabilidad y La coherencia de este proceso son condiciones críticas para todo el sistema. La seguridad de este modelo adolece de dos inconvenientes. En primer lugar, requiere el 51% de la capacidad de la red. el poder minero esté bajo el control de usuarios honestos. En segundo lugar, el progreso del sistema (corrección de errores, correcciones de seguridad, etc.) requieren que la inmensa mayoría de los usuarios apoyen y acepten las cambios (esto ocurre cuando los usuarios actualizan su software de billetera) [6]. Finalmente esta misma votación El mecanismo también se utiliza para encuestas colectivas sobre la implementación de algunas características [7]. Esto nos permite conjeturar las propiedades que debe satisfacer el proof-of-work función de fijación de precios. Esta función no debe permitir que un participante de la red tenga una influencia significativa ventaja sobre otro participante; requiere una paridad entre hardware común y alta costo de los dispositivos personalizados. De los ejemplos recientes [8], podemos ver que la función SHA-256 usó en la arquitectura Bitcoin no posee esta propiedad a medida que la minería se vuelve más eficiente en GPU y dispositivos ASIC en comparación con CPU de gama alta. Por lo tanto, Bitcoin crea condiciones favorables para una gran brecha entre el poder de voto de participantes, ya que viola el principio de "una CPU, un voto", ya que los propietarios de GPU y ASIC poseen un poder de voto mucho mayor en comparación con los propietarios de CPU. Es un ejemplo clásico de la Principio de Pareto donde el 20% de los participantes de un sistema controlan más del 80% de los votos. Se podría argumentar que tal desigualdad no es relevante para la seguridad de la red ya que no es el pequeño número de participantes controla la mayoría de los votos, pero la honestidad de estos participantes que importan. Sin embargo, tal argumento es algo defectuoso ya que es más bien la posibilidad de que aparezca hardware especializado barato en lugar de la honestidad de los participantes, que representa una amenaza. Para demostrar esto, tomemos el siguiente ejemplo. Supongamos que un malévolo El individuo obtiene un poder minero significativo al crear su propia granja minera a través del método barato. 2 rastreado inequívocamente hasta un origen único y un destinatario final. Incluso si dos participantes intercambian fondos de manera indirecta, un método de búsqueda de caminos diseñado adecuadamente revelará el origen y destinatario final. También se sospecha que Bitcoin no satisface la segunda propiedad. Algunos investigadores declaró ([33, 35, 29, 31]) que un análisis cuidadoso de blockchain puede revelar una conexión entre los usuarios de la red Bitcoin y sus transacciones. Aunque existen varios métodos recuestionado [25], se sospecha que se puede extraer mucha información personal oculta del base de datos pública. El hecho de que Bitcoin no cumpla con las dos propiedades descritas anteriormente nos lleva a concluir que es no es un sistema de efectivo electrónico anónimo sino pseudoanónimo. Los usuarios desarrollaron rápidamente soluciones para superar esta deficiencia. Dos soluciones directas fueron “servicios de lavado” [2] y el desarrollo de métodos distribuidos [3, 4]. Ambas soluciones se basan en la idea de mezclar varias transacciones públicas y enviarlas a través de alguna dirección intermediaria; que a su vez sufre el inconveniente de requerir un tercero de confianza. Recientemente, I. Miers et al. propusieron un esquema más creativo. [28]: “Ceromoneda”. Cerocoin utiliza acumuladores criptográficos unidireccionales y pruebas de conocimiento cero que permiten a los usuarios “convertir” bitcoins en zerocoins y gastarlos usando prueba anónima de propiedad en lugar de firmas digitales explícitas basadas en clave pública. Sin embargo, tales pruebas de conocimiento tienen una constante pero tamaño inconveniente: alrededor de 30 kb (según los límites actuales de Bitcoin), lo que hace que la propuesta poco práctico. Los autores admiten que es poco probable que el protocolo sea aceptado alguna vez por la mayoría de los Bitcoin usuarios [5]. 2.2 La función proof-of-work El creador de Bitcoin, Satoshi Nakamoto, describió el algoritmo de toma de decisiones por mayoría como “una CPU, un voto” y utilizó una función de fijación de precios vinculada a la CPU (doble SHA-256) para su proof-of-work. esquema. Dado que los usuarios votan por el historial único de transacciones orden [1], la razonabilidad y La coherencia de este proceso son condiciones críticas para todo el sistema. La seguridad de este modelo adolece de dos inconvenientes. En primer lugar, requiere el 51% de la capacidad de la red. el poder minero esté bajo el control de usuarios honestos. En segundo lugar, el progreso del sistema (corrección de errores, correcciones de seguridad, etc.) requieren que la inmensa mayoría de los usuarios apoyen y acepten las cambios (esto ocurre cuando los usuarios actualizan su software de billetera) [6]. Finalmente esta misma votación El mecanismo también se utiliza para encuestas colectivas sobre la implementación de algunas características [7]. Esto nos permite conjeturar las propiedades que debe satisfacer el proof-of-work función de fijación de precios. Esta función no debe permitir que un participante de la red tenga una influencia significativa ventaja sobre otro participante; requiere una paridad entre hardware común y alta costo de los dispositivos personalizados. De los ejemplos recientes [8], podemos ver que la función SHA-256 usó en la arquitectura Bitcoin no posee esta propiedad a medida que la minería se vuelve más eficiente en GPU y dispositivos ASIC en comparación con CPU de gama alta. Por lo tanto, Bitcoin crea condiciones favorables para una gran brecha entre el poder de voto de participantes, ya que viola el principio de "una CPU, un voto", ya que los propietarios de GPU y ASIC poseen un poder de voto mucho mayor en comparación con los propietarios de CPU. Es un ejemplo clásico de la Principio de Pareto donde el 20% de los participantes de un sistema controlan más del 80% de los votos. Se podría argumentar que tal desigualdad no es relevante para la seguridad de la red ya que no es el pequeño número de participantes controla la mayoría de los votos, pero la honestidad de estos participantes que importan. Sin embargo, tal argumento es algo defectuoso ya que es más bien la posibilidad de que aparezca hardware especializado barato en lugar de la honestidad de los participantes, que representa una amenaza. Para demostrar esto, tomemos el siguiente ejemplo. Supongamos que un malévolo El individuo obtiene un poder minero significativo al crear su propia granja minera a través del método barato. 2 Comentarios en la página 2

The CryptoNote Technology

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

La tecnología CryptoNote

Ahora que hemos cubierto las limitaciones de la tecnología Bitcoin, nos concentraremos en presentando las características de CryptoNote.

Untraceable Transactions

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Transacciones imposibles de rastrear

En esta sección proponemos un esquema de transacciones totalmente anónimas que satisfacen tanto la trazabilidad y condiciones de desvinculación. Una característica importante de nuestra solución es su autonomía: el remitente no está obligado a cooperar con otros usuarios o un tercero de confianza para realizar sus transacciones; por lo tanto, cada participante produce un tráfico de cobertura de forma independiente. 4.1 Revisión de la literatura Nuestro esquema se basa en la primitiva criptográfica llamada firma de grupo. Presentado por primera vez por D. Chaum y E. van Heyst [19], permite al usuario firmar su mensaje en nombre del grupo. Después de firmar el mensaje, el usuario proporciona (para fines de verificación) no su propia información pública 1Este es el llamado “límite suave”, la restricción de referencia del cliente para crear nuevos bloques. Máximo duro de El tamaño de bloque posible era 1 MB. 4 ellos si es necesario que causa los principales inconvenientes. Desafortunadamente, es difícil predecir cuándo Es posible que sea necesario cambiar las constantes y reemplazarlas puede tener consecuencias terribles. Un buen ejemplo de un cambio de límite codificado que conduce a consecuencias desastrosas es el bloque límite de tamaño establecido en 250kb1. Este límite era suficiente para albergar unas 10.000 transacciones estándar. en A principios de 2013, este límite casi se había alcanzado y se llegó a un acuerdo para aumentar el límite. El cambio se implementó en la versión 0.8 de la billetera y terminó con una división de la cadena de 24 bloques. y un exitoso ataque de doble gasto [9]. Si bien el error no estaba en el protocolo Bitcoin, pero más bien, en el motor de la base de datos, podría haberse detectado fácilmente mediante una simple prueba de estrés si hubiera No hay límite de tamaño de bloque introducido artificialmente. Las constantes también actúan como una forma de punto de centralización. A pesar de la naturaleza de igual a igual de Bitcoin, una abrumadora mayoría de nodos utilizan el cliente de referencia oficial [10] desarrollado por un pequeño grupo de personas. Este grupo toma la decisión de implementar cambios al protocolo y la mayoría de la gente acepta estos cambios independientemente de su “corrección”. Algunas decisiones provocaron discusiones acaloradas e incluso llamados al boicot [11], lo que indica que la comunidad y el Los desarrolladores pueden no estar de acuerdo en algunos puntos importantes. Por tanto, parece lógico disponer de un protocolo con variables configurables por el usuario y autoajustables como una posible forma de evitar estos problemas. 2.5 Guiones voluminosos El sistema de secuencias de comandos en Bitcoin es una característica pesada y compleja. Potencialmente permite crear transacciones sofisticadas [12], pero algunas de sus funciones están deshabilitadas debido a problemas de seguridad y algunos ni siquiera se han utilizado [13]. El guión (incluidas las partes del remitente y del receptor) para la transacción más popular en Bitcoin se ve así: OP DUP OP HASH160 OP EQUALVERIFY OP CHECKSIG. El script tiene una longitud de 164 bytes y su único propósito es comprobar si el receptor posee la clave secreta requerida para verificar su firma. 3 La tecnología CryptoNote Ahora que hemos cubierto las limitaciones de la tecnología Bitcoin, nos concentraremos en presentando las características de CryptoNote. 4 Transacciones imposibles de rastrear En esta sección proponemos un esquema de transacciones totalmente anónimas que satisfacen tanto la trazabilidad y condiciones de desvinculación. Una característica importante de nuestra solución es su autonomía: el remitente no está obligado a cooperar con otros usuarios o un tercero de confianza para realizar sus transacciones; por lo tanto, cada participante produce un tráfico de cobertura de forma independiente. 4.1 Revisión de la literatura Nuestro esquema se basa en la primitiva criptográfica llamada firma de grupo. Presentado por primera vez por D. Chaum y E. van Heyst [19], permite al usuario firmar su mensaje en nombre del grupo. Después de firmar el mensaje, el usuario proporciona (para fines de verificación) no su propia información pública 1Este es el llamado “límite suave”, la restricción de referencia del cliente para crear nuevos bloques. Máximo duro de El tamaño de bloque posible era 1 MB. 4 7 En retrospectiva, parece haber sido un gran error hacer que el tamaño del bloque sea un límite fijo en el código. Visa y Mastercard pueden procesar miles, si no cientos de miles, de transacciones por segundo. Sin embargo, las transacciones se producen en un proceso estocástico, a veces en ráfagas masivas, a veces estar en silencio durante horas. Piense en el volumen del intercambio de bitcoins. Parece una gran idea diseñar un sistema que aumente el tamaño del bloque dinámicamente cuando sea necesario. para acomodar el mayor tráfico de transacciones y disminuirlo dinámicamente cuando sea necesario aumentar la eficiencia del ancho de banda. Ahora, aplique esa noción a todos los parámetros del sistema. Y mientras tengamos cuidado de mantener el sistema se salga de control, este shFuncionaría muy bien. https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki Como se mencionó anteriormente, si las variables se autoajustan, se deben imponer algunos controles para evitar que el sistema se salga de control. Llegaremos a eso. Si se tratara de un artículo de Wikipedia, tendría la etiqueta "STUB". Aunque ciertamente estamos en el sección que presenta los "Problemas de Bitcoin", me gustaría obtener más detalles aquí. ¿Por qué es ¿164 bytes son inaceptables para una simple tarea de "comprobar la clave secreta"? ¿Qué tan pequeños pueden llegar a ser? ¿Un lenguaje de programación razonable? Aunque no soy un informático. http://download.springer.com/static/pdf/412/chp%253A10.1007%252F3-540-46416-6_22.pdf?auth66=140 Las firmas de grupo, como se describe, requieren un administrador de grupo. El administrador del grupo es capaz de revocar el anonimato de cualquier firmante. Por lo tanto, existe una centralización incorporada en un grupo. esquema de firma.

clave, sino las claves de todos los usuarios de su grupo. Un verificador está convencido de que el verdadero firmante es un miembro del grupo, pero no puede identificar exclusivamente al firmante. El protocolo original requería un tercero de confianza (llamado Gerente de Grupo), y él era el único que podía rastrear al firmante. Se introdujo la siguiente versión llamada firma de anillo. por Rivest et al. en [34], era un esquema autónomo sin Gerente de Grupo y anonimato revocación. Posteriormente aparecieron varias modificaciones de este esquema: firma de anillo enlazable [26, 27, 17] permitió determinar si dos firmas fueron producidas por el mismo miembro del grupo, rastreables La firma en anillo [24, 23] limitó el anonimato excesivo al brindar la posibilidad de rastrear al firmante de dos mensajes con respecto a la misma metainformación (o “etiqueta” en términos de [24]). Una construcción criptográfica similar también se conoce como firma de grupo ad-hoc [16, 38]. eso enfatiza la formación arbitraria de grupos, mientras que los esquemas de firma de grupo/anillo implican más bien una conjunto fijo de miembros. En su mayor parte, nuestra solución se basa en el trabajo “Firma de anillo rastreable” de E. Fujisaki. y K. Suzuki [24]. Para distinguir el algoritmo original y nuestra modificación, Llame a este último firma de anillo de una sola vez, enfatizando la capacidad del usuario para producir solo una firma válida. firma bajo su clave privada. Debilitamos la propiedad de trazabilidad y mantuvimos la vinculabilidad. sólo para proporcionar unicidad: la clave pública puede aparecer en muchos conjuntos de verificación externos y la La clave privada se puede utilizar para generar una firma anónima única. En caso de un doble gasto Intento, estas dos firmas se vincularán entre sí, pero no es necesario revelar el firmante. para nuestros propósitos. 4.2 Definiciones 4.2.1 Parámetros de la curva elíptica Como nuestro algoritmo de firma base elegimos utilizar el esquema rápido EdDSA, que está desarrollado y implementado por D.J. Bernstein et al. [18]. Al igual que la ECDSA de Bitcoin, se basa en la curva elíptica problema de logaritmo discreto, por lo que nuestro esquema también podría aplicarse a Bitcoin en el futuro. Los parámetros comunes son: q: un número primo; q = 2255 −19; d: un elemento de Fq; re = −121665/121666; E: una ecuación de curva elíptica; −x2 + y2 = 1 + dx2y2; G: un punto base; GRAMO = (x, −4/5); l: orden primo del punto base; l = 2252 + 27742317777372353535851937790883648493; \(H_s\): una función criptográfica hash \(\{0, 1\}^* \to \mathbb{F}_q\); \(H_p\): una función determinista hash \(E(\mathbb{F}_q) \to E(\mathbb{F}_q)\). 4.2.2 Terminología La privacidad mejorada requiere una nueva terminología que no debe confundirse con Bitcoin entidades. la clave electrónica privada es una clave privada de curva elíptica estándar: un número \(a \in [1, l - 1]\); La clave electrónica pública es una clave pública de curva elíptica estándar: un punto A = aG; el par de claves de un solo uso es un par de claves electrónicas públicas y privadas; 5 clave, sino las claves de todos los usuarios de su grupo. Un verificador está convencido de que el verdadero firmante es un miembro del grupo, pero no puede identificar exclusivamente al firmante. El protocolo original requería un tercero de confianza (llamado Gerente de Grupo), y él era el único que podía rastrear al firmante. Se introdujo la siguiente versión llamada firma de anillo. por Rivest et al. en [34], era un esquema autónomo sin Gerente de Grupo y anonimato revocación. Posteriormente aparecieron varias modificaciones de este esquema: firma de anillo enlazable [26, 27, 17] permitió determinar si dos firmas fueron producidas por el mismo miembro del grupo, rastreables La firma en anillo [24, 23] limitó el anonimato excesivo al brindar la posibilidad de rastrear al firmante de dos mensajes con respecto a la misma metainformación (o “etiqueta” en términos de [24]). Una construcción criptográfica similar también se conoce como firma de grupo ad-hoc [16, 38]. eso enfatiza la formación arbitraria de grupos, mientras que los esquemas de firma de grupo/anillo implican más bien una conjunto fijo de miembros. En su mayor parte, nuestra solución se basa en el trabajo “Firma de anillo rastreable” de E. Fujisaki. y K. Suzuki [24]. Para distinguir el algoritmo original y nuestra modificación, Llame a este último firma de anillo de una sola vez, enfatizando la capacidad del usuario para producir solo una firma válida. firma bajo su clave privada. Debilitamos la propiedad de trazabilidad y mantuvimos la vinculabilidad. sólo para proporcionar unicidad: la clave pública puede aparecer en muchos conjuntos de verificación externos y la La clave privada se puede utilizar para generar una firma anónima única. En caso de un doble gasto Intento, estas dos firmas se vincularán entre sí, pero no es necesario revelar el firmante. para nuestros propósitos. 4.2 Definiciones 4.2.1 Parámetros de la curva elíptica Como nuestro algoritmo de firma base elegimose utilizar el esquema rápido EdDSA, que está desarrollado y implementado por D.J. Bernstein et al. [18]. Al igual que ECDSA de Bitcoin, se basa en la curva elíptica problema de logaritmo discreto, por lo que nuestro esquema también podría aplicarse a Bitcoin en el futuro. Los parámetros comunes son: q: un número primo; q = 2255 −19; d: un elemento de Fq; re = −121665/121666; E: una ecuación de curva elíptica; −x2 + y2 = 1 + dx2y2; G: un punto base; GRAMO = (x, −4/5); l: orden primo del punto base; l = 2252 + 27742317777372353535851937790883648493; \(H_s\): una función criptográfica hash \(\{0, 1\}^* \to \mathbb{F}_q\); \(H_p\): una función determinista hash \(E(\mathbb{F}_q) \to E(\mathbb{F}_q)\). 4.2.2 Terminología La privacidad mejorada requiere una nueva terminología que no debe confundirse con Bitcoin entidades. la clave electrónica privada es una clave privada de curva elíptica estándar: un número \(a \in [1, l - 1]\); La clave electrónica pública es una clave pública de curva elíptica estándar: un punto A = aG; el par de claves de un solo uso es un par de claves electrónicas públicas y privadas; 5 8 Una firma en anillo funciona así: Alex quiere filtrar un mensaje a WikiLeaks sobre su empleador. Cada empleado de su empresa tiene un par de claves pública y privada (Ri, Ui). ella compone su firma con entrada configurada como su mensaje, m, su clave privada, Ri, y la de TODOS claves públicas, (Ui;i=1...n). Cualquiera (sin conocer ninguna clave privada) puede verificar fácilmente que algún par (Rj, Uj) debe haber sido usado para construir la firma... alguien que trabaja para el empleador de Alex... pero es esencialmente una suposición aleatoria determinar cuál podría 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 Tenga en cuenta que una firma de anillo vinculable que se describe aquí es algo así como lo opuesto a "no vinculable". descrito anteriormente. Aquí interceptamos dos mensajes y podemos determinar si son los mismos. parte los envió, aunque aún no deberíamos poder determinar quién es esa parte. el La definición de "desvinculable" utilizada para construir Cryptonote significa que no podemos determinar si el mismo partido los está recibiendo. Por lo tanto, lo que realmente tenemos aquí son CUATRO cosas sucediendo. Un sistema puede ser enlazable o no vinculable, dependiendo de si es posible o no determinar si el remitente del dos mensajes son iguales (independientemente de si para ello es necesario revocar el anonimato). y un sistema puede ser desvinculable o no desvinculable, dependiendo de si es posible o no determinar si el receptor de dos mensajes es el mismo (independientemente de si esto requiere revocar el anonimato). Por favor, no me culpen por esta terrible terminología. Los teóricos de grafos probablemente deberían estar contento. Algunos de ustedes pueden sentirse más cómodos con "enlazable por receptor" versus "enlazable por remitente". http://link.springer.com/chapter/10.1007/978-3-540-71677-8_13 Cuando leí esto, me pareció una característica tonta. Luego leí que puede ser una característica para votación electrónica, y eso parecía tener sentido. Algo genial, desde esa perspectiva. pero yo soy No estoy totalmente seguro de implementar intencionalmente firmas de anillo rastreables. http://search.ieice.org/bin/summary.php?id=e95-a_1_151

clave, sino las claves de todos los usuarios de su grupo. Un verificador está convencido de que el verdadero firmante es un miembro del grupo, pero no puede identificar exclusivamente al firmante. El protocolo original requería un tercero de confianza (llamado Gerente de Grupo), y él era el único que podía rastrear al firmante. Se introdujo la siguiente versión llamada firma de anillo. por Rivest et al. en [34], era un esquema autónomo sin Gerente de Grupo y anonimato revocación. Posteriormente aparecieron varias modificaciones de este esquema: firma de anillo enlazable [26, 27, 17] permitió determinar si dos firmas fueron producidas por el mismo miembro del grupo, rastreables La firma en anillo [24, 23] limitó el anonimato excesivo al brindar la posibilidad de rastrear al firmante de dos mensajes con respecto a la misma metainformación (o “etiqueta” en términos de [24]). Una construcción criptográfica similar también se conoce como firma de grupo ad-hoc [16, 38]. eso enfatiza la formación arbitraria de grupos, mientras que los esquemas de firma de grupo/anillo implican más bien una conjunto fijo de miembros. En su mayor parte, nuestra solución se basa en el trabajo “Firma de anillo rastreable” de E. Fujisaki. y K. Suzuki [24]. Para distinguir el algoritmo original y nuestra modificación, Llame a este último firma de anillo de una sola vez, enfatizando la capacidad del usuario para producir solo una firma válida. firma bajo su clave privada. Debilitamos la propiedad de trazabilidad y mantuvimos la vinculabilidad. sólo para proporcionar unicidad: la clave pública puede aparecer en muchos conjuntos de verificación externos y la La clave privada se puede utilizar para generar una firma anónima única. En caso de un doble gasto Intento, estas dos firmas se vincularán entre sí, pero no es necesario revelar el firmante. para nuestros propósitos. 4.2 Definiciones 4.2.1 Parámetros de la curva elíptica Como nuestro algoritmo de firma base elegimos utilizar el esquema rápido EdDSA, que está desarrollado y implementado por D.J. Bernstein et al. [18]. Al igual que ECDSA de Bitcoin, se basa en la curva elíptica problema de logaritmo discreto, por lo que nuestro esquema también podría aplicarse a Bitcoin en el futuro. Los parámetros comunes son: q: un número primo; q = 2255 −19; d: un elemento de Fq; re = −121665/121666; E: una ecuación de curva elíptica; −x2 + y2 = 1 + dx2y2; G: un punto base; GRAMO = (x, −4/5); l: orden primo del punto base; l = 2252 + 27742317777372353535851937790883648493; \(H_s\): una función criptográfica hash \(\{0, 1\}^* \to \mathbb{F}_q\); \(H_p\): una función determinista hash \(E(\mathbb{F}_q) \to E(\mathbb{F}_q)\). 4.2.2 Terminología La privacidad mejorada requiere una nueva terminología que no debe confundirse con Bitcoin entidades. la clave electrónica privada es una clave privada de curva elíptica estándar: un número \(a \in [1, l - 1]\); La clave electrónica pública es una clave pública de curva elíptica estándar: un punto A = aG; el par de claves de un solo uso es un par de claves electrónicas públicas y privadas; 5 clave, sino las claves de todos los usuarios de su grupo. Un verificador está convencido de que el verdadero firmante es un miembro del grupo, pero no puede identificar exclusivamente al firmante. El protocolo original requería un tercero de confianza (llamado Gerente de Grupo), y él era el único que podía rastrear al firmante. Se introdujo la siguiente versión llamada firma de anillo. por Rivest et al. en [34], era un esquema autónomo sin Gerente de Grupo y anonimato revocación. Posteriormente aparecieron varias modificaciones de este esquema: firma de anillo enlazable [26, 27, 17] permitió determinar si dos firmas fueron producidas por el mismo miembro del grupo, rastreables La firma en anillo [24, 23] limitó el anonimato excesivo al brindar la posibilidad de rastrear al firmante de dos mensajes con respecto a la misma metainformación (o “etiqueta” en términos de [24]). Una construcción criptográfica similar también se conoce como firma de grupo ad-hoc [16, 38]. eso enfatiza la formación arbitraria de grupos, mientras que los esquemas de firma de grupo/anillo implican más bien una conjunto fijo de miembros. En su mayor parte, nuestra solución se basa en el trabajo “Firma de anillo rastreable” de E. Fujisaki. y K. Suzuki [24]. Para distinguir el algoritmo original y nuestra modificación, Llame a este último firma de anillo de una sola vez, enfatizando la capacidad del usuario para producir solo una firma válida. firma bajo su clave privada. Debilitamos la propiedad de trazabilidad y mantuvimos la vinculabilidad. sólo para proporcionar unicidad: la clave pública puede aparecer en muchos conjuntos de verificación externos y la La clave privada se puede utilizar para generar una firma anónima única. En caso de un doble gasto Intento, estas dos firmas se vincularán entre sí, pero no es necesario revelar el firmante. para nuestros propósitos. 4.2 Definiciones 4.2.1 Parámetros de la curva elíptica Como nuestro algoritmo de firma base elegimose utilizar el esquema rápido EdDSA, que está desarrollado y implementado por D.J. Bernstein et al. [18]. Al igual que la ECDSA de Bitcoin, se basa en la curva elíptica problema de logaritmo discreto, por lo que nuestro esquema también podría aplicarse a Bitcoin en el futuro. Los parámetros comunes son: q: un número primo; q = 2255 −19; d: un elemento de Fq; re = −121665/121666; E: una ecuación de curva elíptica; −x2 + y2 = 1 + dx2y2; G: un punto base; GRAMO = (x, −4/5); l: orden primo del punto base; l = 2252 + 27742317777372353535851937790883648493; \(H_s\): una función criptográfica hash \(\{0, 1\}^* \to \mathbb{F}_q\); \(H_p\): una función determinista hash \(E(\mathbb{F}_q) \to E(\mathbb{F}_q)\). 4.2.2 Terminología La privacidad mejorada requiere una nueva terminología que no debe confundirse con Bitcoin entidades. la clave electrónica privada es una clave privada de curva elíptica estándar: un número \(a \in [1, l - 1]\); La clave electrónica pública es una clave pública de curva elíptica estándar: un punto A = aG; el par de claves de un solo uso es un par de claves electrónicas públicas y privadas; 5 9 ¡Dios, el autor de este documento técnico seguramente podría haberlo redactado mejor! Digamos que un empresa propiedad de los empleados quiere votar sobre si adquirir o no ciertas nuevas activos, y Alex y Brenda son ambos empleados. La Compañía proporciona a cada empleado un mensaje como "¡Voto sí a la Proposición A!" que tiene el "problema" de metainformación [PROP A] y les pide que lo firmen con un anillo de firma rastreable si apoyan la propuesta. Usando una firma de anillo tradicional, un empleado deshonesto puede firmar el mensaje varias veces, presumiblemente con diferentes nonces, para poder votar tantas veces como quieran. por el otro Por otro lado, en un esquema de firma de anillo rastreable, Alex irá a votar y su clave privada tendrá utilizado en el tema [PROP A]. Si Alex intenta firmar un mensaje como "Yo, Brenda, apruebo ¡proposición A!" para "incriminar" a Brenda y doble voto, este nuevo mensaje también tendrá el tema [PROPUESTA A]. Dado que la clave privada de Alex ya ha provocado el problema [PROP A], la identidad de Alex será inmediatamente revelado como un fraude. Lo cual, acéptalo, ¡es genial! La criptografía impuso la igualdad de votos. http://link.springer.com/chapter/10.1007/978-3-540-71677-8_13 Este artículo es interesante, esencialmente crea una firma de anillo ad-hoc pero sin ninguno de los el consentimiento del otro participante. La estructura de la firma puede ser diferente; no he cavado profundo, y no he visto si es seguro. https://people.csail.mit.edu/rivest/AdidaHohenbergerRivest-AdHocGroupSignaturesFromHijackedKeypai Las firmas de grupos ad hoc son: firmas de anillo, que son firmas de grupo sin grupo gerentes, sin centralización, pero permite que un miembro de un grupo ad hoc afirme de manera demostrable que (no) ha emitido la firma anónima en nombre del grupo. http://link.springer.com/chapter/10.1007/11908739_9 Esto no es del todo correcto, según tengo entendido. Y mi comprensión probablemente cambiará a medida que Profundizo más en este proyecto. Pero, según tengo entendido, la jerarquía se ve así. Firmas de grupo: los administradores de grupo controlan la trazabilidad y la capacidad de agregar o eliminar miembros. de ser firmantes. Firmas de anillo: formación arbitraria de grupos sin responsable de grupo. Sin revocación del anonimato. No hay forma de repudiarse de una firma determinada. Con anillo rastreable y enlazable firmas, el anonimato es algo escalable. Firmas de grupos ad hoc: como firmas de anillo, pero los miembros pueden demostrar que no crearon una firma determinada. Esto es importante cuando cualquier miembro de un grupo puede emitir una firma. http://link.springer.com/chapter/10.1007/978-3-540-71677-8_13 El autor modifica posteriormente el algoritmo de Fujisaki y Suzuki para proporcionar unicidad. entonces Analizaremos el algoritmo de Fujisaki y Suzuki al mismo tiempo que el nuevo algoritmo en lugar de que repasarlo aquí.

clave, sino las claves de todos los usuarios de su grupo. Un verificador está convencido de que el verdadero firmante es un miembro del grupo, pero no puede identificar exclusivamente al firmante. El protocolo original requería un tercero de confianza (llamado Gerente de Grupo), y él era el único que podía rastrear al firmante. Se introdujo la siguiente versión llamada firma de anillo. por Rivest et al. en [34], era un esquema autónomo sin Gerente de Grupo y anonimato revocación. Posteriormente aparecieron varias modificaciones de este esquema: firma de anillo enlazable [26, 27, 17] permitió determinar si dos firmas fueron producidas por el mismo miembro del grupo, rastreables La firma en anillo [24, 23] limitó el anonimato excesivo al brindar la posibilidad de rastrear al firmante de dos mensajes con respecto a la misma metainformación (o “etiqueta” en términos de [24]). Una construcción criptográfica similar también se conoce como firma de grupo ad-hoc [16, 38]. eso enfatiza la formación arbitraria de grupos, mientras que los esquemas de firma de grupo/anillo implican más bien una conjunto fijo de miembros. En su mayor parte, nuestra solución se basa en el trabajo “Firma de anillo rastreable” de E. Fujisaki. y K. Suzuki [24]. Para distinguir el algoritmo original y nuestra modificación, Llame a este último firma de anillo de una sola vez, enfatizando la capacidad del usuario para producir solo una firma válida. firma bajo su clave privada. Debilitamos la propiedad de trazabilidad y mantuvimos la vinculabilidad. sólo para proporcionar unicidad: la clave pública puede aparecer en muchos conjuntos de verificación externos y la La clave privada se puede utilizar para generar una firma anónima única. En caso de un doble gasto Intento, estas dos firmas se vincularán entre sí, pero no es necesario revelar el firmante. para nuestros propósitos. 4.2 Definiciones 4.2.1 Parámetros de la curva elíptica Como nuestro algoritmo de firma base elegimos utilizar el esquema rápido EdDSA, que está desarrollado y implementado por D.J. Bernstein et al. [18]. Al igual que la ECDSA de Bitcoin, se basa en la curva elíptica problema de logaritmo discreto, por lo que nuestro esquema también podría aplicarse a Bitcoin en el futuro. Los parámetros comunes son: q: un número primo; q = 2255 −19; d: un elemento de Fq; re = −121665/121666; E: una ecuación de curva elíptica; −x2 + y2 = 1 + dx2y2; G: un punto base; GRAMO = (x, −4/5); l: orden primo del punto base; l = 2252 + 27742317777372353535851937790883648493; \(H_s\): una función criptográfica hash \(\{0, 1\}^* \to \mathbb{F}_q\); \(H_p\): una función determinista hash \(E(\mathbb{F}_q) \to E(\mathbb{F}_q)\). 4.2.2 Terminología La privacidad mejorada requiere una nueva terminología que no debe confundirse con Bitcoin entidades. la clave electrónica privada es una clave privada de curva elíptica estándar: un número \(a \in [1, l - 1]\); La clave electrónica pública es una clave pública de curva elíptica estándar: un punto A = aG; el par de claves de un solo uso es un par de claves electrónicas públicas y privadas; 5 clave, sino las claves de todos los usuarios de su grupo. Un verificador está convencido de que el verdadero firmante es un miembro del grupo, pero no puede identificar exclusivamente al firmante. El protocolo original requería un tercero de confianza (llamado Gerente de Grupo), y él era el único que podía rastrear al firmante. Se introdujo la siguiente versión llamada firma de anillo. por Rivest et al. en [34], era un esquema autónomo sin Gerente de Grupo y anonimato revocación. Posteriormente aparecieron varias modificaciones de este esquema: firma de anillo enlazable [26, 27, 17] permitió determinar si dos firmas fueron producidas por el mismo miembro del grupo, rastreables La firma en anillo [24, 23] limitó el anonimato excesivo al brindar la posibilidad de rastrear al firmante de dos mensajes con respecto a la misma metainformación (o “etiqueta” en términos de [24]). Una construcción criptográfica similar también se conoce como firma de grupo ad-hoc [16, 38]. eso enfatiza la formación arbitraria de grupos, mientras que los esquemas de firma de grupo/anillo implican más bien una conjunto fijo de miembros. En su mayor parte, nuestra solución se basa en el trabajo “Firma de anillo rastreable” de E. Fujisaki. y K. Suzuki [24]. Para distinguir el algoritmo original y nuestra modificación, Llame a este último firma de anillo de una sola vez, enfatizando la capacidad del usuario para producir solo una firma válida. firma bajo su clave privada. Debilitamos la propiedad de trazabilidad y mantuvimos la vinculabilidad. sólo para proporcionar unicidad: la clave pública puede aparecer en muchos conjuntos de verificación externos y la La clave privada se puede utilizar para generar una firma anónima única. En caso de un doble gasto Intento, estas dos firmas se vincularán entre sí, pero no es necesario revelar el firmante. para nuestros propósitos. 4.2 Definiciones 4.2.1 Parámetros de la curva elíptica Como nuestro algoritmo de firma base elegimose utilizar el esquema rápido EdDSA, que está desarrollado y implementado por D.J. Bernstein et al. [18]. Al igual que ECDSA de Bitcoin, se basa en la curva elíptica problema de logaritmo discreto, por lo que nuestro esquema también podría aplicarse a Bitcoin en el futuro. Los parámetros comunes son: q: un número primo; q = 2255 −19; d: un elemento de Fq; re = −121665/121666; E: una ecuación de curva elíptica; −x2 + y2 = 1 + dx2y2; G: un punto base; GRAMO = (x, −4/5); l: orden primo del punto base; l = 2252 + 27742317777372353535851937790883648493; \(H_s\): una función criptográfica hash \(\{0, 1\}^* \to \mathbb{F}_q\); \(H_p\): una función determinista hash \(E(\mathbb{F}_q) \to E(\mathbb{F}_q)\). 4.2.2 Terminología La privacidad mejorada requiere una nueva terminología que no debe confundirse con Bitcoin entidades. la clave electrónica privada es una clave privada de curva elíptica estándar: un número \(a \in [1, l - 1]\); La clave electrónica pública es una clave pública de curva elíptica estándar: un punto A = aG; el par de claves de un solo uso es un par de claves electrónicas públicas y privadas; 5 10 La vinculabilidad en el sentido de "firmas de anillo vinculables" significa que podemos saber si dos transacciones salientes provienen de la misma fuente sin revelar quién es la fuente. Los autores debilitaron vinculabilidad para (a) preservar la privacidad, pero aún así (b) detectar cualquier transacción que utilice una clave privada por segunda vez como inválido. Bien, esta es una pregunta de orden de eventos. Considere el siguiente escenario. mi mineria La computadora tendrá el blockchain actual, tendrá su propio bloque de transacciones al que llama. legítimo, trabajará en ese bloque en un rompecabezas proof-of-work y tendrá un lista de transacciones pendientes que se agregarán al siguiente bloque. También enviará cualquier novedad. transacciones en ese grupo de transacciones pendientes. Si no resuelvo el siguiente bloque, pero Si alguien más lo hace, obtengo una copia actualizada del blockchain. El bloque en el que estaba trabajando y mi lista de transacciones pendientes ambas pueden tener algunas transacciones que ahora están incorporadas en el blockchain. Desentraña mi bloque pendiente, combínalo con mi lista de transacciones pendientes y llámalo mi grupo de transacciones pendientes. Elimine cualquiera que ahora esté oficialmente en el blockchain. Ahora, ¿qué hago? ¿Debería primero proceder y "eliminar todos los gastos dobles"? por el otro Por otro lado, ¿debería buscar en la lista y asegurarme de que cada clave privada aún no haya sido utilizado, y si ya se ha utilizado en mi lista, entonces recibí la primera copia primero, y por lo tanto cualquier copia adicional es ilegítima. Por lo tanto procedo a simplemente eliminar todas las instancias después de la primera de la misma clave privada. La geometría algebraica nunca ha sido mi fuerte. http://en.wikipedia.org/wiki/EdDSA Qué velocidad, guau. ESTA es la geometría algebraica para ganar. No es que yo supiera nada sobre eso. De manera problemática o no, los registros discretos se están volviendo muy rápidos. Y las computadoras cuánticas se los comen para el desayuno. http://link.springer.com/article/10.1007/s13389-012-0027-1 Este se convierte en un número realmente importante, pero no hay ninguna explicación o cita de cómo fue elegido. Simplemente elegir un único primo grande conocido estaría bien, pero si se conocen Hay datos sobre este gran número primo que podrían influir en nuestra elección. Diferentes variantes de criptonota podría elegir diferentes valores de bien, pero no hay ninguna discusión en este artículo sobre cómo eso La elección afectará nuestras elecciones de otros parámetros globales enumerados en la página 5. Este documento necesita una sección sobre la elección de valores de parámetros.

la clave de usuario privada es un par (a, b) de dos claves electrónicas privadas diferentes; la clave de seguimiento es un par (a, B) de clave electrónica pública y privada (donde B = bG y a ̸= b); la clave pública de usuario es un par (A, B) de dos claves electrónicas públicas derivadas de (a, b); La dirección estándar es una representación de una clave de usuario pública dada en una cadena amigable para los humanos. con corrección de errores; La dirección truncada es una representación de la segunda mitad (punto B) de una clave de usuario pública dada. en una cadena amigable para los humanos con corrección de errores. La estructura de la transacción sigue siendo similar a la estructura en Bitcoin: cada usuario puede elegir varios pagos entrantes independientes (transacciones salidas), firmarlos con el correspondiente claves privadas y enviarlas a diferentes destinos. Contrariamente al modelo de Bitcoin, donde un usuario posee una clave pública y privada única, en el En el modelo propuesto, el remitente genera una clave pública única basada en la dirección del destinatario y algunos datos aleatorios. En este sentido, una transacción entrante para el mismo destinatario se envía a un clave pública de un solo uso (no directamente a una dirección única) y solo el destinatario puede recuperar la parte privada correspondiente para canjear sus fondos (usando su clave privada única). El destinatario puede gastar los fondos utilizando un anillo de firma, manteniendo anónimos su propiedad y sus gastos reales. Los detalles del protocolo se explican en las siguientes subsecciones. 4.3 Pagos no vinculables Las direcciones clásicas Bitcoin, una vez publicadas, se convierten en un identificador inequívoco para las direcciones entrantes. pagos, vinculándolos entre sí y vinculándolos a los seudónimos del destinatario. Si alguien quiere recibir una transacción "desvinculada", debe transmitir su dirección al remitente por un canal privado. Si quiere recibir diferentes transacciones de las que no se puede demostrar que pertenecen al mismo propietario debería generar todas las diferentes direcciones y nunca publicarlas con su propio seudónimo. Público Privado Alicia carol Dirección 1 de Bob Dirección 2 de Bob La clave de Bob 1 La llave de Bob 2 Bob Fig. 2. Modelo tradicional de claves/transacciones Bitcoin. Proponemos una solución que permite a un usuario publicar una única dirección y recibir información incondicional. pagos no vinculables. El destino de cada salida de CryptoNote (por defecto) es una clave pública, derivado de la dirección del destinatario y los datos aleatorios del remitente. La principal ventaja contra Bitcoin es que cada clave de destino es única de forma predeterminada (a menos que el remitente use los mismos datos para cada de sus transacciones al mismo destinatario). Por lo tanto, no existe el problema de la “reutilización de direcciones” por parte de diseño y ningún observador puede determinar si alguna transacción se envió a una dirección o enlace específico dos direcciones juntas. 6 la clave de usuario privada es un par (a, b) de dos claves electrónicas privadas diferentes; la clave de seguimiento es un par (a, B) de clave electrónica pública y privada (donde B = bG y a ̸= b); la clave pública de usuario es un par (A, B) de dos claves electrónicas públicas derivadas de (a, b); La dirección estándar es una representación de una clave de usuario pública dada en una cadena amigable para los humanos. con corrección de errores; La dirección truncada es una representación de la segunda mitad (punto B) de una clave de usuario pública dada. en una cadena amigable para los humanos con corrección de errores. La estructura de la transacción sigue siendo similar a la estructura en Bitcoin: cada usuario puede elegir varios pagos entrantes independientes (transacciones salidas), firmarlos con el correspondiente claves privadas y enviarlas a diferentes destinos. Contrariamente al modelo de Bitcoin, donde un usuario posee una clave pública y privada única, en el En el modelo propuesto, el remitente genera una clave pública única basada en la dirección del destinatario y algunos datos aleatorios. En este sentido, una transacción entrante para el mismo destinatario se envía a un clave pública de un solo uso (no directamente a una dirección única) y solo el destinatario puede recuperar la parte privada correspondiente para canjear sus fondos (usando su clave privada única). El destinatario puede gastar los fondos utilizando un anillo de firma, manteniendo anónimos su propiedad y sus gastos reales. Los detalles del protocolo se explican en las siguientes subsecciones. 4.3 Pagos no vinculables Las direcciones clásicas Bitcoin, una vez publicadas, se convierten en un identificador inequívoco para las direcciones entrantes. pagos, vinculándolos entre sí y vinculándolos a los seudónimos del destinatario. Si alguien quiere recibir una transacción "desvinculada", debe transmitir su dirección al remitente por un canal privado. Si quiere recibir diferentes transacciones de las que no se puede demostrar que pertenecen al mismo propietario debería generar todas las diferentes direcciones y nunca publicarlas con su propio seudónimo. Público Privado Alicia carol Dirección 1 de Bob Dirección 2 de Bob La clave de Bob 1 La llave de Bob 2 Bob Fig. 2. Mod de transacciones/claves tradicionales Bitcoinel. Proponemos una solución que permite a un usuario publicar una única dirección y recibir información incondicional. pagos no vinculables. El destino de cada salida de CryptoNote (por defecto) es una clave pública, derivado de la dirección del destinatario y los datos aleatorios del remitente. La principal ventaja contra Bitcoin es que cada clave de destino es única de forma predeterminada (a menos que el remitente use los mismos datos para cada de sus transacciones al mismo destinatario). Por lo tanto, no existe el problema de la “reutilización de direcciones” por parte de diseño y ningún observador puede determinar si alguna transacción se envió a una dirección o enlace específico dos direcciones juntas. 6 11 Esto es como Bitcoin, pero con infinitos apartados de correos anónimos, canjeables sólo por el receptor. generar una clave privada que sea tan anónima como puede serlo una firma en anillo. Bitcoin funciona de esta manera. Si Alex tiene 0.112 Bitcoin en su billetera que acaba de recibir de Frank, realmente tiene un mensaje "Yo, [FRANK], envío 0.112 Bitcoin a [alex] + H0 + N0" donde 1) Frank ha firmado el mensaje con su clave privada [FRANK], 2) Frank ha firmado el mensaje con la clave pública de Alex clave, [alex], 3) Frank ha incluido alguna forma de la historia del bitcoin, H0, y 4) Frank incluye un bit aleatorio de datos llamado nonce, N0. Si Alex quiere enviar 0.011 Bitcoin a Charlene, tomará el mensaje de Frank y lo establecerá en H1 y firmará dos mensajes: uno para su transacción y otro para el cambio. H1= "Yo, [FRANK], envío 0.112 Bitcoin a [alex] + H0 + N" "Yo, [ALEX], envío 0.011 Bitcoin a [charlene] + H1 + N1" "Yo, [ALEX], envío 0.101 Bitcoin como cambio a [alex] + H1 + N2." donde Alex firma ambos mensajes con su clave privada [ALEX], el primer mensaje con la de Charlene clave pública [charlene], el segundo mensaje con la clave pública de Alex [alex], e incluyendo el historiales y algunos nonces N1 y N2 generados aleatoriamente de forma apropiada. Cryptonote funciona de esta manera: Si Alex tiene 0.112 Cryptonote en su billetera que acaba de recibir de Frank, realmente tiene un mensaje "Yo, [alguien en un grupo ad-hoc], envío 0.112 Cryptonote a [una dirección única] + H0 +N0." Alex descubrió que este era su dinero al comparar su clave privada [ALEX] con [una dirección única] para cada mensaje que pasa, y si desea gastarlo, lo hace en de la siguiente manera. Ella elige un destinatario del dinero, tal vez Charlene haya comenzado a votar a favor de los ataques con drones, por lo que Alex quiere enviarle dinero a Brenda. Entonces Alex busca la clave pública de Brenda, [brenda], y utiliza su propia clave privada, [ALEX], para generar una dirección única [ALEX+brenda]. ella luego elige una colección arbitraria C de la red de usuarios de cryptonote y construye una firma de anillo de este grupo ad-hoc. Configuramos nuestro historial como el mensaje anterior, agregamos nonces y proceder como de costumbre. H1 = "Yo, [alguien en un grupo ad-hoc], envío 0.112 Cryptonote a [una dirección única] + H0 +N0." "Yo, [alguien de la colección C], envío 0.011 Cryptonote a [dirección única hecha por ALEX+brenda] + H1 + N1" "Yo, [alguien de la colección C], envío 0.101 Cryptonote como cambio a [dirección única hecha por ALEX+alex] + H1 + N2" Ahora, Alex y Brenda escanean todos los mensajes entrantes en busca de direcciones únicas que creado usando su clave. Si encuentran alguno, entonces ese mensaje es nuevo y propio. criptonota! E incluso entonces, la transacción seguirá llegando al blockchain. Si las monedas que entran en esa dirección Se sabe que son enviados por delincuentes, contribuyentes políticos o por comités y cuentas. con presupuestos estrictos (es decir, malversación), o si el nuevo propietario de estas monedas alguna vez comete un error y envía estas monedas a una dirección común con monedas que se sabe que posee, la plantilla de anonimato está arriba en bitcoin.

la clave de usuario privada es un par (a, b) de dos claves electrónicas privadas diferentes; la clave de seguimiento es un par (a, B) de clave electrónica pública y privada (donde B = bG y a ̸= b); la clave pública de usuario es un par (A, B) de dos claves electrónicas públicas derivadas de (a, b); La dirección estándar es una representación de una clave de usuario pública dada en una cadena amigable para los humanos. con corrección de errores; La dirección truncada es una representación de la segunda mitad (punto B) de una clave de usuario pública dada. en una cadena amigable para los humanos con corrección de errores. La estructura de la transacción sigue siendo similar a la estructura en Bitcoin: cada usuario puede elegir varios pagos entrantes independientes (transacciones salidas), firmarlos con el correspondiente claves privadas y enviarlas a diferentes destinos. Contrariamente al modelo de Bitcoin, donde un usuario posee una clave pública y privada única, en el En el modelo propuesto, el remitente genera una clave pública única basada en la dirección del destinatario y algunos datos aleatorios. En este sentido, una transacción entrante para el mismo destinatario se envía a un clave pública de un solo uso (no directamente a una dirección única) y solo el destinatario puede recuperar la parte privada correspondiente para canjear sus fondos (usando su clave privada única). El destinatario puede gastar los fondos utilizando un anillo de firma, manteniendo anónimos su propiedad y sus gastos reales. Los detalles del protocolo se explican en las siguientes subsecciones. 4.3 Pagos no vinculables Las direcciones clásicas Bitcoin, una vez publicadas, se convierten en un identificador inequívoco para las direcciones entrantes. pagos, vinculándolos entre sí y vinculándolos a los seudónimos del destinatario. Si alguien quiere recibir una transacción "desvinculada", debe transmitir su dirección al remitente por un canal privado. Si quiere recibir diferentes transacciones de las que no se puede demostrar que pertenecen al mismo propietario debería generar todas las diferentes direcciones y nunca publicarlas con su propio seudónimo. Público Privado Alicia carol Dirección 1 de Bob Dirección 2 de Bob La clave de Bob 1 La llave de Bob 2 Bob Fig. 2. Modelo tradicional de claves/transacciones Bitcoin. Proponemos una solución que permite a un usuario publicar una única dirección y recibir información incondicional. pagos no vinculables. El destino de cada salida de CryptoNote (por defecto) es una clave pública, derivado de la dirección del destinatario y los datos aleatorios del remitente. La principal ventaja frente a Bitcoin es que cada clave de destino es única de forma predeterminada (a menos que el remitente use los mismos datos para cada de sus transacciones al mismo destinatario). Por lo tanto, no existe el problema de la “reutilización de direcciones” por parte de diseño y ningún observador puede determinar si alguna transacción se envió a una dirección o enlace específico dos direcciones juntas. 6 la clave de usuario privada es un par (a, b) de dos claves electrónicas privadas diferentes; la clave de seguimiento es un par (a, B) de clave electrónica pública y privada (donde B = bG y a ̸= b); la clave pública de usuario es un par (A, B) de dos claves electrónicas públicas derivadas de (a, b); La dirección estándar es una representación de una clave de usuario pública dada en una cadena amigable para los humanos. con corrección de errores; La dirección truncada es una representación de la segunda mitad (punto B) de una clave de usuario pública dada. en una cadena amigable para los humanos con corrección de errores. La estructura de la transacción sigue siendo similar a la estructura en Bitcoin: cada usuario puede elegir varios pagos entrantes independientes (transacciones salidas), firmarlos con el correspondiente claves privadas y enviarlas a diferentes destinos. Contrariamente al modelo de Bitcoin, donde un usuario posee una clave pública y privada única, en el En el modelo propuesto, el remitente genera una clave pública única basada en la dirección del destinatario y algunos datos aleatorios. En este sentido, una transacción entrante para el mismo destinatario se envía a un clave pública de un solo uso (no directamente a una dirección única) y solo el destinatario puede recuperar la parte privada correspondiente para canjear sus fondos (usando su clave privada única). El destinatario puede gastar los fondos utilizando un anillo de firma, manteniendo anónimos su propiedad y sus gastos reales. Los detalles del protocolo se explican en las siguientes subsecciones. 4.3 Pagos no vinculables Las direcciones clásicas Bitcoin, una vez publicadas, se convierten en un identificador inequívoco para las direcciones entrantes. pagos, vinculándolos entre sí y vinculándolos a los seudónimos del destinatario. Si alguien quiere recibir una transacción "desvinculada", debe transmitir su dirección al remitente por un canal privado. Si quiere recibir diferentes transacciones de las que no se puede demostrar que pertenecen al mismo propietario debería generar todas las diferentes direcciones y nunca publicarlas con su propio seudónimo. Público Privado Alicia carol Dirección 1 de Bob Dirección 2 de Bob La clave de Bob 1 La llave de Bob 2 Bob Fig. 2. Mod tradicional de claves/transacciones Bitcoinel. Proponemos una solución que permite a un usuario publicar una única dirección y recibir información incondicional. pagos no vinculables. El destino de cada salida de CryptoNote (por defecto) es una clave pública, derivado de la dirección del destinatario y los datos aleatorios del remitente. La principal ventaja contra Bitcoin es que cada clave de destino es única de forma predeterminada (a menos que el remitente use los mismos datos para cada de sus transacciones al mismo destinatario). Por lo tanto, no existe el problema de la “reutilización de direcciones” por parte de diseño y ningún observador puede determinar si alguna transacción se envió a una dirección o enlace específico dos direcciones juntas. 6 12 Por lo tanto, en lugar de que los usuarios envíen monedas desde la dirección (que en realidad es una clave pública) a la dirección (otra clave pública) usando sus claves privadas, los usuarios envían monedas desde un apartado de correos único (que se genera usando la clave pública de tus amigos) a un apartado de correos único (de manera similar) usando tu propias claves privadas. En cierto sentido, estamos diciendo: "Está bien, todos quiten las manos del dinero mientras se entrega". transferido! Basta con saber que nuestras llaves pueden abrir esa caja y que Sabemos cuánto dinero hay en la caja. Nunca ponga sus huellas dactilares en el apartado postal o realmente úselo, simplemente intercambie la caja llena de efectivo. De esa manera no sabemos quién envió qué, pero el contenido de estas direcciones públicas sigue siendo fluido, fungible, divisible y todavía poseemos todas las otras buenas cualidades del dinero que deseamos, como bitcoin". Un conjunto infinito de apartados de correos. Publicas una dirección, yo tengo una clave privada. Utilizo mi clave privada y tu dirección, y algunos datos aleatorios, para generar una clave pública. El algoritmo está diseñado de tal manera que, desde su dirección se utilizó para generar la clave pública, solo SU clave privada funciona para desbloquear la mensaje. Una observadora, Eve, te ve publicar tu dirección y ve la clave pública que anuncio. Sin embargo, ella no sabe si anuncié mi clave pública según tu dirección o la de ella, o la de Brenda. o el de Charlene, o el de quien sea. Ella compara su clave privada con la clave pública que anuncié. y ve que no funciona; no es su dinero. Ella no conoce la clave privada de nadie más y sólo el destinatario del mensaje tiene la clave privada que puede desbloquear el mensaje. entonces nadie escuchar puede determinar quién recibió el dinero y mucho menos tomarlo.

Público Privado Alicia carol Clave de un solo uso Clave de un solo uso Clave de un solo uso Bob La llave de Bob Dirección de Bob Fig. 3. Modelo de transacciones/claves de CryptoNote. Primero, el remitente realiza un intercambio Diffe-Hellman para obtener un secreto compartido de sus datos y la mitad de la dirección del destinatario. Luego calcula una clave de destino única, utilizando el valor compartido secreto y la segunda mitad de la dirección. Se requieren dos claves electrónicas diferentes del destinatario para estos dos pasos, una dirección CryptoNote estándar es casi el doble de grande que una billetera Bitcoin dirección. El receptor también realiza un intercambio Diﬃe-Hellman para recuperar el correspondiente clave secreta. Una secuencia de transacción estándar es la siguiente: 1. Alice quiere enviar un pago a Bob, quien ha publicado su dirección estándar. ella descomprime la dirección y obtiene la clave pública de Bob (A, B). 2. Alice genera un \(r \in [1, l - 1]\) aleatorio y calcula una clave pública única \(P = H_s(rA)G +\) b. 3. Alice usa P como clave de destino para la salida y también empaqueta el valor R = rG (como parte del intercambio Diffe-Hellman) en algún momento de la transacción. Tenga en cuenta que ella puede crear otras salidas con claves públicas únicas: las claves de diferentes destinatarios (Ai, Bi) implican diferentes Pi incluso con la misma r. Transacción clave pública de transmisión salida de transmisión Cantidad Clave de destino R = rG P = Hs(rA)G + B del receptor clave pública Datos aleatorios del remitente r (A,B) Fig. 4. Estructura de transacción estándar. 4. Alice envía la transacción. 5. Bob verifica cada transacción que pasa con su clave privada (a, b) y calcula P ′ = Hs(aR)G + B. Si la transacción de Alice con Bob como destinatario estaba entre ellas, entonces aR = arG = rA y P ′ = P. 7 Público Privado Alicia carol Clave de un solo uso Clave de un solo uso Clave de un solo uso Bob La llave de Bob Dirección de Bob Fig. 3. Modelo de transacciones/claves de CryptoNote. Primero, el remitente realiza un intercambio Diffe-Hellman para obtener un secreto compartido de sus datos y la mitad de la dirección del destinatario. Luego calcula una clave de destino única, utilizando el valor compartido secreto y la segunda mitad de la dirección. Se requieren dos claves electrónicas diferentes del destinatario para estos dos pasos, una dirección CryptoNote estándar es casi el doble de grande que una billetera Bitcoin dirección. El receptor también realiza un intercambio Diﬃe-Hellman para recuperar el correspondiente clave secreta. Una secuencia de transacción estándar es la siguiente: 1. Alice quiere enviar un pago a Bob, quien ha publicado su dirección estándar. ella descomprime la dirección y obtiene la clave pública de Bob (A, B). 2. Alice genera un \(r \in [1, l - 1]\) aleatorio y calcula una clave pública única \(P = H_s(rA)G +\) b. 3. Alice usa P como clave de destino para la salida y también empaqueta el valor R = rG (como parte del intercambio Diffe-Hellman) en algún momento de la transacción. Tenga en cuenta que ella puede crear otras salidas con claves públicas únicas: las claves de diferentes destinatarios (Ai, Bi) implican diferentes Pi incluso con la misma r. Transacción clave pública de transmisión salida de transmisión Cantidad Clave de destino R = rG P = Hs(rA)G + B del receptor clave pública Datos aleatorios del remitente r (A,B) Fig. 4. Estructura de transacción estándar. 4. Alice envía la transacción. 5. Bob verifica cada transacción que pasa con su clave privada (a, b) y calcula P ′ = Hs(aR)G + B. Si la transacción de Alice con Bob como destinatario estaba entre ellas, entonces aR = arG = rA y P ′ = P. 7 13 Me pregunto qué tan doloroso sería implementar una elección de criptografía. esquema. Elíptica o no. Entonces, si algún esquema se rompe en el futuro, la moneda cambia sin preocupación. Probablemente un gran dolor de cabeza. Bien, esto es exactamente lo que acabo de explicar en mi comentario anterior. El tipo Diffe-Hellman Los intercambios son buenos. Digamos que Alex y Brenda tienen cada uno un número secreto, A y B, y un número No les importa mantener el secreto, a y b. Quieren generar un secreto compartido sin Eva lo descubre. A Diffe y Hellman se les ocurrió una manera para que Alex y Brenda compartieran el números públicos a y b, pero no los números privados A y B, y generan un secreto compartido, K. Usando este secreto compartido, K, sin que Eva escuche para poder generar el mismo K, Alex y Brenda ahora pueden usar K como clave de cifrado secreta y devolver mensajes secretos. y adelante. Así es como PUEDE funcionar, aunque debería funcionar con números mucho mayores que 100. Usaremos 100 porque trabajar con los números enteros módulo 100 equivale a "descartar todos sino los dos últimos dígitos de un número." Alex y Brenda eligen cada uno A, a, B y b. Mantienen A y B en secreto. Alex le dice a Brenda su valor de módulo 100 (solo los dos últimos dígitos) y Brenda le dice a Alex. su valor de b módulo 100. Ahora Eva sabe (a,b) módulo 100. Pero Alex sabe (a,b,A) por lo que puede calcular x=abA módulo 100.Alex corta todo excepto el último dígito porque estamos trabajando. bajo los números enteros módulo 100 nuevamente. De manera similar, Brenda sabe (a,b,B) por lo que puede calcular y=abB módulo 100. Alex ahora puede publicar x y Brenda puede publicar y. Pero ahora Alex puede calcular yA = abBA módulo 100, y Brenda puede calcular xB = abBA módulo 100. ¡Ambos saben el mismo número! Pero todo lo que Eva ha oído es (a,b,abA,abB). No tiene una manera fácil de calcular abA*B. Ésta es la forma más fácil y menos segura de pensar en el intercambio Diffe-Hellman. Existen versiones más seguras. Pero la mayoría de las versiones funcionan debido a la factorización de números enteros y discreta. Los logaritmos son difíciles y ambos problemas se resuelven fácilmente con computadoras cuánticas. Investigaré si existe alguna versión que sea resistente a la cuántica. http://en.wikipedia.org/wiki/Diﬃe%E2%80%93Hellman_key_exchange A la "secuencia txn estándar" que se enumera aquí le faltan muchos pasos, como FIRMAS. Aquí simplemente se dan por sentado. Lo cual es realmente malo, porque el orden en el que firmar cosas, la información incluida en el mensaje firmado, etc.... todo esto es extremadamente importante para el protocolo. Equivocarse uno o dos de los pasos, incluso ligeramente fuera de orden, mientras se implementa "el secuencia de transacción estándar" podría poner en duda la seguridad de todo el sistema. Además, las pruebas presentadas más adelante en el artículo pueden no ser lo suficientemente rigurosas si El marco bajo el cual trabajan está definido de manera tan vaga como en esta sección.

Público Privado Alicia carol Clave de un solo uso Clave de un solo uso Clave de un solo uso Bob La llave de Bob Dirección de Bob Fig. 3. Modelo de transacciones/claves de CryptoNote. Primero, el remitente realiza un intercambio Diffe-Hellman para obtener un secreto compartido de sus datos y la mitad de la dirección del destinatario. Luego calcula una clave de destino única, utilizando el valor compartido secreto y la segunda mitad de la dirección. Se requieren dos claves electrónicas diferentes del destinatario para estos dos pasos, una dirección CryptoNote estándar es casi el doble de grande que una billetera Bitcoin dirección. El receptor también realiza un intercambio Diﬃe-Hellman para recuperar el correspondiente clave secreta. Una secuencia de transacción estándar es la siguiente: 1. Alice quiere enviar un pago a Bob, quien ha publicado su dirección estándar. ella descomprime la dirección y obtiene la clave pública de Bob (A, B). 2. Alice genera un \(r \in [1, l - 1]\) aleatorio y calcula una clave pública única \(P = H_s(rA)G +\) b. 3. Alice usa P como clave de destino para la salida y también empaqueta el valor R = rG (como parte del intercambio Diffe-Hellman) en algún momento de la transacción. Tenga en cuenta que ella puede crear otras salidas con claves públicas únicas: las claves de diferentes destinatarios (Ai, Bi) implican diferentes Pi incluso con la misma r. Transacción clave pública de transmisión salida de transmisión Cantidad Clave de destino R = rG P = Hs(rA)G + B del receptor clave pública Datos aleatorios del remitente r (A,B) Fig. 4. Estructura de transacción estándar. 4. Alice envía la transacción. 5. Bob verifica cada transacción que pasa con su clave privada (a, b) y calcula P ′ = Hs(aR)G + B. Si la transacción de Alice con Bob como destinatario estaba entre ellas, entonces aR = arG = rA y P ′ = P. 7 Público Privado Alicia carol Clave de un solo uso Clave de un solo uso Clave de un solo uso Bob La llave de Bob Dirección de Bob Fig. 3. Modelo de transacciones/claves de CryptoNote. Primero, el remitente realiza un intercambio Diffe-Hellman para obtener un secreto compartido de sus datos y la mitad de la dirección del destinatario. Luego calcula una clave de destino única, utilizando el valor compartido secreto y la segunda mitad de la dirección. Se requieren dos claves electrónicas diferentes del destinatario para estos dos pasos, una dirección CryptoNote estándar es casi el doble de grande que una billetera Bitcoin dirección. El receptor también realiza un intercambio Diﬃe-Hellman para recuperar el correspondiente clave secreta. Una secuencia de transacción estándar es la siguiente: 1. Alice quiere enviar un pago a Bob, quien ha publicado su dirección estándar. ella descomprime la dirección y obtiene la clave pública de Bob (A, B). 2. Alice genera un \(r \in [1, l - 1]\) aleatorio y calcula una clave pública única \(P = H_s(rA)G +\) b. 3. Alice usa P como clave de destino para la salida y también empaqueta el valor R = rG (como parte del intercambio Diffe-Hellman) en algún momento de la transacción. Tenga en cuenta que ella puede crear otras salidas con claves públicas únicas: las claves de diferentes destinatarios (Ai, Bi) implican diferentes Pi incluso con la misma r. Transacción clave pública de transmisión salida de transmisión Cantidad Clave de destino R = rG P = Hs(rA)G + B del receptor clave pública Datos aleatorios del remitente r (A,B) Fig. 4. Estructura de transacción estándar. 4. Alice envía la transacción. 5. Bob verifica cada transacción que pasa con su clave privada (a, b) y calcula P ′ = Hs(aR)G + B. Si la transacción de Alice con Bob como destinatario estaba entre ellas, entonces aR = arG = rA y P ′ = P. 7 14 Tenga en cuenta que los autores hacen un trabajo terrible al mantener la terminología correcta en todo momento. el texto, pero especialmente en la siguiente parte. La próxima encarnación de este artículo será necesariamente mucho más riguroso. En el texto se refieren a P como su clave pública única. En el diagrama, se refieren a R como su "clave pública Tx" y P como su "clave de destino". Si tuviera que reescribir esto, lo haría Explique muy específicamente cierta terminología antes de discutir estas secciones. Este codo es enorme. Consulte la página 5. ¿Quién elige a Ell? El diagrama ilustra que la clave pública de la transacción R = rG, que es aleatoria y elegida por el remitente, no forma parte de la salida Tx. Esto se debe a que podría ser el mismo para múltiples transacciones a varias personas y no se utiliza MAS TARDE para gastar. Se genera una nueva R cada vez que desee transmitir una nueva transacción CryptoNote. Además, R sólo se utiliza para comprobar si eres el destinatario de la transacción. No son datos basura, pero son basura para cualquiera. sin las claves privadas asociadas con (A,B). La clave de Destino, por otro lado, P = Hs(rA)G + B es parte de la salida Tx. todos revisar los datos de cada transacción que pasa debe comparar su propio P* generado con esta P para ver si son propietarios de esta transacción pasajera. Cualquier persona con una transacción no gastada (UTXO) tendrá un montón de estas Ps por ahí con cantidades. para gastard, ellos firmar algún mensaje nuevo incluyendo P. Alice debe firmar esta transacción con claves privadas de un solo uso asociadas con las claves de destino de los resultados de la transacción no gastados. Cada llave de destino propiedad de Alice viene equipada con una clave privada única que también pertenece (presumiblemente) a Alice. Cada vez que Alice quiere envíame el contenido de una clave de destino a mí, a Bob, a Brenda, a Charlie o a Charlene, ella utiliza su clave privada para firmar la transacción. Al recibir la transacción, recibiré un nuevo Tx clave pública, una nueva clave pública de Destino y podré recuperar una nueva clave privada única x. Combinando mi clave privada única, x, con el destino público de la nueva transacción La(s) clave(s) es cómo enviamos una nueva transacción.

Bob puede recuperar la clave privada única correspondiente: x = Hs(aR) + b, de modo que P = xG. Puede gastar esta producción en cualquier momento firmando una transacción con x. Transacción clave pública de transmisión salida de transmisión Cantidad Clave de destino P ′ = Hs(aR)G + bG clave pública de un solo uso x = Hs(aR) + b clave privada de un solo uso del receptor clave privada (a,b) R P′ ?=P Fig. 5. Verificación de transacciones entrantes. Como resultado, Bob recibe pagos asociados con claves públicas únicas que son invinculable para un espectador. Algunas notas adicionales: • Cuando Bob “reconoce” sus transacciones (ver paso 5) prácticamente usa sólo la mitad de su información privada: (a, B). Este par, también conocido como clave de seguimiento, se puede pasar a un tercero (Carol). Bob puede delegarle el procesamiento de nuevas transacciones. Bob no necesita confiar explícitamente en Carol, porque no puede recuperar la clave secreta de un solo uso p sin la clave privada completa de Bob (a, b). Este enfoque es útil cuando Bob carece de ancho de banda. o potencia de cálculo (teléfonos inteligentes, carteras de hardware, etc.). • En caso de que Alice quiera demostrar que envió una transacción a la dirección de Bob, puede revelarla r o utilizar cualquier tipo de protocolo de conocimiento cero para demostrar que sabe r (por ejemplo, firmando la transacción con r). • Si Bob quiere tener una dirección compatible con auditoría donde se realicen todas las transacciones entrantes enlazable, puede publicar su clave de seguimiento o utilizar una dirección truncada. esa dirección representan sólo una clave electrónica pública B, y la parte restante requerida por el protocolo es derivado de él de la siguiente manera: a = Hs(B) y A = Hs(B)G. En ambos casos cada persona es capaz de "reconocer" todas las transacciones entrantes de Bob, pero, por supuesto, ninguna puede gastar el fondos encerrados dentro de ellos sin la clave secreta b. 4.4 Firmas de anillo únicas Un protocolo basado en firmas de anillo únicas permite a los usuarios lograr una desvinculación incondicional. Desafortunadamente, los tipos comunes de firmas criptográficas permiten rastrear las transacciones hasta sus respectivos remitentes y receptores. Nuestra solución a esta deficiencia radica en utilizar una firma diferente tipo que los que se utilizan actualmente en los sistemas de efectivo electrónico. Primero proporcionaremos una descripción general de nuestro algoritmo sin referencia explícita a efectivo electrónico. Una firma de anillo de un solo uso contiene cuatro algoritmos: (GEN, SIG, VER, LNK): GEN: toma parámetros públicos y genera un par ec (P, x) y una clave pública I. SIG: toma un mensaje m, un conjunto \(S'\) de claves públicas {Pi}i̸=s, un par (Ps, xs) y genera una firma \(\sigma\) y un conjunto \(S = \)S'\( \cup \{P_s\}\). 8
Bob puede recuperar la clave privada única correspondiente: x = Hs(aR) + b, de modo que P = xG. Puede gastar esta producción en cualquier momento firmando una transacción con x. Transacción clave pública de transmisión salida de transmisión Cantidad Clave de destino P ′ = Hs(aR)G + bG clave pública de un solo uso x = Hs(aR) + b clave privada de un solo uso del receptor clave privada (a,b) R P′ ?=P Fig. 5. Verificación de transacciones entrantes. Como resultado, Bob recibe pagos asociados con claves públicas únicas que son invinculable para un espectador. Algunas notas adicionales: • Cuando Bob “reconoce” sus transacciones (ver paso 5) prácticamente usa sólo la mitad de su información privada: (a, B). Este par, también conocido como clave de seguimiento, se puede pasar a un tercero (Carol). Bob puede delegarle el procesamiento de nuevas transacciones. Bob no necesita confiar explícitamente en Carol, porque no puede recuperar la clave secreta de un solo uso p sin la clave privada completa de Bob (a, b). Este enfoque es útil cuando Bob carece de ancho de banda. o potencia de cálculo (teléfonos inteligentes, carteras de hardware, etc.). • En caso de que Alice quiera demostrar que envió una transacción a la dirección de Bob, puede revelarla r o utilizar cualquier tipo de protocolo de conocimiento cero para demostrar que sabe r (por ejemplo, firmando la transacción con r). • Si Bob quiere tener una dirección compatible con auditoría donde se realicen todas las transacciones entrantes enlazable, puede publicar su clave de seguimiento o utilizar una dirección truncada. esa dirección representan sólo una clave electrónica pública B, y la parte restante requerida por el protocolo es derivado de él de la siguiente manera: a = Hs(B) y A = Hs(B)G. En ambos casos cada persona es capaz de "reconocer" todas las transacciones entrantes de Bob, pero, por supuesto, ninguna puede gastar el fondos encerrados dentro de ellos sin la clave secreta b. 4.4 Firmas de anillo únicas Un protocolo basado en firmas de anillo únicas permite a los usuarios lograr una desvinculación incondicional. Desafortunadamente, los tipos comunes de firmas criptográficas permiten rastrear las transacciones hasta sus respectivos remitentes y receptores. Nuestra solución a esta deficiencia radica en utilizar una firma diferente tipo que los que se utilizan actualmente en los sistemas de efectivo electrónico. Primero proporcionaremos un gen.descripción general de nuestro algoritmo sin referencia explícita a efectivo electrónico. Una firma de anillo de un solo uso contiene cuatro algoritmos: (GEN, SIG, VER, LNK): GEN: toma parámetros públicos y genera un par ec (P, x) y una clave pública I. SIG: toma un mensaje m, un conjunto \(S'\) de claves públicas {Pi}i̸=s, un par (Ps, xs) y genera una firma \(\sigma\) y un conjunto \(S = \)S'\( \cup \{P_s\}\). 8 15 ¿Cómo se ve aquí el resultado de una transacción no gastada? El diagrama sugiere que el resultado de la transacción consta solo de dos puntos de datos: monto y clave de destino. Pero esto no es Suficiente porque cuando intento gastar esta "salida" todavía necesitaré saber R=rG. Recuerde, r es elegido por el remitente, y R se utiliza para reconocer las criptonotas entrantes como su propia y b) utilizada para generar la clave privada única utilizada para "reclamar" su criptonota. ¿La parte de esto que no entiendo? Tomando el teórico "está bien, tenemos estos firmas y transacciones, y las pasamos de un lado a otro" al mundo de la programación "Está bien, ¿qué información específicamente constituye un individuo UTXO?" La mejor manera de responder a esa pregunta es profundizar en el cuerpo del código completamente sin comentarios. Así se hace, equipo de bytecoin. Recuerde: vinculabilidad significa "¿envió la misma persona?" y desvinculación significa "hizo lo mismo persona recibe?". Por lo tanto, un sistema puede ser vinculable o no vinculable, desvinculable o no desvinculable. Molesto, lo sé. Entonces, cuando Nic van Saberhagen dice aquí "...los pagos entrantes [están] asociados con pagos únicos claves públicas que no pueden vincularse para un espectador", veamos a qué se refiere. Primero, considere una situación en la que Alice envía a Bob dos transacciones separadas del mismo dirección a la misma dirección. En el universo Bitcoin, Alice ya cometió el error de envío desde la misma dirección y, por lo tanto, la transacción no cumplió con nuestro deseo de obtener información limitada. vinculabilidad. Además, dado que envió el dinero a la misma dirección, no cumplió con nuestro deseo. por desvinculación. Esta transacción de bitcoin era (totalmente) vinculable y no desvinculable. Por otro lado, en el universo de las criptomonedas, digamos que Alice le envía a Bob algunas criptomonedas, usando la dirección pública de Bob. Ella elige como conjunto ofuscante de claves públicas todas las claves públicas conocidas. llaves en el área metropolitana de Washington DC. Alex genera una clave pública única usando la suya propia información y la información pública de Bob. Ella envía el dinero y cualquier observador se dará cuenta. sólo podrá deducir "Alguien del área metropolitana de Washington DC envió 2,3 criptonotas a la dirección pública única XYZ123." Aquí tenemos un control probabilístico sobre la vinculabilidad, por lo que lo llamaremos "casi no vinculable". También vemos solo las claves públicas únicas a las que se envía el dinero. Incluso si sospechábamos del receptor era Bob, no tenemos sus claves privadas y, por lo tanto, no podemos probar si una transacción aprobada pertenece a Bob y mucho menos generar su clave privada única para canjear su criptonota. entonces esto es, de hecho, totalmente "invinculable". Entonces, este es el truco más ingenioso de todos. ¿Quién quiere realmente confiar en otro MtGox? podemos ser Es cómodo almacenar cierta cantidad de BTC en Coinbase, pero lo último en seguridad de bitcoin es una billetera física. Lo cual es un inconveniente. En este caso, puedes regalar sin confianza la mitad de tu clave privada sin comprometer tu propia capacidad para gastar dinero. Al hacer esto, todo lo que estás haciendo es decirle a alguien cómo romper la desvinculación. el otro Se conservan las propiedades del CN que actúa como moneda, como prueba contra el doble gasto y todo eso.
Bob puede recuperar la clave privada única correspondiente: x = Hs(aR) + b, de modo que P = xG. Puede gastar esta producción en cualquier momento firmando una transacción con x. Transacción clave pública de transmisión salida de transmisión Cantidad Clave de destino P ′ = Hs(aR)G + bG clave pública de un solo uso x = Hs(aR) + b clave privada de un solo uso del receptor clave privada (a,b) R P′ ?=P Fig. 5. Verificación de transacciones entrantes. Como resultado, Bob recibe pagos asociados con claves públicas únicas que son invinculable para un espectador. Algunas notas adicionales: • Cuando Bob “reconoce” sus transacciones (ver paso 5) prácticamente usa sólo la mitad de su información privada: (a, B). Este par, también conocido como clave de seguimiento, se puede pasar a un tercero (Carol). Bob puede delegarle el procesamiento de nuevas transacciones. Bob no necesita confiar explícitamente en Carol, porque no puede recuperar la clave secreta de un solo uso p sin la clave privada completa de Bob (a, b). Este enfoque es útil cuando Bob carece de ancho de banda. o potencia de cálculo (teléfonos inteligentes, carteras de hardware, etc.). • En caso de que Alice quiera demostrar que envió una transacción a la dirección de Bob, puede revelarla r o utilizar cualquier tipo de protocolo de conocimiento cero para demostrar que sabe r (por ejemplo, firmando la transacción con r). • Si Bob quiere tener una dirección compatible con auditoría donde se realicen todas las transacciones entrantes enlazable, puede publicar su clave de seguimiento o utilizar una dirección truncada. esa dirección representan sólo una clave electrónica pública B, y la parte restante requerida por el protocolo es derivado de él de la siguiente manera: a = Hs(B) y A = Hs(B)G. En ambos casos cada persona es capaz de "reconocer" todas las transacciones entrantes de Bob, pero, por supuesto, ninguna puede gastar el fondos encerrados dentro de ellos sin la clave secreta b. 4.4 Firmas de anillo únicas Un protocolo basado en firmas de anillo únicas permite a los usuarios lograr una desvinculación incondicional. Desafortunadamente, los tipos comunes de firmas criptográficas permiten rastrear las transacciones hasta sus respectivos remitentes y receptores. Nuestra solución a esta deficiencia radica en utilizar una firma diferente tipo que los que se utilizan actualmente en los sistemas de efectivo electrónico. Primero proporcionaremos una descripción general de nuestro algoritmo sin referencia explícita a efectivo electrónico. Una firma de anillo de un solo uso contiene cuatro algoritmos: (GEN, SIG, VER, LNK): GEN: toma parámetros públicos y genera un par ec (P, x) y una clave pública I. SIG: toma un mensaje m, un conjunto \(S'\) de claves públicas {Pi}i̸=s, un par (Ps, xs) y genera una firma \(\sigma\) y un conjunto \(S = \)S'\( \cup \{P_s\}\). 8
Bob puede recuperar la clave privada única correspondiente: x = Hs(aR) + b, de modo que P = xG. Puede gastar esta producción en cualquier momento firmando una transacción con x. Transacción clave pública de transmisión salida de transmisión Cantidad Clave de destino P ′ = Hs(aR)G + bG clave pública de un solo uso x = Hs(aR) + b clave privada de un solo uso del receptor clave privada (a,b) R P′ ?=P Fig. 5. Verificación de transacciones entrantes. Como resultado, Bob recibe pagos asociados con claves públicas únicas que son invinculable para un espectador. Algunas notas adicionales: • Cuando Bob “reconoce” sus transacciones (ver paso 5) prácticamente usa sólo la mitad de su información privada: (a, B). Este par, también conocido como clave de seguimiento, se puede pasar a un tercero (Carol). Bob puede delegarle el procesamiento de nuevas transacciones. Bob no necesita confiar explícitamente en Carol, porque no puede recuperar la clave secreta de un solo uso p sin la clave privada completa de Bob (a, b). Este enfoque es útil cuando Bob carece de ancho de banda. o potencia de cálculo (teléfonos inteligentes, carteras de hardware, etc.). • En caso de que Alice quiera demostrar que envió una transacción a la dirección de Bob, puede revelarla r o utilizar cualquier tipo de protocolo de conocimiento cero para demostrar que sabe r (por ejemplo, firmando la transacción con r). • Si Bob quiere tener una dirección compatible con auditoría donde se realicen todas las transacciones entrantes enlazable, puede publicar su clave de seguimiento o utilizar una dirección truncada. esa dirección representan sólo una clave electrónica pública B, y la parte restante requerida por el protocolo es derivado de él de la siguiente manera: a = Hs(B) y A = Hs(B)G. En ambos casos cada persona es capaz de "reconocer" todas las transacciones entrantes de Bob, pero, por supuesto, ninguna puede gastar el fondos encerrados dentro de ellos sin la clave secreta b. 4.4 Firmas de anillo únicas Un protocolo basado en firmas de anillo únicas permite a los usuarios lograr una desvinculación incondicional. Desafortunadamente, los tipos comunes de firmas criptográficas permiten rastrear las transacciones hasta sus respectivos remitentes y receptores. Nuestra solución a esta deficiencia radica en utilizar una firma diferente tipo que los que se utilizan actualmente en los sistemas de efectivo electrónico. Primero proporcionaremos un gen.descripción general de nuestro algoritmo sin referencia explícita a efectivo electrónico. Una firma de anillo de un solo uso contiene cuatro algoritmos: (GEN, SIG, VER, LNK): GEN: toma parámetros públicos y genera un par ec (P, x) y una clave pública I. SIG: toma un mensaje m, un conjunto \(S'\) de claves públicas {Pi}i̸=s, un par (Ps, xs) y genera una firma \(\sigma\) y un conjunto \(S = \)S'\( \cup \{P_s\}\). 8 16 Sí, ahora tenemos a) una dirección de pago yb) un ID de pago. Un crítico podría preguntar "¿realmente necesitamos hacer esto? Después de todo, si un comerciante recibe 112.00678952 CN exactamente, y ese fue mi pedido, y tengo una captura de pantalla o un recibo o lo que sea, ¿no es así? ¿Es suficiente un grado demencial de precisión? La respuesta es "tal vez, la mayor parte del tiempo, en el día a día, transacciones cara a cara." Sin embargo, la situación más común (especialmente en el mundo digital) es la siguiente: un comerciante vende un conjunto de objetos, cada uno con un precio fijo. Digamos que el objeto A es 0,001 CN, el objeto B es 0,01 CN y El objeto C es 0,1 CN. Ahora bien, si el comerciante recibe un pedido de 1.618 CN, hay muchos muchos (¡muchas!) formas de organizar un pedido para un cliente. Y así, sin algún tipo de identificación de pago, identificar el llamado pedido "único" de un cliente con el llamado costo "único" de su El orden se vuelve imposible. Aún más divertido: si todo lo que hay en mi tienda online cuesta exactamente 1,0 CN, ¿y tengo 1000 clientes al día? Y quieres demostrar que compraste exactamente 3 objetos. hace dos semanas? ¿Sin una identificación de pago? Buena suerte, amigo. En pocas palabras: cuando Bob publica una dirección de pago, puede terminar publicando también una ID de pago también (ver, por ejemplo, depósitos Poloniex XMR). Esto es diferente a lo que se describe. en el texto aquí donde Alice es quien genera la identificación de pago. Bob también debe haber alguna forma de generar una identificación de pago. (a,B) Recuerde que la clave de seguimiento (a,B) se puede publicar; perder el secreto del valor de 'un' testamento no violar tu capacidad de gastar ni permitir que la gente te robe (creo... eso habría por probar), simplemente permitirá a la gente ver todas las transacciones entrantes. Una dirección truncada, como se describe en este párrafo, simplemente toma la parte "privada" de la clave. y lo genera desde la parte "pública". Revelar el valor de 'a' eliminará la no vinculabilidad pero preservará el resto de las transacciones. El autor quiere decir "no desvinculable" porque desvinculable se refiere al receptor y vinculable se refiere al remitente. También está claro que el autor no se dio cuenta de que la vinculabilidad tenía dos aspectos diferentes. Dado que, después de todo, la transacción es un objeto dirigido en un gráfico, surgirán dos preguntas: "¿Estas dos transacciones van a la misma persona?" y "¿estas dos transacciones vienen de la misma persona?" Esta es una política de "no retorno" según la cual la propiedad de desvinculación de CryptoNote es condicional. Es decir, Bob puede elegir que sus transacciones entrantes no sean desvinculables. utilizando esta política. Esta es una afirmación que prueban según el modelo aleatorio de Oracle. Llegaremos a eso; el azar Oracle tiene pros y contras.

VER: toma un mensaje m, un conjunto S, una firma \(\sigma\) y genera "verdadero" o "falso". LNK: toma un conjunto I = {Ii}, una firma \(\sigma\) y genera "vinculado" o "independiente". La idea detrás del protocolo es bastante simple: un usuario produce una firma que puede ser verificado por un conjunto de claves públicas en lugar de una clave pública única. La identidad del firmante es indistinguible de los demás usuarios cuyas claves públicas están en el conjunto hasta que el propietario produzca una segunda firma utilizando el mismo par de claves. claves privadas x0 \(\cdots\) xi \(\cdots\) xn Claves públicas P0 \(\cdots\) Pi \(\cdots\) pn anillo Firma firmar verificar Fig. 6. Anonimato de la firma del anillo. GEN: El firmante elige una clave secreta aleatoria \(x \in [1, l - 1]\) y calcula la correspondiente clave pública P = xG. Además, calcula otra clave pública I = xHp(P) que usaremos Llamémosla “imagen clave”. SIG: el firmante genera una firma de anillo única con conocimiento cero no interactivo prueba utilizando las técnicas de [21]. Selecciona un subconjunto aleatorio \(S'\) de n del conjunto de otros usuarios. claves públicas Pi, su propio par de claves (x, P) e imagen de clave I. Sea \(0 \leq s \leq n\) el índice secreto del firmante en S (para que su clave pública sea Ps). Elige un {qi | yo = 0 . . . n} y {wi | yo = 0 . . . n, i ̸= s} de (1 . . . l) y aplica la siguientes transformaciones: Li = ( QiG, si yo = s qiG + wiPi, si i ̸= s ri = ( qiHp(Pi), si yo = s qiHp(Pi) + voluntad, si i ̸= s El siguiente paso es conseguir el desafío no interactivo: c = Hs(m, L1, . . . , Ln, R1, . . . , Rn) Finalmente el firmante calcula la respuesta: ci =    wi, si i ̸= s c- notario público yo=0 ci mod l, si yo = s ri = ( qi, si i ̸= s qs −csx mod l, si yo = s La firma resultante es \(\sigma\) = (I, c1, . . . , cn, r1, . . . , rn). 9 VER: toma un mensaje m, un conjunto S, una firma \(\sigma\) y genera "verdadero" o "falso". LNK: toma un conjunto I = {Ii}, una firma \(\sigma\) y genera "vinculado" o "independiente". La idea detrás del protocolo es bastante simple: un usuario produce una firma que puede ser verificado por un conjunto de claves públicas en lugar de una clave pública única. La identidad del firmante es indistinguible de los demás usuarios cuyas claves públicas están en el conjunto hasta que el propietario produzca una segunda firma utilizando el mismo par de claves. claves privadas x0 \(\cdots\) xi \(\cdots\) xn Claves públicas P0 \(\cdots\) Pi \(\cdots\) pn anillo Firma firmar verificar Fig. 6. Anonimato de la firma del anillo. GEN: El firmante elige una clave secreta aleatoria \(x \in [1, l - 1]\) y calcula la correspondiente clave pública P = xG. Además, calcula otra clave pública I = xHp(P) que usaremos Llamémosla “imagen clave”. SIG: el firmante genera una firma de anillo única con conocimiento cero no interactivo prueba utilizando las técnicas de [21]. Selecciona un subconjunto aleatorio \(S'\) de n del conjunto de otros usuarios. claves públicas Pi, su propio par de claves (x, P) e imagen de clave I. Sea \(0 \leq s \leq n\) el índice secreto del firmante en S (para que su clave pública sea Ps). Elige un {qi | yo = 0 . . . n} y {wi | yo = 0 . . . n, i ̸= s} de (1 . . . l) y aplica la siguientes transformaciones: Li = ( QiG, si yo = s qiG + wiPi, si i ̸= s ri = ( qiHp(Pi), si yo = s qiHp(Pi) + voluntad, si i ̸= s El siguiente paso es conseguir el desafío no interactivo: c = Hs(m, L1, . . . , Ln, R1, . . . , Rn) Finalmente el firmante calcula la respuesta: ci =    wi, si i ̸= s c- notario público yo=0 ci mod l, si yo = s ri = ( qi, si i ̸= s qs −csx mod l, si yo = s La firma resultante es \(\sigma\) = (I, c1, . . . , cn, r1, . . . , rn). 9 17 Quizás esto sea una estupidez, pero hay que tener cuidado al unir S y P_s. Si simplemente agregas el última clave pública hasta el final, la desvinculación se rompe porque cualquiera verifica las transacciones pasadas Puede simplemente verificar la última clave pública enumerada en cada transacción y boom. Esa es la clave pública asociado con el remitente. Entonces, después de la unión, se debe crear un generador de números pseudoaleatorios. Se utiliza para permutar las claves públicas elegidas. "...hasta que el propietario produzca una segunda firma utilizando el mismo par de claves". Deseo que el autor(es?) daría más detalles sobre esto. Creo que esto significa "asegúrate de que cada vez que elijas un conjunto de claves públicas para ofuscar usted mismo, elige un conjunto completamente nuevo sin dos llaves iguales". Lo cual parece una condición bastante fuerte para colocar sobre la desvinculación. Quizás "eliges un nuevo conjunto aleatorio de todas las claves posibles" con el supuesto de que, aunque las intersecciones no triviales inevitablemente suceder, no sucederán a menudo. De cualquier manera, necesito profundizar más en esta afirmación. Esto está generando la firma del anillo. Las pruebas de conocimiento cero son increíbles: te desafío a que me demuestres que conoces un secreto sin revelar el secreto. Por ejemplo, digamos que estamos en la entrada de una cueva con forma de rosquilla, y en la parte trasera de la cueva (más allá de la vista desde la entrada) hay una opuerta de nuevo camino a la que afirma que tienes la llave. Si vas en una dirección, siempre te dejará pasar, pero si vas en la dirección En otra dirección, necesitas una llave. Pero ni siquiera quieres MOSTRARME la clave y mucho menos Muéstrame que abre la puerta. Pero quieres demostrarme que sabes cómo abrir el puerta. En el entorno interactivo, lanzo una moneda. Cara está a la izquierda, cruz a la derecha y bajas por el cueva en forma de rosquilla en cualquier dirección que te indique la moneda. Al fondo, más allá de mi vista, tú Abre la puerta para regresar por el otro lado. Repetimos el experimento de lanzar una moneda al aire. hasta que esté satisfecho de que tienes la llave. Pero esa es claramente la prueba INTERACTIVA de conocimiento cero. Hay versiones no interactivas en las que tú y yo nunca tenemos que comunicarnos; De esta manera, ningún espía podrá interferir. http://en.wikipedia.org/wiki/Zero-knowledge_proof Esto es lo contrario de la definición anterior.

VER: toma un mensaje m, un conjunto S, una firma \(\sigma\) y genera "verdadero" o "falso". LNK: toma un conjunto I = {Ii}, una firma \(\sigma\) y genera "vinculado" o "independiente". La idea detrás del protocolo es bastante simple: un usuario produce una firma que puede ser verificado por un conjunto de claves públicas en lugar de una clave pública única. La identidad del firmante es indistinguible de los demás usuarios cuyas claves públicas están en el conjunto hasta que el propietario produzca una segunda firma utilizando el mismo par de claves. claves privadas x0 \(\cdots\) xi \(\cdots\) xn Claves públicas P0 \(\cdots\) Pi \(\cdots\) pn anillo Firma firmar verificar Fig. 6. Anonimato de la firma del anillo. GEN: El firmante elige una clave secreta aleatoria \(x \in [1, l - 1]\) y calcula la correspondiente clave pública P = xG. Además, calcula otra clave pública I = xHp(P) que usaremos Llamémosla “imagen clave”. SIG: el firmante genera una firma de anillo única con conocimiento cero no interactivo prueba utilizando las técnicas de [21]. Selecciona un subconjunto aleatorio \(S'\) de n del conjunto de otros usuarios. claves públicas Pi, su propio par de claves (x, P) e imagen de clave I. Sea \(0 \leq s \leq n\) el índice secreto del firmante en S (para que su clave pública sea Ps). Elige un {qi | yo = 0 . . . n} y {wi | yo = 0 . . . n, i ̸= s} de (1 . . . l) y aplica la siguientes transformaciones: Li = ( QiG, si yo = s qiG + wiPi, si i ̸= s ri = ( qiHp(Pi), si yo = s qiHp(Pi) + voluntad, si i ̸= s El siguiente paso es conseguir el desafío no interactivo: c = Hs(m, L1, . . . , Ln, R1, . . . , Rn) Finalmente el firmante calcula la respuesta: ci =    wi, si i ̸= s c- notario público yo=0 ci mod l, si yo = s ri = ( qi, si i ̸= s qs −csx mod l, si yo = s La firma resultante es \(\sigma\) = (I, c1, . . . , cn, r1, . . . , rn). 9 VER: toma un mensaje m, un conjunto S, una firma \(\sigma\) y genera "verdadero" o "falso". LNK: toma un conjunto I = {Ii}, una firma \(\sigma\) y genera "vinculado" o "independiente". La idea detrás del protocolo es bastante simple: un usuario produce una firma que puede ser verificado por un conjunto de claves públicas en lugar de una clave pública única. La identidad del firmante es indistinguible de los demás usuarios cuyas claves públicas están en el conjunto hasta que el propietario produzca una segunda firma utilizando el mismo par de claves. claves privadas x0 \(\cdots\) xi \(\cdots\) xn Claves públicas P0 \(\cdots\) Pi \(\cdots\) pn anillo Firma firmar verificar Fig. 6. Anonimato de la firma del anillo. GEN: El firmante elige una clave secreta aleatoria \(x \in [1, l - 1]\) y calcula la correspondiente clave pública P = xG. Además, calcula otra clave pública I = xHp(P) que usaremos Llamémosla “imagen clave”. SIG: el firmante genera una firma de anillo única con conocimiento cero no interactivo prueba utilizando las técnicas de [21]. Selecciona un subconjunto aleatorio \(S'\) de n del conjunto de otros usuarios. claves públicas Pi, su propio par de claves (x, P) e imagen de clave I. Sea \(0 \leq s \leq n\) el índice secreto del firmante en S (para que su clave pública sea Ps). Elige un {qi | yo = 0 . . . n} y {wi | yo = 0 . . . n, i ̸= s} de (1 . . . l) y aplica la siguientes transformaciones: Li = ( QiG, si yo = s qiG + wiPi, si i ̸= s ri = ( qiHp(Pi), si yo = s qiHp(Pi) + voluntad, si i ̸= s El siguiente paso es conseguir el desafío no interactivo: c = Hs(m, L1, . . . , Ln, R1, . . . , Rn) Finalmente el firmante calcula la respuesta: ci =    wi, si i ̸= s c- notario público yo=0 ci mod l, si yo = s ri = ( qi, si i ̸= s qs −csx mod l, si yo = s La firma resultante es \(\sigma\) = (I, c1, . . . , cn, r1, . . . , rn). 9 18 Toda esta área es independiente de las criptonotas y simplemente describe el algoritmo de firma del anillo sin referencia a las monedas. Sospecho que parte de la notación es consistente con el resto del artículo, aunque. Por ejemplo, x es la clave secreta "aleatoria" elegida en GEN, que da la clave pública P y la imagen de clave pública I. Este valor de x es el valor que Bob calcula en la parte 6, página 8. Entonces esto es empezando a aclarar parte de la confusión de la descripción anterior. Esto es algo genial; El dinero no se transfiere de "la dirección pública de Alice a la dirección pública de Bob". dirección." Se está transfiriendo de una dirección única a una dirección única. Entonces, en cierto sentido, así es como funcionan las cosas. Si Alex tiene algunas criptonotas porque alguien se las envió, esto significa que tiene las claves privadas necesarias para enviárselas a Bob. ella usa un intercambio Diffe-Hellman que utiliza la información pública de Bob para generar una nueva dirección única y las criptonotas se transfieren a esa dirección. Ahora, dado que se utilizó un intercambio DH (presumiblemente seguro) para generar la nueva dirección única a lo que Alex envió su CN, Bob es el único que tiene las claves privadas necesarias para repetir el arriba. Ahora Bob es Alex. http://en.wikipedia.org/wiki/Piecewise#Notation_and_interpretation La sumatoria debe indexarse sobre j, no sobre i. Cada c_i es basura aleatoria (ya que w_i es aleatorio) excepto el culo de c_iasociado con la clave real involucrada en esta firma. El valor de c es a hash de la información anterior. Sin embargo, creo que esto puede contener un error tipográfico peor que reutilizar el índice 'i', porque c_s parece definirse implícitamente, no explícitamente. De hecho, si tomamos esta ecuación con fe, entonces determinamos que c_s = (1/2)c - (1/2) sum_i neq s c_i. Es decir, un hash menos un montón de números aleatorios. Por otro lado, si esta sumatoria pretende leerse "c_s = (c - sum_j neq s c_j) mod l", luego tomamos el hash de nuestra información anterior, generamos un montón de números aleatorios, reste todos esos números aleatorios del hash, y eso nos da c_s. Esto parece ser lo que "debería" estar sucediendo según mi intuición, y coincide con el paso de verificación en la página 10. Pero la intuición no es matemática. Profundizaré en esto. Igual que antes; todos estos serán basura aleatoria excepto el asociado con el real clave pública del firmante x. Excepto que esta vez, esto es más lo que esperaría de la estructura: r_i es aleatorio para i!=s y r_s está determinado sólo por los valores secretos x y s indexados de q_i y c_i.

VER: El verificador comprueba la firma aplicando las transformaciones inversas: ( L′ i = riG + ciPi R′ i = riHp(Pi) + ciI Finalmente, el verificador comprueba si notario público yo=0 ci ?= Hs(m, L′ 0, . . . , L′ norte, R′ 0, . . . , R′ n) mod l Si esta igualdad es correcta, el verificador ejecuta el algoritmo LNK. De lo contrario, el verificador rechaza la firma. LNK: El veriﬁcador comprueba si he sido utilizado en firmas pasadas (estos valores se almacenan en el conjunto I). Los usos múltiples implican que se produjeron dos firmas bajo la misma clave secreta. El significado del protocolo: aplicando transformaciones L el firmante demuestra que sabe tal x que al menos un Pi = xG. Para que esta prueba no sea repetible introducimos la imagen clave. como I = xHp(P). El firmante usa los mismos coeficientes (ri, ci) para probar casi la misma afirmación: conoce tal x que al menos un \(H_p(P_i) = I \cdot x^{-1}\). Si el mapeo \(x \to I\) es una inyección: 1. Nadie puede recuperar la clave pública de la imagen de la clave e identificar al firmante; 2. El firmante no puede hacer dos firmas con I diferentes y la misma x. En el Apéndice A se proporciona un análisis de seguridad completo. 4.5 Transacción estándar CryptoNote Al combinar ambos métodos (claves públicas no vinculables y firma de anillo imposible de rastrear), Bob logra nuevo nivel de privacidad en comparación con el esquema original Bitcoin. Sólo requiere que almacene una clave privada (a, b) y publique (A, B) para comenzar a recibir y enviar transacciones anónimas. Mientras valida cada transacción, Bob realiza además solo dos multiplicaciones de curvas elípticas y una suma por salida para verificar si una transacción le pertenece. Por cada uno de ellos salida Bob recupera un par de claves de un solo uso (pi, Pi) y lo almacena en su billetera. Cualquier entrada puede ser circunstancialmente se prueba que tienen el mismo dueño si aparecen en una sola transacción. en De hecho, esta relación es mucho más difícil de establecer debido a la firma del anillo de una sola vez. Con una firma de anillo, Bob puede ocultar eficazmente cada entrada entre las de otra persona; todo lo posible los gastadores serán equiprobable, incluso el propietario anterior (Alice) no tiene más información que cualquier observador. Al firmar su transacción, Bob especifica n productos extranjeros con la misma cantidad que su salida, mezclándolos todos sin la participación de otros usuarios. El propio Bob (así como cualquier otra persona) no sabe si alguno de estos pagos se ha gastado: se puede utilizar un resultado en miles de firmas como factor de ambigüedad y nunca como objetivo de ocultación. el doble La verificación de gastos se produce en la fase LNK cuando se compara con el conjunto de imágenes clave utilizadas. Bob puede elegir el grado de ambigüedad por su cuenta: n = 1 significa que la probabilidad que tiene gastado, la salida tiene una probabilidad del 50%, n = 99 da 1%. El tamaño de la firma resultante aumenta. linealmente como O(n+1), por lo que el anonimato mejorado le cuesta a Bob tarifas de transacción adicionales. el tambien puede establezca n = 0 y haga que su firma de anillo consista en un solo elemento, sin embargo, esto instantáneamente revelarlo como un derrochador. 10 VER: El verificador comprueba la firma aplicando las transformaciones inversas: ( L′ i = riG + ciPi R′ i = riHp(Pi) + ciI Finalmente, el verificador comprueba si notario público yo=0 ci ?= Hs(m, L′ 0, . . . , L′ norte, R′ 0, . . . , R′ n) mod l Si esta igualdad es correcta, el verificador ejecuta el algoritmo LNK. De lo contrario, el verificador rechaza la firma. LNK: El veriﬁcador comprueba si he sido utilizado en firmas pasadas (estos valores se almacenan en el conjunto I). Los usos múltiples implican que se produjeron dos firmas bajo la misma clave secreta. El significado del protocolo: aplicando transformaciones L el firmante demuestra que sabe tal x que al menos un Pi = xG. Para que esta prueba no sea repetible introducimos la imagen clave. como I = xHp(P). El firmante usa los mismos coeficientes (ri, ci) para probar casi la misma afirmación: conoce tal x que al menos un \(H_p(P_i) = I \cdot x^{-1}\). Si el mapeo \(x \to I\) es una inyección: 1. Nadie puede recuperar la clave pública de la imagen de la clave e identificar al firmante; 2. El firmante no puede hacer dos firmas con I diferentes y la misma x. En el Apéndice A se proporciona un análisis de seguridad completo. 4.5 Transacción estándar CryptoNote Al combinar ambos métodos (claves públicas no vinculables y firma de anillo imposible de rastrear), Bob logra nuevo nivel de privacidad en comparación con el esquema original Bitcoin. Sólo requiere que almacene una clave privada (a, b) y publique (A, B) para comenzar a recibir y enviar transacciones anónimas. Mientras valida cada transacción, Bob realiza además solo dos multiplicaciones de curvas elípticas y una suma por salida para verificar si una transacción le pertenece. Por cada uno de ellos salida Bob recupera un par de claves de un solo uso (pi, Pi) y stLo guarda en su billetera. Cualquier entrada puede ser circunstancialmente se prueba que tienen el mismo dueño si aparecen en una sola transacción. en De hecho, esta relación es mucho más difícil de establecer debido a la firma del anillo de una sola vez. Con una firma de anillo, Bob puede ocultar eficazmente cada entrada entre las de otra persona; todo lo posible los gastadores serán equiprobable, incluso el propietario anterior (Alice) no tiene más información que cualquier observador. Al firmar su transacción, Bob especifica n productos extranjeros con la misma cantidad que su salida, mezclándolos todos sin la participación de otros usuarios. El propio Bob (así como cualquier otra persona) no sabe si alguno de estos pagos se ha gastado: se puede utilizar un resultado en miles de firmas como factor de ambigüedad y nunca como objetivo de ocultación. el doble La verificación de gastos se produce en la fase LNK cuando se compara con el conjunto de imágenes clave utilizadas. Bob puede elegir el grado de ambigüedad por su cuenta: n = 1 significa que la probabilidad que tiene gastado, la salida tiene una probabilidad del 50%, n = 99 da 1%. El tamaño de la firma resultante aumenta. linealmente como O(n+1), por lo que el anonimato mejorado le cuesta a Bob tarifas de transacción adicionales. el tambien puede establezca n = 0 y haga que su firma de anillo consista en un solo elemento, sin embargo, esto instantáneamente revelarlo como un derrochador. 10 19 En este punto, estoy terriblemente confundido. Alex recibe un mensaje M con firma (I,c_1, ..., c_n, r_1, ..., r_n) y lista de públicos teclas S. y ejecuta VER. Esto calculará L_i’ y R_i’ Esto verifica que c_s = c - sum_i neq s c_i en la página anterior. Al principio estaba MUY (ja) confundido. Cualquiera puede calcular L_i’ y R_i’. De hecho, cada r_i y c_i han sido publicados en la firma sigma junto con el valor de I. El conjunto S = También se ha publicado el P_i de todas las claves públicas. Así que cualquiera que haya visto sigma y el conjunto de Las claves S = P_i obtendrán los mismos valores para L_i' y R_i' y, por lo tanto, verificarán la firma. Pero luego recordé que esta sección simplemente describe un algoritmo de firma, no una "verificación Si está firmado, verifique si ME LO ENVIÓ y, de ser así, vaya a gastar el dinero". Este es SIMPLEMENTE el parte característica del juego. Me interesa leer el Apéndice A cuando finalmente llegue allí. Me gustaría ver una comparación a gran escala operación por operación de Cryptonote con Bitcoin. Además, electricidad/sostenibilidad. ¿Qué partes de los algoritmos constituyen aquí "entrada"? La entrada de transacción, creo, es una Cantidad y un conjunto de UTXOs que suman una cantidad mayor que la Cantidad. Esto no está claro. "¿Objetivo de esconderse?" He pensado en esto por unos minutos y todavía no tengo el idea más vaga de lo que podría significar. Un ataque de doble gasto solo se puede ejecutar manipulando la clave usada percibida de un nodo conjunto de imágenes \(I\). "Grado de ambigüedad" = n pero el número total de claves públicas incluidas en la transacción es norte+1. Es decir, el grado de ambigüedad sería "¿cuántas OTRAS personas quieres en ¿la multitud?" La respuesta probablemente será, por defecto, "tantos como sea posible".

VER: El verificador comprueba la firma aplicando las transformaciones inversas: ( L′ i = riG + ciPi R′ i = riHp(Pi) + ciI Finalmente, el verificador comprueba si notario público yo=0 ci ?= Hs(m, L′ 0, . . . , L′ norte, R′ 0, . . . , R′ n) mod l Si esta igualdad es correcta, el verificador ejecuta el algoritmo LNK. De lo contrario, el verificador rechaza la firma. LNK: El veriﬁcador comprueba si he sido utilizado en firmas pasadas (estos valores se almacenan en el conjunto I). Los usos múltiples implican que se produjeron dos firmas bajo la misma clave secreta. El significado del protocolo: aplicando transformaciones L el firmante demuestra que sabe tal x que al menos un Pi = xG. Para que esta prueba no sea repetible introducimos la imagen clave. como I = xHp(P). El firmante usa los mismos coeficientes (ri, ci) para probar casi la misma afirmación: conoce tal x que al menos un \(H_p(P_i) = I \cdot x^{-1}\). Si el mapeo \(x \to I\) es una inyección: 1. Nadie puede recuperar la clave pública de la imagen de la clave e identificar al firmante; 2. El firmante no puede hacer dos firmas con I diferentes y la misma x. En el Apéndice A se proporciona un análisis de seguridad completo. 4.5 Transacción estándar CryptoNote Al combinar ambos métodos (claves públicas no vinculables y firma de anillo imposible de rastrear), Bob logra nuevo nivel de privacidad en comparación con el esquema original Bitcoin. Sólo requiere que almacene una clave privada (a, b) y publique (A, B) para comenzar a recibir y enviar transacciones anónimas. Mientras valida cada transacción, Bob realiza además solo dos multiplicaciones de curvas elípticas y una suma por salida para verificar si una transacción le pertenece. Por cada uno de ellos salida Bob recupera un par de claves de un solo uso (pi, Pi) y lo almacena en su billetera. Cualquier entrada puede ser circunstancialmente se prueba que tienen el mismo dueño si aparecen en una sola transacción. en De hecho, esta relación es mucho más difícil de establecer debido a la firma del anillo de una sola vez. Con una firma de anillo, Bob puede ocultar eficazmente cada entrada entre las de otra persona; todo lo posible los gastadores serán equiprobable, incluso el propietario anterior (Alice) no tiene más información que cualquier observador. Al firmar su transacción, Bob especifica n productos extranjeros con la misma cantidad que su salida, mezclándolos todos sin la participación de otros usuarios. El propio Bob (así como cualquier otra persona) no sabe si alguno de estos pagos se ha gastado: se puede utilizar un resultado en miles de firmas como factor de ambigüedad y nunca como objetivo de ocultación. el doble La verificación de gastos se produce en la fase LNK cuando se compara con el conjunto de imágenes clave utilizadas. Bob puede elegir el grado de ambigüedad por su cuenta: n = 1 significa que la probabilidad que tiene gastado, la salida tiene una probabilidad del 50%, n = 99 da 1%. El tamaño de la firma resultante aumenta. linealmente como O(n+1), por lo que el anonimato mejorado le cuesta a Bob tarifas de transacción adicionales. el tambien puede establezca n = 0 y haga que su firma de anillo consista en un solo elemento, sin embargo, esto instantáneamente revelarlo como un derrochador. 10 VER: El verificador comprueba la firma aplicando las transformaciones inversas: ( L′ i = riG + ciPi R′ i = riHp(Pi) + ciI Finalmente, el verificador comprueba si notario público yo=0 ci ?= Hs(m, L′ 0, . . . , L′ norte, R′ 0, . . . , R′ n) mod l Si esta igualdad es correcta, el verificador ejecuta el algoritmo LNK. De lo contrario, el verificador rechaza la firma. LNK: El veriﬁcador comprueba si he sido utilizado en firmas pasadas (estos valores se almacenan en el conjunto I). Los usos múltiples implican que se produjeron dos firmas bajo la misma clave secreta. El significado del protocolo: aplicando transformaciones L el firmante demuestra que sabe tal x que al menos un Pi = xG. Para que esta prueba no sea repetible introducimos la imagen clave. como I = xHp(P). El firmante usa los mismos coeficientes (ri, ci) para probar casi la misma afirmación: conoce tal x que al menos un \(H_p(P_i) = I \cdot x^{-1}\). Si el mapeo \(x \to I\) es una inyección: 1. Nadie puede recuperar la clave pública de la imagen de la clave e identificar al firmante; 2. El firmante no puede hacer dos firmas con I diferentes y la misma x. En el Apéndice A se proporciona un análisis de seguridad completo. 4.5 Transacción estándar CryptoNote Al combinar ambos métodos (claves públicas no vinculables y firma de anillo imposible de rastrear), Bob logra nuevo nivel de privacidad en comparación con el esquema original Bitcoin. Sólo requiere que almacene una clave privada (a, b) y publique (A, B) para comenzar a recibir y enviar transacciones anónimas. Mientras valida cada transacción, Bob realiza además solo dos multiplicaciones de curvas elípticas y una suma por salida para verificar si una transacción le pertenece. Por cada uno de ellos salida Bob recupera un par de claves de un solo uso (pi, Pi) y stLo guarda en su billetera. Cualquier entrada puede ser circunstancialmente se prueba que tienen el mismo dueño si aparecen en una sola transacción. en De hecho, esta relación es mucho más difícil de establecer debido a la firma del anillo de una sola vez. Con una firma de anillo, Bob puede ocultar eficazmente cada entrada entre las de otra persona; todo lo posible los gastadores serán equiprobable, incluso el propietario anterior (Alice) no tiene más información que cualquier observador. Al firmar su transacción, Bob especifica n productos extranjeros con la misma cantidad que su salida, mezclándolos todos sin la participación de otros usuarios. El propio Bob (así como cualquier otra persona) no sabe si alguno de estos pagos se ha gastado: se puede utilizar un resultado en miles de firmas como factor de ambigüedad y nunca como objetivo de ocultación. el doble La verificación de gastos se produce en la fase LNK cuando se compara con el conjunto de imágenes clave utilizadas. Bob puede elegir el grado de ambigüedad por su cuenta: n = 1 significa que la probabilidad que tiene gastado, la salida tiene una probabilidad del 50%, n = 99 da 1%. El tamaño de la firma resultante aumenta. linealmente como O(n+1), por lo que el anonimato mejorado le cuesta a Bob tarifas de transacción adicionales. el tambien puede establezca n = 0 y haga que su firma de anillo consista en un solo elemento, sin embargo, esto instantáneamente revelarlo como un derrochador. 10 20 Esto es interesante; Anteriormente, proporcionamos una manera para que un receptor, Bob, haga todos los ENTRANTE transacciones no desvinculables ya sea eligiendo la mitad de sus claves privadas de manera determinista o publicar la mitad de sus claves privadas como públicas. Se trata de una especie de política de no vuelta atrás. Aquí vemos una forma de que un remitente, Alex, elija una única transacción saliente como vinculable, pero en realidad esto revela a Alex como el remitente de toda la red. Esta NO es una política de no vuelta atrás. Esto es transacción por transacción. ¿Existe una tercera política? ¿Puede un receptor, Bob, generar una identificación de pago única para Alex que ¿Nunca cambia, quizás usando un intercambio Diffe-Hellman? Si alguien incluye ese pago La identificación incluida en algún lugar de su transacción en la dirección de Bob, debe haber venido de Alex. De esta manera, Alex no necesita revelarse a toda la red eligiendo vincular un enlace en particular. transacción, pero aún puede identificarse ante la persona a quien envía su dinero. ¿No es esto lo que hace Poloniex?

Transacción entrada de transmisión Salida0 . . . Salidai . . . Salida Imagen clave Firmas Firma del anillo Clave de destino Salida1 Clave de destino Salida Transacciones extranjeras Salida del remitente Clave de destino Par de claves de un solo uso una sola vez clave privada Yo = xHp(P) P,x Fig. 7. Generación de firma de anillo en una transacción estándar. 5 Prueba de trabajo igualitaria En esta sección proponemos y fundamentamos el nuevo algoritmo proof-of-work. Nuestro objetivo principal es cerrar la brecha entre los mineros de CPU (mayoría) y GPU/FPGA/ASIC (minoría). es Es apropiado que algunos usuarios puedan tener cierta ventaja sobre otros, pero sus inversiones debería crecer al menos linealmente con la potencia. En términos más generales, producir dispositivos para fines especiales. tiene que ser lo menos rentable posible. 5.1 Trabajos relacionados El protocolo original Bitcoin proof-of-work utiliza la función de fijación de precios con uso intensivo de CPU SHA-256. Consiste principalmente en operadores lógicos básicos y se basa únicamente en la velocidad computacional de procesador, por lo tanto, es perfectamente adecuado para la implementación multinúcleo/transportador. Sin embargo, las computadoras modernas no están limitadas únicamente por el número de operaciones por segundo, sino también por el tamaño de la memoria. Si bien algunos procesadores pueden ser sustancialmente más rápidos que otros [8], Es menos probable que los tamaños de memoria varíen entre máquinas. Las funciones de precios ligadas a la memoria fueron introducidas por primera vez por Abadi et al y se definieron como “funciones cuyo tiempo de cálculo está dominado por el tiempo dedicado a acceder a la memoria” [15]. La idea principal es construir un algoritmo que asigne un gran bloque de datos ("bloc de notas") dentro de la memoria a la que se puede acceder con relativa lentitud (por ejemplo, RAM) y “acceder a una secuencia impredecible de ubicaciones” dentro de él. Un bloque debe ser lo suficientemente grande como para que la conservación los datos son más ventajosos que recalcularlos para cada acceso. El algoritmo también debe evitar el paralelismo interno, por lo tanto, N subprocesos simultáneos deberían requerir N veces más memoria a la vez. Dwork et al [22] investigaron y formalizaron este enfoque, lo que los llevó a sugerir otro Variante de la función de fijación de precios: “Mbound”. Una obra más pertenece a F. Coelho [20], quien 11 Transacción entrada de transmisión Salida0 . . . Salidai . . . Salida Imagen clave Firmas Firma del anillo Clave de destino Salida1 Clave de destino Salida Transacciones extranjeras Salida del remitente Clave de destino Par de claves de un solo uso una sola vez clave privada Yo = xHp(P) P,x Fig. 7. Generación de firma de anillo en una transacción estándar. 5 Prueba de trabajo igualitaria En esta sección proponemos y fundamentamos el nuevo algoritmo proof-of-work. Nuestro objetivo principal es cerrar la brecha entre los mineros de CPU (mayoría) y GPU/FPGA/ASIC (minoría). es Es apropiado que algunos usuarios puedan tener cierta ventaja sobre otros, pero sus inversiones debería crecer al menos linealmente con la potencia. En términos más generales, producir dispositivos para fines especiales. tiene que ser lo menos rentable posible. 5.1 Trabajos relacionados El protocolo original Bitcoin proof-of-work utiliza la función de fijación de precios con uso intensivo de CPU SHA-256. Consiste principalmente en operadores lógicos básicos y se basa únicamente en la velocidad computacional de procesador, por lo tanto, es perfectamente adecuado para la implementación multinúcleo/transportador. Sin embargo, las computadoras modernas no están limitadas únicamente por el número de operaciones por segundo, sino también por el tamaño de la memoria. Si bien algunos procesadores pueden ser sustancialmente más rápidos que otros [8], Es menos probable que los tamaños de memoria varíen entre máquinas. Las funciones de precios ligadas a la memoria fueron introducidas por primera vez por Abadi et al y se definieron como “funciones cuyo tiempo de cálculo está dominado por el tiempo dedicado a acceder a la memoria” [15]. La idea principal es construir un algoritmo que asigne un gran bloque de datos ("bloc de notas") dentro de la memoria a la que se puede acceder con relativa lentitud (por ejemplo, RAM) y “acceder a una secuencia impredecible de ubicaciones” dentro de él. Un bloque debe ser lo suficientemente grande como para que la conservación los datos son más ventajosos que recalcularlos para cada acceso. El algoritmo también debe evitar el paralelismo interno, por lo tanto, N subprocesos simultáneos deberían requerir N veces más memoria a la vez. Dwork et al [22] investigaron y formalizaron este enfoque, lo que los llevó a sugerir otro Variante de la función de fijación de precios: “Mbound”. Una obra más pertenece a F. Coelho [20], quien 11 21 Estos son, aparentemente, nuestros UTXO: importes y claves de destino. Si Alex es quien construye esta transacción estándar y se la envía a Bob, entonces Alex también tiene las claves privadas. a cada uno de estos. Me gusta mucho este diagrama porque responde a algunas preguntas anteriores. Una entrada Txn consiste de un conjunto de salidas Txn y un key imagen. Luego se firma con una firma circular, incluyendo todos de las claves privadas que Alex posee para todas las transacciones extranjeras incluidas en el acuerdo. el La salida Txn consta de una cantidad y una clave de destino. El receptor de la transacción podrá, a voluntad, generar su clave privada única como se describió anteriormente en el documento para gastar el dinero. Será un placer descubrir en qué medida esto coincide con el código real... No, Nic van Saberhagen describe vagamente algunas propiedades de un algoritmo de prueba de trabajo, sin realmente describir ese algoritmo. El algoritmo CryptoNight en sí REQUIERE un análisis profundo. Cuando leí esto, tartamudeé. ¿Debería la inversión crecer al menos linealmente con el poder, o debería ¿La inversión crece como máximo linealmente con el poder? Y entonces me di cuenta; Yo, como minero o inversor, suelo pensar en "¿cuánta energía puedo obtener?" para una inversión?" no "¿cuánta inversión se requiere para una cantidad fija de energía?" Por supuesto, denotamos la inversión por I y la potencia por P. Si I(P) es la inversión en función de la potencia y P(I) es el poder en función de la inversión, serán inversos entre sí (dondequiera que pueden existir inversas). Y si I (P) es más rápido que lineal, entonces P (I) es más lento que lineal. Por lo tanto, Habrá una tasa de rendimiento reducida para los inversores. Es decir, lo que aquí dice el autor es: "claro, a medida que inviertas más, obtendrás más poder. Pero deberíamos tratar de hacer de esto una tasa de retorno reducida". Las inversiones en CPU eventualmente tendrán un límite sublineal; la pregunta es si los autores Hemos diseñado un algoritmo POW que obligará a los ASIC a hacer también esto. ¿Una hipotética "moneda futura" debería extraerse siempre con los recursos más lentos/limitados? El artículo de Abadi et al (que tiene como autores a algunos ingenieros de Google y Microsoft) es, Básicamente, aprovechando el hecho de que durante los últimos años el tamaño de la memoria ha tenido una reducción mucho menor. entre máquinas que la velocidad del procesador, y con una relación inversión-potencia más que lineal. ¡En unos años esto habrá que reevaluarlo! Todo es una carrera armamentista... Construir una función hash es difícil; construir una función hash que satisfaga estas restricciones parece ser más difícil. Este artículo parece no tener ninguna explicación de la situación real. hashing algoritmo CryptoNight. Creo que es una implementación de SHA-3 con memoria dura, basada en publicaciones del foro pero no tengo idea... y ese es el punto. Hay que explicarlo.

propuso la solución más eficaz: “Hokkaido”. Hasta donde sabemos, el último trabajo basado en la idea de búsquedas pseudoaleatorias en una gran variedad es el algoritmo conocido como “scrypt” por C. Percival [32]. A diferencia de las funciones anteriores se centra en derivación de claves, y no sistemas proof-of-work. A pesar de este hecho, scrypt puede cumplir nuestro propósito: funciona bien como función de fijación de precios en el problema de conversión parcial hash, como SHA-256 en Bitcoin. A estas alturas, scrypt ya se ha aplicado en Litecoin [14] y algunas otras bifurcaciones Bitcoin. Sin embargo, su implementación no está realmente ligada a la memoria: la relación "tiempo de acceso a la memoria / tiempo total time” no es lo suficientemente grande porque cada instancia usa solo 128 KB. Esto permite a los mineros GPU ser aproximadamente 10 veces más efectivo y continúa dejando la posibilidad de crear relativamente Dispositivos de minería baratos pero altamente eficientes. Además, la propia construcción del scrypt permite un equilibrio lineal entre el tamaño de la memoria y el tamaño de la memoria. Velocidad de la CPU debido al hecho de que cada bloque en el scratchpad se deriva únicamente del anterior. Por ejemplo, puede almacenar cada segundo bloque y recalcular los demás de forma diferida, es decir, sólo cuando sea necesario. Se supone que los índices pseudoaleatorios están distribuidos uniformemente, por lo tanto, el valor esperado de los recálculos de los bloques adicionales es 1 \(2 \cdot N\), donde N es el número de iteraciones. El tiempo total de cálculo aumenta menos de la mitad porque también hay operaciones independientes del tiempo (tiempo constante), como preparar el scratchpad y hashing cada iteración. Ahorrar 2/3 de la memoria cuesta 1 \(3 \cdot N\)+1 3 \(\cdot\) \(2 \cdot N\) = N recálculos adicionales; 9/10 resultados en 1 \(10 \cdot N\)+. . . + 1 \(10 \cdot 9 \cdot N\) = 4,5N. Es fácil demostrar que almacenar sólo 1 s de todos los bloques aumenta el tiempo menos que por un factor de s-1 2 . Esto a su vez implica que una máquina con una CPU 200 veces más rápido que los chips modernos, pueden almacenar sólo 320 bytes del scratchpad. 5.2 El algoritmo propuesto Proponemos un nuevo algoritmo vinculado a memoria para la función de fijación de precios proof-of-work. se basa en acceso aleatorio a una memoria lenta y enfatiza la dependencia de la latencia. A diferencia de scrypt cada El nuevo bloque (64 bytes de longitud) depende de todos los bloques anteriores. Como resultado, una hipotética El “ahorro de memoria” debería aumentar exponencialmente su velocidad de cálculo. Nuestro algoritmo requiere alrededor de 2 Mb por instancia por los siguientes motivos: 1. Cabe en la caché L3 (por núcleo) de los procesadores modernos, que deberían convertirse en algo común. en unos años; 2. Un megabyte de memoria interna es un tamaño casi inaceptable para una tubería ASIC moderna; 3. Las GPU pueden ejecutar cientos de instancias simultáneas, pero están limitadas de otras maneras: La memoria GDDR5 es más lenta que la caché L3 de la CPU y destaca por su ancho de banda, no velocidad de acceso aleatorio. 4. Una expansión significativa del scratchpad requeriría un aumento en las iteraciones, lo que en turno implica un aumento general del tiempo. Las llamadas "pesadas" en una red p2p sin confianza pueden provocar vulnerabilidades graves, porque los nodos están obligados a verificar el proof-of-work de cada nuevo bloque. Si un nodo dedica una cantidad considerable de tiempo a cada evaluación hash, puede ser fácilmente DDoSed por una avalancha de objetos falsos con datos de trabajo arbitrarios (valores nonce). 12 propuso la solución más eficaz: “Hokkaido”. Hasta donde sabemos, el último trabajo basado en la idea de búsquedas pseudoaleatorias en una gran variedad es el algoritmo conocido como “scrypt” por C. Percival [32]. A diferencia de las funciones anteriores se centra en derivación de claves, y no sistemas proof-of-work. A pesar de este hecho, scrypt puede cumplir nuestro propósito: funciona bien como función de fijación de precios en el problema de conversión parcial hash, como SHA-256 en Bitcoin. A estas alturas, scrypt ya se ha aplicado en Litecoin [14] y algunas otras bifurcaciones Bitcoin. Sin embargo, su implementación no está realmente ligada a la memoria: la relación "tiempo de acceso a la memoria / tiempo total time” no es lo suficientemente grande porque cada instancia usa solo 128 KB. Esto permite a los mineros GPU ser aproximadamente 10 veces más efectivo y continúa dejando la posibilidad de crear relativamente Dispositivos de minería baratos pero altamente eficientes. Además, la propia construcción del scrypt permite un equilibrio lineal entre el tamaño de la memoria y el tamaño de la memoria. Velocidad de la CPU debido al hecho de que cada bloque en el scratchpad se deriva únicamente del anterior. Por ejemplo, puede almacenar cada segundo bloque y recalcular los demás de forma diferida, es decir, sólo cuando sea necesario. Se supone que los índices pseudoaleatorios están distribuidos uniformemente, por lo tanto, el valor esperado de los recálculos de los bloques adicionales es 1 \(2 \cdot N\), donden es el numero de iteraciones. El tiempo total de cálculo aumenta menos de la mitad porque también hay operaciones independientes del tiempo (tiempo constante), como preparar el bloc de notas y hashing cada iteración. Ahorrar 2/3 de la memoria cuesta 1 \(3 \cdot N\)+1 3 \(\cdot\) \(2 \cdot N\) = N recálculos adicionales; 9/10 resultados en 1 \(10 \cdot N\)+. . . + 1 \(10 \cdot 9 \cdot N\) = 4,5N. Es fácil demostrar que almacenar sólo 1 s de todos los bloques aumenta el tiempo menos que por un factor de s-1 2 . Esto a su vez implica que una máquina con una CPU 200 veces más rápido que los chips modernos, pueden almacenar sólo 320 bytes del scratchpad. 5.2 El algoritmo propuesto Proponemos un nuevo algoritmo vinculado a memoria para la función de fijación de precios proof-of-work. se basa en acceso aleatorio a una memoria lenta y enfatiza la dependencia de la latencia. A diferencia de scrypt cada El nuevo bloque (64 bytes de longitud) depende de todos los bloques anteriores. Como resultado, una hipotética El “ahorro de memoria” debería aumentar exponencialmente su velocidad de cálculo. Nuestro algoritmo requiere alrededor de 2 Mb por instancia por los siguientes motivos: 1. Cabe en la caché L3 (por núcleo) de los procesadores modernos, que deberían convertirse en algo común. en unos años; 2. Un megabyte de memoria interna es un tamaño casi inaceptable para una tubería ASIC moderna; 3. Las GPU pueden ejecutar cientos de instancias simultáneas, pero están limitadas de otras maneras: La memoria GDDR5 es más lenta que la caché L3 de la CPU y destaca por su ancho de banda, no velocidad de acceso aleatorio. 4. Una expansión significativa del scratchpad requeriría un aumento en las iteraciones, lo que en turno implica un aumento general del tiempo. Las llamadas "pesadas" en una red p2p sin confianza pueden provocar vulnerabilidades graves, porque los nodos están obligados a verificar el proof-of-work de cada nuevo bloque. Si un nodo dedica una cantidad considerable de tiempo a cada evaluación hash, puede ser fácilmente DDoSed por una avalancha de objetos falsos con datos de trabajo arbitrarios (valores nonce). 12 22 No importa, ¿es una moneda scrypt? ¿Dónde está el algoritmo? Lo único que veo es un anuncio. Aquí es donde Cryptonote, si su algoritmo PoW vale la pena, realmente brillará. no es Realmente SHA-256, no es realmente scrypt. Es nuevo, está vinculado a la memoria y no recursivo.

6 Otras ventajas 6.1 Emisión suave El límite superior para la cantidad total de monedas digitales CryptoNote es: MSupply = 264 −1 unidades atómicas. Esta es una restricción natural basada únicamente en los límites de implementación, no en la intuición. como “N monedas deberían ser suficientes para cualquiera”. Para garantizar la fluidez del proceso de emisión utilizamos la siguiente fórmula para el bloque recompensas: Recompensa base = (MSuministro −A) ≫18, donde A es la cantidad de monedas generadas previamente. 6.2 Parámetros ajustables 6.2.1 dificultad CryptoNote contiene un algoritmo de orientación que cambia la dificultad de cada bloque. esto disminuye el tiempo de reacción del sistema cuando la red hashrate crece o disminuye intensamente, preservando una tasa de bloqueo constante. El método original Bitcoin calcula la relación de real y el lapso de tiempo objetivo entre los últimos bloques de 2016 y lo utiliza como multiplicador para el actual dificultad. Obviamente, esto no es adecuado para recálculos rápidos (debido a la gran inercia) y produce oscilaciones. La idea general detrás de nuestro algoritmo es sumar todo el trabajo completado por los nodos y divídelo por el tiempo que han pasado. La medida del trabajo son los valores de dificultad correspondientes. en cada bloque. Pero debido a marcas de tiempo inexactas y que no son confiables, no podemos determinar la fecha exacta. intervalo de tiempo entre bloques. Un usuario puede cambiar su marca de tiempo al futuro y a la próxima vez. los intervalos pueden ser improbablemente pequeños o incluso negativos. Presumiblemente habrá pocos incidentes de este tipo, por lo que podemos simplemente ordenar las marcas de tiempo y eliminar los valores atípicos (es decir, 20%). el rango de el resto de valores es el tiempo que se dedicó al 80% de los bloques correspondientes. 6.2.2 Límites de tamaño Los usuarios pagan por almacenar el blockchain y tendrán derecho a votar por su tamaño. cada minero se ocupa del equilibrio entre equilibrar los costos y el beneficio de las tarifas y establece sus propios “límite suave” para crear bloques. Además, la regla básica para el tamaño máximo de bloque es necesaria para evitando que el blockchain se inunde con transacciones falsas; sin embargo, este valor debe no estar codificado. Sea MN el valor mediano de los últimos N tamaños de bloques. Entonces el “límite estricto” para el tamaño de aceptar bloques es \(2 \cdot M_N\). Evita que el blockchain se hinche pero aún permite que el límite crecer lentamente con el tiempo si es necesario. No es necesario limitar explícitamente el tamaño de la transacción. Está delimitado por el tamaño de un bloque; y si alguien quiere crear una transacción enorme con cientos de entradas/salidas (o con Debido al alto grado de ambigüedad en las firmas de anillos), puede hacerlo pagando una tarifa suficiente. 6.2.3 Penalización por exceso de tamaño Un minero todavía tiene la capacidad de llenar un bloque con sus propias transacciones sin tarifa hasta su máximo. tamaño \(2 \cdot M_b\). Aunque sólo la mayoría de los mineros pueden cambiar el valor medio, todavía hay una 13 6 Otras ventajas 6.1 Emisión suave El límite superior para la cantidad total de monedas digitales CryptoNote es: MSupply = 264 −1 unidades atómicas. Esta es una restricción natural basada únicamente en los límites de implementación, no en la intuición. como “N monedas deberían ser suficientes para cualquiera”. Para garantizar la fluidez del proceso de emisión utilizamos la siguiente fórmula para el bloque recompensas: Recompensa base = (MSuministro −A) ≫18, donde A es la cantidad de monedas generadas previamente. 6.2 Parámetros ajustables 6.2.1 dificultad CryptoNote contiene un algoritmo de orientación que cambia la dificultad de cada bloque. esto disminuye el tiempo de reacción del sistema cuando la hashrate de la red crece o disminuye intensamente, preservando una tasa de bloqueo constante. El método original Bitcoin calcula la relación de real y el lapso de tiempo objetivo entre los últimos bloques de 2016 y lo utiliza como multiplicador para el actual dificultad. Obviamente, esto no es adecuado para recálculos rápidos (debido a la gran inercia) y produce oscilaciones. La idea general detrás de nuestro algoritmo es sumar todo el trabajo completado por los nodos y divídelo por el tiempo que han pasado. La medida del trabajo son los valores de dificultad correspondientes. en cada bloque. Pero debido a marcas de tiempo inexactas y que no son confiables, no podemos determinar la fecha exacta. intervalo de tiempo entre bloques. Un usuario puede cambiar su marca de tiempo al futuro y a la próxima vez. los intervalos pueden ser improbablemente pequeños o incluso negativos. Presumiblemente habrá pocos incidentes de este tipo, por lo que podemos simplemente ordenar las marcas de tiempo y eliminar los valores atípicos (es decir, 20%). el rango de el resto de valores es el tiempo que se dedicó al 80% de los bloques correspondientes. 6.2.2 Límites de tamaño Los usuarios pagan por almacenar el blockchain y tendrán derecho a votar por su tamaño. cada minero se ocupa de la compensación entre equilibrare costos y beneﬁcios de las tarifas y establece sus propios “límite suave” para crear bloques. Además, la regla básica para el tamaño máximo de bloque es necesaria para evitando que el blockchain se inunde con transacciones falsas; sin embargo, este valor debe no estar codificado. Sea MN el valor mediano de los últimos N tamaños de bloques. Entonces el “límite estricto” para el tamaño de aceptar bloques es \(2 \cdot M_N\). Evita que el blockchain se hinche pero aún permite que el límite crecer lentamente con el tiempo si es necesario. No es necesario limitar explícitamente el tamaño de la transacción. Está delimitado por el tamaño de un bloque; y si alguien quiere crear una transacción enorme con cientos de entradas/salidas (o con Debido al alto grado de ambigüedad en las firmas de anillos), puede hacerlo pagando una tarifa suficiente. 6.2.3 Penalización por exceso de tamaño Un minero todavía tiene la capacidad de llenar un bloque con sus propias transacciones sin tarifa hasta su máximo. tamaño \(2 \cdot M_b\). Aunque sólo la mayoría de los mineros pueden cambiar el valor medio, todavía hay una 13 23 Unidades atómicas. Me gusta eso. ¿Es este el equivalente de Satoshis? Si es así, eso significa que habrá 185 mil millones de criptomonedas. Sé que esto, eventualmente, debe modificarse en unas pocas páginas, ¿o tal vez hay un error tipográfico? Si la recompensa base es "todas las monedas restantes", entonces sólo un bloque es suficiente para obtener todas las monedas. Instamina. Por otro lado, si se supone que esto es proporcional de algún modo a la ¿Diferencia de tiempo entre ahora y alguna fecha de terminación de la producción de monedas? eso seria tiene sentido. Además, en mi mundo, dos signos mayores que este significan "mucho mayor que". ¿El autor ¿posiblemente signifique algo más? Si el ajuste a la dificultad ocurre en cada bloque, entonces un atacante podría tener una granja muy grande de Las máquinas extraen dentro y fuera en intervalos de tiempo cuidadosamente elegidos. Esto podría causar una explosión caótica (o una caída a cero) en dificultad, si las fórmulas de ajuste de dificultad no se amortiguan adecuadamente. No hay duda de que el método de Bitcoin no es adecuado para recálculos rápidos, pero la idea de inercia en estos sistemas sería necesario demostrarlo, no darlo por sentado. Además, las oscilaciones en la red la dificultad no es necesariamente un problema a menos que resulte en oscilaciones de suministro de monedas, y tener una dificultad que cambia muy rápidamente podría causar una "corrección excesiva". El tiempo invertido, especialmente en un lapso corto como unos pocos minutos, será proporcional al "total número de bloques creados en la red." La constante de proporcionalidad crecerá en sí misma. con el tiempo, presumiblemente de manera exponencial si CN despega. Puede ser una mejor idea simplemente ajustar la dificultad para mantener "los bloques totales creados en el red desde que se agregó el último bloque a la cadena principal" dentro de algún valor constante, o con variación acotada o algo así. Si un algoritmo adaptativo que es computacionalmente Si se puede determinar si es fácil de implementar, esto parecería resolver el problema. Pero entonces, si usáramos ese método, alguien con una gran granja minera podría cerrarla. durante unas horas y vuelva a encenderlo. Durante las primeras cuadras, esa granja hará banco. Entonces, en realidad, este método traería a colación un punto interesante: la minería se convierte (en promedio) en una perder el juego sin retorno de la inversión, especialmente a medida que más personas se conectan a la red. Si la dificultad minera seguimiento muy de cerca de la red hashrate, de alguna manera dudo que la gente extraiga tanto como actualmente lo hago. O, por otro lado, en lugar de mantener sus granjas mineras funcionando las 24 horas del día, los 7 días de la semana, pueden convertirlas en encendido por 6 horas, apagado por 2, encendido por 6, apagado por 2, o algo así. Simplemente cambia a otra moneda durante unas horas, espera a que disminuya la dificultad y luego vuelve a subir para ganar esos pocos puntos extra. bloques de rentabilidad a medida que la red se adapta. ¿Y sabes qué? En realidad esto es probablemente Uno de los mejores escenarios de minería en los que he pensado... Esto podría ser circular, pero si el tiempo de creación del bloque promedia aproximadamente un minuto, ¿podemos simplemente ¿Utiliza el número de bloques como indicador del "tiempo invertido?"

6 Otras ventajas 6.1 Emisión suave El límite superior para la cantidad total de monedas digitales CryptoNote es: MSupply = 264 −1 unidades atómicas. Esta es una restricción natural basada únicamente en los límites de implementación, no en la intuición. como “N monedas deberían ser suficientes para cualquiera”. Para garantizar la fluidez del proceso de emisión utilizamos la siguiente fórmula para el bloque recompensas: Recompensa base = (MSuministro −A) ≫18, donde A es la cantidad de monedas generadas previamente. 6.2 Parámetros ajustables 6.2.1 dificultad CryptoNote contiene un algoritmo de orientación que cambia la dificultad de cada bloque. esto Disminuye el tiempo de reacción del sistema cuando la velocidad de la red hash crece o disminuye intensamente. preservando una tasa de bloqueo constante. El método original Bitcoin calcula la relación de real y el lapso de tiempo objetivo entre los últimos bloques de 2016 y lo utiliza como multiplicador para el actual dificultad. Obviamente, esto no es adecuado para recálculos rápidos (debido a la gran inercia) y produce oscilaciones. La idea general detrás de nuestro algoritmo es sumar todo el trabajo completado por los nodos y divídelo por el tiempo que han pasado. La medida del trabajo son los valores de dificultad correspondientes. en cada bloque. Pero debido a marcas de tiempo inexactas y que no son confiables, no podemos determinar la fecha exacta. intervalo de tiempo entre bloques. Un usuario puede cambiar su marca de tiempo al futuro y a la próxima vez. los intervalos pueden ser improbablemente pequeños o incluso negativos. Presumiblemente habrá pocos incidentes de este tipo, por lo que podemos simplemente ordenar las marcas de tiempo y eliminar los valores atípicos (es decir, 20%). el rango de el resto de valores es el tiempo que se dedicó al 80% de los bloques correspondientes. 6.2.2 Límites de tamaño Los usuarios pagan por almacenar el blockchain y tendrán derecho a votar por su tamaño. cada minero se ocupa del equilibrio entre equilibrar los costos y el beneficio de las tarifas y establece sus propios “límite suave” para crear bloques. Además, la regla básica para el tamaño máximo de bloque es necesaria para evitando que el blockchain se inunde con transacciones falsas; sin embargo, este valor debe no estar codificado. Sea MN el valor mediano de los últimos N tamaños de bloques. Entonces el “límite estricto” para el tamaño de aceptar bloques es \(2 \cdot M_N\). Evita que el blockchain se hinche pero aún permite que el límite crecer lentamente con el tiempo si es necesario. No es necesario limitar explícitamente el tamaño de la transacción. Está delimitado por el tamaño de un bloque; y si alguien quiere crear una transacción enorme con cientos de entradas/salidas (o con Debido al alto grado de ambigüedad en las firmas de anillos), puede hacerlo pagando una tarifa suficiente. 6.2.3 Penalización por exceso de tamaño Un minero todavía tiene la capacidad de llenar un bloque con sus propias transacciones sin tarifa hasta su máximo. tamaño \(2 \cdot M_b\). Aunque sólo la mayoría de los mineros pueden cambiar el valor medio, todavía hay una 13 6 Otras ventajas 6.1 Emisión suave El límite superior para la cantidad total de monedas digitales CryptoNote es: MSupply = 264 −1 unidades atómicas. Esta es una restricción natural basada únicamente en los límites de implementación, no en la intuición. como “N monedas deberían ser suficientes para cualquiera”. Para garantizar la fluidez del proceso de emisión utilizamos la siguiente fórmula para el bloque recompensas: Recompensa base = (MSuministro −A) ≫18, donde A es la cantidad de monedas generadas previamente. 6.2 Parámetros ajustables 6.2.1 dificultad CryptoNote contiene un algoritmo de orientación que cambia la dificultad de cada bloque. esto Disminuye el tiempo de reacción del sistema cuando la hashrate de la red crece o disminuye intensamente. preservando una tasa de bloqueo constante. El método original Bitcoin calcula la relación de real y el lapso de tiempo objetivo entre los últimos bloques de 2016 y lo utiliza como multiplicador para el actual dificultad. Obviamente, esto no es adecuado para recálculos rápidos (debido a la gran inercia) y produce oscilaciones. La idea general detrás de nuestro algoritmo es sumar todo el trabajo completado por los nodos y divídelo por el tiempo que han pasado. La medida del trabajo son los valores de dificultad correspondientes. en cada bloque. Pero debido a marcas de tiempo inexactas y que no son confiables, no podemos determinar la fecha exacta. intervalo de tiempo entre bloques. Un usuario puede cambiar su marca de tiempo al futuro y a la próxima vez. los intervalos pueden ser improbablemente pequeños o incluso negativos. Presumiblemente habrá pocos incidentes de este tipo, por lo que podemos simplemente ordenar las marcas de tiempo y eliminar los valores atípicos (es decir, 20%). el rango de el resto de valores es el tiempo que se dedicó al 80% de los bloques correspondientes. 6.2.2 Límites de tamaño Los usuarios pagan por almacenar el blockchain y tendrán derecho a votar por su tamaño. cada minero se ocupa de la compensación entre equilibrare costos y beneﬁcios de las tarifas y establece sus propios “límite suave” para crear bloques. Además, la regla básica para el tamaño máximo de bloque es necesaria para evitando que el blockchain se inunde con transacciones falsas; sin embargo, este valor debe no estar codificado. Sea MN el valor mediano de los últimos N tamaños de bloques. Entonces el “límite estricto” para el tamaño de aceptar bloques es \(2 \cdot M_N\). Evita que el blockchain se hinche pero aún permite que el límite crecer lentamente con el tiempo si es necesario. No es necesario limitar explícitamente el tamaño de la transacción. Está delimitado por el tamaño de un bloque; y si alguien quiere crear una transacción enorme con cientos de entradas/salidas (o con Debido al alto grado de ambigüedad en las firmas de anillos), puede hacerlo pagando una tarifa suficiente. 6.2.3 Penalización por exceso de tamaño Un minero todavía tiene la capacidad de llenar un bloque con sus propias transacciones sin tarifa hasta su máximo. tamaño \(2 \cdot M_b\). Aunque sólo la mayoría de los mineros pueden cambiar el valor medio, todavía hay una 13 24 Bien, entonces tenemos un blockchain, y cada bloque tiene marcas de tiempo ADEMÁS de simplemente ser ordenado. Esto se insertó claramente simplemente para dificultar el ajuste, porque las marcas de tiempo son muy poco confiable, como se mencionó. ¿Se nos permite tener marcas de tiempo contradictorias en la cadena? Si el bloque A viene antes que el bloque B en la cadena, y todo es consistente en términos financieros, ¿Pero el bloque A parece haber sido creado después del bloque B? Porque, tal vez, alguien poseía una gran parte de la red? ¿Está bien? Probablemente porque las finanzas no están arruinadas. Bien, odio este arbitrario "sólo el 80% de los bloques son legítimos para el blockchain principal" enfoque. ¿Tenía la intención de evitar que los mentirosos modificaran sus marcas de tiempo? Pero ahora añade incentivo para que todos mientan sobre sus marcas de tiempo y simplemente elijan la mediana. Por favor defina. Lo que significa "para este bloque, solo incluya transacciones que incluyan tarifas mayores superior al p%, preferentemente con tarifas superiores al 2p%" o algo así? ¿Qué quieren decir con falso? Si la transacción es consistente con la historia pasada de la blockchain, y la transacción incluye tarifas que satisfacen a los mineros, ¿no es suficiente? Bueno, no, no necesariamente. Si no existe un tamaño de bloque máximo, no hay nada que pueda mantener a un usuario malintencionado desde simplemente cargar un bloque masivo de transacciones a sí mismo de una vez solo para reducir la velocidad la red. Una regla básica para el tamaño máximo de bloque evita que las personas coloquen enormes cantidades de basura datos en el blockchain todos a la vez solo para ralentizar las cosas. Pero tal norma ciertamente tiene que ser adaptable: durante la temporada navideña, por ejemplo, podríamos esperar que el tráfico aumente, y el tamaño del bloque se vuelve muy grande, e inmediatamente después, para que el tamaño del bloque disminuya posteriormente otra vez. Entonces necesitamos a) algún tipo de límite adaptativo ob) un límite lo suficientemente grande como para que el 99% de Los picos navideños razonables no rompen el límite. Por supuesto, ese segundo es imposible de estimación: ¿quién sabe si una moneda tendrá éxito? Es mejor hacerlo adaptable y no preocuparse. al respecto. Pero entonces tenemos un problema de teoría del control: ¿cómo hacer que esto sea adaptativo sin ¿Vulnerabilidad al ataque u oscilaciones salvajes y locas? Observe que un método adaptativo no impide que los usuarios malintencionados acumulen pequeñas cantidades de datos basura a lo largo del tiempo en el blockchain para causar hinchazón a largo plazo. Este es un tema diferente en conjunto y uno con el que las criptomonedas tienen serios problemas.

6 Otras ventajas 6.1 Emisión suave El límite superior para la cantidad total de monedas digitales CryptoNote es: MSupply = 264 −1 unidades atómicas. Esta es una restricción natural basada únicamente en los límites de implementación, no en la intuición. como “N monedas deberían ser suficientes para cualquiera”. Para garantizar la fluidez del proceso de emisión utilizamos la siguiente fórmula para el bloque recompensas: Recompensa base = (MSuministro −A) ≫18, donde A es la cantidad de monedas generadas previamente. 6.2 Parámetros ajustables 6.2.1 dificultad CryptoNote contiene un algoritmo de orientación que cambia la dificultad de cada bloque. esto disminuye el tiempo de reacción del sistema cuando la hashrate de la red crece o disminuye intensamente, preservando una tasa de bloqueo constante. El método original Bitcoin calcula la relación de real y el lapso de tiempo objetivo entre los últimos bloques de 2016 y lo utiliza como multiplicador para el actual dificultad. Obviamente, esto no es adecuado para recálculos rápidos (debido a la gran inercia) y produce oscilaciones. La idea general detrás de nuestro algoritmo es sumar todo el trabajo completado por los nodos y divídelo por el tiempo que han pasado. La medida del trabajo son los valores de dificultad correspondientes. en cada bloque. Pero debido a marcas de tiempo inexactas y que no son confiables, no podemos determinar la fecha exacta. intervalo de tiempo entre bloques. Un usuario puede cambiar su marca de tiempo al futuro y a la próxima vez. los intervalos pueden ser improbablemente pequeños o incluso negativos. Presumiblemente habrá pocos incidentes de este tipo, por lo que podemos simplemente ordenar las marcas de tiempo y eliminar los valores atípicos (es decir, 20%). el rango de el resto de valores es el tiempo que se dedicó al 80% de los bloques correspondientes. 6.2.2 Límites de tamaño Los usuarios pagan por almacenar el blockchain y tendrán derecho a votar por su tamaño. cada minero se ocupa del equilibrio entre equilibrar los costos y el beneficio de las tarifas y establece sus propios “límite suave” para crear bloques. Además, la regla básica para el tamaño máximo de bloque es necesaria para evitando que el blockchain se inunde con transacciones falsas; sin embargo, este valor debe no estar codificado. Sea MN el valor mediano de los últimos N tamaños de bloques. Entonces el “límite estricto” para el tamaño de aceptar bloques es \(2 \cdot M_N\). Evita que el blockchain se hinche pero aún permite que el límite crecer lentamente con el tiempo si es necesario. No es necesario limitar explícitamente el tamaño de la transacción. Está delimitado por el tamaño de un bloque; y si alguien quiere crear una transacción enorme con cientos de entradas/salidas (o con Debido al alto grado de ambigüedad en las firmas de anillos), puede hacerlo pagando una tarifa suficiente. 6.2.3 Penalización por exceso de tamaño Un minero todavía tiene la capacidad de llenar un bloque con sus propias transacciones sin tarifa hasta su máximo. tamaño \(2 \cdot M_b\). Aunque sólo la mayoría de los mineros pueden cambiar el valor medio, todavía hay una 13 6 Otras ventajas 6.1 Emisión suave El límite superior para la cantidad total de monedas digitales CryptoNote es: MSupply = 264 −1 unidades atómicas. Esta es una restricción natural basada únicamente en los límites de implementación, no en la intuición. como “N monedas deberían ser suficientes para cualquiera”. Para garantizar la fluidez del proceso de emisión utilizamos la siguiente fórmula para el bloque recompensas: Recompensa base = (MSuministro −A) ≫18, donde A es la cantidad de monedas generadas previamente. 6.2 Parámetros ajustables 6.2.1 dificultad CryptoNote contiene un algoritmo de orientación que cambia la dificultad de cada bloque. esto Disminuye el tiempo de reacción del sistema cuando la hashrate de la red crece o disminuye intensamente. preservando una tasa de bloqueo constante. El método original Bitcoin calcula la relación de real y el lapso de tiempo objetivo entre los últimos bloques de 2016 y lo utiliza como multiplicador para el actual dificultad. Obviamente, esto no es adecuado para recálculos rápidos (debido a la gran inercia) y produce oscilaciones. La idea general detrás de nuestro algoritmo es sumar todo el trabajo completado por los nodos y divídelo por el tiempo que han pasado. La medida del trabajo son los valores de dificultad correspondientes. en cada bloque. Pero debido a marcas de tiempo inexactas y que no son confiables, no podemos determinar la fecha exacta. intervalo de tiempo entre bloques. Un usuario puede cambiar su marca de tiempo al futuro y a la próxima vez. los intervalos pueden ser improbablemente pequeños o incluso negativos. Presumiblemente habrá pocos incidentes de este tipo, por lo que podemos simplemente ordenar las marcas de tiempo y eliminar los valores atípicos (es decir, 20%). el rango de el resto de valores es el tiempo que se dedicó al 80% de los bloques correspondientes. 6.2.2 Límites de tamaño Los usuarios pagan por almacenar el blockchain y tendrán derecho a votar por su tamaño. cada minero se ocupa de la compensación entre equilibrare costos y beneﬁcios de las tarifas y establece sus propios “límite suave” para crear bloques. Además, la regla básica para el tamaño máximo de bloque es necesaria para evitando que el blockchain se inunde con transacciones falsas; sin embargo, este valor debe no estar codificado. Sea MN el valor mediano de los últimos N tamaños de bloques. Entonces el “límite estricto” para el tamaño de aceptar bloques es \(2 \cdot M_N\). Evita que el blockchain se hinche pero aún permite que el límite crecer lentamente con el tiempo si es necesario. No es necesario limitar explícitamente el tamaño de la transacción. Está delimitado por el tamaño de un bloque; y si alguien quiere crear una transacción enorme con cientos de entradas/salidas (o con Debido al alto grado de ambigüedad en las firmas de anillos), puede hacerlo pagando una tarifa suficiente. 6.2.3 Penalización por exceso de tamaño Un minero todavía tiene la capacidad de llenar un bloque con sus propias transacciones sin tarifa hasta su máximo. tamaño \(2 \cdot M_b\). Aunque sólo la mayoría de los mineros pueden cambiar el valor medio, todavía hay una 13 25 Al reescalar el tiempo para que una unidad de tiempo sea N bloques, el tamaño promedio de bloque aún podría, en teoría, crecer exponencialmente proporcionalmente a 2ˆt. Por otra parte, un límite más general en el siguiente bloque sería M_nf(M_n) para alguna función f. ¿Qué propiedades de f ¿Elegimos para garantizar un "crecimiento razonable" del tamaño del bloque? La progresión de Los tamaños de bloque (después del tiempo de reescalado) serían así: 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( ... Y el objetivo aquí es elegir f tal que esta secuencia no crezca más rápido que, digamos, linealmente, o quizás incluso como Log(t). Por supuesto, si f(M_n) = a para alguna constante a, esta secuencia es en realidad M_n aM_n aˆ2M_n aˆ3M_n ... Y, por supuesto, la única manera de limitar esto a un crecimiento lineal como máximo es eligiendo a=1. Por supuesto, esto es inviable. No permite ningún crecimiento. Si, por el contrario, f(M_n) es una función no constante, entonces la situación es mucho más complicada. complicado y puede permitir una solución elegante. Pensaré en esto por un tiempo. Esta tarifa tendrá que ser lo suficientemente grande como para descontar la penalización por exceso de tamaño de la siguiente sección. ¿Por qué se supone que un usuario general es hombre, eh? ¿Eh?

posibilidad de inflar el blockchain y producir una carga adicional en los nodos. para desalentar Para que los participantes malévolos creen bloques grandes, introducimos una función de penalización: NuevaRecompensa = Recompensa Base \(\cdot\) Tamaño negro manganeso −1 2 Esta regla se aplica sólo cuando BlkSize es mayor que el tamaño mínimo de bloque libre que debería estar cerca del máximo (10kb, \(M_N \cdot 110\%\)). A los mineros se les permite crear bloques de "tamaño habitual" e incluso excederlo con utilidades cuando los honorarios globales superen la multa. Pero es poco probable que las tarifas aumenten cuadráticamente diferente del valor de la penalización, por lo que habrá un equilibrio. 6.3 Guiones de transacciones CryptoNote tiene un subsistema de secuencias de comandos muy minimalista. Un remitente especifica una expresión Φ = f (x1, x2, . . . , xn), donde n es el número de claves públicas de destino {Pi}n yo=1. Sólo cinco binarios Se admiten operadores: mínimo, máximo, suma, mul y cmp. Cuando el receptor gasta este pago, produce \(0 \leq k \leq n\) firmas y las pasa a la entrada de la transacción. El proceso de verificación simplemente evalúa Φ con xi = 1 para verificar si hay una firma válida para la clave pública Pi, y xi = 0. Un verificador acepta la prueba si ﬀΦ > 0. A pesar de su simplicidad, este enfoque cubre todos los casos posibles: • Firma multiumbral/umbral. Para la firma múltiple “M-out-of-N” de estilo Bitcoin (es decir, el receptor debe proporcionar al menos \(0 \leq M \leq N\) firmas válidas) Φ = x1+x2+. . .+xN \(\geq M\) (Para mayor claridad estamos usando notación algebraica común). La firma del umbral ponderado (algunas claves pueden ser más importantes que otras) podría expresarse como Φ = \(w_1 \cdot x_1\) + \(w_2 \cdot x_2\) + . . . + \(w_N \cdot x_N\) \(\geq wM\). Y escenario donde la llave maestra corresponde a Φ = máx(\(M \cdot x\), x1 + x2 + . . . + xN) \(\geq M\). Es fácil demostrar que cualquier caso sofisticado puede ser expresados con estos operadores, es decir, forman base. • Protección por contraseña. La posesión de una contraseña secreta equivale al conocimiento de una clave privada, derivada de manera determinista de la contraseña: k = KDF(s). Por tanto, un receptor puede demostrar que conoce la contraseña aportando otra firma bajo la clave k. El remitente simplemente agrega la clave pública correspondiente a su propia salida. Tenga en cuenta que esto El método es mucho más seguro que el "rompecabezas de transacciones" utilizado en Bitcoin [13], donde el La contraseña se pasa explícitamente en las entradas. • Casos degenerados. Φ = 1 significa que cualquiera puede gastar el dinero; Φ = 0 marca el la producción no se puede gastar para siempre. En el caso de que el script de salida combinado con claves públicas sea demasiado grande para un remitente, él Puede utilizar un tipo de salida especial, que indica que el destinatario pondrá estos datos en su entrada. mientras que el remitente proporciona solo un hash del mismo. Este enfoque es similar al “pago a hash” de Bitcoin. característica, pero en lugar de agregar nuevos comandos de script, manejamos este caso en la estructura de datos nivel. 7 Conclusión Hemos investigado los principales defectos de Bitcoin y hemos propuesto algunas posibles soluciones. Estas características ventajosas y nuestro desarrollo continuo hacen que el nuevo sistema de efectivo electrónico CryptoNote un serio rival de Bitcoin, superando a todas sus bifurcaciones. 14 posibilidad de inflar el blockchain y producir una carga adicional en los nodos. para desalentar Para que los participantes malévolos creen bloques grandes, introducimos una función de penalización: NuevaRecompensa = Recompensa Base \(\cdot\) Tamaño negro manganeso −1 2 Esta regla se aplica sólo cuando BlkSize es mayor que el tamaño mínimo de bloque libre que debería estar cerca del máximo (10kb, \(M_N \cdot 110\%\)). A los mineros se les permite crear bloques de "tamaño habitual" e incluso excederlo con utilidades cuando los honorarios globales superen la multa. Pero es poco probable que las tarifas aumenten cuadráticamente diferente del valor de la penalización, por lo que habrá un equilibrio. 6.3 Guiones de transacciones CryptoNote tiene un subsistema de secuencias de comandos muy minimalista. Un remitente especifica una expresión Φ = f (x1, x2, . . . , xn), donde n es el número de claves públicas de destino {Pi}n yo=1. Sólo cinco binarios Se admiten operadores: mínimo, máximo, suma, mul y cmp. Cuando el receptor gasta este pago, produce \(0 \leq k \leq n\) firmas y las pasa a la entrada de la transacción. El proceso de verificación simplemente evalúa Φ con xi = 1 para verificar si hay una firma válida para la clave pública Pi, y xi = 0. Un verificador acepta la prueba si ﬀΦ > 0. A pesar de su simplicidad, este enfoque cubre todos los casos posibles: • Firma multiumbral/umbral. Para la firma múltiple “M-out-of-N” de estilo Bitcoin (es decir, el receptor debe proporcionar al menos \(0 \leq M \leq N\) firmas válidas) Φ = x1+x2+. . .+xN \(\geq M\) (Para mayor claridad estamos usando notación algebraica común). La firma del umbral ponderado (algunas claves pueden ser más importantes que otras) podría expresarse como Φ = \(w_1 \cdot x_1\) + \(w_2 \cdot x_2\) + . . . + \(w_N \cdot x_N\) \(\geq wM\). y escenarioio donde la clave maestra corresponde a Φ = máx(\(M \cdot x\), x1 + x2 + . . . + xN) \(\geq M\). Es fácil demostrar que cualquier caso sofisticado puede ser expresados con estos operadores, es decir, forman base. • Protección por contraseña. La posesión de una contraseña secreta equivale al conocimiento de una clave privada, derivada de manera determinista de la contraseña: k = KDF(s). Por tanto, un receptor puede demostrar que conoce la contraseña aportando otra firma bajo la clave k. El remitente simplemente agrega la clave pública correspondiente a su propia salida. Tenga en cuenta que esto El método es mucho más seguro que el "rompecabezas de transacciones" utilizado en Bitcoin [13], donde el La contraseña se pasa explícitamente en las entradas. • Casos degenerados. Φ = 1 significa que cualquiera puede gastar el dinero; Φ = 0 marca el la producción no se puede gastar para siempre. En el caso de que el script de salida combinado con claves públicas sea demasiado grande para un remitente, él Puede utilizar un tipo de salida especial, que indica que el destinatario pondrá estos datos en su entrada. mientras que el remitente proporciona solo un hash del mismo. Este enfoque es similar al “pago a hash” de Bitcoin. característica, pero en lugar de agregar nuevos comandos de script, manejamos este caso en la estructura de datos nivel. 7 Conclusión Hemos investigado los principales defectos de Bitcoin y hemos propuesto algunas posibles soluciones. Estas características ventajosas y nuestro desarrollo continuo hacen que el nuevo sistema de efectivo electrónico CryptoNote un serio rival de Bitcoin, superando a todas sus bifurcaciones. 14 26 Esto puede ser innecesario si podemos encontrar una manera de limitar el tamaño del bloque a lo largo del tiempo... Esto tampoco puede ser correcto. Simplemente configuraron "NewReward" en una parábola orientada hacia arriba donde El tamaño del bloque es la variable independiente. Entonces la nueva recompensa explota hasta el infinito. Si por el otro Por otro lado, la nueva recompensa es Max(0,Base Reward(1-(BlkSize/Mn - 1)ˆ2)), luego la nueva recompensa sería una parábola orientada hacia abajo con pico en el tamaño del bloque = Mn, y con intersecciones en Tamaño de bloque = 0 y Tamaño de bloque = 2Mn. Y eso parece ser lo que intentan describir. Sin embargo, esto no

Analysis

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

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

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

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

Análisis

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

5 No es que importe demasiado que mil millones de personas en el mundo vivan con menos de un dólar al año. día y no tengo esperanzas de participar alguna vez en ningún tipo de red minera... pero una economía Un mundo impulsado por un sistema monetario p2p con una CPU, un voto sería, presumiblemente, más más justo que un sistema impulsado por la banca de reserva fraccionaria. Pero el protocolo de Cryptonote todavía requiere un 51% de usuarios honestos... ver, por ejemplo, Cryptonote foros donde uno de los desarrolladores, Pliskov, dice que un ataque tradicional de reemplazo de datos en elblockchain 51% aún puede funcionar. https://forum.cryptonote.org/viewtopic.php?f=2&t=198 Tenga en cuenta que realmente no necesita un 51% de usuarios honestos. Realmente no necesitas "ni un solo deshonesto facción con más del 51% del hashing poder de la red." Llamemos a este llamado problema del bitcoin "rigidez adaptativa". La solución de Cryptonote para la adaptación La rigidez es la flexibilidad adaptativa en los valores de los parámetros del protocolo. Si necesitas tamaños de bloque más grandes, No hay problema, la red se habrá estado ajustando suavemente todo el tiempo. Es decir, la forma en que Bitcoin ajusta la dificultad a lo largo del tiempo se puede replicar en todo nuestro protocolo parámetros de modo que no sea necesario obtener el consenso de la red para actualizar el protocolo. Superficialmente esto parece una buena idea, pero sin una cuidadosa previsión, una solución autoajustable El sistema puede volverse bastante impredecible y caótico. Analizaremos esto más adelante a medida que surgen oportunidades. Los "buenos" sistemas están en algún punto entre adaptativamente rígidos y adaptativamente flexibles, y tal vez incluso la rigidez misma, son adaptativas. Si realmente tuviéramos "una CPU, un voto", entonces colaboraríamos y desarrollaríamos grupos para llegar al 51 %. Sería más difícil. Esperaríamos que todas las CPU del mundo estuvieran minando, desde teléfonos a la CPU integrada de su Tesla mientras se está cargando. http://en.wikipedia.org/wiki/Pareto_principle Sostengo que el equilibrio de Pareto es algo inevitable. O el 20% del sistema poseerá el 80% de las CPU, o el 20% del sistema poseerá el 80% de los ASIC. Mi hipótesis es esto porque la distribución subyacente de la riqueza en la sociedad ya muestra la distribución de Pareto, y a medida que se unen nuevos mineros, se extraen de esa distribución subyacente. Sin embargo, sostengo que los protocolos con una CPU, un voto generarán un retorno de la inversión en el hardware. Bloquear La recompensa por nodo será más proporcional al número de nodos en la red porque La distribución del rendimiento entre los nodos será mucho más ajustada. Bitcoin, por otro Por otro lado, ve una recompensa de bloque (por nodo) más proporcional a la capacidad computacional de ese nodo. Es decir, sólo los "grandes" siguen en el juego de la minería. Por otra parte, Aunque el principio de Pareto seguirá en vigor, en un mundo de una CPU, un voto, todos participa en la seguridad de la red y obtiene algunos ingresos mineros. En un mundo ASIC, no tiene sentido conectar todos los XBox y teléfonos móviles a los míos. En un mundo de una CPU, un voto, es muy sensato en términos de recompensa minera. Como deliciosa consecuencia, Obtener el 51% de los votos es más difícil cuando hay cada vez más votos, lo que arroja un resultado encantador. beneficio para la seguridad de la red.hardware descrito anteriormente. Supongamos que la tasa global hash disminuye significativamente, incluso para Por un momento, ahora puede usar su poder minero para bifurcar la cadena y gastar dos veces. Como veremos Más adelante en este artículo, no es improbable que ocurra el evento descrito anteriormente. 2.3 Emisión irregular Bitcoin tiene una tasa de emisión predeterminada: cada bloque resuelto produce una cantidad fija de monedas. Aproximadamente cada cuatro años esta recompensa se reduce a la mitad. La intención original era crear una emisión suave limitada con caída exponencial, pero de hecho tenemos una emisión lineal por partes función cuyos puntos de interrupción pueden causar problemas a la infraestructura Bitcoin. Cuando ocurre el punto de interrupción, los mineros comienzan a recibir solo la mitad del valor de su anterior recompensa. La diferencia absoluta entre 12,5 y 6,25 BTC (proyectada para el año 2020) puede parece tolerable. Sin embargo, al examinar la caída de 50 a 25 BTC que tuvo lugar en noviembre 28 de 2012, se consideró inapropiado para un número significativo de miembros de la comunidad minera. Figura 1 muestra una disminución dramática en la tasa hash de la red a fines de noviembre, exactamente cuando se produjo la reducción a la mitad. Este evento podría haber sido el momento perfecto para el individuo malévolo. descrito en la sección de funciones proof-of-work para llevar a cabo un ataque de doble gasto [36]. Fig. 1. Bitcoin hashtabla de tasas (fuente: http://bitcoin.sipa.be) 2.4 Constantes codificadas Bitcoin tiene muchos límites codificados, algunos de los cuales son elementos naturales del diseño original (p. ej. frecuencia de bloqueo, cantidad máxima de oferta monetaria, número de confirmaciones) mientras que otros Parecen limitaciones artificiales. No son tanto los límites, sino la incapacidad de cambiar rápidamente 3 hardware descrito anteriormente. Supongamos que la tasa global hash disminuye significativamente, incluso para Por un momento, ahora puede usar su poder minero para bifurcar la cadena y gastar dos veces. Como veremos Más adelante en este artículo, no es improbable que ocurra el evento descrito anteriormente. 2.3 Emisión irregular Bitcoin tiene una tasa de emisión predeterminada: cada bloque resuelto produce una cantidad fija de monedas. Aproximadamente cada cuatro años esta recompensa se reduce a la mitad. La intención original era crear una emisión suave limitada con caída exponencial, pero de hecho tenemos una emisión lineal por partes función cuyos puntos de interrupción pueden causar problemas a la infraestructura Bitcoin. Cuando ocurre el punto de interrupción, los mineros comienzan a recibir solo la mitad del valor de su anterior recompensa. La diferencia absoluta entre 12,5 y 6,25 BTC (proyectada para el año 2020) puede parece tolerable. Sin embargo, al examinar la caída de 50 a 25 BTC que tuvo lugar en noviembre 28 de 2012, se consideró inapropiado para un número significativo de miembros de la comunidad minera. Figura 1 muestra una disminución dramática en la tasa hash de la red a fines de noviembre, exactamente cuando se produjo la reducción a la mitad. Este evento podría haber sido el momento perfecto para el individuo malévolo. descrito en la sección de función proof-of-work para llevar a cabo un ataque de doble gasto [36]. Fig. 1. Bitcoin hashtabla de tasas (fuente: http://bitcoin.sipa.be) 2.4 Constantes codificadas Bitcoin tiene muchos límites codificados, algunos de los cuales son elementos naturales del diseño original (p. ej. frecuencia de bloqueo, cantidad máxima de oferta monetaria, número de confirmaciones) mientras que otros Parecen limitaciones artificiales. No son tanto los límites, sino la incapacidad de cambiar rápidamente 3 6 Llamemos a esto como es, un ataque zombie. Analicemos qué tan continua puede ser la emisión. relacionado con una CPU, un voto en un escenario de ataque zombie. En un mundo de una CPU, un voto, cada teléfono celular y automóvil, siempre que estén inactivos, estarían minando. Recolectar montones de hardware barato para crear una granja minera sería muy, muy fácil, porque solo Casi todo tiene una CPU. Por otro lado, en ese punto, la cantidad de CPU Creo que lo necesario para lanzar un ataque del 51% sería bastante sorprendente. Además, Precisamente porque sería fácil recolectar hardware barato, podemos esperar razonablemente una Mucha gente empieza a acumular cualquier cosa con una CPU. La carrera armamentista en un mundo de una CPU, un voto es necesariamente más igualitario que en un mundo ASIC. Por lo tanto, una discontinuidad en la red. La seguridad debido a las tasas de emisión debería ser un problema MENOR en un mundo de una CPU, un voto. Sin embargo, quedan dos hechos: 1) la discontinuidad en la tasa de emisión puede conducir a un efecto de tartamudeo en la economía y la seguridad de la red, lo cual es malo, y 2) a pesar de que un 51% de ataques realizado por alguien que recolecta hardware barato todavía puede ocurrir en una CPU-una-votar mundo, Parece que debería ser más difícil. Presumiblemente, la salvaguardia contra esto es que todos los actores deshonestos intentarán esto. simultáneamente, y volvemos a la noción de seguridad anterior de Bitcoin: "no requerimos facción para controlar más del 51% de la red". El autor afirma aquí que un problema con bitcoin es la discontinuidad en la emisión de monedas. La tasa podría provocar caídas repentinas en la participación de la red y, por lo tanto, en la seguridad de la red. Así, Es preferible una tasa de emisión de monedas continua, diferenciable y suave. El autor no se equivoca necesariamente. Cualquier tipo de disminución repentina en la participación en la red puede conducir a tal problema, y si podemos eliminar una fuente del mismo, deberíamos hacerlo. Dicho esto, es posible que largos períodos de emisión de monedas "relativamente constantes" puntuados por cambios repentinos es el camino ideal a seguir desde el punto de vista económico. No soy economista. Entonces, tal vez nosotros Debemos decidir si vamos a cambiar la seguridad de la red por algo económico: ¿qué hay aquí? http://arxiv.org/abs/1402.2009ellos si es necesario que causa los principales inconvenientes. Desafortunadamente, es difícil predecir cuándo Es posible que sea necesario cambiar las constantes y reemplazarlas puede tener consecuencias terribles. Un buen ejemplo de un cambio de límite codificado que conduce a consecuencias desastrosas es el bloque límite de tamaño establecido en 250kb1. Este límite era suficiente para albergar unas 10.000 transacciones estándar. en A principios de 2013, este límite casi se había alcanzado y se llegó a un acuerdo para aumentar el límite. El cambio se implementó en la versión 0.8 de la billetera y terminó con una división de la cadena de 24 bloques. y un exitoso ataque de doble gasto [9]. Si bien el error no estaba en el protocolo Bitcoin, pero más bien, en el motor de la base de datos, podría haberse detectado fácilmente mediante una simple prueba de estrés si hubiera No hay límite de tamaño de bloque introducido artificialmente. Las constantes también actúan como una forma de punto de centralización. A pesar de la naturaleza de igual a igual de Bitcoin, una abrumadora mayoría de nodos utilizan el cliente de referencia oficial [10] desarrollado por un pequeño grupo de personas. Este grupo toma la decisión de implementar cambios al protocolo y la mayoría de la gente acepta estos cambios independientemente de su “corrección”. Algunas decisiones provocaron discusiones acaloradas e incluso llamados al boicot [11], lo que indica que la comunidad y el Los desarrolladores pueden no estar de acuerdo en algunos puntos importantes. Por tanto, parece lógico disponer de un protocolo con variables configurables por el usuario y autoajustables como una posible forma de evitar estos problemas. 2.5 Guiones voluminosos El sistema de secuencias de comandos en Bitcoin es una característica pesada y compleja. Potencialmente permite crear transacciones sofisticadas [12], pero algunas de sus funciones están deshabilitadas debido a problemas de seguridad y algunos ni siquiera se han utilizado [13]. El guión (incluidas las partes del remitente y del receptor) para la transacción más popular en Bitcoin se ve así: OP DUP OP HASH160 OP EQUALVERIFY OP CHECKSIG. El script tiene una longitud de 164 bytes y su único propósito es comprobar si el receptor posee la clave secreta requerida para verificar su firma.