CryptoNote currencies announcements and official reviews

Re: Monero

Postby Febo » Mon Aug 18, 2014 10:14 pm

Monero Missives #10

August 10th, 2014

Hello, and welcome to our tenth Monero Missive!

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

1. 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.

2. 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

3. 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!

4. 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.

5. 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.

Dev Diary

Blockchain: tewinget is starting to bring the abstracted BlockchainDB functions together, as discussed in the Fireside Chat. You can continue to follow his work on his branch:

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:

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.

Until next week!

- updated by fluffypony
Posts: 23
Joined: Mon Aug 18, 2014 9:57 pm

Re: Monero

Postby Febo » Mon Aug 18, 2014 10:15 pm

Monero Missives #11

August 16th, 2014

Hello, and welcome to our eleventh Monero Missive!

Major Updates

1. 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!

2. 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:)

3. 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!

4. 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.

5. 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.

6. 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.

7. 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: 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.

Wallet: mikezackles is heavily refactoring the wallet code to be more legible, and more in line with our standards and expectations. This effort can be followed here: ... t_refactor

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.

Until next week!

- updated by fluffypony
Posts: 23
Joined: Mon Aug 18, 2014 9:57 pm

Re: Monero

Postby Febo » Tue Sep 16, 2014 1:38 pm

Monero Missives#12

September 15th, 2014

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

1. 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:

2. 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.

3. 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:* or take a peek at some of the new designs:


4. 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:, and the Bitcointalk thread dedicated to the project is here:

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

    [li]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).[/li]
    [li]FreeBSD Compatability: 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.[/li]
    [li]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:

    [li]Versioning: versioning is a lot easier, now, as tagged releases from onwards will show version-final (eg. as their version, and those built between tagged releases will show version-commithash (eg. We expect this will greatly aid in debugging problems, as we can immediately pinpoint the actual version / commit a user is on.[/li]
    [li]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.[/li]

6. 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:





7. Monero has been added to another exchange, Coin Swap. You can find the market here:

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.

Until next week!

[size=6pt]- updated by fluffypony[/size]
Posts: 23
Joined: Mon Aug 18, 2014 9:57 pm

Re: Monero

Postby Febo » Sat Nov 22, 2014 1:10 am

Febo wrote:Monero Monday Missives #13

October 6th, 2014

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

1. We are happy to announce the launch of the official Monero forum. You can find it at

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.

Posts and comments can contain MarkDown, including links, inline code blocks, multi-line code blocks, bold and italicised text, and inline images.

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. 2. 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.

3. 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.

4. 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:

5. 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:

"hashlines": [{
"hash": "7cb10e29d67e1c069e6e11b17d30b809724255fee2f6868dc14cfc6ed44dfb25",
"height": 22231
"hash": "bbd604d2ba11ba27935e006ed39c9bfdd99b76bf4a50654bc1e1e61217962698",
"height": 202612
Core: DNS checkpointing. This scans TXT records on the domains 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.

Until next week!
Posts: 23
Joined: Mon Aug 18, 2014 9:57 pm

Re: Monero

Postby Febo » Sat Nov 22, 2014 1:12 am

Febo wrote:Monero Monday Missives #14

October 13th, 2014

Hello, and welcome to our fourteenth Monero Monday Missive!

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)

Core: file and DNS checkpoints now also support blob hash (longhash) checkpointing (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)

Until next week!
Posts: 23
Joined: Mon Aug 18, 2014 9:57 pm

Re: Monero

Postby Febo » Sat Nov 22, 2014 1:13 am

Febo wrote:Monero Monday Missives #15

October 20th, 2014

Hello, and welcome to our fifteenth Monero Monday Missive!

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: (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 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.

Until next week!
Posts: 23
Joined: Mon Aug 18, 2014 9:57 pm

Re: Monero

Postby Febo » Sat Nov 22, 2014 1:15 am

Febo wrote:Monero Monday Missives #16

October 27th, 2014

Hello, and welcome to our sixteenth Monero Monday Missive!

Major Updates

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: 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: (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 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:

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: 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).

Until next week!
Posts: 23
Joined: Mon Aug 18, 2014 9:57 pm

Re: Monero

Postby Febo » Sat Nov 22, 2014 1:16 am

Febo wrote:Monero Monday Missives #17

November 2nd, 2014

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 - (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 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.

Until next week!
Posts: 23
Joined: Mon Aug 18, 2014 9:57 pm

Re: Monero

Postby Febo » Sat Nov 22, 2014 1:17 am

Febo wrote:Monero Monday Missives #18

November 17th, 2014

Hello, and welcome to our eighteenth Monero Monday Missive!

Major Updates

We still have ongoing Windows static build issues, which is preventing us from tagging and releasing Monero 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.

Dev Diary

Core: more CMake changes, although lingering issues exist with static mingw-w64 builds (both native and cross-compiling on Arch)

Core: several bug fixes to the multi-language mnemonic system, a more unified JSON library, and others, are in the wings and nearly ready to deploy, pending the CMake issues being resolved

Until next week!
Posts: 23
Joined: Mon Aug 18, 2014 9:57 pm

Re: Monero

Postby Febo » Wed Dec 03, 2014 6:12 pm

Febo wrote:Monero Monday Missives #19

November 24th, 2014

Hello, and welcome to our nineteenth Monero Monday Missive!

Major Updates

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.
My Monero

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: ... /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

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.

Until next week!
Posts: 23
Joined: Mon Aug 18, 2014 9:57 pm


Return to Announcements

Who is online

Users browsing this forum: No registered users and 1 guest