Signed git commits allow a user to verify the source was signed by one of the contributors. In order for this to work, however, several steps have to be taken:
The user must have git and GPG installed. While git will typically be installed already if the user wants to use github, GPG may not be. Make sure to install it from your distribution's packages, or ...
As well as the informal review of CryptoNote provided to the Monero team by SURAE NOETHER here, the source code is available on monero-project's github here.
These slides also review the protocol.
A possibly important note from those slides about the spec that isn't found anywhere else is given after slide 28, saying:
apparently 2 bad random r in monero ...
This is of course a coarse method, but we can do the following:
Get git to work out who authored a given line for all the lines in src:
$ find src/ -name \*.cpp -o -name \*.c -o -name \*.inl -o -name \*.h | while read f; do git blame -CC "$f";done > full-files
Then check how many of those lines were authored by the pre-Monero authors (anjuarez for the ...
It'd need to wait for git to implement stronger collision resistance. Work is underway for this: http://www.metzdowd.com/pipermail/cryptography/2017-February/031606.html
However, Linus (original creator of git) thinks it's not that easy to exploit in git: https://plus.google.com/+LinusTorvalds/posts/7tp2gYWQugL
As far as I'm aware, there were no "formal" reviews, as in an outside third party is hired for the purpose, and publishes a review document.
The Cryptonote whitepaper was reviewed by a cryptographer, and an informal review is available (https://downloads.getmonero.org/whitepaper_review.pdf).
Some of the code was kinda reviewed by way of being forked and ...
The paper is incorrect; it's actually mod l, not q. l is the curve order of ed25519. The primary reason AFAIK is that the code doesn't work correctly with scalars above a certain multiple of l. The random_scalar() function outputs an integer
I do not know the exact number of lines of Monero source code, but there are a few methods to calculate it, which are described here.
Monero is not based on the Bitcoin code base and is rather complex. Because of this there has been a major effort to document and cleanup Monero source code:
There are over 70,000 lines of source in the src/ folder alone, ...
It is much harder to compile software for Windows than it is for GNU/Linux or MacOSX. Instructions do exist in one of Ilya Kitaev's GitHub forks, but they haven't been merged yet at time of writing. They are copied (almost verbatim) below:
Install msys2, follow the instructions on that page on how to update packages to the latest ...
If history is rewritten, you will not be able to pull over an existing tree (it's a bit more complicated, but in the general case where you're only ever on master, it holds). This is the "fast forward" mode. If history you already have is rewritten, git will fetch the new data, but will complain that it can't fast forward, and leave you with your master ...
Good that you ask. Actually, a
coordinated test is ongoing and you could join in: https://www.reddit.com/r/Monero/comments/6eef96/fluffynet_update_please_move_some_to_tier_3_4_and/
And yes, you can use existing blockchain, the change is in networking part so interest is in blocks / TX propagation etc.
The ref10 folder contains code for operations on curve25519. This code comes from NaCL, and is not specific to monero. Reading material on ECC will be more helpful in understanding this code than the monero whitepaper.
The group refers to the finite set of points that are solutions to the equation defined by curve25519. Each point has an x and y coordinate ...
They are all group elements (hence the ge_ prefix) and are different representations.
From some ed25519 source:
ge means group element.
Here the group is the set of pairs (x,y) of field elements (see fe.h)
satisfying -x^2 + y^2 = 1 + d x^2y^2
where d = -121665/121666.
ge_p2 (projective): (X:Y:Z) satisfying x=X/Z, y=Y/Z
In the CryptoNote protocol, outputs are organized into groups according to their amounts, and m_global_output_index represents the index of a given output in its corresponding group. This reduces the size of the ring signature by only storing those indices of outputs in the signature instead of the actual public keys.
Using David A. Wheeler's SLOCcount (http://www.dwheeler.com/sloccount), the canonical tool for counting such things, Monero appears to be about 65k lines of C++ code and 5k lines of C code (src and contrib/epee), as well as about 17k of crypto code, most of it derived from Daniel Bernstein's crypto code.
Ancillary libraries not counted (unbound, lmdb, etc).
It is the set of block hashes from the genesis block to a fairly recent block, and is used to speed sync up for historical blocks. It is typically updated shortly before a new release.
Those hashes are stored as is so they can be read without having to parse hex strings, which would be slower and use more memory.
The monero GUI source code and installation guide (including Ubuntu 16) can be found here https://github.com/monero-project/monero-core
To answer your questions by referring the guide.
It installs in the directory where you download/cloned the source and build it. So it will not overwrite anything as long as you download it on a an empty folder.
On the sub ...
Sure, assuming you have not made any branches, and that doesn't sound likely, follow these steps:
if you have made any changes to the repo: git stash
git pull --rebase
if you have made any changes to the repo: git stash pop
So in the likely case you haven't changed anything, it's just one step. Then build again (make).
If you did make changes, there's a ...
There are 2 places these ops are found, firstly https://github.com/monero-project/monero/blob/master/src/crypto/crypto-ops.c which has the lower level c code and https://github.com/monero-project/monero/tree/master/src/ringct which has some c++ wrappers.
The two main operations in terms of CPU usage are determining if an output is sent to you (is_out_to_acc_precomp, defined in src/cryptonote_basic/cryptonote_format_utils.cpp) and generating the key derivations that is_out_to_acc_precomp acts on (generate_key_derivation, defined in src/crypto/crypto.cpp). There is some threading there, but it could still be ...
The magic numbers are best explained here:
* Lots of magic numbers :)
* To understand what's going on below, note that
* (1) q = 2^252 + q0 where q0 = 27742317777372353535851937790883648493.
* (2) s11 is the coefficient of 2^(11*21), s23 is the coefficient of 2^(^23*21) and 2^252 = 2^((23-11) * 21)).
* (3) 2^252 congruent -q0 modulo q.
* (4) -...
This is not specific to Monero, rather a C/C++ linking question, nevertheless...
The order you add the libraries matters. In your example:
/usr/bin/c++ _build/pymonero.cpp.o -o pymonero \
-L$MONERO_DIR/src -lversion \
-L$MONERO_DIR/src/cryptonote_basic -lcryptonote_basic \
-L$MONERO_DIR/src/device -ldevice \
Linking CXX executable pymonero
What type of issues is this GitHub meant to address?
From the dev meeting:
fluffypony:: pigeons: do you want to tell people about the new repo we're using for issues?
nanoakron: Please explain?
pigeons: for stuff realted to build machines, build infrastructure, etc
pigeons: anonimal has been ...
Since 2014, and at the time of this writing, Monero had 3107 commits on Github so it's hard to point a finger at some specific difference or give a % as there have been thousands of lines of code edited and decades of man-years spent working on it since the inception.