Latests news

Major Updates

We are saddened to hear of the implosion of Moolah and how it has hampered Monero users in their attempts to withdraw funds held on MintPal. We have actively reached out to the current management staff to try and assist them with Monero withdrawals, and at this stage we're completely unsure as to what the internal state of their system is. We hope and trust they will resolve it and all affected users will be able to withdraw, and we remain completely available to assist their staff as necessary.

It has been a week of fundamentals. Whilst externally visible development is fun and easy to see, there is a dire need to focus on some of the core issues that have been lagging. The longer we wait before addressing these, the harder and more expensive it will be to address them. By spending a little bit of effort now we make Monero more secure and robust for the far future!

Excellent progress has been made with an initial blockchain database implementation. The first implementation is using the Lightning Memory-Mapped Database, or LMDB, which is the same high-performance database used by OpenLDAP. We are hopeful that this initial release will be ready for limited testing by next week. You can read more about LMDB here: http://symas.com/mdb/ (it would appear they're in a competition with us for the best looking website of 1995). We are quite confident that this will be the most performant embedded database option for our workloads, but we will be adding additional implementations and comparing their performance going forward.

Extensive work is underway with the assistance of NLnet Labs (the creators of Unbound and libunbound) to correctly implement DNSSEC trust anchors in a cross-platform manner. Don't worry, you aren't expected to understand that sentence:) What this means is that it prepares us for more widespread, secure use of the OpenAlias standard. One of the key problems it solves is in allowing all Monero users to securely and safely determine whether an alias has been tampered with or not (although even insecure aliases can still receive payments as long as the sender double-checks and confirms it).

To build on what we mentioned last week: we are working directly with Kitware founder Bill Hoffman, along with his colleague Ben Boeckel, to bring our build system (which uses Kitware's CMake and CTest) up to scratch and ensure we are complying with Kitware's best-practices across the board. This may seem like an insignificant effort, but after the difficulties and pain-points we encountered with statically building the Monero 0.8.8.5 release we realised the need for our build environment to be reworked to conform to what Kitware recommends, especially considering the amount of poorly implemented CMake in the reference code we started with.

Dev Diary

Core: per-kb fee testing is going well on testnet, although there are some caveats we are working through.

Core: work is progressing nicely on a new feature that will allow a raw, static blockchain to be generated so that we can provide that for download instead of the serialised blockchain objects. This will mean that importing this file will take as many as several hours, but your daemon will fully verify the downloaded blockchain instead of just assuming it to be correct.

Tests: unit tests have been fixed so that they are now working, and this change is expected to be merged in the next week.

Tests: core tests are currently being worked on to bring them up to a 100% working state. The end goal of all of this is the ability to compile for release-test or debug-test, and have all tests pass, every time a new pull request is submitted.

Major Updates

The database effort is ongoing, and is currently playing a little bit of catch-up back-porting features and fixes we added to the current codebase.

The GUI, too, is progressing at a slightly reduced pace. We hope to update the preview binaries in the next week or two.

We are working hard on solving the static build issues to tag and release updated binaries. If you require any of the more recent features it is compile-only at this stage.

We are happy to announce that per-kb fees is going to be deployed to testnet over the next couple of days. Barring any major complications, we expect positive testing results, and are hopeful that mainnet can move over to per-kb fees within the next two weeks.

A few other things undergoing testing are: parallel support for MSVC 2013 as a build environment, minor tweaks and improvements to the new mnemonic system whereby English words now match on the first 3 letters and not the first 4, asynchronous DNS checkpointing, and support for long / blob hash checkpointing on both the file and DNS side.

Dev Diary

Build: initial work has started on reworking the CMake environment so that it is consistent and extensible. This will reduce build issues further down the line.

Core: per-kb fees are done, and are being deployed to testnet. If you are mining on testnet you don't have to update to that fork/branch, as we want to see more real-world results with both fixed-fee and per-kb miners.

Core: documentation continues, with Doxygen comments now added to the serialisation functions

Core: DNS checkpointing is now asynchronous, and doesn't prevent blocks from being received (in testing)

Wallet: mnemonic lists now support a variable trim length (instead of the previous fixed trim length). English is 3, the rest are 4, and the old English wordlist doesn't really conform to the trim length rule (in testing)

Hello, and welcome to our thirteenth Monero Monday Missive! You'll notice a slight change in name - as of today we will be putting out a Missive every Monday. We want to start shifting the Missive from an announcement platform to a "week in review" platform. Traditionally the Missives have been a place for announcements, but all that is about to change.

Major Updates

We are happy to announce the launch of the official Monero forum. You can find it at https://forum.monero.cc
Instead of using something existing and off-the-shelf we wrote our own. There were several reasons for this, but the primary reason is that there is functionality we required that simply does not exist in existing forum software. Additionally, the nature of forums has hardly changed in well over 20 years (phpBB was released in 2000, SMF that is used on Bitcointalk was released in 2003). The forum software will be open-sourced and released soon. You will find the following features on the new forum of interest:

A clean, modern, responsive interface that provides a threaded view of posts.

Support for those that choose to have JavaScript enabled or disabled in their browser.

Integration into the #bitcoin-otc Web of Trust. Currently this is one-way only, but the OTC WoT will soon start syncing back down.

In combination with that, GPG authentication that is also used as 2FA. When logging in you can choose how long to remain logged in for, so the level of protection you wish to exercise over your account is up to you.

The ability to rate users, as with the WoT. Ratings can be from -10 (untrusted) to 10 (trusted). We will also be adding tools to assist in visualising the trust relationships to forum members to assist with and encourage qualitative use of the WoT.

Posts and comments are weighted, and their position in the forum as well as their visibility is affected by this weighting. The weighting rules are still a work in progress and will mature over time, but they are primarily affected by four things: decrease as it decays over time, increases/decreases as users vote them insightful or irrelevant, and increases/decreases based on votes and child comments from users in your trust group (with influence up to a third level beyond your immediate trust group). The upshot of this is that the posts and comments that are most visible to you, and the order in which posts appear, is unique to you as a user, and depends entirely on your trust relationships. If a post is getting a lot of comments by people that you trust directly or indirectly (trust-of-trust and trust-of-trust-of-trust) you will personally see that post at the top more often than someone else who has no trust relationship with those commenters. We hope that this will, over time, lead to a more personal forum experience, one where troll and shill posts are effectively invisible, and you can focus on the posts and comments most important to you.

We are in the process of baking the funding system into the forum. You will notice that in the Development category there are 4 special sections: Ideas, Open Tasks, Funding Required, and Work in Progress. The way this will work is that anyone can suggest an idea in the Ideas section, whether it is a Monero feature, a peripheral task, or even something completely unrelated to direct development such as a gathering or conference. Once an idea reaches a level of maturity and community support (commensurate with the complexity of the idea, of course) it will be moved to Open Tasks by the Monero core team. At this juncture, a person, team, group, or even company can pitch to run with the task. Especially if they have not done anything Monero-related previously, they will need to detail why they are best suited to the task, and will need to give some indication as to what the cost will be, even if it is a bit of a thumb-suck. The core team will make a decision as to which candidate/group/team is going to run with the task, and the task will move to Funding Required. At this point the community will be able to fund the effort, with individuals being able to reach status levels and earn badges the more funding they provide. Once funding has exceeded 60% for that task work can begin and the task moves to Work in Progress, with a small stub left in Funding Required until the balance of the funding is met. The person or people working on the task can only request payment at most once a week, and funds will only be released if there is general agreement and observation by the community that the work is being done.

Private messaging, forum search, subscriptions, and so on will be added in the near future, but if you have a specific idea please create a post in the "Meta" section of the Monero Forum.

We are, therefore, going to be closing some of the threads here on Bitcointalk and linking them to the Monero Forum instead. It would be appreciated if all could follow suite, so that we have a single place for discussion and ongoing Monero-related efforts rather than having things spread out all over the place.

We have have been working hard in the background on the codebase, and the following additions are available in the source repository:

Major overhaul of the mnemonics system. This includes a brand new English wordlist designed from the ground up to minimise variant differences and to encourage adapting or memorising the list. It also adds an extra word as a checksum, so mnemonic seeds are now 25 words instead of 24. Finally, it adds multi-language support, with initial extra word lists in Japanese, Portuguese, and Spanish. If you would like to assist in creating a word list please get hold of us (by posting on the new forum, for instance!)

The addition of MoneroPulse, a loosely distributed checkpoint alert system. MoneroPulse will allow us to add both block hash checkpoints and blob hash checkpoints (to defeat attacks like the Block 202612 attack). For ordinary nodes that are checked at least occasionally, the daemon will notify you in angry red letters when your local chain doesn't meet a checkpoint. If you run an unattended node (merchant systems, pools, etc.) you will want to turn on the "--enforce-dns-checkpointing" flag so that these checkpoints are enforced and not merely notified.

In the event of someone being a nuisance and trying to disrupt the Monero blockchain, we can now also distribute checkpoints in a simple checkpoints.json file that can be dropped into the same folder as your blockchain. The JSON format is quite simple, and we have provided an example in the Dev Diary below. The combination of file and DNS checkpointing will allow us to respond extremely quickly and secure the blockchain in the event of an attack. Of course, these measures are temporary, and once the Monero network is significantly larger and stronger they will be unnecessary.

There have been a number of minor tweaks and bug fixes.

Please note that static builds still need to be finalised before we can tag a release, but we hope to have new binaries up shortly.

The Monero Research Lab is glad to release a new Research Bulletin, MRL-0003, entitled "Monero is Not That Mysterious". In it, the Monero ring signatures are broken down and analysed both cryptographically and mathematically. In conjunction with that, we are happy to announce the release of MiniNero, a Python implementation of the Monero ring signatures. This is a very basic reimplementation that produces valid ring signatures that are nearly Monero compatible, although slight differences occur due to the hashing and packing algorithms. You can find the MiniNero source code on Github: https://github.com/monero-project/mininero

Monero has been added to the Cryptsy voting list, and within a few short days it has shot up to number 2 on the voting list. Thanks to all that have voted and continue to vote!

Dev Diary

Core: file checkpointing. This is in the form of a checkpoints.json file added to the config_folder. This file is checked every 10 minutes, and new checkpoints are always enforced (it is assumed that if an attacker has write access to your config_folder they can just modify your blockchain without needing to do anything else). At its simplest, the file follows this format:

Core: DNS checkpointing. This scans TXT records on the domains checkpoints.moneropulse.net/org/se/co every hour and, unless an enforce flag is set, notifies the user where checkpoints do not match. The records are all DNSSEC secured, although there is still some work to be done to provide cross-platform root trust anchors.

Build: the build system is a little precarious at the moment. We are working hard on improving it so that builds are easier and less problematic. Our focus is always on making sure the that "usual" dynamic build works, and static builds are thus a secondary concern. At this stage, static builds require a bit of massaging that we hope to have sorted out by the next tagged release.

Core: dga has kindly spend some time annotating and documenting the PoW algorithm in code. If you are working with the PoW algorithm you may find his notes in slow_hash.c to be extremely useful and revealing.

Hello, and welcome to our twelfth Monero Missive! This is our first Missive after a bit of a break whilst we thwarted two related blockchain attacks. Nonetheless, we have not sat by idly, we have been finalising and completing a brand new aspect of Monero designed to protect your privacy now and in the future:

Major Updates

The Monero Research Lab is an open collective and a multi-faceted academic group focused on the ongoing improvement of Monero. Membership is not fixed, and comes and goes as researchers become interested in Monero. This isn't a group focused on the addition of "features" to Monero, but rather the analysis and improvement of the underlying core of Monero to make sure that the theories and cryptography behind Monero continue to remain robust and sound. With that in mind, we are proud to announce the release of the first two publications out of the Monero Research Lab:

This week Friday we're going to have our second #Monero-Dev Fireside Chat this week Friday, September 19th, 2014, at 10:00 EST which is 14:00 UTC and 16:00 UTC +2. For a full table of the time zones you can refer to this image, or you can use this online tool to add your city and make sure you have the correct starting time. Please note that this is a developer event, and so most of the focus will be from that perspective.

To pick up where we left off with our last Missive, we are also happy to announce the availability of Monero merchandise on the Monero Gear store, powered by Zazzle. The advantage of us using Zazzle is that it is on-demand and we never have to worry about print runs or stock or anything. In return we get 15% of each sale as a "royalty" that will go towards enabling further Monero development, although Zazzle do not (yet!) accept Bitcoin or Monero. We hope to add new designs to the store on a regular basis. You can check the store out here: http://www.zazzle.com/monerogear* or take a peek at some of the new designs:

We are also pleased to announce the release of URS, a Monero project written in Go that allows you to sign messages using ring signatures as part of a group. The signature can be verified, but it cannot be determined which one of the signatories in the group did the actual signing (just like Monero uses for transactional unlinkability!). You can take a look at the project here: https://github.com/monero-project/urs, and the Bitcointalk thread dedicated to the project is here: https://bitcointalk.org/index.php?topic=768499.0

We have a new tagged release, 0.8.8.4, available for download (binaries: Windows, Mac, Linux, FreeBSD). This adds the following features:

Testnet: we now have an operating testnet. When using bitmonerod or simplewallet you can now use the --testnet flag to use testnet instead of mainnet. Feel free to run a mining node or just a testnet node, we will be setting up email alerts for testnet nodes when an update is pending (although having a few older testnet nodes on the network won't hurt testing).

FreeBSD Compatibility: Monero now works on FreeBSD out the box. We will add it to the ports tree soon. At the moment compilation is no different from regular Linux and Unix compilation, and the same dependencies apply.

GPG commits: we have begun GPG-signing commits and merges. This is an important step in maintaining the integrity of the codebase, and will ensure that any compromise of our computers or even the github account won't allow a malicious attacker to push code to the repository without the unsigned commits being spotted. Verification can be done by running 'git log --show-signature', which will show and verify signatures. An example of what you should see is below:

Versioning: versioning is a lot easier, now, as tagged releases from 0.8.8.4 onwards will show version-final (eg. 0.8.8.4-final) as their version, and those built between tagged releases will show version-commithash (eg. 0.8.8.4-9088ea1). We expect this will greatly aid in debugging problems, as we can immediately pinpoint the actual version / commit a user is on.

Logging: default log levels have been adjusted so that non-critical warnings are now relegated to log-level 1 and above. Apart from the normal reorganisation notifications, the only messages in red that should show up in the daemon are actual errors.

We have slowed down development on the GUI to give us a bit more time to focus on the Monero internals. This is especially important given the recent attack. However, work has not come to a complete halt, and so we wanted to show off a couple of pages from the first start wizard. Bear in mind that these aren't mockups, this is the actual running Qt interface:

Dev Diary

Core: because of all of the rapid changes that we had to merge into master to deal with the aftermath of the block 202612 attack, we have to bring the development branch in sync. At this stage the development branch should not be considered usable until the rebase is complete.

Build: the big change is FreeBSD compatibility, as mentioned above. A more subtle change is that the build will now first look for miniupnpc on the local system, and use that if found. If it fails to find miniupnpc it will fall back to the local copy.

Build: there is a new Makefile target, release-static, that builds statically linked binaries for redistribution. At this stage it forces 64-bit builds, once we have the embedded database working cleanly we can remove this.

Wallet: per-kb fees are nearly complete, and will be deployed to testnet within the next week or so. Once some thorough testing has been done on testnet we can merge this into master, and transaction fees can return to "normal".

Blockchain: this took a bit of a backseat with the blockchain attacks. Now that things are back to some semblance of normality, the first implementation can be written. We have chosen LMDB for the initial implementation, as this will allow us to rapidly write a Berkeley DB interface based off of it (they use similar APIs) and thus have a baseline for performance comparisons.

Core: all non-critical "errors" and warnings have been moved to log-level 1. As a developer, you may find it useful to run log-level 1 or 2 as your default.

Major Updates

We know everyone is quite keen to play around with the GUI. We are still doing a great deal of underlying work, but we wanted to get the interface out there for everyone to have a play and see how they like it. There are some bugs (for example, resizing the MiniWindow interface does not work), and there are some spelling errors that we'll fix as we pull everything out for Qt Linguist to handle translation. But if you're happy to play around then please grab a binary - we'll take feedback in the form of github issues as soon as we've finalised the initial release of the interface and have it up there. You can download the interface binary for Windows or Mac. We'll also push a Linux build out in the next day or two once it is confirmed as all working!

Our /r/monero sub-reddit broke 600 subscribers! If you are a Redditor and you aren't subscribed, now would be a very excellent time to do so! And whilst you're sorting out your social media, why not make a turn at our Facebook Page and click the "Like" button, and then swing past our Twitter and make sure you're following us:)

We are always quite hesitant when it comes to discussing donations, but they have been quite thin, which does make our job that much more difficult. With our increased download and testing equipment costs, we are spread quite thin. But fear not, within the next week or two we are going to have a way you can donate to the ongoing development of Monero whilst still getting something directly. In the interim, please do not forget that the donation addresses are in the OP, and that it is your ongoing support that is helping us plough ahead with development!

In case you haven't watched the #Monero-Dev Fireside Chat, we'd like to take a moment to discuss an upcoming terminology change. To take it from the github issue that has been at the centre of the discussion: It's been suggested that "wallet" is a poor description for laymen, and may hinder adoption. It's also arguably sexist - men have wallets, women have purses, and whilst "moneybag" is genderless it's probably the wrong term;) Whilst Monero is quite far from a point where this terminology becomes an issue, it's the sort of change that we can make sooner rather than later. The term we're going to be moving to is "account". We are aware that some may think that this implies centralisation, but there are key advantages to making this switch, especially as it pertains to new users not familiar with cryptocurrencies:

It fits in with the whole "be your own bank" motion, which is a good way to explain cryptocurrency in general to people

The idea of separation of accounts is already familiar to people - a married couple may have a joint account, a company will have an account (or accounts), a savings account would be separate, and so on

People are familiar and happy with paying a fee for moving funds between accounts, so it won't be foreign to them

It's the most familiar path for the general public. They understand creating an account, using a strong password, password recovery, etc. It's a natural transition for them.

We expect to make this change sometime in the next month or so when we have our next tagged release.

thefunkybits started a Twitter campaign to mention Monero to major exchanges and news outlets. He is paying 0.4 XMR per Tweet, so if that is something you're interested in head on over to his thread on the matter.

Atrides, the admin of DwarfPool, released an open-source Monero stratum proxy. This allows multiple mining machines inside of a network to all connect to the proxy server, so that only a single connection to the Internet is made. It's also useful for geographically distributed mining rigs, or even for miners that simultaneously GPU and CPU mine. More info is at his thread, and the code is on his github repo.

This week we have been working on finalising the QoS bandwidth control, finalising the mingw64 Windows build system (thus removing the need for Microsoft Visual Studio on Windows builds), and an effort has begun to refactor the wallet code so that integration with the GUI will be much easier later on (and to make things ready for the wallet -> account terminology change).

Dev Diary

Core: we are going to be adding a development branch to the main repo so that vaguely working code can be merged there and rebased by all contributors faster. Right now the multiple branches are becoming messy for rebasing. This won't change that the main branch is staging, but it will provide better fluidity, and obviously all the changes can be merged into master when they are ready for broader end-user/environment testing. Ongoing testing of this branch is heavily encouraged, and opening github issues (for issues that actually exist) will be rewarded with 1x our eternal gratitude (limited to 10 per user).

Build: most of the mingw64 / msys2 is "done", thanks to the mikezackles' hard work. The branch is currently here: https://github.com/mikezackles/bitmonero/tree/mingw. However, we will be pushing this (which includes the Windows service and daemonize changes, as well as the rpcwallet change) into the development branch on Monday. Once it's up, please test it, especially on Windows environments, so we can start stripping out the VS ifdefs.

Blockchain: tewinget's abstraction and refactoring of the blockchain functions is coming to a head, and we are hoping to start some specific integrations for performance testing so that an embedded database can be decided on and fixed.

Core: QoS will need to be rebased by rfree once the mingw branch is pushed to the development branch. Subsequent to rebasing, it will also be merged in to development, so barring any breaking issues it should be available for general testing within the next week.

This Missive was meant to go out on August 10th, but due to a little miscommunication and all the excitement with the new GUI, it went out quite a bit later. Please accept our apologies for the delay in bringing this to you!

Major Updates

We had an extremely successful #Monero-Dev Fireside Chat broadcast last Friday. This was a special event as it let us show off the GUI and talk about all the work that has gone into it thus far. That having been said, the #Monero-Dev Fireside Chats are developer-centric events, so as and when we do them again in future the focus will be more on core components, RPC/IPC, and future development efforts that affect the way developers interact with, expand, and use Monero. We are hoping to do our next #Monero-Dev Fireside Chat in a few weeks once there are more changes that are discussion worth. If you haven't seen the first Fireside Chat, you can always catch-up and watch it here.

As mentioned, we showed off the work that has been done thus far on the Monero GUI. There is still quite a bit of work to be done, but we are very proud of what has been accomplished thus far. You can take a look at the work that has been put into the GUI in these screenshots. A couple of common questions that we'd like to address:

This is not a web-based GUI, it is a standalone desktop application, and is thus not open to common web-based UI exploits (XSS and so on)

It is written using Qt, and is completely cross-platform, so it will run on Windows, Mac, and Linux without issue

There are lots of aspects that are a work-in-progress, so if you spot any spelling errors and so on make a note of it and see if it isn't fixed when we push the first release of the interface up on github for everyone to play with before we start integrating it into the code

There is still a lot of work to be done, so we are unable to provide a release timeline, but we are working on it as hard as possible

We'd also like to extend a warm thank you to all who have donated. The GUI, and everything we do on Monero, is completely donation supported. Without your effort we would not be able to continue working on Monero at the pace we have been! Don't forget that by donating you can secure your place in the Monero Community Hall of Fame!

For those that want to include a price ticker on their website, CoinGecko has an excellent Monero price ticker that lets you display the current Monero price in BTC, USD, GBP, EUR, and lots of other currencies. It's easy to use, and it produces a small snippet you can drop into your website's HTML.

Much of the development effort this week has been building up to the Fireside Chat. A major improvement in the development process is the purchase and configuration of a proper test environment, as we move towards a Continuous Integration process that will allow for much faster testing and deployment. We are also rapidly getting to a point where Windows users will be able to compile Monero without needing Visual Studio.

Build: rfree has completely overhauled the CMakeLists to make for target-specific builds (ie. binaries can be included and excluded at the command line, test suite can be excluded, and precompiled headers can be used to speed up builds). This is in a PR if anyone wants to test it before merge: https://github.com/monero-project/bitmonero/pull/91

Core: part of the PR from rfree is to completely discard the old epee logging system, and move to a logging system he originally developed for Open Transactions. This allows for channeled logging (ie. separation of log levels in log files), as well as a host of other logging improvements. There is still some work to be done on this, but this will be the only logging method available soon, and contributed code will need to use the appropriate calls instead of the old epee calls.

Testing: dbit is going to be working on bringing the unit tests up to scratch and on creating missing unit tests. We have now rented a reasonably specced Mac Mini from MacStadium, and quite a beefy test server from Hetzner to handle VMs for all the Windows and Linux flavours needed. We will be purchasing Windows licenses for the test VMs over the coming weeks.

Download: after taking quite a financial hit servicing nearly 100tb of blockchain and client downloads over the month of April, we're in the process of moving all downloads on to edge servers in data centers in the US, the UK, and the EU. Servers have been rented, and there is quite a bit of work to be done configuring them. Thankfully, all of these servers are on 1gbps unmetered connections, so that will vastly reduce our bandwidth costs next month.

Hello, and welcome to our ninth Monero Missive! Sincerest apologies for the late posting of this one, there were some interesting statistics we were finalising that you will find below.

Major Updates

We had a lot of fun giving a Git Crash Course last week Wednesday, and it was well received by all despite some technical issues with the sound. To that end, we've decided to launch a regular "Monero Fireside Chat" session as a way of both introducing the occasional new feature even before its announcement in the Monero Missives, and as an ongoing developer technical resource. We aren't sure of the frequency we'll do these, so we'll announce them as they're planned. Our first one will be this Friday, August 8th, 2014, at 9:00 EST (note: EST, not EDT) which is 14:00 UTC and 16:00 UTC +2 (aka FOST - fluffypony and othe standard time). This week Friday we will have a very special announcement, before going in to a technical discussion, so if you are able to join us live for that then please do so. It will be broadcast live via Google Hangouts on Air, so you'll be able to watch it on YouTube, and during the dev discussion portion following the announcement we'll be available to take questions on IRC in #monero-dev on Freenode.

We've only recently started tracking our download stats (since July 15th), and we thought we'd share with you some download stats for Monero over the past 3 weeks. Our most popular download has been our blockchain bootstrap, which has seen 41 425 completed downloads in 3 weeks, around 74tb of traffic usage! Leading the pack on these downloads is Windows with around 78.2%, followed by OS X with 14.5%, and the remaining 7.3% snagged by Linux. The client downloads are quite interesting, too - of a total of 15 000 downloads in 3 weeks, Windows again grabbed 78.4%, OS X only grabbing 9%, and Linux grabbing a surprising 12.6%! This obviously excludes those that clone the github repo and compile, which is the majority of Linux users and OS X users (thanks to sammy007's Homebrew recipe). We'd like to thank the donations we've received thus far - it goes directly to many things, including covering costs like the bandwidth provision to help bootstrap new users.

As mentioned in our last Monero Missive, Poloniex added a number of XMR market pairs. In the 12 days since, those markets have had a combined volume of 5830 XMR, and it is growing on a daily basis. The additional liquidity for both miners and traders is certainly a boon to cementing Monero's market position.

Most of the dev effort recently has been around a smoother and cleaner build process, which is important as we move towards continuous integration (through Jenkins) as well as deterministic builds (through Gitian). This will mean that binaries of the code that is currently undergoing testing will be readily available, and it also means that we will have a secure build process so that the binaries you download from the Monero website will be verified and verifiable. Over and above that, the QoS bandwidth management system is functionally complete, and will go into the main staging branch for testing within the next few days. Finally, the backend for DNS seed nodes has been completed, the source code has been published, and the Monero seed nodes are up and running. Integration of DNS seeds into the network seed procedure still has to be completed, but when complete this will ensure a safer and vastly more secure method of discovering the Monero network and connecting to it.

Dev Diary

Build: we've added a Windows build script to make building on Windows easier (it's in /utils/build_scripts/windows.bat). Tangentially to that, we are moving away from the VS 2013 requirement on Windows, and switching to msys2 for dependency management and mingw64 for Windows C / C++ compilation. Progress on this can be tracked in mikezackles' branch: https://github.com/mikezackles/bitmonero/tree/mingw

Core: QoS is feature complete, although some peripheral components such as bandwidth utilisation tracking is still WIP. Completed work will be pushed upstream to staging for broader testing within the next week. Progress can be tracked on rfree's branch: https://github.com/rfree2monero/bitmonero/tree/dev-rfree

Blockchain: the embedded DB work is exceedingly complex work that requires a lot of thought, but it is progressing at a clip. Abstracted code is being refactored, and tewinget has moved to a clean branch for this. Progress can be tracked here: https://github.com/tewinget/bitmonero/tree/bc2

Core: jakoblind has closed a number of github issues. The first major one is adding an optional blockheight parameter to a wallet refresh (ie. refresh from that point).

Core: the second issue closed by jakoblind is the addition of a set of RPC and CLI calls to retrieve the mnemonic seed or the view key for an open wallet. The new RPC call is query_key (a generalised call that lets you specify 'mnemonic' or 'view_key' as the key type). The CLI command is 'seed' to retrieve the mnemonic seed, and 'viewkey' to retrieve the view key. Wallets that are not deterministic (ie. very old wallets, or wallets that are specifically created as non-deterministic) will error out when trying to retrieve the mnemonic.

Core: as mentioned in the Missive, the source code for the DNS seeder is available: https://github.com/monero-project/xmr-seeder. It is as simple as possible (and even a little hacky), but it is beneficial in that we don't have to run BIND to service requests. Instead, we use Gandi.net's API, which is advantageous in that Gandi supports AnyCast for DNS (rapid updates). DNS seeds are by and large a convenience feature, so a group of superpeers will still be available as hard-coded seed nodes, and there will be an option to forego the use of DNS seeds. DNS seed support still needs to be added to the client, possibly along with DNSSEC support. The four DNS seeds (delivered as A records for ipv4, and later on as AAA records for ipv6 when ipv6 support is better baked in) are at: seeds.moneroseeds.ch, seeds.moneroseeds.li, seeds.moneroseeds.ae.org, and seeds.moneroseeds.se

Major Updates

We're extremely pleased to announce that Poloniex has, once again, proven their class-leading initiative by being the first major exchange to add Monero trading pairs. This has been coming for a while, given Monero's large trade volume on Poloniex, and we are certainly grateful to Poloniex for their forward-thinking approach. The markets that have been added are: BCN/XMR, DIEM/XMR, DRK/XMR, IFC/XMR, MAID/XMR, NXT/XMR, and QORA/XMR. The Poloniex press release can be found here.

A major change that has been made concerns the license Monero currently uses. We inherited the MIT / X11 license from CryptoNote, which is a very permissive license that explicitly allows re-licensing with compatible licenses. We have thus decided to move to the BSD 3-clause license, which is equally permissive, enforces attribution, and has a clause that prevents "the name of the copyright holder nor the names of its contributors" from being used to promote or endorse products. The epee library that is part of Monero was already under a BSD 3-clause license, so all we have done is just replaced it with the standard formatting we're using, and have included the original in the /contrib/epee/LICENSE.txt, noted as being the original license as it appeared. We have taken great care to preserve ALL copyrights for the original code, which are attributed to "the Cryptonote developers" for most of it, and "Andrey N. Sabelnikov" for epee. Our copyright appears above that so that we are the copyright holders for any new code. Any brand new files that are added by us will not get any copyright attribution except ours (eg. electrum-words.h and .cpp that have been added by us).
For public domain code we have left the license as is (much of the crypto hashing code, for instance). If you spot ANY code where the original author has not been credited or copyright has not been retained, please let us know by opening an issue on Github or messaging or emailing us.

Along with this change is a new README, that should be a little better at giving the correct build instructions, as well as explaining the development rationale and a more formal staging -> tagged release methodology we will be using moving forward.

Since git (and, by extension, github) can be confusing to developers that are working on Monero code (or on any git repositories, really), one of the Monero key contributors, tewinget, will be hosting a Git Crash Course next week Wednesday, July 30th. He will be joined by fluffypony, and all interested are invited to attend. It will be broadcast through Twitch, and questions and discussions will happen in #monero-dev on Freenode during the course. It's going to be relaxed and informal, so if you want to know how to use git properly it's well worth tuning in. It will start at 2pm EST (6pm UCT). Feel free to invite anyone that you think will benefit from it!

Dev Diary

RPC: a new RPC call has been added to the daemon, get_info. This returns information on the current state of the daemon and the network, including the current block height.

RPC: the new get_bulk_payments RPC call is complete and available. Apart from being able to pass thousands of payment IDs to this function, you can optionally pass a block height, and it will scan from the block height up. To give you an indication: Poloniex went from taking nearly 45 minutes to scan all of their payment IDs with get_payments, to it taking around 17 seconds with get_bulk_payments.

Core: the major change of introducing rpcwallet, as well as proper daemonization / service mode (on *nix or Windows respectively) is ready for testing. If you are able to, please compile and test this branch so we can finalise it and merge it in: https://github.com/mikezackles/bitmonero/tree/daemonize_wip

Major Updates

We've had an incredibly positive response to our ongoing need for donations, and we'd like to thank everyone that has donated and continues to donate. Several pools have stepped up to donate some of their fees to us - CryptonotepoolUK, for instance, has a 1% fee, but the entirety of the fee is donated. Risto Pietila has also kindly setup a donation "Hall of Fame", which has been taken over by cAPSLOCK, and can be found here. This, and all the ongoing donations, are critical to our ability to spend even more time and energy on Monero, and are greatly appreciated.

Now that the CryptoNote whitepaper has been peer reviewed by our mathematicians and cryptographers, they have begun initial work reviewing the implementation thereof. This is most especially important, as Monero has inherited quite a bit from the CryptoNote reference code. The initial focus is on the cryptographic primitives and higher-level cryptographic functions, which will be evaluated by code analysis as well as by running test vectors (that are different from those in the Monero test suite) against those functions. The methodologies and results will, of course, be published in due time.

A number of important and critical dev efforts are under way, most notably the embedded database work (to cut down on the RAM requirement), the daemonising work (to allow for a much more stable environment for exchanges, pools, merchants, and other automated systems), and the QoS work (to reduce and limit the bandwidth requirements). Technical updates on these are in the dev diary below.

We'd like to officially welcome Pavel Kravchenko as a key technical contributor to Monero. With a PhD in Information Security, specialising in public key infrastructures, he will be devoting some time to tackling the larger issues that Monero faces in its drive to become a truly private, untraceable cryptocurrency.

Further to the last missive, the German word list has been completed, and work has begun on the Portuguese version. This is very early work, and is very important to our ensuring that it fits well with our current mnemonic system.

Dev Diary

Blockchain: abstraction of the blockchain storage functions is basically complete, and the next step will be to start integrating LevelDB so that we have a baseline for our performance testing. A number of the key-value stores / embedded databases that we will be evaluating are forked from LevelDB, so it makes sense to start with that. This is moving out of "core" and into "blockchain" for categorisation going forward. The ongoing progress on this can be followed here: https://github.com/tewinget/bitmonero/tree/blockchain

Core / Wallet: much of the work on daemonising Monero has been complete. On Unix-like systems (Linux, OS X) the daemon backgrounds correctly, and commands can be run against the daemon (through command line arguments or RPC calls). On Windows the daemon can install itself as a Windows service, and can subsequently be managed through the standard Windows service system. The Windows service can also be removed by the daemon. Similarly, rpcwallet has inherited this functionality, with the difference that rpcwallet can run in multiple instances (whereas the daemon only allows a single instance). This covers edge cases where a single machine needs to have multiple wallets accessible via multiple rpcwallet instances.

RPC: a new get_connections RPC call has been added to the daemon and merged into master. This is needed by the DNS seed control software, which is at a very early stage. Once complete the hardcoded seed nodes will be removed in lieu of DNS seeds. At a later stage when the DNS seed control software is feature complete, there will be a call for 4 or 5 people who are happy to run DNS seeds on an extremely long-term basis.

RPC: due to some exchanges finding it difficult to poll get_payments, an urgent change has been made to allow for get_payments to take multiple payment IDs are input, as well as a block height to scan from (excluding older transactions). This will break compatibility with the classic get_payments, and will thus be moved to a call of its own. The initial commit can be found here, and tested if you are feeling particularly brave: https://github.com/mikezackles/bitmonero/commit/65c6b193e406fe23944c63eb0a6b69165ef5666b

Major Updates

The GUI bounty is completed and all payouts have been made. You can view the confirmation of payouts in this post, and bounty recipients have confirmed receipt of their bounties. Just to reiterate the comments made by us in that thread: "As it stands right now, we won't be integrating any of these GUI clients into the main codebase just yet, as there is still a great deal of underlying work that must be done before we can ship a GUI wallet that just about anyone can run (unless we want to make the minimum memory requirement 8gb and the minimum Internet connection requirement 20mbps;) That having been said, we will continue to recommend the actively developed GUI wallets to anyone who prefers to use a GUI wallet, and that is the main purpose behind closing and awarding this bounty now: to have a short-list of recommended GUI wallets." The two GUI wallets we recommend using and that are being actively and continuously developed are:

As you may be aware, there's been a great deal of discussion around dev donations. It wasn't something we thought to raise previously, as it is generally accepted that if you are making money from an open-source project (eg. mining, buying and holding for future profit, whatever) you will generally donate as that is the best way to secure an increase in your "investment". It is important to note that this is not a cryptocurrency that has a big, fat premine (or any sort of instamine / ninjamine / premine), and we are, therefore, completely reliant on the donations of our users. We really, truly appreciate all of the donations that we have received, from early pools such as the now-defunct monero.farm contributing a large portion of their earnings, to our largest donation from ceger, to the ramp-up in dev donations from a screed of pools. Thank you, you guys are the ones that are helping us cover costs and pay for contributors where necessary.

The initial work has been completed on analysing the CryptoNote whitepaper, and the review that has come out of it is now available to all. This is an academic approach to analysing it, and is the first step in figuring out whether the principles it espouses are reflected in the Monero code, and (further to that) how we can improve on its deficiencies. You can grab the whitepaper review here: http://monero.cc/downloads/whitepaper_review.pdf

Very early work has begun on reimplementing the mnemonic wordlists in other languages. We are currently doing a German one as a tester to see the amount of effort involved. If you are interested in producing a mnemonic wordlist (1626 words, following a small set of rules) in a language other than German or English please drop us a pm. There will be other translation work coming up (website, tooling etc.), and we will definitely be distributing donations to translators where possible (although they may be relatively small for the work involved).

Dev Diary

Core / Wallet: both the new daemonized daemon and rpcwallet are nearing a stage where they can be merged into master. The final step is to finalise the daemonizing code in rpcwallet, in such a way that it acts the same as the daemon, and we can move from there.

I8N: mnemonic word list German version is in progress and about 90% complete.

I2P: subsequent to discussions with the I2P team, we are going to be making a bit of a diagonal movement from libi2pcpp to i2pd. This should end up with us slightly ahead on the I2P integration project than we would've been. The major focus at the moment is getting TCP streaming (for persistent connections) to work, and that is where the largest focus is at present.