CryptoNote v2.0

By Nicolas van Saberhagen · 2013

The paper presented here is the CryptoNote v2.0 whitepaper by Nicolas van Saberhagen (2013), which describes the cryptographic foundations that Monero is built upon. It is not a Monero-specific whitepaper — Monero launched in 2014 as a fork of the CryptoNote reference implementation (Bytecoin) and has since evolved significantly beyond the original protocol.

🇺🇸 English (Original)

🇮🇩 Bahasa Indonesia (Translation)

Introduction

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

Perkenalan

“Bitcoin” [1] telah berhasil menerapkan konsep uang elektronik p2p. Keduanya para profesional dan masyarakat umum mulai menghargai kombinasi yang nyaman dari transaksi publik dan proof-of-work sebagai model kepercayaan. Saat ini, basis pengguna uang elektronik tumbuh dengan kecepatan yang stabil; pelanggan tertarik dengan biaya rendah dan anonimitas yang diberikan oleh uang elektronik dan pedagang menilai emisi yang diprediksi dan didesentralisasi. Bitcoin punya secara efektif membuktikan bahwa uang elektronik bisa sesederhana uang kertas dan senyaman mungkin kartu kredit. Sayangnya, Bitcoin mempunyai beberapa kekurangan. Misalnya saja sistem terdistribusi sifatnya tidak fleksibel, mencegah penerapan fitur-fitur baru hingga hampir semua pengguna jaringan memperbarui klien mereka. Beberapa kelemahan kritis yang tidak dapat diperbaiki dengan cepat menghalangi Bitcoin penyebarannya secara luas. Dalam model yang tidak fleksibel seperti ini, akan lebih efisien jika meluncurkan proyek baru daripada terus-menerus memperbaiki proyek aslinya. Dalam makalah ini, kami mempelajari dan mengusulkan solusi terhadap kekurangan utama Bitcoin. Kami percaya bahwa sistem yang mempertimbangkan solusi yang kami usulkan akan menghasilkan persaingan yang sehat antara sistem kas elektronik yang berbeda. Kami juga mengusulkan uang elektronik kami sendiri, “CryptoNote”, sebuah nama yang menekankan terobosan berikutnya dalam uang elektronik.

Bitcoin Drawbacks and Possible Solutions

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

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

Bitcoin Kekurangan dan Kemungkinan Solusinya

2 Bitcoin kekurangan dan beberapa kemungkinan solusi 2.1 Ketertelusuran transaksi Privasi dan anonimitas adalah aspek terpenting dari uang elektronik. Pembayaran antar rekan berusaha untuk disembunyikan dari pandangan pihak ketiga, perbedaan yang nyata jika dibandingkan dengan tradisional perbankan. Secara khusus, T. Okamoto dan K. Ohta menjelaskan enam kriteria uang elektronik yang ideal, yang mencakup “privasi: hubungan antara pengguna dan pembeliannya harus tidak dapat dilacak oleh siapa pun” [30]. Dari uraiannya, kami memperoleh dua properti yang sepenuhnya anonim model uang elektronik harus memenuhi persyaratan yang digariskan oleh Okamoto dan Ohta: Untraceability: untuk setiap transaksi masuk, semua pengirim yang mungkin memiliki kemungkinan yang sama. Tidak dapat dihubungkan: untuk dua transaksi keluar mana pun, tidak mungkin dibuktikan bahwa mereka telah dikirim orang yang sama. Sayangnya, Bitcoin tidak memenuhi persyaratan tidak dapat dilacak. Karena semua transaksi yang terjadi di antara peserta jaringan bersifat publik, maka transaksi apa pun bisa bersifat publik 1 Catatan Kripto v 2.0 Nicolas van Saberhagen 17 Oktober 2013 1 Pendahuluan “Bitcoin” [1] telah berhasil menerapkan konsep uang elektronik p2p. Keduanya para profesional dan masyarakat umum mulai menghargai kombinasi yang nyaman dari transaksi publik dan proof-of-work sebagai model kepercayaan. Saat ini, basis pengguna uang elektronik tumbuh dengan kecepatan yang stabil; pelanggan tertarik dengan biaya rendah dan anonimitas yang diberikan oleh uang elektronik dan pedagang menilai emisi yang diprediksi dan didesentralisasi. Bitcoin punya secara efektif membuktikan bahwa uang elektronik bisa sesederhana uang kertas dan senyaman mungkin kartu kredit. Sayangnya, Bitcoin mempunyai beberapa kekurangan. Misalnya saja sistem terdistribusi sifatnya tidak fleksibel, mencegah penerapan fitur-fitur baru hingga hampir semua pengguna jaringan memperbarui klien mereka. Beberapa kelemahan kritis yang tidak dapat diperbaiki dengan cepat menghalangi Bitcoin penyebarannya secara luas. Dalam model yang tidak fleksibel seperti ini, akan lebih efisien jika meluncurkan proyek baru daripada terus-menerus memperbaiki proyek aslinya. Dalam makalah ini, kami mempelajari dan mengusulkan solusi terhadap kekurangan utama Bitcoin. Kami percaya bahwa sistem yang mempertimbangkan solusi yang kami usulkan akan menghasilkan persaingan yang sehat antara sistem kas elektronik yang berbeda. Kami juga mengusulkan uang elektronik kami sendiri, “CryptoNote”, sebuah nama yang menekankan terobosan berikutnya dalam uang elektronik. 2 Bitcoin kekurangan dan beberapa kemungkinan solusi 2.1 Ketertelusuran transaksi Privasi dan anonimitas adalah aspek terpenting dari uang elektronik. Pembayaran antar rekan berusaha untuk disembunyikan dari pandangan pihak ketiga, perbedaan yang nyata jika dibandingkan dengan tradisional perbankan. Secara khusus, T. Okamoto dan K. Ohta menjelaskan enam kriteria uang elektronik yang ideal, yang mencakup “privasi: hubungan antara pengguna dan pembeliannya harus tidak dapat dilacak oleh siapa pun” [30]. Dari uraiannya, kami memperoleh dua properti yang sepenuhnya anonim model uang elektronik harus memenuhi persyaratan yang digariskan oleh Okamoto dan Ohta: Untraceability: untuk setiap transaksi masuk, semua pengirim yang mungkin memiliki kemungkinan yang sama. Tidak dapat dihubungkan: untuk dua transaksi keluar mana pun, tidak mungkin dibuktikan bahwa mereka telah dikirim orang yang sama. Sayangnya, Bitcoin tidak memenuhi persyaratan tidak dapat dilacak. Karena semua transaksi yang terjadi di antara peserta jaringan bersifat publik, maka transaksi apa pun bisa bersifat publik 1 3 Bitcoin pasti gagal dalam "tidak dapat dilacak". Saat saya mengirimi Anda BTC, dompet asal pengirimannya dicap secara tidak dapat ditarik kembali pada blockchain. Tidak ada pertanyaan tentang siapa yang mengirim dana tersebut, karena hanya orang yang mengetahui kunci privat yang dapat mengirimkannya.ditelusuri secara jelas ke asal yang unik dan penerima akhir. Bahkan jika dua peserta bertukar dana secara tidak langsung, metode pencarian jalur yang dirancang dengan baik akan mengungkap asal usul dan penerima akhir. Diduga juga Bitcoin tidak memenuhi properti kedua. Beberapa peneliti menyatakan ([33, 35, 29, 31]) bahwa analisis blockchain yang cermat dapat mengungkapkan hubungan antara pengguna jaringan Bitcoin dan transaksinya. Meskipun ada beberapa metode yang bisa dilakukan disengketakan [25], diduga banyak informasi pribadi tersembunyi yang dapat diambil dari basis data publik. Kegagalan Bitcoin dalam memenuhi kedua sifat yang diuraikan di atas membuat kita menyimpulkan bahwa hal tersebut memang benar adanya bukan sistem kas elektronik anonim melainkan sistem kas elektronik pseudo-anonim. Pengguna cepat berkembang solusi untuk menghindari kelemahan ini. Dua solusi langsung adalah “layanan pencucian” [2] dan pengembangan metode terdistribusi [3, 4]. Kedua solusi tersebut didasarkan pada gagasan pencampuran beberapa transaksi publik dan mengirimkannya melalui beberapa alamat perantara; yang pada gilirannya menderita kelemahan karena membutuhkan pihak ketiga yang tepercaya. Baru-baru ini, skema yang lebih kreatif diusulkan oleh I. Miers dkk. [28]: “Nolkoin”. nol koin menggunakan akumulator kriptografi satu arah dan bukti tanpa pengetahuan yang memungkinkan pengguna melakukannya “konversi” bitcoin menjadi zerocoin dan belanjakan menggunakan bukti kepemilikan anonim tanda tangan digital berbasis kunci publik yang eksplisit. Namun, bukti-bukti pengetahuan tersebut mempunyai keteguhan tetapi ukurannya tidak nyaman - sekitar 30kb (berdasarkan batas Bitcoin saat ini), yang membuat proposal tidak praktis. Penulis mengakui bahwa protokol tersebut kemungkinan besar tidak akan pernah diterima oleh mayoritas orang Bitcoin pengguna [5]. 2.2 Fungsi proof-of-work Pencipta Bitcoin Satoshi Nakamoto mendeskripsikan algoritme pengambilan keputusan mayoritas sebagai “oneCPU-one-vote” dan menggunakan fungsi penetapan harga yang terikat CPU (ganda SHA-256) untuk proof-of-work miliknya skema. Karena pengguna memilih satu riwayat transaksi pesanan [1], kewajaran dan Konsistensi proses ini merupakan kondisi kritis bagi keseluruhan sistem. Keamanan model ini memiliki dua kelemahan. Pertama, ini membutuhkan 51% jaringan kekuatan penambangan berada di bawah kendali pengguna yang jujur. Kedua, kemajuan sistem (perbaikan bug, perbaikan keamanan, dll...) mengharuskan sebagian besar pengguna untuk mendukung dan menyetujuinya perubahan (ini terjadi ketika pengguna memperbarui perangkat lunak dompet mereka) [6]. Akhirnya pemungutan suara yang sama Mekanisme ini juga digunakan untuk jajak pendapat kolektif tentang penerapan beberapa fitur [7]. Hal ini memungkinkan kita untuk menduga sifat-sifat yang harus dipenuhi oleh proof-of-work fungsi penetapan harga. Fungsi tersebut tidak boleh memungkinkan peserta jaringan untuk memiliki signifikansi keunggulan dibandingkan peserta lain; itu membutuhkan keseimbangan antara perangkat keras umum dan perangkat keras tinggi biaya perangkat khusus. Dari contoh terbaru [8], kita dapat melihat bahwa fungsi SHA-256 digunakan dalam arsitektur Bitcoin tidak memiliki properti ini karena penambangan menjadi lebih efisien pada GPU dan perangkat ASIC jika dibandingkan dengan CPU kelas atas. Oleh karena itu, Bitcoin menciptakan kondisi yang menguntungkan bagi kesenjangan yang besar antara hak suara peserta karena melanggar prinsip “satu CPU-satu suara” yang dimiliki oleh pemilik GPU dan ASIC hak suara yang jauh lebih besar jika dibandingkan dengan pemilik CPU. Ini adalah contoh klasik dari Prinsip Pareto dimana 20% peserta sistem mengontrol lebih dari 80% suara. Ada yang berpendapat bahwa ketidaksetaraan tersebut tidak relevan dengan keamanan jaringan karena memang tidak relevan jumlah peserta yang sedikit menguasai suara mayoritas tetapi kejujurannya peserta yang penting. Akan tetapi, argumen tersebut agak cacat karena justru merupakan argumen yang salah kemungkinan munculnya perangkat keras khusus yang murah daripada kejujuran peserta yang mana menimbulkan ancaman. Untuk mendemonstrasikannya, mari kita ambil contoh berikut. Misalkan seorang yang jahat individu memperoleh kekuatan penambangan yang signifikan dengan menciptakan lahan penambangannya sendiri dengan biaya murah 2 ditelusuri secara jelas ke asal yang unik dan penerima akhir. Bahkan jika dua peserta bertukar dana secara tidak langsung, metode pencarian jalur yang dirancang dengan baik akan mengungkap asal usul dan penerima akhir. Diduga juga Bitcoin tidak memenuhi properti kedua. Beberapa peneliti menyatakan ([33, 35, 29, 31]) bahwa analisis blockchain yang cermat dapat mengungkapkan hubungan antara pengguna jaringan Bitcoin dan transaksinya. Meskipun ada beberapa metode yang bisa dilakukan ddisengketakan [25], diduga banyak informasi pribadi tersembunyi yang dapat diekstraksi dari basis data publik. Kegagalan Bitcoin dalam memenuhi dua sifat yang diuraikan di atas membuat kita menyimpulkan bahwa hal tersebut memang benar adanya bukan sistem kas elektronik anonim melainkan sistem kas elektronik pseudo-anonim. Pengguna cepat berkembang solusi untuk menghindari kelemahan ini. Dua solusi langsung adalah “layanan pencucian” [2] dan pengembangan metode terdistribusi [3, 4]. Kedua solusi tersebut didasarkan pada gagasan pencampuran beberapa transaksi publik dan mengirimkannya melalui beberapa alamat perantara; yang pada gilirannya menderita kelemahan karena membutuhkan pihak ketiga yang tepercaya. Baru-baru ini, skema yang lebih kreatif diusulkan oleh I. Miers dkk. [28]: “Nolkoin”. nol koin menggunakan akumulator kriptografi satu arah dan bukti tanpa pengetahuan yang memungkinkan pengguna melakukannya “konversi” bitcoin menjadi zerocoin dan belanjakan menggunakan bukti kepemilikan anonim tanda tangan digital berbasis kunci publik yang eksplisit. Namun, bukti-bukti pengetahuan tersebut mempunyai keteguhan tetapi ukurannya tidak nyaman - sekitar 30kb (berdasarkan batas Bitcoin saat ini), yang membuat proposal tidak praktis. Penulis mengakui bahwa protokol tersebut kemungkinan besar tidak akan pernah diterima oleh mayoritas orang Bitcoin pengguna [5]. 2.2 Fungsi proof-of-work Pencipta Bitcoin Satoshi Nakamoto mendeskripsikan algoritme pengambilan keputusan mayoritas sebagai “oneCPU-one-vote” dan menggunakan fungsi penetapan harga yang terikat CPU (ganda SHA-256) untuk proof-of-work miliknya skema. Karena pengguna memilih satu riwayat transaksi pesanan [1], kewajaran dan Konsistensi proses ini merupakan kondisi kritis bagi keseluruhan sistem. Keamanan model ini memiliki dua kelemahan. Pertama, ini membutuhkan 51% jaringan kekuatan penambangan berada di bawah kendali pengguna yang jujur. Kedua, kemajuan sistem (perbaikan bug, perbaikan keamanan, dll...) mengharuskan sebagian besar pengguna untuk mendukung dan menyetujuinya perubahan (ini terjadi ketika pengguna memperbarui perangkat lunak dompet mereka) [6]. Akhirnya pemungutan suara yang sama Mekanisme ini juga digunakan untuk jajak pendapat kolektif tentang penerapan beberapa fitur [7]. Hal ini memungkinkan kita untuk menduga sifat-sifat yang harus dipenuhi oleh proof-of-work fungsi penetapan harga. Fungsi tersebut tidak boleh memungkinkan peserta jaringan untuk memiliki signifikansi keunggulan dibandingkan peserta lain; itu membutuhkan keseimbangan antara perangkat keras umum dan perangkat keras tinggi biaya perangkat khusus. Dari contoh terbaru [8], kita dapat melihat bahwa fungsi SHA-256 digunakan dalam arsitektur Bitcoin tidak memiliki properti ini karena penambangan menjadi lebih efisien GPU dan perangkat ASIC jika dibandingkan dengan CPU kelas atas. Oleh karena itu, Bitcoin menciptakan kondisi yang menguntungkan bagi kesenjangan yang besar antara hak suara peserta karena melanggar prinsip “satu CPU-satu suara” yang dimiliki oleh pemilik GPU dan ASIC hak suara yang jauh lebih besar jika dibandingkan dengan pemilik CPU. Ini adalah contoh klasik dari Prinsip Pareto dimana 20% peserta sistem mengontrol lebih dari 80% suara. Ada yang berpendapat bahwa ketidaksetaraan tersebut tidak relevan dengan keamanan jaringan karena memang tidak relevan jumlah peserta yang sedikit menguasai suara mayoritas tetapi kejujurannya peserta yang penting. Akan tetapi, argumen tersebut agak cacat karena justru merupakan argumen yang salah kemungkinan munculnya perangkat keras khusus yang murah daripada kejujuran peserta yang mana menimbulkan ancaman. Untuk mendemonstrasikannya, mari kita ambil contoh berikut. Misalkan seorang yang jahat individu memperoleh kekuatan penambangan yang signifikan dengan menciptakan lahan penambangannya sendiri dengan biaya murah 2 4 Agaknya, jika setiap pengguna membantu anonimitas mereka dengan selalu membuat alamat baru untuk SETIAP pembayaran yang diterima (yang tidak masuk akal tetapi secara teknis merupakan cara yang "benar" untuk melakukannya), dan jika setiap pengguna membantu anonimitas orang lain dengan bersikeras bahwa mereka tidak pernah mengirim dana ke alamat BTC yang sama dua kali, maka Bitcoin hanya akan secara tidak langsung meneruskan tes ketidakterhubungan. Mengapa? Data konsumen dapat digunakan untuk mengetahui banyak hal tentang orang-orang sepanjang waktu. Lihat, misalnya http://www.applieddatalabs.com/content/target-knows-it-shows Sekarang, bayangkan ini 20 tahun ke depan dan bayangkan lebih jauh bahwa Target tidak mengetahuinya begitu saja tentang kebiasaan pembelian Anda di Target, tetapi mereka telah menambang blockchain untuk SEMUANYA PEMBELIAN PRIBADI ANDA DENGAN DOMPET COINBASE ANDA UNTUK MASA LALU DUA BELAS TAHUN. Mereka akan berkata, "hai sobat, kamu mungkin ingin membeli obat batuk malam ini, tapi kamu tidak akan melakukannya merasa sehat besok." Hal ini mungkin tidak terjadi jika penyortiran multi-pihak dieksploitasi dengan benar. Lihat, misalnya, inientri blog: http://blog.ezyang.com/2012/07/secure-multiparty-bitcoin-anonymization/ Saya tidak sepenuhnya yakin dengan perhitungan matematisnya, tapi... satu makalah pada satu waktu, bukan? Diperlukan kutipan. Meskipun protokol Zerocoin (mandiri) mungkin tidak mencukupi, Zerocash protokol tampaknya telah menerapkan transaksi berukuran 1kb. Proyek itu didukung oleh tentu saja militer AS dan Israel, jadi siapa yang tahu tentang ketangguhannya. Di sisi lain Di sisi lain, tidak ada orang yang lebih ingin mengeluarkan dana tanpa pengawasan selain pihak militer. http://zerocash-project.org/ Saya tidak yakin... lihat, misalnya, http://fc14.ifca.ai/bitcoin/papers/bitcoin14_submission_12.pdf Mengutip pengembang Cryptonote Maurice Planck (mungkin nama samaran) dari cryptonote tersebut forum: "Zerocoin, Zerocash. Harus saya akui, ini adalah teknologi tercanggih. Ya, kutipannya di atas adalah dari analisis protokol versi sebelumnya. Sepengetahuan saya, ternyata tidak 288, tapi 384 byte, tapi bagaimanapun ini adalah kabar baik. Mereka menggunakan teknik baru yang disebut SNARK, yang memiliki kelemahan tertentu: misalnya, database awal yang besar dari parameter publik yang diperlukan untuk membuat tanda tangan (lebih dari 1 GB) dan waktu yang signifikan diperlukan untuk membuat transaksi (lebih dari satu menit). Akhirnya, mereka menggunakan a crypto muda, yang saya sebutkan sebagai ide yang bisa diperdebatkan: https://forum.cryptonote.org/viewtopic.php?f= " - Maurice P. Kam 03 Apr 2014 19:56 Fungsi yang dijalankan di CPU dan tidak cocok untuk GPU, FPGA, atau ASIC komputasi. "Teka-teki" yang digunakan di proof-of-work disebut sebagai fungsi harga, fungsi biaya, atau fungsi teka-teki.

ditelusuri secara jelas ke asal yang unik dan penerima akhir. Bahkan jika dua peserta bertukar dana secara tidak langsung, metode pencarian jalur yang dirancang dengan baik akan mengungkap asal usul dan penerima akhir. Diduga juga Bitcoin tidak memenuhi properti kedua. Beberapa peneliti menyatakan ([33, 35, 29, 31]) bahwa analisis blockchain yang cermat dapat mengungkapkan hubungan antara pengguna jaringan Bitcoin dan transaksinya. Meskipun ada beberapa metode yang bisa dilakukan disengketakan [25], diduga banyak informasi pribadi tersembunyi yang dapat diambil dari basis data publik. Kegagalan Bitcoin dalam memenuhi kedua sifat yang diuraikan di atas membuat kita menyimpulkan bahwa hal tersebut memang benar adanya bukan sistem kas elektronik anonim melainkan sistem kas elektronik pseudo-anonim. Pengguna cepat berkembang solusi untuk menghindari kelemahan ini. Dua solusi langsung adalah “layanan pencucian” [2] dan pengembangan metode terdistribusi [3, 4]. Kedua solusi tersebut didasarkan pada gagasan pencampuran beberapa transaksi publik dan mengirimkannya melalui beberapa alamat perantara; yang pada gilirannya menderita kelemahan karena membutuhkan pihak ketiga yang tepercaya. Baru-baru ini, skema yang lebih kreatif diusulkan oleh I. Miers dkk. [28]: “Nolkoin”. nol koin menggunakan akumulator kriptografi satu arah dan bukti tanpa pengetahuan yang memungkinkan pengguna melakukannya “konversi” bitcoin menjadi zerocoin dan belanjakan menggunakan bukti kepemilikan anonim tanda tangan digital berbasis kunci publik yang eksplisit. Namun, bukti-bukti pengetahuan tersebut mempunyai keteguhan tetapi ukurannya tidak nyaman - sekitar 30kb (berdasarkan batas Bitcoin hari ini), yang membuat proposal tidak praktis. Penulis mengakui bahwa protokol tersebut kemungkinan besar tidak akan pernah diterima oleh mayoritas orang Bitcoin pengguna [5]. 2.2 Fungsi proof-of-work Pencipta Bitcoin Satoshi Nakamoto mendeskripsikan algoritme pengambilan keputusan mayoritas sebagai “oneCPU-one-vote” dan menggunakan fungsi penetapan harga yang terikat CPU (ganda SHA-256) untuk proof-of-work miliknya skema. Karena pengguna memilih satu riwayat transaksi pesanan [1], kewajaran dan Konsistensi proses ini merupakan kondisi kritis bagi keseluruhan sistem. Keamanan model ini memiliki dua kelemahan. Pertama, ini membutuhkan 51% jaringan kekuatan penambangan berada di bawah kendali pengguna yang jujur. Kedua, kemajuan sistem (perbaikan bug, perbaikan keamanan, dll...) mengharuskan sebagian besar pengguna untuk mendukung dan menyetujuinya perubahan (ini terjadi ketika pengguna memperbarui perangkat lunak dompet mereka) [6]. Akhirnya pemungutan suara yang sama Mekanisme ini juga digunakan untuk jajak pendapat kolektif tentang penerapan beberapa fitur [7]. Hal ini memungkinkan kita untuk menduga sifat-sifat yang harus dipenuhi oleh proof-of-work fungsi penetapan harga. Fungsi tersebut tidak boleh memungkinkan peserta jaringan untuk memiliki signifikansi keunggulan dibandingkan peserta lain; itu membutuhkan keseimbangan antara perangkat keras umum dan perangkat keras tinggi biaya perangkat khusus. Dari contoh terbaru [8], kita dapat melihat bahwa fungsi SHA-256 digunakan dalam arsitektur Bitcoin tidak memiliki properti ini karena penambangan menjadi lebih efisien pada GPU dan perangkat ASIC jika dibandingkan dengan CPU kelas atas. Oleh karena itu, Bitcoin menciptakan kondisi yang menguntungkan bagi kesenjangan yang besar antara hak suara peserta karena melanggar prinsip “satu CPU-satu suara” yang dimiliki oleh pemilik GPU dan ASIC hak suara yang jauh lebih besar jika dibandingkan dengan pemilik CPU. Ini adalah contoh klasik dari Prinsip Pareto dimana 20% peserta sistem mengontrol lebih dari 80% suara. Ada yang berpendapat bahwa ketidaksetaraan tersebut tidak relevan dengan keamanan jaringan karena memang tidak relevan jumlah peserta yang sedikit menguasai suara mayoritas tetapi kejujurannya peserta yang penting. Akan tetapi, argumen tersebut agak cacat karena justru merupakan argumen yang salah kemungkinan munculnya perangkat keras khusus yang murah daripada kejujuran peserta yang mana menimbulkan ancaman. Untuk mendemonstrasikannya, mari kita ambil contoh berikut. Misalkan seorang yang jahat individu memperoleh kekuatan penambangan yang signifikan dengan menciptakan lahan penambangannya sendiri dengan biaya murah 2 ditelusuri secara jelas ke asal yang unik dan penerima akhir. Bahkan jika dua peserta bertukar dana secara tidak langsung, metode pencarian jalur yang dirancang dengan baik akan mengungkap asal usul dan penerima akhir. Diduga juga Bitcoin tidak memenuhi properti kedua. Beberapa peneliti menyatakan ([33, 35, 29, 31]) bahwa analisis blockchain yang cermat dapat mengungkapkan hubungan antara pengguna jaringan Bitcoin dan transaksinya. Meskipun ada beberapa metode yang bisa dilakukan ddisengketakan [25], diduga banyak informasi pribadi tersembunyi yang dapat diekstraksi dari basis data publik. Kegagalan Bitcoin dalam memenuhi kedua sifat yang diuraikan di atas membuat kita menyimpulkan bahwa hal tersebut memang benar adanya bukan sistem kas elektronik anonim melainkan sistem kas elektronik pseudo-anonim. Pengguna cepat berkembang solusi untuk menghindari kelemahan ini. Dua solusi langsung adalah “layanan pencucian” [2] dan pengembangan metode terdistribusi [3, 4]. Kedua solusi tersebut didasarkan pada gagasan pencampuran beberapa transaksi publik dan mengirimkannya melalui beberapa alamat perantara; yang pada gilirannya menderita kelemahan karena membutuhkan pihak ketiga yang tepercaya. Baru-baru ini, skema yang lebih kreatif diusulkan oleh I. Miers dkk. [28]: “Nolkoin”. nol koin menggunakan akumulator kriptografi satu arah dan bukti tanpa pengetahuan yang memungkinkan pengguna melakukannya “konversi” bitcoin menjadi zerocoin dan belanjakan menggunakan bukti kepemilikan anonim tanda tangan digital berbasis kunci publik yang eksplisit. Namun, bukti-bukti pengetahuan tersebut mempunyai keteguhan tetapi ukurannya tidak nyaman - sekitar 30kb (berdasarkan batas Bitcoin saat ini), yang membuat proposal tidak praktis. Penulis mengakui bahwa protokol tersebut kemungkinan besar tidak akan pernah diterima oleh mayoritas orang Bitcoin pengguna [5]. 2.2 Fungsi proof-of-work Pencipta Bitcoin Satoshi Nakamoto mendeskripsikan algoritme pengambilan keputusan mayoritas sebagai “oneCPU-one-vote” dan menggunakan fungsi penetapan harga yang terikat CPU (ganda SHA-256) untuk proof-of-work miliknya skema. Karena pengguna memilih satu riwayat transaksi pesanan [1], kewajaran dan Konsistensi proses ini merupakan kondisi kritis bagi keseluruhan sistem. Keamanan model ini memiliki dua kelemahan. Pertama, ini membutuhkan 51% jaringan kekuatan penambangan berada di bawah kendali pengguna yang jujur. Kedua, kemajuan sistem (perbaikan bug, perbaikan keamanan, dll...) mengharuskan sebagian besar pengguna untuk mendukung dan menyetujuinya perubahan (ini terjadi ketika pengguna memperbarui perangkat lunak dompet mereka) [6]. Akhirnya pemungutan suara yang sama Mekanisme ini juga digunakan untuk jajak pendapat kolektif tentang penerapan beberapa fitur [7]. Hal ini memungkinkan kita untuk menduga sifat-sifat yang harus dipenuhi oleh proof-of-work fungsi penetapan harga. Fungsi tersebut tidak boleh memungkinkan peserta jaringan untuk memiliki signifikansi keunggulan dibandingkan peserta lain; itu membutuhkan keseimbangan antara perangkat keras umum dan perangkat keras tinggi biaya perangkat khusus. Dari contoh terbaru [8], kita dapat melihat bahwa fungsi SHA-256 digunakan dalam arsitektur Bitcoin tidak memiliki properti ini karena penambangan menjadi lebih efisien pada GPU dan perangkat ASIC jika dibandingkan dengan CPU kelas atas. Oleh karena itu, Bitcoin menciptakan kondisi yang menguntungkan bagi kesenjangan yang besar antara hak suara peserta karena melanggar prinsip “satu CPU-satu suara” yang dimiliki oleh pemilik GPU dan ASIC hak suara yang jauh lebih besar jika dibandingkan dengan pemilik CPU. Ini adalah contoh klasik dari Prinsip Pareto dimana 20% peserta sistem mengontrol lebih dari 80% suara. Ada yang berpendapat bahwa ketidaksetaraan tersebut tidak relevan dengan keamanan jaringan karena memang tidak relevan jumlah peserta yang sedikit menguasai suara mayoritas tetapi kejujurannya peserta yang penting. Akan tetapi, argumen tersebut agak cacat karena justru merupakan argumen yang salah kemungkinan munculnya perangkat keras khusus yang murah daripada kejujuran peserta yang mana menimbulkan ancaman. Untuk mendemonstrasikannya, mari kita ambil contoh berikut. Misalkan seorang yang jahat individu memperoleh kekuatan penambangan yang signifikan dengan menciptakan lahan penambangannya sendiri dengan biaya murah 2 Komentar di halaman 2

The CryptoNote Technology

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

Teknologi CryptoNote

Sekarang kita telah membahas keterbatasan teknologi Bitcoin, kita akan berkonsentrasi pada hal tersebut menyajikan fitur-fitur CryptoNote.

Untraceable Transactions

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Transaksi yang Tidak Dapat Dilacak

Pada bagian ini kami mengusulkan skema transaksi anonim yang memenuhi kedua kondisi tidak dapat dilacak dan kondisi tidak dapat dihubungkan. Fitur penting dari solusi kami adalah otonominya: pengirim tidak diharuskan bekerja sama dengan pengguna lain atau pihak ketiga yang dipercaya untuk melakukan transaksinya; karenanya setiap peserta menghasilkan lalu lintas sampul secara mandiri. 4.1 Tinjauan literatur Skema kami bergantung pada primitif kriptografi yang disebut tanda tangan grup. Pertama kali disajikan oleh D. Chaum dan E. van Heyst [19], memungkinkan pengguna untuk menandatangani pesannya atas nama grup. Setelah menandatangani pesan, pengguna memberikan (untuk tujuan verifikasi) bukan pesan publiknya sendiri 1Ini disebut “batas lunak” — batasan klien referensi untuk membuat blok baru. Keras maksimal kemungkinan ukuran blokir adalah 1 MB 4 mereka jika perlu yang menyebabkan kelemahan utama. Sayangnya, sulit untuk memprediksi kapan hal tersebut akan terjadi konstanta mungkin perlu diubah dan menggantinya dapat menimbulkan konsekuensi yang buruk. Contoh bagus dari perubahan batas hardcode yang menyebabkan konsekuensi bencana adalah pemblokiran batas ukuran disetel ke 250kb1. Batas ini cukup untuk menampung sekitar 10.000 transaksi standar. Di awal tahun 2013, batas tersebut hampir tercapai dan tercapai kesepakatan untuk meningkatkannya batas. Perubahan tersebut diterapkan pada dompet versi 0.8 dan diakhiri dengan pemisahan rantai 24 blok dan serangan pembelanjaan ganda yang berhasil [9]. Meskipun bugnya bukan pada protokol Bitcoin, tapi melainkan di mesin database, hal itu bisa dengan mudah ditangkap dengan stress test sederhana jika ada tidak ada batasan ukuran blok yang diperkenalkan secara artifisial. Konstanta juga berperan sebagai bentuk titik sentralisasi. Meskipun bersifat peer-to-peer Bitcoin, sebagian besar node menggunakan klien referensi resmi [10] yang dikembangkan oleh sekelompok kecil orang. Kelompok ini membuat keputusan untuk menerapkan perubahan pada protokol dan kebanyakan orang menerima perubahan ini terlepas dari “kebenarannya”. Beberapa keputusan menyebabkan diskusi yang memanas bahkan seruan boikot [11], yang menandakan bahwa komunitas dan pengembang mungkin tidak setuju pada beberapa poin penting. Oleh karena itu tampaknya logis untuk memiliki protokol dengan variabel yang dapat dikonfigurasi pengguna dan dapat disesuaikan sendiri sebagai cara yang mungkin untuk menghindari masalah ini. 2.5 Skrip besar Sistem skrip di Bitcoin adalah fitur yang berat dan kompleks. Ini berpotensi memungkinkan seseorang untuk berkreasi transaksi canggih [12], namun beberapa fiturnya dinonaktifkan karena masalah keamanan dan bahkan ada yang belum pernah dipakai [13]. Naskah (termasuk bagian pengirim dan penerima) untuk transaksi terpopuler di Bitcoin tampilannya seperti ini: OP DUP OP HASH160 OP SAMAKAN VERIFIKASI OP CHECKSIG. Skrip ini panjangnya 164 byte sedangkan tujuan satu-satunya adalah untuk memeriksa apakah penerima memilikinya kunci rahasia diperlukan untuk memverifikasi tanda tangannya. 3 Teknologi CryptoNote Sekarang kita telah membahas keterbatasan teknologi Bitcoin, kita akan berkonsentrasi pada hal tersebut menyajikan fitur-fitur CryptoNote. 4 Transaksi yang Tidak Dapat Dilacak Pada bagian ini kami mengusulkan skema transaksi anonim yang memenuhi kedua kondisi tidak dapat dilacak dan kondisi tidak dapat dihubungkan. Fitur penting dari solusi kami adalah otonominya: pengirim tidak diharuskan bekerja sama dengan pengguna lain atau pihak ketiga yang dipercaya untuk melakukan transaksinya; karenanya setiap peserta menghasilkan lalu lintas sampul secara mandiri. 4.1 Tinjauan literatur Skema kami bergantung pada primitif kriptografi yang disebut tanda tangan grup. Pertama kali disajikan oleh D. Chaum dan E. van Heyst [19], memungkinkan pengguna untuk menandatangani pesannya atas nama grup. Setelah menandatangani pesan, pengguna memberikan (untuk tujuan verifikasi) bukan pesan publiknya sendiri 1Ini disebut “batas lunak” — batasan klien referensi untuk membuat blok baru. Keras maksimal kemungkinan ukuran blokir adalah 1 MB 4 7 Jika dipikir-pikir lagi, tampaknya merupakan kesalahan besar jika menjadikan ukuran blok sebagai batas tetap dalam kode. Visa dan Mastercard dapat memproses ribuan, bahkan ratusan ribu transaksi per detik. Namun, transaksi terjadi dalam proses stokastik, terkadang dalam ledakan besar, terkadang diam berjam-jam. Pikirkan volume pertukaran bitcoin. Sepertinya ide bagus untuk merancang sistem yang meningkatkan ukuran blok secara dinamis bila diperlukan untuk mengakomodasi peningkatan lalu lintas transaksi, dan menguranginya secara dinamis bila diperlukan meningkatkan efisiensi bandwidth. Sekarang, terapkan gagasan itu ke semua parameter sistem. Dan selama kita berhati-hati dalam menjaganya sistem dari fishtailing di luar kendali, sh inibisa bekerja dengan baik. https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki Seperti disebutkan sebelumnya, jika variabel dapat menyesuaikan diri, beberapa kontrol harus diterapkan agar dapat disesuaikan menjaga agar sistem tidak berjalan liar di luar kendali. Kami akan membahasnya. Jika ini adalah artikel wikipedia, maka akan diberi label "STUB". Meskipun kita pasti berada di dalamnya bagian memperkenalkan "Masalah Bitcoin," Saya ingin penjelasan lebih lanjut di sini. Mengapa demikian 164 byte tidak dapat diterima untuk tugas sederhana "periksa kunci rahasia"? Seberapa kecil yang bisa mereka peroleh bahasa skrip yang masuk akal? Tapi saya bukan ilmuwan komputer. http://download.springer.com/static/pdf/412/chp%253A10.1007%252F3-540-46416-6_22.pdf?auth66=140 Tanda tangan grup, seperti yang dijelaskan, memerlukan manajer grup. Manajer grup mampu untuk mencabut anonimitas penanda tangan mana pun. Oleh karena itu, ada sentralisasi yang tertanam dalam suatu kelompok skema tanda tangan.

kunci, tetapi kunci semua pengguna grupnya. Verifier yakin bahwa penandatangan sebenarnya adalah a anggota kelompok, tetapi tidak dapat secara eksklusif mengidentifikasi penandatangannya. Protokol asli memerlukan pihak ketiga yang tepercaya (disebut Manajer Grup), dan dialah yang melakukannya satu-satunya yang bisa melacak penandatangannya. Versi selanjutnya yang disebut tanda tangan cincin, diperkenalkan oleh Rivest dkk. di [34], merupakan skema otonom tanpa Manajer Grup dan anonimitas pencabutan. Berbagai modifikasi skema ini muncul kemudian: tanda tangan cincin yang dapat ditautkan [26, 27, 17] diperbolehkan untuk menentukan apakah dua tanda tangan dihasilkan oleh anggota kelompok yang sama, dapat dilacak tanda tangan cincin [24, 23] membatasi anonimitas berlebihan dengan memberikan kemungkinan untuk melacak penandatangan dua pesan sehubungan dengan metainformasi yang sama (atau “tag” dalam istilah [24]). Konstruksi kriptografi serupa juga dikenal sebagai tanda tangan kelompok ad-hoc [16, 38]. Itu menekankan pembentukan kelompok yang sewenang-wenang, sedangkan skema tanda tangan kelompok/lingkaran lebih menyiratkan a kumpulan anggota yang tetap. Sebagian besar, solusi kami didasarkan pada karya “Traceable Ring Signature” oleh E. Fujisaki dan K.Suzuki [24]. Untuk membedakan algoritma asli dan modifikasi kami, kami akan melakukannya menyebut yang terakhir sebagai tanda dering satu kali, yang menekankan kemampuan pengguna untuk menghasilkan hanya satu tanda dering yang valid tanda tangan di bawah kunci pribadinya. Kami melemahkan properti ketertelusuran dan mempertahankan keterhubungan hanya untuk memberikan ketepatan waktu: kunci publik dapat muncul di banyak set verifikasi asing dan kunci pribadi dapat digunakan untuk menghasilkan tanda tangan anonim yang unik. Jika terjadi pembelanjaan ganda upayakan kedua tanda tangan ini akan dihubungkan bersama, tetapi tidak perlu mengungkapkan penandatangannya untuk tujuan kita. 4.2 Definisi 4.2.1 Parameter kurva elips Sebagai algoritma tanda tangan dasar kami, kami memilih untuk menggunakan skema cepat EdDSA, yang dikembangkan dan dilaksanakan oleh D.J. Bernstein dkk. [18]. Seperti ECDSA Bitcoin, ECDSA ini didasarkan pada kurva elips masalah logaritma diskrit, sehingga skema kami juga dapat diterapkan ke Bitcoin di masa depan. Parameter umum adalah: q: bilangan prima; q = 2255 −19; d: unsur Fq; d = −121665/121666; E: persamaan kurva elips; −x2 + y2 = 1 + dx2y2; G: titik dasar; G = (x, −4/5); l : orde prima dari titik dasar; aku = 2252 + 27742317777372353535851937790883648493; \(H_s\): fungsi kriptografi hash \(\{0, 1\}^* \to \mathbb{F}_q\); \(H_p\): fungsi hash deterministik \(E(\mathbb{F}_q) \to E(\mathbb{F}_q)\). 4.2.2 Terminologi Peningkatan privasi memerlukan terminologi baru yang berbeda dengan entitas Bitcoin. private ec-key adalah kunci privat kurva elips standar: angka \(a \in [1, l - 1]\); kunci ec publik adalah kunci publik kurva elips standar: titik A = aG; pasangan kunci satu kali adalah sepasang kunci pribadi dan publik; 5 kunci, tetapi kunci semua pengguna grupnya. Verifier yakin bahwa penandatangan sebenarnya adalah a anggota kelompok, tetapi tidak dapat secara eksklusif mengidentifikasi penandatangannya. Protokol asli memerlukan pihak ketiga yang tepercaya (disebut Manajer Grup), dan dialah yang melakukannya satu-satunya yang bisa melacak penandatangannya. Versi selanjutnya yang disebut tanda tangan cincin, diperkenalkan oleh Rivest dkk. di [34], merupakan skema otonom tanpa Manajer Grup dan anonimitas pencabutan. Berbagai modifikasi skema ini muncul kemudian: tanda tangan cincin yang dapat ditautkan [26, 27, 17] diperbolehkan untuk menentukan apakah dua tanda tangan dihasilkan oleh anggota kelompok yang sama, dapat dilacak tanda tangan cincin [24, 23] membatasi anonimitas berlebihan dengan memberikan kemungkinan untuk melacak penandatangan dua pesan sehubungan dengan metainformasi yang sama (atau “tag” dalam istilah [24]). Konstruksi kriptografi serupa juga dikenal sebagai tanda tangan kelompok ad-hoc [16, 38]. Itu menekankan pembentukan kelompok yang sewenang-wenang, sedangkan skema tanda tangan kelompok/lingkaran lebih menyiratkan a kumpulan anggota yang tetap. Sebagian besar, solusi kami didasarkan pada karya “Traceable Ring Signature” oleh E. Fujisaki dan K.Suzuki [24]. Untuk membedakan algoritma asli dan modifikasi kami, kami akan melakukannya menyebut yang terakhir sebagai tanda dering satu kali, yang menekankan kemampuan pengguna untuk menghasilkan hanya satu tanda dering yang valid tanda tangan di bawah kunci pribadinya. Kami melemahkan properti ketertelusuran dan mempertahankan keterhubungan hanya untuk memberikan ketepatan waktu: kunci publik dapat muncul di banyak set verifikasi asing dan kunci pribadi dapat digunakan untuk menghasilkan tanda tangan anonim yang unik. Jika terjadi pembelanjaan ganda upayakan kedua tanda tangan ini akan dihubungkan bersama, tetapi tidak perlu mengungkapkan penandatangannya untuk tujuan kita. 4.2 Definisi 4.2.1 Parameter kurva elips Sebagai algoritma tanda tangan dasar, kami memilihe menggunakan skema cepat EdDSA, yang dikembangkan dan dilaksanakan oleh D.J. Bernstein dkk. [18]. Seperti ECDSA Bitcoin, ECDSA ini didasarkan pada kurva elips masalah logaritma diskrit, sehingga skema kami juga dapat diterapkan ke Bitcoin di masa depan. Parameter umum adalah: q: bilangan prima; q = 2255 −19; d: unsur Fq; d = −121665/121666; E: persamaan kurva elips; −x2 + y2 = 1 + dx2y2; G: titik dasar; G = (x, −4/5); l : orde prima dari titik dasar; aku = 2252 + 27742317777372353535851937790883648493; \(H_s\): fungsi kriptografi hash \(\{0, 1\}^* \to \mathbb{F}_q\); \(H_p\): fungsi hash deterministik \(E(\mathbb{F}_q) \to E(\mathbb{F}_q)\). 4.2.2 Terminologi Privasi yang ditingkatkan memerlukan terminologi baru yang berbeda dengan entitas Bitcoin. private ec-key adalah kunci privat kurva elips standar: angka \(a \in [1, l - 1]\); kunci ec publik adalah kunci publik kurva elips standar: titik A = aG; pasangan kunci satu kali adalah sepasang kunci pribadi dan publik; 5 8 Tanda tangan cincin berfungsi seperti ini: Alex ingin membocorkan pesan ke WikiLeaks tentang majikannya. Setiap karyawan di Perusahaannya memiliki pasangan kunci privat/publik (Ri, Ui). Dia menulis tanda tangannya dengan masukan yang ditetapkan sebagai pesannya, m, kunci pribadinya, Ri, dan milik SEMUA ORANG kunci publik, (Ui;i=1...n). Siapa pun (tanpa mengetahui kunci pribadi apa pun) dapat memverifikasinya dengan mudah beberapa pasangan (Rj, Uj) pasti digunakan untuk membuat tanda tangan... seseorang yang bekerja untuk majikan Alex... tapi pada dasarnya ini hanyalah tebakan acak untuk mengetahui perusahaan mana yang dimaksud. 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 Perhatikan bahwa tanda cincin yang dapat ditautkan yang dijelaskan di sini adalah kebalikan dari "tidak dapat ditautkan" dijelaskan di atas. Di sini, kami mencegat dua pesan, dan kami dapat menentukan apakah pesan tersebut sama pihak yang mengirimkannya, meskipun kami masih belum dapat menentukan siapa pihak tersebut. Itu definisi "tidak dapat ditautkan" yang digunakan untuk membuat Cryptonote berarti kita tidak dapat menentukan apakah pihak yang sama menerimanya. Oleh karena itu, apa yang sebenarnya kita miliki di sini adalah EMPAT hal yang terjadi. Suatu sistem dapat ditautkan atau tidak dapat ditautkan, tergantung pada apakah mungkin untuk menentukan apakah pengirimnya dua pesan adalah sama (terlepas dari apakah hal ini memerlukan pencabutan anonimitas). Dan suatu sistem dapat dibatalkan tautannya atau tidak dapat dibatalkan tautannya, bergantung pada apakah hal itu memungkinkan atau tidak menentukan apakah penerima dua pesan itu sama (terlepas dari apakah atau tidak ini memerlukan pencabutan anonimitas). Tolong jangan salahkan saya atas terminologi buruk ini. Para ahli teori grafik mungkin seharusnya begitu senang. Beberapa dari Anda mungkin lebih nyaman dengan "receiver linkable" versus "sender linkable". http://link.springer.com/chapter/10.1007/978-3-540-71677-8_13 Ketika saya membaca ini, ini tampak seperti fitur yang konyol. Kemudian saya membaca bahwa itu mungkin fitur untuk pemungutan suara elektronik, dan itu tampaknya masuk akal. Agak keren, dari sudut pandang itu. Tapi aku tidak sepenuhnya yakin tentang penerapan tanda tangan cincin yang dapat dilacak dengan sengaja. http://search.ieice.org/bin/summary.php?id=e95-a_1_151

kunci, tetapi kunci semua pengguna grupnya. Verifier yakin bahwa penandatangan sebenarnya adalah a anggota kelompok, tetapi tidak dapat secara eksklusif mengidentifikasi penandatangannya. Protokol asli memerlukan pihak ketiga yang tepercaya (disebut Manajer Grup), dan dialah yang melakukannya satu-satunya yang bisa melacak penandatangannya. Versi selanjutnya yang disebut tanda tangan cincin, diperkenalkan oleh Rivest dkk. di [34], merupakan skema otonom tanpa Manajer Grup dan anonimitas pencabutan. Berbagai modifikasi skema ini muncul kemudian: tanda tangan cincin yang dapat ditautkan [26, 27, 17] diperbolehkan untuk menentukan apakah dua tanda tangan dihasilkan oleh anggota kelompok yang sama, dapat dilacak tanda tangan cincin [24, 23] membatasi anonimitas berlebihan dengan memberikan kemungkinan untuk melacak penandatangan dua pesan sehubungan dengan metainformasi yang sama (atau “tag” dalam istilah [24]). Konstruksi kriptografi serupa juga dikenal sebagai tanda tangan kelompok ad-hoc [16, 38]. Itu menekankan pembentukan kelompok yang sewenang-wenang, sedangkan skema tanda tangan kelompok/lingkaran lebih menyiratkan a kumpulan anggota yang tetap. Sebagian besar, solusi kami didasarkan pada karya “Traceable Ring Signature” oleh E. Fujisaki dan K.Suzuki [24]. Untuk membedakan algoritma asli dan modifikasi kami, kami akan melakukannya menyebut yang terakhir sebagai tanda dering satu kali, yang menekankan kemampuan pengguna untuk menghasilkan hanya satu tanda dering yang valid tanda tangan di bawah kunci pribadinya. Kami melemahkan properti ketertelusuran dan mempertahankan keterhubungan hanya untuk memberikan ketepatan waktu: kunci publik dapat muncul di banyak set verifikasi asing dan kunci pribadi dapat digunakan untuk menghasilkan tanda tangan anonim yang unik. Jika terjadi pembelanjaan ganda upayakan kedua tanda tangan ini akan dihubungkan bersama, tetapi tidak perlu mengungkapkan penandatangannya untuk tujuan kita. 4.2 Definisi 4.2.1 Parameter kurva elips Sebagai algoritma tanda tangan dasar kami, kami memilih untuk menggunakan skema cepat EdDSA, yang dikembangkan dan dilaksanakan oleh D.J. Bernstein dkk. [18]. Seperti ECDSA Bitcoin, ECDSA ini didasarkan pada kurva elips masalah logaritma diskrit, sehingga skema kami juga dapat diterapkan ke Bitcoin di masa depan. Parameter umum adalah: q: bilangan prima; q = 2255 −19; d: unsur Fq; d = −121665/121666; E: persamaan kurva elips; −x2 + y2 = 1 + dx2y2; G: titik dasar; G = (x, −4/5); l : orde prima dari titik dasar; aku = 2252 + 27742317777372353535851937790883648493; \(H_s\): fungsi kriptografi hash \(\{0, 1\}^* \to \mathbb{F}_q\); \(H_p\): fungsi hash deterministik \(E(\mathbb{F}_q) \to E(\mathbb{F}_q)\). 4.2.2 Terminologi Privasi yang ditingkatkan memerlukan terminologi baru yang berbeda dengan entitas Bitcoin. private ec-key adalah kunci privat kurva elips standar: angka \(a \in [1, l - 1]\); kunci ec publik adalah kunci publik kurva elips standar: titik A = aG; pasangan kunci satu kali adalah sepasang kunci pribadi dan publik; 5 kunci, tetapi kunci semua pengguna grupnya. Verifier yakin bahwa penandatangan sebenarnya adalah a anggota kelompok, tetapi tidak dapat secara eksklusif mengidentifikasi penandatangannya. Protokol asli memerlukan pihak ketiga yang tepercaya (disebut Manajer Grup), dan dialah yang melakukannya satu-satunya yang bisa melacak penandatangannya. Versi selanjutnya yang disebut tanda tangan cincin, diperkenalkan oleh Rivest dkk. di [34], merupakan skema otonom tanpa Manajer Grup dan anonimitas pencabutan. Berbagai modifikasi skema ini muncul kemudian: tanda tangan cincin yang dapat ditautkan [26, 27, 17] diperbolehkan untuk menentukan apakah dua tanda tangan dihasilkan oleh anggota kelompok yang sama, dapat dilacak tanda tangan cincin [24, 23] membatasi anonimitas berlebihan dengan memberikan kemungkinan untuk melacak penandatangan dua pesan sehubungan dengan metainformasi yang sama (atau “tag” dalam istilah [24]). Konstruksi kriptografi serupa juga dikenal sebagai tanda tangan kelompok ad-hoc [16, 38]. Itu menekankan pembentukan kelompok yang sewenang-wenang, sedangkan skema tanda tangan kelompok/lingkaran lebih menyiratkan a kumpulan anggota yang tetap. Sebagian besar, solusi kami didasarkan pada karya “Traceable Ring Signature” oleh E. Fujisaki dan K.Suzuki [24]. Untuk membedakan algoritma asli dan modifikasi kami, kami akan melakukannya menyebut yang terakhir sebagai tanda dering satu kali, yang menekankan kemampuan pengguna untuk menghasilkan hanya satu tanda dering yang valid tanda tangan di bawah kunci pribadinya. Kami melemahkan properti ketertelusuran dan mempertahankan keterhubungan hanya untuk memberikan ketepatan waktu: kunci publik dapat muncul di banyak set verifikasi asing dan kunci pribadi dapat digunakan untuk menghasilkan tanda tangan anonim yang unik. Jika terjadi pembelanjaan ganda upayakan kedua tanda tangan ini akan dihubungkan bersama, tetapi tidak perlu mengungkapkan penandatangannya untuk tujuan kita. 4.2 Definisi 4.2.1 Parameter kurva elips Sebagai algoritma tanda tangan dasar, kami memilihe menggunakan skema cepat EdDSA, yang dikembangkan dan dilaksanakan oleh D.J. Bernstein dkk. [18]. Seperti ECDSA Bitcoin, ECDSA ini didasarkan pada kurva elips masalah logaritma diskrit, sehingga skema kami juga dapat diterapkan pada Bitcoin di masa mendatang. Parameter umum adalah: q: bilangan prima; q = 2255 −19; d: unsur Fq; d = −121665/121666; E: persamaan kurva elips; −x2 + y2 = 1 + dx2y2; G: titik dasar; G = (x, −4/5); l : orde prima dari titik dasar; aku = 2252 + 27742317777372353535851937790883648493; \(H_s\): fungsi kriptografi hash \(\{0, 1\}^* \to \mathbb{F}_q\); \(H_p\): fungsi hash deterministik \(E(\mathbb{F}_q) \to E(\mathbb{F}_q)\). 4.2.2 Terminologi Privasi yang ditingkatkan memerlukan terminologi baru yang berbeda dengan entitas Bitcoin. private ec-key adalah kunci privat kurva elips standar: angka \(a \in [1, l - 1]\); kunci ec publik adalah kunci publik kurva elips standar: titik A = aG; pasangan kunci satu kali adalah sepasang kunci pribadi dan publik; 5 9 Astaga, penulis whitepaper ini pasti bisa menjelaskannya dengan lebih baik! Katakanlah sebuah perusahaan milik karyawan ingin mengambil suara apakah akan mengakuisisi perusahaan baru tertentu atau tidak aset, dan Alex serta Brenda keduanya adalah karyawan. Perusahaan membekali setiap karyawan a pesan seperti "Saya memilih ya pada Proposisi A!" yang memiliki metainformasi "masalah" [PROP A] dan meminta mereka untuk menandatanganinya dengan tanda cincin yang dapat dilacak jika mereka mendukung proposisi tersebut. Dengan menggunakan tanda tangan cincin tradisional, karyawan yang tidak jujur dapat menandatangani pesan tersebut berkali-kali, mungkin dengan nonce yang berbeda, untuk memilih sebanyak yang mereka suka. Di sisi lain sisi lain, dalam skema tanda tangan cincin yang dapat dilacak, Alex akan memilih, dan kunci pribadinya akan memilikinya telah digunakan pada masalah [PROP A]. Jika Alex mencoba menandatangani pesan seperti "Saya, Brenda, menyetujuinya proposisi A!" untuk "menjebak" Brenda dan memberikan suara ganda, pesan baru ini juga akan menimbulkan masalah [PROP A]. Karena kunci pribadi Alex telah mengatasi masalah [PROP A], identitas Alex akan segera terungkap sebagai penipuan. Jujur saja, itu cukup keren! Kriptografi menegakkan kesetaraan suara. http://link.springer.com/chapter/10.1007/978-3-540-71677-8_13 Makalah ini menarik, pada dasarnya membuat tanda tangan cincin ad-hoc tetapi tanpa satupun persetujuan peserta lain. Struktur tanda tangannya mungkin berbeda; Saya belum menggali dalam, dan saya belum melihat apakah itu aman. https://people.csail.mit.edu/rivest/AdidaHohenbergerRivest-AdHocGroupSignaturesFromHijackedKeypai Tanda tangan kelompok ad-hoc adalah: tanda tangan cincin, yaitu tanda tangan kelompok yang tidak ada kelompoknya manajer, tidak ada sentralisasi, namun mengizinkan anggota dalam kelompok ad-hoc untuk mengklaim hal tersebut mereka (belum) mengeluarkan tanda tangan anonim atas nama grup. http://link.springer.com/chapter/10.1007/11908739_9 Menurut pemahaman saya, ini kurang tepat. Dan pemahaman saya kemungkinan besar akan berubah Saya mendalami proyek ini lebih dalam. Tapi dari pemahaman saya, hierarkinya terlihat seperti ini. Tanda grup: manajer grup mengontrol ketertelusuran dan kemampuan menambah atau menghapus anggota dari menjadi penandatangan. Ring sign : Pembentukan grup secara sewenang-wenang tanpa adanya manajer grup. Tidak ada pencabutan anonimitas. Tidak ada cara untuk menolak diri sendiri dari tanda tangan tertentu. Dengan cincin yang dapat dilacak dan dihubungkan tanda tangan, anonimitas agak terukur. Tanda tangan kelompok ad-hoc: seperti tanda tangan cincin, namun anggota dapat membuktikan bahwa mereka tidak membuat tanda tangan tertentu. Hal ini penting ketika siapa pun dalam kelompok dapat membuat tanda tangan. http://link.springer.com/chapter/10.1007/978-3-540-71677-8_13 Algoritme Fujisaki dan Suzuki kemudian diubah oleh penulis untuk memberikan ketepatan waktu. Jadi kami akan menganalisis algoritma Fujisaki dan Suzuki secara bersamaan dengan algoritma baru daripada membahasnya di sini.

kunci, tetapi kunci semua pengguna grupnya. Verifier yakin bahwa penandatangan sebenarnya adalah a anggota kelompok, tetapi tidak dapat secara eksklusif mengidentifikasi penandatangannya. Protokol asli memerlukan pihak ketiga yang tepercaya (disebut Manajer Grup), dan dialah yang melakukannya satu-satunya yang bisa melacak penandatangannya. Versi selanjutnya yang disebut tanda tangan cincin, diperkenalkan oleh Rivest dkk. di [34], merupakan skema otonom tanpa Manajer Grup dan anonimitas pencabutan. Berbagai modifikasi skema ini muncul kemudian: tanda tangan cincin yang dapat ditautkan [26, 27, 17] diperbolehkan untuk menentukan apakah dua tanda tangan dihasilkan oleh anggota kelompok yang sama, dapat dilacak tanda tangan cincin [24, 23] membatasi anonimitas berlebihan dengan memberikan kemungkinan untuk melacak penandatangan dua pesan sehubungan dengan metainformasi yang sama (atau “tag” dalam istilah [24]). Konstruksi kriptografi serupa juga dikenal sebagai tanda tangan kelompok ad-hoc [16, 38]. Itu menekankan pembentukan kelompok yang sewenang-wenang, sedangkan skema tanda tangan kelompok/lingkaran lebih menyiratkan a kumpulan anggota yang tetap. Sebagian besar, solusi kami didasarkan pada karya “Traceable Ring Signature” oleh E. Fujisaki dan K.Suzuki [24]. Untuk membedakan algoritma asli dan modifikasi kami, kami akan melakukannya menyebut yang terakhir sebagai tanda dering satu kali, yang menekankan kemampuan pengguna untuk menghasilkan hanya satu tanda dering yang valid tanda tangan di bawah kunci pribadinya. Kami melemahkan properti ketertelusuran dan mempertahankan keterhubungan hanya untuk memberikan ketepatan waktu: kunci publik dapat muncul di banyak set verifikasi asing dan kunci pribadi dapat digunakan untuk menghasilkan tanda tangan anonim yang unik. Jika terjadi pembelanjaan ganda upayakan kedua tanda tangan ini akan dihubungkan bersama, tetapi tidak perlu mengungkapkan penandatangannya untuk tujuan kita. 4.2 Definisi 4.2.1 Parameter kurva elips Sebagai algoritma tanda tangan dasar kami, kami memilih untuk menggunakan skema cepat EdDSA, yang dikembangkan dan dilaksanakan oleh D.J. Bernstein dkk. [18]. Seperti ECDSA Bitcoin, ECDSA ini didasarkan pada kurva elips masalah logaritma diskrit, sehingga skema kami juga dapat diterapkan ke Bitcoin di masa depan. Parameter umum adalah: q: bilangan prima; q = 2255 −19; d: unsur Fq; d = −121665/121666; E: persamaan kurva elips; −x2 + y2 = 1 + dx2y2; G: titik dasar; G = (x, −4/5); l : orde prima dari titik dasar; aku = 2252 + 27742317777372353535851937790883648493; \(H_s\): fungsi kriptografi hash \(\{0, 1\}^* \to \mathbb{F}_q\); \(H_p\): fungsi hash deterministik \(E(\mathbb{F}_q) \to E(\mathbb{F}_q)\). 4.2.2 Terminologi Privasi yang ditingkatkan memerlukan terminologi baru yang berbeda dengan entitas Bitcoin. private ec-key adalah kunci privat kurva elips standar: angka \(a \in [1, l - 1]\); kunci ec publik adalah kunci publik kurva elips standar: titik A = aG; pasangan kunci satu kali adalah sepasang kunci pribadi dan publik; 5 kunci, tetapi kunci semua pengguna grupnya. Verifier yakin bahwa penandatangan sebenarnya adalah a anggota kelompok, tetapi tidak dapat secara eksklusif mengidentifikasi penandatangannya. Protokol asli memerlukan pihak ketiga yang tepercaya (disebut Manajer Grup), dan dialah yang melakukannya satu-satunya yang bisa melacak penandatangannya. Versi selanjutnya yang disebut tanda tangan cincin, diperkenalkan oleh Rivest dkk. di [34], merupakan skema otonom tanpa Manajer Grup dan anonimitas pencabutan. Berbagai modifikasi skema ini muncul kemudian: tanda tangan cincin yang dapat ditautkan [26, 27, 17] diperbolehkan untuk menentukan apakah dua tanda tangan dihasilkan oleh anggota kelompok yang sama, dapat dilacak tanda tangan cincin [24, 23] membatasi anonimitas berlebihan dengan memberikan kemungkinan untuk melacak penandatangan dua pesan sehubungan dengan metainformasi yang sama (atau “tag” dalam istilah [24]). Konstruksi kriptografi serupa juga dikenal sebagai tanda tangan kelompok ad-hoc [16, 38]. Itu menekankan pembentukan kelompok yang sewenang-wenang, sedangkan skema tanda tangan kelompok/lingkaran lebih menyiratkan a kumpulan anggota yang tetap. Sebagian besar, solusi kami didasarkan pada karya “Traceable Ring Signature” oleh E. Fujisaki dan K.Suzuki [24]. Untuk membedakan algoritma asli dan modifikasi kami, kami akan melakukannya menyebut yang terakhir sebagai tanda dering satu kali, yang menekankan kemampuan pengguna untuk menghasilkan hanya satu tanda dering yang valid tanda tangan di bawah kunci pribadinya. Kami melemahkan properti ketertelusuran dan mempertahankan keterhubungan hanya untuk memberikan ketepatan waktu: kunci publik dapat muncul di banyak set verifikasi asing dan kunci pribadi dapat digunakan untuk menghasilkan tanda tangan anonim yang unik. Jika terjadi pembelanjaan ganda upayakan kedua tanda tangan ini akan dihubungkan bersama, tetapi tidak perlu mengungkapkan penandatangannya untuk tujuan kita. 4.2 Definisi 4.2.1 Parameter kurva elips Sebagai algoritma tanda tangan dasar, kami memilihe menggunakan skema cepat EdDSA, yang dikembangkan dan dilaksanakan oleh D.J. Bernstein dkk. [18]. Seperti ECDSA Bitcoin, ECDSA ini didasarkan pada kurva elips masalah logaritma diskrit, sehingga skema kami juga dapat diterapkan ke Bitcoin di masa depan. Parameter umum adalah: q: bilangan prima; q = 2255 −19; d: unsur Fq; d = −121665/121666; E: persamaan kurva elips; −x2 + y2 = 1 + dx2y2; G: titik dasar; G = (x, −4/5); l : orde prima dari titik dasar; aku = 2252 + 27742317777372353535851937790883648493; \(H_s\): fungsi kriptografi hash \(\{0, 1\}^* \to \mathbb{F}_q\); \(H_p\): fungsi hash deterministik \(E(\mathbb{F}_q) \to E(\mathbb{F}_q)\). 4.2.2 Terminologi Peningkatan privasi memerlukan terminologi baru yang berbeda dengan entitas Bitcoin. private ec-key adalah kunci privat kurva elips standar: angka \(a \in [1, l - 1]\); kunci ec publik adalah kunci publik kurva elips standar: titik A = aG; pasangan kunci satu kali adalah sepasang kunci pribadi dan publik; 5 10 Keterhubungan dalam arti “tanda tangan cincin yang dapat ditautkan” berarti kita dapat mengetahui apakah dua transaksi keluar berasal dari sumber yang sama tanpa mengungkapkan siapa sumbernya. Para penulis melemah keterhubungan sehingga (a) menjaga privasi, namun tetap (b) mendeteksi transaksi apa pun yang menggunakan kunci pribadi kedua kalinya sebagai tidak sah. Oke, jadi ini pertanyaan urutan kejadian. Pertimbangkan skenario berikut. Penambangan saya komputer akan memiliki blockchain saat ini, ia akan memiliki blok transaksi sendiri yang dipanggilnya sah, ia akan mengerjakan blok itu dalam teka-teki proof-of-work, dan ia akan memiliki daftar transaksi yang tertunda untuk ditambahkan ke blok berikutnya. Itu juga akan mengirimkan yang baru transaksi ke dalam kumpulan transaksi yang tertunda itu. Jika saya tidak menyelesaikan blok berikutnya, tapi orang lain melakukannya, saya mendapatkan salinan terbaru dari blockchain. Blok yang sedang saya kerjakan dan daftar transaksi saya yang tertunda, keduanya mungkin memiliki beberapa transaksi yang sekarang dimasukkan ke dalam blockchain. Buka blok saya yang tertunda, gabungkan itu dengan daftar transaksi saya yang tertunda, dan panggil itu kumpulan transaksi saya yang tertunda. Hapus semua yang sekarang secara resmi ada di blockchain. Sekarang, apa yang harus saya lakukan? Haruskah saya terlebih dahulu melakukan dan "menghapus semua pembelanjaan ganda"? Di sisi lain Sebaliknya, haruskah saya menelusuri daftar dan memastikan bahwa setiap kunci pribadi belum ada digunakan, dan jika sudah digunakan dalam daftar saya, maka saya menerima salinan pertama terlebih dahulu, dan karenanya salinan selanjutnya tidak sah. Jadi saya melanjutkan dengan menghapus semua instance setelah yang pertama dari kunci pribadi yang sama. Geometri aljabar tidak pernah menjadi keahlian saya. http://en.wikipedia.org/wiki/EdDSA Kecepatan seperti itu, wow. INI adalah geometri aljabar untuk kemenangan. Bukannya aku tahu apa pun tentang itu. Masalahnya, atau tidak, log diskrit menjadi sangat cepat. Dan komputer kuantum memakannya untuk sarapan. http://link.springer.com/article/10.1007/s13389-012-0027-1 Ini menjadi angka yang sangat penting, namun tidak ada penjelasan atau kutipan bagaimana caranya dipilih. Cukup dengan memilih satu bilangan prima besar yang diketahui saja sudah cukup, tetapi jika memang ada bilangan prima yang diketahui fakta tentang bilangan prima besar ini, yang dapat memengaruhi pilihan kita. Varian berbeda dari cryptonote dapat memilih nilai yang berbeda eh, tapi belum ada pembahasan di tulisan ini tentang bagaimana caranya pilihan kita akan memengaruhi pilihan kita terhadap parameter global lainnya yang tercantum di halaman 5. Makalah ini memerlukan bagian tentang pemilihan nilai parameter.

kunci pengguna pribadi adalah pasangan (a, b) dari dua kunci pribadi yang berbeda; kunci pelacakan adalah pasangan (a, B) dari kunci ec pribadi dan publik (di mana B = bG dan a ̸= b); kunci pengguna publik adalah pasangan (A, B) dari dua kunci ec publik yang berasal dari (a, b); alamat standar adalah representasi kunci pengguna publik yang diberikan ke dalam string ramah manusia dengan koreksi kesalahan; alamat terpotong adalah representasi paruh kedua (titik B) dari kunci pengguna publik yang diberikan menjadi string ramah manusia dengan koreksi kesalahan. Struktur transaksi tetap serupa dengan struktur di Bitcoin: setiap pengguna dapat memilih beberapa pembayaran masuk independen (keluaran transaksi), tandatangani dengan yang sesuai kunci pribadi dan mengirimkannya ke tujuan yang berbeda. Bertentangan dengan model Bitcoin, di mana pengguna memiliki kunci pribadi dan publik yang unik, dalam model yang diusulkan pengirim menghasilkan kunci publik satu kali berdasarkan alamat penerima dan beberapa data acak. Dalam pengertian ini, transaksi masuk untuk penerima yang sama dikirim ke a kunci publik satu kali (tidak langsung ke alamat unik) dan hanya penerima yang dapat memulihkannya bagian pribadi yang sesuai untuk menebus dananya (menggunakan kunci pribadi uniknya). Penerima bisa membelanjakan dananya menggunakan tanda tangan cincin, menjaga kepemilikan dan pengeluaran aktualnya tetap anonim. Rincian protokol dijelaskan pada subbagian berikutnya. 4.3 Pembayaran yang tidak dapat ditautkan Alamat Bitcoin klasik, setelah dipublikasikan, menjadi pengenal yang jelas untuk masuk pembayaran, menghubungkannya dan mengaitkannya dengan nama samaran penerima. Jika seseorang ingin menerima transaksi “tidak terikat”, ia harus menyampaikan alamatnya kepada pengirim melalui saluran pribadi. Jika dia ingin menerima transaksi berbeda yang tidak dapat dibuktikan milik pemilik yang sama dia harus membuat semua alamat yang berbeda dan tidak pernah mempublikasikannya dengan nama samarannya sendiri. Publik Pribadi Alice Karol Addr Bob 1 Addr Bob 2 Kunci Bob 1 Kunci Bob 2 Bob Gambar 2. Model kunci/transaksi Bitcoin tradisional. Kami mengusulkan solusi yang memungkinkan pengguna untuk mempublikasikan satu alamat dan menerima tanpa syarat pembayaran yang tidak dapat dihubungkan. Tujuan dari setiap keluaran CryptoNote (secara default) adalah kunci publik, berasal dari alamat penerima dan data acak pengirim. Keuntungan utama melawan Bitcoin adalah setiap kunci tujuan bersifat unik secara default (kecuali pengirim menggunakan data yang sama untuk masing-masing kunci tujuan transaksinya kepada penerima yang sama). Oleh karena itu, tidak ada masalah seperti “penggunaan kembali alamat” oleh desainnya dan tidak ada pengamat yang dapat menentukan apakah ada transaksi yang dikirim ke alamat atau tautan tertentu dua alamat bersama-sama. 6 kunci pengguna pribadi adalah pasangan (a, b) dari dua kunci pribadi yang berbeda; kunci pelacakan adalah pasangan (a, B) dari kunci ec pribadi dan publik (di mana B = bG dan a ̸= b); kunci pengguna publik adalah pasangan (A, B) dari dua kunci ec publik yang berasal dari (a, b); alamat standar adalah representasi kunci pengguna publik yang diberikan ke dalam string ramah manusia dengan koreksi kesalahan; alamat terpotong adalah representasi paruh kedua (titik B) dari kunci pengguna publik yang diberikan menjadi string ramah manusia dengan koreksi kesalahan. Struktur transaksi tetap serupa dengan struktur di Bitcoin: setiap pengguna dapat memilih beberapa pembayaran masuk independen (keluaran transaksi), tandatangani dengan yang sesuai kunci pribadi dan mengirimkannya ke tujuan yang berbeda. Bertentangan dengan model Bitcoin, di mana pengguna memiliki kunci pribadi dan publik yang unik, dalam model yang diusulkan pengirim menghasilkan kunci publik satu kali berdasarkan alamat penerima dan beberapa data acak. Dalam pengertian ini, transaksi masuk untuk penerima yang sama dikirim ke a kunci publik satu kali (tidak langsung ke alamat unik) dan hanya penerima yang dapat memulihkannya bagian pribadi yang sesuai untuk menebus dananya (menggunakan kunci pribadi uniknya). Penerima bisa membelanjakan dananya menggunakan tanda tangan cincin, menjaga kepemilikan dan pengeluaran aktualnya tetap anonim. Rincian protokol dijelaskan pada subbagian berikutnya. 4.3 Pembayaran yang tidak dapat ditautkan Alamat Bitcoin klasik, setelah dipublikasikan, menjadi pengenal yang jelas untuk masuk pembayaran, menghubungkannya dan mengaitkannya dengan nama samaran penerima. Jika seseorang ingin menerima transaksi “tidak terikat”, ia harus menyampaikan alamatnya kepada pengirim melalui saluran pribadi. Jika dia ingin menerima transaksi berbeda yang tidak dapat dibuktikan milik pemilik yang sama dia harus membuat semua alamat yang berbeda dan tidak pernah mempublikasikannya dengan nama samarannya sendiri. Publik Pribadi Alice Karol Addr Bob 1 Addr Bob 2 Kunci Bob 1 Kunci Bob 2 Bob Gambar 2. Mod kunci/transaksi Bitcoin tradisionalel. Kami mengusulkan solusi yang memungkinkan pengguna untuk mempublikasikan satu alamat dan menerima tanpa syarat pembayaran yang tidak dapat dihubungkan. Tujuan dari setiap keluaran CryptoNote (secara default) adalah kunci publik, berasal dari alamat penerima dan data acak pengirim. Keuntungan utama melawan Bitcoin adalah setiap kunci tujuan bersifat unik secara default (kecuali pengirim menggunakan data yang sama untuk masing-masing kunci tujuan transaksinya kepada penerima yang sama). Oleh karena itu, tidak ada masalah seperti “penggunaan kembali alamat” oleh desainnya dan tidak ada pengamat yang dapat menentukan apakah ada transaksi yang dikirim ke alamat atau tautan tertentu dua alamat bersama-sama. 6 11 Jadi ini seperti Bitcoin, tetapi dengan PO Box anonim yang tak terbatas, hanya dapat ditukarkan oleh penerima menghasilkan kunci pribadi yang anonim seperti tanda tangan cincin. Bitcoin bekerja dengan cara ini. Jika Alex memiliki 0,112 Bitcoin di dompetnya yang baru saja dia terima dari Frank, dia benar-benar memiliki tanda tangan pesan "Saya, [FRANK], kirim 0,112 Bitcoin ke [alex] + H0 + N0" dimana 1) Frank telah menandatangani pesan dengan kunci pribadinya [FRANK], 2) Frank telah menandatangani pesan tersebut dengan publik Alex key, [alex], 3) Frank telah memasukkan beberapa bentuk sejarah bitcoin, H0, dan 4) Frank menyertakan sedikit data acak yang disebut nonce, N0. Jika Alex kemudian ingin mengirim 0,011 Bitcoin ke Charlene, dia akan menerima pesan Frank, dan dia akan menyetelnya ke H1, dan menandatangani dua pesan: satu untuk transaksinya, dan satu lagi untuk perubahan. H1= "Saya, [FRANK], kirim 0,112 Bitcoin ke [alex] + H0 + N" "Saya, [ALEX], kirim 0,011 Bitcoin ke [charlene] + H1 + N1" "Saya, [ALEX], kirim 0,101 Bitcoin sebagai perubahan ke [alex] + H1 + N2." di mana Alex menandatangani kedua pesan dengan kunci pribadinya [ALEX], pesan pertama dengan milik Charlene kunci publik [charlene], pesan kedua dengan kunci publik Alex [alex], dan termasuk sejarah dan beberapa nonces N1 dan N2 yang dihasilkan secara acak dengan tepat. Cryptonote bekerja dengan cara ini: Jika Alex memiliki 0,112 Cryptonote di dompetnya yang baru saja dia terima dari Frank, dia benar-benar memiliki tanda tangan pesan "Saya, [seseorang dalam grup ad-hoc], mengirim 0,112 Cryptonote ke [alamat satu kali] + H0 + Tidak0." Alex mengetahui bahwa ini adalah uangnya dengan memeriksa kunci pribadinya [ALEX]. [alamat satu kali] untuk setiap pesan yang lewat, dan jika dia ingin membelanjakannya, dia melakukannya cara berikut. Dia memilih penerima uang, mungkin Charlene sudah mulai memilih serangan drone Alex malah ingin mengirim uang ke Brenda. Jadi Alex mencari kunci publik Brenda, [brenda], dan menggunakan kunci pribadinya sendiri, [ALEX], untuk menghasilkan alamat satu kali [ALEX+brenda]. Dia kemudian memilih koleksi C yang sewenang-wenang dari jaringan pengguna cryptonote dan dia membangunnya tanda tangan cincin dari grup ad-hoc ini. Kami mengatur riwayat kami seperti pesan sebelumnya, tambahkan nonces, dan lanjutkan seperti biasa? H1 = "Saya, [seseorang dalam grup ad-hoc], mengirim 0,112 Cryptonote ke [alamat satu kali] + H0 + Tidak0." "Saya, [seseorang di koleksi C], mengirim 0,011 Cryptonote ke [alamat-satu-kali-dibuat-dariALEX+brenda] + H1 + N1" "Saya, [seseorang di koleksi C], mengirimkan 0,101 Cryptonote sebagai perubahan ke [alamat-satu-kali-dibuat dari-ALEX+alex] + H1 + N2" Sekarang, Alex dan Brenda memindai semua pesan masuk untuk mencari alamat satu kali yang ada dibuat menggunakan kunci mereka. Jika mereka menemukannya, maka pesan itu adalah pesan baru bagi mereka uang kripto! Itupun transaksinya masih akan mencapai blockchain. Jika koin masuk ke alamat itu diketahui dikirim dari penjahat, kontributor politik, atau dari komite dan akun dengan anggaran yang ketat (yaitu penggelapan), atau jika pemilik baru koin tersebut melakukan kesalahan dan mengirimkan koin-koin ini ke alamat yang sama dengan koin-koin yang diketahui miliknya, jig anonimitas ada di bitcoin.

kunci pengguna pribadi adalah pasangan (a, b) dari dua kunci pribadi yang berbeda; kunci pelacakan adalah pasangan (a, B) dari kunci ec pribadi dan publik (di mana B = bG dan a ̸= b); kunci pengguna publik adalah pasangan (A, B) dari dua kunci ec publik yang berasal dari (a, b); alamat standar adalah representasi kunci pengguna publik yang diberikan ke dalam string ramah manusia dengan koreksi kesalahan; alamat terpotong adalah representasi paruh kedua (titik B) dari kunci pengguna publik yang diberikan menjadi string ramah manusia dengan koreksi kesalahan. Struktur transaksi tetap serupa dengan struktur di Bitcoin: setiap pengguna dapat memilih beberapa pembayaran masuk independen (keluaran transaksi), tandatangani dengan yang sesuai kunci pribadi dan mengirimkannya ke tujuan yang berbeda. Bertentangan dengan model Bitcoin, di mana pengguna memiliki kunci pribadi dan publik yang unik, dalam model yang diusulkan pengirim menghasilkan kunci publik satu kali berdasarkan alamat penerima dan beberapa data acak. Dalam pengertian ini, transaksi masuk untuk penerima yang sama dikirim ke a kunci publik satu kali (tidak langsung ke alamat unik) dan hanya penerima yang dapat memulihkannya bagian pribadi yang sesuai untuk menebus dananya (menggunakan kunci pribadi uniknya). Penerima bisa membelanjakan dananya menggunakan tanda tangan cincin, menjaga kepemilikan dan pengeluaran aktualnya tetap anonim. Rincian protokol dijelaskan pada subbagian berikutnya. 4.3 Pembayaran yang tidak dapat ditautkan Alamat Bitcoin klasik, setelah dipublikasikan, menjadi pengenal yang jelas untuk masuk pembayaran, menghubungkannya dan mengaitkannya dengan nama samaran penerima. Jika seseorang ingin menerima transaksi “tidak terikat”, ia harus menyampaikan alamatnya kepada pengirim melalui saluran pribadi. Jika dia ingin menerima transaksi berbeda yang tidak dapat dibuktikan milik pemilik yang sama dia harus membuat semua alamat yang berbeda dan tidak pernah mempublikasikannya dengan nama samarannya sendiri. Publik Pribadi Alice Karol Addr Bob 1 Addr Bob 2 Kunci Bob 1 Kunci Bob 2 Bob Gambar 2. Model kunci/transaksi Bitcoin tradisional. Kami mengusulkan solusi yang memungkinkan pengguna untuk mempublikasikan satu alamat dan menerima tanpa syarat pembayaran yang tidak dapat dihubungkan. Tujuan dari setiap keluaran CryptoNote (secara default) adalah kunci publik, berasal dari alamat penerima dan data acak pengirim. Keuntungan utama melawan Bitcoin adalah setiap kunci tujuan bersifat unik secara default (kecuali pengirim menggunakan data yang sama untuk masing-masing kunci tujuan transaksinya kepada penerima yang sama). Oleh karena itu, tidak ada masalah seperti “penggunaan kembali alamat” oleh desainnya dan tidak ada pengamat yang dapat menentukan apakah ada transaksi yang dikirim ke alamat atau tautan tertentu dua alamat bersama-sama. 6 kunci pengguna pribadi adalah pasangan (a, b) dari dua kunci pribadi yang berbeda; kunci pelacakan adalah pasangan (a, B) dari kunci ec pribadi dan publik (di mana B = bG dan a ̸= b); kunci pengguna publik adalah pasangan (A, B) dari dua kunci ec publik yang berasal dari (a, b); alamat standar adalah representasi kunci pengguna publik yang diberikan ke dalam string ramah manusia dengan koreksi kesalahan; alamat terpotong adalah representasi paruh kedua (titik B) dari kunci pengguna publik yang diberikan menjadi string ramah manusia dengan koreksi kesalahan. Struktur transaksi tetap serupa dengan struktur di Bitcoin: setiap pengguna dapat memilih beberapa pembayaran masuk independen (keluaran transaksi), tandatangani dengan yang sesuai kunci pribadi dan mengirimkannya ke tujuan yang berbeda. Bertentangan dengan model Bitcoin, di mana pengguna memiliki kunci pribadi dan publik yang unik, di model yang diusulkan pengirim menghasilkan kunci publik satu kali berdasarkan alamat penerima dan beberapa data acak. Dalam pengertian ini, transaksi masuk untuk penerima yang sama dikirim ke a kunci publik satu kali (tidak langsung ke alamat unik) dan hanya penerima yang dapat memulihkannya bagian pribadi yang sesuai untuk menebus dananya (menggunakan kunci pribadi uniknya). Penerima bisa membelanjakan dananya menggunakan tanda tangan cincin, menjaga kepemilikan dan pengeluaran aktualnya tetap anonim. Rincian protokol dijelaskan pada subbagian berikutnya. 4.3 Pembayaran yang tidak dapat ditautkan Alamat Bitcoin klasik, setelah dipublikasikan, menjadi pengenal yang jelas untuk masuk pembayaran, menghubungkannya dan mengaitkannya dengan nama samaran penerima. Jika seseorang ingin menerima transaksi “tidak terikat”, ia harus menyampaikan alamatnya kepada pengirim melalui saluran pribadi. Jika dia ingin menerima transaksi berbeda yang tidak dapat dibuktikan milik pemilik yang sama dia harus membuat semua alamat yang berbeda dan tidak pernah mempublikasikannya dengan nama samarannya sendiri. Publik Pribadi Alice Karol Addr Bob 1 Addr Bob 2 Kunci Bob 1 Kunci Bob 2 Bob Gambar 2. Mod kunci/transaksi Bitcoin tradisionalel. Kami mengusulkan solusi yang memungkinkan pengguna untuk mempublikasikan satu alamat dan menerima tanpa syarat pembayaran yang tidak dapat dihubungkan. Tujuan dari setiap keluaran CryptoNote (secara default) adalah kunci publik, berasal dari alamat penerima dan data acak pengirim. Keuntungan utama melawan Bitcoin adalah setiap kunci tujuan bersifat unik secara default (kecuali pengirim menggunakan data yang sama untuk masing-masing kunci tujuan transaksinya kepada penerima yang sama). Oleh karena itu, tidak ada masalah seperti “penggunaan kembali alamat” oleh desainnya dan tidak ada pengamat yang dapat menentukan apakah ada transaksi yang dikirim ke alamat atau tautan tertentu dua alamat bersama-sama. 6 12 Oleh karena itu, daripada pengguna mengirimkan koin dari alamat (yang sebenarnya merupakan kunci publik) ke alamat (kunci publik lainnya) menggunakan kunci pribadi mereka, pengguna mengirimkan koin dari PO-box satu kali (yang dihasilkan menggunakan kunci publik teman Anda) ke PO-box satu kali (demikian pula) menggunakan kunci pribadinya sendiri. Dalam arti tertentu, kita mengatakan, "Oke, semuanya, ambillah uang itu selagi masih ada dipindahkan! Cukup mengetahui bahwa kunci kita dapat membuka kotak itu dan itu kita tahu berapa banyak uang yang ada di dalam kotak. Jangan pernah menaruh sidik jari Anda di PO Box atau benar-benar menggunakannya, cukup tukarkan kotak yang berisi uang tunai itu sendiri. Dengan begitu kita tidak tahu siapa yang mengirim apa, tapi isi dari pidato publik ini masih tanpa gesekan, sepadan, dapat dibagi, dan masih memiliki semua kualitas uang bagus lainnya yang kita inginkan seperti bitcoin." Satu set kotak PO yang tak terbatas. Anda mempublikasikan alamat, saya punya kunci pribadi. Saya menggunakan kunci pribadi saya dan alamat Anda, dan beberapa data acak, untuk menghasilkan kunci publik. Algoritma ini dirancang sedemikian rupa sehingga, sejak Anda alamat digunakan untuk menghasilkan kunci publik, hanya kunci pribadi ANDA yang berfungsi untuk membuka kunci pesan. Seorang pengamat, Eve, melihat Anda mempublikasikan alamat Anda, dan melihat kunci publik yang saya umumkan. Namun, dia tidak tahu apakah saya mengumumkan kunci publik saya berdasarkan alamat Anda, alamatnya, atau alamat Brenda atau milik Charlene, atau siapa pun. Dia memeriksa kunci pribadinya dengan kunci publik yang saya umumkan dan melihatnya tidak berhasil; itu bukan uangnya. Dia tidak mengetahui kunci pribadi orang lain, dan hanya penerima pesan yang memiliki kunci pribadi yang dapat membuka kunci pesan tersebut. Jadi tidak ada seorang pun mendengarkan dapat menentukan siapa yang menerima uang apalagi mengambil uang tersebut.

Publik Pribadi Alice Karol Kunci satu kali Kunci satu kali Kunci satu kali Bob Kunci Bob Alamat Bob Gambar 3. Kunci/model transaksi CryptoNote. Pertama, pengirim melakukan pertukaran Diﬃe-Hellman untuk mendapatkan rahasia bersama dari datanya dan setengah dari alamat penerima. Kemudian dia menghitung kunci tujuan satu kali, menggunakan kunci bersama rahasia dan paruh kedua alamat. Dua kunci ec yang berbeda diperlukan dari penerima untuk dua langkah ini, jadi alamat CryptoNote standar hampir dua kali lebih besar dari dompet Bitcoin alamat. Penerima juga melakukan pertukaran Diﬃe-Hellman untuk memulihkannya kunci rahasia. Urutan transaksi standar adalah sebagai berikut: 1. Alice ingin mengirimkan pembayaran kepada Bob, yang telah mempublikasikan alamat standarnya. Dia membongkar alamatnya dan mendapatkan kunci publik Bob (A, B). 2. Alice membangkitkan r acak \(\in\)[1, l−1] dan menghitung kunci publik satu kali \(P = H_s(rA)G +\) B. 3. Alice menggunakan P sebagai kunci tujuan untuk keluaran dan juga mengemas nilai R = rG (sebagai bagian dari bursa Diﬃe-Hellman) di suatu tempat dalam transaksi. Perhatikan bahwa dia bisa mencipta keluaran lain dengan kunci publik unik: kunci penerima yang berbeda (Ai, Bi) menyiratkan Pi yang berbeda bahkan dengan r yang sama. Transaksi Terima kasih kunci publik Keluaran terima kasih Jumlah Kunci tujuan R = rG P = Hs(rA)G + B Penerima kunci publik Data acak pengirim r (A,B) Gambar 4. Struktur transaksi standar. 4. Alice mengirimkan transaksi. 5. Bob memeriksa setiap transaksi yang lewat dengan kunci privatnya (a, b), dan menghitung P ′ = Hs(ar)G + B. Jika transaksi Alice dengan Bob sebagai penerima ada di antara mereka, maka aR = arG = rA dan P′ = P. 7 Publik Pribadi Alice Karol Kunci satu kali Kunci satu kali Kunci satu kali Bob Kunci Bob Alamat Bob Gambar 3. Kunci/model transaksi CryptoNote. Pertama, pengirim melakukan pertukaran Diﬃe-Hellman untuk mendapatkan rahasia bersama dari datanya dan setengah dari alamat penerima. Kemudian dia menghitung kunci tujuan satu kali, menggunakan kunci bersama rahasia dan paruh kedua alamat. Dua kunci ec yang berbeda diperlukan dari penerima untuk dua langkah ini, jadi alamat CryptoNote standar hampir dua kali lebih besar dari dompet Bitcoin alamat. Penerima juga melakukan pertukaran Diﬃe-Hellman untuk memulihkannya kunci rahasia. Urutan transaksi standar adalah sebagai berikut: 1. Alice ingin mengirimkan pembayaran kepada Bob, yang telah mempublikasikan alamat standarnya. Dia membongkar alamatnya dan mendapatkan kunci publik Bob (A, B). 2. Alice membangkitkan r acak \(\in\)[1, l−1] dan menghitung kunci publik satu kali \(P = H_s(rA)G +\) B. 3. Alice menggunakan P sebagai kunci tujuan untuk keluaran dan juga mengemas nilai R = rG (sebagai bagian dari bursa Diﬃe-Hellman) di suatu tempat dalam transaksi. Perhatikan bahwa dia bisa mencipta keluaran lain dengan kunci publik unik: kunci penerima yang berbeda (Ai, Bi) menyiratkan Pi yang berbeda bahkan dengan r yang sama. Transaksi Terima kasih kunci publik Keluaran terima kasih Jumlah Kunci tujuan R = rG P = Hs(rA)G + B Penerima kunci publik Data acak pengirim r (A,B) Gambar 4. Struktur transaksi standar. 4. Alice mengirimkan transaksi. 5. Bob memeriksa setiap transaksi yang lewat dengan kunci privatnya (a, b), dan menghitung P ′ = Hs(ar)G + B. Jika transaksi Alice dengan Bob sebagai penerima ada di antara mereka, maka aR = arG = rA dan P′ = P. 7 13 Saya bertanya-tanya betapa sulitnya menerapkan pilihan kriptografi skema. Elips atau lainnya. Jadi jika suatu skema dilanggar di masa depan, mata uang akan beralih tanpa rasa khawatir. Mungkin sangat menyebalkan. Oke, ini persis seperti yang baru saja saya jelaskan di komentar saya sebelumnya. Tipe Diffe-Hellman pertukarannya rapi. Katakanlah Alex dan Brenda masing-masing mempunyai nomor rahasia, A dan B, dan sebuah nomor mereka tidak peduli untuk menjaga rahasia, a dan b. Mereka ingin menghasilkan rahasia bersama tanpa Eva menemukannya. Diﬃe dan Hellman menemukan cara agar Alex dan Brenda berbagi nomor publik a dan b, tetapi bukan nomor pribadi A dan B, dan menghasilkan rahasia bersama, K. Menggunakan rahasia bersama ini, K, tanpa ada Eva yang mendengarkan untuk dapat menghasilkan hal yang sama K, Alex dan Brenda sekarang dapat menggunakan K sebagai kunci enkripsi rahasia dan meneruskan pesan rahasia kembali dan sebagainya. Begini cara kerjanya BISA, meskipun harus bekerja dengan angka yang jauh lebih besar dari 100. Kita akan menggunakan 100 karena mengerjakan bilangan bulat modulo 100 sama dengan "membuang semua tapi dua digit terakhir dari sebuah angka." Alex dan Brenda masing-masing memilih A, a, B, dan b. Mereka merahasiakan A dan B. Alex memberi tahu Brenda nilai modulo 100 (hanya dua digit terakhir) dan Brenda memberi tahu Alex nilai b modulo 100. Sekarang Eva tahu (a,b) modulo 100. Tapi Alex tahu (a,b,A) jadi dia dapat menghitung x=abA modulo 100.Alex memotong semuanya kecuali angka terakhir karena kami sedang mengerjakan di bawah bilangan bulat modulo 100 lagi. Demikian pula, Brenda mengetahui (a,b,B) sehingga dia dapat menghitung y=abB modulo 100. Alex sekarang dapat mempublikasikan x dan Brenda dapat mempublikasikan y. Tapi sekarang Alex bisa menghitung yA = abBA modulo 100, dan Brenda bisa menghitung xB = abBA modulo 100. Mereka berdua tahu nomor yang sama! Tapi yang Eva dengar hanyalah (a,b,abA,abB). Dia tidak memiliki cara mudah untuk menghitung abA*B. Sekarang, ini adalah cara berpikir yang paling mudah dan paling tidak aman tentang pertukaran Diﬃe-Hellman. Ada versi yang lebih aman. Tetapi sebagian besar versi berfungsi karena faktorisasi bilangan bulat dan diskrit logaritma itu sulit, dan kedua permasalahan tersebut mudah diselesaikan oleh komputer kuantum. Saya akan melihat apakah ada versi yang tahan terhadap kuantum. http://en.wikipedia.org/wiki/Diﬃe%E2%80%93Hellman_key_exchange "Urutan txn standar" yang tercantum di sini tidak memiliki banyak langkah, seperti TANDA TANGAN. Mereka dianggap remeh di sini. Yang benar-benar buruk, karena urutannya kita barang tanda tangan, informasi yang disertakan dalam pesan yang ditandatangani, dan sebagainya... semua ini luar biasa penting bagi protokol. Melakukan satu atau dua langkah yang salah, bahkan sedikit tidak sesuai, saat menerapkan "the urutan transaksi standar" dapat mempertanyakan keamanan seluruh sistem. Selain itu, bukti-bukti yang disajikan kemudian dalam makalah ini mungkin tidak cukup teliti jika kerangka kerja di mana mereka bekerja didefinisikan secara longgar seperti pada bagian ini.

Publik Pribadi Alice Karol Kunci satu kali Kunci satu kali Kunci satu kali Bob Kunci Bob Alamat Bob Gambar 3. Kunci/model transaksi CryptoNote. Pertama, pengirim melakukan pertukaran Diﬃe-Hellman untuk mendapatkan rahasia bersama dari datanya dan setengah dari alamat penerima. Kemudian dia menghitung kunci tujuan satu kali, menggunakan kunci bersama rahasia dan paruh kedua alamat. Dua kunci ec yang berbeda diperlukan dari penerima untuk dua langkah ini, jadi alamat CryptoNote standar hampir dua kali lebih besar dari dompet Bitcoin alamat. Penerima juga melakukan pertukaran Diﬃe-Hellman untuk memulihkannya kunci rahasia. Urutan transaksi standar adalah sebagai berikut: 1. Alice ingin mengirimkan pembayaran kepada Bob, yang telah mempublikasikan alamat standarnya. Dia membongkar alamatnya dan mendapatkan kunci publik Bob (A, B). 2. Alice membangkitkan r acak \(\in\)[1, l−1] dan menghitung kunci publik satu kali \(P = H_s(rA)G +\) B. 3. Alice menggunakan P sebagai kunci tujuan untuk keluaran dan juga mengemas nilai R = rG (sebagai bagian dari bursa Diﬃe-Hellman) di suatu tempat dalam transaksi. Perhatikan bahwa dia bisa mencipta keluaran lain dengan kunci publik unik: kunci penerima yang berbeda (Ai, Bi) menyiratkan Pi yang berbeda bahkan dengan r yang sama. Transaksi Terima kasih kunci publik Keluaran terima kasih Jumlah Kunci tujuan R = rG P = Hs(rA)G + B Penerima kunci publik Data acak pengirim r (A,B) Gambar 4. Struktur transaksi standar. 4. Alice mengirimkan transaksi. 5. Bob memeriksa setiap transaksi yang lewat dengan kunci privatnya (a, b), dan menghitung P ′ = Hs(ar)G + B. Jika transaksi Alice dengan Bob sebagai penerima ada di antara mereka, maka aR = arG = rA dan P′ = P. 7 Publik Pribadi Alice Karol Kunci satu kali Kunci satu kali Kunci satu kali Bob Kunci Bob Alamat Bob Gambar 3. Kunci/model transaksi CryptoNote. Pertama, pengirim melakukan pertukaran Diﬃe-Hellman untuk mendapatkan rahasia bersama dari datanya dan setengah dari alamat penerima. Kemudian dia menghitung kunci tujuan satu kali, menggunakan kunci bersama rahasia dan paruh kedua alamat. Dua kunci ec yang berbeda diperlukan dari penerima untuk dua langkah ini, jadi alamat CryptoNote standar hampir dua kali lebih besar dari dompet Bitcoin alamat. Penerima juga melakukan pertukaran Diﬃe-Hellman untuk memulihkannya kunci rahasia. Urutan transaksi standar adalah sebagai berikut: 1. Alice ingin mengirimkan pembayaran kepada Bob, yang telah mempublikasikan alamat standarnya. Dia membongkar alamatnya dan mendapatkan kunci publik Bob (A, B). 2. Alice membangkitkan r acak \(\in\)[1, l−1] dan menghitung kunci publik satu kali \(P = H_s(rA)G +\) B. 3. Alice menggunakan P sebagai kunci tujuan untuk keluaran dan juga mengemas nilai R = rG (sebagai bagian dari bursa Diﬃe-Hellman) di suatu tempat dalam transaksi. Perhatikan bahwa dia bisa mencipta keluaran lain dengan kunci publik unik: kunci penerima yang berbeda (Ai, Bi) menyiratkan Pi yang berbeda bahkan dengan r yang sama. Transaksi Terima kasih kunci publik Keluaran terima kasih Jumlah Kunci tujuan R = rG P = Hs(rA)G + B Penerima kunci publik Data acak pengirim r (A,B) Gambar 4. Struktur transaksi standar. 4. Alice mengirimkan transaksi. 5. Bob memeriksa setiap transaksi yang lewat dengan kunci privatnya (a, b), dan menghitung P ′ = Hs(ar)G + B. Jika transaksi Alice dengan Bob sebagai penerima ada di antara mereka, maka aR = arG = rA dan P′ = P. 7 14 Perhatikan bahwa penulisnya melakukan pekerjaan yang buruk dalam menjaga terminologi mereka tetap lurus teksnya, tetapi terutama di bagian berikutnya. Inkarnasi berikutnya dari makalah ini tentu saja akan terjadi jauh lebih ketat. Dalam teks mereka menyebut P sebagai kunci publik satu kali. Dalam diagram, mereka menyebut R sebagai "Kunci publik Tx" dan P sebagai "Kunci Tujuan". Jika saya ingin menulis ulang ini, saya akan melakukannya secara khusus memaparkan beberapa terminologi sebelum membahas bagian ini. Ell ini sangat besar. Lihat halaman 5. Siapa yang memilih El? Diagram tersebut menggambarkan bahwa transaksi kunci publik R = rG yang bersifat acak dan terpilih oleh pengirim, bukan bagian dari keluaran Tx. Ini karena bisa jadi sama untuk banyak orang transaksi ke banyak orang, dan tidak digunakan KEMUDIAN untuk dibelanjakan. R baru dihasilkan setiap kali Anda ingin menyiarkan transaksi CryptoNote baru. Selanjutnya R hanya digunakan untuk memeriksa apakah Anda adalah penerima transaksi. Ini bukan data sampah, tapi sampah bagi siapa pun tanpa kunci pribadi yang terkait dengan (A,B). Sebaliknya, kunci Tujuan, P = Hs(rA)G + B adalah bagian dari keluaran Tx. Semuanya mengobrak-abrik setiap data transaksi yang lewat harus memeriksa P* yang dihasilkannya sendiri P ini untuk melihat apakah mereka memiliki transaksi yang lewat ini. Siapa pun yang memiliki keluaran transaksi yang belum terpakai (UTXO) akan memiliki banyak Ps yang berserakan dengan jumlah. Untuk menghabiskand, mereka menandatangani beberapa pesan baru termasuk P. Alice harus menandatangani transaksi ini dengan kunci pribadi satu kali yang terkait dengan Kunci Tujuan keluaran transaksi yang tidak terpakai. Setiap kunci tujuan yang dimiliki oleh Alice dilengkapi dengan kunci pribadi satu kali yang juga dimiliki (mungkin) oleh Alice. Setiap kali Alice menginginkannya kirimkan isi kunci tujuan kepadaku, atau Bob, atau Brenda, atau Charlie atau Charlene, dia menggunakan kunci pribadinya untuk menandatangani transaksi. Setelah menerima transaksi, saya akan menerima yang baru Kunci publik Tx, kunci publik Tujuan baru, dan saya akan dapat memulihkan kunci pribadi satu kali yang baru x. Menggabungkan kunci pribadi satu kali saya, x, dengan Tujuan publik transaksi baru kuncinya adalah cara kami mengirim transaksi baru

Bob dapat memulihkan kunci pribadi satu kali yang sesuai: x = Hs(aR) + b, sehingga P = xG. Dia dapat membelanjakan output ini kapan saja dengan menandatangani transaksi dengan x. Transaksi Terima kasih kunci publik Keluaran terima kasih Jumlah Kunci tujuan P′ = Hs(aR)G + bG kunci publik satu kali x = Hs(aR) + b kunci pribadi satu kali Penerima kunci pribadi (a,b) R P' ?= hal Gambar 5. Pengecekan transaksi masuk. Hasilnya Bob mendapat pembayaran masuk, terkait dengan kunci publik satu kali tidak dapat dihubungkan untuk penonton. Beberapa catatan tambahan: • Ketika Bob “mengenali” transaksinya (lihat langkah 5) praktis dia hanya menggunakan setengah dari transaksinya informasi pribadi: (a, B). Pasangan ini, juga dikenal sebagai kunci pelacakan, dapat diteruskan kepada pihak ketiga (Carol). Bob dapat mendelegasikan kepadanya pemrosesan transaksi baru. Bob tidak perlu mempercayai Carol secara eksplisit, karena dia tidak dapat memulihkan kunci rahasia satu kali p tanpa kunci pribadi lengkap Bob (a, b). Pendekatan ini berguna ketika Bob kekurangan bandwidth atau kekuatan komputasi (ponsel pintar, dompet perangkat keras, dll.). • Jika Alice ingin membuktikan bahwa dia mengirimkan transaksi ke alamat Bob, dia dapat mengungkapkannya r atau gunakan protokol tanpa pengetahuan apa pun untuk membuktikan bahwa dia mengetahui r (misalnya dengan menandatangani transaksi dengan r). • Jika Bob ingin memiliki alamat yang kompatibel dengan audit di mana semua transaksi masuk berada dapat ditautkan, dia dapat mempublikasikan kunci pelacakannya atau menggunakan alamat yang terpotong. Alamat itu hanya mewakili satu kunci ec publik B, dan bagian sisanya yang diperlukan oleh protokol adalah diturunkan darinya sebagai berikut: a = Hs(B) dan A = Hs(B)G. Dalam kedua kasus tersebut, setiap orang demikian mampu “mengenali” semua transaksi masuk Bob, namun tentu saja tidak ada yang bisa membelanjakannya dana yang terkandung di dalamnya tanpa kunci rahasia b. 4.4 Tanda tangan cincin satu kali Protokol yang didasarkan pada tanda tangan dering satu kali memungkinkan pengguna mencapai ketidakterhubungan tanpa syarat. Sayangnya, jenis tanda tangan kriptografi biasa mengizinkan pelacakan transaksi ke mereka masing-masing pengirim dan penerima. Solusi kami terhadap kekurangan ini terletak pada penggunaan tanda tangan yang berbeda jenisnya dibandingkan yang saat ini digunakan dalam sistem kas elektronik. Pertama-tama kami akan memberikan gambaran umum tentang algoritma kami tanpa referensi eksplisit uang elektronik. Tanda tangan dering satu kali berisi empat algoritma: (GEN, SIG, VER, LNK): GEN: mengambil parameter publik dan mengeluarkan pasangan ec (P, x) dan kunci publik I. SIG: mengambil pesan m, satu set \(S'\) kunci publik {Pi}i̸=s, sepasang (Ps, xs) dan menghasilkan tanda tangan \(\sigma\) dan himpunan \(S = \)S'\( \cup \{P_s\}\). 8
Bob dapat memulihkan kunci pribadi satu kali yang sesuai: x = Hs(aR) + b, sehingga P = xG. Dia dapat membelanjakan output ini kapan saja dengan menandatangani transaksi dengan x. Transaksi Terima kasih kunci publik Keluaran terima kasih Jumlah Kunci tujuan P′ = Hs(aR)G + bG kunci publik satu kali x = Hs(aR) + b kunci pribadi satu kali Penerima kunci pribadi (a,b) R P' ?= hal Gambar 5. Pengecekan transaksi masuk. Hasilnya Bob mendapat pembayaran masuk, terkait dengan kunci publik satu kali tidak dapat dihubungkan untuk penonton. Beberapa catatan tambahan: • Ketika Bob “mengenali” transaksinya (lihat langkah 5) praktis dia hanya menggunakan setengah dari transaksinya informasi pribadi: (a, B). Pasangan ini, juga dikenal sebagai kunci pelacakan, dapat diteruskan kepada pihak ketiga (Carol). Bob dapat mendelegasikan kepadanya pemrosesan transaksi baru. Bob tidak perlu mempercayai Carol secara eksplisit, karena dia tidak dapat memulihkan kunci rahasia satu kali p tanpa kunci pribadi lengkap Bob (a,b). Pendekatan ini berguna ketika Bob kekurangan bandwidth atau kekuatan komputasi (ponsel pintar, dompet perangkat keras, dll.). • Jika Alice ingin membuktikan bahwa dia mengirimkan transaksi ke alamat Bob, dia dapat mengungkapkannya r atau gunakan protokol tanpa pengetahuan apa pun untuk membuktikan bahwa dia mengetahui r (misalnya dengan menandatangani transaksi dengan r). • Jika Bob ingin memiliki alamat yang kompatibel dengan audit di mana semua transaksi masuk berada dapat ditautkan, dia dapat mempublikasikan kunci pelacakannya atau menggunakan alamat yang terpotong. Alamat itu hanya mewakili satu kunci ec publik B, dan bagian sisanya yang diperlukan oleh protokol adalah diturunkan darinya sebagai berikut: a = Hs(B) dan A = Hs(B)G. Dalam kedua kasus tersebut, setiap orang demikian mampu “mengenali” semua transaksi masuk Bob, namun tentu saja tidak ada yang bisa membelanjakannya dana yang terkandung di dalamnya tanpa kunci rahasia b. 4.4 Tanda tangan cincin satu kali Protokol yang didasarkan pada tanda tangan dering satu kali memungkinkan pengguna mencapai ketidakterhubungan tanpa syarat. Sayangnya, jenis tanda tangan kriptografi biasa mengizinkan pelacakan transaksi ke mereka masing-masing pengirim dan penerima. Solusi kami terhadap kekurangan ini terletak pada penggunaan tanda tangan yang berbeda jenisnya dibandingkan yang saat ini digunakan dalam sistem kas elektronik. Pertama-tama kami akan menyediakan general deskripsi algoritma kami tanpa referensi eksplisit uang elektronik. Tanda tangan dering satu kali berisi empat algoritma: (GEN, SIG, VER, LNK): GEN: mengambil parameter publik dan mengeluarkan pasangan ec (P, x) dan kunci publik I. SIG: mengambil pesan m, satu set \(S'\) kunci publik {Pi}i̸=s, sepasang (Ps, xs) dan menghasilkan tanda tangan \(\sigma\) dan himpunan \(S = \)S'\( \cup \{P_s\}\). 8 15 Seperti apa keluaran transaksi yang belum terpakai di sini? Diagram menunjukkan bahwa keluaran transaksi hanya terdiri dari dua titik data: jumlah dan kunci tujuan. Tapi ini tidak cukup karena ketika saya mencoba menggunakan "output" ini saya masih perlu mengetahui R=rG. Ingat, r dipilih oleh pengirim, dan R a) digunakan untuk mengenali catatan kripto yang masuk sebagai milik Anda milik sendiri dan b) digunakan untuk menghasilkan kunci pribadi satu kali yang digunakan untuk "mengklaim" uang kripto Anda. Bagian tentang ini yang aku tidak mengerti? Mengambil teori "oke, kita punya ini tanda tangan dan transaksi, dan kami menyebarkannya bolak-balik" ke dunia pemrograman "oke informasi apa khususnya yang membentuk seorang individu UTXO?" Cara terbaik untuk menjawab pertanyaan itu adalah dengan menggali isi kode yang sepenuhnya tidak dikomentari. Bagus sekali, tim bytecoin. Ingat: keterhubungan berarti "apakah orang yang sama mengirim?" dan unlinkability berarti "melakukan hal yang sama orang menerima?". Jadi suatu sistem bisa bersifat linkable atau non-linkable, unlinkable atau non-unlinkable. Mengganggu, aku tahu. Jadi ketika Nic van Saberhagen di sini mengatakan "...pembayaran yang masuk dikaitkan dengan satu kali saja kunci publik yang tidak dapat ditautkan oleh penonton," mari kita lihat apa maksudnya. Pertama, pertimbangkan situasi di mana Alice mengirim Bob dua transaksi terpisah dari transaksi yang sama alamat ke alamat yang sama. Di alam semesta Bitcoin, Alice telah melakukan kesalahan mengirim dari alamat yang sama sehingga transaksi telah gagal memenuhi keinginan kami secara terbatas keterhubungan. Terlebih lagi, karena dia mengirimkan uang ke alamat yang sama, dia menggagalkan keinginan kami untuk tidak dapat dihubungkan. Transaksi bitcoin ini (sepenuhnya) dapat ditautkan dan tidak dapat dibatalkan tautannya. Di sisi lain, di dunia cryptonote, katakanlah Alice mengirimi Bob beberapa cryptonote, menggunakan alamat publik Bob. Dia memilih sebagai kumpulan kunci publiknya yang mengaburkan semua publik yang dikenal kunci di wilayah metro Washington DC. Alex menghasilkan kunci publik satu kali menggunakan miliknya sendiri informasi dan informasi publik Bob. Dia mengirimkan uangnya, dan pengamat mana pun akan melakukannya hanya dapat memperoleh informasi "Seseorang dari wilayah metro Washington DC mengirim 2,3 cryptonotes ke alamat publik satu kali XYZ123." Kami memiliki kendali probabilistik atas keterhubungan di sini, jadi kami menyebutnya "hampir tidak dapat ditautkan". Kami juga hanya melihat satu kali kunci publik yang menjadi tujuan pengiriman uang. Bahkan jika kita mencurigai penerimanya adalah Bob, kami tidak memiliki kunci pribadinya sehingga kami tidak dapat menguji apakah transaksi tersebut lewat milik Bob apalagi menghasilkan kunci pribadi satu kali untuk menebus cryptonote-nya. Jadi ini pada kenyataannya, sama sekali "tidak dapat dihubungkan". Jadi, ini adalah trik yang paling rapi. Siapa yang ingin mempercayai MtGox lain? Kita mungkin saja nyaman menyimpan sejumlah BTC di Coinbase, tetapi keamanan bitcoin yang paling utama adalah dompet fisik. Itu tidak nyaman. Dalam hal ini, Anda dapat memberikan setengah dari kunci pribadi Anda tanpa mengorbankan kunci pribadi Anda kemampuan sendiri untuk membelanjakan uang. Saat melakukan ini, yang Anda lakukan hanyalah memberi tahu seseorang cara memutus ketidakterhubungan. Yang lainnya properti CN yang bertindak seperti mata uang dipertahankan, sebagai bukti terhadap pembelanjaan ganda dan yang lainnya.
Bob dapat memulihkan kunci pribadi satu kali yang sesuai: x = Hs(aR) + b, sehingga P = xG. Dia dapat membelanjakan output ini kapan saja dengan menandatangani transaksi dengan x. Transaksi Terima kasih kunci publik Keluaran terima kasih Jumlah Kunci tujuan P′ = Hs(aR)G + bG kunci publik satu kali x = Hs(aR) + b kunci pribadi satu kali Penerima kunci pribadi (a,b) R P' ?= hal Gambar 5. Pengecekan transaksi masuk. Hasilnya Bob mendapat pembayaran masuk, terkait dengan kunci publik satu kali tidak dapat dihubungkan untuk penonton. Beberapa catatan tambahan: • Ketika Bob “mengenali” transaksinya (lihat langkah 5) praktis dia hanya menggunakan setengah dari transaksinya informasi pribadi: (a, B). Pasangan ini, juga dikenal sebagai kunci pelacakan, dapat diteruskan kepada pihak ketiga (Carol). Bob dapat mendelegasikan kepadanya pemrosesan transaksi baru. Bob tidak perlu mempercayai Carol secara eksplisit, karena dia tidak dapat memulihkan kunci rahasia satu kali p tanpa kunci pribadi lengkap Bob (a, b). Pendekatan ini berguna ketika Bob kekurangan bandwidth atau kekuatan komputasi (ponsel pintar, dompet perangkat keras, dll.). • Jika Alice ingin membuktikan bahwa dia mengirimkan transaksi ke alamat Bob, dia dapat mengungkapkannya r atau gunakan protokol tanpa pengetahuan apa pun untuk membuktikan bahwa dia mengetahui r (misalnya dengan menandatangani transaksi dengan r). • Jika Bob ingin memiliki alamat yang kompatibel dengan audit di mana semua transaksi masuk berada dapat ditautkan, dia dapat mempublikasikan kunci pelacakannya atau menggunakan alamat yang terpotong. Alamat itu hanya mewakili satu kunci ec publik B, dan bagian sisanya yang diperlukan oleh protokol adalah diturunkan darinya sebagai berikut: a = Hs(B) dan A = Hs(B)G. Dalam kedua kasus tersebut, setiap orang demikian mampu “mengenali” semua transaksi masuk Bob, namun tentu saja tidak ada yang bisa membelanjakannya dana yang terkandung di dalamnya tanpa kunci rahasia b. 4.4 Tanda tangan cincin satu kali Protokol yang didasarkan pada tanda tangan dering satu kali memungkinkan pengguna mencapai ketidakterhubungan tanpa syarat. Sayangnya, jenis tanda tangan kriptografi biasa mengizinkan pelacakan transaksi ke mereka masing-masing pengirim dan penerima. Solusi kami terhadap kekurangan ini terletak pada penggunaan tanda tangan yang berbeda jenisnya dibandingkan yang saat ini digunakan dalam sistem kas elektronik. Pertama-tama kami akan memberikan gambaran umum tentang algoritma kami tanpa referensi eksplisit uang elektronik. Tanda tangan dering satu kali berisi empat algoritma: (GEN, SIG, VER, LNK): GEN: mengambil parameter publik dan mengeluarkan pasangan ec (P, x) dan kunci publik I. SIG: mengambil pesan m, satu set \(S'\) kunci publik {Pi}i̸=s, sepasang (Ps, xs) dan menghasilkan tanda tangan \(\sigma\) dan himpunan \(S = \)S'\( \cup \{P_s\}\). 8
Bob dapat memulihkan kunci pribadi satu kali yang sesuai: x = Hs(aR) + b, sehingga P = xG. Dia dapat membelanjakan output ini kapan saja dengan menandatangani transaksi dengan x. Transaksi Terima kasih kunci publik Keluaran terima kasih Jumlah Kunci tujuan P′ = Hs(aR)G + bG kunci publik satu kali x = Hs(aR) + b kunci pribadi satu kali Penerima kunci pribadi (a,b) R P' ?= hal Gambar 5. Pengecekan transaksi masuk. Hasilnya Bob mendapat pembayaran masuk, terkait dengan kunci publik satu kali tidak dapat dihubungkan untuk penonton. Beberapa catatan tambahan: • Ketika Bob “mengenali” transaksinya (lihat langkah 5) praktis dia hanya menggunakan setengah dari transaksinya informasi pribadi: (a, B). Pasangan ini, juga dikenal sebagai kunci pelacakan, dapat diteruskan kepada pihak ketiga (Carol). Bob dapat mendelegasikan kepadanya pemrosesan transaksi baru. Bob tidak perlu mempercayai Carol secara eksplisit, karena dia tidak dapat memulihkan kunci rahasia satu kali p tanpa kunci pribadi lengkap Bob (a,b). Pendekatan ini berguna ketika Bob kekurangan bandwidth atau kekuatan komputasi (ponsel pintar, dompet perangkat keras, dll.). • Jika Alice ingin membuktikan bahwa dia mengirimkan transaksi ke alamat Bob, dia dapat mengungkapkannya r atau gunakan protokol tanpa pengetahuan apa pun untuk membuktikan bahwa dia mengetahui r (misalnya dengan menandatangani transaksi dengan r). • Jika Bob ingin memiliki alamat yang kompatibel dengan audit di mana semua transaksi masuk berada dapat ditautkan, dia dapat mempublikasikan kunci pelacakannya atau menggunakan alamat yang terpotong. Alamat itu hanya mewakili satu kunci ec publik B, dan bagian sisanya yang diperlukan oleh protokol adalah diturunkan darinya sebagai berikut: a = Hs(B) dan A = Hs(B)G. Dalam kedua kasus tersebut, setiap orang demikian mampu “mengenali” semua transaksi masuk Bob, namun tentu saja tidak ada yang bisa membelanjakannya dana yang terkandung di dalamnya tanpa kunci rahasia b. 4.4 Tanda tangan cincin satu kali Protokol yang didasarkan pada tanda tangan dering satu kali memungkinkan pengguna mencapai ketidakterhubungan tanpa syarat. Sayangnya, jenis tanda tangan kriptografi biasa mengizinkan pelacakan transaksi ke mereka masing-masing pengirim dan penerima. Solusi kami terhadap kekurangan ini terletak pada penggunaan tanda tangan yang berbeda jenisnya dibandingkan yang saat ini digunakan dalam sistem kas elektronik. Pertama-tama kami akan menyediakan general deskripsi algoritma kami tanpa referensi eksplisit uang elektronik. Tanda tangan dering satu kali berisi empat algoritma: (GEN, SIG, VER, LNK): GEN: mengambil parameter publik dan mengeluarkan pasangan ec (P, x) dan kunci publik I. SIG: mengambil pesan m, satu set \(S'\) kunci publik {Pi}i̸=s, sepasang (Ps, xs) dan menghasilkan tanda tangan \(\sigma\) dan himpunan \(S = \)S'\( \cup \{P_s\}\). 8 16 Ya, jadi sekarang kami memiliki a) alamat pembayaran dan b) ID pembayaran. Kritikus mungkin bertanya "apakah kita benar-benar perlu melakukan ini? Lagi pula, jika pedagang menerima 112.00678952 CN tepatnya, dan itu pesanan saya, dan saya punya tangkapan layar atau tanda terima atau apa pun, bukan tingkat presisi yang gila, cukup?" Jawabannya adalah "mungkin, sering kali, dalam kehidupan sehari-hari, transaksi tatap muka.” Namun, situasi yang lebih umum (terutama di dunia digital) adalah: seorang pedagang menjual sekumpulan objek yang masing-masing mempunyai harga tetap. Katakanlah benda A 0,001 CN, benda B 0,01 CN dan benda C adalah 0,1 CN. Nah kalau merchant mendapat order 1.618 CN, banyak sekali (banyak!) cara untuk mengatur pesanan untuk pelanggan. Jadi tanpa semacam ID pembayaran, mengidentifikasi apa yang disebut pesanan "unik" pelanggan dengan apa yang disebut biaya "unik" mereka ketertiban menjadi mustahil. Yang lebih lucu lagi: jika semua yang ada di toko online saya harganya tepat 1,0 CN, dan saya mendapatkan 1000 pelanggan sehari? Dan Anda ingin membuktikan bahwa Anda membeli tepat 3 benda dua minggu lalu? Tanpa ID pembayaran? Semoga berhasil, sobat. Singkat cerita: Saat Bob menerbitkan alamat pembayaran, dia mungkin juga menerbitkan a ID pembayaran juga (lihat, misalnya deposit Poloniex XMR). Hal ini berbeda dengan apa yang dijelaskan dalam teks di sini di mana Alice adalah orang yang menghasilkan ID pembayaran. Pasti ada cara bagi Bob untuk menghasilkan ID pembayaran juga. (a,b) Ingatlah bahwa kunci pelacakan (a,B) dapat dipublikasikan; kehilangan kerahasiaan nilai surat wasiat 'a' tidak melanggar kemampuan Anda untuk membelanjakan uang atau membiarkan orang mencuri dari Anda (menurut saya... itu akan terjadi dibuktikan), itu hanya akan memungkinkan orang untuk melihat semua transaksi masuk. Alamat yang terpotong, seperti yang dijelaskan dalam paragraf ini, hanya mengambil bagian "pribadi" dari kunci tersebut dan menghasilkannya dari bagian "publik". Mengungkap nilai 'a' akan menghilangkan ketidakterhubungan tetapi akan mempertahankan sisa transaksi. Yang dimaksud penulis adalah "tidak dapat ditautkan" karena tidak dapat ditautkan mengacu pada penerima dan dapat ditautkan mengacu pada pengirimnya. Jelas juga bahwa penulis tidak menyadari bahwa ada dua aspek berbeda dalam keterhubungan. Karena transaksi adalah objek berarah pada grafik, maka akan timbul dua pertanyaan: "Apakah kedua transaksi ini ditujukan kepada orang yang sama?" dan "apakah kedua transaksi ini akan datang dari orang yang sama?" Ini adalah kebijakan "tidak ada jalan kembali" yang mendasari properti tidak dapat ditautkannya CryptoNote bersyarat. Artinya, Bob dapat memilih agar transaksi masuknya tidak dapat dibatalkan tautannya menggunakan kebijakan ini. Ini adalah klaim yang mereka buktikan berdasarkan Random Oracle Model. Kita akan membahasnya; yang Acak Oracle memiliki pro dan kontra.

VER: mengambil pesan m, satu set S, tanda tangan \(\sigma\) dan menghasilkan output “benar” atau “salah”. LNK: mengambil himpunan I = {Ii}, tanda tangan \(\sigma\) dan menghasilkan keluaran “tertaut” atau “indep”. Ide di balik protokol ini cukup sederhana: pengguna membuat tanda tangan diperiksa oleh sekumpulan kunci publik, bukan kunci publik unik. Identitas penandatangan adalah tidak dapat dibedakan dari pengguna lain yang kunci publiknya ada di set sampai pemiliknya memproduksinya tanda tangan kedua menggunakan pasangan kunci yang sama. Kunci pribadi x0 \(\cdots\) xi \(\cdots\) xn Kunci publik P0 \(\cdots\) pi \(\cdots\) hal Cincin Tanda tangan tanda tangan verifikasi Gambar 6. Anonimitas tanda tangan dering. GEN: Penanda tangan mengambil kunci rahasia acak \(x \in [1, l - 1]\) dan menghitung kunci rahasia yang sesuai kunci publik P = xG. Selain itu, dia menghitung kunci publik lain I = xHp(P) yang akan kita lakukan sebut "gambar kunci". SIG: Penandatangan menghasilkan tanda tangan dering satu kali dengan pengetahuan nol non-interaktif pembuktian menggunakan teknik dari [21]. Dia memilih subset acak \(S'\) dari n dari pengguna lain. kunci publik Pi, pasangan kuncinya sendiri (x, P) dan gambar kunci I. Misalkan \(0 \leq s \leq n\) menjadi indeks rahasia penanda tangan di S (sehingga kunci publiknya adalah Ps). Dia memilih {qi | secara acak saya = 0 . . . n} dan {wi | saya = 0 . . . n, i ̸= s} dari (1 . . . l) dan menerapkan transformasi berikut: Li = ( qiG, jika saya = s qiG + wiPi, jika saya ̸= s Ri = ( qiHp(Pi), jika saya = s qiHp(Pi) + wiI, jika saya ̸= s Langkah selanjutnya adalah mendapatkan tantangan non-interaktif: c = Hs(m, L1, . . . , Ln, R1, . . . , Rn) Akhirnya penandatangan menghitung responsnya: ci =    wi, jika saya ̸= s c - nP saya=0 ci mod aku, jika saya = s ri = ( qi, jika saya ̸= s qs−csx mod aku, jika saya = s Tanda tangan yang dihasilkan adalah \(\sigma\) = (I, c1, . . . , cn, r1, . . . , rn). 9 VER: mengambil pesan m, satu set S, tanda tangan \(\sigma\) dan menghasilkan output “benar” atau “salah”. LNK: mengambil himpunan I = {Ii}, tanda tangan \(\sigma\) dan menghasilkan keluaran “tertaut” atau “indep”. Ide di balik protokol ini cukup sederhana: pengguna membuat tanda tangan diperiksa oleh sekumpulan kunci publik, bukan kunci publik unik. Identitas penandatangan adalah tidak dapat dibedakan dari pengguna lain yang kunci publiknya ada di set sampai pemiliknya memproduksinya tanda tangan kedua menggunakan pasangan kunci yang sama. Kunci pribadi x0 \(\cdots\) xi \(\cdots\) xn Kunci publik P0 \(\cdots\) pi \(\cdots\) hal Cincin Tanda tangan tanda tangan verifikasi Gambar 6. Anonimitas tanda tangan dering. GEN: Penanda tangan mengambil kunci rahasia acak \(x \in [1, l - 1]\) dan menghitung kunci rahasia yang sesuai kunci publik P = xG. Selain itu, dia menghitung kunci publik lain I = xHp(P) yang akan kita lakukan sebut "gambar kunci". SIG: Penandatangan menghasilkan tanda tangan dering satu kali dengan pengetahuan nol non-interaktif pembuktian menggunakan teknik dari [21]. Dia memilih subset acak \(S'\) dari n dari pengguna lain. kunci publik Pi, pasangan kuncinya sendiri (x, P) dan gambar kunci I. Misalkan \(0 \leq s \leq n\) menjadi indeks rahasia penanda tangan di S (sehingga kunci publiknya adalah Ps). Dia memilih {qi | secara acak saya = 0 . . . n} dan {wi | saya = 0 . . . n, i ̸= s} dari (1 . . . l) dan menerapkan transformasi berikut: Li = ( qiG, jika saya = s qiG + wiPi, jika saya ̸= s Ri = ( qiHp(Pi), jika saya = s qiHp(Pi) + wiI, jika saya ̸= s Langkah selanjutnya adalah mendapatkan tantangan non-interaktif: c = Hs(m, L1, . . . , Ln, R1, . . . , Rn) Akhirnya penandatangan menghitung responsnya: ci =    wi, jika saya ̸= s c - nP saya=0 ci mod aku, jika saya = s ri = ( qi, jika saya ̸= s qs−csx mod aku, jika saya = s Tanda tangan yang dihasilkan adalah \(\sigma\) = (I, c1, . . . , cn, r1, . . . , rn). 9 17 Mungkin ini bodoh, tapi kehati-hatian harus diberikan saat menyatukan S dan P_s. Jika Anda hanya menambahkan kunci publik terakhir sampai akhir, ketidakterhubungan rusak karena siapa pun memeriksa transaksi yang lewat cukup memeriksa kunci publik terakhir yang terdaftar di setiap transaksi dan booming. Itu kunci publiknya berhubungan dengan pengirimnya. Jadi setelah penyatuan, generator nomor pseudorandom harus ada digunakan untuk mengubah kunci publik yang dipilih. "...sampai pemilik membuat tanda tangan kedua menggunakan pasangan kunci yang sama." Saya berharap penulisnya? akan menguraikan hal ini. Saya yakin ini berarti "pastikan bahwa setiap kali Anda memilih sekumpulan kunci publik untuk dikaburkan sendiri, Anda memilih satu set yang benar-benar baru tanpa dua kunci yang sama." Yang tampak seperti a kondisi yang cukup kuat untuk ditempatkan pada ketidakterhubungan. Mungkin "Anda memilih kumpulan acak baru semua kunci yang mungkin" dengan asumsi bahwa, meskipun persimpangan nontrivial pasti akan terjadi terjadi, hal itu tidak akan sering terjadi. Apa pun yang terjadi, saya perlu menggali lebih dalam pernyataan ini. Ini menghasilkan tanda tangan cincin. Bukti tanpa pengetahuan itu luar biasa: Saya menantang Anda untuk membuktikan kepada saya bahwa Anda mengetahui sebuah rahasia tanpa mengungkapkan rahasianya. Misalnya saja kita berada di pintu masuk gua yang berbentuk donat, dan di belakang gua (di luar pandangan dari pintu masuk) ada opintu baru ke mana Anda mengaku kamu punya kuncinya. Jika Anda pergi ke satu arah, ia selalu membiarkan Anda lewat, tetapi jika Anda pergi ke arah yang lain arah lain, Anda memerlukan kunci. Tapi Anda bahkan tidak mau TUNJUKKAN kuncinya kepada saya, apalagi tunjukkan padaku bahwa itu membuka pintu. Tapi Anda ingin membuktikan kepada saya bahwa Anda tahu cara membukanya pintu. Dalam suasana interaktif, saya melempar koin. Kepala di kiri, ekor di kanan, dan Anda turun ke bawah gua berbentuk donat ke arah mana pun koin mengarahkan Anda. Di belakang, di luar pandanganku, kamu buka pintu untuk kembali ke sisi lain. Kami mengulangi eksperimen melempar koin sampai saya puas bahwa Anda memiliki kuncinya. Tapi itu jelas merupakan bukti tanpa pengetahuan yang INTERAKTIF. Ada versi non-interaktif di mana Anda dan saya tidak perlu berkomunikasi; dengan cara ini, tidak ada penyadap yang dapat mengganggu. http://en.wikipedia.org/wiki/Zero-knowledge_proof Ini kebalikan dari definisi sebelumnya.

VER: mengambil pesan m, satu set S, tanda tangan \(\sigma\) dan menghasilkan output “benar” atau “salah”. LNK: mengambil himpunan I = {Ii}, tanda tangan \(\sigma\) dan menghasilkan keluaran “tertaut” atau “indep”. Ide di balik protokol ini cukup sederhana: pengguna membuat tanda tangan diperiksa oleh sekumpulan kunci publik, bukan kunci publik unik. Identitas penandatangan adalah tidak dapat dibedakan dari pengguna lain yang kunci publiknya ada di set sampai pemiliknya memproduksinya tanda tangan kedua menggunakan pasangan kunci yang sama. Kunci pribadi x0 \(\cdots\) xi \(\cdots\) xn Kunci publik P0 \(\cdots\) pi \(\cdots\) hal Cincin Tanda tangan tanda tangan verifikasi Gambar 6. Anonimitas tanda tangan dering. GEN: Penanda tangan mengambil kunci rahasia acak \(x \in [1, l - 1]\) dan menghitung kunci rahasia yang sesuai kunci publik P = xG. Selain itu, dia menghitung kunci publik lain I = xHp(P) yang akan kita lakukan sebut "gambar kunci". SIG: Penandatangan menghasilkan tanda tangan dering satu kali dengan pengetahuan nol non-interaktif bukti menggunakan teknik dari [21]. Dia memilih subset acak \(S'\) dari n dari pengguna lain. kunci publik Pi, pasangan kuncinya sendiri (x, P) dan gambar kunci I. Misalkan \(0 \leq s \leq n\) menjadi indeks rahasia penanda tangan di S (sehingga kunci publiknya adalah Ps). Dia memilih {qi | secara acak saya = 0 . . . n} dan {wi | saya = 0 . . . n, i ̸= s} dari (1 . . . l) dan menerapkan transformasi berikut: Li = ( qiG, jika saya = s qiG + wiPi, jika saya ̸= s Ri = ( qiHp(Pi), jika saya = s qiHp(Pi) + wiI, jika saya ̸= s Langkah selanjutnya adalah mendapatkan tantangan non-interaktif: c = Hs(m, L1, . . . , Ln, R1, . . . , Rn) Akhirnya penandatangan menghitung responsnya: ci =    wi, jika saya ̸= s c - nP saya=0 ci mod aku, jika saya = s ri = ( qi, jika saya ̸= s qs−csx mod aku, jika saya = s Tanda tangan yang dihasilkan adalah \(\sigma\) = (I, c1, . . . , cn, r1, . . . , rn). 9 VER: mengambil pesan m, satu set S, tanda tangan \(\sigma\) dan menghasilkan output “benar” atau “salah”. LNK: mengambil himpunan I = {Ii}, tanda tangan \(\sigma\) dan menghasilkan keluaran “tertaut” atau “indep”. Ide di balik protokol ini cukup sederhana: pengguna membuat tanda tangan diperiksa oleh sekumpulan kunci publik, bukan kunci publik unik. Identitas penandatangan adalah tidak dapat dibedakan dari pengguna lain yang kunci publiknya ada di set sampai pemiliknya memproduksinya tanda tangan kedua menggunakan pasangan kunci yang sama. Kunci pribadi x0 \(\cdots\) xi \(\cdots\) xn Kunci publik P0 \(\cdots\) pi \(\cdots\) hal Cincin Tanda tangan tanda tangan verifikasi Gambar 6. Anonimitas tanda tangan dering. GEN: Penanda tangan mengambil kunci rahasia acak \(x \in [1, l - 1]\) dan menghitung kunci rahasia yang sesuai kunci publik P = xG. Selain itu, dia menghitung kunci publik lain I = xHp(P) yang akan kita lakukan sebut "gambar kunci". SIG: Penandatangan menghasilkan tanda tangan dering satu kali dengan pengetahuan nol non-interaktif bukti menggunakan teknik dari [21]. Dia memilih subset acak \(S'\) dari n dari pengguna lain. kunci publik Pi, pasangan kuncinya sendiri (x, P) dan gambar kunci I. Misalkan \(0 \leq s \leq n\) menjadi indeks rahasia penanda tangan di S (sehingga kunci publiknya adalah Ps). Dia memilih {qi | secara acak saya = 0 . . . n} dan {wi | saya = 0 . . . n, i ̸= s} dari (1 . . . l) dan menerapkan transformasi berikut: Li = ( qiG, jika saya = s qiG + wiPi, jika saya ̸= s Ri = ( qiHp(Pi), jika saya = s qiHp(Pi) + wiI, jika saya ̸= s Langkah selanjutnya adalah mendapatkan tantangan non-interaktif: c = Hs(m, L1, . . . , Ln, R1, . . . , Rn) Akhirnya penandatangan menghitung responsnya: ci =    wi, jika saya ̸= s c - nP saya=0 ci mod aku, jika saya = s ri = ( qi, jika saya ̸= s qs−csx mod aku, jika saya = s Tanda tangan yang dihasilkan adalah \(\sigma\) = (I, c1, . . . , cn, r1, . . . , rn). 9 18 Seluruh area ini adalah cryptonote agnostic, hanya menggambarkan algoritma tanda tangan cincin tanpa referensi mata uang. Saya curiga beberapa notasinya konsisten dengan makalah lainnya, meskipun begitu. Misalnya, x adalah kunci rahasia "acak" yang dipilih di GEN, yang menghasilkan kunci publik P dan gambar kunci publik I. Nilai x ini adalah nilai yang dihitung Bob di bagian 6 halaman 8. Jadi begini mulai menjernihkan beberapa kebingungan dari uraian sebelumnya. Ini keren; uang tidak ditransfer dari "alamat publik Alice ke publik Bob alamat." Ini sedang ditransfer dari alamat satu kali ke alamat satu kali. Jadi, dalam arti tertentu, inilah cara kerjanya. Jika Alex memiliki beberapa cryptonotes karena seseorang mengirimkannya kepadanya, ini berarti dia memiliki kunci pribadi yang diperlukan untuk mengirimkannya kepada Bob. Dia menggunakan pertukaran Diﬃe-Hellman menggunakan informasi publik Bob untuk menghasilkan alamat satu kali yang baru dan cryptonotes ditransfer ke alamat itu. Sekarang, karena pertukaran DH (yang mungkin aman) digunakan untuk menghasilkan alamat satu kali yang baru kepada siapa Alex mengirimkan CN-nya, Bob adalah satu-satunya yang memiliki kunci pribadi yang diperlukan untuk mengulanginya di atas. Jadi sekarang, Bob adalah Alex. http://en.wikipedia.org/wiki/Piecewise#Notation_and_interpretation Penjumlahan harus diindeks pada j bukan i. Setiap c_i adalah sampah acak (karena w_i acak) kecuali pantat c_iterkait dengan kunci sebenarnya yang terlibat dalam tanda tangan ini. Nilai c adalah a hash dari informasi sebelumnya. Saya pikir ini mungkin mengandung kesalahan ketik yang lebih buruk daripada menggunakan kembali indeks 'i', karena sepertinya c_s untuk didefinisikan secara implisit, bukan eksplisit. Memang, jika kita mengambil persamaan ini dengan keyakinan, maka kita menentukan bahwa c_s = (1/2)c - (1/2) jumlah_i neq s c_i. Artinya, hash dikurangi sejumlah angka acak. Sebaliknya jika penjumlahan ini dimaksudkan untuk dibaca "c_s = (c - sum_j neq s c_j) mod l", lalu kita ambil hash dari informasi kita sebelumnya, buat sekumpulan angka acak, kurangi semua angka acak itu dari hash, dan itu memberi kita c_s. Ini tampaknya terjadi apa yang "seharusnya" terjadi berdasarkan intuisi saya, dan cocok dengan langkah verifikasi di halaman 10. Tapi intuisi bukanlah matematika. Saya akan menggali lebih dalam tentang ini. Sama seperti sebelumnya; semua ini akan menjadi sampah acak kecuali yang terkait dengan yang sebenarnya kunci publik penandatangan x. Kecuali kali ini, inilah yang saya harapkan dari strukturnya: r_i acak untuk i!=s dan r_s hanya ditentukan oleh rahasia x dan nilai indeks s dari q_i dan c_i.

VER: Pemverifikasi memeriksa tanda tangan dengan menerapkan transformasi terbalik: ( aku saya = riG + ciPi R′ saya = riHp(Pi) + ciI Akhirnya, pemverifikasi memeriksa apakah nP saya=0 ci ?= Hs(m, L′ 0, . . . , aku′ n, R′ 0, . . . , R′ n) mod l Jika persamaan ini benar, pemverifikasi menjalankan algoritma LNK. Jika tidak, pemverifikasi akan menolak tanda tangan. LNK: Pemverifikasi memeriksa apakah saya telah digunakan pada tanda tangan sebelumnya (nilai-nilai ini disimpan di set I). Penggunaan ganda menyiratkan bahwa dua tanda tangan dihasilkan di bawah kunci rahasia yang sama. Arti protokol: dengan menerapkan transformasi L, penandatangan membuktikan bahwa dia mengetahuinya sedemikian rupa sehingga setidaknya satu Pi = xG. Untuk membuat bukti ini tidak dapat diulangi, kami memperkenalkan gambar kuncinya karena saya = xHp(P). Penandatangan menggunakan koefisien yang sama (ri, ci) untuk membuktikan pernyataan yang hampir sama: dia mengetahui x sedemikian rupa sehingga setidaknya satu \(H_p(P_i) = I \cdot x^{-1}\). Jika pemetaan \(x \to I\) adalah injeksi: 1. Tidak ada seorang pun yang dapat memulihkan kunci publik dari gambar kunci dan mengidentifikasi penandatangannya; 2. Penanda tangan tidak boleh membuat dua tanda tangan dengan huruf I berbeda dan x yang sama. Analisis keamanan lengkap disediakan di Lampiran A. 4.5 Transaksi CryptoNote standar Dengan menggabungkan kedua metode (kunci publik yang tidak dapat ditautkan dan tanda tangan cincin yang tidak dapat dilacak), Bob berhasil mencapainya tingkat privasi baru dibandingkan dengan skema Bitcoin asli. Itu mengharuskan dia untuk menyimpan saja satu kunci pribadi (a, b) dan publikasikan (A, B) untuk mulai menerima dan mengirim transaksi anonim. Saat memvalidasi setiap transaksi, Bob juga hanya melakukan dua perkalian kurva elips dan satu penambahan per output untuk memeriksa apakah suatu transaksi miliknya. Untuk setiap miliknya keluaran Bob memulihkan pasangan kunci satu kali (pi, Pi) dan menyimpannya di dompetnya. Masukan apa saja bisa terbukti secara tidak langsung mempunyai pemilik yang sama hanya jika mereka muncul dalam satu transaksi. Di Faktanya, hubungan ini jauh lebih sulit untuk dibangun karena tanda tangan satu kali saja. Dengan tanda tangan cincin, Bob dapat secara efektif menyembunyikan setiap masukan dari masukan orang lain; semua mungkin pembelanja akan sama besarnya, bahkan pemilik sebelumnya (Alice) tidak memiliki informasi lebih dari itu pengamat mana pun. Saat menandatangani transaksinya, Bob menentukan n output luar negeri dengan jumlah yang sama dengan miliknya keluaran, mencampur semuanya tanpa partisipasi pengguna lain. Bob sendiri (dan juga orang lain) tidak mengetahui apakah pembayaran ini telah dibelanjakan: suatu keluaran dapat digunakan dalam ribuan tanda tangan sebagai faktor ambiguitas dan tidak pernah menjadi sasaran persembunyian. Ganda pemeriksaan pembelanjaan terjadi pada fase LNK saat memeriksa kumpulan gambar kunci yang digunakan. Bob dapat memilih sendiri derajat ambiguitasnya: n = 1 berarti probabilitas yang dimilikinya menghabiskan output adalah probabilitas 50%, n = 99 menghasilkan 1%. Ukuran tanda tangan yang dihasilkan bertambah linier sebagai O(n+1), sehingga peningkatan anonimitas memerlukan biaya transaksi tambahan bagi Bob. Dia juga bisa setel n = 0 dan buat tanda tangan cincinnya hanya terdiri dari satu elemen, namun ini akan langsung terjadi mengungkapkan dia sebagai seorang pemboros. 10 VER: Pemverifikasi memeriksa tanda tangan dengan menerapkan transformasi terbalik: ( aku saya = riG + ciPi R′ saya = riHp(Pi) + ciI Akhirnya, pemverifikasi memeriksa apakah nP saya=0 ci ?= Hs(m, L′ 0, . . . , aku' n, R′ 0, . . . , R′ n) mod l Jika persamaan ini benar, pemverifikasi menjalankan algoritma LNK. Jika tidak, pemverifikasi akan menolak tanda tangan. LNK: Pemverifikasi memeriksa apakah saya telah digunakan pada tanda tangan sebelumnya (nilai-nilai ini disimpan di set I). Penggunaan ganda menyiratkan bahwa dua tanda tangan dihasilkan di bawah kunci rahasia yang sama. Arti protokol: dengan menerapkan transformasi L, penandatangan membuktikan bahwa dia mengetahuinya sedemikian rupa sehingga setidaknya satu Pi = xG. Untuk membuat bukti ini tidak dapat diulangi, kami memperkenalkan gambar kuncinya karena saya = xHp(P). Penandatangan menggunakan koefisien yang sama (ri, ci) untuk membuktikan pernyataan yang hampir sama: dia mengetahui x sedemikian rupa sehingga setidaknya satu \(H_p(P_i) = I \cdot x^{-1}\). Jika pemetaan \(x \to I\) adalah injeksi: 1. Tidak ada seorang pun yang dapat memulihkan kunci publik dari gambar kunci dan mengidentifikasi penandatangannya; 2. Penanda tangan tidak boleh membuat dua tanda tangan dengan huruf I berbeda dan x yang sama. Analisis keamanan lengkap disediakan di Lampiran A. 4.5 Transaksi CryptoNote standar Dengan menggabungkan kedua metode (kunci publik yang tidak dapat ditautkan dan tanda tangan cincin yang tidak dapat dilacak), Bob berhasil mencapainya tingkat privasi baru dibandingkan dengan skema Bitcoin asli. Itu mengharuskan dia untuk menyimpan saja satu kunci pribadi (a, b) dan publikasikan (A, B) untuk mulai menerima dan mengirim transaksi anonim. Saat memvalidasi setiap transaksi, Bob juga hanya melakukan dua perkalian kurva elips dan satu penambahan per output untuk memeriksa apakah suatu transaksi miliknya. Untuk setiap miliknya output Bob memulihkan keypair satu kali (pi, Pi) dan stbijih itu di dompetnya. Masukan apa saja bisa terbukti secara tidak langsung mempunyai pemilik yang sama hanya jika mereka muncul dalam satu transaksi. Di Faktanya, hubungan ini jauh lebih sulit untuk dibangun karena tanda tangan satu kali saja. Dengan tanda tangan cincin, Bob dapat secara efektif menyembunyikan setiap masukan dari masukan orang lain; semua mungkin pembelanja akan sama besarnya, bahkan pemilik sebelumnya (Alice) tidak memiliki informasi lebih dari itu pengamat mana pun. Saat menandatangani transaksinya, Bob menentukan n output luar negeri dengan jumlah yang sama dengan miliknya keluaran, mencampur semuanya tanpa partisipasi pengguna lain. Bob sendiri (dan juga orang lain) tidak mengetahui apakah pembayaran ini telah dibelanjakan: suatu keluaran dapat digunakan dalam ribuan tanda tangan sebagai faktor ambiguitas dan tidak pernah menjadi sasaran persembunyian. Ganda pemeriksaan pembelanjaan terjadi pada fase LNK saat memeriksa kumpulan gambar kunci yang digunakan. Bob dapat memilih sendiri derajat ambiguitasnya: n = 1 berarti probabilitas yang dimilikinya menghabiskan output adalah probabilitas 50%, n = 99 menghasilkan 1%. Ukuran tanda tangan yang dihasilkan bertambah linier sebagai O(n+1), sehingga peningkatan anonimitas memerlukan biaya transaksi tambahan bagi Bob. Dia juga bisa setel n = 0 dan buat tanda tangan cincinnya hanya terdiri dari satu elemen, namun ini akan langsung terjadi mengungkapkan dia sebagai seorang pemboros. 10 19 Saat ini, saya sangat bingung. Alex menerima pesan M dengan tanda tangan (I,c_1, ..., c_n, r_1, ..., r_n) dan daftar publik kunci S. dan dia menjalankan VER. Ini akan menghitung L_i' dan R_i' Ini memverifikasi bahwa c_s = c - sum_i neq s c_i pada halaman sebelumnya. Awalnya saya SANGAT (ha) bingung. Siapa pun dapat menghitung L_i' dan R_i'. Memang, masing-masing r_i dan c_i telah diterbitkan dalam tanda tangan sigma sama dengan nilai I. Himpunan S = P_i dari semua kunci publik juga telah dipublikasikan. Jadi siapapun yang pernah melihat sigma dan himpunan kunci S = P_i akan mendapatkan nilai yang sama untuk L_i' dan R_i' dan karenanya periksa tanda tangannya. Tapi kemudian saya ingat bagian ini hanya menjelaskan algoritma tanda tangan, bukan "cek jika ditandatangani, periksa apakah DIKIRIM KEPADA SAYA, dan jika demikian, belanjakan uangnya." Ini HANYA bagian tanda tangan dari permainan. Saya tertarik untuk membaca Lampiran A ketika saya akhirnya sampai di sana. Saya ingin melihat perbandingan operasi demi operasi skala penuh antara Cryptonote dengan Bitcoin. Juga, listrik/keberlanjutan. Bagian algoritma apa yang merupakan "input" di sini? Saya yakin masukan transaksi adalah Jumlah dan kumpulan UTXO yang jumlahnya lebih besar daripada jumlah Jumlah. Ini tidak jelas. “Target persembunyian?” Saya telah memikirkan hal ini selama beberapa menit sekarang dan saya masih belum memikirkannya gagasan paling kabur tentang apa artinya itu. Serangan pembelanjaan ganda hanya dapat dilakukan dengan memanipulasi kunci yang dianggap digunakan oleh sebuah node kumpulan gambar \(I\). "Tingkat ambiguitas" = n tetapi jumlah total kunci publik yang termasuk dalam transaksi adalah n+1. Artinya, tingkat ambiguitas adalah "berapa banyak orang LAIN yang Anda inginkan orang banyak?" Jawabannya mungkin, secara default, "sebanyak mungkin".

VER: Pemverifikasi memeriksa tanda tangan dengan menerapkan transformasi terbalik: ( aku saya = riG + ciPi R′ saya = riHp(Pi) + ciI Akhirnya, pemverifikasi memeriksa apakah nP saya=0 ci ?= Hs(m, L′ 0, . . . , aku' n, R′ 0, . . . , R′ n) mod l Jika persamaan ini benar, pemverifikasi menjalankan algoritma LNK. Jika tidak, pemverifikasi akan menolak tanda tangan. LNK: Pemverifikasi memeriksa apakah saya telah digunakan pada tanda tangan sebelumnya (nilai-nilai ini disimpan di set I). Penggunaan ganda menyiratkan bahwa dua tanda tangan dihasilkan di bawah kunci rahasia yang sama. Arti protokol: dengan menerapkan transformasi L, penandatangan membuktikan bahwa dia mengetahuinya sedemikian rupa sehingga setidaknya satu Pi = xG. Untuk membuat bukti ini tidak dapat diulangi, kami memperkenalkan gambar kuncinya karena saya = xHp(P). Penandatangan menggunakan koefisien yang sama (ri, ci) untuk membuktikan pernyataan yang hampir sama: dia mengetahui x sedemikian rupa sehingga setidaknya satu \(H_p(P_i) = I \cdot x^{-1}\). Jika pemetaan \(x \to I\) adalah injeksi: 1. Tidak ada seorang pun yang dapat memulihkan kunci publik dari gambar kunci dan mengidentifikasi penandatangannya; 2. Penanda tangan tidak boleh membuat dua tanda tangan dengan huruf I berbeda dan x yang sama. Analisis keamanan lengkap disediakan di Lampiran A. 4.5 Transaksi CryptoNote standar Dengan menggabungkan kedua metode (kunci publik yang tidak dapat ditautkan dan tanda tangan cincin yang tidak dapat dilacak), Bob berhasil mencapainya tingkat privasi baru dibandingkan dengan skema Bitcoin asli. Itu mengharuskan dia untuk menyimpan saja satu kunci pribadi (a, b) dan publikasikan (A, B) untuk mulai menerima dan mengirim transaksi anonim. Saat memvalidasi setiap transaksi, Bob juga hanya melakukan dua perkalian kurva elips dan satu penambahan per output untuk memeriksa apakah suatu transaksi miliknya. Untuk setiap miliknya keluaran Bob memulihkan pasangan kunci satu kali (pi, Pi) dan menyimpannya di dompetnya. Masukan apa saja bisa terbukti secara tidak langsung mempunyai pemilik yang sama hanya jika mereka muncul dalam satu transaksi. Di Faktanya, hubungan ini jauh lebih sulit untuk dibangun karena tanda tangan satu kali saja. Dengan tanda tangan cincin, Bob dapat secara efektif menyembunyikan setiap masukan dari masukan orang lain; semua mungkin pembelanja akan sama besarnya, bahkan pemilik sebelumnya (Alice) tidak memiliki informasi lebih dari itu pengamat mana pun. Saat menandatangani transaksinya, Bob menentukan n output luar negeri dengan jumlah yang sama dengan miliknya keluaran, mencampur semuanya tanpa partisipasi pengguna lain. Bob sendiri (dan juga orang lain) tidak mengetahui apakah pembayaran ini telah dibelanjakan: suatu keluaran dapat digunakan dalam ribuan tanda tangan sebagai faktor ambiguitas dan tidak pernah menjadi sasaran persembunyian. Ganda pemeriksaan pembelanjaan terjadi pada fase LNK saat memeriksa kumpulan gambar kunci yang digunakan. Bob dapat memilih sendiri derajat ambiguitasnya: n = 1 berarti probabilitas yang dimilikinya menghabiskan output adalah probabilitas 50%, n = 99 menghasilkan 1%. Ukuran tanda tangan yang dihasilkan bertambah linier sebagai O(n+1), sehingga peningkatan anonimitas memerlukan biaya transaksi tambahan bagi Bob. Dia juga bisa setel n = 0 dan buat tanda tangan cincinnya hanya terdiri dari satu elemen, namun ini akan langsung terjadi mengungkapkan dia sebagai seorang pemboros. 10 VER: Pemverifikasi memeriksa tanda tangan dengan menerapkan transformasi terbalik: ( aku saya = riG + ciPi R′ saya = riHp(Pi) + ciI Akhirnya, pemverifikasi memeriksa apakah nP saya=0 ci ?= Hs(m, L′ 0, . . . , aku' n, R′ 0, . . . , R′ n) mod l Jika persamaan ini benar, pemverifikasi menjalankan algoritma LNK. Jika tidak, pemverifikasi akan menolak tanda tangan. LNK: Pemverifikasi memeriksa apakah saya telah digunakan pada tanda tangan sebelumnya (nilai-nilai ini disimpan di set I). Penggunaan ganda menyiratkan bahwa dua tanda tangan dihasilkan di bawah kunci rahasia yang sama. Arti protokol: dengan menerapkan transformasi L, penandatangan membuktikan bahwa dia mengetahuinya sedemikian rupa sehingga setidaknya satu Pi = xG. Untuk membuat bukti ini tidak dapat diulangi, kami memperkenalkan gambar kuncinya karena saya = xHp(P). Penandatangan menggunakan koefisien yang sama (ri, ci) untuk membuktikan pernyataan yang hampir sama: dia mengetahui x sedemikian rupa sehingga setidaknya satu \(H_p(P_i) = I \cdot x^{-1}\). Jika pemetaan \(x \to I\) adalah injeksi: 1. Tidak ada seorang pun yang dapat memulihkan kunci publik dari gambar kunci dan mengidentifikasi penandatangannya; 2. Penanda tangan tidak boleh membuat dua tanda tangan dengan huruf I berbeda dan x yang sama. Analisis keamanan lengkap disediakan di Lampiran A. 4.5 Transaksi CryptoNote standar Dengan menggabungkan kedua metode (kunci publik yang tidak dapat ditautkan dan tanda tangan cincin yang tidak dapat dilacak), Bob berhasil mencapainya tingkat privasi baru dibandingkan dengan skema Bitcoin asli. Itu mengharuskan dia untuk menyimpan saja satu kunci pribadi (a, b) dan publikasikan (A, B) untuk mulai menerima dan mengirim transaksi anonim. Saat memvalidasi setiap transaksi, Bob juga hanya melakukan dua perkalian kurva elips dan satu penambahan per output untuk memeriksa apakah suatu transaksi miliknya. Untuk setiap miliknya output Bob memulihkan keypair satu kali (pi, Pi) dan stbijih itu di dompetnya. Masukan apa saja bisa terbukti secara tidak langsung mempunyai pemilik yang sama hanya jika mereka muncul dalam satu transaksi. Di Faktanya, hubungan ini jauh lebih sulit untuk dibangun karena tanda tangan satu kali saja. Dengan tanda tangan cincin, Bob dapat secara efektif menyembunyikan setiap masukan dari masukan orang lain; semua mungkin pembelanja akan sama besarnya, bahkan pemilik sebelumnya (Alice) tidak memiliki informasi lebih dari itu pengamat mana pun. Saat menandatangani transaksinya, Bob menentukan n output luar negeri dengan jumlah yang sama dengan miliknya keluaran, mencampur semuanya tanpa partisipasi pengguna lain. Bob sendiri (dan juga orang lain) tidak mengetahui apakah pembayaran ini telah dibelanjakan: suatu keluaran dapat digunakan dalam ribuan tanda tangan sebagai faktor ambiguitas dan tidak pernah menjadi sasaran persembunyian. Ganda pemeriksaan pembelanjaan terjadi pada fase LNK saat memeriksa kumpulan gambar kunci yang digunakan. Bob dapat memilih sendiri derajat ambiguitasnya: n = 1 berarti probabilitas yang dimilikinya menghabiskan output adalah probabilitas 50%, n = 99 menghasilkan 1%. Ukuran tanda tangan yang dihasilkan bertambah linier sebagai O(n+1), sehingga peningkatan anonimitas memerlukan biaya transaksi tambahan bagi Bob. Dia juga bisa setel n = 0 dan buat tanda tangan cincinnya hanya terdiri dari satu elemen, namun ini akan langsung terjadi mengungkapkan dia sebagai seorang pemboros. 10 20 Ini menarik; sebelumnya, kami menyediakan cara bagi penerima, Bob, untuk melakukan semua MASUK transaksi tidak dapat dibatalkan tautannya baik dengan memilih setengah dari kunci pribadinya secara deterministik atau dengan menerbitkan setengah kunci pribadinya sebagai publik. Ini adalah kebijakan yang tidak ada jalan mundurnya. Di sini, kita lihat cara pengirim, Alex, untuk memilih satu transaksi keluar yang dapat ditautkan, namun kenyataannya begini mengungkapkan Alex sebagai pengirim ke seluruh jaringan. Ini BUKAN kebijakan yang tidak bisa mundur. Ini adalah transaksi demi transaksi. Apakah ada kebijakan ketiga? Bisakah penerima, Bob, membuat ID pembayaran unik untuk Alex itu tidak pernah berubah, mungkin menggunakan pertukaran Diﬃe-Hellman? Jika ada yang memasukkan pembayaran itu ID yang dibundel di suatu tempat dalam transaksinya ke alamat Bob, pasti berasal dari Alex. Dengan cara ini, Alex tidak perlu mengungkapkan dirinya ke seluruh jaringan dengan memilih untuk menghubungkan jaringan tertentu transaksi, namun dia masih dapat mengidentifikasi dirinya kepada orang yang dia kirimi uang. Bukankah ini yang dilakukan Poloniex?

Transaksi Terima kasih masukannya Keluaran0 . . . Keluaran saya . . . Keluaran Gambar kunci Tanda tangan Tanda Tangan Cincin Kunci tujuan Keluaran1 Kunci tujuan Keluaran Transaksi luar negeri Keluaran pengirim Kunci tujuan Pasangan kunci satu kali Satu kali kunci pribadi Saya = xHp(P) hal, x Gambar 7. Pembuatan tanda tangan dering dalam transaksi standar. 5 Bukti Kerja Egalitarian Pada bagian ini kami mengusulkan dan menerapkan algoritma proof-of-work yang baru. Tujuan utama kami adalah untuk menutup kesenjangan antara penambang CPU (mayoritas) dan GPU/FPGA/ASIC (minoritas). Itu benar tepat bahwa beberapa pengguna dapat memiliki keunggulan tertentu dibandingkan yang lain, tetapi investasi mereka harus tumbuh setidaknya secara linear dengan kekuatan. Secara umum, memproduksi perangkat dengan tujuan khusus harus menjadi sesedikit mungkin menguntungkan. 5.1 Pekerjaan terkait Protokol Bitcoin proof-of-work asli menggunakan fungsi penetapan harga intensif CPU SHA-256. Ini terutama terdiri dari operator logika dasar dan hanya mengandalkan kecepatan komputasi prosesor, oleh karena itu sangat cocok untuk implementasi multicore/konveyor. Namun, komputer modern tidak dibatasi oleh jumlah operasi per detik saja, tetapi juga berdasarkan ukuran memori. Meskipun beberapa prosesor bisa jauh lebih cepat dibandingkan prosesor lainnya [8], ukuran memori cenderung bervariasi antar mesin. Fungsi harga terikat memori pertama kali diperkenalkan oleh Abadi et al dan didefinisikan sebagai “fungsi yang waktu komputasinya didominasi oleh waktu yang dihabiskan untuk mengakses memori” [15]. Ide utamanya adalah untuk membangun sebuah algoritma yang mengalokasikan blok data yang besar (“scratchpad”) dalam memori yang dapat diakses secara relatif lambat (misalnya, RAM) dan “mengakses sebuah urutan lokasi yang tidak dapat diprediksi” di dalamnya. Satu blok harus cukup besar untuk dapat diawetkan data lebih menguntungkan daripada menghitung ulang untuk setiap akses. Algoritmenya juga harus mencegah paralelisme internal, maka N thread simultan memerlukan memori N kali lebih banyak sekaligus. Dwork et al [22] menyelidiki dan memformalkan pendekatan ini sehingga mereka menyarankan pendekatan lain varian fungsi penetapan harga: “Mbound”. Satu lagi karya milik F. Coelho [20] yang 11 Transaksi Terima kasih masukannya Keluaran0 . . . Keluaran saya . . . Keluaran Gambar kunci Tanda tangan Tanda Tangan Cincin Kunci tujuan Keluaran1 Kunci tujuan Keluaran Transaksi luar negeri Keluaran pengirim Kunci tujuan Pasangan kunci satu kali Satu kali kunci pribadi Saya = xHp(P) hal, x Gambar 7. Pembuatan tanda tangan dering dalam transaksi standar. 5 Bukti Kerja Egalitarian Di bagian ini kami mengusulkan dan mendasarkan algoritma proof-of-work baru. Tujuan utama kami adalah untuk menutup kesenjangan antara penambang CPU (mayoritas) dan GPU/FPGA/ASIC (minoritas). Itu benar tepat bahwa beberapa pengguna dapat memiliki keunggulan tertentu dibandingkan yang lain, tetapi investasi mereka harus tumbuh setidaknya secara linear dengan kekuatan. Secara umum, memproduksi perangkat dengan tujuan khusus harus menjadi sesedikit mungkin menguntungkan. 5.1 Pekerjaan terkait Protokol Bitcoin proof-of-work asli menggunakan fungsi penetapan harga intensif CPU SHA-256. Ini terutama terdiri dari operator logika dasar dan hanya mengandalkan kecepatan komputasi prosesor, oleh karena itu sangat cocok untuk implementasi multicore/konveyor. Namun, komputer modern tidak dibatasi oleh jumlah operasi per detik saja, tetapi juga berdasarkan ukuran memori. Meskipun beberapa prosesor bisa jauh lebih cepat dibandingkan prosesor lainnya [8], ukuran memori cenderung bervariasi antar mesin. Fungsi harga terikat memori pertama kali diperkenalkan oleh Abadi et al dan didefinisikan sebagai “fungsi yang waktu komputasinya didominasi oleh waktu yang dihabiskan untuk mengakses memori” [15]. Ide utamanya adalah untuk membangun sebuah algoritma yang mengalokasikan blok data yang besar (“scratchpad”) dalam memori yang dapat diakses secara relatif lambat (misalnya, RAM) dan “mengakses sebuah urutan lokasi yang tidak dapat diprediksi” di dalamnya. Satu blok harus cukup besar untuk dapat diawetkan data lebih menguntungkan daripada menghitung ulang untuk setiap akses. Algoritmenya juga harus mencegah paralelisme internal, maka N thread simultan memerlukan memori N kali lebih banyak sekaligus. Dwork et al [22] menyelidiki dan memformalkan pendekatan ini sehingga mereka menyarankan pendekatan lain varian fungsi penetapan harga: “Mbound”. Satu lagi karya milik F. Coelho [20] yang 11 21 Tampaknya ini adalah UTXO kami: jumlah dan kunci tujuan. Jika Alex yang membuat transaksi standar ini dan mengirimkannya ke Bob, maka Alex juga memiliki kunci privatnya untuk masing-masing ini. Saya sangat menyukai diagram ini, karena menjawab beberapa pertanyaan sebelumnya. Masukan Txn terdiri dari satu set keluaran Txn dan kekamu gambar. Kemudian ditandatangani dengan tanda tangan cincin, termasuk semuanya kunci pribadi yang dimiliki Alex untuk semua transaksi luar negeri yang terbungkus dalam kesepakatan itu. Itu Output Txn terdiri dari jumlah dan kunci tujuan. Penerima transaksi dapat, sesuka hati, buat kunci pribadi satu kali seperti yang dijelaskan sebelumnya di makalah untuk dibelanjakan uangnya. Akan menyenangkan untuk mengetahui seberapa cocoknya ini dengan kode sebenarnya... Tidak, Nic van Saberhagen menjelaskan secara longgar beberapa properti dari algoritma bukti kerja, tanpa benar-benar menjelaskan algoritma itu. Algoritma CryptoNight sendiri MEMBUTUHKAN analisis mendalam. Ketika saya membaca ini, saya tergagap. Haruskah investasi tumbuh setidaknya secara linear dengan kekuatan, atau seharusnya investasi tumbuh paling banyak secara linear dengan kekuatan? Dan kemudian saya menyadari; Saya, sebagai penambang, atau investor, biasanya memikirkan "seberapa besar kekuatan yang bisa saya peroleh untuk investasi?" bukan "berapa banyak investasi yang diperlukan untuk jumlah listrik yang tetap?" Tentu saja, nyatakan investasi dengan I dan daya dengan P. Jika I(P) adalah investasi sebagai fungsi daya dan P(I) adalah kekuatan sebagai fungsi investasi, keduanya akan berbanding terbalik satu sama lain (di mana pun invers bisa ada). Dan jika I(P) lebih cepat dari linier maka P(I) lebih lambat dari linier. Oleh karena itu, akan ada penurunan tingkat pengembalian bagi investor. Dengan kata lain, apa yang ingin penulis katakan di sini adalah: "Tentu saja, jika Anda berinvestasi lebih banyak, Anda akan mendapatkan lebih banyak kekuatan. Tapi kita harus mencoba membuat tingkat pengembaliannya lebih rendah." Investasi CPU pada akhirnya akan terbatas secara sub-linear; pertanyaannya adalah apakah penulisnya telah merancang algoritma POW yang akan memaksa ASIC untuk juga melakukan hal ini. Haruskah “mata uang masa depan” hipotetis selalu ditambang dengan sumber daya yang paling lambat/terbatas? Makalah yang ditulis oleh Abadi dkk (yang ditulis oleh beberapa insinyur Google dan Microsoft) adalah, pada dasarnya, menggunakan fakta bahwa selama beberapa tahun terakhir ukuran memori menjadi jauh lebih kecil variansi antar mesin dibandingkan kecepatan prosesor, dan dengan rasio investasi-daya yang lebih dari linier. Dalam beberapa tahun, hal ini mungkin harus dikaji ulang! Semuanya adalah perlombaan senjata... Membangun fungsi hash sulit; membangun fungsi hash yang memenuhi batasan ini tampaknya lebih sulit. Tulisan ini sepertinya tidak memiliki penjelasan yang sebenarnya hashing algoritma CryptoNight. Saya pikir ini adalah implementasi SHA-3 yang berbasis memori di postingan forum tapi saya tidak tahu... dan itulah intinya. Itu harus dijelaskan.

mengusulkan solusi paling efektif: “Hokkaido”. Sepengetahuan kami, karya terakhir yang didasarkan pada gagasan pencarian pseudo-acak dalam array besar adalah algoritma yang dikenal sebagai "scrypt" oleh C. Percival [32]. Berbeda dengan fungsi sebelumnya yang menjadi fokusnya derivasi kunci, dan bukan sistem proof-of-work. Meskipun demikian, scrypt dapat memenuhi tujuan kita: ini berfungsi dengan baik sebagai fungsi penetapan harga dalam masalah konversi parsial hash seperti SHA-256 di Bitcoin. Saat ini scrypt telah diterapkan di Litecoin [14] dan beberapa fork Bitcoin lainnya. Namun, implementasinya tidak terlalu terikat pada memori: rasio “waktu akses memori / keseluruhan time” tidak cukup besar karena setiap instance hanya menggunakan 128 KB. Ini mengizinkan penambang GPU menjadi kira-kira 10 kali lebih efektif dan terus meninggalkan kemungkinan penciptaan secara relatif perangkat penambangan yang murah namun sangat efisien. Selain itu, konstruksi scrypt itu sendiri memungkinkan pertukaran linier antara ukuran memori dan Kecepatan CPU karena fakta bahwa setiap blok di scratchpad hanya diturunkan dari blok sebelumnya. Misalnya, Anda dapat menyimpan setiap blok kedua dan menghitung ulang blok lainnya dengan cara yang malas, yaitu saja ketika hal itu menjadi perlu. Indeks pseudo-acak diasumsikan terdistribusi secara seragam, maka nilai yang diharapkan dari perhitungan ulang blok tambahan adalah 1 \(2 \cdot N\), dimana N adalah nomornya dari iterasi. Waktu komputasi keseluruhan bertambah kurang dari setengahnya karena ada juga operasi yang tidak bergantung pada waktu (waktu konstan) seperti menyiapkan alas gores dan hashmelanjutkan setiap iterasi. Menghemat 2/3 memori membutuhkan biaya 1 3 \(\cdot\) T+1 3 \(\cdot\) \(2 \cdot N\) = N perhitungan ulang tambahan; 9/10 menghasilkan 1 10 \(\cdot\) T+. . . + 1 \(10 \cdot 9 \cdot N\) = 4,5N. Mudah untuk menunjukkan bahwa menyimpan hanya 1 s dari semua blok meningkatkan waktu kurang dari faktor s−1 2. Hal ini pada gilirannya menyiratkan bahwa mesin dengan CPU 200 kali lebih cepat dibandingkan chip modern yang hanya mampu menyimpan 320 byte scratchpad. 5.2 Algoritma yang diusulkan Kami mengusulkan algoritma terikat memori baru untuk fungsi penetapan harga proof-of-work. Itu bergantung pada akses acak ke memori lambat dan menekankan ketergantungan latensi. Berbeda dengan scrypt every blok baru (panjang 64 byte) bergantung pada semua blok sebelumnya. Hasilnya bersifat hipotetis "penghemat memori" akan meningkatkan kecepatan penghitungannya secara eksponensial. Algoritme kami memerlukan sekitar 2 Mb per instance karena alasan berikut: 1. Cocok dengan cache L3 (per inti) prosesor modern, yang seharusnya menjadi mainstream dalam beberapa tahun; 2. Memori internal satu megabyte adalah ukuran yang hampir tidak dapat diterima untuk pipeline ASIC modern; 3. GPU dapat menjalankan ratusan instance secara bersamaan, namun dibatasi dalam hal lain: Memori GDDR5 lebih lambat dari cache CPU L3 dan luar biasa karena bandwidthnya kecepatan akses acak. 4. Perluasan scratchpad secara signifikan memerlukan peningkatan iterasi, yang mana dalam hal ini giliran menyiratkan peningkatan waktu secara keseluruhan. Panggilan “berat” di jaringan p2p yang tidak dapat dipercaya dapat menyebabkan kerentanan serius, karena node wajib memeriksa proof-of-work setiap blok baru. Jika sebuah node menghabiskan banyak waktu pada setiap evaluasi hash, maka node tersebut dapat dengan mudah DDoS oleh banjir objek palsu dengan data kerja sewenang-wenang (nilainonce). 12 mengusulkan solusi paling efektif: “Hokkaido”. Sepengetahuan kami, karya terakhir yang didasarkan pada gagasan pencarian pseudo-acak dalam array besar adalah algoritma yang dikenal sebagai "scrypt" oleh C. Percival [32]. Berbeda dengan fungsi sebelumnya yang menjadi fokusnya derivasi kunci, dan bukan sistem proof-of-work. Meskipun demikian, scrypt dapat memenuhi tujuan kita: ini berfungsi dengan baik sebagai fungsi penetapan harga dalam masalah konversi parsial hash seperti SHA-256 di Bitcoin. Saat ini scrypt telah diterapkan di Litecoin [14] dan beberapa fork Bitcoin lainnya. Namun, implementasinya tidak terlalu terikat pada memori: rasio “waktu akses memori / keseluruhan time” tidak cukup besar karena setiap instance hanya menggunakan 128 KB. Ini mengizinkan penambang GPU menjadi kira-kira 10 kali lebih efektif dan terus meninggalkan kemungkinan penciptaan secara relatif perangkat penambangan yang murah namun sangat efisien. Selain itu, konstruksi scrypt itu sendiri memungkinkan pertukaran linier antara ukuran memori dan Kecepatan CPU karena fakta bahwa setiap blok di scratchpad hanya diturunkan dari blok sebelumnya. Misalnya, Anda dapat menyimpan setiap blok kedua dan menghitung ulang blok lainnya dengan cara yang malas, yaitu saja ketika hal itu menjadi perlu. Indeks pseudo-acak diasumsikan terdistribusi secara seragam, maka nilai yang diharapkan dari perhitungan ulang blok tambahan adalah 1 \(2 \cdot N\), dimanaN adalah nomornya dari iterasi. Waktu komputasi keseluruhan bertambah kurang dari setengahnya karena ada juga operasi yang tidak bergantung pada waktu (waktu konstan) seperti menyiapkan alas gores dan hashmelanjutkan setiap iterasi. Menghemat 2/3 memori membutuhkan biaya 1 3 \(\cdot\) T+1 3 \(\cdot\) \(2 \cdot N\) = N perhitungan ulang tambahan; 9/10 menghasilkan 1 10 \(\cdot\) T+. . . + 1 \(10 \cdot 9 \cdot N\) = 4,5N. Mudah untuk menunjukkan bahwa menyimpan hanya 1 s dari semua blok meningkatkan waktu kurang dari faktor s−1 2. Hal ini pada gilirannya menyiratkan bahwa mesin dengan CPU 200 kali lebih cepat dibandingkan chip modern yang hanya mampu menyimpan 320 byte scratchpad. 5.2 Algoritma yang diusulkan Kami mengusulkan algoritma terikat memori baru untuk fungsi penetapan harga proof-of-work. Itu bergantung pada akses acak ke memori lambat dan menekankan ketergantungan latensi. Berbeda dengan scrypt every blok baru (panjang 64 byte) bergantung pada semua blok sebelumnya. Hasilnya bersifat hipotetis "penghemat memori" akan meningkatkan kecepatan penghitungannya secara eksponensial. Algoritme kami memerlukan sekitar 2 Mb per instance karena alasan berikut: 1. Cocok dengan cache L3 (per inti) prosesor modern, yang seharusnya menjadi mainstream dalam beberapa tahun; 2. Memori internal satu megabyte adalah ukuran yang hampir tidak dapat diterima untuk pipeline ASIC modern; 3. GPU dapat menjalankan ratusan instance secara bersamaan, namun dibatasi dalam hal lain: Memori GDDR5 lebih lambat dari cache CPU L3 dan luar biasa karena bandwidthnya kecepatan akses acak. 4. Perluasan scratchpad secara signifikan memerlukan peningkatan iterasi, yang mana dalam hal ini giliran menyiratkan peningkatan waktu secara keseluruhan. Panggilan “berat” di jaringan p2p yang tidak dapat dipercaya dapat menyebabkan kerentanan serius, karena node wajib memeriksa proof-of-work setiap blok baru. Jika sebuah node menghabiskan banyak waktu pada setiap evaluasi hash, maka node tersebut dapat dengan mudah DDoS oleh banjir objek palsu dengan data kerja sewenang-wenang (nilainonce). 12 22 Sudahlah, itu koin scrypt? Dimana algoritmanya? Yang saya lihat hanyalah sebuah iklan. Di sinilah Cryptonote, jika algoritma PoW mereka bermanfaat, akan benar-benar bersinar. Bukan itu sungguh SHA-256, sebenarnya bukan scrypt. Ini baru, terikat memori, dan non-rekursif.

6 Keuntungan lebih lanjut 6.1 Emisi halus Batas atas jumlah keseluruhan koin digital CryptoNote adalah: MSupply = 264 −1 satuan atom. Ini adalah batasan alami yang hanya didasarkan pada batasan implementasi, bukan berdasarkan intuisi seperti “N koin seharusnya cukup untuk siapa pun”. Untuk menjamin kelancaran proses emisi kami menggunakan formula blok berikut hadiah: BaseReward = (MSupply −A) ≫18, di mana A adalah jumlah koin yang dihasilkan sebelumnya. 6.2 Parameter yang dapat disesuaikan 6.2.1 Kesulitan CryptoNote berisi algoritma penargetan yang mengubah kesulitan setiap blok. Ini mengurangi waktu reaksi sistem ketika laju hash jaringan meningkat atau menyusut secara intensif, mempertahankan tingkat blok yang konstan. Metode Bitcoin asli menghitung relasi aktual dan menargetkan rentang waktu antara blok 2016 terakhir dan menggunakannya sebagai pengali untuk blok saat ini kesulitan. Jelas ini tidak cocok untuk perhitungan ulang yang cepat (karena inersia yang besar) dan menghasilkan osilasi. Ide umum di balik algoritme kami adalah menjumlahkan semua pekerjaan yang diselesaikan oleh node dan membaginya dengan waktu yang telah mereka habiskan. Ukuran pekerjaan adalah nilai kesulitan yang sesuai di setiap blok. Namun karena stempel waktu yang tidak akurat dan tidak dapat dipercaya, kami tidak dapat menentukan waktu yang tepat interval waktu antar blok. Seorang pengguna dapat menggeser stempel waktunya ke masa depan dan waktu berikutnya intervalnya mungkin sangat kecil atau bahkan negatif. Agaknya akan ada beberapa insiden semacam ini, jadi kita tinggal mengurutkan stempel waktu dan menghilangkan outliernya (yaitu 20%). Kisaran nilai sisanya adalah waktu yang dihabiskan untuk 80% blok terkait. 6.2.2 Batasan ukuran Pengguna membayar untuk menyimpan blockchain dan berhak memilih ukurannya. Setiap penambang berurusan dengan pertukaran antara menyeimbangkan biaya dan keuntungan dari biaya dan menetapkan biayanya sendiri “batas lunak” untuk membuat blok. Aturan inti untuk ukuran blok maksimum juga diperlukan mencegah blockchain dibanjiri transaksi palsu, namun nilai ini seharusnya tidak dikodekan secara keras. Misalkan MN adalah nilai median dari N ukuran blok terakhir. Kemudian “batas keras” untuk ukurannya menerima blok adalah \(2 \cdot M_N\). Ini mencegah blockchain membengkak tetapi masih memungkinkan batasnya perlahan tumbuh seiring waktu jika perlu. Ukuran transaksi tidak perlu dibatasi secara eksplisit. Itu dibatasi oleh ukuran sebuah balok; dan jika seseorang ingin membuat transaksi besar dengan ratusan input/output (atau dengan tingkat ambiguitas yang tinggi dalam tanda tangan cincin), ia dapat melakukannya dengan membayar biaya yang cukup. 6.2.3 Hukuman kelebihan ukuran Seorang penambang masih memiliki kemampuan untuk mengisi satu blok penuh dengan transaksi tanpa biaya miliknya hingga maksimum ukuran \(2 \cdot M_b\). Meskipun hanya mayoritas penambang yang dapat menggeser nilai median, masih ada a 13 6 Keuntungan lebih lanjut 6.1 Emisi halus Batas atas jumlah keseluruhan koin digital CryptoNote adalah: MSupply = 264 −1 satuan atom. Ini adalah batasan alami yang hanya didasarkan pada batasan implementasi, bukan berdasarkan intuisi seperti “N koin seharusnya cukup untuk siapa pun”. Untuk menjamin kelancaran proses emisi kami menggunakan formula blok berikut hadiah: BaseReward = (MSupply −A) ≫18, di mana A adalah jumlah koin yang dihasilkan sebelumnya. 6.2 Parameter yang dapat disesuaikan 6.2.1 Kesulitan CryptoNote berisi algoritma penargetan yang mengubah kesulitan setiap blok. Ini mengurangi waktu reaksi sistem ketika laju hash jaringan meningkat atau menyusut secara intensif, mempertahankan tingkat blok yang konstan. Metode Bitcoin asli menghitung hubungan aktual dan menargetkan rentang waktu antara blok 2016 terakhir dan menggunakannya sebagai pengali untuk blok saat ini kesulitan. Jelas ini tidak cocok untuk perhitungan ulang yang cepat (karena inersia yang besar) dan menghasilkan osilasi. Ide umum di balik algoritme kami adalah menjumlahkan semua pekerjaan yang diselesaikan oleh node dan membaginya dengan waktu yang telah mereka habiskan. Ukuran pekerjaan adalah nilai kesulitan yang sesuai di setiap blok. Namun karena stempel waktu yang tidak akurat dan tidak dapat dipercaya, kami tidak dapat menentukan waktu yang tepat interval waktu antar blok. Seorang pengguna dapat menggeser stempel waktunya ke masa depan dan waktu berikutnya intervalnya mungkin sangat kecil atau bahkan negatif. Agaknya akan ada beberapa insiden semacam ini, jadi kita tinggal mengurutkan stempel waktu dan menghilangkan outliernya (yaitu 20%). Kisaran nilai sisanya adalah waktu yang dihabiskan untuk 80% blok terkait. 6.2.2 Batasan ukuran Pengguna membayar untuk menyimpan blockchain dan berhak memilih ukurannya. Setiap penambang berkaitan dengan pertukaran antara penyeimbangan the biaya dan keuntungan dari biaya dan menetapkan sendiri “batas lunak” untuk membuat blok. Aturan inti untuk ukuran blok maksimum juga diperlukan mencegah blockchain dibanjiri transaksi palsu, namun nilai ini seharusnya tidak dikodekan secara keras. Misalkan MN adalah nilai median dari N ukuran blok terakhir. Kemudian “batas keras” untuk ukurannya menerima blok adalah \(2 \cdot M_N\). Ini mencegah blockchain membengkak tetapi masih memungkinkan batasnya perlahan tumbuh seiring waktu jika perlu. Ukuran transaksi tidak perlu dibatasi secara eksplisit. Itu dibatasi oleh ukuran sebuah balok; dan jika seseorang ingin membuat transaksi besar dengan ratusan input/output (atau dengan tingkat ambiguitas yang tinggi dalam tanda tangan cincin), ia dapat melakukannya dengan membayar biaya yang cukup. 6.2.3 Hukuman kelebihan ukuran Seorang penambang masih memiliki kemampuan untuk mengisi satu blok penuh dengan transaksi tanpa biaya miliknya hingga maksimum ukuran \(2 \cdot M_b\). Meskipun hanya mayoritas penambang yang dapat menggeser nilai median, masih ada a 13 23 Unit atom. Saya suka itu. Apakah ini setara dengan Satoshi? Jika demikian, berarti akan ada 185 miliar cryptonote. Saya tahu ini pada akhirnya harus diubah dalam beberapa halaman, atau mungkin ada kesalahan ketik? Jika hadiah dasarnya adalah "semua koin yang tersisa" maka hanya satu blok yang cukup untuk mendapatkan semua koin. Instamin. Di sisi lain, jika hal ini seharusnya proporsional dengan perbedaan waktu antara sekarang dan tanggal penghentian produksi koin? Itu akan terjadi masuk akal. Juga, di duniaku, dua tanda lebih besar dari seperti ini berarti "lebih besar dari". Apakah penulisnya mungkin maksudnya lain? Jika penyesuaian terhadap kesulitan terjadi di setiap blok maka penyerang dapat memiliki lahan yang sangat besar mesin menambang dan mematikan dalam interval waktu yang dipilih dengan cermat. Hal ini dapat menyebabkan ledakan yang kacau (atau jatuh ke titik nol) pada tingkat kesulitan, jika formula penyesuaian tingkat kesulitan tidak diredam dengan tepat. Tidak diragukan lagi bahwa metode Bitcoin tidak cocok untuk penghitungan ulang cepat, tetapi gagasan tentang inersia dalam sistem ini perlu dibuktikan, bukan dianggap remeh. Selanjutnya osilasi dalam kesulitan jaringan belum tentu menjadi masalah kecuali jika hal itu mengakibatkan fluktuasi yang nyata persediaan koin - dan perubahan kesulitan yang sangat cepat dapat menyebabkan "koreksi berlebihan". Waktu yang dihabiskan, terutama dalam rentang waktu yang singkat seperti beberapa menit, akan sebanding dengan “total jumlah blok yang dibuat di jaringan." Konstanta proporsionalitas akan tumbuh dengan sendirinya seiring waktu, mungkin secara eksponensial jika CN lepas landas. Mungkin merupakan ide yang lebih baik untuk menyesuaikan kesulitan untuk menjaga "total blok yang dibuat pada jaringan sejak blok terakhir ditambahkan ke rantai utama" dalam beberapa nilai konstan, atau dengan variasi terbatas atau semacamnya. Jika algoritma adaptif yaitu komputasi mudah diimplementasikan dapat ditentukan, ini tampaknya menyelesaikan masalah. Namun, jika kita menggunakan metode itu, seseorang yang memiliki lahan pertambangan besar bisa saja menutup lahan pertaniannya selama beberapa jam, dan hidupkan kembali. Untuk beberapa blok pertama, lahan pertanian tersebut akan berhasil bank. Jadi sebenarnya cara ini akan memunculkan satu hal menarik: penambangan menjadi (rata-rata) a kalah tanpa ROI, terutama karena semakin banyak orang yang menggunakan jaringan. Jika penambangannya sulit jaringan yang dilacak dengan sangat dekat hashrate, entah bagaimana saya ragu orang akan menambang sebanyak mereka saat ini lakukan. Atau, di sisi lain, alih-alih menjaga lahan pertambangan mereka tetap beroperasi 24/7, mereka malah mengubahnya menyala selama 6 jam, mati selama 2 jam, hidup selama 6 jam, mati selama 2 jam, atau semacamnya. Beralih saja ke koin lain selama beberapa jam, tunggu hingga tingkat kesulitannya mereda, lalu lanjutkan lagi untuk mendapatkan tambahan tersebut blok profitabilitas saat jaringan beradaptasi. Dan tahukah Anda? Ini sebenarnya mungkin salah satu skenario penambangan terbaik yang pernah saya pikirkan... Ini bisa bersifat melingkar, tetapi jika waktu pembuatan blok rata-rata sekitar satu menit, bisakah kita melakukannya? gunakan jumlah blok sebagai proksi untuk "waktu yang dihabiskan?"

6 Keuntungan lebih lanjut 6.1 Emisi halus Batas atas jumlah keseluruhan koin digital CryptoNote adalah: MSupply = 264 −1 satuan atom. Ini adalah batasan alami yang hanya didasarkan pada batasan implementasi, bukan berdasarkan intuisi seperti “N koin seharusnya cukup untuk siapa pun”. Untuk menjamin kelancaran proses emisi kami menggunakan formula blok berikut hadiah: BaseReward = (MSupply −A) ≫18, di mana A adalah jumlah koin yang dihasilkan sebelumnya. 6.2 Parameter yang dapat disesuaikan 6.2.1 Kesulitan CryptoNote berisi algoritma penargetan yang mengubah kesulitan setiap blok. Ini mengurangi waktu reaksi sistem ketika laju hash jaringan meningkat atau menyusut secara intensif, mempertahankan tingkat blok yang konstan. Metode Bitcoin asli menghitung hubungan aktual dan menargetkan rentang waktu antara blok 2016 terakhir dan menggunakannya sebagai pengali untuk blok saat ini kesulitan. Jelas ini tidak cocok untuk perhitungan ulang yang cepat (karena inersia yang besar) dan menghasilkan osilasi. Ide umum di balik algoritme kami adalah menjumlahkan semua pekerjaan yang diselesaikan oleh node dan membaginya dengan waktu yang telah mereka habiskan. Ukuran pekerjaan adalah nilai kesulitan yang sesuai di setiap blok. Namun karena stempel waktu yang tidak akurat dan tidak dapat dipercaya, kami tidak dapat menentukan waktu yang tepat interval waktu antar blok. Seorang pengguna dapat menggeser stempel waktunya ke masa depan dan waktu berikutnya intervalnya mungkin sangat kecil atau bahkan negatif. Agaknya akan ada beberapa insiden semacam ini, jadi kita tinggal mengurutkan stempel waktu dan menghilangkan outliernya (yaitu 20%). Kisaran nilai sisanya adalah waktu yang dihabiskan untuk 80% blok terkait. 6.2.2 Batasan ukuran Pengguna membayar untuk menyimpan blockchain dan berhak memilih ukurannya. Setiap penambang berurusan dengan pertukaran antara menyeimbangkan biaya dan keuntungan dari biaya dan menetapkan biayanya sendiri “batas lunak” untuk membuat blok. Aturan inti untuk ukuran blok maksimum juga diperlukan mencegah blockchain dibanjiri transaksi palsu, namun nilai ini seharusnya tidak dikodekan secara keras. Misalkan MN adalah nilai median dari N ukuran blok terakhir. Kemudian “batas keras” untuk ukurannya menerima blok adalah \(2 \cdot M_N\). Ini mencegah blockchain membengkak tetapi masih memungkinkan batasnya perlahan tumbuh seiring waktu jika perlu. Ukuran transaksi tidak perlu dibatasi secara eksplisit. Itu dibatasi oleh ukuran sebuah balok; dan jika seseorang ingin membuat transaksi besar dengan ratusan input/output (atau dengan tingkat ambiguitas yang tinggi dalam tanda tangan cincin), ia dapat melakukannya dengan membayar biaya yang cukup. 6.2.3 Hukuman kelebihan ukuran Seorang penambang masih memiliki kemampuan untuk mengisi satu blok penuh dengan transaksi tanpa biaya miliknya hingga maksimum ukuran \(2 \cdot M_b\). Meskipun hanya mayoritas penambang yang dapat menggeser nilai median, masih ada a 13 6 Keuntungan lebih lanjut 6.1 Emisi halus Batas atas jumlah keseluruhan koin digital CryptoNote adalah: MSupply = 264 −1 satuan atom. Ini adalah batasan alami yang hanya didasarkan pada batasan implementasi, bukan berdasarkan intuisi seperti “N koin seharusnya cukup untuk siapa pun”. Untuk menjamin kelancaran proses emisi kami menggunakan formula blok berikut hadiah: BaseReward = (MSupply −A) ≫18, di mana A adalah jumlah koin yang dihasilkan sebelumnya. 6.2 Parameter yang dapat disesuaikan 6.2.1 Kesulitan CryptoNote berisi algoritma penargetan yang mengubah kesulitan setiap blok. Ini mengurangi waktu reaksi sistem ketika laju hash jaringan meningkat atau menyusut secara intensif, mempertahankan tingkat blok yang konstan. Metode Bitcoin asli menghitung hubungan aktual dan menargetkan rentang waktu antara blok 2016 terakhir dan menggunakannya sebagai pengali untuk blok saat ini kesulitan. Jelas ini tidak cocok untuk perhitungan ulang yang cepat (karena inersia yang besar) dan menghasilkan osilasi. Ide umum di balik algoritme kami adalah menjumlahkan semua pekerjaan yang diselesaikan oleh node dan membaginya dengan waktu yang telah mereka habiskan. Ukuran pekerjaan adalah nilai kesulitan yang sesuai di setiap blok. Namun karena stempel waktu yang tidak akurat dan tidak dapat dipercaya, kami tidak dapat menentukan waktu yang tepat interval waktu antar blok. Seorang pengguna dapat menggeser stempel waktunya ke masa depan dan waktu berikutnya intervalnya mungkin sangat kecil atau bahkan negatif. Agaknya akan ada beberapa insiden semacam ini, jadi kita tinggal mengurutkan stempel waktu dan menghilangkan outliernya (yaitu 20%). Kisaran nilai sisanya adalah waktu yang dihabiskan untuk 80% blok terkait. 6.2.2 Batasan ukuran Pengguna membayar untuk menyimpan blockchain dan berhak memilih ukurannya. Setiap penambang berkaitan dengan pertukaran antara penyeimbangan the biaya dan keuntungan dari biaya dan menetapkan sendiri “batas lunak” untuk membuat blok. Aturan inti untuk ukuran blok maksimum juga diperlukan mencegah blockchain dibanjiri transaksi palsu, namun nilai ini seharusnya tidak dikodekan secara keras. Misalkan MN adalah nilai median dari N ukuran blok terakhir. Kemudian “batas keras” untuk ukurannya menerima blok adalah \(2 \cdot M_N\). Ini mencegah blockchain membengkak tetapi masih memungkinkan batasnya perlahan tumbuh seiring waktu jika perlu. Ukuran transaksi tidak perlu dibatasi secara eksplisit. Itu dibatasi oleh ukuran sebuah balok; dan jika seseorang ingin membuat transaksi besar dengan ratusan input/output (atau dengan tingkat ambiguitas yang tinggi dalam tanda tangan cincin), ia dapat melakukannya dengan membayar biaya yang cukup. 6.2.3 Hukuman kelebihan ukuran Seorang penambang masih memiliki kemampuan untuk mengisi satu blok penuh dengan transaksi tanpa biaya miliknya hingga maksimum ukuran \(2 \cdot M_b\). Meskipun hanya mayoritas penambang yang dapat menggeser nilai median, masih ada a 13 24 Oke, jadi kita punya blockchain, dan setiap blok memiliki stempel waktu SELAIN sekedar menjadi dipesan. Ini jelas dimasukkan hanya untuk kesulitan penyesuaian, karena ada stempel waktunya sangat tidak dapat diandalkan, seperti yang disebutkan. Apakah kita diperbolehkan memiliki stempel waktu yang bertentangan dalam rantai? Jika Blok A berada sebelum Blok B dalam rantai tersebut, dan semuanya konsisten dalam hal keuangan, tapi Blok A sepertinya dibuat setelah Blok B? Karena, mungkin, ada yang memilikinya sebagian besar jaringan? Apakah itu oke? Mungkin karena keuangannya tidak salah. Oke, jadi saya benci kesewenang-wenangan ini "hanya 80% blok yang sah untuk blockchain utama" pendekatan. Itu dimaksudkan untuk mencegah pembohong mengubah stempel waktunya? Tapi sekarang, ia menambahkan insentif bagi semua orang untuk berbohong tentang stempel waktunya dan hanya memilih median. Silakan jelaskan. Artinya “untuk blok ini, hanya mencakup transaksi yang menyertakan biaya lebih besar dari p%, lebih disukai dengan biaya lebih besar dari 2p%" atau sesuatu seperti itu? Apa yang mereka maksud dengan palsu? Jika transaksi tersebut konsisten dengan riwayat masa lalu blockchain, dan transaksi tersebut mencakup biaya yang memuaskan para penambang, apakah itu tidak cukup? Nah, tidak, belum tentu. Jika tidak ada ukuran blok maksimum, tidak ada yang bisa menahan pengguna jahat dari sekadar mengunggah sejumlah besar transaksi ke dirinya sendiri sekaligus hanya untuk memperlambat jaringan. Aturan inti untuk ukuran blok maksimum mencegah orang membuang sampah dalam jumlah besar data di blockchain sekaligus hanya untuk memperlambat segalanya. Namun aturan seperti itu tentu saja harus dilakukan bersikap adaptif - selama musim Natal, misalnya, kita dapat memperkirakan lalu lintas akan melonjak, dan ukuran blok menjadi sangat besar, dan segera setelah itu, ukuran blok kemudian turun lagi. Jadi kita memerlukan a) semacam batasan adaptif atau b) batasan yang cukup besar sehingga 99%. puncak Natal yang masuk akal tidak akan merusak batasnya. Tentu saja, yang kedua itu tidak mungkin dilakukan perkiraan - siapa yang tahu apakah suatu mata uang akan berhasil? Lebih baik membuatnya adaptif dan tidak khawatir tentang hal itu. Tapi kemudian kita mempunyai masalah teori kontrol: bagaimana membuat ini adaptif tanpanya kerentanan terhadap serangan atau osilasi liar & gila? Perhatikan bahwa metode adaptif tidak menghentikan pengguna jahat untuk mengumpulkan sejumlah kecil uang data sampah dari waktu ke waktu di blockchain menyebabkan pembengkakan jangka panjang. Ini adalah masalah yang berbeda semuanya dan koin cryptonote memiliki masalah serius.

6 Keuntungan lebih lanjut 6.1 Emisi halus Batas atas jumlah keseluruhan koin digital CryptoNote adalah: MSupply = 264 −1 satuan atom. Ini adalah batasan alami yang hanya didasarkan pada batasan implementasi, bukan berdasarkan intuisi seperti “N koin seharusnya cukup untuk siapa pun”. Untuk menjamin kelancaran proses emisi kami menggunakan formula blok berikut hadiah: BaseReward = (MSupply −A) ≫18, di mana A adalah jumlah koin yang dihasilkan sebelumnya. 6.2 Parameter yang dapat disesuaikan 6.2.1 Kesulitan CryptoNote berisi algoritma penargetan yang mengubah kesulitan setiap blok. Ini mengurangi waktu reaksi sistem ketika laju hash jaringan meningkat atau menyusut secara intensif, mempertahankan tingkat blok yang konstan. Metode Bitcoin asli menghitung hubungan aktual dan menargetkan rentang waktu antara blok 2016 terakhir dan menggunakannya sebagai pengali untuk blok saat ini kesulitan. Jelas ini tidak cocok untuk perhitungan ulang yang cepat (karena inersia yang besar) dan menghasilkan osilasi. Ide umum di balik algoritme kami adalah menjumlahkan semua pekerjaan yang diselesaikan oleh node dan membaginya dengan waktu yang telah mereka habiskan. Ukuran pekerjaan adalah nilai kesulitan yang sesuai di setiap blok. Namun karena stempel waktu yang tidak akurat dan tidak dapat dipercaya, kami tidak dapat menentukan waktu yang tepat interval waktu antar blok. Seorang pengguna dapat menggeser stempel waktunya ke masa depan dan waktu berikutnya intervalnya mungkin sangat kecil atau bahkan negatif. Agaknya akan ada beberapa insiden semacam ini, jadi kita tinggal mengurutkan stempel waktu dan menghilangkan outliernya (yaitu 20%). Kisaran nilai sisanya adalah waktu yang dihabiskan untuk 80% blok terkait. 6.2.2 Batasan ukuran Pengguna membayar untuk menyimpan blockchain dan berhak memilih ukurannya. Setiap penambang berurusan dengan pertukaran antara menyeimbangkan biaya dan keuntungan dari biaya dan menetapkan biayanya sendiri “batas lunak” untuk membuat blok. Aturan inti untuk ukuran blok maksimum juga diperlukan mencegah blockchain dibanjiri transaksi palsu, namun nilai ini seharusnya tidak dikodekan secara keras. Misalkan MN adalah nilai median dari N ukuran blok terakhir. Kemudian “batas keras” untuk ukurannya menerima blok adalah \(2 \cdot M_N\). Ini mencegah blockchain membengkak tetapi masih memungkinkan batasnya perlahan tumbuh seiring waktu jika perlu. Ukuran transaksi tidak perlu dibatasi secara eksplisit. Itu dibatasi oleh ukuran sebuah balok; dan jika seseorang ingin membuat transaksi besar dengan ratusan input/output (atau dengan tingkat ambiguitas yang tinggi dalam tanda tangan cincin), ia dapat melakukannya dengan membayar biaya yang cukup. 6.2.3 Hukuman kelebihan ukuran Seorang penambang masih memiliki kemampuan untuk mengisi satu blok penuh dengan transaksi tanpa biaya miliknya hingga maksimum ukuran \(2 \cdot M_b\). Meskipun hanya mayoritas penambang yang dapat menggeser nilai median, masih ada a 13 6 Keuntungan lebih lanjut 6.1 Emisi halus Batas atas jumlah keseluruhan koin digital CryptoNote adalah: MSupply = 264 −1 satuan atom. Ini adalah batasan alami yang hanya didasarkan pada batasan implementasi, bukan berdasarkan intuisi seperti “N koin seharusnya cukup untuk siapa pun”. Untuk menjamin kelancaran proses emisi kami menggunakan formula blok berikut hadiah: BaseReward = (MSupply −A) ≫18, di mana A adalah jumlah koin yang dihasilkan sebelumnya. 6.2 Parameter yang dapat disesuaikan 6.2.1 Kesulitan CryptoNote berisi algoritma penargetan yang mengubah kesulitan setiap blok. Ini mengurangi waktu reaksi sistem ketika laju hash jaringan meningkat atau menyusut secara intensif, mempertahankan tingkat blok yang konstan. Metode Bitcoin asli menghitung relasi aktual dan menargetkan rentang waktu antara blok 2016 terakhir dan menggunakannya sebagai pengali untuk blok saat ini kesulitan. Jelas ini tidak cocok untuk perhitungan ulang yang cepat (karena inersia yang besar) dan menghasilkan osilasi. Ide umum di balik algoritme kami adalah menjumlahkan semua pekerjaan yang diselesaikan oleh node dan membaginya dengan waktu yang telah mereka habiskan. Ukuran pekerjaan adalah nilai kesulitan yang sesuai di setiap blok. Namun karena stempel waktu yang tidak akurat dan tidak dapat dipercaya, kami tidak dapat menentukan waktu yang tepat interval waktu antar blok. Seorang pengguna dapat menggeser stempel waktunya ke masa depan dan waktu berikutnya intervalnya mungkin sangat kecil atau bahkan negatif. Agaknya akan ada beberapa insiden semacam ini, jadi kita tinggal mengurutkan stempel waktu dan menghilangkan outliernya (yaitu 20%). Kisaran nilai sisanya adalah waktu yang dihabiskan untuk 80% blok terkait. 6.2.2 Batasan ukuran Pengguna membayar untuk menyimpan blockchain dan berhak memilih ukurannya. Setiap penambang berkaitan dengan pertukaran antara penyeimbangan the biaya dan keuntungan dari biaya dan menetapkan sendiri “batas lunak” untuk membuat blok. Aturan inti untuk ukuran blok maksimum juga diperlukan mencegah blockchain dibanjiri transaksi palsu, namun nilai ini seharusnya tidak dikodekan secara keras. Misalkan MN adalah nilai median dari N ukuran blok terakhir. Kemudian “batas keras” untuk ukurannya menerima blok adalah \(2 \cdot M_N\). Ini mencegah blockchain membengkak tetapi masih memungkinkan batasnya perlahan tumbuh seiring waktu jika perlu. Ukuran transaksi tidak perlu dibatasi secara eksplisit. Itu dibatasi oleh ukuran sebuah balok; dan jika seseorang ingin membuat transaksi besar dengan ratusan input/output (atau dengan tingkat ambiguitas yang tinggi dalam tanda tangan cincin), ia dapat melakukannya dengan membayar biaya yang cukup. 6.2.3 Hukuman kelebihan ukuran Seorang penambang masih memiliki kemampuan untuk mengisi satu blok penuh dengan transaksi tanpa biaya miliknya hingga maksimum ukuran \(2 \cdot M_b\). Meskipun hanya mayoritas penambang yang dapat menggeser nilai median, masih ada a 13 25 Dengan mengubah skala waktu sehingga satu satuan waktu menjadi N blok, ukuran rata-rata blok, secara teoritis, masih dapat tumbuh secara eksponensial secara proporsional hingga 2ˆt. Di sisi lain, batasan yang lebih umum di blok berikutnya adalah M_nf(M_n) untuk beberapa fungsi f. Sifat f apa yang akan dimilikinya kita memilih untuk menjamin "pertumbuhan yang wajar" dalam ukuran blok? Kemajuan dari ukuran blok (setelah waktu penskalaan ulang) akan menjadi seperti ini: 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( ... Dan tujuannya di sini adalah untuk memilih f sehingga barisan ini tumbuh tidak lebih cepat dari, katakanlah, secara linear, atau mungkin bahkan sebagai Log(t). Tentu saja, jika f(M_n) = a untuk suatu konstanta a, barisan ini adalah sebenarnya M_n aM_n aˆ2M_n aˆ3M_n ... Dan, tentu saja, satu-satunya cara untuk membatasi pertumbuhan linear maksimal adalah dengan memilih a=1. Tentu saja hal ini tidak mungkin dilakukan. Itu tidak memungkinkan pertumbuhan sama sekali. Sebaliknya, jika f(M_n) adalah fungsi non-konstanta, maka situasinya jauh lebih buruk. rumit dan memungkinkan solusi yang elegan. Saya akan memikirkan hal ini sebentar. Biaya ini harus cukup besar untuk mendiskon penalti kelebihan ukuran dari bagian berikutnya. Kenapa pengguna umum diasumsikan laki-laki ya? Hah?

kemungkinan untuk mengasapi blockchain dan menghasilkan beban tambahan pada node. Untuk mencegah peserta jahat dari pembuatan blok besar kami memperkenalkan fungsi penalti: Hadiah Baru = Hadiah Dasar \(\cdot\) Ukuran Blk jamak −1 2 Aturan ini diterapkan hanya ketika BlkSize lebih besar dari ukuran blok bebas minimal yang seharusnya mendekati maksimal (10kb, \(M_N \cdot 110\%\)). Penambang diizinkan membuat blok dengan “ukuran biasa” dan genap melampauinya dengan keuntungan ketika biaya keseluruhan melebihi denda. Namun biayanya kemungkinan tidak akan meningkat kuadratik berbeda dengan nilai penalti sehingga akan terjadi keseimbangan. 6.3 Skrip transaksi CryptoNote memiliki subsistem skrip yang sangat minimalis. Pengirim menentukan ekspresi Φ = f (x1, x2, . . . , xn), dimana n adalah jumlah kunci publik tujuan {Pi}n saya=1. Hanya lima biner operator yang didukung: min, max, sum, mul dan cmp. Ketika penerima membelanjakan pembayaran ini, dia menghasilkan \(0 \leq k \leq n\) tanda tangan dan meneruskannya ke input transaksi. Proses verifikasi cukup evaluasi Φ dengan xi = 1 untuk memeriksa tanda tangan yang valid untuk kunci publik Pi, dan xi = 0. Verifier menerima bukti iﬀΦ > 0. Meskipun sederhana, pendekatan ini mencakup setiap kasus yang mungkin terjadi: • Tanda tangan Multi-/Ambang Batas. Untuk multi-tanda tangan “M-out-of-N” gaya Bitcoin (yaitu penerima harus memberikan setidaknya \(0 \leq M \leq N\) tanda tangan yang sah) Φ = x1+x2+. . .+xN \(\geq M\) (untuk kejelasan kami menggunakan notasi aljabar umum). Tanda tangan ambang batas tertimbang (beberapa kunci mungkin lebih penting dari yang lain) dapat dinyatakan sebagai Φ = \(w_1 \cdot x_1\) + \(w_2 \cdot x_2\) + . . . + \(w_N \cdot x_N\) \(\geq wM\). Dan skenario di mana kunci utama berhubungan dengan Φ = maks(\(M \cdot x\), x1 + x2 + . . . + xN) \(\geq M\). Mudah untuk menunjukkan bahwa kasus secanggih apa pun bisa terjadi dinyatakan dengan operator-operator ini, yaitu mereka membentuk basis. • Perlindungan kata sandi. Kepemilikan kata sandi rahasia setara dengan pengetahuan kunci pribadi, yang secara deterministik diturunkan dari kata sandi: k = KDF(s). Oleh karena itu, penerima dapat membuktikan bahwa dia mengetahui kata sandinya dengan memberikan tanda tangan lain di bawah kunci k. Pengirim cukup menambahkan kunci publik yang sesuai ke keluarannya sendiri. Perhatikan bahwa ini metode ini jauh lebih aman daripada “teka-teki transaksi” yang digunakan di Bitcoin [13], di mana kata sandi secara eksplisit diteruskan dalam input. • Kasus-kasus yang merosot. Φ = 1 berarti siapa pun dapat membelanjakan uangnya; Φ = 0 menandai output sebagai tidak dapat dibelanjakan selamanya. Jika skrip keluaran yang digabungkan dengan kunci publik terlalu besar untuk pengirim, dia dapat menggunakan tipe keluaran khusus, yang menunjukkan bahwa penerima akan memasukkan data ini ke dalam masukannya sedangkan pengirim hanya memberikan hash saja. Pendekatan ini mirip dengan “bayar-ke-hash” Bitcoin fitur, tapi alih-alih menambahkan perintah skrip baru, kami menangani kasus ini di struktur data tingkat. 7 Kesimpulan Kami telah menyelidiki kelemahan utama di Bitcoin dan mengusulkan beberapa kemungkinan solusi. Fitur-fitur bermanfaat ini dan pengembangan berkelanjutan kami menjadikan sistem uang elektronik baru CryptoNote saingan serius bagi Bitcoin, mengungguli semua cabangnya. 14 kemungkinan untuk mengasapi blockchain dan menghasilkan beban tambahan pada node. Untuk mencegah peserta jahat dari pembuatan blok besar kami memperkenalkan fungsi penalti: Hadiah Baru = Hadiah Dasar \(\cdot\) Ukuran Blk jamak −1 2 Aturan ini diterapkan hanya ketika BlkSize lebih besar dari ukuran blok bebas minimal yang seharusnya mendekati maksimal (10kb, \(M_N \cdot 110\%\)). Penambang diizinkan membuat blok dengan “ukuran biasa” dan genap melampauinya dengan keuntungan ketika biaya keseluruhan melebihi denda. Namun biayanya kemungkinan tidak akan meningkat kuadratik berbeda dengan nilai penalti sehingga akan terjadi keseimbangan. 6.3 Skrip transaksi CryptoNote memiliki subsistem skrip yang sangat minimalis. Pengirim menentukan ekspresi Φ = f (x1, x2, . . . , xn), dimana n adalah jumlah kunci publik tujuan {Pi}n saya=1. Hanya lima biner operator yang didukung: min, max, sum, mul dan cmp. Ketika penerima membelanjakan pembayaran ini, dia menghasilkan \(0 \leq k \leq n\) tanda tangan dan meneruskannya ke input transaksi. Proses verifikasi cukup evaluasi Φ dengan xi = 1 untuk memeriksa tanda tangan yang valid untuk kunci publik Pi, dan xi = 0. Verifier menerima bukti iﬀΦ > 0. Meskipun sederhana, pendekatan ini mencakup setiap kasus yang mungkin terjadi: • Tanda tangan Multi-/Ambang Batas. Untuk multi-tanda tangan “M-out-of-N” gaya Bitcoin (yaitu penerima harus memberikan setidaknya \(0 \leq M \leq N\) tanda tangan yang sah) Φ = x1+x2+. . .+xN \(\geq M\) (untuk kejelasan kami menggunakan notasi aljabar umum). Tanda tangan ambang batas tertimbang (beberapa kunci mungkin lebih penting dari yang lain) dapat dinyatakan sebagai Φ = \(w_1 \cdot x_1\) + \(w_2 \cdot x_2\) + . . . + \(w_N \cdot x_N\) \(\geq wM\). Dan skenarioio dimana kunci utama berhubungan dengan Φ = maks(\(M \cdot x\), x1 + x2 + . . . + xN) \(\geq M\). Mudah untuk menunjukkan bahwa kasus secanggih apa pun bisa terjadi dinyatakan dengan operator-operator ini, yaitu mereka membentuk basis. • Perlindungan kata sandi. Kepemilikan kata sandi rahasia setara dengan pengetahuan kunci pribadi, yang secara deterministik diturunkan dari kata sandi: k = KDF(s). Oleh karena itu, penerima dapat membuktikan bahwa dia mengetahui kata sandinya dengan memberikan tanda tangan lain di bawah kunci k. Pengirim cukup menambahkan kunci publik yang sesuai ke keluarannya sendiri. Perhatikan bahwa ini metode ini jauh lebih aman daripada “teka-teki transaksi” yang digunakan di Bitcoin [13], di mana kata sandi secara eksplisit diteruskan dalam input. • Kasus-kasus yang merosot. Φ = 1 berarti siapa pun dapat membelanjakan uangnya; Φ = 0 menandai output sebagai tidak dapat dibelanjakan selamanya. Jika skrip keluaran yang digabungkan dengan kunci publik terlalu besar untuk pengirim, dia dapat menggunakan tipe keluaran khusus, yang menunjukkan bahwa penerima akan memasukkan data ini ke dalam masukannya sedangkan pengirim hanya memberikan hash saja. Pendekatan ini mirip dengan “bayar-untuk-hash” dari Bitcoin fitur, tapi alih-alih menambahkan perintah skrip baru, kami menangani kasus ini di struktur data tingkat. 7 Kesimpulan Kami telah menyelidiki kelemahan utama di Bitcoin dan mengusulkan beberapa kemungkinan solusi. Fitur-fitur bermanfaat ini dan pengembangan berkelanjutan kami menjadikan sistem uang elektronik baru CryptoNote saingan serius bagi Bitcoin, mengungguli semua cabangnya. 14 26 Ini mungkin tidak diperlukan jika kita dapat menemukan cara untuk membatasi ukuran blok dari waktu ke waktu... Ini juga tidak mungkin benar. Mereka hanya menyetel "NewReward" ke parabola yang menghadap ke atas ukuran blok adalah variabel independen. Jadi pahala baru meledak hingga tak terhingga. Jika, di sisi lain di sisi lain, hadiah barunya adalah Maks(0,Hadiah Dasar(1-(BlkSize/Mn - 1)ˆ2)), lalu hadiah baru akan menjadi parabola menghadap ke bawah dengan puncak pada ukuran blok = Mn, dan dengan titik potong pada Ukuran Blok = 0 dan Ukuran Blok = 2Mn. Dan sepertinya itulah yang ingin mereka gambarkan. Namun, hal ini tidak terjadi

Analysis

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

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

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

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

Analisa

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

5 Hal ini tidak terlalu menjadi masalah ketika satu miliar orang di dunia hidup dengan pendapatan kurang dari satu dolar per tahun hari dan tidak punya harapan untuk berpartisipasi dalam jaringan penambangan apa pun... kecuali jaringan ekonomi dunia yang digerakkan oleh sistem mata uang p2p dengan satu cpu-satu suara, mungkin akan lebih baik lagi lebih adil daripada sistem yang didorong oleh perbankan cadangan fraksional. Namun protokol Cryptonote masih membutuhkan 51% pengguna yang jujur... lihat, misalnya, Cryptonote forum di mana salah satu pengembangnya, Pliskov, mengatakan bahwa serangan tradisional replace-the-data-on-theblockchain 51% masih bisa berhasil. https://forum.cryptonote.org/viewtopic.php?f=2&t=198 Perhatikan bahwa Anda tidak terlalu membutuhkan 51% pengguna yang jujur. Anda hanya benar-benar membutuhkan "tidak ada satu pun orang yang tidak jujur faksi dengan lebih dari 51% kekuatan jaringan." Sebut saja masalah bitcoin ini sebagai "kekakuan adaptif". Solusi Cryptonote untuk adaptif kekakuan adalah fleksibilitas adaptif dalam nilai parameter protokol. Jika Anda membutuhkan ukuran blok yang lebih besar, tidak masalah, jaringan akan menyesuaikan secara perlahan sepanjang waktu. Artinya, cara Bitcoin menyesuaikan kesulitan dari waktu ke waktu dapat direplikasi di seluruh protokol kami parameter sehingga konsensus jaringan tidak perlu diperoleh untuk memperbarui protokol. Di permukaan, ini sepertinya ide yang bagus, tapi tanpa pemikiran yang matang, itu hanya penyesuaian diri sistem bisa menjadi sangat tidak terduga dan kacau. Kami akan membahasnya lebih lanjut nanti sebagai peluang muncul. Sistem yang "baik" berada di antara sistem adaptif kaku dan adaptif fleksibel, dan bahkan mungkin kekakuan itu sendiri bersifat adaptif. Jika kita benar-benar memiliki "satu CPU-satu suara", maka berkolaborasi dan mengembangkan kumpulan akan mencapai 51% akan lebih sulit. Kami berharap setiap CPU di dunia menambang, dari ponsel ke CPU terpasang di Tesla Anda saat sedang diisi dayanya. http://en.wikipedia.org/wiki/Pareto_principle Saya menyatakan bahwa keseimbangan Pareto tidak dapat dihindari. 20% dari sistem akan melakukannya memiliki 80% CPU, atau 20% sistem akan memiliki 80% ASIC. Saya berhipotesis demikian karena distribusi kekayaan yang mendasari masyarakat sudah menunjukkan distribusi Pareto, dan ketika para penambang baru bergabung, mereka diambil dari distribusi yang mendasarinya. Namun, saya berpendapat bahwa protokol dengan satu-cpu-satu-suara akan melihat ROI pada perangkat keras. Blokir imbalan per node akan lebih berbanding lurus dengan jumlah node dalam jaringan karena distribusi kinerja di seluruh node akan jauh lebih ketat. Bitcoin, di sisi lain di sisi lain, melihat imbalan blok (per node) lebih sebanding dengan kapasitas komputasinya simpul. Artinya, hanya “anak-anak besar” yang masih terlibat dalam penambangan. Di sisi lain, meskipun prinsip Pareto akan tetap berlaku, di dunia satu cpu-satu suara, semua orang berpartisipasi dalam keamanan jaringan dan memperoleh sedikit pendapatan penambangan. Di dunia ASIC, tidak masuk akal untuk memasang setiap XBox dan ponsel milik saya. Di dunia onecpu-one-vote, sangat masuk akal dalam hal imbalan penambangan. Sebagai konsekuensi yang menggembirakan, memperoleh 51% suara lebih sulit ketika ada lebih banyak suara, menghasilkan hasil yang bagus manfaat untuk keamanan jaringan..perangkat keras yang dijelaskan sebelumnya. Misalkan tingkat hash global menurun secara signifikan, bahkan untuk sebentar, dia sekarang dapat menggunakan kekuatan penambangannya untuk membuat rantai bercabang dan melakukan pembelanjaan ganda. Seperti yang akan kita lihat nanti di artikel ini, kemungkinan besar peristiwa yang dijelaskan sebelumnya akan terjadi. 2.3 Emisi tidak teratur Bitcoin memiliki tingkat emisi yang telah ditentukan: setiap blok yang dipecahkan menghasilkan sejumlah koin yang tetap. Kira-kira setiap empat tahun, imbalan ini dikurangi setengahnya. Niat awalnya adalah untuk membuat a emisi halus terbatas dengan peluruhan eksponensial, namun kenyataannya kita memiliki emisi linier sepotong-sepotong fungsi yang breakpointnya dapat menyebabkan masalah pada infrastruktur Bitcoin. Ketika breakpoint terjadi, penambang mulai menerima hanya setengah dari nilai sebelumnya hadiah. Perbedaan absolut antara 12,5 dan 6,25 BTC (diproyeksikan untuk tahun 2020) mungkin tampaknya dapat ditoleransi. Namun, ketika memeriksa penurunan 50 hingga 25 BTC yang terjadi pada bulan November 28 Tahun 2012, dirasa tidak pantas untuk sejumlah besar anggota komunitas pertambangan. Gambar Gambar 1 menunjukkan penurunan drastis pada tingkat hash jaringan pada akhir bulan November, tepatnya ketika separuh terjadi. Peristiwa ini bisa saja menjadi momen yang tepat bagi individu jahat tersebut dijelaskan di bagian fungsi proof-of-work untuk melakukan serangan pembelanjaan ganda [36]. Gambar 1. Bitcoin hashbagan tarif (sumber: http://bitcoin.sipa.be) 2.4 Konstanta yang dikodekan secara keras Bitcoin memiliki banyak batasan yang dikodekan secara permanen, yang beberapa di antaranya merupakan elemen alami dari desain aslinya (mis. frekuensi blok, jumlah maksimum uang beredar, jumlah konfirmasi) sedangkan lainnya tampaknya merupakan kendala buatan. Yang penting bukanlah batasannya, melainkan ketidakmampuan untuk berubah dengan cepat 3 perangkat keras yang dijelaskan sebelumnya. Misalkan tingkat hash global menurun secara signifikan, bahkan untuk sebentar, dia sekarang dapat menggunakan kekuatan penambangannya untuk membuat rantai bercabang dan melakukan pembelanjaan ganda. Seperti yang akan kita lihat nanti di artikel ini, kemungkinan besar peristiwa yang dijelaskan sebelumnya akan terjadi. 2.3 Emisi tidak teratur Bitcoin memiliki tingkat emisi yang telah ditentukan: setiap blok yang dipecahkan menghasilkan sejumlah koin yang tetap. Kira-kira setiap empat tahun, imbalan ini dikurangi setengahnya. Niat awalnya adalah untuk membuat a emisi halus terbatas dengan peluruhan eksponensial, namun kenyataannya kita memiliki emisi linier sepotong-sepotong fungsi yang breakpointnya dapat menyebabkan masalah pada infrastruktur Bitcoin. Ketika breakpoint terjadi, penambang mulai menerima hanya setengah dari nilai sebelumnya hadiah. Perbedaan absolut antara 12,5 dan 6,25 BTC (diproyeksikan untuk tahun 2020) mungkin tampaknya dapat ditoleransi. Namun, ketika memeriksa penurunan 50 hingga 25 BTC yang terjadi pada bulan November 28 Tahun 2012, dirasa tidak pantas untuk sejumlah besar anggota komunitas pertambangan. Gambar Gambar 1 menunjukkan penurunan drastis pada tingkat hashjaringan pada akhir bulan November, tepatnya ketika separuh terjadi. Peristiwa ini bisa saja menjadi momen yang tepat bagi individu jahat tersebut dijelaskan di bagian fungsi proof-of-work untuk melakukan serangan pembelanjaan ganda [36]. Gambar 1. Bitcoin hashbagan tarif (sumber: http://bitcoin.sipa.be) 2.4 Konstanta yang dikodekan secara keras Bitcoin memiliki banyak batasan yang dikodekan secara keras, yang beberapa di antaranya merupakan elemen alami dari desain aslinya (mis. frekuensi blok, jumlah maksimum uang beredar, jumlah konfirmasi) sedangkan lainnya tampaknya merupakan kendala buatan. Yang penting bukanlah batasannya, melainkan ketidakmampuan untuk berubah dengan cepat 3 6 Sebut saja ini, serangan zombie. Mari kita bahas bagaimana emisi berkelanjutan bisa terjadi terkait dengan satu-cpu-satu-suara dalam skenario serangan zombie. Di dunia satu-cpu-satu-suara, setiap ponsel dan mobil, kapan pun tidak digunakan, akan ditambang. Mengumpulkan banyak perangkat keras murah untuk membuat pertambangan akan sangat mudah, karena sederhana tentang segala sesuatu memiliki CPU di dalamnya. Di sisi lain, pada saat itu, jumlah CPU diperlukan untuk melancarkan serangan 51% akan cukup mencengangkan, menurutku. Selain itu, justru karena mengumpulkan perangkat keras yang murah akan mudah, kita dapat mengharapkan a banyak orang mulai menimbun apa pun dengan CPU. Perlombaan senjata di dunia satu cpu-satu suara tentu lebih egaliter dibandingkan di dunia ASIC. Oleh karena itu, diskontinuitas dalam jaringan keamanan karena tingkat emisi seharusnya KURANG menjadi masalah di dunia satu-cpu-satu-suara. Namun, masih ada dua fakta yang tersisa: 1) diskontinuitas laju emisi dapat menyebabkan dampak yang menghambat ekonomi dan keamanan jaringan keduanya, yang buruk, dan 2) meskipun serangan 51%. dilakukan oleh seseorang yang mengumpulkan perangkat keras murah masih bisa terjadi dalam satu-cpu-satu-pilih dunia, sepertinya itu harusnya lebih sulit. Agaknya, perlindungan terhadap hal ini adalah semua pelaku yang tidak jujur akan mencoba hal ini secara bersamaan, dan kita kembali ke gagasan keamanan Bitcoin sebelumnya: "kita tidak memerlukan tindakan tidak jujur faksi untuk mengendalikan lebih dari 51% jaringan." Penulis mengklaim di sini bahwa satu masalah dengan bitcoin adalah diskontinuitas emisi koin Tingkat ini dapat menyebabkan penurunan tiba-tiba dalam partisipasi jaringan, dan karenanya keamanan jaringan. Jadi, tingkat emisi koin yang berkelanjutan, dapat dibedakan, dan mulus lebih disukai. Penulisnya tidak salah. Penurunan partisipasi jaringan secara tiba-tiba dapat terjadi menyebabkan masalah seperti itu, dan jika kita dapat menghilangkan salah satu sumbernya, kita harus melakukannya. Karena itu, itu benar mungkin saja emisi koin yang "relatif konstan" dalam jangka waktu lama diselingi oleh perubahan yang tiba-tiba adalah cara ideal untuk melangkah dari sudut pandang ekonomi. Saya bukan seorang ekonom. Jadi, mungkin kita harus memutuskan apakah kita akan menukar keamanan jaringan dengan sesuatu yang ekonomis-apa yang ada di sini? http://arxiv.org/abs/1402.2009mereka jika perlu yang menyebabkan kelemahan utama. Sayangnya, sulit untuk memprediksi kapan hal tersebut akan terjadi konstanta mungkin perlu diubah dan menggantinya dapat menimbulkan konsekuensi yang buruk. Contoh bagus dari perubahan batas hardcode yang menyebabkan konsekuensi bencana adalah pemblokiran batas ukuran disetel ke 250kb1. Batas ini cukup untuk menampung sekitar 10.000 transaksi standar. Di awal tahun 2013, batas tersebut hampir tercapai dan tercapai kesepakatan untuk meningkatkannya batas. Perubahan tersebut diterapkan pada dompet versi 0.8 dan diakhiri dengan pemisahan rantai 24 blok dan serangan pembelanjaan ganda yang berhasil [9]. Meskipun bugnya bukan pada protokol Bitcoin, tapi melainkan di mesin database, hal itu bisa dengan mudah ditangkap dengan stress test sederhana jika ada tidak ada batasan ukuran blok yang diperkenalkan secara artifisial. Konstanta juga berperan sebagai bentuk titik sentralisasi. Meskipun bersifat peer-to-peer Bitcoin, sebagian besar node menggunakan klien referensi resmi [10] yang dikembangkan oleh sekelompok kecil orang. Kelompok ini membuat keputusan untuk menerapkan perubahan pada protokol dan kebanyakan orang menerima perubahan ini terlepas dari “kebenarannya”. Beberapa keputusan menyebabkan diskusi yang memanas bahkan seruan boikot [11], yang menandakan bahwa komunitas dan pengembang mungkin tidak setuju pada beberapa poin penting. Oleh karena itu tampaknya logis untuk memiliki protokol dengan variabel yang dapat dikonfigurasi pengguna dan dapat disesuaikan sendiri sebagai cara yang mungkin untuk menghindari masalah ini. 2.5 Skrip besar Sistem skrip di Bitcoin adalah fitur yang berat dan kompleks. Ini berpotensi memungkinkan seseorang untuk berkreasi transaksi canggih [12], namun beberapa fiturnya dinonaktifkan karena masalah keamanan dan bahkan ada yang belum pernah dipakai [13]. Naskah (termasuk bagian pengirim dan penerima) untuk transaksi terpopuler di Bitcoin tampilannya seperti ini: OP DUP OP HASH160 OP SAMAKAN VERIFIKASI OP CHECKSIG. Skrip ini panjangnya 164 byte sedangkan tujuan satu-satunya adalah untuk memeriksa apakah penerima memilikinya kunci rahasia diperlukan untuk memverifikasi tanda tangannya.