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 ...
To answer part of your question, the Monero devs recommend that you stick to tagged releases. So compiling from the head master branch is never recommended unless you are testing or really know what you are doing.
However, you've missed a third option that really is the best of both worlds when it comes to being both paranoid and wanting stability. Namely: ...
Visit the GitHub and sign in, creating a new account first if necessary. Select the specific repositories you would like to watch.
When you watch a repository, you get notifications for any new pull requests and issues that are created, including those not mentioning you.
For example Monero source code can be found in this repository. Monero GUI and ...
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
I'm not a Monero developer, but as a general recommendation I would only use the official release binaries from the Monero website when dealing with non-trivial amounts of XMR.
When dealing with live code, you have no idea if the last commit introduced some fatal bug. The code that's released to the public has undergone testing and is what I would use when ...
There will be a public testnet once there is some code review.
I'm not sure whether the code will be merged prior to the public testnet or not. If it is, then you will be able to pull from master and run in testnet mode. If not, you will have to build from moneromooo's branch. From today's dev meeting, the testnet should happen a few days after the PR ...
Yes there is, and people do host it themselves, and for others:
You can download it here:
An example running is here: http://explore.moneroworld.com/
There are no hard rules. fluffypony gets on a merge fest from time to time, and will merge any outstanding PR that's had at least a couple days time to be reviewed. There are not many reviewers though, so he will review what isn't, and merge. Some PRs fixing urgent bugs get in quickly, and other more complex ones, or ones attracting review comments, get in ...
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 ...
Unless you understand what has changed in the master, I'd advise to use the stable release binaries, as those have been tested prior to being tagged as a release.
If you just want to compile from source you could use the same source as used for release (0.9.4 source).
If security is your concern, the binaries can be be verified by their hashes which are ...
the link to the original code base is maintained
Depends what you mean by "link". There is a link to the original code that is maintained whether you fork publicly on GitHub or whether you clone to a private repository.
However, it would make it harder to do things like issue pull requests if you have a clone instead of a fork. See https://stackoverflow....
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 ...
In addition to the comments from user36303 and JollyMort see this answer to my recent question about the difference between ring size and mixin. The distinction is clarified below:
Ring size = 'mixin' (number of foreign outputs) + 1 (your output)
I agree with the advice above that this task is not urgent and should be left to someone very familiar with ...
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 ...
I dont know about the pull requests specifically, but here you can see overall activity of participants.
Moneromooo is the most active with 710 commits, second being fluffyponny with 285.
Moneromooo's work also looks very steady during last year and half.
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 using it some to get ...
The main reason is that the crypto tests include a set of expected values from the pseudo random number generator, which was recently changed to remove a tiny bias, thereby changing the returned values. A patch which was supposed to update the values did not actually fix it, and another needs to be made instead.
The Windows platforms were also broken for a ...