This is our first Missive for 2015, after a 2 week break over the end of December. We'd like to earnestly thank everyone for their support over the course of this year, and for joining us on the start of our Monero journey. We'd also like to take this opportunity to look back on the past 8 months, and see where we got to.

State of Monero: 2014

As an open-source project, Monero is built on the back of volunteers, contributors, and donations. So let's start with a financial report.

For donations received over the year: we received 21 636.40655 XMR spread over 4343 transactions, and 8.04559 BTC spread over 25 transactions. Thus our average XMR donation is around 5 XMR, and our average BTC donation is around 0.32 BTC. As most of our costs are BTC based, XMR donations were traded into BTC where necessary (typically through OTC trades and not on-market), giving us a rough total of all receipts of 39.536205689 BTC (in XMR donations) + 8.04559 BTC (in BTC donations) = 47.581795689 BTC.

Expenditure for the year comprised of 3 totals as some costs could not be settled in BTC or were preferably settled in XMR. Our expenditure was 190.513492 BTC + 1 891.31 XMR + US $5 732.80, which is around the 212 BTC mark. Thus the shortfall of 164.5 BTC was paid out of the Core Team's own pockets in the hopes of recovering the funds later on (ie. just in case anyone was wondering, not only do the core team not get paid at all, but we've put a significant amount of funds into Monero).

So, what did our ~212 BTC get spent on over the year? Or, in other words, what did we accomplish? Here's a bit of a taste before we dig into the nitty-gritty:

In order to see what we did with some pragmatism we took two folders, one containing the Monero source on April 30th at that last commit, and one containing the Monero source on December 31st. We removed everything in the external/ folder, except the CMakeLists.txt, so that we weren't including external libraries in our count. We then used Araxis Merge to produce a diff report between the two folders (plus Github's compare tool to give us additional information). We then subtracted the license changes we made earlier this year (208 files were affected, which means that for each we have to remove 2 lines from the "removed" count, 1 line from the "changed" count, and 28 lines from the "inserted" count). The summary is below, and whilst it obviously precludes things like where we made several changes to the same line of code, or missteps we reverted, it gives a very general indication of the effort.

35 weeks of development (245 days) since Monero was inherited by the Core Team

594 separate commits

11 contributors

10 221 modified lines

12 706 new lines

32 lines removed

Now may be thinking "wow, that's like 94 lines of code a day!", but it's important to remember that included in this are documentation and code comments, mnemonic word lists for several languages, as well as changes made to Bytecoin early on that we merged in.

However, it doesn't diminish the gargantuan effort that went into the Monero core over the year, and we are truly grateful to all who have been involved. Some of the highlights of work that was committed to the Monero core master repo over the past 8 months, in chronological order, include -

April:

got Monero building and running on OS X

May:

removed purposely obfuscated hashing loop

added a 'diff' daemon command to show current estimated difficulty and hash rate

dropped support for Visual Studio, added support for mingw-w64 + msys2

DNS resolver (libunbound) added, initial OpenAlias support

dynamic file-based checkpointing added

multi-language mnemonics introduced for wallets

new wordlists: Portuguese, and Spanish (first 4 letters unique)

DNS checkpointing added for rapid checkpoint alert / enforcement

October:

reworked log level choices

new wordlists: English (first 3 letters unique), as well as Japanese (first 4 letters unique)

PoW algorithm fully documented

switched to RapidJSON for JSON parsing

changed wallet file format (encrypted JSON)

massive CMake overhaul begun by KitWare, the creators of CMake

November:

per-kb transaction fees introduced

CMake overhaul completed, dynamic and static builds finally working again on all platforms

December:

bug fixes, bug fixes, and more bug fixes

The Monero Research Lab

Another major effort has been the Monero Research Lab, the MRL. In addition to the members of the core team, the triplets (Surae / Sarang / Shen Noether, obviously pseudonyms) spent months reviewing the CryptoNote whitepaper, publishing a synopsis of their review, and then building on that by doing extensive Monero research and finally producing several important research bulletins. From the ground-breaking chain reaction attacks in MRL-0001 to the deep dive explanation of Monero Ring Signatures in MRL-0003 (and the accompanying Python implementation) it has been 8 months of remarkable output for a group of people that at best only knew of each other very peripherally.

The Monero Research Lab members have also engaged regularly with Bitcoin researchers, including a mutually beneficial friendship with Andrew Poelstra who is included in the group of the "MRL Friends".

Between the whitepaper annotations, the review, and the MRL research bulletins published in 2014, 655 lines of python were released and over 25 000 words were written, all of which was the culmination of over 197 000 words spent in intense academic discussion.

The academics in the MRL also had an opportunity to meet up with Riccardo Spagni (fluffypony) and Tom Winget (tewinget) towards the end of the year, in a weekend of epic nerdiness that included a trip to a natural history museum and getting stuck on the side of the highway with no petrol due to a faulty gauge. Don't worry, the emergency petrol fill up wasn't paid for by donations;)

Infrastructure

Our web hosting serves the Monero website, the Monero forum, the Monero Research Lab site, and so on.

Testing infrastructure consists of a Mac Mini hosted at MacStadium, as well as a beefy testing box hosted at Hetzner in Germany, on which we have a number of VMs for the various operating systems and variants we target. Our QA lead contributor, Gazby, who has recently started will be bringing the testing infrastructure up to scratch, and adding things like Jenkins for nightly builds and Gitian for deterministic signed releases.

Download hosting consists of several servers scattered across the globe (3x USA, 2x UK, 1x Germany), and it serves all static content including the blockchain downloads, Monero binaries, MRL publications, and so on. The Monero blockchain alone is downloaded hundreds of times in a month, with our bandwidth usage regularly exceeding 2tb a month across the download nodes. Obviously this provision is not cheap, which is why your continued assistance to this project is greatly appreciated.

OpenAlias

An important project that the Monero Core Team created and developed is OpenAlias. Monero addresses are ugly, complex, and not really human readable. But then, too, so are Bitcoin addresses. Typically most cryptocurrencies attempt to solve this by having some sort of centralised register, say they've developed "aliasing", and call it a day. For Monero, this approach simply wasn't good enough.

To understand why it is important one must first understand "Zooko's Triangle". Zooko Wilcox-O'Hearn, the incredible brain that contributed so much to the Tahoe-LAFS distributed file system (and which was first released May 2nd, 2007), posited that any naming or aliasing system has three goals or desirable traits (and we're just going to quote Wikipedia here) -

Human-meaningful: The quality of meaningfulness and memorability to the users of the naming system. Domain names and nicknaming are naming systems that are highly memorable.

Decentralized: The lack of a centralized authority for determining the meaning of a name. Instead, measures such as a Web of trust are used.

Secure: The quality that there is one, unique and specific entity to which the name maps. For instance, domain names are unique because there is just one party able to prove that they are the owner of each domain name.

Zooko initially concluded that it was impossible for a naming system to have all 3, and at best it could hope to have 2 of the 3. Subsequently, systems such as Namecoin and Twister proved that it was, in fact, possible to have all 3.

Despite that, most of the aliasing / naming implementations that exist today seem to fail on the decentralised aspect (eg. requiring that a block is solved to register an alias centralises it in the hands of the large mining pools, and also limits the number of aliases that can be created a day), and almost always fail on the long-term goal of "human-meaningful".

We say the latter because a limited aliasing system where globally unique nicknames are chosen invariably devolves to a post-land-grab scenario where so many variants of "bob" have been acquired that a user is forced to chose bob0923840129832 as his alias, which really doesn't solve the naming issue at all. In addition, it forces the cryptocurrency creator to be the one responsible for solving alias disputes, and in many cases aliases are permanent and cannot be changed if you lose your private key.

OpenAlias is different. Not only does it "square Zooko's triangle" (still a unique and difficult to accomplish task), but it allows for the offloading of decentralisation to Namecoin or GNUnet or similar, whilst still allowing for the offloading of conflict resolution to existing systems such as ICANN's ADR (Alternative Dispute Resolution). Best of all, it leverages the fact that so many people and companies already own their own domain names, so there is no need for additional complexity.

Monero has implemented OpenAlias on quite a basic level, and will be improving its support as time goes on. The OpenAlias project has also not been standing still, and has been working on several sub-projects.

GUI and Database

With the two attacks we thwarted in 2014, the GUI development had to take a bit of a backseat. On the other hand, the blockchain database implementation has progressed nicely, and is currently being rebased to the latest master and tests are being updated and created for it.

The GUI code alone already consists of 5 213 lines of QML and over 100 lines of C++, and that is well before anything is wired up. The blockchainDB code consists of over 60 commits on the implementation alone (over and above the tons of commits to create the generic classes and implement all the functionality prior to that), with over 5 500 lines of code already part of it. It truly has been a monumental engineering task.

Monero Forum

A project guided and directed by the Core Team, although primarily written by a contributor (Eddieh), the forum grew out of an interesting need. On the one hand, Monero is still in its infancy, and the Monero sub-Reddit would likely have sufficed for quite some time. On the other hand, there was a general pressure for us to have our own forum, our own home.

So why didn't we just use something off-the-shelf? There were several reasons. The primary reason is that most forum software (SimpleMachines, phpBB, Vanilla, etc.) is either too clunky or too old to really be workable in a modern context. And, too, it would be something we would have to live with for a long time (see: Bitcointalk, for instance). Customising existing forum software to suit our needs would not have been cheap (see: Bitcointalk again). Thus a decision was made to see if we could find someone to pursue creating something fresh for us as a peripheral exercise.

After 6311 lines of PHP, 1226 lines of CSS, and 135 lines of JavaScript, we're proud of what we've produced. Instead of using antiquated content systems like BBCode, we have MarkDown. Instead of pages and pages of threads, we have infinite scrolling and threaded views. Instead of fundamentally flawed trust systems like "default trust" we have a synchronised copy of the Bitcoin-OTC Web of Trust, allowing users with existing WoT accounts to immediately have their trust groups accessible on the Monero Forum for trading. Instead of only meaningless sorting by date (which we have!) we have posts sorted by weight. Since weight is a product both of post age, insightful/irrelevant votes, and your trust relationship to the poster, you are already able to visit a thread and only see comments that are relevant to you, with all other comments collapsed. We are actively massaging more usefulness out of the weighting, but it is core and fundamental to the forum.

Obviously this is a project that still has a LONG way to go to reach maturity. With that in mind, don't forget that you are key to this: if there's something about the forum you don't like, or a feature you want, or a bug you've found, put it in the Meta section of the forum (until we have a github repo that you can post issues to).

The Monero Missives

Our first Missive was put out on Monday, June 2nd, 2014, and has been instrumental in collating and bringing together various little snippets and pieces of work and threads every week. In the 30 weeks from that first one till the end of the year we put them on pause for 4 weeks during the attacks in August, and took a 2 week break at the end of the year. The remaining 24 weeks had 21 Missives in them, giving quite a bit of coverage and keeping our userbase as informed as possible. Some Missives are easy and only take us two or three hours to put together.

Some Missives are substantially harder due to time constraints, dependencies, research (see: this Missive you're reading, for instance;) or just the sheer amount of stuff that is going on. In total, the 21 Missives we put out over the past 8 months contained nearly 16 000 words over 689 sentences!

And just for fun, this Missive took several days to put together (not all day, every day, mind you) and unsurprisingly ends up being our largest Missive by far, at 3 450 words and 111 sentences!

Other Core Team Projects

The two other projects the Core Team released in the year are the Monero DNS seeder (xmr-seeder), and URS, a Unique Ring Signature signing tool written in Go. Both of them are active contributions to the Monero infrastructure, and continue to be useful and fundamental on a daily basis.

External Projects: 2014

The Monero Core team and core contributors obviously aren't the only ones working on Monero-related projects. Some highlights from the year include:

Node CryptoNote Pool
When Monero first started there was no open-source pool software for it. Through the collective efforts of zone117x and lucasjones, an open-source pool was developed and released. It was an incredible undertaking, given the monstrous lack of documentation and code comments in the CryptoNote source, and we owe them a debt of thanks.

i2pd Development Partnership
Initially this started as a partnership with the i2p team, with a view to getting i2pcpp to a workable stage. When i2pcpp stalled, and on advice from the i2p team, we form the Privacy Solutions working group between Monero, AnonCoin, members of the i2p team, and the i2pd developers.
The focus for the past few months has been on i2pd, which has made amazing progress. Since the launch of the PrivacySolutions partnership at the end of July, a series of 692 commits has brought i2pd up to a stage where it can maintain relatively stable connections to the i2p network.

ForkGuard and MoneroClub
Both services launched and operated by Atrides, ForkGuard provides realtime information on the current block height for pools and services that run full Monero nodes, and MoneroClub is a listing of localised Monero and fiat OTC trade offers. Atrides isn't stopping there, and for his next project he's looking to produce a Monero fork of OpenBazaar!

MyMonero
Owned by Riccardo Spagni (fluffypony) and Risto Pietilä (rpietila), and operated by fluffypony, MyMonero is the first web-based client for Monero. In doing so it closes a major end-user usability gap, and goes a long way towards making Monero useful and usable.

Crypto Kingdom
Created and started by his lordship, King Risto, Crypto Kingdom is a retro-style virtual world game where players can interact, build, create, and so on. An online playable version is in the works, and as Monero is driving the in-game resources and currency it is well on its way to becoming a fully-fledged microeconomy!

Looking Forward: 2015

We have a lot in the pipeline for 2015. A few things that we'd like to highlight that you can look forward to:

more MRL academic goodness, including some of the work started at our MRL mini-meetup from 2014

a finalised, working, tested blockchain DB implementation using LMDB

i2p integration

some additional blockchain DB implementations

finalisation and release of the Monero core GUI

the release of smart mining functionality

the finalisation of a complete overhaul of the RPC functionality

HTTPS and simple auth support for RPC servers

a new, unified, well-documented RPC interface

blocknotify and walletnotify equivalents in the daemon and wallet client

a complete replacement of the wallet/server IPC with 0MQ

multi-signature transactions

open-sourcing the Monero Forum software

the release of some OpenAlias sub-projects

And, undoubtedly, much more both for Monero core and related external projects.

Of course, none of this would be possible without donations from our users, and we are most appreciative and grateful to those that have donated thus far. We hope that over the next year you will continue to help and assist us - and don't forget our donation addresses are powered by OpenAlias, both XMR and BTC donation addresses are on donate.monero.cc

With the Monero open-source cryptocurrency, your privacy is better protected than with any other technology. No one can know how much money you own, where it comes from or where you spend it. Exactly like cash*, it is untraceable and unlinkeable. This is an improvement over Bitcoin which, contrary to popular belief, gives away even more information than a bank account number.

Monero was launched in April 2014 and is actively developed since then. For the moment, the easiest way to store your moneros is to use the webwallet mymonero.com.

The official site of the Monero Economy Group is live on the first day of the year!

There is an awful lot to do. What we need the most is designers (Drupal) and content creators although pretty soon it would be better to move to a larger webserver too. Please comment on how you'd like to participate - or even just to show your support with a nice comment!

Major Updates

We're aware of the 0.8.8.6 slow startup issues on some Windows environments (over an hour for the daemon to startup for some people). We believe we've identified the problem, and will be rolling out a test fix in the next couple of days, for inclusion in 0.8.8.7

There have been a number of patches merged over the past week to fix issues with simplewallet's new multi-language mnemonics

External Projects

MyMonero: due to a very broad DDoS attack at the data center in which MyMonero is hosted (not targeted at MyMonero) the service was offline on Sunday for a 12 hour stretch. We are putting some effort in place to ensure this does not happen again in future. New features added this past week: a "copy to clipboard" helper is now available on the right of your Monero address on your dashboard, as well as on the login key review screen and account details screen. In addition, clicking on a transaction in the dashboard or your transaction history screens will show additional details, such as the payment ID used.

ForkGuard: added MyMonero.com and MoneroClub.com

I2PD: massive progress was made this week adding support for the su3 router update format (the previous .sud / .su2 format being deprecated), which is used to deliver updates to all routers on the i2p network, including: router update alerts, plugin update alerts, reseed data, and news feed items. Details on the su3 format can be found here: https://geti2p.net/en/docs/spec/updates

Dev Diary

Account: still more fixes to the restore paths and multi-lang mnemonics, known issues with UTF-8 on Windows remain

Core: libunbound lookups moved to a thread in order to trap for failing / slow DNS lookups

Hello, and welcome to our twentieth Monero Monday Missive! We're combining last week's one with this week's, as last week's Missive was pulled down shortly after being put up due to breaking issues in the Windows build of Monero 0.8.8.5 (since resolved). Thank you for your patience!

NOTE: When opening your wallet with simplewallet for the first time with this update you will be prompted to choose a language for your mnemonic seed words, and you will be given a new 25 word mnemonic. You will always be able to restore from the old 24 word mnemonic seed, but it is of course recommended that you move to the newer, more robust mnemonic.

We are (finally) happy to release Monero 0.8.8.6. We released 0.8.8.5 last week, but due to a breaking Windows bug we pulled the announcement down until we solved the bug on the weekend. The major changes for 0.8.8.5 include: OpenAlias support, per-kb fees, multi-language mnemonics, file-based checkpointing, MoneroPulse DNS checkpointing, a move from MSVC to an msys2 / mingw-w64 build environment for Windows, and brand new build CMake. 0.8.8.6 adds some important fixes to the multi-language mnemonic system.

Due to the launch of MyMonero we feel it prudent to add a new section to the Missives, called "External Projects". This is a section to provide updates on other projects that are not an official part of the Monero Project or collectively created by the Monero Core Team, but is related to Monero in some way - thus OpenAlias would not be part of this section, but MyMonero would. If you have an update you would like included in this section, please email dev@monero.cc for inclusion the following Monday, or send any member of the Monero Core Team a message. If this section becomes overly full we may choose to shutter the section, so please keep updates brief and only those that are important. It is not a marketing area, and so every new mining pool launched or minor feature added to a pool will not be eligible for inclusion (although if you've done something cool, let us know;)

We're also quite happy to announce the addition of a new feature to Monero: Smart Mining. This is a feature that will evolve over time, but at its most basic it is something that will allow everyone running the client software to support the network in an unobtrusive manner. Smart Mining detects your CPU usage, and if your CPU is idle and you aren't on battery power (for laptops and/or connected UPS devices) it will begin mining. As soon you switch to battery power or your CPU activity picks up it will pause mining until it sees it is safe to start again. You still set your Monero address for Smart Mining, as always, and whilst your chances of solving a block may be relatively small (for now;) it is still an easy way to support the network without needing to purchase expensive equipment. This work is complete (for Linux) and is currently being tweaked to work on our other supported operating systems. Ongoing process can be followed here: https://github.com/oranjuice/bitmonero/tree/smart-mining

External Projects

MyMonero: the various modal windows, such as the login screen, should be displaying correctly across devices now. We are fixing the scroll issues which still plagues these on some devices. Just to make sure everyone is aware after the recent blockchain.info issues: the MyMonero code has unit tests using the Jasmine testing framework for JavaScript, as well as tests for other parts of the backend application. These tests are executed and checked for every commit. We also have had HTTP Strict Transport Security (HSTS) enabled from the beginning, and have various other things enabled for client-side security such as X-Frame-Options set to deny, X-XSS-Protection on, and X-Content-Type-Options set to nosniff.

I2PD: for those not aware, the i2pd project is a new implementation of the i2p protocol in C++, and is the software that Monero will use for its connection to the i2p network. The source code of the project can be found here: https://github.com/PrivacySolutions/i2pd - the regular stream of commits is testament to the ongoing progress being made. The i2pd team will provide regular updates on i2p-specific functionality as it is added and the project grows to a point of maturity.

Dev Diary

Build: tests are now disabled when building the build-release, build-debug, or release-static targets. The default make target (all-release) will include tests, as will all test- targets, obviously.

Account: lots of fixes to multi-lang mnemonics, although UTF-8 on Windows still seems to be a bit shaky.

Core: all 0.8.8.5 and 0.8.8.6 changes have been covered over the past few Missives.

It is with great pride that we announce the very first Monero hosted account service (a web wallet for Monero, if you will), which we are certain will provide a level of accessibility that was previously unknown with Monero. My Monero is managed by Riccardo "fluffypony" Spagni, although it was created through the efforts and hard work of many people including members of the Monero Core Team, Lucas Jones, Matthew Little, and seed funding provided by Risto Pietila. All of the heavy lifting is done client-side, which means that My Monero can never spend your funds on your behalf or without your authorisation. However, there is a small compromise in that the server knows your view key, which is necessary in order for it to identify transactions belonging to you. Thus there is some reduction in transactional privacy when using My Monero, as if the service is compromised your view key would be revealed. That having been said, stealth addresses would still be in effect even if the server was compromised, and thus transactions can still be said to be unlinkable. If you are truly concerned about absolute transactional privacy, then running your own Monero node will always be the preferred route.

Significant progress has been made to fixing the last few Windows build issues. KitWare have worked with us ensuring that our CMake is 100% up to their best practices, and the resulting 2 905 lines of new CMake (!!!) is evidence thereof: https://github.com/monero-project/bitmonero/pull/180/files. Now that we are seeing light at the end of the proverbial tunnel, we expect to tidy this up by the end of the week and can finally tag-and-release Monero 0.8.8.5.

We are working hard on solving the blockchain DB bugs as and where they are found. If all goes well we should have enough of the nuances worked out to have it merged into master within the next 4 weeks.

We have seen our QA (automated testing) / CI (Continuous Integration) / Gitian build efforts drag their heels extremely slowly over the past few months, mostly due to specialists in those fields originally interested in helping us finally not being able to commit to any significant period of assistance. We are stepping this up a notch with the assistance of a new contributor, Gazby in #monero-dev, who will focus on the devops work.

Dev Diary

Core: msys2 now successfully compiles static releases in PR 180, final testing of new builds will happen this week

Core: expect a mass merge of PRs previously waiting this week. If you have a PR with CMake changes in it expect it to be merged and fixed manually, but moving forward CMake changes will have to comply with the new, cleaner CMake.

Major Updates

We still have ongoing Windows static build issues, which is preventing us from tagging and releasing Monero 0.8.8.5. It is our highest item of priority at the moment, although the nature of the problem and the geographic / timezone spread of the various people working on it means that testing and reproducing the problems is a painstakingly slow process.

On the topic of binaries, we'd like to just remind everyone that the only trustworthy, official binaries are those release by the core team. Any others on any other website may or may not be safe, but it is always recommended that the appropriate level of caution is exercised and that unofficial builds are avoided if possible.

Over the weekend of the 8th and 9th of November the Monero Research Lab had a closed mini-meetup in Salt Lake City, Utah, USA. In attendance were surae, sarang, and shen, as well as tewinget and fluffypony. A great time was had by all attendees meeting for the first time, and long academic discussions were the order of the day. Three primary focus areas that the MRL researchers will be looking at going forward are: Difficulty - an initial foray into creating a more robust, well-understood, and documented difficulty retargeting algorithm; Payment IDs - simplifying payment ID use, including stealth payment IDs or encouraging cross-blockchain payment ID collision; Offloading Processing - ways and means to offload viewkey scanning to a hosted daemon in a way that does not reveal the viewkey to the hosted instance

Excellent feedback has been received from all those that have been testing the initial blockchain DB implementation. Please keep those coming - of particular use would be to test rollbacks by creating a fake checkpoints.json file. We need to ascertain how performant and reliable rollbacks are on various environments.

Hello, and welcome to our seventeeth Monero Monday Missive! This Missive has been horrendously delayed due to travelling, jetlag, and timezones. Nonetheless, we're keeping it short and sweet, as it is a prelude to next week's Missive, in which we hope to have some binaries so you don't have to compile source code to test these new features;)

Major Updates

For those following the database development, we are at a point where it is actually syncing! Our initial observations are that as the blockchain grows LMDB's virtual memory requirements will increase, but since it will rarely touch any of the virtually mapped data the real memory requirements are incredibly tiny. We are currently testing rollbacks and edge-cases, but if you would like to give it a spin (or just check out the nearly 6 000 lines of code that comprise of the blockchain DB clase and the initial lmdb implementation) then you need to clone tewinget's repo and checkout the blockchain branch - https://github.com/tewinget/bitmonero/tree/blockchain (note that this is pretty much Linux only at this stage, Windows and OS X support will come soon)

Per-kb fees are ready to go, and has been merged into the master repository! The per-kb fee has initially been set at 0.01 XMR per kb, and we are confident that this will be a suitable fee for the moment. We are not going to enforce a block-point hard fork, but we would appreciate it if major pools could upgrade by Monday. Thereafter, exchanges and users can upgrade over the course of next week as Monero 0.8.8.5 is released.

Our shiny new CMake is also nearly ready - there are a few final nigglies on Windows and FreeBSD, and then it'll be all merged in.

Dev Diary

Core: LMDB implementation is complete, and is undergoing testing for drastic rollbacks and edge cases. Please grab and test (link is above)

Core: per-kb fees merged into master, and switchover to the new fee structure is hoped to happen next week.

We have made major strides in the initial database implementation (you'll recall from our last Missive that our first implementation will use LMDB), and it is very nearly ready for broader testing. Specifically: the new blockchain is working for most things, but there are bugs with certain aspects of block verification that need to be fixed before it can be more widely tested. If you are particularly intrepid you can already grab it here: https://github.com/tewinget/bitmonero/tree/blockchain and compile it, and thus assist in identifying areas where it breaks down, although such reports are probably best submitted as github issues to tewinget's repository to reduce duplication. Once these and any other major issues have been weeded out the next steps would involve a bit of refactoring, fix cross-platform nigglies, and open it up for general testing.

The testing of per-kb fees on testnet, too, has gone exceedingly well. We will be adding the functionality to simplewallet (previously it required manual creation) and hope to deploy that for general testing within the next week.

Kitware staff, Ben Boeckel in particular, have spent a lot of time completely reworking our CMake build system and bringing it up to best practices. The fruits of those efforts can be seen on the Pull Request currently undergoing testing: https://github.com/monero-project/bitmonero/pull/180 (feel free to checkout this PR if you'd like to test). Now that the build system is starting to come together in its final form, we are hoping to use it to tag and release 0.8.8.5 during the course of next week.

In order to more efficiently deal with changes in the on-disk wallet format we are moving away from the old serialised+encrypted .keys format, and have a new format which is effectively encrypted JSON. This change allows us to note the wordlist language in the wallet format (so that the "seed" command can reflect that choice) and allows for cross-platform compatibility of the .keys file, which we are sure is excellent news for anyone that moves wallets between operating systems and architectures. You can test this in PR 179.

There have been a constant string of improvements and changes to the forum software to make it more usable and useful. In particular, new comments in a thread are highlighted within that thread. Additionally, unread threads (or threads with new unread comments) are highlighted by having a green dot next to them. Both of these apply to logged in users only. If you haven't visited the forum, you are encouraged to do so: https://forum.monero.cc

Dev Diary

Core: LMDB implementation is rough but nearly working (details above). Worth testing cross-platform, least of all from a build perspective.

Core: since we have already had to perform the rather annoyingly complex task of offloading MoneroPulse checkpoint checks to a separate thread (so as not to tie anything up during checks) we have begun extending this to other parts of the core that could potentially be or currently are pain points. This does not include the flat-file blockchain saving, as that is going to be deprecated with the move to LMDB, so pools will just need to hang on and deal with that nuisance for a little bit longer.

Build: CMake is looking a lot cleaner and easier to grok. It also fixes cross-compile (see: http://www.cmake.org/Wiki/CMake_Cross_Compiling) which means that binaries for all our major supported platforms can be built on a single system.

Account: multilang wordlists are now inherent to the wallet/account, so that RPC and CLI calls that retrieve the mnemonic do so in the correct format. This has, in turn, necessitated moving away from the horrible serialised data format for account data. Since epee's JSON library is beyond redemption, we have opted to use RapidJSON instead (which is headers-only and thus straight in the source tree).