Exploring CryptoNote Protocol Features

CryptoNote v2.0 Nicolas van Saberhagen October 17, 2013

CryptoNote is a protocol specification which cryptocurrencies have been based on. The most successful one to date is Monero, which has also added its own optimizations and bells and whistles

CryptoNote CryptoNote defines itself as a Bitcoin competitor Attempts to improve on Bitcoin s limitations: 1. Traceability of transactions We will get to this in a second

CryptoNote CryptoNote defines itself as a Bitcoin competitor Attempts to improve on Bitcoin s limitations: 2. Bitcoin s proof-of-work of function favors GPUs over CPUs Solution: implement proof-of-work with a computation that spends most of its time reading from memory; memory latency is hard to game

3. Bitcoins Inconsistent Hashrate Miners dropped out when the Bitcoin reward decreased The disappearance of validators leaves the network potentially vulnerable to attackers CryptoNote s reward function is smooth

CryptoNote Finally, the problems with Bitcoin that a new currency could most easily solve: 4. Hardcoded constants like block size 5. Messages are too large due to overly complicated scripting system Solution: don t do that

Transaction Anonymization We have two basic goals: Untraceability: Senders should be anonymous, even to receivers Bitcoin has the opposite of this Unlinkability: It should not be visible when multiple transactions are to the same receiver Bitcoin kind of has this if receivers all use a bunch of public keys

We Will Now Talk About Elliptic-Curve Cryptography For The Next Eighteen Hours

EC Crypto for Mathematicians We define a curve with an equation ?2+ ?2= 1 + ??2?2for some d We transfer the curve to the field of integers modulo q Floating point math is imprecise and unsafe q needs to be prime because of *checks notes* the quotients in Euclid's algorithm. We choose a generator point on the curve I mean, actually, the paper does it for us This is what mathematicians are for

EC Crypto for Programmers The takeaway: in programming terms, we now have an STL-style container of points I believe that in CryptoNote there are 2252+ 27742317777372353535851937790883648493 of them This container is forward iterable only It s a singly-linked list of points

EC Crypto for Programmers This makes creating shared secrets easy I take curve.begin(), advance it a times, then then put the resulting iterator in shared memory You take curve.begin(), advance it b times, then put the resulting iterator in shared memory You take my iterator and advance it b times; I take your iterator and advance it a times Now both of our iterators have been advanced a+b times and we have a shared secret that no one else can figure out (*ourIterator)

EC Crypto for Mathematicians Advancing an iterator n times multiplying a point by n private key: a (integer) public generator point: G (point) public key: aG (point) a is hidden because iterator arithmetic is unavailable (or, mathematically, because EC division is hard) So if I publish aG and you publish bG, we can both find abG but no one else can, unless they have your a or my b

Unlinkable Payments Anonymizing the receiver Senders use modified key exchange to generate numerous public keys for any given receiver These are called Stealth Addresses by Monero

Unlinkable Payments Potential receivers have a private key (int a, int b) and public address (A, B) = (aG, bG) Sender chooses random int r and generate R = rG Then creates a transaction using: One-time public key P = hash(rA)G + B Sender s randomized public key R Receiver needs to watch for transactions where: P = hash(aR)G + B These are his incoming transactions (because aR = rA)

Unlinkable Payments The second half of the receiver s public key, B, is apparently necessary for other purposes Receivers can delegate the job of scanning for their incoming transactions without releasing their full private key (a, b); they just need to release (a, B) The thing is, receivers can already use unlimited public keys in Bitcoin. But senders can t auto-generate them, so

Untraceable Payments Anonymizing the sender Senders sign transactions with ring signatures that hide their identity Ring Signatures come from How to Leak a Secret, Rivest et al., 2001 Double spending is blocked by a linking mechanism ironically coming from a paper called Traceable Ring Signature (using a different sense of traceable )

Untraceable Payments How to generate a ring signature: Pool n public keys; include your own. Any of the owners of any of these n public keys could be the sender of a given transaction Compute a random fake private key for each of the public keys: ri Then, carefully choose an r to match your own public key

Ring Signature Simplified for clarity The result of the call to f for P0is fed into P1 Then repeat in a loop and you will get the same result for f or P0when you reach it again For our case f needs to encode a version of these params and also a hash of the transaction

Ring Signature Any owner of any of the public keys could have provided the private key that closed the circle All links are identical to outside observers

Untraceable Payments In this scheme, you can easily gather a bunch of public keys because every transaction has a different public key Although, you do have to find public keys that were used to send the same amount that you want to send, unless the amounts are also hidden like in modern Monero with RingCT It also means that detecting double- spending just means detecting money being sent from the same address twice