From 69e851b21611154d253e3d9d772160b709f3bc7d Mon Sep 17 00:00:00 2001 From: Jorge Maldonado Ventura Date: Sun, 16 Oct 2022 22:41:50 +0200 Subject: [PATCH 1/5] =?UTF-8?q?A=C3=B1ade=20carpeta=20base=20para=20traduc?= =?UTF-8?q?ir=20al=20espa=C3=B1ol?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- translations/es/back/references.bib | 1393 +++++++++++++++++ translations/es/content/Monero.tex | 40 + translations/es/content/Transactions.tex | 165 ++ translations/es/content/addresses.tex | 165 ++ translations/es/content/advancedSchnorr.tex | 400 +++++ translations/es/content/appendix.tex | 360 +++++ translations/es/content/basicConcepts.tex | 519 ++++++ translations/es/content/blockchain.tex | 487 ++++++ translations/es/content/bulletproofs.tex | 136 ++ translations/es/content/commitments.tex | 119 ++ translations/es/content/escrowedMarket.tex | 205 +++ translations/es/content/introduction.tex | 115 ++ translations/es/content/multisig.tex | 636 ++++++++ translations/es/content/txKnowledgeProofs.tex | 314 ++++ translations/es/content/txTangle.tex | 124 ++ translations/es/front/abstract.tex | 14 + .../es/front/figures/monero-symbol-1280.png | Bin 0 -> 22645 bytes translations/es/main.tex | 256 +++ 18 files changed, 5448 insertions(+) create mode 100755 translations/es/back/references.bib create mode 100755 translations/es/content/Monero.tex create mode 100755 translations/es/content/Transactions.tex create mode 100755 translations/es/content/addresses.tex create mode 100755 translations/es/content/advancedSchnorr.tex create mode 100755 translations/es/content/appendix.tex create mode 100755 translations/es/content/basicConcepts.tex create mode 100755 translations/es/content/blockchain.tex create mode 100755 translations/es/content/bulletproofs.tex create mode 100755 translations/es/content/commitments.tex create mode 100755 translations/es/content/escrowedMarket.tex create mode 100755 translations/es/content/introduction.tex create mode 100755 translations/es/content/multisig.tex create mode 100755 translations/es/content/txKnowledgeProofs.tex create mode 100755 translations/es/content/txTangle.tex create mode 100755 translations/es/front/abstract.tex create mode 100755 translations/es/front/figures/monero-symbol-1280.png create mode 100755 translations/es/main.tex diff --git a/translations/es/back/references.bib b/translations/es/back/references.bib new file mode 100755 index 0000000..02d65c3 --- /dev/null +++ b/translations/es/back/references.bib @@ -0,0 +1,1393 @@ +%NOTE: title capitalization was achieved with {Brackets around entire titles}, a lazy method that has no respect for all the different citation styles out there; copy at your own risk + +@book{Hankerson:2003:GEC:940321, + author = {Hankerson, Darrel and Menezes, Alfred J. and Vanstone, Scott}, + title = {{Guide to Elliptic Curve Cryptography}}, + year = {2003}, + isbn = {038795273X}, + publisher = {Springer-Verlag New York, Inc.}, + address = {Secaucus, NJ, USA}, + url = {\url{http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.394.3037&rep=rep1&type=pdf} [Online; accessed 03/04/2020]} +} + +@Inbook{Bernstein2008, + author="Bernstein, Daniel J. + and Birkner, Peter + and Joye, Marc + and Lange, Tanja + and Peters, Christiane", + editor="Vaudenay, Serge", + title="{Twisted Edwards Curves}", + bookTitle="Progress in Cryptology -- AFRICACRYPT 2008: First International Conference on Cryptology in Africa, Casablanca, Morocco, June 11-14, 2008. Proceedings", + year="2008", + publisher="Springer Berlin Heidelberg", + address="Berlin, Heidelberg", + pages="389--405", + abstract="This paper introduces ``twisted Edwards curves,'' a generalization of the recently introduced Edwards curves; shows that twisted Edwards curves include more curves over finite fields, and in particular every elliptic curve in Montgomery form; shows how to cover even more curves via isogenies; presents fast explicit formulas for twisted Edwards curves in projective and inverted coordinates; and shows that twisted Edwards curves save time for many curves that were already expressible as Edwards curves.", + isbn="978-3-540-68164-9", + doi="10.1007/978-3-540-68164-9_26", + url="https://doi.org/10.1007/978-3-540-68164-9_26", + note = {\url{https://eprint.iacr.org/2008/013.pdf} [Online; accessed 02/13/2020]}, +} + +%duplicate +@misc{cryptoeprint:2007:286, + author = {Daniel J. Bernstein and Tanja Lange}, + title = {Faster addition and doubling on elliptic curves}, + howpublished = {Cryptology ePrint Archive, Report 2007/286}, + year = {2007}, + note = {\url{https://eprint.iacr.org/2007/286.pdf} [Online; accessed 03/04/2020]}, +} + +@misc{rfc8032, + series = {Request for Comments}, + number = 8032, + howpublished = {RFC 8032}, + publisher = {RFC Editor}, + doi = {10.17487/RFC8032}, + url = {https://rfc-editor.org/rfc/rfc8032.txt}, + author = {Simon Josefsson and Ilari Liusvaara}, + title = {{Edwards-Curve Digital Signature Algorithm (EdDSA)}}, + pagetotal = 60, + year = 2017, + month = jan, + abstract = {This document describes elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA). The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves. An example implementation and test vectors are provided.}, + note = {\url{https://rfc-editor.org/rfc/rfc8032.txt} [Online; accessed 03/04/2020]} +} + +@article{hales2014nsa, + title={The {NSA} back door to {NIST}}, + author={Hales, Thomas C}, + journal={Notices of the AMS}, + volume={61}, + number={2}, + pages={190--192}, + note = {\url{https://www.ams.org/notices/201402/rnoti-p190.pdf} [Online; accessed 03/04/2020]} +} + +@article{cryptoNoteWhitePaper, + title={{CryptoNote V2.0}}, + author={van Saberhagen, Nicolas}, + note = {\url{https://cryptonote.org/whitepaper.pdf} [Online; accessed 04/04/2018]} +} + +%duplicate mrl0005 +@misc{cryptoeprint:2015:1098, + author = {Shen Noether}, + title = {{Ring Signature Confidential Transactions for Monero}}, + howpublished = {Cryptology ePrint Archive, Report 2015/1098}, + year = {2015}, + note = {\url{http://eprint.iacr.org/2015/1098} [Online; accessed 04/04/2018]}, +} + +@misc{AdamBack-ring-efficiency, + author = {Adam Back}, + title = {{Ring signature efficiency}}, + howpublished = {BitcoinTalk}, + year = {2015}, + note = {\url{https://bitcointalk.org/index.php?topic=972541.msg10619684#msg10619684} [Online; accessed 04/04/2018]}, +} + +@misc{CryptoNight, + author = {Seigen and Max Jameson and Tuomo Nieminen and Neocortex and Antonio M. Juarez}, + title = {{CryptoNight Hash Function}}, + howpublished = {CryptoNote}, + year = {2013}, + month = {March}, + note = {\url{https://cryptonote.org/cns/cns008.txt} [Online; accessed 04/04/2018]}, +} + +@Inbook{Liu2004, + author="Liu, Joseph K. + and Wei, Victor K. + and Wong, Duncan S.", + editor="Wang, Huaxiong + and Pieprzyk, Josef + and Varadharajan, Vijay", + title="Linkable Spontaneous Anonymous Group Signature for Ad Hoc Groups", + bookTitle="Information Security and Privacy: 9th Australasian Conference, ACISP 2004, Sydney, Australia, July 13-15, 2004. Proceedings", + year="2004", + publisher="Springer Berlin Heidelberg", + address="Berlin, Heidelberg", + pages="325--335", + abstract="We present a linkable spontaneously anonymous group (LSAG) signature scheme (alternatively known as linkable ring signature scheme) satisfying the following three properties. (1) Anonymity, or signer indistinguishability. (2) Linkability: That two signatures by the same signer can be linked. (3) Spontaneity: No group secret, therefore no group manager or group secret sharing setup. We reduce the security of our scheme to well-known problems under the random oracle model. Using the scheme, we construct a new efficient one-round e-voting system which does not have a registration phase. We also present a new efficient reduction of famous rewind simulation lemma which only relies on elementary probability theory. Threshold extensions of our scheme are also presented.", + isbn="978-3-540-27800-9", + doi="10.1007/978-3-540-27800-9_28", + url="https://doi.org/10.1007/978-3-540-27800-9_28", + note = {\url{https://eprint.iacr.org/2004/027.pdf} [Online; accessed 03/04/2020]} +} + +@inproceedings{Chaum:1991:GS:1754868.1754897, + author = {Chaum, David and Van Heyst, Eug\`{e}ne}, + title = {{Group Signatures}}, + booktitle = {Proceedings of the 10th Annual International Conference on Theory and Application of Cryptographic Techniques}, + series = {EUROCRYPT'91}, + year = {1991}, + isbn = {3-540-54620-0}, + location = {Brighton, UK}, + pages = {257--265}, + numpages = {9}, + url = {http://dl.acm.org/citation.cfm?id=1754868.1754897}, + acmid = {1754897}, + publisher = {Springer-Verlag}, + address = {Berlin, Heidelberg}, + note = {\url{https://chaum.com/publications/Group_Signatures.pdf} [Online; accessed 03/04/2020]} +} + +@Inbook{Bernstein2007, + author="Bernstein, Daniel J. + and Lange, Tanja", + editor="Kurosawa, Kaoru", + title="Faster Addition and Doubling on Elliptic Curves", + bookTitle="Advances in Cryptology -- ASIACRYPT 2007: 13th International Conference on the Theory and Application of Cryptology and Information Security, Kuching, Malaysia, December 2-6, 2007. Proceedings", + year="2007", + publisher="Springer Berlin Heidelberg", + address="Berlin, Heidelberg", + pages="29--50", + abstract="Edwards recently introduced a new normal form for elliptic curves. Every elliptic curve over a non-binary field is birationally equivalent to a curve in Edwards form over an extension of the field, and in many cases over the original field.", + isbn="978-3-540-76900-2", + doi="10.1007/978-3-540-76900-2_3", + note = {\url{https://eprint.iacr.org/2007/286.pdf} [Online; accessed 03/04/2020]}, +} + +@Inbook{Pedersen1992, + author="Pedersen, Torben Pryds", + editor="Feigenbaum, Joan", + title="Non-Interactive and Information-Theoretic Secure Verifiable Secret Sharing", + bookTitle="Advances in Cryptology --- CRYPTO '91: Proceedings", + year="1992", + publisher="Springer Berlin Heidelberg", + address="Berlin, Heidelberg", + pages="129--140", + abstract="It is shown how to distribute a secret to n persons such that each person can verify that he has received correct information about the secret without talking with other persons. Any k of these persons can later find the secret (1 ≤ k ≤ n), whereas fewer than k persons get no (Shannon) information about the secret. The information rate of the scheme is 1/2 and the distribution as well as the verification requires approximately 2k modular multiplications pr. bit of the secret. It is also shown how a number of persons can choose a secret ``in the well'' and distribute it verifiably among themselves.", + isbn="978-3-540-46766-3", + doi="10.1007/3-540-46766-1_9", + url="https://doi.org/10.1007/3-540-46766-1_9", + note = {\url{https://www.cs.cornell.edu/courses/cs754/2001fa/129.PDF} [Online; accessed 03/04/2020]} +} + +@inproceedings{Signatures2015BorromeanRS, + title={{Borromean Ring Signatures}}, + author={Gregory Maxwell and Andrew Poelstra}, + year={2015}, + note={\url{https://pdfs.semanticscholar.org/4160/470c7f6cf05ffc81a98e8fd67fb0c84836ea.pdf} [Online; accessed 04/04/2018]} +} + +%duplicate mrl0005 +@article{ledger34, + author = {Shen Noether and Adam Mackenzie and Monero Research Lab}, + title = {{Ring Confidential Transactions}}, + journal = {Ledger}, + volume = {1}, + number = {0}, + year = {2016}, + keywords = {}, + abstract = {This article introduces a method of hiding transaction amounts in the strongly decentralized anonymous cryptocurrency Monero. Similar to Bitcoin, Monero is a cryptocurrency which is distributed through a proof-of-work “mining” process having no central party or trusted setup. The original Monero protocol was based on CryptoNote, which uses ring signatures and one-time keys to hide the destination and origin of transactions. Recently the technique of using a commitment scheme to hide the amount of a transaction has been discussed and implemented by Bitcoin Core developer Gregory Maxwell. In this article, a new type of ring signature, A Multilayered Linkable Spontaneous Anonymous Group signature is described which allows one to include a Pedersen Commitment in a ring signature. This construction results in a digital currency with hidden amounts, origins and destinations of transactions with reasonable efficiency and verifiable, trustless coin generation. The author would like to note that early drafts of this were publicized in the Monero Community and on the #bitcoin-wizards IRC channel. Blockchain hashed drafts are available showing that this work was started in Summer 2015, and completed in early October 2015. An eprint is also available at http://eprint.iacr.org/2015/1098. }, + issn = {2379-5980}, pages = {1--18}, doi = {10.5195/ledger.2016.34}, + url = {https://www.ledgerjournal.org/ojs/index.php/ledger/article/view/34} +} + +@Inbook{Fujisaki2007, + author="Fujisaki, Eiichiro + and Suzuki, Koutarou", + editor="Okamoto, Tatsuaki + and Wang, Xiaoyun", + title="Traceable Ring Signature", + bookTitle="Public Key Cryptography -- PKC 2007: 10th International Conference on Practice and Theory in Public-Key Cryptography Beijing, China, April 16-20, 2007. Proceedings", + year="2007", + publisher="Springer Berlin Heidelberg", + address="Berlin, Heidelberg", + pages="181--200", + abstract="The ring signature allows a signer to leak secrets anonymously, without the risk of identity escrow. At the same time, the ring signature provides great flexibility: No group manager, no special setup, and the dynamics of group choice. The ring signature is, however, vulnerable to malicious or irresponsible signers in some applications, because of its anonymity. In this paper, we propose a traceable ring signature scheme. A traceable ring scheme is a ring signature except that it can restrict ``excessive'' anonymity. The traceable ring signature has a tag that consists of a list of ring members and an issue that refers to, for instance, a social affair or an election. A ring member can make any signed but anonymous opinion regarding the issue, but only once (per tag). If the member submits another signed opinion, possibly pretending to be another person who supports the first opinion, the identity of the member is immediately revealed. If the member submits the same opinion, for instance, voting ``yes'' regarding the same issue twice, everyone can see that these two are linked. The traceable ring signature can suit to many applications, such as an anonymous voting on a BBS. We formalize the security definitions for this primitive and show an efficient and simple construction in the random oracle model.", + isbn="978-3-540-71677-8", + doi="10.1007/978-3-540-71677-8_13", + url="https://doi.org/10.1007/978-3-540-71677-8_13", + note = {\url{https://link.springer.com/content/pdf/10.1007\%2F978-3-540-71677-8_13.pdf} [Online; accessed 03/04/2020]} +} + +@Article{Bernstein2012, + author="Bernstein, Daniel J. + and Duif, Niels + and Lange, Tanja + and Schwabe, Peter + and Yang, Bo-Yin", + title="{High-speed high-security signatures}", + journal="Journal of Cryptographic Engineering", + year="2012", + month="Sep", + day="01", + volume="2", + number="2", + pages="77--89", + abstract="This paper shows that a {\$}390 mass-market quad-core 2.4GHz Intel Westmere (Xeon E5620) CPU can create 109000 signatures per second and verify 71000 signatures per second on an elliptic curve at a 2128 security level. Public keys are 32 bytes, and signatures are 64 bytes. These performance figures include strong defenses against software side-channel attacks: there is no data flow from secret keys to array indices, and there is no data flow from secret keys to branch conditions.", + issn="2190-8516", + doi="10.1007/s13389-012-0027-1", + note = {\url{https://ed25519.cr.yp.to/ed25519-20110705.pdf} [Online; accessed 03/04/2020]}, +} + +@article{AnalysisOfLinkability, + author = {Andrew Miller and + Malte M{\"{o}}ser and + Kevin Lee and + Arvind Narayanan}, + title = {{An Empirical Analysis of Linkability in the Monero Blockchain}}, + journal = {CoRR}, + volume = {abs/1704.04299}, + year = {2017}, + url = {http://arxiv.org/abs/1704.04299}, + archivePrefix = {arXiv}, + eprint = {1704.04299}, + timestamp = {Mon, 03 Jul 2017 08:05:20 +0200}, + biburl = {http://dblp.org/rec/bib/journals/corr/MillerMLN17}, + bibsource = {dblp computer science bibliography, http://dblp.org}, + note = {\url{https://arxiv.org/pdf/1704.04299.pdf} [Online; accessed 03/04/2020} +} + +@misc{ReplyTo-AnalysisOfLinkability, + author = {Justin Ehrenhofer and Monero Community}, + title = {{An Unofficial Response to ``An Empirical Analysis of Linkability in the Monero Blockchain"}}, + howpublished = {CryptoNote}, + year = {2017}, + month = {April}, + note = {\url{https://getmonero.org/2017/04/19/an-unofficial-response-to-an-empirical-analysis-of-linkability.html} [Online; accessed 04/04/2018]}, +} + +@inproceedings{DBLP:conf/esorics/KumarFTS17, + author = {Amrit Kumar and + Cl{\'{e}}ment Fischer and + Shruti Tople and + Prateek Saxena}, + title = {{A Traceability Analysis of Monero's Blockchain}}, + booktitle = {Computer Security - {ESORICS} 2017 - 22nd European Symposium on Research + in Computer Security, Oslo, Norway, September 11-15, 2017, Proceedings, + Part {II}}, + pages = {153--173}, + year = {2017}, + crossref = {DBLP:conf/esorics/2017-2}, + url = {https://doi.org/10.1007/978-3-319-66399-9_9}, + doi = {10.1007/978-3-319-66399-9_9}, + timestamp = {Fri, 03 Nov 2017 06:13:45 +0100}, + biburl = {http://dblp.org/rec/bib/conf/esorics/KumarFTS17}, + bibsource = {dblp computer science bibliography, http://dblp.org} +} + +@misc{MRL-0001-chain-reactions, + author = {Surae Noether and Sarang Noether and Adam Mackenzie}, + title = {{A Note on Chain Reactions in Traceability in CryptoNote 2.0, MRL-0001}}, + howpublished = {CryptoNote}, + year = {2014}, + month = {September}, + note = {\url{https://web.getmonero.org/resources/research-lab/pubs/MRL-0001.pdf} [Online; accessed 04/04/2018]}, +} + +@misc{MRL-0004, + author = {Adam Mackenzie and Surae Noether and Monero Core Team}, + title = {{Improving Obfuscation in the CryptoNote Protocol, MRL-0004}}, + howpublished = {CryptoNote}, + year = {2015}, + month = {January}, + note = {\url{https://web.getmonero.org/resources/research-lab/pubs/MRL-0004.pdf} [Online; accessed 04/04/2018]}, +} + +@misc{ECC-patents, + author = {Alexander Klimov}, + title = {{{ECC} Patents?}}, + year = {2005}, + month = {October}, + note = {\url{http://article.gmane.org/gmane.comp.encryption.general/7522} [Online; accessed 04/04/2018]}, +} + +@article{DBLP:journals/corr/NarayananM17, + author = {Arvind Narayanan and + Malte M{\"{o}}ser}, + title = {{Obfuscation in Bitcoin: Techniques and Politics}}, + journal = {CoRR}, + volume = {abs/1706.05432}, + year = {2017}, + url = {http://arxiv.org/abs/1706.05432}, + archivePrefix = {arXiv}, + eprint = {1706.05432}, + timestamp = {Mon, 03 Jul 2017 13:29:02 +0200}, + biburl = {http://dblp.org/rec/bib/journals/corr/NarayananM17}, + bibsource = {dblp computer science bibliography, http://dblp.org}, + note = {\url{https://arxiv.org/ftp/arxiv/papers/1706/1706.05432.pdf} [Online; accessed 03/04/2020]} +} + +@misc{DK-police-tracing-btc, + author = {Karina Bj{\o}rnholdt}, + title = {{Dansk politi har knækket bitcoin-koden}}, + year = {2017}, + month = {May}, + note = {\url{http://www.dansk-politi.dk/artikler/2017/maj/dansk-politi-har-knaekket-bitcoin-koden} [Online; accessed 04/04/2018]}, +} + +@misc{Andrew-Cox-Sandia, + author = {Michael Padilla}, + title = {{Beating Bitcoin bad guys}}, + year = {2016}, + month = {August}, + note = {\url{http://www.sandia.gov/news/publications/labnews/articles/2016/19-08/bitcoin.html} [Online; accessed 04/04/2018]}, +} + +@article{DBLP:journals/corr/ShenTuY15b, + author = {QingChun ShenTu and + Jianping Yu}, + title = {{Research on Anonymization and De-anonymization in the Bitcoin System}}, + journal = {CoRR}, + volume = {abs/1510.07782}, + year = {2015}, + url = {http://arxiv.org/abs/1510.07782}, + archivePrefix = {arXiv}, + eprint = {1510.07782}, + timestamp = {Wed, 07 Jun 2017 14:41:56 +0200}, + biburl = {http://dblp.org/rec/bib/journals/corr/ShenTuY15b}, + bibsource = {dblp computer science bibliography, http://dblp.org}, + note = {\url{https://arxiv.org/ftp/arxiv/papers/1510/1510.07782.pdf} [Online; accessed 03/04/2020]} +} + +@misc{NSA-NIST, + author = {}, + title = {{Trust the math? An Update}}, + note = {\url{http://www.math.columbia.edu/~woit/wordpress/?p=6522} [Online; accessed 04/04/2018]}, +} + +@misc{rivest-leak-secret, + author = {Ronald L. Rivest and Adi Shamir and Yael Tauman}, + title = {{How to Leak a Secret}}, + howpublished = {C. Boyd (Ed.): ASIACRYPT 2001, LNCS 2248, pp. 552-565}, + year = {2001}, + note = {\url{https://people.csail.mit.edu/rivest/pubs/RST01.pdf} [Online; accessed 04/04/2018]}, +} + +@misc{maxwell-ct, + author = {Greg Maxwell}, + title = {{Confidential Transactions}}, + note = {\url{https://people.xiph.org/~greg/confidential_values.txt} [Online; accessed 04/04/2018]}, +} + +@misc{ecdsa, + author = {Don Johnson and Alfred Menezes}, + title = {{The Elliptic Curve Digital Signature Algorithm (ECDSA)}}, + howpublished = {Technical Report CORR 99-34, Dept. of C\&O, University of Waterloo, Canada}, + year = {1999}, + note = {\url{http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.472.9475&rep=rep1&type=pdf} [Online; accessed 04/04/2018]}, +} + +@misc{eddsa-irtf, + author = {S. Josefsson and SJD AB and I. Liusvaara}, + title = {{Edwards-Curve Digital Signature Algorithm (EdDSA)}}, + howpublished = {Internet Research Task Force (IRTF)}, + year = {2017}, + note = {\url{https://tools.ietf.org/html/rfc8032} [Online; accessed 05/11/2018]}, +} + +@misc{ASNL-issue, + title = {{Issue with proof of unforgeability of ASNL}}, + year = {2016}, + note = {\url{https://github.com/monero-project/research-lab/issues/4} [Online; accessed 04/04/2018]}, +} + +@misc{MRL-0006-subaddresses, + author = {Sarang Noether and Brandon Goodell}, + title = {{An efficient implementation of Monero subaddresses, MRL-0006}}, + year = {2017}, + month = {October}, + note = {\url{https://web.getmonero.org/resources/research-lab/pubs/MRL-0006.pdf} [Online; accessed 04/04/2018]}, +} + +@misc{key-image-bug, + author = {Riccardo ``fluffypony" Spagni and luigi1111}, + title = {{Disclosure of a Major Bug in Cryptonote Based Currencies}}, + year = {2017}, + month = {May}, + note = {\url{https://getmonero.org/2017/05/17/disclosure-of-a-major-bug-in-cryptonote-based-currencies.html} [Online; accessed 04/10/2018]}, +} + +@misc{wiki-modular-arithmetic, + title = {Modular arithmetic}, + note = {\url{https://en.wikipedia.org/wiki/Modular_arithmetic} [Online; accessed 04/16/2018]}, +} + +@misc{luigi-address, + title = {{Cryptonote Address Tests}}, + note = {\url{https://xmr.llcoins.net/addresstests.html} [Online; accessed 04/19/2018]}, +} + +@misc{integrated-addresses, + title = {How do payment ids work?}, + note = {\url{https://monero.stackexchange.com/questions/1910/how-do-payment-ids-work} [Online; accessed 04/21/2018]}, +} + +@misc{wolfram-xor, + title = {{XOR -- from Wolfram Mathworld}}, + note = {\url{http://mathworld.wolfram.com/XOR.html} [Online; accessed 04/21/2018]}, +} + +@misc{cryptographic-oracle, + title = {{cryptography - What is a cryptographic oracle?}}, + note = {\url{https://security.stackexchange.com/questions/10617/what-is-a-cryptographic-oracle} [Online; accessed 04/22/2018]}, +} + +@misc{deprecating-payment-ids, + title = {{DevMeeting 2018-05-06}}, + note = {\url{https://monerobase.com/wiki/DevMeeting_2018-05-06} [Online; accessed 05/06/2018]}, +} + +@article{SCOZZAFAVA1993313, + title = "{Uniform distribution and sum modulo m of independent random variables}", + journal = "Statistics \& Probability Letters", + volume = "18", + number = "4", + pages = "313 - 314", + year = "1993", + issn = "0167-7152", + doi = "https://doi.org/10.1016/0167-7152(93)90021-A", + url = "http://www.sciencedirect.com/science/article/pii/016771529390021A", + author = "Paola Scozzafava", + keywords = "Modulo , sum modulo , sum modulo of independent random variables, uniform distribution", + abstract = "If one of two independent random variables (possibly both) is uniformly distributed, then so is their sum modulo m; we show that the converse is true if m is a prime number and the relevant probabilities are rational numbers.", + note = {\url{https://sci-hub.tw/https://www.sciencedirect.com/science/article/abs/pii/016771529390021A} [Online; accessed 03/04/2020]} +} + +@inproceedings{Miller:point-compression-origin, + author = {Miller, Victor S}, + title = {{Use of Elliptic Curves in Cryptography}}, + booktitle = {Lecture Notes in Computer Sciences; 218 on Advances in cryptology---CRYPTO 85}, + year = {1986}, + isbn = {0-387-16463-4}, + location = {Santa Barbara, California, USA}, + pages = {417--426}, + numpages = {10}, + url = {http://dl.acm.org/citation.cfm?id=18262.25413}, + acmid = {25413}, + publisher = {Springer-Verlag}, + address = {Berlin, Heidelberg}, + note = {\url{https://link.springer.com/content/pdf/10.1007/3-540-39799-X_31.pdf} [Online; accessed 03/04/2020]} +} + +@misc{eddsa-ed25519-irtf, + author = {S. Josefsson and SJD AB and N. Moeller}, + title = {{EdDSA and Ed25519}}, + howpublished = {Internet Research Task Force (IRTF)}, + year = {2015}, + note = {\url{https://tools.ietf.org/html/draft-josefsson-eddsa-ed25519-03} [Online; accessed 05/11/2018]}, +} + +@article{maxwell2018simple-musig, + title = {{Simple Schnorr Multi-Signatures with Applications to Bitcoin}}, + author = {Maxwell, Gregory and Poelstra, Andrew and Seurin, Yannick and Wuille, Pieter}, + month = {May}, + year = {2018}, + note = {\url{https://eprint.iacr.org/2018/068.pdf} [Online; accessed 03/01/2020]}, +} + +@InProceedings{simple-zk-proof-maurer, + author="Maurer, Ueli", + editor="Preneel, Bart", + title="{Unifying Zero-Knowledge Proofs of Knowledge}", + booktitle="Progress in Cryptology -- AFRICACRYPT 2009", + year="2009", + publisher="Springer Berlin Heidelberg", + address="Berlin, Heidelberg", + pages="272--286", + abstract="We present a simple zero-knowledge proof of knowledge protocol of which many protocols in the literature are instantiations. These include Schnorr's protocol for proving knowledge of a discrete logarithm, the Fiat-Shamir and Guillou-Quisquater protocols for proving knowledge of a modular root, protocols for proving knowledge of representations (like Okamoto's protocol), protocols for proving equality of secret values, a protocol for proving the correctness of a Diffie-Hellman key, protocols for proving the multiplicative relation of three commitments (as required in secure multi-party computation), and protocols used in credential systems.", + isbn="978-3-642-02384-2", + note = {\url{https://www.crypto.ethz.ch/publications/files/Maurer09.pdf} [Online; accessed 03/04/2020]} +} + +@misc{tutorialspoint-cryptography, + title = {{Cryptography Tutorial}}, + note = {\url{https://www.tutorialspoint.com/cryptography/index.htm} [Online; accessed 05/19/2018]}, +} + +@misc{AES-encryption, + citeulike-article-id = {2470825}, + keywords = {bibtex-import}, + posted-at = {2008-03-05 09:38:14}, + title = {{Federal Information Processing Standards Publication ({FIPS} 197). {Advanced Encryption Standard (AES)}}}, + year = {2001}, + note = {\url{http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf} [Online; access 03/04/2020]}, +} + +@misc{Nakamoto_bitcoin, + author = {Satoshi Nakamoto}, + title = {{Bitcoin: A Peer-to-Peer Electronic Cash System}}, + year = {2008}, + note = {\url{http://bitcoin.org/bitcoin.pdf} [Online; accessed 03/04/2020]} +} + +@misc{cryptonight7, + title = {Monero Cryptonight variants, and add one for v7}, + note = {\url{https://github.com/monero-project/monero/pull/3253} [Online; accessed 05/23/2018]}, + year = {2018}, + month = {April} +} + +@misc{monero-history, + title = {Monero inception and history.}, + note = {\url{https://monero.stackexchange.com/questions/475/monero-inception-and-history-how-did-monero-get-started-what-are-its-origins-a/476#476} [Online; accessed 05/23/2018]}, +} + +@misc{monero-0.9.3, + title = {{Monero v0.9.3 - Hydrogen Helix - released!}}, + note = {\url{https://www.reddit.com/r/Monero/comments/4bgw4z/monero_v093_hydrogen_helix_released_urgent_and/} [Online; accessed 05/24/2018]}, +} + +@misc{monero-v5, + title = {{Add intervening v5 fork for increased min block size}}, + note = {\url{https://github.com/monero-project/monero/pull/1869} [Online; accessed 05/24/2018]}, +} + +@misc{monero-tail-emission, + title = {Tail emission}, + note = {\url{https://getmonero.org/resources/moneropedia/tail-emission.html} [Online; accessed 05/24/2018]}, +} + +@misc{bitmonero-launched, + author = {thankful\_for\_today}, + title = {{[ANN][BMR] Bitmonero - a new coin based on CryptoNote technology - LAUNCHED}}, + year = {2014}, + month = {April}, + day = {9}, + note = {Monero's actual launch date was April 18\nth, 2014. \url{https://bitcointalk.org/index.php?topic=563821.0} [Online; accessed 05/24/2018]}, +} + +@misc{dynamic-per-kb-fee, + title = {How does the dynamic fee calculation work?}, + note = {\url{https://monero.stackexchange.com/questions/2531/how-does-the-dynamic-fee-calculation-work} [Online; accessed 05/25/2018]}, +} + +@misc{monero-coin-emission, + title = {{Useful for learning about Monero coin emission}}, + note = {\url{https://www.reddit.com/r/Monero/comments/512kwh/useful_for_learning_about_monero_coin_emission/d78tpgi/} [Online; accessed 05/25/2018]}, +} + +@misc{transaction-lock, + title = {What is the block maturity value seen in many pool interfaces?}, + note = {\url{https://monero.stackexchange.com/questions/2251/what-is-the-block-maturity-value-seen-in-many-pool-interfaces} [Online; accessed 05/26/2018]}, +} + +@INPROCEEDINGS{merkle-tree, + author={R. C. Merkle}, + booktitle={1980 IEEE Symposium on Security and Privacy}, + title={{Protocols for Public Key Cryptosystems}}, + year={1980}, + volume={}, + number={}, + pages={122-122}, + keywords={Authentication;Contracts;Encryption;Protocols;Public key}, + doi={10.1109/SP.1980.10006}, + ISSN={1540-7993}, + month={April}, + note = {\url{http://www.merkle.com/papers/Protocols.pdf} [Online; accessed 03/04/2020]} +} + +@misc{MRL-0002-merkle-problem, + author = {Jan Macheta and Sarang Noether and Surae Noether and Javier Smooth}, + title = {{Counterfeiting via Merkle Tree Exploits within Virtual Currencies Employing the CryptoNote Protocol, MRL-0002}}, + year = {2014}, + month = {September}, + day = {12}, + note = {\url{https://web.getmonero.org/resources/research-lab/pubs/MRL-0002.pdf} [Online; accessed 05/27/2018]}, +} + +@misc{DAG-wikipedia, + title = {{Directed acyclic graph}}, + note = {\url{https://en.wikipedia.org/wiki/Directed_acyclic_graph} [Online; accessed 05/27/2018]}, +} + +@article{Diffie-Hellman, + author = {Diffie, W. and Hellman, M.}, + title = {{New Directions in Cryptography}}, + journal = {IEEE Trans. Inf. Theor.}, + issue_date = {November 1976}, + volume = {22}, + number = {6}, + month = sep, + year = {2006}, + issn = {0018-9448}, + pages = {644--654}, + numpages = {11}, + url = {http://dx.doi.org/10.1109/TIT.1976.1055638}, + doi = {10.1109/TIT.1976.1055638}, + acmid = {2269104}, + publisher = {IEEE Press}, + address = {Piscataway, NJ, USA}, + note = {\url{https://ee.stanford.edu/~hellman/publications/24.pdf} [Online; accessed 03/04/2020]} +} + +@InProceedings{schnorr-signatures, + author="Schnorr, C. P.", + editor="Brassard, Gilles", + title="{Efficient Identification and Signatures for Smart Cards}", + booktitle="Advances in Cryptology --- CRYPTO' 89 Proceedings", + year="1990", + publisher="Springer New York", + address="New York, NY", + pages="239--252", + abstract="We present an efficient interactive identification scheme and a related signature scheme that are based on discrete logarithms and which are particularly suited for smart cards. Previous cryptoschemes, based on the discrete logarithm, have been proposed by El Gamal (1985), Chaum, Evertse, Graaf (1988), Beth (1988) and G{\"u}nter (1989). The new scheme comprises the following novel features.", + isbn="978-0-387-34805-6", + note = {\url{https://link.springer.com/content/pdf/10.1007\%2F0-387-34805-0_22.pdf} [Online; accessed 03/04/2020]} +} + +@InProceedings{fiat-shamir-transform, + author="Fiat, Amos + and Shamir, Adi", + editor="Odlyzko, Andrew M.", + title="{How To Prove Yourself: Practical Solutions to Identification and Signature Problems}", + booktitle="Advances in Cryptology --- CRYPTO' 86", + year="1987", + publisher="Springer Berlin Heidelberg", + address="Berlin, Heidelberg", + pages="186--194", + abstract="In this paper we describe simple identification and signature schemes which enable any user to prove his identity and the authenticity of his messages to any other user without shared or public keys. The schemes are provably secure against any known or chosen message attack if factoring is difficult, and typical implementations require only 1{\%} to 4{\%} of the number of modular multiplications required by the RSA scheme. Due to their simplicity, security and speed, these schemes are ideally suited for microprocessor-based devices such as smart cards, personal computers, and remote control systems.", + isbn="978-3-540-47721-1", + note = {\url{https://link.springer.com/content/pdf/10.1007\%2F3-540-47721-7_12.pdf} [Online; accessed 03/04/2020]} +} + +@misc{nist-sha3, + title = {{NIST Releases SHA-3 Cryptographic Hash Standard}}, + year = {2015}, + month = {August}, + day = {5}, + note = {\url{https://www.nist.gov/news-events/news/2015/08/nist-releases-sha-3-cryptographic-hash-standard} [Online; accessed 06/02/2018]}, +} + +@misc{ringct-dates, + title = {{Ring CT; Moneropedia}}, + note = {\url{https://getmonero.org/resources/moneropedia/ringCT.html} [Online; accessed 06/05/2018]}, +} + +@misc{tx-extra-field, + author = {Albert Werner and Montag and Prometheus and Tereno}, + title = {{CryptoNote Transaction Extra Field}}, + howpublished = {CryptoNote}, + year = {2012}, + month = {October}, + note = {\url{https://cryptonote.org/cns/cns005.txt} [Online; accessed 04/04/2018]}, +} + +@misc{premine-description, + title = {What is a premine?}, + note = {\url{https://www.cryptocompare.com/coins/guides/what-is-a-premine/} [Online; accessed 06/11/2018]}, +} + +@misc{chacha-irtf, + author = {Y. Nir and Check Point and A. Langley and Google Inc.}, + title = {{ChaCha20 and Poly1305 for IETF Protocols}}, + howpublished = {Internet Research Task Force (IRTF)}, + year = {2015}, + month = {May}, + note = {\url{https://tools.ietf.org/html/rfc7539} [Online; accessed 05/11/2018]}, +} + +@MISC{Bernstein_chacha, + author = {Daniel J. Bernstein}, + title = {{ChaCha, a variant of Salsa20}}, + year = {2008}, + month = {January}, + note = {\url{https://cr.yp.to/chacha/chacha-20080120.pdf} [Online; accessed 03/04/2020]} +} + +@InProceedings{curve25519, + author="Bernstein, Daniel J.", + editor="Yung, Moti + and Dodis, Yevgeniy + and Kiayias, Aggelos + and Malkin, Tal", + title="{Curve25519: New Diffie-Hellman Speed Records}", + booktitle="Public Key Cryptography - PKC 2006", + year="2006", + publisher="Springer Berlin Heidelberg", + address="Berlin, Heidelberg", + pages="207--228", + abstract="This paper explains the design and implementation of a high-security elliptic-curve-Diffie-Hellman function achieving record-setting speeds: e.g., 832457 Pentium III cycles (with several side benefits: free key compression, free key validation, and state-of-the-art timing-attack protection), more than twice as fast as other authors' results at the same conjectured security level (with or without the side benefits).", + isbn="978-3-540-33852-9", + note = {\url{https://cr.yp.to/ecdh/curve25519-20060209.pdf} [Online; accessed 03/04/2020]} +} + +@misc{varint-description, + author = {glv2}, + title = {{Varint description; Issue \#2340}}, + note = {\url{https://github.com/monero-project/monero/issues/2340#issuecomment-324692291} [Online; accessed 06/14/2018]}, +} + +@misc{MRL-0005-ringct, + author = {Shen Noether and Adam Mackenzie and Monero Core Team}, + title = {{Ring Confidential Transactions, MRL-0005}}, + year = {2016}, + month = {February}, + note = {\url{https://web.getmonero.org/resources/research-lab/pubs/MRL-0005.pdf} [Online; accessed 06/15/2018]}, +} + +@misc{MRL-0003-about-monero, + author = {Shen Noether and Sarang Noether}, + title = {{Monero is Not That Mysterious, MRL-0003}}, + year = {2014}, + month = {September}, + note = {\url{https://web.getmonero.org/resources/research-lab/pubs/MRL-0003.pdf} [Online; accessed 06/15/2018]}, +} + +@misc{kurt-original, + author = {Kurt M. Alonso and Jordi Herrera Joancomart\'i}, + title = {{Monero - Privacy in the Blockchain}}, + howpublished = {Cryptology ePrint Archive, Report 2018/535}, + year = {2018}, + note = {\url{https://eprint.iacr.org/2018/535}}, +} + +@inproceedings{key-prefix-paper, + author = {Kiltz, Eike and Masny, Daniel and Pan, Jiaxin}, + title = {{Optimal Security Proofs for Signatures from Identification Schemes}}, + booktitle = {Proceedings, Part II, of the 36th Annual International Cryptology Conference on Advances in Cryptology --- CRYPTO 2016 - Volume 9815}, + year = {2016}, + isbn = {978-3-662-53007-8}, + pages = {33--61}, + numpages = {29}, + url = {https://doi.org/10.1007/978-3-662-53008-5_2}, + doi = {10.1007/978-3-662-53008-5_2}, + acmid = {3081602}, + publisher = {Springer-Verlag}, + address = {Berlin, Heidelberg}, + keywords = {Identification, Schnorr, Signatures, Tightness}, + note = {\url{https://eprint.iacr.org/2016/191.pdf} [Online; accessed 03/04/2020]} +} + +@misc{Bulletproofs_paper, + author = {Benedikt B\"{u}nz and Jonathan Bootle and Dan Boneh and Andrew Poelstra and Pieter Wuille and Greg Maxwell}, + title = {{Bulletproofs: Short Proofs for Confidential Transactions and More}}, + note = {\url{https://eprint.iacr.org/2017/1066.pdf} [Online; accessed 10/28/2018]}, +} + +@misc{monero-building-blocks, + author = {Bassam El Khoury Seguias}, + title = {{Monero Building Blocks}}, + year = {2018}, + note = {\url{https://delfr.com/category/monero/} [Online; accessed 10/28/2018]}, +} + +@misc{ztm-1, + author = {Kurt M. Alonso and Koe}, + title = {{Zero to Monero - First Edition}}, + year = {2018}, + month = {June}, + note = {\url{https://web.getmonero.org/library/Zero-to-Monero-1-0-0.pdf} [Online; accessed 01/15/2020]}, +} + +@misc{bootle-efficient-zkcircuits, + author = {Jonathan Bootle and Andrea Cerulli and Pyrros Chaidos and Jens Groth and Christophe Petit}, + title = {{Efficient Zero-Knowledge Arguments for Arithmetic Circuits in the Discrete Log Setting}}, + howpublished = {Cryptology ePrint Archive, Report 2016/263}, + year = {2016}, + note = {\url{https://eprint.iacr.org/2016/263}}, +} + +@misc{randomx, + title = {RandomX}, + note = {\url{https://www.monerooutreach.org/stories/RandomX.php} [Online; accessed 10/12/2019]}, +} + +@misc{boronbutterfly-v10, + title = {{Monero 0.14.0 ``Boron Butterfly" Release}}, + note = {\url{https://web.getmonero.org/2019/02/25/monero-0.14.0-released.html} [Online; accessed 10/12/2019]}, +} + +@misc{berylliumbullet-v8, + title = {{Monero 0.13.0 ``Beryllium Bullet" Release}}, + note = {\url{https://www.getmonero.org/2018/10/11/monero-0.13.0-released.html} [Online; accessed 10/12/2019]}, +} + +@misc{miner-tx-checks, + title = {{hackerone \#501585}}, + note = {\url{https://hackerone.com/reports/501585} [Online; accessed 12/28/2019]}, +} + +@misc{applied-cryptography-textbook, + author = {Dan Boneh and Victor Shoup}, + title = {{A Graduate Course in Applied Cryptography}}, + note = {\url{https://crypto.stanford.edu/~dabo/cryptobook/} + [Online; accessed 12/30/2019]}, +} + +@misc{monero-pruning-1/8, + author = {Justin Ehrenhofer}, + title = {{Monero Adds Blockchain Pruning and Improves Transaction Efficiency}}, + year = {2019}, + month = {February}, + note = {\url{https://web.getmonero.org/2019/02/01/pruning.html} + [Online; accessed 12/30/2019]}, +} + +@misc{janus-attack, + author = {Justin Ehrenhofer and knacc}, + title = {Advisory note for users making use of subaddresses}, + year = {2019}, + month = {October}, + note = {\url{https://web.getmonero.org/2019/10/18/subaddress-janus.html} + [Online; accessed 01/02/2020]}, +} + +@misc{fee-old-stackexchange, + author = {koe and jtgrassie}, + title = {{Historical significance of FEE\_PER\_KB\_OLD}}, + year = {2019}, + month = {December}, + note = {\url{https://monero.stackexchange.com/questions/11864/historical-significance-of-fee-per-kb-old} + [Online; accessed 01/02/2020]}, +} + +%duplicate +@article{miller-traceability, + author = {Andrew Miller and + Malte M{\"{o}}ser and + Kevin Lee and + Arvind Narayanan}, + title = {{An Empirical Analysis of Linkability in the Monero Blockchain}}, + journal = {CoRR}, + volume = {abs/1704.04299}, + year = {2017}, + note = {\url{https://arxiv.org/pdf/1704.04299.pdf} [Online; accessed 03/04/2020} +} + +%flawed source +@misc{varint-description-better, + author = {jtgrassie}, + title = {{Genesis TX varint}}, + year = {2018}, + month = {June}, + note = {\url{https://monero.stackexchange.com/questions/8566/genesis-tx-varint} [Online; accessed 01/05/2020]}, +} + +@misc{extra-field-stackexchange, + author = {koe and jtgrassie}, + title = {{Complete extra field structure (standard interpretation)}}, + year = {2020}, + month = {January}, + note = {\url{https://monero.stackexchange.com/questions/11888/complete-extra-field-structure-standard-interpretation} + [Online; accessed 01/05/2020]}, +} + +@misc{visualizing-monero-vid, + author = {Mitchell Krawiec-Thayer}, + title = {{MoneroKon 2019 - Visualizing Monero: A Figure is Worth a Thousand Logs}}, + year = {2019}, + month = {June}, + note = {\url{https://www.youtube.com/watch?v=XIrqyxU3k5Q} + [Online; accessed 01/06/2020]}, +} + +@misc{big-bang-github, + author = {Mitchell Krawiec-Thayer}, + title = {{Numerical simulation for upper bound on dynamic blocksize expansion}}, + year = {2019}, + month = {January}, + note = {\url{https://github.com/noncesense-research-lab/Blockchain_big_bang/blob/master/models/Isthmus_Bx_big_bang_model.ipynb} [Online; accessed 01/08/2020]}, +} + +@misc{visa-seasonality, + author = {Manny Trillo}, + title = {{Visa Transactions Hit Peak on Dec. 23}}, + year = {2011}, + month = {January}, + note = {\url{https://www.visa.com/blogarchives/us/2011/01/12/visa-transactions-hit-peak-on-dec-23/index.html} [Online; accessed 01/10/2020]}, +} + +@misc{articmine-fee-video, + author = {Francisco Caba$\tilde{\textrm{n}}$as}, + title = {{MoneroKon 2019 - Spam Mitigation and Size Control in Permissionless Blockchains}}, + year = {2019}, + month = {June}, + note = {\url{https://www.youtube.com/watch?v=Hbm0ub3qWw4&list=LL2HXH-vq_sTPXMNP4fZNKRw&index=10&t=0s} [Online; accessed 01/10/2020]}, +} + +@misc{mastering-monero, + author = {Serhack et al.}, + title = {{Mastering Monero}}, + year = {2019}, + month = {December}, + note = {\url{https://masteringmonero.com/} [Online; accessed 01/10/2020]}, +} + +@misc{jollymore-old-analysis, + author = {JollyMort}, + title = {{Monero Dynamic Block Size and Dynamic Minimum Fee}}, + year = {2017}, + month = {March}, + note = {\url{https://github.com/JollyMort/monero-research/blob/master/Monero\%20Dynamic\%20Block\%20Size\%20and\%20Dynamic\%20Minimum\%20Fee/Monero\%20Dynamic\%20Block\%20Size\%20and\%20Dynamic\%20Minimum\%20Fee\%20-\%20DRAFT.md} [Online; accessed 01/12/2020]}, +} + +@misc{articmine-36c3-dynamics, + author = {Francisco Caba$\tilde{\textrm{n}}$as}, + title = {{Lightning talk: An Overview of Monero’s Adaptive Blockweight Approach to Scaling}}, + year = {2019}, + month = {December}, + note = {\url{https://frab.riat.at/en/36C3/public/events/125.html} [Online; accessed 01/12/2020]}, +} + +@article{selfish-miner, + author = {Ittay Eyal and + Emin G{\"{u}}n Sirer}, + title = {{Majority is not Enough: Bitcoin Mining is Vulnerable}}, + journal = {CoRR}, + volume = {abs/1311.0243}, + year = {2013}, + archivePrefix = {arXiv}, + eprint = {1311.0243}, + note = {\url{https://arxiv.org/pdf/1311.0243.pdf} [Online; accessed 03/04/2020]} +} + +@misc{no-reward-instability, + author = {Miles Carlsten and Harry Kalodner and Matthew Weinberg and Arvind Narayanan}, + title = {{On the Instability of Bitcoin Without the Block Reward}}, + year = {2016}, + note = {\url{http://randomwalker.info/publications/mining_CCS.pdf} [Online; accessed 01/12/2020]}, +} + +@misc{fee-reward-instability, + author = {Arvind Narayanan}, + title = {Bitcoin is unstable without the block reward}, + year = {2016}, + month = {October}, + note = {\url{https://freedom-to-tinker.com/2016/10/21/bitcoin-is-unstable-without-the-block-reward/} [Online; accessed 01/12/2020]}, +} + +@misc{hashtopoint-writeup, + author = {Shen Noether}, + title = {{Understanding ge\_fromfe\_frombytes\_vartime}}, + note = {\url{https://web.getmonero.org/resources/research-lab/pubs/ge_fromfe.pdf} [Online; accessed 01/20/2020]}, +} + +@misc{articmine-defcon27-video, + author = {Francisco Caba$\tilde{\textrm{n}}$as}, + title = {{Francisco Cabanas - Critical Role of Min Block Reward Trail Emission - DEF CON 27 Monero Village}}, + year = {2019}, + month = {December}, + note = {\url{https://www.youtube.com/watch?v=IlghysBBuyU} [Online; accessed 01/15/2020]}, +} + +@misc{MRL-0009-multisig, + author = {Shen Noether and Sarang Noether}, + title = {{Thring Signatures and their Applications to Spender-Ambiguous Digital Currencies, MRL-0009}}, + year = {2018}, + month = {November}, + note = {\url{https://web.getmonero.org/resources/research-lab/pubs/MRL-0009.pdf} [Online; accessed 01/15/2020]}, +} + +@misc{bitcoin-txsizes-2015, + title = {{Analysis of Bitcoin Transaction Size Trends}}, + year = {2015}, + month = {October}, + note = {\url{https://tradeblock.com/blog/analysis-of-bitcoin-transaction-size-trends} [Online; accessed 01/17/2020]}, +} + +@misc{bytecoin-network, + author = {user36100 and cooldude45}, + title = {{Which entities are related to Bytecoin and Minergate?}}, + year = {2016}, + month = {December}, + note = {\url{https://monero.stackexchange.com/questions/2930/which-entities-are-related-to-bytecoin-and-minergate} [Online; accessed 01/17/2020]}, +} + +@misc{duplicate-ring-members, + author = {user36303 and koe}, + title = {Duplicate ring members}, + year = {2020}, + month = {January}, + note = {\url{https://monero.stackexchange.com/questions/11882/duplicate-ring-members} [Online; accessed 01/18/2020]}, +} + +@misc{old-multisig-mrl-note, + author = {Shen Noether and Adam Mackenzie and Monero Core Team}, + title = {{Ring Multisignature}}, + year = {2016}, + month = {April}, + note = {\url{https://web.archive.org/web/20161023010706/https://shnoe.files.wordpress.com/2016/03/mrl-0008_april28.pdf} [Online; accessed via WayBack Machine 01/21/2020]}, +} + +@misc{mms-manual, + author = {Ren\'e ``rbrunner7" Brunner}, + title = {{Multisig transactions with MMS and CLI wallet}}, + note = {\url{https://web.getmonero.org/resources/user-guides/multisig-messaging-system.html} [Online; accessed 01/21/2020]}, +} + +@misc{cli-22multisig-instructions, + author = {rbrunner7}, + title = {{2/2 Multisig in CLI Wallet}}, + year = {2018}, + month = {January}, + note = {\url{https://taiga.getmonero.org/project/rbrunner7-really-simple-multisig-transactions/wiki/22-multisig-in-cli-wallet} [Online; accessed 01/21/2020]}, +} + +@misc{mms-project-proposal, + author = {Ren\'e ``rbrunner7" Brunner}, + title = {{Project Rationale From the Initiator}}, + year = {2018}, + month = {January}, + note = {\url{https://taiga.getmonero.org/project/rbrunner7-really-simple-multisig-transactions/wiki/home} [Online; accessed 01/21/2020]}, +} + +@misc{endianness, + author = {Bradley Kjell}, + title = {{Big Endian and Little Endian}}, + note = {\url{https://chortle.ccsu.edu/AssemblyTutorial/Chapter-15/ass15_3.html} [Online; accessed 01/23/2020]}, +} + +@misc{ecc-projective, + author = {Wikibooks}, + title = {{Cryptography/Prime Curve/Standard Projective Coordinates}}, + year = {2011}, + month = {March}, + note = {\url{https://en.wikibooks.org/wiki/Cryptography/Prime_Curve/Standard_Projective_Coordinates} [Online; accessed 03/03/2020]}, +} + +@misc{coinjoin-wiki, + title = {{CoinJoin}}, + note = {\url{https://en.bitcoin.it/wiki/CoinJoin} [Online; accessed 01/26/2020]}, +} + +@misc{exa-blockchain-analysis, + author = {Exantech}, + title = {Methods of anonymous blockchain analysis: an overview}, + year = {2019}, + month = {November}, + note = {\url{https://medium.com/@exantech/methods-of-anonymous-blockchain-analysis-an-overview-d700e27ea98c} [Online; accessed 01/26/2020]}, +} + +@misc{coinjoin-sudoku, + author = {Kristov Atlas}, + title = {{Kristov Atlas Security Advisory 20140609-0}}, + year = {2014}, + month = {June}, + note = {\url{https://www.coinjoinsudoku.com/advisory/} [Online; accessed 01/26/2020]}, +} + +@misc{coinjoin-pollution, + author = {Sarah Meiklejohn and Claudio Orlandi}, + title = {{Privacy-Enhancing Overlays in Bitcoin}}, + note = {\url{https://fc15.ifca.ai/preproceedings/bitcoin/paper_5.pdf} [Online; accessed 01/26/2020]}, +} + +@misc{MRL-0011-CLSAG, + author = {Brandon Goodell and Sarang Noether and Arthur Blue}, + title = {{Concise linkable ring signatures and applications, MRL-0011}}, + year = {2019}, + month = {September}, + note = {\url{https://web.getmonero.org/resources/research-lab/pubs/MRL-0011.pdf} [Online; accessed 02/02/2020]}, +} + +@misc{cryptoeprint:2018:417, + author = {Manu Drijvers and Kasra Edalatnejad and Bryan Ford and Eike Kiltz and Julian Loss and Gregory Neven and Igors Stepanovs}, + title = {{On the Security of Two-Round Multi-Signatures}}, + howpublished = {Cryptology ePrint Archive, Report 2018/417}, + year = {2018}, + note = {\url{https://eprint.iacr.org/2018/417} [Online; accessed 02/07/2020]}, +} + +@InProceedings{generalized-birthday-wagner, + author="Wagner, David", + editor="Yung, Moti", + title="{A Generalized Birthday Problem}", + booktitle="Advances in Cryptology --- CRYPTO 2002", + year="2002", + publisher="Springer Berlin Heidelberg", + address="Berlin, Heidelberg", + pages="288--304", + abstract="We study a k-dimensional generalization of the birthday problem: given k lists of n-bit values, find some way to choose one element from each list so that the resulting k values xor to zero. For k = 2, this is just the extremely well-known birthday problem, which has a square-root time algorithm with many applications in cryptography. In this paper, we show new algorithms for the case k > 2: we show a cube-root time algorithm for the case of k = 4 lists, and we give an algorithm with subexponential running time when k is unrestricted.", + isbn="978-3-540-45708-4", + note = {\url{https://link.springer.com/content/pdf/10.1007\%2F3-540-45708-9_19.pdf} [Online; accessed 02/07/2020]} +} + +@misc{birthday-problem, + author = {Ursula Whitcher}, + title = {{The Birthday Problem}}, + note = {\url{http://mathforum.org/dr.math/faq/faq.birthdayprob.html} [Online; accessed 02/07/2020]}, +} + +@misc{credit-card-reversals, + title = {{Payment Reversal Explained + 10 Ways to Avoid Them}}, + year = {2018}, + month = {October}, + note = {\url{https://tidalcommerce.com/learn/payment-reversal} [Online; accessed 02/11/2020]}, +} + +@misc{chainalysis-2020-report, + author = {Chainalysis}, + title = {{THE 2020 STATE OF CRYPTO CRIME}}, + year = {2020}, + month = {January}, + note = {\url{https://go.chainalysis.com/rs/503-FAP-074/images/2020-Crypto-Crime-Report.pdf} [Online; accessed 02/11/2020]}, +} + +@misc{openbazaar-rbrunner-investigation, + author = {Ren\'e ``rbrunner7" Brunner}, + title = {{Basic Monero support ready for assessment, Issue \#1638}}, + year = {2019}, + month = {June}, + note = {\url{https://github.com/OpenBazaar/openbazaar-go/issues/1638} [Online; accessed 02/11/2020]}, +} + +@misc{difficuly-algorithm-summary, + author = {zawy12}, + title = {{Summary of Difficulty Algorithms, Issue \#50}}, + year = {2019}, + month = {December}, + note = {\url{https://github.com/zawy12/difficulty-algorithms/issues/50} [Online; accessed 02/11/2020]}, +} + +@misc{subaddress-pull-request, + author = {kenshi84}, + title = {{Subaddresses, Pull Request \#2056}}, + year = {2017}, + month = {May}, + note = {\url{https://github.com/monero-project/monero/pull/2056} [Online; accessed 02/16/2020]}, +} + +@misc{multisig-research-issue-67, + author = {Sarang Noether}, + title = {{Multisignature implementation, Issue \#67}}, + year = {2020}, + month = {January}, + note = {\url{https://github.com/monero-project/research-lab/issues/67} [Online; accessed 02/16/2020]}, +} + +@misc{janus-mitigation-issue-62, + author = {Sarang Noether}, + title = {{Janus mitigation, Issue \#62}}, + year = {2020}, + month = {January}, + note = {\url{https://github.com/monero-project/research-lab/issues/62} [Online; accessed 02/17/2020]}, +} + +@misc{lithiumluna-v7, + title = {{Monero 0.12.0.0 ``Lithium Luna" Release}}, + author = {Riccardo ``fluffypony" Spagni}, + year = {2018}, + month = {March}, + note = {\url{https://web.getmonero.org/2018/03/29/monero-0.12.0.0-released.html} [Online; accessed 02/18/2020]}, +} + +@misc{unspent-proof-issue-68, + author = {UkoeHB}, + title = {{Proof an output has not been spent, Issue \#68}}, + year = {2020}, + month = {January}, + note = {\url{https://github.com/monero-project/research-lab/issues/68} [Online; accessed 02/19/2020]}, +} + +@misc{base-58-encoding, + title = {{Base58Check encoding}}, + year = {2017}, + month = {November}, + note = {\url{https://en.bitcoin.it/wiki/Base58Check_encoding} [Online; accessed 02/20/2020]}, +} + +@misc{sarang-txproofs-v2-update-pr, + author = {Sarang Noether}, + title = {{WIP: Updated transaction proofs and tests, Pull Request \#6329}}, + year = {2020}, + month = {February}, + note = {\url{https://github.com/monero-project/monero/pull/6329} [Online; accessed 02/20/2020]}, +} + +@misc{sarang-txproofs-updates-issue, + author = {Sarang Noether}, + title = {{Transaction proofs (InProofV1 and OutProofV1) have incomplete Schnorr challenges, Issue \#60}}, + year = {2020}, + month = {January}, + note = {\url{https://github.com/monero-project/research-lab/issues/60} [Online; accessed 02/20/2020]}, +} + +@misc{investopedia-audits, + author = {Alicia Tuovila}, + title = {{Audit}}, + year = {2019}, + month = {July}, + note = {\url{https://www.investopedia.com/terms/a/audit.asp} [Online; accessed 02/24/2020]}, +} + +@misc{reserveproofs-pull-request-3027, + author = {stoffu}, + title = {{Reserve proof, Pull Request \#3027}}, + year = {2017}, + month = {December}, + note = {\url{https://github.com/monero-project/monero/pull/3027} [Online; accessed 02/24/2020]}, +} + +@misc{adam-zero-to-bulletproofs, + author = {Adam ``waxwing" Gibson}, + title = {{From Zero (Knowledge) To Bulletproofs}}, + year = {2018}, + month = {March}, + note = {\url{https://github.com/AdamISZ/from0k2bp/blob/master/from0k2bp.pdf} [Online; accessed 03/01/2020]}, +} + +@misc{adam-wagnerian-tragedies, + author = {Adam ``waxwing" Gibson}, + title = {{Avoiding Wagnerian Tragedies}}, + year = {2019}, + month = {December}, + note = {\url{https://joinmarket.me/blog/blog/avoiding-wagnerian-tragedies/} [Online; accessed 03/01/2020]}, +} + +@misc{dalek-bulletproofs-notes, + author = {dalek-cryptography}, + title = {Bulletproofs}, + note = {\url{https://doc-internal.dalek.rs/bulletproofs/index.html} [Online; accessed 03/02/2020]}, +} + +@misc{randomx-pr-5549, + author = {Howard ``hyc" Chu}, + title = {{RandomX, Pull Request \#5549}}, + year = {2019}, + month = {May}, + note = {\url{https://github.com/monero-project/monero/pull/5549} [Online; accessed 03/03/2020]}, +} + +@misc{hashtopoint-original-paper, + title={{Rational points on certain hyperelliptic curves over finite fields}}, + author={Maciej Ulas}, + year={2007}, + eprint={0706.1448}, + archivePrefix={arXiv}, + primaryClass={math.NT}, + note = {\url{https://arxiv.org/pdf/0706.1448.pdf} [Online; accessed 03/03/2020]}, +} + +@misc{triptych-preprint, + author = {Sarang Noether and Brandon Goodell}, + title = {{Triptych: logarithmic-sized linkable ring signatures with applications}}, + howpublished = {Cryptology ePrint Archive, Report 2020/018}, + year = {2020}, + note = {\url{https://eprint.iacr.org/2020/018.pdf} [Online; accessed 03/04/2020}, +} + +@inproceedings{omniring-paper, + author = {Lai, Russell W. F. and Ronge, Viktoria and Ruffing, Tim and Schr\"{o}der, Dominique and Thyagarajan, Sri and Wang, Jiafan}, + year = {2019}, + month = {11}, + pages = {31-48}, + title = {{Omniring: Scaling Private Payments Without Trusted Setup}}, + isbn = {978-1-4503-6747-9}, + doi = {10.1145/3319535.3345655}, + note = {\url{https://eprint.iacr.org/2019/580.pdf} [Online; accessed 03/04/2020]} +} + +@misc{ringct3-preprint, + author = {Tsz Hon Yuen and {Shi-feng} Sun and Joseph K. Liu and Man Ho Au and Muhammed F. Esgin and Qingzhao Zhang and Dawu Gu}, + title = {{RingCT 3.0 for Blockchain Confidential Transaction: Shorter Size and Stronger Security}}, + howpublished = {Cryptology ePrint Archive, Report 2019/508}, + year = {2019}, + note = {\url{https://eprint.iacr.org/2019/508.pdf} [Online; accessed 03/04/2020]}, +} + +@misc{lelantus-preprint, + author = {Aram Jivanyan}, + title = {{Lelantus: Towards Confidentiality and Anonymity of Blockchain Transactions from Standard Assumptions}}, + howpublished = {Cryptology ePrint Archive, Report 2019/373}, + year = {2019}, + note = {\url{https://eprint.iacr.org/2019/373.pdf} [Online; accessed 03/04/2020]}, +} + +@misc{human-action, + author = {Ludwig Von Mises}, + title = {{Human Action: A Treatise on Economics; The Scholar's Edition}}, + year = {1949}, + note = {\url{https://cdn.mises.org/Human\%20Action_3.pdf} [Online; accessed 03/05/2020]}, +} + +@misc{friedman-schelling, + author = {David Friedman}, + title = {{A Positive Account of Property Rights}}, + year = {1994}, + note = {\url{http://www.daviddfriedman.com/Academic/Property/Property.html} [Online; accessed 03/18/2020]}, +} + +@misc{extended-euclidean, + title = {{Extended Euclidean algorithm}}, + note = {\url{https://en.wikipedia.org/wiki/Extended_Euclidean_algorithm} [Online; accessed 03/19/2020]}, +} + +@misc{justin-defcon-2019-community-growth, + author = {Justin Ehrenhofer}, + title = {{Justin Ehrenhofer - Improving Monero Release Schedule - DEF CON 27 Monero Village}}, + year = {2019}, + month = {December}, + note = {\url{https://www.youtube.com/watch?v=MjNXmJUk2Jo} timestamp 22:15 [Online; accessed 03/20/2020]}, +} + +@misc{min-fee-research-issue-70, + author = {UkoeHB}, + title = {{Reduce minimum fee variability, Issue \#70}}, + year = {2020}, + month = {February}, + note = {\url{https://github.com/monero-project/research-lab/issues/70} [Online; accessed 03/20/2020]}, +} + +@misc{pre-ringct-outputs-like-coinbase-research-issue-59, + author = {UkoeHB}, + title = {{Treat pre-RingCT outputs like coinbase outputs, Issue \#59}}, + year = {2020}, + month = {January}, + note = {\url{https://github.com/monero-project/research-lab/issues/59} [Online; accessed 03/22/2020]}, +} + +@misc{monero-ring-heuristics-ryo, + author = {Ryo ``fireice\_uk" Cryptocurrency}, + title = {{On-chain tracking of Monero and other Cryptonotes}}, + year = {2019}, + month = {April}, + note = {\url{https://medium.com/@crypto_ryo/on-chain-tracking-of-monero-and-other-cryptonotes-e0afc6752527} [Online; accessed 03/25/2020]}, +} + +@misc{elliptic-curve-rigidity, + author = {SafeCurves}, + title = {{SafeCurves: +choosing safe curves for elliptic-curve cryptography}}, + year = {2013}, + note = {\url{https://safecurves.cr.yp.to/rigid.html} [Online; accessed 03/25/2020]}, +} + +@misc{selfish-miner-profitability-algorithm-analysis, + author = {Michael Davidson and Tyler Diamond}, + title = {{On the Profitability of Selfish Mining Against Multiple Difficulty Adjustment Algorithms}}, + howpublished = {Cryptology ePrint Archive, Report 2020/094}, + year = {2020}, + note = {\url{https://eprint.iacr.org/2020/094} [Online; accessed 03/26/2020]}, +} + +@misc{mises-org-fungible, + title = {{Fungible}}, + year = {2014}, + month = {July}, + note = {\url{https://wiki.mises.org/wiki/Fungible} [Online; accessed 03/31/2020]}, +} + +@misc{bitcoin-big-bang-taint, + author = {Nicola Minichiello}, + title = {{The Bitcoin Big Bang: Tracking Tainted Bitcoins}}, + year = {2015}, + month = {June}, + note = {\url{https://bravenewcoin.com/insights/the-bitcoin-big-bang-tracking-tainted-bitcoins} [Online; accessed 03/31/2020]}, +} + +@misc{new-bitcoin-premium, + author = {Jamie Redman}, + title = {{Industry Execs Claim Freshly Minted 'Virgin Bitcoins' Fetch 20\% Premium}}, + year = {2020}, + month = {March}, + note = {\url{https://news.bitcoin.com/industry-execs-freshly-minted-virgin-bitcoins/} [Online; accessed 03/31/2020]}, +} + +@misc{diffie-hellman-problem, + title = {{Diffie–Hellman problem}}, + year = {2019}, + month = {December}, + note = {\url{https://en.wikipedia.org/wiki/Diffie\%E2\%80\%93Hellman_problem} [Online; accessed 03/31/2020]}, +} + +@misc{varint-spec, + title = {{The .xz File Format}}, + year = {2009}, + month = {August}, + note = {\url{https://tukaani.org/xz/xz-file-format.txt} section 1.2 [Online; accessed 04/02/2020]}, +} \ No newline at end of file diff --git a/translations/es/content/Monero.tex b/translations/es/content/Monero.tex new file mode 100755 index 0000000..c6234b1 --- /dev/null +++ b/translations/es/content/Monero.tex @@ -0,0 +1,40 @@ +/chapter{Monero the Cryptocurrency} +/label{chapter:Monero-cryptocurrency} + +final chapter ties it all together (? technical enough to skip rest of report? might make it too long - aim to redirect to other parts of report) + + +-curve ed25519 +-address creation + -basic + -subaddresses + -multisig + -payment ID (integrated addresses) +-receipt of old transactions + -scan blockchain, look at output addresses, use view key and transaction public key to see if any spend keys match + -organize results +-building transaction + -structure of a transaction (how the data is serialized/organized and transmitted) + -obtain addresses (or subaddresses) of intended recipients, specify amounts intended for each + -from sending amounts + fee, select a set of owned outputs with amounts sum(a)>=(sum(b)+fee), and set change = sum(a) - (sum(b)+fee) + -construct outputs: + -create transaction public key (or keys if at least one subaddress and >1 output) + -create one-time output address for each output + -commit to each output amount C(b) + -create D-H 'amount' and 'mask' terms for each output commitment + -range proof: borromean ring signature on each output amount + -if payment ids, encrypt them + -construct inputs: + -create pseudo output commitments if transaction type rcttypesimple + -select ring members for each input mlsag + -calculate key images for each input + -build MLSAG signatures on each input, signing a message that contains all other transaction info + -fill out transaction data structure appropriately (continuous throughout transaction procedure) +-submission of transaction + -verified, placed in mempool +-mining into blockchain + -transactions organized into merkle tree, hashed + -nonce searched until difficulty reached + -block published to network + -block accepted or rejected (orphaned); consensus mechanism + -[potential] signature data pruned \ No newline at end of file diff --git a/translations/es/content/Transactions.tex b/translations/es/content/Transactions.tex new file mode 100755 index 0000000..aabf6f2 --- /dev/null +++ b/translations/es/content/Transactions.tex @@ -0,0 +1,165 @@ +\chapter{Monero Ring Confidential Transactions (RingCT)} +\label{chapter:transactions} + +Throughout Chapters \ref{chapter:addresses} and \ref{chapter:pedersen-commitments} we built up several aspects of Monero transactions. At this point a simple one-input, one-output transaction from some unknown author to some unknown recipient sounds like: + +``My transaction uses transaction public key $r G$. I will spend old output $X$ (note that it has a hidden amount $A_X$, committed to in $C_X$). I will give it a pseudo output commitment $C'_X$. I will make one output $Y$, which may be spent by the one-time address $K^o_Y$. It has a hidden amount $A_Y$ committed to in $C_Y$, encrypted for the recipient, and proven in range with a Bulletproofs-style range proof. Please note that $C'_X - C_Y = 0$." + +Some questions remain. Did the author actually own $X$? Does the pseudo output commitment $C'_X$ actually correspond to $C_X$, such that $A_X = A'_X = A_Y$? Has someone tampered with the transaction, and perhaps directed the output at a recipient unintended by the original author? +\\ + +As mentioned in Section \ref{sec:one-time-addresses}, we can prove ownership of an output by signing a message with its one-time address (whoever has the address's key owns the output). We can also prove it has the same amount as a pseudo output commitment by proving knowledge of the commitment to zero's private key ($C_X - C'_X = z_X G$). Moreover, if that message is {\em all the transaction data} (except the signature itself), then verifiers can be assured everything is as the author intended (the signature only works with the original message). MLSAG signatures allow us to do all of this while also obscuring the actual spent output amongst other outputs from the blockchain, so observers can't be sure which one is being spent. + + + +\section{Transaction types} +\label{sec:transaction_types} + +Monero\marginnote{src/crypto- note\_core/ cryptonote\_ tx\_utils.cpp {\tt construct\_ tx\_with\_ tx\_key()}} is a cryptocurrency under steady development. Transaction structures, protocols, and cryptographic schemes are always prone to evolving as new innovations, objectives, or threats are found. + +In this report we have focused our attention on {\em Ring Confidential Transactions}, a.k.a. {\em RingCT}, as they are implemented in the current version of Monero. RingCT is mandatory for all new Monero transactions, so we will not describe any deprecated transaction schemes, even if they are still partially supported.\footnote{RingCT was first implemented in January 2017 (v4 of the protocol). It was made mandatory for all new transactions in September 2017 (v6 of the protocol) \cite{ringct-dates}. RingCT is version 2 of Monero's transaction protocol.} The transaction type we have discussed so far, and which will be further elaborated in this chapter, is {\tt RCTTypeBulletproof2}.\footnote{Within the RingCT era there are three deprecated transaction types: {\tt RCTTypeFull}, {\tt RCTTypeSimple}, and {\tt RCTTypeBulletproof}. The former two coexisted in the first iteration of RingCT and are explored in the first edition of this report \cite{ztm-1}, then with the advent of Bulletproofs (protocol v8) {\tt RCTTypeFull} was deprecated, and {\tt RCTTypeSimple} was upgraded to {\tt RCTTypeBulletproof}. {\tt RCTTypeBulletproof2} arrived due to a minor improvement in encrypting output commitments' masks and amounts (v10).} + +We present a conceptual summary of transactions in Section \ref{sec:transaction_summary}. + + + +\section{Ring Confidential Transactions of type {\tt RCTTypeBulletproof2}} +\label{sec:RCTTypeBulletproof2} + +Currently (protocol v12) all new transactions must use this transaction type, in which each input is signed separately. An actual example of an {\tt RCTTypeBulletproof2} transaction, with all its components, can be inspected in Appendix \ref{appendix:RCTTypeBulletproof2}. + + +\subsection{Amount commitments and transaction fees} +\label{sec:commitments-and-fees} + +Assume a transaction sender has previously received various outputs with amounts $a_1, ..., a_m$ addressed to one-time addresses $K^o_{\pi,1}, ..., K^o_{\pi,m}$ and with amount commitments $C^a_{\pi,1}, ..., C^a_{\pi,m}$. + +This sender knows the private keys $k^o_{\pi,1}, ..., k^o_{\pi,m}$ corresponding to the one-time addresses (Section \ref{sec:one-time-addresses}). The sender also knows the blinding factors $x_j$ used in commitments $C^a_{\pi,j}$ (Section \ref{sec:pedersen_monero}). + +Typically transaction outputs are {\em lower} in total than transaction inputs, in order to provide a fee that will incentivize miners to include the transaction in the blockchain.\footnote{In Monero there is a minimum base fee that scales with transaction weight. It is semi-mandatory because while you can create new blocks containing tiny-fee transactions, most Monero nodes won't relay such transactions to other nodes. The result is few if any miners will try to include them in blocks. Transaction authors can provide miner fees above the minimum if they want. We go into more detail on this in Section \ref{subsec:dynamic-minimum-fee}.} Transaction fee amounts $f$ are stored in clear text in the transaction data transmitted to the network. Miners can create an additional output for themselves with the fee (see Section \ref{subsec:miner-transaction}). + +A transaction consists of inputs \(a_1, ..., a_m\) and outputs \(b_0, ..., b_{p-1}\) such that \(\sum\limits_{j=1}^m a_j - \sum\limits_{t=0}^{p-1} b_t - f = 0\).\footnote{Outputs\marginnote{src/crypto- note\_core/ cryptonote\_ tx\_utils.cpp {\tt construct\_ tx\_with\_ tx\_key()}}[-1.9cm] are randomly shuffled by the core implementation before getting assigned an index, so observers can't build heuristics around their order. Inputs are sorted by key image within transaction data.} + +The sender calculates pseudo output commitments for the input amounts, $C'^a_{\pi,1}, ..., C'^a_{\pi,m}$, and creates commitments for intended output amounts $b_0, ..., b_{p-1}$. Let these new commitments be $C^b_0, ..., C^b_{p-1}$. + +He knows the private keys $z_1,...,z_m$ to the commitments to zero $(C^a_{\pi,1} - C'^a_{\pi,1}),...,(C^a_{\pi,m} - C'^a_{\pi,m})$. + +For verifiers to confirm transaction amounts sum to zero, the fee amount must be converted into a commitment. The solution is to calculate the commitment of the fee $f$ without the masking effect of any blinding factor. That is, $C(f) = f H$. + +Now\marginnote{src/ringct/ rctSigs.cpp verRct- Semantics- Simple()} we can prove input amounts equal output amounts:\\ +\[(\sum_j C'^a_{j} - \sum_t C^b_{t}) - f H = 0\] + + +\subsection{Signature} +\label{full-signature} + +The sender selects $m$ sets of size $v$, of additional unrelated one-time addresses and their commitments from the blockchain, corresponding to apparently unspent outputs.\footnote{\label{input-selection}In Monero it is standard for the sets\marginnote{src/wallet/ wallet2.cpp {\tt get\_outs()}} of `additional unrelated addresses' to be selected from a gamma\marginnote{{\tt gamma\_picker ::pick()}}[1.2cm] distribution across the range of historical outputs (RingCT outputs only, a triangle distribution is used for pre-RingCT outputs). This method uses a binning procedure to smooth out differences in block densities. First calculate the average time between transaction outputs over up to a year ago of RingCT outputs (avg time = [\#outputs/\#blocks]*blocktime). Select an output via the gamma distribution, then look inside its block and grab a random output to be a member of the set. \cite{AnalysisOfLinkability}}\footnote{As of protocol v12, all transaction inputs must be at least 10 blocks old ({\tt CRYPTONOTE\_DEFAULT\_TX \_SPENDABLE\_AGE}). Prior to v12 the core implementation used 10 blocks by default, but it was not required so an alternate wallet could make different choices, and some apparently did \cite{visualizing-monero-vid}.} To sign input $j$, she stirs a set of size $v$ into a {\em ring} with her own $j$\nth unspent one-time address (placed at unique index $\pi$), along with false commitments to zero, as follows:\footnote{In Monero each of a transaction's rings must have the same size, and the protocol controls how many ring members there can be per output-to-be-spent. It has changed with different protocol versions: v2 March 2016 $\geq$ 3, v6 Sept. 2017 $\geq$ 5, v7 April 2018 $\geq$ 7, v8 Oct. 2018 11-only. Since\marginnote{src/crypto- note\_core/ cryptonote\_ core.cpp {\tt check\_ tx\_inputs\_ ring\_members\_ diff()}} v6 each individual ring can not contain duplicate members, though there may be duplicates between rings to allow multiple inputs when there are insufficient total outputs in the transaction history (i.e. to assemble rings without cross-over) \cite{duplicate-ring-members}.} +%functions get_random_rct_outs for rct outputs mixed into an rct spend, and get_random_outputs for pre-rct outputs mixed into a pre-rct spend. These are only used for light wallets -> instead it is wallet2::get_outs for most situations. +%--ring member selection changing to gamma distribution in fall 2018 +%CRYPTONOTE_DEFAULT_TX_SPENDABLE_AGE = 10 blocks + +\begin{align*} + \mathcal{R}_j = \{&\{K^o_{1, j}, (C_{1, j} - C'^a_{\pi, j})\}, \\ + &... \\ + &\{ K^o_{\pi, j}, (C^a_{\pi, j} - C'^a_{\pi, j})\}, \\ + &... \\ + &\{ K^o_{v+1, j}, (C_{v+1, j} - C'^a_{\pi, j})\}\} +\end{align*} + +Alice\marginnote{src/ringct/ rctSigs.cpp proveRct- MGSimple()} uses an MLSAG signature (Section \ref{sec:MLSAG}) to sign this ring, where she knows the private keys $k^o_{\pi,j}$ for $K^o_{\pi,j}$, and $z_j$ for the commitment to zero $(C^a_{\pi,j}$ - $C'^a_{\pi,j})$. Since no key image is needed for the commitments to zero, there is consequently no corresponding key image component in the signature’s construction.\footnote{Building and verifying the signature excludes the term $r_{i,2} \mathcal{H}_p(C_{i, j} - C'^a_{\pi, j}) + c_i \tilde{K}_{z_j}$.} + +Each input in a transaction is signed individually using rings like \(\mathcal{R}_j\) as defined above, thereby obscuring the real outputs being spent, ($K^o_{\pi,1},...,K^o_{\pi,m}$), amongst other unspent outputs.\footnote{The advantage of signing inputs individually is that the set of real inputs and commitments to zero need not be placed at the same index $\pi$, as they would be in the aggregated case. This means even if one input's origin becomes identifiable, the other inputs' origins would not. The old transaction type {\tt RCTTypeFull} used aggregated ring signatures, combining all rings into one, and as we understand it was deprecated for that reason.} Since part of each ring includes a commitment to zero, the pseudo output commitment used must contain an amount equal to the real input being spent. This ties input amounts to the proof that amounts balance, without compromising which ring member is the real input. + +The message $\mathfrak{m}$ signed by each input is essentially a hash of all transaction data {\em except} for the MLSAG signatures.\footnote{The\marginnote{src/ringct/ rctSigs.cpp {\tt get\_pre\_ mlsag\_hash()}} actual message is $\mathfrak{m} = \mathcal{H}(\mathcal{H}(tx\textunderscore prefix),\mathcal{H}(ss),\mathcal{H}(\text{range proofs}))$ where:\par +$tx\textunderscore prefix = $\{transaction era version (i.e. RingCT = 2), inputs \{ring member key offsets, key images\}, outputs \{one-time addresses\}, extra \{transaction public key, payment ID or encoded payment ID, misc.\}\}\par +$ss = $\{transaction type ({\tt RCTTypeBulletproof2} = `4'), transaction fee, pseudo output commitments for inputs, ecdhInfo (encrypted amounts), output commitments\}.\par +See Appendix \ref{appendix:RCTTypeBulletproof2} regarding this terminology.} This ensures transactions are tamper-proof from the perspective of both transaction authors and verifiers. Only one message is produced, and each input MLSAG signs it. + +One-time private key $k^o$ is the essence of Monero's transaction model. Signing $\mathfrak{m}$ with $k^o$ proves you are the owner of the amount committed to in $C^a$. Verifiers can be confident that transaction authors are spending their own funds, without even knowing which funds are being spent, how much is being spent, or what other funds they might own! + + +\subsection{Avoiding double-spending} + +An\marginnote{src/crypto- note\_core/ block- chain.cpp {\tt have\_tx\_ keyimges\_ as\_spent()}} MLSAG signature (Section \ref{sec:MLSAG}) contains images \(\tilde{K}_{j}\) of private keys \(k_{\pi, j}\). An important property for any cryptographic signature scheme is that it should be unforgeable with non-negligible probability. Therefore, to all practical effects, we can assume a signature’s key images must have been deterministically produced from legitimate private keys. + +The network only needs to verify that key images included with MLSAG signatures (corresponding to inputs and calculated as $\tilde{K}^o_{j} = k^o_{\pi,j} \mathcal{H}_p(K^o_{\pi,j})$) have not appeared before in other transactions.\footnote{Verifiers must also check the key image is a member of the generator's subgroup (recall Section \ref{blsag_note}).} If they have, then we can be sure we are witnessing an attempt to re-spend an output $(C^a_{\pi,j}, K_{\pi,j}^o)$. + + +\subsection{Space requirements} +\label{subsec:space-and-ver-rcttypefull} + +\subsubsection*{MLSAG signature (inputs)} + +From Section \ref{sec:MLSAG} we recall that an MLSAG signature in this context would be expressed as + +\hfill \(\sigma_j(\mathfrak{m}) = (c_1, r_{1, 1}, r_{1, 2}, ..., r_{v+1, 1}, r_{v+1, 2}) \textrm{ with } \tilde{K}^o_j \) \hfill \phantom{.} + +As a legacy of CryptoNote, the values \(\tilde{K}^o_j\) are not referred to as part of the signature, but rather as {\em images} of the private keys $k^o_{\pi,j}$. These {\em key images} are normally stored separately in the transaction structure, as they are used to detect double-spending attacks. + +With this in mind and assuming point compression (Section \ref{point_compression_section}), since each ring \(\mathcal{R}_j\) contains \((v+1) \cdot 2\) keys, an input signature $\sigma_j$ will require \( (2(v+1) + 1) \cdot 32 \) bytes. On top of this, the key image $\tilde{K}^o_{\pi,j}$ and the pseudo output commitment $C'^a_{\pi,j}$ leave a total of $(2(v+1)+3) \cdot 32$ bytes per input. + +To this value we would need additional space to store the ring member offsets in the blockchain (see Appendix \ref{appendix:RCTTypeBulletproof2}). These offsets are used by verifiers to find each MLSAG signature's ring members' output keys and commitments in the blockchain, and are stored as variable length integers, hence we can not exactly quantify the space needed.\footnote{See \cite{varint-description} or \cite{varint-spec} for an explanation of Monero's varint data type\marginnote{src/common/ varint.h}. It is an integer type that uses up to 9 bytes, and stores up to 63 bits of information.}\footnote{Imagine\marginnote{src/crypto- note\_basic/ cryptonote\_ format\_ utils.cpp {\tt absolute\_out- put\_offsets\_ to\_relative()}} the blockchain contains a long list of transaction outputs. We report the indices of outputs we want to use in rings. Now, bigger indexes require more storage space. We just need the `absolute' position of {\em one} index from each ring, and the `relative' positions of the other ring members' indices. For example, with real indices \{7,11,15,20\} we just need to report \{7,4,4,5\}. Verifiers can compute the last index with (7+4+4+5 = 20). Ring members are organized in ascending order of blockchain index within rings.}\footnote{A transaction with 10 inputs using rings with 11 total members will need \(((11 \cdot 2 + 3) \cdot 32) \cdot 10 = 8000 \) bytes for its inputs, with around 110 to 330 bytes for the offsets (there are 110 ring members).}%src/cryptonote_basic/cryptonote_format_utils.cpp absolute_output_offsets_to_relative + +Verifying\marginnote{src/ringct/ rctSigs.cpp verRctMG- Simple() verRct- Semantics- Simple()}[-1cm] all of an {\tt RCTTypeBulletproof2} transaction's MLSAGs includes the computation of \( (C_{i, j} - C'^a_{\pi, j}) \) and \( (\sum_j C'^a_{j} \stackrel{?}{=} \sum_t C^b_{t} + f H)\), and verifying key images are in $G$'s subgroup with $l \tilde{K} \stackrel{?}{=} 0$. + +\subsubsection*{Range proofs (outputs)} + +An\marginnote{src/ringct/ bullet- proofs.cpp {\tt bullet- proof\_ VERIFY()}} aggregate Bulletproof range proof will require $(2 \cdot \lceil \textrm{log}_2(64 \cdot p) \rceil + 9) \cdot 32$ total bytes. + + + +\newpage +\section{Concept summary: Monero transactions} +\label{sec:transaction_summary} + +To summarize this chapter, and the previous two chapters, we present the main content of a transaction, organized for conceptual clarity. A real example can be found in Appendix \ref{appendix:RCTTypeBulletproof2}. + +\begin{itemize} + \item \underline{Type}: `0' is {\tt RCTTypeNull} (for miners), `4' is {\tt RCTTypeBulletproof2} %see chapter 7, blockchain, about type 0 transactions + \item \underline{Inputs}: for each input $j \in \{1,...,m\}$ spent by the transaction author + \begin{itemize} + \item \textbf{Ring member offsets}: a list of `offsets' indicating where a verifier can find input $j$'s ring members $i \in \{1,...,v+1\}$ in the blockchain (includes the real input) + \item \textbf{MLSAG Signature}: $\sigma_j$ terms $c_1$, and $r_{i,1}$ \& $r_{i,2}$ for $i \in \{1,...,v+1\}$ + \item \textbf{Key image}: the key image $\tilde{K}^{o,a}_j$ for input $j$ + \item \textbf{Pseudo output commitment}: $C'^{a}_j$ for input $j$ + \end{itemize} + + \item \underline{Outputs}: for each output $t \in \{0,...,p-1\}$ to address or subaddress $(K^v_t,K^s_t)$ + \begin{itemize} + \item \textbf{One-time address}: $K^{o,b}_t$ for output $t$ + \item \textbf{Output commitment}: $C^{b}_t$ for output $t$ + \item \textbf{Encoded amount}: so output owners can compute $b_t$ for output $t$ + \begin{itemize} + \item \textit{Amount}: $b_t \oplus_8 \mathcal{H}_n(``amount”, \mathcal{H}_n(r K_B^v, t))$ + \end{itemize} + \item \textbf{Range proof}: an aggregate Bulletproof for all output amounts $b_t$ + \begin{itemize} + \item \textit{Proof}: $\Pi_{BP} = (A, S, T_1, T_2, \tau_x, \mu, \mathbb{L}, \mathbb{R}, a, b, t)$ + \end{itemize} + \end{itemize} + \item \underline{Transaction fee}: communicated in clear text multiplied by $10^{12}$ (i.e. atomic units, see Section \ref{subsec:block-reward}), so a fee of 1.0 would be recorded as 1000000000000 + \item \underline{Extra}: includes the transaction public key $r G$, or, if at least one output is directed to a subaddress, $r_t K^{s,i}_t$ for each subaddress'd output $t$ and $r_t G$ for each normal address'd output $t$, and maybe an encoded payment ID (should be at most one per transaction)\footnote{No information stored in the `extra' field is verified, though it {\em is} signed by input MLSAGs, so no tampering is possible (except with negligible probability). The field has no limit on how much data it can store, so long as the maximum transaction weight is respected. See \cite{extra-field-stackexchange} for more details.} +\end{itemize} + +Our final one-input/one-output example transaction sounds like this: ``My transaction uses transaction public key $r G$. I will spend one of the outputs in set $\mathbb{X}$ (note that it has a hidden amount $A_X$, committed to in $C_X$). The output being spent is owned by me (I made a MSLAG signature on the one-time addresses in $\mathbb{X}$), and hasn't been spent before (its key image $\tilde{K}$ has not yet appeared in the blockchain). I will give it a pseudo output commitment $C'_X$. I will make one output $Y$, which may be spent by the one-time address $K^o_Y$. It has a hidden amount $A_Y$ committed to in $C_Y$, encrypted for the recipient, and proven in range with a Bulletproofs-style range proof. My transaction includes a transaction fee $f$. Please note that $C'_X - (C_Y + C_f) = 0$, and that I have signed the commitment to zero $C'_X - C_X = z G$ which means the input amount equals the output amount ($A_X = A'_X = A_Y + f$). My MLSAG signed all transaction data, so observers can be sure it hasn't been tampered with." + + +\newpage +\subsection{Storage requirements} + +For {\tt RCTTypeBulletproof2} we need $(2(v+1)+2) \cdot m \cdot 32$ bytes of storage, and the aggregate Bulletproof range proof needs $(2 \cdot \lceil \textrm{log}_2(64 \cdot p) \rceil + 9) \cdot 32$ bytes of storage.\footnote{The amount of transaction content is limited by a maximum so-called `transaction weight'.\marginnote{src/crypto- note\_core/ tx\_pool.cpp {\tt get\_trans- action\_weight \_limit()}} Before Bulletproofs were added in protocol v8 (and indeed currently when transactions have only two outputs) the transaction weight and size in bytes were equivalent. The maximum weight is (0.5*300kB - {\tt CRYPTONOTE\_COINBASE\_BLOB\_RESERVED\_SIZE}), where the blob reserve (600 bytes) is intended to leave room for the miner transaction within blocks. Before v8 the 0.5x multiplier was not included, and the 300kB term was smaller in earlier protocol versions (20kB v1, 60kB v2, 300kB v5). We elaborate on these topics in Section \ref{subsec:dynamic-block-weight}.} + +Miscellaneous requirements: +\begin{itemize} + \setlength\itemsep{\listspace} + \item Input key images: $m*32$ bytes + \item One-time output addresses: $p*32$ bytes + \item Output commitments: $p*32$ bytes + \item Encoded output amounts: $p*8$ bytes + \item Transaction public key: 32 bytes normally, $p*32$ bytes if sending to at least one subaddress. + \item Payment ID: 8 bytes for an integrated address. There should be no more than one per tx. + \item Transaction fee: stored as a variable length integer, so $\leq 9$ bytes + \item Input offsets: stored as variable length integers, so $\leq 9$ bytes per offset, for $m*(v+1)$ ring members + \item Unlock time: stored as a variable length integer, so $\leq 9$ bytes\footnote{Any transaction's author can lock its outputs\marginnote{src/crypto- note\_core/ block- chain.cpp {\tt is\_tx\_ spendtime\_ unlocked()}}, rendering them unspendable until a specified block height where it may be spent (or until a UNIX timestamp, at which time its outputs may be included in a block's transaction's ring members). He only has the option to lock all outputs to the same block height. It is not clear if this offers any meaningful utility to transaction authors (perhaps smart contracts). Miner transactions have a mandatory 60-block lock time. As of protocol v12 normal outputs can't be spent until after the default spendable age (10 blocks) which is functionally equivalent to a mandatory minimum 10-block lock time. If a transaction is published in the 10\nth block with an unlock time of 25, it may be spent in the 25\nth block or later. Unlock time is probably the least used of all transaction features for normal transactions.} + \item `Extra' tags: each piece of data in the `extra' field (e.g. a transaction public key) begins with a 1 byte `tag', and some pieces also have a 1+ byte `length'; see Appendix \ref{appendix:RCTTypeBulletproof2} for more details +\end{itemize} \ No newline at end of file diff --git a/translations/es/content/addresses.tex b/translations/es/content/addresses.tex new file mode 100755 index 0000000..dd80078 --- /dev/null +++ b/translations/es/content/addresses.tex @@ -0,0 +1,165 @@ +\chapter{Monero Addresses} +\label{chapter:addresses} + +The ownership of digital currency stored in a blockchain is controlled by so-called `addresses'. Addresses are sent money which only the address-holder can spend.\footnote{Except with negligible probability.} + +More specifically, an address owns the `outputs' from some transactions, which are like notes giving the address-holder spending rights to an `amount' of money. Such a note might say ``Address C now owns 5.3 XMR". + +To spend an owned output, the address-holder references it as the input to a new transaction. This new transaction has outputs owned by other addresses (or by the sender's address, if the sender wants). A transaction's total input amount equals its total output amount, and once spent an owned output can't be respent. Carol, who has Address C, could reference that old output in a new transaction (e.g. ``In this transaction I'd like to spend that old output.") and add a note saying ``Address B now owns 5.3 XMR". + +An address's balance is the sum of amounts contained in its unspent outputs.\footnote{Computer applications known as `wallets' are used to find and organize the outputs owned by an address, to maintain custody of its private keys for authoring new transactions, and to submit those transactions to the network for verification and inclusion in the blockchain.} + +We discuss hiding the amount from observers in Chapter \ref{chapter:pedersen-commitments}, the structure of transactions in Chapter \ref{chapter:transactions} (which includes how to prove you are spending an owned and previously unspent output, without even revealing which output is being spent), and the money creation process and role of observers in Chapter \ref{chapter:blockchain}. + + + +\section{User keys} +\label{sec:user-keys} + +Unlike Bitcoin, Monero users have two sets of private/public keys, \((k^v, K^v)\) and \( (k^s, K^s) \), generated as described in Section \ref{ec:keys}. + +The {\em address}\marginnote{src/ common/ base58.cpp {\tt encode\_ addr()}} of a user is the pair of public keys \((K^v, K^s)\). Her private keys will be the corresponding pair \( (k^v, k^s) \).\footnote{To communicate an address to other users, it is extremely common to encode it in base-58, a binary-to-text encoding scheme first created for Bitcoin \cite{base-58-encoding}. See \cite{luigi-address} for more details.} +\\ + +Using two sets of keys allows function segregation. The rationale will become clear later in this chapter, but for the moment let us call private key $k^v$ the {\em view key}, and $k^s$ the {\em spend key}. A person can use their view key to determine if their address owns an output, and their spend key will allow them to spend that output in a transaction (and retroactively figure out it has been spent).\footnote{It\marginnote{src/wallet/ api/wallet.cpp {\tt create()} wallet2.cpp {\tt generate()} {\tt get\_seed()}} is currently most common for the view key $k^v$ to equal $\mathcal{H}_n(k^s)$. This means a person only needs to save their spend key $k^s$ in order to access (view and spend) all of the outputs they own (spent and unspent). The spend key is typically represented as a series of 25 words (where the 25th word is a checksum). Other, less popular methods include: generating $k^v$ and $k^s$ as separate random numbers, or generating a random 12-word mnemonic $a$, where $k^s = {\tt sc\textunderscore reduce32}(\mathit{Keccak}(a))$ and $k^v = {\tt sc\textunderscore reduce32}(\mathit{Keccak}(\mathit{Keccak}(a)))$. \cite{luigi-address}} + + + +\section{One-time addresses} +\label{sec:one-time-addresses} + +To receive money, a Monero user may distribute their address to other users, who can then send it money via transaction outputs. + +The address is never used directly.\footnote{The method described here is not enforced by the protocol, just by wallet implementation standards. This means an alternate wallet could follow the style of Bitcoin where recipients' addresses are included directly in transaction data. Such a non-compliant wallet would produce transaction outputs unusable by other wallets, and each Bitcoin-esque address could only be used once due to key image uniqueness.} Instead, a Diffie-Hellman-like exchange is applied to it, creating a unique {\em one-time address} for each transaction output to be paid to the user. In this way, even external observers who know all users’ addresses cannot use them to identify which user owns any given transaction output.\footnote{Except with negligible probability.} + +%A recipient can spend their received outputs by signing a message with the one-time addresses, thereby proving they know the private keys and therefore own what they are spending. We will gradually flesh out this concept. +%\\ + +Let’s start with a very simple mock transaction, containing exactly one output --- a payment of `0' amount from Alice to Bob. + +Bob has private/public keys $(k_B^v, k_B^s)$ and $(K_B^v, K_B^s)$, and Alice knows his public keys (his address). The mock transaction could proceed as follows \cite{cryptoNoteWhitePaper}: + +\begin{enumerate} + \item Alice generates a random number $r \in_R \mathbb{Z}_l$, and calculates the one-time address\footnote{In\marginnote{src/crypto/ crypto.cpp {\tt generate\_ key\_deri- vation()}} Monero, every instance (including when it's used for other parts of the transaction) of $r k^v G$ is multiplied by the cofactor 8, so in this case Alice computes $8*r K^v_B$ and Bob computes $8*k^v_B r G$. As far as we can tell this serves no purpose (but it {\em is} a rule that users must follow). Multiplying by the cofactor ensures the resulting point is in $G$'s subgroup, but if $R$ and $K^v$ don't share a subgroup to begin with, then the discrete logs $r$ and $k^v$ can't be used to make a shared secret regardless.}\vspace{.175cm} + \[K^o = \mathcal{H}_n(r K_B^v)G + K_B^s\marginnote{src/crypto/ crypto.cpp {\tt derive\_pu- blic\_key()}}\] + + \item Alice sets $K^o$ as the addressee of the payment, adds the output amount `0' and the value $r G$ to the transaction data, and submits it to the network. + + \item Bob\marginnote{src/crypto/ crypto.cpp {\tt derive\_ subaddress\_ public\_ key()}} receives the data and sees the values $r G$ and $K^o$. He can calculate $k_B^v r G = r K_B^v$. He can then calculate $K'^s_B = K^o - \mathcal{H}_n(r K_B^v)G$. When he sees that $K'^s_B = K_B^s$, he knows the output is addressed to him.\footnote{$K'^s_B $ is computed with {\tt derive\_subaddress\_public\_key()} because normal address spend keys are stored at index 0 in the spend key lookup table, while subaddresses are at indices 1,2... This will make sense soon: see Section \ref{sec:subaddresses}.} + + The private key $k_B^v$ is called the `view key' because anyone who has it (and Bob’s public spend key $K_B^s$) can calculate $K'^s_B$ for every transaction output in the blockchain (record of transactions), and ‘view’ which ones belong to Bob. + + \item The one-time keys for the output are:\vspace{.175cm} + \begin{align*} + K^o &= \mathcal{H}_n(r K_B^v)G + K_B^s = (\mathcal{H}_n(r K_B^v) + k_B^s)G \\ + k^o &= \mathcal{H}_n(r K_B^v) + k_B^s + \end{align*} +\end{enumerate} + +To spend his `0' amount output [sic] in a new transaction, all Bob needs to do is prove ownership by signing a message with the one-time key $K^o$. The private key $k_B^s$ is the `spend key' since it is required for proving output ownership, while $k_B^v$ is the `view key' since it can be used to find outputs spendable by Bob. + +As will become clear in Chapter \ref{chapter:transactions}, without $k^o$ Alice can't compute the output's key image, so she can never know for sure if Bob spends the output she sent him.\footnote{Imagine Alice produces two transactions, each containing the same one-time output address $K^o$ that Bob can spend. Since $K^o$ only depends on $r$ and $K_B^v$, there is no reason she can't do it. Bob can only spend one of those outputs because each one-time address only has one key image, so if he isn't careful Alice might trick him. She could make transaction 1 with a lot of money for Bob, and later transaction 2 with a small amount for Bob. If he spends the money in 2, he can never spend the money in 1. In fact, no one could spend the money in 1, effectively `burning' it. Monero wallets have been designed to ignore the smaller amount in this scenario.} + +Bob may give a third party his view key. Such a third party could be a trusted custodian, an auditor, a tax authority, etc. Somebody who could be allowed read access to the user’s transaction history, without any further rights. This third party would also be able to decrypt the output's amount (to be explained in Section \ref{sec:pedersen_monero}). See Chapter \ref{chapter:tx-knowledge-proofs} for other ways Bob could provide information about his transaction history. + + +\subsection{Multi-output transactions} +\label{sec:multi_out_transactions} + +Most transactions will contain more than one output. If nothing else, to transfer `change’ back to the sender.\footnote{Actually, as of protocol v12 two outputs are {\em required} from each (non-miner) transaction, even if it means one output has 0 amount ({\tt HF\_VERSION\_MIN\_2\_OUTPUTS}). This improves transaction indistinguishability by mixing 1-output cases with the much more common 2-output transactions. Previous to v12 the core wallet software was already creating 0-value outputs. The core implementation sends 0-amount outputs to a random address.\marginnote{src/wallet/ wallet2.cpp {\tt transfer\_ selected\_ rct()}}}\footnote{After Bulletproofs were implemented in protocol v8, each transaction became limited to no more than 16 outputs ({\tt BULLETPROOF\_MAX\_OUTPUTS}). Previously there was no limit, aside from a restraint on transaction size (in bytes).}%BULLETPROOF_MAX_OUTPUTS; wallet2::transfer_selected_rct() for random address 0-amount + +Monero senders usually generate only one random value $r$. The curve point $r G$ is typically known as the {\em transaction public key} and is published alongside other transaction data in the blockchain.\\ + +To\marginnote{src/crypto- note\_core/ cryptonote\_ tx\_utils.cpp {\tt construct\_ tx\_with\_ tx\_key()}}[-.8cm] ensure that all one-time addresses in a transaction with $p$ outputs are different even in cases where the same addressee is used twice, Monero uses an output index. Every output from a transaction has an index $t \in \{0, ..., p-1\}$. By appending this value to the shared secret before hashing it, one can ensure the resulting one-time addresses are unique:\marginnote{src/crypto/ crypto.cpp {\tt derive\_pu- blic\_key()}}[1.2cm]\vspace{.175cm}%construct_tx_with_tx_key() indexes 0 to p-1 +\begin{align*} + K_t^o &= \mathcal{H}_n(r K_t^v, t)G + K_t^s = (\mathcal{H}_n(r K_t^v, t) + k_t^s)G \\ + k_t^o &= \mathcal{H}_n(r K_t^v, t) + k_t^s +\end{align*} + + + +\section{Subaddresses} +\label{sec:subaddresses} + +Monero users can generate subaddresses from each address \cite{MRL-0006-subaddresses}. Funds sent to a subaddress can be viewed and spent using its main address’s view and spend keys. By analogy: an online bank account may have multiple balances corresponding to credit cards and deposits, yet they are all accessible and spendable from the same point of view – the account holder.\\ + +Subaddresses are convenient for receiving funds to the same place when a user doesn't want to link his activities together by publishing/using the same address. As we will see, most observers would have to solve the DLP to determine a given subaddress is derived from any particular address \cite{MRL-0006-subaddresses}.\footnote{Prior to subaddresses (added in the software update corresponding with protocol v7 \cite{subaddress-pull-request}), Monero users could simply generate many normal addresses. To view each address's balance, you needed to do a separate scan of the blockchain record. This was very inefficient. With subaddresses, users maintain a look-up table of (hashed) spend keys, so one scan of the blockchain takes the same amount of time for 1 subaddress, or 10,000 subaddresses.} + +They are also useful for differentiating between received outputs. For example, if Alice wants to buy an apple from Bob on a Tuesday, Bob could write a receipt describing the purchase and make a subaddress for that receipt, then ask Alice to use that subaddress when she sends him the money. This way Bob can associate the money he receives with the apple he sold. We explore another way to distinguish between received outputs in the next section.%\footnote{Before subaddresses were implemented in April 2018, the Monero developers supported a method called payment IDs, which allowed receivers to differentiate between owned outputs. Payment IDs were text strings included in a transaction's `extra', miscellaneous, data. Recipients could ask senders to include the payment IDs when writing a transaction. Payment IDs could also be encoded in conjunction with so-called integrated addresses. Payment IDs and integrated addresses do not affect transaction verification, so they can still be implemented by anyone, but since they are currently deprecated in the most popular wallets we have chosen not to explain them here.} + +%\footnote{Note that the index $i$ could just as easily be some password-generated hash $\mathcal{H}_n(x)$. This would allow an address owner to view his subaddress funds from his main address view key, but only be able to spend those funds by inputting a password. There are currently no wallet implementations password protecting subaddresses, nor any known plans to develop a wallet with that feature.} +Bob\marginnote{src/device/ device\_de- fault.cpp {\tt get\_sub- address\_ secret\_ key()}} generates his $i^\nth$ subaddress $(i = 1, 2, ...)$ from his address as a pair of public keys $(K^{v,i}, K^{s,i})$:\footnote{It turns out the subaddress hash is domain separated, so it's really $\mathcal{H}_n(T_{sub},k^v,i)$ where $T_{sub} = $``SubAddr". We omit $T_{sub}$ throughout this document for brevity.}\vspace{.175cm} +\begin{align*} + K^{s,i} &= K^s + \mathcal{H}_n(k^v, i) G\\ + K^{v,i} &= k^v K^{s,i} +\end{align*} +\quad So, +\begin{alignat*}{2} + K^{v,i} &= k^v&&(k^s + \mathcal{H}_n(k^v, i))G\\ + K^{s,i} &= &&(k^s + \mathcal{H}_n(k^v, i))G +\end{alignat*} + + +\subsection{Sending to a subaddress} + +Let's say Alice is going to send Bob `0' amount again, this time via his subaddress $(K_B^{v,1}, K_B^{s,1})$. +\begin{enumerate} + \item Alice generates a random number $r \in_R \mathbb{Z}_l$, and calculates the one-time address\vspace{.175cm} + \[ K^o = \mathcal{H}_n(r K_B^{v,1},0)G + K_B^{s,1} \] + + \item Alice sets $K^o$ as the addressee of the payment, adds the output amount `0' and the value $r K_B^{s,1}$ to the transaction data, and submits it to the network. + + \item Bob\marginnote{src/crypto/ crypto.cpp {\tt derive\_ subaddress\_ public\_ key()}} receives the data and sees the values $r K_B^{s,1}$ and $K^o$. He can calculate $k_B^v r K_B^{s,1} = r K_B^{v,1}$. He can then calculate $K'^{s}_B = K^o - \mathcal{H}_n(r K_B^{v,1},0)G$. When he sees that $K'^{s}_B = K^{s,1}_B$, he knows the transaction is addressed to him.\footnote{An advanced attacker may be able to link subaddresses \cite{janus-attack} (a.k.a. the Janus attack). With subaddresses (one of which can be a normal address) $K_B^1$ $\&$ $K_B^2$ the attacker thinks may be related, he makes a transaction output with $K^o = \mathcal{H}_n(r K_B^{v,2},0)G + K_B^{s,1}$ and includes transaction public key $r K_B^{s,2}$. Bob calculates $r K_B^{v,2}$ to find $K'^{s,1}_B$ but has no way of knowing it was his {\em other} (sub)address's key used! If he tells the attacker that he received funds to $K_B^1$, the attacker will know $K_B^2$ is a related subaddress (or normal address). Since subaddresses are outside the protocol's scope, mitigations are up to wallet implementers. No known wallets have done so, and any mitigation would only work for compliant wallets. Potential mitigations include: not informing attackers of received funds, including encrypted transaction private key $r$ in transaction data, a Schnorr signature on the shared secret using $K^{s,1}$ as the base point instead of $G$, and including $rG$ in transaction data and verifying the shared secret with $rK^{s,1} \stackrel{?}{=} (k^s + \mathcal{H}_n(k^v, 1))*rG$ (requires the private spend key). Outputs received by a normal address should also be verified. See \cite{janus-mitigation-issue-62} for a discussion of the last mitigation listed.} + + Bob only needs his private view key $k_B^v$ and subaddress public spend key $K^{s,1}_B$ to find transaction outputs sent to his subaddress. + + \item The one-time keys for the output are:\vspace{.175cm} + \begin{align*} + K^o &= \mathcal{H}_n(r K_B^{v,1},0)G + K_B^{s,1} = (\mathcal{H}_n(r K_B^{v,1},0) + k_B^{s,1})G \\ + k^o &= \mathcal{H}_n(r K_B^{v,1},0) + k_B^{s,1} + \end{align*} +\end{enumerate} + +Now,\marginnote{src/crypto- note\_core/ cryptonote\_ tx\_utils.cpp {\tt construct\_ tx\_with\_ tx\_key()}} Alice's transaction public key is particular to Bob ($r K_B^{s,1}$ instead of $r G$). If she creates a $p$-output transaction with at least one output intended for a subaddress, Alice needs to make a unique transaction public key for each output $t \in \{0,...,p-1\}$. In other words, if Alice is sending to Bob's subaddress $(K_B^{v,1}, K_B^{s,1})$ and Carol's address $(K_C^v, K_C^s)$, she will put two transaction public keys \{$r_1 K_B^{s,1},r_2 G$\} in the transaction data.\footnote{In\marginnote{src/crypto- note\_basic/ cryptonote\_ basic\_impl.cpp {\tt get\_account\_ address\_as\_ str()}} Monero subaddresses are prefixed with an ‘8’, separating them from addresses, which are prefixed with ‘4’. This helps senders choose the correct procedure when constructing transactions.}\footnote{There is some intricacy to when additional transaction public keys are used (see the code path {\tt transfer\_selected\_rct()} $\rightarrow$ {\tt construct\_tx\_and\_get\_tx\_key()} $\rightarrow$ {\tt construct\_tx\_with\_tx\_key()} $\rightarrow$ {\tt generate\_output\_ephemeral\_keys()} and {\tt classify\_addresses()}) surrounding change outputs where the transaction author knows the recipient's view key (since it's himself; also the case for dummy change outputs, which are created when a 0-amount output is necessary, since authors generate those addresses). Whenever there are at least two non-change outputs, and at least one of their recipients is a subaddress, proceed in the normal way explained above (a current bug in the core implementation adds an extra transaction public key to transaction data even beyond the additional keys, which is not used for anything). If either just the change output is to a subaddress, or there is just one non-change output and it's to a subaddress, then only one transaction public key is created. In the former case, the transaction public key is $rG$ and the change's one-time key is (subaddress index 1, using $c$ subscript to denote the change's keys) $K^o = \mathcal{H}_n(k^v_c r G,t)G + K_c^{s,1}$ using the normal view key and subaddress's spend key. In the latter case the transaction public key $r K^{v,1}$ is based off the subaddress's view key, and the change's one time key is $K^o = \mathcal{H}_n(k^v_c*r K^{v,1},t)G + K_c^s$. These details help mingle a portion of subaddress transactions amongst the more common normal address transactions, and 2-output transactions which compose around 95\% of transaction volume as of this writing.} + + + +\section{Integrated addresses} +\label{sec:integrated-addresses} + +To differentiate between the outputs they receive, a recipient can request senders include a {\em payment ID} in transaction data.\footnote{Currently, Monero implementations only support one payment ID per transaction regardless of how many outputs it has.} For example, if Alice wants to buy an apple from Bob on a Tuesday, Bob could write a receipt describing the purchase and ask Alice to include the receipt's ID number when she sends him the money. This way Bob can associate the money he receives with the apple he sold. + +At one point senders could communicate payment IDs in clear text, but manually including the IDs in transactions is inconvenient, and cleartext is a privacy hazard for recipients, who might inadvertently expose their activities.\footnote{These long-form (256 bit) cleartext payment IDs were deprecated in v0.15 of the core software implementation (coincident with protocol v12 in November 2019). While other wallets may still support them and allow their inclusion in transaction data, the core wallet will ignore them.} In\marginnote{src/crypto- note\_basic/ cryptonote\_ basic\_ impl.cpp {\tt get\_ account\_ integrated\_ address\_as\_ str()}} Monero, recipients can integrate payment IDs into their addresses, and provide those {\em integrated addresses}, containing ($K^v$, $K^s$, payment ID), to senders. Payment IDs can technically be integrated into any kind of address, including normal addresses, subaddresses, and multisignature addresses.\footnote{Within the authors' knowledge, integrated addresses have only ever been implemented for normal addresses.} + +Senders addressing outputs to integrated addresses can encode payment IDs using the shared secret $r K_t^v$ and an XOR operation (recall Section \ref{sec:XOR_section}), which recipients can then decode with the appropriate transaction public key and another XOR operation \cite{integrated-addresses}. Encoding payment IDs in this way also allows senders to prove they made particular transaction outputs (e.g. for audits, refunds, etc.).\footnote{Since an observer can recognize the difference between transactions with and without payment IDs, using them is thought to make the Monero transaction history less uniform. Because of this, since protocol v10 the core implementation adds a dummy\marginnote{src/crypto- note\_core/ cryptonote\_ tx\_utils.cpp {\tt construct\_ tx\_with\_ tx\_key()}} encrypted payment ID to all 2-output transactions. Decoding one will reveal all 0s (this is not required by the protocol, just best practice).} + + +\subsubsection*{Encoding} + +The\marginnote{src/device/ device\_de- fault.cpp {\tt encrypt\_ payment\_ id()}} sender encodes the payment ID for inclusion in transaction data\footnote{In Monero payment IDs for integrated addresses are conventionally 64 bits long.}\vspace{.175cm} +\begin{align*} + k_{\textrm{mask}} &= \mathcal{H}_n(r K_t^v,\textrm{pid\_tag}) \\ + k_{\textrm{payment ID}} &= k_{\textrm{mask}} \rightarrow \textrm{reduced to bit length of payment ID}\\ + \textrm{encoded payment ID} &= \textrm{XOR}(k_{\textrm{payment ID}}, \textrm{payment ID}) +\end{align*} + +We include pid\_tag to ensure $k_{\textrm{mask}}$ is different from the component $\mathcal{H}_n(r K_t^v, t)$ in one-time output addresses.\footnote{In Monero, pid\_tag = {\tt ENCRYPTED\_PAYMENT\_ID\_TAIL} = 141. In, for example, multi-input transactions we compute $\mathcal{H}_n(r K_t^v, t) \pmod l$ to ensure we are using a scalar less than the EC subgroup order, but since $l$ is 253 bits and payment IDs are only 64 bits, taking the modulus for encoding payment IDs would be meaningless, so we don't.} + + +\subsubsection*{Decoding} + +Whichever\marginnote{src/device/ device.hpp {\tt decrypt\_ payment\_ id()}} recipient the payment ID was created for can find it using his view key and the transaction public key $r G$:\footnote{Transaction data does not indicate which output a payment ID `belongs' to. Recipients have to identify their own payment IDs.}\vspace{.175cm} +\begin{align*} + k_{\textrm{mask}} &= \mathcal{H}_n(k_t^v r G,\textrm{pid\_tag}) \\ + k_{\textrm{payment ID}} &= k_{\textrm{mask}} \rightarrow \textrm{reduced to bit length of payment ID}\\ + \textrm{payment ID} &= \textrm{XOR}(k_{\textrm{payment ID}}, \textrm{encoded payment ID}) +\end{align*} + +Similarly, senders can decode payment IDs they had previously encoded by recalculating the shared secret.%remove this line? + + + +\section{Multisignature addresses} +\label{sec:multisignature-addresses} + +Sometimes it is useful to share ownership of funds between different people/addresses. We dedicate Chapter \ref{chapter:multisignatures} to elaborating this topic. \ No newline at end of file diff --git a/translations/es/content/advancedSchnorr.tex b/translations/es/content/advancedSchnorr.tex new file mode 100755 index 0000000..4b2f817 --- /dev/null +++ b/translations/es/content/advancedSchnorr.tex @@ -0,0 +1,400 @@ +\chapter{Advanced Schnorr-like Signatures} +\label{chapter:advanced-schnorr} + +A basic Schnorr signature has one signing key. As it happens, we can apply its core concepts to create a variety of progressively more complex signature schemes. One of those schemes, MLSAG, will be of central importance in Monero's transaction protocol. + + + +%-same signing key across multiple bases +\section{Prove knowledge of a discrete logarithm across multiple bases} +\label{sec:proofs-discrete-logarithm-multiple-bases} + +It is often useful to prove the same private key was used to construct public keys on different `base' keys. For example, we could have a normal public key $k G$, and a Diffie-Hellman shared secret $k R$ with some other person's public key (recall Section \ref{DH_exchange_section}), where the base keys are $G$ and $R$. As we will soon see, we can prove knowledge of the discrete log $k$ in $k G$, prove knowledge of $k$ in $k R$, {\em and} prove that $k$ is the same in both cases (all without revealing $k$). + + +\subsection*{Non-interactive proof} + +Suppose we have a private key $k$, and $d$ base keys $\mathcal{J} = \{J_1,...,J_d\}$. The corresponding public keys are $\mathcal{K} = \{K_1,...,K_d\}$. We make a Schnorr-like proof (recall Section \ref{sec:schnorr-fiat-shamir}) across all bases.\footnote{While we say `proof', it can be trivially made a signature by including a message $\mathfrak{m}$ in the challenge hash. The terminology is loosely interchangeable in this context.} Assume the existence of a hash function \(\mathcal{H}_n\) +mapping to integers from 0 to $l-1$.\footnote{In Monero, the hash function $\mathcal{H}_n(x) = \textrm{sc\textunderscore reduce32}(\mathit{Keccak}(x))$ where $\mathit{Keccak}$ is the basis of SHA3 and sc\textunderscore reduce32() puts the 256 bit result in the range 0 to $l-1$ (although it should really be 1 to $l-1$).} + +\begin{enumerate} + \item Generate random number $\alpha \in_R \mathbb{Z}_l$, and compute, for all $i \in (1,...,d)$, $\alpha J_i$. + \item Calculate the challenge,\vspace{.175cm} + \[c = \mathcal{H}_n(\mathcal{J},\mathcal{K},[\alpha J_1],[\alpha J_2],...,[\alpha J_d])\] + \item Define the response $r = \alpha - c*k$. + \item Publish the signature $(c, r)$. +\end{enumerate} + + +\subsection*{Verification} + +Assuming the verifier knows $\mathcal{J}$ and $\mathcal{K}$, he does the following. + +\begin{enumerate} + \item Calculate the challenge:\vspace{.175cm} + \[c' = \mathcal{H}(\mathcal{J},\mathcal{K},[r J_1 + c*K_1],[r J_2 + c*K_2],...,[r J_d + c*K_d])\] + \item If $c = c'$ then the signer must know the discrete logarithm across all bases, and it's the same discrete logarithm in each case (as always, except with negligible probability). +\end{enumerate} + + +\subsection*{Why it works} + +If instead of $d$ base keys there was just one, this proof would clearly be the same as our original Schnorr proof (Section \ref{sec:schnorr-fiat-shamir}). We can imagine each base key in isolation to see that the multi-base proof is just a bunch of Schnorr proofs connected together. Moreover, by using only one challenge and response for all of those proofs, they must have the same discrete logarithm $k$. To get a single response that works for multiple keys the challenge would need to be known before defining an $\alpha$ for each key, but $c$ is a function of $\alpha$! + + + +%-multiple signing keys on their own unique bases (or they can be the same e.g. G) +\section{Multiple private keys in one proof} +\label{sec:multiple_private_keys_in_one_proof} + +Much like a multi-base proof, we can combine many Schnorr proofs that use different private keys. Doing so proves we know all the private keys for a set of public keys, and reduces storage requirements by making just one challenge for all proofs. + + +\subsection*{Non-interactive proof} + +Suppose we have $d$ private keys $k_1,...,k_d$, and base keys $\mathcal{J} = \{J_1,...,J_d\}$.\footnote{There is no reason $\mathcal{J}$ can't contain duplicate base keys here, or for all base keys to be the same (e.g. $G$). Duplicates would be redundant for multi-base proofs, but now we are dealing with different private keys.} The corresponding public keys are $\mathcal{K} = \{K_1,...,K_d\}$. We make a Schnorr-like proof for all keys simultaneously. + +\begin{enumerate} + \item Generate random numbers $\alpha_i \in_R \mathbb{Z}_l$ for all $i \in (1,...,d)$, and compute all $\alpha_i J_i$. + \item Calculate the challenge,\vspace{.175cm} + \[c = \mathcal{H}_n(\mathcal{J},\mathcal{K},[\alpha_1 J_1],[\alpha_2 J_2],...,[\alpha_d J_d])\] + \item Define each response $r_i = \alpha_i - c*k_i$. + \item Publish the signature $(c, r_1,...,r_d)$. +\end{enumerate} + + +\subsection*{Verification} + +Assuming the verifier knows $\mathcal{J}$ and $\mathcal{K}$, he does the following. + +\begin{enumerate} + \item Calculate the challenge:\vspace{.175cm} + \[c' = \mathcal{H}(\mathcal{J},\mathcal{K},[r_1 J_1 + c*K_1],[r_2 J_2 + c*K_2],...,[r_d J_d + c*K_d])\] + \item If $c = c'$ then the signer must know the private keys for all public keys in $\mathcal{K}$ (except with negligible probability). +\end{enumerate} + + + +\section{Spontaneous Anonymous Group (SAG) signatures} +\label{SAG_section} + +Group signatures are a way of proving a signer belongs to a group, without necessarily identifying him. Originally (Chaum in \cite{Chaum:1991:GS:1754868.1754897}), group signature schemes required the system be set up, and in some cases managed, by a trusted person in order to prevent illegitimate signatures, and, in a few schemes, adjudicate disputes. These relied on a {\em group secret} which is not desirable since it creates a disclosure risk that could undermine anonymity. Moreover, requiring coordination between group members (i.e. for setup and management) is not scalable beyond small groups or inside companies. + +Liu {\em et al.} presented a more interesting scheme in \cite{Liu2004} building on the work of Rivest {\em et al.} in \cite{rivest-leak-secret}. The authors detailed a group signature algorithm called LSAG characterized by three properties: {\em anonymity, linkability,} and {\em spontaneity}. Here we discuss SAG, the non-linkable version of LSAG, for conceptual clarity. We reserve the idea of linkability for later sections. +\\ + +Schemes with anonymity and spontaneity are typically referred to as `ring signatures'. In the context of Monero they will ultimately allow for unforgeable, signer-ambiguous transactions that leave currency flows largely untraceable. + + +\subsection*{Signature} + +Ring signatures are composed of a ring and a signature. Each {\em ring} is a set of public keys, one of which belongs to the signer and the rest of which are unrelated. The {\em signature} is generated with that ring of keys, and anyone verifying it would not be able to tell which ring member was the actual signer. + +Our Schnorr-like signature scheme in Section \ref{sec:signing-messages} can be considered a one-key ring signature. We get to two keys by, instead of defining $r$ right away, generating a decoy $r'$ and creating a new challenge to define $r$ with. +\\ + +Let \(\mathfrak{m}\) be the message to sign, \(\mathcal{R} = \{K_1, K_2, ..., K_n\}\) a set of distinct public keys (a group/ring), and \(k_\pi\) the signer's private key corresponding to his public key \(K_\pi \in \mathcal{R}\), where $\pi$ is a secret index. + +\begin{enumerate} + \item Generate random number \(\alpha \in_R \mathbb{Z}_l\) and fake responses \(r_i \in_R \mathbb{Z}_l\) for \(i \in \{1, 2, ..., n\}\) but excluding \(i = \pi\). + + \item Calculate + \[c_{\pi+1} = \mathcal{H}_n(\mathcal{R}, \mathfrak{m}, [\alpha G])\] + + \item For \(i = \pi+1, \pi+2, ..., n, 1, 2, ..., \pi-1\) calculate, replacing \(n + 1 \rightarrow 1\),\vspace{.175cm} + \[ c_{i+1} = \mathcal{H}_n(\mathcal{R}, \mathfrak{m}, [r_i G + c_i K_i])\] + + \item Define the real response $r_\pi$ such that \(\alpha = r_\pi + c_\pi k_\pi \pmod l\). +\end{enumerate} + +The ring signature contains the signature \(\sigma(\mathfrak{m}) = (c_1, r_1, ..., r_n) \), and the ring $\mathcal{R}$. + + +\subsection*{Verification} + +Verification means proving $\sigma(\mathfrak{m})$ is a valid signature created by a private key corresponding to a public key in $\mathcal{R}$ (without necessarily knowing which one), and is done in the following manner: + +\begin{enumerate} + \item For \(i = 1, 2, ..., n\) iteratively compute, replacing \(n + 1 \rightarrow 1\),\vspace{.175cm} + \begin{align*} + c'_{i+1} = \mathcal{H}_n(\mathcal{R}, \mathfrak{m}, [r_i G + c_i {K_i}]) + \end{align*} + + \item If \(c_1 = c'_1\) then the signature is valid. Note that $c'_1$ is the last term calculated. +\end{enumerate} + +In this scheme we store (1+$n$) integers and use $n$ public keys. + + +\subsection*{Why it works} + +We can informally convince ourselves the algorithm works by going through an example. Consider ring $R = \{K_1, K_2, K_3\}$ with $k_\pi = k_2$. First the signature: +\begin{enumerate} + \item Generate random numbers: $\alpha$, $r_1$, $r_3$ +\begin{align*} + \intertext{\item Seed the signature loop:} c_3 &= \mathcal{H}_n(\mathcal{R}, \mathfrak{m}, [\alpha G]) + \intertext{\item Iterate: \vspace{-.2cm}} + c_1 &= \mathcal{H}_n(\mathcal{R}, \mathfrak{m}, [r_3 G + c_3 K_3])\\ + c_2 &= \mathcal{H}_n(\mathcal{R}, \mathfrak{m}, [r_1 G + c_1 K_1]) +\end{align*} + \item Close the loop by responding: $r_2 = \alpha - c_2 k_2 \pmod{l}$ +\end{enumerate} + +We can substitute $\alpha$ into $c_3$ to see where the word ‘ring' comes from:\vspace{.175cm} +\begin{alignat*}{3} + c_3 &= \mathcal{H}_n(\mathcal{R}, \mathfrak{m}, [(r_2 + c_2 k_2) G &&])\\ + c_3 &= \mathcal{H}_n(\mathcal{R}, \mathfrak{m}, [r_2 G + c_2 K_2 &&]) +\end{alignat*}\vspace{.05cm} + +Then verification using $\mathcal{R}$, and $\sigma(\mathfrak{m}) = (c_1, r_1, r_2, r_3)$: +\begin{enumerate} + \item We use $r_1$ and $c_1$ to compute\vspace{.175cm} + \begin{align*} +c'_2 &= \mathcal{H}_n(\mathcal{R}, \mathfrak{m}, [r_1 G + c_1 K_1]) + \intertext{\item From when we made the signature, we see $c'_2 = c_2$. With $r_2$ and $c'_2$ we compute\vspace{.175cm}} +c'_3 &= \mathcal{H}_n(\mathcal{R}, \mathfrak{m}, [r_2 G + c'_2 K_2]) + \intertext{\item We can easily see that $c'_3 = c_3$ by substituting $c_2$ for $c'_2$. Using $r_3$ and $c'_3$ we get\vspace{.175cm}} +c'_1 &= \mathcal{H}_n(\mathcal{R}, \mathfrak{m}, [r_3 G + c'_3 K_3]) + \end{align*} +\end{enumerate} +\quad No surprises here: $c'_1 = c_1$ if we substitute $c_3$ for $c'_3$.\vspace{-.3cm} + + + +\section{Back's Linkable Spontaneous Anonymous Group (bLSAG) signatures} +\label{blsag_note} + +The ring signature schemes discussed here on out display several properties that will be useful for producing confidential transactions.\footnote{Keep in mind that all robust signature schemes have security models which contain various properties. The properties mentioned here are perhaps most relevant to understanding the purpose of Monero's ring signatures, but are not a comprehensive overview of linkable ring signature properties.} Note that both `signer ambiguity' and `unforgeability' also apply to SAG signatures. + +\begin{description} + \item[Signer Ambiguity] + An observer should be able to determine the signer must be a member of the ring (except with negligible probability), but not which member.\footnote{\label{anonymity_note}Anonymity for an action is usually in terms of an `anonymity set’, which is `all the people who could have possibly taken that action’. The largest anonymity set is `humanity’, and for Monero it is the ring size, or e.g. the so-called `mixin level' $v$ plus the real signer. Mixin refers to how many fake members each ring signature has. If the mixin is $v$ = 4 then there are 5 possible signers. Expanding anonymity sets makes it progressively harder to track down real actors.} Monero uses this to obfuscate the origin of funds in each transaction. + + \item[Linkability] + If a private key is used to sign two different messages then the messages will become linked.\footnote{\label{linkability_note}The linkability property does not apply to non-signing public keys. That is, a ring member whose public key has been used in different ring signatures will not cause linkage.} As we will show, this property is used to prevent double-spending attacks in Monero (except with negligible probability). + + \item[Unforgeability] + No attacker can forge a signature except with negligible probability.\footnote{\label{unforgeability_note}Certain ring signature schemes, including the one in Monero, are strong against adaptive chosen-message and adaptive chosen-public-key attacks. An attacker who can obtain legitimate signatures for chosen messages and corresponding to specific public keys in rings of his choice cannot discover how to forge the signature of even one message. This is called {\em existential unforgeability}; see \cite{MRL-0005-ringct} and \cite{Liu2004}.} This is used to prevent theft of Monero funds by those not in possession of the appropriate private keys. +\end{description} + +In the LSAG signature scheme \cite{Liu2004}, the owner of a private key could produce one anonymous unlinked signature per ring.\footnote{\label{lsag_linkability_note}In the LSAG scheme linkability only applies to signatures using rings with the same members and in the same order, the `exact same ring.’ It is really ``one anonymous signature per ring member per ring.” Signatures can be linked even if made for different messages.} In this section we present an enhanced version of the LSAG algorithm where linkability is independent of the ring’s decoy members.\footnote{LSAG was discussed in the first edition of this report. \cite{ztm-1}} + +The modification was unraveled in \cite{MRL-0005-ringct} based on a publication by Adam Back \cite{AdamBack-ring-efficiency} regarding the CryptoNote \cite{cryptoNoteWhitePaper} ring signature algorithm (previously used in Monero, and now deprecated; see Section \ref{subsec:proofs-input-creation-spendproof}), which was in turn inspired by Fujisaki and Suzuki's work in \cite{Fujisaki2007}. + + +\subsection*{Signature} + +As with SAG, let \(\mathfrak{m}\) be the message to sign, \(\mathcal{R} = \{K_1, K_2, ..., K_n\}\) a set of distinct public keys, and \(k_\pi\) the signer's private key corresponding to his public key \(K_\pi \in \mathcal{R}\), where $\pi$ is a secret index. Assume the existence of a hash function \(\mathcal{H}_p\), which maps to curve points in EC.\footnote{It doesn’t matter if points from $\mathcal{H}_p$ are compressed or not. They can always be decompressed.}\footnote{Monero uses a hash function\marginnote{src/ringct/ rctOps.cpp {\tt hash\_to\_p3()}} that returns curve points directly, rather than computing some integer that is then multiplied by $G$. $\mathcal{H}_p$ would be broken if someone discovered a way to find $n_x$ such that $n_x G = \mathcal{H}_p(x)$. See a description of the algorithm in \cite{hashtopoint-writeup}. According to the CryptoNote whitepaper \cite{cryptoNoteWhitePaper} its origin was this paper: \cite{hashtopoint-original-paper}.} + +\begin{enumerate} + \item Calculate key image \(\tilde{K} = k_\pi \mathcal{H}_p(K_\pi)\).\footnote{In Monero it's important to use the hash to point function for key images instead of another base point so linearity doesn't lead to linking signatures created by the same address (even if for different one-time addresses). See \cite{cryptoNoteWhitePaper} page 18.} + + \item Generate random number \(\alpha \in_R \mathbb{Z}_l\) and random numbers \(r_i \in_R \mathbb{Z}_l\) for \(i \in \{1, 2, ..., n\}\) but excluding \(i = \pi\). + + \item Compute + \[c_{\pi+1} = \mathcal{H}_n(\mathfrak{m}, [\alpha G], [\alpha \mathcal{H}_p(K_\pi)])\] + + \item For \(i = \pi+1, \pi+2, ..., n, 1, 2, ..., \pi-1\) calculate, replacing \(n + 1 \rightarrow 1\),\vspace{.175cm} + \[c_{i+1} = \mathcal{H}_n(\mathfrak{m}, [r_i G + c_i K_i], [r_i \mathcal{H}_p(K_i) + c_i \tilde{K}])\] + + \item Define \(r_\pi = \alpha - c_\pi k_\pi \pmod l\). +\end{enumerate} + +The signature will be \(\sigma(\mathfrak{m}) = (c_1, r_1, ..., r_n)\), with key image $\tilde{K}$ and ring $\mathcal{R}$. + + +\subsection*{Verification} + +Verification means proving $\sigma(\mathfrak{m})$ is a valid signature created by a private key corresponding to a public key in $\mathcal{R}$, and is done in the following manner: + +\begin{enumerate} + \item Check $l \tilde{K} \stackrel{?}{=} 0$. + \item For \(i = 1, 2, ..., n\) iteratively compute, replacing \(n + 1 \rightarrow 1\),\vspace{.175cm} + \begin{align*} + c'_{i+1} = \mathcal{H}_n(\mathfrak{m}, [r_i G + c_i {K_i}], [r_i \mathcal{H}_p(K_i) + c_i \tilde{K}]) + \end{align*} + + \item If \(c_1 = c'_1\) then the signature is valid. +\end{enumerate} + +In this scheme we store (1+$n$) integers, have one EC key image, and use $n$ public keys. + +We\marginnote{src/crypto- note\_core/ cryptonote\_ core.cpp {\tt check\_tx\_ inputs\_key- images\_do- main()}} must check $l \tilde{K} \stackrel{?}{=} 0$ because it is possible to add an EC point from the subgroup of size $h$ (the cofactor) to $\tilde{K}$ and, if all $c_i$ are multiples of $h$ (which we could achieve with automated trial and error using different $\alpha$ and $r_i$ values), make $h$ unlinked valid signatures using the same ring and signing key.\footnote{We are not concerned with points from other subgroups because the output of $\mathcal{H}_n$ is confined to $\mathbb{Z}_l$. For EC order $N = h l$, all divisors of $N$ (and hence, possible subgroups) are either multiples of $l$ (a prime) or divisors of $h$.} This is because an EC point multiplied by its subgroup's order is zero.\footnote{In Monero's early history this was not checked for. Fortunately, it was not exploited before a fix was implemented in April 2017 (v5 of the protocol) \cite{key-image-bug}.} + +To be clear, given some point $K$ in the subgroup of order $l$, some point $K^h$ with order $h$, and an integer $c$ divisible by $h$: +\begin{align*} + c*(K + K^h) &= cK + cK^h\\ + &= cK + 0 +\end{align*} + +We can demonstrate correctness (i.e. `how it works') in a similar way to the more simple SAG signature scheme. + +Our description attempts to be faithful to the original explanation of bLSAG, which does not include $\mathcal{R}$ in the hash that calculates $c_i$. Including keys in the hash is known as `key prefixing'. Recent research \cite{key-prefix-paper} suggests it may not be necessary, although adding the prefix is standard practice for similar signature schemes (LSAG uses key prefixing). + + +\subsection*{Linkability} + +Given two valid signatures that are different in some way (e.g. different fake responses, different messages, different overall ring members),\vspace{.1cm} +\begin{align*} + \sigma(\mathfrak{m}) &= (c_1, r_1, ..., r_n)\textrm{ with } \tilde{K}\textrm{, and}\\ + \sigma'(\mathfrak{m}') &= (c_1', r'_1, ..., r'_{n'})\textrm{ with } \tilde{K}'\textrm{,} +\end{align*} +\quad if \(\tilde{K} = \tilde{K}'\) then clearly both signatures come from the same private key.% because $\tilde{K}= k_{\pi} \mathcal{H}_p(\mathcal{R})$. + +While an observer could link $\sigma$ and $\sigma'$, he wouldn’t necessarily know which $K_i$ in $\mathcal{R}$ or $\mathcal{R}'$ was the culprit unless there was only one common key between them. If there was more than one common ring member, his only recourse would be solving the DLP or auditing the rings in some way (such as learning all $k_i$ with $i \neq \pi$, or learning $k_\pi$).\footnote{\label{lsag_unforgeable_note}LSAG, which is quite similar to bLSAG, is unforgeable, meaning no attacker could make a valid ring signature without knowing a private key. If he invents a fake $\tilde{K}$ and seeds his signature computation with $c_{\pi+1}$, then, not knowing $k_\pi$, he can’t calculate a number $r_\pi = \alpha - c_\pi k_\pi$ that would produce $[r_\pi G + c_\pi K_\pi] = \alpha G$. A verifier would reject his signature. Liu {\em et al.} prove forgeries that manage to pass verification are extremely improbable \cite{Liu2004}.} + + + +\section{Multilayer Linkable Spontaneous Anonymous Group (MLSAG) signatures} +\label{sec:MLSAG} + +In order to sign transactions, one has to sign with multiple private keys. In \cite{MRL-0005-ringct}, Shen Noether {\em et al.} describe a multi-layered generalization of the bLSAG signature scheme applicable when we have a set of \(n \cdot m\) keys; that is, the set\vspace{.175cm} +\[\mathcal{R} = \{K_{i,j}\} \quad \textrm{for} \quad i \in \{1, 2, ..., n\} \quad \textrm{and} \quad j \in \{1, 2, ..., m\}\] + +where we know the $m$ private keys \(\{k_{\pi, j}\}\) corresponding to the subset \(\{K_{\pi, j}\}\) for some index \(i = \pi\). Such an algorithm would address our needs if we generalize the notion of linkability. +\begin{description} + \item[Linkability] If any private key \(k_{\pi, j}\) is used in 2 different signatures, then those signatures will be automatically linked. +\end{description} + + +\subsection*{Signature} + +\begin{enumerate} + \item Calculate key images \(\tilde{K_j} = k_{\pi, j} \mathcal{H}_p(K_{\pi, j})\) for all \(j \in \{1, 2, ..., m\}\). + + \item Generate random numbers \(\alpha_j \in_R \mathbb{Z}_l\), and \(r_{i, j} \in_R \mathbb{Z}_l\) for \(i \in \{1, 2, ..., n\}\) (except \(i = \pi\)) and \(j \in \{1, 2, ..., m\}\). + + \item Compute\footnote{Monero\marginnote{src/ringct/ rctSigs.cpp {\tt MLSAG\_Gen()}} MLSAG uses key prefixing. Each challenge contains explicit public keys like this (adding the $K$ terms absent from bLSAG; key images are included in the message signed):\vspace{-.25cm} + \[c_{\pi+1} = \mathcal{H}_n(\mathfrak{m}, K_{\pi, 1}, [\alpha_1 G], [\alpha_1 \mathcal{H}_p(K_{\pi, 1})], ..., K_{\pi, m}, [\alpha_m G], [\alpha_m \mathcal{H}_p(K_{\pi, m})]) + \]} + \[c_{\pi+1} = \mathcal{H}_n(\mathfrak{m}, [\alpha_1 G], [\alpha_1 \mathcal{H}_p(K_{\pi, 1})], ..., [\alpha_m G], [\alpha_m \mathcal{H}_p(K_{\pi, m})])\] + + \item For \(i = \pi+1, \pi+2, ..., n, 1, 2, ..., \pi-1\) calculate, replacing \(n + 1 \rightarrow 1\),\vspace{.175cm} + \[ c_{i+1} = \mathcal{H}_n(\mathfrak{m}, [r_{i, 1} G + c_i K_{i, 1}], [r_{i, 1} \mathcal{H}_p(K_{i, 1}) + c_i \tilde{K}_1], + ..., [r_{i, m} G + c_i K_{i, m}], [r_{i, m} \mathcal{H}_p(K_{i, m}) + c_i \tilde{K}_m])\] + + \item Define all \(r_{\pi, j} = \alpha_j - c_\pi k_{\pi, j} \pmod l\). +\end{enumerate} + +The signature will be \(\sigma(\mathfrak{m}) = (c_1, r_{1, 1}, ..., r_{1, m}, ..., r_{n, 1}, ..., r_{n, m}) \), with key images $(\tilde{K}_1, ..., \tilde{K}_m)$. + +%One way to think about MLSAG is that there are $m$ sub-loops of size $n$, and in each sub-loop we know a private key at index $i = \pi$ ($m \cdot n$ total public keys). The signature algorithm ties together a ‘stack’ of keys at each stage $c$, composed of one key from each sub-loop. bLSAG is the special case where $m = 1$. + + +\subsection*{Verification} + +Verification of a signature is done in the following manner: + +\begin{enumerate} + \item For all $j \in \{1,...,m\}$ check $l \tilde{K}_j \stackrel{?}{=} 0$. + \item For \(i = 1, ..., n\) compute, replacing \(n + 1 \rightarrow 1\),\vspace{.175cm} + \begin{align*} + c'_{i+1} = \mathcal{H}_n(\mathfrak{m}, [r_{i, 1} G + c_i K_{i, 1}], [r_{i, 1} \mathcal{H}_p(K_{i, 1}) + c_i \tilde{K}_1], + ..., [r_{i, m} G + c_i K_{i, m}], [r_{i, m} \mathcal{H}_p(K_{i, m}) + c_i \tilde{K}_m]) + \end{align*} + + \item If \(c_1 = c'_1\) then the signature is valid. +\end{enumerate} + + +\subsection*{Why it works} + +Just as with the SAG algorithm, we can readily observe that + +\begin{itemize} + \item If \(i \ne \pi \), then clearly the values \(c'_{i + 1}\) are calculated as described in the signature algorithm. + + \item If \(i = \pi\) then, since \(r_{\pi, j} = \alpha_j - c_\pi k_{\pi, j} \) closes the loop,\vspace{.175cm} + \begin{alignat*}{6} + r_{\pi, j} G + c_\pi K_{\pi,j} &= (\alpha_j - c_\pi k_{\pi, j}) G + c_\pi K_{\pi,j} = \alpha_j G\\ + \intertext{and} + r_{\pi, j} \mathcal{H}_p(K_{\pi, j}) + c_\pi \tilde{K}_j &= (\alpha_j - c_\pi k_{\pi, j}) \mathcal{H}_p(K_{\pi, j}) + c_\pi \tilde{K}_j = \alpha_j \mathcal{H}_p(K_{\pi, j})\\ + \end{alignat*} + In other words, it holds also that \(c'_{\pi + 1} = c_{\pi+1}\). +\end{itemize} + + +\subsection*{Linkability} + +If a private key \(k_{\pi, j}\) is re-used to make any signature, the corresponding key image \(\tilde{K}_j\) supplied in the signature will reveal it. This observation matches our generalized definition of linkability.\footnote{As with bLSAG, linked MLSAG signatures do not indicate which public key was used to sign it. However, if the linking key image's sub-loops' rings have only one key in common, the culprit is obvious. If the culprit is identified, all other signing members of both signatures are revealed since they share the culprit's indices.} + + +\subsection*{Space requirements} + +In this scheme we store (1+$m*n$) integers, have $m$ EC key images, and use $m*n$ public keys. + + + +\section{Concise Linkable Spontaneous Anonymous Group (CLSAG) signatures} +\label{sec:CLSAG} + +CLSAG \cite{MRL-0011-CLSAG}\footnote{The paper this section is based on is a pre-print being finalized for external review. CLSAG is promising as a replacement for MLSAG in future protocol versions, but has not been implemented, and might not be in the future.} is sort of half-way between bLSAG and MLSAG. Suppose you have a `primary' key, and associated with it are several `auxiliary' keys. It is important to prove knowledge of all private keys, but linkability only applies to the primary. This linkability retraction allows smaller, faster signatures than afforded by MLSAG. + +As with MLSAG, we have a set of \(n \cdot m\) keys ($n$ is the ring size, $m$ is the number of signing keys), and the primary keys are at index 1. In other words, there are $n$ primary keys, and the $\pi$\nth such key and its auxiliaries will sign.\vspace{.175cm} +\[\mathcal{R} = \{K_{i,j}\} \quad \textrm{for} \quad i \in \{1, 2, ..., n\} \quad \textrm{and} \quad j \in \{1, 2, ..., m\}\] + +We know the private keys \(\{k_{\pi, j}\}\) corresponding to the subset \(\{K_{\pi, j}\}\) for some index \(i = \pi\). + + +\subsection*{Signature} + +\begin{enumerate} + \item Calculate key images \(\tilde{K_j} = k_{\pi, j} \mathcal{H}_p(K_{\pi, 1})\) for all \(j \in \{1, 2, ..., m\}\). Note the base key is always the same, and so key images with $j>1$ are `auxiliary key images'. For notational simplicity we call them all $\tilde{K}_j$. + + \item Generate random numbers \(\alpha \in_R \mathbb{Z}_l\), and \(r_{i} \in_R \mathbb{Z}_l\) for \(i \in \{1, 2, ..., n\}\) (except \(i = \pi\)). + + \item Calculate aggregate public keys $W_i$ for \(i \in \{1, 2, ..., n\}\), and aggregate key image $\tilde{W}$\footnote{The CLSAG paper says to use different hash functions for domain separation, which we model by prefixing each hash with a tag \cite{MRL-0011-CLSAG}, e.g. $T_1 =$ ``CLSAG\_1", $T_c =$ ``CLSAG\_c", etc. Domain separated hash functions have different outputs even with the same inputs. We also use key prefixing here (including $\mathcal{R}$, which has all the keys, in the hash). Domain separating is a new policy for Monero development, and will likely be done with all applications of hash functions added in the future (v13+). Historical uses of hash functions will probably be left alone.}%an actual implementation may use $j$ flags, instead of the index itself + \begin{align*} + W_i &= \sum^{m}_{j=1} \mathcal{H}_n(T_j, \mathcal{R}, \tilde{K}_1,...,\tilde{K}_{m})*K_{i,j}\\ + \tilde{W} &= \sum^{m}_{j=1} \mathcal{H}_n(T_j, \mathcal{R}, \tilde{K}_1,...,\tilde{K}_{m})*\tilde{K}_j + \end{align*}{} + where $w_{\pi} = \sum_j \mathcal{H}_n(T_j,...)*k_{\pi,j}$ is the aggregate private key. + + \item Compute + \[c_{\pi+1} = \mathcal{H}_n(T_c, \mathcal{R}, \mathfrak{m}, [\alpha G], [\alpha \mathcal{H}_p(K_{\pi, 1})])\] + + \item For \(i = \pi+1, \pi+2, ..., n, 1, 2, ..., \pi-1\) calculate, replacing \(n + 1 \rightarrow 1\),\vspace{.175cm} + \[c_{i+1} = \mathcal{H}_n(T_c, \mathcal{R}, \mathfrak{m}, [r_i G + c_i W_i], [r_{i} \mathcal{H}_p(K_{i,1}) + c_i \tilde{W}])\] + + \item Define \(r_{\pi} = \alpha - c_\pi w_\pi \pmod l\). +\end{enumerate} + +Therefore \(\sigma(\mathfrak{m}) = (c_1, r_1, ..., r_n) \), with primary key image $\tilde{K}_1$, and auxiliary images $(\tilde{K}_2,...,\tilde{K}_{m})$. + + +\subsection*{Verification} + +The verification of a signature is done in the following manner: + +\begin{enumerate} + \item For all $j \in \{1,...,m\}$ check $l \tilde{K}_j \stackrel{?}{=} 0$.\footnote{In Monero we would only check $l*\tilde{K}_1 \stackrel{?}{=} 0$ for the primary key image. Auxiliary keys would be stored as $(1/8)*\tilde{K}_j$, and during verification multiplied by 8 (recall Section \ref{elliptic_curves_section}), which is more efficient. The method discrepancy is an implementation choice, since linkable key images are very important and so shouldn't be messed with aggressively, and the other method was employed in prior protocol versions.} + + \item Calculate aggregate public keys $W_i$ for \(i \in \{1, 2, ..., n\}\), and aggregate key image $\tilde{W}$\vspace{.175cm} + \begin{align*} + W_i &= \sum^{m}_{j=1} \mathcal{H}_n(T_j, \mathcal{R}, \tilde{K}_1,...,\tilde{K}_{m})*K_{i,j}\\ + \tilde{W} &= \sum^{m}_{j=1} \mathcal{H}_n(T_j, \mathcal{R}, \tilde{K}_1,...,\tilde{K}_{m})*\tilde{K}_j + \end{align*}{} + + \item For \(i = 1, ..., n\) compute, replacing \(n + 1 \rightarrow 1\),\vspace{.175cm} + \[c_{i+1} = \mathcal{H}_n(T_c, \mathcal{R}, \mathfrak{m}, [r_i G + c_i W_i], [r_{i} \mathcal{H}_p(K_{i,1}) + c_i \tilde{W}])\] + + \item If \(c_1 = c'_1\) then the signature is valid. +\end{enumerate} + + +\subsection*{Why it works} + +The biggest danger in concise signatures like this is key cancellation, where the key images reported aren't legitimate, yet still sum to a legitimate aggregate value. This is where the aggregation coefficients $\mathcal{H}_n(T_j, \mathcal{R}, \tilde{K}_1,...,\tilde{K}_{m})$ come into play, locking down each key to its expected value. We leave tracing out the circular repercussions of faking a key image as an exercise to the reader (perhaps start by imagining those coefficients don't exist). Auxiliary key images are an artifact of proving the primary image is legitimate, since the aggregate private key $w_{\pi}$, which contains all the private keys, is applied to base point $\mathcal{H}_p(K_{\pi,1})$. + + +\subsection*{Linkability} + +If a private key \(k_{\pi, 1}\) is re-used to make any signature, the corresponding primary key image \(\tilde{K}_1\) supplied in the signature will reveal it. Auxiliary key images are ignored, as they only exist to facilitate the `Concise' part of CLSAG. + + +\subsection*{Space requirements} + +We store (1+$n$) integers, have $m$ key images, and use $m*n$ public keys. + +%NOTE: in Monero CLSAG key prefixing is a bit different. +%\[c_{i+1} = \mathcal{H}_n(T_c, one-time addresses, output commitments, pseudo output commitment, \mathfrak{m}, [r_i G + c_i W_i], [r_{i} \mathcal{H}_p(K_{i,1}) + c_i \tilde{W}])\] \ No newline at end of file diff --git a/translations/es/content/appendix.tex b/translations/es/content/appendix.tex new file mode 100755 index 0000000..e3ae815 --- /dev/null +++ b/translations/es/content/appendix.tex @@ -0,0 +1,360 @@ +\begin{appendices} + +\renewcommand{\theFancyVerbLine}{% + \textcolor{red}{\small + \arabic{FancyVerbLine}}} + +\chapter{{\tt RCTTypeBulletproof2} Transaction Structure} +\label{appendix:RCTTypeBulletproof2} + +We present in this appendix a dump from a real Monero transaction of type {\tt RCTTypeBulletproof2}, +together with explanatory notes for relevant fields. + +The dump was obtained from the block explorer \url{https://xmrchain.net}. It can also be acquired by executing command {\tt print\_tx +hex +json} in the {\tt monerod} daemon run in non-detached mode. {\tt } is a hash of the transaction (Section \ref{subsec:transaction-id}). The first line printed shows the actual command to run.% see chapter 7 blockchain on TransactionID + +To replicate our results, readers can do the following:%\footnote{Blockchain data can also be found with a web block explorer, such as \url{https://moneroblocks.info/} or \url{https://xmrchain.net}.} +\begin{enumerate} + \item We need the Monero command line tool (CLI), which can be found at \url{https://web.getmonero.org/downloads/} (among other places). Get the `Command Line Tools Only' for your operating system, move the file to a useful location, and unzip it. + \item Open the terminal/command line and navigate into the folder created by unzipping. + \item Run {\tt monerod} with {\tt ./monerod}. Now the Monero blockchain will download. Unfortunately, there is currently no easy way to print transactions on your own system (e.g. without using a block explorer) without downloading the blockchain. + \item After the syncing process is done, commands like {\tt print\_tx} will work. Use {\tt help} to learn other commands. +\end{enumerate} + +%For editorial reasons we have shortened long hexadecimal chains, presenting only the beginning and end as in {\tt 0200010c7f[...]409}. + +Component {\tt rctsig\_prunable}, as indicated by its name, is {\sl prunable} from the blockchain. That is, once a block has been consensuated and the current chain length rules out all possibilities of double-spending attacks, this whole field can be pruned and replaced with its hash for the Merkle tree. + +Key images are stored separately, in the non-prunable area of transactions. These are essential for detecting double-spend attacks and can’t be pruned away. +\\ + +Our sample transaction has 2 inputs and 2 outputs, and was added to the blockchain at timestamp 2020-03-02 19:01:10 UTC (as reported by its block's miner). + +\begin{Verbatim}[commandchars=\\\{\}, numbers=left] +print_tx 84799c2fc4c18188102041a74cef79486181df96478b717e8703512c7f7f3349 +Found in blockchain at height 2045821 +\{ + "version": 2, + "unlock_time": 0, + "vin": [ \{ + "key": \{ + "amount": 0, + "key_offsets": [ 14401866, 142824, 615514, 18703, 5949, 22840, 5572, 16439, + 983, 4050, 320 + ], + "k_image": "c439b9f0da76ca0bb17920ca1f1f3f1d216090751752b091bef9006918cb3db4" + \} + \}, \{ + "key": \{ + "amount": 0, + "key_offsets": [ 14515357, 640505, 8794, 1246, 20300, 18577, 17108, 9824, 581, + 637, 1023 + ], + "k_image": "03750c4b23e5be486e62608443151fa63992236910c41fa0c4a0a938bc6f5a37" + \} + \} + ], + "vout": [ \{ + "amount": 0, + "target": \{ + "key": "d890ba9ebfa1b44d0bd945126ad29a29d8975e7247189e5076c19fa7e3a8cb00" + \} + \}, \{ + "amount": 0, + "target": \{ + "key": "dbec330f8a67124860a9bfb86b66db18854986bd540e710365ad6079c8a1c7b0" + \} + \} + ], + "extra": [ 1, 3, 39, 58, 185, 169, 82, 229, 226, 22, 101, 230, 254, 20, 143, + 37, 139, 28, 114, 77, 160, 229, 250, 107, 73, 105, 64, 208, 154, 182, 158, 200, + 73, 2, 9, 1, 12, 76, 161, 40, 250, 50, 135, 231 + ], + "rct_signatures": \{ + "type": 4, + "txnFee": 32460000, + "ecdhInfo": [ \{ + "amount": "171f967524e29632" + \}, \{ + "amount": "5c2a1a9f54ccf40b" + \}], + "outPk": [ "fed8aded6914f789b63c37f9d2eb5ee77149e1aa4700a482aea53f82177b3b41", + "670e086e40511a279e0e4be89c9417b4767251c5a68b4fc3deb80fdae7269c17"] + \}, + "rctsig_prunable": \{ + "nbp": 1, + "bp": [ \{ + "A": "98e5f23484e97bb5b2d453505db79caadf20dc2b69dd3f2b3dbf2a53ca280216", + "S": "b791d4bc6a4d71de5a79673ed4a5487a184122321ede0b7341bc3fdc0915a796", + "T1": "5d58cfa9b69ecdb2375647729e34e24ce5eb996b5275aa93f9871259f3a1aecd", + "T2": "1101994fea209b71a2aa25586e429c4c0f440067e2b197469aa1a9a1512f84b7", + "taux": "b0ad39da006404ccacee7f6d4658cf17e0f42419c284bdca03c0250303706c03", + "mu": "cacd7ca5404afa28e7c39918d9f80b7fe5e572a92a10696186d029b4923fa200", + "L": [ "d06404fc35a60c6c47a04e2e43435cb030267134847f7a49831a61f82307fc32", + "c9a5932468839ee0cda1aa2815f156746d4dce79dab3013f4c9946fce6b69eff", + "efdae043dcedb79512581480d80871c51e063fe9b7a5451829f7a7824bcc5a0b", + "56fd2e74ac6e1766cfd56c8303a90c68165a6b0855fae1d5b51a2e035f333a1d", + "81736ed768f57e7f8d440b4b18228d348dce1eca68f969e75fab458f44174c99", + "695711950e076f54cf24ad4408d309c1873d0f4bf40c449ef28d577ba74dd86d", + "4dc3147619a6c9401fec004652df290800069b776fe31b3c5cf98f64eb13ef2c" + ], + "R": [ "7650b8da45c705496c26136b4c1104a8da601ea761df8bba07f1249495d8f1ce", + "e87789fbe99a44554871fcf811723ee350cba40276ad5f1696a62d91a4363fa6", + "ebf663fe9bb580f0154d52ce2a6dae544e7f6fb2d3808531b0b0749f5152ddbf", + "5a4152682a1e812b196a265a6ba02e3647a6bd456b7987adff288c5b0b556ec6", + "dc0dcb2e696e11e4b62c20b6bfcb6182290748c5de254d64bf7f9e3c38fb46c9", + "101e2271ced03b229b88228d74b36088b40c88f26db8b1f9935b85fb3ab96043", + "b14aae1d35c9b176ac526c23f31b044559da75cf95bc640d1005bfcc6367040b" + ], + "a": "4809857de0bd6becdb64b85e9dfbf6085743a8496006b72ceb81e01080965003", + "b": "791d8dc3a4ddde5ba2416546127eb194918839ced3dea7399f9c36a17f36150e", + "t": "aace86a7a1cbdec3691859fa07fdc83eed9ca84b8a064ca3f0149e7d6b721c03" + \} + ], + "MGs": [ \{ + "ss": [[ "d7a9b87cfa74ad5322eedd1bff4c4dca08bcff6f8578a29a8bc4ad6789dee106", + "f08e5dfade29d2e60e981cb561d749ea96ddc7e6855f76f9b807842d1a17fe00"], + ["de0a86d12be2426f605a5183446e3323275fe744f52fb439041ad2d59136ea0b", + "0028f97976630406e12c54094cbbe23a23fe5098f43bcae37339bfc0c4c74c07"], + ["f6eef1f99e605372cb1ec2b3dd4c6e56a550fec071c8b1d830b9fda34de5cc05", + "cd98fc987374a0ac993edf4c9af0a6f2d5b054f2af601b612ea118f405303306"], + ["5a8437575dae7e2183a1c620efbce655f3d6dc31e64c96276f04976243461e08", + "5090103f7f73a33024fbda999cd841b99b87c45fa32c4097cdc222fa3d7e9502"], + ["88d34246afbccbd24d2af2ba29d835813634e619912ea4ca194a32281ac14e0e", + "eacdf59478f132dd8dbb9580546f96de194092558ffceeff410ee9eb30ce570e"], + ["571dab8557921bbae30bda9b7e613c8a0cff378d1ec6413f59e4972f30f2470d", + "5ca78da9a129619299304d9b03186233370023debfdaddcd49c1a338c1f0c50d"], + ["ac8dbe6bb28839cf98f02908bd1451742a10c713fdd51319f2d42a58bf1d7507", + "7347bf16cba5ee6a6f2d4f6a59d1ed0c1a43060c3a235531e7f1a75cd8c8530d"], + ["b8876bd3a5766150f0fbc675ba9c774c2851c04afc4de0b17d3ac4b6de617402", + "e39f1d2452d76521cbf02b85a6b626eeb5994f6f28ce5cf81adc0ff2b8adb907"], + ["1309f8ead30b7be8d0c5932743b343ef6c0001cef3a4101eae98ffde53f46300", + "370693fa86838984e9a7232bca42fd3d6c0c2119d44471d61eee5233ba53c20f"], + ["80bc2da5fc5951f2c7406fce37a7aa72ffef9cfa21595b1b68dfab4b7b9f9f0c", + "c37137898234f00bce00746b131790f3223f97960eefe67231eb001092f5510c"], + ["01c89e07571fd365cac6744b34f1b44e06c1c31cbf3ee4156d08309345fdb20e", + "a35c8786695a86c0a4e677b102197a11dadc7171dd8c2e1de90d828f050ec00f"]], + "cc": "0d8b70c600c67714f3e9a0480f1ffc7477023c793752c1152d5df0813f75ff0f" + \}, \{ + "ss": [[ "4536e585af58688b69d932ef3436947a13d2908755d1c644ca9d6a978f0f0206", + "9aab6509f4650482529219a805ee09cd96bb439ee1766ced5d3877bf1518370b"], + ["5849d6bf0f850fcee7acbef74bd7f02f77ecfaaa16a872f52479ebd27339760f", + "96a9ec61486b04201313ac8687eaf281af59af9fd10cf450cb26e9dc8f1ce804"], + ["7fe5dcc4d3eff02fca4fb4fa0a7299d212cd8cd43ec922d536f21f92c8f93f00", + "d306a62831b49700ae9daad44fcd00c541b959da32c4049d5bdd49be28d96701"], + ["2edb125a5670d30f6820c01b04b93dd8ff11f4d82d78e2379fe29d7a68d9c103", + "753ac25628c0dada7779c6f3f13980dfc5b7518fb5855fd0e7274e3075a3410c"], + ["264de632d9cb867e052f95007dfdf5a199975136c907f1d6ad73061938f49c01", + "dd7eb6028d0695411f647058f75c42c67660f10e265c83d024c4199bed073d01"], + ["b2ac07539336954f2e9b9cba298d4e1faa98e13e7039f7ae4234ac801641340f", + "69e130422516b82b456927b64fe02732a3f12b5ee00c7786fe2a381325bf3004"], + ["49ea699ca8cf2656d69020492cdfa69815fb69145e8f922bb32e358c23cebb0f", + "c5706f903c04c7bed9c74844f8e24521b01bc07b8dbf597621cceeeb3afc1d0c"], + ["a1faf85aa942ba30b9f0511141fcab3218c00953d046680d36e09c35c04be905", + "7b6b1b6fb23e0ee5ea43c2498ea60f4fcf62f70c7e0e905eb4d9afa1d0a18800"], + ["785d0993a70f1c2f0ac33c1f7632d64e34dd730d1d8a2fb0606f5770ed633506", + "e12777c49ffc3f6c35d27a9ccb3d9b8fed7f0864a880f7bae7399e334207280e"], + ["ab31972bf1d2f904d6b0bf18f4664fa2b16a1fb2644cd4e6278b63ade87b6d09", + "1efb04fe9a75c01a0fe291d0ae00c716e18c64199c1716a086dd6e32f63e0a07"], + ["a6f4e21a27bf8d28fc81c873f63f8d78e017666adbf038da0b83c2ad04ef6805", + "c02103455f93c2d7ec4b7152db7de00d1c9e806b1945426b6773026b4a85dd03"]], + "cc": "d5ac037bb78db41cf924af713b7379c39a4e13901d3eac017238550a1a3b910a" + \}], + "pseudoOuts": [ "b313c1ae9ca06213684fbdefa9412f4966ad192bc0b2f74ed1731381adb7ab58", + "7148e7ef5cfd156c62a6e285e5712f8ef123575499ff9a11f838289870522423"] + \} +\} +\end{Verbatim} + + + +\section*{Transaction components} + +\begin{itemize} + \item (line 2) - The command {\tt print\_tx} would report the block where it found the transaction, which we replicate here for demonstration purposes. + \item {\tt version} (line 4) - Transaction format/era version; `2' corresponds to RingCT. + \item {\tt unlock\_time} (line 5) - Prevents a transaction's outputs from being spent until the time has past. It is either a block height, or a UNIX timestamp if the number is larger than the beginning of UNIX time. It defaults to zero when no limit is specified. + \item {\tt vin} (line 6-23) - List of inputs (there are two here) + \item {\tt amount} (line 8) - Deprecated (legacy) amount field for type 1 transactions + \item {\tt key\_offset} (line 9) - This allows verifiers to find ring member keys and commitments in the blockchain, and makes it obvious those members are legitimate. The first offset is absolute within the blockchain history, and each subsequent offset is relative to the previous. For example, with real offsets \{7,11,15,20\}, the blockchain records \{7,4,4,5\}. Verifiers compute the last offset like (7+4+4+5 = 20) (Section \ref{subsec:space-and-ver-rcttypefull}). + \item {\tt k\_image} (line 12) - Key image \(\tilde{K_j}\) from Section \ref{sec:MLSAG}, where $j = 1$ since this is the first input. + \item {\tt vout} (lines 24-35) - List of outputs (there are two here) + \item {\tt amount} (line 25) - Deprecated amount field for type 1 transactions + \item {\tt key} (line 27) - One-time destination key for output $t = 0$ as described in Section \ref{sec:one-time-addresses} + \item {\tt extra} (lines 36-39) - Miscellaneous\marginnote{src/crypto- note\_basic/ tx\_extra.h} data, including the {\em transaction public key}, i.e. the share secret $r G$ of Section \ref{sec:one-time-addresses}, and encrypted payment ID from Section \ref{sec:integrated-addresses}. It typically works like this: each number is one byte (it can be 0-255), and each kind of thing that can be in the field has a `tag' and `length'. The tag indicates which information comes next, and length indicates how many bytes that info occupies. The first number is always a tag. Here, `1' indicates a `transaction public key'. Tx public keys are always 32 bytes, so we don't need to include the length. Thirty-two numbers later we find a new tag `2' which means `extra nonce', its length is `9', and the next byte is `1' which means an 8-byte encrypted payment ID (the extra nonce can have fields inside it, for some reason). Eight bytes go by, and that's the end of this extra field. See \cite{extra-field-stackexchange} for more details. (note: in the original Cryptonote specification the first byte indicated the size of the field. Monero doesn't use that.) \cite{tx-extra-field} + \item {\tt rct\_signatures} (lines 40-50) - First part of signature data + \item {\tt type} (line 41) - Signature type; {\tt RCTTypeBulletproof2} is type 4. Deprecated RingCT types {\tt RCTTypeFull} and {\tt RCTTypeSimple} were 1 and 2 respectively. Miner transactions use {\tt RCTTypeNull}, type 0. + \item {\tt txnFee} (line 42) - Transaction fee in clear text, in this case 0.00003246 XMR + \item {\tt ecdhInfo} (lines 43-47) - ‘elliptic curve diffie-hellman info’: Obscured amount for each of the outputs $t \in \{0, ..., p-1\}$; here $p = 2$ + \item {\tt amount} (line 44) - Field {\sl amount} at $t = 0$ as described in Section \ref{sec:pedersen_monero} + \item {\tt outPk} (lines 48-49) - Commitments for each output, Section \ref{sec:ringct-introduction} + + \item {\tt rctsig\_prunable} (lines 51-132) - Second part of signature data + \item {\tt nbp} (line 52) - Number of Bulletproof range proofs in this transaction + \item {\tt bp} (lines 53-80) - Bulletproof proof elements (Bulletproofs were not explored in this document, so we will not itemize further)\vspace{.175cm} + \[\Pi_{BP} = (A, S, T_1, T_2, \tau_x, \mu, \mathbb{L}, \mathbb{R}, a, b, t)\] + \item {\tt MGs} (lines 81-129) - MLSAG signatures + \item {\tt ss} (lines 82-103) - Components \(r_{i,1}\) and \(r_{i,2}\) from the first input's MLSAG signature\vspace{.175cm} + \[\sigma_j(\mathfrak{m}) = (c_1, r_{1, 1}, r_{1, 2}, ..., r_{v+1, 1}, r_{v+1, 2})\] + \item {\tt cc} (line 104) - Component \(c_1\) from aforementioned MLSAG signature + \item {\tt pseudoOuts} (lines 130-131) - Pseudo output commitments $C'^a_j$, as described in Section \ref{sec:pedersen_monero}. Please recall that the sum of these commitments will equal the sum of the two output commitments of this transaction (plus the transaction fee commitment $f H$). +\end{itemize} + + + + +\chapter{Block Content} +\label{appendix:block-content} + +In this appendix we show the structure of a sample block, namely the 1582196\nth block after the genesis block. The block has 5 transactions, and was added to the blockchain at timestamp 2018-05-27 21:56:01 UTC (as reported by the block's miner). + +\begin{Verbatim}[commandchars=\\\{\}, numbers=left] +print_block 1582196 +timestamp: 1527458161 +previous hash: 30bb9b475a08f2ea6fe07a1fd591ea209a7f633a400b2673b8835a975348b0eb +nonce: 2147489363 +is orphan: 0 +height: 1582196 +depth: 2 +hash: 50c8e5e51453c2ab85ef99d817e166540b40ef5fd2ed15ebc863091ca2a04594 +difficulty: 51333809600 +reward: 4634817937431 +\{ + "major_version": 7, + "minor_version": 7, + "timestamp": 1527458161, + "prev_id": "30bb9b475a08f2ea6fe07a1fd591ea209a7f633a400b2673b8835a975348b0eb", + "nonce": 2147489363, + "miner_tx": \{ + "version": 2, + "unlock_time": 1582256, + "vin": [ \{ + "gen": \{ + "height": 1582196 + \} + \} + ], + "vout": [ \{ + "amount": 4634817937431, + "target": \{ + "key": "39abd5f1c13dc6644d1c43db68691996bb3cd4a8619a37a227667cf2bf055401" + \} + \} + ], + "extra": [ 1, 89, 148, 148, 232, 110, 49, 77, 175, 158, 102, 45, 72, 201, 193, + 18, 142, 202, 224, 47, 73, 31, 207, 236, 251, 94, 179, 190, 71, 72, 251, 110, + 134, 2, 8, 1, 242, 62, 180, 82, 253, 252, 0 + ], + "rct_signatures": \{ + "type": 0 + \} + \}, + "tx_hashes": [ "e9620db41b6b4e9ee675f7bfdeb9b9774b92aca0c53219247b8f8c7aecf773ae", + "6d31593cd5680b849390f09d7ae70527653abb67d8e7fdca9e0154e5712591bf", + "329e9c0caf6c32b0b7bf60d1c03655156bf33c0b09b6a39889c2ff9a24e94a54", + "447c77a67adeb5dbf402183bc79201d6d6c2f65841ce95cf03621da5a6bffefc", + "90a698b0db89bbb0704a4ffa4179dc149f8f8d01269a85f46ccd7f0007167ee4" + ] +\} +\end{Verbatim} + + + +\section*{Block components} + +\begin{itemize} + \item (lines 2-10) - Block information collected by software, not actually part of the block properly speaking. + \item {\tt is orphan} (line 5) - Signifies if this block was orphaned. Nodes usually store all branches during a fork situation, and discard unnecessary branches when a cumulative difficulty winner emerges, thereby orphaning the blocks. + \item {\tt depth} (line 7) - In a blockchain copy, the depth of any given block is how far back in the chain it is relative to the most recent block. + \item {\tt hash} (line 8) - This block's block ID. + \item {\tt difficulty} (line 9) - Difficulty isn't stored in a block, since users can compute {\em all} block difficulties from block timestamps and the rules in Section \ref{sec:difficulty}. + \item {\tt major\_version} (line 12) - Corresponds to the protocol version used to verify this block. + \item {\tt minor\_version} (line 13) - Originally intended as a voting mechanism among miners, it now merely reiterates the {\tt major\_version}. Since the field does not occupy much space, the developers probably thought deprecating it would not be worth the effort. + \item {\tt timestamp} (line 14) - An integer representation of this block's UTC timestamp, as reported by the block's miner. + \item {\tt prev\_id} (line 15) - The previous block's block ID. Herein lies the essence of Monero's blockchain. + \item {\tt nonce} (line 16) - The nonce used by this block's miner to pass its difficulty target. Anyone can recompute the proof of work and verify the nonce is valid. + \item {\tt miner\_tx} (lines 17-40) - This block's miner transaction. + \item {\tt version} (line 18) - Transaction format/era version; `2' corresponds to RingCT. + \item {\tt unlock\_time} (line 19) - The miner transaction's output can't be spent until the 1582256\nth block, after 59 more blocks have been mined (it is a 60 block lock time since it can't be spent until 60 block time intervals have passed, e.g. $2*60 = 120$ minutes). + \item {\tt vin} (lines 20-25) - Inputs to the miner tx. There are none, since the miner tx is used to generate block rewards and collect transaction fees. + \item {\tt gen} (line 21) - Short for `generate'. + \item {\tt height} (line 22) - The block height for which this miner tx's block reward was generated. Each block height can only generate a block reward once. + \item {\tt vout} (lines 26-32) - Outputs of the miner tx. + \item {\tt amount} (line 27) - Amount dispersed by the miner tx, containing block reward and fees from this block's transactions. Recorded in atomic units. + \item {\tt key} (line 29) - One-time address assigning ownership of the miner tx's amount. + \item {\tt extra} (lines 33-36) - Extra information for the miner tx, including the transaction public key. + \item {\tt type} (line 38) - Type of transaction, in this case `0' for {\tt RCTTypeNull}, indicating a miner tx. + \item {\tt tx\_hashes} (lines 41-46) - All transaction IDs included in this block (but not the miner tx ID, which is {\tt 06fb3e1cf889bb972774a8535208d98db164394ef2b14ecfe74814170557e6e9}). +\end{itemize} + + + + +\chapter{Genesis Block} +\label{appendix:genesis-block} + +In this appendix we show the structure of the Monero genesis block. The block has 0 transactions (it just sends the first block reward to thankful\_for\_today \cite{bitmonero-launched}). Monero's founder did not add a timestamp, perhaps as a relic of Bytecoin, the coin Monero's code was forked from, whose creators apparently tried to hide a large pre-mine \cite{monero-history}, and may operate a shady network of cryptocurrency-related software and services \cite{bytecoin-network}. + +Block 1 was added to the blockchain at timestamp 2014-04-18 10:49:53 UTC (as reported by the block's miner), so we can assume the genesis block was created the same day. This corresponds with the launch date announced by thankful\_for\_today \cite{bitmonero-launched}. + +\begin{Verbatim}[commandchars=\\\{\}, numbers=left] +print_block 0 +timestamp: 0 +previous hash: 0000000000000000000000000000000000000000000000000000000000000000 +nonce: 10000 +is orphan: 0 +height: 0 +depth: 1580975 +hash: 418015bb9ae982a1975da7d79277c2705727a56894ba0fb246adaabb1f4632e3 +difficulty: 1 +reward: 17592186044415 +\{ + "major_version": 1, + "minor_version": 0, + "timestamp": 0, + "prev_id": "0000000000000000000000000000000000000000000000000000000000000000", + "nonce": 10000, + "miner_tx": \{ + "version": 1, + "unlock_time": 60, + "vin": [ \{ + "gen": \{ + "height": 0 + \} + \} + ], + "vout": [ \{ + "amount": 17592186044415, + "target": \{ + "key": "9b2e4c0281c0b02e7c53291a94d1d0cbff8883f8024f5142ee494ffbbd088071" + \} + \} + ], + "extra": [ 1, 119, 103, 170, 252, 222, 155, 224, 13, 207, 208, 152, 113, 94, 188, + 247, 244, 16, 218, 235, 197, 130, 253, 166, 157, 36, 162, 142, 157, 11, 200, 144, + 209 + ], + "signatures": [ ] + \}, + "tx_hashes": [ ] +\} +\end{Verbatim} + + + +\section*{Genesis block components} + +Since we used the same software to print the genesis block and the block from Appendix \ref{appendix:block-content}, the structure appears basically the same. We point out some unique differences. + +\begin{itemize} + \item {\tt difficulty} (line 9) - The genesis block's difficulty is reported as 1, which means any nonce could work. + \item {\tt timestamp} (line 14) - The genesis block doesn't have a meaningful timestamp. + \item {\tt prev\_id} (line 15) - We use an empty 32 bytes for the previous ID, by convention. + \item {\tt nonce} (line 16) - $n = 10000$ by convention. + \item {\tt amount} (line 27) - This exactly corresponds to our calculation for the first block reward (17.592186044415 XMR) in Section \ref{subsec:block-reward}. + \item {\tt key} (line 29) - The very first Moneroj were dispersed to Monero's founder thankful\_for\_today. + \item {\tt extra} (lines 33-36) - Using the encoding discussed in Appendix \ref{appendix:RCTTypeBulletproof2}, the genesis block's miner tx {\tt extra} field just contains one transaction public key. + \item {\tt signatures} (line 37) - There are no signatures in the genesis block. This is here as an artifact of the {\tt print\_block} function. The same is true for {\tt tx\_hashes} in line 39. +\end{itemize} + + +\end{appendices} \ No newline at end of file diff --git a/translations/es/content/basicConcepts.tex b/translations/es/content/basicConcepts.tex new file mode 100755 index 0000000..2f64293 --- /dev/null +++ b/translations/es/content/basicConcepts.tex @@ -0,0 +1,519 @@ +\chapter{Basic Concepts} +\label{chapter:basicConcepts} + + + +%----------NOTATION +\section{A few words about notation} + +A focal objective of this report was to collect, review, correct, and homogenize all existing information concerning the inner workings of the Monero cryptocurrency. And, at the same time supply all the necessary details to present the material in a constructive and single-threaded manner. + +An important instrument to achieve this was to settle for a number of notational conventions. Among others, we have used: + +\begin{itemize} +\item lower case letters to denote simple values, integers, strings, bit representations, etc. +\item upper case letters to denote curve points and complicated constructs +\end{itemize} + +For items with a special meaning, we have tried to use as much as possible the same symbols throughout the document. For instance, a curve generator is always denoted by \(G\), its order is \(l\), private/public keys are denoted whenever possible by \(k/K\) respectively, etc. +\\ + +Beyond that, we have aimed at being {\em conceptual} in our presentation of algorithms and schemes. A reader with a computer science background may feel we have neglected questions like the bit representation of items, or, in some cases, how to carry out concrete operations. Moreover, students of mathematics may find we disregarded explanations of abstract algebra. + +However, we don’t see this as a loss. A simple object such as an integer or a string can always be represented by a bit string. So-called `endianness' is rarely relevant, and is mostly a matter of convention for our algorithms.\footnote{In computer memory, each byte is stored in its own address (an address is akin to a numbered slot, which a byte can be stored in). A given `word' or variable is referenced by the lowest address of its bytes. If variable $x$ has 4 bytes, stored in addresses 10-13, address 10 is used to find $x$. The way bytes of $x$ are organized in its set of addresses depends on {\em endianness}, although each individual byte is always and everywhere stored the same way within its address. Basically, which end of $x$ is stored in the reference address? It could be the {\em big end} or {\em little end}. Given $x = $ 0x12345678 (hexadecimal, 2 hexadecimal digits occupy 1 byte e.g. 8 binary digits a.k.a. bits), and an array of addresses \{10, 11, 12, 13\}, the big endian encoding of $x$ is \{12, 34, 56, 78\} and the little endian encoding is \{78, 56, 34, 12\}. \cite{endianness}} + +Elliptic curve points are normally denoted by pairs \((x, y)\), and can therefore be represented with two integers. However, in the world of cryptography it is common to apply {\em point compression} techniques, which allow representing a point using only the space of one coordinate. For our conceptual approach it is often accessory whether point compression is used or not, but most of the time it is implicitly assumed.\\ + +We\marginnote{src/crypto/ {\tt keccak.c}} have also used cryptographic hash functions freely without specifying any concrete algorithms. In the case of Monero it will typically be a \(\mathit{Keccak}\)\footnote{\label{kekkak_note}The Keccak hashing algorithm forms the basis for the NIST standard {\em SHA-3} \cite{nist-sha3}.} variant, but if not explicitly mentioned then it is not important to the theory. + +A cryptographic hash function (henceforth simply `hash function', or `hash') takes in some message $\mathfrak{m}$ of arbitrary length and returns a hash $h$ (or `message digest') of fixed length, with each possible output equiprobable for a given input. Cryptographic hash functions are difficult to reverse, have an interesting feature known as the {\em large avalanche effect} which can cause very similar messages to produce very dissimilar hashes, and it is hard to find two messages with the same message digest. + +Hash functions will be applied to integers, strings, curve points, or combinations of these objects. These occurrences should be interpreted as hashes of bit representations, or the concatenation of such representations. Depending on context, the result of a hash will be numeric, a bit string, or even a curve point. Further details in this respect will be given as needed. + + + +%----------MODULAR ARITHMETIC +\section{Modular arithmetic} +\label{sec:modular-arithmetic} + +Most modern cryptography begins with modular arithmetic, which in turn begins with the modulus operation (denoted `mod'). We only care about the positive modulus, which always returns a positive integer. + +The positive modulus is similar to the `remainder' after dividing two numbers, e.g. $c$ the `remainder' of $a/b$. Let's imagine a number line. To calculate $c = a \pmod b$ we stand at point $a$ then walk toward zero with each $\text{step} = b$ until we reach an integer $\geq{0}$ and $ b$ then $c = a+b$, otherwise $c = b - x$. +\end{itemize} + +We can use modular addition to achieve modular multiplication ($a*b \pmod n = c$) with an algorithm called `double-and-add'. Let us demonstrate by example. Say we want to do $7*8 \pmod 9 = 2$. It is the same as +\[7*8 = 8+8+8+8+8+8+8 \pmod 9\] + +Now break this into groups of two. +\[(8+8) + (8+8) + (8+8) + 8\] + +And again, by groups of two. +\[[(8+8) + (8+8)] + (8+8) + 8\] + +The total number of $+$ point operations falls from 6 to 4 because we only need to find $(8+8)$ once.\footnote{The effect of double-and-add becomes apparent with large numbers. For example, with $2^{15} * 2^{30}$ straight addition would require about $2^{15}$ $+$ operations, while double-and-add only requires 15!}\\ + +Double-and-add is implemented by converting the first number (the `multiplicand' $a$) to binary (in our example, 7 $\rightarrow$ [0111]), then going through the binary array and doubling and adding. + +Let's make an array $A = [0111]$ and index it 3,2,1,0.\footnote{This is known as `LSB 0' numbering, since the least significant bit has index 0. We will use `LSB 0' for the rest of this chapter. The point here is clarity, not accurate conventions.} A[0] = 1 is the first element of A and is the least significant bit. We set a result variable to be initially $r = 0$, and set a sum variable to be initially $s = 8$ (more generally, we start with $s = b$). We follow this algorithm: +\begin{enumerate} + \item Iterate through: $i = (0,...,A_{size} - 1)$ + \begin{enumerate} + \item If A[i] == 1, then $r = r + s \pmod n$. + \item Compute $s = s + s \pmod n$. + \end{enumerate} + \item Use the final $r$: $c = r$. +\end{enumerate} + +In our example $7*8 \pmod 9$, this sequence appears: +\begin{enumerate} + \item $i = 0$ + \begin{enumerate} + \item A[0] = 1, so $r = 0 + 8 \pmod 9$ = 8 + \item $s = 8 + 8 \pmod 9$ = 7 + \end{enumerate} + \item $i = 1$ + \begin{enumerate} + \item A[1] = 1, so $r = 8 + 7 \pmod 9$ = 6 + \item $s = 7 + 7 \pmod 9$ = 5 + \end{enumerate} + \item $i = 2$ + \begin{enumerate} + \item A[2] = 1, so $r = 6 + 5 \pmod 9$ = 2 + \item $s = 5 + 5 \pmod 9$ = 1 + \end{enumerate} + \item $i = 3$ + \begin{enumerate} + \item A[3] = 0, so $r$ stays the same + \item $s = 1 + 1 \pmod 9$ = 2 + \end{enumerate} + \item $r = 2$ is the result +\end{enumerate} + + +\subsection{Modular exponentiation} + +Clearly $8^7 \pmod 9 = 8*8*8*8*8*8*8 \pmod 9$. Just like double-and-add, we can do square-and-multiply. For $a^e \pmod{n}$: +\begin{enumerate} + \item Define $e_{scalar} \rightarrow e_{binary}$; $A = [e_{binary}]$; $r = 1$; $m = a$ + \item Iterate through: $i = (0,...,A_{size} - 1)$ + \begin{enumerate} + \item If A[i] == 1, then $r = r * m \pmod n$. + \item Compute $m = m * m \pmod n$. + \end{enumerate} + \item Use the final $r$ as result. +\end{enumerate} + + +\subsection{Modular multiplicative inverse} + +Sometimes we need $1/a \pmod n$, or in other words $a^{-1} \pmod n$. The inverse of something times itself is by definition one (identity). Imagine $0.25 = 1/4$, and then $0.25*4 = 1$.\\ + +In modular arithmetic, for $c = a^{-1} \pmod{n}$, $a c \equiv 1 \pmod{n}$ for $0 \leq c < n$ and for $a$ and $n$ relatively prime.\footnote{In the equation $a \equiv b \pmod{n}$, $a$ is {\em congruent} to $b \pmod{n}$, which just means \(a \pmod{n} = b \pmod{n}\).} Relatively prime means they don't share any divisors except 1 (the fraction $a/n$ can't be reduced/simplified). + +We can use square-and-multiply to compute the modular multiplicative inverse when $n$ is a prime number because of {\em Fermat's little theorem}:\footnote{\label{inverse_rule_note}The modular multiplicative inverse has a rule stating:\\ +{\em If $a c \equiv b \pmod{n}$ with $a$ and $n$ relatively prime, the solution to this linear congruence is given by \(c = a^{-1} b \pmod{n}\).}\cite{wiki-modular-arithmetic}\\ +It means we can do $c = a^{-1} b \pmod n \rightarrow ca \equiv b \pmod n \rightarrow a \equiv c^{-1} b \pmod n$.}\vspace{.175cm} +\begin{align*} + a^{n-1} &\equiv 1 \pmod{n} \\ + a*a^{n-2} &\equiv 1 \pmod{n} \\ + c \equiv a^{n-2} &\equiv a^{-1} \pmod{n} +\end{align*} + +More generally (and more rapidly), the so-called `extended Euclidean algorithm' \cite{extended-euclidean} can also find modular inverses. + + +\subsection{Modular equations} +\label{subsec:modular-equations} + +Suppose we have an equation $c = 3*4*5 \pmod 9$. Computing this is straightforward. Given some operation $\circ$ (for example, $\circ = *$) between two expressions $A$ and $B$:\vspace{.175cm} +\[(A \circ B)\pmod{n} = {[A\pmod {n}] \circ [B\pmod{n}]}\pmod{n}\] + +In our example, we set $A = 3*4$, $B = 5$, and $n = 9$:\vspace{.175cm} +\begin{align*} +(3*4 * 5) \pmod{9} &= {[3*4 \pmod {9}] * [5 \pmod{9}]} \pmod{9} \\ + &= [3]*[5] \pmod 9 \\ + c &= 6 +\end{align*} + +Now we have a way to do modular subtraction.\vspace{.175cm} +\begin{align*} +A - B \pmod n &\rightarrow A + (-B) \pmod n \\ + &\rightarrow {[A \pmod {n}] + [-B \pmod{n}]} \pmod{n} +\end{align*}\\ + +The same principle would apply to something like $x = (a-b*c*d)^{-1} (e*f+g^{h}) \pmod n$.\footnote{The modulus of large numbers can exploit modular equations. It turns out $254 \pmod {13} \equiv 2*10*10 + 5*10 + 4 \equiv (((2)*10 + 5)*10 + 4) \pmod {13}$. An algorithm for $a \pmod n$ when $a > n$ is: +\begin{enumerate} + \item Define $A \rightarrow [a_{decimal}]$; $r = 0$ + \item For $i = A_{size} - 1,...,0$ + \begin{enumerate} + \item $r = (r*10 + A[i]) \pmod n$ + \end{enumerate} + \item Use the final $r$ as result. +\end{enumerate}} + + + +%----------ELLIPTIC CURVE CRYPTOGRAPHY +\section{Elliptic curve cryptography} +\label{EllipticCurveCryptography} + + +\subsection{What are elliptic curves?} +\label{elliptic_curves_section} + +A\marginnote{{\tt fe}: field element} finite field \(\mathbb{F}_q\), where \(q\) is a prime number greater than 3, is the field formed by the set \(\{0, 1, 2, ..., q-1\}\). Addition and multiplication \((+, \cdot)\) and negation $(-)$ are calculated\( \pmod q\). + +``Calculated\( \pmod q\)" means\( \pmod q\) is performed on any instance of an arithmetic operation between two field elements, or negation of a single field element. For example, given a prime field \(\mathbb{F}_p\) with $p = 29$, $17+20=8$ because $37 \pmod{29} = 8$. Also, $-13 = -13 \pmod{29} = 16$.\\ + +Typically, an elliptic curve with a given $(a,b)$ pair is defined as the set of all points with coordinates \((x, y)\) satisfying a {\em Weierstraß} equation \cite{Hankerson:2003:GEC:940321}:\footnote{\label{notation1}Notation: The phrase $a \in \mathbb{F}$ means $a$ is some element in the field $\mathbb{F}$.}\vspace{.175cm} +\[y^2 = x^3 + a x + b \quad \textrm{where} \quad a, b, x, y \in \mathbb{F}_q\] + +The cryptocurrency Monero uses a special curve belonging to the category of so-called {\em Twisted Edwards} curves \cite{Bernstein2008}, which are commonly expressed as (for a given $(a,d)$ pair):\vspace{.175cm} +\[a x^2 + y^2 = 1 + d x^2 y^2 \quad \textrm{where} \quad a, d, x, y \in \mathbb{F}_q \] + + +In what follows we will prefer this second form. The advantage it offers over the previously mentioned Weierstraß form is that basic cryptographic primitives require fewer arithmetic operations, resulting in faster cryptographic algorithms (see Bernstein {\em et al.} in \cite{Bernstein2007} for details).\\ + +Let \(P_1 = (x_1, y_1)\) and \(P_2 = (x_2, y_2)\) be two points belonging to a Twisted Edwards elliptic curve (henceforth known simply as an EC). We define addition on points by defining $P_1 + P_2 = (x_1, y_1) + (x_2, y_2)$ as the point $P_3 = (x_3, y_3)$ where\footnote{Typically elliptic curve points are converted into projective coordinates\marginnote{src/crypto/ crypto\_ops\_ builder/ ref10Comm- entedComb- ined/\\ ge.h} prior to curve operations like point addition, in order to avoid performing field inversions for efficiency. \cite{ecc-projective}}\vspace{.175cm} +\begin{align*} +x_3 & = \frac{x_1 y_2 + y_1 x_ 2}{1 + d x_1 x_2 y_1 y_2} \pmod{q} \\ +y_3 & = \frac{y_1 y_2 - a x_1 x_2}{1 - d x_1 x_2 y_1 y_2} \pmod{q} +\end{align*} + +These formulas for addition also apply for point doubling; that is, when \(P_1 = P_2\). To subtract a point, invert its coordinates over the y-axis, $(x,y) \rightarrow (-x,y)$ \cite{Bernstein2008}, and use point addition. Recall that `negative' elements $-x$ of $\mathbb{F}_q$ are really $-x \pmod{q}$. +\\ + +Whenever two curve points are added together $P_3$ is a point on the `original' elliptic curve, or in other words all $x_3,y_3 \in \mathbb{F}_q$ and satisfy the EC equation. + +Each point $P$ in EC can generate a subgroup of order (size) $u$ out of some of the other points in EC using multiples of itself. For example, some point $P$’s subgroup might have order 5 and contain the points $(0, P, 2P, 3P, 4P)$, each of which is in EC. At $5P$ the so-called {\em point-at-infinity} appears, which is like the `zero’ position on an EC, and has coordinates $(0, 1)$.\footnote{It turns out elliptic curves have {\em abelian group} structure under the addition operation described, since their point-at-infinity's are identity elements. A concise definition of this notion can be found under \url{https://brilliant.org/wiki/abelian-group/}.} + +Conveniently, $5P + P = P$. This means the subgroup is {\em cyclic}.\footnote{\label{cyclical_note}Cyclic subgroup means, for $P$'s subgroup with order $u$, and with any integer $n$, $n P = [n \pmod{u}] P$. We can imagine ourselves standing on a point on a globe some distance from a `zero'th position, and each step we take moves us that distance. After a while, we will wind up back where we started, although it may take many revolutions before we land exactly on the original spot again. The number of steps it takes to land on the exact same spot is the `order' of the `stepping group', and all our footprints are unique points in that group. We recommend applying this concept to other ideas discussed here.} All $P$ in EC generate a cyclic subgroup. If $P$ generates a subgroup whose order is prime, then all the included points (except for the point-at-infinity) generate that same subgroup. In our example, take multiples of point $2P$:\vspace{.175cm} +\[2P, 4P, 6P, 8P, 10P \rightarrow 2P, 4P, 1P, 3P, 0\] + +Another example: a subgroup with order 6 $(0, P, 2P, 3P, 4P, 5P)$. Multiples of point $2P$:\vspace{.175cm} +\[2P, 4P, 6P, 8P, 10P, 12P \rightarrow 2P, 4P, 0, 2P, 4P, 0\] +Here $2P$ has order 3. Since 6 is not prime, not all of its member points recreate the original subgroup. + +Each EC has an order $N$ equal to the total number of points in the curve (including the point-at-infinity), and the orders of all subgroups generated by points are divisors of $N$ (by {\em Lagrange’s theorem}). We can imagine a set of all EC points $\{0,P_1,...,P_{N-1}\}$. If $N$ isn't prime, some points will make subgroups with orders equal to divisors of $N$. + +To find the order, $u$, of any given point $P$'s subgroup: +\begin{enumerate} + \item Find $N$ (e.g. use {\em Schoof's algorithm}). + \item Find all the divisors of $N$. + \item For every divisor $n$ of $N$, compute $n P$. + \item The smallest $n$ such that $n P = 0$ is the order $u$ of the subgroup. +\end{enumerate} + +ECs\marginnote{{\tt ge}: group element} selected for cryptography typically have $N = hl$, where $l$ is some sufficiently large (such as 160 bits) prime number and $h$ is the so-called {\em cofactor} which could be as small as 1 or 2.\footnote{EC with small cofactors allow relatively faster point addition, etc. \cite{Bernstein2008}.} One point in the subgroup of size $l$ is usually selected to be the generator $G$ as a convention. For every other point $P$ in that subgroup there exists an integer $0 < n \leq l$ satisfying $P = n G$. + +Let's expand our understanding. Say there is a point $P'$ with order $N$, where $N=h l$. Any other point $P_i$ can be found with some integer $n_i$ such that $P_i=n_i P'$. If $P_1=n_1 P'$ has order $l$, any $P_2=n_2 P'$ with order $l$ must be in the same subgroup as $P_1$ because $l P_1=0 = l P_2$, and if $l(n_1 P') \equiv l(n_2 P') \equiv N P'=0$, then $n_1$ \& $n_2$ must both be multiples of $h$. Since $N= h l$, there are only $l$ multiples of $h$, implying only one subgroup of size $l$ is possible. + +Put simply, the subgroup formed by multiples of $(h P')$ always contains $P_1$ and $P_2$. Furthermore, $h(n' P')=0$ when $n'$ is a multiple of $l$, and there are only $h$ such variations of $n' \pmod N$ (including the point at infinity for $n' = hl$) because when $n' = h l$ it cycles back to 0: $h l P' = 0$. So, there are only $h$ points $P$ in EC where $h P$ will equal 0. + +A similar argument could be applied to any subgroup of size $u$. Any two points $P_1$ and $P_2$ with order $u$ are in the same subgroup, which is composed of multiples of $(N/u) P'$. +\\ \newline +With this new understanding it is clear we can use the following algorithm to find (non-point-at-infinity) points in the subgroup of order $l$: +\begin{enumerate} + \item Find $N$ of the elliptic curve EC, choose subgroup order $l$, compute $h=N/l$. + \item Choose a random point $P'$ in EC. + \item Compute $P=h P'$. + \item If $P=0$ return to step 2, else $P$ is in the subgroup of order $l$. +\end{enumerate} + +Calculating\marginnote{{\tt sc}: scalar} the scalar product between any integer $n$ and any point $P$, $nP$, is not difficult, whereas finding $n$ such that $P_1 = n P_2$ is thought to be computationally hard. By analogy to modular arithmetic, this is often called the {\em discrete logarithm problem} (DLP). Scalar multiplication can be seen as a {\em one-way function}, which paves the way for using elliptic curves for cryptography.\footnote{No known equation or algorithm can efficiently (based on available technology) solve for $n$ in $P_1 = n P_2$, meaning it would take many many years to unravel just one scalar product.} + +The scalar product $nP$ is equivalent to $(((P+P)+(P+P))…)$. Though not always the most efficient approach, we can use double-and-add like in Section \ref{subsec:modular-addition-multiplication}. To get the sum $R = n P$, remember we use the $+$ point operation discussed in Section \ref{elliptic_curves_section}. + +\begin{enumerate} + \item Define $n_{scalar} \rightarrow n_{binary}$; $A = [n_{binary}]$; $R = 0$, the point-at-infinity; $S = P$ + \item Iterate through: $i = (0,...,A_{size} - 1)$ + \begin{enumerate} + \item If A[i] == 1, then R += S. + \item Compute S += S. + \end{enumerate} + \item Use the final R as result. +\end{enumerate} + +Note that EC scalars for points in the subgroup of size $l$ (which we will be using henceforth) are members of the finite field $\mathbb{F}_l$. This means arithmetic between scalars is mod $l$. + + +\subsection{Public key cryptography with elliptic curves} +\label{ec:keys} +Public key cryptography algorithms can be devised in a way analogous to modular arithmetic. + +Let \(k\) be a randomly selected number satisfying \(0 < k < l\), and call it a {\em private key}.\footnote{The private key is sometimes known as a {\em secret key}. This lets us abbreviate: pk = public key, sk = secret key.} Calculate the corresponding {\em public key} \(K\) (an EC point) with the scalar product \(k G = K\). + +Due to the {\em discrete logarithm problem} (DLP) we cannot easily deduce \(k\) from \(K\) alone. This property allows us to use the values \((k, K)\) in standard public key cryptography algorithms. + + +\subsection{Diffie-Hellman key exchange with elliptic curves} +\label{DH_exchange_section} + +A basic {\em Diffie-Hellman} \cite{Diffie-Hellman} exchange of a shared secret between {\em Alice} and {\em Bob} could take place in the following manner: + +\begin{enumerate} + \item Alice and Bob generate their own private/public keys \((k_A, K_A) \textrm{ and } (k_B, K_B)\). Both publish or exchange their public keys, and keep the private keys for themselves. + + \item Clearly, it holds that \[S = k_A K_B = k_A k_B G = k_B k_A G = k_B K_A\] + + Alice could privately calculate \(S = k_A K_B\), and Bob \(S = k_B K_A\), allowing them to use this single value as a shared secret. + + For example, if Alice has a message $m$ to send Bob, she could hash the shared secret \(h = \mathcal{H}(S)\), compute $x = m + h$, and send $x$ to Bob. Bob computes $h' = \mathcal{H}(S)$, calculates $m = x - h'$, and learns $m$. +\end{enumerate} + +An external observer would not be able to easily calculate the shared secret due to the `Diffie-Hellman Problem' (DHP), which says finding $S$ from $K_A$ and $K_B$ is very difficult. Also, the DLP prevents them from finding $k_A$ or $k_B$.\footnote{The DHP is thought to be of at least similar difficulty to the DLP, although it has not been proven. \cite{diffie-hellman-problem}} + + +\subsection{Schnorr signatures and the Fiat-Shamir transform} +\label{sec:schnorr-fiat-shamir} + +In 1989 Claus-Peter Schnorr published a now-famous interactive authentication protocol \cite{schnorr-signatures}, generalized by Maurer in 2009 \cite{simple-zk-proof-maurer}, that allowed someone to prove they know the private key $k$ of a given public key $K$ without revealing any information about it \cite{Signatures2015BorromeanRS}. It goes something like this: + +\begin{enumerate} + \item The prover generates a random integer \(\alpha \in_R \mathbb{Z}_l\),\footnote{\label{notation3_note}Notation: The $R$ in \(\alpha \in_R \mathbb{Z}_l\) means $\alpha$ is randomly selected from \(\{1,2,3,...,l-1\}\).\marginnote{src/crypto/ crypto.cpp {\tt random32\_ unbiased()}} In other words, $\mathbb{Z}_l$ is all integers$\pmod l$. We exclude `$l$' since the point-at-infinity is not useful here.} computes $\alpha G$, and sends $\alpha G$ to the verifier. + \item The verifier generates a random {\em challenge} $c \in_R \mathbb{Z}_l$ and sends $c$ to the prover. + \item The prover computes the {\em response} $r = \alpha + c*k$ and sends $r$ to the verifier. + \item The verifier computes $R = r G$ and $R' = \alpha G + c*K$, and checks $R \stackrel{?}{=} R'$. +\end{enumerate} + +The verifier can compute $R' = \alpha G + c*K$ before the prover, so providing $c$ is like saying, ``I challenge you to respond with the discrete logarithm of $R'$." A challenge the prover can only overcome by knowing $k$ (except with negligible probability). + +If $\alpha$ was chosen randomly by the prover then $r$ is randomly distributed \cite{SCOZZAFAVA1993313} and $k$ is information-theoretically secure within $r$ (it can still be found by solving the DLP for $K$ or $\alpha G$).\footnote{\label{information_theoretic_note}A cryptosystem with information-theoretic security is one where even an adversary with infinite computing power could not break it, because they simply wouldn't have enough information.} However, if the prover reuses $\alpha$ to prove his knowledge of $k$, anyone who knows both challenges in $r = \alpha + c*k$ and $r' = \alpha + c'*k$ can compute $k$ (two equations, two unknowns).\footnote{If the prover is a computer, you could imagine someone `cloning'/copying the computer after it generates $\alpha$, then presenting each copy with a different challenge.}\vspace{.175cm}%In security proofs, phrases like `forking lemma' and `rewind on success' are analagous to this cloning attack. See for example \cite{Liu2004}. +\[k = \frac{r-r'}{c-c'}\] + +If the prover knew $c$ from the beginning (e.g. if the verifier secretly gave it to her), she could generate a random response $r$ and compute $\alpha G = r G - c K$. When she later sends $r$ to the verifier, she `proves' knowledge of $k$ without ever having to know it. Someone observing the transcript of events between prover and verifier would be none the wiser. The scheme is not {\em publicly verifiable}. \cite{Signatures2015BorromeanRS}\\ + +In his role as challenger, the verifier spits out a random number after receiving $\alpha G$, making him equivalent to a {\em random function}. Random functions, such as hash functions, are known as random oracles because computing one is like requesting a random number from someone \cite{Signatures2015BorromeanRS}.\footnote{More generally, ``[i]n cryptography... an oracle is any system which can give some extra information on a system, which otherwise would not be available."\cite{cryptographic-oracle}}\\ + +Using a hash function, instead of the verifier, to generate challenges is known as a {\em Fiat-Shamir transform} \cite{fiat-shamir-transform}, because it makes an interactive proof non-interactive and publicly verifiable \cite{Signatures2015BorromeanRS}.\footnote{The output of a cryptographic hash function $\mathcal{H}$ is uniformly distributed across the range of possible outputs. That is to say, for some input $A$, $\mathcal{H}(A) \in^D_R \mathbb{S}_H$ where $\mathbb{S}_H$ is the set of possible outputs from $\mathcal{H}$. We use $\in^D_R$ to indicate the function is deterministically random. $\mathcal{H}(A)$ produces the same thing every time, but its output is equivalent to a random number. +}\footnote{Note that non-interactive Schnorr-like proofs (and signatures) require either use of a fixed generator $G$, or inclusion of the generator in the challenge hash. Including it that way is known as key prefixing, which we discuss a bit more later (Sections \ref{blsag_note} and \ref{sec:robust-key-aggregation}).} + +\subsubsection*{Non-interactive proof} + +\begin{enumerate} + \item Generate random number $\alpha \in_R \mathbb{Z}_l$, and compute $\alpha G$. + \item Calculate the challenge using a cryptographically secure hash function, \(c = \mathcal{H}([\alpha G])\). + \item Define the response $r = \alpha + c*k$. + \item Publish the proof pair $(\alpha G, r)$. +\end{enumerate} + +\subsubsection*{Verification} + +\begin{enumerate} + \item Calculate the challenge: \(c' = \mathcal{H}([\alpha G])\). + \item Compute $R = r G$ and $R' = \alpha G + c'*K$. + \item If $R = R'$ then the prover must know $k$ (except with negligible probability). +\end{enumerate} + +\subsubsection*{Why it works} + +\begin{align*} +r G &= (\alpha + c*k) G \\ + &= (\alpha G) + (c*k G) \\ + &= \alpha G + c*K \\ + R &= R' +\end{align*} + +An important part of any proof/signature scheme is the resources required to verify them. This includes space to store proofs, and time spent verifying. In this scheme we store one EC point and one integer, and need to know the public key - another EC point. Since hash functions are comparatively fast to compute, keep in mind that verification time is mostly a function of elliptic curve operations\marginnote{src/ringct/ rctOps.cpp}. + + +\subsection{Signing messages} +\label{sec:signing-messages} + +Typically, a cryptographic signature is performed on a cryptographic hash of a message rather than the message itself, which facilitates signing messages of varying size. However, in this report we will loosely use the term `message', and its symbol $\mathfrak{m}$, to refer to the message properly speaking and/or its hash value, unless specified. + +Signing messages is a staple of Internet security that lets a message's recipient be confident its content is as intended by the signer. One common signature scheme is called ECDSA. See \cite{ecdsa}, ANSI X9.62, and \cite{Hankerson:2003:GEC:940321}. + +The signature scheme we present here is an alternative formulation of the transformed Schnorr proof from before. Thinking of signatures in this way prepares us for exploring ring signatures in the next chapter. + +\subsubsection*{Signature} + +Assume Alice has the private/public key pair \((k_A, K_A)\). To unequivocally sign an arbitrary message $\mathfrak{m}$, she could execute the following steps: + +\begin{enumerate} + \item Generate random number $\alpha \in_R \mathbb{Z}_l$, and compute $\alpha G$. + \item Calculate the challenge using a cryptographically secure hash function, \(c = \mathcal{H}(\mathfrak{m},[\alpha G])\). + \item Define the response $r$ such that $\alpha = r + c*k_A$. In other words, $r = \alpha - c*k_A$. + \item Publish the signature $(c, r)$. +\end{enumerate} + +\subsubsection*{Verification} + +Any third party who knows the EC domain parameters (specifying which elliptic curve was used), the signature $(c, r)$ and the signing method, $\mathfrak{m}$ and the hash function, and $K_A$ can verify the signature: + +\begin{enumerate} + \item Calculate the challenge: \(c' = \mathcal{H}(\mathfrak{m},[r G + c*K_A])\). + \item If $c = c'$ then the signature passes. +\end{enumerate} + +In this signature scheme we store two scalars, and need one public EC key. + +\subsubsection*{Why it works} + +This stems from the fact that +\begin{align*} + r G &= (\alpha - c*k_A) G \\ + &= \alpha G - c*K_A \\ +\alpha G &= r G + c*K_A \\ +\mathcal{H}_n(\mathfrak{m},[\alpha G]) &= \mathcal{H}_n(\mathfrak{m},[r G + c*K_A]) \\ + c &= c' +\end{align*} + +Therefore the owner of $k_A$ (Alice) created $(c,r)$ for $\mathfrak{m}$: she signed the message. The probability someone else, a forger without $k_A$, could have made $(c,r)$ is negligible, so a verifier can be confident the message was not tampered with. + + + +%----------CURVE ED25519 +\section{Curve Ed25519} +\label{Ed25519_section} + +Monero uses a particular Twisted Edwards elliptic curve for cryptographic operations, {\em Ed25519}, the {\em birational equivalent}\footnote{\label{birational_note}Without giving further details, birational equivalence can be thought of as an isomorphism expressible using rational terms.} +of the Montgomery curve {\em Curve25519}. + +Both Curve25519 and Ed25519 were released by Bernstein {\em et al.} \cite{Bernstein2008, Bernstein2012, Bernstein2007}.\footnote{Dr. Bernstein also developed an encryption scheme known as ChaCha \cite{Bernstein_chacha,chacha-irtf}, which the primary Monero implementation uses to encrypt\marginnote{src/wallet/ ringdb.cpp} certain sensitive information related to users' wallets.} + +The\marginnote{src/crypto/ crypto\_ops\_ builder/ ref10Comm- entedComb- ined/\\ ge.h} curve is defined over the prime field \(\mathbb{F}_{2^{255} - 19}\) (i.e. $q = 2^{255}-19$) by means of the following equation:\vspace{.175cm} +\[-x^2 + y^2 = 1 - \frac{121665}{121666} x^2 y^2\] + +This curve addresses many concerns raised by the cryptography community.\footnote{Even if a curve appears to have no cryptographic security problems, it's possible the person/organization that created it knows a secret issue that only crops up in very rare curves. Such a person may have to randomly generate many curves in order to find one with a hidden weakness and no known weaknesses. If reasonable explanations are required for curve parameters, then it becomes even more difficult to find weak curves that will be accepted by the cryptographic community. Curve Ed25519 is known as a `fully rigid' curve, which means its generation process was fully explained. \cite{elliptic-curve-rigidity}} It is well known that NIST\footnote{\label{NIST_note}National Institute of Standards and Technology, \url{https://www.nist.gov/}} +standard algorithms have issues. For example, it has recently become clear the NIST standard random number generation algorithm PNRG (the version based on elliptic curves) is flawed and contains a potential backdoor \cite{hales2014nsa}. Seen from a broader perspective, standardization authorities like NIST lead to a cryptographic monoculture, introducing a point of centralization. A great example of this was illustrated when the NSA used its influence over NIST to weaken an international cryptographic standard \cite{NSA-NIST}. + +Curve Ed25519 is not subject to any patents (see \cite{ECC-patents} for a discussion on this subject), and the team behind it has +developed\marginnote{src/crypto/ crypto\_ops\_ builder/} and adapted basic cryptographic algorithms with efficiency in mind \cite{Bernstein2007}. + +Twisted Edwards curves have order expressible as \(N=2^c l\), where \(l\) is a prime number and \(c\) a positive integer. In the case of curve Ed25519, its order is a 76 digit number ($l$ is 253 bits):\footnote{This means private EC keys in Ed25519 are 253 bits.}\vspace{.175cm} +\[2^3 \cdot 7237005577332262213973186563042994240857116359379907606001950938285454250989\marginnote{src/ringct/ rctOps.h {\tt curve- Order()}}\] + + +\subsection{Binary representation} +\label{binary_note} +Elements of \(\mathbb{F}_{2^{255} - 19} \) are encoded as 256-bit integers, so they can be represented using 32 bytes. Since each element only requires 255 bits, the most significant bit is always zero. + +Consequently, any point in Ed25519 could be expressed using 64 bytes. By applying {\em point compression} techniques, described here below, however, it is possible to reduce this amount by half, to 32 bytes. + + +\subsection{Point compression} +\label{point_compression_section} + +The Ed25519 curve has the property that its points can be easily compressed, so that representing a point will consume only the space of one coordinate. We will not delve into the mathematics necessary to justify this, but we can give a brief insight into how it works \cite{eddsa-ed25519-irtf}. Point compression for the Ed25519 curve was first described in \cite{Bernstein2012}, while the concept was first introduced in \cite{Miller:point-compression-origin}. + +This point compression scheme follows from a transformation of the Twisted Edwards curve equation (assuming $a = -1$, which is true for Monero): $x^2 = (y^2-1)/(d y^2+1)$,\footnote{Here $d = - \frac{121665}{121666}$.} which indicates there are two possible $x$ values ($+$ or $-$) for each $y$. Field elements $x$ and $y$ are calculated$\pmod{q}$, so there are no actual negative values. However, taking$\pmod{q}$ of $–x$ will change the value between odd and even since $q$ is odd. For example: $3 \pmod{5} = 3$, $-3 \pmod{5} = 2$. In other words, the field elements $x$ and $–x$ have different odd/even assignments. + +If we have a curve point and know its $x$ is even, but given its $y$ value the transformed curve equation outputs an odd number, then we know negating that number will give us the right $x$. One bit can convey this information, and conveniently the $y$ coordinate has an extra bit. + +Assume we want to compress a point \((x, y)\). + +\begin{description} + \item[Encoding] We\marginnote{src/crypto/ crypto\_ops\_ builder/ ref10Comm- entedComb- ined/\\ ge\_to- bytes.c} set the most significant bit of $y$ to 0 if $x$ is even, and 1 if it is odd. The resulting value $y’$ will represent the curve point. + + \item[Decoding] \hfill + \begin{enumerate} + \item Retrieve\marginnote{ge\_from- bytes.c}[2.05cm] the compressed point $y’$, then copy its most significant bit to the parity bit $b$ before setting it to 0. Now it is the original $y$ again. + \item Let \(u = y^2-1 \pmod q\) and \(v = d y^2 + 1 \pmod q\). This means $x^2 = u/v \pmod q$. + \item Compute\footnote{Since $q = 2^{255}-19 \equiv 5 \pmod{8}$, $(q-5)/8$ and $(q-1)/4$ are integers.} \(z = u v^3 (u v^7)^{(q-5)/8} \pmod q\). + \begin{enumerate} + \item If \(v z^2 = u \pmod q\) then \(x' = z\). + \item If \(v z^2 = -u \pmod q\) then calculate \(x' = z*2^{(q-1)/4} \pmod q\). + \end{enumerate} + \item Using the parity bit \(b\) from the first step, if $b \ne$ the least significant bit of $x'$ then \(x = -x' \pmod q\), otherwise \(x = x'\). + \item Return the decompressed point $(x,y)$. + \end{enumerate} +\end{description} + +Implementations of Ed25519 (such as Monero) typically use the generator $G = (x,4/5)$ \cite{Bernstein2012}, where x is the `even', or $b = 0$, variant based on point decompression of \(y = 4/5 \pmod q\). + + +\subsection{EdDSA signature algorithm} +\label{EdDSA_section} + +Bernstein and his team have developed a number of basic algorithms based on curve Ed25519.\footnote{\label{group_ops_twisted_edwards_note}See\marginnote{src/crypto/ crypto\_ops\_ builder/ ref10Comm- entedComb- ined/} \cite{Bernstein2007} for efficient group operations in Twisted Edwards EC (i.e. point addition, doubling, mixed addition, etc). See \cite{curve25519} for efficient modular arithmetic.} +For illustration purposes we will describe a highly optimized and secure alternative to the ECDSA signature scheme which, according to the authors, allows producing over 100 000 signatures per second using a commodity Intel Xeon processor \cite{Bernstein2012}. The algorithm can also be found described in Internet RFC8032 \cite{rfc8032}. Note this is a very Schnorr-like signature scheme. + +Among other things, instead of generating random integers every time, it uses a hash value derived from the private key of the signer and the message itself. This circumvents security flaws related to the implementation of random number generators. Also, another goal of the algorithm is to avoid accessing secret or unpredictable memory locations to prevent so-called {\em cache timing attacks} \cite{Bernstein2012}. + +We provide here an outline of the steps performed by the algorithm. A complete description and sample implementation in the Python language can be found in \cite{rfc8032}. + +\subsubsection*{Signature} + +\begin{enumerate} + \item Let \(h_k\) be a hash \(\mathcal{H}(k)\) of the signer's private key \(k\). + Compute \(\alpha\) as a hash \(\alpha = \mathcal{H}(h_k, \mathfrak{m})\) of the hashed private key and message. Depending on implementation, $\mathfrak{m}$ could be the actual message or its hash \cite{rfc8032}. + + \item Calculate \(\alpha G\) and the challenge $ch = \mathcal{H}([\alpha G], K, \mathfrak{m})$. + + \item Calculate the response \(r = \alpha + ch \cdot k \). + + \item The signature is the pair \((\alpha G, r)\). +\end{enumerate} + +\subsubsection*{Verification} +Verification is performed as follows + +\begin{enumerate} + \item Compute \(ch' = \mathcal{H}([\alpha G], K, \mathfrak{m})\). + + \item If the equality \(2^c r G \stackrel{?}{=} 2^c \alpha G + 2^c ch'*K \) holds then the signature is valid. +\end{enumerate} + +The $2^c$ term comes from Bernstein {\em et al.}’s general form of the EdDSA algorithm \cite{Bernstein2012}. According to that paper, though it isn’t required for adequate verification, removing $2^c$ provides stronger equations. + +The public key $K$ can be any EC point, but we only want to use points in the generator $G$'s subgroup. Multiplying by the cofactor $2^c$ ensures all points are in that subgroup. Alternatively, verifiers could check $l K \stackrel{?}{=} 0$, which only works if $K$ is in the subgroup. We do not know of any weaknesses caught by these precautions, though as we will see the latter method is important in Monero (Section \ref{blsag_note}). + +In this signature scheme we store one EC point and one scalar, and have one public EC key. + +\subsubsection*{Why it works} +\begin{align*} +2^c r G &= 2^c (\alpha + \mathcal{H}([\alpha G], K, \mathfrak{m}) \cdot k) \cdot G \\ + &= 2^c \alpha G + 2^c \mathcal{H}([\alpha G], K, \mathfrak{m}) \cdot K +\end{align*} + +\subsubsection*{Binary representation} + +By default, an EdDSA signature would need \(64 + 32\) bytes for the EC point $\alpha G$ and scalar $r$. However, RFC8032 assumes point \(\alpha G\) is compressed, which reduces space requirements to only \(32 + 32\) bytes. We include the public key $K$, which implies \(32 + 32 + 32\) total bytes. + + + +\section{Binary operator XOR} +\label{sec:XOR_section} + +The binary operator XOR is a useful tool that will appear in Sections \ref{sec:integrated-addresses} and \ref{sec:pedersen_monero}. It takes two arguments and returns true if one, but not both, of them is true \cite{wolfram-xor}. Here is its truth table: + +\begin{center} + \begin{tabular}{|c|c|c|} + \hline + A & B & A XOR B \\ + \hline\hline + T & T & F \\ + \hline + T & F & T \\ + \hline + F & T & T \\ + \hline + F & F & F \\ + \hline + \end{tabular} +\end{center} + +In the context of computer science, XOR is equivalent to bit addition modulo 2. For example, the XOR of two bit pairs: +\begin{alignat*}{1} + \text{XOR}(\{1,1\},\{1,0\}) &= \{1+1,1+0\} \pmod 2 \\ + &= \{0,1\} +\end{alignat*} + +Each of these also produce $\{0,1\}$: $\text{XOR}(\{1,0\},\{1,1\})$, $\text{XOR}(\{0,0\},\{0,1\})$, and $\text{XOR}(\{0,1\},\{0,0\})$. For XOR inputs with $b$ bits, there are $2^{\text{b}} - 1$ other combinations of inputs that would make the same output. This means if $C = \text{XOR}(A,B)$ and input $A \in_R \{0,...,2^{\text{b}-1}\}$, an observer who learned $C$ would gain no information about $B$. + +At the same time, anyone who knows two of the elements in $\{A,B,C\}$, where $C = \text{XOR}(A,B)$, can calculate the third element, such as $A = \text{XOR}(B,C)$. XOR indicates if two elements are different or the same, so knowing $C$ and $B$ is enough to expose $A$. A careful examination of the truth table reveals this vital feature.\footnote{One interesting application of XOR (unrelated to Monero) is swapping two bit registers without a third register. We use the symbol $\oplus$ to indicate an XOR operation. $A \oplus A = 0$, so after three XOR operations between the registers: $\{A, B\} \rightarrow{} \{[A \oplus B], B\} \rightarrow{} \{[A \oplus B], B \oplus [A \oplus B]\} = \{[A \oplus B], A \oplus 0\} = \{[A \oplus B], A\} \rightarrow{} \{[A \oplus B] \oplus A, A\} = \{B, A\}$.} \ No newline at end of file diff --git a/translations/es/content/blockchain.tex b/translations/es/content/blockchain.tex new file mode 100755 index 0000000..ff298be --- /dev/null +++ b/translations/es/content/blockchain.tex @@ -0,0 +1,487 @@ +\chapter{The Monero Blockchain} +\label{chapter:blockchain} + +The Internet Age has brought a new dimension to the human experience. We can correspond with people on every corner of the planet, and an unimaginable wealth of information is at our fingertips. Exchanging goods and services is fundamental to a peaceful and prosperous society \cite{human-action}, and in the digital realm we can offer our productivity to the whole world. + +Media of exchange (moneys) are essential, giving us a point of reference to an immense diversity of economic goods that would otherwise be impossible to evaluate, and enabling mutually beneficial interactions between people with nothing in common \cite{human-action}. Throughout history there have been many kinds of money, from seashells to paper to gold. Those were exchanged by hand, and now money can be exchanged electronically. + +In the current, by far most pervasive, model, electronic transactions are handled by third-party financial institutions. These institutions are given custody of money and trusted to transfer it upon request. Such institutions must mediate disputes, their payments are reversible, and they can be censored or controlled by powerful organizations. \cite{Nakamoto_bitcoin} + +To alleviate these drawbacks decentralized digital currencies have been engineered.\footnote{This chapter includes more implementation details than previous chapters, as a blockchain's nature depends heavily on its specific structure.} + + + +\section{Digital currency} +\label{sec:digital-currency} + +Designing a digital currency is non-trivial. There are three types: personal, centralized, or distributed. Keep in mind that a digital currency is just a collection of messages, and the `amounts' recorded in those messages are interpreted as monetary quantities. + +In the \textbf{email model} anyone can make coins (e.g. a message saying `I own 5 coins'), and anyone can send their coins over and over to whoever has an email address. It does not have a limited supply, nor does it prevent spending the same coins over and over (double spending). + +In the \textbf{video game model}, where the entire currency is stored/recorded on one central database, users rely on the custodian to be honest. The currency's supply is unverifiable for observers, and the custodian can change the rules at any time, or be censored by powerful outsiders. + + +\subsection{Distributed/shared version of events} +\label{subsec:shared-version-events} + +In digital `shared' money, many computers each have a record of every currency transaction. When a new transaction is made on one computer it is broadcast to the other computers, and accepted if it follows predefined rules. + +Users only benefit from coins when other users accept them in exchange, and users only accept coins they feel are legitimate. To maximize the utility of their coins, users are naturally inclined to settle on one commonly accepted rule-set, without the presence of a central authority.\footnote{In political science this is called a Schelling Point \cite{friedman-schelling}, social minima, or social contract.} +\begin{itemize} + \item[] \textbf{Rule 1}: Money can only be created in clearly defined scenarios. + \item[] \textbf{Rule 2}: Transactions spend money that already exists. + \item[] \textbf{Rule 3}: A person can only spend a piece of money once. + \item[] \textbf{Rule 4}: Only the person who owns a piece of money can spend it. + \item[] \textbf{Rule 5}: Transactions output money equal to the money spent. + \item[] \textbf{Rule 6}: Transactions are formatted correctly. +\end{itemize} + +Rules 2-6 are covered by the transaction scheme discussed in Chapter \ref{chapter:transactions}, which adds the fungibility and privacy-related benefits of ambiguous signing, anonymous receipt of funds, and unreadable amount transfers. We explain Rule 1 later in this chapter.\footnote{In commodity money like gold these rules are met by physical reality.} Transactions use cryptography, so we call their content a {\em cryptocurrency}. + +If two computers receive different legitimate transactions spending the same money before they have a chance to send the information to each other, how do they decide which is correct? There is a `fork' in the currency, because two different copies that follow the same rules exist. + +Clearly the earliest legitimate transaction spending a piece of money should be canonical. This is easier said than done. As we will see, obtaining consensus for transaction histories constitutes the raison d'\^{e}tre of blockchain technology. + + +\subsection{Simple blockchain} +\label{subsec:simple-blockchain} + +First we need all computers, henceforth referred to as {\em nodes}, to agree on the order of transactions. + +Let's say a currency started with a `genesis' declaration: ``Let the SampleCoin begin!". We call this message a `block', and its block hash is \vspace{.175cm} +\[\mathit{BH}_G = \mathcal{H}(\textrm{``Let the SampleCoin begin!"})\] + +Every time a node receives some transactions, they use hashes of those transactions, $\mathit{TH}$, like messages, along with the previous block's hash, and compute new block hashes\vspace{.175cm} +\[\mathit{BH}_1 = \mathcal{H}(\mathit{BH}_G, \mathit{TH}_1, \mathit{TH}_2,...)\] +\[\mathit{BH}_2 = \mathcal{H}(\mathit{BH}_1, \mathit{TH}_3, \mathit{TH}_4,...)\] + +And so on, publishing each new block of messages as it's made. Each new block references the previous, most recently published block. In this way a clear order of events extends/chains all the way back to the genesis message. We have a very simple `blockchain'.\footnote{A blockchain is technically a `directed acyclic graph' (DAG), with Bitcoin-style blockchains a one-dimensional variant. DAGs contain a finite number of nodes and one-directional edges (vectors) connecting nodes. If you start at one node, you will never loop back to it no matter what path you take. \cite{DAG-wikipedia}} + +Nodes can include a timestamp in their blocks to aid record keeping. If most nodes are honest with timestamps then the blockchain provides a decent picture of when each transaction was recorded. + +If different blocks referencing the same previous block are published at the same time, then the network of nodes will fork as each node receives one of the new blocks before the other (for simplicity, imagine about half the nodes end up with each side of the fork). + + + +\section{Difficulty} +\label{sec:difficulty} + +If nodes can publish new blocks whenever they want, the network might fracture and diverge into many different, equally legitimate, chains. Say it takes 30 seconds to make sure everyone in the network gets a new block. What if new blocks are sent out every 31, 15 seconds, 10 seconds, etc? + +We can control how fast the entire network makes new blocks. If the time it takes to make a new block is much higher than the time for the previous block to reach most nodes, the network will tend to remain intact. + + +\subsection{Mining a block} + +The output of a cryptographic hash function is uniformly distributed and apparently independent of the input. This means, given a potential input, its hash is equally likely to be every single possible output. Furthermore, it takes a certain amount of time to compute a single hash. + +Let's imagine a hash function $\mathcal{H}_i(x)$ which outputs a number from 1 to 100: $\mathcal{H}_i(x) \in^D_R \{1,...,100\}$.\footnote{We use $\in^D_R$ to say the output is deterministically random.} Given some $x$, $\mathcal{H}_i(x)$ selects the same `random' number from \{$1,...,100$\} every time you calculate it. It takes 1 minute to calculate $\mathcal{H}_i(x)$. + +Say we are given a message $\mathfrak{m}$, and told to find a `nonce' $n$ (some integer) such that $\mathcal{H}_i(\mathfrak{m},n)$ outputs a number less than or equal to the {\em target} $t = 5$ (i.e. $\mathcal{H}_i(\mathfrak{m},n) \in \{1,...,5\}$). + +Since only $1/20$\nth of outputs from $\mathcal{H}_i(x)$ will meet the target, it should take around 20 guesses of $n$ to find one that works (and hence 20 minutes of computing time). + +Searching for a useful nonce is called {\em mining}, and publishing the message with its nonce is a {\em proof of work} because it proves we found a useful nonce (even if we were lucky and found it with just one hash, or even blindly published a good nonce), which anyone can verify by computing $\mathcal{H}_i(\mathfrak{m},n)$. + +Now say we have a hash function for generating proofs of work, $\mathcal{H}_{PoW} \in^D_R \{0,...,m\}$, where $m$ is its maximum possible output. Given a message $\mathfrak{m}$ (a block of information), a nonce $n$ to mine, and a target $t$, we can define the expected average number of hashes, the {\em difficulty} $d$, like this: $d = m/t$. If\marginnote{src/crypto- note\_basic/ difficulty.cpp {\tt check\_ hash()}} $\mathcal{H}_{PoW}(\mathfrak{m},n)*d \leq m$, then $\mathcal{H}_{PoW}(\mathfrak{m},n) \leq t$ and $n$ is acceptable.\footnote{In Monero only difficulties are recorded/computed since $\mathcal{H}_{PoW}(\mathfrak{m},n)*d \leq m$ doesn't need $t$.} + +With smaller targets the difficulty rises and it takes a computer more and more hashes, and therefore longer and longer periods of time, to find useful nonces.\footnote{Mining and verifying are asymmetric since it takes the same time to verify a proof of work (one computation of the proof of work algorithm) no matter what the difficulty is.} + + +\subsection{Mining speed} + +Assume all nodes are mining at the same time, but quit on their `current' block when they receive a new one from the network. They immediately start mining a fresh block that references the new one. + +Suppose we collect a bunch $b$ of recent blocks from the blockchain (say, with index $u \in \{1,...,b\}$) which each had a difficulty $d_u$. For now, assume the nodes who mined them were honest, so each block timestamp ${TS}_u$ is accurate.\footnote{Timestamps are determined when a miner {\em starts} mining a block, so they are likely to lag behind the actual publication moment. The next block starts mining right away, so the timestamp that appears {\em after} a given block indicates how long miners spent on it.} The total time between the earliest block and most recent block is $\mathit{totalTime} = {TS}_b - {TS}_1$. The approximate number of hashes it took to mine all the blocks is $\mathit{totalDifficulty} = \sum_u d_u$. + +Now we can guess how fast the network, with all its nodes, can compute hashes. If the actual speed didn't change much while the bunch of blocks was being produced, it should be effectively\footnote{If node 1 tries nonce $n = 23$ and later node 2 also tries $n = 23$, node 2's effort is wasted because the network already `knows' $n = 23$ doesn't work (otherwise node 1 would have published that block). The network's {\em effective} hash rate depends on how fast it hashes {\em unique} nonces for a given block of messages. As we will see, since miners include a miner transaction with one-time address $K^o \in_{ER} \mathbb{Z}_l$ (ER = effectively random) in their blocks, blocks are always unique between miners except with negligible probability, so trying the same nonces doesn't matter.}%\vspace{.175cm} +\[\mathit{hashSpeed} \approx \mathit{totalDifficulty}/\mathit{totalTime}\] + +If we want to set the target time to mine new blocks so blocks are produced at a rate\\ \(\textrm{(one block)/(target time)}\), then we calculate how many hashes it should take for the network to spend that amount of time mining. Note: we round up so the difficulty never equals zero.%\vspace{.175cm} +\[\mathit{newDifficulty} = \mathit{hashSpeed}*\mathit{targetTime}\] + +There is no guarantee the next block will take $\mathit{newDifficulty}$ amount of total network hashes to mine, but over time and many blocks and constantly re-calibrating, the difficulty will track with the network's real hash speed and blocks will tend to take $\mathit{targetTime}$.\footnote{If we assume network hash rate is constantly, gradually, increasing, then since new difficulties depend on {\em past} hashes (i.e. before the hash rate increased a tiny bit) we should expect actual block times to, on average, be slightly less than $\mathit{targetTime}$. The effect of this on the emission schedule (Section \ref{subsec:block-reward}) could be canceled out by penalties from increasing block weights, which we explore in Section \ref{subsec:penalty}.} + + +\subsection{Consensus: largest cumulative difficulty} + +Now we can resolve conflicts between chain forks. + +By convention, the chain with highest cumulative difficulty (from all blocks in the chain), and therefore with most work (network hashes) spent constructing, is considered the real, legitimate version. If a chain splits and each fork has the same cumulative difficulty, nodes continue mining on the branch they received first. When one branch gets ahead of the other they discard (`orphan') the weaker branch.%source? + +If nodes wish to change or upgrade the basic protocol, i.e. the set of rules a node considers when deciding if a blockchain copy or new block is legitimate, they may easily do so by forking the chain. Whether the new branch has any impact on users depends on how many nodes switch and how much software infrastructure is modified.\footnote{Monero developers have successfully changed\marginnote{src/hardforks/ hardforks.cpp {\tt mainnet\_hard\_ forks[]}} its protocol 11 times, with nearly all users and miners adopting each fork: v1 April 18, 2014 (genesis version) \cite{bitmonero-launched}; v2 March 2016; v3 September 2016; v4 January 2017; v5 April 2017; v6 September 2017; v7 April 2018; v8 and v9 October 2018; v10 and v11 March 2019; v12 November 2019. The core git repository's README contains a summary of protocol changes in each version.} + +For an attacker to convince honest nodes to alter the transaction history, perhaps in order to respend/unspend funds, he must create a chain fork (on the current protocol) with higher total difficulty than the main chain (which meanwhile continues to grow). This is very hard to do unless you control over 50\% of the network hash speed and can outwork other miners. \cite{Nakamoto_bitcoin} + + +\subsection{Mining in Monero} %get_difficulty_for_next_block, next_difficulty + +To make sure chain forks are on an even footing, we don't sample the most recent blocks (for calculating new difficulties), instead lagging our bunch $b$ by $l$. For example, if there are 29 blocks in the chain (blocks $1,...,29$), $b = 10$, and $l = 5$, we sample blocks 15-24 in order to compute block 30's difficulty. + +If mining nodes are dishonest they can manipulate timestamps so new difficulties don't match the network's real hash speed. We get around this by sorting timestamps chronologically, then chopping off the first $o$ outliers and last $o$ outliers. Now we have a `window' of blocks $w = b-2*o$. From the previous example, if $o = 3$ and timestamps are honest then we would chop blocks 15-17 and 22-24, leaving blocks 18-21 to compute block 30's difficulty from. + +Before chopping outliers we sorted timestamps, but {\em only} timestamps. Block difficulties are left unsorted. We use the cumulative difficulty for each block, which is that block's difficulty plus the difficulty of all previous blocks in the chain. + +Using\marginnote{src/crypto- note\_core/ block- chain.cpp {\tt get\_diff- iculty\_for\_ next\_ block()}}[-1.8cm] the chopped arrays of $w$ sorted timestamps and unsorted cumulative difficulties (indexed from $1,...,w$), we define +\[ \mathit{totalTime} = \mathit{choppedSortedTimestamps}[w] - \mathit{choppedSortedTimestamps}[1]\] +\[ \mathit{totalDifficulty} = \mathit{choppedCumulativeDifficulties}[w] - \mathit{choppedCumulativeDifficulties}[1]\] + +In\marginnote{src/crypto- note\_config.h} Monero the target time is 120 seconds (2 minutes), $l = 15$ (30 mins), $b = 720$ (one day), and $o = 60$ (2 hours).\footnote{In March 2016 (v2 of the protocol), Monero changed from 1 minute target block times to 2 minute target block times \cite{monero-0.9.3}. Other difficulty parameters have always been the same.}\footnote{Monero's difficulty algorithm may be suboptimal compared to state of the art algorithms \cite{difficuly-algorithm-summary}. Fortunately it is `fairly resilient to selfish mining' \cite{selfish-miner-profitability-algorithm-analysis}, an essential feature.} + +Block difficulties are not stored in the blockchain, so someone downloading a copy of the blockchain and verifying all blocks are legitimate needs to recalculate difficulties from recorded timestamps. There\marginnote{src/crypto- note\_basic/ difficulty.cpp {\tt next\_diff- iculty()}} are a few rules to consider for the first $b+l = 735$ blocks. + +\begin{itemize} + \item[] \textbf{Rule 1}: Ignore the genesis block (block 0, with $d = 1$) completely. Blocks 1 and 2 have $d = 1$. + \item[] \textbf{Rule 2}: Before chopping off outliers, try to get the window $w$ to compute totals from. + \item[] \textbf{Rule 3}: After $w$ blocks, chop off high and low outliers, scaling the amount chopped until $b$ blocks. If the amount of previous blocks (minus $w$) is odd, remove one more low outlier than high. + \item[] \textbf{Rule 4}: After $b$ blocks, sample the earliest $b$ blocks until $b+l$ blocks, after which everything proceeds normally - lagging by $l$. +\end{itemize} + + +\subsection*{Monero proof of work (PoW)} + +Monero\marginnote{src/crypto- note\_basic/ cryptonote\_ tx\_utils.cpp {\tt get\_block\_ longhash()}} has used a few different proof of work hash algorithms (with 32 byte outputs) in different protocol versions. The original, known as Cryptonight, was designed to be relatively inefficient on GPU, FPGA, and ASIC architectures \cite{CryptoNight} compared to standard hash functions like SHA256. In April 2018 (v7 of the protocol), new blocks were required to begin using a slightly modified variant that countered the advent of Cryptonight ASICs \cite{cryptonight7}. Another slight variant, named Cryptonight V2, was implemented in October 2018 (v8) \cite{berylliumbullet-v8}, and Cryptonight-R (based on Cryptonight but with more substantial changes than just a tweak) started being used for new blocks in March 2019 (v10) \cite{boronbutterfly-v10}. A\marginnote{src/crypto/ rx-slow-hash.c} radical new proof of work called RandomX \cite{randomx-pr-5549} was designed and made mandatory for new blocks in November 2019 (v12) with the intention of long-term ASIC resistance \cite{randomx}. + + + +\section{Money supply} +\label{sec:money-supply} + +There are two basic mechanisms for creating money in a blockchain-based cryptocurrency. + +First, the currency's creators can conjure coins and distribute them to people in the genesis message. This is often called an `airdrop'. Sometimes creators give themselves a large amount in a so-called `pre-mine'. \cite{premine-description} + +Second, the currency can be automatically distributed as reward for mining a block, much like mining for gold. There are two types here. In the Bitcoin model the total possible supply is capped. Block rewards slowly decline to zero, after which no more money is ever made. In the inflation model supply increases indefinitely. + +Monero is based on a currency known as Bytecoin that had a sizeable pre-mine, followed by block rewards \cite{monero-history}. Monero had no pre-mine, and as we will see, its block rewards slowly decline to a small amount after which all new blocks reward that same amount, making Monero inflationary. + + +\subsection{Block reward} +\label{subsec:block-reward} %get_block_reward + +Block miners, before mining for a nonce, make a `miner transaction' with no inputs and at least one output.\footnote{A miner transaction can have any number of outputs, although currently the core implementation is only able to make one. Moreover, unlike normal transactions there are no explicit restrictions on miner transaction weight. They are functionally limited by the maximum block weight.} The total output amount is equal to the block reward, plus transaction fees from all transactions to be included in the block, and is communicated in clear text. Nodes who receive a mined block must verify\marginnote{src/crypto- note\_core/ block- chain.cpp {\tt validate\_ miner\_ trans- action()}} the block reward is correct, and can calculate the current money supply by summing all past block rewards together. + +Besides distributing money, block rewards incentivize mining. If there were no block rewards (and no other mechanism), why would anyone mine new blocks? Perhaps altruism or curiosity. However, few miners makes it easy for a malicious actor to assemble $>$50\% of the network's hash rate and easily rewrite recent chain history.\footnote{As an attacker gets higher shares of the hash rate (beyond 50\%), it takes less time to rewrite older and older blocks. Given a block $x$ days old, owned hash speed $v$, and honest hash speed $v_h$ ($v > v_h$), it will take $y = x*(v_h/(v-v_h))$ days to rewrite.} This is also why in Monero block rewards do not fall all the way to zero. + +With block rewards, competition between miners drives total hash rate up until the marginal cost of adding more hash rate is higher than the marginal reward of obtaining that proportion of mined blocks (which appear at a constant rate) (plus some premiums like risk and opportunity cost). This means as a cryptocurrency becomes more valuable, its total hash rate will increase and it becomes progressively more difficult and expensive to gather $>$50\%. + +\subsubsection*{Bit shifting} + +Bit shifting is used for calculating the base block reward (as we will see in Section \ref{subsec:penalty}, the actual block reward can sometimes be reduced below the base amount). + +Suppose we have an integer A = 13 with bit representation [1101]. If we shift the bits of A down by 2 using the bitwise shift right operator, denoted A $>>$ 2, we get [0011].01, which equals 3.25. In reality that last part gets thrown away - `shifted' into oblivion, leaving us with [0011] = 3.\footnote{Bitwise shift right by $n$ bits is equivalent to integer division by $2^n$.} + +\subsubsection*{Calculating base block reward for Monero} + +Let's call the current total money supply M, and the `limit' of the money supply L = $2^{64} - 1$ (in binary it is [11....11], with 64 bits).\footnote{Perhaps now it is clear why range proofs (Section \ref{sec:range_proofs}) limit transaction amounts to 64 bits.} In the beginning of Monero the base block reward was \(\textrm{B = (L-M) $>>$ 20}\). If M = 0, then, in decimal format,\vspace{.175cm} +\[\textrm{L} = 18,446,744,073,709,551,615\] +\[\textrm{B}_0 = (L-0) >> 20 = 17,592,186,044,415\] + +These numbers are in `atomic units' - 1 atomic unit of Monero can't be divided. Clearly atomic units are ridiculous - L is over 18 quintillion! We can divide everything by $10^{12}$ to move the decimal point over, giving us the standard units of Monero (a.k.a. XMR, Monero's so-called `stock ticker').\vspace{.15cm} +\[\frac{\textrm{L}}{10^{12}} = 18,446,744.073709551615\] +\[\textrm{B}_0 = \frac{(L-0) >> 20}{10^{12}} = 17.592186044415\] + +And there it is, the very first block reward, dispersed to pseudonymous thankful\_for\_today (who was responsible for starting the Monero project) in Monero's genesis block \cite{bitmonero-launched}, was about 17.6 Moneroj! See Appendix \ref{appendix:genesis-block} to confirm this for yourself.\footnote{Monero amounts are stored in atomic-unit format in the blockchain.} + +As blocks are mined M grows, lowering subsequent block rewards. Initially (since the genesis block in April 2014) Monero blocks were mined once per minute, but in March 2016, it became two minutes per block \cite{monero-0.9.3}. To keep the rate of money creation, i.e. the `emission schedule',\footnote{For an interesting comparison of Monero and Bitcoin's emission schedules see \cite{monero-coin-emission}.} the same, block rewards were doubled. This just means, after the change, we use (L-M) $>>$ 19 instead of $>>$ 20 for new blocks. Currently the base block reward is\marginnote{src/crypto- note\_basic/ cryptonote\_ basic\_ impl.cpp {\tt get\_block\_ reward()}}\vspace{.175cm} +\[\textrm{B} = \frac{(L-M) >> 19}{10^{12}}\] + + +\subsection{Dynamic block weight} +\label{subsec:dynamic-block-weight} + +It would be nice to mine every new transaction into a block right away. What if someone submits a lot of transactions maliciously? The blockchain, storing every transaction, would quickly grow enormous. + +One mitigation is a fixed block size (in bytes), so the number of transactions per block is limited. What if honest transaction volume rises? Each transaction author would bid for a spot in new blocks by offering fees to miners. Miners would focus on mining transactions with the highest fees. As transaction volume increases, fees would become prohibitively large for transactions of small amounts (such as Alice buying an apple from Bob). Only people willing to outbid everyone else would get their transactions into the blockchain.\footnote{Bitcoin has a history of overloaded transaction volume. This website (\url{https://bitcoinfees.info/}) charts the ridiculous fee levels encountered (up to the equivalent of 35\$ per transaction at one point).}\\ + +Monero avoids those extremes (unlimited vs fixed) with a dynamic block weight. + +\subsubsection*{Size vs Weight} + +Since\marginnote{src/crypto- note\_basic/ cryptonote\_ format\_ utils.cpp {\tt get\_trans- action\_ weight()}} Bulletproofs were added (v8), transaction and block sizes are no longer considered strictly. The term used now is {\em transaction weight}. Transaction weight for a miner transaction (see Section \ref{subsec:miner-transaction}), or a normal transaction with two outputs, is equal to the size in bytes. When a normal transaction has more than two outputs the weight is somewhat higher than the size. + +Recalling Section \ref{sec:range_proofs}, a Bulletproof occupies $(2 \cdot \lceil \textrm{log}_2(64 \cdot p) \rceil + 9) \cdot 32$ bytes, so as more outputs are added the additional storage for range proofs is sub-linear. However, Bulletproof verification is linear, so artificially increasing transaction weights `prices in' that extra verification time (it's called a `clawback').%see get_transaction_weight_clawback() and n_bulletproof_max_amounts() for exact details + +Suppose\marginnote{src/crypto- note\_basic/ cryptonote\_ format\_ utils.cpp {\tt get\_trans- action\_ weight\_ clawback()}} we have a transaction with $p$ outputs, and imagine that if $p$ isn't a power of 2 we create enough dummy outputs to fill the gap. We find the difference between the actual Bulletproof size, and the size of all the Bulletproofs if those $p$ + `dummy outputs' had been in 2-out transactions (it's 0 if $p = 2$). We only claw back 80\% of the difference.\footnote{Note that $\textrm{log}_2(64 \cdot 2) = 7$, and $2*7 + 9 = 23$.}\vspace{.175cm} +\[\textrm{transaction\_clawback} = 0.8*[(23*(p + \textrm{num\_dummy\_outs})/2) \cdot 32 - (2 \cdot \lceil \textrm{log}_2(64 \cdot p) \rceil + 9) \cdot 32]\] + +Therefore the transaction weight is\vspace{.175cm} +\[\textrm{transaction\_weight} = \textrm{transaction\_size} + \textrm{transaction\_clawback}\] + +A block's weight\marginnote{src/crypto- note\_core/ block- chain.cpp {\tt create\_ block\_ template()}} is equal to the sum of its component transactions' weights plus the miner transaction's weight. + +\subsubsection*{Long term block weight} + +If dynamic blocks are allowed to grow at a rapid pace the blockchain can quickly become unmanageable \cite{big-bang-github}. To mitigate this, maximum block weights are tethered by {\em long term block weights}. Each block has, in addition to its normal weight, a `long term weight' calculated based on the previous block's effective median long term weight.\footnote{Similar to block difficulties, block weights and long term block weights are calculated and stored by blockchain verifiers rather than being included in blockchain data.} A block's effective median long term weight is related to the median of the most recent 100000 blocks' long term weights (including its own).\marginnote{src/crypto- note\_core/ block- chain.cpp {\tt update\_ next\_cumu- lative\_ weight\_ limit()}}\footnote{Blocks made before long term weights were implemented have long term weights equal to their normal weights, so there is no concern for us about details surrounding the genesis block or early blocks. A brand new chain could easily make sensible choices.}\footnote{In the beginning\marginnote{src/crypto- note\_basic/ cryptonote\_ basic\_ impl.cpp {\tt get\_min\_ block\_ weight()}} of Monero the `300kB' term was 20kB, then increased to 60kB in March 2016, (v2 of the protocol) \cite{monero-0.9.3}, and has been 300kB since April 2017 (v5 of the protocol) \cite{monero-v5}. This non-zero `floor' within the dynamic block weight medians helps transient transaction volume changes when the absolute volume is low, especially in the early stages of Monero adoption.}%Blockchain::get_next_long_term_block_weight() + +\begin{align*} + \textrm{longterm\_block\_weight} &= min\{\textrm{block\_weight}, 1.4*\textrm{previous\_effective\_longterm\_median}\}\\ + \textrm{effective\_longterm\_median} &= max\{\textrm{300kB}, \textrm{median\_100000blocks\_longterm\_weights}\}%m_long_term_effective_median_block_weight +\end{align*}{} + +If normal block weights stay large for a long time, then it will take at least 50,000 blocks (about 69 days) for the effective long term median to rise by 40\% (that's how long it takes a given long term weight to become the median). + +\subsubsection*{Cumulative median weight} + +Transaction volume can change dramatically in a short period of time, especially around holidays \cite{visa-seasonality}. To accommodate this, Monero allows short term flexibility in block weights. To smooth\marginnote{{\tt CRYPTONOTE\_ REWARD\_ BLOCKS\_ WINDOW}} out transient variability, a block's cumulative median uses the median of the last 100 blocks' normal block weights (including its own).\vspace{.1cm} +\begin{align*} + \textrm{cumulative\_weights\_median} = max\{\textrm{300kB}, min\{&max\{\textrm{300kB}, \textrm{median\_100blocks\_weights}\},\\ + &50*\textrm{effective\_longterm\_median}\}\}%HF_VERSION_EFFECTIVE_SHORT_TERM_MEDIAN_IN_PENALTY %update_next_cumulative_weight_limit() %m_current_block_cumul_weight_median %CRYPTONOTE_SHORT_TERM_BLOCK_WEIGHT_SURGE_FACTOR = 50 +\end{align*}{} + +The next block to be added to the blockchain is constrained in this way:\footnote{The cumulative median replaced `M100' (a similar median term) in protocol v8. Penalties and fees described in the first edition of this report \cite{ztm-1} used M100.}\vspace{.1cm} +\[\textrm{max\_next\_block\_weight}\marginnote{src/crypto- note\_basic/ cryptonote\_ basic\_ impl.cpp {\tt get\_block\_ reward()}} = 2*\textrm{cumulative\_weights\_median}\]% handle_block_to_main_chain() -> validate_miner_transaction() -> get_block_reward() + +While the maximum block weight can rise up to 100 times the effective median long term weight after a few hundred blocks, it cannot rise more than 40\% beyond that over the next 50,000 blocks. Therefore long-term block weight growth is tethered by the long term weights, and in the short term weights may surge above their steady-state values. + + +\subsection{Block reward penalty} +\label{subsec:penalty} + +To mine blocks bigger than the cumulative median, miners have to pay a price, or penalty, in the form of reduced block reward. This means there are functionally two zones within the maximum block weight: the penalty-free zone, and the penalty zone. The median can slowly rise, allowing progressively larger blocks with no penalty. + +If the intended block weight is greater than the cumulative median, then, given base block reward B, the block reward penalty is\vspace{.1cm} +\[\textrm{P} = \textrm{B}*((\textrm{block\_weight}/\textrm{cumulative\_weights\_median}) - 1)^2\] + +The actual block reward\marginnote{src/crypto- note\_basic/ cryptonote\_ basic\_ impl.cpp {\tt get\_block\_ reward()}} is therefore\footnote{Before confidential transactions (RingCT) were implemented (v4), all amounts were communicated in clear text and in some early protocol versions split into chunks (e.g. 1244 $\rightarrow$ 1000 + 200 + 40 + 4). To reduce miner tx size, the core implementation chopped off the lowest significant digits of block rewards (anything less than 0.0001 Moneroj; see {\tt BASE\_REWARD\_CLAMP\_THRESHOLD}) in v2-v3. The extra little bit was not lost, just made available for future block rewards. More generally, since v2\marginnote{src/crypto- note\_core/ block- chain.cpp {\tt validate\_ miner\_trans- action()}} the block reward calculation here is just an upper limit on the real block reward that can be dispersed in a miner tx's outputs. Also of note, very early transactions' outputs with cleartext amounts {\em not} split into chunks can't be used in ring signatures in the current implementation, so to spend them they are migrated into chunked, `mixable', outputs, which can then be spent in normal RingCT transactions by creating rings out of other chunks with the same amount. Exact modern protocol rules around these ancient pre-RingCT outputs are not clear.}\vspace{.3cm} +\begin{align*} + \textrm{B}^{\textrm{actual}} &= \textrm{B} - \textrm{P} \\ + \textrm{B}^{\textrm{actual}} &= \textrm{B}*(1-((\textrm{block\_weight}/\textrm{cumulative\_weights\_median}) - 1)^2) +\end{align*} + +Using the \^{}2 operation means penalties are sub-proportional to block weight. A block weight 10\% larger than the previous cumulative\_weights\_median has just a 1\% penalty, 50\% larger is 25\% penalty, 90\% larger is 81\% penalty, and so on. \cite{monero-coin-emission}\\ + +We can expect miners to create blocks larger than the cumulative median when the fee from adding another transaction is bigger than the penalty incurred. + + +\subsection{Dynamic minimum fee} +\label{subsec:dynamic-minimum-fee} %get_dynamic_per_kb_fee + +To prevent malicious actors from flooding the blockchain with transactions that could be used to pollute ring signatures, and generally bloat it unnecessarily, Monero has a minimum fee\marginnote{src/crypto- note\_core/ block- chain.cpp {\tt check\_fee()}} per byte of transaction data.\footnote{This minimum is enforced by the node consensus protocol, not the blockchain protocol. Most nodes won't relay a transaction to other nodes if it has a fee below the minimum\marginnote{src/crypto- note\_core/ tx\_pool.cpp {\tt add\_tx()}} (at least in part so only transactions likely to be mined by someone are passed along \cite{articmine-36c3-dynamics}), but they {\em will} accept a new block containing that transaction. In particular, this means there is no need to maintain backward compatibility with fee algorithms.} Originally this was 0.01 XMR/KiB (added early during protocol v1) \cite{fee-old-stackexchange}, then it became 0.002 XMR/KiB in September 2016 (v3).\footnote{The unit KiB (kibibyte, 1 KiB = 1024 bytes) is different from kB (kilobyte, 1 kB = 1000 bytes).}%HF_VERSION_PER_BYTE_FEE + +In January 2017 (v4), a dynamic fee per KiB algorithm \cite{articmine-fee-video, articmine-36c3-dynamics, articmine-defcon27-video, jollymore-old-analysis} was added,\footnote{The base fee was changed from 0.002 XMR/KiB to 0.0004 XMR/KiB in April 2017 (v5 of the protocol) \cite{monero-v5}. The first edition of this report described the original dynamic fee algorithm \cite{ztm-1}.} and then along with transaction weight reductions due to Bulletproofs (v8) it changed from per KiB to per byte. The most important feature of the algorithm is that it prevents minimum possible total fees from exceeding the block reward (even with small block rewards and large block weights), which is thought to cause instability \cite{fee-reward-instability, no-reward-instability, selfish-miner}.\footnote{Credit for the concepts in this section largely belongs to Francisco Caba$\tilde{\textrm{n}}$as (a.k.a. `ArticMine'), the architect of Monero's dynamic block and fee system. See \cite{articmine-fee-video, articmine-36c3-dynamics, articmine-defcon27-video}.}%, by scaling with both the base block reward and the median.%\cite{dynamic-per-kb-fee} + +\subsubsection*{The fee algorithm} + +We base our fee algorithm around a reference transaction \cite{jollymore-old-analysis} of weight 3000 bytes (similar to a basic {\tt RCTTypeBulletproof2} 2-input, 2-output transaction, which is usually about 2600 bytes)\footnote{A basic 1-input, 2-output Bitcoin transaction is 250 bytes \cite{bitcoin-txsizes-2015}, or 430 bytes for 2-in/2-out.}, and the fees it would take to offset the penalty when the median is at its minimum (the smallest penalty-free zone, 300kB) \cite{articmine-36c3-dynamics}. In other words, the penalty induced by a 303kB block weight.% Doing this ensures fees required for common transactions to push up the median directly scale off the default fee, rather than requiring a disjointed multiplier compared to sub-median fees. + +Firstly, the fee F to balance the marginal penalty MP from adding a transaction with weight TW to a block with weight BW, is\vspace{.175cm} +\begin{align*} + \textrm{F} = \textrm{MP} = \textrm{B}&*(([\textrm{BW} + \textrm{TW}]/\textrm{cumulative\_median} - 1)^2 -\\ \textrm{B}&*((\textrm{BW}/\textrm{cumulative\_median} - 1)^2 +\end{align*}{} + +Defining the block weight factor $\textrm{WF}_b = (\textrm{BW}/\textrm{cumulative\_median} - 1)$, and transaction weight factor $\textrm{WF}_t = (\textrm{TW}/\textrm{cumulative\_median})$, lets us simplify\vspace{.175cm} +\[\textrm{F} = \textrm{B}*(2*\textrm{WF}_b*\textrm{WF}_t + \textrm{WF}_t^2)\] + +Using a block weighing 300kB (with a cumulative median at the default 300kB) and our reference transaction with 3000 bytes, +\begin{align*} + \textrm{F}_{\textrm{ref}} &= \textrm{B}*(2*0*\textrm{WF}_t + \textrm{WF}_t^2)\\ + \textrm{F}_{\textrm{ref}} &= \textrm{B}*\textrm{WF}_t^2\\ + \textrm{F}_{\textrm{ref}} &= \textrm{B}*(\frac{\textrm{TW}_{\textrm{ref}}}{\textrm{cumulative\_median}_{\textrm{ref}}})^2 +\end{align*}{} + +This fee is spread out over 1\% of the penalty zone (3000 out of 300000). We can spread the same fee over 1\% of any penalty zone with a generalized reference transaction.\vspace{.175cm} +\begin{align*} + \frac{\textrm{TW}_{\textrm{ref}}}{\textrm{cumulative\_median}_{\textrm{ref}}} &= \frac{\textrm{TW}_{\textrm{general-ref}}}{\textrm{cumulative\_median}_{\textrm{general}}}\\ + 1 &= (\frac{\textrm{TW}_{\textrm{general-ref}}}{\textrm{cumulative\_median}_{\textrm{general}}}) * (\frac{\textrm{cumulative\_median}_{\textrm{ref}}}{\textrm{TW}_{\textrm{ref}}})\\ + \textrm{F}_{\textrm{general-ref}} &= \textrm{F}_{\textrm{ref}}\\ + &= \textrm{F}_{\textrm{ref}}*(\frac{\textrm{TW}_{\textrm{general-ref}}}{\textrm{cumulative\_median}_{\textrm{general}}}) * (\frac{\textrm{cumulative\_median}_{\textrm{ref}}}{\textrm{TW}_{\textrm{ref}}})\\ + \textrm{F}_{\textrm{general-ref}} &= \textrm{B}*(\frac{\textrm{TW}_{\textrm{general-ref}}}{\textrm{cumulative\_median}_{\textrm{general}}}) * (\frac{\textrm{TW}_{\textrm{ref}}}{\textrm{cumulative\_median}_{\textrm{ref}}}) +\end{align*}{} + +Now we can scale the fee based on a real transaction weight at a given median, so e.g. if the transaction is 2\% of the penalty zone the fee gets doubled.\vspace{.175cm} +\begin{align*} + \textrm{F}_{\textrm{general}} &= \textrm{F}_{\textrm{general-ref}} * \frac{\textrm{TW}_{\textrm{general}}}{\textrm{TW}_{\textrm{general-ref}}}\\ + \textrm{F}_{\textrm{general}} &= \textrm{B}*(\frac{\textrm{TW}_{\textrm{general}}}{\textrm{cumulative\_median}_{\textrm{general}}}) * (\frac{\textrm{TW}_{\textrm{ref}}}{\textrm{cumulative\_median}_{\textrm{ref}}}) +\end{align*}{} + +This rearranges to the default fee per byte, which we have been working toward.\vspace{.175cm} +\begin{align*} + f^{B}_{default} &= \textrm{F}_{\textrm{general}}/\textrm{TW}_{\textrm{general}}\\ + f^{B}_{default} &= \textrm{B}*(\frac{1}{\textrm{cumulative\_median}_{\textrm{general}}}) * (\frac{3000}{300000}) +\end{align*}{} + +When transaction volume is below the median there is no real reason for fees to be at the reference level \cite{jollymore-old-analysis}. We set the minimum to be 1/5\nth the default.\vspace{.175cm} +\begin{align*} + f^{B}_{min} &= \textrm{B}*(\frac{1}{\textrm{cumulative\_weights\_median}}) * (\frac{3000}{300000}) * (\frac{1}{5})\\ + f^{B}_{min} &= \textrm{B}*(\frac{1}{\textrm{cumulative\_weights\_median}}) * 0.002 +\end{align*}{} + +\subsubsection*{The fee median} + +It turns out using the cumulative median for fees enables a spam attack. By raising the short term median to its highest value (50 x long term median), an attacker can use minimum fees to maintain high block weights (relative to organic transaction volume) with very low cost. + +To avoid this we limit fees for transactions to go in the next block with the smallest median available, which favors higher fees in all cases.\footnote{An attacker can spend just enough in fees for the short term median to hit 50*long-term-median. With current (as of this writing) block rewards at 2 XMR, an optimized attacker can increase the short term median by 17\% every 50 blocks, and reach the upper bound after about 1300 blocks (about 43 hours), spending 0.39*2 XMR per block, for a total setup cost of about 1000 XMR (or around 65k USD at current valuations), and then go back to the minimum fee. When the fee median equals the penalty-free zone, then the minimum total fee to fill the penalty-free zone is 0.004 XMR (about 0.26 USD at current valuations). If the fee median equals the long term median, it would in the spam scenario be 1/50th the penalty-free zone. Therefore it would just be 50x the short-median case, for 0.2 XMR per block (13 USD per block). This comes out to 2.88 XMR per day vs 144 XMR per day (for 69 days, until the long term median rises by 40\%) to maintain every block with 50*long-term-median block weight. The 1000 XMR setup cost would be worthwhile in the former case, but not the latter. This will reduce to 300 XMR setup, and 43 XMR maintenance, at the emission tail.}\vspace{.1cm} +\[\textrm{smallest\_median}\marginnote{src/crypto- note\_core\ block- chain.cpp {\tt check\_fee()}} = max\{\textrm{300kB}, min\{\textrm{median\_100blocks\_weights}, \textrm{effective\_longterm\_median}\}\}\] + +Favoring higher fees during rising transaction volume also facilitates adjusting the short term median and ensuring transactions aren't left pending, as miners are more likely to mine into the penalty zone. + +The actual minimum fee is therefore\footnote{To check if a given fee is correct, we allow a 2\% buffer on $f^{B}_{min-actual}$ in case of integer overflow (we must compute fees before tx weights are completely determined). This means the effective minimum fee is 0.98*$f^{B}_{min-actual}$.\marginnote{src/crypto- note\_core\ block- chain.cpp {\tt check\_fee()}}}\footnote{Research to improve minimum fees even further is ongoing. \cite{min-fee-research-issue-70}}%Blockchain::check_fee() + +\[f^{B}_{min-actual}\marginnote{src/crypto- note\_core\ block- chain.cpp {\tt get\_dyna- mic\_base\_ fee()}} = \textrm{B}*(\frac{1}{\textrm{smallest\_median}}) * 0.002\] + +\subsubsection*{Transaction fees} + +As Caba$\tilde{\textrm{n}}$as said in his insightful presentation on this topic \cite{articmine-36c3-dynamics}, ``[f]ees tell the miner how deep into the penalty [transaction authors are] willing to pay for, in order to get a transaction mined." Miners will fill up their blocks by adding transactions in descending order of fee amount \cite{articmine-36c3-dynamics} (assuming all transactions have the same weight), so to move into the penalty zone there must be numerous transactions with large fees. This means it is likely the block weight cap can only be reached if total fees are at least about 3-4 times the base block reward (at which point the actual block reward is zero).\footnote{\label{penaltyzonecost_footnote}The marginal penalty from the last bytes to fill up a block can be considered a `transaction' comparable to other transactions. In order for a clump of transactions to buy that transaction space from a miner, all its individual transaction fees should be higher than the penalty, since if any one of them is lower then the miner will keep the marginal reward instead. This last marginal reward, assuming a block filled with small transactions, requires at least 4x the base block reward in total fees to be purchased. If transaction weights are maximized (50\% of the minimum penalty-free zone, i.e. 150kB) then if the median is minimized (300kB) the last marginal transaction requires at least 3x in total fees.} + +To calculate fees for a transaction, Monero's core implementation wallet uses `priority'\marginnote{src/wallet/ wallet2.cpp {\tt get\_fee\_ multi- plier()}} multipliers. A `slow' transaction uses the minimum fee directly, `normal' is the default fee (5x), if all transactions use `fast' (25x) they can reach 2.5\% of the penalty zone, and a block with `super urgent' (1000x) transactions can fill 100\% of the penalty zone.%wallet2::get_fee_multiplier() + +One important consequence of dynamic block weights is average total block fees will tend to be of a magnitude lower than, or at least the same as, the block reward (total fees can be expected to equal the base block reward at about 37\% of the penalty zone [68.5\% of the maximum block weight], when the penalty is 13\%). Transactions competing for block space with higher fees leads to a bigger supply of block space, and lower fees.\footnote{As block rewards decline over time, and the median rises due to increased adoption (theoretically), fees should steadily become smaller and smaller. In `real purchasing power' terms, this may be less impactful on transaction costs if the value of Moneroj rises due to adoption and economic deflation.} This feedback mechanism is a strong counter to the renowned `selfish miner' \cite{selfish-miner} threat. + + +\subsection{Emission tail} +\label{subsec:emission-tail} + +Let's suppose a cryptocurrency with fixed maximum supply and dynamic block weight. After a while its block rewards fall to zero. With no more penalty on increasing block weight, miners add any transaction with a non-zero fee to their blocks. + +Block weights stabilize around the average rate of transactions submitted to the network, and transaction authors have no compelling reason to use transaction fees above the minimum, which would be zero according to Section \ref{subsec:dynamic-minimum-fee}. + +This introduces an unstable, insecure situation. Miners have little to no incentive to mine new blocks, leading to a fall in network hash rate as returns on investment decline. Block times remain the same as difficulties adjust, but the cost of performing a double-spend attack may become feasible.\footnote{The case of fixed supply and fixed block weight, as in Bitcoin, is also thought to be unstable. \cite{no-reward-instability}} If minimum fees are forced to be non-zero then the `selfish miner' \cite{selfish-miner} threat becomes realistic \cite{no-reward-instability}.\\ + +Monero\marginnote{src/crypto- note\_basic/ cryptonote\_ basic\_ impl.cpp {\tt get\_block\_ reward()}} prevents this by not allowing the block reward to fall below 0.6 XMR (0.3 XMR per minute). When the following condition is met,\vspace{.175cm} +\begin{align*} + 0.6 &> ((L-M) >> 19)/10^{12} \\ + \textrm{M} &> \textrm{L} - 0.6*2^{19}*10^{12} \\ +\textrm{M}/10^{12} &> \textrm{L}/10^{12} - 0.6*2^{19} \\ +\textrm{M}/10^{12} &> 18,132,171.273709551615 +\end{align*} + +the Monero chain will enter a so-called `emission tail', with constant 0.6 XMR (0.3 XMR/minute) block rewards forever after.\footnote{The Monero emission tail's estimated arrival is May 2022 \cite{monero-tail-emission}. The money supply limit L will be reached in May 2024, but since coin emission will no longer depend on the supply it will have no effect. Based on Monero's range proof, it will be impossible to send more money than L in one output, even if someone manages to accumulate more than that (and assuming they have wallet software that can handle that much).} This corresponds with about 0.9\% yearly inflation to begin with, steadily declining thereafter. + + +\subsection{Miner transaction: {\tt RCTTypeNull}} +\label{subsec:miner-transaction} %-fees -> summed into block reward and spent in the miner tx (construct_miner_tx function) + +A block's miner has the right to claim ownership of the fees provided in its transactions, and to mint new money in the form of a block reward. The mechanism is a miner transaction\marginnote{src/crypto- note\_core/ cryptonote\_ tx\_utils.cpp {\tt construct\_ miner\_tx()}} (a.k.a. coinbase transaction), which is similar to a normal transaction.\footnote{Apparently, at one point miner transactions could be constructed using deprecated transaction format versions, and could include some normal transaction (RingCT) components. The issues were fixed in protocol v12 after this hackerone report was published: \cite{miner-tx-checks}.} + +The output amount(s) of a miner transaction must be no more than the sum of transaction fees and block reward, and are communicated in clear text.\footnote{In the current version miners may claim less than the calculated block reward. The leftovers are pushed back into the emission schedule for future miners.} In place of an input, the block's height is recorded (i.e. ``I claim the block reward and fees for the n\nth block"). + +Ownership of the miner output(s) is assigned to a standard one-time address\footnote{The miner transaction output can theoretically be sent to a subaddress and/or use multisig and/or an encoded payment ID. We don't know if any implementations have any of those features.}, with a corresponding transaction public key stored in the extra field. The funds are locked, unspendable, until the 60\nth block after it is published \cite{transaction-lock}.\footnote{The miner tx can't be locked for more or less than 60 blocks. If it is published in the 10\nth block, its unlock height is 70, and it may be spent in the 70\nth block or later.\marginnote{src/crypto- note\_core/ block- chain.cpp {\tt is\_tx\_ spendtime\_ unlocked()}}[.5cm]}%justification? Blockchain::prevalidate_miner_transaction() + +Since RingCT was implemented in January 2017 (v4 of the protocol) \cite{ringct-dates}, people downloading a new copy of the blockchain compute a commitment to the miner transaction (a.k.a. tx) amount\marginnote{src/block- chain\_db/ blockchain\_ db.cpp {\tt add\_trans- action()}} $a$, as $C = 1G + aH$, and store it for referral. This allows block miners to spend their miner transaction outputs just like a normal transaction's outputs, putting them in MLSAG rings with other normal and miner tx outputs.\\ + +Blockchain verifiers store each post-RingCT block's miner tx amount commitment, for 32 bytes each. + + + +\section{Blockchain structure} +\label{sec:blockchain-structure} + +Monero's blockchain style is simple. + +It starts with a genesis message\marginnote{src/crypto- note\_core/ cryptonote\_ tx\_utils.cpp {\tt generate\_ genesis\_ block()}}[-.8cm] of some kind (in our case basically a miner transaction dispersing the first block reward), which constitutes the genesis block (see Appendix \ref{appendix:genesis-block}). The next block contains a reference to the previous block, in the form of block ID. + +A block ID is simply a hash of\marginnote{src/crypto- note\_basic/ cryptonote\_ format\_ utils.cpp {\tt get\_block\_ hashing\_ blob()}}[1.2cm] the block's header (a list of information about a block), a so-called `Merkle root' that attaches all the block's transaction IDs (which are hashes of each transaction), and the number of transactions (including the miner transaction).\marginnote{src/crypto- note\_basic/ cryptonote\_ format\_ utils.cpp {\tt calculate\_ block\_ hash()}}[4.5cm]\footnote{+1 accounts for the miner tx.}\vspace{.175cm} +%calculate_block_hash, which ultimately uses cn_fast_hash(get_block_hashing_blob) +\[\textrm{Block ID} = \mathcal{H}_n(\textrm{Block header}, \textrm{Merkle root}, \# \textrm{transactions} + 1)\]\vspace{.05cm} + +To produce a new block, one must do proof of work hashes by changing a nonce value stored in the block header until the difficulty target condition is met.\footnote{In Monero a typical miner (from \url{https://monerobenchmarks.info/} as of this writing) can do less than 50,000 hashes per second, so less than 6 million hashes per block. This means the nonce variable doesn't need to be that big. Monero's nonce is 4 bytes (max 4.3 billion), and it would be strange for any miner to require all the bits.} The proof of work and block ID hash the same information, except use different hash functions. Blocks are mined\marginnote{{\tt get\_block\_ longhash()}}[5.55cm] by, while $({PoW}_{output} * {difficulty}) > 2^{256}-1$, repeatedly changing the nonce and recalculating\vspace{.175cm} +\[{PoW}_{output} = \mathcal{H}_{PoW}(\textrm{Block header}, \textrm{Merkle root}, \# \textrm{transactions} + 1)\] + + +\subsection{Transaction ID} +\label{subsec:transaction-id} %calculate_transaction_hash + %each arrow is a hash +Transaction IDs are similar to the message signed by input MLSAG signatures (Section \ref{full-signature}), but include the MLSAG signatures too. + +The following information is hashed: +\begin{itemize} + \item TX Prefix\marginnote{src/crypto- note\_basic/ cryptonote\_ format\_ utils.cpp {\tt calculate\_ transa- ction\_ hash()}} = \{transaction era version (e.g. ringCT = 2), inputs \{key offsets, key images\}, outputs \{one-time addresses\}, extra \{transaction public key, encoded payment ID, misc.\}\} + \item TX Stuff = \{signature type ({\tt RCTTypeNull} or {\tt RCTTypeBulletproof2}), transaction fee, pseudo output commitments for inputs, ecdhInfo (encrypted or cleartext amounts), output commitments\} + \item Signatures = \{MLSAGs, range proofs\} +\end{itemize} + +In this tree diagram the black arrow indicates a hash of inputs. + +\begin{center} + \begin{forest} + forked edges, + for tree = {grow'=90, + edge = {<-, > = triangle 60}, + fork sep = 4.5 mm, + l sep = 8 mm, + rectangle, draw + }, + sn edges, + where n children=0{tier=terminus}{}, + [Transaction ID + [$\mathcal{H}_n$(TX Prefix)] + [$\mathcal{H}_n$(TX Stuff)] [$\mathcal{H}_n$(Signatures)] + ] + \end{forest} +\end{center} + +In place of an `input', a miner transaction records the block height of its block. This ensures the miner transaction's ID, which is simply a normal transaction ID except with $\mathcal{H}_n$(Signatures) $\rightarrow$ 0, is always unique, for simpler ID-searching. + + +\subsection{Merkle tree} +\label{subsec:merkle-tree} %tree_hash + +Some users may want to discard data from their copy of the blockchain. For example, once you verify a transaction's range proofs and input signatures, the only reason to keep that signature information is so users who obtain it from you can verify it for themselves. + +To\marginnote{src/crypto/ tree-hash.c {\tt tree\_hash()}} facilitate `pruning' transaction data, and to more generally organize it within a block, we use a Merkle tree \cite{merkle-tree}, which is just a binary hash tree. Any branch in a Merkle tree can be pruned if you keep its root hash.\footnote{The first known pruning method was added in v0.14.1 of the core Monero implementation (March 2019, coinciding with protocol v10). After verifying a transaction, full nodes can delete all its signature data (including Bulletproofs, MLSAGS, and pseudo output commitments) while keeping $\mathcal{H}_n$(Signatures) for computing the transaction ID. They only do this with 7/8\nths of all transactions, so every transaction is fully stored by at least 1/8\nth of the network's full nodes. This reduces blockchain storage by about 2/3\rds. \cite{monero-pruning-1/8}}\\ + +An example Merkle tree based on four transactions and a miner transaction is diagrammed in Figure \ref*{chapter:blockchain}.1.\footnote{A bug in Monero's Merkle tree code led to a serious, though apparently non-critical, real-world attack on September 4\nth, 2014 \cite{MRL-0002-merkle-problem}.} + +\begin{center} + \begin{forest} + forked edges, + for tree = {grow'=90, + edge = {<-, > = triangle 60}, + fork sep = 4.5 mm, + l sep = 8 mm, + rectangle, draw + }, + sn edges, + where n children=0{tier=terminus}{}, + [Merkle Root + [$Hash$ B + [Transaction ID \\1] + [Transaction ID \\2] + ] + [$Hash$ C + [Transaction ID \\3] + [$Hash$ A + [Transaction ID \\4] + [Miner Transaction ID] + ] + ] + ] + \node at (current bounding box.south) + [below=3ex,thick,draw,rectangle] + {\emph{Figure \ref*{chapter:blockchain}.1: Merkle Tree}}; + \end{forest} +\end{center} + +A Merkle root is inherently a reference to all its included transactions. + + + +\newpage +\subsection{Blocks} +\label{subsec:blocks} %https://monero.stackexchange.com/questions/3958/what-is-the-format-of-a-block-in-the-monero-blockchain/6461#6461 + +A block is basically a block header and some transactions. Block headers record important information about each block. A block's transactions can be referenced with their Merkle root. We present here the outline of a block's content. Our readers can find a real block example in Appendix \ref{appendix:block-content}. +\begin{itemize} + \item \underline{Block header}: + \begin{itemize} + \item \textbf{Major version}: Used to track hard forks (changes to the protocol). + \item \textbf{Minor version}: Once used for voting, now it just displays the major version again. + \item \textbf{Timestamp}:\marginnote{src/crypto- note\_core/ block- chain.cpp {\tt check\_ block\_ timestamp()}} UTC (Coordinated Universal Time) time of the block. Added by miners, timestamps are unverified but they won't be accepted if lower than the median timestamp of the previous 60 blocks. %check_block_timestamp + \item \textbf{Previous block's ID}: Referencing the previous block, this is the essential feature of a blockchain. + \item \textbf{Nonce}: A 4-byte integer that miners change over and over until the PoW hash meets the difficulty target. Block verifiers can easily recalculate the PoW hash. + \end{itemize} + \item \underline{Miner transaction}: Disperses the block reward and transaction fees to the block's miner. + \item \underline{Transaction IDs}: References to non-miner transactions added to the blockchain by this block. Tx IDs can, in combination with the miner tx ID, be used to calculate the Merkle root, and to find the actual transactions wherever they are stored.\\ +\end{itemize}\vspace{.05cm} + +In addition to the data in each transaction (Section \ref{sec:transaction_summary}), we store the following information: +\begin{itemize} + \setlength\itemsep{\listspace} + \item Major and minor versions: variable integers $\leq 9$ bytes + \item Timestamp: variable integer $\leq 9$ bytes + \item Previous block's ID: 32 bytes + \item Nonce: 4 bytes, can extend its effective size with the miner tx extra field's extra nonce\footnote{Within each transaction is an `extra' field which can contain more-or-less arbitrary data. If a miner needs a wider range of nonces than just 4 bytes, they can add or alter data in their miner tx's extra field to `extend' the nonce size. \cite{extra-field-stackexchange}} + \item Miner transaction: 32 bytes for a one-time address, 32 bytes for a transaction public key (+1 byte for its `extra' tag), and variable integers for the unlock time, corresponding block's height, and amount. After downloading the blockchain, we also need 32 bytes to store an amount commitment $C = 1G + a H$ (only for post-RingCT miner tx amounts). + \item Transaction IDs: 32 bytes each +\end{itemize} \ No newline at end of file diff --git a/translations/es/content/bulletproofs.tex b/translations/es/content/bulletproofs.tex new file mode 100755 index 0000000..20e4d69 --- /dev/null +++ b/translations/es/content/bulletproofs.tex @@ -0,0 +1,136 @@ +\chapter{Bulletproofs (WIP)} +\label{chapter:bulletproofs} +%this chapter was not finished since I decided not to include a bulletproofs explanation in ztm2 + + +%---------- +\section{Vector Knowledge Proof} +\label{sec:vectorzkproof} + +Prove knowledge of all elements in vector set $\boldsymbol{V}$ containing $m$ vectors of size $N$ ($m \neq N$), committed to in $(C_1, C_2,..., C_m)$ where $C_i = v_{i,1}*H_1 + v_{i,2}*H_2 + ... + v_{i,N}*H_N$. The discrete logarithms with respect to $G$ of generators in vector $\boldsymbol{H} = \langle H_1,..., H_N \rangle$, $\boldsymbol{\lambda} = \langle \lambda_1, ..., \lambda_N \rangle$, are unknown (and e.g. the discrete log of $H_2$ with respect to $H_4$). Verifiers know there are $m*N$ elements, but gain no information about them. + +\subsubsection*{Non-interactive proof} + +\begin{enumerate} + \item Generate a vector (size N+1) of random integers \(\boldsymbol{\alpha} \in_R \mathbb{Z}_l\), and compute the inner product $C_{\alpha} = \boldsymbol{\alpha} \bullet \textbf{H}$.\footnote{The inner product (a.k.a. dot product) between vectors \(\boldsymbol{v} = \langle 1, 2, 3 \rangle\) and \(\boldsymbol{z} = \langle 4, 5, 6 \rangle\) is \(\boldsymbol{v} \bullet \boldsymbol{z} = 1*4 + 2*5 + 3*6 = 32\).} + \item Calculate the {\em challenge} $c = \mathcal{H}(T_{vec},\boldsymbol{V},C_{\alpha})$.\footnote{We explicitly do domain separation here with $T_{vec}$, and key prefixing with $\boldsymbol{V}$. For the rest of the chapter it is implied with ellipses (...). Those ellipses could also include a message $\mathfrak{m}$ to make the proof a signature.} + \item Define the {\em response vector} (size N+1) $\textbf{r}$, with an element $r_j$ for each generator $H_j$ (imagine vectors listed out in rows, and here we take the column sum with one $v_{i,j}$ from each vector $i$) (note each one is multiplied by $c$ raised to power $i$) + \[r_j = \alpha_j - \sum^{m}_{i=1} c^i*v_{i,j}\] + \item Publish the proof pair $(c, \boldsymbol{r})$. +\end{enumerate} + + +\subsubsection*{Verification} + +\begin{enumerate} + \item Calculate the challenge: \(c' = \mathcal{H}(...,\textbf{r} \bullet \textbf{H} + \sum^{m}_{i=1} (c')^i*C_i)\). + \item If $c = c'$ then the prover must know $\boldsymbol{V}$ (except with negligible probability). +\end{enumerate} + +\subsubsection*{Why it works} + +\begin{align*} +\textbf{r} \bullet \textbf{H} &= C_{\alpha} - \sum^{m}_{i=1} (c')^i*C_i \\ +\sum^{N}_{j=1} [r_j*H_j] &= C_{\alpha} - \sum^{m}_{i=1} (c')^i*C_i \\ +\sum^{N}_{j=1} [(\alpha_j - \sum^{m}_{i=1} c^i*v_{i,j})*H_j] &= C_{\alpha} - \sum^{m}_{i=1} (c')^i*C_i \\ +(\sum^{N}_{j=1} \alpha_j*H_j) - \sum^{N}_{j=1} [(\sum^{m}_{i=1} c^i*v_{i,j})*H_j] &= C_{\alpha} - \sum^{m}_{i=1} (c')^i*C_i \\ +C_{\alpha} - \sum^{m}_{i=1} c^i*[\sum^{N}_{j=1} v_{i,j}*H_j] &= C_{\alpha} - \sum^{m}_{i=1} (c')^i*C_i \\ +C_{\alpha} - \sum^{m}_{i=1} c^i*C_i &= C_{\alpha} - \sum^{m}_{i=1} (c')^i*C_i \\ +\end{align*} + +Verifiers can be confident that provers know all elements of $\boldsymbol{V}$ (except with negligible probability) thanks to a confluence of features in this proof (combined with the logic from basic Schnorr Signatures, explained in Section \ref{sec:schnorr-fiat-shamir}).%Verifiers can compute $R' = C_{\alpha} + \sum^{m}_{i=1} c^i*C_i$ before the prover, so providing $c$ is like saying ``I challenge you to respond with the discrete logarithm vector $\boldsymbol{r}$ of $R'$." + +\subsubsection*{Justification of Features} + +\begin{enumerate} + \item If we do not use $\boldsymbol{H}$ or powers of $c$, and the response was instead $r = \sum \boldsymbol{\alpha} + c* \sum_{i=1}^{m} (\sum_{j=1}^{N} v_{i,j})$, then provers have only demonstrated they know the sum of all vector elements (at most). Or, in other words, just the discrete logarithm of $K = \sum_{i=1}^{m} C_i$ as in a normal Schnorr signature. + + \item Adding in $\boldsymbol{H}$ makes $r_j = \alpha_j + c* \sum_{i=1}^{m} v_{i,j}$, which ensures provers must at least know the sum at each vector index $j$. While there may exist many other $\boldsymbol{r'}$ vectors that produce $R = \boldsymbol{r'} \bullet \boldsymbol{H} = r'_1*\lambda_1*G + r'_2*\lambda_2*G + ...$, it is very difficult to find any of them using just the sum of all elements (step 1) without knowing $\boldsymbol{\lambda}$ (which we assume to be unknown).\footnote{Even if two or more vector indexes have the same sum ($\sum_{i=1}^{m} v_{i,a} = \sum_{i=1}^{m} v_{i,b} = k$), $k$ will not be revealed since in the equation pair $r_a = \alpha_a + c*k$ and $r_b = \alpha_b + c*k$ there are three unknowns ($\alpha_a$, $\alpha_b$, and $k$), and each additional equation $r_q = \alpha_q + c*k$ adds another unknown ($\alpha_q$).} + + \item Including powers of $c$ turns each response element $r_j$ into a polynomial function of $c$, $r_j(c) = \alpha_j + v_{1,j}*c + v_{2,j}*c^2 + ... + v_{m,j}*c^m$. Now, given $c$, there are many combinations of ($\alpha'_j, v'_{1,j}, ..., v'_{m,j}$) that will produce $r_j$, but the probability of guessing one is negligible since $r_j$ is itself unknown (and can be anything between 1 and $l$ [$l$ is the elliptic curve subgroup]). Even if the sum at each vector index is known (step 2), guessing a useful factorization becomes increasingly difficult as the size of $\boldsymbol{V}$ rises (usually the only one that works will be the actual elements of $\boldsymbol{V}$). Moreover, $c$ is unknown in advance so provers can't report a random $r_j$ (recall Section \ref{sec:schnorr-fiat-shamir}). This means provers must know all elements of $\boldsymbol{V}$.\footnote{A person with partial knowledge of $\boldsymbol{V}$ can increase his chances of faking the proof (by only a negligible amount in most cases). For an extreme example, if he knows all elements of $\boldsymbol{V}$ except one, he knows all commitments $C_j$ and their blinding factors, and he knows the missing element is in the range ($q$ to $p$) where ($p - q < l$), then his chances of guessing that element (and checking by computing $C'_j$) are higher than solving the discrete logarithm problem via guess and check. Though in this case he ultimately knows all elements of $\boldsymbol{V}$ anyway. This logic extends to other partial-knowledge scenarios.} +\end{enumerate} + + +%---------- +\section{Inner Product Proof} + +Suppose we have two vectors $\boldsymbol{v}$ and $\boldsymbol{z}$, each with $N$ elements. Their inner product is $s = \boldsymbol{v} \bullet \boldsymbol{z}$, we have their commitments $[C_s = x_s G + s H_1, C_v = (x_v, \boldsymbol{v}) \bullet (G,\boldsymbol{H}), C_z = (x_z, \boldsymbol{z}) \bullet (G,\boldsymbol{H})]$\footnote{Our notation $(x_v, \boldsymbol{v}) \bullet (G,\boldsymbol{H})$ here means blinding factor $x_v$ is appended to the front of $\boldsymbol{v}$ for the inner product, and likewise with generator $G$.}, and we want to prove the inner product equation holds (and that we know all the elements) without revealing any information (aside from N) about $(s, \boldsymbol{v}, \boldsymbol{z})$. In other words, prove the value in $C_s$ is the inner product of the vectors, size N, in $C_v$ and $C_z$. Note that now we include blinding factors $x_s$, $x_v$, and $x_z$, which are not strictly part of the vectors being considered. This concept will be useful in later sections, where it is important to hide the original values with a random mask. + +Basically, we do two vector knowledge proofs (Section \ref{sec:vectorzkproof}) for $\boldsymbol{v}$ and $\boldsymbol{z}$, and an extra bit for the inner product. + + +\subsubsection*{Non-interactive proof} + +\begin{enumerate} + \item Generate two vectors (size N) and four integers \((\alpha_{v,0}, \boldsymbol{\alpha_v}, \alpha_{z,0}, \boldsymbol{\alpha_z}, \alpha_{s,0}, \alpha_{s,1}) \in_R \mathbb{Z}_l\), and compute + \begin{align*} + C_{\alpha}^{v} &= (\alpha_{v,0},\boldsymbol{\alpha_v}) \bullet (G,\textbf{H}) \\ + C_{\alpha}^{z} &= (\alpha_{z,0}, \boldsymbol{\alpha_z}) \bullet (G,\textbf{H}) \\ + C_{\alpha}^{s,0} &= \alpha_{s,0}*G + (\boldsymbol{\alpha_v} \bullet \boldsymbol{\alpha_z})*H_1 \\ + C_{\alpha}^{s,1} &= \alpha_{s,1}*G + (\boldsymbol{v} \bullet \boldsymbol{\alpha_z} + \boldsymbol{z} \bullet \boldsymbol{\alpha_v})*H_1 + \end{align*} + \item Calculate the {\em challenge} $c = \mathcal{H}(...,C_{\alpha}^{v},C_{\alpha}^{z},C_{\alpha}^{s,0},C_{\alpha}^{s,1})$. + \item Define the {\em response}, $\boldsymbol{r}$, containing vectors (size N) $\boldsymbol{r_v}, \boldsymbol{r_z}$, with $r_{v,0}, r_{z,0}$ for the vectors' blinding factors, and $r_s$ for the inner product blinding factor + \begin{align*} + r_{v,0} &= \alpha_{v,0} - c*x_v \\ + r_{z,0} &= \alpha_{z,0} - c*x_z \\ + r_{v,j} &= \alpha_{v,j} - c*v_j \\ + r_{z,j} &= \alpha_{z,j} - c*z_j \\ + r_s &= \alpha_{s,0} + c*\alpha_{s,1} + c^2*x_s + \end{align*} + \item Publish the proof $(c, \boldsymbol{r}, C^{s,0}_{\alpha}, C^{s,1}_{\alpha})$. +\end{enumerate} + +\subsubsection*{Verification} + +\begin{enumerate} + \item Calculate the challenge: + \[c' = \mathcal{H}(...,[(r_{v,0},\boldsymbol{r_v}) \bullet (G,\textbf{H}) + c*C_v],[(r_{z,0},\boldsymbol{r_z}) \bullet (G,\textbf{H}) + c*C_z],[C^{s,0}_{\alpha}],[C^{s,1}_{\alpha}])\] + \item Compute\footnote{Since $C^{s,0}_{\alpha}$ and $C^{s,1}_{\alpha}$ are tied together, it isn't possible (within our knowledge) to move $R_s$ into the challenge computation.} + \begin{align*} + %R_v &= (r_{v,0},\boldsymbol{r_v}) \bullet \textbf{H} \\ + %R'_v &= C_{\alpha}^{v} + c'*C_v \\ + %R_z &= (r_{z,0},\boldsymbol{r_z}) \bullet \textbf{H} \\ + %R'_z &= C_{\alpha}^{z} + c'*C_z \\ + R_s &= r_s*G + (\boldsymbol{r_v} \bullet \boldsymbol{r_z})*H_1 \\ + R'_s &= C_{\alpha}^{s,0} + c'*C_{\alpha}^{s,1} + c'^2*C_s + \end{align*} + \item If $c = c'$, and $R_s = R'_s$, then the prover must know $\boldsymbol{v}, \boldsymbol{z}$, and $s$, and the inner product $s = \boldsymbol{v} \bullet \boldsymbol{z}$ must hold (except with negligible probability). +\end{enumerate} + +\subsubsection*{Why it works (inner product component)} + +\begin{align*} +r_s*G + (\boldsymbol{r_v} \bullet \boldsymbol{r_z})*H_1 &= C_{\alpha}^{s,0} + c*C_{\alpha}^{s,1} + c^2*C_s \\ +(\alpha_{s,0} + c \alpha_{s,1} + c^2 x_s)*G + (\boldsymbol{\alpha_v} \bullet \boldsymbol{\alpha_z} + c[\boldsymbol{v} \bullet \boldsymbol{\alpha_z} + \boldsymbol{z} \bullet \boldsymbol{\alpha_v}] + c^2 [\boldsymbol{v} \bullet \boldsymbol{z}])*H_1 &= C_{\alpha}^{s,0} + c*C_{\alpha}^{s,1} + c^2*C_s \\ +C_{\alpha}^{s,0} + c*C_{\alpha}^{s,1} + c^2 (x_s*G + [\boldsymbol{v} \bullet \boldsymbol{z}]*H_1) &= C_{\alpha}^{s,0} + c*C_{\alpha}^{s,1} + c^2*C_s \\ +c^2 (x_s*G + [\boldsymbol{v} \bullet \boldsymbol{z}]*H_1) &= c^2(x_s*G + s*H_1) \\ +\boldsymbol{v} \bullet \boldsymbol{z} &= s +\end{align*} + +Responses $\boldsymbol{r_v}$ and $\boldsymbol{r_z}$ prove knowledge of vectors $\boldsymbol{v}$ and $\boldsymbol{z}$, so using them in $R_s \stackrel{?}{=} R'_s$ proves the inner product holds. Readers can explore the algebraic logic to confirm this for themselves. + + +\section{Condensed Vector Knowledge Proof} +\label{sec:condensedvectorproof} + +Our original vector knowledge proof was $(c, \boldsymbol{r})$, where the proof size was linear with vector dimension. Given $N = 500$ (and $m = 1$), the proof will take up $(1 + 500)*32 = 16032$ bytes. We can condense the proof size with an approach exposed by Bootle et. al. \cite{bootle-efficient-zkcircuits}. It will be logarithmic with vector dimension (proof size $\approx 6*log_2(N)$, so for N = 500 proof size around 54*32 = 1728 bytes). + + +\subsection*{Non-interactive proof} + +\begin{enumerate} + \item With the intent of minimizing proof size (optimizing verification time is more complex), factor $N$ into $q$ prime numbers ordered largest to smallest. If $N = 500$, $\boldsymbol{f} = \langle 500, 5, 5, 5, 2, 2 \rangle $ and indexed $0$ to $q = 5$ (0\nth term is the original N). + \item For $i = 1$ to $q$ (index 0 corresponds to original vectors), + \begin{enumerate} + \item Chunk $\boldsymbol{v}^{i-1}$ and $\boldsymbol{G}^{i-1}$ into smaller vectors size $f[i]$ + \[ \langle v^{i-1}[1], ..., v^{i-1}[f[i-1]] \rangle \xrightarrow{} \langle \langle v^{i-1}[1],...,v^{i-1}[f[i] \rangle,\langle \rangle,...,\langle v^{i-1}[f[i-1] - f[i] ],..., v^{i-1}[f[i-1]\rangle \rangle \] + \end{enumerate} + \[\begin{pmatrix} + 1 & 2 & 3 \\ + 4 & 5 & 6 + \end{pmatrix}\] +\end{enumerate} + + +\subsection*{Verification} \ No newline at end of file diff --git a/translations/es/content/commitments.tex b/translations/es/content/commitments.tex new file mode 100755 index 0000000..a2d9172 --- /dev/null +++ b/translations/es/content/commitments.tex @@ -0,0 +1,119 @@ +\chapter{Monero Amount Hiding} +\label{chapter:pedersen-commitments} + +In most cryptocurrencies like Bitcoin, transaction output notes, which give spending rights to `amounts' of money, communicate those amounts in clear text. This allows observers to easily verify the amount spent equals the amount sent. + +In Monero we use {\em commitments} to hide output amounts from everyone except senders and receivers, while still giving observers confidence that a transaction sends no more or less than what is spent. As we will see, amount commitments must also have corresponding `range proofs' which prove the hidden amount is within a legitimate range. + + + +\section{Commitments} +\label{sec:commitments} + +Generally speaking, a cryptographic {\em commitment scheme} is a way of committing to a value without revealing the value itself. After committing to something, you are stuck with it. + +For example, in a coin-flipping game Alice could privately commit to one outcome (i.e. ‘call it’) by hashing her committed value with secret data and publishing the hash. After Bob flips the coin, Alice declares which value she committed to and proves it by revealing the secret data. Bob could then verify her claim. + +In other words, assume that Alice has a secret string $blah$ and the value she wants to commit to is $heads$. She hashes $h = \mathcal{H}(blah, heads)$ and gives $h$ to Bob. Bob flips a coin, then Alice tells Bob the secret string $blah$ and that she committed to $heads$. Bob calculates $h’ = \mathcal{H}(blah, heads)$. If $h' = h$, then he knows Alice called $heads$ before the coin flip. + +Alice uses the so-called `salt', $blah$, so Bob can't just guess $\mathcal{H}(heads)$ and $\mathcal{H}(tails)$ before his coin flip, and figure out she committed to $heads$.\footnote{If the committed value is very difficult to guess and check, e.g. if it's an apparently random elliptic curve point, then salting the commitment isn't necessary.} + + + +\section{Pedersen commitments} +\label{pedersen_section} + +A {\em Pedersen commitment} \cite{Pedersen1992} is a commitment that has the property of being {\em additively homomorphic}. If \(C(a)\) and \(C(b)\) denote the commitments for values \(a\) and \(b\) respectively, then \(C(a + b) = C(a) + C(b)\).\footnote{Additively homomorphic in this context means addition is preserved when you transform scalars into EC points by applying, for scalar $x$, $x \rightarrow x G$.} This property will be useful when committing transaction amounts, as one can prove, for instance, that inputs equal outputs, without revealing the amounts at hand. +\\ + +Fortunately, Pedersen commitments are easy to implement with elliptic curve cryptography, as the following holds trivially \[a G + b G = (a + b) G\] + +Clearly, by defining a commitment as simply \(C(a) = a G\), we could easily create cheat tables of commitments to help us recognize common values of $a$. + +To attain information-theoretic privacy, one needs to add a secret {\em blinding factor} and another generator \(H\), such that it is unknown for which value of \(\gamma\) the following holds: \(H = \gamma G\). The hardness of the discrete logarithm problem ensures calculating $\gamma$ from $H$ is infeasible.\footnote{In the case of Monero\marginnote{src/ringct/ rctTypes.h}, $H = 8*to\_point(\mathcal{H}_n(G))$. This differs from the $\mathcal{H}_p$ hash function in that it directly interprets the output of $\mathcal{H}_n(G)$ as a compressed point coordinate instead of deriving a curve point mathematically (see \cite{hashtopoint-writeup}). The historical reasons for this discrepancy\marginnote{tests/unit\_ tests/ ringct.cpp {\tt TEST(ringct, HPow2)}} are unknown to us, and indeed this is the only place where $\mathcal{H}_p$ is not used (Bulletproofs also use $\mathcal{H}_p$). Note how there is a $*8$ operation, to ensure the resultant point is in our $l$ subgroup ($\mathcal{H}_p$ also does that).} + +%In the case of Monero\marginnote{src/ringct/ rctTypes.h}, $H = \mathcal{H}_p(G)$.\footnote{\label{hashtopoint_note}Monero's unique hash to point function\marginnote{src/ringct/ rctOps.cpp {\tt hash\_to\_p3()}} (see \cite{hashtopoint-writeup}) is used in practice to turn the normal hash of one curve point directly into another curve point. For commitments, $H = hash\_to\_point(\mathit{Keccak}(G))$. }%see rctTypes.h + +We can then define the commitment to a value \(a\) as \(C(x, a) = x G + a H\), where \(x\) is the blinding factor (a.k.a. `mask') that prevents observers from guessing $a$. + +Commitment $C(x, a)$ is information-theoretically private because there are many possible combinations of $x$ and $a$ that would output the same $C$.\footnote{Basically, there are many $x’$ and $a’$ such that $x’+a’ \gamma = x+a \gamma$. A committer knows one combination, but an attacker has no way to know which one. This property is also known as `perfect hiding' \cite{adam-zero-to-bulletproofs}. Furthermore, even the committer can't find another combination without solving the DLP for $\gamma$, a property called `computational binding' \cite{adam-zero-to-bulletproofs}.} If $x$ is truly random, an attacker would have literally no way to figure out $a$ \cite{maxwell-ct, SCOZZAFAVA1993313}.%{https://people.xiph.org/~greg/confidential_values.txt} + + + +\section{Amount commitments} +\label{sec:pedersen_monero} + +In Monero, output amounts are stored in transactions as Pedersen commitments. We define a commitment to an output’s amount $b$ as:\vspace{.175cm} +\[C(y,b) = y G + b H\marginnote{src/ringct/ rctOps.cpp {\tt addKeys2()}}\] + +Recipients should be able to know how much money is in each output they own, as well as reconstruct the amount commitments, so they can be used as the inputs to new transactions. This means the blinding factor $y$ and amount $b$ must be communicated to the receiver. + +The solution adopted is a Diffie-Hellman shared secret $r K_B^v$ using the `transaction public key' (recall Section \ref{sec:multi_out_transactions}). For any given transaction in the blockchain, each of its outputs $t \in \{0, ..., p-1\}$ has a mask $y_t$ that senders and receivers can privately compute, and an {\em amount} stored in the transaction's data. While $y_t$ is an elliptic curve scalar and occupies 32 bytes, $b$ will be restricted to 8 bytes by the range proof so only an 8 byte value needs to be stored.\footnote{As\marginnote{src/crypto- note\_core/ cryptonote\_ tx\_utils.cpp {\tt construct\_ tx\_with\_ tx\_key()} calls {\tt generate\_ output\_ ephemeral\_ keys()}} with the one-time address $K^o$ from Section \ref{sec:one-time-addresses}, the output index $t$ is appended to the shared secret before hashing. This ensures outputs directed to the same address do not have similar masks and {\em amounts}, except with negligible probability. Also like before, the term $r K^v_B$ is multiplied by 8, so it's really $8rK^v_B.$}\footnote{This solution (implemented in v10 of the protocol) replaced a previous method that used more data, thereby causing the transaction type to change from v3 ({\tt RCTTypeBulletproof}) to v4 ({\tt RCTTypeBulletproof2}). The first edition of this report discussed the previous method \cite{ztm-1}.}\marginnote{src/ringct/ rctOps.cpp {\tt ecdh- Encode()}}[.725cm]\vspace{.175cm}%Under construct_tx_with_tx_key, key_amounts is created with the shared secret r K_B^v concatenated with the index by calling generate_output_ephemeral_keys() which then uses derivation_to_scalar(), then ecdhEncode builds the mask and amount when key_amounts is passed to it with the unmasked mask & amount. After update, ecdhHash and xor8 also play a role. +\begin{align*} + y_t &= \mathcal{H}_n(``commitment\_mask",\mathcal{H}_n(r K_B^v, t)) \\ + \mathit{amount}_t &= b_t \oplus_8 \mathcal{H}_n(``amount”, \mathcal{H}_n(r K_B^v, t)) +\end{align*} + +Here, $\oplus_8$ means to perform an XOR operation (Section \ref{sec:XOR_section}) between the first 8 bytes of each operand ($b_t$ which is already 8 bytes, and $\mathcal{H}_n(...)$ which is 32 bytes). Recipients can perform the same XOR operation on $\mathit{amount}_t$ to reveal $b_t$. + +The receiver Bob will be able to calculate the blinding factor $y_t$ and the amount $b_t$ using the transaction public key $r G$ and his view key $k_B^v$. He can also check that the commitment $C(y_t, b_t)$ provided in the transaction data, henceforth denoted $C_t^b$, corresponds to the amount at hand.\\ + +More generally, any third party with access to Bob’s view key could decrypt his output amounts, and also make sure they agree with their associated commitments. + + + +\section{RingCT introduction} +\label{sec:ringct-introduction} + +A transaction will contain references to other transactions' outputs (telling observers which old outputs are to be spent), and its own outputs. The content of an output includes a one-time address (assigning ownership of the output) and an output commitment hiding the amount (also the encoded output amount from Section \ref{sec:pedersen_monero}). + +While a transaction's verifiers don’t know how much money is contained in each input and output, they still need to be sure the sum of input amounts equals the sum of output amounts. Monero uses a technique called RingCT \cite{MRL-0005-ringct}, first implemented in January 2017 (v4 of the protocol), to accomplish this. + +If we have a transaction with $m$ inputs containing amounts \(a_1, ..., a_m\), and $p$ outputs with amounts \(b_0, ..., b_{p-1}\), then an observer would justifiably expect that:\footnote{If the intended total output amount doesn't precisely equal any combination of owned outputs, then transaction authors can add a `change' output sending extra money back to themselves. By analogy to cash, with a 20\$ bill and 15\$ expense you will receive 5\$ back from the cashier.}\vspace{.175cm} +\[\sum_j a_j - \sum_t b_t = 0\] + +Since commitments are additive and we don't know $\gamma$, we could easily prove our inputs equal outputs to observers by making the sum of commitments to input and output amounts equal zero (i.e. by setting the sum of output blinding factors equal to the sum of old input blinding factors):\footnote{Recall from Section \ref{elliptic_curves_section} we can subtract a point by inverting its coordinates then adding it. If $P = (x, y)$, $-P = (-x, y)$. Recall also that negations of field elements are calculated$\pmod q$, so $(–x \pmod q)$.}\vspace{.175cm} +\[\sum_{j}{C_{j, in}} - \sum_{t}{C_{t, out}} = 0\] + +To avoid sender identifiability we use a slightly different approach. The amounts being spent correspond to the outputs of previous transactions, which had commitments\vspace{.175cm} +\[C^a_{j} = x_j G + a_j H\] + +The sender can create new commitments to the same amounts but using different blinding factors; that is, +\[C'^a_{j} = x'_j G + a_j H\] + +Clearly, she would know the private key of the difference between the two commitments: \vspace{.175cm} +\[C^a_{j} - C'^a_{j} = (x_j - x'_j) G\]\\ +Hence, she would be able to use this value as a {\em commitment to zero}, since she can make a signature with the private key $(x_j - x'_j) = z_j$ and prove there is no $H$ component to the sum (assuming $\gamma$ is unknown). In other words prove that $C^a_{j} - C'^a_{j} = z_j G + 0H$, which we will actually do in Chapter \ref{chapter:transactions} when we discuss the structure of RingCT transactions. + +Let us call $C'^a_j$ a {\em pseudo output commitment}. Pseudo output commitments are included in transaction data, and there is one for each input. + +Before committing a transaction to the blockchain, the network will want to verify that its amounts balance. Blinding factors for pseudo and output commitments are selected such that\vspace{.175cm} +\[\sum_j x'_j - \sum_t y_t = 0\] + +This\marginnote{src/ringct/ rctSigs.cpp verRct- Semantics- Simple()} allows us to prove input amounts equal output amounts:\vspace{.175cm} +\[(\sum_j C'^a_{j} - \sum_t C^b_{t}) = 0\] + +Fortunately, choosing such blinding factors is easy. In the current version of Monero, all blinding factors are random except for the $m$\nth pseudo out commitment, where $x'_m$ is simply\marginnote{genRct- Simple()} +\[x'_m = \sum_t y_t - \sum_{j=1}^{m-1} x'_j\] + + + +\section{Range proofs} +\label{sec:range_proofs} + +One problem with additive commitments is that, if we have commitments $C(a_1)$, $C(a_2)$, $C(b_1)$, and $C(b_2)$ and we intend to use them to prove that $(a_1 + a_2) - (b_1 + b_2) = 0$, then those commitments would still apply if one value in the equation were `negative'. + +For instance, we could have $a_1 = 6$, $a_2 = 5$, $b_1 = 21$, and $b_2 = -10$.\vspace{.175cm} +\begin{flalign*} + && (6 + 5) - (&21 + -10) = 0&\\ + \intertext{\quad \quad \quad \quad \quad where} && 21G + -10G = 21G + (&l-10)G = (l + 11)G = 11G& +\end{flalign*} + +Since $-10 = l-10$, we have effectively created $l$ more Moneroj (over 7.2x10$^{74}$!) than we put in. + +%Bulletproofs start here +The solution addressing this issue in Monero is to prove each output amount is in a certain range (from 0 to $2^{64}-1$) using the Bulletproofs proving scheme first described by Benedikt B\"{u}nz {\em et al.} in \cite{Bulletproofs_paper} (and also explained in \cite{adam-zero-to-bulletproofs,dalek-bulletproofs-notes}).\footnote{It's conceivable that with several outputs in a legitimate range, the sum of their amounts could roll over and cause a similar problem. However, when the maximum output is much smaller than $l$ it takes a huge number of outputs for that to happen. For example, if the range is 0-5, and l = 99, then to counterfeit money using an input of 2, we would need $5 + 5 + …. + 5 + 1 = 101 \equiv 2 \pmod{99}$, for 21 total outputs. In Monero $l$ is about 2\^{}189 times bigger than the available range, which means a ridiculous 2\^{}189 outputs to counterfeit money.} Given the involved and intricate nature of Bulletproofs, it is not elucidated in this document. Moreover we feel the cited materials adequately present its concepts.\footnote{Prior to protocol v8 range proofs were accomplished with Borromean ring signatures, which were explained in the first edition of Zero to Monero \cite{ztm-1}.} + +The Bulletproof proving algorithm\marginnote{src/ringct/ rctSigs.cpp {\tt proveRange- Bullet- proof()}} takes as input output amounts $b_t$ and commitment masks $y_t$, and outputs all $C^b_t$ and an $n$-tuple aggregate proof $\Pi_{BP} = (A, S, T_1, T_2, \tau_x, \mu, \mathbb{L}, \mathbb{R}, a, b, t)$\footnote{Vectors $\mathbb{L}$ and $\mathbb{R}$ contain $\lceil \textrm{log}_2(64 \cdot p) \rceil$ elements each. $\lceil$ $\rceil$ means the log function is rounded up. Due to their construction, some Bulletproofs use `dummy outputs' as padding to ensure $p$ plus the number of dummy outputs is a power of 2. Those dummy outputs can be generated during verification, and are not stored with the proof data.}\footnote{The variables in a Bulletproof are unrelated to other variables in this document. Symbol overlap is merely coincidental. Note that group elements $A, S, T_1, T_2, \mathbb{L},$ and $\mathbb{R}$ are multiplied by 1/8 before being stored, then multiplied by 8 during verification. This ensures they are all members of the $l$ sub-group (recall Section \ref{elliptic_curves_section}).}. That single proof is used to prove all output amounts are in range at the same time, as aggregating them greatly reduces space requirements (although it does increase the time to verify).\footnote{It turns out multiple separate Bulletproofs can be `batched'\marginnote{rct/ringct/ bulletproofs.cc {\tt bulletproof\_ VERIFY()}} together, which means they are verified simultaneously. Doing so improves how long it takes to verify them, and currently in Monero Bulletproofs are batched on a per-block basis, although there is no theoretical limit to how many can be batched together. Each transaction is only allowed to have one Bulletproof.} The verification algorithm takes as input all $C^b_t$, and $\Pi_{BP}$, and outputs {\tt true} if all committed amounts are in the range 0 to $2^{64} - 1$. + +The $n$-tuple $\Pi_{BP}$ occupies $(2 \cdot \lceil \textrm{log}_2(64 \cdot p) \rceil + 9) \cdot 32$ bytes of storage. \ No newline at end of file diff --git a/translations/es/content/escrowedMarket.tex b/translations/es/content/escrowedMarket.tex new file mode 100755 index 0000000..c7252d0 --- /dev/null +++ b/translations/es/content/escrowedMarket.tex @@ -0,0 +1,205 @@ +\chapter{Monero in an Escrowed Marketplace} +\label{chapter:escrowed-market} + +Most of the time purchasing from an online retailer goes smoothly. A buyer sends money to a vendor, and the expected product arrives at their doorstep. If the product has a defect, or in some cases if the buyer changes their mind, they can return it and get a refund. + +It's difficult to trust a person or organization you have never met, and many shoppers can feel safe in their purchases knowing their credit card company will reverse a payment on request \cite{credit-card-reversals}. + +Cryptocurrency transactions are not reversible, and there is limited legal recourse a buyer or seller can take when something goes wrong, especially for Monero which is not open to easy chain analysis \cite{chainalysis-2020-report}. The cornerstone of robust online shopping with cryptocurrencies is 2-of-3 multisignature-based escrowed exchanges, which enable third parties to mediate disputes. By trusting those third parties, even completely anonymous vendors and shoppers can interact without formality. + +Since Monero multisig interactions can be rather complex (recall Section \ref{sec:simplified-communication}), we dedicate this chapter to describing a maximally efficient escrowed shopping environment.\footnote{Ren\'e ``rbrunner7" Brunner, a Monero contributor who created the MMS \cite{mms-project-proposal, mms-manual}, investigated integrating Monero multisig into the decentralized cryptocurrency-based digital marketplace OpenBazaar \url{https://openbazaar.org/}. The concepts laid out here are inspired by the hurdles Ren\'e encountered \cite{openbazaar-rbrunner-investigation} (his `earlier analysis').}\footnote{Our initial impression is Monero's current implementation of multisig already has a similar transaction creation flow to what we need for an escrowed shopping environment, which is good news for potential implementation efforts. Readers should note that Monero multisig requires some security updates before it can see heavy use \cite{multisig-research-issue-67}.} + + + +\section{Essential features} +\label{sec:escrowed-marketplace-essential-features} + +There are several basic requirements and features for streamlined interactions between buyers and sellers online. We take these points from Ren\'e's OpenBazaar investigation \cite{openbazaar-rbrunner-investigation}, as they are quite sensible and extensible. +\begin{itemize} + \item {\em Offline selling}: A buyer should be able to access a vendor's online shop and place an order while the vendor is offline. Obviously, the vendor must actually go online to receive the order and fulfill it.\footnote{Fulfilling a purchase order means sending the product out to be delivered to the purchaser.} + \item {\em Purchase order-based payments}: Vendor addresses for receipt of funds are unique for each purchase order, in order to match orders and payments. + \item {\em High-trust purchasing}: A buyer may, if they trust a vendor, pay for a product even before it has been fulfilled or delivered. + \begin{itemize} + \item {\em Online direct payment}: After confirming the vendor is online, and that their product listing is available, the purchaser sends money in a single transaction to the vendor via a vendor-provided address, who then signals the order is being fulfilled. + \item {\em Offline payment}: If a vendor is offline, the buyer creates and funds a 1-of-2 multisig address with enough money to cover their intended purchase. When the vendor comes online, they may take money out of the multisig address (sending change back to the buyer), and fulfill the order. If the vendor never comes back online (or e.g. after some reasonable waiting period), or if the buyer changes their mind before he comes back, the buyer may empty the 1-of-2 address back into her personal wallet. + \end{itemize}{} + \item {\em Moderated purchasing}: A 2-of-3 multisig address is constructed between the buyer, vendor, and a moderator agreed on by both buyer and vendor. The buyer funds this address before vendor fulfillment, and then once the product is delivered two of the parties cooperate to release the funds. If the vendor and buyer can't reach an agreement, they may enlist the moderator's judgement. +\end{itemize} + +We will not cover high-trust purchasing, as, without any complex communication required, the features are fairly trivial.\footnote{1-of-2 multisig can take advantage of some concepts useful for 2-of-3 multisig, in particular constructing the address in the first place.} + + +\subsection{Purchasing workflow} +\label{subsec:escrowed-marketplace-purchasing-workflow} + +All purchases should fit within the same set of steps, assuming all parties do their due diligence. A number of steps are related to what a moderator should expect when stepping in, e.g. ``did you request a refund, before getting me involved?". +\begin{enumerate} + \item A buyer accesses the vendor's online shop, identifies a purchase to make, selects `I want to purchase it', makes funding available for that purchase, then submits the purchase order to the vendor. + \item The vendor receives the purchase order, verifies the product is in stock and the available funding is enough, and either returns money to the buyer or fulfills the order by shipping out the product and notifying the buyer with a receipt. + \begin{itemize} + \item For a 2-of-3 multisig, the buyer can optionally authorize payment when receiving notification of fulfillment. + \end{itemize}{} + \item The buyer either receives the product as expected, or doesn't receive the product on time or receives a defective product. + \begin{itemize} + \item {\em Good product}: The buyer either gives feedback to the vendor, or does nothing. + \begin{itemize} + \item {\em Buyer sends feedback}: The buyer can leave either positive, or negative feedback. + \begin{itemize} + \item {\em Positive feedback}: If this is a 2-of-3 multisig that hasn't been paid yet, then this is the step where the buyer confirms payment to the vendor. Otherwise it's just a positive review. [END OF WORKFLOW] + \item {\em Negative feedback}: If this is a 2-of-3 multisig, then this step leads into the `bad product' workflow. Otherwise it's just a negative review. + \end{itemize}{} + \item {\em Buyer does nothing}: Either the vendor has already been paid, or it's a 2-of-3 multisig and he needs to cooperate with someone to receive funds. + \begin{itemize} + \item {\em Vendor has been paid}: [END OF WORKFLOW] + \item {\em Vendor has not been paid}: The vendor pursues payment. + \begin{enumerate} + \item The vendor contacts the buyer requesting payment (or sends out a reminder). + \item The buyer either responds, or does not respond. + \begin{itemize} + \item {\em Buyer responds}: The buyer's response can be to make a payment, or pursue a refund.\\ + $>$ {\em Buyer makes payment}: [END OF WORKFLOW]\\ + $>$ {\em Buyer pursues refund}: Go to the `bad product' workflow. + \item {\em Buyer does not respond}: The vendor enlists the moderator's help to release funds. [END OF WORKFLOW] + \end{itemize}{} + \end{enumerate}{} + \end{itemize} + \end{itemize}{} + \item {\em No product or bad product}: The buyer pursues a refund. + \begin{enumerate} + \item The buyer contacts the vendor requesting a refund, perhaps with an explanation. + \item The vendor complies with the refund request, or contests it (or ignores it). + \begin{itemize} + \item {\em Vendor complies}: Money is refunded to the buyer. [END OF WORKFLOW] + \item {\em Vendor contests}: Either it's not a 2-of-3 multisig, or it is. + \begin{itemize} + \item {\em It's not a 2-of-3}: [END OF WORKFLOW] + \item {\em It's a 2-of-3}: Either the buyer gives up on the refund request (literally, or by failing to respond in a timely manner), or the buyer is adamant. + \begin{itemize} + \item {\em Buyer gives up}: Either the buyer authorized the vendor's payment, or not.\\ + $>$ {\em Buyer authorized payment}: [END OF WORKFLOW]\\ + $>$ {\em Buyer didn't authorize}: The vendor contacts the moderator, who authorizes the payment. [END OF WORKFLOW] + \item {\em Buyer is adamant}: The vendor or buyer contacts the moderator, who cooperates with the participants to pass judgement. [END OF WORKFLOW] + \end{itemize}{} + \end{itemize} + \end{itemize}{} + \end{enumerate}{} + \end{itemize}{} +\end{enumerate}{} + + + +\section{Seamless Monero multisig} +\label{sec:escrowed-marketplace-seamless-multisig} + +We can take advantage of the natural purchase order workflow to squeeze in nearly all parts of a Monero 2-of-3 multisignature interaction without the participants even noticing. There is an extra small step for the vendor at the end, where he must sign and submit the final transaction to receive payment, analogous to `emptying the cash register'.\footnote{Extending this beyond (N-1)-of-N is likely infeasible without more steps, due to the additional rounds necessary for setting up a lower threshold multisig address.} + + +\subsection{Basics of a multisig interaction} +\label{subsec:escrowed-marketplace-multisig-interaction-basics} + +All 2-of-3 multisig interactions contain the same set of communication rounds, involving address setup and transaction building. In order to comply with the normal workflow we use a reorganized transaction construction process compared to our multisig chapter (recall Sections \ref{sec:simplified-communication} and \ref{sec:n-1-of-n}).\footnote{This procedure is actually quite similar to how Monero currently organizes multisig transactions.} +\begin{enumerate} + \item {\em Address setup} + \begin{enumerate} + \item All users must first learn the other participants' base keys, which they will use to construct shared secrets. They transmit the public keys of those shared secrets (e.g. $K^{sh} = \mathcal{H}_n(k^{base}_A*k^{base}_B G) G$) to the other users. + \item After learning all shared secret public keys, each user may {\tt premerge} and then {\tt merge} them into the address's public spend key. The aggregation private spend keys will be used for signing transactions. A hash of the primary signers' (the buyer and vendor) shared secret private key (e.g. $k^{sh} = \mathcal{H}_n(k^{base}_A*k^{base}_B G)$) will be used as the view key (e.g. $k^v = \mathcal{H}_n(k^{sh})$). We go into more detail on these keys later (Section \ref{subsec:escrowed-marketplace-escrow-user-experience}). + \end{enumerate}{} + \item {\em Transaction building}: Assume the address owns at least one output already, and the key images are unknown. There are two signers, the initiator and the cosigner. + \begin{enumerate} + \item {\em Initiate a transaction}: The initiator decides to start a transaction. She generates opening values (e.g. $\alpha G$) for all owned outputs (she isn't sure which ones will get used yet), and commits to them. She also creates partial key images for those owned outputs, and signs them with a proof of legitimacy (recall Section \ref{sec:recalculating-key-images-multisig}). She sends that information, along with her own personal address for receipt of funds (e.g. for change if appropriate, etc.), to the cosigner. + \item {\em Make a partial transaction}: The cosigner verifies that all information in the initiated transaction is valid. He decides the output recipients and amounts (they could be partially based on the initiator's recommendation), inputs to be used along with their respective ring member decoys, and the transaction fee. He generates a transaction private key (or keys if there are subaddresses involved), creates one-time addresses, output commitments, encoded amounts, pseudo output commitment masks, and opening values for the commitments to zero. To prove amounts are in range, he builds the Bulletproof range proof for all outputs. He also generates opening values for his signature (but does not commit to them), random scalars for the MLSAG signatures, partial key images for owned outputs, and proofs of legitimacy for those partial images. All of this is sent to the initiator. + \item {\em Initiator's partial signature}: The initiator verifies the partial transaction's information is valid, and conforms with her expectations (e.g. amounts and recipients are as they should be). She completes the MLSAG signatures and signs them with her private keys, then sends the partially signed transaction to the cosigner along with her revealed opening values. + \item {\em Finish the transaction}: The cosigner finishes signing the transaction, and submits it to the network. + \end{enumerate}{} +\end{enumerate}{} + +\subsubsection*{Single-commitment signing} + +Unlike what is recommended in our multisig chapter, only one commitment is provided per partial transaction (by the transaction initiator), and it is revealed after the cosigner sends out their opening value explicitly. The purpose of committing to opening values (e.g. $\alpha G$) is to prevent a malicious cosigner from using their own opening value to affect the challenge that gets produced, which could allow him to discover other cosigners' aggregation keys (recall Section \ref{sec:threshold-schnorr}). If even one partial opening value is unavailable when the malicious actor generates his own, then it is impossible (or at least negligibly probable) for him to control the challenge.\footnote{This is also why the initiator only reveals her opening values after all transaction information has been determined, so neither signer can alter the MLSAG message and influence the challenge.}\footnote{Single-commitment signing could be generalized as (M-1)-commitment signing, where only the partial transaction author does not commit-and-reveal and other co-signers only reveal after a transaction is fully determined. For example, suppose there is a 3-of-3 address with cosigners (A,B,C), who will attempt single-commitment signing. Signers B and C are in a malicious coalition against A, while C is the initiator and B is the partial transaction author. C initiates with a commitment, then A provides his opening value (without commitment). When B constructs the partial transaction, he can conspire with C to control the signature challenge in order to expose A's private key. Please also note that (M-1)-commitment signing is an original concept first presented here, and is not backed by any advanced research material or code implementation. It may end up being completely erroneous.}\footnote{One way of thinking about this is to consider the meaning and purpose of a `commitment' (recall Section \ref{sec:commitments}). Once Alice commits to value A she is stuck with it, and can't take advantage of new information from event B (caused by Bob) that happens later. Moreover, if A hasn't been revealed then B can't be influenced by it. Alice and Bob can be sure that A and B are independent. It is our contention that single-commitment signing as described meets that standard, and is equivalent to full-commitment signing. If the commitment $c$ is a one-way function of opening values $\alpha_A G$ and $\alpha_B G$ (e.g. $c = \mathcal{H}_n(\alpha_A G,\alpha_B G)$), then if $\alpha_A G$ is committed to initially, $\alpha_B G$ is revealed after $C(\alpha_A G)$ appears, and $\alpha_A G$ is revealed after $\alpha_B G$ appears, then $\alpha_B G$ and $\alpha_A G$ are independent, and $c$ will be random from both Alice's and Bob's perspectives (unless they collaborate, and except with negligible probability).} + +Simplifying in this way removes one communication round, which has important consequences for the buyer-vendor interaction experience. + + +\subsection{Escrowed user experience} +\label{subsec:escrowed-marketplace-escrow-user-experience} + +Here is our detailed walk-through of buyer-vendor-moderator interactions involving a 2-of-3 multisig-based online purchase using Monero. +\begin{enumerate} + \item {\em Buyer makes a purchase} + \begin{enumerate} + \item {\em Buyer's new shopping session}: A shopper enters an online marketplace, and her client generates a new subaddress to be used if she starts a new purchase order.\footnote{Using a new subaddress for each purchase order, or even a new subaddress for each separate vendor or vendor's product, makes it more difficult for vendors to track the behavior of their customers. It also helps make sure each purchase order is unique, in the case of someone buying the same thing twice.} In that marketplace she finds vendors, and each vendor is offering a selection of products and prices. Invisible to the shopper herself, but visible to her client (i.e. the software she is using to buy things), each product has a base key for use in multisig-based purchases. Alongside that base key is a list of preselected moderators, and each such moderator has a base key and precomputed vendor-moderator shared secret public key.\footnote{It would be straightforward for vendors to also include, invisible to shoppers, commitments to opening values for transactions. However, to handle multiple purchase orders for the same product, he would have to provide many commitments up front for each potential buyer. We can only imagine how messy that could become. This is part of the utility brought by our single-commitment signing simplification.} + \item {\em Buyer adds a product to cart}: Our shopper decides she wants something, selects the payment option (i.e. direct payment, 1-of-2 multisig, or 2-of-3 multisig), and if she selects 2-of-3 multisig she is presented with a list of available moderators that she can choose from. When she adds the product to her cart, her client, invisible to her (and assuming she selected 2-of-3 multisig), uses the product's base key, the moderator's base key, and the vendor-moderator shared secret public key, to, in combination with her own shopping-session subaddress's spend key (as her base key), construct a 2-of-3 buyer-vendor-moderator multisig address.\footnote{Exactly how a marketplace should be implemented is open to interpretation, since for example selecting the payment type for a product could be presented to the user at checkout instead of in the `add to cart' interface.}\\ + + The view key is a hash of the buyer-vendor shared secret private key (not the aggregation private key, i.e. before {\tt premerge}), and the encryption key for communications between the buyer and vendor is a hash of the view key.\footnote{This same process would take place for 1-of-2 multisig, leaving out the moderator.} + \item {\em Buyer moves to checkout}: The shopper views her cart with all its products, and decides to proceed to checkout. This is where she makes funding available before finalizing the purchase order. Her client constructs a transaction (but does not sign it yet) that will either pay directly to the vendor, or fund a multisig address (with a little extra for future fees). If funding a 2-of-3 multisig address, the client also initiates two transactions sending money out of that address. One can be used to pay the vendor, and the other to refund the buyer. Their inputs' partial key images are based on the funding transaction that has not been signed yet.\\ + + In reality, she only needs committed opening values for the two transactions, and then separately one copy of the partial key images (with proof of legitimacy) and one copy of her shopping-session subaddress. That subaddress has a dual purpose; it is the buyer's address for refunds or change outputs, and its spend key is the buyer's multisig base key.\footnote{It is important to initiate separate transactions, since committed opening values can only be used once.} + \item {\em Buyer authorizes payment}: After looking over all the purchase order details, the shopper authorizes it.\footnote{If the buyer cancels the purchase order, her funding transaction and partial multisig transactions get deleted.} Her client finishes signing the funding transaction, and submits it to the network.\footnote{If her cart contained multiple vendors' products, then her client can create multiple purchase orders and handle them separately. The vendors can all be paid by the same funding transaction.} It sends the purchase order, along with the funding transaction's hash and initiated multisig transactions, and the buyer-moderator shared secret public key, to the vendor.\footnote{The buyer's client should keep track of payment order details like total price, to later verify the content of multisig transactions before signing them.} + \end{enumerate}{} + \item {\em Vendor fulfills a purchase order} + \begin{enumerate} + \item {\em Vendor appraises purchase order}: The vendor examines our shopper's purchase order, then approves it for shipping. If he was paid directly then there is nothing else to consider, and if he was paid via 1-of-2 multisig then he can make a transaction paying himself out of that address. For 2-of-3 multisig his client generates a subaddress for receipt of money in the purchase order, and makes two partial transactions out of the buyer's initialized transactions. The payment transaction sends the product price to the vendor, and the rest to the buyer as change, while the refund transaction just empties the multisig address back to the buyer.\footnote{The partial transactions could plausibly share a lot of values since they involve the same inputs, and only one of them should ultimately get signed. For the sake of modularity and robust design we think it's best to handle them separately.} Note that he reconstructs the multisig address out of the buyer-vendor-moderator base keys in combination with the buyer-moderator shared secret public key. + \item {\em Vendor ships the product}: The vendor ships the product, and sends a fulfillment notification to the buyer. That notification includes a receipt for the purchase, as well as a request for the user to complete payment (everything from here on out refers to 2-of-3 multisig). Hidden to the user is the vendor's purchase order subaddress, which can be used in case of dispute resolution, and both partial transactions. + \end{enumerate}{} + \item {\em Buyer completes payment or requests a refund}: A buyer can do this as soon as they receive fulfillment notification, or wait until the product has been delivered. + \begin{enumerate} + \item {\em Buyer submits partially signed transaction}: The buyer decides whether to pay for her purchase, or request a refund. Her client creates a partial signature on the appropriate partial transaction, and sends it to the vendor. Any refund would presumably include an explanation justifying it. + \item {\em Vendor completes transaction}: The vendor receives a partially signed transaction, finishes signing it, and submits it to the network. If necessary he sends a refund notification, with proof, to the buyer. + \end{enumerate}{} + \item {\em Moderated dispute}: At any point after the buyer submits a purchase order and before the multisig address is emptied of funds, either the vendor or buyer can decide to get the moderator involved. Party\_A is whoever raised the dispute, while Party\_B is the defendant.\footnote{Our dispute resolution design assumes actors are in good faith. People who are uncooperative, and for example don't initiate or sign transactions that don't favor themselves, will no doubt make the process much more tedious for everyone.} + \begin{enumerate} + \item {\em Party\_A contacts moderator}: Party\_A initiates two transactions, for payment or refund, this time geared toward Party\_A-moderator signing, and send them to the moderator along with necessary information for building the multisig address (the base keys, the Party\_A-Party\_B shared secret public key, and the private view key) and reading the multisig wallet's balance (the partial key images and their proofs). + \item {\em Moderator processes dispute} + \begin{enumerate} + \item {\em Moderator acknowledges dispute}: The moderator acknowledges they are looking into the dispute, at the same time creating partial transactions out of the initiated transactions and sending them to Party\_A. They make sure to notify Party\_B about the dispute, and also initiate two more transactions with Party\_B to expedite failure of Party\_A to comply with the final verdict. + \item {\em Moderator pursues a verdict}: The moderator looks at the available evidence, and can interact with the parties to gather more information. They may try to mediate the argument, in hopes of both parties resolving it without the need to pass a verdict. + \item {\em Dispute reaches an end}: Either the buyer and vendor resolve it on their own in the end, or the moderator passes a verdict which they communicate to both parties. + \end{enumerate}{} + \begin{itemize} + \item Note: If the defendant party should receive funds per the verdict, but hasn't provided an address for whatever reason, the moderator can try to contact them and cooperate with them to receive those funds. Since it doesn't involve the disputer, that contact can be made (or pursued further) after the dispute has been resolved. + \end{itemize}{} + \item {\em Party\_A or B accepts the verdict}: If no Party\_A-Party\_B transactions were finalized, it implies the dispute was resolved by moderator's decision. + \begin{enumerate} + \item {\em Party\_A accepts} + \begin{enumerate} + \item Party\_A completes their partial signature on the verdict transaction, and sends it to the moderator. + \item The moderator completes the signature, and submits the transaction. + \end{enumerate}{} + \item {\em Party\_B accepts} + \begin{enumerate} + \item Party\_B creates a partial transaction for the moderator's initialized verdict transaction, and sends it to the moderator. This step can be performed before the verdict is finalized, in which case Party\_B would make partial transactions for both potential verdicts. + \item The moderator partially signs that partial transaction, and sends it to Party\_B. + \item Party\_B finishes signing the transaction, and submits it to the network. He sends the transaction hash to the moderator. + \end{enumerate}{} + \end{enumerate}{} + \item {\em Moderator closes out the dispute}: The moderator summarizes the dispute and its resolution, and sends their report to the buyer and vendor. + \end{enumerate}{} +\end{enumerate}{} + +There are four key design optimizations installed. + +\subsubsection*{Preselected moderators} + +By choosing the moderators ahead of time, vendors can create a shared secret with each of them for each of their products and publish its public key with the product information.\footnote{Importantly, these multisig addresses are still resistant to key aggregation tests since the buyer's shared secrets are unknown to observers.} This way buyers can construct the complete merged multisig address in one step, as soon as they decide to purchase something, harmonizing with the requirement for `offline selling'. Preselecting multiple moderators allows buyers to choose the one they trust more. + +Buyers may also, if they don't trust a vendor's accepted moderators, cooperate with an online moderator of their choosing to make a multisig address with the vendor's product base key. After receiving a purchase order, the vendor may accept that new moderator or decline the sale.\footnote{For expediency, an escrow service could be `always online', and instead of using preselected moderators all 2-of-3 multisig addresses are actively constructed with that service when a purchase order is made. Another possibility is using nested multisig (Section \ref{sec:general-key-families}), where the preselected moderator is actually a 1-of-N multisig group. That way whenever a dispute arises any moderator from that group who happens to be available can step in. It would likely require substantial development effort to implement.} + +We expect the mutual desire of buyers and vendors for good moderators to, over time, create a hierarchy of moderators organized by the quality and fairness of the service they provide. Lower quality moderators or those with less of a reputation would likely earn less money or service fewer or less significant transactions.\footnote{It is not clear to us the best, or most likely, funding method for moderators. Perhaps they would get paid a flat or percentage fee of each moderated transaction or transaction where they are added as a moderator (and then if the fee wasn't provided in the original partial transactions, refuse to cooperate in a dispute), or users and/or vendors and/or marketplace platforms would contract with them.} + +\subsubsection*{Subaddresses and product IDs} + +Vendors create a new base key for each product line/ID, and those keys are used to construct 2-of-3 multisig addresses.\footnote{This base key is also used for 1-of-2 multisig purchasing. We feel it is important not to expose the private spend key in the communication channel, so using a buyer-vendor shared secret makes a lot of sense.} When vendors fulfill a purchase order they create a unique subaddress for receipt of funds, which can be used to match purchase orders with payments received. + +The requirement for `purchase order-based payments' is met efficiently here, especially since funds directed to different subaddresses are trivially accessible from the same wallet (recall Section \ref{sec:subaddresses}). + +\subsubsection*{Anticipatory partial transactions} + +Multisig transactions take multiple rounds, so we begin making them as soon as possible. For user convenience, partial transactions that are only rarely used (e.g. refund transactions) get made early, so they are immediately available for signing if the need arises. + +\subsubsection*{Conditional moderator access} + +For the sake of both efficiency and privacy, moderators only need access to the details of a trade when settling disputes. To accomplish this, we make the multisig private view key a hash of the buyer-vendor shared secret private key $k^{v,grp}_{purchase-order} = \mathcal{H}_n(T_{mv},k^{sh,\textrm{2x3}}_{AB})$ where $T_{mv}$ is the marketplace view key domain separator and A and B correspond with vendor and buyer, and $k^{sh,\textrm{2x3}}_{AB} = \mathcal{H}_n(k^{base}_{A}*k^{base}_{B} G)$. We extend what it can `view' to the buyer-vendor communication transcript. In other words, the communication encryption key is $k^{ce}_{purchase-order} = \mathcal{H}_n(T_{me},k^{v,grp}_{purchase-order})$ ($T_{me}$ is the marketplace encryption key domain separator).\footnote{Separating the view key and encryption key allows handing out just view rights to the communication log without view rights to the multisig address's transaction history.}\footnote{This method is also used for 1-of-2 multisig addresses.} + +Moderators gain access to the buyer-vendor communications, and the ability to authorize payments, only when one of the original parties releases the view key to them.\footnote{It is important for moderators to verify the communication log they receive hasn't been tampered with. One way might be for each cosigner to include a signed hash of the current message log whenever they send out a new message. Moderators can look at the back-and-forth, and series of hashed logs, to identify discrepancies. It would also help cosigners identify messages that failed to transmit, and alternatively create evidence that particular signers did in fact receive certain messages.} + +Moreover, vendors can verify the marketplace host (who may also be the only moderator available, depending on how this concept is implemented) is not MITM (`man in the middle') of their conversations with customers (i.e. pretending to be the buyer or vendor) by checking that the base keys they publish for each product match what gets displayed. Since the buyer's base key, which gets used to create the multisig address, is also part of the encryption key, a malicious host would have a hard time orchestrating a MITM attack. \ No newline at end of file diff --git a/translations/es/content/introduction.tex b/translations/es/content/introduction.tex new file mode 100755 index 0000000..0e3fe28 --- /dev/null +++ b/translations/es/content/introduction.tex @@ -0,0 +1,115 @@ +\chapter{Introduction} +\label{chapter:introduction} + +In the digital realm it is often trivial to make endless copies of information, with equally endless alterations. For a currency to exist digitally and be widely adopted, its users must believe its supply is strictly limited. A money recipient must trust they are not receiving counterfeit coins, or coins that have already been sent to someone else. To accomplish that without requiring the collaboration of any third party like a central authority, its supply and complete transaction history must be publicly verifiable. + +We can use cryptographic tools to allow data registered in an easily accessible database - the blockchain - to be virtually immutable and unforgeable, with legitimacy that cannot be disputed by any party. +\\ \newline +Cryptocurrencies store transactions in the blockchain, which acts as a public ledger\footnote{In this context ledger just means a record of all currency creation and exchange events. Specifically, how much money was transferred in each event and to whom.} of all the currency operations. Most cryptocurrencies store transactions in clear text, to facilitate verification of transactions by the community of users. +\\ \newline +Clearly, an open blockchain defies any basic understanding of privacy or fungibility\footnote{``\textbf{Fungible} means capable of mutual substitution in use or satisfaction of a contract. ... Examples: ... money, etc."\cite{mises-org-fungible} In an open blockchain such as Bitcoin, the coins owned by Alice can be differentiated from those owned by Bob based on the `transaction history' of those coins. If Alice's transaction history includes transactions related to supposedly nefarious actors, then her coins might be `tainted' \cite{bitcoin-big-bang-taint}, and hence less valuable than Bob's (even if they own the same amount of coins). Reputable figures claim that newly minted Bitcoins trade at a premium over used coins, since they don't have a history \cite{new-bitcoin-premium}.}, since it literally {\em publicizes} the complete transaction histories of its users. +\\ \newline +To address the lack of privacy, users of cryptocurrencies such as Bitcoin can obfuscate transactions by using temporary intermediate addresses \cite{DBLP:journals/corr/NarayananM17}. However, with appropriate tools it is possible to analyze flows and to a large extent link true senders with receivers \cite{DBLP:journals/corr/ShenTuY15b, DK-police-tracing-btc, Andrew-Cox-Sandia, chainalysis-2020-report}. + +In contrast, the cryptocurrency Monero (Moe-neh-row) attempts to tackle the issue of privacy by storing only single-use addresses for receipt of funds in the blockchain, and by authenticating the dispersal of funds in each transaction with ring signatures. With these methods there are no known generally effective ways to link receivers or trace the origin of funds.\footnote{Depending on the behavior of users, there may be cases where transactions can be analyzed to some extent. For an example see this article: \cite{monero-ring-heuristics-ryo}.} + +Additionally, transaction amounts in the Monero blockchain are concealed behind cryptographic constructions, rendering currency flows opaque. + +The result is a cryptocurrency with a high level of privacy and fungibility. + + + +\section{Objectives} +\label{sec:goals} + +Monero is an established cryptocurrency with over five years of development \cite{bitmonero-launched, monero-history}, and maintains a steadily increasing level of adoption \cite{justin-defcon-2019-community-growth}.\footnote{\label{marketcap_note}In terms of market capitalization, Monero has been steady relative to other cryptocurrencies. It was 14\nth as of June 14\nth, 2018, and 12\nth on January 5\nth, 2020; see \url{https://coinmarketcap.com/}.} Unfortunately, there is little comprehensive documentation describing the mechanisms it uses.\footnote{One documentation effort, at \url{https://monerodocs.org/}, has some helpful entries, especially related to the Command Line Interface. The CLI is a Monero wallet accessible through a console/terminal. It has the most functionality out of all Monero wallets, at the expense of no user-friendly graphical interface.}\footnote{Another, more general, documentation effort called Mastering Monero can be found here: \cite{mastering-monero}.} Even worse, essential parts of its theoretical framework have been published in non-peer-reviewed papers that are incomplete or contain errors. For significant parts of the theoretical framework of Monero, only the source code is reliable as a source of information.\footnote{Mr. Seguias has created the excellent Monero Building Blocks series \cite{monero-building-blocks}, which contains a thorough treatment of the cryptographic security proofs used to justify Monero's signature schemes. As with Zero to Monero: First Edition \cite{ztm-1}, Seguias's series is focused on v7 of the protocol.} + +Moreover, for those without a background in mathematics, learning the basics of elliptic curve cryptography, which Monero uses extensively, can be a haphazard and frustrating endeavor.\footnote{A previous attempt to explain how Monero works \cite{MRL-0003-about-monero} did not elucidate elliptic curve cryptography, was incomplete, and is now over five years outdated.} + +We intend to palliate this situation by introducing the fundamental concepts necessary to understand elliptic curve cryptography, reviewing algorithms and cryptographic schemes, and collecting in-depth information about Monero’s inner workings. + +To provide the best experience for our readers, we have taken care to build a constructive, step-by-step description of the Monero cryptocurrency. + +In the second edition of this report we have centered our attention on version 12 of the Monero protocol\footnote{The `protocol' is the set of rules that each new block is tested against before it can be added to the blockchain. This set of rules includes the `transaction protocol' (currently version 2, RingCT), which are general rules pertaining to how a transaction is constructed. Specific transaction rules can, and do, change, without the transaction protocol's version changing. Only large-scale changes to the transaction structure warrant moving its version number.}, corresponding to version 0.15.x.x of the Monero software suite. All transaction and blockchain-related mechanisms described here belong to those versions.\footnote{The Monero codebase's integrity and reliability is predicated on assuming enough people have reviewed it to catch most or all significant errors. We hope that readers will not take our explanations for granted, and verify for themselves the code does what it's supposed to. If it doesn't, we hope you will make a responsible disclosure (\url{https://hackerone.com/monero}) for major problems, or Github pull request (\url{https://github.com/monero-project/monero}) for minor issues.}\footnote{Several protocols worth considering for the next generation of Monero transactions are undergoing research and investigation, including Triptych \cite{triptych-preprint}, RingCT3.0 \cite{ringct3-preprint}, Omniring \cite{omniring-paper}, and Lelantus \cite{lelantus-preprint}.} Deprecated transaction schemes have not been explored to any extent, even if they may be partially supported for backward compatibility. Likewise with deprecated blockchain features. The first edition \cite{ztm-1} corresponded to version 7 of the protocol, and version 0.12.x.x of the software suite. + + + +\section{Readership} + +We anticipate many readers will encounter this report with little to no understanding of discrete mathematics, algebraic structures, cryptography\footnote{An extensive textbook on applied cryptography can be found here: \cite{applied-cryptography-textbook}.}, and blockchains. We have tried to be thorough enough that laypeople from all perspectives may learn Monero without needing external research. + +We have purposefully omitted, or delegated to footnotes, some mathematical technicalities, when they would be in the way of clarity. We have also omitted concrete implementation details where we thought they were not essential. Our objective has been to present the subject half-way between mathematical cryptography and computer programming, aiming at completeness and conceptual clarity.\footnote{Some footnotes, especially in chapters related to the protocol, spoil future chapters or sections. These are intended to make more sense on a second read-through, since they usually involve specific implementation details that are only useful to those who have a grasp of how Monero works.} + + + +\section{Origins of the Monero cryptocurrency} + +The cryptocurrency Monero, initially known as BitMonero, was created in April 2014 as a derivative of the proof-of-concept currency CryptoNote \cite{bitmonero-launched}. Monero means `money' in the language Esperanto, and its plural form is Moneroj (Moe-neh-rowje, similar to Moneros but using the -ge from orange). + +CryptoNote is a cryptocurrency devised by various individuals. A landmark whitepaper describing it was published under the pseudonym of Nicolas van Saberhagen in October 2013 \cite{cryptoNoteWhitePaper}. It offered receiver anonymity through the use of one-time addresses, and sender ambiguity by means of ring signatures. + +Since its inception, Monero has further strengthened its privacy aspects by implementing amount hiding, as described by Greg Maxwell (among others) in \cite{Signatures2015BorromeanRS} and integrated into ring signatures based on Shen Noether's recommendations in \cite{MRL-0005-ringct}, then made more efficient with Bulletproofs \cite{Bulletproofs_paper}. + + + +\section{Outline} + +As mentioned, our aim is to deliver a self-contained and step-by-step description of the Monero cryptocurrency. Zero to Monero has been structured to fulfill this objective, leading the reader through all parts of the currency’s inner workings. + + +\subsection{Part 1: `Essentials'} + +In our quest for comprehensiveness, we have chosen to present all the basic elements of cryptography needed to understand the complexities of Monero, and their mathematical antecedents. In Chapter \ref{chapter:basicConcepts} we develop essential aspects of elliptic curve cryptography. + +Chapter \ref{chapter:advanced-schnorr} expands on the Schnorr signature scheme from the prior chapter, and outlines the ring signature algorithms that will be applied to achieve confidential transactions. + +Chapter \ref{chapter:addresses} explores how Monero uses addresses to control ownership of funds, and the different kinds of addresses. + +In Chapter \ref{chapter:pedersen-commitments} we introduce the cryptographic mechanisms used to conceal amounts. + +With all the components in place, we explain the transaction scheme used in Monero in Chapter \ref{chapter:transactions}. + +The Monero blockchain is unfolded in Chapter \ref{chapter:blockchain}. + + +\subsection{Part 2: `Extensions'} + +A cryptocurrency is more than just its protocol, and in `Extensions' we talk about a number of different ideas, many of which have not been implemented.\footnote{Please note that future protocol versions of Monero, especially those implementing new transaction protocols, may make any or all of these ideas impossible or impractical.} + +Various information about a transaction can be proven to observers, and those methods are the content of Chapter \ref{chapter:tx-knowledge-proofs}. + +While not essential to the operation of Monero, there is a lot of utility in multisignatures that allow multiple people to send and receive money collaboratively. Chapter \ref{chapter:multisignatures} describes Monero's current multisignature approach and outlines possible future developments in that area.%This is formally called (N-1)-of-N and N-of-N threshold authentication. + +Of extreme importance is applying multisig to the interactions of vendors and shoppers in online marketplaces. Chapter \ref{chapter:escrowed-market} constitutes our original design of an escrowed marketplace using Monero multisig. + +First presented here, TxTangle, outlined in Chapter \ref{chapter:txtangle}, is a decentralized protocol for joining the transactions of multiple individuals into one. + + +\subsection{Additional content} + +Appendix \ref{appendix:RCTTypeBulletproof2} explains the structure of a sample transaction from the blockchain. Appendix \ref{appendix:block-content} explains the structure of blocks (including block headers and miner transactions) in Monero's blockchain. Finally, Appendix \ref{appendix:genesis-block} brings our report to a close by explaining the structure of Monero's genesis block. These provide a connection between the theoretical elements described in earlier sections with their real-life implementation. + +We\marginnote{Isn't this useful?} use margin notes to indicate where Monero implementation details can be found in the source code.\footnote{Our margin notes are accurate for version 0.15.x.x of the Monero software suite, but may gradually become inaccurate as the codebase is constantly changing. However, the code is stored in a git repository (\url{https://github.com/monero-project/monero}), so a complete history of changes is available.} There is usually a file path, such as src/ringct/rctOps.cpp, and a function, such as \(\textrm{{\tt ecdhEncode()}}\). Note: `-' indicates split text, such as crypto- note $\rightarrow$ cryptonote, and we neglect namespace qualifiers (e.g. {\tt Blockchain::}) in most cases. + + + +\section{Disclaimer} + +All signature schemes, applications of elliptic curves, and Monero implementation details should be considered descriptive only. Readers considering serious practical applications (as opposed to a hobbyist's explorations) should consult primary sources and technical specifications (which we have cited where possible). Signature schemes need well-vetted security proofs, and Monero implementation details can be found in Monero's source code. In particular, as a common saying goes, `don't roll your own crypto'. Code implementing cryptographic primitives should be well-reviewed by experts and have a long history of dependable performance. Moreover, original contributions in this document may not be well-reviewed and are likely untested, so readers should exercise their judgement when reading them. + + + +\section{History of Zero to Monero} + +Zero to Monero is an expansion of Kurt Alonso's master's thesis, `Monero - Privacy in the Blockchain' \cite{kurt-original}, published in May 2018. The first edition was published in June 2018 \cite{ztm-1}. + +For the second edition we have improved how ring signatures are introduced (Chapter \ref{chapter:advanced-schnorr}), reorganized how transactions are explained (added Chapter \ref{chapter:addresses} on Monero Addresses), modernized the method used to communicate output amounts (Section \ref{sec:pedersen_monero}), replaced Borromean ring signatures with Bulletproofs (Section \ref{sec:range_proofs}), deprecated {\tt RCTTypeFull} (Chapter \ref{chapter:transactions}), updated and elaborated Monero's dynamic block weight and fee system (Chapter \ref{chapter:blockchain}), investigated transaction-related proofs (Chapter \ref{chapter:tx-knowledge-proofs}), described Monero multisignatures (Chapter \ref{chapter:multisignatures}), designed solutions for escrowed marketplaces (Chapter \ref{chapter:escrowed-market}), proposed a new decentralized joint transaction protocol named TxTangle (Chapter \ref{chapter:txtangle}), updated or added various minor details to align with the most current protocol (v12) and Monero software suite (v0.15.x.x), and scoured the document for quality-of-reading edits.\footnote{The \LaTeX{} source code for both editions of Zero to Monero can be found here (the first edition is in branch `ztm1'): \url{https://github.com/UkoeHB/Monero-RCT-report}.} + + + +\section{Acknowledgements} +\label{sec:acknowledgements} + +Written by author `koe'. + +This report would not exist without Kurt's original master's thesis \cite{kurt-original}, so to him I owe a great debt of gratitude. Monero Research Lab (MRL) researchers Brandon ``Surae Noether" Goodell and pseudonymous `Sarang Noether' (who collaborated with me on Section \ref{sec:range_proofs} and Chapter \ref{chapter:tx-knowledge-proofs}) have been a reliable and knowledgeable resource throughout both editions of Zero to Monero's development. Pseudonymous `moneromooo', the Monero Project's most prolific core developer, has probably the most extensive understanding of the codebase on this planet, and has pointed me in the right direction numerous times. And of course, many other wonderful Monero contributors have spent time answering my endless questions. Finally, to the various individuals who contacted us with proofreading feedback, and encouraging comments, thank you! \ No newline at end of file diff --git a/translations/es/content/multisig.tex b/translations/es/content/multisig.tex new file mode 100755 index 0000000..f58fde6 --- /dev/null +++ b/translations/es/content/multisig.tex @@ -0,0 +1,636 @@ +\chapter{Multisignatures in Monero} +\label{chapter:multisignatures} + +Cryptocurrency transactions are not reversible. If someone steals private keys or succeeds in a scam, the money lost could be gone forever. Dividing signing power between people can weaken the potential danger of a miscreant. + +Say you deposit money into a joint account with a security company that monitors for suspicious activity related to your account. Transactions can only be signed if both you and the company cooperate. If someone steals your keys, you can notify the company there is a problem and the company will stop signing transactions for your account. This is usually called an `escrow' service.\footnote{Multisignatures have a diversity of applications, from corporate accounts to newspaper subscriptions to online marketplaces.}\\ + +Cryptocurrencies use a `multisignature' technique to achieve collaborative signing with so-called `M-of-N multisig'. In M-of-N, N people cooperate to make a joint key, and only M people (M $\leq$ N) are needed to sign with that key. We begin this chapter by introducing the basics of N-of-N multisig, progress into N-of-N Monero multisig, generalize for M-of-N multisig, and then explain how to nest multisig keys inside other multisig keys.\\ + +In this chapter we focus on how we feel multisig {\em should} be done, based on the recommendations in \cite{MRL-0009-multisig}, and various observations about efficient implementation. We try to point out in footnotes where the current implementation deviates from what is described.\footnote{As of this writing we are aware of three multisig implementations. First is a very basic manual process using the CLI (command line interface) \cite{cli-22multisig-instructions}. Second is the truly excellent MMS (Multisig Messaging System) which enables secure, highly automated multisig via the CLI \cite{mms-manual, mms-project-proposal}. Third is the commercially available `Exa Wallet', which has initial release code available on their Github repository at \url{https://github.com/exantech} (it does not appear up to date with current release version). All three of these rely on the same fundamental core team's codebase, which essentially means only one implementation exists.} Our contributions are detailing M-of-N multisig, and a novel approach to nesting multisig keys. + + + +\section{Communicating with co-signers} +\label{sec:communicating} + +Building joint keys and joint transactions requires communicating secret information between people who could be located all around the globe. To keep that information secure from observers, co-signers need to encrypt the messages they send each other. + +Diffie-Hellman exchange (ECDH) is a very simple way to encrypt messages using elliptic curve cryptography. We already mentioned this in Section \ref{sec:pedersen_monero}, where Monero output amounts are communicated to recipients via the shared secret $r K^v$. It looked like this:\vspace{.175cm} +\begin{align*} + \mathit{amount}_t = b_t \oplus_8 \mathcal{H}_n(``amount”, \mathcal{H}_n(r K_B^v, t)) +\end{align*} + +We could easily extend this to any message. First encode the message as a series of bits, then break it into chunks equal in size to the output of $\mathcal{H}_n$. Generate a random number $r \in \mathbb{Z}_l$ and perform a Diffie-Hellman exchange on all the message chunks using the recipient's public key $K$. Send those encrypted chunks along with the public key $r G$ to the intended recipient, who can then decrypt the message with the shared secret $k r G$. Message senders should also create a signature on their encrypted message (or just the encrypted message's hash for simplicity) so receivers can confirm messages weren't tampered with (a signature is only verifiable on the correct message $\mathfrak{m}$). + +Since encryption\marginnote{src/wallet/ wallet2.cpp {\tt export\_ multisig()}} is not essential to the operation of a cryptocurrency like Monero, we do not feel it necessary to go into more detail. Curious readers can look at this excellent conceptual overview \cite{tutorialspoint-cryptography}, or see a technical description of the popular AES encryption scheme here \cite{AES-encryption}. Also, Dr. Bernstein developed an encryption scheme known as ChaCha \cite{Bernstein_chacha,chacha-irtf}, which the primary Monero implementation uses to encrypt certain sensitive information\marginnote{src/wallet/ ringdb.cpp} related to users' wallets (such as key images for owned outputs). + + + +\section{Key aggregation for addresses} +\label{sec:key-aggregation} + +\subsection{Naive approach} +\label{sec:naive-key-aggregation} + +Let's say N people want to create a group multisignature address, which we denote $(K^{v,grp},K^{s,grp})$. Funds can be sent to that address just like any normal address, but, as we will see later, to spend those funds all N people have to work together to sign transactions. + +Since all N participants should be able to view funds received by the group address, we can let everyone know the group view key $k^{v,grp}$ (recall Sections \ref{sec:user-keys} and \ref{sec:one-time-addresses}). To give all participants equal power, the view key can be a sum of view key components that all participants send each other securely. For participant $e \in \{1,...,N\}$, his base view key component is $k^{v,base}_e \in_R \mathbb{Z}_l$, and all participants can compute the group private view key\marginnote{src/multi- sig/multi- sig.cpp {\tt generate\_ multisig\_ view\_sec- ret\_key()}} +\[k^{v,grp} = \sum^{N}_{e=1} k^{v,base}_e\] + +In a similar fashion, the group spend key $K^{s,grp} = k^{s,grp} G$ could be a sum of private spend key base components. However, if someone knows all the private spend key components then they know the total private spend key. Add in the private view key and he can sign transactions on his own. It wouldn't be multisignature, just a plain old signature. + +Instead,\marginnote{src/multi- sig/multi- sig.cpp {\tt generate\_ multisig\_ N\_N()}} we get the same effect if the group spend key is a sum of public spend keys. Say the participants have base public spend keys $K^{s,base}_e$ which they send each other securely. Now let them each compute +\[K^{s,grp} = \sum_e K^{s,base}_e\] + +Clearly this is the same as +\[K^{s,grp} = (\sum_e k^{s,base}_e)*G\] + + +\subsection{Drawbacks to the naive approach} +\label{subsec:drawbacks-naive-aggregation-cancellation} + +Using a sum of public spend keys is intuitive and seemingly straightforward, but leads to a couple issues. + +\subsubsection*{Key aggregation test} +An outside adversary who knows all the base public spend keys $K^{s,base}_e$ can trivially test a given public address $(K^v,K^s)$ for key aggregation by computing $K^{s,grp} = \sum_e K^{s,base}_e$ and checking $K^s \stackrel{?}{=} K^{s,grp}$. This ties in with a broader requirement that aggregated keys be indistinguishable from normal keys, so observers can't gain any insight into users' activities based on the kind of address they publish.\footnote{If at least one honest participant uses components selected randomly from a uniform distribution, then keys aggregated by a simple sum are indistinguishable \cite{SCOZZAFAVA1993313} from normal keys.}%cite multisig paper + +We can get around this by creating new base spend keys for each multisignature address, or by masking old keys. The former case is easy, but may be inconvenient. + +The second case proceeds like this: given participant $e$'s old key pair $(K^v_e,K^s_e)$ with private keys $(k^v_e,k^s_e)$ and random masks $\mu^v_e,\mu^s_e$,\footnote{The random masks could easily be derived from some password. For example, $\mu^s = \mathcal{H}_n(password)$ and $\mu^v = \mathcal{H}_n(\mu^s)$. Or, as is done in Monero, mask the spend and view keys with a string\marginnote{src/multisig/ multisig.cpp {\tt get\_multi- sig\_blind- ed\_secret \_key()}} e.g. $\mu^s,\mu^v =$ ``Multisig". This implies Monero only supports one multisig base spend key per normal address, although in reality making a wallet multisig causes users to lose access to the original wallet \cite{cli-22multisig-instructions}. Users must make a new wallet with their normal address to access its funds, assuming the multisig wasn't made from a brand new normal address.} let his new base private key components for the group address be +\begin{align*} + k^{v,base}_e &= \mathcal{H}_n(k^v_e,\mu^v_e)\\ + k^{s,base}_e &= \mathcal{H}_n(k^s_e,\mu^s_e) +\end{align*} + +If participants don't want observers to gather the new keys and test for key aggregation, they would have to communicate their new key components to each other securely.\footnote{As we will see in Section \ref{sec:smaller-thresholds}, key aggregation does not work on M-of-N multisig when M $<$ N due to the presence of shared secrets.} + +If key aggregation tests are not a concern, they could publish their public key base components $(K^{v,base}_e,K^{s,base}_e)$ as normal addresses. Any third party could then compute the group address from those individual addresses and send funds to it, without interacting with any of the joint recipients \cite{maxwell2018simple-musig}. + +\subsubsection*{Key cancellation} + +If the group spend key is a sum of public keys, a dishonest participant who learns his collaborators' spend key base components ahead of time can cancel them. + +For example, say Alice and Bob want to make a group address. Alice, in good faith, tells Bob her key components $(k^{v,base}_A,K^{s,base}_A)$. Bob privately makes his key components $(k^{v,base}_B,K^{s,base}_B)$ but doesn't tell Alice right away. Instead, he computes $K'^{s,base}_B = K^{s,base}_B - K^{s,base}_A$ and tells Alice $(k^{v,base}_B,K'^{s,base}_B)$. The group address is:\vspace{.175cm} +\begin{align*} + K^{v,grp} &= (k^{v,base}_A + k^{v,base}_B) G \\ + &= k^{v,grp} G\\ + K^{s,grp} &= K^{s,base}_A + K'^{s,base}_B \\ + &= K^{s,base}_A + (K^{s,base}_B - K^{s,base}_A)\\ + &= K^{s,base}_B +\end{align*} + +This leaves a group address $(k^{v,grp} G,K^{s,base}_B)$ where Alice knows the private group view key, and Bob knows both the private view key {\em and} private spend key! Bob can sign transactions on his own, fooling Alice, who might believe funds sent to the address can only be spent with her permission. + +We could solve this issue by requiring each participant, before aggregating keys, to make a signature proving they know the private key to their spend key component \cite{old-multisig-mrl-note}.\footnote{Monero's current (and first) iteration of multisig, made available in April 2018 \cite{lithiumluna-v7} (with M-of-N integration following in October 2018 \cite{berylliumbullet-v8}), used this naive key aggregation, and required users sign\marginnote{src/wallet/ wallet2.cpp {\tt get\_multi- sig\_info()}} their spend key components.} This is inconvenient and vulnerable to implementation mistakes. Fortunately a solid alternative is available.%by required did I mean, they must do it on their own time; not part of multisig workflow to automatically happen + + +\subsection{Robust key aggregation} +\label{sec:robust-key-aggregation} + +To easily resist key cancellation we make a small change to spend key aggregation (leaving view key aggregation the same). Let the set of N signers' base spend key components be $\mathbb{S}^{base} = \{K^{s,base}_1,...,K^{s,base}_N\}$, ordered according to some convention (such as smallest to largest numerically, i.e. lexicographically).\footnote{$\mathbb{S}^{base}$ needs to be ordered consistently so participants can be sure they are all hashing the same thing.} The robust aggregated spend key is \cite{MRL-0009-multisig}\footnote{Recalling Section \ref{sec:CLSAG}, hash functions should be domain separated by prefixing them with tags, e.g. $T_{agg} =$ ``Multisig\_Aggregation". We leave tags out for examples like the next section's Schnorr signatures.}\footnote{It is important to include $\mathbb{S}^{base}$ in the aggregation hashes to avoid sophisticated key cancellation attacks involving Wagner's generalized solution to the birthday problem \cite{generalized-birthday-wagner}. \cite{adam-wagnerian-tragedies} \cite{maxwell2018simple-musig}}\vspace{.175cm} +\[K^{s,grp} = \sum_e \mathcal{H}_n(T_{agg},\mathbb{S}^{base},K^{s,base}_e)K^{s,base}_e\] + +Now if Bob tries to cancel Alice's spend key, he gets stuck with a very difficult problem.\vspace{.175cm} +\begin{align*} + K^{s,grp} &= \mathcal{H}_n(T_{agg},\mathbb{S},K^{s}_A)K^{s}_A + \mathcal{H}_n(T_{agg},\mathbb{S},K'^{s}_B)K'^{s}_B \\ + &= \mathcal{H}_n(T_{agg},\mathbb{S},K^{s}_A)K^{s}_A + \mathcal{H}_n(T_{agg},\mathbb{S},K'^{s}_B)K^{s}_B - \mathcal{H}_n(T_{agg},\mathbb{S},K'^{s}_B)K^{s}_A \\ + &= [\mathcal{H}_n(T_{agg},\mathbb{S},K^{s}_A) - \mathcal{H}_n(T_{agg},\mathbb{S},K'^{s}_B)]K^{s}_A + \mathcal{H}_n(T_{agg},\mathbb{S},K'^{s}_B)K^{s}_B +\end{align*} + +We leave Bob's frustration to the reader's imagination. + +Just like with the naive approach, any third party who knows $\mathbb{S}^{base}$ and the corresponding public view keys can compute the group address. + +Since participants don't need to prove they know their private spend keys, or really interact at all before signing transactions, our robust key aggregation meets the so-called {\em plain public-key model}, where ``the only requirement is that each potential signer has a public key"\cite{maxwell2018simple-musig}.\footnote{As we will see later, key aggregation only meets the plain public-key model for N-of-N and 1-of-N multisig.} + +\subsubsection*{Functions {\tt premerge} and {\tt merge}} + +More formally, and for the sake of clarity going forward, we can say there is an operation {\tt premerge} which takes in a set of base keys $\mathbb{S}^{base}$, and outputs a set of aggregation keys $\mathbb{K}^{agg}$ of equal size, where element\footnote{Notation: $\mathbb{K}^{agg}[e]$ is the e\nth element of the set.} +\[\mathbb{K}^{agg}[e] = \mathcal{H}_n(T_{agg},\mathbb{S}^{base},K^{s,base}_e)K^{s,base}_e\] + +The aggregation private keys $k^{agg}_e$ are used in group signatures.\footnote{Robust key aggregation has not yet been implemented in Monero, but since participants can store and use private key $k^{agg}_e$ (for naive key aggregation, $k^{agg}_e = k^{base}_e$), updating Monero to use robust key aggregation will only change the premerge process.} + +There is another operation {\tt merge} which takes the aggregation keys from {\tt premerge} and constructs the group signing key (e.g. spend key for Monero)\vspace{.175cm} +\[K^{grp} = \sum_e \mathbb{K}^{agg}[e]\] + +We generalize these functions for (N-1)-of-N and M-of-N in Section \ref{sec:n-1-of-n}, and further generalize them for nested multisig in Section \ref{subsec:nesting-multisig-keys}. + + + +\section{Thresholded Schnorr-like signatures} +\label{sec:threshold-schnorr} + +It takes a certain amount of signers for a multisignature to work, so we say there is a `threshold' of signers below which the signature can't be produced. A multisignature with N participants that requires all N people to build a signature, usually referred to as {\em N-of-N multisig}, would have a threshold of N. Later we will extend this to M-of-N (M $\leq$ N) multisig where N participants create the group address but only M people are needed to make signatures. + +Let's take a step back from Monero. All signature schemes in this document lead from Maurer's general zero-knowledge proof of knowledge \cite{simple-zk-proof-maurer}, so we can demonstrate the essential form of thresholded signatures using a simple Schnorr-like signature (recall Section \ref{sec:signing-messages}) \cite{old-multisig-mrl-note}. + + +\subsection*{Signature} + +Say there are N people who each have a public key in the set $\mathbb{K}^{agg}$, where each person $e \in \{1,...,N\}$ knows the private key $k^{agg}_e$. Their N-of-N group public key, which they will use to sign messages, is $K^{grp}$. Suppose they want to jointly sign a message $\mathfrak{m}$. They could collaborate on a basic Schnorr-like signature like this +\begin{enumerate} + \item Each participant $e \in \{1,...,N\}$ does the following: + \begin{enumerate} + \item picks random component $\alpha_e \in_R \mathbb{Z}_l$, + \item computes $\alpha_e G$ + \item commits to it with $C^{\alpha}_e = \mathcal{H}_n(T_{com},\alpha_e G)$, + \item and sends $C^{\alpha}_e$ to the other participants securely. + \end{enumerate} + \item Once all commitments $C^{\alpha}_e$ have been collected, each participant sends their $\alpha_e G$ to the other participants securely. They must verify that $C^{\alpha}_e \stackrel{?}{=} \mathcal{H}_n(T_{com},\alpha_e G)$ for all other participants. + \item Each participant computes + \[ \alpha G = \sum_e \alpha_e G \] + \item Each participant $e \in \{1,...,N\}$ does the following:\footnote{As in Section \ref{sec:schnorr-fiat-shamir}, it is important not to reuse $\alpha_e$ for different challenges $c$. This means to reset a multisignature process where responses have been sent out, it should start again from the beginning with new $\alpha_e$ values.} + \begin{enumerate} + \item computes the challenge $c = \mathcal{H}_n(\mathfrak{m},[\alpha G])$, + \item defines their response component $r_e = \alpha_e - c* k^{agg}_e \pmod l$, + \item and sends $r_e$ to the other participants securely. + \end{enumerate} + \item Each participant computes + \[ r = \sum_e r_e\] + \item Any participant can publish the signature $\sigma(\mathfrak{m}) = (c,r)$. +\end{enumerate} + + +\subsection*{Verification} + +Given $K^{grp}$, $\mathfrak{m}$, and $\sigma(\mathfrak{m}) = (c,r)$: +\begin{enumerate} + \item Compute the challenge $c' = \mathcal{H}_n(\mathfrak{m},[r G + c*K^{grp}])$. + \item If $c = c'$ then the signature is legitimate except with negligible probability. +\end{enumerate} + +We included the superscript $grp$ for clarity, but in reality the verifier has no way to tell $K^{grp}$ is a merged key unless a participant tells him, or unless he knows the base or aggregation key components. + + +\subsection*{Why it works} + +Response $r$ is the core of this signature. Participant $e$ knows two secrets in $r_e$ ($\alpha_e$ and $k^{agg}_e$), so his private key $k^{agg}_e$ is information-theoretically secure from other participants (assuming he never reuses $\alpha_e$). Moreover, verifiers use the group public key $K^{grp}$, so all key components are needed to build signatures. +\begin{align*} + r G &= (\sum_e r_e) G \\ + &= (\sum_e (\alpha_e - c*k^{agg}_e)) G \\ + &= (\sum_e \alpha_e) G - c*(\sum_e k^{agg}_e) G \\ + &= \alpha G - c*K^{grp} \\ + \alpha G &= r G + c*K^{grp} \\ + \mathcal{H}_n(\mathfrak{m},[\alpha G]) &= \mathcal{H}_n(\mathfrak{m},[r G + c*K^{grp}]) \\ + c &= c' +\end{align*} + + +\subsection*{Additional commit-and-reveal step} + +The reader may be wondering where Step 2 came from. Without commit-and-reveal \cite{MRL-0009-multisig}, a malicious co-signer could learn all $\alpha_e G$ {\em before} the challenge is computed. This lets him control the challenge produced to some degree, by modifying his own $\alpha_e G$ prior to sending it out. He can use the response components collected from multiple controlled signatures to derive other signers' private keys $k^{agg}_e$ in sub-exponential time \cite{cryptoeprint:2018:417}, a serious security threat. This threat relies on Wagner's generalization \cite{generalized-birthday-wagner} (see also \cite{adam-wagnerian-tragedies} for a more intuitive explanation) of the birthday problem \cite{birthday-problem}.\footnote{Commit-and-reveal is not used in the current implementation of Monero multisig, although it is being looked at for future releases. \cite{multisig-research-issue-67}} + + + +\section{MLSTAG Ring Confidential signatures for Monero} +\label{sec:MLSTAG-RingCT} + +Monero thresholded ring confidential transactions add some complexity because MLSTAG (thresholded MLSAG) signing keys are one-time addresses and commitments to zero (for input amounts). + +Recalling Section \ref{sec:multi_out_transactions}, a one-time address assigning ownership of a transaction's $t$\nth output to whoever has public address $(K^v_t,K^s_t)$ goes like this\vspace{.175cm} +\begin{align*} + K_t^o &= \mathcal{H}_n(r K_t^v, t)G + K_t^s = (\mathcal{H}_n(r K_t^v, t) + k_t^s)G \\ + k_t^o &= \mathcal{H}_n(r K_t^v, t) + k_t^s +\end{align*} + +We can update our notation for outputs received by a group address $(K^{v,grp}_t,K^{s,grp}_t)$:\vspace{.175cm} +\begin{align*} + K^{o,grp}_t &= \mathcal{H}_n(r K^{v,grp}_t, t)G + K^{s,grp}_t \\ + k^{o,grp}_t &= \mathcal{H}_n(r K^{v,grp}_t, t) + k^{s,grp}_t +\end{align*} + +Just as before, anyone with $k^{v,grp}_t$ and $K^{s,grp}_t$ can discover $K^{o,grp}_t$ is their address's owned output, and can decode the Diffie-Hellman term for output amount and reconstruct the corresponding commitment mask (Section \ref{sec:pedersen_monero}). + +This also means multisig subaddresses are possible (Section \ref{sec:subaddresses}). Multisig transactions using funds received to a subaddress require some fairly straightforward modifications to the following algorithms, which we mention in footnotes.\footnote{Multisig subaddresses are supported in Monero.} + + +\subsection{{\tt RCTTypeBulletproof2} with N-of-N multisig} +\label{sec:rcttypebulletproof2-multisig} + +Most parts of a multisig transaction can be completed by whoever initiated it. Only the MLSTAG signatures require collaboration. An initiator should do these things to prepare for an {\tt RCTTypeBulletproof2} transaction (recall Section \ref{sec:RCTTypeBulletproof2}): +\begin{enumerate} + \item Generate a transaction private key $r \in_R \mathbb{Z}_l$ (Section \ref{sec:one-time-addresses}) and compute the corresponding public key $r G$ (or multiple such keys if dealing with a subaddress recipient; Section \ref{sec:subaddresses}). + \item Decide the inputs to be spent ($j \in \{1,...,m\}$ owned outputs with one-time addresses $K^{o,grp}_j$ and amounts $a_1,...,a_m$), and recipients to receive funds ($t \in \{0,...,p-1\}$ new outputs with amounts $b_0,...,b_{p-1}$ and one-time addresses $K^{o}_t$). This includes the miner's fee $f$ and its commitment $f H$. Decide each input's set of decoy ring members. + \item Encode each output's amount $\mathit{amount}_t$ (Section \ref{sec:pedersen_monero}), and compute the output commitments $C^b_t$. + \item Select, for each input $j \in \{1,...,m-1\}$, pseudo output commitment mask components $x'_{j} \in_R \mathbb{Z}_l$, and compute the $m$\nth mask as (Section \ref{sec:ringct-introduction}) + \[x'_m = \sum_t y_t - \sum_{j=1}^{m-1} x'_j\] + Compute the pseudo output commitments $C'^a_{j}$. + \item Produce the aggregate Bulletproof range proof for all outputs. Recall Section \ref{sec:range_proofs}. + \item Prepare for MLSTAG signatures by generating, for the commitments to zero, seed components $\alpha^z_{j} \in_R \mathbb{Z}_l$, and computing $\alpha^z_{j} G$.\footnote{There is no need to commit-and-reveal these since the commitments to zero are known by all signers.} +\end{enumerate} + +He sends all this information to the other participants securely. Now the group of signers is ready to build input signatures with their private keys $k^{s,agg}_e$, and the commitments to zero $C^a_{\pi,j} - C'^a_{\pi,j} = z_j G$. + +\subsubsection*{MLSTAG RingCT} + +First\marginnote{src/wallet/ wallet2.cpp {\tt sign\_multi- sig\_tx()}} they construct the group key images for all inputs $j \in \{1,...,m\}$ with one-time addresses $K^{o,grp}_{\pi,j}$.\footnote{If $K^{o,grp}_{\pi,j}$ is built from an $i$-indexed multisig subaddress, then (from Section \ref{sec:subaddresses}) its private key is a composite: +\[k^{o,grp}_{\pi,j} = \mathcal{H}_n(k^{v,grp} r_{u_j} K^{s,grp,i}, u_j) + \sum_e k^{s,agg}_e + \mathcal{H}_n(k^{v,grp},i)\]} +\begin{enumerate} + \item For each input $j$ each participant $e$ does the following: + \begin{enumerate} + \item computes partial key image $\tilde{K}^{o}_{j,e} = k^{s,agg}_e \mathcal{H}_p(K^{o,grp}_{\pi,j})$, + \item and sends $\tilde{K}^{o}_{j,e}$ to the other participants securely. + \end{enumerate} + \item Each participant can now compute, using $u_j$ as the output index in the transaction where $K^{o,grp}_{\pi,j}$ was sent to the multisig address,\footnote{If the one-time address corresponds to an $i$-indexed multisig subaddress, add\marginnote{src/crypto- note\_basic/ cryptonote\_ format\_ utils.cpp {\tt generate\_key\_ image\_helper\_ precomp()}} + \[\tilde{K}^{o,grp}_j = ... + \mathcal{H}_n(k^{v,grp},i) \mathcal{H}_p(K^{o,grp}_{\pi,j})\]} + \[\tilde{K}^{o,grp}_j = \mathcal{H}_n(k^{v,grp} r G, u_j) \mathcal{H}_p(K^{o,grp}_{\pi,j}) + \sum_e \tilde{K}^{o}_{j,e}\] +\end{enumerate} + +Then they build a MLSTAG signature for each input $j$. +\begin{enumerate} + \item Each participant $e$ does the following: + \begin{enumerate} + \item generates\marginnote{src/wallet/ wallet2.cpp {\tt get\_multi- sig\_kLRki()}} seed components $\alpha_{j,e} \in_R \mathbb{Z}_l$ and computes $\alpha_{j,e} G$, and $\alpha_{j,e} \mathcal{H}_p(K^{o,grp}_{\pi,j})$, + \item generates, for $i \in \{1,...,v+1\}$ except $i = \pi$, random components $r_{i,j,e}$ and $r^z_{i,j,e}$, + \item computes the commitment + \[C^{\alpha}_{j,e} = \mathcal{H}_n(T_{com},\alpha_{j,e} G, \alpha_{j,e} \mathcal{H}_p(K^{o,grp}_{\pi,j}),r_{1,j,e},...,r_{v+1,j,e},r^z_{1,j,e},...,r^z_{v+1,j,e})\] + \item and sends $C^{\alpha}_{j,e}$ to the other participants securely. + \end{enumerate} + \item Upon receiving all $C^{\alpha}_{j,e}$ from the other participants, send all $\alpha_{j,e} G$, $\alpha_{j,e} \mathcal{H}_p(K^{o,grp}_{\pi,j})$, and $r_{i,j,e}$ and $r^z_{i,j,e}$, and verify each participant's original commitment was valid. + \item Each participant can compute all + \begin{align*} + \alpha_{j} G &= \sum_e \alpha_{j,e} G\\ + \alpha_{j} \mathcal{H}_p(K^{o,grp}_{\pi,j}) &= \sum_e \alpha_{j,e} \mathcal{H}_p(K^{o,grp}_{\pi,j})\\ + r_{i,j} &= \sum_e r_{i,j,e}\\ + r^{z}_{i,j} &= \sum_e r^z_{i,j,e} + \end{align*}{} + \item Each participant can build the signature loop (see Section \ref{sec:MLSAG}). + \item To finish closing the signature, each participant $e$ does the following: + \begin{enumerate} + \item defines $r_{\pi,j,e} = \alpha_{j,e} - c_{\pi} k^{s,agg}_e \pmod l$, + \item and sends $r_{\pi,j,e}$ to the other participants securely. + \end{enumerate} + \item Everyone\marginnote{src/ringct/ rctSigs.cpp {\tt signMulti- sig()}} can compute (recall $\alpha^z_{j,e}$ was created by the initiator)\footnote{If the one-time address $K^{o,grp}_{\pi,j}$ corresponds to an $i$-indexed multisig subaddress, include\marginnote{src/crypto- note\_basic/ cryptonote\_ format\_ utils.cpp {\tt generate\_key\_ image\_helper\_ precomp()}} + \[r_{\pi,j} = ... - c_{\pi}*\mathcal{H}_n(k^{v,grp},i)\]}\vspace{.175cm} + \[r_{\pi,j} = \sum_e r_{\pi,j,e} - c_{\pi}*\mathcal{H}_n(k^{v,grp} r G, u_j)\] + \[r^{z}_{\pi,j} = \alpha^z_{j,e} - c_{\pi} z_j \pmod l\] +\end{enumerate} + +The signature for input $j$ is $\sigma_j(\mathfrak{m}) = (c_1,r_{1,j},r^{z}_{1,j},...,r_{v+1,j},r^{z}_{v+1,j})$ with $\tilde{K}^{o,grp}_j$. + +Since in Monero the message $\mathfrak{m}$ and the challenge $c_{\pi}$ depend on all other parts of the transaction, any participant who tries to cheat by sending the wrong value, at any point in the whole process, to his fellow signers will cause the signature to fail. The response $r_{\pi,j}$ is only useful for the $\mathfrak{m}$ and $c_{\pi}$ it is defined for. + + +\subsection{Simplified communication} +\label{sec:simplified-communication} + +It takes a lot of steps to build a multisignature Monero transaction. We can reorganize and simplify some of them so that signer interactions are encompassed by two parts with five total rounds. +\begin{enumerate} + \item {\it Key aggregation for a multisig public address}: Anyone with a set of public addresses can run {\tt premerge} on them and then {\tt merge} an N-of-N address, but no participant will know the group view key unless they learn all the components, so the group starts by sending $k^{v}_e$ and $K^{s,base}_e$ to each other securely\marginnote{src/wallet/ wallet2.cpp {\tt pack\_multi- signature\_ keys()}}. Any participant can {\tt premerge} and {\tt merge} and publish $(K^{v,grp},K^{s,grp})$, allowing the group to receive funds to the group address. M-of-N aggregation requires more steps, which we describe in Section \ref{sec:smaller-thresholds}. + \item {\it Transactions}: + \begin{enumerate} + \item Some participant or sub-coalition (the initiator)\marginnote{src/wallet/ wallet2.cpp {\tt transfer\_ selected\_ rct()}} decides to write a transaction. They choose $m$ inputs with one-time addresses $K^{o,grp}_{j}$ and amount commitments $C^a_j$, $m$ sets of $v$ additional one-time addresses and commitments to be used as ring decoys, pick $p$ output recipients with public addresses $(K^v_t,K^s_t)$ and amounts $b_t$ to send them, decide a transaction fee $f$, pick a transaction private key $r$,\footnote{Or transaction private keys $r_{t}$ if sending to at least one subaddress.} generate pseudo output commitment masks $x'_{j}$ with $j \neq m$, construct the ECDH term $\mathit{amount}_t$ for each output, produce an aggregate range proof, and generate signature openers $\alpha^z_j$ for all inputs' commitments to zero and random scalars $r_{i,j}$ and $r^z_{i,j}$ with $i \neq \pi_j$.\footnote{Note that we simplify the signing process by letting the initiator generate random scalars $r_{i,j}$ and $r^z_{i,j}$, instead of each co-signer generating components that eventually get summed together.} They also prepare their contribution for the next communication round.\\ + + The initiator\marginnote{src/wallet/ wallet2.cpp {\tt save\_multi- sig\_tx()}} sends all this information to the other participants securely.\footnote{He doesn't need to send the output amounts $b_t$ directly, as they can be computed from $\mathit{amount}_t$. Monero takes the reasonable approach of creating a partial transaction filled with the information selected by the initiator, and sending that to other cosigners along with a list of related information like transaction private keys, destination addresses, the real inputs, etc.} The other participants can signal agreement by sending their part of the next communication round, or negotiate for changes. + \item Each participant chooses their opening components for the MLSTAG signature(s), commits to them, calculates their partial key images, and sends those commitments and partial images to other participants securely.\\ + + MLSTAG Signature(s): key image $\tilde{K}^{o}_{j,e}$, signature randomness $\alpha_{j,e} G$, and $\alpha_{j,e} \mathcal{H}_p(K^{o,grp}_{\pi,j})$. Partial key images don't need to be in committed data, as they can't be used to extract signers' private keys. They are also useful for viewing which owned outputs have been spent, so for the sake of modular design should be handled separately.% In line with that modularity, since participants could provide fake partial images in order to fool other participants (e.g. non-signing ones) into thinking an owned output is unspent, it is necessary to create a proof of legitimacy for all partial key images using the method from Section \ref{dualbase proof}. + \item Upon receiving all signature commitments, each participant sends the committed information to the other participants securely. + \item Each participant closes their part of the MLSTAG signature(s), sending all $r_{{\pi_j},j,e}$ to the other participants securely.\footnote{It is imperative that each signing attempt by a signer use a unique $\alpha_{j,e}$, to avoid leaking his private spend key to other signers (recall Section \ref{sec:schnorr-fiat-shamir}) \cite{MRL-0009-multisig}. Wallets should fundamentally enforce this by always deleting\marginnote{src/wallet/ wallet2.cpp {\tt save\_multi- sig\_tx()}} $\alpha_{j,e}$ whenever a response that uses it has been transmitted outside of the wallet.} + \end{enumerate} +\end{enumerate} + +Assuming the process went well, all participants can finish writing the transaction and broadcast it on their own. Transactions authored by a multisig coalition are indistinguishable from those authored by individuals. + + + +\section{Recalculating key images} +\label{sec:recalculating-key-images-multisig} + +If someone loses their records and wants to calculate their address's balance (received minus spent funds), they need to check the blockchain. View keys are only useful for reading received funds, so users need to calculate key images for all owned outputs to see if they have been spent, by comparing with key images stored in the blockchain. Since members of a group address can't compute key images on their own, they need to enlist the other participants' help. + +Calculating key images from a simple sum of components might fail if dishonest participants report false keys.\footnote{Currently Monero\marginnote{src/wallet/ wallet2.cpp {\tt export\_multi- sig()}} appears to use a simple sum.} Given a received output with one-time address $K^{o,grp}$, the group can produce a simple `linkable' Schnorr-like proof (basically single-key bLSTAG, recall Sections \ref{sec:proofs-discrete-logarithm-multiple-bases} and \ref{blsag_note}) to prove the key image $\tilde{K}^{o,grp}$ is legitimate without revealing their private spend key components or needing to trust each other. + + +\subsection*{Proof} + +\begin{enumerate} + \item Each participant $e$ does the following: + \begin{enumerate} + \item computes $\tilde{K}^{o}_{e} = k^{s,agg}_e \mathcal{H}_p(K^{o,grp})$, + \item generates seed component $\alpha_e \in_R \mathbb{Z}_l$ and computes $\alpha_e G$ and $\alpha_e \mathcal{H}_p(K^{o,grp})$, + \item commits to the data with $C^{\alpha}_{e} = \mathcal{H}_n(T_{com}, \alpha_e G, \alpha_e \mathcal{H}_p(K^{o,grp}))$, + \item and sends $C^{\alpha}_{e}$ and $\tilde{K}^{o}_{e}$ to the other participants securely. + \end{enumerate} + \item Upon receiving all $C^{\alpha}_{e}$, each participant sends the committed information and verifies other participants' commitments were legitimate. + \item Each participant can compute:\footnote{If the one-time address corresponds to an $i$-indexed multisig subaddress, add + \[\tilde{K}^{o,grp} = ... + \mathcal{H}_n(k^{v,grp},i) \mathcal{H}_p(K^{o,grp})\]}\vspace{.175cm} + \[\tilde{K}^{o,grp} = \mathcal{H}_n(k^{v,grp} r G, u) \mathcal{H}_p(K^{o,grp}) + \sum_e \tilde{K}^{o}_{e}\] + \[\alpha G = \sum_e \alpha_{e} G\] + \[\alpha \mathcal{H}_p(K^{o,grp}) = \sum_e \alpha_{e} \mathcal{H}_p(K^{o,grp})\] + \item Each participant computes the challenge\footnote{This proof should include domain separation and key prefixing, which we omit for brevity.}\vspace{.175cm} + \[c = \mathcal{H}_n([\alpha G],[\alpha \mathcal{H}_p(K^{o,grp})])\] + \item Each participant does the following: + \begin{enumerate} + \item defines $r_e = \alpha_e - c*k^{s,agg}_e \pmod l$, + \item and sends $r_e$ to the other participants securely. + \end{enumerate} + \item Each participant can compute\footnote{If the one-time address $K^{o,grp}$ corresponds to an $i$-indexed multisig subaddress, include + \[r^{resp} = ... - c*\mathcal{H}_n(k^{v,grp},i)\]}\vspace{.175cm} + \[r^{resp} = \sum_e r_e - c*\mathcal{H}_n(k^{v,grp} r G, u)\] +\end{enumerate} + +The proof is $(c,r^{resp})$ with $\tilde{K}^{o,grp}$. + + +\subsection*{Verification} + +\begin{enumerate} + \item Check $l \tilde{K}^{o,grp} \stackrel{?}{=} 0$. + \item Compute $c' = \mathcal{H}_n([r^{resp} G + c*K^{o,grp}],[r^{resp} \mathcal{H}_p(K^{o,grp}) + c*\tilde{K}^{o,grp}])$. + \item If $c = c'$ then the key image $\tilde{K}^{o,grp}$ corresponds to one-time address $K^{o,grp}$ (except with negligible probability). +\end{enumerate} + + + +\section{Smaller thresholds} +\label{sec:smaller-thresholds} + +At the beginning of this chapter we discussed escrow services, which used 2-of-2 multisig to split signing power between a user and a security company. That setup isn't ideal, because if the security company is compromised, or refuses to cooperate, your funds may get stuck. + +We can get around that potentiality with a 2-of-3 multisig address, which has three participants but only needs two of them to sign transactions. An escrow service provides one key and users provide two keys. Users can store one key in a secure location (like a safety deposit box), and use the other for day-to-day purchases. If the escrow service fails, a user can use the secure key and day key to withdraw funds. + +Multisignatures with sub-N thresholds have a wide range of uses. + + +\subsection{1-of-N key aggregation} +\label{sec:1-of-n} + +Suppose a group of people want to make a multisig key $K^{grp}$ they can all sign with. The solution is trivial: let everyone know the private key $k^{grp}$. There are three ways to do this. +\begin{enumerate} + \item One participant or sub-coalition selects a key and sends it to everyone else securely. + \item All participants compute private key components and send them securely, using the simple sum as the merged key.\footnote{Note that key cancellation is largely meaningless here because everyone knows the full private key.} + \item Participants extend M-of-N multisig to 1-of-N. This might be useful if an adversary has access to the group's communications. +\end{enumerate} + +In this case, for Monero, everyone would know the private keys $(k^{v,grp,{1\textrm{xN}}},k^{s,grp,{1\textrm{xN}}})$. Before this section all group keys were N-of-N, but now we use superscript 1xN to denote keys related to 1-of-N signing. + + +\subsection{(N-1)-of-N key aggregation} +\label{sec:n-1-of-n} + +In an (N-1)-of-N group key, such as 2-of-3 or 4-of-5, any set of (N-1) participants can sign. We achieve this with Diffie-Hellman shared secrets. Lets say there are participants $e \in \{1,...,N\}$, with base public keys $K^{base}_e$ which they are all aware of. + +Each participant\marginnote{src/multi- sig/multi- sig.cpp {\tt generate\_ multisig\_ N1\_N()}} $e$ computes, for $w \in \{1,...,N\}$ but $w \neq e$\vspace{.175cm} +\[k^{sh,\textrm{(N-1)xN}}_{e,w} = \mathcal{H}_n(k^{base}_e K^{base}_w)\] + +Then he computes all $K^{sh,\textrm{(N-1)xN}}_{e,w} = k^{sh,\textrm{(N-1)xN}}_{e,w} G$ and sends them to the other participants securely. We now use superscript $sh$ to denote keys shared by a sub-group of participants. + +Each participant will have (N-1) shared private key components corresponding to each of the other participants, making N*(N-1) total keys between everyone. All keys are shared by two Diffie-Hellman partners, so there are really [N*(N-1)]/2 unique keys. Those unique keys compose the set $\mathbb{S}^{\textrm{(N-1)xN}}$. + +\subsubsection*{Generalizing {\tt premerge} and {\tt merge}} + +This is where we update the definition of {\tt premerge} from Section \ref{sec:robust-key-aggregation}. Its input will be the set $\mathbb{S}^{\textrm{MxN}}$, where $M$ is the `threshold' that the set's keys are prepared for. When $M = N$, $\mathbb{S}^{\textrm{NxN}} = \mathbb{S}^{base}$, and when $M < N$ it contains shared keys. The output is $\mathbb{K}^{agg,\textrm{MxN}}$. + +The [N*(N-1)]/2 key components in $\mathbb{K}^{agg,\textrm{(N-1)xN}}$ can be sent into {\tt merge}, outputting $K^{grp,\textrm{(N-1)xN}}$. Importantly, all [N*(N-1)]/2 private key components can be assembled with just (N-1) participants since each participant shares one Diffie-Hellman secret with the N\nth guy. + +\subsubsection*{A 2-of-3 example} + +Say there are three people with public keys $\{K^{base}_1,K^{base}_2,K^{base}_3\}$, to which they each know a private key, who want to make a 2-of-3 multisig key. After Diffie-Hellman and sending each other the public keys they each know the following: +\begin{enumerate} + \item Person 1: $k^{sh,\textrm{2x3}}_{1,2}$, $k^{sh,\textrm{2x3}}_{1,3}$, $K^{sh,\textrm{2x3}}_{2,3}$ + \item Person 2: $k^{sh,\textrm{2x3}}_{2,1}$, $k^{sh,\textrm{2x3}}_{2,3}$, $K^{sh,\textrm{2x3}}_{1,3}$ + \item Person 3: $k^{sh,\textrm{2x3}}_{3,1}$, $k^{sh,\textrm{2x3}}_{3,2}$, $K^{sh,\textrm{2x3}}_{1,2}$ +\end{enumerate} + +Where $k^{sh,\textrm{2x3}}_{1,2} = k^{sh,\textrm{2x3}}_{2,1}$, and so on. The set $\mathbb{S}^{\textrm{2x3}} = \{ K^{sh,\textrm{2x3}}_{1,2}, K^{sh,\textrm{2x3}}_{1,3}, K^{sh,\textrm{2x3}}_{2,3}\}$. + +Performing {\tt premerge} and {\tt merge} creates the group key:\footnote{Since the merged key is composed of shared secrets, an observer who just knows the original base public keys would not be able to aggregate them (Section \ref{subsec:drawbacks-naive-aggregation-cancellation}) and identify members of the merged key.}\vspace{.175cm} +\begin{align*} + K^{grp,\textrm{2x3}} = &\mathcal{H}_n(T_{agg},\mathbb{S}^{\textrm{2x3}},K^{sh,\textrm{2x3}}_{1,2}) K^{sh,\textrm{2x3}}_{1,2} + \\ + &\mathcal{H}_n(T_{agg},\mathbb{S}^{\textrm{2x3}},K^{sh,\textrm{2x3}}_{1,3}) K^{sh,\textrm{2x3}}_{1,3} + \\ + &\mathcal{H}_n(T_{agg},\mathbb{S}^{\textrm{2x3}},K^{sh,\textrm{2x3}}_{2,3}) K^{sh,\textrm{2x3}}_{2,3} +\end{align*} + +Now let's say persons 1 and 2 want to sign a message $\mathfrak{m}$. We will use a basic Schnorr-like signature to demonstrate. +\begin{enumerate} + \item Each participant $e \in \{1,2\}$ does the following: + \begin{enumerate} + \item picks random component $\alpha_e \in_R \mathbb{Z}_l$, + \item computes $\alpha_e G$, + \item commits with $C^{\alpha}_{e} = \mathcal{H}_n(T_{com},\alpha_e G)$, + \item and sends $C^{\alpha}_{e}$ to the other participants securely. + \end{enumerate} + \item On receipt of all $C^{\alpha}_{e}$, each participant sends out $\alpha_e G$ and verifies the other commitments were legitimate. + \item Each participant computes + \[\alpha G = \sum_e \alpha_e G\] + \[c = \mathcal{H}_n(\mathfrak{m},[\alpha G])\] + \item Participant 1 does the following: + \begin{enumerate} + \item computes $r_1 = \alpha_1 - c*[k^{agg,\textrm{2x3}}_{1,3} + k^{agg,\textrm{2x3}}_{1,2}]$, + \item and sends $r_1$ to participant 2 securely. + \end{enumerate} + \item Participant 2 does the following: + \begin{enumerate} + \item computes $r_2 = \alpha_2 - c*k^{agg,\textrm{2x3}}_{2,3}$, + \item and sends $r_2$ to participant 1 securely. + \end{enumerate} + \item Each participant computes + \[r = \sum_e r_e\] + \item Either participant can publish the signature $\sigma(\mathfrak{m}) = (c,r)$. +\end{enumerate} + +The only change with sub-N threshold signatures is how to `close the loop' by defining $r_{\pi,e}$ (in the case of ring signatures, with secret index $\pi$). Each participant must include their shared secret corresponding to the `missing person', but since all the other shared secrets are doubled up there is a trick. Given the set $\mathbb{S}^{base}$ of all participants' original keys, only the {\em first person} - ordered by index in $\mathbb{S}^{base}$ - with the copy of a shared secret uses it to calculate his $r_{\pi,e}$.\footnote{In\marginnote{src/wallet/ wallet2.cpp {\tt transfer\_ selected\_ rct()}} practice this means an initiator should determine which subset of M signers will sign a given message. If he discovers O signers are willing to sign, with (O $\geq$ M), he can orchestrate multiple concurrent signing attempts for each M-size subset within O to increase the chances of one succeeding. It appears Monero uses this approach. It also turns out (an esoteric point) that the {\em original} list of output destinations created by the initiator is randomly shuffled, and that random list is then used by all concurrent signing attempts, and all other co-signers (this is related to the obscure flag {\tt shuffle\_outs}).}\footnote{Currently Monero appears to use a round-robin signing method\marginnote{src/wallet/ wallet2.cpp {\tt sign\_multi- sig\_tx()}}, where the initiator signs with all his private keys, passes the partially signed transaction to another signer who signs with all {\em his} private keys (that have not been used to sign with yet), who passes to yet another signer, and so on, until the final signer who can either publish the transaction or send it to other signers so they can publish it.} + +In the previous example, participant 1 computes\vspace{.175cm} +\[r_1 = \alpha_1 - c*[k^{agg,\textrm{2x3}}_{1,3} + k^{agg,\textrm{2x3}}_{1,2}]\] + +while participant 2 only computes +\[r_2 = \alpha_2 - c*k^{agg,\textrm{2x3}}_{2,3}\] + +The same principle applies to computing the group key image in sub-N threshold Monero multisig transactions. + + +\subsection{M-of-N key aggregation} +\label{sec:m-of-n} + +We can understand M-of-N by adjusting our perspective on (N-1)-of-N. In (N-1)-of-N every shared secret between two public keys, such as $K^{base}_1$ and $K^{base}_2$, contains two private keys, $k^{base}_1 k^{base}_2 G$. It's a secret because only person 1 can compute $k^{base}_1 K^{base}_2$, and only person 2 can compute $k^{base}_2 K^{base}_1$. + +What if there is a third person with $K^{base}_3$, there exist shared secrets $k^{base}_1 k^{base}_2 G$, $k^{base}_1 k^{base}_3 G$, and $k^{base}_2 k^{base}_3 G$, and the participants send those public keys to each other (making them no longer secret)? They each contributed a private key to two of the public keys. Now say they make a new shared secret with that third public key. + +Person 1\marginnote{src/multi- sig/multi- sig.cpp {\tt generate\_ multisig\_ deriv- ations()}} computes shared secret $k^{base}_1*(k^{base}_2 k^{base}_3 G)$, person 2 computes $k^{base}_2*(k^{base}_1 k^{base}_3 G)$, and person 3 computes $k^{base}_3*(k^{base}_1 k^{base}_2 G)$. Now they all know $k^{base}_1 k^{base}_2 k^{base}_3 G$, making a three-way shared secret (so long as no one publishes it). + +The group could use $k^{sh,\textrm{1x3}} = \mathcal{H}_n(k^{base}_1 k^{base}_2 k^{base}_3 G)$ as a shared private key, and publish\vspace{.155cm} \[K^{grp,\textrm{1x3}} = \mathcal{H}_n(T_{agg},\mathbb{S}^{\textrm{1x3}},K^{sh,\textrm{1x3}}) K^{sh,\textrm{1x3}}\] as a 1-of-3 multisig address. + +In a 3-of-3 multisig every 1 person has a secret, in a 2-of-3 multisig every group of 2 people has a shared secret, and in 1-of-3 every group of 3 people has a shared secret. + +Now we can generalize to M-of-N: every possible group of (N-M+1) people has a shared secret \cite{old-multisig-mrl-note}. If (N-M) people are missing, all their shared secrets are owned by at least one of the M remaining people, who can collaborate to sign with the group's key. + +\subsubsection*{M-of-N algorithm} + +Given participants $e \in \{1,...,N\}$ with initial private keys $k^{base}_1,...,k^{base}_N$ who wish to produce an M-of-N merged key (M $\leq$ N; M $\geq$ 1 and N $\geq$ 2), we can use an\marginnote{src/wallet/ wallet2.cpp {\tt exchange\_ multisig\_ keys()}} interactive algorithm. + +We will use $\mathbb{S}_s$ to denote all the {\em unique} public keys at stage $s \in \{0,...,(N-M)\}$. The final set $\mathbb{S}_{N-M}$ is ordered according to a sorting convention (such as smallest to largest numerically, i.e. lexicographically). This notation is a convenience, and $\mathbb{S}_s$ is the same as $\mathbb{S}^{\textrm{(N-s)xN}}$ from the previous sections. + +We will use $\mathbb{S}^K_{s,e}$ to denote the set of public keys each participant created at stage $s$ of the algorithm. In the beginning $\mathbb{S}^K_{0,e} = \{K^{base}_e\}$. + +The set $\mathbb{S}^{k}_{e}$ will contain each participant's aggregation private keys at the end. +\begin{enumerate} + \item Each participant $e$ sends their original public key set $\mathbb{S}^K_{0,e} = \{K^{base}_e\}$ to the other participants securely. + \item Each participant builds $\mathbb{S}_{0}$ by collecting all $\mathbb{S}^K_{0,e}$ and removing duplicates. + \item For stage $s \in \{1,...,(N-M)\}$ (skip if M = N) + \begin{enumerate} + \item Each participant $e$ does the following: + \begin{enumerate} + \item For each element $g_{s-1}$ of $\mathbb{S}_{s-1} \notin \mathbb{S}^K_{s-1,e}$, compute a new shared secret \[k^{base}_e*\mathbb{S}_{s-1}[g_{s-1}]\] + \item Put all new shared secrets in $\mathbb{S}^K_{s,e}$. + \item If $s = (N-M)$, compute the shared private key for each element $x$ in $\mathbb{S}^K_{N-M,e}$ + \[\mathbb{S}^{k}_{e}[x] = \mathcal{H}_n(\mathbb{S}^K_{N-M,e}[x])\] + + and overwrite the public key by setting $\mathbb{S}^K_{N-M,e}[x] = \mathbb{S}^{k}_{e}[x]*G$. + \item Send the other participants $\mathbb{S}^K_{s,e}$. + \end{enumerate} + \item Each participant builds $\mathbb{S}_{s}$ by collecting all $\mathbb{S}^K_{s,e}$ and removing duplicates.\footnote{Participants should keep track of who has which keys at the last stage ($s = N-M$), to facilitate collaborative signing, where only the first person in $\mathbb{S}_0$ with a certain private key uses it to sign. See Section \ref{sec:n-1-of-n}.} + \end{enumerate} + \item Each participant sorts $\mathbb{S}_{N-M}$ according to the convention. + \item The {\tt premerge} function takes $\mathbb{S}_{(N-M)}$ as input, and each aggregation key is, for \(g \in \{1,...,(\textrm{size of }\mathbb{S}_{N-M})\}\),\vspace{.175cm} + \[\mathbb{K}^{agg,\textrm{MxN}}[g] = \mathcal{H}_n(T_{agg},\mathbb{S}_{(N-M)},\mathbb{S}_{(N-M)}[g])*\mathbb{S}_{(N-M)}[g]\] + \item The {\tt merge} function takes $\mathbb{K}^{agg,\textrm{MxN}}$ as input, and the group key is\vspace{.175cm} + \[K^{grp,\textrm{MxN}} = \sum^{\textrm{size of }\mathbb{S}_{N-M}}_{g = 1} \mathbb{K}^{agg,\textrm{MxN}}[g]\] + \item Each participant $e$ overwrites each element $x$ in $\mathbb{S}^k_{e}$ with their aggregation private key\vspace{.175cm} + \[ \mathbb{S}^k_{e}[x] = \mathcal{H}_n(T_{agg},\mathbb{S}_{(N-M)},\mathbb{S}^k_{e}[x] G)*\mathbb{S}^k_{e}[x] \] +\end{enumerate} + +Note: If users want to have unequal signing power in a multisig, like 2 shares in a 3-of-4, they should use multiple starting key components instead of reusing the same one. + + + +\section{Key families} +\label{sec:general-key-families} + +Up to this point we have considered key aggregation between a simple group of signers. For example, Alice, Bob, and Carol each contributing key components to a 2-of-3 multisig address. + +Now imagine Alice wants to sign all transactions from that address, but doesn't want Bob and Carol to sign without her. In other words, (Alice + Bob) or (Alice + Carol) are acceptable, but not (Bob + Carol). + +We can achieve that scenario with two layers of key aggregation. First a 1-of-2 multisig aggregation $\mathbb{K}^{agg,{1\textrm{x}2}}_{BC}$ between Bob and Carol, then a 2-of-2 group key $K^{grp,{2\textrm{x}2}}$ between Alice and $\mathbb{K}^{agg,{1\textrm{x}2}}_{BC}$. Basically, a (2-of-([1-of-1] and [1-of-2])) multisig address. + +This implies access structures to signing rights can be fairly open-ended. + +\subsection{Family trees} + +We can diagram the (2-of-([1-of-1] and [1-of-2])) multisig address like this: +\begin{center} + \begin{forest} + forked edges, + for tree = {edge = {<-, > = triangle 60} + ,fork sep = 4.5 mm, + ,l sep = 8 mm + ,circle, draw + }, + where n children=0{tier=terminus}{}, + [$K^{grp,{2\textrm{x}2}}$ + [$K^{base}_A$] + [$\mathbb{K}^{agg,{1\textrm{x}2}}_{BC}$ + [$K^{base}_B$] + [$K^{base}_C$] + ] + ] + \end{forest} +\end{center} + +The keys $K^{base}_A,K^{base}_B,K^{base}_C$ are considered {\em root ancestors}, while $\mathbb{K}^{agg,{1\textrm{x}2}}_{BC}$ is the {\em child} of {\em parents} $K^{base}_B$ and $K^{base}_C$. Parents can have more than one child, though for conceptual clarity we consider each copy of a parent as distinct. This means there can be multiple root ancestors that are the same key. + +For example, in this 2-of-3 and 1-of-2 joined in a 2-of-2, Carol's key $K^{base}_C$ is used twice and displayed twice: +\begin{center} + \begin{forest} + forked edges, + for tree = {edge = {<-, > = triangle 60} + ,fork sep = 4.5 mm, + ,l sep = 8 mm + ,circle, draw + }, + where n children=0{tier=terminus}{}, + [$K^{grp,{2\textrm{x}2}}$ + [$\mathbb{K}^{agg,{2\textrm{x}3}}_{ABC}$ + [$K^{base}_A$] + [$K^{base}_B$] + [$K^{base}_C$] + ] + [$\mathbb{K}^{agg,{1\textrm{x}2}}_{CD}$ + [$K^{base}_C$] + [$K^{base}_D$] + ] + ] + \end{forest} +\end{center} + +Separate sets $\mathbb{S}$ are defined for each multisig sub-coalition. There are three premerge sets in the previous example: $\mathbb{S}^{\textrm{2x3}}_{ABC} = \{K^{sh,\textrm{2x3}}_{AB},K^{sh,\textrm{2x3}}_{BC},K^{sh,\textrm{2x3}}_{AC}\}$, $\mathbb{S}^{\textrm{1x2}}_{CD} = \{K^{sh,\textrm{1x2}}_{CD}\}$, and $\mathbb{S}^{\textrm{2x3}}_{final} = \{\mathbb{K}^{agg,{2\textrm{x}3}}_{ABC},\mathbb{K}^{agg,{1\textrm{x}2}}_{CD}\}$. + + +\subsection{Nesting multisig keys} +\label{subsec:nesting-multisig-keys} + +Suppose we have the following key family +\begin{center} + \begin{forest} + forked edges, + for tree = {edge = {<-, > = triangle 60} + ,fork sep = 4.5 mm, + ,l sep = 8 mm + ,circle, draw + }, + where n children=0{tier=terminus}{}, + [$K^{grp,{2\textrm{x}3}}$ + [$K^{grp,{2\textrm{x}3}}_{ABC}$ + [$K^{base}_A$] + [$K^{base}_B$] + [$K^{base}_C$] + ] + [$K^{base}_D$] + [$K^{base}_E$] + ] + \end{forest} +\end{center} + +If we merge the keys in $\mathbb{S}^{\textrm{2x3}}_{ABC}$ corresponding to the first 2-of-3, we run into an issue at the next level. Let's take just one shared secret, between $K^{grp,\textrm{2x3}}_{ABC}$ and $K^{base}_D$, to illustrate:\vspace{.175cm} +\[k_{ABC,D} = \mathcal{H}_n(k^{grp,\textrm{2x3}}_{ABC} K^{base}_D)\] + +Now, two people from ABC could easily contribute aggregation key components so the sub-coalition can compute +\[k^{grp,\textrm{2x3}}_{ABC} K^{base}_D = \sum k^{agg,\textrm{2x3}}_{ABC} K^{base}_D\] + +The problem is everyone from ABC can compute $k^{sh,\textrm{2x3}}_{ABC,D} = \mathcal{H}_n(k^{grp,\textrm{2x3}}_{ABC} K^{base}_D)$! If everyone from a lower-tier multisig knows all its private keys for a higher-tier multisig, then the lower-tier multisig might as well be 1-of-N. + +We get around this by not completely merging keys until the final child key. Instead, we just do {\tt premerge} for all keys output by low-tier multisigs. + +\subsubsection*{Solution for nesting} + +To use $\mathbb{K}^{agg,\textrm{MxN}}$ in a new multisig, we pass it around just like a normal key, with one change. Operations involving $\mathbb{K}^{agg,\textrm{MxN}}$ use each of its member keys, instead of the merged group key. For example, the public `key' of a shared secret between $\mathbb{K}^{agg,\textrm{2x3}}_x$ and $K^{base}_A$ would look like\vspace{.175cm} +\[\mathbb{K}^{sh,\textrm{1x2}}_{x,A} = \{ [\mathcal{H}_n(k^{base}_A \mathbb{K}^{agg,\textrm{2x3}}_x[1])*G], [\mathcal{H}_n(k^{base}_A \mathbb{K}^{agg,\textrm{2x3}}_x[2])*G], ...\}\] + +This way all members of $\mathbb{K}^{agg,\textrm{2x3}}_x$ only know shared secrets corresponding to their private keys from the lower-tier 2-of-3 multisig. An operation between a keyset of size two ${}^{2}\mathbb{K}_A$ and keyset of size three ${}^{3}\mathbb{K}_B$ would produce a keyset of size six ${}^{6}\mathbb{K}_{AB}$. We can generalize all keys in a key family as keysets, where single keys are denoted ${}^{1}\mathbb{K}$. Elements of a keyset are ordered according to some convention (i.e. smallest to largest numerically), and sets containing keysets (e.g. $\mathbb{S}$ sets) are ordered by the first element in each keyset, according to some convention.\\ + +We let the key sets propagate through the family structure, with each nested multisig group sending their {\tt premerge} aggregation set as the `base key' for the next level,\footnote{Note that {\tt premerge} needs to be done to the outputs of {\em all} nested multisigs, even when an N'-of-N' multisig is nested into an N-of-N, because the set $\mathbb{S}$ will change.} until the last child's aggregation set appears, at which point {\tt merge} is finally used.\\ + +Users should store their base private keys, the aggregation private keys for all levels of a multisig family structure, and the public keys for all levels. Doing so facilitates creating new structures, {\tt merging} nested multisigs, and collaborating with other signers to rebuild a structure if there is a problem. + + +\subsection{Implications for Monero} + +Each sub-coalition contributing to the final key needs to contribute components to Monero transactions (such as the opening values $\alpha G$), and so every sub-sub-coalition needs to contribute to its child sub-coalition. + +This means every root ancestor, even when there are multiple copies of the same key in the family structure, must contribute one root component to their child, and each child one component to its child and so on. We use simple sums at each level. + +For example, let's take this family +\begin{center} + \begin{forest} + forked edges, + for tree = {edge = {<-, > = triangle 60} + ,fork sep = 4.5 mm, + ,l sep = 8 mm + ,circle, draw + }, + where n children=0{tier=terminus}{}, + [${}^{1}\mathbb{K}^{grp,{2\textrm{x}2}}$ + [${}^{1}\mathbb{K}^{base}_A$] + [${}^{2}\mathbb{K}^{agg,{2\textrm{x}2}}_{AB}$ + [${}^{1}\mathbb{K}^{base}_A$] + [${}^{1}\mathbb{K}^{base}_B$] + ] + ] + \end{forest} +\end{center} + +Say they need to compute some group value $x$ for a signature. Root ancestors contribute: $x_{A,1}$, $x_{A,2}$, $x_B$. The total is $x = x_{A,1} + x_{A,2} + x_B$. + +There are currently no implementations of nested multisig in Monero. \ No newline at end of file diff --git a/translations/es/content/txKnowledgeProofs.tex b/translations/es/content/txKnowledgeProofs.tex new file mode 100755 index 0000000..06d945a --- /dev/null +++ b/translations/es/content/txKnowledgeProofs.tex @@ -0,0 +1,314 @@ +\chapter{Monero Transaction-Related Knowledge Proofs} +\label{chapter:tx-knowledge-proofs} +%original draft by Sarang Noether, Ph.D. + +\iffalse +https://github.com/monero-project/monero/pull/6329/files + +https://monero.stackexchange.com/questions/8122/what-is-the-spendproofv1-or-outproofv1-in-the-details-of-a-sent-transa + +https://monero.stackexchange.com/questions/9991/how-does-the-get-reserve-proof-command-work + +https://github.com/monero-project/research-lab/issues/68 +\fi + +Monero is a currency, and like any currency its uses are complex. From corporate accounting, to market exchange, to legal arbitration, different interested parties may want to know detailed information about transactions made. + +How can you know for sure that money you received came from a specific person? Or prove that you did in fact send a certain output or transaction to someone despite claims to the contrary? Senders and recipients in the Monero public ledger are ambiguous. How can you prove you have a certain amount of money, without compromising your private keys? Amounts in Monero are completely hidden from observers. + +We consider several types of transaction assertions, a few of which are implemented in Monero and available with built-in wallet tools. We also outline a framework for auditing the full balance owned by a person or organization, that doesn't require leaking information about future transactions they might make. + + + +\section{Transaction proofs in Monero} +\label{sec:proofs-monero-proofs} + +Monero transaction proofs are in the process of being updated \cite{sarang-txproofs-updates-issue}. The currently implemented proofs are all `version 1', and don't include domain separation. We describe only the most advanced proofs, whether they be currently implemented, slated for implementation in future releases \cite{sarang-txproofs-v2-update-pr}, or hypothetical proofs that may or may not get implemented (Sections \ref{subsec:proofs-owned-output-spent-unspentproof} \cite{unspent-proof-issue-68}, and \ref{subsec:proofs-address-subaddress-correspond-subaddressproof}). + + +\subsection{Multi-base Monero transaction proofs} +\label{subsec:proofs-multi-base-monero} + +There are a few details to be aware of going forward. Most Monero transaction proofs involve multi-base proofs (recall Section \ref{sec:proofs-discrete-logarithm-multiple-bases}). Wherever relevant, the domain separator is $T_{txprf2} = \mathcal{H}_n(``\textrm{TXPROOF\_V2}")$.\footnote{Just like in Section \ref{sec:CLSAG}, hash functions should be domain separated by prefixing them with tags. The current Monero transaction proofs implementation has no domain separation, so all the tags in this chapter are in features {\em not} yet implemented.} The message being signed\marginnote{src/wallet/ wallet2.cpp {\tt get\_tx\_ proof()}} is usually (unless otherwise specified) $\mathfrak{m} = \mathcal{H}_n(\texttt{tx\_hash, \texttt{message}})$, where {\tt tx\_hash} is the relevant transaction's ID (Section \ref{subsec:transaction-id}), and {\tt message} is an optional message that provers or third parties can provide to make sure the prover actually makes a proof and hasn't stolen it. + +Proofs are encoded in base-58, a binary-to-text encoding scheme first introduced for Bitcoin \cite{base-58-encoding}. Verifying these proofs always involves first decoding them from base-58 back to binary. Note that verifiers also need access to the blockchain, so they can use transaction ID references to get information like one-time addresses.\footnote{Transaction IDs are usually communicated separately from proofs.} +\\ + +The structure of key prefixing in proofs is somewhat lopsided, due in part to accumulating updates that haven't reorganized it. Challenges for 2-base `version 2' proofs are assembled with this format, where if `base key 1' is $G$ then its position in the challenge is filled with 32 zero bytes,\vspace{.175cm} +\[c = \mathcal{H}_n(\mathfrak{m}\textrm{, public key 2, proof part 1, proof part 2, $T_{txprf2}$, public key 1, base key 2, base key 1})\] + + +\subsection{Prove creation of a transaction input ({\tt SpendProofV1})} +\label{subsec:proofs-input-creation-spendproof} + +Suppose we made a transaction, and want to prove it. Clearly, by remaking a transaction input's signature on a new message, any verifier would have no choice but to conclude we made the original. Remaking {\em all} of a transaction's inputs' signatures means we must have made the entire transaction (recall Section \ref{full-signature}), or at the very least fully funded it.\footnote{As we will see in Chapter \ref{chapter:txtangle}, someone who made one input signature didn't necessarily make all input signatures.} + +A so-called `SpendProof'\marginnote{src/wallet/ wallet2.cpp {\tt get\_spend\_ proof()}} contains remade signatures for all of a transaction's inputs. Importantly, SpendProof ring signatures re-use the original ring members to avoid identifying the true signer via ring intersections. + +SpendProofs are implemented in Monero, and to encode one for transmission to verifiers, the prover concatenates the prefix string ``{\tt SpendProofV1}" with the list of signatures. Note that the prefix string is not in base-58 and doesn't need to be encoded/decoded, since its purpose is human readability.%what about the message signed? + +\subsubsection*{The SpendProof} + +SpendProofs unexpectedly don't use MLSAGs, but rather Monero's original ring signature scheme \marginnote{src/crypto/ crypto.cpp {\tt generate\_ ring\_signa- ture()}} that was used in the very first transaction protocol (pre-RingCT) \cite{cryptoNoteWhitePaper}. + +\begin{enumerate} + \item Calculate key image \(\tilde{K} = k^o_\pi \mathcal{H}_p(K^o_\pi)\). + + \item Generate random number \(\alpha \in_R \mathbb{Z}_l\) and random numbers \(c_i, r_i \in_R \mathbb{Z}_l\) for \(i \in \{1, 2, ..., n\}\) but excluding \(i = \pi\). + + \item Compute + \[c_{tot} = \mathcal{H}_n(\mathfrak{m},[r_1 G + c_1 K^o_1],[r_1 \mathcal{H}_p(K^o_1) + c_1 \tilde{K}],...,[\alpha G],[\alpha \mathcal{H}_p(K^o_{\pi})],...,\textrm{etc.})\] + + \item Define the real challenge + \[c_{\pi} = c_{tot} - \sum^{n}_{i=1,i\neq \pi} c_i\] + + \item Define \(r_{\pi} = \alpha - c_{\pi}*k^o_{\pi} \pmod l\). +\end{enumerate} + +The signature is $\sigma = (c_1, r_1,c_2,r_2,...,c_n,r_n)$. + +\subsubsection*{Verification} + +To verify\marginnote{src/wallet/ wallet2.cpp {\tt check\_spe- nd\_proof()}} a SpendProof on a given transaction, the verifier confirms that all ring signatures are valid using information found in the relevant reference transaction (e.g. key images, and output offsets for getting one-time addresses from other transactions). + +\begin{enumerate} + \item Compute + \[c_{tot} = \mathcal{H}_n(\mathfrak{m},[r_1 G + c_1 K^o_1],[r_1 \mathcal{H}_p(K^o_1) + c_1 \tilde{K}],...,[r_n G + c_n K^o_n],[r_n \mathcal{H}_p(K^o_n) + c_n \tilde{K}])\] + + \item Check that + \[c_{tot} \stackrel{?}{=} \sum^{n}_{i=1} c_i\] +\end{enumerate} + +\subsubsection*{Why it works} + +Note how this scheme is the same as bLSAG (Section \ref{blsag_note}) when there is only one ring member. To add a fake member, instead of passing the challenge $c_{\pi+1}$ into a new challenge hash, the member gets added into the original hash. Since the following equation\vspace{.175cm} +\[c_{s} = c_{tot} - \sum^{n}_{i=1,i\neq s} c_i\] + +trivially holds for any index $s$, a verifier will have no way to identify the real challenge. Moreover, without knowledge of $k^o_{\pi}$ the prover would never have been able to define $r_{\pi}$ properly (except with negligible probability). + + +\subsection{Prove creation of a transaction output ({\tt OutProofV2})} +\label{subsec:proofs-output-creator-outproof} + +Now suppose we sent someone money (an output) and want to prove it. Transaction outputs contain at heart three components: the recipient's address, the amount sent, and the transaction private key. Amounts are encoded, so we only really need the address and transaction private key to get started. Anyone who deletes or loses their transaction private key will be unable to make an OutProof, so in that sense OutProofs are the least reliable of all Monero transaction proofs.\footnote{We can think of an `OutProof' as showing an output is `outgoing' from the prover. The corresponding `InProofs' (Section \ref{subsec:proofs-output-ownership-inproof}) show outputs that are `incoming' to the prover's address.} + +Our task here is to show the one-time address was made from the recipient's address, and allow verifiers to reconstruct the output commitment. We do so by providing the sender-receiver shared secret $rK^v$, then proving we created it and that it corresponds with the transaction public key and recipient's address by signing a 2-base signature (Section \ref{sec:proofs-discrete-logarithm-multiple-bases}) on the base keys $G$ and $K^v$. Verifiers can use the shared secret to check the recipient\marginnote{src/wallet/ wallet2.cpp {\tt check\_tx\_ proof()}} (Section \ref{sec:one-time-addresses}), decode the amount (Section \ref{sec:pedersen_monero}), and reconstruct the output commitment (Section \ref{sec:pedersen_monero}). We provide details for both normal addresses and subaddresses. + +\subsubsection*{The OutProof} + +To generate\marginnote{src/crypto/ crypto.cpp {\tt generate\_ tx\_proof()}} a proof for an output directed to an address $(K^{v},K^{s})$ or subaddress $(K^{v,i},K^{s,i})$, with transaction private key $r$, where the sender-receiver shared secret is $rK^v$, recall that the transaction public key stored in transaction data is either $rG$ or $rK^{s,i}$ depending on whether or not the recipient is a subaddress (Section \ref{sec:subaddresses}). + +\begin{enumerate} + \item Generate random number $\alpha \in_R \mathbb{Z}_l$, and compute + \begin{enumerate} + \item {\em Normal address}: $\alpha G$ and $\alpha K^v$ + \item {\em Subaddress}: $\alpha K^{s,i}$ and $\alpha K^{v,i}$ + \end{enumerate}{} + \item Calculate the challenge + \begin{enumerate} + \item {\em Normal address}:\footnote{Here the `0' value is a 32-byte encoding of zero bytes.} + \[c = \mathcal{H}_n(\mathfrak{m},[rK^v], [\alpha G], [\alpha K^v], [T_{txprf2}], [rG], [K^v], [0])\] + \item {\em Subaddress}: + \[c = \mathcal{H}_n(\mathfrak{m},[rK^{v,i}], [\alpha K^{s,i}], [\alpha K^{v,i}], [T_{txprf2}], [rK^{s,i}], [K^{v,i}], [K^{s,i}])\] + \end{enumerate}{} + \item Define the response\footnote{Due to the limited number of available symbols, we unfortunately used $r$ for both responses and the transaction private key. Superscript `resp' for `response' will be used to differentiate the two when necessary.} $r^{resp} = \alpha - c*r$. + \item The signature is $\sigma^{outproof} = (c, r^{resp})$. +\end{enumerate}{} + +A prover\marginnote{src/wallet/ wallet2.cpp {\tt get\_tx\_ proof()}} can generate a bunch of OutProofs, and send them all together to a verifier. He concatenates prefix string ``{\tt OutProofV2}" with a list of proofs, where each item (encoded in base-58) consists of the sender-receiver shared secret $r K^v$ (or $r K^{v,i}$ for a subaddress), and its corresponding $\sigma^{outproof}$. We assume the verifier knows the appropriate address for each proof. + +\subsubsection*{Verification} + +\begin{enumerate} + \item Calculate the challenge\marginnote{src/crypto/ crypto.cpp {\tt check\_tx\_ proof()}} + \begin{enumerate} + \item {\em Normal address}:\vspace{.145cm} + \[c' = \mathcal{H}_n(\mathfrak{m},[rK^v], [r^{resp} G + c*r G], [r^{resp} K^v + c*r K^v], [T_{txprf2}], [rG], [K^v], [0])\] + \item {\em Subaddress}:\vspace{.16cm} + \[c' = \mathcal{H}_n(\mathfrak{m},[rK^{v,i}], [r^{resp} K^{s,i} + c*r K^{s,i}], [r^{resp} K^{v,i} + c*r K^{v,i}], [T_{txprf2}], [rK^{s,i}], [K^{v,i}], [K^{s,i}])\] + \end{enumerate}{} + \item If $c = c'$ then the prover knows $r$, and $rK^v$ is legitimately a shared secret between $r G$ and $K^v$ (except with negligible probability). + \item The\marginnote{src/wallet/ wallet2.cpp {\tt check\_tx\_ key\_hel- per()}} verifier should check the recipient's address provided can be used to make a one-time address from the relevant transaction (it's the same computation for normal addresses and subaddresses) + \[K^s \stackrel{?}{=} K^o_t - \mathcal{H}_n(r K^v,t)\] + \item They should also decode the output amount $b_t$, compute the output mask $y_t$, and try to reconstruct the corresponding output commitment\footnote{A valid OutProof signature doesn't necessarily mean the recipient considered is the real recipient. A malicious prover could generate a random view key $K'^v$, compute $K'^s = K^o - \mathcal{H}_n(rK'^v,t)*G$, and provide $(K'^v,K'^s)$ as the nominal recipient. By recalculating the output commitment, verifiers can be more confident the recipient address in question is legitimate. However, a prover and recipient could collaborate to encode the output commitment using $K'^v$, while the one-time address uses $(K^v,K^s)$. Since the recipient would need to know the private key $k'^v$ (assuming the output amount is still meant to be spendable), there is questionable utility to that level of deception. Why wouldn't the recipient just use $(K'^v,K'^s)$ (or some other single-use address) for the entire output? Since the computation of $C^b_t$ is related to the recipient, we consider the described OutProof verification process adequate. In other words, the prover can't use it to deceive verifiers without coordinating with the recipient.}\vspace{.175cm} + \[C^b_t \stackrel{?}{=} y_t G + b_t H\] +\end{enumerate}{} + + +\subsection{Prove ownership of an output ({\tt InProofV2})} +\label{subsec:proofs-output-ownership-inproof} + +An OutProof shows the prover sent an output to an address, while an InProof shows an output was received to a certain address. It is essentially the other `side' of the sender-receiver shared secret $r K^v$. This time the prover proves knowledge of $k^v$ in $K^v$, and that in combination with the transaction public key $r G$ the shared secret $k^v*r G$ appears. + +Once a verifier has $r K^v$, they can check if the corresponding one-time address is owned by the prover's address with\marginnote{src/wallet/ wallet2.cpp {\tt check\_tx\_ proof()}} $K^o - \mathcal{H}_n(k^v*rG,t)*G \stackrel{?}{=} K^s$ (Section \ref{sec:multi_out_transactions}). By making an InProof for all transaction public keys on the blockchain, a prover will reveal all his owned outputs. + +Giving the view key directly to a verifier would have the same effect, but once they have that key the verifier would be able to identify ownership of outputs to be created in the future. With InProofs the prover is able to retain control of his private keys, at the cost of the time it takes to prove (and then verify) each output is owned or unowned. + +\subsubsection*{The InProof} + +An InProof is constructed the same way as an OutProof\marginnote{src/crypto/ crypto.cpp {\tt generate\_ tx\_proof()}}, except the base keys are now $\mathcal{J} = \{G, r G\}$, the public keys are $\mathcal{K} = \{K^v, r K^{v}\}$, and the signing key is $k^v$ instead of $r$. We will show just the verification step to clarify our meaning. Note that the order of key prefixing changes ($r G$ and $K^v$ swap places) to coincide with the different role each key has. + +A multitude of InProofs, related to many outputs owned by the same address, can be sent together to the verifier.\marginnote{src/wallet/ wallet2.cpp {\tt get\_tx\_ proof()}} They are prefixed with the string ``{\tt InProofV2}", and each item (encoded in base-58) contains the sender-receiver shared secret $r K^v$ (or $r K^{v,i}$), and its corresponding $\sigma^{inproof}$. + +\subsubsection*{Verification} + +\begin{enumerate} + \item Calculate the challenge\marginnote{src/crypto/ crypto.cpp {\tt check\_tx\_ proof()}} + \begin{enumerate} + \item {\em Normal address}:\vspace{.145cm} + \[c' = \mathcal{H}_n(\mathfrak{m},[rK^v], [r^{resp} G + c*K^v], [r^{resp}*r G + c*k^v*r G], [T_{txprf2}], [K^v], [rG], [0])\] + \item {\em Subaddress}:\vspace{.16cm} + \[c' = \mathcal{H}_n(\mathfrak{m},[rK^{v,i}], [r^{resp} K^{s,i} + c*K^{v,i}], [r^{resp}*r K^{s,i} + c*k^v*r K^{s,i}], [T_{txprf2}], [K^{v,i}], [r K^{s,i}], [K^{s,i}])\] + \end{enumerate}{} + \item If $c = c'$ then the prover knows $k^v$, and $k^v*r G$ is legitimately a shared secret between $K^v$ and $r G$ (except with negligible probability). +\end{enumerate}{} + +\subsubsection*{Prove `full' ownership with the one-time address key} + +While an InProof shows a one-time address was constructed with a specific address (except with negligible probability), it doesn't necessarily mean the prover can {\em spend} that output. Only those who can spend an output actually own it. + +Proving ownership, once an InProof is complete, is as simple as signing a message with the spend key.\footnote{The ability to provide such a signature directly does not seem to be available in Monero, although as we will see ReserveProofs (Section \ref{subsec:proofs-minimum-balance-reserveproof}) do include them.} + + +\subsection{Prove an owned output was not spent in a transaction (UnspentProof)} +\label{subsec:proofs-owned-output-spent-unspentproof} + +It would seem like proving an output is spent or unspent is as simple as recreating its key image with a multi-base proof on $\mathcal{J} = \{G,\mathcal{H}_p(K^o)\}$ and $\mathcal{K} = \{K^o,\tilde{K}\}$. While this does obviously work, verifiers must learn the key image, which also reveals when an unspent output is spent {\em in the future}. + +It turns out we can prove an output wasn't spent in a specific transaction without revealing the key image. Moreover, we can prove it is currently unspent {\em full stop}, by extending this UnspentProof \cite{unspent-proof-issue-68} to `all the transactions where it was included as a ring member'.\footnote{UnspentProofs have not been implemented in Monero.} + +More specifically, our UnspentProof says that a given key image from a transaction on the blockchain does, or does not, correspond with a specific one-time address from its corresponding ring. Incidentally, as we will see, UnspentProofs go hand-in-hand with InProofs. + +\subsubsection*{Setting up an UnspentProof} + +The verifier of an UnspentProof must know $r K^v$, the sender-receiver shared secret for a given owned output with one-time address $K^o$ and transaction public key $r G$. He either knows the view key $k^v$, which allowed him to calculate $k^v*r G$ and check $K^o - \mathcal{H}_n(k^v*rG,t)*G \stackrel{?}{=} K^s$ so he knows the output being tested belongs to the prover (recall Section \ref{sec:one-time-addresses}), or the prover provided $r K^v$. This is where InProofs come in, since with an InProof the verifier can be assured $r K^v$ legitimately came from the prover's view key, and corresponds with an owned output, without learning the private view key. + +Before verifying an UnspentProof, the verifier will learn the key image to be tested $\tilde{K}_?$, and checks that its corresponding ring includes the prover's owned output's one-time address $K^o$. He then calculates the partial `spend' image $\tilde{K}^s_?$.\vspace{.175cm} +\[\tilde{K}^s_? = \tilde{K}_? - \mathcal{H}_n(r K^v,t)*\mathcal{H}_p(K^o)\] + +If the tested key image was created from $K^o$ then the resultant point will be $\tilde{K}^s_? = k^s*\mathcal{H}_p(K^o)$. + +\subsubsection*{The UnspentProof} + +Our prover creates two multi-base proofs (recall Section \ref{sec:proofs-discrete-logarithm-multiple-bases}). His address, which owns the output in question, is $(K^v, K^s)$ or $(K^{v,i}, K^{s,i})$.\footnote{UnspentProofs are made the same way for subaddresses and normal addresses. The full spend key of a subaddress is required, e.g. $k^{s,i} = k^s + \mathcal{H}_n(k^v,i)$ (Section \ref{sec:subaddresses}).} + +\begin{enumerate} + \item A 3-base proof, where the signing key is $k^s$, and\vspace{.175cm} + \begin{align*} + \mathcal{J}^{unspent}_3 &= \{[G], [K^s], [\tilde{K}^s_?]\}\\ + \mathcal{K}^{unspent}_3 &= \{[K^s], [k^s*K^s], [k^s*\tilde{K}^s_?]\} + \end{align*}{} + \item A 2-base proof, where the signing key is $k^s*k^s$, and\vspace{.175cm} + \begin{align*} + \mathcal{J}^{unspent}_2 &= \{[G], [\mathcal{H}_p(K^o)]\}\\ + \mathcal{K}^{unspent}_2 &= \{[k^s*K^s], [k^s*k^s*\mathcal{H}_p(K^o)]\} + \end{align*}{} +\end{enumerate}{} + +Along with proofs $\sigma^{unspent}_3$ and $\sigma^{unspent}_2$, the prover makes sure to communicate the public keys $k^s*K^s$, $k^s*\tilde{K}^s_?$, and $k^s*k^s*\mathcal{H}_p(K^o)$. + +\subsubsection*{Verification} + +\begin{enumerate} + \item Confirm $\sigma^{unspent}_3$ and $\sigma^{unspent}_2$ are legitimate. + \item Make sure the same public key $k^s*K^s$ was used in both proofs. + \item Check whether $k^s*\tilde{K}^s_?$ and $k^s*k^s*\mathcal{H}_p(K^o)$ are the same. If they are, the output is spent, and if not it is unspent (except with negligible probability). +\end{enumerate}{} + +\subsubsection*{Why it works} + +This seemingly roundabout approach prevents the verifier from learning $k^s*H_p(K^o)$ for an unspent output, which he could use in combination with $r K^v$ to compute its real key image, while leaving him confident the tested key image doesn't correspond to that output. + +Proof $\sigma^{unspent}_2$ can be reused for any number of UnspentProofs involving the same output, although if it actually was spent then only one is really necessary (i.e. UnspentProofs can also be used to demonstrate an output is spent). Performing UnspentProofs on all ring signatures where a given unspent output was referenced should not be computationally expensive. An output is only likely, over time, to be included as decoys in on the order of 11 (current ring size) different rings. + + +\subsection{Prove an address has a minimum unspent balance ({\tt ReserveProofV2})} +\label{subsec:proofs-minimum-balance-reserveproof} + +Despite the privacy leak of revealing an output's key image when it isn't spent yet, it's still a somewhat useful method and was implemented in Monero \cite{reserveproofs-pull-request-3027} before UnspentProofs were invented \cite{unspent-proof-issue-68}. Monero's so-called `ReserveProof'\marginnote{src/wallet/ wallet2.cpp {\tt get\_rese- rve\_proof()}} is used to prove an address owns a minimum amount of money by creating key images for some unspent outputs. + +More specifically, given a minimum balance, the prover finds enough unspent outputs to cover it, demonstrates ownership with InProofs, makes key images for them and proves they are legitimately based on those outputs with 2-base proofs (using a different key prefixing format), and then proves knowledge of the private spend keys used with normal Schnorr signatures (there may be more than one if some outputs are owned by different subaddresses). A verifier can check that the key images have not appeared on the blockchain, and hence their outputs must be unspent. + +\subsubsection*{The ReserveProof}%get_reserve_proof() wallet2.cpp + +All the sub-proofs within a ReserveProof sign a different message than other proofs (e.g. OutProofs, InProofs, or SpendProofs). This time it is $\mathfrak{m} = \mathcal{H}_n(\texttt{message}, \texttt{address}, \tilde{K}^o_1, ..., \tilde{K}^o_n)$, where {\tt address} is the encoded form (see \cite{luigi-address}) of the prover's normal address $(K^v, K^s)$, and the key images correspond with unspent outputs to be included in the proof. + +\begin{enumerate} + \item Each output has an InProof, which shows the prover's address (or one of his subaddresses) owns the output. + \item Each output's key image is signed with a 2-base proof\marginnote{src/crypto/ crypto.cpp {\tt generate\_ ring\_signa- ture()}}, where the challenge is formatted like this%generate_ring_signature() + \[c = \mathcal{H}_n(\mathfrak{m}, [r G + c*K^o], [r \mathcal{H}_p(K^o) + c*\tilde{K}])\] + \item Each address (and subaddress) that owns at least one output has a normal Schnorr signature (Section \ref{sec:signing-messages}), and the challenge looks like (it's the same for normal addresses and subaddresses)\marginnote{src/crypto/ crypto.cpp {\tt generate\_ signature()}} + \[c = \mathcal{H}_n(\mathfrak{m}, K^{s,i}, [r G + c*K^{s,i}])\] +\end{enumerate}{} + +To send a ReserveProof to someone else\marginnote{src/wallet/ wallet2.cpp {\tt get\_rese- rve\_proof()}}[.3cm], the prover concatenates prefix string ``{\tt ReserveProofV2}" with two lists encoded in base-58 (e.g. ``{\tt ReserveProofV2}, list 1, list 2"). Each item in list 1 is related to a specific output and contains its transaction hash (Section \ref{subsec:transaction-id}), output index in that transaction (Section \ref{sec:multi_out_transactions}), the relevant shared secret $r K^v$, its key image, its InProof $\sigma^{inproof}$, and its key image proof. List 2 items are the addresses that own those outputs along with their Schnorr signatures. + +%in encoded data there are two lists of items, first list is per output [tx_hash, owned output's index, the shared secret r K^v, its key image, a \sigma^{inproof}, and a key image proof], second list is [subaddress, subaddress proof] +%key image proof uses generate_ring_signature() on message m (InProof also uses this message, different from otherwise), basically a 1-member ring sig +%subaddress proofs (basic schnorr signatures) includes a proof for main spend key if necessary! so ReserveProof not only reveals an unspent balance, but also means the prover fully owns them; however, this does not prove the subaddresses correspond with the original address + +\subsubsection*{Verification} + +\begin{enumerate} + \item Check the ReserveProof key images have not appeared in the blockchain.\marginnote{src/wallet/ wallet2.cpp {\tt check\_rese- rve\_proof()}} + \item Verify the InProof for each output, and that one of the provided addresses owns each one. + \item Verify the 2-base key image signatures. + \item Use the sender-receiver shared secrets to decode the output amounts (Section \ref{sec:pedersen_monero}). + \item Check each address's signature. +\end{enumerate}{} + +If everything is legitimate, then the prover must own, unspent, at least the total amount contained in the ReserveProof's outputs (except with negligible probability).\footnote{ReserveProofs, while demonstrating full ownership of funds, do not include proofs that given subaddresses actually correspond with the prover's normal address.} + + + +\section{Monero audit framework} +\label{sec:proofs-monero-audit-framework} + +In the USA most companies undergo yearly audits of their financial statements \cite{investopedia-audits}, which include the income statement, balance sheet, and cash flow statement. Of these the former two involve in large part a company's internal record-keeping, while the last involves every transaction that affects how much money the company currently has. Cryptocurrencies are digital cash, so any audit of a cryptocurrency user's cash flow statement must relate to transactions stored on the blockchain. + +The first task of an audited person is to identify all the outputs they currently own (spent and unspent). This can be one with InProofs using all of their addresses. A large business may have a multitude of subaddresses, especially retailers operating in online marketplaces (see Chapter +\ref{chapter:escrowed-market}). Creating InProofs on all transactions for every single subaddress may result in enormous computational and storage requirements for both provers and verifiers. + +Instead, we can make InProofs for just the prover's normal addresses (on all transactions). The auditor uses those sender-receiver shared secrets to check if any outputs are owned by the prover's main address or its related subaddresses. Recalling Section \ref{sec:subaddresses}, a user's view key is enough to identify all outputs owned by an address's subaddresses. + +To ensure the prover is not hoodwinking an auditor by hiding the normal address for some of his subaddresses, he also must prove all subaddresses correspond with one of his known normal addresses. + + +\subsection{Prove an address and subaddress correspond (SubaddressProof)} +\label{subsec:proofs-address-subaddress-correspond-subaddressproof} + +SubaddressProofs show that a normal address's view key can be used to identify outputs owned by a given subaddress.\footnote{SubaddressProofs have not been implemented in Monero.} + +\subsubsection*{The SubaddressProof} +%subaddress proof: base keys [G, K^{s,i}] public keys [K^v, K^{v,i}] signing key [k^v] +SubaddressProofs can be made in much the same way as OutProofs and InProofs. Here the base keys are $\mathcal{J} = \{G, K^{s,i}\}$, public keys are $\mathcal{K} = \{K^v, K^{v,i}\}$, and signing key is $k^v$. Again, we show just the verification step to clarify our meaning. + +\subsubsection*{Verification} + +A verifier knows the prover's address $(K^v, K^s)$, subaddress $(K^{v,i}, K^{s,i})$, and has the SubaddressProof $\sigma^{subproof} = (c,r)$. + +\begin{enumerate} + \item Calculate the challenge\vspace{.175cm} + \[c' = \mathcal{H}_n(\mathfrak{m},[K^{v,i}], [r G + c*K^v], [r K^{s,i} + c*K^{v,i}], [T_{txprf2}], [K^v], [K^{s,i}], [0])\] + \item If $c = c'$ then the prover knows $k^v$ for $K^v$, and $K^{s,i}$ in combination with that view key makes $K^{v,i}$ (except with negligible probability). +\end{enumerate}{} + + +\subsection{The audit framework} +\label{subsec:audit-framework} + +Now we are prepared to learn as much as possible about a person's transaction history.\footnote{This audit framework is not completely available in Monero. SubaddressProofs and UnspentProofs are not implemented, InProofs are not prepared for the optimization related to subaddresses that we explained, and there is no real structure to easily get or organize all the necessary information for both provers and verifiers.} + +\begin{enumerate} + \item The prover gathers a list of all his accounts, where each account consists of a normal address and various subaddresses. He makes SubaddressProofs for all subaddresses. Much like ReserveProofs, he also makes a signature with the spend key of each address and subaddress, demonstrating he has spend-rights over all outputs owned by those addresses. + \item The prover generates, for each of his normal addresses, InProofs on all transactions (e.g. all transaction public keys) in the blockchain. This reveals to the auditor all outputs owned by the prover's addresses since they can check all one-time addresses with the sender-receiver shared secrets. They can be sure outputs owned by subaddresses will be identified, because of the SubaddressProofs.\footnote{This step can also be completed by providing the private view keys, although it has obvious privacy implications.} + \item The prover generates, for each of his owned outputs, UnspentProofs on all transaction inputs where they appear as ring members. Now the auditor will know the prover's balance, and can further investigate spent outputs.\footnote{Alternatively, he could make ReserveProofs for all owned outputs. Again, revealing the key images of unspent outputs has obvious privacy implications.} + \item {\em Optional}: The prover generates, for each transaction where he spent an output, an OutProof to show the auditor the recipient and amount. This step is only possible for transactions where the prover saved the transaction private key(s). +\end{enumerate}{} + +Importantly, a prover has no way to show the origin of funds directly. His only recourse is to request a set of proofs from people sending him money. + +\begin{enumerate} + \item For a transaction sending money to the prover, its author makes a SpendProof demonstrating they actually sent it. + \item The prover's funder also makes a signature with an identifying public key, for example the spend key of their normal address. Both the SpendProof and this signature should sign a message containing that identifying public key, to ensure the SpendProof wasn't stolen or in fact made by someone else. +\end{enumerate}{} \ No newline at end of file diff --git a/translations/es/content/txTangle.tex b/translations/es/content/txTangle.tex new file mode 100755 index 0000000..b7d7655 --- /dev/null +++ b/translations/es/content/txTangle.tex @@ -0,0 +1,124 @@ +\chapter{Joint Monero Transactions (TxTangle)} +\label{chapter:txtangle} + +There are a number of unavoidable transaction graph heuristics created by the nature of different entities and scenarios. In particular, the behavior of miners, pools (Section 5.1 of \cite{AnalysisOfLinkability}), escrowed marketplaces, and exchanges have clear patterns open to analysis even within Monero's ring signature-based protocol. + +We describe here TxTangle, analogous to Bitcoin's CoinJoin \cite{coinjoin-wiki}, one method to confuse those heuristics.\footnote{This chapter constitutes the proposal for a joint transaction protocol. No such protocol has been implemented as of this writing. A previous proposal, named MoJoin and created by pseudonymous co-author Monero Research Lab (MRL) researcher Sarang Noether, required a trusted dealer to function. Such a dealer seems to conflict with the Monero project's basic commitment to privacy and fungibility, and hence MoJoin was not pursued further.} In essence, several transactions are squashed into one transaction, making the behavior patterns of each participant blend together. + +To accomplish that obfuscation, it must be unreasonably difficult for observers to use the information contained in a joint transaction to group inputs and outputs, and associate them with individual participants, nor know how many participants there actually were.\footnote{Since in Bitcoin amounts are clearly visible, it is often possible to group CoinJoin inputs and outputs based on amount sums. \cite{coinjoin-sudoku}} Moreover, even the participants themselves should not be aware of the number of participants, or be able to group the inputs and outputs of other participants unless they control all but one participant's grouping.\footnote{Maliciously polluting joint transactions is a potential attack on this method, first identified for CoinJoin. \cite{coinjoin-pollution}} Finally, it should be possible to construct joint transactions without relying on a central authority \cite{exa-blockchain-analysis}. Fortunately, all these requirements can be achieved in Monero. + + + +\section{Building joint transactions} +\label{sec:building-txtangle} + +In a normal transaction, inputs and outputs are tied together using the proof that amounts balance. From Section \ref{sec:commitments-and-fees}, the sum of pseudo output commitments equals the sum of output commitments (plus the fee commitment). +\[\sum_j C'^a_{j} - (\sum_t C^b_{t} + f H) = 0\] + +A trivial joint transaction could take all the content of multiple transactions, and stick them in one. MLSAG messages would sign all the sub-transactions' data, and amount balancing would quite obviously work (0 + 0 + 0 = 0).\footnote{Since Bulletproofs-style range proofs are actually aggregated into one (Section \ref{sec:range_proofs}), participants would have to collaborate to some extent even in the trivial case.} However, input and output groupings could just as trivially be identified based on testing if input/output subsets have balancing amounts.\footnote{Participants could try to divide up the fee in a fancy manner to confuse observers, but it would fail in the face of brute force since fees are not that large (around 32 bits or less).} + +We can easily get around this by computing shared secrets between each pair of participants, then adding these offsets to their pseudo output commitments' masks (Section \ref{sec:ringct-introduction}). In each pair, one participant adds the shared secret to one of his pseudo output commitments, and the other participant subtracts it from one of {\em his} pseudo commitments. When summed together, the secrets cancel out, and since each pair of participants has a shared secret the amount balance only appears after all commitments are combined.\footnote{We offset the pseudo output commitments instead of output commitments since output commitment masks are constructed from the recipient's address (Section \ref{sec:pedersen_monero}).} + +Shared secrets may hide input/output groupings in the immediate sense, but participants must learn about all the inputs and outputs somehow, and the easiest way is if they each communicate their individual input/output groupings. Clearly this violates the initial premise, and in any case implies participants know the number of participants. + + +\subsection{$n$-way communication channel} +\label{subsec:n-way-channel} + +The maximum number of participants to a TxTangle is either the number of outputs or inputs (whichever is lower). We model that by each real participant pretending to be a different person for each output he is sending. This is primarily for the purpose of setting up a group communication channel with other would-be participants, without revealing how many participants there are. + +Imagine $n$ ($2 \leq n \leq 16$, although at least 3 is recommended)\footnote{Currently, a transaction may have at most 16 outputs.} supposedly unrelated people gather at apparently random intervals in a chatroom, scheduled to open at time $t_0$ and close at $t_1$ (only 16 people can be in a chatroom at once, and the chatroom has conditions like fee priority, base fee per byte [to simplify consensus around the current median and block reward], and range of acceptable transaction types since e.g. currently transactions from the beginning of Monero can't be directly spent in a RingCT transaction \cite{pre-ringct-outputs-like-coinbase-research-issue-59}). At $t_1$ all mock-members signal desire to proceed by publishing a public key, and the room is converted into an $n$-way communication channel by constructing a shared secret amongst all the mock-members.\footnote{The multisig method from Section \ref{sec:m-of-n} is one way, extending M-of-N all the way to 1-of-N.} This shared secret is used to encrypt message contents, while mock-members sign input-related messages using SAG signatures (Section \ref{SAG_section}) so it's never clear who sent a given message, and output-related messages with a bLSAG (Section \ref{blsag_note}) on the set of mock-member public keys so actual outputs are dissociated from mock-members.\footnote{Each separate set of TxTangle bLSAGs should use the same key images, since everything related to a given output is linked together.}% can create their key images using a different hash-to-point algorithm, or more simply by tagging the hash with a string, e.g. $\tilde{K}_t = \mathcal{H}_p(``TxTangle\_bLSAG\_2",K_t)$.} + + +\subsection{Message rounds to construct a joint transaction} +\label{subsec:message-rounds-txtangle} + +After the channel is set up, TxTangle transactions can be constructed in five rounds of communication, where the next round may only begin after the previous is finished, and each round is given a timed communication interval within which messages should be randomly published. These intervals are intended to prevent message clusters that would reveal input/output groupings. +\begin{enumerate} + \item Each mock-member privately generates a random scalar for each intended output, and signs them with bLSAGs. A sorted list of these scalars is used to determine output indices (recall Section \ref{sec:multi_out_transactions}; the smallest scalar gets index $t = 0$).\footnote{Output index selection should match other implementations of transaction construction to avoid fingerprinting different software. We use this effectively random approach to align with the core implementation, which also randomizes outputs.} They publish those bLSAGs, and also SAGs which sign the transaction version numbers of intended inputs. After this round participants can calculate the transaction weight based on number of inputs and outputs, and accurately estimate the fee required.\footnote{If it turns out there must be only two real participants, based on comparing the number of inputs and outputs to one's own input/output count, the TxTangle can be abandoned. It's recommended for each participant to have at least two inputs and two outputs, in case of malicious actors who don't abandon TxTangles even when they realize it's just two participants. This recommendation is open to debate, since using more inputs and outputs is not heuristically neutral.}\footnote{TxTangle transactions should not have extraneous information stored in the extra field (e.g. no encrypted payment ID unless it's only a 2-output TxTangle which should have at least a dummy encrypted payment ID).}\footnote{Fee estimation should be based on a standardized approach, so each participant calculates the same thing. Otherwise outputs may be clustered based on fee calculation method. This same fee standard should be implemented outside of TxTangle, to promote TxTangle transactions looking the same as normal transactions.} + \item Each mock-member uses the list of public keys to construct a shared secret with each other member for offsetting their pseudo output commitments, and decides who will add or subtract based on each pair's smaller public key.\footnote{Since points are compressed (Section \ref{point_compression_section}), just interpret the keys as 32-byte integers. The smaller key's owner adds, and larger key's owner subtracts, by convention.} Each mock-member must pay for 1/$n$\nth of the fee estimate (using integer division). The mock-member with lowest output index is given the responsibility of paying for the remainder after dividing (it will be a truly infinitesimal amount, but must be taken into account to prevent fingerprinting TxTangle transactions). They privately generate transaction public keys for each of their outputs (not to be sent to other members just yet), and construct their output commitments, encoded amounts, and Part A partial proofs to be used for the aggregate Bulletproof range proof, signing all of it with bLSAGs (one commitment, one encoded amount, and one partial proof per bLSAG message, and the key image links these to the original list of random scalars that was used to specify output indices). Pseudo output commitments are generated as normal (Section \ref{sec:ringct-introduction}), then offset with the shared secrets, and signed with SAGs. After the bLSAGs and SAGs are published, and assuming participants estimated the total fee in the same way, they may now verify that amounts balance overall.\footnote{We don't publish the separate fee amounts paid for in case a participant calculated it wrong, which may reveal an output cluster due to a collection of non-standard fee amounts. If amounts don't balance properly, the TxTangle transaction may be abandoned.} + \item If amounts balance properly we begin a small additional round for building the aggregate Bulletproof that proves all output amounts are in range. Each mock-member uses the previous round's Part A partial proofs and output commitments, and privately computes the aggregate challenge A. They use it to construct their Part B partial proof, which they send to the channel with a bLSAG. + \item Participants begin filling in the message to be signed by MLSAGs (recall the footnote in Section \ref{full-signature}). Published in random order over the communication interval are two kinds of messages. Each input's ring member offsets and key images are signed with a SAG and associated with the correct pseudo output commitment. Each output's one-time address, transaction public key, and Part C partial proof (computed based on the Part B partial proofs and an aggregate challenge B) are signed with a bLSAG (these can also include a random base transaction public key component, which as we will see can be used for fake Janus mitigation). + \item Participants use all the partial proofs to complete the aggregate Bulletproof, and privately apply a logarithmic inner product technique to compress it for the final proof to be included in transaction data. Once all the information to be signed by MLSAGs is collected, each participant completes their inputs' MSLAGs and randomly sends them (with a SAG for each) to the channel over the communication interval. Any participant may submit the transaction as soon as they have all the pieces. +\end{enumerate}{} + +\subsubsection*{Transaction public keys and the Janus mitigation} + +If every participant to a TxTangle knows the transaction private key $r$ (Section \ref{sec:one-time-addresses}), then any of them may test the others' one-time output addresses against a list of known addresses. For this reason it is necessary to construct TxTangle transactions as if there were a subaddress recipient (Section \ref{sec:subaddresses}), including different transaction public keys for each output. + +To match with possible implementation of a mitigation for the Janus attack related to subaddresses, in which one additional `base' transaction public key is included in the extra field \cite{janus-mitigation-issue-62}, TxTangles should also have a fake `base' key composed of a sum of random keys generated by each mock-member.\footnote{Key cancellation (Section \ref{subsec:drawbacks-naive-aggregation-cancellation}) should not be a problem, since it's just a fake key and should ideally be randomly indexed within the list of transaction public keys.} + +Many TxTangle participants sending money to a subaddress will likely have at least two outputs, one of which diverts change back to the participant. This means any TxTangle participant can still enable Janus mitigation by making their change's transaction public key also the `base' key for the subaddress recipient.\footnote{If sending to your own subaddress, there is no need for Janus mitigation. Wallets enabled for Janus mitigation should recognize the amount spent in a TxTangle equals the amount received to your subaddress, so they don't erroneously notify the user of a problem.} The subaddress recipient might realize the transaction is a TxTangle, and that the `base' key probably corresponds with the sender's change output.\footnote{This is assuming transaction public keys are 1:1 with the outputs, as is apparently the case today. If it was standard for transaction public keys to be in random or sorted order within the extra field, then TxTangle and non-TxTangle transactions would be largely indistinguishable for subaddress recipients. There are niche cases where TxTangle participants are unable to include a `base' key (e.g. when all their outputs are to subaddresses), or where it is clearly non-TxTangle since the subaddress recipient receives most or all of the outputs. Note that since TxTangle transactions would generally have a lot more outputs than a typical transaction, this heuristic can be used to differentiate TxTangles from normal subaddress'd transactions.} + + +\subsection{Weaknesses} +\label{subsec:weaknesses-txtangle} + +Malicious actors have two primary ways to defeat the purpose of TxTangle, which is to hide input/output groupings from potential adversaries/analysts. They may pollute the transactions, such that the subset of honest participants is smaller (or even non-existent) \cite{coinjoin-pollution}. They may also cause TxTangle attempts to fail, and use subsequent attempts by the same participants to estimate input/output groupings. + +The former case is not easy to mitigate, especially in the very decentralized case where no participant has a reputation. One possible application of TxTangle is with collaborating pools, who may hide which pool their miners belong to among a collection of pools. Such pools would know the input/output groupings, but since the purpose is helping their connected miners it would behoove them to keep the information secret. Moreover, such TxTangles would not permit bad actors, assuming the pools are somewhat honest. + +The latter case can be defended against by only attempting to TxTangle a few times before taking a break, and by always regenerating most random elements of a transaction for new attempts. These elements include the transaction public keys, pseudo commitment masks, range proof scalars, and MLSAG scalars. In particular, the set of ring decoys for each input should remain the same to prevent cross-comparisons revealing the true input. If possible, different true inputs should be used for different TxTangle attempts. Since this weakness is inevitable, it makes the next section's concept more palatable. + + + +\section{Hosted TxTangle} +\label{sec:hosted-txtangle} + +Truly decentralized TxTangle has some open questions. How are the timed rounds initiated and enforced? How are chatrooms created in the first place, for participants to find each other? The most straightforward way is with a TxTangle host, who generates and manages those chatrooms. + +Such a host would seem to defy the goal of obfuscated participation, since each individual must connect, and send it messages that could be used to correlate input/output groupings (especially if the host participates and knows the message contents). We can use a network like I2P\footnote{The Invisible Internet Project (\url{https://geti2p.net/en/}).} to make each message received by the host appear as if from a unique individual. + + +\subsection{Basic communication with a host over I2P, and other features} +\label{subsec:txtangle-host-communication} + +With I2P, users make so-called `tunnels' that pass heavily encrypted messages through other users' clients before reaching their destination. From what we understand, these tunnels can transport multiple messages before being destroyed and recreated (e.g. there appears to be a 10-minute timer on tunnels). It is essential for our use case to carefully control when new tunnels are created, and which messages may come out of the same tunnel.\footnote{In I2P there are `outbound' and `inbound' tunnels (see \url{https://geti2p.net/en/docs/how/tunnel-routing}). Everything received through an inbound tunnel looks like it's from the same source even if from multiple sources, so on the surface it would appear TxTangle users don't need to create different tunnels for all their usecases. However, if the TxTangle host makes himself the entry point for his own inbound tunnel, then he gains direct access to the outbound tunnels of TxTangle participants.}%\footnote{For the sake of absolutely minimal information leaks, what we describe here is probably incredibly inefficient, especially since I2P is already very inefficient compared to the `clear' web.} is it? +\begin{enumerate} + \item {\em Applying for TxTangles}: In our original $n$-way proposal (Section \ref{subsec:n-way-channel}) participants gradually add their mock-members to available TxTangle rooms before they are scheduled to close. However, if a large enough volume of users try to TxTangle concurrently, there is likely to be a high rate of failure as users try to randomly put all their intended outputs in the same TxTangle `room', but then the rooms get full too soon so they have to back out. It would be quite a mess. + + We can make an impactful optimization by telling the host how many outputs we have (e.g. giving him a list of our mock-member public keys), and letting him assemble each TxTangle's participants. Since we still retain the bLSAG and SAG messaging protocol, the host won't be able to identify output groupings in the final transaction. All he knows is the number of participants, and how many outputs each had. Moreover, in this scenario observers can't monitor open TxTangle rooms to deduce information about the participants, an important privacy improvement. Note that the host's power to pollute TxTangles isn't significantly different from the non-host design, so this change is neutral to that attack vector. + \item {\em Communication method}: Since the host is already acting as the locus of message transport, it is simplest for him to manage TxTangle communication. During each round the host collects messages from mock-members (still at random over a communication interval), and at the end of a round there is a short data distribution phase where he sends all the collected data to each participant, with a buffer period before the next round to ensure the messages are received and given time to process.% If someone controls multiple mock-members, it's possible that some of those messages just fizzle out, or perhaps that person receives duplicate messages (e.g. the host is given a different destination for each mock-member). The host should not realize how many real people he is distributing to, nor which mock-member has a given output. + \item {\em Tunnels and input/output groupings}: Once a TxTangle has been initiated, users should dissociate their mock-member identities from the actual outputs that get created. This means creating new tunnels for bLSAG-signed messages, and each such tunnel may only transmit messages related to a specific output (it is fine to transmit multiple such messages through the same tunnel, since obviously information about the same output comes from the same source). They should also create new tunnels for SAG-signed messages related to specific inputs. + \item {\em Threat of host MITM attack}: The host might fool a participant by pretending to be other participants, since he controls sending out the mock-member list for constructing bLSAGs and SAGs. In other words, the list he sends participant A might contain participant A's mock-members, and all the rest are his own. Messages received by participant B are re-signed using A's list before being retransmitted to A. Since all messages signed by A's list belong to A, the host would have direct insight into A's input/output groupings! + + We can prevent the host from acting as MITM of honest participant interactions by modifying how transaction public keys are made. Participants send each other their intended transaction public keys as normal (with a bLSAG), then, much like robust key aggregation from Section \ref{sec:robust-key-aggregation}, the actual keys that get included in transaction data (and used to make output commitment masks, etc.) are prefixed with a hash of the mock-member list. In other words, $\mathcal{H}_n(T_{agg},\mathbb{S}_{mock},r_t G)*r_t G$ is the $t$\nth transaction public key. Baking the mock-member list into the transaction itself makes it very difficult to complete TxTangles without direct communication between all actual participants.\footnote{If Janus mitigation is implemented, this MITM defense should instead be done with the fake Janus base key. Each mock-member provides a random key $r_{mock} G$, then the actual base key is $\sum_{mock} \mathcal{H}_n(T_{agg},\mathbb{S}_{mock},r_{mock} G)*r_{mock} G$.}%Users must access the host's `eepsite/service' to discover available TxTangles, without revealing to the host how many prospective participants there are. If he sees five requests for available TxTangles, and then five outputs/mock-members appear, he shouldn't be able to conclude there are five actual participants, nor easily associate any given request with a specific mock-member. To accomplish this, while engaged in a TxTangle a user's client should at random intervals create a new tunnel to the host and through it send a (false) request for available TxTangles. Users should also create new tunnels for each intended output/mock-member, which are used to actually apply for a TxTangle.\footnote{In I2P there are `outbound' and `inbound' tunnels (see \url{https://geti2p.net/en/docs/how/tunnel-routing}). Everything received through a inbound tunnel looks like it's from the same source even if from multiple sources, so on the surface it would appear TxTangle users don't need to create different tunnels for all their usecases. However, if the TxTangle host makes himself the entry point for his own inbound tunnel, then he gains direct access to the outbound tunnels of TxTangle participants.}\footnote{If a large enough volume of users try to TxTangle concurrently, there is likely to be a high rate of failure as users try to randomly put all their intended outputs in the same TxTangle `room', but then the rooms get full too soon so they have to back out. It would be quite a mess. We can make an impactful optimization by telling the host how many outputs we have (e.g. giving him a list of our mock-member public keys), and letting him assemble each TxTangle's participants. Since we still retain the bLSAG and SAG messaging protocol, the host won't be able to identify output groupings in the final transaction. All he knows is the number of participants, and how many outputs each had. Moreover, in this scenario observers can't monitor open TxTangle rooms to deduce information about the participants, an important privacy improvement. Note that the host's power to pollute TxTangles isn't significantly affected, so this change is neutral to that attack vector. We can prevent the host from acting as MITM (`man in the middle') of honest participant interactions (he could do this by serving them fake mock-member lists where he pretends to be all the other participants) by modifying how transaction public keys are made. Participants send each other their intended transaction public keys as normal (with a bLSAG), then, much like robust key aggregation from Section \ref{sec:robust-key-aggregation}, the actual keys that get included in transaction data are prefixed with a hash of the mock-member list and list of original transaction public keys. In other words, $\mathcal{H}_n(T_{agg},\mathbb{S}_{mock},\mathbb{S}_{r-original},r_t*G)*r_t*G$ is the $t$\nth transaction public key. Baking the mock-member list into the transaction itself makes it is very difficult to complete TxTangles without direct communication between all actual participants.} +\end{enumerate}{} + + +\subsection{Host as a service} +\label{subsec:txtangle-host-service} + +It's important for sustainability and continuous improvement that a TxTangle service operate for profit.\footnote{While a deployed TxTangle service may be for profit, the code itself could be open source. This would be important for auditing wallet software that interacts with a TxTangle service.} Rather than compromise user identities with an account-based model, the host may participate in each TxTangle as a lone output, and require the participants to fund it. When accessing the host's `eepsite'/service to apply for TxTangles, users are notified of the current hosting charge, which should be paid on a per-output basis. + +Participants would be responsible for paying fractions of the fee {\em and} the host charge. This time, the smallest mock-member's public key (excluding the host's key) would take the remainder of both the fee and host charge.\footnote{We must use mock-member keys here since the host doesn't pay a fee, and his output index is unknown.} Since the host has no inputs, he has no pseudo output commitment to cancel his output's commitment mask. Instead, he creates shared secrets with the other mock-members as usual, then separates his real commitment mask into randomly sized chunks for each other mock-member and divides them by the shared secrets. He publishes a list of those scalars (corresponding them with each other mock-member based on their public key), signing with his mock-member key so participants know it's from the host. The appearance of this list signals the beginning of round 1 from Section \ref{subsec:message-rounds-txtangle} (e.g. the end of setup round `0'). Mock-members will multiply their host-scalar by the appropriate shared secret, and add that to their pseudo commitment mask. In this way, even the host's output cannot be identified by any participant in the final transaction without a full coalition against him. + +To simplify calculations of the fee, the host may distribute the total fee to be used in the transaction at the end of round 1, since he will learn the transaction weight early. Participants can verify that amount is similar to the expected amount, and pay their fraction of it. + +If participants collaborate to cheat, and not provide the hosting charge, then the host may terminate the TxTangle at round 3. He may also terminate if messages appear in the channel that should not be there or that aren't valid. + +At the end of round 5 the host completes the transaction and submits it to the network for verification, as part of his service. He includes the transaction hash in the final distribution message. + + + +\section{Using a trusted dealer} +\label{sec:dealer-txtangle} + +There are some drawbacks to decentralized TxTangle. It requires all participants actively communicate within a strict timing schedule (and find each other to begin with), and is challenging to implement. + +Adding a central dealer, who is responsible for collecting transaction information from each participant and obfuscating the input/output groupings, can simplify the proceedings. The cost is a higher bar of trust, since the dealer must (at minimum) learn those groupings.\footnote{This section is inspired by the MoJoin protocol outline.} + + +\subsection{Dealer-based procedure} +\label{subsec:dealer-procedure-txtangle} + +The dealer will advertise that he is available to manage TxTangles, and collects applications from potential participants (consisting of the number of intended inputs [with their types] and outputs). He may participate with his own input/output set if he wishes. + +After a grouping of almost 16 outputs is assembled (there should be two or more participants, and no participant may have all but one output or input), the dealer will start the first of five rounds. In each round he accumulates information from each participant, makes some decisions, and sends out messages that signify the beginning of a new round. +\begin{enumerate} + \item To begin, the dealer generates, for each pair of participants, a random scalar, and decides which in each pair should have the positive or negative version. He uses the number and type of inputs and outputs to estimate the total fee required. He sums each participant's scalars together, and privately sends to each their sum, along with the fee fraction they are expected to pay for, and the (randomly chosen) indices of their outputs. These messages constitute a signal to participants that a TxTangle is beginning. + \item Each participant constructs their sub-transaction as they normally would, generating separate transaction public keys for their outputs (with Janus mitigation as needed), calculating one-time output addresses and encoding output amounts, making pseudo output commitments that balance output commitments and the fee fraction, assembling a list of ring member offsets for use in MLSAG signatures along with the appropriate key images, and add to one of their pseudo output commitments the dealer-sent scalar (multiplied by $G$). They create Part A partial proofs for their outputs, and send all this information to the dealer. The dealer verifies that input and output amounts balance, and sends the complete list of Part A partial proofs to each participant. + \item Each participant computes the aggregate challenge A, and generates Part B partial proofs which they send to the dealer. The dealer collects the partial proofs and distributes them to all the other participants. + \item Each participant computes the aggregate challenge B, and generates Part C partial proofs which they send to the dealer. The dealer collects these, and applies the logarithmic inner product technique to compress them into the final proof. Assuming the proof verifies as it should, he generates a random fake Janus `base' transaction public key, and sends the message to be signed in MLSAGs to each participant. + \item Each participant completes their MLSAGs and sends them to the dealer. Once he has all the pieces, he may finish constructing the transaction, and submit it to be included in the blockchain. He may also send the transaction ID to each participant so they can confirm it was published. +\end{enumerate}{} \ No newline at end of file diff --git a/translations/es/front/abstract.tex b/translations/es/front/abstract.tex new file mode 100755 index 0000000..2ce6805 --- /dev/null +++ b/translations/es/front/abstract.tex @@ -0,0 +1,14 @@ +% this file is called up by main.tex +% content in this file will be fed into the main document + +% --------------------------------------------------------------------------- + +Cryptography. It may seem like only mathematicians and computer scientists have access to this obscure, esoteric, powerful, elegant topic. In fact, many kinds of cryptography are simple enough that anyone can learn their fundamental concepts. +\\ \newline +It is common knowledge that cryptography is used to secure communications, whether they be coded letters or private digital interactions. Another application is in so-called cryptocurrencies. These digital moneys use cryptography to assign and transfer ownership of funds. To ensure that no piece of money can be duplicated or created at will, cryptocurrencies usually rely on `blockchains', which are public, distributed ledgers containing records of currency transactions that can be verified by third parties \cite{Nakamoto_bitcoin}. +\\ \newline +It might seem at first glance that transactions need to be sent and stored in plain text format to make them publicly verifiable. In fact, it is possible to conceal a transaction's participants, as well as the amounts involved, using cryptographic tools that nevertheless allow transactions to be verified and agreed upon by observers \cite{cryptoNoteWhitePaper}. This is exemplified in the cryptocurrency Monero. +\\ \newline +We endeavor here to teach anyone who knows basic algebra and simple computer science concepts like the `bit representation' of a number not only how Monero works at a deep and comprehensive level, but also how useful and beautiful cryptography can be. +\\ \newline +For our experienced readers: Monero is a standard one-dimensional distributed acyclic graph (DAG) cryptocurrency blockchain \cite{Nakamoto_bitcoin} where transactions are based on elliptic curve cryptography using curve Ed25519 \cite{Bernstein2008}, transaction inputs are signed with Schnorr-style multilayered linkable spontaneous anonymous group signatures (MLSAG) \cite{MRL-0005-ringct}, and output amounts (communicated to recipients via ECDH \cite{Diffie-Hellman}) are concealed with Pedersen commitments \cite{maxwell-ct} and proven in a legitimate range with Bulletproofs \cite{Bulletproofs_paper}. Much of the first part of this report is spent explaining these ideas. \ No newline at end of file diff --git a/translations/es/front/figures/monero-symbol-1280.png b/translations/es/front/figures/monero-symbol-1280.png new file mode 100755 index 0000000000000000000000000000000000000000..0c61b0c924e3b81018731a86e38b39927359dfed GIT binary patch literal 22645 zcmeFZc_38Z8#sLKox!z~8HqtQj_b zC}K+C(?%(25u#M~HiN4jcMkB{ux`;hFQ1)T{#$2_ zkcYan{j4QB-nG>|+cLiV_~pjfF&yivgEFy3RgIClvN!3kt^v-=>HRVn@@h?eh%h65 z8JTCqZ=SVA@w@xjB^Fh6;_0?akM^#!S@3Y5-uw@*L(fM)RzH4pA^{BipMU>H1H&3< zpD~R@%+%kjW@r~rSuKvbdE91G!3mqnolzmDY{Wxmi1|S=2u%yq{g6D=FL@C)G%;dq zN8Zu>O@9)HinVNpcK)jOHVq&8S`ufEnB(#QdtI#iHQ?p!qJD#!vG>Y{LceTD9Tzfo zfBn$TPeW69Br38)Y?NLTdM2bLAhS}tdUjiXaLc&QyNV76Nd}|7>8M6p77qHS>L7YC zn?@NMBYM91wwHI7M0VHT`W(_XSW-R|5i;<4;X1@@1m0-hh#tR|kL7i{v=4mV?7CO) zLuP+n?9hDWLWR!f*VYt4>}B|pe8hQh>u}(-h+=2u7s@rkC&qnhSanxv?f^6VJGLYwEa<6L++pia{b9P(s7x>W<=o zy9XkgdgA`2Zt5AB&XFs@`?)eSG?n*v;o5bKHqT-oWNC)l%)?;aQ#y=&Wro|3~2azz~>Vo6}I z4-Z|@M&uofaUU*L z?rxCNBNz{0nOZxerhiAOHa#-`zb#&fngif=5jUO$Dn;%8OUB(J!>&?e8f{BsvbpNSRe1@$Per zuW?n(0>`+@YoYZ>lmLi4?*FnWDSx4yu}-^QOZ+^HMF@9->5c4vv1$`}6jB_82%*C{ zZISas0A@h!2`U3fO-Gg#xxjSGn6Gj8 z{HM;0E||q*xK@5~ru*oK3u0$DMdVw3?C&;TgAD7+-|r4gCYhID zO4W;h+^$6L%|+&}26??EZRmuO>V z;>yB zJoK9l`y)>V%>%yDPIbv4$2;@v_(%~yCc|TH0e*z2AS{o=W8&~5ytPb+$E(uE3HUJ$ z9+!U@uft*VK=w9QU{P24$b!eBx%jaTznuw>*7M+z({YGHi4?&W#V(Ap^{a{WzmvWgSt+tXqp0J4pT;aFWhDm9&x6lNgKJ9D3`XJDQ#)V zZLJ%U&CntFw0B>}VzHIQ2;}>mH&j-~*lNkpR&1Ja__gZpnBvH}oBzn5mmQW}JG{HB z&ZEm`5al-AqMt;@1+JTwWG|nF=ZWg!2+0*VPf;K)AA{%Pj_TpzsYNZysP;^v9hx*A zkxMRgh7=Bzt%}mBMri-G)Q(UVXrCSngcN{~Q;&MMKgg8!U%=fG!{&Pn(L)17vdzc# zj4iD{>W7fx9p@gMsvANkV^GLOCJ<9Iqe>=pD+rzpfomm- zK*rsCoZL8|qbWm=0YN$YfoqvN&iiFpv5k~~M))~SNScY6-l2%t4IToz z5!fPK%Oj$AHiK72BKz*2UA@}nF~nm%M5<b~aEb=^$JPsf#=aAo6JmgHLk(>JiN-AK03GtF<+*uD4CYSJdOPl5~Ylh zm(}!<<5$Ht5`iCnx9BJ%rhN1BYt>rbXyXJ#E^RHmrBNK|95O(lu3O!PUG?w|9QL*f zir)Bp)w|4oap-0+R*|qs)hCI`cOYI>SfS`izgP8{)RlBDkg!mLS<|$p>($fr>Fprm zm8sUZl9dCS`lb41^or*7tcTps?SgPN3u5yw z+ts&k7LPq3NdSAD+!&rI*}kicO;wJh`9+QQ+b%V>h8;#oNZ6iPbt#I+;=l?VYj&?Q zu;_E>Cg9HqN{M=vwtEciv>&l_Ts!-*H$ea}amke@OXgQ*pvGE)ik)V?BiTZ-KQ-dy z30Z_DYlfozskM`8x4tO@X&na!Fbi1$JqqcK$6xhdigp9B?9x8=SgiiDWgXB` zZCEdsl!g(}6r0Z2u~?#2-_vqxGD1h12fBLQ+3dNX*EwO^-tN^afkEG-C~tOnpep@u z5sPE!Uf;gIALBpbAG%`Qt`HeRY{-L|>XV0jR1jiMEgsdi!5htmT=M8!;V<($Z6HG0 zUxUrnh0&n5atIwQ7;6)?bvosy(23XyU0-i1L$+hS=6xHy$7r2Lb0IoXPMwG((B&gq zG10mpxzFd!H3&`mvPYOfL3q4%QMLW(e%Rk7G=`Xc6q@!br`v$!>fRr-QBG2 zSN~${!oJndx_b8lA~Sgg)>Ux}Mzz9XwZe~VipqjY&mH@wXoEd1G$Z+Vft_P(F+d_w z3*;CF5je7uGh(Za$3Teyv?WSF3MWS77k-@${=>AiuRc0$rWMNwf>X$?W|A zbb}#e8f!}T3+qgJrch?^{q<}bs+Rj{leQ*UcoN%kqG zY8;@`!|1B*X`E|DaECx+`lQ`fHtidWiCXKDcC%NKWc!X2m`cOPN4Ff1CLh_c`Zo6@ z4!qO{c*iN1Zj)})9htMi)yBUjgPGCkEyE^!H4numVChAt?di*DdLp-fi{HnUNMZg2 znPuxR3XpC`r$=rHO9g5{m+{J4#><#O@|QS(KGA$&W*wWp>{Nd-v9a|{<5rxuL_d2~CM==Y3NbwRN)BTAe~w2P$?WLW$9RtTZ+c`W00xl#S=>#onnP*BmTfv^lD zo6tMiv|)-?6oDA#gOXC53OXyOPA(bNS^S11CMsl_;K(B@be6wZlKT^M8^19>^LULp ztpgLEEcj2#pTBzbJ6Xe6U?!-^7#QJNux8JKWT+sJtSy3--2_ySF*VAnaDHbJ@k0ga zOtTn-;2ynonm`p?H)-6ezQ%h|z*ROB6WJ%Cb+kKCY*CqaiBzoI#O9-pDMt}?{8wFv zdsenHIMs;S`J4EBmLsFHyHUOVb=U72?0sc_Q(dbH@>(}#0N^ygEaFrEiP5g9krMN8 zb12%7>Enz1oT)%zdvbXsBt{r%)7?2WIZ6WD1zn>)_32Fl2Q_X5RVg;oLqIu>OAuqCOzpNkDVPYn0}_l zMHIuPJ>2TsSNn%~f#aacyJs>n1}X@sXeud68R^3kS>Q z*^U{2Zewkw*hbX7CxnrE`^ri60eaRk!oK0Ch$M0K8{TtM+`oByZ!Do1>FUy8iU4OP=0Li#*d6Q~W+)@=$=-ABtF%;RMS} z1YTxNf1w0LZF}{xrjPhf%dTTKz-Gk#rOVl9x6&#}*HAud-*NndYu;5nAgK87E z!PZJaY0XwP@AMyYsnrgiT(D_+gCfZf2f#2t>?n;Z=Wm+Pz;$FAxsF(054NiEiec>! zfBs?($X7c?W{)w&2)1BX$k5zRmg?S>)7C55HdvIt>BOU=hRO|Z3KM5#?1HI>@*Q9*W2T$U zMSgbm7q2#M+Ju$kl2^Tgd!>aEyw-}$ICH80dX?Nj|Pqr}^Ks&mkV6;QSJhI*-(;E8PA!AGGc**a&T z0kbrH%3#;Hy$$v>LL_JCdw1!rW3k^U=GDdz#qDyTGI(6UVDR;4>*)$E7uoccY4?hL zKi2=QLz2ji-+g`lvMKDd4kX{~hx!Qxj9k@TlA9Up29TdV9k?qUp(R((D9*aPA32$= zl)RATauAdBuq32_6MF>+J$$5{%pnL=K}$9z0$2ia8Vz9MFxcpQQ30C9?Cyk#SNLd= zqGObnKG4k}yRQd?5Q}7pl&-$b`9A|UsRXD129FeRdB}>bcF=DR}TAKKak z>rjpIjJ?I`XT>J6SfKU#gWa|3SA^MlkbE!LpYQDoHMsAHl{SqtwBvDTwWg|_3fkvy z-M2~0{0tXRTSkk^w-!YvRIzEh?}c?2wU-&(UyM=h=MQ$LU-kP(p^;+jKN}ktIkDNO z0e#Z0Ik&_W>7Oi~msq>vn>nE(sahG8JBA_+dad-Q=c&3%&f5dj7$W7Rc%J+tY{dk? z6`&Xf{O$o@!s14BYWht zJtB3=;ku|Ln5bpE*m1IXbvn--5SE5I(2AJsJs>-(^Z}c8e~p`b0j@Fbn6|OXknf9- z6ug92su+nz_8;G;5Eqtyk>y+P+gQM>`D-92OL}Tsx>v-b(z{!L7sGO6} zZsqL(TR(laW|B|`6zxWJD`#cPJ0KtP>g}I_x6fccdi^KuEN`pq8(z@r*!n|V!2>JQ zM;FkV&jQ}o-p!Oe))$V2`8iX&m1{!HvTrx~0I0?qx9@VJvM>|wx`VUEwN$Urns0!n zs(T*R!Tfrpf#TjRp;5CBc)*_Piia6%Fo{s-lXf$#Dt8+70ZEs-d%QzliP4DtkaWe;A zcf^V1wiGDEo|k9F4D6mT-gXC{#KU{UayM$@OJA_*{p(sy*f^c7;egdn?xC15{=2#_ zryj5qU}m{P{A-G-(LqW?ig$s86$3WN*a>_cuI9tYN)6&6>iNoPa8dR}K<*b>$m@i@a`hCi&MPG?b4dJJVJe&{4A69NgWi z$O-vq4+XHR@Ur^=RFOV*wLZG39OcS5fTO!vcPr0#bWgAR#XZmZHj#A?A&x>{B3edf>hnTQm<4 zdO(B4aiAZ;x*rJA2H8>XqydOK8lYLoz1IGA7`V7eyDox ziQWys0xJN{++YrLZmi>3rU9K??hv!MU_{z=iV0tT*W~L1ea0IggCIOCU)KbP!ktm` zygUWg1Yonl_mj3Tpi-Aj7yDcl1mT5tqyfnC$H)OSANEVkDN#YWpm<^6Cv8FgymDqI z$e63maX?RDRb-$8!K# z&{LtAcOwIo--t z$S@t%UM`-eUYh!Ih<*WLK#j^6KEI?!?`DfaCJxaQs7?kNV*fB47`Q`@p}^u9^e62M z8O|P5oAK>?;QPpEH<+ma{i}tmTwIwliV1k9NpPS(q=|>N^eFxqBF8mPLVAIx`+%C# zk&gT@$Z-IX1zhr+W2iQ*c;1P|P2MW>HlR6KWr#`l&orlJvqgUjerR3ZLs24yhqf6G z?`UrrlDwuEyn-7+cWvXv5vC5vzp{p6-r*t8@y0x}m^_LZA&q5-CO17$pay8U{rM#a zT8}Ntvusjc;>u>hr4w3VZryg1XK^Me^p=UMJ zI~`eB*U*8nX)jd1k4H66Y*#QE z05%6a@5^nom>Iz1k00}y<9H0veYrG#$y}6`n%fV@vILO;u4goR-sL06r{?ySxabNIixsP+6S zRu-(v9?&68Igsb3K~&i;LhHf6Poey(nCE#p33+H6x3Vkj+3Yk}I#bSIpd6b?Gie81 zJ}xtvslJLwxoGkylEX{|VI86I`nXXysmNkj0W@Ke)GC&-XvXAv(B51)`5y_pv`+E z(3}06gC@TSeg1`Y1nSsYpc+%9i7AxUtYnZqow4PUHf^+G_IS2vm*hVRt>qBW4uGxO zcf?T+YCZdyg%|l`n78(&<|G}|=O|Ab=<=(ea^g?PKC40sW%{O^QpWzoIY3cM=1W-d z?cp0ovL~RLSqJ4P(Ap%>^;=tM7<(S0Ovgsj;Fg!_7s$e$X@-k}eDAd%Cp&&cNfsF6Y z%>>5F^1$U;;+qo!8{_m-obuJ5!e#{9lGv- z7>Y6i4`?tMp$jMdXcBnWG=Rv^C58Twtr{TFrC}tC^Bg#-_~s92WE5Bm+*@$Dc=1PK zM><7~aRv-?R@kp3g)2AL6AjCC`9b_{WhTOx3$^Q(RXhS2!@QX=uWeo;H5Vnd9&kXS zP4;vHgaO)Hr5mGynika&wTW4uBv!gR-)@ z5A_jA&xQkq)6f(gp@LZ7tu}NJmZvG|8AO}qaRcsQ#H+r;ML`N&PCEFdK;2cBPY4Wd zk7W+;W2%&Z!RY}>{BgrWu$;QhgrPgbLz%Xk1lr0a&aMCk=T+&GD#$yS&107DW8C1# zgt_ReLdZjTyPu+7LvNj_q!^Qb+mVqSJGKjYRmU=&+4`ugS%rht^hi4oK(a}SWcN3# zp(^A7TsDI5WjUOPcSK3$?w-h9hqU8iuxf)CIMQY|03j&j(2k>s2jPi44pY=45Uc`1 z?FPjR9wbCp?P)`(Tj}{)dhrmt=novCm;mtxJ}I=W2c_SMXHwwsi|GEqxN)lX=agrUl@rakG?oV=HjSd5>@lNL{dk_y4`QR#u zC)@&_kz>f^oW^H@S2@VL7s$msv16};O6@N#Wb2}`PvJ8W6bN15yYvXt1ey(79y47& z0EqhV|Cj3WM_{>)hRJ6rz%yv~@-X=)aa`o4$W7S;@UQ-ozsV*1@Bx_*9MB?ggC!7c zaCip~Z{Y!-$|dN)1N1lkjR!Dj<0+k!YUlDP%1H+JPCvW!p$;l*)EvO9^hgz`sBl3A58!N43~+S`C5$IkFjZB!Vt}CEu}A@>1gPwApmEFw#q`lmwWOCH0$WT%Q8*p??pF9*t zRd65LLSqJb;Ja8a?dh8wVmc#sgsutN1YYB@n{raq<%e;G@VY8=1#UNSiT~`_&A{Vw z5FiV*B!s|*_=O&vo+3Ev7(fmkDvVrj7^oS}zEg%VIZO0lOUs-Dm|!U)|MX#McOaab zr7YFzcOSqn!J?B6a2x0u;$XvfM~7`Cgx%GcN!eOyQy$f zjO;~F0Qtb_wwo^K=w&?PqeHsS8Rl^jP&?wp)>q`_C=By>1mAmGA{7Lx9_h3hFzwJj zJZ+EuFf}$Q%-XvG=YKpHHeY4P0|LBZ`a}gnFjDyz4OJH?u++%9rkOA3mkHV5#L%R+89ljmu8!e^0dYG~= z9&{E-;N8(fC-~g9y z1r)wUWP;R9L^C03?dhq0`u`hX5dt;k=jaLe_qiXGp;T2l3MKWBhQ0sc6bVNOVTHaE zS^kDcJdy^VdsyT!yA506#kg~u5}0A9>@p<;Usz^v%L`B)`X8#k&M>lfsIAU8Xv~Jw z;zsvie%po}ZQCxime;KJnvg3K`1)SOy(OPQ*5dA)^LI3Huww#j!FEMXB^k)hM!E-q^&3z< z3Kzb!Ukg4{pv6s@lVuGGGlGa<1}Ns+ji+kD>AL(x4?nO1uDNp*vbh)LAeRHmZ?XK# zA3oO25SN25GOvA;`TqbbZ3}?tf_i<5m ze^sXv&HUyN%fJ5=sc_vS-p~{kO|nh&9fe;v%Z(7uw5N~tHO$=bKl*di?PJ&?)84KT zIa7eKw26P&_4wzEyb4r5B1?N(&1B18aMYv%Xl7fAW`MwJ&;3u}-{Iy?DJU(oM1v4* z#BZAazTwLcqn{o$N?3;xE&7WnC8>sbsfRNElM7~kj{>=8>iw1b!YzjsD3@H_5qSa9 zKUeO5R`~CQJ}{Koe|8*W8qXN@?rgmFS3>&c855@@STCvp(+^f(z~6E7)DgM7fpzw+_kcK*-E|MlOe;9^K-YoG&4F#?^h z#FoHyh;TY7yc_N-=X8Rq(CzD*FlYidZTMPRdQOK?+O@5E$O-B%ALzOAN78_X_}QESKYS48Y7r=z77-SD}nG)at?DG;Mwy`BA7k54ME_5voxBx&>Ntz5Ga_yp5ev{J*N}s>s}7?3xL`H z=-h3G6hObl@%q)|iAWXt1?%xP&Na;G3`*Mz>M}e;Q7(`x4NrebAqau;wI*5I#&vv$V3mr*lH1UH;^=igu2Xkqy`85%qU~ILER;Qh6vLm9U2gj zDbTR8gdUj4%yh33#b{XWirAuez;h=mfHo5@{|d@_tHwB;L}|)%#xYl6%kUhQ=FJ&q zK6dEWYc2eGJ`Q(o8(t%PSrtQ&YO{FGi+?MAxH~$*HAzBX#J_^>-KMS~F7+CoJx$02l}j6ppY{_%l!qjom>{wi;KDD1+ zk%rRpletJ>!sQr1+fQ&lnJWb=wIb3$icuKf@jWRfgdk8$4+)`PkOWn^kkHbrNJVKk z&c9ju{@yJELgZpk^P)j9eTrTvc37=@lR$Z0Sa%gj6k4GAW&B9dN)MmC}E^ty8M-}Qsn3YQfR#~=ifx85gsyJ&Ljww z?Jtxb^U<+VWmB|?PcDM49dq<8Z@XOd^}{(SOPGBtCYWN@b?+V_g5IW&D-1pQ$eT5tExH-LfsL|KD5qm!0r%&< zQ8HZg0OCxa03wNkj4G54EsiuC2mC1bEXSzEGx~F&7B$h*Gfad-s{dJsChh4% z;6N#9A-*g)?lYvbujfd|Iq6_wHpQFI2DX~Zg9rJ_W(|2I|EFB)v zMQUHaZr|P^H;!TNW3pnPN`GKJdsGJ88@&@LAd!kbdD9RS^ziMVry-HE5?Wl0JuHn- z3Gi9K&tc?o`TU#Ld0{u&)R`sw7~F2-vsz{=X3(VYZ5GMquhZq{g5*`m=@jxX4;vz! zPEi#XFm)6R#tHy_d}y|h3J9%dy8l{p#Dd`J|_F`a|WPRQuPi`Fact5+OGd_7&h9E4lN607i@OG1)AGfE!u zEnsg1gI%Z2oRnvNos>cJetWtDIy$1z$lwX+WgzS0Hsj4KIA_!4YeS+-x%0Ep$~JBk zy5r+4KzCG#JFr?Yoqb2(c<#{n`>5H4-8>f9E^b{6XElnj3@t@W+dgI`W^vV-mlU(| zv$iY>of*=YFpR138k6wh&c4)TI5sXTFWG-r+6g3uQsOk#6Kquklm*9-2WX7&l zr~2hcdvvlwcnftPgw%pH2<>uSgztP-gj_`>VbSmiQc+_l9|N?EWr#7ExV1Ga27! zZga#qthhm5z_RpPFlHd0Q3O+=k+46+rQ^xtc$Os;?+pUo1{aJFu8k3B%$6mAz@oJ6LW z`R;v881yz!CMN7Mn_Z*_atT*pcDLD!JTdla_`CvTjwe6DVF#@F7{yF(*G!Be9HW5k z3GC{Ta5bJ3o^SvPEhLgi-;CCRN*6Kfps9d%kjrBoHmAAbtqX%7P|Kc zwH{t6MP7qDCLWi3pn#M^Ih!$iyRvPDQQ$^R*87c6y~?2!xCD!Y1McclX18Hx{XATy zC|+Vx7reWr{9V9yb9%B?N*BsS3Z%fN~YcTH99e4); z*9@_=y?4!q(P1hd*=~OoM;0+EVy0EM;)*4e`B!C-~=s zL*xHU#;W-Lr?4A(di)JKvD$^Hd!=^~9sRwN4kSgdTuwN3tcJxKp?pg-GWgHG+?3o* zzjt@9X>SX(g-_@Zy4F3ZOq^_zGHo)Nc>hVqbPHJ+{J7O7d_!!OJmX_rRy(wN^JD=G zc3O=so@Q6G61u^5RDG!N1WbwEFv>gJU+IWQfu8%xZ5e>=YAM!Rq>{?GC1v_OZ@t^G z?A~d7YoC5G$ng&MRyy)PO_(ssPJAP5r!T${Ip(bW4cyZi?grh<5Pun9p(1hY8UY8Ly(xV;J8$p-jbfvR zXXpG@zs5n0tMW(|LKmKmG~NM$xU5z|2|~fzGpcbW$uBB*7lM!boO;`*sI7t;cMZc{ zY(K4D28#r0)RYeBm)EQ*xPQq3z1fuh#d!NF+pixZ@n-|*>L0L_b{Tq;OLA;F*4_4W z7>ST*M!??A&7u*oEZIzn4SIPmJP>R3>Mz5x0yEiyCyh7Mz-f8aw(tqw5UeDsfKHVBy=v-b~>Q8D7U_zw|ZV?+(^? zvkKfVeMk7aY5aaQHO!F$HNo6^RJ_FFYh;{NAz-d$6b$ zyAa5z4XlkZzPn))K%?{DO1$rx$`;tBG9o8CYCu8MS=bWo2X8*ii|VLv;+>CE6Ob@N z-?duu$(jZeE|g3u6R#=5i>H_Ua~3#lL4Gdpe0GUIcLRDLJ}Cz|E-0y!fT;56h# zNwN`GR|wUUwKN!r;g4TRP5|h;G4LkE9#fA#m>mF`+Zti>ECY5Tmxr@}Fk-rRQC1 zjeIh&4@>Xn=n=xF)@rKQV3JKO({P>JGnT;K8sqM7){( z)E>Y_Z15~l1Q0ov7-V~zp4ofxT5E~B)Ucm-s(F9lv7XLDu`;Hvx!J9K zvwHq)tptrb7XimpXYpD1iIn}yyuQ-r}rgU5bE7fVq(AY2Ex=zV@a6x(nGuNN3YQ<0c{~Cvw(qmW8yT(onX>0cB2E}M4p=$R+}^e0=2HuJ{V;;l&DYAWfphH9ME^TW38rwA_HGY4M;VLwsd-Waj{Z7ssz(=1xMju(!}d$noCxisSR( zA5qG|Ouxu~Tl=opy`O+BJ?883q%Gb`&_m%&tu}oIPJU)Gwp4AspVR}2C?-V*4_MOL zL(k#c9X({1xrf^E;a-F<{`l&j)n&Xj8mwk#_=pG0iSMGK51)+6#1DA5Lh`{EWRcCe z15uaC&`uD=a5kj2qtggbP(Iu_d^o`YJ^C7TBM?W+*AlJxC^z^(O5w#oux;n+am#f1 z@IA$5t8fdX;H4-~HHhuX2PO2kX_?lWir)*=>;31op8-P zs^@r#nS$Yoe?+1t^E8*G|VlKdKxnwr7K@`H?Lvn6-Kq(wzihf&#% zjY^^jiV+#wQ4#ELxbT7mn%&C0N3en>odq}ke%I!jznm;$Oh6=GHna{g>ZDKWlDgwe zkTgZA`8ZkfZ6&mTVz9{!fho8*U;^& zhO)!@JuwL#yF&0cVXVa=rh)tK+lBxKm?-eg@(}Ak&F39D=hK)-HbUm0-U@!cLMha^( ziuN~^E-*uH?+pxb*xROnzrXob*_-=Wy&@e^syeY%YexR~pburs zCnz}}3hux{6*5%e+-8nn`j^zZ*M@S#`g^cPx~1oC%>Qv6-s;2KM+!RDovQ~u?u_Rle(1ol zdUcbsY4Alj95&6##baS`@A6Tu49_tApZf?c4_n&)Y0V~8`aht`i{+eNQuvyItEuQh zcKwg{drK@F2-u?*>BR+2}@FmUe=uvRfv zlur1<_B^)d2nywl9GIgGF1x{j=z^;vqOo`QY`FZf@)wZ<{RZKJDHMErbR^LR{QamcbuC||EY#|{(RKl7QWLqltGOF#g1!Pe{`e5#BXtp#AV*Me*C!2$(=3b5p(6Kga0o7;tJfwqeWA|oVL779!^#h_6)Kxqxnv-((R z@ZGdP=PKma&FfxkiypFRM#BT7?INxY!f}S0kkL@m_ODY_LODOL4Ecj%o|b}Qj>mE4 zU#Z(D@`gZGsCEaUTIb<|WyraL>(YY06!fH%s=KWR8F}UNBMN^GWIzF$NoC?DCel_kD!+z)DLSzKJ7>|9N2U|eOu7{?G zc^Gh|?n((L^cb{avT(k;{a(%AjE_>%fz-e6BZ!(u4ac#Z%FS#nW4q`S6oZw2mFM;7Z*bopKm{v}tmSgiysl z2LsAX+?cQ11=)n&(zkW6FT4195}7duW<5 zaB(Qe{Z0c*`ZH&#I$f=g=jfo6!-L@^>JPLL$wwu@-U8&~wYc3~5|BhPa0^Hzw}(?( z&y!TaPX=k6fZrWz&;&RO$Q9Q^CX)wXkLi9jJEXDmsUa%BmwvKiY2j(!L8gvu~43_o%M#!HAG1aEiCMK4io!AL=Pf9{6A&x}X&0kNE3NTTgK~D{0gBG>B zvvDmV^L_~kihq774a$jvcX6VYOoE>E{K_ivreu4II|4Ri4F$97Uk#&qfYak>-%G5;ObiU<5& z8?#h%iqf~)4Wr-%5eUTI^JLH_=*Z@5T!vp{Y$aj!ZRsac*Z{1r)WWv89%VuP5 z*ZsU1_R+FlnNfwDpg$qD>bh*(>;@1MJUE_4qMxi!}mwuK3hcM$w))?4uWin-KTWhOOW&T}*+vgvyrnfg9Fzl@-#uxWJDXDJw{ zz@vTHomVWz1ytcvd4)#Tyl!iwM=;lL&(dhL#J!(z;{%hrcV_W23^)Ifk^0gjSY)q~ zLl@s=k7V<;2h{2V*Cqvm104b^0$v_vdp*RYO3jNg{p}fE^6m6A&u~Hr%~ocUlKS42 z*A%SHxy;f{SM$|(-6|tcC#bSPtyHZs>e>fgr5uCQeDNR8a0_^20U;<{#KFDzQMWY^Fc*O=m)8ctl z&;)qp0u4>L8y<~1Ie^Upuo(#pT*XsmZ3JBY)`;f9_{hzjGE6TBk&^=f`rBM~+zBdW zU*5YpB_N<@6O#VkQI4)oY}5C4_r_792$kG_KW=UhNM^xZWI%pY^Z5wtfBi?x)?Cg0 z=undUQ-Xx2fCbn(HhMw44=q_fmNMF~_}+-fygwvO;#XB+S6TgUycZJ&FWn1sC6Sl2 zey|vQ;2|Y?@&>up*GAr2#j{+ZEjEAseraU(K}5fUSrt_|tHc+Ak5fSw%a)1X)+nOm z(1y=Icr{fgPia%X0K6gJWF&&4OA5*CGN%4ql?l+;6TWKmw}F3EB=Ffe$RD)*N!L1# zwfSf#_xCdg%vXEvA{h8?9CbxEE;@L)qxV@?U)2)f?LJZdzaOu4ZAyk?4%l&^j^@XC zjW!A^##2vxujXIv&&&HsqELJzQclBN-e%0W4e}4feYyRS$q}zNZ?C^|1BxavGV>xn zCMc)JyS~PKH4+*D9l^gk3V$k{*Yyj2^@-lNmmZH82)hBdM#0IE(OS#JT?MnPzqa7Nop|dKo&ZV!bdba)!QM~@M4|YP}yNv$I)0L*ZTT)mXdL#Y%&2!3dya=fE+aGJ}PMs_hHLd7$+DN(DC7pAMA8SM)`V**@ zzp3=`{g0npZSVEeA6Yl8XfWt^Np>>}1>>gq97Ua#*Tz_nJ3X}QUfqf|$^C6BPnRwm zaXsql$7>B%2TV36A}Dck>fvAe_g?BzUiNX#K)r^em33-oRPmRn(6_R%;RQm> z!F%dTSHG7Yja^pSc=51H`Hh{OCGWonR1``&|2&RT+=Y-H1ORgXzxHa@gdh7JXYC7Z u&;6RWqI!M-@L+^dFd72z5ZGY#U;O}sLuJM%- Date: Sun, 16 Oct 2022 22:44:22 +0200 Subject: [PATCH 2/5] =?UTF-8?q?A=C3=B1ade=20.gitignore?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .gitignore | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) create mode 100644 .gitignore diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..acacdff --- /dev/null +++ b/.gitignore @@ -0,0 +1,18 @@ +translations/es/content/addresses.aux +translations/es/content/advancedSchnorr.aux +translations/es/content/appendix.aux +translations/es/content/basicConcepts.aux +translations/es/content/blockchain.aux +translations/es/content/commitments.aux +translations/es/content/escrowedMarket.aux +translations/es/content/introduction.aux +translations/es/content/multisig.aux +translations/es/content/transactions.aux +translations/es/content/txKnowledgeProofs.aux +translations/es/content/txTangle.aux +translations/es/front/abstract.aux +translations/es/main.aux +translations/es/main.log +translations/es/main.out +translations/es/main.pdf +translations/es/main.toc From f218620f2d10482b83aca4e5059faa510a8bd5b3 Mon Sep 17 00:00:00 2001 From: Jorge Maldonado Ventura Date: Sun, 16 Oct 2022 22:53:32 +0200 Subject: [PATCH 3/5] Traduce main.tex --- translations/es/main.tex | 45 ++++++++++++++++++++-------------------- 1 file changed, 23 insertions(+), 22 deletions(-) diff --git a/translations/es/main.tex b/translations/es/main.tex index fa5ca01..78deb0c 100755 --- a/translations/es/main.tex +++ b/translations/es/main.tex @@ -25,14 +25,14 @@ % ------------------------------------- \usepackage[usenames,dvipsnames]{xcolor} -% Control line spacing +% Control line spacing % ------------------------------------- % putting this between footmisc and hyperref seemed to fix broken footnote links \usepackage{setspace} \AtBeginDocument{\let~=\nobreakspace} \spacing{1.1} -% Advanced crossreferencing commands +% Advanced crossreferencing commands % ------------------------------------- % Default settings: % \usepackage[]{hyperref} @@ -91,7 +91,7 @@ \ChNameAsIs \ChNameUpperCase \ChNameVar{\Large\bf} -\ChNumVar{\Huge} +\ChNumVar{\Huge} \ChTitleVar{\LARGE} % Modify appendix and add subappendices environments @@ -131,14 +131,14 @@ \hypersetup{ - pdftitle = {Zero to Monero - Second Edition}, - pdfauthor = {koe Kurt and Sarang} + pdftitle = {De cero a Monero - Segunda Edición}, + pdfauthor = {koe, Kurt y Sarang} } \begin{document} -%\maketitle +%\maketitle % ------ Title page ------------------------ \setlength{\abovedisplayskip}{0pt} \setlength{\belowdisplayskip}{0pt} @@ -159,14 +159,15 @@ \vfill{} -{\par\centering \textsc{\huge Zero to Monero: Second Edition}\par} +{\par\centering \textsc{\huge De cero a Monero: segunda edición}\par} \bigskip \bigskip -{\par\centering \textsc{\LARGE a technical guide to a private digital currency; for beginners, amateurs, and experts}\par} +{\par\centering \textsc{\LARGE Una guía técnica para una moneda digital privada; para principiantes, aficionados y especialistas.}\par} \bigskip -{\par\centering \textsc{\LARGE Published \today{} (v2.0.0)}\par} -%{\par\centering \textsc{\LARGE \today{}, Pre-Publication Draft 1.2.0}\par} +{\par\centering \textsc{\LARGE Publicado el \today{} (v. 2.0.0)}\par} \bigskip -{\par\centering \textsc{\large koe\footnote{ukoe@protonmail.com}, Kurt M. Alonso\footnote{kurt@oktav.se}, Sarang Noether\footnote{sarang.noether@protonmail.com}}%\\(for questions and comments, please CC both authors) +{\par\centering \textsc{\large koe\footnote{ukoe@protonmail.com}, Kurt M. Alonso\footnote{kurt@oktav.se}, Sarang Noether\footnote{sarang.noether@protonmail.com}} +{\par\centering \textsc{\large Traducido por Jorge Maldonado Ventura \footnote{jorgesumle@freakspot.net}}\par} +%\\(for questions and comments, please CC both authors) \par} \vfill{} @@ -174,7 +175,7 @@ \begin{minipage}[t]{6.43in} %\textbf{DRAFT INFORMATION}: This is just a draft, and may not always be available wherever it is currently hosted. The final version will be published at \url{https://web.getmonero.org/library/}. -\textbf{License}: Zero to Monero: Second Edition is released into the public domain. + \textbf{Licencia}: \textit{De cero a Monero: segunda edición} está publicado en dominio público. \end{minipage} \end{center} @@ -185,16 +186,16 @@ \pagestyle{empty} \begin{center} \vspace*{\fill}%\vspace*{3.5cm} -{\LARGE \bfseries Abstract} +{\LARGE \bfseries Resumen} \end{center} \vspace{0.5cm} -\begin{center} +\begin{center} \begin{minipage}{5.5in} -\begin{center} \vrule width 4.5in height 0.4pt \end{center} -\parindent=0pt +\begin{center} \vrule width 4.5in height 0.4pt \end{center} +\parindent=0pt \include{front/abstract} -\begin{center} \vrule width 4.5in height 0.4pt \end{center} -\end{minipage} +\begin{center} \vrule width 4.5in height 0.4pt \end{center} +\end{minipage} \vspace*{\fill} \end{center} @@ -216,7 +217,7 @@ \include{content/introduction} -\part{Essentials} +\part{Fundamentos} \include{content/basicConcepts} \include{content/advancedSchnorr} \include{content/addresses} @@ -224,7 +225,7 @@ \part{Essentials} \include{content/transactions} \include{content/blockchain} -\part{Extensions} +\part{Extensiones} \include{content/txKnowledgeProofs} \include{content/multisig} \include{content/escrowedMarket} @@ -237,7 +238,7 @@ \part{Extensions} % -------- Bibliography ----------------------- -\addcontentsline{toc}{chapter}{Bibliography} +\addcontentsline{toc}{chapter}{Bibliografía} {\footnotesize \bibliographystyle{plain} \bibliography{back/references.bib} @@ -253,4 +254,4 @@ \part{Extensions} -\end{document} \ No newline at end of file +\end{document} From f1fbdd435b02778f0c46ae052a3a312380b66920 Mon Sep 17 00:00:00 2001 From: Jorge Maldonado Ventura Date: Thu, 22 Jun 2023 10:18:21 +0200 Subject: [PATCH 4/5] =?UTF-8?q?Resolve=20errores=20de=20generaci=C3=B3n?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- translations/es/content/appendix.tex | 74 +++++++++++------------ translations/es/content/basicConcepts.tex | 46 +++++++------- translations/es/content/blockchain.tex | 30 +++++---- translations/es/content/multisig.tex | 50 ++++++++------- translations/es/front/abstract.tex | 6 +- translations/es/main.tex | 2 +- 6 files changed, 111 insertions(+), 97 deletions(-) diff --git a/translations/es/content/appendix.tex b/translations/es/content/appendix.tex index e3ae815..5b0e2b2 100755 --- a/translations/es/content/appendix.tex +++ b/translations/es/content/appendix.tex @@ -7,10 +7,10 @@ \chapter{{\tt RCTTypeBulletproof2} Transaction Structure} \label{appendix:RCTTypeBulletproof2} -We present in this appendix a dump from a real Monero transaction of type {\tt RCTTypeBulletproof2}, +We present in this appendix a dump from a real Monero transaction of type {\tt RCTTypeBulletproof2}, together with explanatory notes for relevant fields. -The dump was obtained from the block explorer \url{https://xmrchain.net}. It can also be acquired by executing command {\tt print\_tx +hex +json} in the {\tt monerod} daemon run in non-detached mode. {\tt } is a hash of the transaction (Section \ref{subsec:transaction-id}). The first line printed shows the actual command to run.% see chapter 7 blockchain on TransactionID +The dump was obtained from the block explorer \url{https://xmrchain.net}. It can also be acquired by executing command {\tt print\_tx {\textless}TransactionID{\textgreater} +hex +json} in the {\tt monerod} daemon run in non-detached mode. {\tt {\textless}TransactionID{\textgreater}} is a hash of the transaction (Section \ref{subsec:transaction-id}). The first line printed shows the actual command to run.% see chapter 7 blockchain on TransactionID To replicate our results, readers can do the following:%\footnote{Blockchain data can also be found with a web block explorer, such as \url{https://moneroblocks.info/} or \url{https://xmrchain.net}.} \begin{enumerate} @@ -33,62 +33,62 @@ \chapter{{\tt RCTTypeBulletproof2} Transaction Structure} print_tx 84799c2fc4c18188102041a74cef79486181df96478b717e8703512c7f7f3349 Found in blockchain at height 2045821 \{ - "version": 2, - "unlock_time": 0, + "version": 2, + "unlock_time": 0, "vin": [ \{ "key": \{ - "amount": 0, + "amount": 0, "key_offsets": [ 14401866, 142824, 615514, 18703, 5949, 22840, 5572, 16439, 983, 4050, 320 - ], + ], "k_image": "c439b9f0da76ca0bb17920ca1f1f3f1d216090751752b091bef9006918cb3db4" \} \}, \{ "key": \{ - "amount": 0, + "amount": 0, "key_offsets": [ 14515357, 640505, 8794, 1246, 20300, 18577, 17108, 9824, 581, 637, 1023 - ], + ], "k_image": "03750c4b23e5be486e62608443151fa63992236910c41fa0c4a0a938bc6f5a37" \} \} - ], + ], "vout": [ \{ - "amount": 0, + "amount": 0, "target": \{ "key": "d890ba9ebfa1b44d0bd945126ad29a29d8975e7247189e5076c19fa7e3a8cb00" \} \}, \{ - "amount": 0, + "amount": 0, "target": \{ "key": "dbec330f8a67124860a9bfb86b66db18854986bd540e710365ad6079c8a1c7b0" \} \} - ], + ], "extra": [ 1, 3, 39, 58, 185, 169, 82, 229, 226, 22, 101, 230, 254, 20, 143, 37, 139, 28, 114, 77, 160, 229, 250, 107, 73, 105, 64, 208, 154, 182, 158, 200, 73, 2, 9, 1, 12, 76, 161, 40, 250, 50, 135, 231 - ], + ], "rct_signatures": \{ - "type": 4, - "txnFee": 32460000, + "type": 4, + "txnFee": 32460000, "ecdhInfo": [ \{ "amount": "171f967524e29632" \}, \{ "amount": "5c2a1a9f54ccf40b" - \}], + \}], "outPk": [ "fed8aded6914f789b63c37f9d2eb5ee77149e1aa4700a482aea53f82177b3b41", "670e086e40511a279e0e4be89c9417b4767251c5a68b4fc3deb80fdae7269c17"] - \}, + \}, "rctsig_prunable": \{ - "nbp": 1, + "nbp": 1, "bp": [ \{ - "A": "98e5f23484e97bb5b2d453505db79caadf20dc2b69dd3f2b3dbf2a53ca280216", - "S": "b791d4bc6a4d71de5a79673ed4a5487a184122321ede0b7341bc3fdc0915a796", - "T1": "5d58cfa9b69ecdb2375647729e34e24ce5eb996b5275aa93f9871259f3a1aecd", - "T2": "1101994fea209b71a2aa25586e429c4c0f440067e2b197469aa1a9a1512f84b7", - "taux": "b0ad39da006404ccacee7f6d4658cf17e0f42419c284bdca03c0250303706c03", - "mu": "cacd7ca5404afa28e7c39918d9f80b7fe5e572a92a10696186d029b4923fa200", + "A": "98e5f23484e97bb5b2d453505db79caadf20dc2b69dd3f2b3dbf2a53ca280216", + "S": "b791d4bc6a4d71de5a79673ed4a5487a184122321ede0b7341bc3fdc0915a796", + "T1": "5d58cfa9b69ecdb2375647729e34e24ce5eb996b5275aa93f9871259f3a1aecd", + "T2": "1101994fea209b71a2aa25586e429c4c0f440067e2b197469aa1a9a1512f84b7", + "taux": "b0ad39da006404ccacee7f6d4658cf17e0f42419c284bdca03c0250303706c03", + "mu": "cacd7ca5404afa28e7c39918d9f80b7fe5e572a92a10696186d029b4923fa200", "L": [ "d06404fc35a60c6c47a04e2e43435cb030267134847f7a49831a61f82307fc32", "c9a5932468839ee0cda1aa2815f156746d4dce79dab3013f4c9946fce6b69eff", "efdae043dcedb79512581480d80871c51e063fe9b7a5451829f7a7824bcc5a0b", @@ -96,7 +96,7 @@ \chapter{{\tt RCTTypeBulletproof2} Transaction Structure} "81736ed768f57e7f8d440b4b18228d348dce1eca68f969e75fab458f44174c99", "695711950e076f54cf24ad4408d309c1873d0f4bf40c449ef28d577ba74dd86d", "4dc3147619a6c9401fec004652df290800069b776fe31b3c5cf98f64eb13ef2c" - ], + ], "R": [ "7650b8da45c705496c26136b4c1104a8da601ea761df8bba07f1249495d8f1ce", "e87789fbe99a44554871fcf811723ee350cba40276ad5f1696a62d91a4363fa6", "ebf663fe9bb580f0154d52ce2a6dae544e7f6fb2d3808531b0b0749f5152ddbf", @@ -104,12 +104,12 @@ \chapter{{\tt RCTTypeBulletproof2} Transaction Structure} "dc0dcb2e696e11e4b62c20b6bfcb6182290748c5de254d64bf7f9e3c38fb46c9", "101e2271ced03b229b88228d74b36088b40c88f26db8b1f9935b85fb3ab96043", "b14aae1d35c9b176ac526c23f31b044559da75cf95bc640d1005bfcc6367040b" - ], - "a": "4809857de0bd6becdb64b85e9dfbf6085743a8496006b72ceb81e01080965003", - "b": "791d8dc3a4ddde5ba2416546127eb194918839ced3dea7399f9c36a17f36150e", + ], + "a": "4809857de0bd6becdb64b85e9dfbf6085743a8496006b72ceb81e01080965003", + "b": "791d8dc3a4ddde5ba2416546127eb194918839ced3dea7399f9c36a17f36150e", "t": "aace86a7a1cbdec3691859fa07fdc83eed9ca84b8a064ca3f0149e7d6b721c03" \} - ], + ], "MGs": [ \{ "ss": [[ "d7a9b87cfa74ad5322eedd1bff4c4dca08bcff6f8578a29a8bc4ad6789dee106", "f08e5dfade29d2e60e981cb561d749ea96ddc7e6855f76f9b807842d1a17fe00"], @@ -132,7 +132,7 @@ \chapter{{\tt RCTTypeBulletproof2} Transaction Structure} ["80bc2da5fc5951f2c7406fce37a7aa72ffef9cfa21595b1b68dfab4b7b9f9f0c", "c37137898234f00bce00746b131790f3223f97960eefe67231eb001092f5510c"], ["01c89e07571fd365cac6744b34f1b44e06c1c31cbf3ee4156d08309345fdb20e", - "a35c8786695a86c0a4e677b102197a11dadc7171dd8c2e1de90d828f050ec00f"]], + "a35c8786695a86c0a4e677b102197a11dadc7171dd8c2e1de90d828f050ec00f"]], "cc": "0d8b70c600c67714f3e9a0480f1ffc7477023c793752c1152d5df0813f75ff0f" \}, \{ "ss": [[ "4536e585af58688b69d932ef3436947a13d2908755d1c644ca9d6a978f0f0206", @@ -156,7 +156,7 @@ \chapter{{\tt RCTTypeBulletproof2} Transaction Structure} ["ab31972bf1d2f904d6b0bf18f4664fa2b16a1fb2644cd4e6278b63ade87b6d09", "1efb04fe9a75c01a0fe291d0ae00c716e18c64199c1716a086dd6e32f63e0a07"], ["a6f4e21a27bf8d28fc81c873f63f8d78e017666adbf038da0b83c2ad04ef6805", - "c02103455f93c2d7ec4b7152db7de00d1c9e806b1945426b6773026b4a85dd03"]], + "c02103455f93c2d7ec4b7152db7de00d1c9e806b1945426b6773026b4a85dd03"]], "cc": "d5ac037bb78db41cf924af713b7379c39a4e13901d3eac017238550a1a3b910a" \}], "pseudoOuts": [ "b313c1ae9ca06213684fbdefa9412f4966ad192bc0b2f74ed1731381adb7ab58", @@ -168,11 +168,11 @@ \chapter{{\tt RCTTypeBulletproof2} Transaction Structure} \section*{Transaction components} - + \begin{itemize} \item (line 2) - The command {\tt print\_tx} would report the block where it found the transaction, which we replicate here for demonstration purposes. \item {\tt version} (line 4) - Transaction format/era version; `2' corresponds to RingCT. - \item {\tt unlock\_time} (line 5) - Prevents a transaction's outputs from being spent until the time has past. It is either a block height, or a UNIX timestamp if the number is larger than the beginning of UNIX time. It defaults to zero when no limit is specified. + \item {\tt unlock\_time} (line 5) - Prevents a transaction's outputs from being spent until the time has past. It is either a block height, or a UNIX timestamp if the number is larger than the beginning of UNIX time. It defaults to zero when no limit is specified. \item {\tt vin} (line 6-23) - List of inputs (there are two here) \item {\tt amount} (line 8) - Deprecated (legacy) amount field for type 1 transactions \item {\tt key\_offset} (line 9) - This allows verifiers to find ring member keys and commitments in the blockchain, and makes it obvious those members are legitimate. The first offset is absolute within the blockchain history, and each subsequent offset is relative to the previous. For example, with real offsets \{7,11,15,20\}, the blockchain records \{7,4,4,5\}. Verifiers compute the last offset like (7+4+4+5 = 20) (Section \ref{subsec:space-and-ver-rcttypefull}). @@ -241,7 +241,7 @@ \chapter{Block Content} \} ], "extra": [ 1, 89, 148, 148, 232, 110, 49, 77, 175, 158, 102, 45, 72, 201, 193, - 18, 142, 202, 224, 47, 73, 31, 207, 236, 251, 94, 179, 190, 71, 72, 251, 110, + 18, 142, 202, 224, 47, 73, 31, 207, 236, 251, 94, 179, 190, 71, 72, 251, 110, 134, 2, 8, 1, 242, 62, 180, 82, 253, 252, 0 ], "rct_signatures": \{ @@ -329,8 +329,8 @@ \chapter{Genesis Block} \} \} ], - "extra": [ 1, 119, 103, 170, 252, 222, 155, 224, 13, 207, 208, 152, 113, 94, 188, - 247, 244, 16, 218, 235, 197, 130, 253, 166, 157, 36, 162, 142, 157, 11, 200, 144, + "extra": [ 1, 119, 103, 170, 252, 222, 155, 224, 13, 207, 208, 152, 113, 94, 188, + 247, 244, 16, 218, 235, 197, 130, 253, 166, 157, 36, 162, 142, 157, 11, 200, 144, 209 ], "signatures": [ ] @@ -357,4 +357,4 @@ \section*{Genesis block components} \end{itemize} -\end{appendices} \ No newline at end of file +\end{appendices} diff --git a/translations/es/content/basicConcepts.tex b/translations/es/content/basicConcepts.tex index 2f64293..383c7d9 100755 --- a/translations/es/content/basicConcepts.tex +++ b/translations/es/content/basicConcepts.tex @@ -1,12 +1,12 @@ -\chapter{Basic Concepts} +\chapter{Conceptos básicos} \label{chapter:basicConcepts} %----------NOTATION -\section{A few words about notation} +\section{Unas palabras sobre la notación} -A focal objective of this report was to collect, review, correct, and homogenize all existing information concerning the inner workings of the Monero cryptocurrency. And, at the same time supply all the necessary details to present the material in a constructive and single-threaded manner. +Un objetivo central de este informe ha sido recoger, revisar, corregir y homogeneizar toda la información existente en relación al funcionamiento interno de la criptomoneda Monero; y, al mismo tiempo, proporcionar todos los detalles necesarios para presentar el material de forma constructiva y con un solo hilo. An important instrument to achieve this was to settle for a number of notational conventions. Among others, we have used: @@ -24,7 +24,7 @@ \section{A few words about notation} Elliptic curve points are normally denoted by pairs \((x, y)\), and can therefore be represented with two integers. However, in the world of cryptography it is common to apply {\em point compression} techniques, which allow representing a point using only the space of one coordinate. For our conceptual approach it is often accessory whether point compression is used or not, but most of the time it is implicitly assumed.\\ -We\marginnote{src/crypto/ {\tt keccak.c}} have also used cryptographic hash functions freely without specifying any concrete algorithms. In the case of Monero it will typically be a \(\mathit{Keccak}\)\footnote{\label{kekkak_note}The Keccak hashing algorithm forms the basis for the NIST standard {\em SHA-3} \cite{nist-sha3}.} variant, but if not explicitly mentioned then it is not important to the theory. +We\marginnote{src/crypto/ {\tt keccak.c}} have also used cryptographic hash functions freely without specifying any concrete algorithms. In the case of Monero it will typically be a \(\mathit{Keccak}\)\footnote{\label{kekkak_note}The Keccak hashing algorithm forms the basis for the NIST standard {\em SHA-3} \cite{nist-sha3}.} variant, but if not explicitly mentioned then it is not important to the theory. A cryptographic hash function (henceforth simply `hash function', or `hash') takes in some message $\mathfrak{m}$ of arbitrary length and returns a hash $h$ (or `message digest') of fixed length, with each possible output equiprobable for a given input. Cryptographic hash functions are difficult to reverse, have an interesting feature known as the {\em large avalanche effect} which can cause very similar messages to produce very dissimilar hashes, and it is hard to find two messages with the same message digest. @@ -55,10 +55,10 @@ \subsection{Modular addition and multiplication} \item Compute $x = n-a$. If $x > b$ then $c = a+b$, otherwise $c = b - x$. \end{itemize} -We can use modular addition to achieve modular multiplication ($a*b \pmod n = c$) with an algorithm called `double-and-add'. Let us demonstrate by example. Say we want to do $7*8 \pmod 9 = 2$. It is the same as +We can use modular addition to achieve modular multiplication ($a*b \pmod n = c$) with an algorithm called `double-and-add'. Let us demonstrate by example. Say we want to do $7*8 \pmod 9 = 2$. It is the same as \[7*8 = 8+8+8+8+8+8+8 \pmod 9\] -Now break this into groups of two. +Now break this into groups of two. \[(8+8) + (8+8) + (8+8) + 8\] And again, by groups of two. @@ -66,7 +66,7 @@ \subsection{Modular addition and multiplication} The total number of $+$ point operations falls from 6 to 4 because we only need to find $(8+8)$ once.\footnote{The effect of double-and-add becomes apparent with large numbers. For example, with $2^{15} * 2^{30}$ straight addition would require about $2^{15}$ $+$ operations, while double-and-add only requires 15!}\\ -Double-and-add is implemented by converting the first number (the `multiplicand' $a$) to binary (in our example, 7 $\rightarrow$ [0111]), then going through the binary array and doubling and adding. +Double-and-add is implemented by converting the first number (the `multiplicand' $a$) to binary (in our example, 7 $\rightarrow$ [0111]), then going through the binary array and doubling and adding. Let's make an array $A = [0111]$ and index it 3,2,1,0.\footnote{This is known as `LSB 0' numbering, since the least significant bit has index 0. We will use `LSB 0' for the rest of this chapter. The point here is clarity, not accurate conventions.} A[0] = 1 is the first element of A and is the least significant bit. We set a result variable to be initially $r = 0$, and set a sum variable to be initially $s = 8$ (more generally, we start with $s = b$). We follow this algorithm: \begin{enumerate} @@ -127,7 +127,7 @@ \subsection{Modular multiplicative inverse} We can use square-and-multiply to compute the modular multiplicative inverse when $n$ is a prime number because of {\em Fermat's little theorem}:\footnote{\label{inverse_rule_note}The modular multiplicative inverse has a rule stating:\\ {\em If $a c \equiv b \pmod{n}$ with $a$ and $n$ relatively prime, the solution to this linear congruence is given by \(c = a^{-1} b \pmod{n}\).}\cite{wiki-modular-arithmetic}\\ It means we can do $c = a^{-1} b \pmod n \rightarrow ca \equiv b \pmod n \rightarrow a \equiv c^{-1} b \pmod n$.}\vspace{.175cm} -\begin{align*} +\begin{align*} a^{n-1} &\equiv 1 \pmod{n} \\ a*a^{n-2} &\equiv 1 \pmod{n} \\ c \equiv a^{n-2} &\equiv a^{-1} \pmod{n} @@ -191,7 +191,7 @@ \subsection{What are elliptic curves?} Let \(P_1 = (x_1, y_1)\) and \(P_2 = (x_2, y_2)\) be two points belonging to a Twisted Edwards elliptic curve (henceforth known simply as an EC). We define addition on points by defining $P_1 + P_2 = (x_1, y_1) + (x_2, y_2)$ as the point $P_3 = (x_3, y_3)$ where\footnote{Typically elliptic curve points are converted into projective coordinates\marginnote{src/crypto/ crypto\_ops\_ builder/ ref10Comm- entedComb- ined/\\ ge.h} prior to curve operations like point addition, in order to avoid performing field inversions for efficiency. \cite{ecc-projective}}\vspace{.175cm} \begin{align*} x_3 & = \frac{x_1 y_2 + y_1 x_ 2}{1 + d x_1 x_2 y_1 y_2} \pmod{q} \\ -y_3 & = \frac{y_1 y_2 - a x_1 x_2}{1 - d x_1 x_2 y_1 y_2} \pmod{q} +y_3 & = \frac{y_1 y_2 - a x_1 x_2}{1 - d x_1 x_2 y_1 y_2} \pmod{q} \end{align*} These formulas for addition also apply for point doubling; that is, when \(P_1 = P_2\). To subtract a point, invert its coordinates over the y-axis, $(x,y) \rightarrow (-x,y)$ \cite{Bernstein2008}, and use point addition. Recall that `negative' elements $-x$ of $\mathbb{F}_q$ are really $-x \pmod{q}$. @@ -216,7 +216,7 @@ \subsection{What are elliptic curves?} \item Find all the divisors of $N$. \item For every divisor $n$ of $N$, compute $n P$. \item The smallest $n$ such that $n P = 0$ is the order $u$ of the subgroup. -\end{enumerate} +\end{enumerate} ECs\marginnote{{\tt ge}: group element} selected for cryptography typically have $N = hl$, where $l$ is some sufficiently large (such as 160 bits) prime number and $h$ is the so-called {\em cofactor} which could be as small as 1 or 2.\footnote{EC with small cofactors allow relatively faster point addition, etc. \cite{Bernstein2008}.} One point in the subgroup of size $l$ is usually selected to be the generator $G$ as a convention. For every other point $P$ in that subgroup there exists an integer $0 < n \leq l$ satisfying $P = n G$. @@ -255,7 +255,7 @@ \subsection{Public key cryptography with elliptic curves} \label{ec:keys} Public key cryptography algorithms can be devised in a way analogous to modular arithmetic. -Let \(k\) be a randomly selected number satisfying \(0 < k < l\), and call it a {\em private key}.\footnote{The private key is sometimes known as a {\em secret key}. This lets us abbreviate: pk = public key, sk = secret key.} Calculate the corresponding {\em public key} \(K\) (an EC point) with the scalar product \(k G = K\). +Let \(k\) be a randomly selected number satisfying \(0 < k < l\), and call it a {\em private key}.\footnote{The private key is sometimes known as a {\em secret key}. This lets us abbreviate: pk = public key, sk = secret key.} Calculate the corresponding {\em public key} \(K\) (an EC point) with the scalar product \(k G = K\). Due to the {\em discrete logarithm problem} (DLP) we cannot easily deduce \(k\) from \(K\) alone. This property allows us to use the values \((k, K)\) in standard public key cryptography algorithms. @@ -273,7 +273,7 @@ \subsection{Diffie-Hellman key exchange with elliptic curves} Alice could privately calculate \(S = k_A K_B\), and Bob \(S = k_B K_A\), allowing them to use this single value as a shared secret. For example, if Alice has a message $m$ to send Bob, she could hash the shared secret \(h = \mathcal{H}(S)\), compute $x = m + h$, and send $x$ to Bob. Bob computes $h' = \mathcal{H}(S)$, calculates $m = x - h'$, and learns $m$. -\end{enumerate} +\end{enumerate} An external observer would not be able to easily calculate the shared secret due to the `Diffie-Hellman Problem' (DHP), which says finding $S$ from $K_A$ and $K_B$ is very difficult. Also, the DLP prevents them from finding $k_A$ or $k_B$.\footnote{The DHP is thought to be of at least similar difficulty to the DLP, although it has not been proven. \cite{diffie-hellman-problem}} @@ -381,7 +381,7 @@ \subsubsection*{Why it works} \section{Curve Ed25519} \label{Ed25519_section} -Monero uses a particular Twisted Edwards elliptic curve for cryptographic operations, {\em Ed25519}, the {\em birational equivalent}\footnote{\label{birational_note}Without giving further details, birational equivalence can be thought of as an isomorphism expressible using rational terms.} +Monero uses a particular Twisted Edwards elliptic curve for cryptographic operations, {\em Ed25519}, the {\em birational equivalent}\footnote{\label{birational_note}Without giving further details, birational equivalence can be thought of as an isomorphism expressible using rational terms.} of the Montgomery curve {\em Curve25519}. Both Curve25519 and Ed25519 were released by Bernstein {\em et al.} \cite{Bernstein2008, Bernstein2012, Bernstein2007}.\footnote{Dr. Bernstein also developed an encryption scheme known as ChaCha \cite{Bernstein_chacha,chacha-irtf}, which the primary Monero implementation uses to encrypt\marginnote{src/wallet/ ringdb.cpp} certain sensitive information related to users' wallets.} @@ -389,7 +389,7 @@ \section{Curve Ed25519} The\marginnote{src/crypto/ crypto\_ops\_ builder/ ref10Comm- entedComb- ined/\\ ge.h} curve is defined over the prime field \(\mathbb{F}_{2^{255} - 19}\) (i.e. $q = 2^{255}-19$) by means of the following equation:\vspace{.175cm} \[-x^2 + y^2 = 1 - \frac{121665}{121666} x^2 y^2\] -This curve addresses many concerns raised by the cryptography community.\footnote{Even if a curve appears to have no cryptographic security problems, it's possible the person/organization that created it knows a secret issue that only crops up in very rare curves. Such a person may have to randomly generate many curves in order to find one with a hidden weakness and no known weaknesses. If reasonable explanations are required for curve parameters, then it becomes even more difficult to find weak curves that will be accepted by the cryptographic community. Curve Ed25519 is known as a `fully rigid' curve, which means its generation process was fully explained. \cite{elliptic-curve-rigidity}} It is well known that NIST\footnote{\label{NIST_note}National Institute of Standards and Technology, \url{https://www.nist.gov/}} +This curve addresses many concerns raised by the cryptography community.\footnote{Even if a curve appears to have no cryptographic security problems, it's possible the person/organization that created it knows a secret issue that only crops up in very rare curves. Such a person may have to randomly generate many curves in order to find one with a hidden weakness and no known weaknesses. If reasonable explanations are required for curve parameters, then it becomes even more difficult to find weak curves that will be accepted by the cryptographic community. Curve Ed25519 is known as a `fully rigid' curve, which means its generation process was fully explained. \cite{elliptic-curve-rigidity}} It is well known that NIST\footnote{\label{NIST_note}National Institute of Standards and Technology, \url{https://www.nist.gov/}} standard algorithms have issues. For example, it has recently become clear the NIST standard random number generation algorithm PNRG (the version based on elliptic curves) is flawed and contains a potential backdoor \cite{hales2014nsa}. Seen from a broader perspective, standardization authorities like NIST lead to a cryptographic monoculture, introducing a point of centralization. A great example of this was illustrated when the NSA used its influence over NIST to weaken an international cryptographic standard \cite{NSA-NIST}. Curve Ed25519 is not subject to any patents (see \cite{ECC-patents} for a discussion on this subject), and the team behind it has @@ -419,7 +419,7 @@ \subsection{Point compression} \begin{description} \item[Encoding] We\marginnote{src/crypto/ crypto\_ops\_ builder/ ref10Comm- entedComb- ined/\\ ge\_to- bytes.c} set the most significant bit of $y$ to 0 if $x$ is even, and 1 if it is odd. The resulting value $y’$ will represent the curve point. - + \item[Decoding] \hfill \begin{enumerate} \item Retrieve\marginnote{ge\_from- bytes.c}[2.05cm] the compressed point $y’$, then copy its most significant bit to the parity bit $b$ before setting it to 0. Now it is the original $y$ again. @@ -445,18 +445,18 @@ \subsection{EdDSA signature algorithm} Among other things, instead of generating random integers every time, it uses a hash value derived from the private key of the signer and the message itself. This circumvents security flaws related to the implementation of random number generators. Also, another goal of the algorithm is to avoid accessing secret or unpredictable memory locations to prevent so-called {\em cache timing attacks} \cite{Bernstein2012}. -We provide here an outline of the steps performed by the algorithm. A complete description and sample implementation in the Python language can be found in \cite{rfc8032}. +We provide here an outline of the steps performed by the algorithm. A complete description and sample implementation in the Python language can be found in \cite{rfc8032}. \subsubsection*{Signature} \begin{enumerate} - \item Let \(h_k\) be a hash \(\mathcal{H}(k)\) of the signer's private key \(k\). + \item Let \(h_k\) be a hash \(\mathcal{H}(k)\) of the signer's private key \(k\). Compute \(\alpha\) as a hash \(\alpha = \mathcal{H}(h_k, \mathfrak{m})\) of the hashed private key and message. Depending on implementation, $\mathfrak{m}$ could be the actual message or its hash \cite{rfc8032}. - + \item Calculate \(\alpha G\) and the challenge $ch = \mathcal{H}([\alpha G], K, \mathfrak{m})$. \item Calculate the response \(r = \alpha + ch \cdot k \). - + \item The signature is the pair \((\alpha G, r)\). \end{enumerate} @@ -465,7 +465,7 @@ \subsubsection*{Verification} \begin{enumerate} \item Compute \(ch' = \mathcal{H}([\alpha G], K, \mathfrak{m})\). - + \item If the equality \(2^c r G \stackrel{?}{=} 2^c \alpha G + 2^c ch'*K \) holds then the signature is valid. \end{enumerate} @@ -478,7 +478,7 @@ \subsubsection*{Verification} \subsubsection*{Why it works} \begin{align*} 2^c r G &= 2^c (\alpha + \mathcal{H}([\alpha G], K, \mathfrak{m}) \cdot k) \cdot G \\ - &= 2^c \alpha G + 2^c \mathcal{H}([\alpha G], K, \mathfrak{m}) \cdot K + &= 2^c \alpha G + 2^c \mathcal{H}([\alpha G], K, \mathfrak{m}) \cdot K \end{align*} \subsubsection*{Binary representation} @@ -511,9 +511,9 @@ \section{Binary operator XOR} In the context of computer science, XOR is equivalent to bit addition modulo 2. For example, the XOR of two bit pairs: \begin{alignat*}{1} \text{XOR}(\{1,1\},\{1,0\}) &= \{1+1,1+0\} \pmod 2 \\ - &= \{0,1\} + &= \{0,1\} \end{alignat*} Each of these also produce $\{0,1\}$: $\text{XOR}(\{1,0\},\{1,1\})$, $\text{XOR}(\{0,0\},\{0,1\})$, and $\text{XOR}(\{0,1\},\{0,0\})$. For XOR inputs with $b$ bits, there are $2^{\text{b}} - 1$ other combinations of inputs that would make the same output. This means if $C = \text{XOR}(A,B)$ and input $A \in_R \{0,...,2^{\text{b}-1}\}$, an observer who learned $C$ would gain no information about $B$. -At the same time, anyone who knows two of the elements in $\{A,B,C\}$, where $C = \text{XOR}(A,B)$, can calculate the third element, such as $A = \text{XOR}(B,C)$. XOR indicates if two elements are different or the same, so knowing $C$ and $B$ is enough to expose $A$. A careful examination of the truth table reveals this vital feature.\footnote{One interesting application of XOR (unrelated to Monero) is swapping two bit registers without a third register. We use the symbol $\oplus$ to indicate an XOR operation. $A \oplus A = 0$, so after three XOR operations between the registers: $\{A, B\} \rightarrow{} \{[A \oplus B], B\} \rightarrow{} \{[A \oplus B], B \oplus [A \oplus B]\} = \{[A \oplus B], A \oplus 0\} = \{[A \oplus B], A\} \rightarrow{} \{[A \oplus B] \oplus A, A\} = \{B, A\}$.} \ No newline at end of file +At the same time, anyone who knows two of the elements in $\{A,B,C\}$, where $C = \text{XOR}(A,B)$, can calculate the third element, such as $A = \text{XOR}(B,C)$. XOR indicates if two elements are different or the same, so knowing $C$ and $B$ is enough to expose $A$. A careful examination of the truth table reveals this vital feature.\footnote{One interesting application of XOR (unrelated to Monero) is swapping two bit registers without a third register. We use the symbol $\oplus$ to indicate an XOR operation. $A \oplus A = 0$, so after three XOR operations between the registers: $\{A, B\} \rightarrow{} \{[A \oplus B], B\} \rightarrow{} \{[A \oplus B], B \oplus [A \oplus B]\} = \{[A \oplus B], A \oplus 0\} = \{[A \oplus B], A\} \rightarrow{} \{[A \oplus B] \oplus A, A\} = \{B, A\}$.} diff --git a/translations/es/content/blockchain.tex b/translations/es/content/blockchain.tex index ff298be..f58f69b 100755 --- a/translations/es/content/blockchain.tex +++ b/translations/es/content/blockchain.tex @@ -48,8 +48,8 @@ \subsection{Simple blockchain} First we need all computers, henceforth referred to as {\em nodes}, to agree on the order of transactions. -Let's say a currency started with a `genesis' declaration: ``Let the SampleCoin begin!". We call this message a `block', and its block hash is \vspace{.175cm} -\[\mathit{BH}_G = \mathcal{H}(\textrm{``Let the SampleCoin begin!"})\] +Let's say a currency started with a `genesis' declaration: «Let the SampleCoin begin!». We call this message a `block', and its block hash is \vspace{.175cm} +\[\mathit{BH}_G = \mathcal{H}(\textrm{«Let the SampleCoin begin!»})\] Every time a node receives some transactions, they use hashes of those transactions, $\mathit{TH}$, like messages, along with the previous block's hash, and compute new block hashes\vspace{.175cm} \[\mathit{BH}_1 = \mathcal{H}(\mathit{BH}_G, \mathit{TH}_1, \mathit{TH}_2,...)\] @@ -77,7 +77,7 @@ \subsection{Mining a block} Let's imagine a hash function $\mathcal{H}_i(x)$ which outputs a number from 1 to 100: $\mathcal{H}_i(x) \in^D_R \{1,...,100\}$.\footnote{We use $\in^D_R$ to say the output is deterministically random.} Given some $x$, $\mathcal{H}_i(x)$ selects the same `random' number from \{$1,...,100$\} every time you calculate it. It takes 1 minute to calculate $\mathcal{H}_i(x)$. -Say we are given a message $\mathfrak{m}$, and told to find a `nonce' $n$ (some integer) such that $\mathcal{H}_i(\mathfrak{m},n)$ outputs a number less than or equal to the {\em target} $t = 5$ (i.e. $\mathcal{H}_i(\mathfrak{m},n) \in \{1,...,5\}$). +Say we are given a message $\mathfrak{m}$, and told to find a `nonce' $n$ (some integer) such that $\mathcal{H}_i(\mathfrak{m},n)$ outputs a number less than or equal to the {\em target} $t = 5$ (i.e. $\mathcal{H}_i(\mathfrak{m},n) \in \{1,...,5\}$). Since only $1/20$\nth of outputs from $\mathcal{H}_i(x)$ will meet the target, it should take around 20 guesses of $n$ to find one that works (and hence 20 minutes of computing time). @@ -151,7 +151,7 @@ \section{Money supply} First, the currency's creators can conjure coins and distribute them to people in the genesis message. This is often called an `airdrop'. Sometimes creators give themselves a large amount in a so-called `pre-mine'. \cite{premine-description} -Second, the currency can be automatically distributed as reward for mining a block, much like mining for gold. There are two types here. In the Bitcoin model the total possible supply is capped. Block rewards slowly decline to zero, after which no more money is ever made. In the inflation model supply increases indefinitely. +Second, the currency can be automatically distributed as reward for mining a block, much like mining for gold. There are two types here. In the Bitcoin model the total possible supply is capped. Block rewards slowly decline to zero, after which no more money is ever made. In the inflation model supply increases indefinitely. Monero is based on a currency known as Bytecoin that had a sizeable pre-mine, followed by block rewards \cite{monero-history}. Monero had no pre-mine, and as we will see, its block rewards slowly decline to a small amount after which all new blocks reward that same amount, making Monero inflationary. @@ -167,7 +167,7 @@ \subsection{Block reward} \subsubsection*{Bit shifting} -Bit shifting is used for calculating the base block reward (as we will see in Section \ref{subsec:penalty}, the actual block reward can sometimes be reduced below the base amount). +Bit shifting is used for calculating the base block reward (as we will see in Section \ref{subsec:penalty}, the actual block reward can sometimes be reduced below the base amount). Suppose we have an integer A = 13 with bit representation [1101]. If we shift the bits of A down by 2 using the bitwise shift right operator, denoted A $>>$ 2, we get [0011].01, which equals 3.25. In reality that last part gets thrown away - `shifted' into oblivion, leaving us with [0011] = 3.\footnote{Bitwise shift right by $n$ bits is equivalent to integer division by $2^n$.} @@ -190,7 +190,7 @@ \subsubsection*{Calculating base block reward for Monero} \subsection{Dynamic block weight} \label{subsec:dynamic-block-weight} -It would be nice to mine every new transaction into a block right away. What if someone submits a lot of transactions maliciously? The blockchain, storing every transaction, would quickly grow enormous. +It would be nice to mine every new transaction into a block right away. What if someone submits a lot of transactions maliciously? The blockchain, storing every transaction, would quickly grow enormous. One mitigation is a fixed block size (in bytes), so the number of transactions per block is limited. What if honest transaction volume rises? Each transaction author would bid for a spot in new blocks by offering fees to miners. Miners would focus on mining transactions with the highest fees. As transaction volume increases, fees would become prohibitively large for transactions of small amounts (such as Alice buying an apple from Bob). Only people willing to outbid everyone else would get their transactions into the blockchain.\footnote{Bitcoin has a history of overloaded transaction volume. This website (\url{https://bitcoinfees.info/}) charts the ridiculous fee levels encountered (up to the equivalent of 35\$ per transaction at one point).}\\ @@ -392,11 +392,12 @@ \subsection{Transaction ID} \end{itemize} In this tree diagram the black arrow indicates a hash of inputs. - + +\begin{otherlanguage}{english} \begin{center} \begin{forest} forked edges, - for tree = {grow'=90, + for tree = {grow'=90, edge = {<-, > = triangle 60}, fork sep = 4.5 mm, l sep = 8 mm, @@ -408,8 +409,9 @@ \subsection{Transaction ID} [$\mathcal{H}_n$(TX Prefix)] [$\mathcal{H}_n$(TX Stuff)] [$\mathcal{H}_n$(Signatures)] ] - \end{forest} + \end{forest} \end{center} +\end{otherlanguage} In place of an `input', a miner transaction records the block height of its block. This ensures the miner transaction's ID, which is simply a normal transaction ID except with $\mathcal{H}_n$(Signatures) $\rightarrow$ 0, is always unique, for simpler ID-searching. @@ -423,10 +425,11 @@ \subsection{Merkle tree} An example Merkle tree based on four transactions and a miner transaction is diagrammed in Figure \ref*{chapter:blockchain}.1.\footnote{A bug in Monero's Merkle tree code led to a serious, though apparently non-critical, real-world attack on September 4\nth, 2014 \cite{MRL-0002-merkle-problem}.} +\begin{otherlanguage}{english} \begin{center} \begin{forest} forked edges, - for tree = {grow'=90, + for tree = {grow'=90, edge = {<-, > = triangle 60}, fork sep = 4.5 mm, l sep = 8 mm, @@ -434,11 +437,11 @@ \subsection{Merkle tree} }, sn edges, where n children=0{tier=terminus}{}, - [Merkle Root + [Merkle Root [$Hash$ B [Transaction ID \\1] [Transaction ID \\2] - ] + ] [$Hash$ C [Transaction ID \\3] [$Hash$ A @@ -452,6 +455,7 @@ \subsection{Merkle tree} {\emph{Figure \ref*{chapter:blockchain}.1: Merkle Tree}}; \end{forest} \end{center} +\end{otherlanguage} A Merkle root is inherently a reference to all its included transactions. @@ -484,4 +488,4 @@ \subsection{Blocks} \item Nonce: 4 bytes, can extend its effective size with the miner tx extra field's extra nonce\footnote{Within each transaction is an `extra' field which can contain more-or-less arbitrary data. If a miner needs a wider range of nonces than just 4 bytes, they can add or alter data in their miner tx's extra field to `extend' the nonce size. \cite{extra-field-stackexchange}} \item Miner transaction: 32 bytes for a one-time address, 32 bytes for a transaction public key (+1 byte for its `extra' tag), and variable integers for the unlock time, corresponding block's height, and amount. After downloading the blockchain, we also need 32 bytes to store an amount commitment $C = 1G + a H$ (only for post-RingCT miner tx amounts). \item Transaction IDs: 32 bytes each -\end{itemize} \ No newline at end of file +\end{itemize} diff --git a/translations/es/content/multisig.tex b/translations/es/content/multisig.tex index f58fde6..464d1f3 100755 --- a/translations/es/content/multisig.tex +++ b/translations/es/content/multisig.tex @@ -138,7 +138,7 @@ \subsection*{Signature} \item and sends $C^{\alpha}_e$ to the other participants securely. \end{enumerate} \item Once all commitments $C^{\alpha}_e$ have been collected, each participant sends their $\alpha_e G$ to the other participants securely. They must verify that $C^{\alpha}_e \stackrel{?}{=} \mathcal{H}_n(T_{com},\alpha_e G)$ for all other participants. - \item Each participant computes + \item Each participant computes \[ \alpha G = \sum_e \alpha_e G \] \item Each participant $e \in \{1,...,N\}$ does the following:\footnote{As in Section \ref{sec:schnorr-fiat-shamir}, it is important not to reuse $\alpha_e$ for different challenges $c$. This means to reset a multisignature process where responses have been sent out, it should start again from the beginning with new $\alpha_e$ values.} \begin{enumerate} @@ -146,7 +146,7 @@ \subsection*{Signature} \item defines their response component $r_e = \alpha_e - c* k^{agg}_e \pmod l$, \item and sends $r_e$ to the other participants securely. \end{enumerate} - \item Each participant computes + \item Each participant computes \[ r = \sum_e r_e\] \item Any participant can publish the signature $\sigma(\mathfrak{m}) = (c,r)$. \end{enumerate} @@ -190,17 +190,17 @@ \section{MLSTAG Ring Confidential signatures for Monero} Recalling Section \ref{sec:multi_out_transactions}, a one-time address assigning ownership of a transaction's $t$\nth output to whoever has public address $(K^v_t,K^s_t)$ goes like this\vspace{.175cm} \begin{align*} - K_t^o &= \mathcal{H}_n(r K_t^v, t)G + K_t^s = (\mathcal{H}_n(r K_t^v, t) + k_t^s)G \\ + K_t^o &= \mathcal{H}_n(r K_t^v, t)G + K_t^s = (\mathcal{H}_n(r K_t^v, t) + k_t^s)G \\ k_t^o &= \mathcal{H}_n(r K_t^v, t) + k_t^s -\end{align*} +\end{align*} We can update our notation for outputs received by a group address $(K^{v,grp}_t,K^{s,grp}_t)$:\vspace{.175cm} \begin{align*} - K^{o,grp}_t &= \mathcal{H}_n(r K^{v,grp}_t, t)G + K^{s,grp}_t \\ + K^{o,grp}_t &= \mathcal{H}_n(r K^{v,grp}_t, t)G + K^{s,grp}_t \\ k^{o,grp}_t &= \mathcal{H}_n(r K^{v,grp}_t, t) + k^{s,grp}_t \end{align*} -Just as before, anyone with $k^{v,grp}_t$ and $K^{s,grp}_t$ can discover $K^{o,grp}_t$ is their address's owned output, and can decode the Diffie-Hellman term for output amount and reconstruct the corresponding commitment mask (Section \ref{sec:pedersen_monero}). +Just as before, anyone with $k^{v,grp}_t$ and $K^{s,grp}_t$ can discover $K^{o,grp}_t$ is their address's owned output, and can decode the Diffie-Hellman term for output amount and reconstruct the corresponding commitment mask (Section \ref{sec:pedersen_monero}). This also means multisig subaddresses are possible (Section \ref{sec:subaddresses}). Multisig transactions using funds received to a subaddress require some fairly straightforward modifications to the following algorithms, which we mention in footnotes.\footnote{Multisig subaddresses are supported in Monero.} @@ -343,7 +343,7 @@ \subsection*{Verification} \end{enumerate} - + \section{Smaller thresholds} \label{sec:smaller-thresholds} @@ -413,7 +413,7 @@ \subsubsection*{A 2-of-3 example} \item and sends $C^{\alpha}_{e}$ to the other participants securely. \end{enumerate} \item On receipt of all $C^{\alpha}_{e}$, each participant sends out $\alpha_e G$ and verifies the other commitments were legitimate. - \item Each participant computes + \item Each participant computes \[\alpha G = \sum_e \alpha_e G\] \[c = \mathcal{H}_n(\mathfrak{m},[\alpha G])\] \item Participant 1 does the following: @@ -426,7 +426,7 @@ \subsubsection*{A 2-of-3 example} \item computes $r_2 = \alpha_2 - c*k^{agg,\textrm{2x3}}_{2,3}$, \item and sends $r_2$ to participant 1 securely. \end{enumerate} - \item Each participant computes + \item Each participant computes \[r = \sum_e r_e\] \item Either participant can publish the signature $\sigma(\mathfrak{m}) = (c,r)$. \end{enumerate} @@ -434,7 +434,7 @@ \subsubsection*{A 2-of-3 example} The only change with sub-N threshold signatures is how to `close the loop' by defining $r_{\pi,e}$ (in the case of ring signatures, with secret index $\pi$). Each participant must include their shared secret corresponding to the `missing person', but since all the other shared secrets are doubled up there is a trick. Given the set $\mathbb{S}^{base}$ of all participants' original keys, only the {\em first person} - ordered by index in $\mathbb{S}^{base}$ - with the copy of a shared secret uses it to calculate his $r_{\pi,e}$.\footnote{In\marginnote{src/wallet/ wallet2.cpp {\tt transfer\_ selected\_ rct()}} practice this means an initiator should determine which subset of M signers will sign a given message. If he discovers O signers are willing to sign, with (O $\geq$ M), he can orchestrate multiple concurrent signing attempts for each M-size subset within O to increase the chances of one succeeding. It appears Monero uses this approach. It also turns out (an esoteric point) that the {\em original} list of output destinations created by the initiator is randomly shuffled, and that random list is then used by all concurrent signing attempts, and all other co-signers (this is related to the obscure flag {\tt shuffle\_outs}).}\footnote{Currently Monero appears to use a round-robin signing method\marginnote{src/wallet/ wallet2.cpp {\tt sign\_multi- sig\_tx()}}, where the initiator signs with all his private keys, passes the partially signed transaction to another signer who signs with all {\em his} private keys (that have not been used to sign with yet), who passes to yet another signer, and so on, until the final signer who can either publish the transaction or send it to other signers so they can publish it.} In the previous example, participant 1 computes\vspace{.175cm} -\[r_1 = \alpha_1 - c*[k^{agg,\textrm{2x3}}_{1,3} + k^{agg,\textrm{2x3}}_{1,2}]\] +\[r_1 = \alpha_1 - c*[k^{agg,\textrm{2x3}}_{1,3} + k^{agg,\textrm{2x3}}_{1,2}]\] while participant 2 only computes \[r_2 = \alpha_2 - c*k^{agg,\textrm{2x3}}_{2,3}\] @@ -453,13 +453,13 @@ \subsection{M-of-N key aggregation} The group could use $k^{sh,\textrm{1x3}} = \mathcal{H}_n(k^{base}_1 k^{base}_2 k^{base}_3 G)$ as a shared private key, and publish\vspace{.155cm} \[K^{grp,\textrm{1x3}} = \mathcal{H}_n(T_{agg},\mathbb{S}^{\textrm{1x3}},K^{sh,\textrm{1x3}}) K^{sh,\textrm{1x3}}\] as a 1-of-3 multisig address. -In a 3-of-3 multisig every 1 person has a secret, in a 2-of-3 multisig every group of 2 people has a shared secret, and in 1-of-3 every group of 3 people has a shared secret. +In a 3-of-3 multisig every 1 person has a secret, in a 2-of-3 multisig every group of 2 people has a shared secret, and in 1-of-3 every group of 3 people has a shared secret. Now we can generalize to M-of-N: every possible group of (N-M+1) people has a shared secret \cite{old-multisig-mrl-note}. If (N-M) people are missing, all their shared secrets are owned by at least one of the M remaining people, who can collaborate to sign with the group's key. \subsubsection*{M-of-N algorithm} -Given participants $e \in \{1,...,N\}$ with initial private keys $k^{base}_1,...,k^{base}_N$ who wish to produce an M-of-N merged key (M $\leq$ N; M $\geq$ 1 and N $\geq$ 2), we can use an\marginnote{src/wallet/ wallet2.cpp {\tt exchange\_ multisig\_ keys()}} interactive algorithm. +Given participants $e \in \{1,...,N\}$ with initial private keys $k^{base}_1,...,k^{base}_N$ who wish to produce an M-of-N merged key (M $\leq$ N; M $\geq$ 1 and N $\geq$ 2), we can use an\marginnote{src/wallet/ wallet2.cpp {\tt exchange\_ multisig\_ keys()}} interactive algorithm. We will use $\mathbb{S}_s$ to denote all the {\em unique} public keys at stage $s \in \{0,...,(N-M)\}$. The final set $\mathbb{S}_{N-M}$ is ordered according to a sorting convention (such as smallest to largest numerically, i.e. lexicographically). This notation is a convenience, and $\mathbb{S}_s$ is the same as $\mathbb{S}^{\textrm{(N-s)xN}}$ from the previous sections. @@ -499,9 +499,9 @@ \subsubsection*{M-of-N algorithm} \section{Key families} \label{sec:general-key-families} -Up to this point we have considered key aggregation between a simple group of signers. For example, Alice, Bob, and Carol each contributing key components to a 2-of-3 multisig address. +Up to this point we have considered key aggregation between a simple group of signers. For example, Alice, Bob, and Carol each contributing key components to a 2-of-3 multisig address. -Now imagine Alice wants to sign all transactions from that address, but doesn't want Bob and Carol to sign without her. In other words, (Alice + Bob) or (Alice + Carol) are acceptable, but not (Bob + Carol). +Now imagine Alice wants to sign all transactions from that address, but doesn't want Bob and Carol to sign without her. In other words, (Alice + Bob) or (Alice + Carol) are acceptable, but not (Bob + Carol). We can achieve that scenario with two layers of key aggregation. First a 1-of-2 multisig aggregation $\mathbb{K}^{agg,{1\textrm{x}2}}_{BC}$ between Bob and Carol, then a 2-of-2 group key $K^{grp,{2\textrm{x}2}}$ between Alice and $\mathbb{K}^{agg,{1\textrm{x}2}}_{BC}$. Basically, a (2-of-([1-of-1] and [1-of-2])) multisig address. @@ -510,6 +510,7 @@ \section{Key families} \subsection{Family trees} We can diagram the (2-of-([1-of-1] and [1-of-2])) multisig address like this: +\begin{otherlanguage}{english} \begin{center} \begin{forest} forked edges, @@ -526,12 +527,14 @@ \subsection{Family trees} [$K^{base}_C$] ] ] - \end{forest} + \end{forest} \end{center} +\end{otherlanguage} -The keys $K^{base}_A,K^{base}_B,K^{base}_C$ are considered {\em root ancestors}, while $\mathbb{K}^{agg,{1\textrm{x}2}}_{BC}$ is the {\em child} of {\em parents} $K^{base}_B$ and $K^{base}_C$. Parents can have more than one child, though for conceptual clarity we consider each copy of a parent as distinct. This means there can be multiple root ancestors that are the same key. +The keys $K^{base}_A,K^{base}_B,K^{base}_C$ are considered {\em root ancestors}, while $\mathbb{K}^{agg,{1\textrm{x}2}}_{BC}$ is the {\em child} of {\em parents} $K^{base}_B$ and $K^{base}_C$. Parents can have more than one child, though for conceptual clarity we consider each copy of a parent as distinct. This means there can be multiple root ancestors that are the same key. For example, in this 2-of-3 and 1-of-2 joined in a 2-of-2, Carol's key $K^{base}_C$ is used twice and displayed twice: +\begin{otherlanguage}{english} \begin{center} \begin{forest} forked edges, @@ -552,8 +555,9 @@ \subsection{Family trees} [$K^{base}_D$] ] ] - \end{forest} + \end{forest} \end{center} +\end{otherlanguage} Separate sets $\mathbb{S}$ are defined for each multisig sub-coalition. There are three premerge sets in the previous example: $\mathbb{S}^{\textrm{2x3}}_{ABC} = \{K^{sh,\textrm{2x3}}_{AB},K^{sh,\textrm{2x3}}_{BC},K^{sh,\textrm{2x3}}_{AC}\}$, $\mathbb{S}^{\textrm{1x2}}_{CD} = \{K^{sh,\textrm{1x2}}_{CD}\}$, and $\mathbb{S}^{\textrm{2x3}}_{final} = \{\mathbb{K}^{agg,{2\textrm{x}3}}_{ABC},\mathbb{K}^{agg,{1\textrm{x}2}}_{CD}\}$. @@ -562,6 +566,7 @@ \subsection{Nesting multisig keys} \label{subsec:nesting-multisig-keys} Suppose we have the following key family +\begin{otherlanguage}{english} \begin{center} \begin{forest} forked edges, @@ -580,8 +585,9 @@ \subsection{Nesting multisig keys} [$K^{base}_D$] [$K^{base}_E$] ] - \end{forest} + \end{forest} \end{center} +\end{otherlanguage} If we merge the keys in $\mathbb{S}^{\textrm{2x3}}_{ABC}$ corresponding to the first 2-of-3, we run into an issue at the next level. Let's take just one shared secret, between $K^{grp,\textrm{2x3}}_{ABC}$ and $K^{base}_D$, to illustrate:\vspace{.175cm} \[k_{ABC,D} = \mathcal{H}_n(k^{grp,\textrm{2x3}}_{ABC} K^{base}_D)\] @@ -607,11 +613,12 @@ \subsubsection*{Solution for nesting} \subsection{Implications for Monero} -Each sub-coalition contributing to the final key needs to contribute components to Monero transactions (such as the opening values $\alpha G$), and so every sub-sub-coalition needs to contribute to its child sub-coalition. +Each sub-coalition contributing to the final key needs to contribute components to Monero transactions (such as the opening values $\alpha G$), and so every sub-sub-coalition needs to contribute to its child sub-coalition. This means every root ancestor, even when there are multiple copies of the same key in the family structure, must contribute one root component to their child, and each child one component to its child and so on. We use simple sums at each level. For example, let's take this family +\begin{otherlanguage}{english} \begin{center} \begin{forest} forked edges, @@ -628,9 +635,10 @@ \subsection{Implications for Monero} [${}^{1}\mathbb{K}^{base}_B$] ] ] - \end{forest} + \end{forest} \end{center} +\end{otherlanguage} Say they need to compute some group value $x$ for a signature. Root ancestors contribute: $x_{A,1}$, $x_{A,2}$, $x_B$. The total is $x = x_{A,1} + x_{A,2} + x_B$. -There are currently no implementations of nested multisig in Monero. \ No newline at end of file +There are currently no implementations of nested multisig in Monero. diff --git a/translations/es/front/abstract.tex b/translations/es/front/abstract.tex index 2ce6805..5887722 100755 --- a/translations/es/front/abstract.tex +++ b/translations/es/front/abstract.tex @@ -3,7 +3,9 @@ % --------------------------------------------------------------------------- -Cryptography. It may seem like only mathematicians and computer scientists have access to this obscure, esoteric, powerful, elegant topic. In fact, many kinds of cryptography are simple enough that anyone can learn their fundamental concepts. +Criptografia. Puede parecer que solo los matemáticos e informáticos tienen + +It may seem like only mathematicians and computer scientists have access to this obscure, esoteric, powerful, elegant topic. In fact, many kinds of cryptography are simple enough that anyone can learn their fundamental concepts. \\ \newline It is common knowledge that cryptography is used to secure communications, whether they be coded letters or private digital interactions. Another application is in so-called cryptocurrencies. These digital moneys use cryptography to assign and transfer ownership of funds. To ensure that no piece of money can be duplicated or created at will, cryptocurrencies usually rely on `blockchains', which are public, distributed ledgers containing records of currency transactions that can be verified by third parties \cite{Nakamoto_bitcoin}. \\ \newline @@ -11,4 +13,4 @@ \\ \newline We endeavor here to teach anyone who knows basic algebra and simple computer science concepts like the `bit representation' of a number not only how Monero works at a deep and comprehensive level, but also how useful and beautiful cryptography can be. \\ \newline -For our experienced readers: Monero is a standard one-dimensional distributed acyclic graph (DAG) cryptocurrency blockchain \cite{Nakamoto_bitcoin} where transactions are based on elliptic curve cryptography using curve Ed25519 \cite{Bernstein2008}, transaction inputs are signed with Schnorr-style multilayered linkable spontaneous anonymous group signatures (MLSAG) \cite{MRL-0005-ringct}, and output amounts (communicated to recipients via ECDH \cite{Diffie-Hellman}) are concealed with Pedersen commitments \cite{maxwell-ct} and proven in a legitimate range with Bulletproofs \cite{Bulletproofs_paper}. Much of the first part of this report is spent explaining these ideas. \ No newline at end of file +For our experienced readers: Monero is a standard one-dimensional distributed acyclic graph (DAG) cryptocurrency blockchain \cite{Nakamoto_bitcoin} where transactions are based on elliptic curve cryptography using curve Ed25519 \cite{Bernstein2008}, transaction inputs are signed with Schnorr-style multilayered linkable spontaneous anonymous group signatures (MLSAG) \cite{MRL-0005-ringct}, and output amounts (communicated to recipients via ECDH \cite{Diffie-Hellman}) are concealed with Pedersen commitments \cite{maxwell-ct} and proven in a legitimate range with Bulletproofs \cite{Bulletproofs_paper}. Much of the first part of this report is spent explaining these ideas. diff --git a/translations/es/main.tex b/translations/es/main.tex index 78deb0c..36b4ec6 100755 --- a/translations/es/main.tex +++ b/translations/es/main.tex @@ -4,7 +4,7 @@ \usepackage{fancyvrb} \usepackage[utf8]{inputenc} -\usepackage[english]{babel} +\usepackage[spanish]{babel} \usepackage[pdftex]{graphicx} From 972f4b77a8641005644edb71cf14d7e75caf0009 Mon Sep 17 00:00:00 2001 From: Jorge Maldonado Ventura Date: Thu, 22 Jun 2023 12:54:45 +0200 Subject: [PATCH 5/5] Traduce 'front/abstract.tex' --- translations/es/front/abstract.tex | 12 +++++------- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git a/translations/es/front/abstract.tex b/translations/es/front/abstract.tex index 5887722..debc2b1 100755 --- a/translations/es/front/abstract.tex +++ b/translations/es/front/abstract.tex @@ -3,14 +3,12 @@ % --------------------------------------------------------------------------- -Criptografia. Puede parecer que solo los matemáticos e informáticos tienen - -It may seem like only mathematicians and computer scientists have access to this obscure, esoteric, powerful, elegant topic. In fact, many kinds of cryptography are simple enough that anyone can learn their fundamental concepts. +Criptografía. Puede parecer que solo los matemáticos e informáticos tienen acceso a este tema misterioso, esotérico, poderoso y elegante. De hecho, muchos tipos de criptografía son lo suficientemente sencillos como para que cualquiera pueda aprender sus conceptos fundamentales. \\ \newline -It is common knowledge that cryptography is used to secure communications, whether they be coded letters or private digital interactions. Another application is in so-called cryptocurrencies. These digital moneys use cryptography to assign and transfer ownership of funds. To ensure that no piece of money can be duplicated or created at will, cryptocurrencies usually rely on `blockchains', which are public, distributed ledgers containing records of currency transactions that can be verified by third parties \cite{Nakamoto_bitcoin}. +Casi todo el mundo sabe que la criptografía se usa para proteger las comunicaciones, ya sean cartas codificadas o interacciones digitales privadas. También se aplica en lo que se conoce como criptomonedas. Estas monedas digitales utilizan la criptografía para asignar y transferir la propiedad de los fondos. Para garantizar que ninguna unidad de dinero pueda duplicarse o crearse a voluntad, las criptomonedas suelen basarse en `cadenas de bloque', que son libros de contabilidad públicos y distribuidos que contienen registros de transacciones monetarias que pueden ser verificadas por terceros \cite{Nakamoto_bitcoin}. \\ \newline -It might seem at first glance that transactions need to be sent and stored in plain text format to make them publicly verifiable. In fact, it is possible to conceal a transaction's participants, as well as the amounts involved, using cryptographic tools that nevertheless allow transactions to be verified and agreed upon by observers \cite{cryptoNoteWhitePaper}. This is exemplified in the cryptocurrency Monero. +A primera vista, podría pensarse que las transacciones deben enviarse y almacenarse en formato de texto plano para que se puedan verificar públicamente. No obstante, es posible ocultar a los participantes de una transacción, así como las cantidades implicadas, utilizando herramientas criptográficas que, sin embargo, permiten que las transacciones sean verificadas y consensuadas por observadores \cite{cryptoNoteWhitePaper}. Esto se ejemplifica en la criptomoneda Monero. \\ \newline -We endeavor here to teach anyone who knows basic algebra and simple computer science concepts like the `bit representation' of a number not only how Monero works at a deep and comprehensive level, but also how useful and beautiful cryptography can be. +Aquí no solo nos esforzamos en enseñar a cualquiera que sepa álgebra básica y conceptos sencillos de informática como la `representación en bits' de un número cómo funciona Monero a un nivel detallado y exhaustivo, sino también lo útil y hermosa que puede ser la criptografía. \\ \newline -For our experienced readers: Monero is a standard one-dimensional distributed acyclic graph (DAG) cryptocurrency blockchain \cite{Nakamoto_bitcoin} where transactions are based on elliptic curve cryptography using curve Ed25519 \cite{Bernstein2008}, transaction inputs are signed with Schnorr-style multilayered linkable spontaneous anonymous group signatures (MLSAG) \cite{MRL-0005-ringct}, and output amounts (communicated to recipients via ECDH \cite{Diffie-Hellman}) are concealed with Pedersen commitments \cite{maxwell-ct} and proven in a legitimate range with Bulletproofs \cite{Bulletproofs_paper}. Much of the first part of this report is spent explaining these ideas. +Para nuestros lectores experimentados: Monero es una criptomoneda de cadena de bloque de gráfico acíclico distribuido unidimensional estándar \cite{Nakamoto_bitcoin} en la que las transacciones se basan en criptografía de curva elíptica usando la curva Ed25519 \cite{Bernstein2008}, las entradas de transacciones son firmadas con firmas de grupo anónimas multicapa enlazables espontáneas de tipo Schnorr \cite{MRL-0005-ringct} y las cantidades de salida (comunicadas a los destinatarios a través de ECDH \cite{Diffie-Hellman}) se ocultan con compromisos de Pedersen \cite{maxwell-ct} y se prueban en un rango legítimo con Bulletproofs \cite{Bulletproofs_paper}. En gran medida, la primera parte de este informe se dedica a explicar estas ideas.