Monero Monday Missives

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

• 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: https://github.com/monero-project/mininero

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

Until next week!