CryptoNote v2.0
Makalah yang disajikan di sini adalah whitepaper CryptoNote v2.0 karya Nicolas van Saberhagen (2013), yang mendeskripsikan fondasi kriptografi yang mendasari Monero. Ini bukan whitepaper khusus Monero — Monero diluncurkan pada tahun 2014 sebagai fork dari implementasi referensi CryptoNote (Bytecoin) dan sejak saat itu telah berkembang jauh melampaui protokol aslinya.
Introduction
Introduction
"Bitcoin" [1] has been a successful implementation of the concept of p2p electronic cash. Both professionals and the general public have come to appreciate the convenient combination of public transactions and proof-of-work as a trust model. Today, the user base of electronic cash is growing at a steady pace; customers are attracted to low fees and the anonymity provided by electronic cash and merchants value its predicted and decentralized emission. Bitcoin has effectively proved that electronic cash can be as simple as paper money and as convenient as credit cards. Unfortunately, Bitcoin suffers from several deficiencies. For example, the system's distributed nature is inflexible, preventing the implementation of new features until almost all of the network users update their clients. Some critical flaws that cannot be fixed rapidly deter Bitcoin's widespread propagation. In such inflexible models, it is more efficient to roll-out a new project rather than perpetually fix the original project. In this paper, we study and propose solutions to the main deficiencies of Bitcoin. We believe that a system taking into account the solutions we propose will lead to a healthy competition among different electronic cash systems. We also propose our own electronic cash, "CryptoNote", a name emphasizing the next breakthrough in electronic cash.
giriiş
“Bitcoin” [1], p2p elektronik nakit kavramının başarılı bir uygulaması olmuştur. Her ikisi de profesyoneller ve genel halk, aşağıdakilerin uygun kombinasyonunu takdir etmeye başladı halka açık işlemler ve güven modeli olarak proof-of-work. Günümüzde elektronik paranın kullanıcı tabanı istikrarlı bir hızla büyüyor; Müşteriler düşük ücretlerden ve sağlanan anonimlikten etkilenirler elektronik nakit ve tüccarlar tahmin edilen ve merkezi olmayan emisyona değer veriyor. Bitcoin var elektronik paranın kağıt para kadar basit ve kullanışlı olabileceğini etkili bir şekilde kanıtladı kredi kartları. Maalesef Bitcoin birçok eksiklikten muzdariptir. Örneğin, sistemin dağıtılmış doğası esnek değildir ve neredeyse tüm ağ kullanıcıları istemcilerini güncelleyinceye kadar yeni özelliklerin uygulanmasını engeller. Hızla düzeltilemeyen bazı kritik kusurlar Bitcoin'nin çalışmasını caydırır yaygın yayılma. Bu tür esnek olmayan modellerde yeni bir projenin hayata geçirilmesi daha verimlidir. Orijinal projeyi sürekli olarak düzeltmek yerine. Bu yazıda Bitcoin'nın ana eksikliklerini inceliyor ve bunlara çözümler öneriyoruz. inanıyoruz önerdiğimiz çözümleri dikkate alan bir sistemin sağlıklı bir rekabete yol açacağı farklı elektronik nakit sistemleri arasında. Ayrıca kendi elektronik paramız olan “CryptoNote”u da öneriyoruz. elektronik nakitte bir sonraki atılımı vurgulayan bir isim.
Bitcoin Drawbacks and Possible Solutions
Bitcoin Drawbacks and Possible Solutions
2 Bitcoin drawbacks and some possible solutions 2.1 Traceability of transactions Privacy and anonymity are the most important aspects of electronic cash. Peer-to-peer payments seek to be concealed from third party’s view, a distinct difference when compared with traditional banking. In particular, T. Okamoto and K. Ohta described six criteria of ideal electronic cash, which included “privacy: relationship between the user and his purchases must be untraceable by anyone” [30]. From their description, we derived two properties which a fully anonymous electronic cash model must satisfy in order to comply with the requirements outlined by Okamoto and Ohta: Untraceability: for each incoming transaction all possible senders are equiprobable. Unlinkability: for any two outgoing transactions it is impossible to prove they were sent to the same person. Unfortunately, Bitcoin does not satisfy the untraceability requirement. Since all the transactions that take place between the network’s participants are public, any transaction can be 1 CryptoNote v 2.0 Nicolas van Saberhagen October 17, 2013 1 Introduction “Bitcoin” [1] has been a successful implementation of the concept of p2p electronic cash. Both professionals and the general public have come to appreciate the convenient combination of public transactions and proof-of-work as a trust model. Today, the user base of electronic cash is growing at a steady pace; customers are attracted to low fees and the anonymity provided by electronic cash and merchants value its predicted and decentralized emission. Bitcoin has effectively proved that electronic cash can be as simple as paper money and as convenient as credit cards. Unfortunately, Bitcoin suffers from several deficiencies. For example, the system’s distributed nature is inflexible, preventing the implementation of new features until almost all of the network users update their clients. Some critical flaws that cannot be fixed rapidly deter Bitcoin’s widespread propagation. In such inflexible models, it is more efficient to roll-out a new project rather than perpetually fix the original project. In this paper, we study and propose solutions to the main deficiencies of Bitcoin. We believe that a system taking into account the solutions we propose will lead to a healthy competition among different electronic cash systems. We also propose our own electronic cash, “CryptoNote”, a name emphasizing the next breakthrough in electronic cash. 2 Bitcoin drawbacks and some possible solutions 2.1 Traceability of transactions Privacy and anonymity are the most important aspects of electronic cash. Peer-to-peer payments seek to be concealed from third party’s view, a distinct difference when compared with traditional banking. In particular, T. Okamoto and K. Ohta described six criteria of ideal electronic cash, which included “privacy: relationship between the user and his purchases must be untraceable by anyone” [30]. From their description, we derived two properties which a fully anonymous electronic cash model must satisfy in order to comply with the requirements outlined by Okamoto and Ohta: Untraceability: for each incoming transaction all possible senders are equiprobable. Unlinkability: for any two outgoing transactions it is impossible to prove they were sent to the same person. Unfortunately, Bitcoin does not satisfy the untraceability requirement. Since all the transactions that take place between the network’s participants are public, any transaction can be 1 3 Bitcoin definitely fails "untraceability." When I send you BTC, the wallet from which it is sent is irrevocably stamped on the blockchain. There is no question about who sent those funds, because only the knower of the private keys can send them.
unambiguously traced to a unique origin and final recipient. Even if two participants exchange funds in an indirect way, a properly engineered path-finding method will reveal the origin and final recipient. It is also suspected that Bitcoin does not satisfy the second property. Some researchers stated ([33, 35, 29, 31]) that a careful blockchain analysis may reveal a connection between the users of the Bitcoin network and their transactions. Although a number of methods are disputed [25], it is suspected that a lot of hidden personal information can be extracted from the public database. Bitcoin’s failure to satisfy the two properties outlined above leads us to conclude that it is not an anonymous but a pseudo-anonymous electronic cash system. Users were quick to develop solutions to circumvent this shortcoming. Two direct solutions were “laundering services” [2] and the development of distributed methods [3, 4]. Both solutions are based on the idea of mixing several public transactions and sending them through some intermediary address; which in turn suffers the drawback of requiring a trusted third party. Recently, a more creative scheme was proposed by I. Miers et al. [28]: “Zerocoin”. Zerocoin utilizes a cryptographic one-way accumulators and zero-knoweldge proofs which permit users to “convert” bitcoins to zerocoins and spend them using anonymous proof of ownership instead of explicit public-key based digital signatures. However, such knowledge proofs have a constant but inconvenient size - about 30kb (based on today’s Bitcoin limits), which makes the proposal impractical. Authors admit that the protocol is unlikely to ever be accepted by the majority of Bitcoin users [5]. 2.2 The proof-of-work function Bitcoin creator Satoshi Nakamoto described the majority decision making algorithm as “oneCPU-one-vote” and used a CPU-bound pricing function (double SHA-256) for his proof-of-work scheme. Since users vote for the single history of transactions order [1], the reasonableness and consistency of this process are critical conditions for the whole system. The security of this model suffers from two drawbacks. First, it requires 51% of the network’s mining power to be under the control of honest users. Secondly, the system’s progress (bug fixes, security fixes, etc...) require the overwhelming majority of users to support and agree to the changes (this occurs when the users update their wallet software) [6].Finally this same voting mechanism is also used for collective polls about implementation of some features [7]. This permits us to conjecture the properties that must be satisfied by the proof-of-work pricing function. Such function must not enable a network participant to have a significant advantage over another participant; it requires a parity between common hardware and high cost of custom devices. From recent examples [8], we can see that the SHA-256 function used in the Bitcoin architecture does not posses this property as mining becomes more efficient on GPUs and ASIC devices when compared to high-end CPUs. Therefore, Bitcoin creates favourable conditions for a large gap between the voting power of participants as it violates the “one-CPU-one-vote” principle since GPU and ASIC owners posses a much larger voting power when compared with CPU owners. It is a classical example of the Pareto principle where 20% of a system’s participants control more than 80% of the votes. One could argue that such inequality is not relevant to the network’s security since it is not the small number of participants controlling the majority of the votes but the honesty of these participants that matters. However, such argument is somewhat flawed since it is rather the possibility of cheap specialized hardware appearing rather than the participants’ honesty which poses a threat. To demonstrate this, let us take the following example. Suppose a malevolent individual gains significant mining power by creating his own mining farm through the cheap 2 unambiguously traced to a unique origin and final recipient. Even if two participants exchange funds in an indirect way, a properly engineered path-finding method will reveal the origin and final recipient. It is also suspected that Bitcoin does not satisfy the second property. Some researchers stated ([33, 35, 29, 31]) that a careful blockchain analysis may reveal a connection between the users of the Bitcoin network and their transactions. Although a number of methods are disputed [25], it is suspected that a lot of hidden personal information can be extracted from the public database. Bitcoin’s failure to satisfy the two properties outlined above leads us to conclude that it is not an anonymous but a pseudo-anonymous electronic cash system. Users were quick to develop solutions to circumvent this shortcoming. Two direct solutions were “laundering services” [2] and the development of distributed methods [3, 4]. Both solutions are based on the idea of mixing several public transactions and sending them through some intermediary address; which in turn suffers the drawback of requiring a trusted third party. Recently, a more creative scheme was proposed by I. Miers et al. [28]: “Zerocoin”. Zerocoin utilizes a cryptographic one-way accumulators and zero-knoweldge proofs which permit users to “convert” bitcoins to zerocoins and spend them using anonymous proof of ownership instead of explicit public-key based digital signatures. However, such knowledge proofs have a constant but inconvenient size - about 30kb (based on today’s Bitcoin limits), which makes the proposal impractical. Authors admit that the protocol is unlikely to ever be accepted by the majority of Bitcoin users [5]. 2.2 The proof-of-work function Bitcoin creator Satoshi Nakamoto described the majority decision making algorithm as “oneCPU-one-vote” and used a CPU-bound pricing function (double SHA-256) for his proof-of-work scheme. Since users vote for the single history of transactions order [1], the reasonableness and consistency of this process are critical conditions for the whole system. The security of this model suffers from two drawbacks. First, it requires 51% of the network’s mining power to be under the control of honest users. Secondly, the system’s progress (bug fixes, security fixes, etc...) require the overwhelming majority of users to support and agree to the changes (this occurs when the users update their wallet software) [6].Finally this same voting mechanism is also used for collective polls about implementation of some features [7]. This permits us to conjecture the properties that must be satisfied by the proof-of-work pricing function. Such function must not enable a network participant to have a significant advantage over another participant; it requires a parity between common hardware and high cost of custom devices. From recent examples [8], we can see that the SHA-256 function used in the Bitcoin architecture does not posses this property as mining becomes more efficient on GPUs and ASIC devices when compared to high-end CPUs. Therefore, Bitcoin creates favourable conditions for a large gap between the voting power of participants as it violates the “one-CPU-one-vote” principle since GPU and ASIC owners posses a much larger voting power when compared with CPU owners. It is a classical example of the Pareto principle where 20% of a system’s participants control more than 80% of the votes. One could argue that such inequality is not relevant to the network’s security since it is not the small number of participants controlling the majority of the votes but the honesty of these participants that matters. However, such argument is somewhat flawed since it is rather the possibility of cheap specialized hardware appearing rather than the participants’ honesty which poses a threat. To demonstrate this, let us take the following example. Suppose a malevolent individual gains significant mining power by creating his own mining farm through the cheap 2 4 Presumably, if every user helps their own anonymity out by always generating a new address for EVERY received payment (which is absurd but technically the "correct" way to do it), and if every user helped out everyone else’s anonymity by insisting that they never send funds to the same BTC address twice, then Bitcoin would still only circumstantially pass the unlinkability test. Why? Consumer data can be used to figure an astonishing amount about people all the time. See, for example http://www.applieddatalabs.com/content/target-knows-it-shows Now, imagine this is 20 years in the future and further imagine that Target didn’t just know about your purchase habits at Target, but they had been mining the blockchain for ALL OF YOUR PERSONAL PURCHASES WITH YOUR COINBASE WALLET FOR THE PAST TWELVE YEARS. They’ll be like "hey buddy you might want to pick up some cough medicine tonight, you won’t feel well tomorrow." This may not be the case if multi-party sorting is exploited correctly. See, for example, this blog post: http://blog.ezyang.com/2012/07/secure-multiparty-bitcoin-anonymization/ I’m not totally convinced of the math on that, but ... one paper at a time, right? Citation needed. Whereas the Zerocoin protocol (standalone) may be insufficient, the Zerocash protocol seems to have implemented a 1kb sized transactions. That project is supported by the US and Israeli militaries, of course, so who knows about it’s robustness. On the other hand, no one wants to be able to spend funds without oversight more than the military. http://zerocash-project.org/ I’m not convinced... see, for example, http://fc14.ifca.ai/bitcoin/papers/bitcoin14_submission_12.pdf Quoting a Cryptonote developer Maurice Planck (presumably a pseudonym) from the cryptonote fora: "Zerocoin, Zerocash. This is the most advanced technology, I must admit. Yes, the quote above is from the analysis of the previous version of the protocol. To my knowledge, it’s not 288, but 384 bytes, but anyway this is good news. They used a brand new technic called SNARK, which has certain downsides: for example, large initial database of public parameters required to create a signature (more than 1 GB) and significant time required to create a transaction (more than a minute). Finally, they’re using a young crypto, which I’ve mentioned to be an arguable idea: https://forum.cryptonote.org/viewtopic.php?f= " - Maurice P. Thu Apr 03, 2014 7:56 pm A function that is performed in the CPU and is not suitable for GPU, FPGA, or ASIC computation. The "puzzle" used in proof-of-work is referred to as the pricing function, cost function, or puzzle function.
unambiguously traced to a unique origin and final recipient. Even if two participants exchange funds in an indirect way, a properly engineered path-finding method will reveal the origin and final recipient. It is also suspected that Bitcoin does not satisfy the second property. Some researchers stated ([33, 35, 29, 31]) that a careful blockchain analysis may reveal a connection between the users of the Bitcoin network and their transactions. Although a number of methods are disputed [25], it is suspected that a lot of hidden personal information can be extracted from the public database. Bitcoin’s failure to satisfy the two properties outlined above leads us to conclude that it is not an anonymous but a pseudo-anonymous electronic cash system. Users were quick to develop solutions to circumvent this shortcoming. Two direct solutions were “laundering services” [2] and the development of distributed methods [3, 4]. Both solutions are based on the idea of mixing several public transactions and sending them through some intermediary address; which in turn suffers the drawback of requiring a trusted third party. Recently, a more creative scheme was proposed by I. Miers et al. [28]: “Zerocoin”. Zerocoin utilizes a cryptographic one-way accumulators and zero-knoweldge proofs which permit users to “convert” bitcoins to zerocoins and spend them using anonymous proof of ownership instead of explicit public-key based digital signatures. However, such knowledge proofs have a constant but inconvenient size - about 30kb (based on today’s Bitcoin limits), which makes the proposal impractical. Authors admit that the protocol is unlikely to ever be accepted by the majority of Bitcoin users [5]. 2.2 The proof-of-work function Bitcoin creator Satoshi Nakamoto described the majority decision making algorithm as “oneCPU-one-vote” and used a CPU-bound pricing function (double SHA-256) for his proof-of-work scheme. Since users vote for the single history of transactions order [1], the reasonableness and consistency of this process are critical conditions for the whole system. The security of this model suffers from two drawbacks. First, it requires 51% of the network’s mining power to be under the control of honest users. Secondly, the system’s progress (bug fixes, security fixes, etc...) require the overwhelming majority of users to support and agree to the changes (this occurs when the users update their wallet software) [6].Finally this same voting mechanism is also used for collective polls about implementation of some features [7]. This permits us to conjecture the properties that must be satisfied by the proof-of-work pricing function. Such function must not enable a network participant to have a significant advantage over another participant; it requires a parity between common hardware and high cost of custom devices. From recent examples [8], we can see that the SHA-256 function used in the Bitcoin architecture does not posses this property as mining becomes more efficient on GPUs and ASIC devices when compared to high-end CPUs. Therefore, Bitcoin creates favourable conditions for a large gap between the voting power of participants as it violates the “one-CPU-one-vote” principle since GPU and ASIC owners posses a much larger voting power when compared with CPU owners. It is a classical example of the Pareto principle where 20% of a system’s participants control more than 80% of the votes. One could argue that such inequality is not relevant to the network’s security since it is not the small number of participants controlling the majority of the votes but the honesty of these participants that matters. However, such argument is somewhat flawed since it is rather the possibility of cheap specialized hardware appearing rather than the participants’ honesty which poses a threat. To demonstrate this, let us take the following example. Suppose a malevolent individual gains significant mining power by creating his own mining farm through the cheap 2 unambiguously traced to a unique origin and final recipient. Even if two participants exchange funds in an indirect way, a properly engineered path-finding method will reveal the origin and final recipient. It is also suspected that Bitcoin does not satisfy the second property. Some researchers stated ([33, 35, 29, 31]) that a careful blockchain analysis may reveal a connection between the users of the Bitcoin network and their transactions. Although a number of methods are disputed [25], it is suspected that a lot of hidden personal information can be extracted from the public database. Bitcoin’s failure to satisfy the two properties outlined above leads us to conclude that it is not an anonymous but a pseudo-anonymous electronic cash system. Users were quick to develop solutions to circumvent this shortcoming. Two direct solutions were “laundering services” [2] and the development of distributed methods [3, 4]. Both solutions are based on the idea of mixing several public transactions and sending them through some intermediary address; which in turn suffers the drawback of requiring a trusted third party. Recently, a more creative scheme was proposed by I. Miers et al. [28]: “Zerocoin”. Zerocoin utilizes a cryptographic one-way accumulators and zero-knoweldge proofs which permit users to “convert” bitcoins to zerocoins and spend them using anonymous proof of ownership instead of explicit public-key based digital signatures. However, such knowledge proofs have a constant but inconvenient size - about 30kb (based on today’s Bitcoin limits), which makes the proposal impractical. Authors admit that the protocol is unlikely to ever be accepted by the majority of Bitcoin users [5]. 2.2 The proof-of-work function Bitcoin creator Satoshi Nakamoto described the majority decision making algorithm as “oneCPU-one-vote” and used a CPU-bound pricing function (double SHA-256) for his proof-of-work scheme. Since users vote for the single history of transactions order [1], the reasonableness and consistency of this process are critical conditions for the whole system. The security of this model suffers from two drawbacks. First, it requires 51% of the network’s mining power to be under the control of honest users. Secondly, the system’s progress (bug fixes, security fixes, etc...) require the overwhelming majority of users to support and agree to the changes (this occurs when the users update their wallet software) [6].Finally this same voting mechanism is also used for collective polls about implementation of some features [7]. This permits us to conjecture the properties that must be satisfied by the proof-of-work pricing function. Such function must not enable a network participant to have a significant advantage over another participant; it requires a parity between common hardware and high cost of custom devices. From recent examples [8], we can see that the SHA-256 function used in the Bitcoin architecture does not posses this property as mining becomes more efficient on GPUs and ASIC devices when compared to high-end CPUs. Therefore, Bitcoin creates favourable conditions for a large gap between the voting power of participants as it violates the “one-CPU-one-vote” principle since GPU and ASIC owners posses a much larger voting power when compared with CPU owners. It is a classical example of the Pareto principle where 20% of a system’s participants control more than 80% of the votes. One could argue that such inequality is not relevant to the network’s security since it is not the small number of participants controlling the majority of the votes but the honesty of these participants that matters. However, such argument is somewhat flawed since it is rather the possibility of cheap specialized hardware appearing rather than the participants’ honesty which poses a threat. To demonstrate this, let us take the following example. Suppose a malevolent individual gains significant mining power by creating his own mining farm through the cheap 2 Comments on page 2
Bitcoin Dezavantajları ve Olası Çözümler
2 Bitcoin dezavantajları ve bazı olası çözümler 2.1 İşlemlerin izlenebilirliği Gizlilik ve anonimlik elektronik paranın en önemli unsurlarıdır. Eşler arası ödemeler Geleneksel ile karşılaştırıldığında belirgin bir fark, üçüncü tarafın görüşünden gizlenmeye çalışılmasıdır. bankacılık. Özellikle, T. Okamoto ve K. Ohta ideal elektronik paranın altı kriterini tanımladılar: "Gizlilik: kullanıcı ile satın aldıkları arasındaki ilişki takip edilemez olmalıdır" herkes tarafından” [30]. Açıklamalarından, tamamen anonim olan iki özellik elde ettik. Okamoto tarafından belirtilen gerekliliklere uymak için elektronik nakit modelinin karşılanması gerekir ve Ohta: Takip edilemezlik: Gelen her işlem için tüm olası göndericilerin eşit olasılıklı olması. Bağlantısızlık: Yapılan herhangi iki işlem için bunların gönderildiğini kanıtlamak imkansızdır. aynı kişi. Maalesef Bitcoin izlenemezlik şartını karşılamıyor. Ağın katılımcıları arasında gerçekleşen tüm işlemler halka açık olduğundan, herhangi bir işlem gerçekleştirilebilir. 1 CryptoNote v 2.0 Nicolas van Saberhagen 17 Ekim 2013 1 Giriş “Bitcoin” [1], p2p elektronik nakit kavramının başarılı bir uygulaması olmuştur. Her ikisi de profesyoneller ve genel halk, aşağıdakilerin uygun kombinasyonunu takdir etmeye başladı halka açık işlemler ve güven modeli olarak proof-of-work. Günümüzde elektronik paranın kullanıcı tabanı istikrarlı bir hızla büyüyor; Müşteriler düşük ücretlerden ve sağlanan anonimlikten etkilenirler elektronik nakit ve tüccarlar tahmin edilen ve merkezi olmayan emisyona değer veriyor. Bitcoin var elektronik paranın kağıt para kadar basit ve kullanışlı olabileceğini etkili bir şekilde kanıtladı kredi kartları. Maalesef Bitcoin çeşitli eksikliklerden muzdariptir. Örneğin, sistemin dağıtılmış doğası esnek değildir ve neredeyse tüm ağ kullanıcıları istemcilerini güncelleyinceye kadar yeni özelliklerin uygulanmasını engeller. Hızlı bir şekilde düzeltilemeyen bazı kritik kusurlar Bitcoin'nin çalışmasını caydırır yaygın yayılma. Bu tür esnek olmayan modellerde yeni bir projenin hayata geçirilmesi daha verimlidir. Orijinal projeyi sürekli olarak düzeltmek yerine. Bu yazıda Bitcoin'nın ana eksikliklerini inceliyor ve bunlara çözümler öneriyoruz. inanıyoruz önerdiğimiz çözümleri dikkate alan bir sistemin sağlıklı bir rekabete yol açacağı farklı elektronik nakit sistemleri arasında. Ayrıca kendi elektronik paramız olan “CryptoNote”u da öneriyoruz. elektronik nakitte bir sonraki atılımı vurgulayan bir isim. 2 Bitcoin dezavantajları ve bazı olası çözümler 2.1 İşlemlerin izlenebilirliği Gizlilik ve anonimlik elektronik paranın en önemli unsurlarıdır. Eşler arası ödemeler Geleneksel ile karşılaştırıldığında belirgin bir fark, üçüncü tarafın görüşünden gizlenmeye çalışılmasıdır. bankacılık. Özellikle, T. Okamoto ve K. Ohta ideal elektronik paranın altı kriterini tanımladılar: "Gizlilik: kullanıcı ile satın aldıkları arasındaki ilişki takip edilemez olmalıdır" herkes tarafından” [30]. Açıklamalarından, tamamen anonim olan iki özellik elde ettik. Okamoto tarafından belirtilen gerekliliklere uymak için elektronik nakit modelinin karşılanması gerekir ve Ohta: Takip edilemezlik: Gelen her işlem için tüm olası göndericilerin eşit olasılıklı olması. Bağlantısızlık: Yapılan herhangi iki işlem için bunların gönderildiğini kanıtlamak imkansızdır. aynı kişi. Ne yazık ki Bitcoin izlenemezlik şartını karşılamıyor. Ağın katılımcıları arasında gerçekleşen tüm işlemler halka açık olduğundan, herhangi bir işlem gerçekleştirilebilir. 1 3 Bitcoin kesinlikle "takip edilemezlik" konusunda başarısız oluyor. Size BTC gönderdiğimde, bunun gönderildiği cüzdan blockchain üzerine geri dönülemez şekilde damgalanmıştır. Bu fonları kimin gönderdiğine dair hiçbir soru yok. çünkü yalnızca özel anahtarları bilenler bunları gönderebilir.benzersiz bir kökene ve nihai alıcıya kadar izi sürülebilir. İki katılımcı değişse bile Dolaylı bir şekilde fon sağlanması durumunda, uygun şekilde tasarlanmış bir yol bulma yöntemi, kaynağı ve kaynağı ortaya çıkaracaktır. son alıcı. Ayrıca Bitcoin öğesinin ikinci özelliği karşılamadığından da şüpheleniliyor. Bazı araştırmacılar ([33, 35, 29, 31]) dikkatli bir blockchain analizinin aralarında bir bağlantı ortaya çıkarabileceğini belirtmiştir ([33, 35, 29, 31]) Bitcoin ağının kullanıcıları ve bunların işlemleri. Her ne kadar bir takım yöntemler mevcut olsa da [25] ihtilaflı olduğundan, birçok gizli kişisel bilginin bu siteden alınabileceğinden şüpheleniliyor halka açık veritabanı. Bitcoin'nin yukarıda özetlenen iki özelliği karşılamadaki başarısızlığı, bunun şu sonuca varmasına neden olur: anonim değil, sahte anonim bir elektronik nakit sistemi. Kullanıcılar hızla gelişti Bu eksikliği ortadan kaldıracak çözümler. İki doğrudan çözüm "aklama hizmetleri" [2] ve dağıtılmış yöntemlerin geliştirilmesi [3, 4]. Her iki çözüm de karıştırma fikrine dayanmaktadır. çeşitli kamu işlemleri ve bunların bazı aracı adresler aracılığıyla gönderilmesi; hangisi sırayla güvenilir bir üçüncü tarafa ihtiyaç duymanın dezavantajını yaşar. Son zamanlarda I. Miers ve diğerleri tarafından daha yaratıcı bir plan önerildi. [28]: “Sıfırcoin”. Sıfırcoin kullanıcıların kriptografik tek yönlü akümülatörleri ve sıfır bilgi kanıtlarını kullanır. Bitcoin'leri sıfır paraya "dönüştürün" ve bunları, yerine anonim sahiplik kanıtı kullanarak harcayın Açık genel anahtar tabanlı dijital imzalar. Ancak bu tür bilgi kanıtlarının sabit bir değeri vardır. ancak uygunsuz boyut - yaklaşık 30 kb (bugünün Bitcoin sınırlarına göre), bu da teklifi geçerli kılıyor pratik değil. Yazarlar, protokolün çoğunluk tarafından kabul edilmesinin pek mümkün olmadığını itiraf ediyor Bitcoin kullanıcılar [5]. 2.2 proof-of-work işlevi Bitcoin yaratıcısı Satoshi Nakamoto, çoğunluk karar verme algoritmasını "bir CPU-bir oy" olarak tanımladı ve proof-of-work için CPU'ya bağlı fiyatlandırma işlevini (çift SHA-256) kullandı. şeması. Kullanıcılar tek işlem geçmişi emri [1] için oy verdiğinden, makullük ve Bu sürecin tutarlılığı tüm sistem için kritik koşullardır. Bu modelin güvenliği iki dezavantaja sahiptir. İlk olarak, ağın %51'ini gerektirir Madencilik gücünün dürüst kullanıcıların kontrolü altında olması. İkinci olarak sistemin ilerlemesi (hata düzeltmeleri, güvenlik düzeltmeleri vb.) kullanıcıların büyük çoğunluğunun aşağıdakileri desteklemesini ve kabul etmesini gerektirir: değişiklikler (bu, kullanıcılar cüzdan yazılımlarını güncellediklerinde meydana gelir) [6].Sonunda aynı oylama mekanizma aynı zamanda bazı özelliklerin uygulanmasına ilişkin toplu anketler için de kullanılıyor [7]. Bu, proof-of-work tarafından karşılanması gereken özellikleri tahmin etmemizi sağlar. fiyatlandırma fonksiyonu Bu tür bir işlev, bir ağ katılımcısının önemli bir yetkiye sahip olmasını sağlamamalıdır. başka bir katılımcıya göre avantaj; ortak donanım ve yüksek seviye arasında bir eşitlik gerektirir özel cihazların maliyeti. Son örneklerden [8], SHA-256 fonksiyonunun kullanıldığını görebiliriz Bitcoin mimarisinde madencilik daha verimli hale geldiğinden bu özelliğe sahip değildir Üst düzey CPU'larla karşılaştırıldığında GPU'lar ve ASIC cihazları. Bu nedenle Bitcoin, oy verme gücü arasında büyük bir fark olması için uygun koşullar yaratır. GPU ve ASIC sahiplerinin sahip olduğu "bir CPU-bir oy" ilkesini ihlal ettiği için katılımcılar CPU sahipleriyle karşılaştırıldığında çok daha büyük bir oylama gücü. Bunun klasik bir örneğidir Bir sistemdeki katılımcıların %20'sinin oyların %80'inden fazlasını kontrol ettiği Pareto ilkesi. Böyle bir eşitsizliğin ağın güvenliğiyle ilgili olmadığı, çünkü Oyların çoğunluğunu kontrol eden az sayıda katılımcı ancak bunların dürüstlüğü önemli olan katılımcılar. Ancak böyle bir argüman biraz kusurlu çünkü daha ziyade katılımcıların dürüstlüğünden ziyade ucuz özel donanımın ortaya çıkma olasılığı tehdit oluşturuyor. Bunu göstermek için aşağıdaki örneği ele alalım. Diyelim ki kötü niyetli birey, ucuz yöntemlerle kendi madencilik çiftliğini kurarak önemli bir madencilik gücü elde eder. 2 benzersiz bir kökene ve nihai alıcıya kadar izi sürülebilir. İki katılımcı değişse bile Dolaylı bir şekilde fon sağlanması durumunda, uygun şekilde tasarlanmış bir yol bulma yöntemi, kaynağı ve kaynağı ortaya çıkaracaktır. son alıcı. Ayrıca Bitcoin'nin ikinci özelliği karşılamadığından da şüpheleniliyor. Bazı araştırmacılar ([33, 35, 29, 31]) dikkatli bir blockchain analizinin aralarında bir bağlantıyı ortaya çıkarabileceğini belirtmiştir ([33, 35, 29, 31]) Bitcoin ağının kullanıcıları ve onların işlemleri. Her ne kadar bir takım yöntemler mevcut olsa da d[25] olarak belirtildiyse, birçok gizli kişisel bilginin bu siteden alınabileceğinden şüpheleniliyor. halka açık veritabanı. Bitcoin'nin yukarıda özetlenen iki özelliği karşılamadaki başarısızlığı, bunun şu sonuca varmasına neden oluyor: anonim değil, sahte anonim bir elektronik nakit sistemi. Kullanıcılar hızla gelişti Bu eksikliği ortadan kaldıracak çözümler. İki doğrudan çözüm “aklama hizmetleri” idi [2] ve dağıtılmış yöntemlerin geliştirilmesi [3, 4]. Her iki çözüm de karıştırma fikrine dayanmaktadır. çeşitli kamu işlemleri ve bunların bazı aracı adresler aracılığıyla gönderilmesi; hangisi sırayla güvenilir bir üçüncü tarafa ihtiyaç duymanın dezavantajını yaşar. Son zamanlarda I. Miers ve diğerleri tarafından daha yaratıcı bir plan önerildi. [28]: “Sıfırcoin”. Sıfırcoin kullanıcıların kriptografik tek yönlü akümülatörleri ve sıfır bilgi kanıtlarını kullanır. Bitcoin'leri sıfır paraya "dönüştürün" ve bunları, yerine anonim sahiplik kanıtı kullanarak harcayın Açık genel anahtar tabanlı dijital imzalar. Ancak bu tür bilgi kanıtlarının sabit bir değeri vardır. ancak uygunsuz boyut - yaklaşık 30 kb (bugünün Bitcoin sınırlarına göre), bu da teklifi geçerli kılıyor pratik değil. Yazarlar, protokolün çoğunluk tarafından kabul edilmesinin pek mümkün olmadığını itiraf ediyor Bitcoin kullanıcılar [5]. 2.2 proof-of-work işlevi Bitcoin yaratıcısı Satoshi Nakamoto, çoğunluk karar verme algoritmasını "bir CPU-bir oy" olarak tanımladı ve proof-of-work için CPU'ya bağlı fiyatlandırma işlevini (çift SHA-256) kullandı. şeması. Kullanıcılar tek işlem geçmişi emri [1] için oy verdiğinden, makullük ve Bu sürecin tutarlılığı tüm sistem için kritik koşullardır. Bu modelin güvenliği iki dezavantaja sahiptir. İlk olarak, ağın %51'ini gerektirir Madencilik gücünün dürüst kullanıcıların kontrolü altında olması. İkinci olarak sistemin ilerlemesi (hata düzeltmeleri, güvenlik düzeltmeleri vb.) kullanıcıların büyük çoğunluğunun aşağıdakileri desteklemesini ve kabul etmesini gerektirir: değişiklikler (bu, kullanıcılar cüzdan yazılımlarını güncellediklerinde meydana gelir) [6].Sonunda aynı oylama mekanizma aynı zamanda bazı özelliklerin uygulanmasına ilişkin toplu anketler için de kullanılıyor [7]. Bu bize proof-of-work tarafından karşılanması gereken özellikleri tahmin etmemizi sağlar. fiyatlandırma fonksiyonu Bu tür bir işlev, bir ağ katılımcısının önemli bir yetkiye sahip olmasını sağlamamalıdır. başka bir katılımcıya göre avantaj; ortak donanım ve yüksek seviye arasında bir eşitlik gerektirir özel cihazların maliyeti. Son örneklerden [8], SHA-256 fonksiyonunun kullanıldığını görebiliriz Bitcoin mimarisinde madencilik daha verimli hale geldiğinden bu özelliğe sahip değildir Üst düzey CPU'larla karşılaştırıldığında GPU'lar ve ASIC cihazları. Bu nedenle Bitcoin, oylama güçleri arasında büyük bir fark olması için uygun koşullar yaratır. GPU ve ASIC sahiplerinin sahip olduğu "bir CPU-bir oy" ilkesini ihlal ettiği için katılımcılar CPU sahipleriyle karşılaştırıldığında çok daha büyük bir oylama gücü. Bunun klasik bir örneğidir Bir sistemdeki katılımcıların %20'sinin oyların %80'inden fazlasını kontrol ettiği Pareto ilkesi. Böyle bir eşitsizliğin ağın güvenliğiyle ilgili olmadığı, çünkü Oyların çoğunluğunu kontrol eden az sayıda katılımcı ancak bunların dürüstlüğü önemli olan katılımcılar. Ancak böyle bir argüman biraz kusurlu çünkü daha ziyade katılımcıların dürüstlüğünden ziyade ucuz özel donanımın ortaya çıkma olasılığı tehdit oluşturuyor. Bunu göstermek için aşağıdaki örneği ele alalım. Diyelim ki kötü niyetli birey, ucuz yöntemlerle kendi madencilik çiftliğini kurarak önemli bir madencilik gücü elde eder. 2 4 Muhtemelen, eğer her kullanıcı her zaman yeni bir adres oluşturarak kendi anonimliğini ortadan kaldırıyorsa Alınan HER ödeme için (bu saçma ama teknik olarak bunu yapmanın "doğru" yolu), ve eğer her kullanıcı, asla para göndermemeleri konusunda ısrar ederek diğer herkesin anonimliğine yardımcı olsaydı aynı BTC adresine iki kez gitse, Bitcoin yine de yalnızca dolaylı olarak iletecektir bağlantı kurulamazlık testi Neden? Tüketici verileri, insanlar hakkında her zaman şaşırtıcı miktarda bilgi edinmek için kullanılabilir. Örneğin bkz. http://www.applieddatalabs.com/content/target-knows-it-shows Şimdi bunun 20 yıl gelecekte olduğunu hayal edin ve ayrıca Target'in bunu bilmediğini hayal edin. Target'taki satın alma alışkanlıklarınız hakkında, ancak ALL OF için blockchain madenciliği yapıyorlardı GEÇMİŞ İÇİN COINBASE CÜZDANINIZ İLE KİŞİSEL ALIŞVERİŞLERİNİZ ON İKİ YIL. Şöyle diyecekler: "Hey dostum, bu gece biraz öksürük ilacı almak isteyebilirsin, almayacaksın yarın kendini iyi hisset." Çok partili sıralama doğru şekilde kullanılırsa durum böyle olmayabilir. Örneğin buna bakınblog yazısı: http://blog.ezyang.com/2012/07/secure-multiparty-bitcoin-anonymization/ Bunun matematiğine tam olarak ikna olmadım ama... her seferinde bir kağıt, değil mi? Alıntı gerekli. Zerocoin protokolü (bağımsız) yetersiz olabilirken Zerocash protokolün 1kb boyutunda bir işlem gerçekleştirmiş olduğu görülüyor. O proje destekleniyor Tabii ki ABD ve İsrail orduları, yani sağlamlığını kim bilebilir? diğer tarafta Öte yandan hiç kimse ordu kadar gözetim olmadan fon harcamayı istemez. http://zerocash-project.org/ İkna olmadım... örneğin bkz. http://fc14.ifca.ai/bitcoin/papers/bitcoin14_submission_12.pdf Cryptonote geliştiricisi Maurice Planck'tan (muhtemelen takma ad) kripto nottan alıntı fora: "Sıfırcoin, Zerocash. Bu en ileri teknoloji, itiraf etmeliyim. Evet alıntı Yukarıdaki, protokolün önceki versiyonunun analizinden alınmıştır. Bildiğim kadarıyla öyle değil 288 ama 384 byte ama yine de bu iyi bir haber. SNARK adında yepyeni bir teknik kullandılar, bunun da bazı dezavantajları var: Örneğin; Bir imza oluşturmak için gereken genel parametrelerden oluşan geniş bir başlangıç veri tabanı (1 GB'den fazla) ve bir işlem oluşturmak için önemli bir sürenin gerekli olması (bir dakikadan fazla). Son olarak, bir tartışılabilir bir fikir olduğundan bahsettiğim genç kripto: https://forum.cryptonote.org/viewtopic.php?f= " - Maurice P. Per 03 Nis 2014 19:56 CPU'da gerçekleştirilen ve GPU, FPGA veya ASIC için uygun olmayan bir işlev hesaplama. proof-of-work'de kullanılan "bulmaca", fiyatlandırma işlevi, maliyet işlevi veya bulmaca işlevi.
benzersiz bir kökene ve nihai alıcıya kadar izi sürülebilir. İki katılımcı değişse bile Dolaylı bir şekilde fon sağlanması durumunda, uygun şekilde tasarlanmış bir yol bulma yöntemi, kaynağı ve kaynağı ortaya çıkaracaktır. son alıcı. Ayrıca Bitcoin'nin ikinci özelliği karşılamadığından da şüpheleniliyor. Bazı araştırmacılar ([33, 35, 29, 31]) dikkatli bir blockchain analizinin aralarında bir bağlantı olduğunu ortaya çıkarabileceğini belirtmiştir ([33, 35, 29, 31]) Bitcoin ağının kullanıcıları ve bunların işlemleri. Her ne kadar bir takım yöntemler mevcut olsa da [25] ihtilaflı olduğundan, birçok gizli kişisel bilginin bu siteden alınabileceğinden şüpheleniliyor halka açık veritabanı. Bitcoin'in yukarıda özetlenen iki özelliği karşılamadaki başarısızlığı, bunun şu sonuca varmasına neden oluyor: anonim değil, sahte anonim bir elektronik nakit sistemi. Kullanıcılar hızla gelişti Bu eksikliği ortadan kaldıracak çözümler. İki doğrudan çözüm “aklama hizmetleri” idi [2] ve dağıtılmış yöntemlerin geliştirilmesi [3, 4]. Her iki çözüm de karıştırma fikrine dayanmaktadır. çeşitli kamu işlemleri ve bunların bazı aracı adresler aracılığıyla gönderilmesi; hangisi sırayla güvenilir bir üçüncü tarafa ihtiyaç duymanın dezavantajını yaşar. Son zamanlarda I. Miers ve diğerleri tarafından daha yaratıcı bir plan önerildi. [28]: “Sıfırcoin”. Sıfırcoin kullanıcıların kriptografik tek yönlü akümülatörleri ve sıfır bilgi kanıtlarını kullanır. Bitcoin'leri sıfır paraya "dönüştürün" ve bunları, yerine anonim sahiplik kanıtı kullanarak harcayın Açık genel anahtar tabanlı dijital imzalar. Ancak bu tür bilgi kanıtlarının sabit bir değeri vardır. ancak uygunsuz boyut - yaklaşık 30 kb (bugünün Bitcoin sınırlarına göre), bu da teklifi geçerli kılıyor pratik değil. Yazarlar, protokolün çoğunluk tarafından kabul edilmesinin pek mümkün olmadığını itiraf ediyor Bitcoin kullanıcılar [5]. 2.2 proof-of-work işlevi Bitcoin yaratıcısı Satoshi Nakamoto, çoğunluk karar verme algoritmasını "bir CPU-bir oy" olarak tanımladı ve proof-of-work için CPU'ya bağlı fiyatlandırma işlevini (çift SHA-256) kullandı. şeması. Kullanıcılar tek işlem geçmişi emri [1] için oy verdiğinden, makullük ve Bu sürecin tutarlılığı tüm sistem için kritik koşullardır. Bu modelin güvenliği iki dezavantaja sahiptir. İlk olarak, ağın %51'ini gerektirir Madencilik gücünün dürüst kullanıcıların kontrolü altında olması. İkinci olarak sistemin ilerlemesi (hata düzeltmeleri, güvenlik düzeltmeleri vb.) kullanıcıların büyük çoğunluğunun aşağıdakileri desteklemesini ve kabul etmesini gerektirir: değişiklikler (bu, kullanıcılar cüzdan yazılımlarını güncellediklerinde meydana gelir) [6].Sonunda aynı oylama mekanizma aynı zamanda bazı özelliklerin uygulanmasına ilişkin toplu anketler için de kullanılıyor [7]. Bu, proof-of-work tarafından karşılanması gereken özellikleri tahmin etmemizi sağlar. fiyatlandırma fonksiyonu Bu tür bir işlev, bir ağ katılımcısının önemli bir yetkiye sahip olmasını sağlamamalıdır. başka bir katılımcıya göre avantaj; ortak donanım ve yüksek seviye arasında bir eşitlik gerektirir özel cihazların maliyeti. Son örneklerden [8], SHA-256 fonksiyonunun kullanıldığını görebiliriz Bitcoin mimarisinde madencilik daha verimli hale geldiğinden bu özelliğe sahip değildir Üst düzey CPU'larla karşılaştırıldığında GPU'lar ve ASIC cihazları. Bu nedenle Bitcoin, oy verme gücü arasında büyük bir fark olması için uygun koşullar yaratır. GPU ve ASIC sahiplerinin sahip olduğu "bir CPU-bir oy" ilkesini ihlal ettiği için katılımcılar CPU sahipleriyle karşılaştırıldığında çok daha büyük bir oylama gücü. Bunun klasik bir örneğidir Bir sistemdeki katılımcıların %20'sinin oyların %80'inden fazlasını kontrol ettiği Pareto ilkesi. Böyle bir eşitsizliğin ağın güvenliğiyle ilgili olmadığı, çünkü Oyların çoğunluğunu kontrol eden az sayıda katılımcı ancak bunların dürüstlüğü önemli olan katılımcılar. Ancak böyle bir argüman biraz kusurlu çünkü daha ziyade katılımcıların dürüstlüğünden ziyade ucuz özel donanımın ortaya çıkma olasılığı tehdit oluşturuyor. Bunu göstermek için aşağıdaki örneği ele alalım. Diyelim ki kötü niyetli birey, ucuz yöntemlerle kendi madencilik çiftliğini kurarak önemli bir madencilik gücü elde eder. 2 benzersiz bir kökene ve nihai alıcıya kadar izi sürülebilir. İki katılımcı değişse bile Dolaylı bir şekilde fon sağlanması durumunda, uygun şekilde tasarlanmış bir yol bulma yöntemi, kaynağı ve kaynağı ortaya çıkaracaktır. son alıcı. Ayrıca Bitcoin öğesinin ikinci özelliği karşılamadığından da şüpheleniliyor. Bazı araştırmacılar ([33, 35, 29, 31]) dikkatli bir blockchain analizinin aralarında bir bağlantı olduğunu ortaya çıkarabileceğini belirtmiştir ([33, 35, 29, 31]) Bitcoin ağının kullanıcıları ve bunların işlemleri. Her ne kadar bir takım yöntemler mevcut olsa da d[25] olarak öne sürülen bu siteden birçok gizli kişisel bilginin alınabileceğinden şüpheleniliyor. halka açık veritabanı. Bitcoin'nin yukarıda özetlenen iki özelliği karşılamadaki başarısızlığı, bunun şu sonuca varmasına neden oluyor: anonim değil, sahte anonim bir elektronik nakit sistemi. Kullanıcılar hızla gelişti Bu eksikliği ortadan kaldıracak çözümler. İki doğrudan çözüm "aklama hizmetleri" [2] ve dağıtılmış yöntemlerin geliştirilmesi [3, 4]. Her iki çözüm de karıştırma fikrine dayanmaktadır. çeşitli kamu işlemleri ve bunların bazı aracı adresler aracılığıyla gönderilmesi; hangisi sırayla güvenilir bir üçüncü tarafa ihtiyaç duymanın dezavantajını yaşar. Son zamanlarda I. Miers ve diğerleri tarafından daha yaratıcı bir plan önerildi. [28]: “Sıfırcoin”. Sıfırcoin kullanıcıların kriptografik tek yönlü akümülatörleri ve sıfır bilgi kanıtlarını kullanır. Bitcoin'leri sıfır paraya "dönüştürün" ve bunları, yerine anonim sahiplik kanıtı kullanarak harcayın Açık genel anahtar tabanlı dijital imzalar. Ancak bu tür bilgi kanıtlarının sabit bir değeri vardır. ancak uygunsuz boyut - yaklaşık 30 kb (bugünün Bitcoin sınırlarına göre), bu da teklifi geçerli kılıyor pratik değil. Yazarlar, protokolün çoğunluk tarafından kabul edilmesinin pek mümkün olmadığını itiraf ediyor Bitcoin kullanıcılar [5]. 2.2 proof-of-work işlevi Bitcoin yaratıcısı Satoshi Nakamoto, çoğunluk karar verme algoritmasını "bir CPU-bir oy" olarak tanımladı ve proof-of-work için CPU'ya bağlı fiyatlandırma işlevini (çift SHA-256) kullandı. şeması. Kullanıcılar tek işlem geçmişi emri [1] için oy verdiğinden, makullük ve Bu sürecin tutarlılığı tüm sistem için kritik koşullardır. Bu modelin güvenliği iki dezavantaja sahiptir. İlk olarak, ağın %51'ini gerektirir Madencilik gücünün dürüst kullanıcıların kontrolü altında olması. İkinci olarak sistemin ilerlemesi (hata düzeltmeleri, güvenlik düzeltmeleri vb.) kullanıcıların büyük çoğunluğunun aşağıdakileri desteklemesini ve kabul etmesini gerektirir: değişiklikler (bu, kullanıcılar cüzdan yazılımlarını güncellediklerinde meydana gelir) [6].Sonunda aynı oylama mekanizma aynı zamanda bazı özelliklerin uygulanmasına ilişkin toplu anketler için de kullanılıyor [7]. Bu bize proof-of-work tarafından karşılanması gereken özellikleri tahmin etmemizi sağlar. fiyatlandırma fonksiyonu Bu tür bir işlev, bir ağ katılımcısının önemli bir yetkiye sahip olmasını sağlamamalıdır. başka bir katılımcıya göre avantaj; ortak donanım ve yüksek seviye arasında bir eşitlik gerektirir özel cihazların maliyeti. Son örneklerden [8], SHA-256 fonksiyonunun kullanıldığını görebiliriz Bitcoin mimarisinde madencilik daha verimli hale geldiğinden bu özelliğe sahip değildir Üst düzey CPU'larla karşılaştırıldığında GPU'lar ve ASIC cihazları. Bu nedenle Bitcoin, oylama güçleri arasında büyük bir fark olması için uygun koşullar yaratır. GPU ve ASIC sahiplerinin sahip olduğu "bir CPU-bir oy" ilkesini ihlal ettiği için katılımcılar CPU sahipleriyle karşılaştırıldığında çok daha büyük bir oylama gücü. Bunun klasik bir örneğidir Bir sistemdeki katılımcıların %20'sinin oyların %80'inden fazlasını kontrol ettiği Pareto ilkesi. Böyle bir eşitsizliğin ağın güvenliğiyle ilgili olmadığı, çünkü Oyların çoğunluğunu kontrol eden az sayıda katılımcı ancak bunların dürüstlüğü önemli olan katılımcılar. Ancak böyle bir argüman biraz kusurlu çünkü daha ziyade katılımcıların dürüstlüğünden ziyade ucuz özel donanımın ortaya çıkma olasılığı tehdit oluşturuyor. Bunu göstermek için aşağıdaki örneği ele alalım. Diyelim ki kötü niyetli birey, ucuz yöntemlerle kendi madencilik çiftliğini kurarak önemli bir madencilik gücü elde eder. 2 2. sayfadaki yorumlar
The CryptoNote Technology
The CryptoNote Technology
Now that we have covered the limitations of the Bitcoin technology, we will concentrate on presenting the features of CryptoNote.
CryptoNote Teknolojisi
Artık Bitcoin teknolojisinin sınırlamalarını ele aldığımıza göre, şu konulara odaklanacağız: CryptoNote'un özelliklerini sunuyor.
Untraceable Transactions
Untraceable Transactions
In this section we propose a scheme of fully anonymous transactions satisfying both untraceability
and unlinkability conditions. An important feature of our solution is its autonomy: the sender
is not required to cooperate with other users or a trusted third party to make his transactions;
hence each participant produces a cover traffic independently.
4.1
Literature review
Our scheme relies on the cryptographic primitive called a group signature. First presented by
D. Chaum and E. van Heyst [19], it allows a user to sign his message on behalf of the group.
After signing the message the user provides (for verification purposes) not his own single public
1This is so-called “soft limit” — the reference client restriction for creating new blocks. Hard maximum of
possible blocksize was 1 MB
4
them if necessary that causes the main drawbacks. Unfortunately, it is hard to predict when the
constants may need to be changed and replacing them may lead to terrible consequences.
A good example of a hardcoded limit change leading to disastrous consequences is the block
size limit set to 250kb1. This limit was sufficient to hold about 10000 standard transactions. In
early 2013, this limit had almost been reached and an agreement was reached to increase the
limit. The change was implemented in wallet version 0.8 and ended with a 24-blocks chain split
and a successful double-spend attack [9]. While the bug was not in the Bitcoin protocol, but
rather in the database engine it could have been easily caught by a simple stress test if there was
no artificially introduced block size limit.
Constants also act as a form of centralization point.
Despite the peer-to-peer nature of
Bitcoin, an overwhelming majority of nodes use the official reference client [10] developed by
a small group of people. This group makes the decision to implement changes to the protocol
and most people accept these changes irrespective of their “correctness”. Some decisions caused
heated discussions and even calls for boycott [11], which indicates that the community and the
developers may disagree on some important points. It therefore seems logical to have a protocol
with user-configurable and self-adjusting variables as a possible way to avoid these problems.
2.5
Bulky scripts
The scripting system in Bitcoin is a heavy and complex feature. It potentially allows one to create
sophisticated transactions [12], but some of its features are disabled due to security concerns and
some have never even been used [13]. The script (including both senders’ and receivers’ parts)
for the most popular transaction in Bitcoin looks like this:
key, but the keys of all the users of his group. A verifier is convinced that the real signer is a member of the group, but cannot exclusively identify the signer. The original protocol required a trusted third party (called the Group Manager), and he was the only one who could trace the signer. The next version called a ring signature, introduced by Rivest et al. in [34], was an autonomous scheme without Group Manager and anonymity revocation. Various modifications of this scheme appeared later: linkable ring signature [26, 27, 17] allowed to determine if two signatures were produced by the same group member, traceable ring signature [24, 23] limited excessive anonymity by providing possibility to trace the signer of two messages with respect to the same metainformation (or “tag” in terms of [24]). A similar cryptographic construction is also known as a ad-hoc group signature [16, 38]. It emphasizes the arbitrary group formation, whereas group/ring signature schemes rather imply a fixed set of members. For the most part, our solution is based on the work “Traceable ring signature” by E. Fujisaki and K. Suzuki [24]. In order to distinguish the original algorithm and our modification we will call the latter a one-time ring signature, stressing the user’s capability to produce only one valid signature under his private key. We weakened the traceability property and kept the linkability only to provide one-timeness: the public key may appear in many foreign verifying sets and the private key can be used for generating a unique anonymous signature. In case of a double spend attempt these two signatures will be linked together, but revealing the signer is not necessary for our purposes. 4.2 Definitions 4.2.1 Elliptic curve parameters As our base signature algorithm we chose to use the fast scheme EdDSA, which is developed and implemented by D.J. Bernstein et al. [18]. Like Bitcoin’s ECDSA it is based on the elliptic curve discrete logarithm problem, so our scheme could also be applied to Bitcoin in future. Common parameters are: \(q\): a prime number; \(q = 2^{255} - 19\); \(d\): an element of \(\mathbb{F}_q\); \(d = -121665/121666\); \(E\): an elliptic curve equation; \(-x^2 + y^2 = 1 + dx^2y^2\); \(G\): a base point; \(G = (x, -4/5)\); \(l\): a prime order of the base point; \(l = 2^{252} + 27742317777372353535851937790883648493\); \(H_s\): a cryptographic hash function \(\{0, 1\}^* \to \mathbb{F}_q\); \(H_p\): a deterministic hash function \(E(\mathbb{F}_q) \to E(\mathbb{F}_q)\). 4.2.2 Terminology Enhanced privacy requires a new terminology which should not be confused with Bitcoin entities. private ec-key is a standard elliptic curve private key: a number \(a \in [1, l - 1]\); public ec-key is a standard elliptic curve public key: a point \(A = aG\); one-time keypair is a pair of private and public ec-keys; 5 key, but the keys of all the users of his group. A verifier is convinced that the real signer is a member of the group, but cannot exclusively identify the signer. The original protocol required a trusted third party (called the Group Manager), and he was the only one who could trace the signer. The next version called a ring signature, introduced by Rivest et al. in [34], was an autonomous scheme without Group Manager and anonymity revocation. Various modifications of this scheme appeared later: linkable ring signature [26, 27, 17] allowed to determine if two signatures were produced by the same group member, traceable ring signature [24, 23] limited excessive anonymity by providing possibility to trace the signer of two messages with respect to the same metainformation (or “tag” in terms of [24]). A similar cryptographic construction is also known as a ad-hoc group signature [16, 38]. It emphasizes the arbitrary group formation, whereas group/ring signature schemes rather imply a fixed set of members. For the most part, our solution is based on the work “Traceable ring signature” by E. Fujisaki and K. Suzuki [24]. In order to distinguish the original algorithm and our modification we will call the latter a one-time ring signature, stressing the user’s capability to produce only one valid signature under his private key. We weakened the traceability property and kept the linkability only to provide one-timeness: the public key may appear in many foreign verifying sets and the private key can be used for generating a unique anonymous signature. In case of a double spend attempt these two signatures will be linked together, but revealing the signer is not necessary for our purposes. 4.2 Definitions 4.2.1 Elliptic curve parameters As our base signature algorithm we chose to use the fast scheme EdDSA, which is developed and implemented by D.J. Bernstein et al. [18]. Like Bitcoin’s ECDSA it is based on the elliptic curve discrete logarithm problem, so our scheme could also be applied to Bitcoin in future. Common parameters are: \(q\): a prime number; \(q = 2^{255} - 19\); \(d\): an element of \(\mathbb{F}_q\); \(d = -121665/121666\); \(E\): an elliptic curve equation; \(-x^2 + y^2 = 1 + dx^2y^2\); \(G\): a base point; \(G = (x, -4/5)\); \(l\): a prime order of the base point; \(l = 2^{252} + 27742317777372353535851937790883648493\); \(H_s\): a cryptographic hash function \(\{0, 1\}^* \to \mathbb{F}_q\); \(H_p\): a deterministic hash function \(E(\mathbb{F}_q) \to E(\mathbb{F}_q)\). 4.2.2 Terminology Enhanced privacy requires a new terminology which should not be confused with Bitcoin entities. private ec-key is a standard elliptic curve private key: a number \(a \in [1, l - 1]\); public ec-key is a standard elliptic curve public key: a point \(A = aG\); one-time keypair is a pair of private and public ec-keys; 5 8 A ring signature works like this: Alex wants to leak a message to WikiLeaks about her employer. Every employee in her Company has a private/public key pair (Ri, Ui). She composes her signature with input set as her message, m, her private key, Ri, and EVERYBODY’s public keys, (Ui;i=1...n). Anyone (without knowing any private keys) can verify easily that some pair (Rj, Uj) must have been used to construct the signature... someone who works for Alex’s employer... but it’s essentially a random guess to figure out which one it could be. http://en.wikipedia.org/wiki/Ring_signature#Crypto-currencies http://link.springer.com/chapter/10.1007/3-540-45682-1_32#page-1 http://link.springer.com/chapter/10.1007/11424826_65 http://link.springer.com/chapter/10.1007/978-3-540-27800-9_28 http://link.springer.com/chapter/10.1007%2F11774716_9 Notice that a linkable ring signature described here is kind of the opposite of "unlinkable" described above. Here, we intercept two messages, and we can determine whether the same party sent them, although we should still be unable to determine who that party is. The definition of "unlinkable" used to construct Cryptonote means we cannot determine whether the same party is receiving them. Hence, what we really have here is FOUR things going on. A system can be linkable or non-linkable, depending on whether or not it’s possible to determine whether the sender of two messages are the same (regardless of whether this requires revoking anonymity). And a system can be unlinkable or non-unlinkable, depending on whether or not it’s possible to determine whether the receiver of two messages are the same (regardless of whether or not this requires revoking anonymity). Please don’t blame me for this terrible terminology. Graph theorists should probably be pleased. Some of you may be more comfortable with "receiver linkable" versus "sender linkable." http://link.springer.com/chapter/10.1007/978-3-540-71677-8_13 When I read this, this seemed like a silly feature. Then I read that it may be a feature for electronic voting, and that seemed to make sense. Kinda cool, from that perspective. But I’m not totally sure about purposely implementing traceable ring signatures. http://search.ieice.org/bin/summary.php?id=e95-a_1_151
key, but the keys of all the users of his group. A verifier is convinced that the real signer is a member of the group, but cannot exclusively identify the signer. The original protocol required a trusted third party (called the Group Manager), and he was the only one who could trace the signer. The next version called a ring signature, introduced by Rivest et al. in [34], was an autonomous scheme without Group Manager and anonymity revocation. Various modifications of this scheme appeared later: linkable ring signature [26, 27, 17] allowed to determine if two signatures were produced by the same group member, traceable ring signature [24, 23] limited excessive anonymity by providing possibility to trace the signer of two messages with respect to the same metainformation (or “tag” in terms of [24]). A similar cryptographic construction is also known as a ad-hoc group signature [16, 38]. It emphasizes the arbitrary group formation, whereas group/ring signature schemes rather imply a fixed set of members. For the most part, our solution is based on the work “Traceable ring signature” by E. Fujisaki and K. Suzuki [24]. In order to distinguish the original algorithm and our modification we will call the latter a one-time ring signature, stressing the user’s capability to produce only one valid signature under his private key. We weakened the traceability property and kept the linkability only to provide one-timeness: the public key may appear in many foreign verifying sets and the private key can be used for generating a unique anonymous signature. In case of a double spend attempt these two signatures will be linked together, but revealing the signer is not necessary for our purposes. 4.2 Definitions 4.2.1 Elliptic curve parameters As our base signature algorithm we chose to use the fast scheme EdDSA, which is developed and implemented by D.J. Bernstein et al. [18]. Like Bitcoin’s ECDSA it is based on the elliptic curve discrete logarithm problem, so our scheme could also be applied to Bitcoin in future. Common parameters are: \(q\): a prime number; \(q = 2^{255} - 19\); \(d\): an element of \(\mathbb{F}_q\); \(d = -121665/121666\); \(E\): an elliptic curve equation; \(-x^2 + y^2 = 1 + dx^2y^2\); \(G\): a base point; \(G = (x, -4/5)\); \(l\): a prime order of the base point; \(l = 2^{252} + 27742317777372353535851937790883648493\); \(H_s\): a cryptographic hash function \(\{0, 1\}^* \to \mathbb{F}_q\); \(H_p\): a deterministic hash function \(E(\mathbb{F}_q) \to E(\mathbb{F}_q)\). 4.2.2 Terminology Enhanced privacy requires a new terminology which should not be confused with Bitcoin entities. private ec-key is a standard elliptic curve private key: a number \(a \in [1, l - 1]\); public ec-key is a standard elliptic curve public key: a point \(A = aG\); one-time keypair is a pair of private and public ec-keys; 5 key, but the keys of all the users of his group. A verifier is convinced that the real signer is a member of the group, but cannot exclusively identify the signer. The original protocol required a trusted third party (called the Group Manager), and he was the only one who could trace the signer. The next version called a ring signature, introduced by Rivest et al. in [34], was an autonomous scheme without Group Manager and anonymity revocation. Various modifications of this scheme appeared later: linkable ring signature [26, 27, 17] allowed to determine if two signatures were produced by the same group member, traceable ring signature [24, 23] limited excessive anonymity by providing possibility to trace the signer of two messages with respect to the same metainformation (or “tag” in terms of [24]). A similar cryptographic construction is also known as a ad-hoc group signature [16, 38]. It emphasizes the arbitrary group formation, whereas group/ring signature schemes rather imply a fixed set of members. For the most part, our solution is based on the work “Traceable ring signature” by E. Fujisaki and K. Suzuki [24]. In order to distinguish the original algorithm and our modification we will call the latter a one-time ring signature, stressing the user’s capability to produce only one valid signature under his private key. We weakened the traceability property and kept the linkability only to provide one-timeness: the public key may appear in many foreign verifying sets and the private key can be used for generating a unique anonymous signature. In case of a double spend attempt these two signatures will be linked together, but revealing the signer is not necessary for our purposes. 4.2 Definitions 4.2.1 Elliptic curve parameters As our base signature algorithm we chose to use the fast scheme EdDSA, which is developed and implemented by D.J. Bernstein et al. [18]. Like Bitcoin’s ECDSA it is based on the elliptic curve discrete logarithm problem, so our scheme could also be applied to Bitcoin in future. Common parameters are: \(q\): a prime number; \(q = 2^{255} - 19\); \(d\): an element of \(\mathbb{F}_q\); \(d = -121665/121666\); \(E\): an elliptic curve equation; \(-x^2 + y^2 = 1 + dx^2y^2\); \(G\): a base point; \(G = (x, -4/5)\); \(l\): a prime order of the base point; \(l = 2^{252} + 27742317777372353535851937790883648493\); \(H_s\): a cryptographic hash function \(\{0, 1\}^* \to \mathbb{F}_q\); \(H_p\): a deterministic hash function \(E(\mathbb{F}_q) \to E(\mathbb{F}_q)\). 4.2.2 Terminology Enhanced privacy requires a new terminology which should not be confused with Bitcoin entities. private ec-key is a standard elliptic curve private key: a number \(a \in [1, l - 1]\); public ec-key is a standard elliptic curve public key: a point \(A = aG\); one-time keypair is a pair of private and public ec-keys; 5 9 Gosh, the author of this whitepaper sure could have worded this better! Let’s say that an employee-owned company wants to take a vote on whether or not to acquire certain new assets, and Alex and Brenda are both employees. The Company provides each employee a message like "I vote yes on Proposition A!" which has the metainformation "issue" [PROP A] and asks them to sign it with a traceable ring signature if they support the proposition. Using a traditional ring signature, a dishonest employee can sign the message multiple times, presumably with different nonces, in order to vote as many times as they like. On the other hand, in a traceable ring signature scheme, Alex will go to vote, and her private key will have been used on the issue [PROP A]. If Alex tries to sign a message like "I, Brenda, approve of proposition A!" to "frame" Brenda and double vote, this new message will also have the issue [PROP A]. Since Alex’s private key has already tripped the [PROP A] issue, Alex’s identity will be immediately revealed as a fraud. Which, face it, is pretty cool! Cryptography enforced voting equality. http://link.springer.com/chapter/10.1007/978-3-540-71677-8_13 This paper is interesting, essentially creating an ad-hoc ring signature but without any of the other participant’s consent. The structure of the signature may be different; I haven’t dug deep, and I haven’t seen whether it’s secure. https://people.csail.mit.edu/rivest/AdidaHohenbergerRivest-AdHocGroupSignaturesFromHijackedKeypai Ad-hoc group signatures are: ring signatures, which are group signatures with no group managers, no centralization, but allows a member in an ad-hoc group to provably claim that it has (not) issued the anonymous signature on behalf of the group. http://link.springer.com/chapter/10.1007/11908739_9 This isn’t quite correct, from my understanding. And my understanding will likely change as I get deeper into this project. But from my understanding, the hierarchy looks like this. Group sigs: group managers control traceability and the ability of adding or removing members from being signers. Ring sigs: Arbitrary group formation without a group manager. No anonymity revocation. No way to repudiate oneself from a particular signature. With traceable and linkable ring signatures, anonymity is somewhat scaleable. Ad-hoc group signatures: like ring signatures, but members can prove that they did not create a particular signature. This is important when anyone in a group can produce a signature. http://link.springer.com/chapter/10.1007/978-3-540-71677-8_13 Fujisaki and Suzuki’s algorithm is tweaked later by the author to provide one-time-ness. So we will analyze Fujisaki and Suzuki’s algorithm concurrently with the new algorithm rather than going over it here.
key, but the keys of all the users of his group. A verifier is convinced that the real signer is a member of the group, but cannot exclusively identify the signer. The original protocol required a trusted third party (called the Group Manager), and he was the only one who could trace the signer. The next version called a ring signature, introduced by Rivest et al. in [34], was an autonomous scheme without Group Manager and anonymity revocation. Various modifications of this scheme appeared later: linkable ring signature [26, 27, 17] allowed to determine if two signatures were produced by the same group member, traceable ring signature [24, 23] limited excessive anonymity by providing possibility to trace the signer of two messages with respect to the same metainformation (or “tag” in terms of [24]). A similar cryptographic construction is also known as a ad-hoc group signature [16, 38]. It emphasizes the arbitrary group formation, whereas group/ring signature schemes rather imply a fixed set of members. For the most part, our solution is based on the work “Traceable ring signature” by E. Fujisaki and K. Suzuki [24]. In order to distinguish the original algorithm and our modification we will call the latter a one-time ring signature, stressing the user’s capability to produce only one valid signature under his private key. We weakened the traceability property and kept the linkability only to provide one-timeness: the public key may appear in many foreign verifying sets and the private key can be used for generating a unique anonymous signature. In case of a double spend attempt these two signatures will be linked together, but revealing the signer is not necessary for our purposes. 4.2 Definitions 4.2.1 Elliptic curve parameters As our base signature algorithm we chose to use the fast scheme EdDSA, which is developed and implemented by D.J. Bernstein et al. [18]. Like Bitcoin’s ECDSA it is based on the elliptic curve discrete logarithm problem, so our scheme could also be applied to Bitcoin in future. Common parameters are: \(q\): a prime number; \(q = 2^{255} - 19\); \(d\): an element of \(\mathbb{F}_q\); \(d = -121665/121666\); \(E\): an elliptic curve equation; \(-x^2 + y^2 = 1 + dx^2y^2\); \(G\): a base point; \(G = (x, -4/5)\); \(l\): a prime order of the base point; \(l = 2^{252} + 27742317777372353535851937790883648493\); \(H_s\): a cryptographic hash function \(\{0, 1\}^* \to \mathbb{F}_q\); \(H_p\): a deterministic hash function \(E(\mathbb{F}_q) \to E(\mathbb{F}_q)\). 4.2.2 Terminology Enhanced privacy requires a new terminology which should not be confused with Bitcoin entities. private ec-key is a standard elliptic curve private key: a number \(a \in [1, l - 1]\); public ec-key is a standard elliptic curve public key: a point \(A = aG\); one-time keypair is a pair of private and public ec-keys; 5 key, but the keys of all the users of his group. A verifier is convinced that the real signer is a member of the group, but cannot exclusively identify the signer. The original protocol required a trusted third party (called the Group Manager), and he was the only one who could trace the signer. The next version called a ring signature, introduced by Rivest et al. in [34], was an autonomous scheme without Group Manager and anonymity revocation. Various modifications of this scheme appeared later: linkable ring signature [26, 27, 17] allowed to determine if two signatures were produced by the same group member, traceable ring signature [24, 23] limited excessive anonymity by providing possibility to trace the signer of two messages with respect to the same metainformation (or “tag” in terms of [24]). A similar cryptographic construction is also known as a ad-hoc group signature [16, 38]. It emphasizes the arbitrary group formation, whereas group/ring signature schemes rather imply a fixed set of members. For the most part, our solution is based on the work “Traceable ring signature” by E. Fujisaki and K. Suzuki [24]. In order to distinguish the original algorithm and our modification we will call the latter a one-time ring signature, stressing the user’s capability to produce only one valid signature under his private key. We weakened the traceability property and kept the linkability only to provide one-timeness: the public key may appear in many foreign verifying sets and the private key can be used for generating a unique anonymous signature. In case of a double spend attempt these two signatures will be linked together, but revealing the signer is not necessary for our purposes. 4.2 Definitions 4.2.1 Elliptic curve parameters As our base signature algorithm we chose to use the fast scheme EdDSA, which is developed and implemented by D.J. Bernstein et al. [18]. Like Bitcoin’s ECDSA it is based on the elliptic curve discrete logarithm problem, so our scheme could also be applied to Bitcoin in future. Common parameters are: \(q\): a prime number; \(q = 2^{255} - 19\); \(d\): an element of \(\mathbb{F}_q\); \(d = -121665/121666\); \(E\): an elliptic curve equation; \(-x^2 + y^2 = 1 + dx^2y^2\); \(G\): a base point; \(G = (x, -4/5)\); \(l\): a prime order of the base point; \(l = 2^{252} + 27742317777372353535851937790883648493\); \(H_s\): a cryptographic hash function \(\{0, 1\}^* \to \mathbb{F}_q\); \(H_p\): a deterministic hash function \(E(\mathbb{F}_q) \to E(\mathbb{F}_q)\). 4.2.2 Terminology Enhanced privacy requires a new terminology which should not be confused with Bitcoin entities. private ec-key is a standard elliptic curve private key: a number \(a \in [1, l - 1]\); public ec-key is a standard elliptic curve public key: a point \(A = aG\); one-time keypair is a pair of private and public ec-keys; 5 10 Linkability in the sense of "linkable ring signatures" means we can tell if two outgoing transactions came from the same source without revealing who the source is. The authors weakened linkability so as to (a) preserve privacy, but still (b) spot any transaction using a private key a second time as invalid. Okay, so this is an order-of-events question. Consider the following scenario. My mining computer will have the current blockchain, it will have it’s own block of transactions it calls legitimate, it will be working on that block in a proof-of-work puzzle, and it will have a list of pending transactions to be added to the next block. It will also be sending any new transactions into that pool of pending transactions. If I do not solve the next block, but someone else does, I get an updated copy of the blockchain. The block I was working on and my list of pending transactions both may have some transactions that are now incorporated into the blockchain. Unravel my pending block, combine that with my list of pending transactions, and call that my pool of pending transactions. Remove any that are now officially in the blockchain. Now, what do I do? Should I first go through and "remove all double-spends"? On the other hand, should I search through the list and make sure that each private key has not yet been used, and if it has been used already in my list, then I received the first copy first, and hence any further copy is illegitimate. Thus I proceed to simply delete all instances after the first of the the same private key. Algebraic geometry has never been my strong suit. http://en.wikipedia.org/wiki/EdDSA Such speed, much wow. THIS is algebraic geometry for the win. Not that I’d know anything about that. Problematically, or not, discrete logs are getting very fast. And quantum computers eat them for breakfast. http://link.springer.com/article/10.1007/s13389-012-0027-1 This becomes a really important number, but there is no explanation or citation to how it was chosen. Simply choosing a single known large prime would be fine, but if there are known facts about this large prime, that could influence our choice. Different variants of cryptonote could choose different values of ell, but there is no discussion in this paper about how that choice will affect our choices of other global parameters listed on page 5. This paper needs a section on choosing parameter values.
private user key is a pair \((a, b)\) of two different private ec-keys; tracking key is a pair \((a, B)\) of private and public ec-key (where \(B = bG\) and \(a \neq b\)); public user key is a pair \((A, B)\) of two public ec-keys derived from \((a, b)\); standard address is a representation of a public user key given into human friendly string with error correction; truncated address is a representation of the second half (point \(B\)) of a public user key given into human friendly string with error correction. The transaction structure remains similar to the structure in Bitcoin: every user can choose several independent incoming payments (transactions outputs), sign them with the corresponding private keys and send them to different destinations. Contrary to Bitcoin’s model, where a user possesses unique private and public key, in the proposed model a sender generates a one-time public key based on the recipient’s address and some random data. In this sense, an incoming transaction for the same recipient is sent to a one-time public key (not directly to a unique address) and only the recipient can recover the corresponding private part to redeem his funds (using his unique private key). The recipient can spend the funds using a ring signature, keeping his ownership and actual spending anonymous. The details of the protocol are explained in the next subsections. 4.3 Unlinkable payments Classic Bitcoin addresses, once being published, become unambiguous identifier for incoming payments, linking them together and tying to the recipient’s pseudonyms. If someone wants to receive an “untied” transaction, he should convey his address to the sender by a private channel. If he wants to receive different transactions which cannot be proven to belong to the same owner he should generate all the different addresses and never publish them in his own pseudonym. Public Private Alice Carol Bob’s addr 1 Bob’s addr 2 Bob’s key 1 Bob’s key 2 Bob Fig. 2. Traditional Bitcoin keys/transactions model. We propose a solution allowing a user to publish a single address and receive unconditional unlinkable payments. The destination of each CryptoNote output (by default) is a public key, derived from recipient’s address and sender’s random data. The main advantage against Bitcoin is that every destination key is unique by default (unless the sender uses the same data for each of his transactions to the same recipient). Hence, there is no such issue as “address reuse” by design and no observer can determine if any transactions were sent to a specific address or link two addresses together. 6 private user key is a pair \((a, b)\) of two different private ec-keys; tracking key is a pair \((a, B)\) of private and public ec-key (where \(B = bG\) and \(a \neq b\)); public user key is a pair \((A, B)\) of two public ec-keys derived from \((a, b)\); standard address is a representation of a public user key given into human friendly string with error correction; truncated address is a representation of the second half (point \(B\)) of a public user key given into human friendly string with error correction. The transaction structure remains similar to the structure in Bitcoin: every user can choose several independent incoming payments (transactions outputs), sign them with the corresponding private keys and send them to different destinations. Contrary to Bitcoin’s model, where a user possesses unique private and public key, in the proposed model a sender generates a one-time public key based on the recipient’s address and some random data. In this sense, an incoming transaction for the same recipient is sent to a one-time public key (not directly to a unique address) and only the recipient can recover the corresponding private part to redeem his funds (using his unique private key). The recipient can spend the funds using a ring signature, keeping his ownership and actual spending anonymous. The details of the protocol are explained in the next subsections. 4.3 Unlinkable payments Classic Bitcoin addresses, once being published, become unambiguous identifier for incoming payments, linking them together and tying to the recipient’s pseudonyms. If someone wants to receive an “untied” transaction, he should convey his address to the sender by a private channel. If he wants to receive different transactions which cannot be proven to belong to the same owner he should generate all the different addresses and never publish them in his own pseudonym. Public Private Alice Carol Bob’s addr 1 Bob’s addr 2 Bob’s key 1 Bob’s key 2 Bob Fig. 2. Traditional Bitcoin keys/transactions model. We propose a solution allowing a user to publish a single address and receive unconditional unlinkable payments. The destination of each CryptoNote output (by default) is a public key, derived from recipient’s address and sender’s random data. The main advantage against Bitcoin is that every destination key is unique by default (unless the sender uses the same data for each of his transactions to the same recipient). Hence, there is no such issue as “address reuse” by design and no observer can determine if any transactions were sent to a specific address or link two addresses together. 6 11 So this is like Bitcoin, but with infinite, anonymous PO Boxes, redeemable only by the receiver generating a private key that is as anonymous as a ring signature can be. Bitcoin works this way. If Alex has 0.112 Bitcoin in her wallet she just received from Frank, she really has a signed message "I, [FRANK], send 0.112 Bitcoin to [alex] + H0 + N0" where 1) Frank has signed the message with his private key [FRANK], 2) Frank has signed the message with Alex’s public key, [alex], 3) Frank has included some form of the history of the bitcoin, H0, and 4) Frank includes a random bit of data called the nonce, N0. If Alex then wants to send 0.011 Bitcoin to Charlene, she will take Frank’s message, and she will set that to H1, and sign two messages: one for her transaction, and one for the change. H1= "I, [FRANK], send 0.112 Bitcoin to [alex] + H0 + N" "I, [ALEX], send 0.011 Bitcoin to [charlene] + H1 + N1" "I, [ALEX], send 0.101 Bitcoin as change to [alex] + H1 + N2." where Alex signs both messages with her private key [ALEX], the first message with Charlene’s public key [charlene], the second message with Alex’s public key [alex], and including the histories and some randomly generated nonces N1 and N2 appropriately. Cryptonote works this way: If Alex has 0.112 Cryptonote in her wallet she just received from Frank, she really has a signed message "I, [someone in an ad-hoc group], send 0.112 Cryptonote to [a one-time address] + H0 + N0." Alex discovered that this was her money by checking her private key [ALEX] against [a one-time address] for every passing message, and if she wishes to spend it she does so in the following way. She chooses a recipient of the money, perhaps Charlene has started voting for drone-strikes so Alex wants to send money to Brenda instead. So Alex looks up Brenda’s public key, [brenda], and uses her own private key, [ALEX], to generate a one-time address [ALEX+brenda]. She then chooses an arbitrary collection C from the network of cryptonote users and she constructs a ring signature from this ad-hoc group. We set our history as the previous message, add nonces, and proceed as usual? H1 = "I, [someone in an ad-hoc group], send 0.112 Cryptonote to [a one-time address] + H0 + N0." "I, [someone in the collection C], send 0.011 Cryptonote to [one-time-address-made-fromALEX+brenda] + H1 + N1" "I, [someone in the collection C], send 0.101 Cryptonote as change to [one-time-address-madefrom-ALEX+alex] + H1 + N2" Now, Alex and Brenda both scan all incoming messages for any one-time-addresses that were created using their key. If they find any, then that message is their very own brand new cryptonote! And even then, the transaction will still hit the blockchain. If the coins entering that address are known to be sent from criminals, political contributors, or from committees and accounts with strict budgets (i.e. embezzling), or if the new owner of these coins ever makes a mistake and sends these coins to a common address with coins he is known to own, the anonymity jig is up in bitcoin.
private user key is a pair \((a, b)\) of two different private ec-keys; tracking key is a pair \((a, B)\) of private and public ec-key (where \(B = bG\) and \(a \neq b\)); public user key is a pair \((A, B)\) of two public ec-keys derived from \((a, b)\); standard address is a representation of a public user key given into human friendly string with error correction; truncated address is a representation of the second half (point \(B\)) of a public user key given into human friendly string with error correction. The transaction structure remains similar to the structure in Bitcoin: every user can choose several independent incoming payments (transactions outputs), sign them with the corresponding private keys and send them to different destinations. Contrary to Bitcoin’s model, where a user possesses unique private and public key, in the proposed model a sender generates a one-time public key based on the recipient’s address and some random data. In this sense, an incoming transaction for the same recipient is sent to a one-time public key (not directly to a unique address) and only the recipient can recover the corresponding private part to redeem his funds (using his unique private key). The recipient can spend the funds using a ring signature, keeping his ownership and actual spending anonymous. The details of the protocol are explained in the next subsections. 4.3 Unlinkable payments Classic Bitcoin addresses, once being published, become unambiguous identifier for incoming payments, linking them together and tying to the recipient’s pseudonyms. If someone wants to receive an “untied” transaction, he should convey his address to the sender by a private channel. If he wants to receive different transactions which cannot be proven to belong to the same owner he should generate all the different addresses and never publish them in his own pseudonym. Public Private Alice Carol Bob’s addr 1 Bob’s addr 2 Bob’s key 1 Bob’s key 2 Bob Fig. 2. Traditional Bitcoin keys/transactions model. We propose a solution allowing a user to publish a single address and receive unconditional unlinkable payments. The destination of each CryptoNote output (by default) is a public key, derived from recipient’s address and sender’s random data. The main advantage against Bitcoin is that every destination key is unique by default (unless the sender uses the same data for each of his transactions to the same recipient). Hence, there is no such issue as “address reuse” by design and no observer can determine if any transactions were sent to a specific address or link two addresses together. 6 private user key is a pair \((a, b)\) of two different private ec-keys; tracking key is a pair \((a, B)\) of private and public ec-key (where \(B = bG\) and \(a \neq b\)); public user key is a pair \((A, B)\) of two public ec-keys derived from \((a, b)\); standard address is a representation of a public user key given into human friendly string with error correction; truncated address is a representation of the second half (point \(B\)) of a public user key given into human friendly string with error correction. The transaction structure remains similar to the structure in Bitcoin: every user can choose several independent incoming payments (transactions outputs), sign them with the corresponding private keys and send them to different destinations. Contrary to Bitcoin’s model, where a user possesses unique private and public key, in the proposed model a sender generates a one-time public key based on the recipient’s address and some random data. In this sense, an incoming transaction for the same recipient is sent to a one-time public key (not directly to a unique address) and only the recipient can recover the corresponding private part to redeem his funds (using his unique private key). The recipient can spend the funds using a ring signature, keeping his ownership and actual spending anonymous. The details of the protocol are explained in the next subsections. 4.3 Unlinkable payments Classic Bitcoin addresses, once being published, become unambiguous identifier for incoming payments, linking them together and tying to the recipient’s pseudonyms. If someone wants to receive an “untied” transaction, he should convey his address to the sender by a private channel. If he wants to receive different transactions which cannot be proven to belong to the same owner he should generate all the different addresses and never publish them in his own pseudonym. Public Private Alice Carol Bob’s addr 1 Bob’s addr 2 Bob’s key 1 Bob’s key 2 Bob Fig. 2. Traditional Bitcoin keys/transactions model. We propose a solution allowing a user to publish a single address and receive unconditional unlinkable payments. The destination of each CryptoNote output (by default) is a public key, derived from recipient’s address and sender’s random data. The main advantage against Bitcoin is that every destination key is unique by default (unless the sender uses the same data for each of his transactions to the same recipient). Hence, there is no such issue as “address reuse” by design and no observer can determine if any transactions were sent to a specific address or link two addresses together. 6 12 Hence, rather than users sending coins from address (which is really a public key) to address (another public key) using their private keys, users are sending coins from one-time PO-box (which is generating using your friends public key) to one-time PO-box (similarly) using your own private keys. In a sense, we’re saying "Okay, everyone take your hands offthe money while it’s being transferred around! It’s simply enough to know that our keys can open that box and that we know how much money is in the box. Never put your fingerprints on the PO Box or actually use it, just trade the box filled with cash itself. That way we don’t know who sent what, but the contents of these public addresses are still frictionless, fungible, divisible, and still possess all the other nice qualities of money we desire like bitcoin." An infinite set of PO boxes. You publish an address, I have a private key. I use my private key and your address, and some random data, to generate a public key. The algorithm is designed such that, since your address was used to generate the public key, only YOUR private key works to unlock the message. An observer, Eve, sees you publish your address, and sees the public key I announce. However, she doesn’t know if I announced my public key based on your address or hers, or Brenda’s or Charlene’s, or whoever’s. She checks her private key against the public key I announced and sees it doesn’t work; it isn’t her money. She doens’t know anyone else’s private key, and only the recipient of the message has the private key that can unlock the message. So no one listening in can determine who received the money much less take the money.
Public Private Alice Carol One-time key One-time key One-time key Bob Bob’s Key Bob’s Address Fig. 3. CryptoNote keys/transactions model. First, the sender performs a Diffie-Hellman exchange to get a shared secret from his data and half of the recipient’s address. Then he computes a one-time destination key, using the shared secret and the second half of the address. Two different ec-keys are required from the recipient for these two steps, so a standard CryptoNote address is nearly twice as large as a Bitcoin wallet address. The receiver also performs a Diffie-Hellman exchange to recover the corresponding secret key. A standard transaction sequence goes as follows: 1. Alice wants to send a payment to Bob, who has published his standard address. She unpacks the address and gets Bob’s public key \((A, B)\). 2. Alice generates a random \(r \in [1, l-1]\) and computes a one-time public key \(P = H_s(rA)G + B\). 3. Alice uses \(P\) as a destination key for the output and also packs value \(R = rG\) (as a part of the Diffie-Hellman exchange) somewhere into the transaction. Note that she can create other outputs with unique public keys: different recipients’ keys \((A_i, B_i)\) imply different \(P_i\) even with the same \(r\). Transaction Tx public key Tx output Amount Destination key \(R = rG\) \(P = H_s(rA)G + B\) Receiver’s public key Sender’s random data \(r\) \((A, B)\) Fig. 4. Standard transaction structure. 4. Alice sends the transaction. 5. Bob checks every passing transaction with his private key \((a, b)\), and computes \(P' = H_s(aR)G + B\). If Alice’s transaction for with Bob as the recipient was among them, then \(aR = arG = rA\) and \(P' = P\). 7 Public Private Alice Carol One-time key One-time key One-time key Bob Bob’s Key Bob’s Address Fig. 3. CryptoNote keys/transactions model. First, the sender performs a Diffie-Hellman exchange to get a shared secret from his data and half of the recipient’s address. Then he computes a one-time destination key, using the shared secret and the second half of the address. Two different ec-keys are required from the recipient for these two steps, so a standard CryptoNote address is nearly twice as large as a Bitcoin wallet address. The receiver also performs a Diffie-Hellman exchange to recover the corresponding secret key. A standard transaction sequence goes as follows: 1. Alice wants to send a payment to Bob, who has published his standard address. She unpacks the address and gets Bob’s public key \((A, B)\). 2. Alice generates a random \(r \in [1, l-1]\) and computes a one-time public key \(P = H_s(rA)G + B\). 3. Alice uses \(P\) as a destination key for the output and also packs value \(R = rG\) (as a part of the Diffie-Hellman exchange) somewhere into the transaction. Note that she can create other outputs with unique public keys: different recipients’ keys \((A_i, B_i)\) imply different \(P_i\) even with the same \(r\). Transaction Tx public key Tx output Amount Destination key \(R = rG\) \(P = H_s(rA)G + B\) Receiver’s public key Sender’s random data \(r\) \((A, B)\) Fig. 4. Standard transaction structure. 4. Alice sends the transaction. 5. Bob checks every passing transaction with his private key \((a, b)\), and computes \(P' = H_s(aR)G + B\). If Alice’s transaction for with Bob as the recipient was among them, then \(aR = arG = rA\) and \(P' = P\). 7 13 I wonder how much of a pain in the neck it would be to implement a choice of cryptography scheme. Elliptic or otherwise. So if some scheme is broken in the future, the currency switches without concern. Probably a big pain in the ass. Okay, this is exactly what I just explained in my previous comment. The Diffie-Hellman-type exchanges are neato. Say Alex and Brenda each have a secret number, A and B, and a number they don’t care about keeping secret, a and b. They wish to generate a shared secret without Eva discovering it. Diffie and Hellman came up with a way for Alex and Brenda to share the public numbers a and b, but not the private numbers A and B, and generate a shared secret, K. Using this shared secret, K, without any Eva listening in being able to generate the same K, Alex and Brenda can now use K as a secret encryption key and pass secret messages back and forth. Here’s how it CAN work, although it should work with much larger numbers than 100. We’ll use 100 because working over the integers modulo 100 is equivalent to "throwing out all but the last two digit of a number." Alex and Brenda each choose A, a, B, and b. They keep A and B secret. Alex tells Brenda her value of a modulo 100 (just the last two digits) and Brenda tells Alex her value of b modulo 100. Now Eva knows (a,b) modulo 100. But Alex knows (a,b,A) so she can compute x=abA modulo 100. Alex chops offall but the last digit because we’re working under the integers modulo 100 again. Similarly, Brenda knows (a,b,B) so she can compute y=abB modulo 100. Alex can now publish x and Brenda can publish y. But now Alex can compute yA = abBA modulo 100, and Brenda can compute xB = abBA modulo 100. They both know the same number! But all Eva has heard is (a,b,abA,abB). She has no easy way of computing abA*B. Now, this is the easiest and least secure way of thinking about the Diffie-Hellman exchange. More secure versions exist. But most versions work because integer factorization and discrete logarithms are difficult, and both of those problems are easily solved by quantum computers. I will look into whether any versions that are resistant to quantum exist. http://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange The "standard txn sequence" listed here is missing a whole bunch of steps, like SIGNATURES. They’re just taken for granted in here. Which is really bad, because the order in which we sign stuff, the information included in the signed message, and so on... all of this is extremely important to the protocol. Getting one or two of the steps wrong, even slightly out of order, while implementing "the standard transaction sequence" could throw the security of the whole system into question. Furthermore, the proofs presented later in the paper may not be sufficiently rigorous if the framework under which they work is as loosely defined as in this section.
Public Private Alice Carol One-time key One-time key One-time key Bob Bob’s Key Bob’s Address Fig. 3. CryptoNote keys/transactions model. First, the sender performs a Diffie-Hellman exchange to get a shared secret from his data and half of the recipient’s address. Then he computes a one-time destination key, using the shared secret and the second half of the address. Two different ec-keys are required from the recipient for these two steps, so a standard CryptoNote address is nearly twice as large as a Bitcoin wallet address. The receiver also performs a Diffie-Hellman exchange to recover the corresponding secret key. A standard transaction sequence goes as follows: 1. Alice wants to send a payment to Bob, who has published his standard address. She unpacks the address and gets Bob’s public key \((A, B)\). 2. Alice generates a random \(r \in [1, l-1]\) and computes a one-time public key \(P = H_s(rA)G + B\). 3. Alice uses \(P\) as a destination key for the output and also packs value \(R = rG\) (as a part of the Diffie-Hellman exchange) somewhere into the transaction. Note that she can create other outputs with unique public keys: different recipients’ keys \((A_i, B_i)\) imply different \(P_i\) even with the same \(r\). Transaction Tx public key Tx output Amount Destination key \(R = rG\) \(P = H_s(rA)G + B\) Receiver’s public key Sender’s random data \(r\) \((A, B)\) Fig. 4. Standard transaction structure. 4. Alice sends the transaction. 5. Bob checks every passing transaction with his private key \((a, b)\), and computes \(P' = H_s(aR)G + B\). If Alice’s transaction for with Bob as the recipient was among them, then \(aR = arG = rA\) and \(P' = P\). 7 Public Private Alice Carol One-time key One-time key One-time key Bob Bob’s Key Bob’s Address Fig. 3. CryptoNote keys/transactions model. First, the sender performs a Diffie-Hellman exchange to get a shared secret from his data and half of the recipient’s address. Then he computes a one-time destination key, using the shared secret and the second half of the address. Two different ec-keys are required from the recipient for these two steps, so a standard CryptoNote address is nearly twice as large as a Bitcoin wallet address. The receiver also performs a Diffie-Hellman exchange to recover the corresponding secret key. A standard transaction sequence goes as follows: 1. Alice wants to send a payment to Bob, who has published his standard address. She unpacks the address and gets Bob’s public key \((A, B)\). 2. Alice generates a random \(r \in [1, l-1]\) and computes a one-time public key \(P = H_s(rA)G + B\). 3. Alice uses \(P\) as a destination key for the output and also packs value \(R = rG\) (as a part of the Diffie-Hellman exchange) somewhere into the transaction. Note that she can create other outputs with unique public keys: different recipients’ keys \((A_i, B_i)\) imply different \(P_i\) even with the same \(r\). Transaction Tx public key Tx output Amount Destination key \(R = rG\) \(P = H_s(rA)G + B\) Receiver’s public key Sender’s random data \(r\) \((A, B)\) Fig. 4. Standard transaction structure. 4. Alice sends the transaction. 5. Bob checks every passing transaction with his private key \((a, b)\), and computes \(P' = H_s(aR)G + B\). If Alice’s transaction for with Bob as the recipient was among them, then \(aR = arG = rA\) and \(P' = P\). 7 14 Note that the author(s?) do a terrible job of keeping their terminology straight throughout the text, but especially in this next bit. Next incarnation of this paper will necessarily be much more rigorous. In the text they refer to P as their one-time public key. In the diagram, they refer to R as their "Tx public key" and P as their "Destination key." If I were going to re-write this, I’d very specifically lay out some terminology before discussing these sections. This ell is massive. See page 5. Who chooses ell? Diagram illustrates that the transaction public key \(R = rG\), which is random and chosen by the sender, is not part of Tx output. This is because it could be the same for multiple transactions to multiple people, and isn’t used LATER to spend. A fresh R is generated every time you want to broadcast a new CryptoNote transaction. Furthermore, R is only used to check if you are the recipient of the transaction. It’s not junk data, but it’s junk to anyone without the private keys associated with (A,B). The Destination key, on the other hand, \(P = H_s(rA)G + B\) is part of Tx output. Everyone rifling through every passing transaction’s data must check their own generated P* against this P to see if they own this passing transaction. Anyone with an unspent transaction output (UTXO) will have a bunch of these Ps laying around with amounts. In order to spend, they sign some new message including P. Alice must sign this transaction with one-time private key(s) associated with the unspent transaction output(s) Destination Key(s). Each destination key owned by Alice comes equipped with a one-time private key also owned (presumably) by Alice. Every time Alice wants to send the contents of a destination key to me, or Bob, or Brenda, or Charlie or Charlene, she uses her private key to sign the transaction. Upon receipt of transaction, I will receive a new Tx public key, a new Destination public key, and I will be able to recover a new one-time private key x. Combining my one-time private key, x, with new transaction’s public Destination key(s) is how we send a new transaction
- Bob can recover the corresponding one-time private key: \(x = H_s(aR) + b\), so as \(P = xG\). He can spend this output at any time by signing a transaction with \(x\). Transaction Tx public key Tx output Amount Destination key \(P' = H_s(aR)G + bG\) one-time public key \(x = H_s(aR) + b\) one-time private key Receiver’s private key \((a, b)\) \(R\) \(P'\) \(\stackrel{?}{=} P\) Fig. 5. Incoming transaction check. As a result Bob gets incoming payments, associated with one-time public keys which are unlinkable for a spectator. Some additional notes: • When Bob “recognizes” his transactions (see step 5) he practically uses only half of his private information: \((a, B)\). This pair, also known as the tracking key, can be passed to a third party (Carol). Bob can delegate her the processing of new transactions. Bob doesn’t need to explicitly trust Carol, because she can’t recover the one-time secret key \(p\) without Bob’s full private key \((a, b)\). This approach is useful when Bob lacks bandwidth or computation power (smartphones, hardware wallets etc.). • In case Alice wants to prove she sent a transaction to Bob’s address she can either disclose \(r\) or use any kind of zero-knowledge protocol to prove she knows \(r\) (for example by signing the transaction with \(r\)). • If Bob wants to have an audit compatible address where all incoming transaction are linkable, he can either publish his tracking key or use a truncated address. That address represent only one public ec-key \(B\), and the remaining part required by the protocol is derived from it as follows: \(a = H_s(B)\) and \(A = H_s(B)G\). In both cases every person is able to “recognize” all of Bob’s incoming transaction, but, of course, none can spend the funds enclosed within them without the secret key \(b\). 4.4 One-time ring signatures A protocol based on one-time ring signatures allows users to achieve unconditional unlinkability. Unfortunately, ordinary types of cryptographic signatures permit to trace transactions to their respective senders and receivers. Our solution to this deficiency lies in using a different signature type than those currently used in electronic cash systems. We will first provide a general description of our algorithm with no explicit reference to electronic cash. A one-time ring signature contains four algorithms: (GEN, SIG, VER, LNK): GEN: takes public parameters and outputs an ec-pair \((P, x)\) and a public key \(I\). SIG: takes a message \(m\), a set \(S'\) of public keys \(\{P_i\}_{i \neq s}\), a pair \((P_s, x_s)\) and outputs a signature \(\sigma\) and a set \(S = S' \cup \{P_s\}\). 8
-
Bob can recover the corresponding one-time private key: \(x = H_s(aR) + b\), so as \(P = xG\). He can spend this output at any time by signing a transaction with \(x\). Transaction Tx public key Tx output Amount Destination key \(P' = H_s(aR)G + bG\) one-time public key \(x = H_s(aR) + b\) one-time private key Receiver’s private key \((a, b)\) \(R\) \(P'\) \(\stackrel{?}{=} P\) Fig. 5. Incoming transaction check. As a result Bob gets incoming payments, associated with one-time public keys which are unlinkable for a spectator. Some additional notes: • When Bob “recognizes” his transactions (see step 5) he practically uses only half of his private information: \((a, B)\). This pair, also known as the tracking key, can be passed to a third party (Carol). Bob can delegate her the processing of new transactions. Bob doesn’t need to explicitly trust Carol, because she can’t recover the one-time secret key \(p\) without Bob’s full private key \((a, b)\). This approach is useful when Bob lacks bandwidth or computation power (smartphones, hardware wallets etc.). • In case Alice wants to prove she sent a transaction to Bob’s address she can either disclose \(r\) or use any kind of zero-knowledge protocol to prove she knows \(r\) (for example by signing the transaction with \(r\)). • If Bob wants to have an audit compatible address where all incoming transaction are linkable, he can either publish his tracking key or use a truncated address. That address represent only one public ec-key \(B\), and the remaining part required by the protocol is derived from it as follows: \(a = H_s(B)\) and \(A = H_s(B)G\). In both cases every person is able to “recognize” all of Bob’s incoming transaction, but, of course, none can spend the funds enclosed within them without the secret key \(b\). 4.4 One-time ring signatures A protocol based on one-time ring signatures allows users to achieve unconditional unlinkability. Unfortunately, ordinary types of cryptographic signatures permit to trace transactions to their respective senders and receivers. Our solution to this deficiency lies in using a different signature type than those currently used in electronic cash systems. We will first provide a general description of our algorithm with no explicit reference to electronic cash. A one-time ring signature contains four algorithms: (GEN, SIG, VER, LNK): GEN: takes public parameters and outputs an ec-pair \((P, x)\) and a public key \(I\). SIG: takes a message \(m\), a set \(S'\) of public keys \(\{P_i\}_{i \neq s}\), a pair \((P_s, x_s)\) and outputs a signature \(\sigma\) and a set \(S = S' \cup \{P_s\}\). 8 15 What does an unspent transaction output look like here? The diagram suggests that transaction output consists only of two data points: amount and destination key. But this isn’t sufficient because when I try to spend this "output" I will still need to know R=rG. Remember, r is chosen by the sender, and R is a) used to recognize incoming cryptonotes as your own and b) used to generate the one-time private key used to "claim" your cryptonote. The part about this that I don’t understand? Taking the theoretical "okay, we have these signatures and transactions, and we pass ’em back and forth" into the world of programming "okay what information specifically makes up an individual UTXO?" Best way to answer that question is to dig into the body of completely uncommented code. Way to go, bytecoin team. Recall: linkability means "did the same person send?" and unlinkability means "did the same person receive?". So a system can be linkable or non-linkable, unlinkable or non-unlinkable. Annoying, I know. So when Nic van Saberhagen here says "...incoming payments [are] associated with one-time public keys which are unlinkable for a spectator," let’s see what he means. First, consider a situation in which Alice sends Bob two separate transactions from the same address to the same address. In the Bitcoin universe, Alice has already made the mistake of sending from the same address and so the transaction has failed our desire for limited linkability. Furthermore, since she sent the money to the same address, she’s failed our desire for unlinkability. This bitcoin transaction was both (totally) linkable and non-unlinkable. On the other hand, in the cryptonote universe, let’s say that Alice sends Bob some cryptonote, using Bob’s public address. She chooses as her obfuscating set of public keys all known public keys in the Washington DC metro area. Alex generates a one-time public key using her own information and Bob’s public information. She sends the money off, and any observer will only be able to glean "Someone from the Washington DC metro area sent 2.3 cryptonotes to the one-time public address XYZ123." We have a probabilistic control over linkability here, so we’ll call this "almost non-linkable." We also only see the one-time public keys money is sent to. Even if we suspected the receiver was Bob, we don’t have his private keys and so we can’t test whether a passing transaction belongs to Bob let alone generate his one-time private key to redeem his cryptonote. So this is, in fact, totally "unlinkable." So, this is the neatest trick of all. Who wants to really trust another MtGox? We may be comfortable storing some amount of BTC on Coinbase, but the ultimate in bitcoin security is a physical wallet. Which is inconvenient. In this case, you can trustlessly give away half of your private key without compromising your own ability to spend money. When doing this, all you are doing is telling someone how to break unlinkability. The other properties of CN acting like a currency are preserved, like proof against double spending and whatnot.
-
Bob can recover the corresponding one-time private key: \(x = H_s(aR) + b\), so as \(P = xG\). He can spend this output at any time by signing a transaction with \(x\). Transaction Tx public key Tx output Amount Destination key \(P' = H_s(aR)G + bG\) one-time public key \(x = H_s(aR) + b\) one-time private key Receiver’s private key \((a, b)\) \(R\) \(P'\) \(\stackrel{?}{=} P\) Fig. 5. Incoming transaction check. As a result Bob gets incoming payments, associated with one-time public keys which are unlinkable for a spectator. Some additional notes: • When Bob “recognizes” his transactions (see step 5) he practically uses only half of his private information: \((a, B)\). This pair, also known as the tracking key, can be passed to a third party (Carol). Bob can delegate her the processing of new transactions. Bob doesn’t need to explicitly trust Carol, because she can’t recover the one-time secret key \(p\) without Bob’s full private key \((a, b)\). This approach is useful when Bob lacks bandwidth or computation power (smartphones, hardware wallets etc.). • In case Alice wants to prove she sent a transaction to Bob’s address she can either disclose \(r\) or use any kind of zero-knowledge protocol to prove she knows \(r\) (for example by signing the transaction with \(r\)). • If Bob wants to have an audit compatible address where all incoming transaction are linkable, he can either publish his tracking key or use a truncated address. That address represent only one public ec-key \(B\), and the remaining part required by the protocol is derived from it as follows: \(a = H_s(B)\) and \(A = H_s(B)G\). In both cases every person is able to “recognize” all of Bob’s incoming transaction, but, of course, none can spend the funds enclosed within them without the secret key \(b\). 4.4 One-time ring signatures A protocol based on one-time ring signatures allows users to achieve unconditional unlinkability. Unfortunately, ordinary types of cryptographic signatures permit to trace transactions to their respective senders and receivers. Our solution to this deficiency lies in using a different signature type than those currently used in electronic cash systems. We will first provide a general description of our algorithm with no explicit reference to electronic cash. A one-time ring signature contains four algorithms: (GEN, SIG, VER, LNK): GEN: takes public parameters and outputs an ec-pair \((P, x)\) and a public key \(I\). SIG: takes a message \(m\), a set \(S'\) of public keys \(\{P_i\}_{i \neq s}\), a pair \((P_s, x_s)\) and outputs a signature \(\sigma\) and a set \(S = S' \cup \{P_s\}\). 8
- Bob can recover the corresponding one-time private key: \(x = H_s(aR) + b\), so as \(P = xG\). He can spend this output at any time by signing a transaction with \(x\). Transaction Tx public key Tx output Amount Destination key \(P' = H_s(aR)G + bG\) one-time public key \(x = H_s(aR) + b\) one-time private key Receiver’s private key \((a, b)\) \(R\) \(P'\) \(\stackrel{?}{=} P\) Fig. 5. Incoming transaction check. As a result Bob gets incoming payments, associated with one-time public keys which are unlinkable for a spectator. Some additional notes: • When Bob “recognizes” his transactions (see step 5) he practically uses only half of his private information: \((a, B)\). This pair, also known as the tracking key, can be passed to a third party (Carol). Bob can delegate her the processing of new transactions. Bob doesn’t need to explicitly trust Carol, because she can’t recover the one-time secret key \(p\) without Bob’s full private key \((a, b)\). This approach is useful when Bob lacks bandwidth or computation power (smartphones, hardware wallets etc.). • In case Alice wants to prove she sent a transaction to Bob’s address she can either disclose \(r\) or use any kind of zero-knowledge protocol to prove she knows \(r\) (for example by signing the transaction with \(r\)). • If Bob wants to have an audit compatible address where all incoming transaction are linkable, he can either publish his tracking key or use a truncated address. That address represent only one public ec-key \(B\), and the remaining part required by the protocol is derived from it as follows: \(a = H_s(B)\) and \(A = H_s(B)G\). In both cases every person is able to “recognize” all of Bob’s incoming transaction, but, of course, none can spend the funds enclosed within them without the secret key \(b\). 4.4 One-time ring signatures A protocol based on one-time ring signatures allows users to achieve unconditional unlinkability. Unfortunately, ordinary types of cryptographic signatures permit to trace transactions to their respective senders and receivers. Our solution to this deficiency lies in using a different signature type than those currently used in electronic cash systems. We will first provide a general description of our algorithm with no explicit reference to electronic cash. A one-time ring signature contains four algorithms: (GEN, SIG, VER, LNK): GEN: takes public parameters and outputs an ec-pair \((P, x)\) and a public key \(I\). SIG: takes a message \(m\), a set \(S'\) of public keys \(\{P_i\}_{i \neq s}\), a pair \((P_s, x_s)\) and outputs a signature \(\sigma\) and a set \(S = S' \cup \{P_s\}\). 8 16 Yes, so now we have a) a payment address and b) a payment ID. A critic could ask "do we really need to do this? After all, if a merchant receives 112.00678952 CN exactly, and that was my order, and I have a screenshot or a receipt or whatever, isn’t that insane degree of precision sufficient?" The answer is "maybe, most of the time, in day-to-day, face-to-face transactions." However, the more common situation (especially in the digial world) is this: a merchant sells a set of objects, each with a fixed price. Say object A is 0.001 CN, object B is 0.01 CN and object C is 0.1 CN. Now, if the merchant receives an order for 1.618 CN, there are many many (many!) ways to arrange an order for a customer. And so without some sort of payment ID, identifying the so-called "unique" order of a customer with the so-called "unique" cost of their order becomes impossible. Even funnier: if everything in my online store costs exactly 1.0 CN, and I get 1000 customers a day? And you want to prove that you bought exactly 3 objects two weeks ago? Without a payment ID? Good luck, buddy. Long story short: When Bob publishes a payment address, he may end up also publishing a payment ID as well (see, e.g. Poloniex XMR deposits). This is different than what is described in the text here where Alice is the one who generates the payment ID. There must be some way for Bob to generate a payment ID as well. \((a, B)\) Recall that the tracking key \((a, B)\) can be published; losing the secrecy of the value for ’a’ will not violate your ability to spend or allow folks to steal from you (I think... that would have to be proven), it will simply allow folks to see all incoming transactions. A truncated address, as described in this paragraph, simply takes the "private" part of the key and generates it from the "public" part. Revealing the value for ’a’ will remove non-linkability but will preserve the rest of the transactions. The author means "not unlinkable" because unlinkable refers to the receiver and linkable refers to the sender. It’s also clear the author didn’t realize that there were two different aspects to linkability. Since, after all, the transaction is a directed object on a graph, there will be two questions: "are these two transactions going to the same person?" and "are these two transactions coming from the same person?" This is a "no-going-back" policy under which the unlinkability property of CryptoNote is conditional. That is to say, Bob can choose his incoming transactions to be not unlinkable using this policy. This is a claim they prove under the Random Oracle Model. We’ll get to that; the Random Oracle has pros and cons.
VER: takes a message \(m\), a set \(S\), a signature \(\sigma\) and outputs "true" or "false". LNK: takes a set \(I = \{I_i\}\), a signature \(\sigma\) and outputs "linked" or "indep". The idea behind the protocol is fairly simple: a user produces a signature which can be checked by a set of public keys rather than a unique public key. The identity of the signer is indistinguishable from the other users whose public keys are in the set until the owner produces a second signature using the same keypair. Private keys \(x_0\) \(\cdots\) \(x_i\) \(\cdots\) \(x_n\) Public keys \(P_0\) \(\cdots\) \(P_i\) \(\cdots\) \(P_n\) Ring Signature sign verify Fig. 6. Ring signature anonymity. GEN: The signer picks a random secret key \(x \in [1, l-1]\) and computes the corresponding public key \(P = xG\). Additionally he computes another public key \(I = xH_p(P)\) which we will call the “key image”. SIG: The signer generates a one-time ring signature with a non-interactive zero-knowledge proof using the techniques from [21]. He selects a random subset \(S'\) of \(n\) from the other users’ public keys \(P_i\), his own keypair \((x, P)\) and key image \(I\). Let \(0 \leq s \leq n\) be signer’s secret index in \(S\) (so that his public key is \(P_s\)). He picks a random \(\{q_i \mid i = 0, \ldots, n\}\) and \(\{w_i \mid i = 0, \ldots, n, i \neq s\}\) from \((1, \ldots, l)\) and applies the following transformations: \[L_i = \begin{cases} q_iG & \text{if } i = s \\ q_iG + w_iP_i & \text{if } i \neq s \end{cases}\] \[R_i = \begin{cases} q_iH_p(P_i) & \text{if } i = s \\ q_iH_p(P_i) + w_iI & \text{if } i \neq s \end{cases}\] The next step is getting the non-interactive challenge: \(c = H_s(m, L_1, \ldots, L_n, R_1, \ldots, R_n)\) Finally the signer computes the response: \(c_i =\) wi, if i ̸= s c − nP i=0 ci mod l, if i = s ri = ( qi, if i ̸= s qs −csx mod l, if i = s The resulting signature is \(\sigma = (I, c_1, \ldots, c_n, r_1, \ldots, r_n)\). 9 VER: takes a message \(m\), a set \(S\), a signature \(\sigma\) and outputs “true” or “false”. LNK: takes a set \(\mathcal{I} = \{I_i\}\), a signature \(\sigma\) and outputs “linked” or “indep”. The idea behind the protocol is fairly simple: a user produces a signature which can be checked by a set of public keys rather than a unique public key. The identity of the signer is indistinguishable from the other users whose public keys are in the set until the owner produces a second signature using the same keypair. Private keys \(x_0\) \(\cdots\) \(x_i\) \(\cdots\) \(x_n\) Public keys \(P_0\) \(\cdots\) \(P_i\) \(\cdots\) \(P_n\) Ring Signature sign verify Fig. 6. Ring signature anonymity. GEN: The signer picks a random secret key \(x \in [1, l - 1]\) and computes the corresponding public key \(P = xG\). Additionally he computes another public key \(I = xH_p(P)\) which we will call the “key image”. SIG: The signer generates a one-time ring signature with a non-interactive zero-knowledge proof using the techniques from [21]. He selects a random subset \(S'\) of \(n\) from the other users’ public keys \(P_i\), his own keypair \((x, P)\) and key image \(I\). Let \(0 \leq s \leq n\) be signer’s secret index in \(S\) (so that his public key is \(P_s\)). He picks a random \(\{q_i \mid i = 0, \ldots, n\}\) and \(\{w_i \mid i = 0, \ldots, n, i \neq s\}\) from \((1, \ldots, l)\) and applies the following transformations: \[L_i = \begin{cases} q_i G, & \text{if } i = s \\\\ q_i G + w_i P_i, & \text{if } i \neq s \end{cases}\] \[R_i = \begin{cases} q_i H_p(P_i), & \text{if } i = s \\\\ q_i H_p(P_i) + w_i I, & \text{if } i \neq s \end{cases}\] The next step is getting the non-interactive challenge:
\[c = H_s(m, L_1, \ldots, L_n, R_1, \ldots, R_n)\] Finally the signer computes the response: \[c_i = \begin{cases} w_i, & \text{if } i \neq s \\\\ c - \sum_{i=0}^{n} c_i \mod l, & \text{if } i = s \end{cases}\] \[r_i = \begin{cases} q_i, & \text{if } i \neq s \\ q_s - c_s x \mod l, & \text{if } i = s \end{cases}\] The resulting signature is \(\sigma = (I, c_1, \ldots, c_n, r_1, \ldots, r_n)\). 9 17 Perhaps this is stupid, but care must be taken when unioning S and P_s. If you just append the last public key to the end, unlinkability is broken because anyone checking passing transactions can just check the last public key listed in each transaction and boom. That’s the public key associated with the sender. So after unioning, a pseudorandom number generator must be used to permute the public keys chosen. "...until the owner produces a second signature using the same keypair." I wish the author(s?) would elaborate on this. I believe this means "make sure that every time you choose a set of public keys to obfuscate yourself with, you pick a completely new set with no two keys alike." Which seems like a pretty strong condition to place upon unlinkability. Perhaps "you pick a new random set from all possible keys" with the assumption that, although nontrivial intersections will inevitably happen, they won’t happen often. Either way, I need to dig deeper into this statement. This is generating the ring signature. Zero-knowledge proofs are awesome: I challenge you to prove to me that you know a secret without revealing the secret. For example, say we are at the entrance of a donut-shaped cave, and at the back of the cave (beyond sight from the entrance) is a one-way door to which you claim you have the key. If you go one direction, it always lets you through, but if you go the other direction, you need a key. But you don’t even want to SHOW me the key, let alone show me that it opens the door. But you want to prove to me that you know how to open the door. In the interactive setting, I flip a coin. Heads is left, tails is right, and you go down the donut-shaped cave whichever way the coin directs you. At the back, beyond my sight, you open the door to come back around the other side. We repeat the coin-flipping experiment until I’m satisfied that you have the key. But that’s clearly the INTERACTIVE zero-knowledge proof. There are non-interactive versions in which you and I never have to communicate; this way, no eavesdroppers can interfere. http://en.wikipedia.org/wiki/Zero-knowledge_proof This is reversed from the previous definition.
VER: takes a message \(m\), a set \(S\), a signature \(\sigma\) and outputs “true” or “false”. LNK: takes a set \(\mathcal{I} = \{I_i\}\), a signature \(\sigma\) and outputs “linked” or “indep”. The idea behind the protocol is fairly simple: a user produces a signature which can be checked by a set of public keys rather than a unique public key. The identity of the signer is indistinguishable from the other users whose public keys are in the set until the owner produces a second signature using the same keypair. Private keys \(x_0\) \(\cdots\) \(x_i\) \(\cdots\) \(x_n\) Public keys \(P_0\) \(\cdots\) \(P_i\) \(\cdots\) \(P_n\) Ring Signature sign verify Fig. 6. Ring signature anonymity. GEN: The signer picks a random secret key \(x \in [1, l - 1]\) and computes the corresponding public key \(P = xG\). Additionally he computes another public key \(I = xH_p(P)\) which we will call the “key image”. SIG: The signer generates a one-time ring signature with a non-interactive zero-knowledge proof using the techniques from [21]. He selects a random subset \(S'\) of \(n\) from the other users’ public keys \(P_i\), his own keypair \((x, P)\) and key image \(I\). Let \(0 \leq s \leq n\) be signer’s secret index in \(S\) (so that his public key is \(P_s\)). He picks a random \(\{q_i \mid i = 0, \ldots, n\}\) and \(\{w_i \mid i = 0, \ldots, n, i \neq s\}\) from \((1, \ldots, l)\) and applies the following transformations: \[L_i = \begin{cases} q_i G, & \text{if } i = s \\\\ q_i G + w_i P_i, & \text{if } i \neq s \end{cases}\] \[R_i = \begin{cases} q_i H_p(P_i), & \text{if } i = s \\\\ q_i H_p(P_i) + w_i I, & \text{if } i \neq s \end{cases}\] The next step is getting the non-interactive challenge:
\[c = H_s(m, L_1, \ldots, L_n, R_1, \ldots, R_n)\] Finally the signer computes the response: \[c_i = \begin{cases} w_i, & \text{if } i \neq s \\\\ c - \sum_{i=0}^{n} c_i \mod l, & \text{if } i = s \end{cases}\] \[r_i = \begin{cases} q_i, & \text{if } i \neq s \\ q_s - c_s x \mod l, & \text{if } i = s \end{cases}\] The resulting signature is \(\sigma = (I, c_1, \ldots, c_n, r_1, \ldots, r_n)\). 9 VER: takes a message \(m\), a set \(S\), a signature \(\sigma\) and outputs “true” or “false”. LNK: takes a set \(\mathcal{I} = \{I_i\}\), a signature \(\sigma\) and outputs “linked” or “indep”. The idea behind the protocol is fairly simple: a user produces a signature which can be checked by a set of public keys rather than a unique public key. The identity of the signer is indistinguishable from the other users whose public keys are in the set until the owner produces a second signature using the same keypair. Private keys \(x_0\) \(\cdots\) \(x_i\) \(\cdots\) \(x_n\) Public keys \(P_0\) \(\cdots\) \(P_i\) \(\cdots\) \(P_n\) Ring Signature sign verify Fig. 6. Ring signature anonymity. GEN: The signer picks a random secret key \(x \in [1, l - 1]\) and computes the corresponding public key \(P = xG\). Additionally he computes another public key \(I = xH_p(P)\) which we will call the “key image”. SIG: The signer generates a one-time ring signature with a non-interactive zero-knowledge proof using the techniques from [21]. He selects a random subset \(S'\) of \(n\) from the other users’ public keys \(P_i\), his own keypair \((x, P)\) and key image \(I\). Let \(0 \leq s \leq n\) be signer’s secret index in \(S\) (so that his public key is \(P_s\)). He picks a random \(\{q_i \mid i = 0, \ldots, n\}\) and \(\{w_i \mid i = 0, \ldots, n, i \neq s\}\) from \((1, \ldots, l)\) and applies the following transformations: \[L_i = \begin{cases} q_i G, & \text{if } i = s \\\\ q_i G + w_i P_i, & \text{if } i \neq s \end{cases}\] \[R_i = \begin{cases} q_i H_p(P_i), & \text{if } i = s \\\\ q_i H_p(P_i) + w_i I, & \text{if } i \neq s \end{cases}\] The next step is getting the non-interactive challenge:
\[c = H_s(m, L_1, \ldots, L_n, R_1, \ldots, R_n)\] Finally the signer computes the response: \[c_i = \begin{cases} w_i, & \text{if } i \neq s \\\\ c - \sum_{i=0}^{n} c_i \mod l, & \text{if } i = s \end{cases}\] \[r_i = \begin{cases} q_i, & \text{if } i \neq s \\ q_s - c_s x \mod l, & \text{if } i = s \end{cases}\] The resulting signature is \(\sigma = (I, c_1, \ldots, c_n, r_1, \ldots, r_n)\). 9 18 This whole area is cryptonote agnostic, simply describing the ring signature algorithm without reference to currencies. I suspect some of the notation is consistent with the rest of the paper, though. For example, x is the "random" secret key chosen in GEN, which gives public key P and public key image I. This value of x is the value Bob computes in part 6 page 8. So this is starting to clear up some of the confusion from the previous description. This is kind of cool; money isn’t being transferred from "Alice’s public address to Bob’s public address." It’s being transferred from one-time address to one-time address. So, in a sense, here’s how stuffis working. If Alex has some cryptonotes because someone sent them to her, this means she has the private keys needed to send them to Bob. She uses a Diffie-Hellman exchange using Bob’s public information to generate a new one-time address and the cryptonotes are transferred to that address. Now, since a (presumably secure) DH exchange was used to generate the new one-time address to which Alex sent her CN, Bob is the only one with the private keys needed to repeat the above. So now, Bob is Alex. http://en.wikipedia.org/wiki/Piecewise#Notation_and_interpretation Summation should be indexed over j not i. Each c_i is random junk (since w_i is random) except for the c_i associated with the actual key involved in this signature. The value of c is a hash of the previous information. I think this may contain a typo worse than re-using the index ’i,’ though, because c_s seems to be implicitly, not explicitly, defined. Indeed, if we take this equation on faith, then we determine that c_s = (1/2)c - (1/2) sum_i neq s c_i. That is, a hash minus a whole bunch of random numbers. On the other hand, if this summation is intended to be read "c_s = (c - sum_j neq s c_j) mod l", then we take the hash of our previous information, generate a bunch of random numbers, subtract all of those random numbers offthe hash, and that gives us c_s. This seems to be what "should" be happening given my intuition, and matches the verification step on page 10. But intuition is not mathematics. I’ll dig deeper into this. Same as before; all of these will be random junk except for the one associated with the actual signer’s public key x. Except this time, this is more what I would expect from the structure: r_i is random for i!=s and r_s is determined only by the secret x and the s-indexed values of q_i and c_i.
VER: The verifier checks the signature by applying the inverse transformations:
\[L'_i = r_i G + c_i P_i\]
\[R'_i = r_i H_p(P_i) + c_i I\] Finally, the verifier checks if
\[\sum_{i=0}^{n} c_i \stackrel{?}{=} H_s(m, L'_0, \ldots, L'_n, R'_0, \ldots, R'_n) \mod l\] If this equality is correct, the verifier runs the algorithm LNK. Otherwise the verifier rejects the signature. LNK: The verifier checks if \(I\) has been used in past signatures (these values are stored in the set \(\mathcal{I}\)). Multiple uses imply that two signatures were produced under the same secret key. The meaning of the protocol: by applying L-transformations the signer proves that he knows such \(x\) that at least one \(P_i = xG\). To make this proof non-repeatable we introduce the key image as \(I = xH_p(P)\). The signer uses the same coefficients \((r_i, c_i)\) to prove almost the same statement: he knows such \(x\) that at least one \(H_p(P_i) = I \cdot x^{-1}\). If the mapping \(x \to I\) is an injection: 1. Nobody can recover the public key from the key image and identify the signer; 2. The signer cannot make two signatures with different \(I\)'s and the same \(x\). A full security analysis is provided in Appendix A. 4.5 Standard CryptoNote transaction By combining both methods (unlinkable public keys and untraceable ring signature) Bob achieves new level of privacy in comparison with the original Bitcoin scheme. It requires him to store only one private key \((a, b)\) and publish \((A, B)\) to start receiving and sending anonymous transactions. While validating each transaction Bob additionally performs only two elliptic curve multiplications and one addition per output to check if a transaction belongs to him. For his every output Bob recovers a one-time keypair \((p_i, P_i)\) and stores it in his wallet. Any inputs can be circumstantially proved to have the same owner only if they appear in a single transaction. In fact this relationship is much harder to establish due to the one-time ring signature. With a ring signature Bob can effectively hide every input among somebody else’s; all possible spenders will be equiprobable, even the previous owner (Alice) has no more information than any observer. When signing his transaction Bob specifies \(n\) foreign outputs with the same amount as his output, mixing all of them without the participation of other users. Bob himself (as well as anybody else) does not know if any of these payments have been spent: an output can be used in thousands of signatures as an ambiguity factor and never as a target of hiding. The double spend check occurs in the LNK phase when checking against the used key images set. Bob can choose the ambiguity degree on his own: \(n = 1\) means that the probability he has spent the output is 50% probability, \(n = 99\) gives 1%. The size of the resulting signature increases linearly as \(O(n+1)\), so the improved anonymity costs to Bob extra transaction fees. He also can set \(n = 0\) and make his ring signature to consist of only one element, however this will instantly reveal him as a spender. 10 VER: The verifier checks the signature by applying the inverse transformations:
\[L'_i = r_i G + c_i P_i\]
\[R'_i = r_i H_p(P_i) + c_i I\] Finally, the verifier checks if
\[\sum_{i=0}^{n} c_i \stackrel{?}{=} H_s(m, L'_0, \ldots, L'_n, R'_0, \ldots, R'_n) \mod l\] If this equality is correct, the verifier runs the algorithm LNK. Otherwise the verifier rejects the signature. LNK: The verifier checks if \(I\) has been used in past signatures (these values are stored in the set \(\mathcal{I}\)). Multiple uses imply that two signatures were produced under the same secret key. The meaning of the protocol: by applying L-transformations the signer proves that he knows such \(x\) that at least one \(P_i = xG\). To make this proof non-repeatable we introduce the key image as \(I = xH_p(P)\). The signer uses the same coefficients \((r_i, c_i)\) to prove almost the same statement: he knows such \(x\) that at least one \(H_p(P_i) = I \cdot x^{-1}\). If the mapping \(x \to I\) is an injection: 1. Nobody can recover the public key from the key image and identify the signer; 2. The signer cannot make two signatures with different \(I\)'s and the same \(x\). A full security analysis is provided in Appendix A. 4.5 Standard CryptoNote transaction By combining both methods (unlinkable public keys and untraceable ring signature) Bob achieves new level of privacy in comparison with the original Bitcoin scheme. It requires him to store only one private key \((a, b)\) and publish \((A, B)\) to start receiving and sending anonymous transactions. While validating each transaction Bob additionally performs only two elliptic curve multiplications and one addition per output to check if a transaction belongs to him. For his every output Bob recovers a one-time keypair \((p_i, P_i)\) and stores it in his wallet. Any inputs can be circumstantially proved to have the same owner only if they appear in a single transaction. In fact this relationship is much harder to establish due to the one-time ring signature. With a ring signature Bob can effectively hide every input among somebody else’s; all possible spenders will be equiprobable, even the previous owner (Alice) has no more information than any observer. When signing his transaction Bob specifies \(n\) foreign outputs with the same amount as his output, mixing all of them without the participation of other users. Bob himself (as well as anybody else) does not know if any of these payments have been spent: an output can be used in thousands of signatures as an ambiguity factor and never as a target of hiding. The double spend check occurs in the LNK phase when checking against the used key images set. Bob can choose the ambiguity degree on his own: \(n = 1\) means that the probability he has spent the output is 50% probability, \(n = 99\) gives 1%. The size of the resulting signature increases linearly as \(O(n+1)\), so the improved anonymity costs to Bob extra transaction fees. He also can set \(n = 0\) and make his ring signature to consist of only one element, however this will instantly reveal him as a spender. 10 19 At this point, I’m terribly confused. Alex receives a message M with signature (I,c_1, ..., c_n, r_1, ..., r_n) and list of public keys S. and she runs VER. This will compute L_i’ and R_i’ This verifies that c_s = c - sum_i neq s c_i on the previous page. At first I was VERy (ha) confused. Anyone can compute L_i’ and R_i’. Indeed, each r_i and c_i have been published in the signature sigma together with the value for I. The set S = P_i of all public keys has also been published. So anyone who has seen sigma and the set of keys S = P_i will get the same values for L_i’ and R_i’ and hence check the signature. But then I remembered this section is simply describing a signature algorithm, not a "check if signed, check if SENT TO ME, and if so, then go spend the money." This is SIMPLY the signature part of the game. I’m interested to read Appendix A when I finally get there. I would like to see a full-scale operation-by-operation comparison of Cryptonote to Bitcoin. Also, electricity/sustainability. What pieces of the algorithms constitute "input" here? Transaction input, I believe, is an Amount and a set of UTXOs that sum to a greater amount than the Amount. This is unclear. "Target of hiding?" I have thought about this for a few minutes now and I still haven’t the foggiest idea of what it could mean. A double-spend attack can be executed only by manipulating a node’s perceived used-key images set \(I\). "Ambiguity degree" = n but the total number of public keys included in the transaction is n+1. That is to say, ambiguity degree would be "how many OTHER people do you want in the crowd?" The answer will probably be, by default "as many as possible."
VER: The verifier checks the signature by applying the inverse transformations:
\[L'_i = r_i G + c_i P_i\]
\[R'_i = r_i H_p(P_i) + c_i I\] Finally, the verifier checks if
\[\sum_{i=0}^{n} c_i \stackrel{?}{=} H_s(m, L'_0, \ldots, L'_n, R'_0, \ldots, R'_n) \mod l\] If this equality is correct, the verifier runs the algorithm LNK. Otherwise the verifier rejects the signature. LNK: The verifier checks if \(I\) has been used in past signatures (these values are stored in the set \(\mathcal{I}\)). Multiple uses imply that two signatures were produced under the same secret key. The meaning of the protocol: by applying L-transformations the signer proves that he knows such \(x\) that at least one \(P_i = xG\). To make this proof non-repeatable we introduce the key image as \(I = xH_p(P)\). The signer uses the same coefficients \((r_i, c_i)\) to prove almost the same statement: he knows such \(x\) that at least one \(H_p(P_i) = I \cdot x^{-1}\). If the mapping \(x \to I\) is an injection: 1. Nobody can recover the public key from the key image and identify the signer; 2. The signer cannot make two signatures with different \(I\)'s and the same \(x\). A full security analysis is provided in Appendix A. 4.5 Standard CryptoNote transaction By combining both methods (unlinkable public keys and untraceable ring signature) Bob achieves new level of privacy in comparison with the original Bitcoin scheme. It requires him to store only one private key \((a, b)\) and publish \((A, B)\) to start receiving and sending anonymous transactions. While validating each transaction Bob additionally performs only two elliptic curve multiplications and one addition per output to check if a transaction belongs to him. For his every output Bob recovers a one-time keypair \((p_i, P_i)\) and stores it in his wallet. Any inputs can be circumstantially proved to have the same owner only if they appear in a single transaction. In fact this relationship is much harder to establish due to the one-time ring signature. With a ring signature Bob can effectively hide every input among somebody else’s; all possible spenders will be equiprobable, even the previous owner (Alice) has no more information than any observer. When signing his transaction Bob specifies \(n\) foreign outputs with the same amount as his output, mixing all of them without the participation of other users. Bob himself (as well as anybody else) does not know if any of these payments have been spent: an output can be used in thousands of signatures as an ambiguity factor and never as a target of hiding. The double spend check occurs in the LNK phase when checking against the used key images set. Bob can choose the ambiguity degree on his own: \(n = 1\) means that the probability he has spent the output is 50% probability, \(n = 99\) gives 1%. The size of the resulting signature increases linearly as \(O(n+1)\), so the improved anonymity costs to Bob extra transaction fees. He also can set \(n = 0\) and make his ring signature to consist of only one element, however this will instantly reveal him as a spender. 10 VER: The verifier checks the signature by applying the inverse transformations:
\[L'_i = r_i G + c_i P_i\]
\[R'_i = r_i H_p(P_i) + c_i I\] Finally, the verifier checks if
\[\sum_{i=0}^{n} c_i \stackrel{?}{=} H_s(m, L'_0, \ldots, L'_n, R'_0, \ldots, R'_n) \mod l\] If this equality is correct, the verifier runs the algorithm LNK. Otherwise the verifier rejects the signature. LNK: The verifier checks if \(I\) has been used in past signatures (these values are stored in the set \(\mathcal{I}\)). Multiple uses imply that two signatures were produced under the same secret key. The meaning of the protocol: by applying L-transformations the signer proves that he knows such \(x\) that at least one \(P_i = xG\). To make this proof non-repeatable we introduce the key image as \(I = xH_p(P)\). The signer uses the same coefficients \((r_i, c_i)\) to prove almost the same statement: he knows such \(x\) that at least one \(H_p(P_i) = I \cdot x^{-1}\). If the mapping \(x \to I\) is an injection: 1. Nobody can recover the public key from the key image and identify the signer; 2. The signer cannot make two signatures with different \(I\)'s and the same \(x\). A full security analysis is provided in Appendix A. 4.5 Standard CryptoNote transaction By combining both methods (unlinkable public keys and untraceable ring signature) Bob achieves new level of privacy in comparison with the original Bitcoin scheme. It requires him to store only one private key \((a, b)\) and publish \((A, B)\) to start receiving and sending anonymous transactions. While validating each transaction Bob additionally performs only two elliptic curve multiplications and one addition per output to check if a transaction belongs to him. For his every output Bob recovers a one-time keypair \((p_i, P_i)\) and stores it in his wallet. Any inputs can be circumstantially proved to have the same owner only if they appear in a single transaction. In fact this relationship is much harder to establish due to the one-time ring signature. With a ring signature Bob can effectively hide every input among somebody else’s; all possible spenders will be equiprobable, even the previous owner (Alice) has no more information than any observer. When signing his transaction Bob specifies \(n\) foreign outputs with the same amount as his output, mixing all of them without the participation of other users. Bob himself (as well as anybody else) does not know if any of these payments have been spent: an output can be used in thousands of signatures as an ambiguity factor and never as a target of hiding. The double spend check occurs in the LNK phase when checking against the used key images set. Bob can choose the ambiguity degree on his own: \(n = 1\) means that the probability he has spent the output is 50% probability, \(n = 99\) gives 1%. The size of the resulting signature increases linearly as \(O(n+1)\), so the improved anonymity costs to Bob extra transaction fees. He also can set \(n = 0\) and make his ring signature to consist of only one element, however this will instantly reveal him as a spender. 10 20 This is interesting; earlier, we provided a way for a receiver, Bob, to make all INCOMING transactions non-unlinkable either by choosing half of his private keys deterministically or by publishing half his private keys as public. This is a no-going-back sort of policy. Here, we see a way of a sender, Alex, to choose a single outgoing transaction as linkable, but in fact this reveals Alex as the sender to the whole network. This is NOT a no-going-back sort of policy. This is transaction-by-transaction. Is there a third policy? Can a receiver, Bob, generate a unique payment ID for Alex that never changes, perhaps using a Diffie-Hellman exchange? If anyone includes that payment ID bundled somewhere in her transaction to Bob’s address, it must have come from Alex. This way, Alex need not reveal herself to the whole network by choosing to link a particular transaction, but she can still identify herself to the person to whom she sends her money. Isn’t this what Poloniex does?
Transaction Tx input \(\text{Output}_0\) \(\ldots\) \(\text{Output}_i\) \(\ldots\) \(\text{Output}_n\) Key image Signatures Ring Signature Destination key Output1 Destination key Outputn Foreign transactions Sender’s output Destination key One-time keypair One-time private key \(I = xH_p(P)\) \(P\), \(x\) Fig. 7. Ring signature generation in a standard transaction. 5 Egalitarian Proof-of-work In this section we propose and ground the new proof-of-work algorithm. Our primary goal is to close the gap between CPU (majority) and GPU/FPGA/ASIC (minority) miners. It is appropriate that some users can have a certain advantage over others, but their investments should grow at least linearly with the power. More generally, producing special-purpose devices has to be as less profitable as possible. 5.1 Related works The original Bitcoin proof-of-work protocol uses the CPU-intensive pricing function SHA-256. It mainly consists of basic logical operators and relies solely on the computational speed of processor, therefore is perfectly suitable for multicore/conveyer implementation. However, modern computers are not limited by the number of operations per second alone, but also by memory size. While some processors can be substantially faster than others [8], memory sizes are less likely to vary between machines. Memory-bound price functions were first introduced by Abadi et al and were defined as “functions whose computation time is dominated by the time spent accessing memory” [15]. The main idea is to construct an algorithm allocating a large block of data (“scratchpad”) within memory that can be accessed relatively slowly (for example, RAM) and “accessing an unpredictable sequence of locations” within it. A block should be large enough to make preserving the data more advantageous than recomputing it for each access. The algorithm also should prevent internal parallelism, hence \(N\) simultaneous threads should require \(N\) times more memory at once. Dwork et al [22] investigated and formalized this approach leading them to suggest another variant of the pricing function: “Mbound”. One more work belongs to F. Coelho [20], who 11 Transaction Tx input \(\text{Output}_0\) \(\ldots\) \(\text{Output}_i\) \(\ldots\) \(\text{Output}_n\) Key image Signatures Ring Signature Destination key Output1 Destination key Outputn Foreign transactions Sender’s output Destination key One-time keypair One-time private key \(I = xH_p(P)\) \(P\), \(x\) Fig. 7. Ring signature generation in a standard transaction. 5 Egalitarian Proof-of-work In this section we propose and ground the new proof-of-work algorithm. Our primary goal is to close the gap between CPU (majority) and GPU/FPGA/ASIC (minority) miners. It is appropriate that some users can have a certain advantage over others, but their investments should grow at least linearly with the power. More generally, producing special-purpose devices has to be as less profitable as possible. 5.1 Related works The original Bitcoin proof-of-work protocol uses the CPU-intensive pricing function SHA-256. It mainly consists of basic logical operators and relies solely on the computational speed of processor, therefore is perfectly suitable for multicore/conveyer implementation. However, modern computers are not limited by the number of operations per second alone, but also by memory size. While some processors can be substantially faster than others [8], memory sizes are less likely to vary between machines. Memory-bound price functions were first introduced by Abadi et al and were defined as “functions whose computation time is dominated by the time spent accessing memory” [15]. The main idea is to construct an algorithm allocating a large block of data (“scratchpad”) within memory that can be accessed relatively slowly (for example, RAM) and “accessing an unpredictable sequence of locations” within it. A block should be large enough to make preserving the data more advantageous than recomputing it for each access. The algorithm also should prevent internal parallelism, hence \(N\) simultaneous threads should require \(N\) times more memory at once. Dwork et al [22] investigated and formalized this approach leading them to suggest another variant of the pricing function: "Mbound". One more work belongs to F. Coelho [20], who 11 21 These are, ostensibly, our UTXO’s: amounts and destination keys. If Alex is the one constructing this standard transaction and is sending to Bob, then Alex also has the private keys to each of these. I like this diagram a whole lot, because it answers some earlier questions. A Txn input consists of a set of Txn outputs and a key image. It is then signed with a ring signature, including all of the private keys Alex owns to all of the foreign transactions wrapped up in the deal. The Txn output consists of an amount and a destination key. The receiver of the transaction may, at will, generate their one-time private key as described earlier in the paper in order to spend the money. It will be delightful to find out how much this matches the actual code... No, Nic van Saberhagen describes loosely some properties of a proof of work algorithm, without actually describing that algorithm. The CryptoNight algorithm itself will REQUIRE a deep analysis. When I read this, I stuttered. Should investment grow at least linearly with power, or should investment grow at most linearly with power? And then I realized; I, as a miner, or an investor, usually think of "how much power can I get for an investment?" not "how much investment is required for a fixed amount of power?" Of course, denote investment by \(I\) and power by \(P\). If \(I(P)\) is investment as a function of power and \(P(I)\) is power as a function of investment, they'll be inverses of each other (wherever inverses can exist). And if \(I(P)\) is faster-than-linear than \(P(I)\) is slower-than-linear. Hence, there will be a reduced rate of returns for investors. That is to say, what the author is saying here is: "sure, as you invest more, you’ll get more power. But we should try to make that a reduced rate of returns thing." CPU investments will cap out sub-linearly, eventually; the question is whether the authors have designed a POW algorithm that will force the ASICs to also do this. Should a hypothetical "future currency" always mine with the slowest/most limited resources? The paper by Abadi et al, (which has some Google and Microsoft engineers as authors) is, essentially, using the fact that for the past few years memory size has had a much smaller variance across machines than processor speed, and with a more-than-linear investment-forpower ratio. In a few years, this may have to be re-assessed! Everything is an arms race... Constructing a hash function is difficult; constructing a hash function satisfying these constraints seems to be more difficult. This paper seems to have no explanation of the actual hashing algorithm CryptoNight. I think it’s a memory-hard implementation of SHA-3, based on forum posts but I have no idea... and that’s the point. It must be explained.
proposed the most effective solution: “Hokkaido”. To our knowledge the last work based on the idea of pseudo-random searches in a big array is the algorithm known as “scrypt” by C. Percival [32]. Unlike the previous functions it focuses on key derivation, and not proof-of-work systems. Despite this fact scrypt can serve our purpose: it works well as a pricing function in the partial hash conversion problem such as SHA-256 in Bitcoin. By now scrypt has already been applied in Litecoin [14] and some other Bitcoin forks. However, its implementation is not really memory-bound: the ratio “memory access time / overall time” is not large enough because each instance uses only 128 KB. This permits GPU miners to be roughly 10 times more effective and continues to leave the possibility of creating relatively cheap but highly-efficient mining devices. Moreover, the scrypt construction itself allows a linear trade-offbetween memory size and CPU speed due to the fact that every block in the scratchpad is derived only from the previous. For example, you can store every second block and recalculate the others in a lazy way, i.e. only when it becomes necessary. The pseudo-random indexes are assumed to be uniformly distributed, hence the expected value of the additional blocks' recalculations is \(\frac{1}{2} \cdot N\), where \(N\) is the number of iterations. The overall computation time increases less than by half because there are also time independent (constant time) operations such as preparing the scratchpad and hashing on every iteration. Saving 2/3 of the memory costs \(\frac{1}{3} \cdot N + \frac{1}{3} \cdot 2 \cdot N = N\) additional recalculations; 9/10 results in \(\frac{1}{10} \cdot N + \ldots + \frac{1}{10} \cdot 9 \cdot N = 4.5N\). It is easy to show that storing only \(\frac{1}{s}\) of all blocks increases the time less than by a factor of \(\frac{s-1}{2}\). This in turn implies that a machine with a CPU 200 times faster than the modern chips can store only 320 bytes of the scratchpad. 5.2 The proposed algorithm We propose a new memory-bound algorithm for the proof-of-work pricing function. It relies on random access to a slow memory and emphasizes latency dependence. As opposed to scrypt every new block (64 bytes in length) depends on all the previous blocks. As a result a hypothetical "memory-saver" should increase his calculation speed exponentially. Our algorithm requires about 2 Mb per instance for the following reasons: 1. It fits in the L3 cache (per core) of modern processors, which should become mainstream in a few years; 2. A megabyte of internal memory is an almost unacceptable size for a modern ASIC pipeline; 3. GPUs may run hundreds of concurrent instances, but they are limited in other ways: GDDR5 memory is slower than the CPU L3 cache and remarkable for its bandwidth, not random access speed. 4. Significant expansion of the scratchpad would require an increase in iterations, which in turn implies an overall time increase. "Heavy" calls in a trust-less p2p network may lead to serious vulnerabilities, because nodes are obliged to check every new block's proof-of-work. If a node spends a considerable amount of time on each hash evaluation, it can be easily DDoSed by a flood of fake objects with arbitrary work data (nonce values). 12 proposed the most effective solution: "Hokkaido". To our knowledge the last work based on the idea of pseudo-random searches in a big array is the algorithm known as “scrypt” by C. Percival [32]. Unlike the previous functions it focuses on key derivation, and not proof-of-work systems. Despite this fact scrypt can serve our purpose: it works well as a pricing function in the partial hash conversion problem such as SHA-256 in Bitcoin. By now scrypt has already been applied in Litecoin [14] and some other Bitcoin forks. However, its implementation is not really memory-bound: the ratio “memory access time / overall time” is not large enough because each instance uses only 128 KB. This permits GPU miners to be roughly 10 times more effective and continues to leave the possibility of creating relatively cheap but highly-efficient mining devices. Moreover, the scrypt construction itself allows a linear trade-offbetween memory size and CPU speed due to the fact that every block in the scratchpad is derived only from the previous. For example, you can store every second block and recalculate the others in a lazy way, i.e. only when it becomes necessary. The pseudo-random indexes are assumed to be uniformly distributed, hence the expected value of the additional blocks’ recalculations is \(\frac{1}{2} \cdot N\), where \(N\) is the number of iterations. The overall computation time increases less than by half because there are also time independent (constant time) operations such as preparing the scratchpad and hashing on every iteration. Saving 2/3 of the memory costs \(\frac{1}{3} \cdot N + \frac{1}{3} \cdot 2 \cdot N = N\) additional recalculations; 9/10 results in \(\frac{1}{10} \cdot N + \ldots + \frac{1}{10} \cdot 9 \cdot N = 4.5N\). It is easy to show that storing only \(\frac{1}{s}\) of all blocks increases the time less than by a factor of \(\frac{s-1}{2}\). This in turn implies that a machine with a CPU 200 times faster than the modern chips can store only 320 bytes of the scratchpad. 5.2 The proposed algorithm We propose a new memory-bound algorithm for the proof-of-work pricing function. It relies on random access to a slow memory and emphasizes latency dependence. As opposed to scrypt every new block (64 bytes in length) depends on all the previous blocks. As a result a hypothetical “memory-saver” should increase his calculation speed exponentially. Our algorithm requires about 2 Mb per instance for the following reasons: 1. It fits in the L3 cache (per core) of modern processors, which should become mainstream in a few years; 2. A megabyte of internal memory is an almost unacceptable size for a modern ASIC pipeline; 3. GPUs may run hundreds of concurrent instances, but they are limited in other ways: GDDR5 memory is slower than the CPU L3 cache and remarkable for its bandwidth, not random access speed. 4. Significant expansion of the scratchpad would require an increase in iterations, which in turn implies an overall time increase. “Heavy” calls in a trust-less p2p network may lead to serious vulnerabilities, because nodes are obliged to check every new block’s proof-of-work. If a node spends a considerable amount of time on each hash evaluation, it can be easily DDoSed by a flood of fake objects with arbitrary work data (nonce values). 12 22 Nevermind, it’s a scrypt coin? Where is the algorithm? All I see is an advertisement. This is where Cryptonote, if their PoW algorithm is worthwhile, will really shine. It’s not really SHA-256, it’s not really scrypt. It’s new, memory bound, and non-recursive.
6 Further advantages 6.1 Smooth emission The upper bound for the overall amount of CryptoNote digital coins is: \(M_{Supply} = 2^{64} - 1\) atomic units. This is a natural restriction based only on implementation limits, not on intuition such as “N coins ought to be enough for anybody”. To ensure the smoothness of the emission process we use the following formula for block rewards: \(BaseReward = (M_{Supply} - A) \gg 18\), where \(A\) is amount of previously generated coins. 6.2 Adjustable parameters 6.2.1 Difficulty CryptoNote contains a targeting algorithm which changes the difficulty of every block. This decreases the system’s reaction time when the network hashrate is intensely growing or shrinking, preserving a constant block rate. The original Bitcoin method calculates the relation of actual and target time-span between the last 2016 blocks and uses it as the multiplier for the current difficulty. Obviously this is unsuitable for rapid recalculations (because of large inertia) and results in oscillations. The general idea behind our algorithm is to sum all the work completed by the nodes and divide it by the time they have spent. The measure of work is the corresponding difficulty values in each block. But due to inaccurate and untrusted timestamps we cannot determine the exact time interval between blocks. A user can shift his timestamp into the future and the next time intervals might be improbably small or even negative. Presumably there will be few incidents of this kind, so we can just sort the timestamps and cut-offthe outliers (i.e. 20%). The range of the rest values is the time which was spent for 80% of the corresponding blocks. 6.2.2 Size limits Users pay for storing the blockchain and shall be entitled to vote for its size. Every miner deals with the trade-offbetween balancing the costs and profit from the fees and sets his own “soft-limit” for creating blocks. Also the core rule for the maximum block size is necessary for preventing the blockchain from being flooded with bogus transaction, however this value should not be hard-coded. Let \(M_N\) be the median value of the last \(N\) blocks sizes. Then the “hard-limit” for the size of accepting blocks is \(2 \cdot M_N\). It averts the blockchain from bloating but still allows the limit to slowly grow with time if necessary. Transaction size does not need to be limited explicitly. It is bounded by the size of a block; and if somebody wants to create a huge transaction with hundreds of inputs/outputs (or with the high ambiguity degree in ring signatures), he can do so by paying sufficient fee. 6.2.3 Excess size penalty A miner still has the ability to stuffa block full of his own zero-fee transactions up to its maximum size \(2 \cdot M_b\). Even though only the majority of miners can shift the median value, there is still a 13 6 Further advantages 6.1 Smooth emission The upper bound for the overall amount of CryptoNote digital coins is: \(M_{Supply} = 2^{64} - 1\) atomic units. This is a natural restriction based only on implementation limits, not on intuition such as “N coins ought to be enough for anybody”. To ensure the smoothness of the emission process we use the following formula for block rewards: \(BaseReward = (M_{Supply} - A) \gg 18\), where \(A\) is amount of previously generated coins. 6.2 Adjustable parameters 6.2.1 Difficulty CryptoNote contains a targeting algorithm which changes the difficulty of every block. This decreases the system’s reaction time when the network hashrate is intensely growing or shrinking, preserving a constant block rate. The original Bitcoin method calculates the relation of actual and target time-span between the last 2016 blocks and uses it as the multiplier for the current difficulty. Obviously this is unsuitable for rapid recalculations (because of large inertia) and results in oscillations. The general idea behind our algorithm is to sum all the work completed by the nodes and divide it by the time they have spent. The measure of work is the corresponding difficulty values in each block. But due to inaccurate and untrusted timestamps we cannot determine the exact time interval between blocks. A user can shift his timestamp into the future and the next time intervals might be improbably small or even negative. Presumably there will be few incidents of this kind, so we can just sort the timestamps and cut-offthe outliers (i.e. 20%). The range of the rest values is the time which was spent for 80% of the corresponding blocks. 6.2.2 Size limits Users pay for storing the blockchain and shall be entitled to vote for its size. Every miner deals with the trade-offbetween balancing the costs and profit from the fees and sets his own “soft-limit” for creating blocks. Also the core rule for the maximum block size is necessary for preventing the blockchain from being flooded with bogus transaction, however this value should not be hard-coded. Let \(M_N\) be the median value of the last \(N\) blocks sizes. Then the “hard-limit” for the size of accepting blocks is \(2 \cdot M_N\). It averts the blockchain from bloating but still allows the limit to slowly grow with time if necessary. Transaction size does not need to be limited explicitly. It is bounded by the size of a block; and if somebody wants to create a huge transaction with hundreds of inputs/outputs (or with the high ambiguity degree in ring signatures), he can do so by paying sufficient fee. 6.2.3 Excess size penalty A miner still has the ability to stuffa block full of his own zero-fee transactions up to its maximum size \(2 \cdot M_b\). Even though only the majority of miners can shift the median value, there is still a 13 23 Atomic units. I like that. Is this the equivalent of Satoshis? If so, then that means there are going to be 185 billion cryptonote. I know this must be, eventually, tweaked in a few pages, or maybe there’s a typo? If the base reward is "all remaining coins" then only one block is sufficient to get all coins. Instamine. On the other hand, if this is supposed to be proportional in some way to the difference in time between now and some coin-production-termination-date? That would make sense. Also, in my world, two greater than signs like this means "much greater than." Did the author possibly mean something else? If adjustment to difficulty occurs every block then an attacker could have a very large farm of machines mine on and offin carefully chosen time intervals. This could cause a chaotic explosion (or crash to zero) in difficulty, if difficulty adjustment formulas aren’t suitably damped. No doubt that Bitcoin’s method is unsuitable for rapid recalculations, but the idea of inertia in these systems would need to be proven, not taken for granted. Furthermore, oscillations in network difficulty isn’t necessarily a problem unless it results in oscillations of ostensible supply of coins - and having a very rapidly changing difficulty could cause "over-correction." Time spent, especially over a short time span like a few minutes, will be proportional to "total number of blocks created on the network." The constant of proportionality will, itself, grow over time, presumably exponentially if CN takes off. It may be a better idea to simply adjust the difficulty to keep "total blocks created on the network since the last block was added to the main chain" within some constant value, or with bounded variation or something like that. If an adaptive algorithm that is computationally easy to implement can be determined, this would seem to solve the problem. But then, if we used that method, someone with a big mining farm could shut their farm down for a few hours, and switch it back on again. For the first few blocks, that farm will make bank. So, actually, this method would bring up an interesting point: mining becomes (on average) a losing game with no ROI, especially as more folks hop on the network. If the mining difficulty very closely tracked network hashrate, I somehow doubt people would mine as much as they currently do. Or, on the other hand, instead of keeping their mining farms going 24/7, they may turn them on for 6 hours, offfor 2, on for 6, offfor 2, or something like that. Just switch to another coin for a few hours, wait for difficulty to drop, then hop back on in order to gain those few extra blocks of profitability as the network adapts. And you know what? This is actually probably one of the better mining scenarios I’ve put my mind into... This could be circular, but if block creation time averages to about a minute, can we just use the number of blocks as a proxy for "time spent?"
6 Further advantages 6.1 Smooth emission The upper bound for the overall amount of CryptoNote digital coins is: \(M_{Supply} = 2^{64} - 1\) atomic units. This is a natural restriction based only on implementation limits, not on intuition such as “N coins ought to be enough for anybody”. To ensure the smoothness of the emission process we use the following formula for block rewards: \(BaseReward = (M_{Supply} - A) \gg 18\), where \(A\) is amount of previously generated coins. 6.2 Adjustable parameters 6.2.1 Difficulty CryptoNote contains a targeting algorithm which changes the difficulty of every block. This decreases the system’s reaction time when the network hashrate is intensely growing or shrinking, preserving a constant block rate. The original Bitcoin method calculates the relation of actual and target time-span between the last 2016 blocks and uses it as the multiplier for the current difficulty. Obviously this is unsuitable for rapid recalculations (because of large inertia) and results in oscillations. The general idea behind our algorithm is to sum all the work completed by the nodes and divide it by the time they have spent. The measure of work is the corresponding difficulty values in each block. But due to inaccurate and untrusted timestamps we cannot determine the exact time interval between blocks. A user can shift his timestamp into the future and the next time intervals might be improbably small or even negative. Presumably there will be few incidents of this kind, so we can just sort the timestamps and cut-offthe outliers (i.e. 20%). The range of the rest values is the time which was spent for 80% of the corresponding blocks. 6.2.2 Size limits Users pay for storing the blockchain and shall be entitled to vote for its size. Every miner deals with the trade-offbetween balancing the costs and profit from the fees and sets his own “soft-limit” for creating blocks. Also the core rule for the maximum block size is necessary for preventing the blockchain from being flooded with bogus transaction, however this value should not be hard-coded. Let \(M_N\) be the median value of the last \(N\) blocks sizes. Then the “hard-limit” for the size of accepting blocks is \(2 \cdot M_N\). It averts the blockchain from bloating but still allows the limit to slowly grow with time if necessary. Transaction size does not need to be limited explicitly. It is bounded by the size of a block; and if somebody wants to create a huge transaction with hundreds of inputs/outputs (or with the high ambiguity degree in ring signatures), he can do so by paying sufficient fee. 6.2.3 Excess size penalty A miner still has the ability to stuffa block full of his own zero-fee transactions up to its maximum size \(2 \cdot M_b\). Even though only the majority of miners can shift the median value, there is still a 13 6 Further advantages 6.1 Smooth emission The upper bound for the overall amount of CryptoNote digital coins is: \(M_{Supply} = 2^{64} - 1\) atomic units. This is a natural restriction based only on implementation limits, not on intuition such as “N coins ought to be enough for anybody”. To ensure the smoothness of the emission process we use the following formula for block rewards: \(BaseReward = (M_{Supply} - A) \gg 18\), where \(A\) is amount of previously generated coins. 6.2 Adjustable parameters 6.2.1 Difficulty CryptoNote contains a targeting algorithm which changes the difficulty of every block. This decreases the system’s reaction time when the network hashrate is intensely growing or shrinking, preserving a constant block rate. The original Bitcoin method calculates the relation of actual and target time-span between the last 2016 blocks and uses it as the multiplier for the current difficulty. Obviously this is unsuitable for rapid recalculations (because of large inertia) and results in oscillations. The general idea behind our algorithm is to sum all the work completed by the nodes and divide it by the time they have spent. The measure of work is the corresponding difficulty values in each block. But due to inaccurate and untrusted timestamps we cannot determine the exact time interval between blocks. A user can shift his timestamp into the future and the next time intervals might be improbably small or even negative. Presumably there will be few incidents of this kind, so we can just sort the timestamps and cut-offthe outliers (i.e. 20%). The range of the rest values is the time which was spent for 80% of the corresponding blocks. 6.2.2 Size limits Users pay for storing the blockchain and shall be entitled to vote for its size. Every miner deals with the trade-offbetween balancing the costs and profit from the fees and sets his own “soft-limit” for creating blocks. Also the core rule for the maximum block size is necessary for preventing the blockchain from being flooded with bogus transaction, however this value should not be hard-coded. Let \(M_N\) be the median value of the last \(N\) blocks sizes. Then the “hard-limit” for the size of accepting blocks is \(2 \cdot M_N\). It averts the blockchain from bloating but still allows the limit to slowly grow with time if necessary. Transaction size does not need to be limited explicitly. It is bounded by the size of a block; and if somebody wants to create a huge transaction with hundreds of inputs/outputs (or with the high ambiguity degree in ring signatures), he can do so by paying sufficient fee. 6.2.3 Excess size penalty A miner still has the ability to stuffa block full of his own zero-fee transactions up to its maximum size \(2 \cdot M_b\). Even though only the majority of miners can shift the median value, there is still a 13 24 Okay, so we have a blockchain, and each block has timestamps IN ADDITION to simply being ordered. This was clearly inserted simply for difficulty adjustment, because timestamps are very unreliable, as mentioned. Are we allowed to have contradicting timestamps in the chain? If Block A comes before Block B in the chain, and everything is consistent in terms of finances, but Block A appears to have been created after Block B? Because, perhaps, someone owned a large part of the network? Is that ok? Probably, because the finances aren’t goofed up. Okay, so I hate this arbitrary "only 80% of the blocks are legitimate for the main blockchain" approach. It was intended to prevent liars from tweaking their timestamps? But now, it adds incentive for everyone to lie about their timestamps and just pick the median. Please define. Meaning "for this block, only include transactions that include fees greater than p%, preferentially with fees greater than 2p%" or something like that? What do they mean by bogus? If the transaction is consistent with past history of the blockchain, and the transaction includes fees that satisfy miners, is that not enough? Well, no, not necessarily. If no maximum block size exists, there is nothing to keep a malicious user from simply uploading a massive block of transactions to himself all at once just to slow down the network. A core rule for maximum block size prevents people from putting enormous amounts of junk data on the blockchain all at once just to slow things down. But such a rule certianly has to be adaptive - during the christmas season, for example, we could expect traffic to spike, and block size to get very big, and immediately afterward, for the block size to subsequently drop again. So we need either a) some sort of adaptive cap or b) a cap large enough so that 99% of reasonable christmas peaks don’t break the cap. Of course, that second one is impossible to estimate - who knows if a currency will catch on? Better to make it adaptive and not worry about it. But then we have a control theory problem: how to make this adaptive without vulnerability to attack or wild & crazy oscillations? Notice an adaptive method doesn’t stop malicious users from accumulating small amounts of junk data over time on the blockchain to cause long-term bloat. This is a different issue altogether and one that cryptonote coins have serious problems with.
6 Further advantages 6.1 Smooth emission The upper bound for the overall amount of CryptoNote digital coins is: \(M_{Supply} = 2^{64} - 1\) atomic units. This is a natural restriction based only on implementation limits, not on intuition such as “N coins ought to be enough for anybody”. To ensure the smoothness of the emission process we use the following formula for block rewards: \(BaseReward = (M_{Supply} - A) \gg 18\), where \(A\) is amount of previously generated coins. 6.2 Adjustable parameters 6.2.1 Difficulty CryptoNote contains a targeting algorithm which changes the difficulty of every block. This decreases the system’s reaction time when the network hashrate is intensely growing or shrinking, preserving a constant block rate. The original Bitcoin method calculates the relation of actual and target time-span between the last 2016 blocks and uses it as the multiplier for the current difficulty. Obviously this is unsuitable for rapid recalculations (because of large inertia) and results in oscillations. The general idea behind our algorithm is to sum all the work completed by the nodes and divide it by the time they have spent. The measure of work is the corresponding difficulty values in each block. But due to inaccurate and untrusted timestamps we cannot determine the exact time interval between blocks. A user can shift his timestamp into the future and the next time intervals might be improbably small or even negative. Presumably there will be few incidents of this kind, so we can just sort the timestamps and cut-offthe outliers (i.e. 20%). The range of the rest values is the time which was spent for 80% of the corresponding blocks. 6.2.2 Size limits Users pay for storing the blockchain and shall be entitled to vote for its size. Every miner deals with the trade-offbetween balancing the costs and profit from the fees and sets his own “soft-limit” for creating blocks. Also the core rule for the maximum block size is necessary for preventing the blockchain from being flooded with bogus transaction, however this value should not be hard-coded. Let \(M_N\) be the median value of the last \(N\) blocks sizes. Then the “hard-limit” for the size of accepting blocks is \(2 \cdot M_N\). It averts the blockchain from bloating but still allows the limit to slowly grow with time if necessary. Transaction size does not need to be limited explicitly. It is bounded by the size of a block; and if somebody wants to create a huge transaction with hundreds of inputs/outputs (or with the high ambiguity degree in ring signatures), he can do so by paying sufficient fee. 6.2.3 Excess size penalty A miner still has the ability to stuffa block full of his own zero-fee transactions up to its maximum size \(2 \cdot M_b\). Even though only the majority of miners can shift the median value, there is still a 13 6 Further advantages 6.1 Smooth emission The upper bound for the overall amount of CryptoNote digital coins is: \(M_{Supply} = 2^{64} - 1\) atomic units. This is a natural restriction based only on implementation limits, not on intuition such as “N coins ought to be enough for anybody”. To ensure the smoothness of the emission process we use the following formula for block rewards: \(BaseReward = (M_{Supply} - A) \gg 18\), where \(A\) is amount of previously generated coins. 6.2 Adjustable parameters 6.2.1 Difficulty CryptoNote contains a targeting algorithm which changes the difficulty of every block. This decreases the system’s reaction time when the network hashrate is intensely growing or shrinking, preserving a constant block rate. The original Bitcoin method calculates the relation of actual and target time-span between the last 2016 blocks and uses it as the multiplier for the current difficulty. Obviously this is unsuitable for rapid recalculations (because of large inertia) and results in oscillations. The general idea behind our algorithm is to sum all the work completed by the nodes and divide it by the time they have spent. The measure of work is the corresponding difficulty values in each block. But due to inaccurate and untrusted timestamps we cannot determine the exact time interval between blocks. A user can shift his timestamp into the future and the next time intervals might be improbably small or even negative. Presumably there will be few incidents of this kind, so we can just sort the timestamps and cut-offthe outliers (i.e. 20%). The range of the rest values is the time which was spent for 80% of the corresponding blocks. 6.2.2 Size limits Users pay for storing the blockchain and shall be entitled to vote for its size. Every miner deals with the trade-offbetween balancing the costs and profit from the fees and sets his own “soft-limit” for creating blocks. Also the core rule for the maximum block size is necessary for preventing the blockchain from being flooded with bogus transaction, however this value should not be hard-coded. Let \(M_N\) be the median value of the last \(N\) blocks sizes. Then the “hard-limit” for the size of accepting blocks is \(2 \cdot M_N\). It averts the blockchain from bloating but still allows the limit to slowly grow with time if necessary. Transaction size does not need to be limited explicitly. It is bounded by the size of a block; and if somebody wants to create a huge transaction with hundreds of inputs/outputs (or with the high ambiguity degree in ring signatures), he can do so by paying sufficient fee. 6.2.3 Excess size penalty A miner still has the ability to stuffa block full of his own zero-fee transactions up to its maximum size \(2 \cdot M_b\). Even though only the majority of miners can shift the median value, there is still a 13 25 Rescaling time so that one unit of time is \(N\) blocks, the average block size could still, theoretically, grow exponentially proportionally to \(2^t\). On the other hand, a more general cap on the next block would be \(M_n \cdot f(M_n)\) for some function \(f\). What properties of \(f\) would we choose in order to guarantee some "reasonable growth" of block size? The progression of block sizes (after rescaling time) would go like this: \(M_n \quad f(M_n) \cdot M_n \quad f(f(M_n) \cdot M_n) \cdot f(M_n) \cdot M_n \quad f(f(f(M_n) \cdot M_n) \cdot f(M_n) \cdot M_n) \cdot f(f(M_n) \cdot M_n) \cdot f(\ldots)\) \(\ldots\) And the goal here is to choose \(f\) such that this sequence grows no faster than, say, linearly, or perhaps even as \(\log(t)\). Of course, if \(f(M_n) = a\) for some constant \(a\), this sequence is actually \(M_n \quad a \cdot M_n \quad a^2 \cdot M_n \quad a^3 \cdot M_n \quad \ldots\) And, of course, the only way this can be limited to at-most linear growth is by choosing \(a = 1\). This is, of course, infeasible. It does not allow growth at all. If, on the other hand, \(f(M_n)\) is a non-constant function, then the situation is much more complicated and may allow for an elegant solution. I’ll think on this for awhile. This fee will have to be large enough to discount the excess size penalty from the next section. Why is a general user assumed male, huh? Huh?
possibility to bloat the blockchain and produce an additional load on the nodes. To discourage malevolent participants from creating large blocks we introduce a penalty function: \[NewReward = BaseReward \cdot \left(\frac{BlkSize}{M_N} - 1\right)^2\] This rule is applied only when \(BlkSize\) is greater than minimal free block size which should be close to \(\max(10kb, M_N \cdot 110\%)\). Miners are permitted to create blocks of “usual size” and even exceed it with profit when the overall fees surpass the penalty. But fees are unlikely to grow quadratically unlike the penalty value so there will be an equilibrium. 6.3 Transaction scripts CryptoNote has a very minimalistic scripting subsystem. A sender specifies an expression \(\Phi = f(x_1, x_2, \ldots, x_n)\), where \(n\) is the number of destination public keys \(\{P_i\}_{i=1}^{n}\). Only five binary operators are supported: min, max, sum, mul and cmp. When the receiver spends this payment, he produces \(0 \leq k \leq n\) signatures and passes them to transaction input. The verification process simply evaluates \(\Phi\) with \(x_i = 1\) to check for a valid signature for the public key \(P_i\), and \(x_i = 0\). A verifier accepts the proof iff \(\Phi > 0\). Despite its simplicity this approach covers every possible case: • Multi-/Threshold signature. For the Bitcoin-style “M-out-of-N” multi-signature (i.e. the receiver should provide at least \(0 \leq M \leq N\) valid signatures) \(\Phi = x_1 + x_2 + \ldots + x_N \geq M\) (for clarity we are using common algebraic notation). The weighted threshold signature (some keys can be more important than other) could be expressed as \(\Phi = w_1 \cdot x_1 + w_2 \cdot x_2 + \ldots + w_N \cdot x_N \geq w_M\). And scenario where the master-key corresponds to \(\Phi = \max(M \cdot x, x_1 + x_2 + \ldots + x_N) \geq M\). It is easy to show that any sophisticated case can be expressed with these operators, i.e. they form basis. • Password protection. Possession of a secret password \(s\) is equivalent to the knowledge of a private key, deterministically derived from the password: \(k = KDF(s)\). Hence, a receiver can prove that he knows the password by providing another signature under the key \(k\). The sender simply adds the corresponding public key to his own output. Note that this method is much more secure than the “transaction puzzle” used in Bitcoin [13], where the password is explicitly passed in the inputs. • Degenerate cases. \(\Phi = 1\) means that anybody can spend the money; \(\Phi = 0\) marks the output as not spendable forever. In the case when the output script combined with public keys is too large for a sender, he can use special output type, which indicates that the recipient will put this data in his input while the sender provides only a hash of it. This approach is similar to Bitcoin’s “pay-to-hash” feature, but instead of adding new script commands we handle this case at the data structure level. 7 Conclusion We have investigated the major flaws in Bitcoin and proposed some possible solutions. These advantageous features and our ongoing development make new electronic cash system CryptoNote a serious rival to Bitcoin, outclassing all its forks. 14 possibility to bloat the blockchain and produce an additional load on the nodes. To discourage malevolent participants from creating large blocks we introduce a penalty function: \[NewReward = BaseReward \cdot \left(\frac{BlkSize}{M_N} - 1\right)^2\] This rule is applied only when \(BlkSize\) is greater than minimal free block size which should be close to \(\max(10kb, M_N \cdot 110\%)\). Miners are permitted to create blocks of “usual size” and even exceed it with profit when the overall fees surpass the penalty. But fees are unlikely to grow quadratically unlike the penalty value so there will be an equilibrium. 6.3 Transaction scripts CryptoNote has a very minimalistic scripting subsystem. A sender specifies an expression \(\Phi = f(x_1, x_2, \ldots, x_n)\), where \(n\) is the number of destination public keys \(\{P_i\}_{i=1}^{n}\). Only five binary operators are supported: min, max, sum, mul and cmp. When the receiver spends this payment, he produces \(0 \leq k \leq n\) signatures and passes them to transaction input. The verification process simply evaluates \(\Phi\) with \(x_i = 1\) to check for a valid signature for the public key \(P_i\), and \(x_i = 0\). A verifier accepts the proof iff \(\Phi > 0\). Despite its simplicity this approach covers every possible case: • Multi-/Threshold signature. For the Bitcoin-style “M-out-of-N” multi-signature (i.e. the receiver should provide at least \(0 \leq M \leq N\) valid signatures) \(\Phi = x_1 + x_2 + \ldots + x_N \geq M\) (for clarity we are using common algebraic notation). The weighted threshold signature (some keys can be more important than other) could be expressed as \(\Phi = w_1 \cdot x_1 + w_2 \cdot x_2 + \ldots + w_N \cdot x_N \geq w_M\). And scenario where the master-key corresponds to \(\Phi = \max(M \cdot x, x_1 + x_2 + \ldots + x_N) \geq M\). It is easy to show that any sophisticated case can be expressed with these operators, i.e. they form basis. • Password protection. Possession of a secret password \(s\) is equivalent to the knowledge of a private key, deterministically derived from the password: \(k = KDF(s)\). Hence, a receiver can prove that he knows the password by providing another signature under the key \(k\). The sender simply adds the corresponding public key to his own output. Note that this method is much more secure than the “transaction puzzle” used in Bitcoin [13], where the password is explicitly passed in the inputs. • Degenerate cases. \(\Phi = 1\) means that anybody can spend the money; \(\Phi = 0\) marks the output as not spendable forever. In the case when the output script combined with public keys is too large for a sender, he can use special output type, which indicates that the recipient will put this data in his input while the sender provides only a hash of it. This approach is similar to Bitcoin’s “pay-to-hash” feature, but instead of adding new script commands we handle this case at the data structure level. 7 Conclusion We have investigated the major flaws in Bitcoin and proposed some possible solutions. These advantageous features and our ongoing development make new electronic cash system CryptoNote a serious rival to Bitcoin, outclassing all its forks. 14 26 This may be unnecessary if we can figure out a way to bound block size over time... This also cannot be correct. They just set "NewReward" to an upward-facing parabola where block size is the independent variable. So new reward blows up to infinity. If, on the other hand, the new reward is \(\max(0, BaseReward \cdot (1 - (BlkSize/M_n - 1)^2))\), then the new reward would be a downward facing parabola with peak at \(blocksize = M_n\), and with intercepts at \(Blocksize = 0\) and \(Blocksize = 2 \cdot M_n\). And that seems to be what they are trying to describe. However, this does not
Takip Edilemeyen İşlemler
Bu bölümde, hem izlenemezliği hem de koşulları karşılayan tamamen anonim işlemlere yönelik bir plan öneriyoruz.
ve bağlanamazlık koşulları. Çözümümüzün önemli bir özelliği özerkliğidir: gönderen
işlemlerini gerçekleştirmek için diğer kullanıcılarla veya güvenilir bir üçüncü tarafla işbirliği yapması gerekmemektedir;
dolayısıyla her katılımcı bağımsız olarak bir kapak trafiği üretir.
4.1
Literatür taraması
Planımız grup imzası adı verilen kriptografik temele dayanıyor. İlk kez sunulan
D. Chaum ve E. van Heyst [19], bir kullanıcının grup adına mesajını imzalamasına olanak tanır.
Kullanıcı mesajı imzaladıktan sonra (doğrulama amacıyla) kendi geneline ait değil
1Buna "yumuşak limit" denir; yeni bloklar oluşturmak için referans istemci kısıtlaması. Zor maksimum
olası blok boyutu 1 MB'tı
4
Gerektiğinde bunları kullanmak ana dezavantajlara neden olur. Maalesef ne zaman geleceğini tahmin etmek zor.
sabitlerin değiştirilmesi gerekebilir ve bunların değiştirilmesi korkunç sonuçlara yol açabilir.
Felaket sonuçlara yol açan sabit kodlanmış bir limit değişikliğine iyi bir örnek, bloktur.
boyut sınırı 250kb1 olarak ayarlandı. Bu limit yaklaşık 10.000 standart işlemi tutmaya yetiyordu. içinde
2013 yılının başında bu sınıra neredeyse ulaşıldı ve bu limitin artırılması konusunda anlaşmaya varıldı.
Sınır. Değişiklik cüzdan 0.8 sürümünde uygulandı ve 24 blokluk zincir bölünmesiyle sona erdi
ve başarılı bir çift harcama saldırısı [9]. Hata Bitcoin protokolünde olmasa da
bunun yerine veritabanı motorunda, eğer varsa basit bir stres testiyle kolayca yakalanabilirdi.
yapay olarak getirilmiş blok boyutu sınırı yoktur.
Sabitler ayrıca bir tür merkezileştirme noktası görevi görür.
Eşler arası doğasına rağmen
Bitcoin, düğümlerin büyük çoğunluğu tarafından geliştirilen resmi referans istemcisi [10] kullanılıyor
küçük bir grup insan. Bu grup protokolde değişiklik yapılmasına karar verir
ve çoğu insan bu değişiklikleri “doğruluklarına” bakılmaksızın kabul ediyor. Bazı kararlar neden oldu
hararetli tartışmalar ve hatta boykot çağrıları [11], bu da topluluğun ve
geliştiriciler bazı önemli noktalarda aynı fikirde olmayabilir. Bu nedenle bir protokole sahip olmak mantıklı görünüyor
Bu sorunları önlemenin olası bir yolu olarak kullanıcı tarafından yapılandırılabilen ve kendi kendini ayarlayan değişkenler kullanılır.
2.5
Hacimli komut dosyaları
Bitcoin'deki komut dosyası sistemi ağır ve karmaşık bir özelliktir. Potansiyel olarak kişinin yaratmasına izin verir
karmaşık işlemler [12], ancak güvenlik endişeleri nedeniyle bazı özellikleri devre dışı bırakıldı ve
bazıları hiç kullanılmamış bile [13]. Komut dosyası (hem gönderici hem de alıcı kısımları dahil)
Bitcoin'deki en popüler işlem için şuna benzer:
anahtar, ancak grubundaki tüm kullanıcıların anahtarları. Doğrulayıcının, gerçek imzalayanın bir kişi olduğuna ikna olması grubun üyesidir, ancak yalnızca imzalayanın kimliğini belirleyemez. Orijinal protokol, güvenilir bir üçüncü tarafa (Grup Yöneticisi adı verilen) ihtiyaç duyuyordu ve o da imzalayanın izini sürebilecek tek kişi. Halka imza adı verilen bir sonraki sürüm tanıtıldı Rivest ve diğerleri tarafından. [34]'da, Grup Yöneticisi olmayan ve anonimlik içermeyen özerk bir plandı iptal. Bu şemanın çeşitli modifikasyonları daha sonra ortaya çıktı: bağlanabilir halka imzası [26, 27, 17] iki imzanın aynı grup üyesi tarafından üretilip üretilmediğini belirlemeye izin verildi, izlenebilir halka imza [24, 23] imzalayanın izini sürme olanağı sağlayarak aşırı anonimliği sınırladı aynı meta bilgiye (veya [24] anlamında "etiket") ilişkin iki mesaj. Benzer bir kriptografik yapı aynı zamanda geçici grup imzası olarak da bilinir [16, 38]. o Grup/halka imza şemaları daha çok bir grup/halka imza şemasını ima ederken, keyfi grup oluşumunu vurgulamaktadır. sabit üye kümesi. Çözümümüz çoğunlukla E. Fujisaki'nin "İzlenebilir halka imzası" çalışmasına dayanmaktadır. ve K. Suzuki [24]. Orijinal algoritmayı ve yaptığımız değişikliği ayırt etmek için ikincisini tek seferlik zil imzası olarak adlandırın ve kullanıcının yalnızca bir geçerli zil sesi üretme yeteneğini vurgulayın özel anahtarının altına imza atar. İzlenebilirlik özelliğini zayıflattık ve bağlanabilirliği koruduk yalnızca tek seferliklik sağlamak için: genel anahtar birçok yabancı doğrulama setinde görünebilir ve özel anahtar benzersiz bir anonim imza oluşturmak için kullanılabilir. Çift harcama durumunda Bu iki imza birbirine bağlanacaktır ancak imzalayanın açıklanmasına gerek yoktur bizim amaçlarımız için. 4.2 Tanımlar 4.2.1 Eliptik eğri parametreleri Temel imza algoritmamız olarak, geliştirilen ve geliştirilen hızlı EdDSA şemasını kullanmayı seçtik. D.J. tarafından uygulandı. Bernstein ve ark. [18]. Bitcoin'nin ECDSA'sı gibi eliptik eğriyi temel alır ayrık logaritma problemi olduğundan, şemamız gelecekte Bitcoin'ye de uygulanabilir. Ortak parametreler şunlardır: q: bir asal sayı; q = 2255 −19; d: Fq'nun bir elemanı; d = −121665/121666; E: eliptik bir eğri denklemi; −x2 + y2 = 1 + dx2y2; G: bir taban noktası; G = (x, −4/5); l: taban noktasının asal sırası; l = 2252 + 27742317777372353535851937790883648493; \(H_s\): kriptografik bir hash işlevi \(\{0, 1\}^* \to \mathbb{F}_q\); \(H_p\): deterministik bir hash fonksiyonu \(E(\mathbb{F}_q) \to E(\mathbb{F}_q)\). 4.2.2 Terminoloji Gelişmiş gizlilik, Bitcoin varlıklarla karıştırılmaması gereken yeni bir terminoloji gerektirir. özel ec-anahtarı standart bir eliptik eğri özel anahtarıdır: bir sayı \(a \in [1, l - 1]\); genel ec-anahtarı standart bir eliptik eğridir genel anahtar: bir nokta A = aG; tek kullanımlık anahtar çifti, bir çift özel ve genel ec anahtarıdır; 5 anahtar, ancak grubundaki tüm kullanıcıların anahtarları. Doğrulayıcının, gerçek imzalayanın bir kişi olduğuna ikna olması grubun üyesidir, ancak yalnızca imzalayanın kimliğini belirleyemez. Orijinal protokol, güvenilir bir üçüncü tarafa (Grup Yöneticisi adı verilen) ihtiyaç duyuyordu ve o da imzalayanın izini sürebilecek tek kişi. Halka imza adı verilen bir sonraki sürüm tanıtıldı Rivest ve diğerleri tarafından. [34]'da, Grup Yöneticisi olmayan ve anonimlik içermeyen özerk bir plandı iptal. Bu şemanın çeşitli modifikasyonları daha sonra ortaya çıktı: bağlanabilir halka imzası [26, 27, 17] iki imzanın aynı grup üyesi tarafından üretilip üretilmediğini belirlemeye izin verildi, izlenebilir halka imza [24, 23] imzalayanın izini sürme olanağı sağlayarak aşırı anonimliği sınırladı aynı meta bilgiye (veya [24] anlamında "etiket") ilişkin iki mesaj. Benzer bir kriptografik yapı aynı zamanda geçici grup imzası olarak da bilinir [16, 38]. o Grup/halka imza şemaları daha çok bir grup/halka imza şemasını ima ederken, keyfi grup oluşumunu vurgulamaktadır. sabit üye kümesi. Çözümümüz çoğunlukla E. Fujisaki'nin "İzlenebilir halka imzası" çalışmasına dayanmaktadır. ve K. Suzuki [24]. Orijinal algoritmayı ve yaptığımız değişikliği ayırt etmek için ikincisini tek seferlik zil imzası olarak adlandırın ve kullanıcının yalnızca bir geçerli zil sesi üretme yeteneğini vurgulayın özel anahtarının altına imza atar. İzlenebilirlik özelliğini zayıflattık ve bağlanabilirliği koruduk yalnızca tek seferliklik sağlamak için: genel anahtar birçok yabancı doğrulama setinde görünebilir ve özel anahtar benzersiz bir anonim imza oluşturmak için kullanılabilir. Çift harcama durumunda Bu iki imza birbirine bağlanacaktır ancak imzalayanın açıklanmasına gerek yoktur bizim amaçlarımız için. 4.2 Tanımlar 4.2.1 Eliptik eğri parametreleri Temel imza algoritmamız olarak seçiyoruze geliştirilen ve geliştirilen hızlı EdDSA şemasını kullanmak D.J. tarafından uygulandı. Bernstein ve ark. [18]. Bitcoin'nin ECDSA'sı gibi eliptik eğriyi temel alır ayrık logaritma problemi olduğundan, şemamız gelecekte Bitcoin'ye de uygulanabilir. Ortak parametreler şunlardır: q: bir asal sayı; q = 2255 −19; d: Fq'nun bir elemanı; d = −121665/121666; E: eliptik bir eğri denklemi; −x2 + y2 = 1 + dx2y2; G: bir taban noktası; G = (x, −4/5); l: taban noktasının asal sırası; l = 2252 + 27742317777372353535851937790883648493; \(H_s\): kriptografik bir hash işlevi \(\{0, 1\}^* \to \mathbb{F}_q\); \(H_p\): deterministik bir hash fonksiyonu \(E(\mathbb{F}_q) \to E(\mathbb{F}_q)\). 4.2.2 Terminoloji Gelişmiş gizlilik, Bitcoin varlıklarla karıştırılmaması gereken yeni bir terminoloji gerektirir. özel ec-anahtarı standart bir eliptik eğri özel anahtarıdır: bir sayı \(a \in [1, l - 1]\); genel ec-anahtarı standart bir eliptik eğridir genel anahtar: bir nokta A = aG; tek kullanımlık anahtar çifti, bir çift özel ve genel ec anahtarıdır; 5 8 Yüzük imzası şu şekilde çalışır: Alex, işvereniyle ilgili bir mesajı WikiLeaks'e sızdırmak ister. Şirketindeki her çalışanın özel/genel anahtar çifti (Ri, Ui) vardır. O besteliyor girişi mesajı, m, özel anahtarı, Ri ve HERKE\(S'\)inki olarak ayarlanan imzası ortak anahtarlar, (Ui;i=1...n). Herkes (herhangi bir özel anahtar bilmeden) bunu kolayca doğrulayabilir İmzayı oluşturmak için bir çift (Rj, Uj) kullanılmış olmalı... çalışan biri Alex'in işvereni için... ama hangisi olabileceğini anlamak aslında rastgele bir tahmin. 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 Burada açıklanan bağlanabilir halka imzasının "bağlanamaz" ifadesinin tam tersi olduğuna dikkat edin. yukarıda açıklanmıştır. Burada iki mesajı yakalıyoruz ve aynı olup olmadığını belirleyebiliyoruz. taraf gönderdi, ancak yine de o tarafın kim olduğunu belirleyemeyiz.
Cryptonote'u oluşturmak için kullanılan "bağlanamaz" tanımı, Cryptonote'u oluşturup oluşturmadığımızı belirleyemeyeceğimiz anlamına gelir. onları aynı taraf alıyor. Dolayısıyla burada gerçekte olan DÖRT şeyin devam etmesidir. Bir sistem bağlanabilir veya gönderenin olup olmadığını belirlemenin mümkün olup olmadığına bağlı olarak bağlantı kurulamaz. iki mesaj aynıdır (bunun anonimliğin iptal edilmesini gerektirip gerektirmediğine bakılmaksızın). Ve bir sistemin mümkün olup olmamasına bağlı olarak bağlantısız veya bağlantısız olabilir. iki mesajın alıcısının aynı olup olmadığına karar verin (olup olmadığına bakılmaksızın) bu, anonimliğin iptal edilmesini gerektirir). Lütfen bu korkunç terminoloji için beni suçlamayın. Grafik teorisyenleri muhtemelen memnun oldum. Bazılarınız "alıcıya bağlanabilirlik" yerine "göndere bağlanabilirlik" konusunda daha rahat olabilir. http://link.springer.com/chapter/10.1007/978-3-540-71677-8_13 Bunu okuduğumda bu aptalca bir özellik gibi geldi. Daha sonra bunun bir özellik olabileceğini okudum. elektronik oylama ve bu mantıklı görünüyordu. Bu açıdan bakınca çok hoş. Ama ben izlenebilir halka imzaların bilinçli olarak uygulanması konusunda tam olarak emin değilim. http://search.ieice.org/bin/summary.php?id=e95-a_1_151
anahtar, ancak grubundaki tüm kullanıcıların anahtarları. Doğrulayıcının, gerçek imzalayanın bir kişi olduğuna ikna olması grubun üyesidir, ancak yalnızca imzalayanın kimliğini belirleyemez. Orijinal protokol, güvenilir bir üçüncü tarafa (Grup Yöneticisi adı verilen) ihtiyaç duyuyordu ve o da imzalayanın izini sürebilecek tek kişi. Halka imza adı verilen bir sonraki sürüm tanıtıldı Rivest ve diğerleri tarafından. [34]'de, Grup Yöneticisi olmayan ve anonimlik içermeyen özerk bir plandı iptal. Bu şemanın çeşitli modifikasyonları daha sonra ortaya çıktı: bağlanabilir halka imzası [26, 27, 17] iki imzanın aynı grup üyesi tarafından üretilip üretilmediğini belirlemeye izin verildi, izlenebilir halka imza [24, 23] imzalayanın izini sürme olanağı sağlayarak aşırı anonimliği sınırladı aynı meta bilgiye (veya [24] anlamında "etiket") ilişkin iki mesaj. Benzer bir kriptografik yapı aynı zamanda geçici grup imzası olarak da bilinir [16, 38]. o Grup/halka imza şemaları daha çok bir grup/halka imza şemasını ima ederken, keyfi grup oluşumunu vurgulamaktadır. sabit üye kümesi. Çözümümüz çoğunlukla E. Fujisaki'nin "İzlenebilir halka imzası" çalışmasına dayanmaktadır. ve K. Suzuki [24]. Orijinal algoritmayı ve yaptığımız değişikliği ayırt etmek için ikincisini tek seferlik zil imzası olarak adlandırın ve kullanıcının yalnızca bir geçerli zil sesi üretme yeteneğini vurgulayın özel anahtarının altına imza atar. İzlenebilirlik özelliğini zayıflattık ve bağlanabilirliği koruduk yalnızca tek seferliklik sağlamak için: genel anahtar birçok yabancı doğrulama setinde görünebilir ve özel anahtar benzersiz bir anonim imza oluşturmak için kullanılabilir. Çift harcama durumunda Bu iki imza birbirine bağlanacaktır ancak imzalayanın açıklanmasına gerek yoktur bizim amaçlarımız için. 4.2 Tanımlar 4.2.1 Eliptik eğri parametreleri Temel imza algoritmamız olarak, geliştirilen ve geliştirilen hızlı EdDSA şemasını kullanmayı seçtik. D.J. tarafından uygulandı. Bernstein ve ark. [18]. Bitcoin'nin ECDSA'sı gibi eliptik eğriyi temel alır ayrık logaritma problemi olduğundan, şemamız gelecekte Bitcoin'ye de uygulanabilir. Ortak parametreler şunlardır: q: bir asal sayı; q = 2255 −19; d: Fq'nun bir elemanı; d = −121665/121666; E: eliptik bir eğri denklemi; −x2 + y2 = 1 + dx2y2; G: bir taban noktası; G = (x, −4/5); l: taban noktasının asal sırası; l = 2252 + 27742317777372353535851937790883648493; \(H_s\): kriptografik bir hash işlevi \(\{0, 1\}^* \to \mathbb{F}_q\); \(H_p\): deterministik bir hash fonksiyonu \(E(\mathbb{F}_q) \to E(\mathbb{F}_q)\). 4.2.2 Terminoloji Gelişmiş gizlilik, Bitcoin varlıklarla karıştırılmaması gereken yeni bir terminoloji gerektirir. özel ec-anahtarı standart bir eliptik eğri özel anahtarıdır: bir sayı \(a \in [1, l - 1]\); genel ec-anahtarı standart bir eliptik eğridir genel anahtar: bir nokta A = aG; tek kullanımlık anahtar çifti, bir çift özel ve genel ec anahtarıdır; 5 anahtar, ancak grubundaki tüm kullanıcıların anahtarları. Doğrulayıcının, gerçek imzalayanın bir kişi olduğuna ikna olması grubun üyesidir, ancak yalnızca imzalayanın kimliğini belirleyemez. Orijinal protokol, güvenilir bir üçüncü tarafa (Grup Yöneticisi adı verilen) ihtiyaç duyuyordu ve o da imzalayanın izini sürebilecek tek kişi. Halka imza adı verilen bir sonraki sürüm tanıtıldı Rivest ve diğerleri tarafından. [34]'de, Grup Yöneticisi olmayan ve anonimlik içermeyen özerk bir plandı iptal. Bu şemanın çeşitli modifikasyonları daha sonra ortaya çıktı: bağlanabilir halka imzası [26, 27, 17] iki imzanın aynı grup üyesi tarafından üretilip üretilmediğini belirlemeye izin verildi, izlenebilir halka imza [24, 23] imzalayanın izini sürme olanağı sağlayarak aşırı anonimliği sınırladı aynı meta bilgiye (veya [24] anlamında "etiket") ilişkin iki mesaj. Benzer bir kriptografik yapı aynı zamanda geçici grup imzası olarak da bilinir [16, 38]. o Grup/halka imza şemaları daha çok bir grup/halka imza şemasını ima ederken, keyfi grup oluşumunu vurgulamaktadır. sabit üye kümesi. Çözümümüz çoğunlukla E. Fujisaki'nin "İzlenebilir halka imzası" çalışmasına dayanmaktadır. ve K. Suzuki [24]. Orijinal algoritmayı ve yaptığımız değişikliği ayırt etmek için ikincisini tek seferlik zil imzası olarak adlandırın ve kullanıcının yalnızca bir geçerli zil sesi üretme yeteneğini vurgulayın özel anahtarının altına imza atar. İzlenebilirlik özelliğini zayıflattık ve bağlanabilirliği koruduk yalnızca tek seferliklik sağlamak için: genel anahtar birçok yabancı doğrulama setinde görünebilir ve özel anahtar benzersiz bir anonim imza oluşturmak için kullanılabilir. Çift harcama durumunda Bu iki imza birbirine bağlanacaktır ancak imzalayanın açıklanmasına gerek yoktur bizim amaçlarımız için. 4.2 Tanımlar 4.2.1 Eliptik eğri parametreleri Temel imza algoritmamız olarak seçiyoruze geliştirilen ve geliştirilen hızlı EdDSA şemasını kullanmak D.J. tarafından uygulandı. Bernstein ve ark. [18]. Bitcoin'nın ECDSA'sı gibi eliptik eğriyi temel alır ayrık logaritma problemi olduğundan, şemamız gelecekte Bitcoin'ye de uygulanabilir. Ortak parametreler şunlardır: q: bir asal sayı; q = 2255 −19; d: Fq'nun bir elemanı; d = −121665/121666; E: eliptik bir eğri denklemi; −x2 + y2 = 1 + dx2y2; G: bir taban noktası; G = (x, −4/5); l: taban noktasının asal sırası; l = 2252 + 27742317777372353535851937790883648493; \(H_s\): kriptografik bir hash işlevi \(\{0, 1\}^* \to \mathbb{F}_q\); \(H_p\): deterministik bir hash fonksiyonu \(E(\mathbb{F}_q) \to E(\mathbb{F}_q)\). 4.2.2 Terminoloji Gelişmiş gizlilik, Bitcoin varlıklarla karıştırılmaması gereken yeni bir terminoloji gerektirir. özel ec-anahtarı standart bir eliptik eğri özel anahtarıdır: bir sayı \(a \in [1, l - 1]\); genel ec-anahtarı standart bir eliptik eğridir genel anahtar: bir nokta A = aG; tek kullanımlık anahtar çifti, bir çift özel ve genel ec anahtarıdır; 5 9 Tanrım, bu teknik incelemenin yazarı bunu kesinlikle daha iyi ifade edebilirdi! Diyelim ki bir Çalışanların sahibi olduğu şirket, belirli yeni ürünleri satın alıp almama konusunda oylama yapmak istiyor varlıklardır ve Alex ve Brenda'nın ikisi de çalışandır. Şirket her çalışana bir "Öneri A'ya evet oyu veriyorum!" gibi bir mesaj "sorun" meta bilgisine sahip olan [PROP A] ve eğer teklifi destekliyorlarsa izlenebilir bir yüzük imzasıyla imzalamalarını istiyor. Dürüst olmayan bir çalışan, geleneksel zil sesi imzasını kullanarak mesajı birden çok kez imzalayabilir. muhtemelen farklı nonce'lerle, istedikleri kadar oy verebilmek için. diğer tarafta izlenebilir bir halka imza şemasında Alex oy kullanmaya gidecek ve onun özel anahtarı [PROP A] sorunu üzerinde kullanıldı. Alex "Ben, Brenda, onaylıyorum" gibi bir mesajı imzalamaya çalışırsa A önermesi!" Brenda'yı "çerçevelemek" ve çifte oylama yapmak için, bu yeni mesaj aynı zamanda sorunu da çözecek [PROP A]. Alex'in özel anahtarı zaten [PROP A] sorununu tetiklediği için Alex'in kimliği dolandırıcılık olduğu hemen ortaya çıkacaktır. Kabul et ki bu oldukça havalı! Kriptografi oy eşitliğini zorunlu kıldı. http://link.springer.com/chapter/10.1007/978-3-540-71677-8_13 Bu makale ilginçtir, esas olarak geçici bir halka imzası oluşturur, ancak bu imzalardan herhangi birini içermez. diğer katılımcının onayı. İmzanın yapısı farklı olabilir; kazmadım derin ve güvenli olup olmadığını görmedim. https://people.csail.mit.edu/rivest/AdidaHohenbergerRivest-AdHocGroupSignaturesFromHijackedKeypai Geçici grup imzaları şunlardır: grubu olmayan grup imzaları olan halka imzalar yöneticiler, merkezileştirme yok, ancak geçici bir gruptaki bir üyenin kanıtlanabilir bir şekilde şunu iddia etmesine izin veriyor: grup adına isimsiz imzayı vermiştir/vermemiştir. http://link.springer.com/chapter/10.1007/11908739_9 Anladığım kadarıyla bu pek doğru değil. Ve anlayışım muhtemelen değişecek Bu projenin derinliklerine iniyorum. Ama benim anladığım kadarıyla hiyerarşi şöyle görünüyor. Grup imzaları: grup yöneticileri izlenebilirliği ve üye ekleme veya çıkarma yeteneğini kontrol eder imzacı olmaktan. Ring işaretleri: Grup yöneticisi olmadan keyfi grup oluşumu. Anonimliğin iptali yok. Belirli bir imzayı reddetmenin hiçbir yolu yoktur. İzlenebilir ve bağlanabilir halkalı imzalar, anonimlik bir şekilde ölçeklenebilir. Geçici grup imzaları: halka imzalara benzer ancak üyeler kendilerinin oluşturmadığını kanıtlayabilir özel bir imza. Gruptaki herhangi biri imza atabildiğinde bu önemlidir. http://link.springer.com/chapter/10.1007/978-3-540-71677-8_13 Fujisaki ve Suzuki'nin algoritması daha sonra yazar tarafından tek seferliklik sağlayacak şekilde ayarlandı. Yani Fujisaki ve Suzuki’nin algoritmasını yeni algoritmayla eş zamanlı olarak analiz edeceğiz. burada üzerinden geçmek yerine.
anahtar, ancak grubundaki tüm kullanıcıların anahtarları. Doğrulayıcının, gerçek imzalayanın bir kişi olduğuna ikna olması grubun üyesidir, ancak yalnızca imzalayanın kimliğini belirleyemez. Orijinal protokol, güvenilir bir üçüncü tarafa (Grup Yöneticisi adı verilen) ihtiyaç duyuyordu ve o da imzalayanın izini sürebilecek tek kişi. Halka imza adı verilen bir sonraki sürüm tanıtıldı Rivest ve diğerleri tarafından. [34]'de, Grup Yöneticisi olmayan ve anonimlik içermeyen özerk bir plandı iptal. Bu şemanın çeşitli modifikasyonları daha sonra ortaya çıktı: bağlanabilir halka imzası [26, 27, 17] iki imzanın aynı grup üyesi tarafından üretilip üretilmediğini belirlemeye izin verildi, izlenebilir halka imza [24, 23] imzalayanın izini sürme olanağı sağlayarak aşırı anonimliği sınırladı aynı meta bilgiye (veya [24] anlamında "etiket") ilişkin iki mesaj. Benzer bir kriptografik yapı aynı zamanda geçici grup imzası olarak da bilinir [16, 38]. o Grup/halka imza şemaları daha çok bir grup/halka imza şemasını ima ederken, keyfi grup oluşumunu vurgulamaktadır. sabit üye kümesi. Çözümümüz çoğunlukla E. Fujisaki'nin "İzlenebilir halka imzası" çalışmasına dayanmaktadır. ve K. Suzuki [24]. Orijinal algoritmayı ve yaptığımız değişikliği ayırt etmek için ikincisini tek seferlik zil imzası olarak adlandırın ve kullanıcının yalnızca bir geçerli zil sesi üretme yeteneğini vurgulayın özel anahtarının altına imza atar. İzlenebilirlik özelliğini zayıflattık ve bağlanabilirliği koruduk yalnızca tek seferliklik sağlamak için: genel anahtar birçok yabancı doğrulama setinde görünebilir ve özel anahtar benzersiz bir anonim imza oluşturmak için kullanılabilir. Çift harcama durumunda Bu iki imza birbirine bağlanacaktır ancak imzalayanın açıklanmasına gerek yoktur bizim amaçlarımız için. 4.2 Tanımlar 4.2.1 Eliptik eğri parametreleri Temel imza algoritmamız olarak, geliştirilen ve geliştirilen hızlı EdDSA şemasını kullanmayı seçtik. D.J. tarafından uygulandı. Bernstein ve ark. [18]. Bitcoin'nun ECDSA'sı gibi eliptik eğriye dayanmaktadır ayrık logaritma problemi olduğundan, şemamız gelecekte Bitcoin'ye de uygulanabilir. Ortak parametreler şunlardır: q: bir asal sayı; q = 2255 −19; d: Fq'nun bir elemanı; d = −121665/121666; E: eliptik bir eğri denklemi; −x2 + y2 = 1 + dx2y2; G: bir taban noktası; G = (x, −4/5); l: taban noktasının asal sırası; l = 2252 + 27742317777372353535851937790883648493; \(H_s\): kriptografik bir hash işlevi \(\{0, 1\}^* \to \mathbb{F}_q\); \(H_p\): deterministik bir hash fonksiyonu \(E(\mathbb{F}_q) \to E(\mathbb{F}_q)\). 4.2.2 Terminoloji Gelişmiş gizlilik, Bitcoin varlıklarla karıştırılmaması gereken yeni bir terminoloji gerektirir. özel ec-anahtarı standart bir eliptik eğri özel anahtarıdır: bir sayı \(a \in [1, l - 1]\); genel ec-anahtarı standart bir eliptik eğridir genel anahtar: bir nokta A = aG; tek kullanımlık anahtar çifti, bir çift özel ve genel ec anahtarıdır; 5 anahtar, ancak grubundaki tüm kullanıcıların anahtarları. Doğrulayıcının, gerçek imzalayanın bir kişi olduğuna ikna olması grubun üyesidir, ancak yalnızca imzalayanın kimliğini belirleyemez. Orijinal protokol, güvenilir bir üçüncü tarafa (Grup Yöneticisi adı verilen) ihtiyaç duyuyordu ve o da imzalayanın izini sürebilecek tek kişi. Halka imza adı verilen bir sonraki sürüm tanıtıldı Rivest ve diğerleri tarafından. [34]'da, Grup Yöneticisi olmayan ve anonimlik içermeyen özerk bir plandı iptal. Bu şemanın çeşitli modifikasyonları daha sonra ortaya çıktı: bağlanabilir halka imzası [26, 27, 17] iki imzanın aynı grup üyesi tarafından üretilip üretilmediğini belirlemeye izin verildi, izlenebilir halka imza [24, 23] imzalayanın izini sürme olanağı sağlayarak aşırı anonimliği sınırladı aynı meta bilgiye (veya [24] anlamında "etiket") ilişkin iki mesaj. Benzer bir kriptografik yapı aynı zamanda geçici grup imzası olarak da bilinir [16, 38]. o Grup/halka imza şemaları daha çok bir grup/halka imza şemasını ima ederken, keyfi grup oluşumunu vurgulamaktadır. sabit üye kümesi. Çözümümüz çoğunlukla E. Fujisaki'nin "İzlenebilir halka imzası" çalışmasına dayanmaktadır. ve K. Suzuki [24]. Orijinal algoritmayı ve yaptığımız değişikliği ayırt etmek için ikincisini tek seferlik zil imzası olarak adlandırın ve kullanıcının yalnızca bir geçerli zil sesi üretme yeteneğini vurgulayın özel anahtarının altına imza atar. İzlenebilirlik özelliğini zayıflattık ve bağlanabilirliği koruduk yalnızca tek seferliklik sağlamak için: genel anahtar birçok yabancı doğrulama setinde görünebilir ve özel anahtar benzersiz bir anonim imza oluşturmak için kullanılabilir. Çift harcama durumunda Bu iki imza birbirine bağlanacaktır ancak imzalayanın açıklanmasına gerek yoktur bizim amaçlarımız için. 4.2 Tanımlar 4.2.1 Eliptik eğri parametreleri Temel imza algoritmamız olarak seçiyoruze geliştirilen ve geliştirilen hızlı EdDSA şemasını kullanmak D.J. tarafından uygulandı. Bernstein ve ark. [18]. Bitcoin'nin ECDSA'sı gibi eliptik eğriyi temel alır ayrık logaritma problemi olduğundan, şemamız gelecekte Bitcoin'ye de uygulanabilir. Ortak parametreler şunlardır: q: bir asal sayı; q = 2255 −19; d: Fq'nun bir elemanı; d = −121665/121666; E: eliptik bir eğri denklemi; −x2 + y2 = 1 + dx2y2; G: bir taban noktası; G = (x, −4/5); l: taban noktasının asal sırası; l = 2252 + 27742317777372353535851937790883648493; \(H_s\): kriptografik bir hash işlevi \(\{0, 1\}^* \to \mathbb{F}_q\); \(H_p\): deterministik bir hash fonksiyonu \(E(\mathbb{F}_q) \to E(\mathbb{F}_q)\). 4.2.2 Terminoloji Gelişmiş gizlilik, Bitcoin varlıklarla karıştırılmaması gereken yeni bir terminoloji gerektirir. özel ec-anahtarı standart bir eliptik eğri özel anahtarıdır: bir sayı \(a \in [1, l - 1]\); genel ec-anahtarı standart bir eliptik eğridir genel anahtar: bir nokta A = aG; tek kullanımlık anahtar çifti, bir çift özel ve genel ec anahtarıdır; 5 10 "Bağlanabilir halka imzaları" anlamındaki bağlanabilirlik, kaynağın kim olduğunu açıklamadan, giden iki işlemin aynı kaynaktan gelip gelmediğini söyleyebilmemiz anlamına gelir. Yazarlar zayıfladı (a) gizliliği korumak, ancak yine de (b) özel anahtar kullanarak herhangi bir işlemi tespit etmek için bağlanabilirlik ikinci kez geçersiz. Tamam, bu bir olaylar sırası sorusudur. Aşağıdaki senaryoyu düşünün. Benim madenciliğim bilgisayar geçerli blockchain numarasına sahip olacak, çağırdığı kendi işlem bloğuna sahip olacak meşru, bir proof-of-work bulmacasındaki o blok üzerinde çalışacak ve Bir sonraki bloğa eklenecek bekleyen işlemlerin listesi. Ayrıca yenilerini de gönderecek işlemleri bekleyen işlemler havuzuna aktarır. Bir sonraki bloğu çözemezsem ama başkası bunu yaparsa blockchain dosyasının güncellenmiş bir kopyasını alırım. Üzerinde çalıştığım blok ve bekleyen işlemler listemin her ikisinde de şu anda dahil edilmiş bazı işlemler bulunabilir blockchain içine. Bekleyen bloğumu çöz, bunu bekleyen işlemler listemle birleştir ve buna çağrı yap bekleyen işlemler havuzum. Şu anda resmi olarak blockchain içinde bulunanları kaldırın. Şimdi ne yapacağım? İlk önce "tüm çift harcamaları kaldırmalı mıyım"? diğer tarafta Öte yandan, listede arama yapıp her özel anahtarın henüz değiştirilmediğinden emin olmalı mıyım? kullanılmış ve listemde zaten kullanılmışsa, ilk kopyayı ilk ben aldım ve dolayısıyla bundan sonraki herhangi bir kopya gayri meşrudur. Böylece ilkinden sonra tüm örnekleri silmeye devam ediyorum. aynı özel anahtardan. Cebirsel geometri hiçbir zaman bana göre bir güç olmadı. http://en.wikipedia.org/wiki/EdDSA Bu kadar hız, çok vay be. BU kazanmaya yönelik cebirsel geometridir. Hiçbir şey bildiğimden değil bu konuda. Sorunlu olsun veya olmasın, ayrık günlükler çok hızlı hale geliyor. Ve kuantum bilgisayarlar onları yiyor kahvaltı için. http://link.springer.com/article/10.1007/s13389-012-0027-1 Bu gerçekten önemli bir sayı haline geliyor, ancak nasıl olduğuna dair hiçbir açıklama veya alıntı yok. seçildi. Bilinen tek bir büyük asal sayıyı seçmek yeterli olacaktır, ancak eğer bilinenler varsa seçimimizi etkileyebilecek bu büyük asal sayı hakkındaki gerçekler. Kripto notun farklı çeşitleri farklı değerler seçilebilir eh, ama bu yazıda bunun nasıl olduğuna dair bir tartışma yok. seçim, sayfa 5'te listelenen diğer küresel parametrelere ilişkin seçimlerimizi etkileyecektir. Bu yazının parametre değerlerinin seçimiyle ilgili bir bölüme ihtiyacı var.
özel kullanıcı anahtarı iki farklı özel ec anahtarından oluşan bir (a, b) çiftidir; izleme anahtarı, özel ve genel ec anahtarının bir çiftidir (a, B) (burada B = bG ve a̸= b); genel kullanıcı anahtarı, (a, b)'den türetilen iki genel ec anahtarının (A, B) çiftidir; standart adres, insan dostu dizeye verilen genel kullanıcı anahtarının bir temsilidir hata düzeltme ile; kısaltılmış adres, verilen genel kullanıcı anahtarının ikinci yarısının (B noktası) temsilidir hata düzeltmeyle insan dostu dizeye dönüştürülür. İşlem yapısı Bitcoin'deki yapıya benzer kalır: her kullanıcı seçebilir birkaç bağımsız gelen ödeme (işlem çıktıları), bunları ilgili imzalarla imzalayın özel anahtarlar ve bunları farklı hedeflere gönderin. Kullanıcının benzersiz özel ve genel anahtara sahip olduğu Bitcoin modelinin aksine, Önerilen modelde gönderici, alıcının adresine dayalı olarak tek seferlik bir genel anahtar üretir ve bazı rastgele veriler. Bu anlamda aynı alıcıya gelen bir işlem, tek kullanımlık genel anahtar (doğrudan benzersiz bir adrese değil) ve yalnızca alıcı bu anahtarı kurtarabilir fonlarını kullanmak için karşılık gelen özel kısım (benzersiz özel anahtarını kullanarak). Alıcı şunları yapabilir: fonları bir yüzük imzası kullanarak, mülkiyetini ve fiili harcamalarını anonim tutarak harcayacaktır. Protokolün detayları sonraki alt bölümlerde açıklanmaktadır. 4.3 Bağlantısı kaldırılamayan ödemeler Klasik Bitcoin adresleri yayınlandıktan sonra gelenler için kesin bir tanımlayıcı haline gelir. ödemeleri birbirine bağlamak ve alıcının takma adlarına bağlamak. Birisi isterse “bağlantısız” bir işlem alıyorsa, göndericiye adresini özel bir kanaldan iletmesi gerekir. Aynı sahibine ait olduğu kanıtlanamayan farklı işlemleri almak istiyorsa tüm farklı adresleri oluşturmalı ve bunları asla kendi takma adıyla yayınlamamalıdır. halka açık Özel Alice Carol Bob'un adresi 1 Bob'un adresi 2 Bob'un anahtarı 1 Bob'un anahtarı 2 Bob Şekil 2. Geleneksel Bitcoin anahtarlar/işlemler modeli. Kullanıcının tek bir adres yayınlamasına ve koşulsuz olarak almasına olanak tanıyan bir çözüm öneriyoruz bağlantısız ödemeler Her CryptoNote çıkışının hedefi (varsayılan olarak) bir genel anahtardır, alıcının adresinden ve gönderenin rastgele verilerinden elde edilir. Bitcoin'a karşı ana avantaj her hedef anahtarın varsayılan olarak benzersiz olmasıdır (gönderen her anahtar için aynı verileri kullanmadığı sürece) işlemlerinin aynı alıcıya yapılması). Dolayısıyla “adresin yeniden kullanılması” gibi bir sorun söz konusu değildir. tasarım ve hiçbir gözlemci herhangi bir işlemin belirli bir adrese veya bağlantıya gönderilip gönderilmediğini belirleyemez iki adres bir arada. 6 özel kullanıcı anahtarı iki farklı özel ec anahtarından oluşan bir (a, b) çiftidir; izleme anahtarı, özel ve genel ec anahtarının bir çiftidir (a, B) (burada B = bG ve a̸= b); genel kullanıcı anahtarı, (a, b)'den türetilen iki genel ec anahtarının (A, B) çiftidir; standart adres, insan dostu dizeye verilen genel kullanıcı anahtarının bir temsilidir hata düzeltme ile; kısaltılmış adres, verilen genel kullanıcı anahtarının ikinci yarısının (B noktası) temsilidir hata düzeltmeyle insan dostu dizeye dönüştürülür. İşlem yapısı Bitcoin'deki yapıya benzer kalır: her kullanıcı seçebilir birkaç bağımsız gelen ödeme (işlem çıktıları), bunları ilgili imzalarla imzalayın özel anahtarlar ve bunları farklı hedeflere gönderin. Kullanıcının benzersiz özel ve genel anahtara sahip olduğu Bitcoin modelinin aksine, Önerilen modelde gönderici, alıcının adresine dayalı olarak tek seferlik bir genel anahtar üretir ve bazı rastgele veriler. Bu anlamda aynı alıcıya gelen bir işlem, tek kullanımlık genel anahtar (doğrudan benzersiz bir adrese değil) ve yalnızca alıcı bu anahtarı kurtarabilir fonlarını kullanmak için karşılık gelen özel kısım (benzersiz özel anahtarını kullanarak). Alıcı şunları yapabilir: fonları bir yüzük imzası kullanarak, mülkiyetini ve fiili harcamalarını anonim tutarak harcayacaktır. Protokolün detayları sonraki alt bölümlerde açıklanmaktadır. 4.3 Bağlantısı kaldırılamayan ödemeler Klasik Bitcoin adresleri yayınlandıktan sonra gelenler için kesin bir tanımlayıcı haline gelir. ödemeleri birbirine bağlamak ve alıcının takma adlarına bağlamak. Birisi isterse “bağlantısız” bir işlem alıyorsa, göndericiye adresini özel bir kanaldan iletmesi gerekir. Aynı sahibine ait olduğu kanıtlanamayan farklı işlemleri almak istiyorsa tüm farklı adresleri oluşturmalı ve bunları asla kendi takma adıyla yayınlamamalıdır. halka açık Özel Alice Carol Bob'un adresi 1 Bob'un adresi 2 Bob'un anahtarı 1 Bob'un anahtarı 2 Bob Şekil 2. Geleneksel Bitcoin anahtarlar/işlemler moduel. Kullanıcının tek bir adres yayınlamasına ve koşulsuz olarak almasına olanak tanıyan bir çözüm öneriyoruz bağlantısız ödemeler Her CryptoNote çıkışının hedefi (varsayılan olarak) bir genel anahtardır, alıcının adresinden ve gönderenin rastgele verilerinden elde edilir. Bitcoin'ye karşı ana avantaj her hedef anahtarın varsayılan olarak benzersiz olmasıdır (gönderen her anahtar için aynı verileri kullanmadığı sürece) işlemlerinin aynı alıcıya yapılması). Dolayısıyla “adresin yeniden kullanılması” gibi bir sorun söz konusu değildir. tasarım ve hiçbir gözlemci herhangi bir işlemin belirli bir adrese veya bağlantıya gönderilip gönderilmediğini belirleyemez iki adres bir arada. 6 11 Yani bu Bitcoin gibi, ancak sonsuz, anonim Posta Kutuları var, yalnızca alıcı tarafından kullanılabilecek Bir halka imzasının olabileceği kadar anonim olan özel bir anahtar oluşturmak. Bitcoin bu şekilde çalışır. Eğer Alex'in Frank'ten yeni aldığı cüzdanında 0,112 Bitcoin varsa, gerçekten imzalı bir parası var demektir "Ben, [FRANK], 0.112 Bitcoin'yi [alex] + H0 + N0'a gönder" mesajı burada 1) Frank imzaladı özel anahtarıyla [FRANK] mesaj attı, 2) Frank mesajı Alex'in herkese açık anahtarıyla imzaladı anahtar, [alex], 3) Frank Bitcoin'in geçmişinin bir kısmını dahil etti, H0 ve 4) Frank nonce, N0 adı verilen rastgele bir veri biti içerir. Alex daha sonra Charlene'e 0,011 Bitcoin göndermek isterse Frank'in mesajını alacak ve bunu H1'e ayarlayacak ve iki mesaj imzalayacak: biri işlemi için, diğeri değişiklik için. H1= "Ben, [FRANK], 0,112 Bitcoin'yi [alex] + H0 + N'ye gönder" "I, [ALEX], 0,011 Bitcoin'yi gönder [charlene] + H1 + N1" "Ben, [ALEX], [alex] + H1 + N2'ye değişiklik olarak 0.101 Bitcoin gönder." Alex'in her iki mesajı da kendi özel anahtarıyla [ALEX] imzaladığı yer, Charlene'nin şifresini içeren ilk mesaj genel anahtar [charlene], Alex'in genel anahtarının [alex] bulunduğu ikinci mesaj ve geçmişleri ve bazıları rastgele oluşturulmuş nonces N1 ve N2'yi uygun şekilde oluşturur. Cryptonote şu şekilde çalışır: Alex'in Frank'ten yeni aldığı cüzdanında 0.112 Cryptonote varsa gerçekten imzalı bir parası var demektir. "Ben, [geçici bir gruptaki biri], [tek seferlik bir adrese] + H0'a 0.112 Cryptonote gönderiyorum + Hayır." Alex, özel anahtarını [ALEX] kontrol ederek bunun kendisine ait olduğunu keşfetti. Her geçen mesaj için [tek seferlik bir adres] ve eğer onu harcamak isterse bunu aşağıdaki şekilde. Paranın alıcısını seçiyor, belki de Charlene drone saldırılarına oy vermeye başlamıştır. Alex bunun yerine Brenda'ya para göndermek istiyor. Alex, Brenda'nın genel anahtarına (brenda) bakar, ve tek seferlik bir adres [ALEX+brenda] oluşturmak için kendi özel anahtarı olan [ALEX]'i kullanır. O daha sonra kriptonot kullanıcıları ağından rastgele bir C koleksiyonu seçer ve oluşturur bu geçici gruptan bir halka imzası. Geçmişimizi bir önceki mesaj olarak ayarladık, ekledik nonces ve her zamanki gibi devam edilsin mi? H1 = "Ben, [geçici bir gruptaki biri], [tek seferlik bir adrese] + H0'a 0.112 Cryptonote gönderiyorum + Hayır." "Ben, [C koleksiyonundan biri], [ALEX+brenda'dan tek seferlik adres yapımı] + H1 + N1'e 0,011 Cryptonote gönderiyorum" "Ben, [C koleksiyonundan biri], değişiklik olarak 0.101 Cryptonote'u [ALEX+alex'ten yapılan tek seferlik adres] + H1 + N2'ye gönderiyorum" Artık Alex ve Brenda, gelen tüm mesajları tek seferlik adresler için tarıyor. anahtarları kullanılarak oluşturulmuştur. Eğer herhangi bir şey bulurlarsa, o zaman bu mesaj kendilerine ait yepyeni bir mesajdır. kriptonot! Ve o zaman bile işlem yine de blockchain'ye ulaşacaktır. Eğer o adrese giren coinler suçlulardan, siyasi katkıda bulunanlardan veya komitelerden ve hesaplardan gönderildiği biliniyor bütçeleri kısıtlıysa (örn. zimmete para geçirme) veya bu paraların yeni sahibi bir hata yaparsa ve bu paraları sahibi olduğu bilinen paralarla ortak bir adrese, anonimlik oyununa gönderir Bitcoin'de yükseliş var.
özel kullanıcı anahtarı iki farklı özel ec anahtarından oluşan bir (a, b) çiftidir; izleme anahtarı, özel ve genel ec anahtarının bir çiftidir (a, B) (burada B = bG ve a̸= b); genel kullanıcı anahtarı, (a, b)'den türetilen iki genel ec anahtarının (A, B) çiftidir; standart adres, insan dostu dizeye verilen genel kullanıcı anahtarının bir temsilidir hata düzeltme ile; kısaltılmış adres, verilen genel kullanıcı anahtarının ikinci yarısının (B noktası) temsilidir hata düzeltmeyle insan dostu dizeye dönüştürülür. İşlem yapısı Bitcoin'deki yapıya benzer: her kullanıcı seçebilir birkaç bağımsız gelen ödeme (işlem çıktıları), bunları ilgili imzalarla imzalayın özel anahtarlar ve bunları farklı hedeflere gönderin. Kullanıcının benzersiz özel ve genel anahtara sahip olduğu Bitcoin modelinin aksine, Önerilen modelde gönderici, alıcının adresine dayalı olarak tek seferlik bir genel anahtar üretir ve bazı rastgele veriler. Bu anlamda aynı alıcıya gelen bir işlem, tek kullanımlık genel anahtar (doğrudan benzersiz bir adrese değil) ve yalnızca alıcı bu anahtarı kurtarabilir fonlarını kullanmak için karşılık gelen özel kısım (benzersiz özel anahtarını kullanarak). Alıcı şunları yapabilir: fonları bir yüzük imzası kullanarak, mülkiyetini ve fiili harcamalarını anonim tutarak harcayacaktır. Protokolün detayları sonraki alt bölümlerde açıklanmaktadır. 4.3 Bağlantısı kaldırılamayan ödemeler Klasik Bitcoin adresleri yayınlandıktan sonra gelenler için kesin bir tanımlayıcı haline gelir. ödemeleri birbirine bağlamak ve alıcının takma adlarına bağlamak. Birisi isterse “bağlantısız” bir işlem alıyorsa, göndericiye adresini özel bir kanaldan iletmesi gerekir. Aynı sahibine ait olduğu kanıtlanamayan farklı işlemleri almak istiyorsa tüm farklı adresleri oluşturmalı ve bunları asla kendi takma adıyla yayınlamamalıdır. halka açık Özel Alice Carol Bob'un adresi 1 Bob'un adresi 2 Bob'un anahtarı 1 Bob'un anahtarı 2 Bob Şekil 2. Geleneksel Bitcoin anahtarlar/işlemler modeli. Kullanıcının tek bir adres yayınlamasına ve koşulsuz olarak almasına olanak tanıyan bir çözüm öneriyoruz bağlantısız ödemeler Her CryptoNote çıkışının hedefi (varsayılan olarak) bir genel anahtardır, alıcının adresinden ve gönderenin rastgele verilerinden elde edilir. Bitcoin'ye karşı ana avantaj her hedef anahtarın varsayılan olarak benzersiz olmasıdır (gönderen her anahtar için aynı verileri kullanmadığı sürece) işlemlerinin aynı alıcıya yapılması). Dolayısıyla “adresin yeniden kullanılması” gibi bir sorun söz konusu değildir. tasarım ve hiçbir gözlemci herhangi bir işlemin belirli bir adrese veya bağlantıya gönderilip gönderilmediğini belirleyemez iki adres bir arada. 6 özel kullanıcı anahtarı iki farklı özel ec anahtarından oluşan bir (a, b) çiftidir; izleme anahtarı, özel ve genel ec anahtarının bir çiftidir (a, B) (burada B = bG ve a̸= b); genel kullanıcı anahtarı, (a, b)'den türetilen iki genel ec anahtarının (A, B) çiftidir; standart adres, insan dostu dizeye verilen genel kullanıcı anahtarının bir temsilidir hata düzeltme ile; kısaltılmış adres, verilen genel kullanıcı anahtarının ikinci yarısının (B noktası) temsilidir hata düzeltmeyle insan dostu dizeye dönüştürülür. İşlem yapısı Bitcoin'deki yapıya benzer kalır: her kullanıcı seçebilir birkaç bağımsız gelen ödeme (işlem çıktıları), bunları ilgili imzalarla imzalayın özel anahtarlar ve bunları farklı hedeflere gönderin. Kullanıcının benzersiz özel ve genel anahtara sahip olduğu Bitcoin modelinin aksine, Önerilen modelde gönderici, alıcının adresine dayalı olarak tek seferlik bir genel anahtar üretir ve bazı rastgele veriler. Bu anlamda aynı alıcıya gelen bir işlem, tek kullanımlık genel anahtar (doğrudan benzersiz bir adrese değil) ve yalnızca alıcı bu anahtarı kurtarabilir fonlarını kullanmak için karşılık gelen özel kısım (benzersiz özel anahtarını kullanarak). Alıcı şunları yapabilir: fonları bir yüzük imzası kullanarak, mülkiyetini ve fiili harcamalarını anonim tutarak harcayacaktır. Protokolün detayları sonraki alt bölümlerde açıklanmaktadır. 4.3 Bağlantısı kaldırılamayan ödemeler Klasik Bitcoin adresleri yayınlandıktan sonra gelenler için kesin bir tanımlayıcı haline gelir. ödemeleri birbirine bağlamak ve alıcının takma adlarına bağlamak. Birisi isterse “bağlantısız” bir işlem alıyorsa, göndericiye adresini özel bir kanaldan iletmesi gerekir. Aynı sahibine ait olduğu kanıtlanamayan farklı işlemleri almak istiyorsa tüm farklı adresleri oluşturmalı ve bunları asla kendi takma adıyla yayınlamamalıdır. halka açık Özel Alice Carol Bob'un adresi 1 Bob'un adresi 2 Bob'un anahtarı 1 Bob'un anahtarı 2 Bob Şekil 2. Geleneksel Bitcoin anahtarlar/işlemler moduel. Kullanıcının tek bir adres yayınlamasına ve koşulsuz olarak almasına olanak tanıyan bir çözüm öneriyoruz bağlantısız ödemeler Her CryptoNote çıkışının hedefi (varsayılan olarak) bir genel anahtardır, alıcının adresinden ve gönderenin rastgele verilerinden elde edilir. Bitcoin'ye karşı ana avantaj her hedef anahtarın varsayılan olarak benzersiz olmasıdır (gönderen her anahtar için aynı verileri kullanmadığı sürece) işlemlerinin aynı alıcıya yapılması). Dolayısıyla “adresin yeniden kullanılması” gibi bir sorun söz konusu değildir. tasarım ve hiçbir gözlemci herhangi bir işlemin belirli bir adrese veya bağlantıya gönderilip gönderilmediğini belirleyemez iki adres bir arada. 6 12 Bu nedenle, kullanıcıların adresten (aslında bir genel anahtardır) adrese para göndermesi yerine (başka bir genel anahtar) özel anahtarlarını kullanarak kullanıcılar tek kullanımlık posta kutusundan para gönderiyorlar (arkadaşlarınızın genel anahtarını kullanarak oluşturuyor) tek seferlik posta kutusuna (benzer şekilde) kendi özel anahtarlarınız. Bir anlamda "Tamam, herkes paranın üzerinden elini çeksin" diyoruz. etrafa transfer edildi! Anahtarlarımızın o kutuyu açabileceğini bilmek yeterli. Kutuda ne kadar para olduğunu biliyoruz. Hiçbir zaman parmak izlerinizi Posta Kutusunun veya onu gerçekten kullan, sadece nakit dolu kutuyu takas et. Bu şekilde kimin gönderdiğini bilmiyoruz ama bu halka açık konuşmaların içerikleri hala sürtünmesiz, takas edilebilir, bölünebilir ve Bitcoin gibi paranın arzu ettiğimiz tüm diğer güzel niteliklerine hâlâ sahibiz.” Sonsuz sayıda posta kutusu seti. Bir adres yayınlıyorsun, benim özel anahtarım var. Özel anahtarımı ve adresinizi kullanıyorum ve ortak anahtar oluşturmak için bazı rastgele veriler. Algoritma öyle tasarlanmıştır ki, adresiniz genel anahtarı oluşturmak için kullanıldı, yalnızca SİZİN özel anahtarınız kilidi açmak için çalışır mesaj. Bir gözlemci olan Eve, adresinizi yayınladığınızı ve duyurduğum genel anahtarı görüyor. Ancak, Genel anahtarımı sizin adresinize mi yoksa onun adresine mi, yoksa Brenda'ya mı dayanarak açıkladığımı bilmiyor ya da Charlene'ninki ya da her kimse. Özel anahtarını açıkladığım genel anahtarla karşılaştırıyor ve işe yaramadığını görüyor; bu onun parası değil. Başka kimsenin özel anahtarını bilmiyor ve mesajın kilidini açabilecek özel anahtar yalnızca mesajın alıcısına sahiptir. Yani kimse dinlemek, parayı kimin aldığını çok daha az belirleyebilir.
halka açık Özel Alice Carol Tek kullanımlık anahtar Tek kullanımlık anahtar Tek kullanımlık anahtar Bob Bob'un Anahtarı Bob'un Adresi Şekil 3. CryptoNote anahtarları/işlem modeli. İlk olarak gönderen, verilerinden paylaşılan bir sır elde etmek için bir Diffe-Hellman alışverişi gerçekleştirir ve alıcının adresinin yarısı. Daha sonra paylaşılan anahtarı kullanarak tek seferlik bir hedef anahtarı hesaplar. gizli ve adresin ikinci yarısı. Alıcıdan iki farklı ec-anahtarı isteniyor Bu iki adım için standart bir CryptoNote adresi, Bitcoin cüzdanının neredeyse iki katı büyüklüğündedir. adresi. Alıcı ayrıca karşılık gelen verileri kurtarmak için bir Diffe-Hellman değişimi gerçekleştirir. gizli anahtar. Standart bir işlem sırası şu şekildedir: 1. Alice, standart adresini yayınlayan Bob'a ödeme göndermek istiyor. O adresi açar ve Bob'un genel anahtarını (A, B) alır. 2. Alice rastgele bir \(r \in [1, l - 1]\) üretir ve bir kerelik genel anahtarı \(P = H_s(rA)G +\) hesaplar B. 3. Alice, çıktı için hedef anahtar olarak P'yi kullanır ve aynı zamanda R = rG değerini de paketler (bir parça olarak) Diffe-Hellman borsasının) işlemin bir yerinde. oluşturabileceğini unutmayın. benzersiz ortak anahtarlara sahip diğer çıktılar: farklı alıcıların anahtarları (Ai, Bi) farklı Pi anlamına gelir aynı r ile bile. İşlem Tx ortak anahtarı Gönderim çıkışı Tutar Hedef anahtarı R = rG P = Hs(rA)G + B Alıcının genel anahtar Gönderenin rastgele verileri r (A, B) Şekil 4. Standart işlem yapısı. 4. Alice işlemi gönderir. 5. Bob geçen her işlemi özel anahtarıyla (a, b) kontrol eder ve P ′ = değerini hesaplar Hs(aR)G + B. Alice'in alıcı olarak Bob'la yaptığı işlem bunların arasındaysa, o zaman aR = arG = rA ve P ′ = P. 7 halka açık Özel Alice Carol Tek kullanımlık anahtar Tek kullanımlık anahtar Tek kullanımlık anahtar Bob Bob'un Anahtarı Bob'un Adresi Şekil 3. CryptoNote anahtarları/işlem modeli. İlk olarak gönderen, verilerinden paylaşılan bir sır elde etmek için bir Diffe-Hellman alışverişi gerçekleştirir ve alıcının adresinin yarısı. Daha sonra paylaşılan anahtarı kullanarak tek seferlik bir hedef anahtarı hesaplar. gizli ve adresin ikinci yarısı. Alıcıdan iki farklı ec-anahtarı isteniyor bu iki adım için standart bir CryptoNote adresi, Bitcoin cüzdanının neredeyse iki katı kadardır. adresi. Alıcı ayrıca karşılık gelen verileri kurtarmak için bir Diffe-Hellman değişimi gerçekleştirir. gizli anahtar. Standart bir işlem sırası şu şekildedir: 1. Alice, standart adresini yayınlayan Bob'a ödeme göndermek istiyor. O adresi açar ve Bob'un genel anahtarını (A, B) alır. 2. Alice rastgele bir \(r \in [1, l - 1]\) üretir ve bir kerelik genel anahtarı \(P = H_s(rA)G +\) hesaplar B. 3. Alice, çıktı için hedef anahtar olarak P'yi kullanır ve aynı zamanda R = rG değerini de paketler (bir parça olarak) Diffe-Hellman borsasının) işlemin bir yerinde. oluşturabileceğini unutmayın. benzersiz ortak anahtarlara sahip diğer çıktılar: farklı alıcıların anahtarları (Ai, Bi) farklı Pi anlamına gelir aynı r ile bile. İşlem Tx ortak anahtarı Gönderim çıkışı Tutar Hedef anahtarı R = rG P = Hs(rA)G + B Alıcının genel anahtar Gönderenin rastgele verileri r (A, B) Şekil 4. Standart işlem yapısı. 4. Alice işlemi gönderir. 5. Bob geçen her işlemi özel anahtarıyla (a, b) kontrol eder ve P ′ = değerini hesaplar Hs(aR)G + B. Alice'in alıcı olarak Bob'la yaptığı işlem bunların arasındaysa, o zaman aR = arG = rA ve P ′ = P. 7 13 Kriptografi seçeneğini uygulamanın ne kadar büyük bir acı olacağını merak ediyorum. şeması. Eliptik veya başka türlü. Yani gelecekte bir plan bozulursa para birimi değişir endişelenmeden. Muhtemelen büyük bir baş ağrısı. Tamam, bu tam olarak önceki yorumumda açıkladığım şey. Diffe-Hellman tipi takaslar gayet düzgün. Alex ve Brenda'nın her birinin gizli bir numarası, A ve B'si ve bir numarası olduğunu varsayalım. sır saklamayı umursamıyorlar, a ve b. Paylaşılan bir sır oluşturmak istiyorlar Eva bunu keşfediyor. Diffe ve Hellman, Alex ve Brenda'nın bu durumu paylaşması için bir yol buldular. genel numaralar a ve b, ancak özel numaralar A ve B değil ve paylaşılan bir sır oluşturur, K. Bu paylaşılan sırrı kullanarak, K, Eva'nın dinlemesine gerek kalmadan aynı şeyi üretebilir. K, Alex ve Brenda artık K'yi gizli bir şifreleme anahtarı olarak kullanabilir ve gizli mesajları geri iletebilir ve ileri. 100'den çok daha büyük sayılarla çalışması gerekmesine rağmen CAN şu şekilde çalışır. 100'ü kullanacağız çünkü modulo 100 tamsayıları üzerinde çalışmak "hepsini atmak" ile eşdeğerdir ama bir sayının son iki rakamı." Alex ve Brenda'nın her biri A, a, B ve b'yi seçiyor. A ve B'yi gizli tutuyorlar. Alex, Brenda'ya modulo 100'ün değerini (yalnızca son iki rakam) söyler ve Brenda, Alex'e söyler. b modulo 100'ün değeri. Artık Eva (a,b) modulo 100'ü biliyor. Ama Alex (a,b,A)'yı biliyor, dolayısıyla o x=abA modulo 100'ü hesaplayabilir.Alex çalıştığımız için son rakam hariç hepsini kesiyor tekrar modulo 100 tamsayılarının altında. Benzer şekilde, Brenda da (a,b,B)'yi bildiğinden hesaplayabilmektedir. y=abB modulo 100. Alex artık x'i yayınlayabilir ve Brenda da y'yi yayınlayabilir. Ama şimdi Alex yA = abBA modulo 100'ü hesaplayabiliyor ve Brenda da xB'yi hesaplayabiliyor = abBA modulo 100. İkisi de aynı numarayı biliyor! Ama Eva'nın tek duyduğu şey (a,b,abA,abB). abA*B'yi hesaplamanın kolay bir yolu yok. Diffe-Hellman değişimi hakkında düşünmenin en kolay ve en az güvenli yolu bu. Daha güvenli versiyonlar mevcut. Ancak çoğu sürüm, tamsayı çarpanlarına ayırma ve ayrıklık nedeniyle çalışır. logaritmalar zordur ve bu sorunların her ikisi de kuantum bilgisayarlar tarafından kolaylıkla çözülebilir. Kuantuma dirençli versiyonların olup olmadığına bakacağım. http://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange Burada listelenen "standart txn dizisi"nde, İMZALAR gibi birçok adım eksik. Burada olduğu gibi kabul ediliyorlar. Bu gerçekten kötü, çünkü içinde bulunduğumuz sıra imza maddeleri, imzalı mesajın içerdiği bilgiler vb... bunların hepsi son derece protokol için önemlidir. Uygulama sırasında adımlardan bir veya ikisinin yanlış, hatta biraz bozuk olması standart işlem sırası" tüm sistemin güvenliğini sorgulayabilir. Ayrıca, makalede daha sonra sunulan kanıtlar yeterince kesin olmayabilir. altında çalıştıkları çerçeve bu bölümde olduğu gibi gevşek bir şekilde tanımlanmıştır.
halka açık Özel Alice Carol Tek kullanımlık anahtar Tek kullanımlık anahtar Tek kullanımlık anahtar Bob Bob'un Anahtarı Bob'un Adresi Şekil 3. CryptoNote anahtarları/işlem modeli. İlk olarak gönderen, verilerinden paylaşılan bir sır elde etmek için bir Diffe-Hellman alışverişi gerçekleştirir ve alıcının adresinin yarısı. Daha sonra paylaşılan anahtarı kullanarak tek seferlik bir hedef anahtarı hesaplar. gizli ve adresin ikinci yarısı. Alıcıdan iki farklı ec-anahtarı isteniyor bu iki adım için standart bir CryptoNote adresi, Bitcoin cüzdanının neredeyse iki katı kadardır. adresi. Alıcı ayrıca karşılık gelen verileri kurtarmak için bir Diffe-Hellman değişimi gerçekleştirir. gizli anahtar. Standart bir işlem sırası şu şekildedir: 1. Alice, standart adresini yayınlayan Bob'a ödeme göndermek istiyor. O adresi açar ve Bob'un genel anahtarını (A, B) alır. 2. Alice rastgele bir \(r \in [1, l - 1]\) üretir ve bir kerelik genel anahtarı \(P = H_s(rA)G +\) hesaplar B. 3. Alice, çıktı için hedef anahtar olarak P'yi kullanır ve aynı zamanda R = rG değerini de paketler (bir parça olarak) Diffe-Hellman borsasının) işlemin bir yerinde. oluşturabileceğini unutmayın. benzersiz ortak anahtarlara sahip diğer çıktılar: farklı alıcıların anahtarları (Ai, Bi) farklı Pi anlamına gelir aynı r ile bile. İşlem Tx ortak anahtarı Gönderim çıkışı Tutar Hedef anahtarı R = rG P = Hs(rA)G + B Alıcının genel anahtar Gönderenin rastgele verileri r (A, B) Şekil 4. Standart işlem yapısı. 4. Alice işlemi gönderir. 5. Bob geçen her işlemi özel anahtarıyla (a, b) kontrol eder ve P ′ = değerini hesaplar Hs(aR)G + B. Alice'in alıcı olarak Bob'la yaptığı işlem bunların arasındaysa, o zaman aR = arG = rA ve P ′ = P. 7 halka açık Özel Alice Carol Tek kullanımlık anahtar Tek kullanımlık anahtar Tek kullanımlık anahtar Bob Bob'un Anahtarı Bob'un Adresi Şekil 3. CryptoNote anahtarları/işlem modeli. İlk olarak gönderen, verilerinden paylaşılan bir sır elde etmek için bir Diffe-Hellman alışverişi gerçekleştirir ve alıcının adresinin yarısı. Daha sonra paylaşılan anahtarı kullanarak tek seferlik bir hedef anahtarı hesaplar. gizli ve adresin ikinci yarısı. Alıcıdan iki farklı ec-anahtarı isteniyor bu iki adım için standart bir CryptoNote adresi, Bitcoin cüzdanının neredeyse iki katı kadardır. adresi. Alıcı ayrıca karşılık gelen verileri kurtarmak için bir Diffe-Hellman değişimi gerçekleştirir. gizli anahtar. Standart bir işlem sırası şu şekildedir: 1. Alice, standart adresini yayınlayan Bob'a ödeme göndermek istiyor. O adresi açar ve Bob'un genel anahtarını (A, B) alır. 2. Alice rastgele bir \(r \in [1, l - 1]\) üretir ve bir kerelik genel anahtarı \(P = H_s(rA)G +\) hesaplar B. 3. Alice, çıktı için hedef anahtar olarak P'yi kullanır ve aynı zamanda R = rG değerini de paketler (bir parça olarak) Diffe-Hellman borsasının) işlemin bir yerinde. oluşturabileceğini unutmayın. benzersiz ortak anahtarlara sahip diğer çıktılar: farklı alıcıların anahtarları (Ai, Bi) farklı Pi anlamına gelir aynı r ile bile. İşlem Tx ortak anahtarı Gönderim çıkışı Tutar Hedef anahtarı R = rG P = Hs(rA)G + B Alıcının genel anahtar Gönderenin rastgele verileri r (A, B) Şekil 4. Standart işlem yapısı. 4. Alice işlemi gönderir. 5. Bob geçen her işlemi özel anahtarıyla (a, b) kontrol eder ve P ′ = değerini hesaplar Hs(aR)G + B. Alice'in alıcı olarak Bob'la yaptığı işlem bunların arasındaysa, o zaman aR = arG = rA ve P ′ = P. 7 14 Yazar(lar)ın baştan sona terminolojilerini düz tutmak konusunda berbat bir iş çıkardıklarını unutmayın. metin, ama özellikle bu sonraki kısımda. Bu makalenin bir sonraki enkarnasyonu mutlaka olacaktır. çok daha titiz. Metinde P'den tek kullanımlık genel anahtar olarak bahsediyorlar. Diyagramda R'ye şu şekilde atıfta bulunurlar: "Tx genel anahtarı" ve "Hedef anahtarı" olarak P. Eğer bunu yeniden yazacak olsaydım, Bu bölümleri tartışmadan önce bazı terminolojiyi çok spesifik olarak ortaya koyacağım. Bu cehennem çok büyük. 5. sayfaya bakın. Ell'i kim seçer? Diyagram, rastgele ve seçilen işlem genel anahtarı R = rG'yi göstermektedir. gönderen tarafından Tx çıkışının bir parçası değildir. Bunun nedeni birden fazla kişi için aynı olabilmesidir. birden fazla kişiye yapılan işlemlerdir ve harcamak için SONRA kullanılmaz. Yeni bir R üretilir her yeni CryptoNote işlemini yayınlamak istediğinizde. Ayrıca, R yalnızca kullanılır İşlemin alıcısı olup olmadığınızı kontrol etmek için. Bunlar önemsiz veriler değil, ancak herkes için önemsizdir (A,B) ile ilişkili özel anahtarlar olmadan. Hedef tuşu ise P = Hs(rA)G + B, Tx çıkışının bir parçasıdır. Herkes Her geçen işlemin verilerini inceleyerek kendi oluşturdukları P*'yi kontrol etmelidir. Bu geçen işlemin sahibi olup olmadıklarını görmek için bu P'yi kullanın. Harcanmamış işlem çıktısı olan herkes (UTXO) bu P'lerden bir demetini ortalıkta miktarlarla birlikte bulunduracak. Harcamak içind, onlar P'nin de dahil olduğu yeni bir mesaj imzalayın. Alice, bu işlemi, harcanmamış işlem çıktısı/çıktıları Hedef Anahtarı/Anahtarları ile ilişkili bir kerelik özel anahtar/anahtarlarla imzalamalıdır. Alice'in sahip olduğu her hedef anahtarı donanımlı olarak gelir (muhtemelen) Alice'e ait olan tek seferlik özel anahtarla. Alice her istediğinde hedef anahtarının içeriğini bana veya Bob'a veya Brenda'ya veya Charlie'ye veya Charlene'e gönder, o işlemi imzalamak için özel anahtarını kullanır. İşlemi aldıktan sonra yeni bir tane alacağım Tx genel anahtarı, yeni bir Hedef ortak anahtarı ve yeni bir kerelik özel anahtar x'i kurtarabileceğim. Tek kullanımlık özel anahtarım x'i yeni işlemin genel Hedefi ile birleştirme anahtar(lar) yeni bir işlemi nasıl gönderdiğimizdir
- Bob karşılık gelen bir kerelik özel anahtarı kurtarabilir: x = Hs(aR) + b, yani P = xG. Bu çıktıyı istediği zaman x ile bir işlem imzalayarak harcayabilir. İşlem Tx ortak anahtarı Gönderim çıkışı Tutar Hedef anahtarı P ′ = Hs(aR)G + bG tek kullanımlık genel anahtar x = Hs(aR) + b tek kullanımlık özel anahtar Alıcının özel anahtar (a, b) R P' ?= P Şekil 5. Gelen işlem kontrolü. Sonuç olarak Bob, tek seferlik ortak anahtarlarla ilişkili gelen ödemeleri alır. izleyici için bağlanılamaz. Bazı ek notlar: • Bob işlemlerini "tanıdığında" (bkz. adım 5) pratikte parasının yalnızca yarısını kullanır. Özel bilgiler: (a, B). İzleme anahtarı olarak da bilinen bu çift, iletilebilir üçüncü bir tarafa (Carol). Bob, yeni işlemlerin işlenmesi konusunda ona yetki verebilir. Bob Carol'a açıkça güvenmesine gerek yok çünkü tek seferlik gizli anahtarı kurtaramıyor Bob'un tam özel anahtarı (a, b) olmadan. Bu yaklaşım Bob'un bant genişliğinin yetersiz olduğu durumlarda faydalıdır veya hesaplama gücü (akıllı telefonlar, donanım cüzdanları vb.). • Alice, Bob'un adresine bir işlem gönderdiğini kanıtlamak isterse bunu açıklayabilir r veya r'yi bildiğini kanıtlamak için herhangi bir tür sıfır bilgi protokolü kullanın (örneğin imzalayarak) r) ile yapılan işlem. • Bob, gelen tüm işlemlerin kaydedildiği denetim uyumlu bir adrese sahip olmak istiyorsa bağlanabilirse, izleme anahtarını yayınlayabilir veya kısaltılmış bir adres kullanabilir. Bu adres yalnızca bir genel ec-anahtarı B'yi temsil eder ve protokolün gerektirdiği geri kalan kısım bundan şu şekilde türetilir: a = Hs(B) ve A = Hs(B)G. Her iki durumda da her insan Bob'un gelen tüm işlemlerini "tanıyabilir", ancak elbette hiçbiri bu parayı harcayamaz. gizli anahtar olmadan içlerinde yer alan fonlar b. 4.4 Tek seferlik zil imzaları Tek seferlik halka imzalara dayalı bir protokol, kullanıcıların koşulsuz bağlantı kurulamazlığına erişmesine olanak tanır. Ne yazık ki, sıradan kriptografik imza türleri, işlemlerin ilgili gönderici ve alıcılar. Bu eksikliğe çözümümüz farklı bir imza kullanmaktan geçiyor Şu anda elektronik nakit sistemlerinde kullanılanlardan daha fazla tür. Öncelikle algoritmamızın genel bir tanımını, açık bir referans olmadan sunacağız. elektronik nakit. Bir kerelik halka imzası dört algoritma içerir: (GEN, SIG, VER, LNK): GEN: genel parametreleri alır ve bir ec çifti (P, x) ve bir genel anahtar I çıkarır. SIG: bir m mesajını, {Pi}i̸=s genel anahtarlarından oluşan bir \(S'\) kümesini, bir çifti (Ps, xs) alır ve bir \(\sigma\) imzası çıkarır ve bir \(S = \)S'\( \cup \{P_s\}\) kümesi. 8
-
Bob karşılık gelen bir kerelik özel anahtarı kurtarabilir: x = Hs(aR) + b, yani P = xG. Bu çıktıyı istediği zaman x ile bir işlem imzalayarak harcayabilir. İşlem Tx ortak anahtarı Gönderim çıkışı Tutar Hedef anahtarı P ′ = Hs(aR)G + bG tek kullanımlık genel anahtar x = Hs(aR) + b tek kullanımlık özel anahtar Alıcının özel anahtar (a, b) R P' ?= P Şekil 5. Gelen işlem kontrolü. Sonuç olarak Bob, tek seferlik ortak anahtarlarla ilişkili gelen ödemeleri alır. izleyici için bağlanılamaz. Bazı ek notlar: • Bob işlemlerini "tanıdığında" (bkz. adım 5) pratikte parasının yalnızca yarısını kullanır. Özel bilgiler: (a, B). İzleme anahtarı olarak da bilinen bu çift, iletilebilir üçüncü bir tarafa (Carol). Bob, yeni işlemlerin işlenmesi konusunda ona yetki verebilir. Bob Carol'a açıkça güvenmesine gerek yok çünkü tek seferlik gizli anahtarı kurtaramıyor Bob'un tam özel anahtarı (a, b) olmadan. Bu yaklaşım Bob'un bant genişliğinin yetersiz olduğu durumlarda faydalıdır veya hesaplama gücü (akıllı telefonlar, donanım cüzdanları vb.). • Alice, Bob'un adresine bir işlem gönderdiğini kanıtlamak isterse bunu açıklayabilir r veya r'yi bildiğini kanıtlamak için herhangi bir tür sıfır bilgi protokolü kullanın (örneğin imzalayarak) r) ile yapılan işlem. • Bob, gelen tüm işlemlerin kaydedildiği denetim uyumlu bir adrese sahip olmak istiyorsa bağlanabilirse, izleme anahtarını yayınlayabilir veya kısaltılmış bir adres kullanabilir. Bu adres yalnızca bir genel ec-anahtarı B'yi temsil eder ve protokolün gerektirdiği geri kalan kısım bundan şu şekilde türetilir: a = Hs(B) ve A = Hs(B)G. Her iki durumda da her insan Bob'un gelen tüm işlemlerini "tanıyabilir", ancak elbette hiçbiri bu parayı harcayamaz. gizli anahtar olmadan içlerinde yer alan fonlar b. 4.4 Tek seferlik zil imzaları Tek seferlik halka imzalara dayalı bir protokol, kullanıcıların koşulsuz bağlantı kurulamazlığına erişmesine olanak tanır. Ne yazık ki, sıradan kriptografik imza türleri, işlemlerin ilgili gönderici ve alıcılar. Bu eksikliğe çözümümüz farklı bir imza kullanmaktan geçiyor Şu anda elektronik nakit sistemlerinde kullanılanlardan daha fazla tür. İlk önce bir gen sağlayacağızaçık bir referans olmadan algoritmamızın tüm açıklaması elektronik nakit. Bir kerelik halka imzası dört algoritma içerir: (GEN, SIG, VER, LNK): GEN: genel parametreleri alır ve bir ec çifti (P, x) ve bir genel anahtar I çıkarır. SIG: bir m mesajını, {Pi}i̸=s genel anahtarlarından oluşan bir \(S'\) kümesini, bir çifti (Ps, xs) alır ve bir \(\sigma\) imzası çıkarır ve bir \(S = \)S'\( \cup \{P_s\}\) kümesi. 8 15 Harcanmamış bir işlem çıktısı burada nasıl görünüyor? Diyagram, işlem çıktısının yalnızca iki veri noktasından oluştuğunu göstermektedir: miktar ve hedef anahtar. Ama bu değil Yeterli çünkü bu "çıktıyı" harcamaya çalıştığımda hala R=rG'yi bilmem gerekecek. Unutmayın, r gönderen tarafından seçilir ve R a) gelen kriptonotları sizin şifreniz olarak tanımak için kullanılır. kendi ve b) kriptonotunuzu "talep etmek" için kullanılan tek seferlik özel anahtarı oluşturmak için kullanılır. Bu konuda anlamadığım kısım? Teorik olarak "tamam, elimizde bunlar var imzalar ve işlemler ve bunları programlama dünyasına ileri geri aktarıyoruz "peki özellikle hangi bilgiler bir kişiyi UTXO oluşturur?" Bu soruyu cevaplamanın en iyi yolu, tamamen yorumlanmamış kodun gövdesini incelemektir. Tebrikler bytecoin ekibi. Hatırlayın: bağlanabilirlik "aynı kişi mi gönderdi?" anlamına gelir. ve bağlantı kurulamazlık "aynısını yaptım" anlamına gelir kişi alıyor mu?" Dolayısıyla bir sistem bağlanabilir veya bağlanamaz, bağlanamaz veya bağlanamaz olabilir. Sinir bozucu, biliyorum. Nic van Saberhagen burada "...gelen ödemeler tek seferlik ödemelerle ilişkilidir" dediğinde İzleyici için bağlantı kurulamayan genel anahtarlar" derken ne demek istediğini görelim. İlk olarak, Alice'in Bob'a aynı yerden iki ayrı işlem gönderdiği bir durumu düşünün. adresi aynı adrese. Bitcoin evreninde Alice zaten hatayı yaptı aynı adresten gönderim yapılması nedeniyle sınırlı işlem isteğimiz başarısız oldu bağlanabilirlik. Üstelik parayı aynı adrese gönderdiği için isteğimizi boşa çıkardı bağlantı kurulamazlığı için. Bu bitcoin işlemi hem (tamamen) bağlanabilir hem de bağlantısı kaldırılamaz nitelikteydi. Öte yandan kriptonot evreninde Alice'in Bob'a bir kriptonot gönderdiğini varsayalım, Bob'un genel adresini kullanarak. Gizleyici ortak anahtarlar kümesi olarak bilinen tüm halka açık anahtarları seçiyor Washington DC metro bölgesindeki anahtarlar. Alex kendi anahtarını kullanarak tek seferlik bir genel anahtar üretiyor bilgiler ve Bob'un kamuya açık bilgileri. Parayı o gönderiyor ve herhangi bir gözlemci sadece "Washington DC metropol bölgesinden biri şu adrese 2,3 kriptonot gönderdi" tek seferlik genel adres XYZ123." Burada bağlanabilirlik üzerinde olasılıksal bir kontrolümüz var, dolayısıyla buna "neredeyse bağlantı kurulamaz" adını vereceğiz. Ayrıca paranın gönderildiği tek seferlik ortak anahtarları da görüyoruz. Alıcıdan şüphelensek bile Bob'du, onun özel anahtarlarına sahip değiliz ve bu nedenle geçen bir işlemin olup olmadığını test edemiyoruz bırakın kripto notunu kullanmak için tek seferlik özel anahtarını oluşturmayı bırakın Bob'a aittir. Yani bu aslında tamamen "bağlanamaz". Yani bu en güzel numaradır. Kim gerçekten başka bir MtGox'a güvenmek ister? Biz olabiliriz Bir miktar BTC'yi Coinbase'de depolamak rahattır, ancak bitcoin güvenliğinde son nokta fiziksel bir cüzdan. Bu da sakıncalı. Bu durumda, özel anahtarınızın yarısını, gizliliğinizi tehlikeye atmadan, güvenle verebilirsiniz. para harcamak için kendi yeteneği. Bunu yaparken yaptığınız tek şey birine bağlantısızlığın nasıl ortadan kaldırılacağını anlatmaktır. Diğeri CN'nin bir para birimi gibi davranan özellikleri korunur; çifte harcamaya karşı kanıt ve ne değil.
-
Bob karşılık gelen bir kerelik özel anahtarı kurtarabilir: x = Hs(aR) + b, yani P = xG. Bu çıktıyı istediği zaman x ile bir işlem imzalayarak harcayabilir. İşlem Tx ortak anahtarı Gönderim çıkışı Tutar Hedef anahtarı P ′ = Hs(aR)G + bG tek kullanımlık genel anahtar x = Hs(aR) + b tek kullanımlık özel anahtar Alıcının özel anahtar (a, b) R P' ?= P Şekil 5. Gelen işlem kontrolü. Sonuç olarak Bob, tek seferlik ortak anahtarlarla ilişkili gelen ödemeleri alır. izleyici için bağlanılamaz. Bazı ek notlar: • Bob işlemlerini "tanıdığında" (bkz. adım 5) pratikte parasının yalnızca yarısını kullanır. Özel bilgiler: (a, B). İzleme anahtarı olarak da bilinen bu çift, iletilebilir üçüncü bir tarafa (Carol). Bob, yeni işlemlerin işlenmesi konusunda ona yetki verebilir. Bob Carol'a açıkça güvenmesine gerek yok çünkü tek seferlik gizli anahtarı kurtaramıyor Bob'un tam özel anahtarı (a, b) olmadan. Bu yaklaşım Bob'un bant genişliğinin yetersiz olduğu durumlarda faydalıdır veya hesaplama gücü (akıllı telefonlar, donanım cüzdanları vb.). • Alice, Bob'un adresine bir işlem gönderdiğini kanıtlamak isterse bunu açıklayabilir r veya r'yi bildiğini kanıtlamak için herhangi bir tür sıfır bilgi protokolü kullanın (örneğin imzalayarak) r) ile yapılan işlem. • Bob, gelen tüm işlemlerin kaydedildiği denetim uyumlu bir adrese sahip olmak istiyorsa bağlanabilirse, izleme anahtarını yayınlayabilir veya kısaltılmış bir adres kullanabilir. Bu adres yalnızca bir genel ec-anahtarı B'yi temsil eder ve protokolün gerektirdiği geri kalan kısım bundan şu şekilde türetilir: a = Hs(B) ve A = Hs(B)G. Her iki durumda da her insan Bob'un gelen tüm işlemlerini "tanıyabilir", ancak elbette hiçbiri bu parayı harcayamaz. gizli anahtar olmadan içlerinde yer alan fonlar b. 4.4 Tek seferlik zil imzaları Tek seferlik halka imzalara dayalı bir protokol, kullanıcıların koşulsuz bağlantı kurulamazlığına erişmesine olanak tanır. Ne yazık ki, sıradan kriptografik imza türleri, işlemlerin ilgili gönderici ve alıcılar. Bu eksikliğe çözümümüz farklı bir imza kullanmaktan geçiyor Şu anda elektronik nakit sistemlerinde kullanılanlardan daha fazla tür. Öncelikle algoritmamızın genel bir tanımını, açık bir referans olmadan sunacağız. elektronik nakit. Bir kerelik halka imzası dört algoritma içerir: (GEN, SIG, VER, LNK): GEN: genel parametreleri alır ve bir ec çifti (P, x) ve bir genel anahtar I çıkarır. SIG: bir m mesajını, {Pi}i̸=s genel anahtarlarından oluşan bir \(S'\) kümesini, bir çifti (Ps, xs) alır ve bir \(\sigma\) imzası çıkarır ve bir \(S = \)S'\( \cup \{P_s\}\) kümesi. 8
- Bob karşılık gelen bir kerelik özel anahtarı kurtarabilir: x = Hs(aR) + b, yani P = xG. Bu çıktıyı istediği zaman x ile bir işlem imzalayarak harcayabilir. İşlem Tx ortak anahtarı Gönderim çıkışı Tutar Hedef anahtarı P ′ = Hs(aR)G + bG tek kullanımlık genel anahtar x = Hs(aR) + b tek kullanımlık özel anahtar Alıcının özel anahtar (a, b) R P' ?= P Şekil 5. Gelen işlem kontrolü. Sonuç olarak Bob, tek seferlik ortak anahtarlarla ilişkili gelen ödemeleri alır. izleyici için bağlanılamaz. Bazı ek notlar: • Bob işlemlerini "tanıdığında" (bkz. adım 5) pratikte parasının yalnızca yarısını kullanır. Özel bilgiler: (a, B). İzleme anahtarı olarak da bilinen bu çift, iletilebilir üçüncü bir tarafa (Carol). Bob, yeni işlemlerin işlenmesi konusunda ona yetki verebilir. Bob Carol'a açıkça güvenmesine gerek yok çünkü tek seferlik gizli anahtarı kurtaramıyor Bob'un tam özel anahtarı (a, b) olmadan. Bu yaklaşım Bob'un bant genişliğinin yetersiz olduğu durumlarda faydalıdır veya hesaplama gücü (akıllı telefonlar, donanım cüzdanları vb.). • Alice, Bob'un adresine bir işlem gönderdiğini kanıtlamak isterse bunu açıklayabilir r veya r'yi bildiğini kanıtlamak için herhangi bir tür sıfır bilgi protokolü kullanın (örneğin imzalayarak) r) ile yapılan işlem. • Bob, gelen tüm işlemlerin kaydedildiği denetim uyumlu bir adrese sahip olmak istiyorsa bağlanabilirse, izleme anahtarını yayınlayabilir veya kısaltılmış bir adres kullanabilir. Bu adres yalnızca bir genel ec-anahtarı B'yi temsil eder ve protokolün gerektirdiği geri kalan kısım bundan şu şekilde türetilir: a = Hs(B) ve A = Hs(B)G. Her iki durumda da her insan Bob'un gelen tüm işlemlerini "tanıyabilir", ancak elbette hiçbiri bu parayı harcayamaz. gizli anahtar olmadan içlerinde yer alan fonlar b. 4.4 Tek seferlik zil imzaları Tek seferlik halka imzalara dayalı bir protokol, kullanıcıların koşulsuz bağlantı kurulamazlığına erişmesine olanak tanır. Ne yazık ki, sıradan kriptografik imza türleri, işlemlerin ilgili gönderici ve alıcılar. Bu eksikliğe çözümümüz farklı bir imza kullanmaktan geçiyor Şu anda elektronik nakit sistemlerinde kullanılanlardan daha fazla tür. İlk önce bir gen sağlayacağızaçık bir referans olmadan algoritmamızın tüm açıklaması elektronik nakit. Bir kerelik halka imzası dört algoritma içerir: (GEN, SIG, VER, LNK): GEN: genel parametreleri alır ve bir ec çifti (P, x) ve bir genel anahtar I çıkarır. SIG: bir m mesajını, {Pi}i̸=s genel anahtarlarından oluşan bir \(S'\) kümesini, bir çifti (Ps, xs) alır ve bir \(\sigma\) imzası çıkarır ve bir \(S = \)S'\( \cup \{P_s\}\) kümesi. 8 16 Evet, artık a) bir ödeme adresimiz ve b) bir ödeme kimliğimiz var. Bir eleştirmen şunu sorabilir: "Bunu gerçekten yapmamız gerekiyor mu? Sonuçta, bir tüccar 112.00678952 alırsa Tam olarak CN, benim siparişim de buydu ve elimde ekran görüntüsü ya da makbuz falan var, değil mi çılgın derecede kesinlik yeterli mi?" Cevap şu: "Belki de çoğu zaman, günlük yaşamda, yüz yüze işlemler." Ancak (özellikle dijital dünyada) daha yaygın olan durum şudur: Bir tüccar, her biri sabit bir fiyata sahip olan bir dizi nesne. A nesnesinin 0,001 CN, B nesnesinin 0,01 CN olduğunu ve C nesnesi 0,1 CN'dir. Şimdi, eğer satıcı 1.618 CN tutarında bir sipariş alırsa, çok sayıda sipariş var. Bir müşteri için sipariş ayarlamanın (birçok!) yolu. Ve bir tür ödeme kimliği olmadan, Bir müşterinin sözde "benzersiz" siparişini, müşterilerinin sözde "benzersiz" maliyetiyle tanımlamak düzen imkansız hale gelir. Daha da komik: çevrimiçi mağazamdaki her şeyin maliyeti tam olarak 1,0 ise CN ve benim günde 1000 müşterim mi oluyor? Ve tam olarak 3 nesne satın aldığınızı kanıtlamak istiyorsunuz iki hafta önce mi? Ödeme kimliği olmadan mı? İyi şanslar dostum. Uzun lafın kısası: Bob bir ödeme adresi yayınladığında, aynı zamanda bir ödeme adresi de yayınlayabilir. ödeme kimliği de (bkz. örneğin Poloniex XMR para yatırma işlemleri). Bu anlatılandan farklı Buradaki metinde ödeme kimliğini oluşturan kişinin Alice olduğu yer almaktadır. Bob'un da bir ödeme kimliği oluşturmasının bir yolu olmalı. (a,B) İzleme anahtarının (a,B) yayınlanabileceğini hatırlayın; 'a'nın değerinin gizliliğini kaybetmek harcama yeteneğinizi ihlal etmeyin veya başkalarının sizden çalmasına izin vermeyin (sanırım... bu Kanıtlanacak), insanların gelen tüm işlemleri görmesine izin verecek. Bu paragrafta açıklandığı gibi kısaltılmış bir adres, anahtarın "özel" kısmını alır. ve onu "genel" kısımdan üretir. 'a'nın değerinin ortaya çıkarılması, bağlanamazlığı ortadan kaldıracaktır ancak işlemlerin geri kalanını koruyacaktır. Yazar "bağlantı kurulamaz" demek istiyor çünkü bağlantı kurulamaz alıcıyı ve bağlantı kurulabilir olanı ifade ediyor göndereni ifade eder. Ayrıca yazarın bağlanabilirliğin iki farklı yönü olduğunu fark etmediği de açıktır. Sonuçta işlem bir grafik üzerinde yönlendirilmiş bir nesne olduğundan iki soru ortaya çıkacaktır: "Bu iki işlem aynı kişiye mi gidiyor?" ve "bu iki işlem geliyor mu? aynı kişiden mi?" Bu, CryptoNote'un bağlantı kurulamazlık özelliğinin geçerli olduğu bir "geri dönmeme" politikasıdır. şartlı. Yani Bob, gelen işlemlerinin bağlantısının kesilemez olmasını seçebilir bu politikayı kullanarak. Bu, Rastgele Oracle Modeli kapsamında kanıtladıkları bir iddiadır. Buna ulaşacağız; Rastgele Oracle'ın artıları ve eksileri var.
VER: m mesajını, S kümesini, \(\sigma\) imzasını alır ve “doğru” veya “yanlış” çıktısını verir. LNK: bir I = {Ii} kümesini, bir \(\sigma\) imzasını alır ve "bağlantılı" veya "indep" çıktısını verir. Protokolün arkasındaki fikir oldukça basittir: Bir kullanıcı, imzalanabilecek bir imza üretir. benzersiz bir genel anahtar yerine bir dizi genel anahtarla kontrol edilir. İmzalayanın kimliği: sahibi üretinceye kadar ortak anahtarları sette bulunan diğer kullanıcılardan ayırt edilemez aynı anahtar çiftini kullanan ikinci bir imza. Özel anahtarlar x0 \(\cdots\) xi \(\cdots\) xn Genel anahtarlar P0 \(\cdots\) Pi \(\cdots\) Pn Yüzük İmza işaret doğrulamak Şekil 6. Halka imzasının anonimliği. GEN: İmzalayan kişi rastgele bir \(x \in [1, l - 1]\) gizli anahtarını seçer ve karşılık gelen değeri hesaplar. ortak anahtar P = xG. Ek olarak başka bir genel anahtar olan I = xHp(P)'yi de hesaplar. “anahtar resim” olarak adlandırın. SIG: İmzalayan, etkileşimli olmayan sıfır bilgiyle tek seferlik halka imza oluşturur [21] tekniklerini kullanarak kanıt. Diğer kullanıcıların arasından n'nin rastgele bir \(S'\) alt kümesini seçer. genel anahtarlar Pi, kendi anahtar çifti (x, P) ve anahtar görüntüsü I. İmzalayanın gizli dizini \(0 \leq s \leq n\) olsun \(S'\)de (ortak anahtarı Ps olacak şekilde). Rastgele bir {qi | ben = 0. . . n} ve {wi | ben = 0. . . (1 . . . l)'den n, i ̸= s} ve şunu uygular: aşağıdaki dönüşümler: Li = ( qiG, eğer ben = s qiG + wiPi, eğer ben ̸= s Ri = ( qiHp(Pi), eğer ben = s qiHp(Pi) + wiI, eğer ben ̸= s Bir sonraki adım etkileşimli olmayan mücadeleyi almaktır: c = Hs(m, L1, . . , Ln, R1, . . , Rn) Son olarak imzalayan kişi yanıtı hesaplar: ci = wi, eğer ben ̸= s c - nP ben=0 ci mod ben, eğer ben = s ri = ( qi, eğer ben ̸= s qs –csx mod l, eğer ben = s Sonuçta ortaya çıkan imza \(\sigma\) = (I, c1, . . , cn, r1, . . , rn) olur. 9 VER: m mesajını, S kümesini, \(\sigma\) imzasını alır ve “doğru” veya “yanlış” çıktısını verir. LNK: bir I = {Ii} kümesini, bir \(\sigma\) imzasını alır ve "bağlantılı" veya "indep" çıktısını verir. Protokolün arkasındaki fikir oldukça basittir: Bir kullanıcı, imzalanabilecek bir imza üretir. benzersiz bir genel anahtar yerine bir dizi genel anahtarla kontrol edilir. İmzalayanın kimliği: sahibi üretinceye kadar ortak anahtarları sette bulunan diğer kullanıcılardan ayırt edilemez aynı anahtar çiftini kullanan ikinci bir imza. Özel anahtarlar x0 \(\cdots\) xi \(\cdots\) xn Genel anahtarlar P0 \(\cdots\) Pi \(\cdots\) Pn Yüzük İmza işaret doğrulamak Şekil 6. Halka imzasının anonimliği. GEN: İmzalayan kişi rastgele bir \(x \in [1, l - 1]\) gizli anahtarını seçer ve karşılık gelen değeri hesaplar. ortak anahtar P = xG. Ek olarak başka bir genel anahtar olan I = xHp(P)'yi de hesaplar. “anahtar resim” olarak adlandırın. SIG: İmzalayan, etkileşimli olmayan sıfır bilgiyle tek seferlik halka imza oluşturur [21] tekniklerini kullanarak kanıt. Diğer kullanıcıların arasından n'nin rastgele bir \(S'\) alt kümesini seçer. genel anahtarlar Pi, kendi anahtar çifti (x, P) ve anahtar görüntüsü I. İmzalayanın gizli dizini \(0 \leq s \leq n\) olsun \(S'\)de (ortak anahtarı Ps olacak şekilde). Rastgele bir {qi | ben = 0. . . n} ve {wi | ben = 0. . . (1 . . . l)'den n, i ̸= s} ve şunu uygular: aşağıdaki dönüşümler: Li = ( qiG, eğer ben = s qiG + wiPi, eğer ben ̸= s Ri = ( qiHp(Pi), eğer ben = s qiHp(Pi) + wiI, eğer ben ̸= s Bir sonraki adım etkileşimli olmayan mücadeleyi almaktır: c = Hs(m, L1, . . , Ln, R1, . . , Rn) Son olarak imzalayan kişi yanıtı hesaplar: ci = wi, eğer ben ̸= s c - nP ben=0 ci mod l, eğer ben = s ri = ( qi, eğer ben ̸= s qs –csx mod l, eğer ben = s Sonuçta ortaya çıkan imza \(\sigma\) = (I, c1, . . , cn, r1, . . , rn) olur. 9 17 Belki bu aptalcadır, ancak S ve P_'leri birleştirirken dikkatli olunmalıdır. Eğer sadece şunu eklerseniz sona kadar olan son genel anahtar, herhangi biri geçen işlemleri kontrol ettiğinden bağlantı kurulamazlık bozuldu her işlemde ve patlamada listelenen son genel anahtarı kontrol edebilirsiniz. Bu genel anahtardır gönderenle ilişkilidir. Yani birleştirmeden sonra, bir sözde rasgele sayı üreteci oluşturulmalıdır. seçilen genel anahtarlara izin vermek için kullanılır. "...sahibi aynı anahtar çiftini kullanarak ikinci bir imza oluşturana kadar." Keşke yazar(lar?) bu konuyu detaylandıracaktı. Bunun şu anlama geldiğine inanıyorum: "Gizlenmek için bir dizi genel anahtar seçtiğinizde her zaman emin olun. Kendinize, iki anahtarın birbirine benzemediği tamamen yeni bir set seçersiniz." bağlantı kurulamaz duruma getirilecek oldukça güçlü bir durum. Belki "yeni bir rastgele set seçersiniz her ne kadar önemsiz olmayan kesişmeler kaçınılmaz olsa da, tüm olası anahtarlar" varsayımıyla olur, sık sık olmazlar. Her iki durumda da, bu ifadeyi daha derinlemesine incelemem gerekiyor. Bu, halka imzasını oluşturuyor. Sıfır bilgi kanıtları muhteşem: Bir sırrı bildiğinizi bana kanıtlamanız için size meydan okuyorum sırrını açıklamadan. Mesela çörek şeklinde bir mağaranın girişinde olduğumuzu varsayalım. ve mağaranın arka tarafında (girişin görülemeyeceği yerde) bir o vardır.hangi yöne giden kapı anahtarın sende olduğunu iddia et. Bir yöne gidersen her zaman geçmene izin verir, ama diğer yöne gidersen diğer yönde ise bir anahtara ihtiyacınız var. Ama bırakın anahtarı bana göstermek bile istemiyorsunuz bana kapıyı açtığını göster. Ama sen bana kapıyı nasıl açacağını bildiğini kanıtlamak istiyorsun. kapı. İnteraktif ortamda yazı tura atıyorum. Yazılar sola, yazılar sağa ve aşağıya iniyorsunuz madeni para sizi nereye yönlendirirse yönlendirsin, çörek şeklindeki mağara. Arkada, görüş alanımın ötesinde, sen diğer tarafa dönmek için kapıyı açın. Yazı-tura atma deneyini tekrarlıyoruz Anahtarın sende olduğundan emin olana kadar. Ancak bu açıkça ETKİLEŞİMLİ sıfır bilgi kanıtıdır. Sizin ve benim hiçbir zaman iletişim kurmak zorunda olmadığımız, etkileşimli olmayan versiyonlar da var; bu şekilde kulak misafiri olan kimse müdahale edemez. http://en.wikipedia.org/wiki/Zero-knowledge_proof Bu önceki tanımın tersidir.
VER: m mesajını, S kümesini, \(\sigma\) imzasını alır ve “doğru” veya “yanlış” çıktısını verir. LNK: bir I = {Ii} kümesini, bir \(\sigma\) imzasını alır ve "bağlantılı" veya "indep" çıktısını verir. Protokolün arkasındaki fikir oldukça basittir: Bir kullanıcı, imzalanabilecek bir imza üretir. benzersiz bir genel anahtar yerine bir dizi genel anahtarla kontrol edilir. İmzalayanın kimliği: sahibi üretinceye kadar ortak anahtarları sette bulunan diğer kullanıcılardan ayırt edilemez aynı anahtar çiftini kullanan ikinci bir imza. Özel anahtarlar x0 \(\cdots\) xi \(\cdots\) xn Genel anahtarlar P0 \(\cdots\) Pi \(\cdots\) Pn Yüzük İmza işaret doğrulamak Şekil 6. Halka imzasının anonimliği. GEN: İmzalayan kişi rastgele bir \(x \in [1, l - 1]\) gizli anahtarını seçer ve karşılık gelen değeri hesaplar. ortak anahtar P = xG. Ek olarak başka bir genel anahtar olan I = xHp(P)'yi de hesaplar. “anahtar resim” olarak adlandırın. SIG: İmzalayan, etkileşimli olmayan sıfır bilgiyle tek seferlik halka imza oluşturur [21] tekniklerini kullanarak kanıt. Diğer kullanıcıların arasından n'nin rastgele bir \(S'\) alt kümesini seçer. genel anahtarlar Pi, kendi anahtar çifti (x, P) ve anahtar görüntüsü I. İmzalayanın gizli dizini \(0 \leq s \leq n\) olsun \(S'\)de (ortak anahtarı Ps olacak şekilde). Rastgele bir {qi | ben = 0. . . n} ve {wi | ben = 0. . . (1 . . . l)'den n, i ̸= s} ve şunu uygular: aşağıdaki dönüşümler: Li = ( qiG, eğer ben = s qiG + wiPi, eğer ben ̸= s Ri = ( qiHp(Pi), eğer ben = s qiHp(Pi) + wiI, eğer ben ̸= s Bir sonraki adım etkileşimli olmayan mücadeleyi almaktır: c = Hs(m, L1, . . , Ln, R1, . . , Rn) Son olarak imzalayan kişi yanıtı hesaplar: ci = wi, eğer ben ̸= s c - nP ben=0 ci mod l, eğer ben = s ri = ( qi, eğer ben ̸= s qs –csx mod l, eğer ben = s Sonuçta ortaya çıkan imza \(\sigma\) = (I, c1, . . , cn, r1, . . , rn) olur. 9 VER: m mesajını, S kümesini, \(\sigma\) imzasını alır ve “doğru” veya “yanlış” çıktısını verir. LNK: bir I = {Ii} kümesini, bir \(\sigma\) imzasını alır ve "bağlantılı" veya "indep" çıktısını verir. Protokolün arkasındaki fikir oldukça basittir: Bir kullanıcı, imzalanabilecek bir imza üretir. benzersiz bir genel anahtar yerine bir dizi genel anahtarla kontrol edilir. İmzalayanın kimliği: sahibi üretinceye kadar ortak anahtarları sette bulunan diğer kullanıcılardan ayırt edilemez aynı anahtar çiftini kullanan ikinci bir imza. Özel anahtarlar x0 \(\cdots\) xi \(\cdots\) xn Genel anahtarlar P0 \(\cdots\) Pi \(\cdots\) Pn Yüzük İmza işaret doğrulamak Şekil 6. Halka imzasının anonimliği. GEN: İmzalayan kişi rastgele bir \(x \in [1, l - 1]\) gizli anahtarını seçer ve karşılık gelen değeri hesaplar. ortak anahtar P = xG. Ek olarak başka bir genel anahtar olan I = xHp(P)'yi de hesaplar. “anahtar resim” olarak adlandırın. SIG: İmzalayan, etkileşimli olmayan sıfır bilgiyle tek seferlik halka imza oluşturur [21] tekniklerini kullanarak kanıt. Diğer kullanıcıların arasından n'nin rastgele bir \(S'\) alt kümesini seçer. genel anahtarlar Pi, kendi anahtar çifti (x, P) ve anahtar görüntüsü I. İmzalayanın gizli dizini \(0 \leq s \leq n\) olsun \(S'\)de (ortak anahtarı Ps olacak şekilde). Rastgele bir {qi | ben = 0. . . n} ve {wi | ben = 0. . . (1 . . . l)'den n, i ̸= s} ve şunu uygular: aşağıdaki dönüşümler: Li = ( qiG, eğer ben = s qiG + wiPi, eğer ben ̸= s Ri = ( qiHp(Pi), eğer ben = s qiHp(Pi) + wiI, eğer ben ̸= s Bir sonraki adım etkileşimli olmayan mücadeleyi almaktır: c = Hs(m, L1, . . , Ln, R1, . . , Rn) Son olarak imzalayan kişi yanıtı hesaplar: ci = wi, eğer ben ̸= s c - nP ben=0 ci mod l, eğer ben = s ri = ( qi, eğer ben ̸= s qs –csx mod l, eğer ben = s Sonuçta ortaya çıkan imza \(\sigma\) = (I, c1, . . , cn, r1, . . , rn) olur. 9 18 Tüm bu alan kriptonottan bağımsızdır, halka imza algoritmasını basitçe tanımlar. para birimlerine referans. Bazı notasyonların makalenin geri kalanıyla tutarlı olduğundan şüpheleniyorum. yine de. Örneğin x, GEN'de seçilen ve P genel anahtarını veren "rastgele" gizli anahtardır. ve genel anahtar görüntüsü I. X'in bu değeri Bob'un bölüm 6, sayfa 8'de hesapladığı değerdir. Önceki açıklamadaki bazı karışıklıkları gidermeye başlıyoruz. Bu çok hoş; "Alice'in genel adresinden Bob'un genel adresine para aktarılmıyor Adres." Tek kullanımlık adresten tek kullanımlık adrese aktarılıyor. Yani bir bakıma işler şu şekilde yürüyor. Eğer Alex'in bazı kriptonotları varsa çünkü birisi bunları ona gönderdiyse bu, bunları Bob'a göndermek için gereken özel anahtarlara sahip olduğu anlamına gelir. O kullanıyor yeni bir tek seferlik adres oluşturmak için Bob'un kamuya açık bilgilerini kullanan bir Diffe-Hellman alışverişi ve kriptonotlar bu adrese aktarılır. Şimdi, yeni tek seferlik adresi oluşturmak için (muhtemelen güvenli) bir DH değişimi kullanıldığı için Alex'in CN'sini gönderdiği yerde, mesajı tekrarlamak için gereken özel anahtarlara sahip olan tek kişi Bob'tur. yukarıda. Artık Bob Alex oldu. http://en.wikipedia.org/wiki/Piecewise#Notation_and_interpretation Toplama i yerine j üzerinden indekslenmelidir. Her c_i rastgele önemsizdir (w_i rastgele olduğundan) c_i eşek hariçBu imzada yer alan gerçek anahtarla bağlantılıdır. c'nin değeri önceki bilgilerin hash'u. Bunun 'i' indeksini yeniden kullanmaktan daha kötü bir yazım hatası içerebileceğini düşünüyorum çünkü c_s görünüyor açıkça değil, örtülü olarak tanımlanmalıdır. Aslında bu denklemi güvenerek alırsak c_s = (1/2)c - (1/2) olduğunu tespit ederiz. toplam_i neq s c_i. Yani, bir hash eksi bir grup rastgele sayı. Öte yandan bu toplamın okunması amaçlanıyorsa "c_s = (c - sum_j neq s c_j) mod" l", sonra önceki bilgilerimizin hash değerini alırız, bir grup rastgele sayı üretiriz, tüm bu rastgele sayıları hash'den çıkarırız ve bu bize c_s'yi verir. Bu öyle görünüyor sezgilerime göre ne "olması gerektiği" ve sayfa 10'daki doğrulama adımıyla eşleştiği. Ancak sezgi matematik değildir. Bu konuyu daha derinlemesine inceleyeceğim. Daha önce olduğu gibi; gerçek olayla ilişkili olanlar dışında bunların tümü rastgele önemsiz olacaktır. imzalayanın genel anahtarı x. Bu seferki hariç, yapıdan beklediğim şey daha fazlası: r_i, i!=s için rastgeledir ve r_s, yalnızca gizli x ve s-indeksli değerleri tarafından belirlenir. q_i ve c_i.
VER: Doğrulayıcı, ters dönüşümleri uygulayarak imzayı kontrol eder: ( L' i = riG + ciPi R' i = riHp(Pi) + ciI Son olarak, doğrulayıcı şunları kontrol eder: nP ben=0 ci ?= Hs(m, L' 0, . . . , L' n, R' 0, . . . , R' n) mod l Bu eşitlik doğruysa, doğrulayıcı LNK algoritmasını çalıştırır. Aksi takdirde doğrulayıcı reddeder imza. LNK: Doğrulayıcı geçmiş imzalarda I kullanılıp kullanılmadığını kontrol eder (bu değerler I'i ayarla). Çoklu kullanım, aynı gizli anahtar altında iki imzanın üretildiği anlamına gelir. Protokolün anlamı: L-dönüşümlerini uygulayarak imzalayan kişi bildiğini kanıtlar öyle bir x ki, en az bir Pi = xG. Bu kanıtı tekrarlanamaz kılmak için anahtar görseli tanıtıyoruz I = xHp(P) olarak. İmzalayan kişi neredeyse aynı ifadeyi kanıtlamak için aynı katsayıları (ri, ci) kullanır: öyle bir x biliyor ki, en az bir \(H_p(P_i) = I \cdot x^{-1}\). Eğer \(x \to I\) eşlemesi bir enjeksiyon ise: 1. Hiç kimse anahtar görselden genel anahtarı kurtaramaz ve imzalayanı tanımlayamaz; 2. İmzalayan kişi farklı I'lere ve aynı x'e sahip iki imza atamaz. Tam bir güvenlik analizi Ek A'da verilmektedir. 4.5 Standart CryptoNote işlemi Bob, her iki yöntemi (bağlanamayan genel anahtarlar ve izlenemeyen halka imza) birleştirerek şunu başarır: Orijinal Bitcoin şemasıyla karşılaştırıldığında yeni gizlilik düzeyi. Yalnızca saklamasını gerektirir anonim işlemleri almaya ve göndermeye başlamak için bir özel anahtar (a, b) ve yayınlayın (A, B). Bob, her işlemi doğrularken ayrıca işlemin kendisine ait olup olmadığını kontrol etmek için yalnızca iki eliptik eğri çarpımı ve çıktı başına bir toplama işlemi gerçekleştirir. Onun için her çıktı Bob bir kerelik anahtar çiftini (pi, Pi) kurtarır ve bunu cüzdanında saklar. Herhangi bir giriş olabilir yalnızca tek bir işlemde ortaya çıkmaları durumunda aynı sahibine sahip oldukları ikinci dereceden kanıtlanmıştır. içinde Aslında tek seferlik zil imzası nedeniyle bu ilişkinin kurulması çok daha zordur. Bir halka imzasıyla Bob, her girişi başkasının girişleri arasında etkili bir şekilde gizleyebilir; hepsi mümkün Önceki sahibin (Alice) bile bundan daha fazla bilgisi olmasa bile harcama yapanlar eşit olasılıklı olacaktır. herhangi bir gözlemci Bob, işlemini imzalarken, kendisininkiyle aynı miktarda yabancı çıktı belirtir. çıktı, diğer kullanıcıların katılımı olmadan hepsini karıştırıyor. Bob'un kendisi (aynı zamanda başkası) bu ödemelerden herhangi birinin harcanıp harcanmadığını bilmiyor: bir çıktı kullanılabilir Binlerce imzada belirsizlik unsuru olarak yer alıyor ve asla saklanma hedefi olarak görülmüyor. Çift Harcama kontrolü LNK aşamasında, kullanılan anahtar görseller setine göre kontrol edilirken gerçekleşir. Bob belirsizlik derecesini kendisi seçebilir: n = 1, sahip olduğu olasılık anlamına gelir harcanan çıktının olasılığı %50, n=99 ise %1'i verir. Ortaya çıkan imzanın boyutu artar O(n+1) şeklinde doğrusaldır, dolayısıyla geliştirilmiş anonimlik Bob'a ekstra işlem ücreti maliyeti getirir. O da yapabilir n = 0'ı ayarlayın ve halka imzasının yalnızca bir öğeden oluşmasını sağlayın, ancak bu anında onu müsrif biri olarak ifşa et. 10 VER: Doğrulayıcı, ters dönüşümleri uygulayarak imzayı kontrol eder: ( L' i = riG + ciPi R' i = riHp(Pi) + ciI Son olarak, doğrulayıcı şunları kontrol eder: nP ben=0 ci ?= Hs(m, L' 0, . . . , L' n, R' 0, . . . , R' n) mod l Bu eşitlik doğruysa, doğrulayıcı LNK algoritmasını çalıştırır. Aksi takdirde doğrulayıcı reddeder imza. LNK: Doğrulayıcı geçmiş imzalarda I kullanılıp kullanılmadığını kontrol eder (bu değerler I'i ayarla). Çoklu kullanım, aynı gizli anahtar altında iki imzanın üretildiği anlamına gelir. Protokolün anlamı: L-dönüşümlerini uygulayarak imzalayan kişi bildiğini kanıtlar öyle bir x ki, en az bir Pi = xG. Bu kanıtı tekrarlanamaz kılmak için anahtar görseli tanıtıyoruz I = xHp(P) olarak. İmzalayan kişi neredeyse aynı ifadeyi kanıtlamak için aynı katsayıları (ri, ci) kullanır: öyle bir x biliyor ki, en az bir \(H_p(P_i) = I \cdot x^{-1}\). Eğer \(x \to I\) eşlemesi bir enjeksiyon ise: 1. Hiç kimse anahtar görselden genel anahtarı kurtaramaz ve imzalayanı tanımlayamaz; 2. İmzalayan kişi farklı I'lere ve aynı x'e sahip iki imza atamaz. Tam bir güvenlik analizi Ek A'da verilmektedir. 4.5 Standart CryptoNote işlemi Bob, her iki yöntemi (bağlanamayan genel anahtarlar ve izlenemeyen halka imza) birleştirerek şunu başarır: Orijinal Bitcoin şemasıyla karşılaştırıldığında yeni gizlilik düzeyi. Yalnızca saklamasını gerektirir anonim işlemleri almaya ve göndermeye başlamak için bir özel anahtar (a, b) ve yayınlayın (A, B). Bob, her işlemi doğrularken ayrıca işlemin kendisine ait olup olmadığını kontrol etmek için yalnızca iki eliptik eğri çarpımı ve çıktı başına bir toplama işlemi gerçekleştirir. Onun için her çıktı Bob bir kerelik anahtar çiftini (pi, Pi) kurtarır ve stcüzdanında saklıyor. Herhangi bir giriş olabilir yalnızca tek bir işlemde ortaya çıkmaları durumunda aynı sahibine sahip oldukları ikinci dereceden kanıtlanmıştır. içinde Aslında tek seferlik zil imzası nedeniyle bu ilişkinin kurulması çok daha zordur. Bir halka imzasıyla Bob, her girişi başkasının girişleri arasında etkili bir şekilde gizleyebilir; hepsi mümkün Önceki sahibin (Alice) bile bundan daha fazla bilgisi olmasa bile harcama yapanlar eşit olasılıklı olacaktır. herhangi bir gözlemci Bob, işlemini imzalarken, kendisininkiyle aynı miktarda yabancı çıktı belirtir. çıktı, diğer kullanıcıların katılımı olmadan hepsini karıştırıyor. Bob'un kendisi (aynı zamanda başkası) bu ödemelerden herhangi birinin harcanıp harcanmadığını bilmiyor: bir çıktı kullanılabilir Binlerce imzada belirsizlik unsuru olarak yer alıyor ve asla saklanma hedefi olarak görülmüyor. Çift Harcama kontrolü LNK aşamasında, kullanılan anahtar görseller setine göre kontrol edilirken gerçekleşir. Bob belirsizlik derecesini kendisi seçebilir: n = 1, sahip olduğu olasılık anlamına gelir harcanan çıktının olasılığı %50, n=99 ise %1'i verir. Ortaya çıkan imzanın boyutu artar O(n+1) şeklinde doğrusaldır, dolayısıyla geliştirilmiş anonimlik Bob'a ekstra işlem ücreti maliyeti getirir. O da yapabilir n = 0'ı ayarlayın ve halka imzasının yalnızca bir öğeden oluşmasını sağlayın, ancak bu anında onu müsrif biri olarak ifşa et. 10 19 Bu noktada kafam çok karışık. Alex, imzayı (I,c_1, ..., c_n, r_1, ..., r_n) ve genel listeyi içeren bir M mesajı alır. S. tuşlarına basıyor ve VER'i çalıştırıyor. Bu L_i' ve R_i'yi hesaplayacaktır Bu, önceki sayfada c_s = c - sum_i neq s c_i olduğunu doğrular. İlk başta kafam çok karışıktı. Herkes L_i' ve R_i'yi hesaplayabilir. Aslında her r_i ve c_i imzada yayınlandı sigma I değeriyle birlikte. S = kümesi Tüm genel anahtarların P_i'si de yayınlandı. Yani sigmayı ve setini gören herkes S = P_i tuşları L_i' ve R_i' için aynı değerleri alacak ve dolayısıyla imzayı kontrol edecektir. Ancak daha sonra bu bölümün bir "kontrol" değil, yalnızca bir imza algoritmasını tanımladığını hatırladım. İmzalanmışsa, BANA GÖNDERİLİP GÖNDERİLMEDİĞİNİ kontrol et ve eğer öyleyse, git parayı harca." Bu KESİNLİKLE Oyunun imza kısmı. Sonunda oraya vardığımda Ek A'yı okumak isterim. Cryptonote'un Bitcoin ile tam ölçekli operasyon bazında karşılaştırmasını görmek istiyorum. Ayrıca elektrik/sürdürülebilirlik. Algoritmanın hangi parçaları burada "girdi" oluşturuyor? İşlem girişinin bir Tutar ve toplamı UTXOs kümesinden oluştuğuna inanıyorum. Tutar. Bu belirsiz. "Gizlenme hedefi mi?" Bunu birkaç dakikadır düşünüyorum ve hala bulamadım bunun ne anlama gelebileceğine dair en belirsiz fikir. Çift harcama saldırısı yalnızca bir düğümün algılanan kullanılmış anahtarı değiştirilerek gerçekleştirilebilir resimler \(I\) olarak ayarlandı. "Belirsizlik derecesi" = n ancak işleme dahil edilen genel anahtarların toplam sayısı n+1. Yani belirsizlik derecesi "başka kaç kişinin olmasını istiyorsunuz" olacaktır. kalabalık mı?" Cevap muhtemelen varsayılan olarak "mümkün olduğu kadar çok" olacaktır.
VER: Doğrulayıcı, ters dönüşümleri uygulayarak imzayı kontrol eder: ( L' i = riG + ciPi R' i = riHp(Pi) + ciI Son olarak, doğrulayıcı şunları kontrol eder: nP ben=0 ci ?= Hs(m, L' 0, . . . , L' n, R' 0, . . . , R' n) mod l Bu eşitlik doğruysa, doğrulayıcı LNK algoritmasını çalıştırır. Aksi takdirde doğrulayıcı reddeder imza. LNK: Doğrulayıcı geçmiş imzalarda I kullanılıp kullanılmadığını kontrol eder (bu değerler I'i ayarla). Çoklu kullanım, aynı gizli anahtar altında iki imzanın üretildiği anlamına gelir. Protokolün anlamı: L-dönüşümlerini uygulayarak imzalayan kişi bildiğini kanıtlar öyle bir x ki, en az bir Pi = xG. Bu kanıtı tekrarlanamaz kılmak için anahtar görseli tanıtıyoruz I = xHp(P) olarak. İmzalayan kişi neredeyse aynı ifadeyi kanıtlamak için aynı katsayıları (ri, ci) kullanır: öyle bir x biliyor ki, en az bir \(H_p(P_i) = I \cdot x^{-1}\). Eğer \(x \to I\) eşlemesi bir enjeksiyon ise: 1. Hiç kimse anahtar görselden genel anahtarı kurtaramaz ve imzalayanı tanımlayamaz; 2. İmzalayan kişi farklı I'lere ve aynı x'e sahip iki imza atamaz. Tam bir güvenlik analizi Ek A'da verilmektedir. 4.5 Standart CryptoNote işlemi Bob, her iki yöntemi (bağlanamayan genel anahtarlar ve izlenemeyen halka imza) birleştirerek şunu başarır: Orijinal Bitcoin düzeniyle karşılaştırıldığında yeni gizlilik düzeyi. Yalnızca saklamasını gerektirir anonim işlemleri almaya ve göndermeye başlamak için bir özel anahtar (a, b) ve yayınlayın (A, B). Bob, her işlemi doğrularken ayrıca işlemin kendisine ait olup olmadığını kontrol etmek için yalnızca iki eliptik eğri çarpımı ve çıktı başına bir toplama işlemi gerçekleştirir. Onun için her çıktı Bob bir kerelik anahtar çiftini (pi, Pi) kurtarır ve bunu cüzdanında saklar. Herhangi bir giriş olabilir yalnızca tek bir işlemde ortaya çıkmaları durumunda aynı sahibine sahip oldukları ikinci dereceden kanıtlanmıştır. içinde Aslında tek seferlik zil imzası nedeniyle bu ilişkinin kurulması çok daha zordur. Bir halka imzasıyla Bob, her girişi başkasının girişleri arasında etkili bir şekilde gizleyebilir; hepsi mümkün Önceki sahibin (Alice) bile bundan daha fazla bilgisi olmasa bile harcama yapanlar eşit olasılıklı olacaktır. herhangi bir gözlemci Bob, işlemini imzalarken, kendisininkiyle aynı miktarda yabancı çıktı belirtir. çıktı, diğer kullanıcıların katılımı olmadan hepsini karıştırıyor. Bob'un kendisi (aynı zamanda başkası) bu ödemelerden herhangi birinin harcanıp harcanmadığını bilmiyor: bir çıktı kullanılabilir Binlerce imzada belirsizlik unsuru olarak yer alıyor ve asla saklanma hedefi olarak görülmüyor. Çift Harcama kontrolü LNK aşamasında, kullanılan anahtar görseller setine göre kontrol edilirken gerçekleşir. Bob belirsizlik derecesini kendisi seçebilir: n = 1, sahip olduğu olasılık anlamına gelir harcanan çıktının olasılığı %50, n=99 ise %1'i verir. Ortaya çıkan imzanın boyutu artar O(n+1) şeklinde doğrusaldır, dolayısıyla geliştirilmiş anonimlik Bob'a ekstra işlem ücreti maliyeti getirir. O da yapabilir n = 0'ı ayarlayın ve halka imzasının yalnızca bir öğeden oluşmasını sağlayın, ancak bu anında onu müsrif biri olarak ifşa et. 10 VER: Doğrulayıcı, ters dönüşümleri uygulayarak imzayı kontrol eder: ( L' i = riG + ciPi R' i = riHp(Pi) + ciI Son olarak, doğrulayıcı şunları kontrol eder: nP ben=0 ci ?= Hs(m, L' 0, . . . , L' n, R' 0, . . . , R' n) mod l Bu eşitlik doğruysa, doğrulayıcı LNK algoritmasını çalıştırır. Aksi takdirde doğrulayıcı reddeder imza. LNK: Doğrulayıcı geçmiş imzalarda I kullanılıp kullanılmadığını kontrol eder (bu değerler I'i ayarla). Çoklu kullanım, aynı gizli anahtar altında iki imzanın üretildiği anlamına gelir. Protokolün anlamı: L-dönüşümlerini uygulayarak imzalayan kişi bildiğini kanıtlar öyle bir x ki, en az bir Pi = xG. Bu kanıtı tekrarlanamaz kılmak için anahtar görseli tanıtıyoruz I = xHp(P) olarak. İmzalayan kişi neredeyse aynı ifadeyi kanıtlamak için aynı katsayıları (ri, ci) kullanır: öyle bir x biliyor ki, en az bir \(H_p(P_i) = I \cdot x^{-1}\). Eğer \(x \to I\) eşlemesi bir enjeksiyon ise: 1. Hiç kimse anahtar görselden genel anahtarı kurtaramaz ve imzalayanı tanımlayamaz; 2. İmzalayan kişi farklı I'lere ve aynı x'e sahip iki imza atamaz. Tam bir güvenlik analizi Ek A'da verilmektedir. 4.5 Standart CryptoNote işlemi Bob, her iki yöntemi (bağlanamayan genel anahtarlar ve izlenemeyen halka imza) birleştirerek şunu başarır: Orijinal Bitcoin şemasıyla karşılaştırıldığında yeni gizlilik düzeyi. Yalnızca saklamasını gerektirir anonim işlemleri almaya ve göndermeye başlamak için bir özel anahtar (a, b) ve yayınlayın (A, B). Bob, her işlemi doğrularken ayrıca işlemin kendisine ait olup olmadığını kontrol etmek için yalnızca iki eliptik eğri çarpımı ve çıktı başına bir toplama işlemi gerçekleştirir. Onun için her çıktı Bob bir kerelik anahtar çiftini (pi, Pi) kurtarır ve stcüzdanında saklıyor. Herhangi bir giriş olabilir yalnızca tek bir işlemde ortaya çıkmaları durumunda aynı sahibine sahip oldukları ikinci dereceden kanıtlanmıştır. içinde Aslında tek seferlik zil imzası nedeniyle bu ilişkinin kurulması çok daha zordur. Bir halka imzasıyla Bob, her girişi başkasının girişleri arasında etkili bir şekilde gizleyebilir; hepsi mümkün Önceki sahibin (Alice) bile bundan daha fazla bilgisi olmasa bile harcama yapanlar eşit olasılıklı olacaktır. herhangi bir gözlemci Bob, işlemini imzalarken, kendisininkiyle aynı miktarda yabancı çıktı belirtir. çıktı, diğer kullanıcıların katılımı olmadan hepsini karıştırıyor. Bob'un kendisi (aynı zamanda başkası) bu ödemelerden herhangi birinin harcanıp harcanmadığını bilmiyor: bir çıktı kullanılabilir Binlerce imzada belirsizlik unsuru olarak yer alıyor ve asla saklanma hedefi olarak görülmüyor. Çift Harcama kontrolü LNK aşamasında, kullanılan anahtar görseller setine göre kontrol edilirken gerçekleşir. Bob belirsizlik derecesini kendisi seçebilir: n = 1, sahip olduğu olasılık anlamına gelir harcanan çıktının olasılığı %50, n=99 ise %1'i verir. Ortaya çıkan imzanın boyutu artar O(n+1) şeklinde doğrusaldır, dolayısıyla geliştirilmiş anonimlik Bob'a ekstra işlem ücreti maliyeti getirir. O da yapabilir n = 0'ı ayarlayın ve halka imzasının yalnızca bir öğeden oluşmasını sağlayın, ancak bu anında onu müsrif biri olarak ifşa et. 10 20 Bu ilginç; daha önce Bob adlı alıcının tüm GELENLERİ alabilmesi için bir yol sunmuştuk. özel anahtarlarının yarısını deterministik olarak seçerek veya özel anahtarlarının yarısını herkese açık olarak yayınlıyor. Bu geri dönüşü olmayan bir politikadır. Burada görüyoruz Gönderenin Alex'in tek bir giden işlemi bağlanabilir olarak seçmesinin bir yolu, ama aslında bu Alex'in tüm ağın göndericisi olduğunu ortaya koyuyor. Bu geri dönüşü olmayan bir politika DEĞİLDİR. Bu, işlem bazındadır. Üçüncü bir politika var mı? Alıcı Bob, Alex için benzersiz bir ödeme kimliği oluşturabilir mi? belki Diffe-Hellman değişimini kullanarak hiç değişmiyor? Birisi bu ödemeyi dahil ederse İşlemin bir yerinde Bob'un adresine gönderilen kimlik, Alex'ten gelmiş olmalı. Bu şekilde, Alex'in belirli bir bağlantıya bağlanmayı seçerek kendisini tüm ağa göstermesine gerek kalmaz. ancak yine de parasını gönderdiği kişiye kendisini tanıtabilir. Poloniex'in yaptığı da bu değil mi?
İşlem Gönderim girişi Çıkış0 . . . Çıkış . . . Çıkış Anahtar resim İmzalar Yüzük İmzası Hedef anahtarı Çıkış1 Hedef anahtarı Çıkış Yabancı işlemler Gönderenin çıktısı Hedef anahtarı Tek kullanımlık anahtar eşleştirme Bir kerelik özel anahtar ben = xHp(P) P, x Şekil 7. Standart bir işlemde halka imzası üretimi. 5 Eşitlikçi İş Kanıtı Bu bölümde yeni proof-of-work algoritmasını öneriyor ve temellendiriyoruz. Öncelikli hedefimiz CPU (çoğunluk) ve GPU/FPGA/ASIC (azınlık) madencileri arasındaki boşluğu kapatmaktır. öyle bazı kullanıcıların diğerlerine göre belirli bir avantaja sahip olabileceği ancak yatırımlarının en azından güçle birlikte doğrusal olarak büyümelidir. Daha genel olarak özel amaçlı cihazların üretilmesi mümkün olduğu kadar az kârlı olmalıdır. 5.1 İlgili çalışmalar Orijinal Bitcoin proof-of-work protokolü, CPU yoğun fiyatlandırma işlevini SHA-256 kullanır. Temel olarak temel mantıksal operatörlerden oluşur ve yalnızca hesaplama hızına dayanır. işlemci bu nedenle çok çekirdekli/taşıyıcı uygulaması için mükemmel şekilde uygundur. Ancak modern bilgisayarlar yalnızca saniyedeki işlem sayısıyla sınırlı değildir. ama aynı zamanda hafıza boyutuna göre. Bazı işlemciler diğerlerinden önemli ölçüde daha hızlı olsa da [8], bellek boyutlarının makineler arasında değişme olasılığı daha azdır. Belleğe bağlı fiyat fonksiyonları ilk olarak Abadi ve diğerleri tarafından tanıtıldı ve şu şekilde tanımlandı: “hesaplama zamanına belleğe erişimde harcanan sürenin hakim olduğu işlevler” [15]. Ana fikir, büyük bir veri bloğunu (“not defteri”) tahsis eden bir algoritma oluşturmaktır. Nispeten yavaş erişilebilen bellek içinde (örneğin RAM) ve “bir içindeki öngörülemeyen konumlar dizisi”. Bir blok muhafaza edilebilecek kadar büyük olmalıdır Verileri her erişim için yeniden hesaplamaktan daha avantajlıdır. Algoritma aynı zamanda dahili paralelliği önler, dolayısıyla N eşzamanlı iş parçacığı N kat daha fazla bellek gerektirir hemen. Dwork ve diğerleri [22] bu yaklaşımı araştırıp resmileştirdiler ve bu da onları başka bir yaklaşım önermeye yönlendirdi fiyatlandırma fonksiyonunun bir çeşidi: “Mbound”. Bir eser daha F. Coelho'ya ait [20] 11 İşlem Gönderim girişi Çıkış0 . . . Çıkış . . . Çıkış Anahtar resim İmzalar Yüzük İmzası Hedef anahtarı Çıkış1 Hedef anahtarı Çıkış Yabancı işlemler Gönderenin çıktısı Hedef anahtarı Tek kullanımlık anahtar eşleştirme Bir kerelik özel anahtar ben = xHp(P) P, x Şekil 7. Standart bir işlemde halka imzası üretimi. 5 Eşitlikçi İş Kanıtı Bu bölümde yeni proof-of-work algoritmasını öneriyor ve temellendiriyoruz. Öncelikli hedefimiz CPU (çoğunluk) ve GPU/FPGA/ASIC (azınlık) madencileri arasındaki boşluğu kapatmaktır. öyle bazı kullanıcıların diğerlerine göre belirli bir avantaja sahip olabileceği ancak yatırımlarının en azından güçle birlikte doğrusal olarak büyümelidir. Daha genel olarak özel amaçlı cihazların üretilmesi mümkün olduğu kadar az kârlı olmalıdır. 5.1 İlgili çalışmalar Orijinal Bitcoin proof-of-work protokolü, CPU yoğun fiyatlandırma işlevini SHA-256 kullanır. Temel olarak temel mantıksal operatörlerden oluşur ve yalnızca hesaplama hızına dayanır. işlemci bu nedenle çok çekirdekli/taşıyıcı uygulaması için mükemmel şekilde uygundur. Ancak modern bilgisayarlar yalnızca saniyedeki işlem sayısıyla sınırlı değildir. ama aynı zamanda hafıza boyutuna göre. Bazı işlemciler diğerlerinden önemli ölçüde daha hızlı olabilse de [8], bellek boyutlarının makineler arasında değişme olasılığı daha azdır. Belleğe bağlı fiyat fonksiyonları ilk olarak Abadi ve diğerleri tarafından tanıtıldı ve şu şekilde tanımlandı: “hesaplama zamanına belleğe erişimde harcanan sürenin hakim olduğu işlevler” [15]. Ana fikir, büyük bir veri bloğunu (“not defteri”) tahsis eden bir algoritma oluşturmaktır. Nispeten yavaş erişilebilen bellek içinde (örneğin RAM) ve “bir içindeki öngörülemeyen konumlar dizisi”. Bir blok muhafaza edilebilecek kadar büyük olmalıdır Verileri her erişim için yeniden hesaplamaktan daha avantajlıdır. Algoritma aynı zamanda dahili paralelliği önler, dolayısıyla N eşzamanlı iş parçacığı N kat daha fazla bellek gerektirir hemen. Dwork ve arkadaşları [22] bu yaklaşımı araştırıp resmileştirdiler ve bu da onları başka bir yaklaşım önermeye yöneltti. fiyatlandırma fonksiyonunun bir çeşidi: “Mbound”. Bir eser daha F. Coelho'ya ait [20] 11 21 Görünüşte bunlar bizim UTXO'larımız: tutarlar ve hedef anahtarlarımız. Bu standart işlemi oluşturan ve Bob'a gönderen kişi Alex ise, o zaman Alex'in özel anahtarları da vardır bunların her birine. Bu diyagramı çok seviyorum çünkü daha önceki bazı sorulara yanıt veriyor. Bir Txn girişi oluşur bir dizi Txn çıkışı ve bir keresim. Daha sonra tümü dahil olmak üzere halka imzayla imzalanır. Alex'in anlaşmaya dahil edilen tüm yabancı işlemlere ait özel anahtarları. Txn çıktısı bir miktar ve bir hedef anahtarından oluşur. İşlemin alıcısı, harcamak için makalede daha önce açıklandığı gibi tek kullanımlık özel anahtarlarını istedikleri zaman oluşturabilirler. para. Bunun gerçek kodla ne kadar eşleştiğini öğrenmek çok keyifli olacak... Hayır, Nic van Saberhagen iş kanıtı algoritmasının bazı özelliklerini gevşek bir şekilde açıklıyor, aslında bu algoritmayı tanımlamadan. CryptoNight algoritmasının kendisi derin bir analiz GEREKTİRİR. Bunu okuyunca kekeledim. Yatırım en azından güçle birlikte doğrusal olarak mı büyümeli, yoksa yatırım en fazla güçle doğrusal olarak mı büyüyor? Ve sonra şunu fark ettim; Ben bir madenci veya yatırımcı olarak genellikle "ne kadar güç elde edebilirim" diye düşünürüm yatırım için mi?" "Sabit miktardaki güç için ne kadar yatırım gerekir?" değil. Elbette, yatırımı I ile, gücü ise P ile belirtin. Eğer I(P) gücün bir fonksiyonu olarak yatırım ise ve P(I) yatırımın bir fonksiyonu olarak güçtür, birbirlerinin tersi olacaktır (nerede olursa olsun) tersler mevcut olabilir). Ve eğer I(P), doğrusaldan daha hızlıysa, P(I) doğrusaldan daha yavaştır. Bu nedenle, yatırımcılar için daha düşük bir getiri oranı olacaktır. Yani yazarın burada söylediği şu: "Elbette, ne kadar çok yatırım yaparsanız, o kadar çok kazanırsınız. güç. Ancak bunu daha düşük bir getiri oranı meselesi haline getirmeye çalışmalıyız." CPU yatırımları eninde sonunda alt sınıra ulaşacak; soru, yazarların ASIC'leri de bunu yapmaya zorlayacak bir POW algoritması tasarladık. Varsayımsal bir "geleceğin para birimi" her zaman en yavaş/en sınırlı kaynaklarla mı madencilik yapmalı? Abadi ve arkadaşlarının (bazı Google ve Microsoft mühendislerinin yazar olduğu) makalesi şöyledir: esasen, son birkaç yıldır bellek boyutunun çok daha küçük olduğu gerçeğini kullanarak makineler arasında işlemci hızından daha fazla farklılık vardır ve doğrusaldan daha fazla bir yatırım-güç oranına sahiptir. Birkaç yıl içinde bunun yeniden değerlendirilmesi gerekebilir! Herşey bir silahlanma yarışı... Bir hash işlevinin oluşturulması zordur; bu kısıtlamaları karşılayan bir hash işlevi oluşturmak daha zor görünüyor. Bu yazıda gerçekle ilgili hiçbir açıklama yok gibi görünüyor hashing algoritması CryptoNight. Bunun SHA-3'ün hafıza açısından zor bir uygulaması olduğunu düşünüyorum. forum gönderilerinde ama hiçbir fikrim yok... ve mesele de bu. Açıklanması gerekir.
en etkili çözümü önerdi: “Hokkaido”. Bildiğimiz kadarıyla büyük bir dizide sözde rastgele arama fikrine dayanan son çalışma C. Percival [32] tarafından “scrypt” olarak bilinen algoritma. Önceki işlevlerden farklı olarak aşağıdakilere odaklanır: anahtar türetme ve proof-of-work sistemler değil. Bu gerçeğe rağmen scrypt amacımıza hizmet edebilir: SHA-256 gibi kısmi hash dönüşüm probleminde bir fiyatlandırma işlevi olarak iyi çalışır. Bitcoin. Şu ana kadar Litecoin [14] ve diğer bazı Bitcoin çatallarda şifre zaten uygulandı. Bununla birlikte, uygulanması aslında belleğe bağlı değildir: "bellek erişim süresi / genel" oranı time" yeterince büyük değil çünkü her örnek yalnızca 128 KB kullanıyor. Bu, GPU madencilerinin kabaca 10 kat daha etkili olmaya devam ediyor ve nispeten yaratma olanağı bırakmaya devam ediyor ucuz ama son derece verimli madencilik cihazları. Dahası, şifre yapısının kendisi bellek boyutu ile bellek boyutu arasında doğrusal bir değiş tokuşa izin verir. Karalama defterindeki her bloğun yalnızca bir öncekinden türetilmesi nedeniyle CPU hızı. Örneğin, her ikinci bloğu saklayabilir ve diğerlerini tembel bir şekilde yeniden hesaplayabilirsiniz, yani yalnızca gerekli olduğunda. Sözde rastgele indekslerin düzgün dağıldığı varsayılır, dolayısıyla ek blokların yeniden hesaplamalarının beklenen değeri 1'dir \(2 \cdot N\), burada N sayıdır yinelemelerden oluşur. Genel hesaplama süresi yarıdan daha az artar çünkü ayrıca karalama defterinin hazırlanması ve hashing gibi zamandan bağımsız (sabit zamanlı) işlemler her yineleme. Bellek maliyetlerinin 2/3'ünden tasarruf etmek 1 \(3 \cdot N\) + 1 3 \(\cdot\) \(2 \cdot N\) = N ek yeniden hesaplama; 9/10 sonuç 1 \(10 \cdot N\) + . . . + 1 \(10 \cdot 9 \cdot N\) = 4,5K. Sadece 1 tanesinin saklandığını göstermek kolaydır. tüm bloklardan zamanı s−1 faktöründen daha az artırır 2. Bu da CPU'lu bir makinenin olduğu anlamına gelir. Modern çiplerden 200 kat daha hızlı olan çipler, karalama defterinin yalnızca 320 baytını depolayabiliyor. 5.2 Önerilen algoritma proof-of-work fiyatlandırma işlevi için yeni bir belleğe bağlı algoritma öneriyoruz. Şuna dayanır: Yavaş bir belleğe rastgele erişim ve gecikme bağımlılığını vurgular. Her birini şifrelemenin aksine yeni blok (64 bayt uzunluğunda) önceki tüm bloklara bağlıdır. Sonuç olarak varsayımsal "Hafıza koruyucu" hesaplama hızını katlanarak artırmalıdır. Algoritmamız aşağıdaki nedenlerden dolayı örnek başına yaklaşık 2 Mb gerektirir: 1. Modern işlemcilerin ana akım haline gelmesi gereken L3 önbelleğine (çekirdek başına) sığar birkaç yıl içinde; 2. Bir megabayt dahili bellek, modern bir ASIC boru hattı için neredeyse kabul edilemez bir boyuttur; 3. GPU'lar yüzlerce eş zamanlı örneği çalıştırabilir ancak başka açılardan sınırlıdırlar: GDDR5 bellek, CPU L3 önbelleğinden daha yavaştır ve bant genişliği açısından dikkat çekicidir. rastgele erişim hızı. 4. Karalama defterinin önemli ölçüde genişlemesi yinelemelerde bir artış gerektirecektir; dönüş genel bir süre artışı anlamına gelir. Güvenin olmadığı bir p2p ağında "ağır" çağrılar, ciddi güvenlik açıkları var çünkü düğümler her yeni bloğun proof-of-work değerini kontrol etmek zorunda. Bir düğüm her hash değerlendirmesine önemli miktarda zaman harcıyorsa, bu kolayca yapılabilir. Rastgele çalışma verilerine (nonce değerleri) sahip bir dizi sahte nesne tarafından DDoS uygulandı. 12 en etkili çözümü önerdi: “Hokkaido”. Bildiğimiz kadarıyla büyük bir dizide sözde rastgele arama fikrine dayanan son çalışma C. Percival [32] tarafından “scrypt” olarak bilinen algoritma. Önceki işlevlerden farklı olarak aşağıdakilere odaklanır: anahtar türetme, proof-of-work sistemler değil. Bu gerçeğe rağmen scrypt amacımıza hizmet edebilir: SHA-256 gibi kısmi hash dönüştürme probleminde bir fiyatlandırma işlevi olarak iyi çalışır. Bitcoin. Şu ana kadar Litecoin [14] ve diğer bazı Bitcoin çatallarda şifre zaten uygulandı. Bununla birlikte, uygulanması aslında belleğe bağlı değildir: "bellek erişim süresi / genel" oranı time" yeterince büyük değil çünkü her örnek yalnızca 128 KB kullanıyor. Bu, GPU madencilerine izin verir kabaca 10 kat daha etkili olmaya devam ediyor ve nispeten yaratma olanağı bırakmaya devam ediyor ucuz ama son derece verimli madencilik cihazları. Dahası, şifre yapısının kendisi bellek boyutu ile bellek boyutu arasında doğrusal bir değiş tokuşa izin verir. Karalama defterindeki her bloğun yalnızca bir öncekinden türetilmesi nedeniyle CPU hızı. Örneğin, her ikinci bloğu saklayabilir ve diğerlerini tembel bir şekilde yeniden hesaplayabilirsiniz, yani yalnızca gerekli olduğunda. Sözde rastgele indekslerin düzgün dağıldığı varsayılır, dolayısıyla ek blokların yeniden hesaplamalarının beklenen değeri 1'dir \(2 \cdot N\), buradaN sayıdır yinelemelerden oluşur. Genel hesaplama süresi yarıdan daha az artar çünkü ayrıca karalama defterinin hazırlanması ve hashing gibi zamandan bağımsız (sabit zamanlı) işlemler her yineleme. Bellek maliyetlerinin 2/3'ünden tasarruf etmek 1 \(3 \cdot N\) + 1 3 \(\cdot\) \(2 \cdot N\) = N ek yeniden hesaplama; 9/10 sonuç 1 \(10 \cdot N\) + . . . + 1 \(10 \cdot 9 \cdot N\) = 4,5K. Sadece 1 tanesinin saklandığını göstermek kolaydır. tüm bloklardan zamanı s−1 faktöründen daha az artırır 2. Bu da CPU'lu bir makinenin olduğu anlamına gelir. Modern çiplerden 200 kat daha hızlı olan çipler, karalama defterinin yalnızca 320 baytını depolayabiliyor. 5.2 Önerilen algoritma proof-of-work fiyatlandırma işlevi için yeni bir belleğe bağlı algoritma öneriyoruz. Şuna dayanır: Yavaş bir belleğe rastgele erişim ve gecikme bağımlılığını vurgular. Her birini şifrelemenin aksine yeni blok (64 bayt uzunluğunda) önceki tüm bloklara bağlıdır. Sonuç olarak varsayımsal "Hafıza koruyucu" hesaplama hızını katlanarak artırmalıdır. Algoritmamız aşağıdaki nedenlerden dolayı örnek başına yaklaşık 2 Mb gerektirir: 1. Modern işlemcilerin ana akım haline gelmesi gereken L3 önbelleğine (çekirdek başına) sığar birkaç yıl içinde; 2. Bir megabayt dahili bellek, modern bir ASIC boru hattı için neredeyse kabul edilemez bir boyuttur; 3. GPU'lar yüzlerce eş zamanlı örneği çalıştırabilir ancak başka açılardan sınırlıdırlar: GDDR5 bellek, CPU L3 önbelleğinden daha yavaştır ve bant genişliği açısından dikkat çekicidir. rastgele erişim hızı. 4. Karalama defterinin önemli ölçüde genişlemesi yinelemelerde bir artış gerektirecektir; dönüş genel bir süre artışı anlamına gelir. Güvenin olmadığı bir p2p ağında "ağır" çağrılar, ciddi güvenlik açıkları var çünkü düğümler her yeni bloğun proof-of-work değerini kontrol etmek zorunda. Bir düğüm her hash değerlendirmesine önemli miktarda zaman harcıyorsa, bu kolayca yapılabilir. Rastgele çalışma verilerine (nonce değerleri) sahip bir dizi sahte nesne tarafından DDoS uygulandı. 12 22 Boşver, bu bir şifreli para mı? Algoritma nerede? Gördüğüm tek şey bir reklam. Burası, eğer PoW algoritması değerliyse, Cryptonote'un gerçekten parlayacağı yerdir. değil gerçekten SHA-256, gerçekten şifreli değil. Yenidir, belleğe bağlıdır ve yinelenmez.
6 Diğer avantajlar 6.1 Sorunsuz emisyon CryptoNote dijital paralarının toplam miktarının üst sınırı şöyledir: MSarzı = 264 −1 atom birimleri. Bu, sezgiye değil, yalnızca uygulama sınırlarına dayanan doğal bir kısıtlamadır. "N tane para herkese yetmeli" gibi. Emisyon sürecinin düzgünlüğünü sağlamak için blok için aşağıdaki formülü kullanıyoruz: ödüller: Temel Ödül = (MSarzı −A) ≫18, burada A, daha önce üretilen madeni paraların miktarıdır. 6.2 Ayarlanabilir parametreler 6.2.1 Zorluk CryptoNote, her bloğun zorluğunu değiştiren bir hedefleme algoritması içerir. Bu Ağ hashhızının yoğun bir şekilde arttığı veya daraldığı durumlarda sistemin tepki süresini azaltır, sabit bir blok oranının korunması. Orijinal Bitcoin yöntemi, gerçek değer ilişkisini hesaplar ve son 2016 blok arasındaki zaman aralığını hedef alır ve bunu mevcut blok için çarpan olarak kullanır zorluk. Açıkçası bu, hızlı yeniden hesaplamalar için uygun değildir (büyük atalet nedeniyle) ve salınımlarla sonuçlanır. Algoritmamızın arkasındaki genel fikir, düğümlerin tamamladığı tüm işleri toplamak ve harcadıkları zamana bölün. İşin ölçüsü karşılık gelen zorluk değerleridir her blokta. Ancak yanlış ve güvenilmeyen zaman damgaları nedeniyle kesin zamanı belirleyemiyoruz bloklar arasındaki zaman aralığı. Kullanıcı zaman damgasını geleceğe ve bir sonraki zamana kaydırabilir aralıklar beklenmedik derecede küçük veya hatta negatif olabilir. Muhtemelen birkaç olay yaşanacak bu tür, böylece zaman damgalarını sıralayabilir ve aykırı değerleri (yani %20) kesebiliriz. aralığı geri kalan değerler karşılık gelen blokların %80'i için harcanan süredir. 6.2.2 Boyut sınırları Kullanıcılar blockchain dosyasını depolamak için ödeme yapar ve boyutuna göre oy verme hakkına sahip olur. Her madenci maliyetleri dengelemek ile ücretlerden elde edilen karı dengelemek arasında karar verir ve kendi kararını verir Blok oluşturmak için “yumuşak limit”. Ayrıca maksimum blok boyutuna ilişkin temel kural aşağıdakiler için gereklidir: blockchain'nin sahte işlemlerle doldurulması engelleniyor, ancak bu değerin sabit kodlanmış olmayın. MN, son N blok boyutunun medyan değeri olsun. Daha sonra boyut için "zor sınır" Blok kabul etme oranı \(2 \cdot M_N\)'dir. blockchain öğesinin şişmesini önler ancak yine de sınırın aşılmasına izin verir Gerekirse zamanla yavaş yavaş büyüyün. İşlem boyutunun açıkça sınırlandırılmasına gerek yoktur. Bir bloğun boyutuyla sınırlıdır; ve eğer birisi yüzlerce girdi/çıktı (veya Halka imzalardaki belirsizlik derecesinin yüksek olması nedeniyle) bunu yeterli ücret ödeyerek yapabilir. 6.2.3 Aşırı boyut cezası Bir madenci hâlâ kendi sıfır ücretli işlemleriyle dolu bir bloğu maksimum seviyeye kadar doldurma yeteneğine sahiptir boyut \(2 \cdot M_b\). Her ne kadar madencilerin yalnızca çoğunluğu medyan değeri değiştirebilse de, hala 13 6 Diğer avantajlar 6.1 Sorunsuz emisyon CryptoNote dijital paralarının toplam miktarının üst sınırı şöyledir: MSarzı = 264 −1 atom birimleri. Bu, sezgiye değil, yalnızca uygulama sınırlarına dayanan doğal bir kısıtlamadır. "N tane para herkese yetmeli" gibi. Emisyon sürecinin düzgünlüğünü sağlamak için blok için aşağıdaki formülü kullanıyoruz: ödüller: Temel Ödül = (MSarzı −A) ≫18, burada A, daha önce üretilen madeni paraların miktarıdır. 6.2 Ayarlanabilir parametreler 6.2.1 Zorluk CryptoNote, her bloğun zorluğunu değiştiren bir hedefleme algoritması içerir. Bu Ağ hashhızının yoğun bir şekilde arttığı veya daraldığı durumlarda sistemin tepki süresini azaltır, sabit bir blok oranının korunması. Orijinal Bitcoin yöntemi, gerçek değer ilişkisini hesaplar ve son 2016 blok arasındaki zaman aralığını hedef alır ve bunu mevcut blok için çarpan olarak kullanır zorluk. Açıkçası bu, hızlı yeniden hesaplamalar için uygun değildir (büyük atalet nedeniyle) ve salınımlarla sonuçlanır. Algoritmamızın arkasındaki genel fikir, düğümlerin tamamladığı tüm işleri toplamak ve harcadıkları zamana bölün. İşin ölçüsü karşılık gelen zorluk değerleridir her blokta. Ancak yanlış ve güvenilmeyen zaman damgaları nedeniyle kesin zamanı belirleyemiyoruz bloklar arasındaki zaman aralığı. Kullanıcı zaman damgasını geleceğe ve bir sonraki zamana kaydırabilir aralıklar beklenmedik derecede küçük veya hatta negatif olabilir. Muhtemelen birkaç olay yaşanacak bu tür, böylece zaman damgalarını sıralayabilir ve aykırı değerleri (yani %20) kesebiliriz. aralığı geri kalan değerler karşılık gelen blokların %80'i için harcanan süredir. 6.2.2 Boyut sınırları Kullanıcılar blockchain dosyasını depolamak için ödeme yapar ve boyutuna göre oy verme hakkına sahip olur. Her madenci dengeleme arasındaki değiş tokuşla ilgilenirÜcretlerden maliyetleri ve karı kendisi belirler Blok oluşturmak için “yumuşak limit”. Ayrıca maksimum blok boyutuna ilişkin temel kural aşağıdakiler için gereklidir: blockchain'nin sahte işlemle doldurulması engelleniyor, ancak bu değerin sabit kodlanmış olmayın. MN, son N blok boyutunun medyan değeri olsun. Daha sonra boyut için "zor sınır" Blok kabul etme oranı \(2 \cdot M_N\)'dir. blockchain öğesinin şişmesini önler ancak yine de sınırın aşılmasına izin verir Gerekirse zamanla yavaş yavaş büyüyün. İşlem boyutunun açıkça sınırlandırılmasına gerek yoktur. Bir bloğun boyutuyla sınırlıdır; ve eğer birisi yüzlerce girdi/çıktı (veya Halka imzalardaki belirsizlik derecesinin yüksek olması nedeniyle) bunu yeterli ücret ödeyerek yapabilir. 6.2.3 Aşırı boyut cezası Bir madenci hâlâ kendi sıfır ücretli işlemleriyle dolu bir bloğu maksimum seviyeye kadar doldurma yeteneğine sahiptir boyut \(2 \cdot M_b\). Her ne kadar madencilerin yalnızca çoğunluğu medyan değeri değiştirebilse de, hala 13 23 Atomik birimler. Bunu sevdim. Bu Satoshi'nin eşdeğeri mi? Eğer öyleyse, bu 185 milyar kriptonot olacağı anlamına geliyor. Bunun eninde sonunda birkaç sayfada düzeltilmesi gerektiğini biliyorum, yoksa bir yazım hatası mı var? Temel ödül "kalan tüm paralar" ise tüm paraları almak için yalnızca bir blok yeterlidir. Instamine. Öte yandan, eğer bunun bir şekilde orantılı olması gerekiyorsa, şimdi ile madeni para üretim-sonlandırma-tarihi arasında zaman farkı var mı? bu olurdu mantıklı. Ayrıca benim dünyamda bunun gibi iki büyüktür işareti "çok daha büyük" anlamına gelir. Yazar mı muhtemelen başka bir şey mi kastediyorsun? Eğer zorluğa uyum her blokta gerçekleşirse, saldırganın çok büyük bir çiftliği olabilir. makineler dikkatle seçilmiş zaman aralıklarında madencilik yapar ve kapatır. Zorluk ayarlama formülleri uygun şekilde sönümlenmezse, bu durum zorlukta kaotik bir patlamaya (veya sıfıra çarpmaya) neden olabilir. Bitcoin'nin yönteminin hızlı yeniden hesaplamalar için uygun olmadığına şüphe yok, ancak eylemsizlik fikri bu sistemlerde olduğu gibi kabul edilmesi değil, kanıtlanması gerekir. Ayrıca salınımlar görünürde dalgalanmalara neden olmadığı sürece ağ zorluğu mutlaka bir sorun değildir. madeni para arzı - ve çok hızlı değişen bir zorluğa sahip olmak "aşırı düzeltmeye" neden olabilir. Özellikle birkaç dakika gibi kısa bir zaman diliminde harcanan zaman, "toplam" ile orantılı olacaktır. ağda oluşturulan blok sayısı." Orantılılık sabitinin kendisi büyüyecek zamanla, eğer CN başlarsa muhtemelen katlanarak. "Oluşturulan toplam blokları" korumak için zorluğu basitçe ayarlamak daha iyi bir fikir olabilir. Son bloğun ana zincire eklenmesinden bu yana ağ" sabit bir değer dahilinde veya sınırlı varyasyon veya buna benzer bir şey. Hesaplamalı uyarlanabilir bir algoritma ise uygulanması kolay belirlenebilirse, bu sorunu çözüyor gibi görünmektedir. Ancak bu yöntemi kullanırsak, büyük bir madencilik çiftliği olan birisi çiftliğini kapatabilir. birkaç saatliğine açın ve tekrar açın. İlk birkaç blokta o çiftlik banka. Yani aslında bu yöntem ilginç bir noktayı gündeme getiriyor: madencilik (ortalama olarak) bir Özellikle daha fazla insan ağa bağlandıkça yatırım getirisi olmadan oyunu kaybetmek. Madencilik zorluğu varsa ağ çok yakından takip ediliyor hashoranı, insanların bu kadar madencilik yapacağından bir şekilde şüpheliyim şu anda yapıyorum. Veya diğer taraftan madencilik çiftliklerini 7/24 çalışır durumda tutmak yerine, onları çevirebilirler. 6 saat açık, 2 saat kapalı, 6 saat açık, 2 saat kapalı veya bunun gibi bir şey. Sadece başka bir paraya geçin birkaç saat boyunca zorluğun düşmesini bekleyin, sonra birkaç ekstra kazanmak için tekrar atlayın ağ uyum sağladıkça karlılık blokları. Ve biliyor musun? Bu aslında muhtemelen Aklıma koyduğum en iyi madencilik senaryolarından biri... Bu döngüsel olabilir, ancak blok oluşturma süresi ortalama yaklaşık bir dakika ise, bunu yapabilir miyiz? "harcanan zaman" için blok sayısını temsili olarak mı kullanacaksınız?
6 Diğer avantajlar 6.1 Sorunsuz emisyon CryptoNote dijital paralarının toplam miktarının üst sınırı şöyledir: MSarzı = 264 −1 atom birimleri. Bu, sezgiye değil, yalnızca uygulama sınırlarına dayanan doğal bir kısıtlamadır. "N tane para herkese yetmeli" gibi. Emisyon sürecinin düzgünlüğünü sağlamak için blok için aşağıdaki formülü kullanıyoruz: ödüller: Temel Ödül = (MSarzı −A) ≫18, burada A, daha önce üretilen madeni paraların miktarıdır. 6.2 Ayarlanabilir parametreler 6.2.1 Zorluk CryptoNote, her bloğun zorluğunu değiştiren bir hedefleme algoritması içerir. Bu Ağ hashoranı yoğun bir şekilde büyüdüğünde veya daraldığında sistemin tepki süresini azaltır, sabit bir blok oranının korunması. Orijinal Bitcoin yöntemi, gerçek değer ilişkisini hesaplar ve son 2016 blok arasındaki zaman aralığını hedef alır ve bunu mevcut blok için çarpan olarak kullanır zorluk. Açıkçası bu, hızlı yeniden hesaplamalar için uygun değildir (büyük atalet nedeniyle) ve salınımlarla sonuçlanır. Algoritmamızın arkasındaki genel fikir, düğümlerin tamamladığı tüm işleri toplamak ve harcadıkları zamana bölün. İşin ölçüsü karşılık gelen zorluk değerleridir her blokta. Ancak yanlış ve güvenilmeyen zaman damgaları nedeniyle kesin zamanı belirleyemiyoruz bloklar arasındaki zaman aralığı. Kullanıcı zaman damgasını geleceğe ve bir sonraki zamana kaydırabilir aralıklar beklenmedik derecede küçük veya hatta negatif olabilir. Muhtemelen birkaç olay yaşanacak bu tür, böylece zaman damgalarını sıralayabilir ve aykırı değerleri (yani %20) kesebiliriz. aralığı geri kalan değerler karşılık gelen blokların %80'i için harcanan süredir. 6.2.2 Boyut sınırları Kullanıcılar blockchain dosyasını depolamak için ödeme yapar ve boyutuna göre oy kullanma hakkına sahip olur. Her madenci maliyetleri dengelemek ile ücretlerden elde edilen karı dengelemek arasında karar verir ve kendi kararını verir Blok oluşturmak için “yumuşak limit”. Ayrıca maksimum blok boyutuna ilişkin temel kural aşağıdakiler için gereklidir: blockchain'nin sahte işlemlerle doldurulması engelleniyor, ancak bu değerin sabit kodlanmış olmayın. MN, son N blok boyutunun medyan değeri olsun. Daha sonra boyut için "zor sınır" Blok kabul etme oranı \(2 \cdot M_N\)'dir. blockchain öğesinin şişmesini önler ancak yine de sınırın aşılmasına izin verir Gerekirse zamanla yavaş yavaş büyüyün. İşlem boyutunun açıkça sınırlandırılmasına gerek yoktur. Bir bloğun boyutuyla sınırlıdır; ve eğer birisi yüzlerce girdi/çıktı (veya Halka imzalardaki belirsizlik derecesinin yüksek olması nedeniyle) bunu yeterli ücret ödeyerek yapabilir. 6.2.3 Aşırı boyut cezası Bir madenci hâlâ kendi sıfır ücretli işlemleriyle dolu bir bloğu maksimum seviyeye kadar doldurma yeteneğine sahiptir boyut \(2 \cdot M_b\). Her ne kadar madencilerin yalnızca çoğunluğu medyan değeri değiştirebilse de, hala 13 6 Diğer avantajlar 6.1 Sorunsuz emisyon CryptoNote dijital paralarının toplam miktarının üst sınırı şöyledir: MSarzı = 264 −1 atom birimleri. Bu, sezgiye değil, yalnızca uygulama sınırlarına dayanan doğal bir kısıtlamadır. "N tane para herkese yetmeli" gibi. Emisyon sürecinin düzgünlüğünü sağlamak için blok için aşağıdaki formülü kullanıyoruz: ödüller: Temel Ödül = (MSarzı −A) ≫18, burada A, daha önce üretilen madeni paraların miktarıdır. 6.2 Ayarlanabilir parametreler 6.2.1 Zorluk CryptoNote, her bloğun zorluğunu değiştiren bir hedefleme algoritması içerir. Bu Ağ hashhızının yoğun şekilde arttığı veya daraldığı durumlarda sistemin tepki süresini azaltır, sabit bir blok oranının korunması. Orijinal Bitcoin yöntemi, gerçek değer ilişkisini hesaplar ve son 2016 blok arasındaki zaman aralığını hedef alır ve bunu mevcut blok için çarpan olarak kullanır zorluk. Açıkçası bu, hızlı yeniden hesaplamalar için uygun değildir (büyük atalet nedeniyle) ve salınımlarla sonuçlanır. Algoritmamızın arkasındaki genel fikir, düğümlerin tamamladığı tüm işleri toplamak ve harcadıkları zamana bölün. İşin ölçüsü karşılık gelen zorluk değerleridir her blokta. Ancak yanlış ve güvenilmeyen zaman damgaları nedeniyle kesin zamanı belirleyemiyoruz bloklar arasındaki zaman aralığı. Kullanıcı zaman damgasını geleceğe ve bir sonraki zamana kaydırabilir aralıklar beklenmedik derecede küçük veya hatta negatif olabilir. Muhtemelen birkaç olay yaşanacak bu tür, böylece zaman damgalarını sıralayabilir ve aykırı değerleri (yani %20) kesebiliriz. aralığı geri kalan değerler karşılık gelen blokların %80'i için harcanan süredir. 6.2.2 Boyut sınırları Kullanıcılar blockchain dosyasını depolamak için ödeme yapar ve boyutuna göre oy verme hakkına sahip olur. Her madenci dengeleme arasındaki değiş tokuşla ilgilenirÜcretlerden maliyetleri ve karı kendisi belirler Blok oluşturmak için “yumuşak limit”. Ayrıca maksimum blok boyutuna ilişkin temel kural aşağıdakiler için gereklidir: blockchain'nin sahte işlemlerle doldurulması engelleniyor, ancak bu değerin sabit kodlanmış olmayın. MN, son N blok boyutunun medyan değeri olsun. Daha sonra boyut için "zor sınır" Blok kabul etme oranı \(2 \cdot M_N\)'dir. blockchain öğesinin şişmesini önler ancak yine de sınırın aşılmasına izin verir Gerekirse zamanla yavaş yavaş büyüyün. İşlem boyutunun açıkça sınırlandırılmasına gerek yoktur. Bir bloğun boyutuyla sınırlıdır; ve eğer birisi yüzlerce girdi/çıktı (veya Halka imzalardaki belirsizlik derecesinin yüksek olması nedeniyle) bunu yeterli ücret ödeyerek yapabilir. 6.2.3 Aşırı boyut cezası Bir madenci hâlâ kendi sıfır ücretli işlemleriyle dolu bir bloğu maksimum seviyeye kadar doldurma yeteneğine sahiptir boyut \(2 \cdot M_b\). Her ne kadar madencilerin yalnızca çoğunluğu medyan değeri değiştirebilse de, hala 13 24 Tamam, elimizde bir blockchain var ve her blokta yalnızca zaman damgaları var EK OLARAK sipariş edildi. Bu açıkça ayarlamayı zorlaştırmak için eklenmiştir, çünkü zaman damgaları Bahsedildiği gibi çok güvenilmez. Zincirde çelişen zaman damgalarına sahip olmamıza izin veriliyor mu? Zincirde A Blok B Bloktan önce geliyorsa ve finansal açıdan her şey tutarlıysa, ancak A Blok, B Bloktan sonra oluşturulmuş gibi görünüyor? Çünkü belki birisinin sahibi ağın büyük bir kısmı? Tamam mı? Muhtemelen mali durum iyi olmadığı için. Tamam, bu keyfi "blokların yalnızca %80'i ana blockchain için meşru" olmasından nefret ediyorum yaklaşım. Yalancıların zaman damgalarını değiştirmesini engellemek için mi tasarlanmıştı? Ama şimdi ekliyor herkesin zaman damgaları hakkında yalan söylemesi ve sadece ortalamayı seçmesi için teşvik. Lütfen tanımlayın. Anlamı "Bu blok için yalnızca daha yüksek ücretler içeren işlemleri dahil edin" %p'den fazla, tercihen %2p'den yüksek ücretlerle" veya buna benzer bir şey mi? Sahte derken neyi kastediyorlar? İşlemin geçmiş geçmişiyle tutarlı olması durumunda blockchain ve işlem madencileri tatmin edecek ücretler içeriyor, bu yeterli değil mi? Peki, hayır, mutlaka değil. Maksimum blok boyutu yoksa, kötü niyetli bir kullanıcıyı tutacak hiçbir şey yoktur. Yavaşlamak için devasa bir işlem bloğunu tek seferde kendisine yüklemekten ağ. Maksimum blok boyutuna yönelik temel bir kural, insanların çok büyük miktarda çöp koymasını engeller işleri yavaşlatmak için blockchain üzerindeki verilerin hepsini aynı anda. Ancak böyle bir kuralın mutlaka Adaptif olun - örneğin Noel sezonunda trafiğin artmasını bekleyebiliriz ve blok boyutu çok büyüyecek ve hemen ardından blok boyutu düşecek tekrar. Yani ya a) bir çeşit uyarlanabilir üst sınıra ya da b) yeterince büyük bir üst sınıra ihtiyacımız var ki böylece %99'u makul Noel zirveleri sınırı aşmaz. Tabiki ikincisini yapmak imkansız tahmin - bir para biriminin tutunup tutunamayacağını kim bilebilir? Uyarlanabilir hale getirmek ve endişelenmemek daha iyi bu konuda. Ama sonra bir kontrol teorisi problemimiz var: bunu nasıl uyarlanabilir hale getireceğiz? saldırıya karşı savunmasızlık mı yoksa vahşi ve çılgın salınımlar mı? Uyarlanabilir bir yöntemin kötü niyetli kullanıcıların küçük miktarlar biriktirmesini engellemediğine dikkat edin blockchain üzerinde zamanla gereksiz verilerin birikmesi uzun vadeli şişkinliğe neden olur. Bu farklı bir konu tamamen ve kripto paraların ciddi sorunları olduğu bir durum.
6 Diğer avantajlar 6.1 Sorunsuz emisyon CryptoNote dijital paralarının toplam miktarının üst sınırı şöyledir: MSarzı = 264 −1 atom birimleri. Bu, sezgiye değil, yalnızca uygulama sınırlarına dayanan doğal bir kısıtlamadır. "N tane para herkese yetmeli" gibi. Emisyon sürecinin düzgünlüğünü sağlamak için blok için aşağıdaki formülü kullanıyoruz: ödüller: Temel Ödül = (MSarzı −A) ≫18, burada A, daha önce üretilen madeni paraların miktarıdır. 6.2 Ayarlanabilir parametreler 6.2.1 Zorluk CryptoNote, her bloğun zorluğunu değiştiren bir hedefleme algoritması içerir. Bu Ağ hashoranı yoğun bir şekilde büyüdüğünde veya daraldığında sistemin tepki süresini azaltır, sabit bir blok oranının korunması. Orijinal Bitcoin yöntemi gerçek değer ilişkisini hesaplar ve son 2016 blok arasındaki zaman aralığını hedef alır ve bunu mevcut blok için çarpan olarak kullanır zorluk. Açıkçası bu, hızlı yeniden hesaplamalar için uygun değildir (büyük atalet nedeniyle) ve salınımlarla sonuçlanır. Algoritmamızın arkasındaki genel fikir, düğümlerin tamamladığı tüm işleri toplamak ve harcadıkları zamana bölün. İşin ölçüsü karşılık gelen zorluk değerleridir her blokta. Ancak yanlış ve güvenilmeyen zaman damgaları nedeniyle kesin zamanı belirleyemiyoruz bloklar arasındaki zaman aralığı. Kullanıcı zaman damgasını geleceğe ve bir sonraki zamana kaydırabilir aralıklar beklenmedik derecede küçük veya hatta negatif olabilir. Muhtemelen birkaç olay yaşanacak bu tür, böylece zaman damgalarını sıralayabilir ve aykırı değerleri (yani %20) kesebiliriz. aralığı geri kalan değerler karşılık gelen blokların %80'i için harcanan süredir. 6.2.2 Boyut sınırları Kullanıcılar blockchain dosyasını depolamak için ödeme yapar ve boyutuna göre oy verme hakkına sahip olur. Her madenci maliyetleri dengelemek ile ücretlerden elde edilen karı dengelemek arasında karar verir ve kendi kararını verir Blok oluşturmak için “yumuşak limit”. Ayrıca maksimum blok boyutuna ilişkin temel kural aşağıdakiler için gereklidir: blockchain'nin sahte işlemlerle doldurulması engelleniyor, ancak bu değerin sabit kodlanmış olmayın. MN, son N blok boyutunun medyan değeri olsun. Daha sonra boyut için "zor sınır" Blok kabul etme oranı \(2 \cdot M_N\)'dir. blockchain öğesinin şişmesini önler ancak yine de sınırın aşılmasına izin verir Gerekirse zamanla yavaş yavaş büyüyün. İşlem boyutunun açıkça sınırlandırılmasına gerek yoktur. Bir bloğun boyutuyla sınırlıdır; ve eğer birisi yüzlerce girdi/çıktı (veya Halka imzalardaki belirsizlik derecesinin yüksek olması nedeniyle) bunu yeterli ücret ödeyerek yapabilir. 6.2.3 Aşırı boyut cezası Bir madenci hâlâ kendi sıfır ücretli işlemleriyle dolu bir bloğu maksimum seviyeye kadar doldurma yeteneğine sahiptir boyut \(2 \cdot M_b\). Her ne kadar madencilerin yalnızca çoğunluğu medyan değeri değiştirebilse de, hala 13 6 Diğer avantajlar 6.1 Sorunsuz emisyon CryptoNote dijital paralarının toplam miktarının üst sınırı şöyledir: MSarzı = 264 −1 atom birimleri. Bu, sezgiye değil, yalnızca uygulama sınırlarına dayanan doğal bir kısıtlamadır. "N tane para herkese yetmeli" gibi. Emisyon sürecinin düzgünlüğünü sağlamak için blok için aşağıdaki formülü kullanıyoruz: ödüller: Temel Ödül = (MSarzı −A) ≫18, burada A, daha önce üretilen madeni paraların miktarıdır. 6.2 Ayarlanabilir parametreler 6.2.1 Zorluk CryptoNote, her bloğun zorluğunu değiştiren bir hedefleme algoritması içerir. Bu Ağ hashhızının yoğun şekilde arttığı veya daraldığı durumlarda sistemin tepki süresini azaltır, sabit bir blok oranının korunması. Orijinal Bitcoin yöntemi, gerçek değer ilişkisini hesaplar ve son 2016 blok arasındaki zaman aralığını hedef alır ve bunu mevcut blok için çarpan olarak kullanır zorluk. Açıkçası bu, hızlı yeniden hesaplamalar için uygun değildir (büyük atalet nedeniyle) ve salınımlarla sonuçlanır. Algoritmamızın arkasındaki genel fikir, düğümlerin tamamladığı tüm işleri toplamak ve harcadıkları zamana bölün. İşin ölçüsü karşılık gelen zorluk değerleridir her blokta. Ancak yanlış ve güvenilmeyen zaman damgaları nedeniyle kesin zamanı belirleyemiyoruz bloklar arasındaki zaman aralığı. Kullanıcı zaman damgasını geleceğe ve bir sonraki zamana kaydırabilir aralıklar beklenmedik derecede küçük veya hatta negatif olabilir. Muhtemelen birkaç olay yaşanacak bu tür, böylece zaman damgalarını sıralayabilir ve aykırı değerleri (yani %20) kesebiliriz. aralığı geri kalan değerler karşılık gelen blokların %80'i için harcanan süredir. 6.2.2 Boyut sınırları Kullanıcılar blockchain dosyasını depolamak için ödeme yapar ve boyutuna göre oy verme hakkına sahip olur. Her madenci dengeleme arasındaki değiş tokuşla ilgilenirÜcretlerden maliyetleri ve karı kendisi belirler Blok oluşturmak için “yumuşak limit”. Ayrıca maksimum blok boyutuna ilişkin temel kural aşağıdakiler için gereklidir: blockchain'nin sahte işlemlerle doldurulması engelleniyor, ancak bu değerin sabit kodlanmış olmayın. MN, son N blok boyutunun medyan değeri olsun. Daha sonra boyut için "zor sınır" Blok kabul etme oranı \(2 \cdot M_N\)'dir. blockchain öğesinin şişmesini önler ancak yine de sınırın aşılmasına izin verir Gerekirse zamanla yavaş yavaş büyüyün. İşlem boyutunun açıkça sınırlandırılmasına gerek yoktur. Bir bloğun boyutuyla sınırlıdır; ve eğer birisi yüzlerce girdi/çıktı (veya Halka imzalardaki belirsizlik derecesinin yüksek olması nedeniyle) bunu yeterli ücret ödeyerek yapabilir. 6.2.3 Aşırı boyut cezası Bir madenci hâlâ kendi sıfır ücretli işlemleriyle dolu bir bloğu maksimum seviyeye kadar doldurma yeteneğine sahiptir boyut \(2 \cdot M_b\). Her ne kadar madencilerin yalnızca çoğunluğu medyan değeri değiştirebilse de, hala 13 25 Bir birim zaman N blok olacak şekilde zamanı yeniden ölçeklendirdiğimizde, ortalama blok boyutu yine de teorik olarak 2ˆt ile orantılı olarak üstel olarak büyüyebilir. Öte yandan, daha genel bir sınır sonraki blokta bazı f fonksiyonları için M_nf(M_n) olacaktır. f'nin hangi özellikleri Blok boyutunun bir miktar "makul büyümesini" garanti etmek için mi seçiyoruz? ilerlemesi blok boyutları (yeniden ölçeklendirme süresinden sonra) şöyle olur: 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( ... Buradaki amaç, f dizisini doğrusal olarak daha hızlı büyümeyecek şekilde seçmektir: veya belki Log(t) olarak bile. Elbette, eğer bir a sabiti için f(M_n) = a ise, bu dizi şu şekildedir: aslında M_n aM_n aˆ2M_n aˆ3M_n ... Ve elbette, bunu en fazla doğrusal büyümeyle sınırlamanın tek yolu a=1'i seçmektir. Bu elbette mümkün değildir. Hiçbir şekilde büyümeye izin vermiyor. Öte yandan f(M_n) sabit olmayan bir fonksiyon ise durum çok daha karmaşıktır. karmaşıktır ve zarif bir çözüme izin verebilir. Bir süre bunun üzerinde düşüneceğim. Bu ücretin bir sonraki bölümdeki aşırı boyut cezasını indirecek kadar büyük olması gerekecektir. Genel bir kullanıcının neden erkek olduğu varsayılıyor? Ha?
blockchain'yi şişirme ve düğümlerde ek yük oluşturma olasılığı. Cesaretini kırmak Kötü niyetli katılımcıların büyük bloklar oluşturmasını önleyen bir ceza fonksiyonu sunuyoruz: Yeni Ödül = Temel Ödül \(\cdot\) BlkBoyut MN −1 2 Bu kural yalnızca BlkSize minimum serbest blok boyutundan büyük olduğunda uygulanır; maksimuma yakın olmalıdır (10kb, MN \(\cdot\) %110). Madencilerin "normal boyutta" bloklar oluşturmasına izin veriliyor ve hatta Toplam ücretler cezayı aştığında bunu kârla aşarsınız. Ancak ücretlerin artması pek olası değil Ceza değerinden ikinci dereceden farklı olarak bir denge oluşacaktır. 6.3 İşlem komut dosyaları CryptoNote'un oldukça minimalist bir komut dosyası alt sistemi vardır. Gönderici bir ifade belirtir: Φ = f (x1, x2, . . . , xn), burada n, {Pi}n hedef genel anahtarlarının sayısıdır ben=1. Yalnızca beş ikili operatörler desteklenir: min, max, sum, mul ve cmp. Alıcı bu ödemeyi harcadığında, \(0 \leq k \leq n\) adet imza üretip bunları işlem girişine aktarır. Doğrulama süreci genel anahtar Pi için geçerli bir imza olup olmadığını kontrol etmek için Φ'yi xi = 1 ile değerlendirir ve xi = 0'dır. Doğrulayıcı, eğer > 0 ise ispatı kabul eder. Basitliğine rağmen bu yaklaşım olası her durumu kapsar: • Çoklu/Eşik imzası. Bitcoin tarzı "N'den M" çoklu imza için (ör. alıcı en az \(0 \leq M \leq N\) geçerli imza sağlamalıdır) Φ = x1+x2+. . .+xN \(\geq M\) (açıklık sağlamak için ortak cebirsel gösterimi kullanıyoruz). Ağırlıklı eşik imzası (bazı tuşlar diğerlerinden daha önemli olabilir) Φ = \(w_1 \cdot x_1\) + olarak ifade edilebilir \(w_2 \cdot x_2\) + . . . + \(w_N \cdot x_N\) \(\geq wM\). Ve ana anahtarın Φ ='ye karşılık geldiği senaryo maks(\(M \cdot x\), x1 + x2 + . . . + xN) \(\geq M\). Herhangi bir karmaşık durumun olabileceğini göstermek kolaydır. bu operatörlerle ifade edilir, yani temeli oluştururlar. • Şifre koruması. Gizli bir şifreye sahip olmak, onu bilmekle eşdeğerdir. deterministik olarak şu paroladan türetilen özel bir anahtar: k = KDF(ler). Dolayısıyla bir alıcı k anahtarının altına başka bir imza sağlayarak şifreyi bildiğini kanıtlayabilir. Gönderen, ilgili genel anahtarı kendi çıktısına ekler. Bunu unutmayın yöntem, Bitcoin [13]'da kullanılan "işlem bulmacasından" çok daha güvenlidir; Girişlerde şifre açıkça iletilir. • Dejenere vakalar. Φ = 1 herkesin parayı harcayabileceği anlamına gelir; Φ = 0, çıktının sonsuza kadar harcanamaz olması. Genel anahtarlarla birleştirilmiş çıktı betiğinin gönderen için çok büyük olması durumunda, alıcının bu verileri girişine koyacağını belirten özel çıktı türünü kullanabilir gönderen bunun yalnızca hash kısmını sağlar. Bu yaklaşım, Bitcoin'nin "hash'ye öde" yaklaşımına benzer özelliği, ancak yeni komut dosyası komutları eklemek yerine bu durumu veri yapısında ele alıyoruz seviye. 7 Sonuç Bitcoin'daki ana kusurları araştırdık ve bazı olası çözümler önerdik. Bu avantajlı özellikler ve devam eden gelişimimiz, CryptoNote'u yeni elektronik nakit sistemi haline getiriyor Bitcoin'nin ciddi bir rakibi, tüm çatallarını geride bırakıyor. 14 blockchain'yi şişirme ve düğümlerde ek yük oluşturma olasılığı. Cesaretini kırmak Kötü niyetli katılımcıların büyük bloklar oluşturmasını önleyen bir ceza fonksiyonu sunuyoruz: Yeni Ödül = Temel Ödül \(\cdot\) BlkBoyut MN −1 2 Bu kural yalnızca BlkSize minimum serbest blok boyutundan büyük olduğunda uygulanır; maksimuma yakın olmalıdır (10kb, MN \(\cdot\) %110). Madencilerin "normal boyutta" bloklar oluşturmasına izin veriliyor ve hatta Toplam ücretler cezayı aştığında bunu kârla aşarsınız. Ancak ücretlerin artması pek olası değil Ceza değerinden ikinci dereceden farklı olarak bir denge oluşacaktır. 6.3 İşlem komut dosyaları CryptoNote'un oldukça minimalist bir komut dosyası alt sistemi vardır. Gönderici bir ifade belirtir: Φ = f (x1, x2, . . . , xn), burada n, {Pi}n hedef genel anahtarlarının sayısıdır ben=1. Yalnızca beş ikili operatörler desteklenir: min, max, sum, mul ve cmp. Alıcı bu ödemeyi harcadığında, \(0 \leq k \leq n\) adet imza üretip bunları işlem girişine aktarır. Doğrulama süreci Pi ortak anahtarının geçerli bir imzasını kontrol etmek için Φ'yi xi = 1 ile değerlendirir ve xi = 0'dır. Doğrulayıcı, eğer > 0 ise ispatı kabul eder. Basitliğine rağmen bu yaklaşım olası her durumu kapsar: • Çoklu/Eşik imzası. Bitcoin tarzı "N'den M" çoklu imza için (ör. alıcı en az \(0 \leq M \leq N\) geçerli imza sağlamalıdır) Φ = x1+x2+. . .+xN \(\geq M\) (açıklık sağlamak için ortak cebirsel gösterimi kullanıyoruz). Ağırlıklı eşik imzası (bazı tuşlar diğerlerinden daha önemli olabilir) Φ = \(w_1 \cdot x_1\) + olarak ifade edilebilir \(w_2 \cdot x_2\) + . . . + \(w_N \cdot x_N\) \(\geq wM\). Ve senaryoio burada ana anahtar şuna karşılık gelir: Φ = maks(\(M \cdot x\), x1 + x2 + . . . + xN) \(\geq M\). Herhangi bir karmaşık durumun olabileceğini göstermek kolaydır. bu operatörlerle ifade edilir, yani temeli oluştururlar. • Şifre koruması. Gizli bir şifreye sahip olmak, onu bilmekle eşdeğerdir. deterministik olarak şu paroladan türetilen özel bir anahtar: k = KDF(ler). Dolayısıyla bir alıcı k anahtarının altına başka bir imza sağlayarak şifreyi bildiğini kanıtlayabilir. Gönderen, ilgili genel anahtarı kendi çıktısına ekler. Bunu unutmayın yöntem, Bitcoin [13]'de kullanılan "işlem bulmacasından" çok daha güvenlidir; Girişlerde şifre açıkça iletilir. • Dejenere vakalar. Φ = 1 herkesin parayı harcayabileceği anlamına gelir; Φ = 0, çıktının sonsuza kadar harcanamaz olması. Genel anahtarlarla birleştirilmiş çıktı betiğinin gönderen için çok büyük olması durumunda, alıcının bu verileri girişine koyacağını belirten özel çıktı türünü kullanabilir gönderen bunun yalnızca hash kısmını sağlar. Bu yaklaşım Bitcoin'nin "hash'ye öde" yaklaşımına benzer özelliği, ancak yeni komut dosyası komutları eklemek yerine bu durumu veri yapısında ele alıyoruz seviye. 7 Sonuç Bitcoin'deki ana kusurları araştırdık ve bazı olası çözümler önerdik. Bu avantajlı özellikler ve devam eden gelişimimiz, CryptoNote'u yeni elektronik nakit sistemi haline getiriyor Bitcoin'nin ciddi bir rakibi, tüm çatallarını geride bırakıyor. 14 26 Eğer zaman içinde blok boyutunu sınırlamanın bir yolunu bulabilirsek bu gereksiz olabilir... Bu da doğru olamaz. "NewReward"ı yukarıya bakan bir parabole yerleştirdiler. blok boyutu bağımsız değişkendir. Böylece yeni ödül sonsuza kadar patlar. Diğer taraftan ise elde, yeni ödül Max(0,Base Reward(1-(BlkSize/Mn - 1)ˆ2)) olur, ardından yeni ödül tepe noktası blok boyutunda = Mn olan ve kesişme noktaları olan aşağıya doğru bakan bir parabol olacaktır. Blokboyutu = 0 ve Blokboyutu = 2Mn. Ve tanımlamaya çalıştıkları şey de bu gibi görünüyor. Ancak bu durum
Analysis
Analysis
5 Not that it matters too much when a billion people in the world live on less than a dollar a day and have no hope in ever participating in any sort of mining network... but an economic world driven by a p2p currency system with one-cpu-one-vote would be, presumably, more fair than a system driven by fractional reserve banking. But Cryptonote’s protocol still requires 51% honest users... see, for example, the Cryptonote forums where one of the developers, Pliskov, says that a traditional replace-the-data-on-theblockchain 51% attack can still work. https://forum.cryptonote.org/viewtopic.php?f=2&t=198 Note that you don’t really need 51% honest users. You just really need "no single dishonest faction with more than 51% of the hashing power of the network." Let’s call this so-called problem of bitcoin "adaptive rigidity." Cryptonote’s solution to adaptive rigidity is adaptive flexibility in the protocol parameter values. If you need block sizes bigger, no problem, the network will have been gently adjusting the whole time. That is to say, the way that Bitcoin adjusts difficulty over time can be replicated across all of our protocol parameters so that network consensus need not be obtained for updating the protocol. On the surface this seems like a good idea, but without careful forethought, a self-adjusting system can become quite unpredictable and chaotic. We’ll look further into this later as the opportunities arise. "Good" systems are somewhere between adaptively rigid and adaptively flexible, and perhaps even the rigidity itself are adaptive. If we truly had "one-CPU-one-vote," then collaborating and developing pools to get to 51% would be more difficult. We would expect every CPU in the world to be mining, from phones to the on-board CPU in your Tesla while it’s charging. http://en.wikipedia.org/wiki/Pareto_principle I claim that the Pareto equilibrium is somewhat unavoidable. Either 20% of the system will own 80% of the CPUs, or 20% of the system will own 80% of the ASICs. I hypothesize this because the underlying distribution of wealth in society already exhibits the Pareto distribution, and as new miners join up, they are drawn from that underlying distribution. However, I argue that protocols with one-cpu-one-vote will see ROI on hardware. Block reward per node will be more closely proportional to number of nodes in the network because distribution of performance across the nodes will be much more tight. Bitcoin, on the other hand, sees a block reward (per node) more proportional to the computational capacity of that node. That is to say, only the "big boys" are still in the mining game. On the other hand, even though the Pareto principle will still be in play, in a one-cpu-one-vote world, everyone participates in network security and gains a bit of mining income. In an ASIC world, it’s not sensible to rig every XBox and cell phone to mine. In a onecpu-one-vote world, it’s very sensible in terms of mining reward. As a delightful consequence, gaining 51% of the vote is more difficult when there are more and more votes, yielding a lovely benefit to network security..
hardware described previously. Suppose that the global hashrate decreases significantly, even for a moment, he can now use his mining power to fork the chain and double-spend. As we shall see later in this article, it is not unlikely for the previously described event to take place. 2.3 Irregular emission Bitcoin has a predetermined emission rate: each solved block produces a fixed amount of coins. Approximately every four years this reward is halved. The original intention was to create a limited smooth emission with exponential decay, but in fact we have a piecewise linear emission function whose breakpoints may cause problems to the Bitcoin infrastructure. When the breakpoint occurs, miners start to receive only half of the value of their previous reward. The absolute difference between 12.5 and 6.25 BTC (projected for the year 2020) may seem tolerable. However, when examining the 50 to 25 BTC drop that took place on November 28 2012, felt inappropriate for a significant number of members of the mining community. Figure 1 shows a dramatic decrease in the network’s hashrate in the end of November, exactly when the halving took place. This event could have been the perfect moment for the malevolent individual described in the proof-of-work function section to carry-out a double spending attack [36]. Fig. 1. Bitcoin hashrate chart (source: http://bitcoin.sipa.be) 2.4 Hardcoded constants Bitcoin has many hard-coded limits, where some are natural elements of the original design (e.g. block frequency, maximum amount of money supply, number of confirmations) whereas other seem to be artificial constraints. It is not so much the limits, as the inability of quickly changing 3 hardware described previously. Suppose that the global hashrate decreases significantly, even for a moment, he can now use his mining power to fork the chain and double-spend. As we shall see later in this article, it is not unlikely for the previously described event to take place. 2.3 Irregular emission Bitcoin has a predetermined emission rate: each solved block produces a fixed amount of coins. Approximately every four years this reward is halved. The original intention was to create a limited smooth emission with exponential decay, but in fact we have a piecewise linear emission function whose breakpoints may cause problems to the Bitcoin infrastructure. When the breakpoint occurs, miners start to receive only half of the value of their previous reward. The absolute difference between 12.5 and 6.25 BTC (projected for the year 2020) may seem tolerable. However, when examining the 50 to 25 BTC drop that took place on November 28 2012, felt inappropriate for a significant number of members of the mining community. Figure 1 shows a dramatic decrease in the network’s hashrate in the end of November, exactly when the halving took place. This event could have been the perfect moment for the malevolent individual described in the proof-of-work function section to carry-out a double spending attack [36]. Fig. 1. Bitcoin hashrate chart (source: http://bitcoin.sipa.be) 2.4 Hardcoded constants Bitcoin has many hard-coded limits, where some are natural elements of the original design (e.g. block frequency, maximum amount of money supply, number of confirmations) whereas other seem to be artificial constraints. It is not so much the limits, as the inability of quickly changing 3 6 Let’s call this what it is, a zombie attack. Let’s discuss how continuous emission may be related to one-cpu-one-vote in a zombie attack scenario. In a one-cpu-one-vote world, every cell phone and car, whenever idle, would be mining. Collecting heaps of cheap hardware to create a mining farm would be very very easy, because just about everything has a CPU in it. On the other hand, at that point, the number of CPUs required to launch a 51% attack would be quite astonishing, I would think. Furthermore, precisely because it would be easy to collect cheap hardware, we can reasonably expect a lot of folks to start hoarding anything with a CPU. The arms race in a one-cpu-one-vote world is necessarily more egalitarian than in an ASIC world. Hence, a discontinuity in network security due to emission rates should be LESS of a problem in a one-cpu-one-vote world. However, two facts remain: 1) discontinuity in emission rate can lead to a stuttering effect in the economy and in network security both, which is bad, and 2) even though a 51% attack performed by someone collecting cheap hardware can still occur in a one-cpu-one-vote world, it seems like it should be harder. Presumably, the safeguard against this is that all the dishonest actors will be trying this simultaneously, and we fall back to Bitcoin’s previous security notion: "we require no dishonest faction to control more than 51% of the network." The author is claiming here that one problem with bitcoin is that discontinuity in coin emission rate could lead to sudden drops in network participation, and hence network security. Thus, a continuous, differentiable, smooth coin emission rate is preferable. The author ain’t wrong, necessarily. Any sort of sudden decrease in network participation can lead to such a problem, and if we can remove one source of it, we should. Having said that, it’s possible that long periods of "relatively constant" coin emission punctuated by sudden changes is the ideal way to go from an economics point of view. I’m not an economist. So, perhaps we must decide if we are going to trade network security for economic something-whatsit here? http://arxiv.org/abs/1402.2009
them if necessary that causes the main drawbacks. Unfortunately, it is hard to predict when the
constants may need to be changed and replacing them may lead to terrible consequences.
A good example of a hardcoded limit change leading to disastrous consequences is the block
size limit set to 250kb1. This limit was sufficient to hold about 10000 standard transactions. In
early 2013, this limit had almost been reached and an agreement was reached to increase the
limit. The change was implemented in wallet version 0.8 and ended with a 24-blocks chain split
and a successful double-spend attack [9]. While the bug was not in the Bitcoin protocol, but
rather in the database engine it could have been easily caught by a simple stress test if there was
no artificially introduced block size limit.
Constants also act as a form of centralization point.
Despite the peer-to-peer nature of
Bitcoin, an overwhelming majority of nodes use the official reference client [10] developed by
a small group of people. This group makes the decision to implement changes to the protocol
and most people accept these changes irrespective of their “correctness”. Some decisions caused
heated discussions and even calls for boycott [11], which indicates that the community and the
developers may disagree on some important points. It therefore seems logical to have a protocol
with user-configurable and self-adjusting variables as a possible way to avoid these problems.
2.5
Bulky scripts
The scripting system in Bitcoin is a heavy and complex feature. It potentially allows one to create
sophisticated transactions [12], but some of its features are disabled due to security concerns and
some have never even been used [13]. The script (including both senders’ and receivers’ parts)
for the most popular transaction in Bitcoin looks like this:
Analiz
5
Dünyada bir milyar insanın günde bir dolardan daha az bir parayla yaşaması pek de önemli değil.
ve herhangi bir madencilik ağına katılma konusunda hiçbir umudum yok... ama ekonomik bir
Bir işlemci-bir oy ilkesine dayalı bir p2p para sistemi tarafından yönlendirilen dünya, muhtemelen daha fazla olacaktır.
Kısmi rezerv bankacılığının yönlendirdiği bir sistemden daha adil.
Ancak Cryptonote'un protokolü hala %51 dürüst kullanıcı gerektiriyor... örneğin Cryptonote'a bakın
Geliştiricilerden biri olan Pliskov'un, geleneksel veriyi değiştirmeblockchain %51 saldırısının hala işe yarayabileceğini söylediği forumlarda. https://forum.cryptonote.org/viewtopic.php?f=2&t=198
Gerçekten %51 dürüst kullanıcıya ihtiyacınız olmadığını unutmayın. Gerçekten ihtiyacın olan tek bir sahtekârın olmaması
ağın hashing gücünün %51'inden fazlasına sahip olan grup."
Bitcoin'in bu sözde sorununa "adaptif katılık" adını verelim. Cryptonote'un uyarlanabilirlik çözümü
katılık, protokol parametre değerlerinde uyarlanabilir esnekliktir. Daha büyük blok boyutlarına ihtiyacınız varsa,
sorun değil, ağ sürekli olarak yavaş yavaş ayarlanıyor olacaktır.
Yani,
Bitcoin'in zaman içinde zorluğu ayarlama şekli tüm protokolümüzde kopyalanabilir
Böylece protokolün güncellenmesi için ağ konsensusunun elde edilmesine gerek kalmaz.
Görünüşte bu iyi bir fikir gibi görünüyor, ancak dikkatli bir öngörü olmadan, kendi kendini ayarlayan bir
sistem oldukça öngörülemez ve kaotik hale gelebilir. Bu konuyu daha sonra detaylı olarak inceleyeceğiz
fırsatlar ortaya çıkıyor. "İyi" sistemler uyarlanabilir katı ve uyarlanabilir arasında bir yerdedir
esnektir ve belki de katılığın kendisi bile uyarlanabilirdir.
Eğer gerçekten "bir CPU-bir oy"a sahip olsaydık, %51'e ulaşmak için işbirliği yapıp havuzlar geliştirebilirdik
daha zor olurdu. Dünyadaki her CPU'nun telefonlardan madencilik yapmasını beklerdik
Tesla'nız şarj olurken yerleşik CPU'ya.
http://en.wikipedia.org/wiki/Pareto_principle
Pareto dengesinin bir şekilde kaçınılmaz olduğunu iddia ediyorum. Sistemin %20'si
CPU'ların %80'ine sahip olacak veya sistemin %20'si ASIC'lerin %80'ine sahip olacak. Bunu varsayıyorum çünkü toplumdaki temel zenginlik dağılımı zaten Pareto dağılımını gösteriyor,
ve yeni madenciler katıldıkça bu temel dağılımdan yararlanıyorlar.
Ancak, bir işlemci-bir oy ilkesine dayalı protokollerin donanım üzerinde yatırım getirisi göreceğini savunuyorum.
Blok
Düğüm başına ödül, ağdaki düğüm sayısıyla daha yakından orantılı olacaktır çünkü
Performansın düğümler arasındaki dağılımı çok daha sıkı olacaktır. Bitcoin, diğer tarafta
bir blok ödülünün (düğüm başına) hesaplama kapasitesiyle daha orantılı olduğunu düşünüyor
düğüm. Yani madencilik oyununda hâlâ yalnızca "büyük adamlar" var. Öte yandan,
Pareto ilkesi hâlâ yürürlükte olsa da, bir işlemcinin bir oy olduğu bir dünyada herkes
ağ güvenliğine katılır ve bir miktar madencilik geliri elde eder.
ASIC dünyasında, her XBox'u ve cep telefonunu madencilik için donatmak mantıklı değil.
Tek işlemcili bir oy dünyasında, madencilik ödülü açısından bu çok mantıklı. Keyifli bir sonuç olarak,
Oyların sayısı arttıkça %51 oy almak daha zor oluyor ve bu da güzel bir sonuç sağlıyor.
ağ güvenliğine fayda sağlar..Daha önce açıklanan donanım. Küresel hashoranın önemli ölçüde azaldığını varsayalım.
Bir anlığına artık madencilik gücünü kullanarak zinciri çatallayabilir ve çift harcama yapabilir. Göreceğimiz gibi
Bu makalenin ilerleyen kısımlarında, daha önce anlatılan olayın gerçekleşmesi pek olası değildir.
2.3
Düzensiz emisyon
Bitcoin önceden belirlenmiş bir emisyon oranına sahiptir: çözülen her blok sabit miktarda para üretir.
Yaklaşık her dört yılda bir bu ödül yarıya indirilir. Asıl amaç bir yaratmaktı
üstel bozulma ile sınırlı düzgün emisyon, ancak aslında parçalı doğrusal bir emisyona sahibiz
kesme noktaları Bitcoin altyapısında sorunlara neden olabilecek işlev.
Kırılma noktası oluştuğunda madenciler önceki değerlerinin yalnızca yarısını almaya başlarlar.
ödül. 12,5 ile 6,25 BTC (2020 yılı için öngörülen) arasındaki mutlak fark,
tolere edilebilir görünüyor. Ancak Kasım ayında gerçekleşen 50 ila 25 BTC düşüşünü incelerken
28 2012, madencilik camiasının önemli sayıda üyesi için uygunsuz bulundu. Şekil
Şekil 1, Kasım ayı sonunda ağın hashoranında çarpıcı bir düşüş gösteriyor;
yarılanma gerçekleşti. Bu olay kötü niyetli birey için mükemmel bir an olabilirdi.
proof-of-work işlev bölümünde çift harcama saldırısı [36] gerçekleştirmek için açıklanmıştır.
Şekil 1. Bitcoin hashoran tablosu
(kaynak: http://bitcoin.sipa.be)
2.4
Sabit kodlanmış sabitler
Bitcoin, bazıları orijinal tasarımın doğal unsurları olan birçok sabit kodlanmış sınıra sahiptir (ör.
blok sıklığı, maksimum para arzı miktarı, onay sayısı) ve diğer
yapay kısıtlamalar gibi görünüyor. Hızla değişememe gibi, sınırlar da değil
3
Daha önce açıklanan donanım. Küresel hashoranın önemli ölçüde azaldığını varsayalım.
Bir anlığına artık madencilik gücünü kullanarak zinciri çatallayabilir ve çift harcama yapabilir. Göreceğimiz gibi
Bu makalenin ilerleyen kısımlarında, daha önce anlatılan olayın gerçekleşmesi pek olası değildir.
2.3
Düzensiz emisyon
Bitcoin önceden belirlenmiş bir emisyon oranına sahiptir: çözülen her blok sabit miktarda para üretir.
Yaklaşık her dört yılda bir bu ödül yarıya indirilir. Asıl amaç bir yaratmaktı
üstel bozulma ile sınırlı düzgün emisyon, ancak aslında parçalı doğrusal bir emisyona sahibiz
kesme noktaları Bitcoin altyapısında sorunlara neden olabilecek işlev.
Kırılma noktası oluştuğunda madenciler önceki değerlerinin yalnızca yarısını almaya başlarlar.
ödül. 12,5 ile 6,25 BTC (2020 yılı için öngörülen) arasındaki mutlak fark,
tolere edilebilir görünüyor. Ancak Kasım ayında gerçekleşen 50 ila 25 BTC düşüşünü incelerken
28 2012, madencilik camiasının önemli sayıda üyesi için uygunsuz bulundu. Şekil
Şekil 1, Kasım ayı sonunda ağın hashoranında çarpıcı bir düşüş gösteriyor;
yarılanma gerçekleşti. Bu olay kötü niyetli birey için mükemmel bir an olabilirdi.
proof-of-work işlev bölümünde çift harcama saldırısı [36] gerçekleştirmek için açıklanmıştır.
Şekil 1. Bitcoin hashoran tablosu
(kaynak: http://bitcoin.sipa.be)
2.4
Sabit kodlanmış sabitler
Bitcoin, bazıları orijinal tasarımın doğal unsurları olan birçok sabit kodlanmış sınıra sahiptir (ör.
blok sıklığı, maksimum para arzı miktarı, onay sayısı) ve diğer
yapay kısıtlamalar gibi görünüyor. Hızla değişememe gibi, sınırlar da değil
3
6
Buna bir zombi saldırısı diyelim.
Sürekli emisyonun nasıl olabileceğini tartışalım
zombi saldırısı senaryosunda bir işlemci bir oy ile ilgili.
Tek işlemcinin tek oy olduğu bir dünyada, her cep telefonu ve araba boşta kaldığında madencilik yapıyor olurdu. Bir madencilik çiftliği oluşturmak için yığınla ucuz donanım toplamak çok çok kolay olurdu çünkü
neredeyse her şeyin içinde bir CPU vardır. Öte yandan, bu noktada CPU sayısı
% 51'lik bir saldırı başlatmak için gerekli olanın oldukça şaşırtıcı olacağını düşünüyorum.
Ayrıca,
kesinlikle çünkü ucuz donanım toplamak kolay olacaktır, makul bir şekilde
Pek çok insan CPU ile her şeyi istiflemeye başlıyor. Tek işlemcinin tek oy olduğu bir dünyada silahlanma yarışı
ASIC dünyasına göre mutlaka daha eşitlikçidir.
Bu nedenle ağda bir süreksizlik
Emisyon oranlarından kaynaklanan güvenlik, tek işlemcinin bir oy olduğu bir dünyada DAHA AZ sorun olmalıdır.
Ancak geriye iki gerçek kalıyor: 1) Emisyon oranındaki süreksizlik, emisyon oranında kekemelik etkisine yol açabilir.
hem ekonomi hem de ağ güvenliği açısından kötü, ve 2) %51'lik bir saldırı olmasına rağmen
Ucuz donanım toplayan biri tarafından gerçekleştirilen tek işlemcili bir bilgisayarda da gerçekleşebilir-oy ver dünya,
sanki daha zor olmalı.
Muhtemelen buna karşı önlem, tüm sahtekâr aktörlerin bunu deneyecek olmasıdır
eşzamanlı olarak Bitcoin'nin önceki güvenlik kavramına geri dönüyoruz: "dürüst olmayanlara ihtiyacımız yok
ağın %51'inden fazlasını kontrol eden grup."
Yazar burada bitcoin ile ilgili bir problemin madeni para emisyonundaki süreksizlik olduğunu iddia ediyor
oranı, ağ katılımında ve dolayısıyla ağ güvenliğinde ani düşüşlere neden olabilir. Böylece,
sürekli, farklılaştırılabilir, düzgün bir madeni para emisyon oranı tercih edilir.
Yazar mutlaka hatalı değil. Ağ katılımındaki herhangi bir ani düşüş,
böyle bir soruna yol açıyor ve eğer bunun bir kaynağını ortadan kaldırabiliyorsak bunu kaldırmalıyız. Bunu söyledikten sonra,
Uzun süreli "nispeten sabit" madeni para emisyonunun ani değişikliklerle kesintiye uğraması mümkün
ekonomik açıdan gidilecek ideal yoldur. Ben bir ekonomist değilim. Yani belki biz
Ağ güvenliğini ekonomik bir şeyle takas edip etmeyeceğimize karar vermemiz gerekiyor; burada ne var?
http://arxiv.org/abs/1402.2009Gerektiğinde bunları kullanmak ana dezavantajlara neden olur. Maalesef ne zaman geleceğini tahmin etmek zor.
sabitlerin değiştirilmesi gerekebilir ve bunların değiştirilmesi korkunç sonuçlara yol açabilir.
Felaket sonuçlara yol açan sabit kodlanmış bir limit değişikliğine iyi bir örnek, bloktur.
boyut sınırı 250kb1 olarak ayarlandı. Bu limit yaklaşık 10.000 standart işlemi tutmaya yetiyordu. içinde
2013 yılının başında bu sınıra neredeyse ulaşıldı ve bu limitin artırılması konusunda anlaşmaya varıldı.
Sınır. Değişiklik cüzdan 0.8 sürümünde uygulandı ve 24 blokluk zincir bölünmesiyle sona erdi
ve başarılı bir çift harcama saldırısı [9]. Hata Bitcoin protokolünde olmasa da
bunun yerine veritabanı motorunda, eğer varsa basit bir stres testiyle kolayca yakalanabilirdi.
yapay olarak getirilmiş blok boyutu sınırı yoktur.
Sabitler ayrıca bir tür merkezileştirme noktası görevi görür.
Eşler arası doğasına rağmen
Bitcoin, düğümlerin büyük çoğunluğu tarafından geliştirilen resmi referans istemcisi [10] kullanılıyor
küçük bir grup insan. Bu grup protokolde değişiklik yapılmasına karar verir
ve çoğu insan bu değişiklikleri “doğruluklarına” bakılmaksızın kabul ediyor. Bazı kararlar neden oldu
hararetli tartışmalar ve hatta boykot çağrıları [11], bu da topluluğun ve
geliştiriciler bazı önemli noktalarda aynı fikirde olmayabilir. Bu nedenle bir protokole sahip olmak mantıklı görünüyor
Bu sorunları önlemenin olası bir yolu olarak kullanıcı tarafından yapılandırılabilen ve kendi kendini ayarlayan değişkenler kullanılır.
2.5
Hacimli komut dosyaları
Bitcoin'deki komut dosyası sistemi ağır ve karmaşık bir özelliktir. Potansiyel olarak kişinin yaratmasına izin verir
karmaşık işlemler [12], ancak güvenlik endişeleri nedeniyle bazı özellikleri devre dışı bırakıldı ve
bazıları hiç kullanılmamış bile [13]. Komut dosyası (hem gönderici hem de alıcı kısımları dahil)
Bitcoin'daki en popüler işlem için şuna benzer: