Added new site

2024-12-04 15:41:11 +02:00 · 2017-07-04 00:00:32 -06:00 · 2017-07-04 00:00:32 -06:00 · 4e41a6a0cf
commit 4e41a6a0cf
parent 3c3d0698c9
411 changed files with 34903 additions and 0 deletions
--- a/.gitignore
+++ b/.gitignore
@ -0,0 +1,3 @@
+ietemplates/
+_site/*
+.idea/
--- a/404/css/ie7.css
+++ b/404/css/ie7.css
@ -0,0 +1,25 @@
+@charset "utf-8";
+div.not-found-text{
+	top:65px;	
+}
+
+div.planet{
+	z-index:-1;	
+}
+
+div.dog{
+	z-index:1000;	
+}
+
+div.dog-bubble{
+	filter: alpha(opacity=0); /* IE6+ */
+    filter: progid:DXImageTransform.Microsoft.Alpha(opacity=0); /* IE6+ */
+	-ms-filter: "progid:DXImageTransform.Microsoft.Alpha(opacity=0)";
+	padding-top:35px;	
+}
+
+#dog-changer ul li a{
+	filter: alpha(opacity=30); /* IE6+ */
+    filter: progid:DXImageTransform.Microsoft.Alpha(opacity=30); /* IE6+ */
+	-ms-filter: "progid:DXImageTransform.Microsoft.Alpha(opacity=30)";
+}
--- a/404/css/main.css
+++ b/404/css/main.css
@ -0,0 +1,313 @@
+@charset "utf-8";
+
+/* === General stuff === */
+
+html, body{
+	height:100%;
+	background:#186aa9 url(/404/images/sky-background.png) top repeat-x;	
+	overflow:hidden;
+	padding:0;
+	margin:0;
+	font-family:Arial, Helvetica, sans-serif;
+	margin-top: 5px;
+}
+
+.footer{
+	display: none;
+}
+
+a{
+	color:#3680b1;	
+}
+
+img, a img{
+	border:0px none;	
+	outline:none;
+}
+
+/* === Main Section === */
+
+#wrapper{	
+	width:980px;
+	margin:0px auto;
+	position:relative;
+	height:100%;
+	background:url(/404/images/sky-shine.jpg) top left no-repeat;
+}
+
+div.top-left{
+	position:absolute;
+	right:0px;
+}
+
+div.not-found-text{
+	position:absolute;
+	top:35px;
+	right:0px;
+	width:430px;
+}
+
+h1.not-found-text{
+	font-size:50px;
+	color:#fff;
+	letter-spacing:2px;
+	margin-bottom:20px;
+}
+
+div.graphic{
+	position:absolute;
+	top:80px;
+	left:0px;
+}
+
+div.planet{
+	position:absolute;
+	bottom:-720px;
+	margin:0px auto;
+	z-index:0;
+}
+
+div.planet>img{
+	width:960px;
+}
+
+div.dog-wrapper{
+	position:absolute;
+	top:45px;
+	left:440px;
+}
+
+div.dog{
+	position:absolute;
+	bottom:0px;
+	left:0px;
+	width:80px;
+	height:80px;
+	z-index:999;
+	background:url(/404/images/dog1.png) 0px 0px no-repeat;
+}
+
+div.dog-bubble{
+	font-size:18px;
+	line-height:1.5;
+	font-style:italic;
+	height:179px;
+	width:246px;
+	background:url(/404/images/bubble.png) top center no-repeat;
+	padding:20px 0px;
+	position:absolute;
+	bottom:0px;
+	left:30px;
+	z-index:999;
+	opacity:0;
+	color:#555555;
+	text-shadow:1px 1px 0 #ffffff;
+}
+
+div.dog-bubble>p{
+	text-align:center;
+	padding:0px 35px;	
+}
+
+div.bubble-options{
+	opacity:0;
+	visibility:hidden;
+	display:none;
+}
+
+/* === Responsive === */
+
+/* #Small laptop screens
+================================================== */
+
+    @media only screen and (max-width: 960px) {
+    	#wrapper{
+    		width:600px;
+    		background-image:none;
+			margin-top: 50px;
+    	}
+
+        div.planet{
+			position:absolute;
+			bottom:-300px;
+			margin:0 auto 0 -280px;
+			z-index:0;
+			left:50%;
+			
+		}
+
+		div.planet>img{
+			width:560px;
+		}
+
+		div.dog-wrapper{
+			position:absolute;
+			top:30px;
+			left:250px;
+			
+		}
+
+		div.graphic{
+			position:absolute;
+			top:50px;
+			left:40px;
+			
+		}
+
+		div.top-left {
+		    position: absolute;
+		    right: 0px;
+		    top: -40px;
+		}
+
+		div.graphic>img{
+			width:60%;
+		}
+
+		div.graphic{
+			left: 0px;
+		    position: absolute;
+		    top: 20px;
+		}
+
+		div.not-found-text{
+			right:0px;
+			top:22px;
+			width:320px;
+		}
+
+		h1.not-found-text{
+			font-size:35px;
+		}
+
+    }
+
+
+/*  #Tablets and small screens
+================================================== */
+
+    @media only screen and (max-width: 767px) {
+        
+    	#wrapper{
+    		width:400px;
+    		background-image:none;
+    	}
+
+    	div.graphic>img{
+			width:40%;
+		}
+
+        div.planet{
+			position:absolute;
+			bottom:-170px;
+			margin:0 auto 0 -180px;
+			z-index:0;
+			left:50%;
+			
+		}
+
+		div.planet>img{
+			width:360px;
+		}
+
+		div.dog-wrapper{
+			position:absolute;
+			top:30px;
+			left:150px;
+			
+		}
+
+		div.graphic{
+			position:absolute;
+			top:20px;
+			left:0px;
+			
+		}
+
+		div.top-left {
+		    position: absolute;
+		    right: 390px;
+		    top: 170px;
+		}
+
+		h1.not-found-text {
+		    font-size: 26px;
+		}
+
+		div.not-found-text {
+		    right: -60px;
+		    top: 33px;
+		    width: 270px;
+		}
+
+		div.top-left {
+		    position: absolute;
+		    right: 0;
+		    top: -38px;
+		}
+
+    }
+
+
+/* #Mobile phones
+================================================== */
+
+    @media only screen and (max-width: 479px){
+        
+    	#wrapper{
+    		width:320px;
+    		background-image:none;
+    	}
+
+		h1.not-found-text {
+		    font-size: 20px;
+		    text-align: center;
+		}
+
+		div.not-found-text {
+		    right: 20px;
+		    top: 210px;
+		}
+
+    	div.graphic>img{
+			width:100%;
+		}
+		
+
+        div.planet{
+			position:absolute;
+			bottom:-70px;
+			margin:0 auto 0 -100px;
+			z-index:0;
+			left:50%;
+			
+		}
+
+		div.planet>img{
+			width:200px;
+		}
+
+		div.dog-wrapper {
+		    left: 70px;
+		    position: absolute;
+		    top: 26px;
+		}
+
+		div.dog-bubble{
+			font-size:10px;
+			line-height:1.5;
+			font-style:italic;
+			height:107px;
+			width:147px;
+			background:url(/404/images/bubble.png) top center no-repeat;
+			background-size: contain;
+			padding:10px 0px;
+			position:absolute;
+			bottom:0px;
+			left:55px;
+			z-index:999;
+			opacity:0;
+			color:#555555;
+			text-shadow:1px 1px 0 #ffffff;
+		}
+    }
--- a/404/images/404.png
+++ b/404/images/404.png
--- a/404/images/bubble.png
+++ b/404/images/bubble.png
--- a/404/images/cat.png
+++ b/404/images/cat.png
--- a/404/images/cookie.png
+++ b/404/images/cookie.png
--- a/404/images/dog1.png
+++ b/404/images/dog1.png
--- a/404/images/planet.png
+++ b/404/images/planet.png
--- a/404/images/sky-background.png
+++ b/404/images/sky-background.png
--- a/404/images/sky-shine.jpg
+++ b/404/images/sky-shine.jpg
--- a/404/index.md
+++ b/404/index.md
@ -0,0 +1,39 @@
+---
+layout: error
+title: "Error 404, Page Not Found"
+---
+
+<link rel="stylesheet" href="/404/css/main.css" type="text/css" media="screen, projection" />
+<!--[if lt IE 8]>
+	<link rel="stylesheet" type="text/css" href="/404/css/ie7.css" />
+<![endif]-->
+
+<div id="wrapper">
+	<div class="graphic">
+		<img src="/404/images/404.png" alt="404" />
+	</div>
+
+	<div class="top-left">
+			<div class="not-found-text">
+				<h1 class="not-found-text">Oh no, we couldn't find anything for that link!</h1>
+			</div>
+	</div>
+
+	<div class="planet">
+		<div class="dog-wrapper">
+			<div class="dog"></div>
+			<div class="dog-bubble"></div>
+
+			<div class="bubble-options">
+				{% for data_talk in site.data.dogtalk %}
+				<p class="dog-bubble">
+					{{ data_talk.bubble }}
+				</p>
+				{% endfor %}
+			</div>
+		</div>
+
+		<img src="/404/images/planet.png" alt="planet" />
+	</div>
+
+</div>
--- a/README.md
+++ b/README.md
@ -0,0 +1,56 @@
+# Monero
+
+Copyright (c) 2014-2017, The Monero Project
+
+## Development Resources
+
+Web: [getmonero.org](http://getmonero.org)
+Mail: [dev@getmonero.org](mailto:dev@getmonero.org)
+IRC: [#monero-dev on Freenode](irc://chat.freenode.net/#monero-dev)
+
+## About this Project
+
+This is the Monero website. Instead of using MediaWiki or similar, we are using Jekyll and hosting the source on github. All site content is in the easy-to-use Markdown format (Kramdown, specifically), so contributors don't need to have any knowledge of HTML or anything else.
+
+## Pages, Formats, and Rules
+
+If you would like to suggest changes you can do so by forking the repository, making changes directly on your fork, and then submitting them as pull requests. If you need help doing so feel free to ask for assistance in #monero-dev on Freenode.
+
+Pages and formats should be based off existing pages to maintain a consistent look-and-feel. The following notes apply to various parts of the site:
+
+- changes made to _layouts, _includes, and home.php will need to use {% t x.x %} translation tags to pull in the YAML tag from _strings_en.yml, as this is required for multi-language support later on
+- with the exception of something like blog/index.html (that is required to be a .html file for Jekyll's pagination to work) all pages should be .md files
+- static content (CSS/JS/images) can be found in the [monero-forum](https://github.com/monero-project/monero-forum) repo
+- SVG should be used in header icons and diagrams, and FontAwesome icons can be used in text
+- Moneropedia entries require nothing more than creating the .md file in knowledge-base/moneropedia/, please use the 00-base-00 file as a boilerplate
+- To create a CLI screen shot, prefix the text block with {:.cli-code}, and use span elements for the colours; see getting-started/running.md, getting-started/accepting.md, and the account.md Moneropedia entry
+
+## Deployment
+
+Deploying this website requires Jekyll (3.0+) and the following ruby gems: builder, rubysl-rexml, jekyll-paginate
+
+Multiple language support will be added soon.
+
+To test changes locally before pushing to git, make sure you have ruby installed on your system, then:
+
+1. Make sure you have the necessary ruby gems: `gem install builder rubysl-rexml jekyll-paginate jekyll`
+2. Navigate to the your local `monero-site` repository.
+3. Serve the website: `jekyll serve`
+4. Open a browser and go to [http://127.0.0.1:4000](http://127.0.0.1:4000).
+5. A basic page list will appear. Click on the part of the site you are working on (ex: `design_goals`) and see your work!
+
+## License
+
+Copyright (c) 2014-2017, The Monero Project
+
+All rights reserved.
+
+Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
+
+1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
+
+2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
+
+3. Neither the name of the copyright holder nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
--- a/_config.yml
+++ b/_config.yml
@ -0,0 +1,38 @@
+email: dev@getmonero.org
+name: Monero
+description: Monero is a digital currency that is secure, private, and untraceable.
+keywords: "monero, xmr, bitmonero, cryptocurrency"
+baseurl: ""
+url: "https://getmonero.org"
+
+markdown: kramdown
+
+# Kramdown was using smart quotes, which messes up CLI examples
+# TODO: smart quotes are actually quite pretty, so this is perhaps better handled via a plugin that reverts them for CLI blocks
+kramdown:
+    smart_quotes: ["apos", "apos", "quot", "quot"]
+    input: GFM
+
+exclude: ["README.md"]
+gems: [jekyll-paginate]
+paginate: 10
+paginate_path: blog/page:num/
+
+# Windows live tiles config
+ie_tile_color: eeeeee
+ie_tile_small: https://static.getmonero.org/images/live-tiles/small.png
+ie_tile_medium: https://static.getmonero.org/images/live-tiles/medium.png
+ie_tile_wide: https://static.getmonero.org/images/live-tiles/wide.png
+ie_tile_large: https://static.getmonero.org/images/live-tiles/large.png
+
+# Sitemap
+sitemap:
+    exclude:
+        - "/ietemplates/ieconfig.xml"
+        - "/ietemplates/poll1.xml"
+        - "/ietemplates/poll2.xml"
+        - "/ietemplates/poll3.xml"
+        - "/ietemplates/poll4.xml"
+        - "/ietemplates/poll5.xml"
+        - "/feed.xml"
+        - "/404/index.md"
--- a/_config/nginx.conf
+++ b/_config/nginx.conf
@ -0,0 +1,243 @@
+# This is included as an example of a config file that works for the site. This is important so that anyone can re-host it in the event of something going wrong with the main site.
+# The main takeaways from this config file are the redirects, everything is relatively bog standard.
+
+server {
+    listen       80;
+    listen       443 ssl http2;
+
+    ssl_certificate      /etc/ssl/certs/ssl-cert-snakeoil.pem;
+    ssl_certificate_key  /etc/ssl/private/ssl-cert-snakeoil.key;
+
+    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
+    ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4";
+    ssl_prefer_server_ciphers   on;
+
+    # Specify this vhost's domain name
+    server_name updates.getmonero.org downloads.getmonero.org downloads.monero.cc;
+    root /var/www/downloads.getmonero.org/webroot;
+    index index.php index.html index.htm;
+
+    # Specify log locations for current site
+    access_log off;
+    error_log /var/log/nginx/default-site.log warn;
+
+    # Let's not give away too much info:
+    error_page 403 = 404;
+
+    # These are the restrictions I generally have on
+    # Disable logging for favicon
+    location = /favicon.ico {
+        log_not_found off;
+        access_log off;
+    }
+
+    # Disable logging for robots.txt
+    location = /robots.txt {
+        allow all;
+        log_not_found off;
+        access_log off;
+    }
+
+    location ~* \.(ico|css|js|gif|jpe?g|png)$
+    {
+        expires 31536000s;
+        access_log off;
+        log_not_found off;
+        add_header Pragma public;
+        add_header Cache-Control "max-age=31536000, public";
+    }
+
+    # Deny all attempts to access hidden files such as .htaccess, .htpasswd, .DS_Store (Mac).
+    location ~ /\. {
+        deny all;
+        access_log off;
+        log_not_found off;
+    }
+    # End of general restrictions
+
+    # Downloads!
+    location /win64 {
+        rewrite ^ /cli/monero-win-x64-v0.10.3.1.zip redirect;
+    }
+
+    location /win32 {
+        rewrite ^ /cli/monero-win-x86-v0.10.3.1.zip redirect;
+    }
+
+    location /mac64 {
+        rewrite ^ /cli/monero-mac-x64-v0.10.3.1.tar.bz2 redirect;
+    }
+
+    location /linux64 {
+        rewrite ^ /cli/monero-linux-x64-v0.10.3.1.tar.bz2 redirect;
+    }
+
+    location /linux32 {
+        rewrite ^ /cli/monero-linux-x86-v0.10.3.1.tar.bz2 redirect;
+    }
+
+    location /linuxarm7 {
+        rewrite ^ /cli/monero-linux-armv7-v0.10.3.1.tar.bz2 redirect;
+    }
+
+    location /linuxarm8 {
+        rewrite ^ /cli/monero-linux-armv8-v0.10.3.1.tar.bz2 redirect;
+    }
+
+    location /freebsd64 {
+        rewrite ^ /cli/monero-freebsd-x64-v0.10.3.1.tar.bz2 redirect;
+    }
+
+    location /dragonflybsd64 {
+        rewrite ^ /cli/monero-dragonflybsd-x64-v0.10.3.1.tar.bz2 redirect;
+    }
+    
+    # GUI downloads
+    location /gui/win64 {
+        rewrite ^ /gui/monero-win-x64-v0.10.3.1.zip redirect;
+    }
+
+    location /gui/mac64 {
+        rewrite ^ /gui/monero-mac-x64-v0.10.3.1.tar.bz2 redirect;
+    }
+
+    location /gui/linux64 {
+        rewrite ^ /gui/monero-linux-x64-v0.10.3.1.tar.bz2 redirect;
+    }
+
+    location /gui/linux32 {
+        rewrite ^ /gui/monero-linux-x86-v0.10.3.1.tar.bz2 redirect;
+    }
+
+    # Other download redirects
+    location /cli/win64 {
+        rewrite ^ /win64 permanent;
+    }
+
+    location /cli/win32 {
+        rewrite ^ /win32 permanent;
+    }
+
+    location /cli/mac64 {
+        rewrite ^ /mac64 permanent;
+    }
+
+    location /cli/linux64 {
+        rewrite ^ /linux64 permanent;
+    }
+
+    location /cli/linux32 {
+        rewrite ^ /linux32 permanent;
+    }
+
+    location /cli/linuxarm7 {
+        rewrite ^ /linuxarm7 permanent;
+    }
+
+    location /cli/linuxarm8 {
+        rewrite ^ /linuxarm8 permanent;
+    }
+
+    location /cli/freebsd64 {
+        rewrite ^ /freebsd64 permanent;
+    }
+
+    location /cli/dragonflybsd64 {
+        rewrite ^ /dragonflybsd64 permanent;
+    }
+
+    location /win {
+        rewrite ^ /win64 permanent;
+    }
+
+    location /mac {
+        rewrite ^ /mac64 permanent;
+    }
+
+    location /linux {
+        rewrite ^ /linux64 permanent;
+    }
+
+    location /freebsd {
+        rewrite ^ /freebsd64 permanent;
+    }
+
+    location /dragonflybsd {
+        rewrite ^ /dragonflybsd64 permanent;
+    }
+
+    location /arm {
+        rewrite ^ /linuxarm7 permanent;
+    }
+
+    location /arm64 {
+        rewrite ^ /linuxarm8 permanent;
+    }
+
+    location /arm7 {
+        rewrite ^ /linuxarm7 permanent;
+    }
+
+    location /arm8 {
+        rewrite ^ /linuxarm8 permanent;
+    }
+
+    location /monero.win.x64.latest.zip {
+        rewrite ^ /win64 permanent;
+    }
+
+    location /monero.win.x32.latest.zip {
+        rewrite ^ /win32 permanent;
+    }
+
+    location /monero.mac.x64.latest.tar.bz2 {
+        rewrite ^ /mac64 permanent;
+    }
+
+    location /monero.linux.x64.latest.tar.bz2 {
+        rewrite ^ /linux64 permanent;
+    }
+
+    location /monero.linux.x86.latest.tar.bz2 {
+        rewrite ^ /linux86 permanent;
+    }
+
+    location /monero.linux.arm7.latest.tar.bz2 {
+        rewrite ^ /linuxarm7 permanent;
+    }
+
+    location /monero.linux.arm8.latest.tar.bz2 {
+        rewrite ^ /linuxarm8 permanent;
+    }
+
+    location /monero.freebsd.x64.latest.tar.bz2 {
+        rewrite ^ /freebsd64 permanent;
+    }
+
+    location /monero.dragonflybsd.x64.latest.tar.bz2 {
+        rewrite ^ /dragonflybsd64 permanent;
+    }
+
+    location / {
+        try_files $uri $uri/ $uri.php $uri.htm $uri.html =404;
+        index index.html index.htm index.php;
+    }
+
+    # Block for processing PHP files
+    # Specifically matches URIs ending in .php
+    location ~ \.php$ {
+        try_files $uri =404;
+
+        # Fix for server variables that behave differently under nginx/php-fpm than typically expected
+        fastcgi_split_path_info ^(.+\.php)(/.+)$;
+        # Include the standard fastcgi_params file included with nginx
+        include fastcgi_params;
+        fastcgi_param  PATH_INFO        $fastcgi_path_info;
+        fastcgi_index index.php;
+        # Override the SCRIPT_FILENAME variable set by fastcgi_params
+        fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
+        # Pass to upstream PHP-FPM; This must match whatever you name your upstream connection
+        fastcgi_pass phpfpm;
+    }
+
+}
--- a/_data/dogtalk.yml
+++ b/_data/dogtalk.yml
@ -0,0 +1,10 @@
+- bubble: "The page went missing? The entire page? Oh noooo!"
+- bubble: "<br />Barooooooooooo!"
+- bubble: "<br />I'm the best tracker out there, I'll find it!"
+- bubble: "My kingdom for a dog biscuit!<br /><img style='margin-top:8px' src='/404/images/cookie.png' alt='cookie' />"
+- bubble: "<br />I'm sure the page is just around the corner..."
+- bubble: "Does anyone smell something cooking? Nom nom nom."
+- bubble: "Am I just going in circles?<br />IS IT TRUE??"
+- bubble: "<br />Have you tried to Google for it?"
+- bubble: "I keep day-dreaming...<br /><img style='margin-top:8px' src='/404/images/cat.png' alt='cat' />"
+- bubble: "<br />Uh oh...I forgot what I'm looking for!"
--- a/_data/donators.yml
+++ b/_data/donators.yml
@ -0,0 +1,428 @@
+- level: 10
+  name: ArticMine
+  amount: 20024.6
+  quote: Everyone has the right to freedom of opinion and expression; this right includes freedom to hold opinions without interference and to seek, receive and impart information and ideas through any media and regardless of frontiers.
+  quote-author: Article 19, The Universal Declaration of Human Rights
+  history: [10th Dan on 2015-11-11, 9th Dan on 2015-11-11, 8th Dan on 2015-01-14, 7th Dan on 2014-12-02, 6th Dan on 2014-08-24, 5th Dan on 2014-08-01, 4th Dan on 2014-07-21]
+
+- level: 9
+  name: pa
+  amount: 12500
+  history: [8th Dan on 2016-01-01, 9th Dan on 2016-01-01, 7th Dan on 2015-02-25, 6th Dan on 2014-12-30, 5th Dan on 2014-09-18]
+
+- level: 9
+  name: ajiekceu4
+  amount: 11666
+  history: [9th Dan on 2016-02-03, 8th Dan on 2015-11-4, 7th Dan on 2015-08-31, 6th Dan on 2015-05-11]
+  
+- level: 8
+  name: Lloydimiller4
+  amount: 7800
+  history: [8th Dan on 2015-09-28, 7th Dan on 2015-02-25, 6th Dan on 2015-02-16, 5th Dan on 2014-09-20, 4th Dan on 2014-08-26]
+
+- level: 8
+  name: rpietila
+  amount: 8100
+  quote: We hold these truths to be self-evident, that all men are created equal, that they are endowed by their Creator with certain unalienable Rights, that among these are Life, Liberty and the pursuit of Happiness.--That to secure these rights, Governments are instituted among Men, deriving their just powers from the consent of the governed, --That whenever any Form of Government becomes destructive of these ends, it is the Right of the People to alter or to abolish it, and to institute new Government---it is their right, it is their duty, to throw off such Government.
+  quote-author: Declaration of Independence
+  history: [8th Dan on 2015-02-23, 7th Dan on 2014-09-04, 6th Dan on 2014-08-23, 5th Dan on 2014-08-01, 4th Dan on 2014-07-16]
+
+- level: 7
+  name: antw081
+  amount: 3100
+  history: [7th Dan on 2015-07-16, 6th Dan on 2015-02-23, 5th Dan on 2015-02-10, 4th Dan on 2014-11-25, 3rd Dan on 2014-09-05]
+  
+- level: 7
+  name: antw081
+  amount: 3100
+  history: [7th Dan on 2015-07-16, 6th Dan on 2015-02-23, 5th Dan on 2015-02-10, 4th Dan on 2014-11-25, 3rd Dan on 2014-09-05]
+  
+- level: 7
+  name: ajiekceu4
+  amount: 7666
+  history: [8th Dan on 2015-11-4, 7th Dan on 2015-08-31, 6th Dan on 2015-05-11]
+  
+- level: 7
+  name: antw081
+  amount: 3100
+  history: [7th Dan on 2015-07-16, 6th Dan on 2015-02-23, 5th Dan on 2015-02-10, 4th Dan on 2014-11-25, 3rd Dan on 2014-09-05]
+  
+- level: 7
+  name: smooth
+  amount: 2500
+  quote: No State shall...coin Money; emit Bills of Credit; make any Thing but gold and silver Coin a Tender in Payment of Debts...
+  quote-author: Section 10
+  history: [7th Dan on 2014-08-13, 6th Dan on 2014-04-29]
+
+- level: 6
+  name: HardwarePal
+  amount: 1000
+  quote: The right of the people to be secure in their persons, houses, papers, and effects, against unreasonable searches and seizures, shall not be violated, and no Warrants shall issue, but upon probable cause, supported by Oath or affirmation, and particularly describing the place to be searched, and the persons or things to be seized.
+  quote-author: IV Amendment
+  history: [6th Dan on 2014-07-17, 5th Dan on 2014-06-30]
+
+- level: 6
+  name: buybitcoinscanada
+  amount: 1013
+  history: [6th Dan on 2014-09-05, 4th Dan on 2014-08-13]
+
+- level: 6
+  name: Medusa13
+  amount: 1980.6
+  history: [6th Dan on 2015-01-27, 4th Dan on 2014-11-08, 3rd Dan on 2014-08-26]
+
+- level: 5
+  name: bassica
+  amount: 849.9
+  history: [5th Dan on 2015-07-17, 4th Dan on 2015-05-11, 3rd Dan on 2014-11-25, 2nd Dan on 2014-09-10]
+  
+- level: 5
+  name: eizh
+  amount: 500
+  history: [5th Dan on 2014-08-09]
+
+- level: 5
+  name: TheKoziTwo
+  amount: 500
+  history: [5th Dan on 2014-09-04]
+
+- level: 5
+  name: ceger
+  amount: 550
+  history: [5th Dan on 2014-09-20]
+
+- level: 5
+  name: binaryFate
+  amount: 500
+  history: [5th Dan on 2015-01-07, 4th Dan on 2014-07-31]
+
+- level: 5
+  name: shitaifan2013/drfred
+  amount: 500
+  history: [5th Dan on 2015-02-04, 4th Dan on 2014-08-18, 3rd Dan on 2014-07-17]
+
+- level: 6
+  name: dnaleor
+  amount: 1201.1337
+  history: [6th Dan 0n 2016-02-03, 5th Dan on 2015-02-23, 4th Dan on 2014-12-17, 3rd Dan on 2014-07-17, 1st Dan on 2014-05-03]
+  quote: Crypto may offer 'key blinding'. I did some research and it was obscure, but there may be something there. 'Group signatures' may be related. ñ Satoshi Nakamoto, 2010
+
+- level: 5
+  name: ajiekceu4
+  amount: 666
+  history: [5th Dan on 2015-2-25]
+
+- level: 5
+  name: saddambitcoin
+  amount: 1400
+  history: [6th Dan on 2016-02-06, 5th Dan on 2015-02-28, 4th Dan on 2014-08-18]
+
+- level: 5
+  name: Quicken
+  amount: 500
+  history: [5th Dan on 2015-03-27]
+
+- level: 5
+  name: G2M (aka "kbm")
+  amount: 500
+  history: [5th Dan on 2015-06-03, 4th Dan on 2014-05-06]
+
+- level: 4
+  name: bobabouey2
+  amount: 250
+  history: [4th Dan on 2014 -07-21]
+
+- level: 4
+  name: fluffypony
+  amount: 245
+  history: [4th Dan on 2014-08-01]
+
+- level: 4
+  name: exciter0
+  amount: 300
+  history: [4th Dan on 2014-10-14, 3rd Dan on 2014-08-20]
+
+- level: 4
+  name: Jungian
+  amount: 201
+  history: [4th Dan on 2014-12-17, 3rd Dan on 2014-09-18]
+
+- level: 4
+  name: jehst
+  amount: 200
+  history: [4th Dan on 2015-01-07]
+
+- level: 4
+  name: GreekBitcoin
+  amount: 300
+  history: [4th Dan on 2015-01-26, 3rd Dan on 2014-05-11]
+
+- level: 4
+  name: RaskaRuby
+  amount: 450
+  history: [4th Dan 2015-01-01, 3rd Dan on 2014-10-27, 2nd Dan on 2014-09-18, 1st Dan on 2014-07-27]
+
+- level: 4
+  name: djjacket
+  amount: 200
+  history: [4th Dan on 2015-03-27]
+
+- level: 4
+  name: iourzzz
+  amount: 311
+  history: [4th Dan on 2015-04-08, 3rd Dan on 2015-03-15, 2nd Dan on 2014-09-14, 1st Dan on 2014-08-01]
+
+- level: 4
+  name: nioc
+  amount: 215
+  history: [4th Dan on 2015-11-11, 3rd Dan on 2015-04-18, 2nd Dan on 2015-01-27, 1st Dan on 2014-09-17]
+
+- level: 4
+  name: canth
+  amount: 300
+  history: [4rth Dan on 2105-11-12, 3rd Dan on 2015-05-17]  
+    
+- level: 4
+  name: iCEBREAKER
+  amount: 256
+  history: [3rd Dan on 2015-11-21]
+  
+- level: 3
+  name: Quanttek
+  amount: 100
+  history: [3rd Dan on 2014-07-15]
+
+- level: 3
+  name: darlidada
+  amount: 125.55
+  history: [3rd Dan on 2014-09-04, 2nd Dan on 2014-07-17, 1st Dan on 2014-06-11]
+
+- level: 3
+  name: blaaaaacksuit
+  amount: 100
+  history: [3rd Dan on 2014-08-09]
+
+- level: 3
+  name: AKWAnalytics
+  amount: 111
+  history: [3rd Dan on 2014-09-20]
+
+- level: 3
+  name: Monero House ([CryptoKingdom](https://bitcointalk.org/index.php?topic=819073.msg9156194#msg9156194))
+  amount: 150
+  history: [3rd Dan on 2014-11-06]
+
+- level: 3
+  name: Shrikez
+  amount: 150
+  history: [3rd Dan on 2015-01-27, 2nd Dan on 2014-09-18, 1st Dan on 2014-07-11]
+
+- level: 3
+  name: explorer
+  amount: 104
+  history: [3rd Dan on 2015-02-05]
+
+- level: 3
+  name: Karl Hungus
+  amount: 180
+  history: [3rd Dan on 2016-01-01]
+
+- level: 3
+  name: palexander
+  amount: 150
+  history: [3rd Dan on 2015-05-13, 2nd Dan on 2015-04-03]
+
+- level: 2
+  name: Warptangent Memorial Fund 
+  amount: 64
+  history: [2nd Dan on 2016-07-19]
+
+- level: 2
+  name: superresistant
+  amount: 50
+  history: [2nd Dan on 2014-07-17]
+
+- level: 2
+  name: perl
+  amount: 50
+  history: [2nd Dan on 2014-07-17]
+
+- level: 2
+  name: dbasql
+  amount: 50
+  history: [2nd Dan on 2014-07-17]
+
+- level: 2
+  name: paratox
+  amount: 50
+  history: [2nd Dan on 2014-08-09]
+
+- level: 2
+  name: Arux
+  amount: 70.1
+  history: [2nd Dan on 2015-01-31, 1st Dan on 2014-07-29]
+
+- level: 2
+  name: papa_lazzarou
+  amount: 50.1
+  history: [2nd Dan on 2015-02-23]
+
+- level: 2
+  name: GingerAle
+  amount: 50
+  history: [2nd Dan on 2015-04-22]
+
+- level: 2
+  name: ibuyltc
+  amount: 50
+  history: [2nd Dan on 2015-05-11, 1st Dan on 2014-08-20]
+
+- level: 2
+  name: equipoise
+  amount: 53
+  history: [2nd Dan on 2015-12-11, 1st Dan on 2015-01-24, 1st Kyu on 2014-07-24]
+  
+- level: 1
+  name: anonimal
+  amount: 45.6
+  history: [1st Dan on 2016-12-06]
+
+- level: 1
+  name: David Latapie
+  amount: 20
+  history: [1st Dan on 2014-04-29]
+
+- level: 1
+  name: hodlmybtc
+  amount: 20
+  history: [1st Dan on 2014-07-01]
+
+- level: 1
+  name: monoman
+  amount: 20
+  history: [1st Dan on 2014-07-11]
+
+- level: 1
+  name: Jshank
+  amount: 20
+  history: [1st Dan on 2014-07-16]
+
+- level: 1
+  name: dreamspark
+  amount: 20
+  history: [1st Dan on 2014-07-17]
+
+- level: 1
+  name: IntroVert
+  amount: 20
+  history: [1st Dan on 2014-07-17]
+
+- level: 1
+  name: dawie
+  amount: 20
+  history: [1st Dan on 2014-07-17]
+
+- level: 1
+  name: cAPSLOCK
+  amount: 20
+  history: [1st Dan on 2014-07-17]
+
+- level: 1
+  name: statdude
+  amount: 48.265
+  history: [1st Dan on 2014-07-17]
+
+- level: 1
+  name: Roy Badami
+  amount: 20
+  history: [1st Dan on 2014-07-18]
+
+- level: 1
+  name: whap
+  amount: 20.44
+  history: [1st Dan on 2014-09-17]
+
+- level: 1
+  name: SunnyIgor
+  amount: 26
+  history: [1st Dan on 2014-09-18]
+
+- level: 1
+  name: Chicken76
+  amount: 20
+  history: [1st Dan on 2014-10-10]
+
+- level: 1
+  name: dEBRUYNE
+  amount: 33.5
+  history: [1st Dan on 2015-01-14]
+
+- level: 1
+  name: 5w00p
+  amount: 20.05
+  history: [1st Dan on 2015-01-18, 1st Kyu on 2014-12-06, 2nd Kyu on 2014-09-21]
+
+- level: 1
+  name: matrix961
+  amount: 40.015
+  history: [1st Dan on 2015-02-09]
+
+- level: 1
+  name: kazuki49
+  amount: 20
+  history: [1st Dan on 2015-02-28, 1st Kyu on 2015-02-07]
+
+- level: -1
+  name: nakaone
+  amount: 10
+  history: [1st Kyu on 2014-07-15]
+
+- level: -1
+  name: carpetbagger
+  amount: 10
+  history: [1st Kyu on 2014-09-21]
+
+- level: -2
+  name: celestio
+  amount: 5
+  history: [2nd Kyu on 2014-07-16]
+
+- level: -2
+  name: znaky
+  amount: 5
+  history: [2nd Kyu on 2014-07-17]
+
+- level: -2
+  name: Nekomata
+  amount: 7
+  history: [2nd Kyu on 2014-09-20]
+
+- level: -2
+  name: thefunkybits
+  amount: 5
+  history: [2nd Kyu on 2015-02-23]
+
+- level: -3
+  name: jwinterm
+  amount: 2
+  history: [3rd Kyu on 2014-07-18]
+
+- level: -3
+  name: myagui
+  amount: 2
+  history: [3rd Kyu on 2014-07-17]
+
+- level: -3
+  name: yAmAdA
+  amount: 2
+  history: [3rd Kyu on 2014-08-11]
+
+- level: -4
+  name: Evan Duffield (care of iCEBREAKER)
+  amount: 1
+  history: [4th Kyu on 2014-11-20]
+  
+- level: -4
+  name: TheDashGuy (care of iCEBREAKER)
+  amount: 1
+  history: [4th Kyu on 2016-08-19]
--- a/_data/downloads.yml
+++ b/_data/downloads.yml
@ -0,0 +1,89 @@
+- platform: Windows, 64-bit
+  id: windows
+  icon: icon-windows
+  cli_url: win64
+  cli_hash: 2fbda6f6b1051053703e40cf77b6c6e11334509ad03a3c22d89b6bcb05615910
+  gui_url: win64
+  gui_hash: 0eddd423f5f0df236303d8b9225842142b331093eb69e6183f3f694238c371a7
+  version: 0.10.3.1
+  tag: Wolfram Warptangent
+  blockchain: win
+
+- platform: Windows, 32-bit
+  icon: icon-windows
+  cli_url: win32
+  cli_hash: da628a45adfcb8be44df06ac904711d644d608c4eb6479a5d256062a5f6d74de
+  version: 0.10.3.1
+  tag: Wolfram Warptangent
+  blockchain: win
+
+- platform: Mac OS X, 64-bit
+  id: mac
+  icon: icon-apple
+  cli_url: mac64
+  cli_hash: fd17d55a8c9e901ff4064c39d9e14786cdd077aff9b3bb556e60d3a5e322050c
+  gui_url: mac64
+  gui_hash: c80ca68037158216a080e59e90b0a70761cff2f317d3c9cd0eeb661e8e2a1f99
+  version: 0.10.3.1
+  tag: Wolfram Warptangent
+  blockchain: mac
+
+- platform: Linux, 64-bit
+  id: linux
+  icon: icon-linux
+  cli_url: linux64
+  cli_hash: 8db80f8cc4f80d4106db807432828df730a59eac78972ea81652aa6b9bac04ad
+  gui_url: linux64
+  gui_hash: 4915473265d58720fd8f019e536c2b7fb02648ab51a8087e84aa1e2434788452
+  version: 0.10.3.1
+  tag: Wolfram Warptangent
+  blockchain: linux
+
+- platform: Linux, 32-bit
+  icon: icon-linux
+  cli_url: linux32
+  cli_hash: abc99f3928f4083bd1a380a869253e07bee9950e0aeb6388e9493bc0f0ec3f53
+  gui_url: linux32
+  gui_hash: 092b49080c3380666845f7f39823b09f4960ea1e250b84b150856ef33ca30690
+  version: 0.10.3.1
+  tag: Wolfram Warptangent
+  blockchain: linux
+
+- platform: ARMv7
+  id: arm
+  icon: icon-arm
+  cli_url: linuxarm7
+  cli_hash: 8473fa20e0db4a3d3e46120cdf92c55be6a159478c511e21f7b77aa05d6c1910
+  version: 0.10.3.1
+  tag: Wolfram Warptangent
+  blockchain: arm
+
+- platform: ARMv8
+  icon: icon-arm
+  cli_url: linuxarm8
+  cli_hash: 451f65e4846b92d54859e22a5d92124557b397b4208d8752d5289d0262573c3c
+  version: 0.10.3.1
+  tag: Wolfram Warptangent
+  blockchain: arm
+
+- platform: FreeBSD, 64-bit
+  id: bsd
+  icon: icon-freebsd
+  cli_url: freebsd64
+  cli_hash: 4c66a76752e18ae70b5fb1c728f0d2780eb129a6c8c7d0dee7ba02e05d91efae
+  version: 0.10.3.1
+  tag: Wolfram Warptangent
+  blockchain: freebsd
+
+- platform: Source Code & Blockchain
+  id: source
+  icon: icon-github
+  cli_url: https://github.com/monero-project/bitmonero
+  cli_hash: source
+  version: Bleeding edge (possibly unstable)
+  
+- platform: Mobile & Light Wallets
+  id: mobilelight
+  
+- platform: Hardware Wallets
+  id: hardware
--- a/_data/events.yml
+++ b/_data/events.yml
@ -0,0 +1,5 @@
+- event: Monero Meetup (Dublin, Ireland) - June 26th, 2017
+  where: J.W. Sweetman Craft Brewery, 1-2 Burgh Quay, Dublin 2, Dublin, Ireland
+  when: 7:00 PM - Monday, June 26, 2017
+  description: The meeting will cover the history of privacy and fungibility in Bitcoin, discuss several approaches to these problems, and explain how Monero achieves its privacy in detail. Justin will discuss the next steps in development going forward and the limitations compared to other coins. Finally, there will be a Q&A session after the meeting, where he can clear up some final thoughts.
+  link: https://www.meetup.com/Bitcoin-Dublin/events/240152422/
--- a/_data/ffs.yml
+++ b/_data/ffs.yml
@ -0,0 +1,34 @@
+- stage: Ideas
+  proposals:
+    - name: Fake. Nothing here yet. Check WiP and Completed Proposals.
+      url: #
+      summary: This is for the best ideas ever!
+      author: rehrar
+      
+- stage: Open Tasks
+  proposals:
+    - name: Fake. Nothing here yet. Check WiP and Completed Proposals.
+      url: #
+      summary: This is for the best ideas ever!
+      author: rehrar
+      
+- stage: Funding Required
+  proposals:
+    - name: Monero Bounty For HackerOne
+      url: /forum-funding-system/proposals/monero-bounty-hackerone.html
+      summary: we need dedicated funds to satisfy bounty for Monero and all Monero sub-projects on hackerone.com/monero
+      author: anonimal
+      
+- stage: Work in Progress
+  proposals:
+    - name: Getmonero.org Redesign
+      url: /forum-funding-system/proposals/getmonero-redesign.html
+      summary: Redesign the official getmonero.org website to make it more accessible and aesthetically pleasing.
+      author: rehrar
+    
+- stage: Completed Proposals
+  proposals:
+    - name: What is Monero? is produced and open-sourced
+      url: /forum-funding-system/proposals/whatismonero-produced.html
+      summary: Make an introduction video to Monero.
+      author: savandra
--- a/_data/merchants.yml
+++ b/_data/merchants.yml
@ -0,0 +1,158 @@
+- category: Exchanges
+  merchants:
+    - name: "#monero-otc (OTC)"
+      url: https://webchat.freenode.net?channels=%23monero-otc
+    - name: Bitsquare (decentralized)
+      url: https://bitsquare.io/
+    - name: BitMEX
+      url: https://www.bitmex.com/app/trade/XMR7D 
+    - name: Bittrex
+      url: https://www.bittrex.com/Market/Index?MarketName=BTC-XMR
+    - name: Bter
+      url: https://bter.com/
+    - name: CoinCut (OTC)
+      url: https://www.coincut.com
+    - name: Cryptopia
+      url: https://www.cryptopia.co.nz/Exchange?market=XMR_BTC
+    - name: Livecoin (BTC and USD trading pairs)
+      url: https://www.livecoin.net
+    - name: LiteBit (Bankwire/GiroPay/iDeal/SOFORT)
+      url: https://www.litebit.eu/en/buy/monero
+    - name: MoneroDirect (Euro only)
+      url: https://monerodirect.com
+    - name: Poloniex
+      url: https://poloniex.com/exchange/btc_xmr
+    - name: ShapeShift (Instant)
+      url: https://shapeshift.io/
+    - name: Tux Exchange
+      url: https://www.tuxexchange.com/trade?coin=XMR&market=BTC
+    - name: Bitfinex (XMRUSD, XMRBTC)
+      url: https://www.bitfinex.com/
+    - name: Alfacashier
+      url: https://www.alfacashier.com/
+    - name: Kraken (XMRUSD, XMREUR, XMRBTC)
+      url: https://www.kraken.com/
+    - name: BIT.AC
+      url: https://bit.ac/
+    - name: Premium investment and exchange services
+      url: https://www.kaiserex.com/
+- category: Block Explorers
+  merchants:
+    - name: ChainRadar
+      url: http://chainradar.com/xmr/blocks
+    - name: MoneroBlocks
+      url: http://moneroblocks.info
+    - name: MoneroExplorer
+      url: https://explorer.xmr.my/
+    - name: MoneroHash Explorer
+      url: https://monerohash.com/explorer/
+    - name: xmrchain.net
+      url: https://xmrchain.net/
+- category: Payment Gateways
+  merchants:  
+    - name: Living Room of Satoshi
+      url: https://www.livingroomofsatoshi.com/?sc=xmr  
+    - name: Monero Merchants
+      url: https://monero-merchants.com
+    - name: Paybee (Private Beta)
+      url: https://payb.ee/
+- category: Libraries and Helpers
+  merchants:
+    - name: monero-nodejs (Node.js)
+      url: https://github.com/PsychicCat/monero-nodejs
+    - name: python-monero (Python)
+      url: https://github.com/tippero/python-monero
+    - name: MoneroPy (Python)
+      url: https://github.com/bigreddmachine/MoneroPy
+    - name: moneronjs (NodeJS)
+      url: https://github.com/netmonk/moneronjs
+    - name: MoneroApi.Net (.NET)
+      url: https://github.com/Jojatekok/MoneroApi.Net
+    - name: xmr-integration (PHP)
+      url: https://github.com/TheKoziTwo/xmr-integration
+    - name: PHP-Monero (PHP)
+      url: https://github.com/MalMen/PHP-Monero
+    - name: Monero-PHP (PHP)
+      url: https://github.com/PsychicCat/monero-php
+- category: Tools
+  merchants:
+    - name: nestorgames
+      url: http://www.nestorgames.com
+    - name: ForkGuard Network Monitoring
+      url: http://forkguard.com
+    - name: MoneroBase Price Charts and Tools
+      url: http://monerobase.com
+    - name: MoneroPric.es Price Converter
+      url: https://moneropric.es
+    - name: MoneroPrice.com Price Converter
+      url: http://moneroprice.com/
+    - name: Offline Monero address generator
+      url: https://moneroaddress.org/
+    - name: Monero Monitor for Chrome
+      url: https://chrome.google.com/webstore/detail/monero-monitor/ojekadcfnkkihlleaafggfgbggdckpgo
+- category: Services
+  merchants:
+    - name: Azur Samui - Luxury Apartment and Villa Development, Koh, Samui, Thailand
+      url: http://www.azursamui.com
+    - name: California Fintech Network
+      url: https://www.californiafintech.org/plans/
+    - name: Infield Loan Services - Atlanta, Construction Consulting, Contract review, Feasibility, Funds Escrow
+      url: mailto:info@loandraw.com
+    - name: Cryptostorm VPN
+      url: https://cryptostorm.is/
+    - name: Esperanto lessons from Kaja
+      url: mailto:kiah.morante@gmail.com
+    - name: Farmer ALP, LLC, Arizona
+      url: mailto:farmeralp@gmail.com
+    - name: Guitar Music Theory course w/ 30% XMR discount
+      url: http://www.guitartheoryrevolution.info/blog/guitar-theory-revolution-store/
+    - name: MyMonero Web-based Wallet
+      url: https://mymonero.com
+    - name: Pradeep Atluri, Psychiatrist, New York
+      url: http://dr.mindsci.com/
+    - name: Simple, no non-sense hosting
+      url: https://rootbox.host/
+    - name: Web Developer - Stefanos
+      url: http://www.stefanosioannou.com/web-development-monero-accepted
+    - name: XMR.to Monero to Bitcoin Payment Service
+      url: https://xmr.to
+    - name: algoStrategic - Internet Marketing and Web Development
+      url: https://algostrategic.com
+    - name: Emmanuel Galang, Canada Immigration and Refugee Lawyer
+      url: https://galanglaw.com/
+    - name: Web Developer - Python with Django web framework
+      url: http://www.voteforrodneylewis.com
+    - name: FlokiNET
+      url: https://flokinet.is
+    - name: Nerdzy Lawn Care
+      url: http://http://www.nerdzy.net
+- category: Goods
+  merchants:
+    - name: CryptoMercado - coffee and snacks
+      url: https://www.cryptomercado.com/
+    - name: Cryptonic Physical Monero & Bitcoin coins
+      url: https://cryptonic.net
+    - name: Fine Art from Jeanine King ~ Artwork of Home/Archtecture, Pets, Potraits, Caricatures ~ International Shipping
+      url: http://art2unlimited.webs.com/
+    - name: Digital gift cards
+      url: https://giftoff.com/
+    - name: Mushroom cultures, mushroom growing supplies, seeds
+      url: https://www.vesp.co/Fungible
+    - name: Handcrafted goods
+      url: https://mychain.store/
+    - name: Cellphone and laptop repair online store in Sweden
+      url: http://www.LagaiPhone.se
+    - name: InvestmentArt
+      url: http://investmentart.org/
+    - name: Directvoltage
+      url: http://directvoltage.com
+- category: Entertainment
+  merchants:
+    - name: Crypto Kingdom
+      url: http://cryptokingdom.me
+    - name: MoneroDice
+      url: https://monerodice.net
+    - name: SafeDice
+      url: https://safedice.com
+    - name: Crypto Games
+      url: https://www.crypto-games.net/
--- a/_data/roadmap.yml
+++ b/_data/roadmap.yml
@ -0,0 +1,79 @@
+- year: 2014
+  accomplishments:
+    - name: Launched on Bitcointalk
+      date: April 18, 2014
+      status: completed
+    - name: Renamed from Bitmonero to Monero
+      date: April 23, 2014
+      status: completed
+    - name: Recovered from a spam attack
+      date: September 4, 2014
+      status: completed
+    - name: Monero Research Lab Papers 1 and 2 published
+      date: September 12, 2014
+      status: completed
+    - name: Monero Research Lab Paper 3 published
+      date: September 25, 2014
+      status: completed
+    - name: 0.8.8.6 released
+      date: December 8, 2014
+      status: completed
+- year: 2015
+  accomplishments:
+    - name: Monero Research Lab Paper 4 published.
+      date: January 26, 2015
+      status: completed
+- year: 2016
+  accomplishments:
+    - name: 0.9.0 Hydrogen Helix published
+      date: January 1, 2016
+      status: completed
+    - name: Monero Research Lab Paper 5 published
+      date: February, 2016
+      status: completed
+    - name: Hardfork to impose minimum ringsize 3 on all transactions
+      date: March, 2016
+      status: completed
+    - name: 0.10.0 Wolfram Warptangent released
+      date: September 18, 2016
+      status: completed
+    - name: Official GUI Beta 1 released
+      date: December, 2016
+      status: completed
+- year: 2017
+  accomplishments:
+    - name: RingCT enabled. Sees quick acceptance.
+      date: January, 2017
+      status: completed
+    - name: 0.10.2 released; critical vulnerability patched
+      date: February 22, 2017
+      status: completed
+    - name: Hardfork for dynamic block and dynamic fee improvements
+      date: April, 2017
+      status: completed
+    - name: Hardfork for increased ringsize and mandatory RingCT
+      date: September, 2017
+      status: upcoming
+    - name: Fluffy blocks
+      date:
+      status: ongoing
+    - name: 0MQ/ZeroMQ
+      date:
+      status: ongoing
+    - name: GUI out of beta
+      date:
+      status: ongoing
+    - name: Kovri Alpha release
+      date:
+      status: ongoing
+    - name: Website Redesign
+      date:
+      status: ongoing
+- year: 2018
+  accomplishments:
+    - name: Research papers
+      date:
+      status: upcoming
+    - name: Second layer solutions for speed and scalability
+      date:
+      status: upcoming
--- a/_data/tags.yml
+++ b/_data/tags.yml
@ -0,0 +1,77 @@
+- slug: monero missives
+  name: Monero Missives
+
+- slug: conferences
+  name: Conferences
+
+- slug: exchanges
+  name: Exchanges
+
+- slug: gui
+  name: Monero Core GUI
+
+- slug: usability
+  name: Usability
+
+- slug: dev diaries
+  name: Dev Diaries
+
+- slug: mining
+  name: Mining
+
+- slug: i2p
+  name: i2p
+
+- slug: i8n
+  name: Internationalisation
+
+- slug: rpc
+  name: RPC API
+
+- slug: docs
+  name: Documentation
+
+- slug: branding
+  name: Branding and Graphics
+
+- slug: compliance
+  name: Standards Compliance
+
+- slug: crypto
+  name: Cryptography
+
+- slug: platforms
+  name: Platform Support
+
+- slug: core
+  name: Monero Core
+
+- slug: accounts
+  name: Accounts (Wallets)
+
+- slug: external
+  name: External Projects
+
+- slug: mymonero
+  name: MyMonero.com
+
+- slug: forkguard
+  name: ForkGuard.com
+
+- slug: year in review
+  name: Year in Review
+
+- slug: funding
+  name: Funding and Donations
+  
+- slug: research
+  name: Monero Research Lab
+
+- slug: blockchaindb
+  name: BlockchainDB
+
+- slug: 0mq
+  name: ZeroMQ
+
+- slug: releases
+  name: Monero Software Releases
--- a/_data/team.yml
+++ b/_data/team.yml
@ -0,0 +1,64 @@
+- area: Core
+  member:
+    - name: othe
+      url: 
+      email: othe@getmonero.org
+      description:
+    - name: smooth
+      url: https://github.com/iamsmooth
+      email: smooth@getmonero.org
+      description:
+    - name: Riccardo "fluffypony" Spagni
+      url: https://github.com/fluffypony
+      email: ric@getmonero.org
+      description:
+    - name: tacotime
+      url:  
+      email: tacotime@getmonero.org
+      description:
+    - name: Francisco "ArticMine" Cabañas
+      url: https://github.com/ArticMine
+      email: articmine@getmonero.org
+      description:
+    - name: luigi1111
+      url: https://github.com/luigi1111
+      email: luigi1111@getmonero.org
+      description:
+    - name: NoodleDoodle
+      url: https://github.com/NoodleDoodleNoodleDoodleNoodleDoodleNoo
+      email: noodledoodle@getmonero.org
+      description:
+- area: Developers
+  member:
+    - name: moneromooo
+      url: https://github.com/moneromooo-monero
+    - name: hyc
+      url: https://github.com/hyc
+    - name: Thomas Winget
+      url: https://github.com/tewinget
+    - name: Jaqueeee
+      url: https://github.com/Jaqueeee
+    - name: mikezackles
+      url: https://github.com/mikezackles
+    - name: Paul Shapiro
+      url: https://github.com/paulshapiro
+- area: Community
+  member:  
+    - name: dEBRUYNE
+      url:
+    - name: SamsungGalaxyPlayer
+      url:
+    - name: gingeropolous
+      url:
+- area: Special Thanks
+  member:
+    - name: warptangent
+      url: https://github.com/warptangent
+    - name: Shen Noether
+      url:
+- area: Monero Research Lab
+  member:
+    - name: Brandon Goodell (Surae Noether)
+      url:
+    - name: Sarang Noether
+      url:
--- a/_includes/dog.html
+++ b/_includes/dog.html
@ -0,0 +1,63 @@
+    <script type="text/javascript">
+		var degree = 0;
+		var maxtalk = 0;
+		var talkbubble = 1;
+		$(document).ready(function(){
+			$("div.bubble-options p.dog-bubble").each(function(){
+				maxtalk++;
+			});		
+		});
+		function dogTalk(){
+			var timer = setTimeout(function() {
+				$temp = "<p>"+$("div.bubble-options p.dog-bubble:nth-child("+talkbubble+")").html()+"</p>";		
+				$("div.dog-bubble").html($temp);
+				//randomize bubbles
+				oldbubble = talkbubble;
+				while (talkbubble == oldbubble) {
+					talkbubble = Math.floor((Math.random()*maxtalk)+1);
+				}
+				//show the bubble
+				$(".dog-bubble").animate({"opacity":'1', "bottom":'30px'}, 400);
+				//hide the bubble
+				setTimeout(function() {
+					$(".dog-bubble").animate({"opacity":'0', "bottom":'0px'}, 400);
+					dogTalk();	
+				}, 5000);		
+			}, 2000);	
+		}
+		function rotate() {
+			$planet = $("div.planet>img");
+			  //CSS3
+			$planet.css({ 'transform' : 'rotate(' + degree + 'deg)'}); 
+			  // For webkit browsers: e.g. Chrome
+			$planet.css({ WebkitTransform : 'rotate(' + degree*2 + 'deg)'});
+			  // For Mozilla browser: e.g. Firefox
+			$planet.css({ '-moz-transform' : 'rotate(' + degree + 'deg)'});
+			  //IE9
+			$planet.css({ '-ms-transform' : 'rotate(' + degree + 'deg)'});
+			  //Opera
+			$planet.css({ '-o-transform' : 'rotate(' + degree + 'deg)'});
+			// Animate rotation with a recursive call
+			var timer = setTimeout(function() {
+				degree-=0.1; 
+				rotate();
+			},10);
+		}
+		function dogRun(){
+			var dog = $("div.dog");
+			var timer2 = setTimeout(function() {
+							 
+				if(dog.css("background-position") == "0px 0px")
+					dog.css({"background-position":"-80px -2px"});
+				else
+					dog.css({"background-position":"0px 0px"});							 
+		
+				dogRun();	
+			}, 130);	
+		}
+		$(window).load(function(){
+			rotate();
+			dogRun();
+			dogTalk();
+		});
+	</script>
--- a/_includes/download.php
+++ b/_includes/download.php
@ -0,0 +1,77 @@
+<?php
+// try figure out the OS from the useragent so we can serve the right default download
+function detect_os($useragent){
+  $uas_os = array();
+  if (preg_match('#(Windows|Win) ([a-zA-Z0-9.\ ]+)#i', $useragent, $regmatch)){
+    $uas_os['name'] = "Windows";
+    $uas_os['code'] = "win";
+    if(preg_match('/x86_64/i', $useragent) || preg_match('/x86-64/i', $useragent) || preg_match('/Win64/i', $useragent) || preg_match('/x64;/i', $useragent) || preg_match('/amd64/i', $useragent) || preg_match('/WOW64/i', $useragent) || preg_match('/x64_64/i', $useragent)){
+      $uas_os['bits'] = "64";
+    }
+    else
+    {
+      $uas_os['bits'] = "32";
+    }
+    $uas_os['ext'] = "zip";
+  }elseif (preg_match('/Mac/i', $useragent)){
+    $uas_os['name'] = "OS X";
+    $uas_os['code'] = "mac";
+    $uas_os['bits'] = "64";
+  }elseif (preg_match('/Linux/i', $useragent)){
+    $uas_os['name'] = "Linux";
+    $uas_os['code'] = "linux";
+    $uas_os['bits'] = "64";
+  }elseif (preg_match('/FreeBSD/i', $useragent)){
+    $uas_os['name'] = "FreeBSD";
+    $uas_os['code'] = "freebsd";
+    $uas_os['bits'] = "64";
+/*  }elseif (preg_match('/CrOS/', $useragent)){
+    $uas_os['name'] = "Chrome OS";
+    $uas_os['code'] = "chrome";
+  }elseif (preg_match('/FreeBSD/i', $useragent)){
+    $uas_os['name'] = "FreeBSD";
+    $uas_os['code'] = "freebsd";
+  }elseif (preg_match('/OpenBSD/i', $useragent)){
+    $uas_os['name'] = "OpenBSD";
+    $uas_os['code'] = "openbsd";
+  }elseif (preg_match('/Solaris/i', $useragent)){
+    $uas_os['name'] = "Solaris";
+    $uas_os['code'] = "solaris";
+  }elseif (preg_match('/Nintendo Wii/i', $useragent)){
+    $uas_os['name'] = "Nintendo Wii";
+    $uas_os['code'] = "wii";
+  }elseif(preg_match('/Nintendo DSi/i', $useragent)){
+    $uas_os['namee'] = "Nintendo DSi";
+    $uas_os['code'] = "ndsi";
+  }elseif (preg_match('#SymbianOS/([.0-9a-zA-Z]+)#i', $useragent, $regmatch)){
+    $uas_os['name'] = "SymbianOS";
+    $uas_os['code'] = "symbian";*/
+  }else{
+    $uas_os['name'] = "Windows";
+    $uas_os['code'] = "win";
+    $uas_os['bits'] = "32";
+  }
+
+  return $uas_os;
+}
+
+$os_array = detect_os($_SERVER['HTTP_USER_AGENT']);
+
+?>
+            <p class="download-links">
+              {% t index.monero_for %} <?php echo $os_array['name']; ?> 
+              <span>
+                <a href="//downloads.getmonero.org/<?php echo $os_array['code']; ?><?php echo $os_array['bits']; ?>" class="btn btn-grey pull-right">
+                  <i class="fa fa-plus-circle icon_download" style="color: white; font-size: 20px;"></i> {% t index.c_download %}
+                </a>
+              </span>
+            </p>
+            
+            <p class="download-links">
+              {% t index.latest_blockchain %}
+              <span>
+                <a href="//downloads.getmonero.org/blockchain.raw" class="btn btn-grey pull-right">
+                  <i class="fa fa-plus-circle icon_download" style="color: white; font-size: 20px;"></i> {% t index.c_download %}
+                </a>
+              </span>
+            </p>
--- a/_includes/footer.html
+++ b/_includes/footer.html
@ -0,0 +1,61 @@
+<footer class="container-fluid">
+            <div class="container">
+                <div class="row around-xs footer-wrapper">
+                   <div class="col-sm-3 col-xs-6">
+                        <h3>Resources</h3>
+                        <ul class="list-unstyled">
+                            <li><a href="/resources/about/" class="white">About Monero</a></li>
+                            <li><a href="/resources/moneropedia/" class="white">Moneropedia</a></li>
+                            <li><a href="/resources/developer-guides/" class="white">Developer Guides</a></li>
+                            <li><a href="/resources/user-guides/" class="white">User Guides</a></li>
+                        </ul>
+                    </div>
+                    <div class="col-sm-3 col-xs-6">
+                        <h3>IRC Channel</h3>
+                        <ul class="list-unstyled">
+                            <li><a href="irc://chat.freenode.net/#monero" class="white">#monero (General)</a></li>
+                            <li><a href="irc://chat.freenode.net/#monero-dev" class="white">#monero-dev (Development)</a></li>
+                            <li><a href="irc://chat.freenode.net/#monero-markets" class="white">#monero-markets (Markets)</a></li>
+                            <li><a href="irc://chat.freenode.net/#monero-pools" class="white">#monero-pools (Mining)</a></li>
+                            <li><a href="irc://chat.freenode.net/#monero-community" class="white">#monero-community (Community)</a></li>
+                        </ul>
+                    </div>
+                    <div class="col-sm-3 col-xs-6">
+                        <h3>Community</h3>
+                        <ul class="list-unstyled">
+                            <li><a href="https://reddit.com/r/monero" class="white">Reddit</a></li>
+                            <li><a href="https://monero.stackexchange.com" class="white">Stack Exchange</a></li>
+                            <li><a href="https://bitcointalk.org/index.php?topic=583449.0" class="white">BitcoinTalk Thread</a></li>
+                            <li><a href="https://monero.slack.com" class="white">Slack Chat</a></li>
+                            <li><a href="https://telegram.me/bitmonero" class="white">Telegram Chat</a></li>
+                        </ul>
+                    </div>
+                    <div class="col-sm-3 col-xs-6">
+                        <h3>The Monero Project</h3>
+                        <ul class="list-unstyled">
+                            <li><a href="https://openalias.org" class="white">Open Alias</a></li>
+                            <li><a href="https://getkovri.org" class="white">Kovri</a></li>
+                            <li><a href="/resources/research-lab/" class="white">Monero Research Lab</a></li>
+                            <li><a href="#" class="white">Monero Press Kit</a></li>
+                        </ul>
+                    </div>
+                </div>
+                <div class="row center-xs">
+                    <div class="social-icons">
+                    </div>
+                    <div class="footer-links">
+                        <ul class="list-unstyled list-inline">
+                            <li><a href="/legal/" class="white footer-link">Legal</a></li>
+                            <li><a href="https://github.com/monero-project" class="white footer-link">Source Code</a></li>
+                            <li><a href="#" class="white footer-link">Coin Specs</a></li>
+                        </ul>
+                    </div>
+                </div>
+            </div>
+        </footer>
+
+
+    <!-- JS -->
+    <script src="//static.getmonero.org/scripts.js"></script>
+    
+    {% include hostflag.html %}
--- a/_includes/head.html
+++ b/_includes/head.html
@ -0,0 +1,29 @@
+  <head>
+    <meta charset="utf-8">
+    <meta http-equiv="X-UA-Compatible" content="IE=edge">
+    <meta name="viewport" content="width=device-width, initial-scale=1">
+
+    <title>{% if page.entry %}{{ page.entry }} | {% t global.wiki %} | {% t index.page_title %}{% elsif tag %}{% t global.tags %}: {{ tag.name }} | {% t index.page_title %}{% elsif page.title %}{{ page.title }} | {% t index.page_title %}{% else %}{% t index.page_title %}{% endif %}</title>
+	<meta name="description" content="{% if page.entry %}{{ page.entry }}: {{ page.summary }} [{% t global.wikimeta %}]{% elsif tag %}{% t global.tagsmeta %}: {{ tag.name }}{% elsif page.meta %}{{ page.meta }}{% elsif page.title %}{{ page.title }} [{% t global.titlemeta %}]{% else %}{{ site.description }}{% endif %}">
+	<meta name="keywords" content="{{ site.keywords }}">
+
+    <meta property="og:title" content="{% if page.entry %}{% t global.wiki %}: {{ page.entry }}{% elsif tag %}{% t global.tags %}: {{ tag.name }}{% elsif page.title %}{% t global.monero %}: {{ page.title }}{% else %}{% t index.page_title %}{% endif %}"/>
+    <meta property="og:description" content="{% if page.entry %}{{ page.entry }}: {{ page.summary }} [{% t global.wikimeta %}]{% elsif tag %}{% t global.tagsmeta %}: {{ tag.name }}{% elsif page.meta %}{{ page.meta }}{% elsif page.title %}{{ page.title }} [{% t global.titlemeta %}]{% else %}{{ site.description }}{% endif %}">
+    <meta property="og:image" content="{% if page.icon %}http://static.getmonero.org/images/opengraph/{{ page.icon }}.png{% else %}http://static.getmonero.org/images/opengraph/logo.png{% endif %}">
+    <meta property="og:site_name" content="{% t global.sitename %}">
+    <meta property="og:url" content="https://getmonero.org{{ page.url }}">
+    <meta property="og:type" content="website">
+
+    <link rel="apple-touch-icon" sizes="180x180" href="/meta/apple-touch-icon.png">
+        <link rel="icon" type="image/png" sizes="32x32" href="/meta/favicon-32x32.png">
+        <link rel="icon" type="image/png" sizes="16x16" href="/meta/favicon-16x16.png">
+        <link rel="manifest" href="/meta/manifest.json">
+        <link rel="mask-icon" href="/meta/safari-pinned-tab.svg" color="#5bbad5">
+        <meta name="theme-color" content="#ffffff">
+
+    <link href="/css/custom.css" rel="stylesheet">
+
+    
+    <meta name="msapplication-config" content="/ietemplates/ieconfig.xml">
+
+  </head>
--- a/_includes/header.html
+++ b/_includes/header.html
@ -0,0 +1,162 @@
+<div class="mob-nav">
+              <input class="burger-check" id="mobile-burger" type="checkbox"><label for="mobile-burger" class="burger"></label>
+           
+        <div class="slide-in-nav">
+             <div class="container slide-in">
+                 <div class="row">
+                     <div class="col-xs-12 dropdown text-center nav-item">
+                            <label for="drop1">Get Started<div class="arrow-down"></div></label>
+                            <input class="burger-checkdropdown" id="drop1" type="checkbox">
+                            <div class="dropdown-content">
+                                <a href="/get-started/what-is-monero/">What Is Monero?</a>
+                                <a href="/get-started/using/">Using</a>
+                                <a href="/get-started/accepting/">Accepting</a>
+                                <a href="/get-started/contributing/">Contributing</a>
+                                <a href="/get-started/mining/">Mining</a>
+                                <a href="/get-started/faq">FAQ</a>
+                            </div>
+                     </div>
+                 </div>
+                 <div class="row">
+                     <div class="col-xs-12">
+                         <div class="text-center nav-item">
+                            <a href="/downloads/">Downloads</a> 
+                         </div>
+                     </div>
+                 </div>
+                 <div class="row">
+                     <div class="col-xs-12 dropdown text-center nav-item">
+                        <label for="drop2">Recent News<div class="arrow-down"></div></label>
+                        <input class="burger-checkdropdown" id="drop2" type="checkbox">
+                         <div class="dropdown-content">
+                            <a href="/blog/">All Posts</a>
+                            <a href="/blog/tags/monero%20missives.html">Missives</a>
+                            <a href="/blog/tags/dev%20diaries.html">Meeting Logs</a>
+                            <a href="/blog/tags/releases.html">Releases</a>
+                          </div>
+                     </div>
+                 </div>
+                 <div class="row">
+                         <div class="col-xs-12 dropdown text-center nav-item">
+                            <label for="drop4">Community<div class="arrow-down"></div></label>
+                        <input class="burger-checkdropdown" id="drop4" type="checkbox">
+                         <div class="dropdown-content">
+                            <a href="/community/team/">Team</a>
+                            <a href="/community/hangouts/">Hangouts</a>
+                            <a href="/community/events/">Events</a>
+                            <a href="/community/sponsorships/">Sponsorships</a>
+                            <a href="/community/merchants/">Merchants</a>
+                          </div>
+                     </div>
+                 </div>
+                 <div class="row">
+                     <div class="col-xs-12 dropdown text-center nav-item">
+                        <label for="drop3">Resources<div class="arrow-down"></div></label>
+                        <input class="burger-checkdropdown" id="drop3" type="checkbox">
+                         <div class="dropdown-content">
+                            <a href="/resources/about/">About</a>
+                            <a href="/resources/roadmap/">Roadmap</a>
+                            <a href="/resources/research-lab/">Monero Research Lab</a>
+                            <a href="/resources/moneropedia/">Moneropedia</a>
+                            <a href="/resources/user-guides/">User Guides</a>
+                            <a href="/resources/developer-guides/">Developer Guides</a>
+                          </div>
+                     </div>
+                 </div>
+                 <div class="row">
+                     <div class="col-xs-12">
+                         <div class="text-center nav-item mob">
+                            <a href="/forum-funding-system/">Forum Funding System</a> 
+                         </div>
+                     </div>
+                 </div>
+                 <div class="row">
+                     <div class="col-xs-12">
+                         <div class="text-center nav-item mob">
+                            <a href="/the-monero-project/">The Monero Project</a> 
+                         </div>
+                     </div>
+                 </div>            
+             </div>
+          
+        </div>
+       </div>
+        <div class="desktop-nav">
+            <nav class="container">
+            <div class="topnav">
+              <div class="row middle-xs">
+                  <div class="col-lg-4 col-md-4 col-sm-4 col-xs-4">
+                    <a href="/"><img src="/img/monero-logo.png" alt="Monero Logo" class="monero-logo"></a>
+                  </div>
+                  <div class="col-lg-8 col-md-8 col-sm-8 topnav-list end-xs">
+                      <div class="row end-xs">
+                         <div class="col-md-12">
+                          <a href="/forum-funding-system/" class="mob top-link col-md-4">Forum Funding System</a>
+                          <a href="/the-monero-project/" class="mob top-link col-md-3">The Monero Project</a>
+                          </div>
+                      </div>
+                  </div>
+              </div>
+            </div>
+            <div class="botnav white-nav">
+                <input class="burger-check" id="burger-check" type="checkbox"><label for="burger-check" class="burger"></label>
+                <div class="row between-xs nav-items">
+                    <div class="col dropdown nav-item">
+                            <label for="drop1">Get Started<div class="arrow-down"></div></label>
+                            <input class="burger-checkdropdown" id="drop1" type="checkbox">
+                            <div class="dropdown-content">
+                                <a href="/get-started/what-is-monero/">What Is Monero?</a>
+                                <a href="/get-started/using/">Using</a>
+                                <a href="/get-started/accepting/">Accepting</a>
+                                <a href="/get-started/contributing/">Contributing</a>
+                                <a href="/get-started/mining/">Mining</a>
+                                <a href="/get-started/faq">FAQ</a>
+                            </div>
+                    </div>
+                     <div class="col nav-item">
+                        <a href="/downloads/">Downloads</a> 
+                    </div>
+                    <div class="col dropdown nav-item">
+                        <label for="drop2">Recent News<div class="arrow-down"></div></label>
+                        <input class="burger-checkdropdown" id="drop2" type="checkbox">
+                         <div class="dropdown-content">
+                            <a href="/blog/">All Posts</a>
+                            <a href="/blog/tags/monero%20missives.html">Missives</a>
+                            <a href="/blog/tags/dev%20diaries.html">Meeting Logs</a>
+                            <a href="/blog/tags/releases.html">Releases</a>
+                          </div>
+                    </div>
+                    <div class="col dropdown nav-item">
+                        <label for="drop4">Community<div class="arrow-down"></div></label>
+                        <input class="burger-checkdropdown" id="drop4" type="checkbox">
+                         <div class="dropdown-content">
+                            <a href="/community/team/">Team</a>
+                            <a href="/community/hangouts/">Hangouts</a>
+                            <a href="/community/events/">Events</a>
+                            <a href="/community/sponsorships/">Sponsorships</a>
+                            <a href="/community/merchants/">Merchants</a>
+                          </div>
+                    </div>
+                     <div class="col dropdown nav-item">
+                        <label for="drop3">Resources<div class="arrow-down"></div></label>
+                        <input class="burger-checkdropdown" id="drop3" type="checkbox">
+                         <div class="dropdown-content">
+                            <a href="/resources/about/">About</a>
+                            <a href="/resources/roadmap/">Roadmap</a>
+                            <a href="/resources/research-lab/">Research Lab</a>
+                            <a href="/resources/moneropedia/">Moneropedia</a>
+                            <a href="/resources/user-guides/">User Guides</a>
+                            <a href="/resources/developer-guides/">Developer Guides</a>
+                          </div>
+                    </div>
+                  </div>
+            </div>
+        </nav>
+        </div>
+        <div class="mob bot-nav white-nav">
+            <div class="row center-xs">
+                <div class="col-xs-6">
+                    <a href="/"><img src="/img/monero-logo.png" alt="Monero Logo" class="monero-logo"></a>
+                </div>
+            </div>     
+        </div>    
--- a/_includes/hostflag.html
+++ b/_includes/hostflag.html
@ -0,0 +1 @@
+<!-- page served by server N -->
--- a/_includes/language_cookie.php
+++ b/_includes/language_cookie.php
@ -0,0 +1,12 @@
+<?php
+// set the language cookie, all languages must use the appropriate ISO 639-1 code
+$lang = "en"; // fallback to English
+// we expect the path of this file to be /XX (two letter language code), if its not then the most likely event is that we are in the
+// English language part of the site. If we are in, say, /de then we can just grab that ISO code and run with it. The nginx rules won't
+// match on a language we don't know about anyway.
+if (substr(realpath(dirname(__FILE__)), -3, 1) == "/")
+	$lang = substr(realpath(dirname(__FILE__)), -2);
+// apply to all Monero subdomains, expire in a month
+//setcookie("MONERO_LANG", $lang, time()+2592000, "/", ".getmonero.org");
+setcookie("MONERO_LANG", $lang, time()+2592000, "/");
+?>
--- a/_layouts/base.html
+++ b/_layouts/base.html
@ -0,0 +1,13 @@
+<!DOCTYPE html>
+<html>
+
+  {% include head.html %}
+
+  <body>
+    <div class="page-wrapper">
+        {% include header.html %}
+        {{content}}
+    {% include footer.html %}
+    </div>
+  </body>
+</html>
--- a/_layouts/blog_by_tag.html
+++ b/_layouts/blog_by_tag.html
@ -0,0 +1,76 @@
+---
+layout: custom
+---
+ 
+  {% assign filename = page.path | remove: '.md' | split: '/' | last %}
+  {% for data_tag in site.data.tags %}
+	{% if data_tag.slug == filename %}
+		{% assign tag = data_tag %}
+	{% endif %}
+  {% endfor %}
+
+<div class="site-wrap">
+    <section class="container">
+            <div class="row">
+                <!-- left two-thirds block-->
+                <div class="left two-thirds col-lg-8 col-md-8 col-sm-8 col-xs-12">
+                    <div class="info-block">
+                        <div class="row center-xs">
+                        <div class="page-title">
+		                  <h2 class="inline">{% t tags.all %}: <span class="kicks">{{ tag.name }}</span></h2>
+		                </div>
+                    </div>
+                    <div>
+                       {% if site.tags[tag.slug] %}
+				{% for post in site.tags[tag.slug] %}
+				  <h3><a href="{{ post.url }}">{{ post.title }}</a></h3>
+				  <p>
+					{{ post.summary }}
+				  </p>
+				{% endfor %}
+			{% else %}
+				<h3>{% t tags.notags %}</h3>
+			{% endif %}
+                    </div>
+                    </div>
+                </div>
+                <!-- end left two-thirds block-->
+                
+                <!-- right one-third block-->
+                <div class="right one-third col-lg-4 col-md-4 col-sm-12 col-xs-12">
+                        <div class="sidebar col-sm-12 col-xs-12">   
+                            <div class="info-block">
+                                <div class="row center-xs">
+                                    <div class="col"><h2>Recent Posts</h2></div>
+                                </div>
+                                {% for post in site.posts limit:4 %}
+                                <div class="row start-xs info-block-row">
+                                    <div class="col">
+                                         <p><a href="{{ post.url }}">{{ post.title }}</a></p>
+                                     </div>
+                                </div>
+                                {% endfor %}
+                            </div>
+                            <div class="info-block">
+                                <div class="row center-xs">
+                                    <div class="col">
+                                        <h2>Popular Tags</h2>
+                                    </div>
+                                </div>
+                                    {% for tag in site.data.tags limit:4 %}
+                                    <div class="row start-xs">
+                                        <div class="col">
+                                             <p><a href="/blog/tags/{{ tag.slug }}.html">{{ tag.name }}</a></p>
+                                         </div>
+                                     </div>
+                                     {% endfor %}
+
+
+                            </div>
+                        </div> 
+                </div>
+                <!-- end right one-third block-->
+            </div>
+        </section>
+    
+</div>
--- a/_layouts/custom.html
+++ b/_layouts/custom.html
@ -0,0 +1,7 @@
+---
+layout: default
+---
+
+<div class="site-wrap">
+    {{content}}
+</div>
--- a/_layouts/default.html
+++ b/_layouts/default.html
@ -0,0 +1,5 @@
+---
+layout: base
+---
+<h1 class="text-center">{{page.title}}</h1>
+    {{content}}
--- a/_layouts/defaultnt.html
+++ b/_layouts/defaultnt.html
@ -0,0 +1,17 @@
+---
+layout: base
+---
+    <div class="site-wrap">
+    <!-- FULL WIDTH BLOCK -->
+        <section class="container full">
+                <div class="info-block">
+                    <div class="row center-xs">
+                        <div class="col"><h2>Title Goes Here</h2></div>
+                    </div>
+                    <div>
+                        {{content}}
+                    </div>
+                </div>
+        </section>
+    <!-- END FULL WIDTH BLOCK -->
+    </div>
--- a/_layouts/error.html
+++ b/_layouts/error.html
@ -0,0 +1,17 @@
+<!DOCTYPE html>
+<html>
+
+  {% include head.html %}
+
+  <body>
+
+    {% include header.html %}
+
+    {{ content }}
+
+    {% include footer.html %}
+    {% include dog.html %}
+
+  </body>
+
+</html>
--- a/_layouts/ffs-cp.html
+++ b/_layouts/ffs-cp.html
@ -0,0 +1,30 @@
+---
+layout: base
+---
+<div class="site-wrap">
+<div class="container ffs-breadcrumbs">
+
+<p><a href="/forum-funding-system/">Forum Funding System</a> > <a href="/forum-funding-system/completed-proposals/">Completed Proposals</a> > {{page.title}}</p>
+
+</div>
+    <!-- FULL WIDTH BLOCK -->
+        <section class="container full">
+                <div class="info-block text-adapt">
+                   <div class="row center-xs">
+                        <div class="col">
+                            <h2>{{page.title}}</h2>
+                            <p>by {{page.author}}</p>
+                             <div class="ffs-status complete">
+                                <p>This project has been completed. The proposal is kept here both to celebrate the achievements of the Monero community, and for historical accuracy about what was accomplished.</p>
+                            </div>
+                        </div>
+                    </div>
+                    <div>
+                        {{content}}
+                    </div>
+                </div>
+        </section>
+    <!-- END FULL WIDTH BLOCK -->
+    </div>
+    
+    <!-- JAVASCRIPT FOR DISQUS -->
--- a/_layouts/ffs-fr.html
+++ b/_layouts/ffs-fr.html
@ -0,0 +1,48 @@
+---
+layout: base
+---
+
+<div class="site-wrap">
+<div class="container ffs-breadcrumbs">
+
+<p><a href="/forum-funding-system/">Forum Funding System</a> > <a href="/forum-funding-system/funding-required/">Funding Required</a> > {{page.title}}</p>
+
+</div>
+       <!-- FULL WIDTH BLOCK -->
+        <section class="container full">
+                <div class="info-block text-adapt">
+                    <div class="row center-xs">
+                        <div class="col">
+                            <h2>How to Contribute</h2>
+                        </div>
+                    </div>
+                    <div class="row">
+                        <div class="col-xs-12">
+                            <p>In order to contribute to the cause of <strong>{{page.title}}</strong> all you have to do is the following:</p>
+                            <p>Have a valid Monero address. If you don't have one, you can read on getting started!</p>
+                            <p>Send the amount of XMR that you wish to contribute to the address: <strong>{{page.address}}</strong></p>
+                            <p>Make sure that you enter a payment ID of <strong>{{page.paymentid}}</strong> in order for us to be able to assign your contribution to this specific project!</p>
+                        </div>
+                    </div>
+                </div>
+        </section>
+    <!-- END FULL WIDTH BLOCK -->
+   
+    <!-- FULL WIDTH BLOCK -->
+        <section class="container full">
+                <div class="info-block text-adapt">
+                    <div class="row center-xs">
+                        <div class="col">
+                            <h2>{{page.title}}</h2>
+                            <p>by {{page.author}}</p>
+                        </div>
+                    </div>
+                    <div>
+                        {{content}}
+                    </div>
+                </div>
+        </section>
+    <!-- END FULL WIDTH BLOCK -->
+    </div>
+    
+    <!-- JAVASCRIPT FOR DISQUS -->
--- a/_layouts/ffs-ideas.html
+++ b/_layouts/ffs-ideas.html
@ -0,0 +1,27 @@
+---
+layout: base
+---
+<div class="site-wrap">
+<div class="container ffs-breadcrumbs">
+
+<p><a href="/forum-funding-system/">Forum Funding System</a> > <a href="/forum-funding-system/ideas/">Ideas</a> > {{page.title}}</p>
+
+</div>
+    <!-- FULL WIDTH BLOCK -->
+        <section class="container full">
+                <div class="info-block text-adapt">
+                   <div class="row center-xs">
+                        <div class="col">
+                            <h2>{{page.title}}</h2>
+                            <p>{{page.author}}</p>
+                        </div>
+                    </div>
+                    <div>
+                        {{content}}
+                    </div>
+                </div>
+        </section>
+    <!-- END FULL WIDTH BLOCK -->
+    </div>
+    
+    <!-- JAVASCRIPT FOR DISQUS -->
--- a/_layouts/ffs-ot.html
+++ b/_layouts/ffs-ot.html
@ -0,0 +1,28 @@
+---
+layout: base
+---
+<div class="site-wrap">
+<div class="container ffs-breadcrumbs">
+
+<p><a href="/forum-funding-system/">Forum Funding System</a> > <a href="/forum-funding-system/open-tasks/">Open Tasks</a> > {{page.title}}</p>
+
+</div>
+
+    <!-- FULL WIDTH BLOCK -->
+        <section class="container full">
+                <div class="info-block text-adapt">
+                   <div class="row center-xs">
+                        <div class="col">
+                            <h2>{{page.title}}</h2>
+                            <p>{{page.author}}</p>
+                        </div>
+                    </div>
+                    <div>
+                        {{content}}
+                    </div>
+                </div>
+        </section>
+    <!-- END FULL WIDTH BLOCK -->
+    </div>
+    
+    <!-- JAVASCRIPT FOR DISQUS -->
--- a/_layouts/ffs-wip.html
+++ b/_layouts/ffs-wip.html
@ -0,0 +1,32 @@
+---
+layout: base
+---
+<div class="site-wrap">
+
+<div class="container ffs-breadcrumbs">
+
+<p><a href="/forum-funding-system/">Forum Funding System</a> > <a href="/forum-funding-system/work-in-progress/">Work in Progress</a> > {{page.title}}</p>
+
+</div>
+
+    <!-- FULL WIDTH BLOCK -->
+        <section class="container full">
+                <div class="info-block text-adapt">
+                   <div class="row center-xs">
+                        <div class="col">
+                            <h2>{{page.title}}</h2>
+                            <p>by {{page.author}}</p>
+                            <div class="ffs-status inprogress">
+                                <p>This project has been funded and is being worked on. Keep an eye out here at the bottom of the proposal for updates.</p>
+                            </div>
+                        </div>
+                    </div>
+                    <div>
+                        {{content}}
+                    </div>
+                </div>
+        </section>
+    <!-- END FULL WIDTH BLOCK -->
+    </div>
+    
+    <!-- JAVASCRIPT FOR DISQUS -->
--- a/_layouts/ffs.html
+++ b/_layouts/ffs.html
@ -0,0 +1,17 @@
+---
+layout: default
+---
+<div class="site-wrap">
+    <!-- FULL WIDTH BLOCK -->
+        <section class="container full">
+                <div class="info-block text-adapt">
+                   <a href="/forum-funding-system/ideas/">Back to Ideas</a>
+                    <div>
+                        {{content}}
+                    </div>
+                </div>
+        </section>
+    <!-- END FULL WIDTH BLOCK -->
+    </div>
+    
+    <!-- JAVASCRIPT FOR DISQUS -->
--- a/_layouts/full-text.html
+++ b/_layouts/full-text.html
@ -0,0 +1,14 @@
+---
+layout: default
+---
+<div class="site-wrap">
+    <!-- FULL WIDTH BLOCK -->
+        <section class="container full">
+                <div class="info-block text-adapt">
+                    <div>
+                        {{content}}
+                    </div>
+                </div>
+        </section>
+    <!-- END FULL WIDTH BLOCK -->
+    </div>
--- a/_layouts/full.html
+++ b/_layouts/full.html
@ -0,0 +1,14 @@
+---
+layout: default
+---
+<div class="site-wrap">
+    <!-- FULL WIDTH BLOCK -->
+        <section class="container full">
+                <div class="info-block">
+                    <div>
+                        {{content}}
+                    </div>
+                </div>
+        </section>
+    <!-- END FULL WIDTH BLOCK -->
+    </div>
--- a/_layouts/moneropedia.html
+++ b/_layouts/moneropedia.html
@ -0,0 +1,16 @@
+---
+layout: base
+---
+<h1 class="text-center">{{page.title}}</h1>
+    <div class="site-wrap">
+    <!-- FULL WIDTH BLOCK -->
+        <section class="container full">
+                <div class="info-block text-adapt">
+                   <h2>{{page.entry}}</h2>
+                    <div>
+                        {{content}}
+                    </div>
+                </div>
+        </section>
+    <!-- END FULL WIDTH BLOCK -->
+    </div>
--- a/_layouts/none.html
+++ b/_layouts/none.html
@ -0,0 +1,10 @@
+<!DOCTYPE html>
+<html lang="en">
+
+  <body>
+
+    {{ content }}
+
+  </body>
+
+</html>
--- a/_layouts/post.html
+++ b/_layouts/post.html
@ -0,0 +1,78 @@
+---
+layout: base
+---
+
+{% assign post = page %}
+{% if post.tags.size > 0 %}
+    {% capture tags_content %}Post tags {% if post.tags.size == 1 %}<i class="fa fa-tag"></i>{% else %}<i class="fa fa-tags"></i>{% endif %}: {% endcapture %}
+    {% for post_tag in post.tags %}
+        {% for data_tag in site.data.tags %}
+            {% if data_tag.slug == post_tag %}
+                {% assign tag = data_tag %}
+            {% endif %}
+        {% endfor %}
+        {% if tag %}
+            {% capture tags_content_temp %}{{ tags_content }}<a href="/blog/tags/{{ tag.slug }}.html">{{ tag.name }}</a>{% if forloop.last == false %}, {% endif %}{% endcapture %}
+            {% assign tags_content = tags_content_temp %}
+        {% endif %}
+    {% endfor %}
+{% else %}
+    {% assign tags_content = '' %}
+{% endif %}
+<div class="site-wrap post">
+    
+    <section class="container">
+            <div class="row">
+                <!-- left two-thirds block-->
+                <div class="left two-thirds col-lg-8 col-md-8 col-sm-12 col-xs-12">
+                    <div class="info-block">
+                        <div class="row">
+                        <div class="col"><h2>{{ page.title }}</h2>
+                        <p class="author">{% t blog.author %}: {% if page.author %}{{page.author}}{% else %}{{site.author}}{% endif%}</p></div>
+                    </div>
+                    <div>
+                        {{content}}
+                    </div>
+                    <hr>
+                    <p id="post-meta">{{ tags_content }}</p>
+                    </div>
+                </div>
+                <!-- end left two-thirds block-->
+                
+                <!-- right one-third block-->
+                <div class="right one-third col-lg-4 col-md-4 col-sm-12 col-xs-12">
+                        <div class="sidebar col-sm-12 col-xs-12">   
+                            <div class="info-block">
+                                <div class="row center-xs">
+                                    <div class="col"><h2>Recent Posts</h2></div>
+                                </div>
+                                {% for post in site.posts limit:4 %}
+                                <div class="row start-xs info-block-row">
+                                    <div class="col">
+                                         <p><a href="{{ post.url }}">{{ post.title }}</a></p>
+                                     </div>
+                                </div>
+                                {% endfor %}
+                            </div>
+                            <div class="info-block">
+                                <div class="row center-xs">
+                                    <div class="col">
+                                        <h2>Popular Tags</h2>
+                                    </div>
+                                </div>
+                                    {% for tag in site.data.tags limit:4 %}
+                                    <div class="row start-xs">
+                                        <div class="col">
+                                             <p><a href="/blog/tags/{{ tag.slug }}.html">{{ tag.name }}</a></p>
+                                         </div>
+                                     </div>
+                                     {% endfor %}
+
+
+                            </div>
+                        </div> 
+                </div>
+                <!-- end right one-third block-->
+            </div>
+        </section>
+    </div>        
--- a/_layouts/proposal.html
+++ b/_layouts/proposal.html
@ -0,0 +1,5 @@
+---
+layout: base
+---
+<h1 class="text-center">{{page.title}}</h1>
+    {{content}}
--- a/_layouts/root.html
+++ b/_layouts/root.html
@ -0,0 +1,23 @@
+{% include language_cookie.php %}
+<!DOCTYPE html>
+<html>
+
+  {% include head.html %}
+
+  <body>
+
+    <div id="wrap">
+
+        {% include header.html %}
+
+        <div class="container main-content">
+            {{ content }}
+        </div>
+
+        {% include footer.html %}
+
+    </div>
+
+  </body>
+
+</html>
--- a/_layouts/static_page.html
+++ b/_layouts/static_page.html
@ -0,0 +1,15 @@
+---
+layout: base
+---
+<h1 class="text-center">{{page.title}}</h1>
+    <div class="site-wrap">
+    <!-- FULL WIDTH BLOCK -->
+        <section class="container full">
+                <div class="info-block text-adapt">
+                    <div>
+                        {{content}}
+                    </div>
+                </div>
+        </section>
+    <!-- END FULL WIDTH BLOCK -->
+    </div>
--- a/_plugins/jekyll-live-tiles.rb
+++ b/_plugins/jekyll-live-tiles.rb
@ -0,0 +1,164 @@
+# Jekyll plugin for generating Windows 8.1 start screen live tiles
+#
+# Usage: place this file in the _plugins directory and set the required configuration
+#        attributes in the _config.yml file
+#
+# Uses the following attributes in _config.yml:
+#   ie_category:   - (optional) poll only a specific category of posts
+#   ie_frequency:  - (optional) the frequency of site polling. Options are {30,60,360,720,1440}. Default is 1440 (1 day) 
+#   ie_tile_color: - (optional) the color of the windows 8 pinned background tile
+#   ie_tile_small: - location of small tile image (For more information of tile sizes visit http://msdn.microsoft.com/en-us/library/dn455106(v=vs.85).aspx)
+#   ie_tile_medium - location of medium tile image
+#   ie_tile_wide   - location of wide tile image
+#   ie_tile_large  - location of large tile image
+
+#
+# Author: Matt Sheehan <sheehamj@mountunion.edu>
+# Site: http://mattsheehan.me
+# Source: http://github.com/
+#
+# Distributed under the MIT license
+# Copyright Matt Sheehan 2014
+
+
+module Jekyll
+
+  class TileTemplater < Generator
+    priority :low
+    safe true
+
+    # Entry method
+    def generate(site)
+      # create tile config file
+      site.static_files << TileConfig.new(site, site.source, "/ietemplates/", "ieconfig.xml")
+
+      # create tile poll files
+      # create at most 4
+      category = site.config["ie_category"]
+      posts = !category ? site.posts : site.categories.has_key?(category) ? site.categories[category] : site.posts
+      
+      count = [posts.docs.length, 4].min
+
+      posts.docs.reverse[0..count].each_with_index do |post, index|
+        site.static_files << TilePoll.new(site, site.source, "/ietemplates/", "poll#{index+1}.xml", post)
+      end
+    end
+
+  end
+
+
+
+  # polling xml
+  class TilePoll < StaticFile
+    def initialize(site, base, dir, name, post)
+      super(site, base, dir, name, nil)
+
+      @post = post
+    end
+
+    def write(dest)
+      # post.render(site.layouts, site.site_payload)
+
+      # Create directory if doesn't exist
+      poll_dir = File.join(dest, @dir)
+      FileUtils.mkdir_p(poll_dir)
+
+
+      # Build xml tile templates
+      xml = Builder::XmlMarkup.new( :indent => 2)
+      xml.instruct! :xml, :encoding => "utf-8"
+
+      xml.tile do |tile|
+        tile.visual("lang"=>"en-US", "version"=>"2") do |v|
+          v.binding("template"=>"TileSquare150x150Text04", "branding"=>"logo", "fallback"=>"TileSquareImage") do |b|
+            b.tag!("text", @post['title'], "id"=>"1")
+          end
+          v.binding("template"=>"TileWide310x150Text03", "branding"=>"logo", "fallback"=>"TileWideImage") do |b|
+            b.tag!("text", @post['title'], "id"=>"1")
+          end
+          v.binding("template"=>"TileSquare310x310TextList02", "branding"=>"logo", "fallback"=>"TileWideText09") do |b|
+            b.tag!("text", @post['title'], "id"=>"1")
+            b.tag!("text", shorten(strip(@post.content)),"id"=>"2")
+            b.tag!("text", "#{@post.date.month}-#{@post.date.day}-#{@post.date.year}", "id"=>"3")
+          end
+        end
+      end
+
+      poll_path = File.join(poll_dir, @name)
+      File.open(poll_path, "w") { |f| f.write(xml.target!) }
+    end
+
+
+    private
+
+    # Shortens string and adds trailing ellipsis
+    def shorten(str, count = 30)
+      if str.length >= count
+        return str[0, count] << "..."
+      end
+      return str
+    end
+
+    # Strips html tags (not the best)
+    def strip(string)
+      string.gsub(/<[^>]*>/, "")
+    end
+
+  end
+
+
+  # sets ie 11 configs
+  class TileConfig < StaticFile; 
+    def initialize(site, base, dir, name)
+      super(site, base, dir, name)
+    end
+
+    def write(dest)
+      require 'builder'
+
+      # configs
+      tile_color = @site.config["ie_tile_color"] || "#000000"
+      tile_small = @site.config["ie_tile_small"]
+      tile_medium = @site.config["ie_tile_medium"]
+      tile_wide = @site.config["ie_tile_wide"]
+      tile_large = @site.config["ie_tile_large"]
+
+      frequency = @site.config["ie_frequency"] || 1440
+      raise "frequency must be either 30, 60, 360, 720, 1440" unless [30,60,360,720,1440].include?(frequency)
+
+      # create dir for tile config
+      config_dir = File.join(dest, @dir)
+      FileUtils.mkdir_p(config_dir)
+
+
+      # build xml config
+      xml = Builder::XmlMarkup.new( :indent=>2)
+      xml.instruct! :xml, :encoding=>"utf-8"
+
+      xml.browserconfig do |config|
+        config.msapplication do |app|
+          app.tile do |tile|
+            tile.tag!("square70x70logo", "src"=>"#{tile_small}")
+            tile.tag!("square150x150logo", "src"=>"#{tile_medium}")
+            tile.tag!("wide310x150logo", "src"=>"#{tile_wide}")
+            tile.tag!("square310x310logo", "src"=>"#{tile_large}")
+            tile.tag!("TileColor", "#{tile_color}")
+          end
+          app.notification do |n|
+            n.tag!("polling-uri", "src"=>"/ietemplates/poll1.xml")
+            n.tag!("polling-uri2", "src"=>"/ietemplates/poll2.xml")
+            n.tag!("polling-uri3", "src"=>"/ietemplates/poll3.xml")
+            n.tag!("polling-uri4", "src"=>"/ietemplates/poll4.xml")
+            n.tag!("polling-uri5", "src"=>"/ietemplates/poll5.xml")
+            n.tag!("frequency", "#{frequency}")
+            n.tag!("cycle", "1")
+          end
+        end
+      end
+
+      # write file
+      config_path = File.join(config_dir, @name)
+      File.open(config_path, "w") { |f| f.write(xml.target!) }
+    end
+   end
+end
--- a/_plugins/moneropedia.rb
+++ b/_plugins/moneropedia.rb
@ -0,0 +1,83 @@
+# Copyright (c) 2014-2015, The Monero Project
+# 
+# All rights reserved.
+# 
+# Redistribution and use in source and binary forms, with or without modification, are
+# permitted provided that the following conditions are met:
+# 
+# 1. Redistributions of source code must retain the above copyright notice, this list of
+#    conditions and the following disclaimer.
+# 
+# 2. Redistributions in binary form must reproduce the above copyright notice, this list
+#    of conditions and the following disclaimer in the documentation and/or other
+#    materials provided with the distribution.
+# 
+# 3. Neither the name of the copyright holder nor the names of its contributors may be
+#    used to endorse or promote products derived from this software without specific
+#    prior written permission.
+# 
+# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY
+# EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+# MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL
+# THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
+# PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+# INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
+# STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF
+# THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+module Jekyll
+  module Converters
+    class Markdown < Converter
+      alias base_converter convert
+      @@moneropedia = Array.new
+      @@moneropedia_ordered = Hash.new
+
+      def convert(content)
+        # build up index of Moneropedia summaries
+        if @@moneropedia.empty?
+          
+          # grab all .md files in the Moneropedia folder, ignore index.md
+          moneropedia_path = File.join(@config["source"], "/resources/moneropedia/*.md")
+          files = Dir.glob(moneropedia_path).reject{|f| f =~ Regexp.new('index.md', Regexp::EXTENDED | Regexp::IGNORECASE) }
+
+          # step through all the files
+          files.each do |entry_file|
+            entry = { }
+            entry = SafeYAML.load_file(entry_file)
+
+            if !entry.empty?
+              @@moneropedia.push({ :terms => entry['terms'], :summary => entry['summary'], :file => File.basename(entry_file, ".*") })
+              @@moneropedia_ordered = @@moneropedia_ordered.merge({ entry['entry'] => File.basename(entry_file, ".*") })
+            end
+          end
+        end
+
+        # Jekyll.logger.warn YAML::dump(@@moneropedia_ordered)
+        if content.include? '@moneropedia'
+          # Moneropedia index, replace with a list of entries
+          cur_letter = 'A'
+          replace = "<div class='col-md-4 col-sm-6 col-xs-12 moneropedia'>\n<h4 class='text-center'>A</h4>\n"
+          @@moneropedia_ordered.sort.map do |entry, link|
+            if cur_letter != entry[0]
+              replace += "</div>\n<div class='col-md-4 col-sm-6 col-xs-12 moneropedia'>\n<h4 class='text-center'>" + entry[0] + "</h4>\n"
+              cur_letter = entry[0]
+            end
+            replace += "<a href='/resources/moneropedia/" + link + ".html'>" + entry + "</a><br>\n"
+          end
+          replace += "</div>"
+          content = content.gsub(/(\@moneropedia)/i, replace)          
+        end
+
+        # replace instances of @term with tooltips of the summary
+        @@moneropedia.each do |entry|
+          entry[:terms].each do |term|
+            content = content.gsub(/(\@#{term})\b/i, '<a data-tooltip="' + entry[:summary] + '" href="/resources/moneropedia/' + entry[:file] + '.html" >' + term.gsub('-',' ') + '</a>')
+          end
+        end
+        
+        base_converter(content)
+      end
+    end
+  end
+end
--- a/_plugins/plugin.rb
+++ b/_plugins/plugin.rb
@ -0,0 +1,70 @@
+# Just a placeholder plugin to do translated strings, gives us room and scope to get the
+# jekyll-multiple-languages-plugin to work correctly
+
+module Jekyll
+  module Translated
+    module Strings
+      module Plugin
+        VERSION = "0.1"
+      end
+    end
+  end
+end
+
+module Jekyll
+  class LocalizeTag < Liquid::Tag
+
+    def initialize(tag_name, key, tokens)
+      super
+      @key = key.strip
+    end
+
+    def render(context)
+      if "#{context[@key]}" != "" #Check for page variable
+        key = "#{context[@key]}"
+      else
+        key = @key
+      end
+
+      site = context.registers[:site]
+
+      stringsfile = File.join(site.source, '_strings_en.yml')
+
+      strings_en = YAML.load_file(stringsfile)
+
+      translation = strings_en.access(key) if key.is_a?(String)
+      if translation.nil? || translation.empty?
+        Jekyll.logger.abort_with "Missing key: #{key}"
+      end
+      
+      # If we have an @, pass the string through the markdown converter, so that we hit the Moneropedia plugin
+      if translation.include? '@'
+        converter = site.find_converter_instance(::Jekyll::Converters::Markdown)
+        translation = converter.convert(translation)[3..-6]
+      end
+
+      translation
+    end
+  end
+
+end
+
+unless Hash.method_defined? :access
+  class Hash
+    def access(path)
+      ret = self
+      path.split('.').each do |p|
+        if p.to_i.to_s == p
+          ret = ret[p.to_i]
+        else
+          ret = ret[p.to_s] || ret[p.to_sym]
+        end
+        break unless ret
+      end
+      ret
+    end
+  end
+end
+
+Liquid::Template.register_tag('t', Jekyll::LocalizeTag)
+Liquid::Template.register_tag('translate', Jekyll::LocalizeTag)
--- a/_plugins/sitemap_generator.rb
+++ b/_plugins/sitemap_generator.rb
@ -0,0 +1,274 @@
+# Sitemap.xml Generator is a Jekyll plugin that generates a sitemap.xml file by 
+# traversing all of the available posts and pages.
+# 
+# See readme file for documenation
+# 
+# Updated to use config file for settings by Daniel Groves
+# Site: http://danielgroves.net
+# 
+# Author: Michael Levin
+# Site: http://www.kinnetica.com
+# Distributed Under A Creative Commons License
+#   - http://creativecommons.org/licenses/by/3.0/
+require 'jekyll/document'
+require 'rexml/document'
+
+module Jekyll
+
+  class Jekyll::Document
+    attr_accessor :name
+
+    def path_to_source
+      File.join(*[@name].compact)
+    end
+
+    def location_on_server(my_url)
+      "#{my_url}#{url}"
+    end
+  end
+
+  class Page
+    attr_accessor :name
+
+    def path_to_source
+      File.join(*[@dir, @name].compact)
+    end
+
+    def location_on_server(my_url)
+      location = "#{my_url}#{url}"
+      location.gsub(/index.html$/, "")
+    end
+  end
+
+  # Recover from strange exception when starting server without --auto
+  class SitemapFile < StaticFile
+    def write(dest)
+      true
+    end
+  end
+
+  class SitemapGenerator < Generator
+    priority :lowest
+
+    # Config defaults
+    SITEMAP_FILE_NAME = "/sitemap.xml"
+    EXCLUDE = ["/atom.xml", "/feed.xml", "/feed/index.xml"]
+    INCLUDE_POSTS = ["/index.html"] 
+    CHANGE_FREQUENCY_NAME = "change_frequency"
+    PRIORITY_NAME = "priority"
+    
+    # Valid values allowed by sitemap.xml spec for change frequencies
+    VALID_CHANGE_FREQUENCY_VALUES = ["always", "hourly", "daily", "weekly",
+      "monthly", "yearly", "never"] 
+
+    # Goes through pages and posts and generates sitemap.xml file
+    #
+    # Returns nothing
+    def generate(site)
+      # Configuration
+      sitemap_config = site.config['sitemap'] || {}
+      @config = {}
+      @config['filename'] = sitemap_config['filename'] || SITEMAP_FILE_NAME
+      @config['change_frequency_name'] = sitemap_config['change_frequency_name'] || CHANGE_FREQUENCY_NAME
+      @config['priority_name'] = sitemap_config['priority_name'] || PRIORITY_NAME
+      @config['exclude'] = sitemap_config['exclude'] || EXCLUDE
+      @config['include_posts'] = sitemap_config['include_posts'] || INCLUDE_POSTS
+
+      sitemap = REXML::Document.new << REXML::XMLDecl.new("1.0", "UTF-8")
+
+      urlset = REXML::Element.new "urlset"
+      urlset.add_attribute("xmlns", 
+        "http://www.sitemaps.org/schemas/sitemap/0.9")
+
+      @last_modified_post_date = fill_posts(site, urlset)
+      fill_pages(site, urlset)
+
+      sitemap.add_element(urlset)
+
+      # Create destination directory if it doesn't exist yet. Otherwise, we cannot write our file there.
+      Dir::mkdir(site.dest) if !File.directory? site.dest
+
+      # File I/O: create sitemap.xml file and write out pretty-printed XML
+      filename = @config['filename']
+      file = File.new(File.join(site.dest, filename), "w")
+      formatter = REXML::Formatters::Pretty.new(4)
+      formatter.compact = true
+      formatter.write(sitemap, file)
+      file.close
+
+      # Keep the sitemap.xml file from being cleaned by Jekyll
+      site.static_files << Jekyll::SitemapFile.new(site, site.dest, "/", filename)
+    end
+
+    # Create url elements for all the posts and find the date of the latest one
+    #
+    # Returns last_modified_date of latest post
+    def fill_posts(site, urlset)
+
+      last_modified_date = nil
+      site.collections["posts"].docs.each do |post|
+        if !excluded?(site, post.name)
+          url = fill_url(site, post)
+          urlset.add_element(url)
+        end
+
+        date = File.mtime(post.path)
+        last_modified_date = date if last_modified_date == nil or date > last_modified_date
+      end
+
+      last_modified_date
+    end
+
+    # Create url elements for all the normal pages and find the date of the
+    # index to use with the pagination pages
+    #
+    # Returns last_modified_date of index page
+    def fill_pages(site, urlset)
+      site.pages.each do |page|
+        if !excluded?(site, page.path_to_source)
+          if File.exists?(page.path)
+            url = fill_url(site, page)
+            urlset.add_element(url)
+          end
+        end
+      end
+    end
+
+    # Fill data of each URL element: location, last modified,
+    # change frequency (optional), and priority.
+    #
+    # Returns url REXML::Element
+    def fill_url(site, page_or_post)
+      url = REXML::Element.new "url"
+
+      loc = fill_location(site, page_or_post)
+      url.add_element(loc)
+
+      lastmod = fill_last_modified(site, page_or_post)
+      url.add_element(lastmod) if lastmod
+
+
+
+      if (page_or_post.data[@config['change_frequency_name']])
+        change_frequency = 
+          page_or_post.data[@config['change_frequency_name']].downcase
+          
+        if (valid_change_frequency?(change_frequency))
+          changefreq = REXML::Element.new "changefreq"
+          changefreq.text = change_frequency
+          url.add_element(changefreq)
+        else
+          puts "ERROR: Invalid Change Frequency In #{page_or_post.name}"
+        end
+      end
+
+      if (page_or_post.data[@config['priority_name']])
+        priority_value = page_or_post.data[@config['priority_name']]
+        if valid_priority?(priority_value)
+          priority = REXML::Element.new "priority"
+          priority.text = page_or_post.data[@config['priority_name']]
+          url.add_element(priority)
+        else
+          puts "ERROR: Invalid Priority In #{page_or_post.name}"
+        end
+      end
+
+      url
+    end
+
+    # Get URL location of page or post 
+    #
+    # Returns the location of the page or post
+    def fill_location(site, page_or_post)
+      loc = REXML::Element.new "loc"
+      url = site.config['url'] + site.config['baseurl']
+      loc.text = page_or_post.location_on_server(url)
+
+      loc
+    end
+
+    # Fill lastmod XML element with the last modified date for the page or post.
+    #
+    # Returns lastmod REXML::Element or nil
+    def fill_last_modified(site, page_or_post)
+      lastmod = REXML::Element.new "lastmod"
+      date = File.mtime(page_or_post.path)
+      latest_date = find_latest_date(date, site, page_or_post)
+
+      if @last_modified_post_date == nil
+        # This is a post
+        lastmod.text = latest_date.iso8601
+      else
+        # This is a page
+        if posts_included?(site, page_or_post.path_to_source)
+          # We want to take into account the last post date
+          final_date = greater_date(latest_date, @last_modified_post_date)
+          lastmod.text = final_date.iso8601
+        else
+          lastmod.text = latest_date.iso8601
+        end
+      end
+      lastmod
+    end
+
+    # Go through the page/post and any implemented layouts and get the latest
+    # modified date
+    #
+    # Returns formatted output of latest date of page/post and any used layouts
+    def find_latest_date(latest_date, site, page_or_post)
+      layouts = site.layouts
+      layout = layouts[page_or_post.data["layout"]]
+      while layout
+        date = File.mtime(layout.path)
+
+        latest_date = date if (date > latest_date)
+
+        layout = layouts[layout.data["layout"]]
+      end
+
+      latest_date
+    end
+
+    # Which of the two dates is later
+    #
+    # Returns latest of two dates
+    def greater_date(date1, date2)
+      if (date1 >= date2) 
+        date1
+      else 
+        date2 
+      end
+    end
+
+    # Is the page or post listed as something we want to exclude?
+    #
+    # Returns boolean
+    def excluded?(site, name)
+      @config['exclude'].include? name
+    end
+
+    def posts_included?(site, name)
+      @config['include_posts'].include? name
+    end
+
+    # Is the change frequency value provided valid according to the spec
+    #
+    # Returns boolean
+    def valid_change_frequency?(change_frequency)
+      VALID_CHANGE_FREQUENCY_VALUES.include? change_frequency
+    end
+
+    # Is the priority value provided valid according to the spec
+    #
+    # Returns boolean
+    def valid_priority?(priority)
+      begin
+        priority_val = Float(priority)
+        return true if priority_val >= 0.0 and priority_val <= 1.0
+      rescue ArgumentError
+      end
+
+      false
+    end
+  end
+end
--- a/_posts/00-base-00
+++ b/_posts/00-base-00
@ -0,0 +1,9 @@
+---
+layout: post
+title: Monero Missive for the Week of 
+summary: 
+tags: [monero missives, ]
+author: Riccardo Spagni (fluffypony)
+forum: 
+---
+
--- a/_posts/2014-06-02-dev-diary-for-the-week-of-2014-06-02.md
+++ b/_posts/2014-06-02-dev-diary-for-the-week-of-2014-06-02.md
@ -0,0 +1,23 @@
+---
+layout: post
+title: Dev Diary for the Week of 2014-06-02
+summary: Block reward penalty adjustment, faster CPU miner, missing RPC calls added
+tags: [dev diaries, mining, i2p, rpc, crypto]
+author: Riccardo Spagni (fluffypony)
+---
+
+*June 2nd, 2014*
+
+**RPC:** Neozaru and others have submitted pull requests to add RPC methods that were missing.
+
+**I2P:** libssu has been decoupled, and outstanding changes to master have been merged.
+
+**Core:** just a reminder that there are breaking changes to 0.8.8 to prevent a transaction dust attack on the block reward. Because of the block reward penalty, it was previously possible to constantly reduce the block reward down to nearly zero, which is what has been fixed. You can see this quite dramatically on the [Block Reward chart on monerochain.info](http://monerochain.info/charts/reward) where our average block reward plummeted by around 13% on May 25 - 27 as the fix was tested, deployed, and miners began adopting it. Please don't forget that simplewallet using the older code will not add the correct transaction fees, causing transactions to sit in the mempool for several days before being rejected.
+
+**Core:** initial work has begun on documenting the code and on providing architecture overviews. This will be a relatively lengthy project, but will provide us with a more useful codebase that has had more eyes on it.
+
+**Crypto:** we have also begun an initial foray into examining the underlying cryptographic and mathematic principles of the CryptoNote protocol, and ensuring that it has been correctly implemented in the reference code (Bytecoin - upon which Monero is based). We will reveal more details as this project progresses.
+
+**Crypto:** DGA has done an incredible job of optimising the PoW hashing code, and has vastly improved the speed at which it operates. This makes syncing the blockchain faster, as well as improves the speed at which miners can run and pools can verify work.
+
+**Mining:** Wolf has worked hard on optimising and tweaking LucasJones miner. If you are mining, it is strongly suggested you give [Wolf's fork of cpuminer-multi](https://github.com/wolf9466/cpuminer-multi) a spin. Because it takes advantage of AES-NI you may find that reducing the number of threads down to around half of the number of cores in your computer is the most efficient.
--- a/_posts/2014-06-02-monero-missive-for-the-week-of-2014-06-02.md
+++ b/_posts/2014-06-02-monero-missive-for-the-week-of-2014-06-02.md
@ -0,0 +1,30 @@
+---
+layout: post
+title: Monero Missive for the Week of 2014-06-02
+summary: Our first Missive! New logo, pool software completed and bounty awarded, ticker symbol changed to XMR
+tags: [monero missives, branding, mining, compliance]
+author: Riccardo Spagni (fluffypony)
+---
+
+*June 2nd, 2014*
+
+This is the start of a slightly more formal way of keeping everyone updated as to what we're doing in Monero. On an ongoing weekly basis we'll post an update on what has happened over the past week, as well as a dev diary highlighting work done on major efforts. If you'd like to get involved with Monero don't ask for permission - just get stuck in:) Fork the repo, make changes, submit a pull-request, and let's discuss it.
+
+Also an important note on updates: Our policy is to only provide announcements on projects which are either complete or near completion. We'd like to focus on providing you with the most accurate and reliable news, without generating any type of investor hype or speculation. As Monero is still a project in its infancy, and there is a great deal of work still to be done, we want to make sure you are getting an honest overview of our ongoing progress.
+
+**Major Updates**
+
+1. The big one...we have a logo! If you use Monero in any of your projects, [you can grab a branding pack here](http://downloads.getmonero.org/resources/branding.zip). You can also see it in all its glory right here:  
+![logo](http://downloads.getmonero.org/resources/logo-200.jpg){: .center-image }
+
+2. With our logo completed, we are going to be moving forward on a major overhaul and redesign of our website. We are also in the process of architecting and designing a better repository of information - which includes a forum-style that allows for both discussion, as well an open-source, crowd-funded development incubator. We will be keeping you updated on our progress in the coming weeks. In the meantime, the best place for threaded discussions are the [/r/monero subreddit](http://www.reddit.com/r/monero), and for live discussions join us on Freenode: #monero for general chat, #monero-dev for development efforts, and #monero-otc for price talk and over-the-counter trades.
+
+3. The pool bounty has now closed, and was awarded to zone117x and LucasJones for their excellent work on the Node CryptoNote pool. You can see the results of their hard work on [their github repo here](https://github.com/zone117x/node-cryptonote-pool) or, you know, just use pretty much any of the Monero mining pools:)
+
+4. In order to maintain ISO 4217 compliance, we are changing our ticker symbol from MRO to XMR effective immediately. This change primarily effects exchanges at this early stage, as we are sure that MRO will continue to be used colloquially and in general discussion. We are aware that this may cause a little confusion, but we feel it necessary to make this change early on rather than later when Monero is more widely spread.
+
+We'd also like to take the time to introduce you to our core team (in no particular order) - tacotime, eizh, smooth, fluffypony, othe, davidlatapie, NoodleDoodle
+
+Many others are involved in peripheral and related projects, including: zone117x, Neozaru, LucasJones, Wolf, Quanttek, and so many others
+
+Thank you for your hard work if you have been involved in Monero already, and we look forward to continuing to innovate as keep Monero the most secure, private, untraceable cryptocurrency!
--- a/_posts/2014-06-10-dev-diary-for-the-week-of-2014-06-10.md
+++ b/_posts/2014-06-10-dev-diary-for-the-week-of-2014-06-10.md
@ -0,0 +1,21 @@
+---
+layout: post
+title: Dev Diary for the Week of 2014-06-10
+summary: New RPC calls, GPU miner launched, Doxygen code comments started
+tags: [dev diaries, mining, i2p, rpc, docs]
+author: Riccardo Spagni (fluffypony)
+---
+
+*June 10th, 2014*
+
+**RPC:** incoming_transfers is now available as a simplewallet RPC API call, and payment_id has been added as an optional argument to the transfer RPC API call. Neozaru also committed a large amount of additional functionality to the RPC API, including progress estimation to getinfo.
+
+**I2P:** no commits this week, much of the work has been around scoping and planning the RPC subsystem.
+
+**Core:** new seed nodes have been added, so bootstrapping on cold start should work just fine. We are going to add DNS seed node bootstrapping at a later stage.
+
+**Docs:** work has begun on adding Doxygen comments throughout the code. This will both help us to understand the code written by "The CryptoNote Developers" (who appear at the top of every piece of source code except for the epee library), but will also result in proper developer documentation being made available.
+
+**Mining:** Wolf` has continued to improve his CPU miner - the latest copy of which can be found on [his github repo](https://github.com/wolf9466/cpuminer-multi).
+
+**Mining:** Claymore released a CryptoNight GPU miner, which [you can find at this thread](https://bitcointalk.org/index.php?topic=638915.0). Please be advised that his miner is currently closed source, and the appropriate level of caution should be exercised.
--- a/_posts/2014-06-10-monero-missive-for-the-week-of-2014-06-10.md
+++ b/_posts/2014-06-10-monero-missive-for-the-week-of-2014-06-10.md
@ -0,0 +1,33 @@
+---
+layout: post
+title: Monero Missive for the Week of 2014-06-10
+summary: Deterministic wallets based on mnemonic seeds, fluffypony to attend the Bitcoin Supernode Conference
+tags: [monero missives, conferences, exchanges, gui, usability]
+author: Riccardo Spagni (fluffypony)
+---
+
+*June 10th, 2014*
+
+Hello XMR users! Welcome to our second Monero Missives.
+
+**Major Updates**
+
+1. We're happy to introduce a major new feature for Monero: deterministic wallets based on a mnemonic seed! When creating a new wallet you now get a 24 word seed that you can use to restore the wallet:  
+![mnemonic screenshot](http://i.imgur.com/Qk90Rp2.png){: .center-image }  
+  Usage: This affects simplewallet, and is the default behaviour for --generate-new-wallet. If you would like to disable the deterministic seed during wallet generation, you can pass the --non-deterministic flag. To restore from a seed you can use the --restore-deterministic-wallet flag.  
+  This provides a MAJOR benefit in that backing up your wallet *no longer requires backing up the .bin.keys file*! All you have to do is write down the 24 words and that's the only backup you need. If you're particularly brave you can even memorise the 24 words. You can also use this to create an offline cold wallet or a paper wallet: create a wallet on a computer disconnected from the Internet, write the 24 words and the address and the view key down, and then remove all the files created by the wallet.  
+  Security notes: Please note that this key is independent of your password. By default the 24 word key is written to simplewallet.log when the wallet is created. This is the expected behaviour, the next release will both exclude this from the log and reduce the default log level. Please run --generate-new-wallet with the --set_log 0 flag, or alternatively make sure to delete the simplewallet.log file afterwards.  
+  Technical details: The key length for this remains 256-bits and thus does not compromise user security. The view key seed is generated from a keccak1600 hash of the spend key (which is directly from the mnemonic seed), hence the deterministic nature of this. The non-deterministic method is still available as an option.  
+  How to get it: binaries in the OP have already been updated, or you can compile from the source on github.  
+  Moving to a deterministic wallet: unfortunately it's not possible to retroactively make an existing wallet deterministic. If you want to take advantage of the new feature, you will have to create a new wallet and move your funds in there.
+
+2. XMR is now on Mintpal for voting. You can find the voting link here: https://www.mintpal.com/voting#XMR - Mintpal allows 1 vote an hour from registered users who have traded before, as well as paid-for votes.
+
+3. Monero will be officially represented by fluffypony at the Bitcoin Supernode Conference at Malla Castle in Estonia at the end of this month.
+
+4. Neozaru has made great strides in his RPC-based Qt GUI wallet, and it requires some testing. If you are keen on trying it out, head over [to his comment the GUI thread](https://bitcointalk.org/index.php?topic=589561.msg7240186#msg7240186), give it a spin, and give him feedback.
+
+
+Until next week!
+
+PS. If you've made it this far, there's a reward in the example wallet listed in the screenshot - first to grab it gets the prize!
--- a/_posts/2014-06-18-dev-diary-for-the-week-of-2014-06-16.md
+++ b/_posts/2014-06-18-dev-diary-for-the-week-of-2014-06-16.md
@ -0,0 +1,17 @@
+---
+layout: post
+title: Dev Diary for the Week of 2014-06-16
+summary: New checkpoint, better mempool handling from BBR, Arch Linux support
+tags: [dev diaries, usability, platforms, accounts, core]
+author: Riccardo Spagni (fluffypony)
+---
+
+*June 18th, 2014*
+
+**Core:** Checkpoint added at block 80 000
+
+**Core:** We've incorporated two changes from BBR - proper tx_pool handling, and a fix for the high number of orphans pool miners were experiencing. tx_pool handling is incomplete, as it is implemented by the daemon but the wallet is not, as yet, mempool aware.
+
+**Core:** Initial tx auto-split commit, ready for testing
+
+**Build:** Made changes to CMakeLists to allow for the project to build on Arch
--- a/_posts/2014-06-18-monero-missive-for-the-week-of-2014-06-16.md
+++ b/_posts/2014-06-18-monero-missive-for-the-week-of-2014-06-16.md
@ -0,0 +1,29 @@
+---
+layout: post
+title: Monero Missive for the Week of 2014-06-16
+summary: Monero number 1 on the MintPal voting list, whitepaper annotations released and peer review started, initial transaction splitting test
+tags: [monero missives, exchanges, research, usability, gui]
+author: Riccardo Spagni (fluffypony)
+---
+
+*June 18th, 2014*
+
+Hello, and welcome to our third Monero Missive.
+
+**Major Updates**
+
+1. We've been stalling this week's Missive on purpose, because we were hoping it would happen...and it happened! We got to number 1 on the MintPal voting list in a week - which is quite an achievement. There was quite a stack of paid-for votes (more than normal for a cryptocurrency on the MintPal voting list), which is surprising, but it definitely helped catapult us up front.  
+An [interesting graph on CryptVote](http://cryptvote.com) shows the meteoric climb (XMR is the blue line):  
+![](http://i.imgur.com/GfQ67Tz.jpg){: .center-image }
+
+2. We are immensely grateful for the work the CryptoNote developers have put into the protocol, but their whitepaper is unfortunately lacking in peer reviews. To that end, we have taken it upon ourselves to peer review the whitepaper, and to release the peer review as an annotated whitepaper.  
+The two primary peer reviewers are not part of the Monero core team, and are highly qualified academics in the fields of mathematics and cryptography. They are assisted by some of the Monero core team who have a similar computer science academic background. Due to the nature of the Monero project both of the primary peer reviewers have chosen to work under a pseudonym. In a later missive we'll introduce them more formally, but for the moment we wanted to release the current copy of the annotated whitepaper for everyone to take a look at. If you'd like to provide your input on the annotations, please feel free to email any comments to dev@getmonero.org  
+The latest annotated whitepaper can be downloaded here: http://downloads.getmonero.org/whitepaper_annotated.pdf. Please bear in mind that it is only up to page 8 in the CryptoNote whitepaper at present, so the annotation does cut short there:)
+
+3. We have completed initial work and testing on transaction auto-splitting (thanks to tewinget's tireless work). Now, if you have too many inputs for your transaction, simplewallet will automatically try to split your transfer up to as many as 30 transactions. It will prompt you first and let you know the total fees before just sending it, of course:  
+![](http://i.imgur.com/IyG3Uq0.jpg){: .center-image }  
+This feature requires more testing, and is NOT in the main code base yet. If you're able to build Monero, please grab it from fluffypony's repo here, and build and test: https://github.com/fluffypony/bitmonero - you won't need to build tests or change the daemon, it's just simplewallet's operation that has changed. Please do not try this with the RPC API yet, this needs the CLI at the moment.
+
+4. We have had a lot of people asking about the progress of the GUI wallet. We'd like to reiterate that there are a great number of core and fundamental things that need to be worked on *before* we can get lots and lots of users flocking in. Some of the core necessities that we're working on at breakneck pace are: QoS to reduce the bandwidth demand on full nodes (as everyone will be running a full node at this stage anyway), segregation of wallet functions in order to create a far more robust system for exchanges and merchants to use, [Gitian-based builds](http://gitian.org) for everyone's safety and to ensure binaries are safe (safer, really), moving blockchain storage to an embedded database, fixing the now-infamous "ABSTRACT_SERVER_SEND_QUE_MAX_COUNT" (in big red letters!) error that is quite harmless but everyone freaks out about, and so on.
+
+   These are issues at Monero's core that we're working on, and we need to have these in place and fixed before a GUI wallet is widely dispersed, otherwise there will be massive resource constraints placed on user's systems. We're not here to win a race against other cryptocurrencies. We're here to to continue to push out great features and stable and reliable code, in a way that will make sure Monero is around for decades and not just a flash-in-the-pan.
--- a/_posts/2014-07-06-dev-diary-for-the-week-of-2014-06-30.md
+++ b/_posts/2014-07-06-dev-diary-for-the-week-of-2014-06-30.md
@ -0,0 +1,13 @@
+---
+layout: post
+title: Dev Diary for the Week of 2014-06-30
+summary: Daemonize and rpcwallet both ready for testing
+tags: [dev diaries, core, accounts]
+author: Riccardo Spagni (fluffypony)
+---
+
+*July 6th, 2014*
+
+**Core:** daemonizing changes are ready for testing: https://github.com/mikezackles/bitmonero/tree/daemonize
+
+**Core:** rpcwallet is ready for testing: https://github.com/tewinget/bitmonero/tree/rpcwallet
--- a/_posts/2014-07-06-monero-missive-for-the-week-of-2014-06-30.md
+++ b/_posts/2014-07-06-monero-missive-for-the-week-of-2014-06-30.md
@ -0,0 +1,25 @@
+---
+layout: post
+title: Monero Missive for the Week of 2014-06-30
+summary: CryptoNote whitepaper review moving to the code, transaction auto-splitting added to master
+tags: [monero missives, research, usability, accounts, gui, conferences]
+author: Riccardo Spagni (fluffypony)
+---
+
+*July 6th, 2014*
+
+Hello, and welcome to our fifth Monero Missive!
+
+**Major Updates**
+
+1. fluffypony had a great time discussing Monero at the Bitcoin Supernode Conference in Estonia. Many thanks to rpietila for hosting him and all attendees.
+
+2. Work on the academic peer review of the CryptoNote whitepaper is slowly starting to move away from an academic platform and on to the code itself, to determine whether the reference implementation correctly implements the whitepaper. Before that happens, though, a summary of the initial findings will be published. We are expecting this to be completed this coming week.
+
+3. Transaction auto-splitting is now in the main codebase. To explain our methodology: the main github repo will always be "active development", and may contain code that will be reverted or is not fully tested. For those that are brave and want to test and contribute to development, it is the ideal starting point. However, on an ongoing basis we are going to create tagged releases, whereby when a group of new features have been fully tested, a new release can be tagged, and binaries can be put out (along with the code on the github tag, of course). Expect this change to start taking effect within the next 4 weeks.
+
+4. We'd like to apologise for not finalise the GUI bounty - everyone has been a little scattered this week. We will resolve this in its entirety within the next 48 hours!
+
+This Missive is a little light on major updates (well, we can't have something major every week;) primarily because there has been lots of plotting and planning this week. As always: you can keep up to date with the nitty-gritty on IRC in #monero-dev on Freenode if you're interested.
+
+Until next week!
--- a/_posts/2014-07-13-dev-diary-for-the-week-of-2014-07-07.md
+++ b/_posts/2014-07-13-dev-diary-for-the-week-of-2014-07-07.md
@ -0,0 +1,17 @@
+---
+layout: post
+title: Dev Diary for the Week of 2014-07-07
+summary: Work has begun on moving to an embedded database, good progress on daemonize, moving focus from i2pcpp to i2pd
+tags: [dev diaries, core, accounts, i2p, i8n, blockchaindb]
+author: Riccardo Spagni (fluffypony)
+---
+
+*July 13th, 2014*
+
+**Core**: major work has begun on moving to an embedded database. The ongoing progress on this can be followed here: https://github.com/tewinget/bitmonero/tree/blockchain
+
+**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.
--- a/_posts/2014-07-13-monero-missive-for-the-week-of-2014-07-07.md
+++ b/_posts/2014-07-13-monero-missive-for-the-week-of-2014-07-07.md
@ -0,0 +1,25 @@
+---
+layout: post
+title: Monero Missive for the Week of 2014-07-07
+summary: GUI bounty finalised and paid, a note on donations, mnemonic multilang wordlists started
+tags: [monero missives, research, usability, external, funding, i8n]
+author: Riccardo Spagni (fluffypony)
+---
+
+*July 13th, 2014*
+
+Hello, and welcome to our sixth Monero Missive!
+
+**Major Updates**
+
+1. The GUI bounty is completed and all payouts have been made. You can view the [confirmation of payouts in this post](https://bitcointalk.org/index.php?topic=589561.msg7833251#msg7833251), 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:  
+- neozaru's wallet: https://github.com/Neozaru/bitmonero-qt  
+- Jojatekok's Monero Client .NET: https://github.com/Jojatekok/monero-client / https://bitcointalk.org/index.php?topic=683365.0
+
+2. 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.
+
+3. 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
+
+4. 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).
+
+Until next week!
--- a/_posts/2014-12-15-dev-diary-for-the-week-of-2014-12-15.md
+++ b/_posts/2014-12-15-dev-diary-for-the-week-of-2014-12-15.md
@ -0,0 +1,16 @@
+---
+layout: post
+title: Dev Diaries for the Week of 2014-12-15
+summary: Restore paths for mnemonics fixed, libunbound lookups moved to its own thread
+tags: [dev diaries, core, accounts]
+author: Riccardo Spagni (fluffypony)
+forum: https://forum.getmonero.org/1/news-and-announcements/115/monday-monero-missives-21-december-15th-2014
+---
+
+*December 15th, 2014*
+
+**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
+
+Until next week!
--- a/_posts/2014-12-15-external-projects-for-the-week-of-2014-12-15.md
+++ b/_posts/2014-12-15-external-projects-for-the-week-of-2014-12-15.md
@ -0,0 +1,16 @@
+---
+layout: post
+title: External Projects for the Week of 2014-12-15
+summary: MyMonero side-swiped in a DDoS attack on their data center, i2pd added su3 router update support
+tags: [external, mymonero, i2p, forkguard]
+author: Riccardo Spagni (fluffypony)
+forum: https://forum.getmonero.org/1/news-and-announcements/115/monday-monero-missives-21-december-15th-2014
+---
+
+*December 15th, 2014*
+
+**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
--- a/_posts/2014-12-15-monero-missive-for-the-week-of-2014-12-15.md
+++ b/_posts/2014-12-15-monero-missive-for-the-week-of-2014-12-15.md
@ -0,0 +1,20 @@
+---
+layout: post
+title: Monero Missive for the Week of 2014-12-15
+summary: DNS timeouts causing slow startups fixed, multi-language mnemonic bugs fixed
+tags: [monero missives, accounts, core]
+author: Riccardo Spagni (fluffypony)
+forum: 
+---
+
+*December 15th, 2014*
+
+Hello, and welcome to our twenty-first Monero Monday Missive!
+
+**Major Updates**
+
+1. 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
+
+2. There have been a number of patches merged over the past week to fix issues with simplewallet's new multi-language mnemonics
+
+Until next week!
--- a/_posts/2015-01-05-monero-missive-2014-year-in-review.md
+++ b/_posts/2015-01-05-monero-missive-2014-year-in-review.md
@ -0,0 +1,237 @@
+---
+layout: post
+title: Monero Missive Special Edition - 2014 Year in Review 
+summary: A review of everything Monero accomplished from its inception through to the end of 2014
+tags: [monero missives, year in review, core, funding, accounts, usability, platforms, gui, exchanges, i2p]
+author: Riccardo Spagni (fluffypony)
+forum: https://forum.getmonero.org/1/news-and-announcements/134/monday-monero-missives-22-year-in-review-january-5th-2015
+---
+
+*January 5th, 2015*
+
+Hello, and welcome to our twenty-second Monero Monday Missive!
+
+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:
+
+![Infographic](/blog/assets/2014-year-in-review/overview.jpg)
+
+*Core Development*
+
+Well, let's start by excluding a lot of development done in branches on forks, and focusing on the master branch of the git repo. We inherited the Monero project pretty much from the end of April, with [thankful_for_today's last commit on April 30th, 2014](https://github.com/monero-project/bitmonero/commit/e940386f9a8765423ab3dd9e3aabe19a68cba9f9).
+
+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
+- more hashing optimisations, including AES-NI support
+- new wallet RPC commands: save_bc, getaddress; new daemon RPC commands: mining_status
+- enabled checkpointing and checkpoint verification
+- fixed the block reward penalty mechanism and dynamic block sizing
+- new wallet RPC commands: incoming_transfers
+- fixed exit flags, added --exit-after-cmd simplewallet flag
+
+June:
+
+- added payment IDs to simplewallet's 'transfer' RPC command
+- added Doxyfile for code documentation
+- refactored parts of simplewallet
+- added Electrum-style mnemonics to simplewallet
+- got Monero building and running on Arch Linux
+- further improvements to hashing algorithm, including huge pages and AES-NI key expansion
+- added tx auto-splitting and changed transaction creation semantics internally
+
+July:
+
+- new wallet RPC command: get_bulk_payments; new daemon RPC command: get_connections
+- new README, license changes to BSD 3-clause
+
+August:
+
+- optional height parameter for simplewallet refresh
+- fixed wallet restore from seed
+- new wallet RPC command: query_key; new wallet commands: seed, viewkey
+- stopped a major spam attack dead in its tracks
+- highly sophisticated attack causes the network to fork for 30 minutes, urgently and immediately patched
+
+September:
+
+- blob checkpointing added (over and above normal block hash checkpointing)
+- got Monero building and running on FreeBSD
+- major documentation of several C classes
+- new versioning system to allow for rapid identification of build commit
+- started enforcing GPG signed commits and merges, initial GPG keys added
+- testnet launched
+- 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*
+
+The Monero web infrastructure consists of 4 key components: web hosting, testing infrastructure, seeding, and download hosting.
+
+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.
+
+Seeding infrastructure consists of several geographically separated boxes that keep the moneroseeds.se/ae.org/ch/li records updated with active seed nodes.
+
+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](http://en.wikipedia.org/wiki/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](https://github.com/zone117x/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](https://github.com/PrivacySolutions/i2pd)*
+
+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](http://forkguard.com) and [MoneroClub](https://www.moneroclub.com)*
+
+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](https://mymonero.com)*
+
+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](https://bitcointalk.org/index.php?topic=819073.0)*
+
+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.getmonero.org
+
+Thank you for a great 2014, and here's to a great 2015!
+
+Your Core Team - Riccardo "fluffypony" Spagni, smooth, othe, David Latapie, tacotime, NoodleDoodle, eizh
--- a/_posts/2015-02-23-monero-missive-for-the-week-of-2015-02-23.md
+++ b/_posts/2015-02-23-monero-missive-for-the-week-of-2015-02-23.md
@ -0,0 +1,200 @@
+---
+layout: post
+title: Monero Missive for the Week of 2015-02-23
+summary: New website, moved from monero.cc to getmonero.org, MRL-0004 released, Monero design and development goals published
+tags: [monero missives, research, usability]
+author: Riccardo Spagni (fluffypony)
+forum: https://forum.getmonero.org/1/news-and-announcements/161/monday-monero-missives-23-february-23rd-2015
+---
+
+We are moving to a new Missive format, it is now in the form of a podcast!
+
+<div class="text-center"><iframe style="border: none" src="//html5-player.libsyn.com/embed/episode/id/3381043/height/600/width/600/theme/standard-mini/direction/no/autoplay/no/autonext/no/thumbnail/yes/preload/no/no_addthis/no/" height="600" width="600" scrolling="no"  allowfullscreen webkitallowfullscreen mozallowfullscreen oallowfullscreen msallowfullscreen></iframe></div>
+
+To download the podcast directly please [use this link to the MP3](http://traffic.libsyn.com/monero/Monero_Missives_Podcast_for_the_week_of_2015-02-23.mp3).
+
+A brief summary of the points discussed follows, and a full transcription of the podcast is below.
+
+1. The release of the new website, and the move to [the getmonero.org domain](https://getmonero.org/)
+
+2. The publication of [MRL-0004, Improving Obfuscation in the CryptoNote Protocol](https://lab.getmonero.org/pubs/MRL-0004.pdf)
+
+3. Monero's [design and development goals](http://getmonero.org/design-goals/)
+
+Dev Diaries and External Projects will resume being covered from next week. Until then!
+
+# Podcast Transcription
+
+#### Riccardo "fluffypony" Spagni
+
+Hello and good morning or evening to you wherever you are I am Riccardo, fluffypony, and with me today I have Gingeropolous...say hi!
+
+#### Gingeropolous
+
+Hello everyone!
+
+#### Riccardo
+
+And this is the start of a new type of Monero Missive, because we realized as a core team that preparing a full Monero Missive with all its bits and pieces was taking up a lot of time and soaking up a lot of effort that would have been spent elsewhere. And more importantly we also realized that a lot of people just weren't getting through the content of the Missives that we were putting out, hence this new format.
+
+So, Gingeropolous you are reasonably well known already, why don't you tell us a little bit about you and your involvement in the Monero community.
+
+#### Gingeropolous
+
+Oh sure, I watch the Monero community on the forums and as there was no Missives coming out people were like "hey, why aren't there any Missives," and I was like all right I will go ahead and make a version of them to sort of sum up what I saw happen in the community. So that's where that whole digest came from and I guess that digest caught the eye of the actual core developers, and they contacted me like "hey, do you want to do this podcast?" And I guess my sort of role or function is to bridge the gap between those that actually know what [Jason](https://en.wikipedia.org/wiki/JSON) is doing and those that either don't know what Jason is doing, cause Jason is very popular.
+
+#### Riccardo
+
+Yeah and you've never even met him!
+
+#### Gingeropolous
+
+No I haven't, you know he always calls a lot. His buddy RPC, and API, API is a good guy.
+
+#### Riccardo
+
+So you're the community liaison let's call it that. So today were going to forego the normal bits that we do at the end of the Missive, we're going to skip the Dev Diary and skip External Projects, because there are 3 major things we need to talk about. Now for our listeners who are not English-speaking and may struggle to understand this, we are asking the community in their own time when they get a chance to transcribe some of the podcast content into written form so that it can be understood better and eventually translated. But obviously that's not high priority, and at your earliest convenience if you have some time and feel like transcribing it the first one out the gate is always a winner. 
+
+So what we'd like to concentrate on are 3 things and the first thing were going to talk about is the new website which has only been like a year in production. There's been a great deal of effort that we've put into this and as everyone knows we started with a design that we built quite early on which is been available in the forum for quite some time. But one of the things we wanted to do is really create a website that was accessible not just a hard-core Monero fans or existing users, but to new people that wanted to know what is Monero; what does it do; how can I use it; how can I do simple things...how can I accept payments with Monero; how can I use Monero; how can I run a @node...once I eventually understand what a node is. And so we created this website, and along with the creation of the website we also felt it prudent to move away from the monero.cc domain, which has served us well, but it's time for us to move to something that is a little better suited. So we are moving to getmonero.org which has a long-standing tradition in open source community, Firefox when it first launched also didn't have firefox.org, and so they ran with getfirefox.org for very long time before they eventually started to get other domains that were donated to them. So it's the same with this: the monero.cc domain will forward to getmonero.org, so nothing will change if you have old links or subdomains that are on monero.cc, carry on using them, it will automatically forward you through.
+
+#### Gingeropolous
+
+Fantastic
+
+#### Riccardo
+
+There are a couple of things that we've done in this website I'd like to just point out. The first thing is where we use terms that are confusing or technical, or perhaps what's the word I'm looking for terms that are unfamiliar to new users...
+
+#### Gingeropolous
+
+Like jargon.
+
+#### Riccardo
+
+Ja jargon, something like @blockchain or @transaction. Transaction has a familiarity to us because we use cryptocurrency, but a transaction like a credit card transaction is very different to a transaction in digital or cryptocurrency terms. So you can't, we can't make assumptions about what people know. So part of this is we've created something called a Moneropedia, which obviously is like Wikipedia but for Monero. There are still a lot of room to grow in terms of content, there's a lot of continent needs to be added, but you'll notice that certain things like even on the front page, those 3 green blocks that explain the secure, private, and untraceable nature of Monero, you'll notice that there are some words that have got slightly darker text, and when you hover over them or if you're on a mobile device when you tap on them it actually gives you little summary of that term. So hover over "@consensus" or "@accounts" or "@mnemonic-seed" or "@blockchain" or "@transactions", it explains the term to you. So we are trying to create something that is accessible and that people don't get overwhelmed with tons of information.
+
+We've created a lot of content especially in the getting started section that's pretty much done, which means that people who would want to accept Monero payments, either by hand or programmatically, there is plenty of information there. And in the knowledge base there is still a lot of stuff we are working on in terms of content, but Moneropedia we've already started filling in a lot of that. And the [source code for the website is in a Github repository](https://github.com/monero-project/monero-site) so you can take a look at it, you can look at the way everything is put together. It's all Markdown, processed through a system called Jekyll, which is what Github pages uses. So you can take a look at the existing Moneropedia entries, and you can take a look at the Moneropedia entry for account and see how we structured everything in the Markdown. And if you want to contribute content, by adding entries or correcting mistakes we've made, please, please do so.
+
+#### Gingeropolous
+
+So there's a way for the community to contribute to this, that's awesome.
+
+#### Riccardo
+
+Exactly, so along with that there's also we haven't forgotten about internationalization, you notice that when we hit the website for the first time you have to choose a language and at the moment the only language is English. And the reason that we haven't bolted another language just yet is we want to first flesh out the English content, and everything is pretty much ready for us to start adding other languages, but we just want to get English sorted of first and then we will do a call for translations, and will have strings up on Transifex so that people can translate.
+
+So on the monero-project Github there is a [monero-site](https://github.com/monero-project/monero-site) repository, and if you notice any issues, if you notice dead links or anything like that, you can open an issue on Github. If there's anything you want to change or add or whatever, then you can clone the repository and fix it on your side and then submit a pull request, which is the same way we work with all of the other projects.
+
+So one of the reasons that we went this road instead of going for more traditional wiki where anyone can edit it and so on is because the git, and github by extension, format for dealing with changes is just a lot more geared toward consensus, at least that's what we feel. So, for example, if somebody wanted to make a change to an article in Moneropedia, they would make the change and submitted it as a Pull Request, and then in the comments section the community can back and forward and say "I think this sentence should be done that way," or "you forgot to highlight the word here so it gets flagged and linked to its definition in Moneropedia," and so on. And there can be a general feeling that the change is good or bad. So it just sort of lends itself more towards a community driven project than the one where, like with Wikipedia where it just ends up being refined purely by brute force almost.
+
+Let's go on to [MRL 4](https://lab.getmonero.org/pubs/MRL-0004.pdf)!
+
+#### Gingeropolous
+
+We're done with the website?
+
+#### Riccardo
+
+We're done with the website. So the Monero Research Lab may have seemed quiet for the past few months and that's because [MRL 4](https://lab.getmonero.org/pubs/MRL-0004.pdf) has been quite a hefty thing to put together. Basically it has been an exercise in trying to pick magic numbers which normally ends badly. But as everyone is aware, or should be aware, our very first Monero Research Lab bulletin revealed a weakness in the CryptoNote protocol.
+
+Obviously Monero is very grateful for the effort that CryptoNote put into the initial cryptography, we are taking this further. And one of the key things we are doing is fixing this massive gaping hole in the CryptoNote protocol. So Gingeropolous, you've read [MRL 4](https://lab.getmonero.org/pubs/MRL-0004.pdf), why don't you tell us a little bit about what you understood and what your take aways were.
+
+#### Gingeropolous
+
+Well I did read it a week ago, from what I recall the main sort of meat of [MRL 4](https://lab.getmonero.org/pubs/MRL-0004.pdf) was the whole concept of how anonymous is the actual CryptoNote protocol, and the main thing I think was the take-home was it has to do with the amount of mixins that you put in your transfers. I'm sort of rambling here.
+
+#### Riccardo
+
+You are spot on...there are two different aspects to privacy in Monero and that is the unlinkability and the untraceability of transactions. Now when we say unlinkability we are talking about the dual-key stealth addressing that addresses that component; but untraceability is another thing entirely. So, the untraceability is dealt with by ring signatures. As [MRL 1](https://lab.getmonero.org/pubs/MRL-0001.pdf) pointed out there is a potential compromise, and a cascading compromise, to the ununtraceable nature of CryptoNote transactions.
+
+Just to sort-of explain it quite simply: if I create a bunch of transactions, and in each transaction I have my signature along with your signature...so just by chance I happen to mix with your signature, and it's the same denomination I put every single time. And then in 6 months' time you go and spend that output at a mixin 0. Suddenly what you're effectively doing is you are invalidating all of the times that output was used previously. Which means that all of the transactions where you and I, where I used your signature as a ring signature on it, is suddenly like...well, anybody looking can go "hey, this ring signature is part of an output that was spent, and so therefore the other one must be the correct one." So that revelation becomes dangerous especially when owning a certain number of outputs, and the knowing that you control those outputs leads to a cascade or a snowball.
+
+So what we're really trying to move away from his instead of having "unspent" outputs that we mix with, just having outputs that we mixed with and they should always be unspent; it should be impossible to tell if an output has actually been spent on the blockchain or not.
+
+Now the reason that we might need 0 mix transactions, or mixin 0 transactions, is because traditionally in Monero there is dust. And dust, when you are using it as an input, will never have anything, or will most likely, not have anything it can mix with. So it presented an interesting problem for us and for the rest of the members of the Monero Research Lab. Because not only did we have to devise a scheme that just disallowed mixin 0 transactions, but we also needed to figure out a way to get dust out the system, to maybe do this in a way that dust eventually comes of the system instead of having some sort of magical destroyer of dust go through the blockchain, which is impossible.
+
+So [MRL 4](https://lab.getmonero.org/pubs/MRL-0004.pdf) is something that people can read in their own time, but basically the long and the short of it is that we're going to be moving quite soon to a minimum mixin of 2, and we are going to programmatically lock in that within the next 3 to 5 years that minimum mixing is going to move to 4.
+
+#### Gingeropolous
+
+And by minimum mixin you mean something that is hardcoded into the actual protocol, or is this in the wallet, or payment...?
+
+#### Riccardo
+
+This will be a hardfork, and it will mean that anyone trying to send anything with a mixin of 0 or 1, their transaction is going to be rejected by the network.
+
+#### Gingeropolous
+
+Okay I got you.
+
+#### Riccardo
+
+And obviously any miner that mines a block with mixin 0 transactions, their block is going to be rejected by the network. The one key, or little thing at the end, which is how to deal with dust, is the way it is proposed in [MRL 4](https://lab.getmonero.org/pubs/MRL-0004.pdf), and this is the way were going to be implementing, it is to allow mixin 0 transactions only under a special set of circumstances. So the protocol will allow mixin 0 @transactions if it uses an input that has nothing else it can mix with, so a dust input essentially, and in its' output it does not create new outputs that cannot be mixed with. So the idea is the wallet  software already picks dust up as it creates transactions, and what we might do is try and prioritize that a little bit to try and flush dust out faster. But over time, and I don't think it's going to take too long, but over a period of time there will be a smattering of a mixin 0 transactions that will be taking dust out of the system but not creating new dust, so eventually they'll be no more dust.
+
+#### Gingeropolous
+
+Just so any completely new people to cryptocurrency are wondering, dust is like when you have like 0.0013...a bunch of random numbers out of Monero that you are trying to send, and so it has to break apart your transaction into pieces and that little 0.00-whatever is very unique and it can't mix with anything so that's why the dust is the problem. Did I get that right?
+
+#### Riccardo
+
+That's correct.
+
+So there are a couple other text that are detailed in the paper, things like association by use attacks and so on, and so one of the small things we are going to be adding is every 6 to 8 weeks, if you are using the wallet regularly...every 6 to 8 weeks if there is a certain number of blocks that are being added to the block chain, 6 to 8 weeks' worth since you last received any transfers to your Monero wallet, it is going to flash you a little warning, and it's going to encourage you to send some funds to yourself. Just send it out and back to yourself, which means you are sending it back to yourself as the recipient. And some of the changes like that, it's not hardfork changes, it is just encouraging certain behaviors. It is really just to prevent certain attacks, and the reality is a lot of these attacks are edge cases. Some of them do require a certain level of skill, prowess, money, power, whatever of an attacker, but it is just a really trim down those edge cases so that the risks, the edge case risks, are reduced even more with the Monero.
+
+#### Gingeropolous
+
+And so is there going to be like a recommendation from your wallet software, or just sort of hardcoded in there like "oh you haven't done anything in 2 months...I'm going to send half of your wallet to yourself?"
+
+#### Riccardo
+
+Well one of the reasons that we can't do that is because we can't force people to spend the money in fees, that's the first thing. So we can't have a protocol that's living on the @blockchain or living on @nodes that spends money or spends funds without the user's involvement because they control the fees. Now the nature of things is that not everyone keeps their wallet open all the time even if they are running a @full-node and that node is connected to the network. So it's not really suitable to doing stuff in an automated fashion. It is just something where thre would have to be some cognizance on the user side where they will see the warning and they will go "oh dear, I've got to send out to myself," and on the GUI side maybe we'll add a big fat button that they can just click on and off it goes. And a lot of it is to reduce things like association by usage problems and so on.
+
+And one of the things is age-based association as well, which is something which, quite literally, the Monero Research Lab spend about 3 or 4 weeks discussing at length. Now the age-based association problem is quite simple. If, and I will use Bitcoin is an example, if Satoshi suddenly reappeared and touched some of the early blocks, some of the Bitcoins that were generated in the very early blocks, there would be this mass panic because people would be like "oh...why is he moving his Bitcoin, is a suddenly cashing out?" Now that sort of thing is a product of knowing exactly what happens within that very obvious and transparent @blockchain. Now in Monero there is kind of a similar thing that can happen and it's not quite, I mean the consequences are a little bit different.
+
+Let's say you receive funds today...you received 100 Monero and that's an output that gets created. Now in 20 years' time you haven't touched that, and you suddenly decide to go and spend it. Now there is a temporal association problem because, over time, the 100 Monero has been chosen by, or should be chosen by, people to mix with. And in 20 years' time when you go along and actually spend it, because of the nature of how outputs are chosen to mix with it could be that your spend becomes obvious. Because, for the most part, maybe by virtue of the way outputs are chosen, the distribution of outputs, that statistically that output would not likely be selected for ring signature. And so now there can be an analysis that happens where somebody can say with reasonable certainty that of the signatures in this 100 Monero input in this transaction, they are fairly certain this 20 year old output is used to sign with it is the real one.
+
+So this is something, this age-based association problem, is something that is really tricky to deal with, and is not something that were going to deal with on a protocol level. We are not going to prevent people or force people to mix in a certain way. Instead what we're going to be doing is we are going to be monitoring the way the way outputs are selected of a period of time, and monitoring the distribution. And we're going to sort-of get a feel for it, and get some data, and then we are going to be able to say "okay, based on that we are going to recommend this sort of distribution...Poisson distribution," or whatever it is, in order to reduce the risk of age-based or temporal associations.
+
+So that's something that's not quite as critical as the minimum mixin thing; the minimum mixin thing is really like ground zero for fixing the CryptoNote protocol at its rawest level, and then everything else is bolting on top of that to reduce very low-risk, very edge case issues.
+
+#### Gingeropolous
+
+Gotcha.
+
+#### Riccardo
+
+So that's basically...the long and short of it is that minimum mixin is going to be implemented on a wallet level quite quickly, and the hard fork will be planned and will happen later.
+
+Okay, so we spoke about the new website, we've spoken about [MRL 4](https://lab.getmonero.org/pubs/MRL-0004.pdf), and now we're going to kinda jump back just to something on the website. Now if you are on getmonero.org and you go to the Knowledge Base menu you will see the section called [Design and Development Goals](https://getmonero.org/design-goals). Now design and developing goals is something will be updating from time to time, but of particular interest to people, and of particular interest to us as well because we created it, are really the things that were going to be doing in the future.
+
+Now we are not what to discuss it in this Missive, because otherwise it really would end up being a 4, 5, 6 hour missive, and frankly...who's got the time for that, ain't nobody got time for that! But there's some key things that were going to be doing, and I think what is quite nice, especially on the development side, is it does show the flow to important things like what needs to be done before we get to the GUI, what needs to be done before we get to IPC. That's not to say this is the absolute order of things, it's just to show some of the fundamentals that need to be put in place.
+
+Same with the research goals, there are some fundamentals and need to be put into place, there are some things we are working on, but there's some next-level, next-generation stuff that we think will blow people out of the water and we think will really put Monero in a position where it is eminently useful and usable.
+
+#### Gingeropolous
+
+You mean there's more things that have to happen before the GUI comes out?
+
+#### Riccardo
+
+Yip...there's a lot of stuff that's "almost there", but there are some essential components and...there's a lot of stuff, I'll give you just one example: refactoring everything out into library form so that we have common libraries for Monero @accounts and @wallets, we have a library for the daemon...the connection to the network, we have a library for @consensus, so verifying and checking validity of @transactions and @blocks and @signatures and @ring-signatures, and we also have a library for RPC interfaces.
+
+Having that, and having those library functions and library APIs documented and available, might seem like stuff that we don't need to do to get the GUI out, but it is important because it means that from a QT side we will be able to plug into that library quite easily. And the other up-shot is once we have that done it will open the way to really good third-party implementations, so being able to use those libraries on an iOS or Android wallet means that there's just really cool stuff that can be done without needing to reimplement stuff, you know.
+
+#### Gingeropolous
+
+Well I don't know...when you say refactoring things into libraries I'm sort of...I'm putting together like right now...the Monero code exists as this big old chunk of stuff and re-factoring into libraries means you've got to break it up so you can call things and say "hey...let's do this stuff together!" I don't know.
+
+#### Riccardo
+
+Kind of...I mean, I think that over the next while we will take some time in future Missives, especially when it's been a quieter week, when we can do some of the stuff and talk about why it's necessary, what it does, and why we did it at all. It's not a matter of us being perfectionists, as has being mentioned, or us wanting Monero to be enterprise grade. It's true, we are working very slowly on making Monero incredibly robust and incredibly extensible, but a lot of the stuff it's kind of like...if we don't do it now it's never going to be done or it will be done...maybe...in like 10 years.
+
+So...that's our first Missive podcast: [new website](https://getmonero.org); [MRL 4](https://lab.getmonero.org/pubs/MRL-0004.pdf); [design and development goals](https://getmonero.org/design-goals).
+
+#### Gingeropolous
+
+For those tuning in I think that, at the end of that, the sense was that fluffypony and I will have a lot more to talk about, so stay tuned...tune your dial back to wherever this is going to end up...because I have a lot to learn about all these inter-workings, and if you are interested in hearing me question fluffypony incessantly about random things then you can tune in and hear about it.
+
+#### Riccardo
+
+Thanks very much for the chat...and back to Fred with the weather!
--- a/_posts/2015-03-02-monero-missive-for-the-week-of-2015-03-02.md
+++ b/_posts/2015-03-02-monero-missive-for-the-week-of-2015-03-02.md
@ -0,0 +1,141 @@
+---
+layout: post
+title: Dev Diaries for the Week of 2015-03-02
+summary: BlockchainDB progress update, performance considerations, and rationale; RPC->0MQ communication change progress update
+tags: [monero missives, dev diaries, core, blockchaindb, rpc, 0mq]
+author: Riccardo Spagni (fluffypony)
+forum: https://forum.getmonero.org/1/news-announcements-and-editorials/195/monday-monero-missives-24-march-2nd-2015
+---
+
+<div class="text-center"><iframe style="border: none" src="//html5-player.libsyn.com/embed/episode/id/3399146/height/360/width/640/theme/standard-mini/direction/no/autoplay/no/autonext/no/thumbnail/yes/preload/no/no_addthis/no/" height="600" width="600" scrolling="no"  allowfullscreen webkitallowfullscreen mozallowfullscreen oallowfullscreen msallowfullscreen></iframe></div>
+
+To download the podcast directly please [use this link to the MP3](http://traffic.libsyn.com/monero/Monero_Missives_Podcast_for_the_week_of_2015-03-02.mp3).
+
+A brief summary of the points discussed follows, and a full transcription of the podcast is below (currently being completed, and it will be updated as it progresses).
+
+In this week's podcast we restart dev diaries, and focus on two things:
+
+1. Updates on blockchainDB, including rationale, performance considerations, and future steps
+
+2. Moving away from the old RPC system for talking to the daemon, to a 0MQ-based IPC system
+
+Technical note: in order to make this Missive a little more accessible, given its technical nature, we have taken some liberties in using the term "RPC" to refer to the JSON RPC API 2.0 over HTTP system used when currently communicating with the daemon, and "IPC" to refer to a complete replacement of that subsystem with 0MQ subsystem based on their Router/Dealer pattern, using the zmq_tcp transport for compatability.
+
+External Projects has moved to be covered next week. Until then!
+
+# Podcast Transcription
+
+#### Riccardo "fluffypony" Spagni
+
+Hello! And welcome to our second Monero Missives podcast. I'm Riccardo, fluffypony.
+
+#### Gingeropolous
+
+And I'm Gingeropolous!
+
+#### Riccardo
+
+Over the past week we've had some feedback on the Missive Podcast, we've had some feedback on the website. We're not going to talk much about the website - or at all. Instead, what we wanted to do, is get back to Dev Diaries, because obviously with the raw amount of content in last week's Missive we weren't able to talk about Dev Diaries at all.
+
+So Dev Diaries is a Missive feature - a long-running Missive feature - where we discuss the more technical commits or things that have happened in the past week. First and foremost on everyone's mind: the move to BlockchainDB is something that seems to be a little bit misunderstood, especially in terms of where things are right now.
+
+Just to clarify: the vast majority of the work on BlockchainDB has been completed. In fact, it was completed towards the end of last year. Plenty of us have been running BlockchainDB, or LMDB, instances of Monero for the almost two months now.
+
+#### Gingeropolous
+
+I can confirm that. I've been running the database version for a while now - I actually have a 2gb Linux box, it's just this crappy little old computer that I've managed to run the database build on for a while now. So it definitely works with low memory.
+
+#### Riccardo
+
+No exactly, and it does compile on the various platforms that we support. So there's no problem with platform support, there's no holdup with anything, the main issue we've had over the past month or so has got to do with two things.
+
+Firstly, with sync speed, so in other words...if you're catching up, maybe your @node has been down for a couple of days, or you're catching up from scratch, from the Genesis block. And the second issue that we've had to deal with is conversion. So you've got the current, in-memory @blockchain saved on disk, and you upgrade to the database version and you want to convert what you've got on disk - you don't need to sync up from scratch when you're pretty much caught up with the network.
+
+So this really has to do with the speed at which we write to the embedded database. It's not really a performance issue in terms of the database that we're using, but it's really a product of the fact that the entire @blockchain, for example, needs to be kept in RAM and then you have to have the database version whilst it's dumping. Or, when you're syncing up from scratch, there's all these extra components in the database, like indexes, that need to get written as it's busy dumping @blocks and @transactions down as it verifies them.
+
+It has been quite challenging to figure out ways of improving this, and the bulk of the really clever thinking and clever work has been done by warptangent, and we've had a lot of really good input from the LMDB author, Howard Chu. Without input from him I think it would've been a lot more challenging, a lot more difficult, to figure out how to take advantage of LMDB's speed.
+
+But at the moment it's really coming along nicely, and I reckon we are no more than a couple of weeks away from a point at which we can merge it into upstream and it can be pulled out into a release, into 0.8.8.7, and then we'll be able to at least get a feel on a wider basis as to how things are performing.
+
+#### Gingeropolous
+
+So regarding the database, I've been watching the forums, and it's been mentioned that other CryptoNote coins have utilised other methods to get around the whole @blockchain being in memory. Is there a reason that we didn't choose to just clone those methods, or "why use LMDB?" I guess is the main question...why sink all this time into making something new vs taking something that works.
+
+#### Riccardo
+
+That's a good question. So one of the things that we...one of the challenges that we faced is, when we really started going down the BlockchainDB route, there was some code added to the CryptoNote reference code, I believe Bytecoin added it initially. It was a version of the swapping between disk and memory that your operating system already does.
+
+So just to explain what happens: if you've got a 1gb file, and a program needs to access that 1gb file, but it only needs to access a small portion in the middle...there's no point, generally, in loading the entire thing into memory. But because most programs have to deal with files of all sorts of size and shape and colour they can't say "oh, I only need this portion in the middle" preemptively. So what they'll do is they'll request the entire file to be loaded into memory.
+
+But because the operating system knows that it only needs this portion at the beginning, and then later on this portion in the middle when it's requested, it won't actually load the whole thing into memory, but it'll page it into a temporary storage area on disk and then load portions into memory. So that's effectively what some of the other CryptoNote coins have used, this swapping.
+
+We felt that there was limited value in doing the swapping that the operating system is doing already...in a manner that may not be as efficient as the operating system. And that's not a knock on the piece of code that's been written, we just felt that it was better to abstract the @blockchain class out, and to create something that is more performant and more extensible.
+
+Obviously we had to balance that with the fact that the @blockchain was growing, and it was growing to a point where it was excessively big for many, and so we knew that there was this limited time that we had where we either had to get the database done, or we would have to fall back to some other solution. And we're still within that timeframe, and the database, as you know and as we've discussed, is pretty much done.
+
+So using that other fake-swap system wouldn't have had value, and wouldn't have solved the problem, and at worst it would've made us lazy to finish the database because there would've been no pressure.
+
+#### Gingeropolous
+
+One of the things that I saw mentioned on IRC is that LMDB works best - or only? I dunno - on a 64-bit system. So how will we address users that have 32-bit systems if the database is now using LMDB?
+
+#### Riccardo
+
+Ok, so there's two things that we're doing. The first is that LMDB has a branch that is 32-bit specific, called vl-32, and we will have that in the codebase. Outside of that, later on we do need a greater solution to something like ARM. If we want to run, and we are working on getting Monero running efficiently on a Raspberry Pi for example, it's not going to play well with the 64-bit version of LMDB because LMDB requires such a large MMAP space.
+
+#### Gingeropolous
+
+For those that aren't familiar, what fluffypony is talking about with ARM is a microarchitecture, a computer architecture, that is mainly used on mobile phones. So your Android device has ARM processors, whereas your computer has x86...or whatever it's called. So the goal here is to make sure that the database also works potentially on smaller, mobile, more efficient devices.
+
+#### Riccardo
+
+That's exactly it. It's one thing to have the ability to run a full @node on a computer...what about something smaller...something like a Raspberry Pi? What about the ability to have, almost like an appliance-level device, where you plug it into your network and that's it...that's your Monero @node. It syncs up to the network, if you need to access the @blockchain, or send @transactions, or receive @transactions, you don't need to then run another instance of the daemon because you've already got it running on that little appliance.
+
+#### Gingeropolous
+
+Oh nice!
+
+#### Riccardo
+
+This is the sort of thinking, as a longer-term prospect, which necessitates having multiple database implementation options, because that's really one of the sticking points, or one of the pain points. So LMDB...great, vl-32 branch...awesome, the vl-32 branch will probably, and we haven't tested this yet, will probably play quite nicely with Raspberry Pi. But even beyond that we're going to, at a slightly later stage, once we've got a little time in a couple of months, we're going to be adding BerkleyDB support.
+
+Now BerkleyDB is a slightly more pedestrian embedded database. It uses a different approach than the one that LMDB uses, and it means that it's not quite as performant as LMDB, but it's also a lot more forgiving when it comes to what architecture it can run on. And it also doesn't need as much MMAP space, for example...well it doesn't need MMAP space at all, really.
+
+#### Gingeropolous
+
+Whatever MMAP space is!
+
+#### Riccardo
+
+It's one of JSON's friends
+
+#### Gingeropolous
+
+Oh...that's where he lives...MMAP...it's what he uses to get places!
+
+#### Riccardo
+
+You know, we use Google Maps, he uses MMAP!
+
+Ok, so that really should give all our listeners an indication as to what the current state of the database is, the painpoints we've faced and have had to overcome, and what we're going to be doing in future...not only to make Monero run on multiple platforms, but to make it run smoothly and efficiently on the smallest of devices.
+
+So that's the database, I think that's the bulk of what we wanted to chat about about the database, unless there's anything else you'd like to add.
+
+#### Gingeropolous
+
+I think next on the list for the Dev Diaries is...
+
+#### Riccardo
+
+Is JSON...well, JSON's friend...RPC.
+
+#### Gingeropolous
+
+Going into acronym land!
+
+#### Riccardo
+
+Yeah we are a little bit!
+
+
+### Incomplete, Work in Progress
--- a/_posts/2015-03-09-monero-missive-for-the-week-of-2015-03-09.md
+++ b/_posts/2015-03-09-monero-missive-for-the-week-of-2015-03-09.md
@ -0,0 +1,233 @@
+---
+layout: post
+title: External Projects for the Week of 2015-03-09
+summary: MyMonero adds wallet importing, and an interview with the xmr.to team
+tags: [monero missives, external, usability, mymonero, accounts]
+author: Riccardo Spagni (fluffypony)
+forum: https://forum.getmonero.org/1/news-announcements-and-editorials/206/monday-monero-missives-25-march-9th-2015
+---
+
+<div class="text-center"><iframe style="border: none" src="//html5-player.libsyn.com/embed/episode/id/3415228/height/360/width/640/theme/standard-mini/direction/no/autoplay/no/autonext/no/thumbnail/yes/preload/no/no_addthis/no/" height="600" width="600" scrolling="no"  allowfullscreen webkitallowfullscreen mozallowfullscreen oallowfullscreen msallowfullscreen></iframe></div>
+
+To download the podcast directly please [use this link to the MP3](http://traffic.libsyn.com/monero/Monero_Missives_Podcast_for_the_week_of_2015-03-09.mp3), or [this link to the AAC/MP4](http://traffic.libsyn.com/monero/Monero_Missives_Podcast_for_the_week_of_2015-03-09.mp4), or [this link to the FLAC](http://traffic.libsyn.com/monero/Monero_Missives_Podcast_for_the_week_of_2015-03-09.flac).
+
+A brief summary of the points discussed follows, a full transcription of the podcast is below that and was kindly transcribed by goin2mars. You can donate to him for his transcription efforts: 4AzncXEK71uEtNtSKJjaX845XnJr9s7onXYNSBPTB2AGNnPbTjaN5W72qo8YgSSYsLGcr5pTBQkjnE7ADn6XbbHG2CTvvU1
+
+In this week's podcast we cover external projects, with an interview with the [xmr.to](http://xmr.to) team.
+
+1. [MyMonero](https://mymonero.com) has added existing wallet import functionality. Just use your 25 word mnemonic from simplewallet when logging in, and after paying the 10 XMR once-off fee your wallet will be available in MyMonero.
+
+2. An interview with two members of the xmr.to team, binaryFate and Krongle, discussing some of the system's inner workings and challenges they've faced.
+
+Until next week!
+
+# Podcast Transcription
+
+#### Riccardo "fluffypony" Spagni
+
+Hello, and welcome to yet another Monero Missive podcast! I'm fluffypony, and i'm joined today by several people: Gingeropoulos,
+
+#### Gingeropolous
+
+Hi everyone how are you doing!
+
+#### Riccardo
+
+And Tom, who you may know as tewinget,
+
+#### Tom
+
+Hello!
+
+#### Riccardo
+
+And binaryFate,
+
+#### binaryFate
+
+Good morning
+
+#### Riccardo
+
+and Krongle!
+
+#### Krongle
+
+Hi everybody
+
+#### Riccardo
+
+So because of the amount of stuff that we seem to be covering in each weeks Missive podcast we obviously haven't been able to touch on external projects. A recap for everyone that doesn't know what external projects is: it's a section of the missive that deals with projects that are not entirely by the Core Team, they're by members of the community...or anyone, really, that's doing something interesting that involves Monero.
+
+Ok, so you know MyMonero seems to be growing in popularity, and obviously one of the concerns that people have had is the ability to...you know, they want to be able to use MyMonero if MyMonero explodes, and they don't want to lose access to their funds, for want of a better term. And obviously they are still in control of their funds, they're in control of their private key, but we do recognise that there is a need for simplewallet to be able to use the MyMonero style keys.
+
+So that's something we are working on, and that's something that's something that we're quite close to, but what were happy to announce is the availability of an import wallet function. So if you have an existing simplewallet mnemonic, 25 word mnemonic, you will now be able to import your wallet into MyMonero. However, this doesn't come free - if you've ever done a wallet restore then you'll know that it is a little bit painful, because a wallet restore takes several hours, even on a snappy machine. So for us to import wallets we have to incur a cost purely from a processing perspective, and that has to be handed over to customers.
+
+So at this initial stage we're going to be charging 10 Monero for a wallet import. It's a once-off cost, you'll never need to pay it again, and it will run from there on out with no additional fees for importing it. Obviously as time progresses, and depending on how successful this feature is, we may look at reducing the cost or whatever depending on how it scales. And one of the other things is we do support all the mnemonic languages that Monero supports, and will continue adding support for them as they increase. The ability to go the opposite route, you know to go from MyMonero into simplewallet, should be in simplewallet shortly.
+
+Then really the last prong of this three pronged attack that we're doing is to give people the ability to create watch-only wallets...which effectively you can kinda fake now, in a way, by importing your view key with a random spend key, but we'll have proper watch only wallet functionality soon.
+
+### Gingeropolous
+
+Oh cool, so you just log in to check like how much you have in your account, to see if anyone has sent you anything.
+
+#### Riccardo
+
+Ja, and its not in a manner that can be exploited, because we wont have your spend key, and even if we try to change the JavaScript we still wouldn't have your spend key.
+
+Ok so pretty much since we last did external projects there's a newcomer on the scene that's kinda exciting: xmr.to. And that's why today we have Krongle and binaryFate who are both from xmr.to, they're part of the team.
+
+So to start off why don't you guys tell us a little bit about what xmr.to is, either of you?
+
+#### Krongle
+
+Alright, so we're a bunch of computer science researchers, in fact there's three of us - there's us the two of us and Arnuschky, who's also known. I'm the newer guy, but these other guys have been involved in crypto for a longer time, and binaryFate, I think, has been aware of the whole Monero stuff right from the beginning. He got me and Arnuschky excited about the whole space, so we've been looking to get into crypto for a while.
+
+We've just recently started a company called CryptoSphere Systems, which is the brand that we wanna get involved with, that we wanna use. So we wanted to do something simple and quick to dip our toes in the water. So we came up with this idea, that one of the things obviously that is great and exciting about Monero is the whole anonymity, but the problem is that it's very hard to spend this stuff, whereas everyone's spending Bitcoin.
+
+So the idea was quite a simple one...just try and enable people to spend Monero, but in Bitcoin world.
+
+#### Riccardo
+
+binaryFate, can you tell us a little bit about how xmr.to works from a user's perspective?
+
+#### binaryFate
+
+From the user perspective, it's quite simple in fact. Basically you have a friend you want to send to Bitcoin to, or you have a BitPay bill to purchase something online, you are given a Bitcoin address and you send a Bitcoin amount.
+
+What xmr.to is doing is to be an automatic gateway to pay these bill in Bitcoin for you, and for you sending us some XMR. So in the end it boils down to the ability for the user to purchase anything with Bitcoin, while only spending Moneros.
+
+So xmr.to gives the possibility to the end user, basically, to send Bitcoin - so to purchase any kind of goods online with Bitcoin that is now probably accepted unlike Moneros for the moment - so the user can purchase stuff with Bitcoin by only paying Monero.
+
+#### Gingeropolous
+
+I myself tried the thing out within, like, the first hour of you guys posting, I dunno if you recall. So yeah I was able to just plug in the Bitcoin address I had, and pay myself with Monero.
+
+You know my question in these things is always, from the new user...you know, just pretend I'm some guy that watched the Superbowl and was like "oh Bitcoin" and then read about "oh Monero!" How secure is it? What are the processes of it where i can be sure that I'm actually sending Monero and it'll turn up as bitcoin somewhere? Again this is the whole trusting a third-party thing, so I dunno if you guys could elaborate.
+
+#### Krongle
+
+I think there's two different aspects to this. So one is just: do you trust any third-party, so some random person on the internet, do you trust them? I mean in a way there's not that much you can do about it...
+
+#### Gingeropolous
+
+Right, right
+
+#### Krongle
+
+...beyond just trying with a small amount, and I guess that's kind of what we've seen people doing already.
+
+#### Riccardo
+
+You know, when it comes down to it you've also gotta trust the company you're buying from anyway. So whether you're adding another layer to it...meh.
+
+#### Krongle
+
+This is the same as what everything on the internet before the community as well so you see that people have had positive experiences and the thing hits a critical mass and then you can be fairly confident that it works. you will feel the first couple of users that its just this weird black box that you don't know whats coming out the other end
+
+#### Gingeropolous
+
+Yeah just to mention that as you said its something that we witness anywhere in general because we are to trust the merchant or we are to trust bitpay to actually act as a gateway and not to keep your bitcoin so its just one layer that people i think are quite used to
+
+
+yeah i think the most important thing for me to mention is that there is absolutely no trust involved for anything that is um privacy related so you spend your Monero and we dunno anything more than that.
+
+Gingeropolus
+mhm
+
+#### binaryFate
+
+because Monero is not traceable back so we can really the only information that we know about you is your ip address but if you reach xmr.to through some um anonymous networks like tor i2p then there is not much that we can do even if we were some really bad guys we would like to we couldn't do anything basically which is very nice
+
+Gingeropolus
+yeah
+
+#### binaryFate
+
+no problem for the user
+
+#### Riccardo
+
+i think the one key advantage as well is um most of the you know a lot of the losses that have occurred when in crypto wen people have had to trust third parties have been things like exchanges with they've left money on the exchange and with you guys its straight through you dump Monero in and out pops the bitcoin and there's not really much of an interval in between where things can go wrong
+
+#### binaryFate
+
+yeah
+
+and on that front one of the things we've tried to the do on the user interface is to make it very responsive so that basically you can always see that something is happening so we actually spent like a bit of extra time um on it with a bit of extra development effort monitoring the transaction pool rather than just waiting for confirmation which is our first attempt we realized we were quite keen
+
+that the user gets the sense that things are happening snappily so that you don't feel that oh I've sent my money into the void, whats going on. but you get in fact very quickly get back some sort of notification saying okay we're seeing that somethings going on here what were doing about it and we've tried to make that user experience so right from the moment you send your money to the moment that the bitcoin appears that the other end yourself always being notified in real time whats happening so you don't just get left with this sinking feeling of oh god
+
+
+Gingeropolus
+
+hah hah hah hah yea i did enjoy that part of the experience like i sent my Monero there and all of a sudden you had the screen change and there's was a tracking number and i was like oh OK something is happening
+
+#### binaryFate
+
+nice to know that the effort was noticed. appreciated.
+
+Gingeropolus
+i have a couple of questions about that whole process
+
+#### binaryFate
+
+yeah
+
+Gingeropolus
+for one um, there are some merchant services i believe bitpay and coinbase being two of them i think they have roughly ten minute timeouts on a transaction so if you start a transaction then that amount of bitocin they want you to send is valid for only ten minutes to deal with the volatility a bit. do you wait for enough confirmations from Monero from the blockchain and if so is it within that limit would i have a problem with that?
+
+so basically withing that fifteen minutes i have to send Monero to you. it has to get enough confirmations or you guys to mark it as safe and then you have to send the bitocin and so what toms asking is what are the chances of missing that window
+
+
+#### binaryFate
+
+so what we do is to give the user five minutes time window but what matters and what needs to happen within this time window is just that we actually see the transaction on the peer to peer network. if you send the transaction on time there is literally zero chance that you miss this time window. if you are just connected to the Monero network. and as soon as we actually witness the transaction on the network we stop the timer and we just wait for one confirmation before sending the bitocin. we think that for now one confirmation is way enough and we can take the risk especially because we're still dealing with very small amounts. but because we don't need the confirmation to happen in the time window but only to witness the transaction on the network its very safe for the user because you're practicality no chance to miss it
+
+but in terms of missing the second timeout like the lock on time amount of whoever you're paying in bitocin its quite unlikely if you're snappy on your end as an end users i think that were just benefiting form the fact that the Monero confirmations clock in much faster than the bitcoin confirmations
+
+Gingeropolus
+it sounds like waiting for one confirmation is plenty small time.
+
+even if we eventually want to up that to two or three you're still within, you can get 2 or 3 Monero confirmation well before even one bitocin confirmation so no one in bitcoin world is gonna set their timeout so small because of the slow confirmations
+
+#### binaryFate
+
+if in the future this becomes an issue say bitpay suddenly decides to change this countdown to five minutes instead of fifteen what we could do on our side is to accept a zero confirmation transation which is exactly what bitpay is doing. based on some rules you judge whether the transation is highly likely to be spend and for now its really do it and see for our needs but its something we could do int he future.
+
+
+Gingeropolus
+now if i could ask just one other question. i don't know this one that you probably might not want to answer but I'm curious how does this work on the back end. like can you give any sort of like brief synopsis of that. because I'm curious like do you take the xmr and then go and buy the bitcoin like where does the bitcoin come from in this i guess is the question.
+
+#### Krongle
+
+yeah well, uh, in a way i think its important for the user to know at least one thing this thing is that we don't buy the equivalent of bitcoin right away because that would be possibly weakening the privacy right because you could make some time correlations because poloniex could do for instance we would use poloniex to change the Moneros immediately. for the same amount that was just sent to us. that would be an issue. so we don't do that. we are not sure how in the future how we are going to change them but for now i think  we do it like once a week. so yeah for now in a way .....? and we are still figuring out what the best way for us to go financially speaking but yeah whats important to know is we don't change them back right away.
+
+and the other thing important for the end user to know is we set our maximum based on how much bitcoin we have in our funds so we will never accept an order we cant fulfill basically. if were running low on funds.
+
+
+#### Riccardo
+
+your risk tolerance is based on how much you got in reserve
+
+#### binaryFate
+
+yeah so were exposing ourselves to exchange fluctuations at the moment we just take on that risk and as Jeremy says we need to come up with a plan where we protect ourselves against that.
+
+#### Riccardo
+
+thanks very much for the chat guys and well see everyone next week
+
+Gingeropolus
+yeah thanks for hanging out guys
+
+#### Tom
+
+cheers guys see ya
+
+#### binaryFate
+
+thinks for having us bye
+
+Gingeropolus
+thank you all for joining it was quite a big crowd today, very awesome. thanks all for listening and tune in next week and here's bob with sports.
--- a/_posts/2015-03-16-monero-missive-for-the-week-of-2015-03-16.md
+++ b/_posts/2015-03-16-monero-missive-for-the-week-of-2015-03-16.md
@ -0,0 +1,26 @@
+---
+layout: post
+title: Monero Missive for the Week of 2015-03-16
+summary: Initial DB merge is about a week away, Tippero available on IRC / Twitter / Reddit, English mnemonic bug
+tags: [monero missives, accounts, blockchaindb, external]
+author: Riccardo Spagni (fluffypony)
+forum: https://forum.getmonero.org/1/news-announcements-and-editorials/225/monday-monero-missives-26-march-16th-2015
+---
+
+<div class="text-center"><iframe style="border: none" src="//html5-player.libsyn.com/embed/episode/id/3430948/height/360/width/640/theme/standard-mini/direction/no/autoplay/no/autonext/no/thumbnail/yes/preload/no/no_addthis/no/" height="600" width="600" scrolling="no"  allowfullscreen webkitallowfullscreen mozallowfullscreen oallowfullscreen msallowfullscreen></iframe></div>
+
+To download the podcast directly please [use this link to the MP3](http://traffic.libsyn.com/monero/Monero_Missives_Podcast_for_the_week_of_2015-03-16.mp3), or [this link to the AAC/MP4](http://traffic.libsyn.com/monero/Monero_Missives_Podcast_for_the_week_of_2015-03-16.mp4), or [this link to the FLAC](http://traffic.libsyn.com/monero/Monero_Missives_Podcast_for_the_week_of_2015-03-16.flac).
+
+A brief summary of the points discussed follows, a full transcription of the podcast is outstanding (can be submitted via [Github Issues](https://github.com/monero-project/monero-site/issues)).
+
+In this week's podcast we update the progress on the DB, discuss Tippero, talk about decentralising-all-the-things, and discuss the English wordlist bug.
+
+1. Initial DB merge is about a week away.
+
+2. Tippero has been officially made publicly available, and allows for tipping on IRC, Reddit, and Twitter! For IRC, send a message to Tippero with ```!help``` or ```!commands```. For Reddit, message [/u/tippero](https://reddit.com/user/tippero) with ```!deposit``` for your address, and tip with ```+amount /u/tippero optional message``` in a reply. For Twitter, you can tip with ```+amount @recipient_person @tipperome optional message```. Until Tippero lets you link your accounts across networks you can manually move funds, for eg. on IRC: ```/msg tippero !tip twitter:fluffyponyza 10``` or ```/msg tippero !tip reddit:fluffyponyza 10```.
+
+3. Not everything needs to be in a blockchain, and not everything can be decentralised with our current level of technological advancement. The Monero core team won't crowbar decentralisation into everything unnecessarily, especially when it has potentially disastrous results.
+
+4. English mnemonics that contained "incline" or "launchpad" will need to test restoring by replacing "incline" with either "incur" or "inline", and "launchpad" with either "ourselves" or "launching".
+
+Until next week!
--- a/_posts/2015-03-23-monero-missive-for-the-week-of-2015-03-23.md
+++ b/_posts/2015-03-23-monero-missive-for-the-week-of-2015-03-23.md
@ -0,0 +1,24 @@
+---
+layout: post
+title: Dev Diaries for the Week of 2015-03-23
+summary: Detail on the structure of the new blockchain conversion and import utilities
+tags: [monero missives, dev diaries, blockchaindb, core]
+author: Riccardo Spagni (fluffypony)
+forum: https://forum.getmonero.org/1/news-announcements-and-editorials/245/monday-monero-missives-27-march-23rd-2015
+---
+
+<div class="text-center"><iframe style="border: none" src="//html5-player.libsyn.com/embed/episode/id/3450222/height/360/width/640/theme/standard-mini/direction/no/autoplay/no/autonext/no/thumbnail/yes/preload/no/no_addthis/no/" height="600" width="600" scrolling="no"  allowfullscreen webkitallowfullscreen mozallowfullscreen oallowfullscreen msallowfullscreen></iframe></div>
+
+To download the podcast directly please [use this link to the MP3](http://traffic.libsyn.com/monero/Monero_Missives_Podcast_for_the_week_of_2015-03-23.mp3), or [this link to the AAC/MP4](http://traffic.libsyn.com/monero/Monero_Missives_Podcast_for_the_week_of_2015-03-23.mp4), or [this link to the FLAC](http://traffic.libsyn.com/monero/Monero_Missives_Podcast_for_the_week_of_2015-03-23.flac).
+
+A brief summary of the points discussed follows, a full transcription of the podcast is outstanding (can be submitted via [Github Issues](https://github.com/monero-project/monero-site/issues)).
+
+In this week's podcast we discuss the new blockchain utilities in preparation for their final merge.
+
+1. blockchain_converter converts between database types, right now its only job is to convert from the old in-RAM system to an lmdb database. It chews memory, though, as it has to keep the blockchain in RAM as well as the lmdb driver.
+
+2. blockchain_export takes the default database (set at compile time) and exports it to a blockchain.raw file. This is the file we're going to make available for download as the blockchain bootstrap in future.
+
+3. blockchain_import imports from the blockchain.raw file into whatever database format (specified at runtime, the default database is specified at compile time). It allows you to import with verification off for the fastest possible speed, specify LMDB options, and specify a batching count for loading in chunks.
+
+Until next week!
--- a/_posts/2015-03-30-monero-missive-for-the-week-of-2015-03-30.md
+++ b/_posts/2015-03-30-monero-missive-for-the-week-of-2015-03-30.md
@ -0,0 +1,18 @@
+---
+layout: post
+title: External Projects for the Week of 2015-03-30
+summary: An interview with Jojatekok, creator of the MoneroX GUI
+tags: [monero missives, external, gui, usability]
+author: Riccardo Spagni (fluffypony)
+forum: https://forum.getmonero.org/1/news-announcements-and-editorials/252/monday-monero-missives-28-march-30th-2015
+---
+
+<div class="text-center"><iframe style="border: none" src="//html5-player.libsyn.com/embed/episode/id/3467135/height/360/width/640/theme/standard-mini/direction/no/autoplay/no/autonext/no/thumbnail/yes/preload/no/no_addthis/no/" height="600" width="600" scrolling="no"  allowfullscreen webkitallowfullscreen mozallowfullscreen oallowfullscreen msallowfullscreen></iframe></div>
+
+To download the podcast directly please [use this link to the MP3](http://traffic.libsyn.com/monero/Monero_Missives_Podcast_for_the_week_of_2015-03-30.mp3), or [this link to the AAC/MP4](http://traffic.libsyn.com/monero/Monero_Missives_Podcast_for_the_week_of_2015-03-30.mp4), or [this link to the FLAC](http://traffic.libsyn.com/monero/Monero_Missives_Podcast_for_the_week_of_2015-03-30.flac).
+
+A brief summary of the points discussed follows, a full transcription of the podcast is outstanding (can be submitted via [Github Issues](https://github.com/monero-project/monero-site/issues)).
+
+In this week's podcast we interview Jojatekok, the 17 year old creator of the MoneroX GUI, and discuss his switch to cross-platform support for MoneroX, as well as some of his future plans. We also spend some time musing over his youth, and wondering where ours went to!
+
+Until next week!
--- a/_posts/2015-06-29-monero-missive-for-the-week-of-2015-06-29.md
+++ b/_posts/2015-06-29-monero-missive-for-the-week-of-2015-06-29.md
@ -0,0 +1,344 @@
+---
+layout: post
+title: Monero Missives for the Week of 2015-06-29
+summary: A warm welcome back, and a report from Riccardo's trip to Europe
+tags: [monero missives, conferences]
+author: Riccardo Spagni (fluffypony)
+forum: https://forum.getmonero.org/1/news-announcements-and-editorials/319/monday-monero-missives-30-june-29th-2015
+---
+
+<div class="text-center"><iframe style="border: none" src="//html5-player.libsyn.com/embed/episode/id/3645472/height/360/width/640/theme/standard-mini/direction/no/autoplay/no/autonext/no/thumbnail/yes/preload/no/no_addthis/no/" height="600" width="600" scrolling="no"  allowfullscreen webkitallowfullscreen mozallowfullscreen oallowfullscreen msallowfullscreen></iframe></div>
+
+To download the podcast directly please [use this link to the MP3](http://traffic.libsyn.com/monero/Monero_Missives_Podcast_for_the_week_of_2015-06-29.mp3), or [this link to the AAC/MP4](http://traffic.libsyn.com/monero/Monero_Missives_Podcast_for_the_week_of_2015-06-29.mp4), or [this link to the FLAC](http://traffic.libsyn.com/monero/Monero_Missives_Podcast_for_the_week_of_2015-06-29.flac).
+
+In this week's "welcome back" episode we discuss Riccardo "fluffypony" Spagni's trip to Europe, and the various meetups and conferences he spoke at.
+
+Until next week!
+
+# Podcast Transcription
+
+Note: the Bitcoinference presentation video can be found [on YouTube](https://www.youtube.com/watch?v=GEVm1dMn5Ks)
+
+#### Riccardo "fluffypony" Spagni
+
+Hello and welcome back to the Monero missives. I am Riccardo, fluffypony and with me today as always I have the fantastic Gingeropolous. 
+
+#### Gingeropolous
+
+Hello everyone, welcome back. 
+
+#### Riccardo
+
+It has been too long since our last conversation and that's my fault because I went on a little Monero tour of Europe, but now I am back. 
+
+#### Gingeropolous
+
+The magical mystery Monero tour. 
+
+#### Riccardo
+
+Exactly. 
+
+#### Gingeropolous
+
+So now we are here to find out what the mystery is all about. 
+
+#### Riccardo
+
+Yes, as some of them wondered what happened in Europe. 
+
+#### Gingeropolous
+
+We saw some pictures from Brussels, I don't know where those were, with the tiny elevator. 
+
+#### Riccardo
+
+Yes, it was Brussels and I was going to put more pictures up, but then between running around, being super busy and also Bitcointalk being down for like ages, I just gave up on that idea. So I'll try and put some photos up. I didn't unfortunately take much in the way of photos of the actual meetups and bitcoin friends, but that also because not everyone wants their picture taken and plastered all over Bitcointalk. Apparently I am the exception to that. 
+
+So basically to sort of give everyone a bit of overview. The reason I went to Europe was not just for Monero. I also went for a friends' wedding and to visit, for my wife and I, my in laws (her parents). Then we sort of coupled some stuff on top of that, which were the Monero meetups ,some Bitcoin meetups and the Bitcoinference. So we ended up having three Monero meetups, we had one in Brussels, one in Paris and one in Berlin. Then I also spoke at a Bitcoin meetup in Berlin where I spoke about OpenAlias and then lastly I went to Bitcoinference in Amsterdam and spoke at Bitcoinference also about Monero. 
+
+#### Gingeropolous
+
+That's a lot of talking. 
+
+#### Riccardo
+
+So, it's a lot of talking. Thankfully for the most part it was the same talk that I gave at all three. I mean, sorry, at all 4 of the meetups/conferences. Then obviously the OpenAlias talk was different, but it was more like a soft introduction to OpenAlias and a bit of a discussion about how we provide lookup privacy and that sort of thing.  
+
+#### Gingeropolous
+
+Gotcha. 
+
+#### Riccardo
+
+So let me run through them one at the time and give a bit of an executive summary 
+
+#### Gingeropolous
+
+That's sounds good, I am interested to hear what happened. Take it away 
+
+#### Riccardo
+
+So the Brussels meetup was pretty amazing. It was organized by Binaryfate. One of the guys behind XMR.TO and it was very kindly hosted. The venue was provided by Peter Hintjes, the guy behind ZeroMQ and it was really, really good. We had quite a nice turnout. It was myself and David who were there and who spoke. Then also BinaryFate spoke and then there was also a talk by Thomas Spass about privacy and fungibility from a legal perspective. Which was very interesting as well. So, what sort of came out of those initial talks, the one by BinaryFate and the one by Thomas about privacy and fungibility was really an overview of why fungibility is such an important aspect of a currency and also why or what the consequences could be of Bitcoin not having fungibility. That's not to say Bitcoin is going to fail and I don't want to give anyone the impression that there was some sort of negativity towards Bitcoin, because there wasn't. It's just, you know, let's talk about this. 
+
+Then I gave my talk after David. David sort of gave an introduction as to a brief overview of Monero and then also an overview as to why privacy is important. Then I spoke a little bit more about some other aspects of  the importance of privacy, but then I went into a little bit more detail about how Monero works. So afterwards we then hung around and  had a bit of a braai?. Braai is the South African for barbecue , but we did it South African style. Which means that somebody else cooks and then everyone else just eats the food and pretends that they know how to cook. And you know, the beer flows, the usual. Then BinaryFate, Peter and myself were kind of the last to leave. Before I get to that, Peter kindly arranged for some guys (musicians) from I guess the DRC, can't really remember where they were from, but anyway. They were really cool guys and just jammed a bit on the guitars and sang and that was really awesome. It was like background music, but I mean live and that was nice. After the musicians packed up then eventually it was just BinaryFate, Peter and myself  and we sat and spoke for like hours. A lot of the stuff, like the 6 month rolling hard fork, that we've been speaking about now and there is some other stuff that I've been putting down. A lot of that comes out of that conversation between BinaryFate, Peter and myself. I've written this all down in a post that I am putting up on the forum about some other changes that we want to make. But Peter, obviously as the guy behind ZeroMQ, manages and is responsible for a very large open source project and so he has gone through a lot of the pain of dealing with an open source project and dealing with different personalities, people of various skill levels and contributors. You know, all that sort of jazz, and so there was a lot that I was able to take away from that discussion, took back and we didn't discussed as a core team. Some really nice things have come out of that, some really nice ideas and also just a general sense of how difficult it is to manage an open source project and to sort of do so in a way that doesn't offend people that want to contribute and doesn't make the barrier to entry so high, but at the same time acknowledging that this is difficult. It's security software and it's not the sort of thing that we want to leave open to making very many mistakes. So yeah, there was that. 
+
+That was kind of the end of the Brussels meetup and then pretty much from there, the next day I went straight through to Paris. I took the train to Paris, which was kind of exciting. It was one of the high-speed trains, the Thalyss one. First time I have ever been on a high-speed train, well I mean one like that. We've got a reasonably fast train in Johannesburg, that goes pretty much from to the airport into and around parts of Johannesburg. But I mean, this was really like a different story, that train was crazy.  Then I got to Paris and met up with my wife, she didn't come to Brussels, but she joined me in Paris and so we got to run around the city and do the normal Parisian thing. Like the tourist thing, go to see the Eiffel tower, go see Versailles, all the touristy stuff. Then we had the meetup and it was kind of challenging. Obviously David organized that and we had a very nice turnout there, quite a few people. I would say at the Paris meetup we probably ended up with like between 30 and 40 people at a guess. The Brussels meetup a little bit less than that, but also quite well attended. It was quite challenging, because obviously in France and Paris in particular, a lot of the locals don't really have a need to speak English or to speak much English. So there was a language barrier, whereas in Brussels it seemed that pretty much everyone spoke English with no problem. So David reckons that about 50% of the audience their English was not fantastic. It's difficult because when you are talking and speaking in English. You see some people whose eyes are lighting up and they're obviously understanding what you're saying, but then you are not sure of the other people. They are looking at you and you sort of going well they seem to be understanding, everything is great. Or hey, that guy looks a bit bored, but that's fine. But I realized, especially with some of the jokes I told. I mean I am not very frivolous, but I threw out the occasional joke or two and then some of them I had to repeat before the audience got it. It was still fun though. I think if I had to do the Paris meetup again I probably want to do it with someone translating to reduce that sort of gap between me and the audience. But still had a lot of fun there, met lots of cool people and met some of the Monero contributers who live there or who live in France. Met some of the guys that operate mining pools in France and that sort of thing. 
+
+#### Gingeropolous
+
+Oh cool, there is a lot of them there. 
+
+#### Riccardo
+
+So that was nice and then pretty much from there went back to Berlin (a few days after that) and then we had the Berlin Meetup. Which was on a Sunday, sort of late afternoon / early evening. It was a public holiday, so I think a lot of people were not in the right frame of mind to go to a meetup, but we had a nice turnout nonetheless. We were joined by Risto (Risto Pietila) and some of his friends from Finland and one of Risto's associates, Ally, gave a nice talk on Monero as a private store of value (as a private store of wealth) after I had given my presentation, which was quite interesting. Then Risto spoke a little bit as well. I am very hesitant to talk about Monero as an investment, because I don't believe it's an investment. I believe it should be used and should be useful. If you buy Monero and then expect it to magically go up, you probably end up getting burned, because that is not the way it works. Normally when people ask me how can make money with Monero I encourage them to contribute to the ecosystem. Create an application, website or whatever. That's where you going to make money, not from buying, holding and hoping something happens. So I am always kind of hesitant with conversations like that, but there was a lot that I learned from Ally and Risto's presentation that I hadn't thought of before in terms of how Monero can be useful to certain classes of people as a private store of value. They also spoke about cryptocurrency in general being a new asset class. That also lent itself quite nicely to a general discussion of why the privacy in Monero is so important to fungibility of private store of value. So that was Berlin and afterwards we went out for some food and beer. Well, never have I walked so much in my life as I did in Europe. Everyone walks everywhere and everyone drives everywhere. That's always fun, but you get used to it. Then a few days later we had the Bitcoin meetup, there were 3 speakers: Myself, one of the gals that works on Ethereum and the lady that started up Zipcar, which is a car sharing service, but one of the first ones. 
+
+#### Gingeropolous
+
+Oh yeah, I use Zipcar. 
+
+#### Riccardo
+
+She's just written a book and she spoke a little bit about how she envisions Bitcoin and general blockchain technology being used in the future. Then the gal from Ethereum spoke about creating an almost like a chain of authenticity or custody, so that you are able to take a product and then know it's supply chain and then know where comes from. Like if I am buying organic wine does it really come from an organic farm and do they get their stuff from another organic farm. I know that there is a large movement at the moment to have verifiable supply chains. Who knows, maybe there is something interesting that will happen in that space. Whether it needs to be decentralized is a different conversation, but I do think there is scope for cryptographically verifiable supply chains amongst certain groups and in certain spaces. Then I spoke about OpenAlias, which everyone knows about. I spoke a little bit about the cottage industries that are starting to pop up that are providing OpenAlias services. I mean you can purchase OpenAlias identities and so on. That's what I think is quite cool, I think there is a lot of scope there. That was pretty much Berlin.
+
+Then I went to the Netherlands, to Amsterdam. Which was quite exciting, because I went there for Bitcoinference, but also because Amsterdam and the Netherlands in general has been quite a hub of Bitcoin activity. So I was quite excited about that. I was a little disappointed in Amsterdam itself, because I found that there were a lot of places still on Coinmap that say: We accept bitcoin or have a bitcoin ATM, but then you go there and (a) they don't accept bitcoin anymore because there was a lack of purchases with bitcoin, but also (b) the bitcoin ATM that was there has gone missing or was stolen. But overall, Amsterdam itself was fascinating. I have never seen so many bicycles in my life. Everyone rides a bicycle and the running joke is: In Amsterdam you don't actually own a bicycle, you just borrow one until it gets stolen and you need to go borrow someone else's  (because bicycle also get stolen all the time). So that made me chuckle. 
+
+#### Gingeropolous
+
+Did you borrow a bicycle? 
+
+#### Riccardo
+
+No I didn't, come on, I am South African I just drove everywhere. But that was fun. Then Bitcoinference was on that weekend and it was a Saturday and a Sunday. Also, nice turnout. It was the whole day, there were like 5-7 speeches/talks every day and lots of really interesting stuff as well. There was one talk from a professor at one of the Universities who was speaking about the definition of money, whether bitcoin qualifies as money and how we define money. He also spoke about how bitcoin has many of the properties of money, but he feels that the lack of privacy and therefore the lack of fungibility makes Bitcoin not money, because it just doesn't have enough of the properties. 
+
+#### Gingeropolous
+
+Well, wouldn't you know! 
+
+#### Riccardo
+
+The funny thing is, he said all of that and I was the next speaker. Unfortunately his speech got moved up, because he had to leave (he was supposed to be after me). So right after doing this entire talk how Bitcoin could be money if it was more private, he is like: "Ok, thank you very much" and off he goes. I talk next and I am like: "Well, thank you for the introduction, I am so sorry he is not going to be around to hear my talk". Which was kind of sad, but anyway. I did manage to record my slides and my audio, so I am going to put that up. It will go up with this missive, so that people can download it and have a listen to the presentation and see the slides at the same time. Bitcoinference also recorded me and they will put together a more complete video for all of the presentations. It's definitely well worth watching that presentation on whether Bitcoin is money and so on. So that will go up so that at least people can see the talk and get a bit of a feel for what the audience was asking afterwards and so. 
+
+#### Gingeropolous
+
+Just as a little primer, did you talk about Monero at the Bitcoinference or was it sort of a general privacy talk? 
+
+#### Riccardo
+
+No it was about Monero, it was entirely about Monero. It wasn't anything else, like unrelated. It was 100% about Monero. A lot of the conversations that we had, especially afterwards and some of the things I speak about in that talk are about Monero as it relates to other efforts. With Bitcoin privacy for instance. As it relates to other altcoins that are trying to do privacy and also as it relates to some of the future advances that are being done, especially in the Zerocoin/Zerocash space. I try to be as realistic as possible and acknowledge Monero's weaknesses and failings which I think is important in general so that people at least got a realistic view and that people understand how Monero works a lot better and how Monero could be useful to people. Again, not as a replacement for Bitcoin, but just as something that can be useful along with Bitcoin.
+
+#### Gingeropolous 
+
+Yeah, I'm interested to hear how what you said during the presentation and how the concept was received in general. So yeah, I look forward to seeing that post
+
+#### Riccardo
+
+We also had a couple of people that are Monero contributors that were there. One guy came from Sint-Petersburg in Russia. He has contributed to Monero Core and he is doing some Monero related stuff.  So that was quite nice to meet him in Amsterdam. So it was really a nice to meet people you normally only see their nickname on a screen. You don't even see their real name. So it was really special and I really enjoyed meeting people face to face.
+
+#### Gingeropolous 
+
+Awesome.
+
+#### Riccardo
+
+So meeting the people that contribute to the Monero ecosystem is definitely something that I would like to keep doing in the future. 
+
+#### Gingeropolous
+
+So after you presentation, was their anything else worthy of reporting? 
+
+#### Riccardo
+
+Oh there wasn't really anything else major that I did afterwards. However, I went to the next day. But I went to Arnhem. It's quite a little hub for Bitcoin activity in the Netherlands. I think that's because Arnhem is smaller than Amsterdam and so they're able to cover more of the shops and also the Bitcoin advocates are then able to use the places more. Obviously Amsterdam is so large that if 100 places accept Bitcoin then no one is going to all of those 100 places. They just keep going to the 3-4 places they like. I think in a smaller town it's easier to have a more broad coverage.
+
+#### Gingeropolous
+
+I haven't heard about that town.
+
+#### Riccardo
+
+Neither had I but I was quite pleasantly surprised when I got there.I could go to different places  and pay with BTC. It really is quite a vibrant buzzing cryptocurrency community there. So anyone who is going to the Netherlands,  you got to do Amsterdam obviously but Arnhem is worth making the trip. It's an hour by train and from Amsterdam and it 's definitely worth going there and meeting up with some of the Bitcoin guys going to some of the places. We went to a really nice Mexican restaurant that accepts bitcoin for example. They had fantastic food and really nice mojito's so if you heading for Europe and then try to seek up Bitcoin accepting places just purely to keep giving them the feeling it's worthwhile accepting it.
+
+#### Gingeropolous 
+
+I think they weren't open to accepting Monero yet?
+
+#### Riccardo
+
+Well, we had lots of conversations with the places that are already accepting Bitcoin, especially at the place where the Bitcoin embassy is in Amsterdam.
+
+#### Gingeropolous 
+
+A bitcoin embassy?! That's awesome!
+
+#### Riccardo
+
+Well, it's not like them accepting Monero will make them any less of an Bitcoin embassy. By the way, it's more the restaurant that's attached to the Bitcoin embassy, not the embassy themselves
+
+It's something like we're giving people a choice to pay with one or the other. This is advantageous for merchants but I also think that there's a lot of infrastructure that can be leveraged at the moment. If merchants are really used to accepting it or firing up Blockchain.info or running electrum or whatever for accepting Bitcoin payments,  it's not such a massive leap to start accepting Monero payments. Obviously that will only improve with time as systems get build out and so one. So we'll see how that goes, but I'm not a very big believer in merchant adoption being key for adoption. I think we've seen with bitcoin already that having massive amounts of merchant adoption hasn't helped with getting Bitcoin into the hands of people.
+
+There are some side projects where i' ve been working on for a while with some guys to try to improve that ecosystem not only for Bitcoin, but also for Monero as well. So we're helping people to get and to earn Bitcoin and Monero rather than to say to the people: "well there's a thousand places where you can spend it but sorry you need to go through this complicated process to buy it". 
+
+So that's kinda Fluffypony's trip to Europe.
+
+#### Gingeropolous
+
+The Magical Mystery Tour  in a nutshell
+
+#### Riccardo
+
+Yes, unfortunately I didn't make any T-shirts for it to wear, with all the places I've gonna be performing at. 
+
+Fluffypony on tour 2015 Europe, yeah!
+
+#### Gingeropolous 
+
+As a really brief recap based on what I get from this conversation it sounds like at the first meetup, you had the ZeroMQ guy there and the big takeaway was that you guys had to sit down and hash out how to gain more knowledge on managing an open source project. You brainstormed about this scheduled hard fork idea which has been a great conversation to follow on the forum if anyone hasn't tuned in to that yet. That post I recommend especially if you are interested in Monero and assuming you listening to this podcast, you want to know what it's doing and where it's going. Check out that thread, it's on forum.getmonero.org in the academic and technical section. 
+
+So that was the first one and then the second one was France do I have this right?
+
+#### Riccardo 
+
+Yes, it was Paris after Brussels.
+
+#### Gingeropolous 
+
+Ok, Paris after Brussels. It sounds like there was just a language barrier there. 
+
+#### Riccardo
+
+No, it was good and there was really good feedback afterwards but I think there were some people that struggled to follow what I was saying because I didn't really slowed down. I gave it like I normally gave it. I didn't make the connection between being in Paris and people speaking French. For some reason my brain blanked out on that. I thought I was speaking to an English audience and I like remembered it afterwards.
+
+#### Gingeropolous
+
+Oh you know,  you get caught up in the moment presenting. It's a general exciting thing so yeah...and from their was it Amsterdam next or am I missing something?
+
+#### Riccardo
+
+No, Berlin was in between then Amsterdam. 
+
+#### Gingeropolous
+
+Yeah, I already forgot what happened there. 
+
+#### Riccardo
+
+We had a meetup there and It was cool. 
+
+#### Gingeropolous 
+
+And then the coinference. I just like saying "coinference" I think. 
+
+#### Riccardo
+
+I was like "man, when I read the name...This guy has the best domain...bitcoinference.com.  You can't get better than that, if you will have a Bitcoin conference". He really  scored there.
+
+#### Gingeropolous
+
+Awesome! It sounds like it was a great trip and you got to spread the Good Word of Monero. One of the question I had was...You were doing your general presentation about Monero to audiences that hadn't either heard of it or had heard of it but only knew  it as how generally people think of altcoins. I mean what was the sense from these people? Were they like "oh, why do we need this? I get the privacy thing but can't bitcoin eventually do that?" Anything that really stands out from that? Because we are sort of in an echo chamber in the Monero community. We all believe in this different concept like privacy and fungibility and the utility of having a secondary currency...We've seen the conversations on the various fora of what the Monero community thinks of sidechains for example. So being in this echo chamber we miss a perspective. SO I'm curious if anything really stood out like "oh, that's something that we haven't heard of in the echo chamber" ? 
+
+#### Riccardo
+
+I think some of the things that jumped out at me are that there is a general misconception that Bitcoin is private enough. I think that the Bitcoin core maintainers are quite happy to acknowledge that Bitcoin is not private at all. I understand that there are a lot of Bitcoin purists that can't imagine that there could be anything else that could also be useful on any level, but I think for the most part there is a general acknowledgment at least amongst technical people I speak too that Bitoin is amazing and literally is THE ONLY cryptocurrency right now. But then Monero could also provide some value  someday as a truly fungible cryptocurrency. It's important speaking too people and having a chat with them. Some of the stuff that surprised me is those people didn't realize what we really mean when we speak about privacy within Bitcoin. We are not talking about how to privately buy drugs. We're talking about no one can determine my net worth or not being implicitly linked to a crime through blockchain analysis, whereas with Bitcoin I could receive tainted funds without wanting to or realizing it. So there is all stuff like that that came out.
+
+The other thing we had a lot of conversations about was the fact that within Bitcoin and within other altcoins there is a lot of "privacy theater" and "decentralized theater" as well.
+
+#### Gingeropolous 
+
+Privacy theater?
+
+#### Riccardo
+
+So privacy theater and decentralized theater is basically when something put on a show of being private and being decentralized. I"ll give you an example: there is a lot of conversation recently about ripple. Is it a cryptocurrency and it is decentralized? The reality is that there is a lot that you can do to sort of run your own component within the ripple network, but it's not decentralized. At best we can say ripple is distributed. But distributed and decentralized are different things. So obviously Ripple can claim to be decentralized and then they can say "look anyone can run you this or that" but that's not the same as being truly decentralized. What happens is that you end up with in that case decentralized theater where people might mistakenly expect or assume that Ripple is decentralized. The same goes for a  lot of these altcoins, and altcoins are particularly bad at this, that have centralized mixing build into their wallet and then they pretend that they are somehow private. What they sometimes even do is hosting a couple of servers and use an API  and a website to handle the mixing. And then they go like "see, it's hosted on more than one server" but again that's not the same as being decentralized, that's merely distributed. So there again we've got privacy theater and decentralized theater because the privacy that they are adding is not privacy to the level of being fungible. 
+
+The fungibility thing is a big one because there are lots of solutions for being relatively private. For example with Bitcoin, if you want to be relatively private I really like joinmarket. Joinmarket is this decentralized way to link people together that want to do coinjoin transactions and it provides significantly more privacy than a lot of other solutions that I've seen including a lot of altcoin solutions but the problem is while it provides privacy, it doesn't provide enough so that it makes Bitcoin fungible. It‘s a great solution and I encourage people to take a look at joinmarket but I think there has be an understanding that it can only do so much. It can take Bitcoin up to a point if everyone uses it, but not to a point that Bitcoin can truly be fungible. Just like with Monero , just like we understand the limitations and we are happy to talk about the limitations and the potential pitfalls, I think that it's important to look at all the other solutions and view them with the same realism and pragmatism. 
+
+#### Gingeropolous 
+
+Interesting, interesting...
+
+#### Riccardo
+
+...but I do talk about JoinMarket and all those other things in my presentation so there's that.
+
+#### Gingeropolous 
+
+So check out the presentation!
+
+#### Riccardo
+
+Pretty much. And that's about it.
+
+#### Gingeropolous 
+
+Awesome! Well, thank you for the recap and thanks for fitting the Monero meetups and all that stuff into your family vacation tour thing. It definitely adds a level to any trip.
+
+#### Riccardo
+
+It wasn't just work or pleasure. It was a good trip and there were lots of projects that I'm working on at the moment where the developers and some of my business partners are scattered around Europe. So being able to meet up with those guys as well was advantageous. So well I mean things are looking good and we've had lots of positive feedback and I'm sure when people watch the presentation they also hopefully learn a little bit about Monero's inner workings if they don't understand it already. 
+
+#### Gingeropolous 
+
+I think I might be still a freshmen when it comes to that. Maybe I graduate to sophomore class soon. 
+
+#### Riccardo
+
+Well, I mean you are a developer so you know...
+
+#### Gingeropolous 
+
+Oh yes, much develop.
+
+#### Riccardo
+
+I'm just saying...Gingeropolous, lead developer of Gingeropolous Software Incoproated
+
+#### Gingeropolous 
+
+Yeah, yes, that's me!
+
+Well, now that you're back from the Mystery Tour, we've got a lot of missive to post, that's for sure. I assume we post this one first because everyone is full of anticipation about what happened. So this will go up first so if you are listening now, you are obviously listening now...So after this one we will post the other ones that are in the hopper. So yeah, tune in next week! 
+
+#### Riccardo
+
+Now we can go back to a normal schedule. 
+
+#### Gingeropolous 
+
+Yeah or a schedule, either way
+
+#### Riccardo
+
+But it would be really a schedule. 
+
+I just want to make sure that everyone knows that when you write dates you put them year-month-day and you also measure things in meters and grams. 
+
+#### Gingeropolous 
+
+No no, you measure them in English units and metrics units so when you send probes to Mars you screw up and loose hundreds of millions of dollars
+
+#### Riccardo
+
+Yeah, oh dear we just overshot everything
+
+#### Gingeropolous 
+
+...because you are actually using metric.
+
+Yes, but I agree year-month-day is the way to do it. Makes file searching so much easier indeed.
+
+#### Riccardo
+
+Indeed, exactly right?
+
+#### Gingeropolous 
+
+Yeah, it's incredible!
+
+#### Riccardo
+
+Ok cool thanks for the chat and we'll chat again next week
+
+#### Gingeropolous 
+
+Yeah, thanks for tuning in!
--- a/_posts/2015-08-31-monero-missive-for-the-week-of-2015-08-31.md
+++ b/_posts/2015-08-31-monero-missive-for-the-week-of-2015-08-31.md
@ -0,0 +1,130 @@
+---
+layout: post
+title: Monero Missives for the Week of 2015-08-31
+summary: Contributing to, and building, the Monero website
+tags: [monero missives, usability]
+author: Riccardo Spagni (fluffypony)
+forum: https://forum.getmonero.org/1/news-announcements-and-editorials/2368/monday-monero-missives-31-august-31st-2015
+---
+
+<div class="text-center"><iframe style="border: none" src="//html5-player.libsyn.com/embed/episode/id/3775209/height/360/width/640/theme/standard-mini/direction/no/autoplay/no/autonext/no/thumbnail/yes/preload/no/no_addthis/no/" height="600" width="600" scrolling="no"  allowfullscreen webkitallowfullscreen mozallowfullscreen oallowfullscreen msallowfullscreen></iframe></div>
+
+To download the podcast directly please [use this link to the MP3](http://traffic.libsyn.com/monero/Monero_Missives_Podcast_for_the_week_of_2015-08-31.mp3), or [this link to the AAC/MP4](http://traffic.libsyn.com/monero/Monero_Missives_Podcast_for_the_week_of_2015-08-31.mp4), or [this link to the FLAC](http://traffic.libsyn.com/monero/Monero_Missives_Podcast_for_the_week_of_2015-08-31.flac).
+
+In this week's episode we discuss the website content, and how everyone can contribute to making the Monero website a more complete and useful resource for newcomers.
+
+Until next week!
+
+# Podcast Transcription
+
+#### Riccardo "fluffypony" Spagni
+
+Hello everyone and welcome to another Monero Missive. I am Riccardo, fluffypony, and again unsurprisingly today I have gingeropolous
+
+#### Gingeropolous
+
+Good morning everyone, this is Gingeropolous. How are you doing? But it is not morning. It could be afternoon for you, I keep forgetting that.
+
+#### Riccardo
+
+Could be evening
+
+#### Gingeropolous
+
+Ya
+
+#### Riccardo
+
+Could be middle of the night. So a lot have people seen the website and for example they have seen that parts of the website are complete and have content and other parts don't. We often get questions from people who want to help and they can’t necessarily contribute to Monero core, and they don’t have funds to contribute to the dev donation fund, so they prefer in some other way. They don’t want to create peripheral projects of their own.
+
+#### Riccardo
+
+One of the key areas that does need attention and will always need attention is the website. So what we wanted to do is chat a little bit about what is needed on the website right now and what will be needed on the website in the future and how you can get involved in helping us make the Monero website even better than it is.  Because it is meant to be a repository of terminal knowledge about Monero. That is what we want to it to be.
+
+#### Gingeropolous
+
+Indeed, time to fill up a lot of these, such as the “knowledge base” and  “user guides”. Just fill it up.
+
+#### Riccardo
+
+Just make it
+
+#### Gingeropolous
+
+I have come across these works in progress and I just wonder, how to get words on the page. I know the github version of these pages exist. But when I get to github I just wonder how do I make a commit? I don’t know
+
+#### Riccardo
+
+So lets talk very briefly about the technology of the Monero website. It is not important to know all the ins and outs, just as long as you know how to work on it. The website does not use something like wordpress or any of the common content management systems, it uses a system called Jekyll. Jekyll takes the content we write using a system called markdown and it turns it into HTML. So essentially the entire site is this flat static thing and we never need to worry about getting hacked with a SQL injection or anything like that. Its also very nice from a performance perspective.
+
+#### Gingeropolous
+
+I don’t know what a SQL injection is. Let us assume that those that know what a SQL injection is are happy. Moving on...
+
+#### Riccardo
+
+The long and the short of it is that it is not a point and click system. Markdown is a pretty easy system to work with for performing simple operations. If you are doing things that are more complex, it takes some figuring out. The parts of the website that need work and have close to nothing in them essentially all are “knowledge base” sections. Primarily there are 4 main sections that have next to nothing in them and those are:
+
+1. About Monero
+
+2. Moneropedia
+
+3. User Guides
+
+4. Developer Guides
+
+Those are the 4 areas in where we need assistance.  About Monero is not an area where are particularly concerned about getting much assistance because it is just a one pager. Although we would like some animations or videos explaining the inner workings, this is not a massive priority.
+
+Moneropedia on the other hand is something that needs a lot of work. On the website with the Moneropedia link there is a list of things we already have definitions for. Many of these are just one liners. They are used for providing definitions when you hover over the words elsewhere on the Monero website. The definition of “account” (first entry in Moneropedia) has been done completely with lots of detail. That is what we would like to see in Moneropedia for every single term, including the terms we are now missing. Not every term will be able to have more than a couple of lines. We need to flush out definitions for both newcomers and those who have been around crypto currencies for a while
+
+#### Gingeropolous
+
+Okay so the account page is basically the template of what we are looking for
+
+#### Riccardo
+
+Yes, this is what we would like things to look like. Now behind this page is not a bunch of HTML it is a markdown file. Om github you can see the account markdown file and get a good idea just by looking at the example. We will add some functionality to the site over the next week so that people can click and see and suggest changes easier. Now if you are not familiar with github and you don’t care to take the time to learn how to use git and directly contribute by making pull requests, then you can go to the right hand side of the Monero site github to submit a new issue. You can literally just type your suggestion in plain text into that area and suggest that. Then we can take that content, and properly format it into markdown and so on. This way people can help without having to spend time learning how to use markdown or github. The fastest way to get there is https://github.com/monero-project/monero-site
+
+#### Gingeropolous
+
+Easy enough
+
+#### Riccardo
+
+Now the same thing goes for developer guides and user guides. We have had a lot of people complain about a lack of documentation. They say I want to use the wallet API or daemon API but say “oh there is no documentation”. Someone needs to build the documentation. Its not always something the developers can tackle. Now those that have built things on top of Monero, please right down what you have learned. This way new developers do not need to spend days on IRC trying to muddle through it.
+
+#### Gingeropolous
+
+It is as easy as writing down content and an issue on github so that it can be added to the website. For example on the github page you can find he transcription of 3/19/15 missive which was transcribed by a community member who took the time to write it down. It is easily done
+
+#### Riccardo
+
+We are trying to make it easy for people to submit content. It is important to have a certain quality in terms on quality and grammar and spelling. Good flow and a consistent feel is also important. But frankly if you write a guide or any other content, someone else can come along to make changes and edits to assist with that. Its just a matter of getting content up there in the first place
+
+#### Gingeropolous
+
+It is much easier to edit something that create it. If you are inspired to create something don't be worried about needing some sort of polished gem that is worthy of being on our beautiful Monero website. Just make something happen and we will all work together to make it website worthy.
+
+#### Riccardo
+
+Now a lot of people have expressed some interest in helping with translations.  We are almost at the stage where we are ready to switch over to translated version of the website. Please if you can help do so, the front being the most important. In the next weeks we will be ready to switch over to the multi- language version and move some things over to Transifex. This will make it easily for people to assist with translations
+
+#### Gingeropolous
+
+Someone recently made a post stating that we found out Transifex is free for open source developers.
+
+#### Riccardo
+
+The nice thing about Transifex as well is that if someone submits a translation, someone else can always come along better to make edits to make better translations. Hopefully not only the content but also the intent of the website and posts in the translation.
+
+#### Gingeropolous
+
+So in general this call for content and help for edits is a reminder that Monero is not your typical cryto-currency where the devs do everything. This is our coin, its a community coin. Don’t sit around screaming at the website yelling “why is there no content”. Do something!
+
+#### Riccardo
+
+Just make it! Just to reiterate Monero is starting to achieve a level of visibility that is really outstripping its usability to some degree. People are become ever more interested in it while we are still working on the fundamentals.  Having a website that is easy to navigate, that has content, terms and explains to people how to get going is critical. We have done a lot of that but there is tons more. When it comes to translation, we should not use terms that are too technical. When we do need to use technical terms we should make sure there is a Moneropedia entry (even a short one) to define that so there is no confusion.
+
+#### Gingeropolous
+
+Well thank you fluffypony for the conversation and thank you listeners for tuning in. Until next week
--- a/_posts/2015-09-14-monero-missive-for-the-week-of-2015-09-14.md
+++ b/_posts/2015-09-14-monero-missive-for-the-week-of-2015-09-14.md
@ -0,0 +1,434 @@
+---
+layout: post
+title: Monero Missives for the Week of 2015-09-14
+summary: An interview with the creators of MoneroDice, a new Monero gaming site
+tags: [monero missives, external]
+author: Riccardo Spagni (fluffypony)
+forum: https://forum.getmonero.org/1/news-announcements-and-editorials/2378/monday-monero-missives-32-september-14th-2015
+---
+
+<div class="text-center"><iframe style="border: none" src="//html5-player.libsyn.com/embed/episode/id/3798493/height/360/width/640/theme/standard-mini/direction/no/autoplay/no/autonext/no/thumbnail/yes/preload/no/no_addthis/no/" height="600" width="600" scrolling="no"  allowfullscreen webkitallowfullscreen mozallowfullscreen oallowfullscreen msallowfullscreen></iframe></div>
+
+To download the podcast directly please [use this link to the MP3](http://traffic.libsyn.com/monero/Monero_Missives_Podcast_for_the_week_of_2015-09-14.mp3), or [this link to the AAC/MP4](http://traffic.libsyn.com/monero/Monero_Missives_Podcast_for_the_week_of_2015-09-14.mp4), or [this link to the FLAC](http://traffic.libsyn.com/monero/Monero_Missives_Podcast_for_the_week_of_2015-09-14.flac).
+
+In this week's episode we feature a brand new external project: [Monero Dice](https://monerodice.net/), and interview its founders and operators, Riccardo "fluffypony" Spagni, and rznag.
+
+Until next week!
+
+# Podcast Transcription
+
+#### Riccardo "fluffypony" Spagni
+
+Hello everyone and welcome to yet another Monero Missive. I am Riccardo (fluffypony) and with me today I have Gingeropolous
+
+#### Gingeropolous
+
+Hello everyone, this is Gingeropolous
+
+#### Riccardo
+
+And also today we have rznag, joining us from sunny Europe.
+
+#### rznag
+
+Hi.
+
+#### Riccardo
+
+So, we are going to cover another external project. This is a brand new external project, and it's one that I have started so I suppose Gingeropolous is going to be interviewing me...surprise!
+
+#### Riccardo
+
+So basically after the demise of cryptocoinsdice, which you may recall, was the first dice site to support Monero, and then the owner decided to do a runner with everyone's money. There was a gap that opened up for a reliable Monero dice site, and I thought, well hey, you know, let me take that up and run with it.
+
+#### Gingeropolous
+
+Don't run with it!
+
+#### Riccardo
+
+haha good one, let me take that up and –walk- with it, in a circle, not going anywhere. With that said...
+
+#### Gingeropolous
+
+In a ring signature
+
+#### Riccardo
+
+To that end rznag and I have gotten together and we are launching Monero Dice, a very unexpected name, very original. We were going to call it Dark Flarb Dice, but unfortunately we were worried about copyright issues
+
+#### Gingeropolous
+
+Why not Dice-aro?
+
+#### Riccardo
+
+Dice-aro, because no one would be able to spell it.
+
+#### Gingeropolous
+
+Hmmm
+
+#### Riccardo
+
+So, Gingeropolous - have you played around with the test site?
+
+#### Gingeropolous
+
+No I have not. I have mainly played dice with that bastard Tippero, he's taken a lot of my Monero. Well, what are some of the interesting and unique features of your dice site?
+
+#### rznag
+
+It's for Monero. 
+
+#### Gingeropolous
+
+Well that is unique and interesting
+
+#### Riccardo
+
+And we will not run.
+
+#### Gingeropolous
+
+How do we know you will not run? What is your anti-run mechanism?
+
+#### Riccardo
+
+Well, you see, I think what you better ask yourself is, would a rznag, and a fluffypony make off with Monero?
+
+#### Gingeropolous
+
+Would you make off with Monero? I hope not. So rznag, why don't you tell us about the provable fair features of Monero Dice?
+
+#### rznag
+
+Okay. Provably fair? You can check out the source for single draws or if you, if you roll your dice, you will see that hash that and can calculate it for yourself to see that it is fair.
+
+#### Gingeropolous
+
+Cool, cool...I don't know how to do that
+
+#### Riccardo
+
+It's very complicated, very technical. We promise, I give you the fluffypony guarantee that it's, that it's fair. Okay? Okay, well I mean, the other thing is we got an autoroll system, so traditionally if people wanted to play a bunch of successive roles on a dice site, then they would have to write an API, or write a little program that uses API or whatnot, and we forego that by having an autoroll system, that is designed to allow ordinary folk to click a button and off it goes. And it doesn't do martindale, martingayle, whatever that stupid thing is called, but it just does rolls, you know? In a row, successive, forever, however many you want.
+
+#### rznag
+
+And as long as you have credit.
+
+#### Riccardo
+
+Yes, till you run out of money.
+
+#### Gingeropolous
+
+Hmm, alright, I have logged in now. So, so say I wanted to get rich, how would I do that by investing in Monero Dice?
+
+#### Riccardo
+
+If you wanted to get rich I think we are in the wrong industry.
+
+#### Gingeropolous
+
+Well I mean. You know
+
+#### rznag
+
+You should deposit some Monero, roll the dice, and then you should have luck perhaps, that's the thing, perhaps not. So it could work out, but most not.
+
+#### Gingeropolous
+
+Yea, but can people bankroll Monero Dice? I mean, that's apparently a thing.
+
+#### rznag
+
+Yes, we have an invest feature. You can, invest into the bank and then if other players lose, the money goes into the bankroll, and is split into for the investors.
+
+#### Gingeropolous
+
+Okay
+
+#### Riccardo
+
+And obviously there is no guarantee of making money  because you are basically contributing to the bankroll. So if the site makes a loss, then the investors lose as well, and if the site makes a profit, then the investors profit. But it's important to understand that, and I think that this is key – that when you are dealing with a gambling site, which effectively this is, or a gaming site, that the house edge is the thing that balances out. So the house edge is the thing that makes sure that we don't shut down after two weeks, because we've bled money.
+
+#### Gingeropolous
+
+Right, right
+
+#### Riccardo
+
+But at the same time, the house edge can work both ways. So I mean we can, we can sort of lose money for a time and then get back up
+
+#### Gingeropolous
+
+So how would I know that my funds are actually secure on this dice site, you know if I have to deposit my Monero in order to play.
+
+#### rznag
+
+You can secure your account with 2 Factor Authentication to have a basic security mechanism on your account, and also we are storing funds in a cold wallet system, so we don't have much in our hot wallet.
+
+#### Gingeropolous
+
+Okay
+
+#### Riccardo
+
+Which is of course beneficial, because it wouldn't be the first time that a site got “hacked” and just disappeared with money.
+
+#### Gingeropolous
+
+Okay, so cold storage and 2 factor authentication. So, I'm not critiquing you guys for your efforts, but you know this is one of those comments that is sure to come to fruition due to the nature of cryptocurrency space now, and all of the “investors”- or the critics that don't develop themselves, but just hope that others will make them rich. fluffypony, you're a core developer of Monero, so, the first thing that's going to come up is "Oh the core developer is not developing the core, and he's just making these dice sites...why!?" "Why? Why is this happening?"
+
+#### Riccardo
+
+So look, it's a valid point, and I think it's important to understand. We had a discussion, on Bitcointalk the other day where a very dear friend of mine, a guy that's close to my heart, Blockafett, came into the Bitcointalk thread, and he had such gentle and soothing words to say, and we got into a discussion about Monero investors. And I think this is important to understand, cause I explained our role as a core team, and how it relates. And this is such an important thing to understand because as a core team, our role as stewards of Monero is to push this technologically interesting project forward. However, obviously we want to make money, but the way we are going to make money is not by adjusting the emission curve, or by mining, -accidentally- mining 5% of the entire emission in the first 36 hours. You know, by means of an example unrelated to anything else. But that's not the way you make money - it's a cryptocurrency, it's not an investment opportunity. There's no sort of reward for buying Monero, there shouldn't be a reward for buying any currency. And unfortunately, because Bitcoin went through a stage where it spiked from being well under a dollar to being over a thousand dollars over a period of a couple of years, you end up with this um, this, this line of reasoning that people have which is, if Bitcoin can do it, we can too, and can you imagine if you owned 100 000 Bitcoin when it was still really cheap and blah blah blah. But, that's the wrong way to look at it - it's a medium of exchange and it's a store of value. If the valuation of that store of value changes over time, that's great, congratulations, you've by virtue of that earned some money, but that's not really the point. The point is, money should be made regardless of how that valuation changes, unless you are a currency trader. So, currency traders will, you know, set up hedgefunds, and, and do day trading between the Euro and the Dollar, or whatever.
+
+#### Gingeropolous
+
+Right
+
+#### Riccardo
+
+And they'll make money through that. But ordinary people and you're really wealthy people like Warren Buffet, and Mark Zuckerburg and whoever - the way they make money is not by currency trading. So investing in a cryptocurrency is fundamentally stupid, if that's what you are trying to do ...I don't know how else to put it. The way they make money is buy building stuff like Zuckerburg made Facebook, or stole Facebook from the Winklevoss twins or whatever the case is. You know, and Buffet as well, I mean, Buffet goes and invests in companies and yada yada. 
+
+#### Gingeropolous
+
+Yea
+
+#### Riccardo
+
+So that's his thing, and the reason that we're moving forward with Monero Dice is precisely for that reason. I'm not trying to make money, and rznag's not trying to make money by buying a whole bunch of Monero and then saying, “well I hope it goes up in value.” Instead we're going, “hey, let's make money by building something that makes money.”
+
+#### Gingeropolous
+
+Mhhmm
+
+#### rznag
+
+The services and there's an environment that push the cryptocurrency as a result.
+
+#### Riccardo
+
+Yea
+
+#### Gingeropolous
+
+Yea, build an environment to actually use the currency as a currency.
+
+#### rznag
+
+Yea
+
+#### Riccardo
+
+Yea, not try and get rich by fudging some numbers in the cryptocurrency's emission curve.
+
+#### Gingeropolous
+
+But, that works so well!
+
+#### Riccardo
+
+No, apparently it does. That's why it keeps happening.
+
+#### Gingeropolous
+
+Its kind of related, but is there a cut of proceeds that's going to funnel down to the core, or is it that because fluffypony is involved, that it's going to the core.
+
+#### Riccardo
+
+Yea, well, that's pretty much it. So, the earnings that I make from this will go to core development, definitely right now and for the foreseeable future. Obviously if at some stage in the future, core development is self-sustaining, then, I probably won't need to give 100% of my earnings to core development, but since the core team's mostly paying for core development out of our pockets, it really, you know it doesn't make sense for me to withhold any of my Monero Dice earnings.
+
+#### Gingeropolous
+
+Gotcha. I thought of a potential other interesting question that's not finance related. In terms of actually developing this sort of application, how much knowledge of the Monero core is necessary - is this all RPC, API...whatever...
+
+#### Riccardo
+
+JSON
+
+#### Gingeropolous
+
+At the interface level. Is this at the interface level of dealing with Monero, or does it go further than that.
+
+#### rznag
+
+No, it's just at interface level. It's RPC and, RPC, API, JSON, we communicate directly with the daemon and the wallet and get data from there by API. So, in the end, not something very complicated.
+
+#### Gingeropolous
+
+Gotcha, but apparently something that's very easy to run with.
+
+#### Riccardo
+
+Yes...run away!
+
+#### Gingeropolous
+
+Bastards
+
+#### Riccardo
+
+Let's qualify what we, what we mean when we say run away, not run
+
+#### Gingeropolous
+
+Yea, I'm sorry
+
+#### Riccardo
+
+But, I think the other thing that's come out of this, that's been quite cool is that rznag's written a little test system in Python that uses the the Tippero Python Library, and that's great for system automators, or merchants, or developers that are using Monero. The whole ecosystem's starting to build up now, where there are a lot of libraries with tools to test them, and so, I think the more that stuff happens over time, the easier it's going to be for integrators to just like say, “ok, I'm going to take this library and use it”, rather than sitting in #Monero-dev IRC channel and asking for help.
+
+#### Gingeropolous
+
+Right, right, awesome. Is this software opensource? Is this on GitHub?
+
+#### Riccardo
+
+It is not. One of the things that I'd like to do at a later stage, is put the-the secret sauce that's in the provably fair stuff, to sect that out and put that on Git-Hub. Because I do think that, when it comes to being provably fair, the fundamental aspect of it is, “is there a piece of code that I can compare?” And secondly, are the hashes made available now and maybe even in perpetuity. Really, it should be simple for someone to grab a piece of code, put the-the hash in and go, “okay cool, that's the output that I expected.”
+
+#### Gingeropolous
+
+Gotcha. Somewhat related to that, I finally stumbled upon the “provably fair” part of it. In the settings, I see hash of current server seed, current notch number, and, your current seed. So, this all looks fine and well, I have no idea what it all is. So how could I go like, “oh look at these numbers, this is probably fair.”
+
+#### rznag
+
+Okay, you can recalculate all of that numbers, the hashes, and verify at the end it's provably fair. With these numbers and so on, you can recalculate it, and see that we did the correct calculation.
+
+#### Gingeropolous
+
+Oh, the calculation for what? That's what I'm lost on.
+
+#### rznag
+
+For when rolled, for the result of your dice roll. We show random, but it's not that random, not completely random.
+
+#### Gingeropolous
+
+Alright, so hash of the current server seed, that is, a hash of a current server seed, which makes absolutely zero sense to me.
+
+#### Riccardo
+
+Okay, so the way it works is, you've got, the server seed, and you've got your individual user seed. Okay? And then you've got the nonce.
+
+#### Gingeropolous
+
+Okay.
+
+#### Riccardo
+
+And then what happens is that nonce, that nonce increases or changes for every roll. Okay?
+
+#### Gingeropolous
+
+Yea
+
+#### Riccardo
+
+So, the server seed is global, everyone shares the same server seed that server seed can reset under various circumstances and it can roll-over. And your user seed can also change, reset, whatever, based on either user request or based on certain circumstances, and the way it works is, every single role, it takes the server seed, it takes your seed, it takes the nonce, and squishes them all together and uses that as the seed for the roll. And in the next roll, it will do the same thing.
+
+#### Gingeropolous
+
+Ok, so that's how the random is generated
+
+#### Riccardo
+
+Yea, and that's super simplified, but it gives you an idea of the relation. So, even though it is random and you can't go and predict the roll in advance, it also means that you can after the fact, go and verify it quite easily
+
+#### Gingeropolous
+
+Okay, so, theoretically, if I knew how to squish the numbers together, I could take this information, in the settings column, and then squish it, and get an output, and then go back to the, the actual rolling, and then perform the same thing there and see my odds and go, “ah, they are similar, or they are the same.” Right?
+
+#### Riccardo
+
+Yes, that is correct.
+
+#### Gingeropolous
+
+Okay, okay, so for those out there that know how to squish the numbers together, you can do it.
+
+#### Riccardo
+
+You can be a number squisher too.
+
+#### rznag
+
+Get your code on Github
+
+#### Riccardo
+
+Yes, eventually, one day, soon™. Thanks very much for the chat and rznag, thanks for joining us
+
+#### rznag
+
+Yes, thank you too. 
+
+#### Gingeropolous
+
+Yea, thank you guys for the chat, and thanks everyone for listening. I hope you enjoy these Monero Dice; roll away, invest away, number squish away, do what you will.
+
+#### Riccardo
+
+Don't run away
+
+#### Gingeropolous
+
+Yea, trust that this one's not running
+
+#### Riccardo
+
+It is running, but we're not running...there is, there's running that is happening, but it's not the bad running, it's the good running.
+
+#### Gingeropolous
+
+Good luck people translating this to other languages, I hope that there's as much nuance with –running- in other languages.
+
+#### Riccardo
+
+Allright
+
+#### Gingeropolous
+
+And tune in next week, there'll be, who knows, another external project, another what-ever-the-other-one's are called.
+
+#### Riccardo
+
+Dev Diary.
+
+#### Gingeropolous
+
+Dev Diary, that's one, and what's that final one?
+
+#### Riccardo
+
+Monero Missive.
+
+#### Gingeropolous
+
+Oh, yea, okay. I'm sure they're all Monero Missives. Anyhoo, find out next week, what we'll talk about. Alright.
+
+#### Riccardo
+
+Yea
+
+#### Gingeropolous
+
+Well, I think that the caffeine worked today folks, so I hope you have a good day, 
+
+#### Riccardo
+
+Cheers
+
+#### Gingeropolous
+
+Or a good night.
+
+#### rznag
+
+Bye
+
+#### Gingeropolous
+
+Bye
--- a/_posts/2015-12-26-monero-missive-for-the-week-of-2015-12-26
+++ b/_posts/2015-12-26-monero-missive-for-the-week-of-2015-12-26
@ -0,0 +1,17 @@
+---
+layout: post
+title: Monero Missives for the Week of 2015-12-26
+summary: An interview with psi, from the I2P project, and an announcement of the Monero Kovri project
+tags: [monero missives, kovri]
+author: Riccardo Spagni (fluffypony)
+---
+
+<div class="text-center"><iframe style="border: none" src="//html5-player.libsyn.com/embed/episode/id/4038955/height/360/width/640/theme/standard-mini/direction/no/autoplay/no/autonext/no/thumbnail/yes/preload/no/no_addthis/no/" height="600" width="600" scrolling="no"  allowfullscreen webkitallowfullscreen mozallowfullscreen oallowfullscreen msallowfullscreen></iframe></div>
+
+To download the podcast directly please [use this link to the MP3](http://traffic.libsyn.com/monero/Monero_Missives_Podcast_for_the_week_of_2015-12-26.mp3), or [this link to the AAC/MP4](http://traffic.libsyn.com/monero/Monero_Missives_Podcast_for_the_week_of_2015-12-26.mp4), or [this link to the FLAC](http://traffic.libsyn.com/monero/Monero_Missives_Podcast_for_the_week_of_2015-12-26.flac).
+
+In this week's episode we interview psi, from the I2P project, and also announce the new Monero Kovri project, an open-source C++ router.
+
+The source can be found here: [https://github.com/monero-project/kovri](https://github.com/monero-project/kovri)
+
+Until next week! (this is now a running joke...right guys?)
--- a/_posts/2016-01-01-monero-0.9.0-hydrogen-helix-released.md
+++ b/_posts/2016-01-01-monero-0.9.0-hydrogen-helix-released.md
@ -0,0 +1,69 @@
+---
+layout: post
+title: Monero 0.9.0 "Hydrogen Helix" Released
+summary: A major release in Monero's history, too much to summarise!
+tags: [releases]
+author: Riccardo Spagni (fluffypony)
+---
+
+*January 1st, 2016*
+
+## Summary of Changes
+
+Too much to describe. Represents a major release in Monero's history, over a year-and-a-half in the making. Some highlights:
+
+- moved from in-RAM database to a backend-agnostic blockchain database
+- created an LMDB blockchainDB implementation (with the help of Howard Chu, the creator of LMDB)
+- created a BerkeleyDB blockchainDB implementation
+- created an OS-agnostic raw blockchain format
+- built tools to convert between blockchain implementations, as well as import and export them
+- added ARM support
+- brought back 32-bit support (WIP)
+- added QoS (bandwidth control)
+- added [OpenAlias](https://openalias.org) support
+- fixed all (previously broken) unit tests and core tests
+- implemented daemonize for proper backgrounding of the Monero daemon
+- drastically increased sync speed
+- included block headers in the source
+- designed and implemented a stealth payment ID scheme
+- designed and implemented a unified address+payment ID scheme
+- implemented a hard fork mechanism
+- changed the block time to 2 minutes
+- implemented the [MRL-0001](https://lab.getmonero.org/pubs/MRL-0001.pdf) and [MRL-0004](https://lab.getmonero.org/pubs/MRL-0004.pdf) recommendations
+- added tons of simplewallet / rpcwallet / daemon commands
+- added a dust handler to simplewallet
+- created a multilanguage mechanism, implemented in simplewallet
+- bug fixes, bug fixes, bug fixes
+- completely overhauled the CMake (with the help of Kitware, the creators of CMake)
+- added a bad peer auto-banning mechanism
+- refactored a ton of code, added a ton of comments
+- added a core crypto implementation based on SUPERCOP ref10
+- switched to a triangular distribution for output selection
+- added multiple new mnemonic wordlists, including Russian and Italian
+- created a "trusted daemon" system for remote daemon use
+
+In total this represents 922 commits worth of work by 9 contributors. This will probably be the biggest release in Monero's history, everything from here on out can be done as faster point releases.
+
+## Updating: Blockchain Conversion
+
+It is highly recommended that you delete the contents of your Monero working directory and sync from scratch. This directory can be found in ```~/.bitmonero``` on Linux and OS X, and on Windows in ```\Users\username\AppData\Roaming\bitmonero``` or ```\ProgramData\bitmonero```.
+
+Syncing from scratch is EXTREMELY fast in this version, pretty much at bittorrent speeds, and will leave you with a fully verified blockchain.
+
+*Alternatively*: if you want to grab the bootstrap (NOTE: there is a new bootstrap format!) off the website then you can get it at https://downloads.getmonero.org/blockchain.raw - once downloaded you can import it with ```blockchain_import --input-file /path/to/your/download.raw```. If you're particularly brave you can pass the ```--verify 0``` flag to skip verification during import.
+
+*If you REALLY want to convert your old blockchain*: you can either use the ```blockchain_converter``` tool, or you can use ```blockchain_export``` to create a blockchain.raw, followed by ```blockchain_import``` to import it into the new LMDB format.
+
+## Official Download Links
+
+- [Windows, 64-bit](https://downloads.getmonero.org/monero.win.x64.v0-9-0-0.zip)
+- [OS X, 64-bit](https://downloads.getmonero.org/monero.mac.x64.v0-9-0-0.tar.bz2)
+- [Linux, 64-bit](https://downloads.getmonero.org/monero.linux.x64.v0-9-0-0.tar.bz2)
+
+## Download Hashes
+
+If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes:
+
+- monero.win.x64.v0-9-0-0.zip, c61284c4d5f78db2bc2072bef76f2b539293cca74bdd3fb9536a35ca54b4fd2e
+- monero.linux.x64.v0-9-0-0.tar.bz2, 655875a899aded6d63f99c5dfea6a45b3e77533bb2173e63612646ec7ac97100
+- monero.mac.x64.v0-9-0-0.tar.bz2, fce5140d9cb38d62ad1b9f1b0d06feaa209433f9ec542b8d368ef9e0da431b78
--- a/_posts/2016-01-15-monero-0.9.1-released.md
+++ b/_posts/2016-01-15-monero-0.9.1-released.md
@ -0,0 +1,37 @@
+---
+layout: post
+title: Monero 0.9.1 Released
+summary: A point release of Monero Hydrogen Helix to prevent a repeat of the block 913193 attack
+tags: [releases]
+author: Riccardo Spagni (fluffypony)
+---
+
+*January 15th, 2016*
+
+## Summary of Changes
+
+This has urgent and important bug fixes to 0.9.0 *Hydrogen Helix*
+
+- Bug fix for the block 913193 attack, plus checkpoints
+- Restored CMake 2.9 support
+- Added --password-file option to simplewallet
+- Various fixes for building on ARM
+- Fixed importing with verify off
+
+## Official Download Links
+
+- [Windows, 64-bit](https://downloads.getmonero.org/monero.win.x64.v0-9-1-0.zip)
+- [Windows, 32-bit](https://downloads.getmonero.org/monero.win.x86.v0-9-1-0.zip)
+- [OS X, 64-bit](https://downloads.getmonero.org/monero.mac.x64.v0-9-1-0.tar.bz2)
+- [Linux, 64-bit](https://downloads.getmonero.org/monero.linux.x64.v0-9-1-0.tar.bz2)
+- [Linux, 32-bit](https://downloads.getmonero.org/monero.linux.x86.v0-9-1-0.tar.bz2)
+
+## Download Hashes
+
+If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes:
+
+- monero.win.x64.v0-9-1-0.zip, 1e2650d598dd995a40591596bde75cbad7af0b42d9dadedd0b70b9a2f49bc0e8
+- monero.win.x86.v0-9-1-0.zip, 425b1c1c52dbaeeb277a25463668e1adc6699980490e5632ae0c07d36035a8ea
+- monero.mac.x64.v0-9-1-0.tar.bz2, dfd2740939a8eeed0e044232b2654d9255ca894ee5d6022c1258b6268e63185f
+- monero.linux.x64.v0-9-1-0.tar.bz2, 4aa6a890e49f7813e7999530415a0f7440c5b446991363f99469794d524efdad
+- monero.linux.x86.v0-9-1-0.tar.bz2, d41e16bf7a9adc40201d79f89de70b7fe97f05ad82895fc3b6ed2b1192203a1d
--- a/_posts/2016-01-31-overview-and-logs-for-the-dev-meeting-held-on-2016-01-31.md
+++ b/_posts/2016-01-31-overview-and-logs-for-the-dev-meeting-held-on-2016-01-31.md
@ -0,0 +1,359 @@
+---
+layout: post
+title: Overview and Logs for the Dev Meeting Held on 2016-01-31
+summary: Dev branch, style guide, Collective Code Construction Contract
+tags: [dev diaries, core, crypto]
+author: gingeropolous
+---
+
+*January 31st, 2016*
+
+# Summary
+
+## Use of dev branch
+
+First thing discussed is the dev branch. Contributors have fell back into the habbit of merging stuff to master. All hacking should be done onto dev branch.
+
+Apparently this is because of bugs. A new point release to fix the v1/v2 stuck transaction bugs is coming.
+
+The thing holding up general move to development branch is that CZMQ/0MQ hasn't been bundled in source, so its a pain to compile. Everyone agrees to bundle CZMQ/0MQ into dev branch. fluffypony will get it in the source tree.
+
+There is more talk about minor tweaks that should or shouldn't go into the upcoming point release.
+
+## Style guide
+
+In Kovri they've been working with [a style guide](https://github.com/monero-project/kovri/blob/master/CONTRIBUTING.md#style), and fluffypony suggests implementing one in Monero. Basically, this is the way the code is formatted (human formatted).
+
+Its agreed to use the new style with new code, and restyle-as-you-go with old code. Restyling for the sake of restyling is though to be unnecessary. Key points:
+
+> we assume from this point on the code is indented like the majority of the code so far - 2 spaces, not tabs, not 4 spaces.
+
+> push harder on "code should go in a .cpp not .h"
+
+## Collective Code Construction Contract (C4)
+
+As used in 0MQ as [described here](http://rfc.zeromq.org/spec:22)
+
+The idea is to merge every PR as long as it doesn't break the build. Aim is to avoid PR-hell where everyone comments on a PR for days and weeks and it never gets merged, because its never "perfect." Merge-everything is done so that contributors establish a history, and they can be banned if they are repeat offenders.
+
+In general, the idea is agreed upon. However, there is concern and uncertaintly regarding the roles of the various branches and how the contract applies to which branches. The conversation bleeds into ringCT implementation and timeframe and how the c4 would affect this process. The fact that 0MQ-dev branch is currently unusable is brought up regarding how the c4 would function. It is noted that 0MQ was pushed to dev because the original contributor couldn't continue working on it. Ultimately the 0MQ situation will not happen again.
+
+Ultimately, this issue will be brought up at the next meeting.
+
+## Keep hacking around things or dump stuff for things that are easier
+
+This is a lot of meta-code stuff. The thing that was salient to me was the doxygen-compatible approach, which would allow newcomers to the code to become acquainted more efficiently.
+
+## Thanks!
+
+fluffypony extends his gratitude to all contributors, and everyone makes their way to the reception hall for bacon wrapped shrimp, pigs in blankets, and all other sorts of tiny foods that hover on discs.
+
+# Logs
+
+**\<fluffypony>**  who are we missing  
+**\<fluffypony>**  tewinget / othe / warptangent / NoodleDoodle you guys around?  
+**\<warptangent>**  ^  
+**\<fluffypony>**  hokay  
+**\<dEBRUYNE>**  smooth?  
+**\<fluffypony>**  smooth and luigi1111w are around  
+**\<fluffypony>**  although luigi1111w is using some other nick  
+**\<fluffypony>**  luigi1112 I think  
+**\<luigi1114>**  4  
+**\<moneromooo>**  mario1114  
+**\<fluffypony>**  lol  
+**\<fluffypony>**  about a year ago we did this using TeamSpeak  
+**\<fluffypony>**  I mean Mumble  
+**\<luigi1114>**  for you guys  
+**\<fluffypony>**  which was nice, but it isn't as fluid as typing because sometimes you can't hear that someone else is talking  
+**\<binaryFate>**  Firechat? Was cool  
+**\<fluffypony>**  binaryFate: no we did a couple of actual dev meetings   
+**\<fluffypony>**  but it's tough to sustain  
+**\<binaryFate>**  Oh ok  
+**\<xmrpromotions>**  I think typing is fine too.  
+**\<ArticMine>**  This is fine  
+**\<fluffypony>**  agreed  
+**\<fluffypony>**  plus there are people working on Monero that would prefer not to have to use a voice changer just to participate :-P  
+**\<fluffypony>**  ok so there are a few things on the agenda   
+**\<luigi1111>**  I'm sick so my voice is already changed  
+**\<warptangent>**  the format seems to have been working well for kovri too  
+**\<fluffypony>**  the first thing I think we should discuss is the dev branch   
+**\<fluffypony>**  we've fallen back into the habit of merging stuff to master  
+**\<moneromooo>**  That's because bugs  
+**\<fluffypony>**  I know  
+**\<fluffypony>**  we're going to have to do a point release to fix the v1/v2 / stuck transactions bugs  
+**\<fluffypony>**  are there any bug fixes waiting in the wings, or should we do that next week?  
+**\<moneromooo>**  That last commit thing, which I'll have to think about a bit more.  
+**\<moneromooo>**  Also, possibly merging the per-tx bits in lmdb.  
+**\<hyc>**  which?  
+**\<moneromooo>**  tx_{unlocks,heights,outputs}  
+**\<hyc>**  ah  
+**\<moneromooo>**  And output_{keys,amounts,indices,txs}  
+**\<hyc>**  DB format change, I don't think that's a bug-fix  
+**\<moneromooo>**  Way more of htose than blocks  
+**\<fluffypony>**  maybe we need to consider a more generalised approach to format changes   
+**\<fluffypony>**  something like Laravel's migrations  
+**\<fluffypony>**  it'll have to be per-DB-format anyway   
+**\<fluffypony>**  per-DB-type I mean  
+**\<warptangent>**  i've got schema changes i've been using for a couple months, for better use on hdd, but they aren't bug fixes.  
+**\<warptangent>**  two sets of bug fixes not yet added though  
+**\<fluffypony>**  ok if they're not considered crucial for 0.9.x then we can put them into dev?  
+**\<hyc>**  warptangent: since I've been working on the same thing, I guess I should take a look at your stuff  
+**\<warptangent>**  1. berkeleydb support for importer - almost ready, some argument usage cleanup  
+**\<moneromooo>**  Once I re-merged then  
+**\<hyc>**  but I don't consider anything I'm looking at now as bug-fix  
+**\<fluffypony>**  (this is how we meeting http://i.imgur.com/OR5ZVoI.jpg)  
+**\<warptangent>**  2. finish hf fix for importer - mostly done, pending some cleanup with bdb  
+**\<fluffypony>**  hokay  
+**\<hyc>**  (I have a wineglass here too, sadly empty)  
+**\<warptangent>**  hyc: yes, that would be good. i think i mentioned the tx changes last month to avoid as many subdbs with tx hash keys  
+**\<fluffypony>**  also I think the thing that's holding up a general move of effort to dev is that we haven't bundled CZMQ / 0MQ in source, which makes compiling a bit painful  
+**\<fluffypony>**  any objections to the bundling?  
+**\<luigi1111>**  how much of a pain is it to change formats?  
+**\<hyc>**  I haven't even looked at dev. no objection from me  
+**\<fluffypony>**  luigi1111w: mostly just requires copying data to a new table and nuking the old one  
+**\<moneromooo>**  Hmm. I have a few patches to czmq, to make things build.  
+**\<moneromooo>**  Not super sure whether it was me being dumb or not though.  
+**\<fluffypony>**  ok well moneromooo, maybe post-bugfix do you want to do the merge from master to dev, and then plonk those patches on?  
+**\<fluffypony>**  I'll get it in the source tree the meantime, and cmake-ify all of the things  
+**\<moneromooo>**  I'll merge yes. Then you can add zmq to the cmake stuff :P Then I'll add my patches if they're still needed.  
+**\<moneromooo>**  Great, ty  
+**\<fluffypony>**  great minds think alike  
+**\<fluffypony>**  ok next I'd like us to chat about a style guide  
+**\<fluffypony>**  we've been working on one in Kovri that we can possibly use for Monero  
+**\<fluffypony>**  https://github.com/monero-project/kovri/blob/master/CONTRIBUTING.md#style  
+**\<hyc>**  oh, I do have one outstanding - tweak to BlocchainLMDB::get_estimated_batch_size - change batch_safety_factor to get blockchain_import to succeed on 32bit  
+**\<fluffypony>**  not necessary to read the style guide now, just more a general sense of if everyone is comfy with *a* style guide, and if anyone has any particular preferences   
+**\<smooth>**  i have no objection to any reasonable style guide but i do object to re-styling of existing code  
+**\<moneromooo>**  Pages and pages of stuff ? :|  
+**\<moneromooo>**  I object too, if it's only restyling for the sake of it.  
+**\<fluffypony>**  ok so more of a restyle-as-you-go   
+**\<moneromooo>**  That massive reindent patch already caused me grief  
+**\<fluffypony>**  which is in line with our refactor-as-you-go approach  
+**\<ArticMine>**  Apply the style guide to new code  
+**\<smooth>**  imo the best policy is keep the style on small chages to existing code and new style on new code  
+**\<smooth>**  there is probably a gray area there  
+**\<warptangent>**  should we assume from this point on the code is indented like the majority of the code so far - 2 spaces, not tabs, not 4 spaces.  
+**\<hyc>**  agreed  
+**\<fluffypony>**  warptangent: that's the one area where we differ from Kovri, I'd lean towards yes  
+**\<moneromooo>**  I tend to keep the style of whatever I'm hacking on. And I doubt I'll read all that google style guide thing. I'd prefer we use common sense.  
+**\<warptangent>**  moneromooo: style on the current project though, not different styles per file, right?  
+**\<moneromooo>**  Whatever code I'm modifying.  
+**\<moneromooo>**  It causes the least problems.  
+**\<fluffypony>**  moneromooo: don't worry about the Google style guide, the 16 points we've put in for Kovri are more what I was referring to  
+**\<warptangent>**  the majority of files are one style in the codebase, with a few that became some kind of hybrid at one point  
+**\<moneromooo>**  Oh OK.  
+**\<moneromooo>**  With that out of the way...  
+**\<fluffypony>**  ok - everyone happy with that as a general starting point? I can dump those points in and then we can take pull requests on it if anyone wants to refine / change things  
+**\<warptangent>**  yes, seems good  
+**\<hyc>**  I would push harder on "code should go in a .cpp not .h"  
+**\<fluffypony>**  hyc: agreed  
+**\<fluffypony>**  I'll make it clearer  
+**\<fluffypony>**  moneromooo: did you want to raise a point, or were you saying we can move on?  
+**\<hyc>**  overall it looks sane to me  
+**\<moneromooo>**  I'm good.  
+**\<fluffypony>**  ok   
+**\<fluffypony>**  next point is also administrative in nature  
+**\<fluffypony>**  we'd like to adopt the Collective Code Construction Contract that 0MQ uses, as a guide for project administrators and for contributors  
+**\<fluffypony>**  http://rfc.zeromq.org/spec:22  
+**\<fluffypony>**  we can discuss it more in future, but the long and the short of it  
+**\<fluffypony>**  is that we merge every PR as long as it doesn't break the build  
+**\<fluffypony>**  if it does something bad / dangerous we can have a follow up PR to revert  
+**\<fluffypony>**  but the aim is to avoid PR-hell where everyone comments on a PR for days and weeks and it never gets merged  
+**\<fluffypony>**  because it's never "perfect"  
+**\<fluffypony>**  so merge, create issues on Github where something is lacking (eg. new feature, little or no tests - create issues for tests)  
+**\<moneromooo>**  This PR-hell problem's never happened, has it ?  
+**\<fluffypony>**  moneromooo: not in Monero yet, but Bitcoin is chock-full of it  
+**\<gingeropolous>**  ^ this is for dev branch, right?  
+**\<moneromooo>**  I think common sense is again a better thing than going the opposite extreme.  
+**\<fluffypony>**  gingeropolous: this is in general  
+**\<warptangent>**  i haven't read the zeromq document thoroughly, but does it leave room for the common sense aspect?  
+**\<fluffypony>**  moneromooo: the problem is that there are lots of nuanced situations where "common sense" isn't that common :-P  
+**\<smooth>**  i dont think there should be an arbitrary merge policy on master, but it is already stated by me that i dont think anything but tagged releases should go on master  
+**\<moneromooo>**  Well, if it's nuanced, fine.  
+**\<fluffypony>**  warptangent: it does, yes  
+**\<fluffypony>**  as explained by Pieter to binaryFate and I last year  
+**\<smooth>**  if the concept of only taggest releases on master is no adopted then i would oppose going even further in the other direction  
+**\<smooth>**  *tagged  
+**\<fluffypony>**  smooth: yes that's a given  
+**\<fluffypony>**  master represents a stable, tagged release  
+**\<fluffypony>**  we work in dev  
+**\<fluffypony>**  anyone that submits a PR to master gets it closed and asked to submit it to dev  
+**\<fluffypony>**  anyway what I wanted to say, is that Pieter explained that the reason that you want to merge-all-of-the-things and then revert something bad is that you have a historical record of the bad actor   
+**\<smooth>**  there needs to be a place for bug fix releases though  
+**\<binaryFate>**  I'm with you fluffypony. 0MQ founder/leader feedback on this approach was extremely valuable.  
+**\<moneromooo>**  There's also the potential thing about not being able to use the 0mq version in time for the next 6-month fork. It wasn't exactly usable yet last I hacked on it.  
+**\<binaryFate>**  Common sense might work now, long term with a higher market cap we'll face same issues as btc  
+**\<binaryFate>**  Where common sense diverges and the code Base ossifies  
+**\<xmrpromotions>**  As a non programmer smooths comment seems like the safer approach. Thank you for clarifying the master vs dev branch issue fluffy. http://rfc.zeromq.org/spec:22 sounded scary as applied to PRs sent to master before dev  
+**\<fluffypony>**  smooth: it doesn't preclude it  
+**\<fluffypony>**  moneromooo: as it stands we're probably going to push the fork date out a little to see if we have enough room to work on RingCT, so that's fine  
+**\<binaryFate>**  What's the envisionned time scale for ringct?  
+**\<smooth>**  the idea of a historical record is good  
+**\<hyc>**  we have similar issues with OpenLDAP - you need 3 branches  
+**\<hyc>**  one for dev, one for released code, and one for release bugfixes  
+**\<smooth>**  but i would make the case then that 0MQ should be reverted since it is unusable  
+**\<hyc>**  particularly when dev and release are far apart  
+**\<smooth>**  im not actually proposing this because i know it would be a mess, but making a point for the future  
+**\<hyc>**  like now, where dev has 0MQ and release doesn't  
+**\<fluffypony>**  smooth: I agree - moneromooo and I will play around with it next week and make a decision   
+**\<moneromooo>**  Reverting isn't really possible.  
+**\<fluffypony>**  moneromooo: we could drop dev and re-branch  
+**\<moneromooo>**  But one could add ringCT to a new branch based on master.  
+**\<fluffypony>**  if it came to that, I mean  
+**\<moneromooo>**  That'd be a lot of pain. I'd rather not. Much better to hack on master and merge do dev again.  
+**\<fluffypony>**  ok  
+**\<smooth>**  imo something like zeromq should be developed on a separate branch somewhere, until it is actually usable  
+**\<moneromooo>**  s/on master/on a branch based off master/  
+**\<fluffypony>**  smooth: it was usable-ish, we might have regressed some in fiddling   
+**\<moneromooo>**  Yes, that.  
+**\<fluffypony>**  anyway - let's evaluate and figure out  
+**\<moneromooo>**  I think I added all missing RPC so it cn be used, just not by people who want it to work without problem.  
+**\<dnaleor>**  **\<fluffypony> moneromooo: as it stands we're probably going to push the fork date out a little to see if we have enough room to work on RingCT, so that's fine <= I welcome this. Just wanted to say that imho it's important to have RingCT active in the september/october hard fork. Carry on. i'm watching  
+**\<hyc>**  doing all new work in dev is fine, but backporting bugfixes to release will become non-trivial as more features are added to dev  
+**\<fluffypony>**  hyc: I guess it depends on the importance of a bug fix  
+**\<moneromooo>**  It looks to me like ring CT is going to need a lot of changes to bitmonerod/CN. September looks very close.  
+**\<fluffypony>**  we'll see   
+**\<fluffypony>**  I don't think we need to create a pressure-cooker for it  
+**\<fluffypony>**  ok can I go on?  
+**\<ArticMine>**  There are trade offs here. I see problems if dev and master deviate materially  
+**\<xmrpromotions>**  it seems like 3 branches as smooth mentioned would be easiest for everyone in long run even if it requires more effort now. 1.dev 3. release and bug fixes  
+**\<fluffypony>**  xmrpromotions: otoh we can backport fixes straight into master to allow for immediate testing by affected parties  
+**\<ArticMine>**  With bug fixes as a transition from dev to master  
+**\<fluffypony>**  again depends on the nature of the bugfix   
+**\<fluffypony>**  like warptangent's work on BDB and the importer probably aren't critical enough to go into master  
+**\<warptangent>**  the importer works properly when it has the hard fork support though, and that uses the bdb support  
+**\<moneromooo>**  If someone wants to rewrite that hard fork code, btw, you're welcome. I don't like it, and I'm not sure how to improve it.  
+**\<ArticMine>**  My concern is master deviating materially from a quasi stable dev  
+**\<fluffypony>**  ArticMine: something like ringct would have to be done in both master and dev  
+**\<ArticMine>**  So a project based on master would need a major rewrite after a tagged release  
+**\<fluffypony>**  we did dual-PRs for a while  
+**\<fluffypony>**  we can do them again  
+**\<fluffypony>**  might be easier than The Grand Merge  
+**\<smooth>**  something like ringct should only be in dev imo  
+**\<ArticMine>**  Yes anything fundamental has to be done in parallel  
+**\<smooth>**  until it gets released of course  
+**\<fluffypony>**  I think let's defer further discussion of this till the next meeting  
+**\<luigi1111>**  agreed to both  
+**\<fluffypony>**  we don't have enough info on the ringct effort or on the state of the dev branch right now anyway  
+**\<binaryFate>**  One thing I miss in discussion is what is master purpose? Do we want to encourage users to compile from it? How is master gonna diverge from tag release between them?  
+**\<ArticMine>**  I agree and lets carefully review the zeromq rfc in the meantime  
+**\<moneromooo>**  I think large things should go to their own branch (ie, ringct). Smaller things can share branches (to dev). Both end up being merged to master when ready.  
+**\<fluffypony>**  binaryFate: no matter what we say people clone and build master  
+**\<gingeropolous>**  **\<- this guy  
+**\<fluffypony>**  it doesn't matter how much we encourage building a tagged release  
+**\<fluffypony>**  so we made a decision ages ago that master would be stable  
+**\<fluffypony>**  so that anyone pulling and building master doesn't get some hacky, broken branch  
+**\<binaryFate>**  Ok  
+**\<fluffypony>**  moneromooo: I don't know if we want topic branches in the main repo, but perhaps a more generalised "staging" branch, as long as anything going to that is also PRd to dev  
+**\<moneromooo>**  It can be in any repo.  
+**\<smooth>**  i think not in the main repo is fine  
+**\<moneromooo>**  Like I was hacking on tewinget's branch for a while.  
+**\<fluffypony>**  yeah that's a good point  
+**\<luigi1111>**  +1  
+**\<fluffypony>**  as long as that person is around and accepting PRs it's perfect  
+**\<warptangent>**  then one big PR to dev when it's ready?  
+**\<moneromooo>**  If we go to a dev/master setup, how does dev get merged to master anyway ?  
+**\<warptangent>**  that has worked before, yes  
+**\<hyc>**  yeah, keep main repo relatively clean  
+**\<luigi1111>**  a new feature can get a sort of "lead dev"  
+**\<fluffypony>**  moneromooo: when we release we merge from dev to master and tag master  
+**\<luigi1111>**  and contributers can hack on his repo  
+**\<moneromooo>**  So master becomes a copy of dev at that point ?  
+**\<fluffypony>**  yes  
+**\<ArticMine>**  Yes but a six month cycle could be too long  
+**\<smooth>**  thats a different issue  
+**\<smooth>**  how often to have major releases  
+**\<fluffypony>**  we can do major releases whenever, as long as we have major fork releases every 6 months  
+**\<smooth>**  also are releases time based or feature based  
+**\<luigi1111>**  kinda both ?  
+**\<fluffypony>**  yeah both  
+**\<hyc>**  feature-based is all that makes sense to me  
+**\<ArticMine>**  The merge to master may need to be more frequent than major fork releases  
+**\<moneromooo>**  feature based, but the rolling hard fork also pulls time based I think.  
+**\<fluffypony>**  yes  
+**\<binaryFate>**  Those Dev -> Master merges would happen with what kind of tagging? Point fix? Even more frequent?  
+**\<fluffypony>**  binaryFate: depends on how stable dev is  
+**\<luigi1111>**  so new features thus shouldn't be in dev until they are working properly/ready for release  
+**\<luigi1111>**  because of timed releases  
+**\<smooth>**  time based means that if you have 6 features in progress and one doesn't work in time, you do the release anyway, without the unfinished feture  
+**\<fluffypony>**  smooth, luigi1111: yes, you're both right  
+**\<luigi1111>**  it works as long as the half finished feature isn't partially merged  
+**\<luigi1111>**  or whatever  
+**\<fluffypony>**  the only reason 0MQ got pushed to dev anyway was because oranjuice could no longer work on it, and it was basically done  
+**\<fluffypony>**  but I think let's make it the last time that happens  
+**\<fluffypony>**  then we avoid complication  
+**\<warptangent>**  ok  
+**\<moneromooo>**  tbh I'd be tempted to not really care about people building master. If it's said clearly to use a release if you don't know what you're doing, then it's your problem.  
+**\<smooth>**  i agree with ArticMine that we can have releases sooner than 6 months  
+**\<gingeropolous>**  ah ok. so how the 0MQ happened is not how it will be in future  
+**\<binaryFate>**  Agree with moneromooo  
+**\<fluffypony>**  ok guys we're running overtime, so let's drop this for now, we can pick it up again later  
+**\<smooth>**  i think it is simply unnecessary to merge to master  
+**\<smooth>**  er sorry, commit unreleased stuff to master  
+**\<moneromooo>**  I think one of the problems with 0mq is that oranjuice kinda left  
+**\<smooth>**  any developer can handle getting the latest stuff from someone ele  
+**\<smooth>**  *somewhere else  
+**\<moneromooo>**  So it jsut had to be merged  
+**\<ArticMine>**  Let get back to this question at the next meeting  
+**\<fluffypony>**  ok  
+**\<fluffypony>**  last two things   
+**\<smooth>**  yup  
+**\<fluffypony>**  the first is that we have some major efforts coming up, besides ringCT, and things like epee, the 3 (THREE!!!) different logging systems, and a bunch of unused stuff is going to get in the way  
+**\<fluffypony>**  I'd like us to decide whether we want to keep hacking around things  
+**\<moneromooo>**  Does epee really get in the way ?  
+**\<fluffypony>**  or if we want to spend the effort now dumping this stuff for things that are easier  
+**\<hyc>**  it makes 32bit builds murder. but if we can abandon 32bit, that problem disappears too  
+**\<moneromooo>**  epee does ?  
+**\<hyc>**  yeah  
+**\<fluffypony>**  moneromooo: yes it does; it made QoS an absolute nightmare to do  
+**\<fluffypony>**  and it's still not done properly  
+**\<moneromooo>**  We'd have a replace a lot of stuff.  
+**\<ArticMine>**  32bit especially on windows is going to be around for a long time  
+**\<dEBRUYNE>**  + TAILS  
+**\<moneromooo>**  And a lot of somewhat low level stuff.  
+**\<warptangent>**  the multiple logging systems situation is strange, but i don't think it's interfered with current work. is there any knowledge on rfree's likelihood of returning?  
+**\<fluffypony>**  warptangent: low to impossible at the moment  
+**\<fluffypony>**  I mean, we can rip and replace the logging stuff with boost::log  
+**\<fluffypony>**  all the console stuff can go ncurses or similar   
+**\<smooth>**  id be more in favor of specific items like that, done on feature branch  
+**\<fluffypony>**  and the wire protocol can go ZMTP, since we have a 0MQ dep anyway  
+**\<fluffypony>**  eventually we'll get to a point where we're no longer reliant on epee  
+**\<moneromooo>**  I agree with the bit by bit approach.  
+**\<warptangent>**  that sounds manageable  
+**\<fluffypony>**  also then we'll actually have usable Doxygen docs  
+**\<smooth>**  the thing to bear in mind is this has virtually zero end user benefit, if not actually zero  
+**\<fluffypony>**  yes  
+**\<fluffypony>**  on the flip side, we can plug the GUI in via 0MQ instead of monero-as-a-library  
+**\<moneromooo>**  Well, the benefit is said to be for 32 bit users.  
+**\<fluffypony>**  so we have a shortcut of sorts there  
+**\<fluffypony>**  (in terms of users clamouring for stuff)  
+**\<fluffypony>**  moneromooo: and long-term viability   
+**\<fluffypony>**  we've had potential contributors ask for an architectural doc for the code, and get turned off when there isn't one  
+**\<fluffypony>**  so there's scope to slowly bring the codebase in line  
+**\<smooth>**  i dont believe there is anything about the current code that precludes a GUI. After all, BBR has one with basically the same code.  
+**\<hyc>**  huh.. contributors that are turned off so easily ... I wouldn't expect much use out of them if they stayed  
+**\<moneromooo>**  I was kinda thinking that too...  
+**\<fluffypony>**  I guess, but tbh it does make the project seem significantly less mature  
+**\<fluffypony>**  which I guess is fair, it's not even 2 years old  
+**\<gingeropolous>**  less hurdles, more good  
+**\<smooth>**  it is somewhat hard to come up to speed with the code, i would agree with that  
+**\<fluffypony>**  alright  
+**\<fluffypony>**  last thing so we can wrap up  
+**\<fluffypony>**  I just wanted to deeply thank everyone who has contributed and who continues to contribute to Monero development, whether it is Monero's core, the website, any other peripheral projects  
+**\<fluffypony>**  both on behalf of the core team, and on behalf of the community   
+**\<fluffypony>**  you all do an amazing job, and we've done a truckload of work in 2014 and 2015  
+**\<fluffypony>**  so here's to an amazing 2016  
+**\<gingeropolous>**  hear hear! thank you fluffypony for herding the cats so good  
+**\<Bassica>**  hear hear!  
+**\<xmrpromotions>**  thank you!  
+**\<ArticMine>**  Thanks for all the good work  
+**\<fluffypony>**  thus concludes the first meeting, next one in two weeks  
+**\<warptangent>**  thanks fluffypony  
+**\<luigi1111>**  thanks  
+**\<binaryFate>**  Thanks to you fluffy (enjoy that wine)! Thanks to all of you, awesome community.  
+**\<dEBRUYNE>**  Thanks fluffypony!  
+**\<hyc>**  **\<glug> thanks all  
+**\<Infinite_Jest>**  is there a buffet?  
+**\<fluffypony>**  Infinite_Jest: snacks will be served in The Grand Ballroom in 15 mins  
+**\<Infinite_Jest>**  ok great :) but seriously thanks!  
+**\<cardboardoranges>**  thanks fluffy
--- a/_posts/2016-02-10-monero-missive-2015-year-in-review.md
+++ b/_posts/2016-02-10-monero-missive-2015-year-in-review.md
@ -0,0 +1,159 @@
+---
+layout: post
+title: Monero Missive Special Edition - 2015 Year in Review 
+summary: A review of everything Monero accomplished in 2015
+tags: [monero missives, year in review, core, funding, accounts, usability, platforms, gui, exchanges, i2p, 0mq, kovri, blockchaindb]
+author: Riccardo Spagni (fluffypony)
+forum: https://forum.getmonero.org/1/news-announcements-and-editorials/2481/monero-missive-special-edition-2015-year-in-review
+---
+
+*February 10th, 2016*
+
+Hello, and welcome to a special edition of the Monero Missives: the 2015 Year in Review!
+
+As you may know (or may not know:) we had an extremely busy January, which has led to this Missive taking its sweet time in being finalised.
+
+## State of Monero: 2015
+
+The past year has been an interesting one for Monero. There was something of a reckoning as speculators realised that Monero was never going to be a pump-and-dump, rushing out a flashy GUI and ill-conceived features with no regard to the security of the network or the safety of our users. Those that stuck it out have seen steady, constant progress and steady, constant community growth.
+
+{:.text-center}
+![Project Stats 2015 Overview](/blog/assets/2015-year-in-review/stats.jpg)
+
+**Governance**
+
+Over the course of 2015 we have considered Monero's governance model. In the context of cryptocurrencies and consensus systems, the term "governance" seems to be quite taboo. However, for anyone that has ever been involved in an open-source project, a lack of governance is as good as a death knell. An [excellent article](http://oss-watch.ac.uk/resources/governancemodels) on governance models is maintained by OSS Watch, and they point out the reason for this:
+
+> There are almost as many variations of open source management strategies as there are open source projects. It is therefore critical that a project clearly communicates its policies and strategies to potential users and developers of the project’s outputs. A clear governance model also allows potential contributors to understand how they should engage with the project, what is expected of them and what protections are provided to ensure that their contributions will always be available to them. In addition, it describes the quality control processes that help to assure potential users of the viability of the project. The development and communication of a clear and concise governance model is one of the most important steps a project can take towards sustainability through open development.
+
+Of course, we are primarily talking about the governance of the open-source project (ie. the source code in the [monero-project](https://github.com/monero-project/bitmonero) repositories and associated systems and structures). The Monero network itself cannot be governed, and as has already happened just after Monero's launch, the project can be forked and effectively taken over if the core project is no longer considered viable. If that is the case, why bother with governance at all? Over and above the reasons mentioned in the OSS Watch article, it is important to prevent a gridlock in decision making. There are going to be decisions in Monero's future that will be extremely difficult to make, and if there's no clear path as to *how* they can be made then the project is very unlikely to grow.
+
+When considering a governance model for Monero our main aim has been to find a balance between pure community consensus on the one hand, and the Core Team operating as "benevolent dictators for life" on the other. Neither of these governance models are desirable on their own, but there is a mixture of the two that we feel is well-suited to Monero. It is effectively the workflow we used last year when a decision had to be made on whether or not to change Monero's emission curve (ultimately it was decided against doing so); this is the workflow for decision making:
+
+- An idea is pitched by someone, whether via a Github issue, IRC in #monero-dev, the Monero Forum, or elsewhere, and discussion ensues. The preferred forums for discussion around an idea would be as a Github issue or a Monero Forum thread.
+- If there are no major objections, or objections are responded to and the idea is refined accordingly, this will be deemed enough for "rough community consensus", or "lazy consensus". A good indicator of community consensus, in many instances, would be if it is an idea that requires funding, and the community successfully funds the effort.
+- In the event of the community being unable to reach general consensus on the matter within a reasonable period of time (typically a couple of weeks to a few months, dependent upon the complexity of the idea), the matter will be referred to the Core Team.
+- The Core Team will set a date for a meeting on the matter, normally to be held within a week or two. They will review all written material before the meeting.
+- The meeting will be held between the members of the Core Team on IRC, openly visible to the community at large, and logs will be made available after. A maximum time limit will be set for the meeting.
+- Members of the Core Team will be given an opportunity to state their views, vote (using the voting system detailed below), and discuss the matter at length, within the time limit of the meeting.
+- To conclude the meeting, the members of the Core Team will tally the votes that have been cast on the matter during the discussion and forward the decision to the community.
+
+{:.text-center}
+![Governance Process Overview](/blog/assets/2015-year-in-review/governance-process.jpg)
+
+The Core Team, as well as individual contributors, can participate in all related discussions, but their opinions are not absolute or perfect. Community members are encouraged to test and push arguments, regardless of who is making them, until they are satisfied that the idea or change is workable or worth the risks.
+
+The voting system that the Core Team uses is based on the CentOS voting system. Votes are not cast permanently, so a member can cast a vote at the beginning of the meeting and change it several times throughout. In order from disagreement to agreement, the following votes can be cast:
+
+- Veto vote (-1). This is generally discouraged, unless it is accompanied by substantive arguments rooted in project-relevant criteria (protecting the community, economic reasons, technical reasons)
+- Reservations vote (-1 or 0). Either a neutral vote, or a negative vote, coupled with reservations and concerns that are stated with the vote.
+- Stand aside vote (0). A neutral vote, which can be accompanied with some reservations, but which does not seek to block the vote.
+- Supporting vote (+1). Supports the proposal / idea / change. The voter would be expected to also indicate whether or not they will personally assist in driving the effort if successful.
+
+In the absence of any vetoes, the votes are tallied, which gives both the result of the vote as well as an indication of the amount of support (or lack thereof). If the votes add up to a negative or positive amount then the outcome is clear. If the votes add up to 0 that is normally an indication of no support and only small reservations, in which case the matter is not blocked by the vote, but it is also not particularly supported. In this event the Core Team may choose to hold another vote, optionally at a subsequent meeting a week or two later, if the matter is such that it requires more positive support.
+
+Our hope is that this process will prevent Monero from falling prey to "design by committee", but also prevent "design by Wikipedia" or "design by the person with the loudest mouth / most eloquent writing". This process is currently up for discussion and comment; please feel free to provide input on it.
+
+**Core Team**
+
+Due to the formalisation of the governance of the project, and the clarification of the Core Team's role as stewards, members of the Core Team are expected to be active on an ongoing basis. If a member of the Core Team cannot be regularly active, it is expected that they will step down from their role on the Core Team; the remaining members can elect to replace them if they wish.
+
+With that in mind, two members are no longer going to form part of the Core Team due to time constraints: *David Latapie* and *eizh*. Both of them have been part of Monero since its inception and the formation of the Core Team. We are immensely grateful for their efforts in the past, and any efforts from them in the future.
+
+We have also elected two new members to the Core Team: *Franciso "ArticMine" Cabañas*, and *luigi1111*. Francisco is based in Canada, and holds a PhD in Physics and brings extensive business and non-profit experience to the table. He has actively researched and invested in cryptocurrencies since 2011, and focuses on the economic, social, regulatory, and long-term viability aspects of cryptocurrencies. luigi1111 hails from the Midwestern United States and is a sysadmin by day. He has been actively involved in several cryptocurrencies since 2013, and loves cryptography, probability, and English grammar.
+
+We welcome them to the Core Team, and look forward to working with them both going forward.
+
+**Finances**
+
+Our financial situation has dramatically changed with the introduction of the Forum Funding System (FFS). We still have core expenses, some of which include the servers hosting our infrastructure, our test / build hosted machines, annual domain registration for core / MoneroPulse / MoneroSeeds domains, LibSyn's hosting and syndication of our Missives podcast, CloudFlare's services, our GitHub micro plan, and so on. We are quite grateful for those that have continued to send donations to the core fund, and where possible we have also used those to kickstart Forum Funding System fundraisers.
+
+As mentioned in 2014's Year in Review, the founding members of the Core Team all put in a large portion of funds over the course of 2014, amounting to around 164.5 BTC, when donations were scarce. At this juncture we have not sought to recover those funds, as our focus is on building Monero up, recovering our donations at some later stage, if ever.
+
+Some [highlights of the FFS over the year](https://forum.getmonero.org/9/work-in-progress) include:
+
+- [tewinget's Documentation and Cleanup of Source Code](https://forum.getmonero.org/9/work-in-progress/2373/documentation-and-cleanup-of-source-code): raised 3600 XMR in 23 contributions; completed 3/4 milestones.
+- [moneromoo's initial fundraiser for 6 months of work](https://forum.getmonero.org/22/completed-tasks/334/fund-a-developer-moneromoo-will-work-part-time-on-monero-for-260-hours-over-approx-6-months): raised over its target of 7800 XMR in 45 contributions; completed all 6 milestones.
+- [moneromoo's second fundraiser for for about 10 additional months of work](https://forum.getmonero.org/9/work-in-progress/2410/a-continuation-for-all-purpose-programming-of-what-needs-to-get-done-in-monero): raised 18000 XMR in 21 contributions; completed 3/10 milestones thus far.
+- [Shen Noether's translation of some of the website content into Chinese](https://forum.getmonero.org/9/work-in-progress/329/translation-of-content-on-getmonero-org-into-chinese): raised 950 XMR from a target of 600 XMR in 9 contributions; completed its milestone.
+- [Shen Noether's fundraiser to complete the C++ implementation of RingCT](https://forum.getmonero.org/9/work-in-progress/2450/ring-ct-c-crypto): raised 3150 XMR in 13 contributions; has very nearly reached completion of all 7 of its milestones.
+- [Wolf0's very efficient AMD miner](https://forum.getmonero.org/9/work-in-progress/2400/open-source-amd-miner-by-wolf0): raised 7750 XMR in 20 contributions; completed 6/7 milestones.
+- (just sneaking a 2016 one in:) - [Ilya Kitaev's initial funding to complete the Monero Core GUI](https://forum.getmonero.org/9/work-in-progress/2476/the-official-qt-gui-project): raised just over its 14000 XMR target in a matter of hours; work has just begun.
+
+In total, excluding the GUI fundraiser, the FFS raised just over 48260 XMR over the course of 2015. Virtually all of the fundraisers were for direct open-source code development, and no payouts were made until a milestone had been met, and the community had reviewed the code and confirmed that the milestone had been achieved.
+
+We can safely say that the FFS has been a fantastic success thus far, and we hope to see more projects being funded of a development nature, as well as of a promotional and educational nature (such as community members covering their costs if they go speak at a conference).
+
+The FFS exists in a centralised manner today, but in the future we hope to host it in a more decentralised fashion (eg. using Tahoe-LAFS) and couple it with future systems like MoneroID and MoneroTrust.
+
+**Donation Addresses**
+
+For general housekeeping purposes we have decided to roll-over the donation addresses every so often, perhaps every year or two. Please take note of the new address details below. We have updated the donate.getmonero.org OpenAlias and other references, but pool operators and anyone else that auto-donates will need to update their systems accordingly. We will maintain the old addresses for some time, but will likely only check them sporadically and move any funds to the new addresses.
+
+Monero Donations: [44AFFq5kSiGBoZ4NMDwYtN18obc8AemS33DBLWs3H7otXft3XjrpDtQGv7SqSsaBYBb98uNbr2VBBEt7f2wfn3RVGQBEP3A](monero:44AFFq5kSiGBoZ4NMDwYtN18obc8AemS33DBLWs3H7otXft3XjrpDtQGv7SqSsaBYBb98uNbr2VBBEt7f2wfn3RVGQBEP3A?recipient_name=Monero%20Development&tx_description=Donation%20to%20Monero%20Core%20Team) (view key: f359631075708155cc3d92a32b75a7d02a5dcf27756707b47a2b31b21c389501)  
+Bitcoin Donations: [1KTexdemPdxSBcG55heUuTjDRYqbC5ZL8H](bitcoin:1KTexdemPdxSBcG55heUuTjDRYqbC5ZL8H?label=Monero%20Development&message=Donation%20to%20Monero%20Core%20Team)
+
+**Design and Development Goals**
+
+During the course of 2015 we published a set of [Design and Development Goals](https://getmonero.org/design-goals/) focused not only on pure development, but also on research goals that the Monero Research Lab are pursuing. Typically the development goals are smaller, more immediate, and easier to achieve, whereas some of the research goals might not even be feasible, and others could take many years to find a suitable solution.
+
+Nevertheless, over the course of 2015 we managed to complete 7 of the development goals and 2 of the research goals:
+
+- *LMDB embedded database implementation*: the Lightning Memory-Mapped Database is the brainchild of Howard Chu, who has become quite actively involved in the Monero Project. Our implementation of LMDB in Monero has led to a truly massive reduction in memory usage of the daemon, down to well under 100mb of real memory in use, whilst still remaining exceptionally performant.
+- *Daemonize*: instead of being forced to run the Monero daemon in the foreground, this effort allows for it to fork to the background, but still be able to interact with and query the daemon. On Windows computers it can even install itself as a system service.
+- *BerkeleyDB fall-back database implementation*: initially this was added as an acid test for our generic blockchain database class, but proved useful when we hit LMDB issues on 32-bit and ARM systems (subsequently resolved).
+- *32-bit and ARM support*: we lost 32-bit support when the in-RAM database started requiring more than 4gb of RAM. Thankfully, our blockchainDB work, as well as the LMDB and BDB implementations, brought this back, and allowed us to add ARM support as a bonus!
+- *Various synchronisation improvements*: thanks to a vastly improved synchronisation mechanism a brand new Monero node can completely sync up with the network from scratch in as little as 45 minutes.
+- *ØMQ and TLS support for RPC*: currently only available in the development branch, this is part of a series of underlying changes that will make Monero far more extensible and flexible in the future, and will allow for more secure integration for merchants and other developers.
+- *Stealth & serialised payment IDs*: this started off as something that had to be researched and figured out, but thanks to some clever work by luigi1111 and others this is integrated in the 0.9 codebase.
+- *RingCT*: as mentioned in Academic Research section, this goal has been achieved, and the C++ code for it is nearing completion.
+
+In many ways Monero's long-term design goals represent a fundamental shift in focus. Monero's primary use, at this point, is as a private store of value and medium of exchange. But since Monero has a global, decentralised, censorship-resistant timestamping database, there is a world of functionality that can be bolted on top. Thus, the aim with Monero is for it to become more than just a private cryptocurrency; we want Monero to become an entire suite of easy-to-use tools and systems designed to enhance personal privacy.
+
+**Releases**
+
+During 2015 we kept our collective heads down, focusing on the gargantuan effort required to get the database implementation running smoothly and implement the MRL-0004 guidelines. This culminated in the release of Monero 0.9 *Hydrogen Helix* on the first day of 2016. A full list of the changes can be found on the release page: https://github.com/monero-project/bitmonero/releases/tag/v0.9.0
+
+We'd like to extend our gratitude to the 19 contributors that invented, developed, hacked, wrote, tested, broke, fixed, and built Monero's core code over 2015: moneromooo-monero, warptangent, Thomas Winget, Riccardo Spagni, rfree, smooth, NoodleDoodle, Howard Chu, Sergey Kazenyuk, luigi1111, Shen Noether, Rostislav, Brendan Telzrow, Lex Kalinkin, sammy007, Wladimir van der Laan, David Vorick, roman, and meshpoint.
+
+Over the year there were 904 commits made to the main Monero repository, plus quite a few more to the development branch. Using the same methodology we applied in the previous Year in Review, this means:
+
+| Statistic | 2014 | 2015 | Total |
+|---|---|---|---|
+| Weeks of Development | 35 | 52 | 87 |
+| Days of Development | 245 | 365 | 610 |
+| Commits | 594 | 904 | 1498 |
+| Contributors | 11 | 19 | 30 |
+| Modified Lines | 10 221 | 5 342 | 15 563 |
+| New Lines | 12 706 | 263 288 | 275 994 |
+| Removed Lines | 32 | 514 | 546 |
+
+
+**Academic Research**
+
+The Monero Research Lab also had a busy 2015. Two main efforts were completed during the year:
+
+- *[MRL-0004: Improving Obfuscation in the CryptoNote Protocol](https://lab.getmonero.org/pubs/MRL-0004.pdf)* - this was a major research effort that analysed the failures highlighted in [MRL-0001](https://lab.getmonero.org/pubs/MRL-0001.pdf), as well as uncovered some others, and presented a number of solutions to these. The solutions presented in MRL-0004 were incorporated in the Monero hardfork coming up in March, 2016.
+- *[MRL-0005: Ring Signature Confidential Transactions for Monero](https://lab.getmonero.org/pubs/MRL-0005.pdf)* - based on [the excellent work of Bitcoin Core developer, Greg Maxwell](https://people.xiph.org/%7Egreg/confidential_values.txt), this couples Confidential Transactions with Monero's Ring Signatures, efficiently hiding transaction values on the blockchain, and thus crossing a major privacy threshold. Once implemented this will make Monero the first cryptocurrency in production and in use that cryptographically obscures transaction values, where the transaction inputs come from, and where the transaction outputs are going to.
+
+**Kovri**
+
+One of the areas that Monero has long been focusing on is disconnecting the link between a transaction and the IP address of the node that was first observed broadcasting it, as this information often reveals the IP address of the transaction originator. Severing this link is vital, and it is not merely enough to support this functionality optionally through networks like Tor; it needs to be native and an inherent part of the Monero protocol.
+
+With that in mind, our work with members of the I2P community has progressed from initially being involved with i2pcpp, to i2pd, and finally to an initiative from a few months ago: the Kovri I2P Router. Initially forked from a branch of i2pd, the Kovri project stands on its own in the Monero stable. It is not a mere side project, but a large fully fledged open-source project.
+
+Nearly 2300 commits from 37 contributors have lead to just under 30000 lines of code, and the effort is ongoing. You can follow Kovri's progress on the Github repo: [https://github.com/monero-project/kovri](https://github.com/monero-project/kovri)
+
+**Monero Website**
+
+At the beginning of 2015 we opened the Monero Forum. But we didn't stop there - the Monero website was also overhauled and released as a brand new site, powered by Jekyll, with a look-and-feel matching the Monero Forum. The website is open-source and can be found here: [https://github.com/monero-project/monero-site](https://github.com/monero-project/monero-site)
+
+Since its inception, the Monero website has had over 320 commits from 14 contributors. The community has been fantastic at supporting the initiative and helping shape the information on the site. As we roll out new tools to make contributing to the site even easier, we can only expect this to grow.
+
+**Looking Forward: 2016**
+
+We accomplished a great deal in 2015, with ever more to do. In 2016 we are hoping to tick more items off of our Design and Development Goals, and continue the slow and steady move towards Monero becoming a privacy suite.
+
+We hope you will continue with us on this journey, and we look forward to an excellent 2016!
+
+Your Core Team - Riccardo "fluffypony" Spagni, luigi1111, NoodleDoodle, smooth, tacotime, Franciso "ArticMine" Cabañas, othe
--- a/_posts/2016-02-14-overview-and-logs-for-the-dev-meeting-held-on-2016-02-14.md
+++ b/_posts/2016-02-14-overview-and-logs-for-the-dev-meeting-held-on-2016-02-14.md
@ -0,0 +1,284 @@
+---
+layout: post
+title: Overview and Logs for the Dev Meeting Held on 2016-02-14
+summary: Further dev branch discussions, 0.9.2 release date, RingCT implementation, DB migrator 
+tags: [dev diaries, core, crypto]
+author: gingeropolous
+---
+
+*February 14th, 2016*
+
+# Summary
+
+## Review
+
+Lots of stuff done in the past 2 weeks:
+
+- v2 block tests
+- flattened CMake issues (DNSSEC will work again)
+- the possibilities of inconstent database state and the mempool transactions "have been clobbered"
+
+Amongst other stuff not mentioned, but copying here from moneromoos milestone work:
+
+- fixes for the wallet creating txes over max size the daemon will accept
+- more work on tests (including tests for the MRL-0004 changes)
+- going through all the V1/V2 stuff to catch what I saw was wrong
+- fix for txes not expiring from pool due to other nodes coming online regularly
+- better handling of pending/failed txes in simplewallet
+- new command/RPC to flush txes from the txpool
+- preventing two daemons from using the same data dir concurrently
+- more intelligent handling against duplicate outs
+
+## RingCT
+
+Shen is almost done with reference code, volunteers needed to actually implement. warptangent takes on the db stuff. 
+
+https://github.com/ShenNoether/MiniNero/tree/master/brief
+
+When RingCT gets merged, will be a good time to merge other database formats. DB format changes - build a converter that "upgrades" format changes. It's left open, but hyc agrees to tackle it later. 
+
+## Dev Branch
+
+This has become the bastard child of Monero development apparently. Lines 82 - 167 encompass discussion on this topic. The goal is "to merge back to the dev branch" Ultimately the decision is to hack at it for a bit and reevalauate in next meeting. 
+
+> <moneromooo> What I'll do it hack at it to make it work better, really. All that's needed is time without the problem of a release coming too quick.
+
+Godspeed moneromooo. 
+
+## Hardforks
+
+The next fork (RingCT) will be the last time any modifications of the hardfork schedule are permitted. 
+
+# Logs
+
+**\<fluffypony>** welcome everyone  
+**\<fluffypony>** first off, thanks for being present  
+**\<fluffypony>** lots has been done in the last couple of weeks  
+**\<fluffypony>** moneromooo hit another milestone on his FFS fundraiser, so good job on that  
+**\<fluffypony>** he also clobbered some major issues (v2 block tests etc)  
+**\<hyc>** here  
+**\<fluffypony>** warptangent has also been a monster in the last couple of weeks  
+**\<fluffypony>** flattened CMake issues that we were struggling with  
+**\<fluffypony>** so that means that our static builds now do DNSSEC resolution again, even when a local DNSSEC root key is not available   
+**\<fluffypony>** (which is basically on every Windows box)  
+**\<fluffypony>** which means we need to evaluate our 0.9.2 release  
+**\<fluffypony>** is there anything urgent that needs to go into 0.9.2, or can we push that out?  
+**\<fluffypony>** (besides open PRs, I mean)  
+**\<hyc>** I've got nothing pending  
+**\<warptangent>** with the updates to block handling, the possibilities of inconstent database state was addressed(block height and hf versions not matching)  
+**\<warptangent>** issues there were most urgent on my mind last time  
+**\<fluffypony>** yeah, that and the mempool transactions were the two biggies  
+**\<fluffypony>** both have been clobbered   
+**\<warptangent>** there are some bdb updates i'm finishing up, but they aren't urgent.  
+**\<fluffypony>** moneromooo: anything from your side?  
+**\<moneromooo>** No  
+**\<smooth>** saberhagen reporting in  
+**\<fluffypony>** hah hah  
+**\<warptangent>** !!  
+**\<fluffypony>** better late than never :-P  
+**\<warptangent>** he was here two years ago. we are the ones late  
+**\<fluffypony>** well apparently he was here 5 years ago :-P  
+**\<dEBRUYNE>** warptangent: 2 years? Make that 4-5  
+**\<DaveyJones>** 4 years please :)  
+**\<fluffypony>** hah hah  
+**\<warptangent>** :)  
+**\<fluffypony>** ok so  
+**\<fluffypony>** let's talk about RingCT  
+**\<fluffypony>** shen is getting close-to-done on his reference implementation code  
+**\<fluffypony>** but it requires some actual implementation, and some DB work, to actually integrate it  
+**\<fluffypony>** I think someone needs to volunteer to chiefly run with that  
+**\<fluffypony>** any takers?  
+**\<warptangent>** i'm up for db stuff  
+**\<fluffypony>** ok it's mostly in here: https://github.com/ShenNoether/MiniNero/tree/master/brief  
+**\<fluffypony>** there's been some discussion in the MRL as to what is actually required   
+**\<fluffypony>** I'll ask Shen to make some notes   
+**\<fluffypony>** next up  
+**\<hyc>** I guess that will be a good time to merge other DB format changes too  
+**\<fluffypony>** yes  
+**\<fluffypony>** definitely  
+**\<fluffypony>** re: DB format changes, we would need to build in a converter that "upgrades" format changes  
+**\<fluffypony>** I was thinking something like Laravel's migrations would work (I think I mentioned this last time)  
+**\<fluffypony>** so if I'm on format v1 there are migrations in the code to v2, v3, v4, v5, and it just runs them in succession till I'm on current  
+**\<fluffypony>** that way the code only actually needs to know how to interact with the latest format  
+**\<fluffypony>** and the logic of getting there from any arbitrary previous version lives in migrations  
+**\<fluffypony>** (that are specific to implementations)  
+**\<fluffypony>** we can either generalise that, or just do that for LMDB and leave other implementations to handle it to their liking  
+**\<warptangent>** yeah that sounds good, but it can get involved too, because migrations typically are run on full-featuerd dbs like postgres and mysql that cover a lot of abstractions  
+**\<warptangent>** so when you change a field, it handles the data migration and protects the database consistency if it's interrupted  
+**\<fluffypony>** I don't think we'd be able to handle interruptions easily  
+**\<fluffypony>** maybe dump it into a temp db and then rename?  
+**\<warptangent>** here, if we're transferring 3 subdbs into one consolidate subdb, for instance, if that gets interrupted, it will be some trouble to deal with resuming  
+**\<fluffypony>** so that way there's no resuming, it's restarting and wiping out any existing temp dbs  
+**\<warptangent>** oh that is far easier, sure  
+**\<hyc>** yeah, that tells me we really just want an offline dedicated migrate tool  
+**\<warptangent>** a more integrated form of export and import  
+**\<fluffypony>** hyc: I thought about that, the problem is that people are going to just upgrade ->** restart the daemon  
+**\<fluffypony>** and then if it chokes and says "run this tool" they'll get frustrated  
+**\<fluffypony>** also we have to automate it for the GUI too because GUI users...  
+**\<moneromooo>** We don't really need to bother, there's a version field.  
+**\<moneromooo>** So you could create the new dbs, then set the field to new version.  
+**\<moneromooo>** If it's interrupted, it will recreate the new dbs, erasing the partial ones.  
+**\<fluffypony>** as long as new dbs have unique names never used in previous ones  
+**\<moneromooo>** At least for the tx/block subdb work anyway.  
+**\<hyc>** we can append version# to the name if we want similar names  
+**\<fluffypony>** yeah  
+**\<fluffypony>** ok - I'll create that as an issue, does anyone want to have it assigned to them, or should I just leave it open for now?  
+**\<smooth>** is the problem that the migration can't run as a transaction because the amount of data being moved is too large?  
+**\<hyc>** leave open for now, but I'll probably take it later  
+**\<hyc>** smooth - yeah, pretty much  
+**\<hyc>** the txn can be that large but it slows down quite a bit then  
+**\<smooth>** for some migrations that should be okay though (depending on how much the format is being changed)  
+**\<hyc>** and a single txn to update the entire blockchain - you lose all progress if it's interrupted. there might be a way to migrate incrementally  
+**\<hyc>** so that you can resume from an interruption  
+**\<fluffypony>** ok  
+**\<fluffypony>** next up  
+**\<fluffypony>** once 0.9.2 is tagged in the next week we have to merge back to the dev branch  
+**\<fluffypony>** and then I'd like to lock down master - anything that is PR'd either needs to be dev branch only, or has to go to both (as a backport to 0.9.x)  
+**\<fluffypony>** does anyone have any objections to that?  
+**\<moneromooo>** When do you plan a release after 0.9.2 ?  
+**\<fluffypony>** moneromooo: the next fork date is meant to be October / September, but we can be a little flexible about when we freeze the code for that release because we want it to include RingCT  
+**\<fluffypony>** if that appears to be unachievable then we'll re-address it in a couple of months time  
+**\<ArticMine>** So we are looking to a freeze for Ring CT in April/May?  
+**\<fluffypony>** depending on how implementation goes, yes  
+**\<moneromooo>** 0.9 took quite some time, dev is flaky and needs all the buffer overflows fixed at the very least before it can be put in any release.  
+**\<fluffypony>** moneromooo: I know - if we need to we can push the fork date   
+**\<ArticMine>** Testing?  
+**\<moneromooo>** Alright then.  
+**\<fluffypony>** ArticMine: you mean in terms of functional tests or automated tests?  
+**\<ArticMine>** both  
+**\<xmrpromotions>** what is the minumum time allowable between freeze date and fork date? I know the desire is 6 months but what is the margin of error?  
+**\<fluffypony>** xmrpromotions: for planned forks, given how small Monero is, we could probably get away with a month or two  
+**\<fluffypony>** but likely for the last time  
+**\<dEBRUYNE>** \<fluffypony> moneromooo: I know - if we need to we can push the fork date <= I am in favor of this as well  
+**\<fluffypony>** it'll become harder and harder to do stuff like that, so if we're making an exception on a planned fork let's make it the last time  
+**\<dEBRUYNE>** we don´t necessarily need to stick to a certain date for something that important  
+**\<dEBRUYNE>** Agree fluffypony  
+**\<fluffypony>** the larger issue here is that the 0MQ stuff was pushed prematurely because OranJuice couldn't work on Monero any longer  
+**\<fluffypony>** in future I don't expect stuff like that will happen  
+**\<dEBRUYNE>** Same issue with smart mining right?  
+**\<smooth>** i still think we can consider dumping the dev branch. i think we need to be open minded about whether its state will hurt development rather than help it  
+**\<fluffypony>** moneromooo is probably in the best position to make a call on that  
+**\<smooth>** meaning it may be more productive to pull what we want from it (that isn't unfinished) and merge to master than vice versa  
+**\<smooth>** \*with master (not to master)  
+**\<moneromooo>** Well, personally I'd not have a dev branch so...  
+**\<fluffypony>** heh  
+**\<fluffypony>** if people knew how to checkout a tag it wouldn't be a problem :)  
+**\<moneromooo>** Negative reinforcement helps make that a reality :)  
+**\<smooth>** i agree with not having a dev branch really but it doesn't address what to do with the code we want from te current dev branch  
+**\<hyc>** right, how much in there is usable?  
+**\<moneromooo>** What I'll do it hack at it to make it work better, really. All that's needed is time without the problem of a release coming too quick.  
+**\<moneromooo>** It is usable, just rough.  
+**\<warptangent>** are the main features in the dev branch 0mq and smart mining? wouldn't it be simpler to rebase those onto master instead of trying to merge with the current dev branch?  
+**\<fluffypony>** warptangent: no smart mining, just 0mq  
+**\<warptangent>** ah  
+**\<smooth>** i would suggest: put 0mq back on its own branch, finish it first, then merge when it is ready  
+**\<dEBRUYNE>** smooth: Isn´t 0mq the mere reason we have a dev branch currently?  
+**\<smooth>** so basically merge nothing from dev right now  
+**\<fluffypony>** there are some other bits and pieces on the dev branch  
+**\<fluffypony>** tewinget's code comments, for eg.  
+**\<hyc>** if that's the only real difference between dev and master ...  
+**\<dEBRUYNE>** I see  
+**\<hyc>** ah  
+**\<dEBRUYNE>** fluffypony: What if contributors just worked on their own fork until it is sufficient for master?  
+**\<smooth>** anyway im not saying which is more productive necessary but the question is worth asking rather than inertia  
+**\<dEBRUYNE>** fork/branch  
+**\<fluffypony>** dEBRUYNE: that's the way it normally works  
+**\<fluffypony>** the 0MQ thing was an exception  
+**\<moneromooo>** It'd also mean you get to redo the merge with all the stuff I merged recently :/  
+**\<fluffypony>** oh yes  
+**\<moneromooo>** And deal with that fucking white space patch AGAIN  
+**\<fluffypony>** my instinct is that we've put too much effort into the dev branch already to make cherry-picking worthwhile  
+**\<fluffypony>** there's a handful of merges since moneromooo's last merge to dev  
+**\<smooth>** effort isnt really the right measure  
+**\<smooth>** the measure is how much useful value is there  
+**\<fluffypony>** well it works  
+**\<fluffypony>** but there are some bugs that need to be fixed  
+**\<smooth>** there has been a lot of work on master only in the past few months  
+**\<fluffypony>** and we need to rip the net_skeleton stuff out and replace  
+**\<hyc>** so how much effort would it be to reapply just 0mq to current master  
+**\<moneromooo>** Probably a big pita. However, the original merge was also a bit crappy.  
+**\<fluffypony>** last merge up to dev was Jan 3rd  
+**\<fluffypony>** afaik  
+**\<moneromooo>** And while I was hacking on it, thre's a fair number of changes to the 0mq stuff I made in master.  
+**\<moneromooo>** Like fixes, all the missing RPC calls  
+**\<smooth>** in dev?  
+**\<warptangent>** 0mq in master?  
+**\<fluffypony>** in dev?  
+**\<fluffypony>** lol  
+**\<moneromooo>** Yes, in dev  
+**\<smooth>** at least people are paying attention  
+**\<warptangent>** lol  
+**\<fluffypony>** ok I say we hack at it for a bit  
+**\<smooth>** id say be open minded about it and undertake a review  
+**\<fluffypony>** and then re-evaluate   
+**\<warptangent>** \<fluffypony> last merge up to dev was Jan 3rd << does this also mean dev was up to date in terms of master as well?  
+**\<fluffypony>** warptangent: yes that's what I mean - all of master was merged up to dev on Jan 3rd  
+**\<moneromooo>** Yes. I expected we'd move to dev then.  
+**\<fluffypony>** the only reason we didn't was 0.9.x fixes  
+**\<warptangent>** that might not be too bad then.  
+**\<smooth>** moving to dev is fine (assuming its state is good enough) but that should be independent of any necessary point releases  
+**\<fluffypony>** ok - let's give it to the next meeting to reevaluate   
+**\<smooth>** this is especially the case due to the premature 0mq merge  
+**\<fluffypony>** speaking of the next meeting - the 28th I will be overseas, and March 6th I will be away, does anyone have an issue with us skipping the Feb 28th meeting altogether?  
+**\<dEBRUYNE>** perhaps do it on another day?  
+**\<dEBRUYNE>** saturday?  
+**\<ArticMine>** Saturday works better for me  
+**\<hyc>** Saturday is fine with me  
+**\<fluffypony>** dEBRUYNE: can't do that whole weekend on the 28th, we can do March 5th but then we'd have to have a meeting the next week to be back in sync with Kovri dev meetings  
+**\<fluffypony>** otherwise those of us that attend both end up with every Sunday having a block out  
+**\<dEBRUYNE>** I am fine with 5 - 12 march  
+**\<dEBRUYNE>** and then go on the biweekly schedule again  
+**\<dEBRUYNE>** There is also the hardfork coming up on 20 March, so might be important to have at least 2 meetings before it  
+**\<fluffypony>** ok - so we push the meeting till March 5th, and then the meeting thereafter will be March 14th  
+**\<hyc>** 5-6 March not great for me, but that's probably not a big deal  
+**\<dEBRUYNE>** 14th is a monday fluffypony  
+**\<fluffypony>** sorry 13th, thanks dEBRUYNE   
+**\<dEBRUYNE>** so March 5th Saturday and March 13th Sunday  
+**\<fluffypony>** yes  
+**\<warptangent>** that is fine here  
+**\<ArticMine>** can we meet earlier on March 13th?  
+**\<fluffypony>** ArticMine: Kovri meeting is at 6pm UTC, so if we meet earlier it means those of us that attend both have to block out a longer period of time  
+**\<fluffypony>** I can ask to push the Kovri meeting back on that day  
+**\<fluffypony>** but I know EinMByte has indicated he can't do earlier  
+**\<fluffypony>** let me see what I can do in the Kovri meeting in a few minute's time  
+**\<ArticMine>** It is because of the change to daylight savings time  
+**\<fluffypony>** ah  
+**\<ArticMine>** In the Northern hemisphere  
+**\<fluffypony>** ok then the last thing, unless someone has anything to add  
+**\<dEBRUYNE>** I got a general question  
+**\<fluffypony>** there are open issues that are low hanging fruit, from really long ago, like #83, #84, #92  
+**\<dEBRUYNE>** Is 0MQ highest priority currently? Certainly with the GUI work being done currently  
+**\<fluffypony>** if you're feeling bored feel free to try knock those out, if we can keep the issues deck clean it makes it easier to maintain   
+**\<fluffypony>** some are more suited to "after 0MQ", but there's others that are more general  
+**\<fluffypony>** dEBRUYNE: not really, no, Ilya can only work part-time every week so it's not like the GUI is going to be done in a month  
+**\<ArticMine>** I was going the raise the question of the 32 bit versions  
+**\<fluffypony>** and 0MQ \*works\*, it just needs some bug fixing and massaging  
+**\<fluffypony>** ArticMine: good point - I'd forgotten about that  
+**\<dEBRUYNE>** fluffypony: As long as it doesn´t hold up the work it´s fine  
+**\<fluffypony>** hyc: are you able to put together some build instructions for win32, given the issue with builds on 32-bit msys2?  
+**\<ArticMine>** I have been testing 0.9.1.0-9cc8c24  
+**\<ArticMine>** on XP and 7  
+**\<hyc>** sure  
+**\<hyc>** I already had a start at that on the reddit  
+**\<othe>** ilya is working on the c++ interface currently, doesn´t really matter for the gui if its using zeromq or not  
+**\<fluffypony>** btw hyc, you may find this of interest: https://github.com/niXman/mingw-builds  
+**\<dEBRUYNE>** othe: Thanks for clarifying that  
+**\<bookies>** are all issues on getmonero.org sorted on github? meaning I saw some that are probably old and might be resolved.  
+**\<fluffypony>** bookies: you mean for the site, or for Monero itself?  
+**\<bookies>** https://github.com/monero-project/monero-site  
+**\<hyc>** fluffypony: heh, ok. are we going to tell people they need to build their own compiler before they can build win32?  
+**\<fluffypony>** bookies: I haven't checked - there may very well be some old ones that are sorted  
+**\<bookies>** ty  
+**\<smooth>** \<hyc> fluffypony: heh, ok. are we going to tell people they need to build their own compiler before they can build win32? <= if that is what is needed then that's what the instructions should include  
+**\<fluffypony>** hyc: oh - don't they provide binaries? I thought there were  
+**\<fluffypony>** may have misread  
+**\<hyc>** afaics they're just build scripts for building gcc etc  
+**\<fluffypony>** ah ok  
+**\<fluffypony>** alright, that's our hour - anything else before we close the meeting?  
+**\<moneromooo>** Shall I merge master into dev again then ?  
+**\<moneromooo>** I was going to do that, but...  
+**\<fluffypony>** moneromooo: yes, please  
+**\<moneromooo>** kk  
+**\<xmrpromotions>** will someone publish the meeting minutes like last time?  
+**\<fluffypony>** yes  
+**\<xmrpromotions>** Thank you  
--- a/_posts/2016-03-16-monero-0.9.2-released.md
+++ b/_posts/2016-03-16-monero-0.9.2-released.md
@ -0,0 +1,38 @@
+---
+layout: post
+title: Monero 0.9.2 Released
+summary: A point release of Monero Hydrogen Helix containing performance improvements and bug fixes
+tags: [releases]
+author: Riccardo Spagni (fluffypony)
+---
+
+*March 16th, 2016*
+
+## Summary of Changes
+
+This has urgent and important bug fixes to 0.9.1 *Hydrogen Helix*
+
+- Major performance and size improvements to the LMDB database implementation
+- Urgent and important bug fixes for the upcoming hard fork
+- Huge bug fixes to the database hard fork handling
+- New simplewallet flag to restore from keys
+- Initial work on a wallet library / API
+- Updated in-source block headers
+
+## Official Download Links
+
+- [Windows, 64-bit](https://downloads.getmonero.org/monero.win.x64.v0-9-2-0.zip)
+- [OS X, 64-bit](https://downloads.getmonero.org/monero.mac.x64.v0-9-2-0.tar.bz2)
+- [Linux, 64-bit](https://downloads.getmonero.org/monero.linux.x64.v0-9-2-0.tar.bz2)
+- [Linux, 32-bit](https://downloads.getmonero.org/monero.linux.x86.v0-9-2-0.tar.bz2)
+- [Linux, ARM v7](https://downloads.getmonero.org/monero.linux.arm7.v0-9-2-0.tar.bz2)
+
+## Download Hashes
+
+If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes:
+
+- monero.win.x64.v0-9-2-0.zip, a64119348fbf1f74e82afde283cbaa76bdb81fcb7181f639ea7e8579ef754534
+- monero.mac.x64.v0-9-2-0.tar.bz2, efc59859944a8406b22f5a19e8987bb6c18b2ff0095b0e77a1557a7a639c0d98
+- monero.linux.x64.v0-9-2-0.tar.bz2, de9db0ca6e72fc3e19d555fd003313a93e490ca747cd58a6370ff8a916996f2a
+- monero.linux.x86.v0-9-2-0.tar.bz2, ee0a32f7e3d12b1a02267593f71a6f9e13f85f43c86d0a4814f3f12c3dbaabc8
+- monero.linux.arm7.v0-9-2-0.tar.bz2, e0b9bcd7d3b8013a974f36ae0311c3a150a223032f16978bf53e03535f9b5836
--- a/_posts/2016-03-19-overview-and-logs-for-the-dev-meeting-held-on-2016-03-19.md
+++ b/_posts/2016-03-19-overview-and-logs-for-the-dev-meeting-held-on-2016-03-19.md
@ -0,0 +1,342 @@
+---
+layout: post
+title: Overview and Logs for the Dev Meeting Held on 2016-03-19
+summary: Open PRs, GUI commits, app/add-on infrastructure, versioning
+tags: [dev diaries, core, crypto]
+author: dEBRUYNE / fluffypony
+---
+ 
+*March 19th, 2016*
+ 
+# Logs
+
+**\<dEBRUYNE>** dev meeting in 5 min, FYI  
+**\<hyc>** dingdong  
+**\<gingeropolous>** hello  
+**\<dEBRUYNE>** fluffypony, smooth, othe, ArticMine, luigiw, NoodleDoodle, tewinget, moneromooo  
+**\<floofypony>** there we go  
+**\<dEBRUYNE>** did I forget anyone?  
+**\<tewinget>** oh, hello  
+**\<luigi>** is warptangent around?  
+**\<ArticMine>** Hello  
+**\<hyc>** he's been fighting a flu last we heard  
+**\<moneromooo>** hi  
+**\<NoodleDoodle>** Hello. I'm here but I'm fighting the apocalypse.  
+**\<NoodleDoodle>** of flus.  
+**\<luigi>** keep doing it  
+**\<luigi>** wait you're alive that's good to hear  
+**\<dEBRUYNE>** fluffypony seems ded  
+**\<fluffypony>** sorry  
+**\<fluffypony>** was eating  
+**\<fluffypony>** welcome everyone  
+**\<fluffypony>** so as you know we pushed out 0.9.2  
+**\<fluffypony>** however, there are some nagging issues from the ReadTXN work  
+**\<fluffypony>** hyc has nailed a major one as of a few hours ago  
+**\<fluffypony>** so we'll probably do a point release on Monday or so  
+**\<fluffypony>** also that means that the way we use LMDB has changed a bit  
+**\<fluffypony>** hyc can you tell us briefly how we should wrapping access to LMDB, both read and write operations?  
+**\<hyc>** Are you talking about the CRITICAL\_REGION stuff?  
+**\<fluffypony>** yes, and the cursors vs. txns stuff  
+**\<hyc>** ok, the critical\_region stuff actually is not a change at all.  
+**\<hyc>** basically, when you're setting up to do a write, you need exclusive access to the DB  
+**\<hyc>** this appears to have been a long-standing bug, unrelated to the readtxn changes  
+**\<hyc>** so as for reads - there is now a long-lived read txn per thread  
+**\<hyc>** and a set of read cursors to go with each  
+**\<hyc>** the TXN\_PREFIX\_RDONLY macro sets that up in a particular function, grabbing the thread-local-storage for it  
+**\<hyc>** and RCURSOR(dbname) sets up a read cursor for a particular DB  
+**\<hyc>** these are analogous to the CURSOR(dbname) macro for getting a write cursor to a DB  
+**\<hyc>** the point of all this is to avoid a bunch of malloc/free/seek when accessing a DB  
+**\<hyc>** the old code was allocating a readtxn and cursors inside each function  
+**\<hyc>** likewise for writes  
+**\<hyc>** by reusing the same cursors acros a set oof functions we get a pretty good performance gain  
+**\<hyc>** ok?  
+**\<fluffypony>** neat  
+**\<fluffypony>** also on the topic of stuff-hyc-did-lately  
+**\<fluffypony>** if anyone missed it, we now have a win environment guide up on forum.getmonero.org  
+**\<dEBRUYNE>** ^ https//forum.getmonero.org/5/support//building-monero-v0-9-2-on-winMonero  
+**\<fluffypony>** so that should get us all on the same page with testing etc.  
+**\<hyc>** and one success story replied to it already ;)  
+**\<fluffypony>** we've also dropped support for BDB as the default database, and switched to LMDB as the default  
+**\<fluffypony>** including on -bit and ARM  
+**\<fluffypony>** BDB will remain supported for the moment, primarily as a mechanism for contributors to understand how to build out DB support  
+**\<fluffypony>** krongle)  
+**\<fluffypony>** shew we have the entire xmr.to team here today, that's awesome  
+**\<binaryFate>** fluffypony good memory P  
+**\<fluffypony>** we shared a podcast together, binaryFate -P  
+**\<krongle>** yes - impressive nick-name recollection  
+**\<fluffypony>** hah hah  
+**\<fluffypony>** while we have you guys here, are you guys doing anything cool you want to talk about?  
+**\<binaryFate>** we're doing many cool things, but nothing we can talk about at this stage  
+**\<fluffypony>** hah hah  
+**\<fluffypony>** it does lead to an interesting point of conversation  
+**\<binaryFate>** seriously considering btc -> xmr direction  
+**\<fluffypony>** plugins  
+**\<iam6yearsold>** If NobleSir or xmr.to team could talk more about xmr.to integration at MiniNero that would be great.... also are 2 way conversions coming to xmr.to soon?  
+**\<fluffypony>** iam6yearsold Shen's offline at the moment, I'll ask him to update the Reddit thread with some info )  
+**\<fluffypony>** re plugins, we've spoken briefly about options for the GUI  
+**\<dEBRUYNE>** iam6yearsold There is a bit of info here -> https//imgur.com/a/HZL7k  
+**\<binaryFate>** iam6yearsold for MiniNero integration you'd have to see with NobleSir. The API doc is at http//xmrto-api.readthedocs.org/en/latest/  
+**\<fluffypony>** but I guess we could have "plugins", of a sort, that add functionality  
+**\<fluffypony>** like xmr.to or shapeshift integration right in wallet2 / wallet2\_api  
+**\<dEBRUYNE>** I think we should be fairly strict on which plugins to allow  
+**\<binaryFate>** fluffypony we wanted to discuss that plugin integration soon in fact )  
+**\<arnuschky>** we're quite interested to all secondary  questions related to plugins  
+**\<fluffypony>** I guess the major question becomes  
+**\<arnuschky>** so plugin repository/db, packaging, distribution etc  
+**\<fluffypony>** do we allow "permissionless" plugin development, or do we just have a central repo that we git submodule in?  
+**\<ArticMine>** The main question I see with plugins is trust  
+**\<fluffypony>** ArticMine exactly  
+**\<arnuschky>** yes. It puts quite a bit responsibility on the dev team  
+**\<gingeropolous>** well no ones going to trust anything that doesn;t come from core  
+**\<tewinget>** \<fluffypony> we shared a podcast together, binaryFate -P  <-- wasn't I there for that?  
+**\<fluffypony>** considering the recent Google Chrome Bitcoin stealing malware I think that premissionless plugins are dangerous  
+**\<gingeropolous>** as we've seen with 3rd party GUIs  
+**\<luigi>** you obviously can't stop permissionless dev, you can discourage users from trusting it I guess  
+**\<hyc>** we can start signing binaries, ohjoy  
+**\<dEBRUYNE>** I would prefer the latter  
+**\<fluffypony>** luigi I mean permissionless within core  
+**\<luigi>** oh  
+**\<luigi>** I think no  
+**\<arnuschky>** it's related to how plugins are written. If it's binary blobs, it's a) hard to build, distribute etc, and b) hard to examine  
+**\<binaryFate>** fluffypony I'd see both possible all together. Unpermissioned scale and central repo for a selected subset would ease experience and trust for user  
+**\<arnuschky>** so if plugins are interpreted (eg python), things become a whole lot easier  
+**\<iam6yearsold>** for the record I hated the twittter plugin idea I saw a while back  
+**\<ArticMine>** My take permissionless has to be allowed. The end user has to be made aware who is signing and if to trust the plugin  
+**\<fluffypony>** well the Electrum model works well  
+**\<moneromooo>** I agree with ArticMine  
+**\<arnuschky>** (inspection in case of central repo, but also self-distribution by plugin devs)  
+**\<fluffypony>** ThomasV will merge basically any plugin, as long as it's not malicious  
+**\<fluffypony>** and plugins are part of the core code, effectively just in a subfolder  
+**\<fluffypony>** I think it's a testament to Electrum that they haven't had a malicious plugin ever  
+**\<arnuschky>** how do they deal with the upgrade/maintenance workload? Or do they just disable broken plugins?  
+**\<dEBRUYNE>** Is there a way to make a subfolder in the subfolder? i.e. (1) signed and approved by core-team, (2) optional  
+**\<fluffypony>** arnuschky yeah they just disable broken plugins, and eventually they get deprecated out  
+**\<ArticMine>** We should allow self distribution with appropriate warning  
+**\<fluffypony>** ArticMine anyone can compile their own build, which would be the same thing  
+**\<arnuschky>** are you planning for compiled plugins or interpreted ones? that's quite a differens IMHO  
+**\<fluffypony>** arnuschky so  
+**\<arnuschky>** self-distribution is a mess for compiled ones...  
+**\<fluffypony>** I was thinking we have a repo, say it's called monero-plugins  
+**\<arnuschky>** audit as well  
+**\<fluffypony>** and then anyone can PR to that repo  
+**\<fluffypony>** and that repo is pulled into the main Monero source as a git submodule  
+**\<fluffypony>** there are two advantages to this  
+**\<fluffypony>** 1. as it gets bigger and harder to deal with, we can step back and other known members of the community can manage that repo  
+**\<fluffypony>** 2. if we come up with a standard set of functionality hooks, then other projects can pull that same repo in  
+**\<fluffypony>** eg. jwinterm's lightwallet  
+**\<fluffypony>** also it means that the compiled Monero binaries have those plugins baked in, and you can't add extra plugins post-compile  
+**\<fluffypony>** so no need to deal with interpreted code and securing that on disk and in memory  
+**\<hyc>** baked in means no dynamic loading?  
+**\<tewinget>** \<fluffypony> so no need to deal with interpreted code and securing that on disk  <-- if securing an interpreted plugin on disk became an issue, securing the binary would be an issue anyway, so I don't know of that bit matters  
+**\<binaryFate>** Sounds all good to us. If distribution is done through official channels it's great.  
+**\<fluffypony>** hyc yes  
+**\<fluffypony>** no dynamic loading  
+**\<hyc>** cool  
+**\<fluffypony>** tewinget I mean we can't secure it in the path from random-site-on-the-web down to random-download-folder and eventually into secure-disk-location  
+**\<arnuschky>** fluffypony that would be really great.  
+**\<fluffypony>** ok - I think next steps would be to consider some of the hooks we need to provide to add functionality  
+**\<fluffypony>** we can use the Monero wikia as a collaboration area for that  
+**\<ArticMine>** It is a good balance for plugins  
+**\<fluffypony>** and then we'll just update the Monero Slack  
+**\<arnuschky>** well securing the plugins can always happen by signature - no matter if interpreted or binary  
+**\<fluffypony>** I'm kidding, we don't have a Slack  
+**\<fluffypony>** we're not that cool  
+**\<aerbax>** Would these plugins allow for interpreted languages like Lua or Python?  
+**\<arnuschky>** :)  
+**\<fluffypony>** aerbax I don't see why not, individual CMake files in each plugin folder that allow it to produce a library fix everything  
+**\<binaryFate>** We could financially support development of plugin architecture if xmr.to is the first instanciation of those plugins.  
+**\<fluffypony>** if it spits out a .so / .a / .dll with the right hooks then it's fine  
+**\<tewinget>** fluffypony> tewinget I mean we can't secure it in the path from random-site-on-the-web down to random-download-folder and eventually into secure-disk-location  <-- and yet, we provide binary downloads...so "random site on the web" could be managed the same as said binary downloads  
+**\<tewinget>** just like any random site on the web can offer binaries for download and we can't secure that either  
+**\<tewinget>** caveat emptor has to come into play at some point, I think  
+**\<fluffypony>** the binaries present a single attack surface, and there's GPG-signed hashes  
+**\<fluffypony>** if we have to do GPG-signed hashes for a bunch of .py files I think I'll go mad -P  
+**\<tewinget>** I'm not saying I think it should be one way or another, I'm merely pointing out flaws in your argument P  
+**\<fluffypony>** fair enough  
+**\<fluffypony>** binaryFate I think the stumbling block will be that somebody needs to champion this and run with it, and I won't be able to lead it due to travelling in a week  
+**\<ArticMine>** As long as people can compile their own version with non permissioned plugins this can work  
+**\<luigi>** they can always do that  
+**\<fluffypony>** yep  
+**\<fluffypony>** and in fact that would be the testing model  
+**\<luigi>** we're not apple )  
+**\<fluffypony>** fork the repo, and build a binary to test your new plugin  
+**\<iam6yearsold>** asking noobs to compile will limit adoption  
+**\<ArticMine>** luigi Exactly  
+**\<fluffypony>** iam6yearsold why would noobs be writing their own plugins?  
+**\<gingeropolous>** for security  
+**\<dEBRUYNE>** lol gingeropolous  
+**\<fluffypony>** lol  
+**\<arnuschky>** fluffypony championing the first plugin or the whole infrastructure?  
+**\<tewinget>** What about a curated repo of plugins (as suggested) but with those plugins written in python/lua?  Someone modifying the python/lua on a target's disk is the same as someone modifying the binary anyway, and python/lua plugins would be far easier to develop and audit I think  
+**\<fluffypony>** arnuschky championing the design, I guess  
+**\<arnuschky>** tewinget I would prefer that.  
+**\<iam6yearsold>** how about 1 version with binaries and gpg sig and no plugins? caveat emptor for the rest  
+**\<arnuschky>** mostly due to auditing, and there's no build/distribution mess attached  
+**\<fluffypony>** I would prefer we remain language agnostic  
+**\<fluffypony>** iam6yearsold that's what we already have  
+**\<tewinget>** fluffypony language-agnostic is fine, but...well, how do you imagine that will work out?  
+**\<iam6yearsold>** thanks pony. I like the current situation then  
+**\<fluffypony>** tewinget read up  
+**\<arnuschky>** ah even language agnostic. I thought up to now it's supposed to be a C++ only API  
+**\<tewinget>** as in, how do we become language-agnostic so that we can remain so?  
+**\<fluffypony>** []  \<aerbax>        Would these plugins allow for interpreted languages like Lua or Python?  
+**\<fluffypony>** []  \<fluffypony>   aerbax I don't see why not, individual CMake files in each plugin folder that allow it to produce a library fix everything  
+**\<fluffypony>** ^^  
+**\* smooth** is here  
+**\<fluffypony>** also what if a plugin wants to call a function in the core crypto library, for instance?  
+**\<arnuschky>** design-wise, that's sounds like a nightmare, no?  
+**\<moneromooo>** Oh, so linked directly ? I kinda assumed it was gointg to be RPC based.  
+**\<fluffypony>** ok well I think we're getting into an implementation discussion that's outside of the scope of this meeting  
+**\<arnuschky>** I mean, if you don't have a small and defined API, every bigger change in the wallet will break plugins  
+**\<arnuschky>** true )  
+**\<fluffypony>** after the dev meeting we can continue this conversation if you guys want  
+**\<fluffypony>** but let's first circle back around  
+**\<luigi>** this deserves some kind of design thread like ringct imo  
+**\<moneromooo>** Oh, link ?  
+**\<fluffypony>** moneromooo: "this deserves"  
+**\<fluffypony>** so nothing yet  
+**\<moneromooo>** "like ringct"  
+**\<fluffypony>** oh  
+**\<fluffypony>** I see what you were asking  
+**\<luigi>** oh  
+**\<moneromooo>** Oh  
+**\<fluffypony>** OH  
+**\<luigi>** "like ringct is supposed to get"  
+**\<moneromooo>** Fair enough.  
+**\<fluffypony>** so basically this is all luigi's fault  
+**\<luigi>** warp was gonna go it!@  
+**\<gingeropolous>** its true. i mis-called out luigi on that one  
+**\<fluffypony>** warptangent is off sick at the moment  
+**\<luigi>** yes  
+**\<luigi>** so I blame that  
+**\<fluffypony>** I blame Canada  
+**\<fluffypony>** ok back on track  
+**\<fluffypony>** since the last meeting the bulk of the PRs have been bug fixes  
+**\<fluffypony>** and changes to the way we access the DB as discussed at the beginning  
+**\<fluffypony>** we also had a huge discussion about how to handle mixins below the minimum in the RPC call  
+**\<fluffypony>** which was then implemented in #715  
+**\<fluffypony>** I'm also going to try to personally spend some time on the text that users see, things like the level 0 logging output and the CLI flag help  
+**\<luigi>** oh I was gonna do that  
+**\<luigi>** but then I didn't  
+**\<fluffypony>** luigi we can do it together  
+**\<luigi>** awwww  
+**\<fluffypony>** I can show you the world, shining shimmering splendid  
+**\<gingeropolous>** take you wonder by wonder  
+**\<fluffypony>** lol  
+**\<fluffypony>** also #728 was a little contentious  
+**\<fluffypony>** so we created a company called Mixinstream that has hired all the contributors  
+**\<palexander>** heh heh  
+**\<fluffypony>** and gingeropolous has launched Monero Classic  
+**\<gingeropolous>** ( sorry )  
+**\<fluffypony>** -P  
+**\<fluffypony>** ok so #728 is Ilya's work as part of the GUI effort  
+**\<dEBRUYNE>** Can I launch unlimited?  
+**\<fluffypony>** he was struggling with wallet2, and decided to break it out into something more logical and usable  
+**\<fluffypony>** (to him at any rate)  
+**\<ArticMine>** What makes it contentious?  
+**\<fluffypony>** ArticMine I'll get to that now  
+**\<fluffypony>** he's unintuitively called it wallet2\_api, which is a little confusing  
+**\<fluffypony>** but basically a lot of it is a wallet2\_api call which then does little additional logic, and mainly just passes stuff back to wallet2  
+**\<fluffypony>** and there's a lot of DRY-violating code because of it  
+**\<fluffypony>** obviously there was some push back, not to prevent merging it  
+**\<fluffypony>** but more to understand the thought process  
+**\<moneromooo>** Define DRY ?  
+**\<iam6yearsold>** DRY violating scares the shit out of me  
+**\<gingeropolous>** https//en.wikipedia.org/wiki/Don%t\_repeat\_yourself  
+**\<gingeropolous>** maybe  
+**\<fluffypony>** yes  
+**\<fluffypony>** iam6yearsold DRY violations are just where you have a piece of code in two places  
+**\<fluffypony>** so any changes have to happen in both  
+**\<fluffypony>** we can treat the DRY-violating code as a temporary issue, though  
+**\<iam6yearsold>** two places = more opportunity for error  
+**\<fluffypony>** as we're going to wait until Ilya is done with it  
+**\<ArticMine>** Which makes maintenance much harder  
+**\<fluffypony>** and then we'll either drop wallet2 and replace it with the new wallet API  
+**\<fluffypony>** (ie. replace the simplewallet calls as well)  
+**\<fluffypony>** or if it's just a pointless layer we'll have to go the opposite route  
+**\<fluffypony>** and change his Qt callers to use wallet2  
+**\<fluffypony>** as it stands it's kinda undecided and we'll have to see how Ilya goes  
+**\<ArticMine>** Is Ilya aware of the concern?  
+**\<fluffypony>** ArticMine yes, we had some discussion on the PR, and othe has also spoken to him afaik  
+**\<fluffypony>** he was responsive on the PR comments, but this isn't Bitcoin  
+**\<fluffypony>** we don't ACK NACK utACK for years before merging somethingm  
+**\<fluffypony>** aintnobodygottimeforthat.gif  
+**\<luigi>** utNACK  
+**\<fluffypony>** luigi #networknerd  
+**\<moneromooo>** utACK was not a typo ?  
+**\<luigi>** no  
+**\<luigi>** means untested  
+**\<luigi>** conceptACK or similar  
+**\<fluffypony>** yeah  
+**\<fluffypony>** moneromooo https//lists.linuxfoundation.org/pipermail/bitcoin-dev/-December/71.html  
+**\<fluffypony>** if you're interested  
+**\<hyc>** crap  
+**\<fluffypony>** LOL  
+**\<fluffypony>** PasteGate 2.0  
+**\<gingeropolous>** internets  
+**\<othe>** ur pasting skills suck  
+**\<dEBRUYNE>** Hahah  
+**\<fluffypony>** othe pasting is a scam  
+**\<hyc>** that's how I write all my patches  
+**\<fluffypony>** I just copy-and-paste code from StackExchange  
+**\<gingeropolous>** thats my job  
+**\<fluffypony>** heh  
+**\<fluffypony>** ok so anyone who can reproduce the 0.9.2 segfault please try latest master  
+**\<fluffypony>** and if you're still segfaulting let us know  
+**\<fluffypony>** else we're going to do a point release on Monday  
+**\<fluffypony>** 0.9.3, I guess?  
+**\<luigi>** hrm  
+**\<fluffypony>** or 0.9.2.1  
+**\<luigi>** we're gonna run out of numbers at this rate  
+**\<fluffypony>** yeah we are  
+**\<luigi>** oh wait  
+**\<hyc>** 0921  
+**\<luigi>** we have 0.10  
+**\<luigi>** nevermind  
+**\<iam6yearsold>** will there be multiple devs in IRC at time of hard fork this week just in case? I see a few pools still on old cold and probably a few users too  
+**\<fluffypony>** yes we just do a Bitcoin  
+**\<moneromooo>** No chance, there's an infinity of those.  
+**\<fluffypony>** 0.11  
+**\<fluffypony>** iam6yearsold yes, and we've reached out to as many of them as we can  
+**\<luigi>** is 0.10 supposed to be for next hard fork?  
+**\<fluffypony>** luigi fork that  
+**\<fluffypony>** when warptangent is back we'll see how it goes on ringCT  
+**\<fluffypony>** and make a more concrete decision as to the timing of the next fork  
+**\<dEBRUYNE>** iam6yearsold The hardfork will approximately take place at 13:00 UTC, so both US and Europe will probably be awake  
+**\<dEBRUYNE>** and Asia of course  
+**\<luigi>** everyone will be awake  
+**\<fluffypony>** even me  
+**\<dEBRUYNE>** hawaii will probably be asleep  
+**\<dEBRUYNE>** -P  
+**\<fluffypony>** heh  
+**\<dEBRUYNE>** fwiw!  
+**\<luigi>** wat  
+**\<Wolf\`>** lol  
+**\<smooth>** we should also consider what else we should go in the next major version besides ringct (doesn't need to be discussed now)  
+**\<dEBRUYNE>** uh I meant  UTC btw  
+**\<dEBRUYNE>** you muricans with AM/PM  
+**\<Wolf\`>** who got drunk and posted about a party in #monero-dev  
+**\<luigi>** oh  
+**\<luigi>** then america won't be up  
+**\<moneromooo>** The db reorg seems like a good candidate.  
+**\<luigi>** oh well  
+**\<fluffypony>** smooth agreed  
+**\<dEBRUYNE>** east coast will right?  
+**\<luigi>** sure ish  
+**\<dEBRUYNE>** You better set your alarm luigi  
+**\<dEBRUYNE>** :-P  
+**\<fluffypony>** Surae is also going to be picking up MRL-6 in the summer  
+**\<fluffypony>** he has some ideas about how to complete that  
+**\<dEBRUYNE>** MRL-6 is multisig?  
+**\<iam6yearsold>** I will party hard if fork happens with no drama  
+**\<fluffypony>** dEBRUYNE: no  
+**\<fluffypony>** https//github.com/monero-project/research-lab/tree/master/publications/MRL-%-%Difficulty%Adjustment%Algorithms%in%Cryptocurrency%Protocols  
+**\<dEBRUYNE>** oh cool, thanks  
+**\<moneromooo>** How do get cmake to tell you the commands it's running ?  
+**\<luigi>** we have diff, we have db stuff, we have fee stuff  
+**\<fluffypony**> moneromooo: I normally make VERBOSE=1  
+**\<moneromooo>** Thanks, I was trying V=1  
+**\<luigi>** I like my V=2  
+**\<fluffypony>** ok - any last things to add  
+**\<fluffypony>** or can we call it?  
+**\<luigi>** call it  
--- a/_posts/2016-03-22-monero-0.9.3-released.md
+++ b/_posts/2016-03-22-monero-0.9.3-released.md
@ -0,0 +1,40 @@
+---
+layout: post
+title: Monero 0.9.3 Released
+summary: A point release of Monero Hydrogen Helix containing important bug fixes
+tags: [releases]
+author: Riccardo Spagni (fluffypony)
+---
+
+*March 22nd, 2016*
+
+## Summary of Changes
+
+This has urgent and important bug fixes to 0.9.2 *Hydrogen Helix*
+
+- Urgent bug fix for database corruption issues in 0.9.2
+- Official Windows 32-bit releases are back
+- Updates to miniupnpc
+- Sets v3 fork date for September, 2016
+- Fixes core tests and re-enables them
+- Fixes a problem with --password-file not working in RPC mode
+
+## Official Download Links
+
+- [Windows, 64-bit](https://downloads.getmonero.org/monero.win.x64.v0-9-3-0.zip)
+- [Windows, 32-bit](https://downloads.getmonero.org/monero.win.x86.v0-9-3-0.zip)
+- [OS X, 64-bit](https://downloads.getmonero.org/monero.mac.x64.v0-9-3-0.tar.bz2)
+- [Linux, 64-bit](https://downloads.getmonero.org/monero.linux.x64.v0-9-3-0.tar.bz2)
+- [Linux, 32-bit](https://downloads.getmonero.org/monero.linux.x86.v0-9-3-0.tar.bz2)
+- [Linux, ARM v7](https://downloads.getmonero.org/monero.linux.arm7.v0-9-3-0.tar.bz2)
+
+## Download Hashes
+
+If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes:
+
+- monero.win.x64.v0-9-3-0.zip, 246115b0da133e0203dc78d26bbc82e9b76a178939bff8d4541bf04a02a19854
+- monero.win.x86.v0-9-3-0.zip, 4663222a810ad854da1fc9d665e51252e61ddb1a8f69de3a31ad195386d445a2
+- monero.mac.x64.v0-9-3-0.tar.bz2, f471a420485413d5fcb1b19065a3b4e9a68c49596ddd6291787ad34121bad32c
+- monero.linux.x64.v0-9-3-0.tar.bz2, 9e6747b69642389e98ca5f70cec7276f7af7156e5dce95409a8da7cccff5876e
+- monero.linux.x86.v0-9-3-0.tar.bz2, 90c51c4a68f78ac2262a7b5a676f02d43ba7b9b6800b8b150d89980604c969f2
+- monero.linux.arm7.v0-9-3-0.tar.bz2, c312ba0810bf04ab2e28b61a50de2a83c1c614fd789bab4cacacb716134a7239
--- a/_posts/2016-04-02-monero-0.9.4-released.md
+++ b/_posts/2016-04-02-monero-0.9.4-released.md
@ -0,0 +1,38 @@
+---
+layout: post
+title: Monero 0.9.4 Released
+summary: A point release of Monero Hydrogen Helix containing important bug fixes
+tags: [releases]
+author: Riccardo Spagni (fluffypony)
+---
+
+*April 2nd, 2016*
+
+## Summary of Changes
+
+This has important bug fixes to 0.9.3 *Hydrogen Helix*
+
+- Fix remaining issues with coinbase transactions
+- Removed ```connectivity_tool```
+- Switched to new Clang move diagnostics
+- Added a new ```--generate-from-json``` flag to simplewallet to allow wallet creation from a JSON file
+- Add a new and improved version of ```sweep_dust```
+- Various bug fixes to handle failures such as map resize failures and bad simplewallet exits
+
+## Official Download Links
+
+- [Windows, 64-bit](https://downloads.getmonero.org/monero.win.x64.v0-9-4-0.zip)
+- [Windows, 32-bit](https://downloads.getmonero.org/monero.win.x86.v0-9-4-0.zip)
+- [OS X, 64-bit](https://downloads.getmonero.org/monero.mac.x64.v0-9-4-0.tar.bz2)
+- [Linux, 64-bit](https://downloads.getmonero.org/monero.linux.x64.v0-9-4-0.tar.bz2)
+- [Linux, 32-bit](https://downloads.getmonero.org/monero.linux.x86.v0-9-4-0.tar.bz2)
+
+## Download Hashes
+
+If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes:
+
+- monero.win.x64.v0-9-4-0.zip, a6f171c942a2b75432573c3cea6ca3becb10769a08eaaea5cca080c92b8ee297
+- monero.win.x86.v0-9-4-0.zip, c9e4abc19c767ab570c2d0a9d504ba75d73eea26e7cf719a1260fdbb9469c250
+- monero.linux.x64.v0-9-4-0.tar.bz2, 0b3610c9b301ea14174ce700923a604909fa7cbd9335849112c9d6cfb07a1a43
+- monero.linux.x86.v0-9-4-0.tar.bz2, c070125bb885c5b887d3adce866e9bb941ed790485ef34444e62e0881fe8852a
+- monero.mac.x64.v0-9-4-0.tar.bz2, ded52162d34d5a726b53ffd14ebbf02388d9b396f3f4e278a4755e5286b1aeab
--- a/_posts/2016-04-24-overview-and-logs-for-the-dev-meeting-held-on-2016-04-24.md
+++ b/_posts/2016-04-24-overview-and-logs-for-the-dev-meeting-held-on-2016-04-24.md
@ -0,0 +1,219 @@
+---
+layout: post
+title: Overview and Logs for the Dev Meeting Held on 2016-04-24
+summary: A review and discussion of open PRs, moving forward with Ring CT
+tags: [dev diaries, core, crypto]
+author: dEBRUYNE / fluffypony
+---
+ 
+*April 24th, 2016*
+ 
+# Logs
+ 
+**\<hyc>** hey what's on our agenda for today anyway  
+**\<hyc>** slideshow from fluffypony's trip to Asia?  
+**\<dEBRUYNE>** we could do that :D  
+**\<dEBRUYNE>** hyc: More seriously, I suppose some Ring CT stuff + something about the performance branch  
+**\<fluffypony>** lol  
+**\<dEBRUYNE>** hyc: Plus I think there are still some PRs open for review  
+**\<hyc>** sounds good. looking at NobleSir's DB schema, doesn't seem like there's much new needed on the DB side of things  
+**\<dEBRUYNE>** hyc, fluffypony: I could make a list of which PRs are still open for review if you want?  
+**\<hyc>** 13 open right now  
+**\<dEBRUYNE>** all right  
+**\<hyc>** moneromooo already reviewed PR#806  
+**\<dEBRUYNE>** Oh yeah this is easier to spot -> https://github.com/monero-project/bitmonero/pulls  
+**\<dEBRUYNE>** :-P  
+**\<hyc>** yep  
+**\<dEBRUYNE>** smooth and moneromooo had a little chat about 818 & 819 earlier today  
+**\<hyc>** I've browsed thru them but frankly don't know enough about how things work to know their implications  
+**\<moneromooo>** I felt like that abour your/warp's DB perf branch :P  
+**\<hyc>** ;)  
+**\<hyc>** looking at git history I'd guess tewinget or NoodleDoodle would have breezed thru them  
+**\<fluffypony>** hokay  
+**\<fluffypony>** t -1 hour  
+**\<dEBRUYNE>** t -5 min  
+**\<ArticMine>** hello  
+**\<JonathanD_>** hi  
+**\<hyc>** hola  
+**\<smooth>** bonjour  
+**\<xmrpromotions>** bonjour  
+**\<fluffypony>** Comment allez-vous ?  
+**\<fluffypony>** la réunion d'aujourd'hui aura lieu en français  
+**\<bigreddmachine>** laissez les bon temps rouler  
+**\<fluffypony>** lol  
+**\<xmrpromotions>** Konnichiwa  
+**\<fluffypony>** ok so  
+**\<fluffypony>** welcome to the dev meeting  
+**\<fluffypony>** after a brief intermission we're back on every 2 weeks  
+**\<luigi1112>** I'm here but not really  
+**\<fluffypony>** I've been trying to keep up whilst travelling, but there's some backlog I didn't read  
+**\<fluffypony>** I think before we discuss #805 and the performance PR, let's just touch base on the smaller ones  
+**\<fluffypony>** #810, #814, #818, all seem to have been reviewed and are ready for merge  
+**\<moneromooo>** smooth had reservations about 810.  
+**\<moneromooo>** Or hyc. Or both.  
+**\<fluffypony>** smooth / hyc: any new thoughts beyond the one comment on the PR?  
+**\<hyc>** both I think, but I don't remember smooth's comments  
+**\<moneromooo>** I think it was just extra complexity htat might not be worth it.  
+**\<hyc>** my point - the current pool code calls getblocktemplate 1/second but doesn't do anything with the response if the height is the same as before  
+**\<hyc>** the pool code ought to just call getblockcount in that case, which executes in 0ms  
+**\<dEBRUYNE>** smooth commented on #810 -> https://github.com/monero-project/bitmonero/pull/810  
+**\* DaveyJones**: quotes deBRUYNE from yesterday : dEBRUYNE pages othe, NoodleDoodle, smooth, tewinget, binaryFate  
+**\<fluffypony>** so then the pool code is bad, right ?  
+**\<hyc>** yeah, in my perspective anyway  
+**\<xmrpromotions>** No comment on the code for https://github.com/monero-project/bitmonero/pull/794 but is there some way we can reach out to the family of warptangent to let them know we are very greatful for his contributions?  
+**\<smooth>** i added a comment to 810  
+**\<dEBRUYNE>** ^ His dad commented in the thread  
+**\<fluffypony>** xmrpromotions: they're already speaking to us, and we've let them know  
+**\<dEBRUYNE>** but let's stick to -dev decisions for now  
+**\<smooth>** 818 i think needs review by a cryptographer before we release that feature  
+**\<fluffypony>** agreed  
+**\<smooth>** hyc> the pool code ought to just call getblockcount in that case <= this is incorrect as we discussed before, but not relevant to 810  
+**\<moneromooo>** getinfo returns top hash.  
+**\<moneromooo>** And seems fairly lightweight.  
+**\<smooth>** it should check the top block hash, not height, but in any case even calling getblocktemplate 1/second isn't obvious to me would be a performance issue at all  
+**\<moneromooo>** Maybe PCFiL can test. He reported high CPU use when there were like 15 txes in the pool, and calming down at ~3.  
+**\<moneromooo>** Or I could test it actually, just curl that URI.  
+**\<smooth>** maybe we should look at why it takes so long then. when happens when there are 500?  
+**\<hyc>** fair enough, re: getinfo. still, it seems like this cache should be unnecessary  
+**\<fluffypony>** we can pack a bunch of transactions into testnet's mempool to see  
+**\<smooth>** next topic?  
+**\<hyc>** sounds like a good plan. perf optimizations should always have before/after metrics.  
+**\<fluffypony>** 811 / 812 / 813, any thoughts or objections on them ?  
+**\<hyc>** 811 seems pretty straightforward  
+**\<hyc>** tho moneromooo mentioned that the test in question never actually gets run  
+**\<hyc>** anyway, compiling unit tests is broken without it, so 811 needs to go in  
+**\<fluffypony>** ok  
+**\<fluffypony>** 812 seems fine too  
+**\<smooth>** those all look fine, noting that the net code is a complete black box to me so i can't really have an opinion there  
+**\<fluffypony>** ok - has anyone tested 815?  
+**\<moneromooo>** Well, I did :)  
+**\<fluffypony>** lol  
+**\<fluffypony>** 816 is also pretty straightforward  
+**\<fluffypony>** I'll review 817 later when I'm merging  
+**\<fluffypony>** and 819 is obvious  
+**\<moneromooo>** 818 won't apply once 816 is merged (duplicate -8 new error code), I'll update once this is done.  
+**\<hyc>** yeah 816 looks fine  
+**\<fluffypony>** I wouldn't bother yet - wait until there's been an MRL review on 818, moneromooo  
+**\<moneromooo>** OK  
+**\<fluffypony>** 810 I'll hold off on and let it bounce around, final decision at the next meeting if not before  
+**\<fluffypony>** ok so 806, the PR that fixes issue 805 - any final thoughts on it or can I merge?  
+**\<hyc>** works for me ;)  
+**\<moneromooo>** Seems fine. I didn' try it though.  
+**\<hyc>** it will make starting up a new wallet less painful for new users  
+**\<fluffypony>** oh and then unwind, I forgot about that - moneromooo you commented today that you're going to do some more work on that, do you want to merge and then submit further PRs for improvement, or work off that PR?  
+**\<moneromooo>** Leave it out for now.  
+**\<fluffypony>** k  
+**\<fluffypony>** so then performance  
+**\<fluffypony>** are we going to merge it, or leave it for 0.10.0 ?  
+**\<hyc>** conclusion - migrating DB schema in-place is much slower than just export/reimport from scratch  
+**\<fluffypony>** hyc: yeah I know, the conversion tool was always horrendously slow by comparison  
+**\<smooth>** im not sure that invalidates it  
+**\<fluffypony>** but in-place migration has its place  
+**\<fluffypony>** eg. when running as a service  
+**\<smooth>** easy of use matters, and if advanced users want to do it faster they can use th etools  
+**\<fluffypony>** agreed  
+**\<smooth>** sync from scratch is an option too, if they dont care about bandwidth  
+**\<fluffypony>** I guess the overriding factor here is that we suck at communicating with the end users that are running nodes  
+**\<fluffypony>** the fork taught me that, at any rate, so we have to assume people won't be reading release notes  
+**\<hyc>** ok. but are they going to notice that their newly restarted server isn't talking to anyone on the network for 1+ hour?  
+**\<fluffypony>** I don't think they'll care if it's an unattended server  
+**\<fluffypony>** we do need a way to universally respond to RPC calls with an error that explains that it's busy and this is the conversion % or something  
+**\<hyc>** ok  
+**\<gingeropolous>** i guess the use case to consider is shapeshift  
+**\<fluffypony>** yeah  
+**\<moneromooo>** RPC calls that care about this do return busy.  
+**\<moneromooo>** If not, file a bug with details.  
+**\<fluffypony>** moneromooo: a conversion will lock almost everything out, though ?  
+**\<fluffypony>** except I guess blindly broadcasting transactions  
+**\<moneromooo>** Oh, nevermind.  
+**\<smooth>** even then it probably has to verify them  
+**\<fluffypony>** yeah so I think the entire RPC interface has to error with a status  
+**\<moneromooo>** I'm guessing the RPC server will not be up yet if it's converting the db.  
+**\<hyc>** yeah, the conversion is firing up from db open  
+**\<hyc>** I don't think anything else is up yet  
+**\<fluffypony>** ah point  
+**\<smooth>** whats the problem with refusing to start until they do something with their db?  
+**\<smooth>** i mean error out at startup, no conversion  
+**\<smooth>** you can either delete/rename it (and therefore resync) or convert it  
+**\<fluffypony>** smooth: because in background mode / windows service mode you won't know that it's dying  
+**\<smooth>** you'll know its not working, there must be some way to indicate a reason  
+**\<fluffypony>** so practically: I have Bitcoin and Monero on a Windows node  
+**\<smooth>** maybe leave a message file behind and the cli can report the message  
+**\<moneromooo>** system("xmessage \"help\"")  
+**\<fluffypony>** and at some point the Bitcoin DB got corrupted (multiple times)  
+**\<fluffypony>** I have the service set to restart on fail, and eventually restart the whole machine  
+**\<fluffypony>** so it was restarting the machine every 15 minutes, and since I was only using the Monero node on it I had no idea  
+**\<gingeropolous>** right, so the overarching question is monero's philosophy on un-managed nodes  
+**\<gingeropolous>** (perhaps)  
+**\<hyc>** if truly no one is monitoring, then the daemon can do its conversion in however many hours it takes and no one will be bothered  
+**\<hyc>** if anyone is doing a health check they're gonig to wonder why it's not responding  
+**\<hyc>** Aside from that I'd feel more comfortable if someone besides me has tested the current branch with migration happening  
+**\<fluffypony>** I will  
+**\<hyc>** we know the perf code itself, not counting the migrate bit, is working fine  
+**\<fluffypony>** hyc: if I start it up with a current blockchain it'll just convert, right?  
+**\<hyc>** yep  
+**\<fluffypony>** ok I'll give it a spin on a few devices  
+**\<fluffypony>** so then I guess the final question is whether this goes into 0.9.x or 0.10.0 ?  
+**\<othe>** perf code itself i run on multiple nodes, from 32 bit arm to 64bit x86 - works absolutely flaweless here  
+**\<gingeropolous>** peanut gallery here - makes more sense to call it 0.9.x . big number change seems appropriate for consensus mechanism changes (i.e., ringct)  
+**\<bigreddmachine>** yeah i agree with gingeropolous in general... iterate the version on huge changes, subversion on consensus changes, and point on small changes that don't break consensus.  
+**\<fluffypony>** gingeropolous: I don't disagree, I'm also leaning towards it being a point release  
+**\<ArticMine>** Also if there is down time for the nodes during conversion a more gradual approach in 0.9.x is preferable  
+**\<bigreddmachine>** that maintains the idea that all 0.9.x are compatible, and not compatible for 0.10.x  
+**\<fluffypony>** well with a 0.9.x release everyone won't update at once  
+**\<hyc>** well, they're compatible on the wire, at least  
+**\<bigreddmachine>** and that's what matters in the long run... say 2-3 years from now there are lots of companies with various implementations and such, like in Bitcoin. a switch to 0.10.x indicates to them "get your stuff together or be left behind"  
+**\<fluffypony>** yeah  
+**\<bigreddmachine>** so might as well use that precedence earlier rather than later.  
+**\<fluffypony>** ok I think that's it from my side - does anyone have anything they want to ask / add / discuss ?  
+**\<smooth>** i think anything with a conversion process like that should be branded as a major/semi-major upgrade, especially since you can't easily downgrade  
+**\<dEBRUYNE>** perhaps a bit about ring CT? Though hyc kind of already said something about that before the discussion  
+**\<dEBRUYNE>** more specifically -> \<hyc> sounds good. looking at NobleSir's DB schema, doesn't seem like there's much new needed on the DB side of things  
+**\<fluffypony>** smooth: can definitely make that clear in the release  
+**\<dEBRUYNE>** oh and fluffypony, perhaps a bit about the 0MQ stuff as well?  
+**\<fluffypony>** hyc is better suited to update us on RingCT  
+**\<smooth>** 0mq is kind of a big issue i think, maybe leave for the next meeting  
+**\<xmrpromotions>** Is omq the only/primary reason why work is still being done on master instead of dev branch?  
+**\<smooth>** thats part of the whole issue of how the repo is organized and the workflow  
+**\<fluffypony>** yeah I think that's a discussion we can have at the next meeting  
+**\<hyc>** sorry I've got very little intelligent to say about ringct  
+**\<hyc>** i've compiled the code and run the test successfully  
+**\<hyc>** but I don't really think i'm in position to merge it, don't understand the pieces  
+**\<moneromooo>** I'm better acquainted with monero in general, though less with the db side.  
+**\<moneromooo>** And IANAC.  
+**\<fluffypony>** you are not a cat ?  
+**\<fluffypony>** obviously, you're a moo!  
+**\<moneromooo>** That is true.  
+**\<moneromooo>** Maybe we can get riddick on the job.  
+**\<fluffypony>** that's riddick-ulous  
+**\<moneromooo>** OK then. No cats.  
+**\<moneromooo>** Thing is, I'm wary of starting a large piece of work these days, as I don't have as much free time as I used to.  
+**\<dEBRUYNE_>** hyc, moneromooo: Perhaps the two of you could collaborate with NobleSir on it  
+**\<bigreddmachine>** Once the meeting is adjourned, can i hijack everyone/someone's attention for 2 mins to ask a question? it's not an official dev question, but still related i guess.  
+**\<othe>** just throw it out  
+**\<xmrpromotions>** can I ask about multi sig? Am I right that ring ct will be a prerequisit for it? I ask because it sounds like it will be needed for bitsquare (at least to be used as intended)  
+**\<othe>** no ringct is no prerequesite for multisig  
+**\<othe>** and no bitshares doesnt need it  
+**\<othe>** bitsquare  
+**\<fluffypony>** lol bitshares  
+**\<smooth>** notsquares  
+**\<othe>** all they need is some gui changes like payment id support or alternatively its enough to use integrated addresses instead  
+**\<othe>** and then they need support for the spendkey stuff to proof a payment, thats it  
+**\<moneromooo>** Multisig happens as a byproduct of ringct withou much extra work though AIUI.  
+**\<fluffypony>** yeah  
+**\<xmrpromotions>** ok thank you. maybe I read about dev priorities and misinterpreted a comment about ringct coming before multi sig  
+**\<bigreddmachine>** Can I get someone's opinion on something? The "incoming\_transfers" simplewallet method with "all" as the type returns a list of all transfers with in XMR coming into the wallet, including change from outgoing txs. For the wallet i've been working on, I have introduced a way to track outgoing transactions locally and store them using IndexedDB, since there’s not a good way to do that over rpc. I’d like  
+**\<bigreddmachine>**  to present users with a "pseudo-ledger" so-to-speak that showed incoming txs and outgoing txs, and should add up to the balance for a wallet. Would it be correct/good/valid for me to check the returns from "incoming\_transfers" to see if any tx\_ids match those from the outgoing transfers database, and if they do match, don't display them? That would result in the displayed "incoming transfers" to only be  
+**\<bigreddmachine>** transfers from another source.  
+**\<moneromooo>** incoming\_transfers shows the raw outputs. So you need to subtract those coming back from the ones leaving with the same txid.  
+**\<moneromooo>** But I'll add RPC for the others in the near future.  
+**\<binaryFate>** moneromooo can you be more explicit, what do you intend to add?  
+**\<bigreddmachine>** Well, the data i record in the database is only the amount that leaves the wallet (it is ignorant of the fact that there is change leaving and coming back). Although, come to think of it, it also is ignorant of the fee paid... hmm, okay, i'll need to think on this more  
+**\<moneromooo>** RPC for getting the same info that show\_transfers displays.  
+**\<binaryFate>** ok  
+**\<bigreddmachine>** ^that would solve all my issues and i'd love you forever. in a manly way.  
+**\<dEBRUYNE_>** othe: afaik Bitsquare needs it if you want XMR/fiat markets  
+**\<othe>** altcoins are the fiat markets in bitsquares atm i think  
+**\<bigreddmachine>** dEBRUYNE_: that's correct. but based on the interview on daily decrypt, i don't think he plans to have fiat markets other than BTC anytime soon. he kind of alluded to that.  
+**\<bigreddmachine>** he said in the interview that if you wanted to trade an altcoin for fiat, you'd have to go through bitcoin because that's what has the best liquidity and what multisig is implemented in the market  
+**\<othe>** correct  
--- a/_posts/2016-05-08-logs-for-the-kovri-dev-meeting-held-on-2016-05-08.md
+++ b/_posts/2016-05-08-logs-for-the-kovri-dev-meeting-held-on-2016-05-08.md
@ -0,0 +1,117 @@
+---
+layout: post
+title: Logs for the Kovri Dev Meeting Held on 2016-05-08
+summary: Mac / BSD support moving forward
+tags: [dev diaries, i2p, crypto]
+author: dEBRUYNE / fluffypony
+---
+ 
+*May 8th, 2016*
+ 
+# Logs
+
+**\<anonimal>** Hi fluffypony  
+**\<fluffypony>** hiiii  
+**\<fluffypony>** was just about to check if you're around :)  
+**\<anonimal>** Hi everyone, I think meeting-bot is still online  
+**\<fluffypony>** yes it is  
+**\<fluffypony>** coming through loud and clear on this side  
+**\* anonimal** reading backlog  
+**\<anonimal>** Hi moneromoo.  
+**\<anonimal>** Hi psi, uncrustify configs? Can you explain?  
+**\<psi>** uncrustify is a code styler for c/c++  
+**\<fluffypony>** I've never heard of it, plz tell me more psi?  
+**\<psi>** it auto formats the code  
+**\* psi** gets relevant links  
+**\<psi>** https://github.com/uncrustify/uncrustify  
+**\<anonimal>** I know that psi, but why for *.conf?  
+**\<psi>** i don;t understand?  
+**\<psi>** what about *.conf?  
+**\<fluffypony>** oh anonimal  
+**\<fluffypony>** not for *.conf  
+**\<fluffypony>** he means conf file for uncrustify matching our coding style  
+**\<psi>** damn lag  
+**\* psi** waits to catch up  
+**\<psi>** fluffypony: right  
+**\* anonimal** back  
+**\<fluffypony>** wb  
+**\<anonimal>** To answer the question, no I don't have an uncrustify config for kovri.  
+**\<anonimal>** Just a simple .vimrc.  
+**\<anonimal>** I can take a look at creating a config after #174 is resolved.  
+**\<anonimal>** fluffypony: I saw your comment in #56, what system are you runnning?  
+**\<fluffypony>** anonimal: Ubuntu 14.04  
+**\<fluffypony>** and there's no Boost 1.59 / 1.60 available  
+**\<fluffypony>** but that little hack worked  
+**\<anonimal>** 1.54 should work though  
+**\* anonimal** triple checks  
+**\<fluffypony>** I can't use 1.54  
+**\<fluffypony>** incompatible with Monero  
+**\<psi>** monero needs .56 or higher ?  
+**\<fluffypony>** .55 or higher  
+**\<psi>** kk  
+**\<fluffypony>** so basically .59 or higher if you want both  
+**\<anonimal>** I need about 5-15 minutes to build on bsd and osx so I can open the new linkage error tickets I talked about in #174  
+**\<fluffypony>** kk  
+**\<psi>** :\  
+**\* anonimal** the only time I have is now and a bit later but the meeting is now so I want to throw it into the topic  
+**\* anonimal** still compiling, should be done in 5 or so  
+**\<anonimal>** #monero-dev, FYI, our meetings have always been more organized, on-point, and I've almost always been prepared.  
+**\<anonimal>** This one caught me off guard.  
+**\<anonimal>** (last minute suggestion by fluffypony)  
+**\<anonimal>** Sorry for the wait.  
+**\<fluffypony>** don't stress, ours are always by the seat of our pants  
+**\* anonimal** opening tickets  
+**\<anonimal>** Hmf, I need to work with the bsd a bit more before posting.  
+**\<anonimal>** Anyway, https://github.com/monero-project/kovri/issues/175  
+**\<anonimal>** I'm only sitting with this again since I left off < 24 hours or so ago so,  
+**\<anonimal>** I haven't drawn any conclusions yet.  
+**\<anonimal>** Has anyone seen this before? #monero-dev?  
+**\* fluffypony** clicks  
+**\<fluffypony>** moneromooo: seen anything like that before ?  
+**\<fluffypony>** "Undefined symbols for architecture x86_64"  
+**\<anonimal>** The usual 'Undefined symbols for architecture x86_64' has been an osx complaint on this machine in the past.  
+**\<moneromooo>** Not as such. I've seen plenty of really annoying linking issues though.  
+**\<fluffypony>** this is gcc on OS X tho, right ?  
+**\<anonimal>** fluffypony: Yes.  
+**\<fluffypony>** maybe we're chasing our tails on that  
+**\<anonimal>** I don't have time to deal with clang. If we want multi-distro builds, I need to streamline our process.  
+**\<anonimal>** for macosx, clang won't build because it doesn't like the things I did for the reseed rewrite and,  
+**\<anonimal>** I don't have time to keep-up with llvm development.  
+**\<anonimal>** So, thoughts?  
+**\<fluffypony>** rewrite everything in C :-P  
+**\<anonimal>** lol  
+**\<fluffypony>** ok my suggestion is that we eschew OS X / BSD compatibility for the moment  
+**\<fluffypony>** until we can fix Clang support  
+**\<anonimal>** Thanks moneromoo. I'm glad this isn't just a kovri thing.  
+**\<fluffypony>** rather than trying to fudge it  
+**\<anonimal>** Well that's the problem, this won't be the only issue.  
+**\<fluffypony>** yeah I know  
+**\<anonimal>** And I'll end up wasting time juggling compilers instead of working on other things.  
+**\<fluffypony>** I mean that can be a later piece of work  
+**\<fluffypony>** let's focus on getting it working on one Linux and Windows, where we're running gcc and it's fine  
+**\<anonimal>** fluffypony: what part will be the later piece of work?  
+**\<fluffypony>** anonimal: fixing Clang incompatibilities  
+**\<moneromooo>** I don't use OSX btw, so kinda ignore what I said above.  
+**\<anonimal>** Ok sounds great, I'll focus on linux/win building.  
+**\<anonimal>** Should we remove osx/bsd build instructions from BUILDING.md?  
+**\<anonimal>** Or I'll just open the bsd ticket and maybe someone will see it?  
+**\<fluffypony>** yeah, I think let's make a note that it's broken on OS X / BSD for the moment, and that contributors are welcome to fix  
+**\<fluffypony>** kk  
+**\<anonimal>** Ok, I'll add the note.  
+**\<anonimal>** Any other questions/comments on #175?  
+**\<fluffypony>** no not yet  
+**\<fluffypony>** I mean no not atm, lol  
+**\<anonimal>** Ok, I'll add a note in #174 about what we discussed.  
+**\<anonimal>** And part 1) in #174, apparently there is an env variable I can set to get it to work.  
+**\<anonimal>** Not the first travis issue I've had to deal with.  
+**\<anonimal>** Oh well, they are growing quite nicely IMHO.  
+**\<fluffypony>** travis issues are growing quite nicely ?  
+**\<anonimal>** lol, yes, and I meant their project as a whole.  
+**\<fluffypony>** lol  
+**\<anonimal>** Ok, hour is up. Anything else pressing?  
+**\<fluffypony>** I don't think so - this was kinda an interim meeting because Kovri's was last week  
+**\<fluffypony>** so this brings them into line  
+**\<fluffypony>** next one on May 22nd, same time  
+**\<anonimal>** Ok, I'll mark the calendar.  
+**\<anonimal>** Thanks everyone.  
+**\<fluffypony>** thank you
--- a/_posts/2016-05-08-overview-and-logs-for-the-dev-meeting-held-on-2016-05-08.md
+++ b/_posts/2016-05-08-overview-and-logs-for-the-dev-meeting-held-on-2016-05-08.md
@ -0,0 +1,127 @@
+---
+layout: post
+title: Overview and Logs for the Dev Meeting Held on 2016-05-08
+summary: Clarification on ringCT next steps, 0MQ, discussion of open PRs
+tags: [dev diaries, core, crypto]
+author: dEBRUYNE / fluffypony
+---
+
+*May 8th, 2016*
+
+# Logs
+
+**\<fluffypony>** hyc, moneromooo, smooth, luigi1111w, luigi1112, luigi1114, ArticMine, NoodleDoodle, tewinget: meeting starting  
+**\<hyc>** hey  
+**\<fluffypony>** and othe  
+**\<fluffypony>** just waiting for the relay to come up  
+**\<fluffypony>** there we go  
+**\<luigi1112>** Not here  
+**\<fluffypony>** hello, and welcome to the 75th annual hunger games  
+**\<bigreddmachine>** crap, luigi1112's not here.  
+**\<fluffypony>** luigi1112 is literally a ghost  
+**\<fluffypony>** ok so we have a couple of PRs hanging around  
+**\<bigreddmachine>** is that why there are always 2-3 of him?  
+**\<fluffypony>** bigreddmachine: exactly :)  
+**\<luigi1112>** Hoooooo can say  
+**\<fluffypony>** I've reviewed #831 and it's ready for merge  
+**\<fluffypony>** same with 827  
+**\<fluffypony>** has anyone had further thoughts on 818 or are we ok with merging that functionality in its current form ?  
+**\<fluffypony>** bearing in mind that this will haunt us basically forever  
+**\<fluffypony>** and we pretty much can't change it ever again  
+**\<fluffypony>** no pressure or anything  
+**\<fluffypony>** (just kidding, we can definitely version it)  
+**\* fluffypony** waaaaaits  
+**\<hyc>** I haven't looked at 818, it's a crypto question still  
+**\<fluffypony>** yeah I think shen looked at it  
+**\<fluffypony>** ok we'll put a peg on that pending input from moneromooo and smooth  
+**\<ArticMine>** What are shen's thoughts on 818?  
+**\<MRL-Relay>** {-shen} I took a glance at it, but if desired I can look deeper  
+**\<MRL-Relay>** {-shen} at glance looked ok  
+**\<fluffypony>** shen: I think take a closer look if you can, given how we \*are\* stuck with it forever we may as well try get it right off the bat  
+**\<MRL-Relay>** {-shen} ok I will budget some time today or tomorrow  
+**\<fluffypony>** ok cool  
+**\<fluffypony>** then with the performance branch (794) we found an issue with the initial migration, messed up a global index on some txos  
+**\<luigi1112>** Is that the sig thing?  
+**\<fluffypony>** this appears to be fixed with the new / faster migration  
+**\<fluffypony>** luigi1112: yes  
+**\<luigi1112>** Ok  
+**\<fluffypony>** luigi1112: also I think if you have a second do you want to glance at the output format, maybe we need to give it a version prefix and a suffix of some sort  
+**\<fluffypony>** ok so performance is ready for merge, unless anyone has an objection  
+**\<hyc>** sounds good to me  
+**\<fluffypony>** then 810, I'm still unclear as to whether we're dropping that idea or we're merging it  
+**\<hyc>** given the increased locking requirements I'm against it.  
+**\<fluffypony>** ok  
+**\<hyc>** and as said before, I think fixing the pool code to use cheaper queries is better  
+**\<fluffypony>** I'm onboard with that  
+**\<fluffypony>** so now that we're getting the performance branch out the way  
+**\<fluffypony>** the next two major things on the radar are 0MQ and ringct  
+**\<fluffypony>** at the moment we have that stall in the dev branch, not sure whether it's time to nuke it and start the new one  
+**\<fluffypony>** I'll wait for input from moneromooo on that  
+**\<fluffypony>** and then ringct - hyc, did you say you were going to do some of that? I can't even remember  
+**\<hyc>** I looked into it but no, moneromooo should take lead  
+**\<fluffypony>** ok  
+**\<fluffypony>** shen  
+**\<hyc>** I can do whatever DB additions are needed  
+**\<fluffypony>** what's the status of your implementation code ?  
+**\<dEBRUYNE>** perhaps hyc can assist with the DB stuff  
+**\<dEBRUYNE>** oh he was quicker than me already  
+**\<MRL-Relay>** {-shen} Should be ready for test net at least  
+**\<fluffypony>** ok  
+**\<fluffypony>** it's time for a testnet fork anyway, so we can work towards that  
+**\<fluffypony>** basically everything else requires moneromooo and smooth, so we can put a peg in them till next meeting  
+**\<fluffypony>** speaking of which  
+**\<fluffypony>** next one on the 22nd  
+**\<dEBRUYNE>** perhaps they will show up within the next 30 minutes :-P Just page them 3 times!  
+**\<fluffypony>** hah hah  
+**\<dEBRUYNE>** Btw fluffypony, will the performance branch be used for a new point release?  
+**\<fluffypony>** dEBRUYNE: yes  
+**\<dEBRUYNE>** All right  
+**\<dEBRUYNE>** Btw, if moneromooo and smooth show up later tonight and have a chat about 0MQ we could just add that to the dev logs  
+**\<fluffypony>** ok  
+**\<bigreddmachine>** q: for the next point release... will it include arm7 binaries? 0.9.4 does not  
+**\<fluffypony>** it should  
+**\<bigreddmachine>** okay. unreleated, probably for hyc... you mentioned that simplewallet now only needs to sync ~30 MB instead of 3 GB with the new improvements. What was the savings? was there just a lot of data being shared that was unnecessary?  
+**\<luigi1112>** fluffypony: I'll think about that  
+**\<hyc>** bigreddmachine: sync of irrelevant blocks, only needed to use hashes  
+**\<bigreddmachine**> kk, thats what i figured  
+**\<bigreddmachine>** now just syncing block headers?  
+**\<hyc>** up to a given refresh height it only syncs hashes  
+**\<fluffypony>** moneromooo: we can carry on chatting about the bits you missed after the kovri meeting, if that's ok ?  
+**\<moneromooo>** Sure.  
+**\<fluffypony>** ok back to the Monero side  
+**\<fluffypony>** moneromooo: have you had a chance to read the meeting backlog ?  
+**\<moneromooo>** I did.  
+**\<fluffypony>** ok - thoughts on 0MQ / dev branch?  
+**\<fluffypony>** if you have the dev branch on your fork we can nuke it and reset  
+**\<moneromooo>** I think you can nuke the dev branch.  
+**\<moneromooo>** As for 0mq... whenever I get to start it, it's going to be a largeish amount of work at once I think.  
+**\<fluffypony>** ok  
+**\<moneromooo>** I happen to be not super motivated to code these days, after day job spent debugging stuff.  
+**\<fluffypony>** sometimes you gotta take a break and work on fun stuff  
+**\<dEBRUYNE>** perhaps Ring CT qualifies as fun stuff, perhaps not :-P  
+**\<moneromooo>** What's more important btw, 0mq or ringct ?  
+**\<fluffypony>** I would think ringct  
+**\<dEBRUYNE>** I'd say Ring CT too  
+**\<dEBRUYNE>** Iirc ring CT needs to be some time on testnet too anyway  
+**\<moneromooo>** And we can ask the "did nobody test this ?" peanut gallery in to test it :D  
+**\<fluffypony>** awesome  
+**\<moneromooo>** One other thing I wanted to do, which is interesting from a user's point of view, is to allow the wallet to see/decode pool txes.  
+**\<moneromooo>** That's probably not too much work.  
+**\<dEBRUYNE>** lol moneromooo   
+**\<dEBRUYNE>** Btw moneromooo, in case you hadn't read it yet hyc can assist you with the DB stuff  
+**\<dEBRUYNE>** More specifically -> \<hyc> I can do whatever DB additions are needed  
+**\<moneromooo>** I saw that. It's good so I don't break it all.  
+**\<dEBRUYNE>** Btw fluffypony, I forgot to ask earlier. Not sure if he is here, but any plans to opensource NoodleDoodle's trezor code soon^tm?  
+**\<fluffypony>** you'd have to ask NoodleDoodle that  
+**\<dEBRUYNE>** all right, perhaps he responds :-P  
+**\<moneromooo>** Oh: about reviewing the signature patch, IIRC smooth said that code was only used for the debug commands, so the CN people might not have make it so resistant to misuse or something. So might be worth looking at its internals (I expect it uses the same building blocks as ring signatures, but I don't really know).  
+**\<dEBRUYNE>** Also, regarding #810, a pool op commented the following: "Adding this to the current HEAD 8b0d22a reduces CPU by an order of magnitude on a pool wallet: 80% usage on a core down to 8%. Seems like a significant performance win to me." Since there is a mixed feeling about the PR itself I figured perhaps just close it and send the pool ops a mail that they could possibly apply the code/patch to their own code if they want to do so. I could   
+**\<dEBRUYNE>** gather email addresses and setup a standardized mail.  
+**\<dEBRUYNE>** ^ fluffypony   
+**\<moneromooo>** Changing the pool code to call getinfo and check top hash would also drop CPU usage a lot.  
+**\<fluffypony>** shen, see above ^^  
+**\<fluffypony>** (before the pool code stuff)  
+**\<MRL-Relay>** {-shen} ok  
+**\<MRL-Relay>** {-shen} good point  
+**\<dEBRUYNE>** moneromooo: I see, well then it's more up to the pool ops instead of the contributors/developers imo  
+**\<moneromooo>** Up to whoever gets his butt in gear to do it, as usual :D
--- a/_posts/2016-05-22-logs-for-the-kovri-dev-meeting-held-on-2016-05-22.md
+++ b/_posts/2016-05-22-logs-for-the-kovri-dev-meeting-held-on-2016-05-22.md
@ -0,0 +1,202 @@
+---
+layout: post
+title: Logs for the Kovri Dev Meeting Held on 2016-05-22
+summary: GNU Social status, Kovri website, i2p StackExchange, Coverity for Kovri
+tags: [dev diaries, i2p, crypto]
+author: dEBRUYNE / fluffypony
+---
+ 
+*May 22nd, 2016*
+ 
+# Logs
+
+**\<fluffypony>** ok starting the meeting relay for the Kovri meeting  
+**\<meeting-bot> [anonimal]** Hello.  
+**\<fluffypony>** anonimal: all yours :)  
+**\<i2p-relay> {-anonimal}** From https://github.com/monero-project/kovri/issues/177  
+**\<i2p-relay> {-anonimal}** Proposed meeting items:  
+**\<i2p-relay> {-anonimal}** 17:00 (UTC)  
+**\<i2p-relay> {-anonimal}** 1. Review assigned open tickets: status, code ideas (if applicable), etc.  
+**\<i2p-relay> {-anonimal}** 2. Any additional meeting items  
+**\<i2p-relay> {-anonimal}** 3. Confirm next meeting date/time  
+**\<i2p-relay> {-anonimal}** Starting with 1., as discussed in private with fluffypony, let's tackle https://github.com/monero-project/kovri/issues/assigned/fluffypony  
+**\<fluffypony>** hokay - should we do them one at a time ?  
+**\<meeting-bot> [anonimal]** Sure, #105.  
+**\<fluffypony>** sec, just opening it up  
+**\<meeting-bot> [anonimal]** I'm more curious about status updates and if we'll pursue some of these ideas.  
+**\<fluffypony>** ok 107  
+**\<fluffypony>** I asked dEBRUYNE and the rest of the social media guys about that in January last  
+**\<fluffypony>** dEBRUYNE: have you guys looked at that at all ?  
+**\<dEBRUYNE>** I think xmrpromotions was handling that  
+**\<meeting-bot> [anonimal]** JFTR: s/107/105/  
+**\<dEBRUYNE>** I honestly cannot remember you asking me :-P  
+**\* fluffypony** has the IRC logs to prove it :-P  
+**\<dEBRUYNE>** regardless, I think xmrpromotions was handling most of that :-P  
+**\<fluffypony>** ok - xmrpromotions, did you have a chance to look at GNU Social ?  
+**\<ArticMine>** I am looking at GNU social right now  
+**\<xmrpromotions>** I am sorry but I have not  
+**\<meeting-bot> [anonimal]** Can I ask everone, candidly, what they think of the idea?  
+**\<meeting-bot> [anonimal]** Is it something worth pursuing?  
+**\<ArticMine>** My initial instinct is yes  
+**\<fluffypony>** tbh I had hardly heard about GNU Social till you brought it up  
+**\<xmrpromotions>** Are there more details I can read about it? https://github.com/monero-project/kovri/issues/105  
+**\<fluffypony>** but I think in terms of providing a more freedom-friendly social presence it's advantageous  
+**\<fluffypony>** plus if we can spend the energy maintaining a Facebook page we can definitely justify this... :-P  
+**\<ArticMine>** Way better than a Facebook page  
+**\<ArticMine>** There are many who dislike the corporate centralization of Facebook in social media  
+**\<meeting-bot> [anonimal]** xmrpromotions: A great example of a working instance is https://quitter.se/  
+**\<__uguu__>** facebook is currently actively banning users that talk about the censorship too so...  
+**\<meeting-bot> [anonimal]** xmrpromortions: For technical details, https://gnu.io/social/  
+**\<meeting-bot> [anonimal]** lol, sorry, not auto-completion here  
+**\<meeting-bot> [anonimal]** Yes, recent news items re: censorship just get crazier and crazier.  
+**\<xmrpromotions>** Thank you I will read the details and be ready to comment later. It is too early for me to commit to anything quite yet  
+**\<meeting-bot> [anonimal]** And the social monopolies are finally showing their true colors.  
+**\<meeting-bot> [anonimal]** Ok, so #105 is on hold pending xmrpromotions' review?  
+**\<fluffypony>** yup  
+**\<meeting-bot> [anonimal]** Ok, next ticket.  
+**\<fluffypony>** ok  
+**\<meeting-bot> [anonimal]** #46  
+**\<meeting-bot> [anonimal]** The Kovri website.  
+**\<fluffypony>** #46 - does anyone have any strong opinions on whether it should be a page on the Monero website, or a separate site that matches the Monero site's look and feel (maybe with different colours), or a completely unrelated site ?  
+**\<fluffypony>** anonimal: and your input on this would be appreciated too  
+**\<fluffypony>** I think the relay is wonky  
+**\<meeting-bot> [anonimal]** What's the time-cost in terms of managing two sites?  
+**\<meeting-bot> [anonimal]** Yes, missed almost everything it looks like.  
+**\<fluffypony>** anonimal: it's mostly just the initial work, after that I mostly go hands-off and let the community run with the content  
+**\<meeting-bot> [anonimal]** Can anyone read this?  
+**\<meeting-bot> [anonimal]** Ok, so could we start small with a page on the website, or maybe subdomain/ and if things get bigger move onto another site?  
+**\<fluffypony>** that would be my recommendation  
+**\<fluffypony>** we start with a sub-section on the Monero site  
+**\<fluffypony>** and forward the kovri site through to it  
+**\<fluffypony>** if we feel the need later on we can create a separate site on its own  
+**\<meeting-bot> [anonimal]** Ok, sounds good to me. Anyone else?  
+**\<xmrpromotions>** Of the three options mentioned a separate site that matches the Monero site's look and feel may help draw a wider audience than a page on the Monero site while at the same time anyone who visits the Kovri page knows that Monero is associated with it  
+**\<xmrpromotions>** It seems like a judgement call to me. Either plan sounds reasonable  
+**\<fluffypony>** restarting meeting bot  
+**\<fluffypony>** in fact, if you want to write up some content for me I'll do it on the plane on Tuesday  
+**\<fluffypony>** in fact, I can probably take most of it from the readme  
+**\<fluffypony>** in fact, if I say in fact again I'll summon the in-fact-bot  
+**\<meeting-bot> [anonimal]** Ok, ideas for content? I can blabber but ideas are welcome.  
+**\<meeting-bot> [anonimal]** ping in-fact-bot  
+**\<xmrpromotions>** Any thoughts on creating a stackexchange proposal for I2P? Tor has a page now https://area51.stackexchange.com/proposals/56447/tor and we should be able to reach the commitment stage quickly with the same supporters behind the Monero proposal?  
+**\<fluffypony>** xmrpromotions: we'd have to run it past zzz, at the very least  
+**\<meeting-bot> [fluffypony]** zzz ^^  
+**\<xmrpromotions>** sorry for off topic idea. I can table it for later if appropriate  
+**\<fluffypony> no I think it's an excellent idea, if the i2p community at large is interested then now is definitely the time  
+**\<meeting-bot> [anonimal]** From what I've seen, alot of great ideas come and go through #i2p-dev but it always comes down to resources.  
+**\<meeting-bot> [anonimal]** I think we'd all love that but someone will have to take the initiative.  
+**\<xmrpromotions>** I will take the initiative on that  
+**\<meeting-bot> [anonimal]** AFAICT all i2p-related dev (including Kovri) is in a bit of a dry spell so, priorities.  
+**\<meeting-bot> [anonimal]** I like the idea though.  
+**\<fluffypony>** anonimal: the advantage is that we can basically get everyone who's committed to the Monero proposal to also back an i2p proposal  
+**\<fluffypony>** but now is the time to do so  
+**\<fluffypony>** whilst everyone's excited  
+**\<meeting-bot> [anonimal]** Ok, so what's the next step?  
+**\<xmrpromotions>** If the I2P communty supports it. As fluffypony said now is the time as the synergy will help both I2P and Monero proposals pass faster for REP related reasons  
+**\<fluffypony>** so basically next step on the website is let's get a bit of content and I'll put it together on the plane on Tuesday  
+**\<fluffypony>** next step on the StackExchange proposal is to wait for feedback from zzz  
+**\<xmrpromotions>** sounds good. I wont act until I hear confirmation that zzz is ready to proceed  
+**\<meeting-bot> [anonimal]** I dropped a line in #i2p-dev.  
+**\<meeting-bot> [anonimal]** We'll see who bites.  
+**\<meeting-bot> [anonimal]** Ok, so #46: 1) create content 2) On Tuesday, fluffypony will put something together 3) ETA after that?  
+**\<fluffypony>** ok next ticket ?  
+**\<fluffypony>** oh  
+**\<fluffypony>** once it's pushed to the repo it goes live  
+**\<fluffypony>** there's no ETA beyond that  
+**\<fluffypony>** or no steps beyond pulling it and rebuilding the Jekyll site  
+**\<meeting-bot> [anonimal]** Ok great, I'll paste a note in ticket.  
+**\<meeting-bot> [anonimal]** Moving on, #43.  
+**\<fluffypony>** ok - can we just use the Monero addresses, or do we want separate addresses?  
+**\<meeting-bot> [anonimal]** I'm fine with Monero addresses.  
+**\<fluffypony>** ok then they're avialable here, anonimal: http://donate.getmonero.org  
+**\<fluffypony>** *available  
+**\<meeting-bot> [anonimal]** Ok. Also, I can apply for FFS when needed or include my address somewhere or we can simply put a note in README to donate to either. Sound fair?  
+**\<meeting-bot> [anonimal]** Or no?  
+**\<othe>** ffs is prolly more efficient  
+**\<fluffypony>** FFS is better than direct donations  
+**\<fluffypony>** and it's generally more trustworthy because you raise funds for a specific piece of work, and then get paid out on milestones  
+**\<meeting-bot> [anonimal]** Ok, we should put a note in README directing to FFS and donation page or just FFS?  
+**\<fluffypony>** the readme just needs the donation page  
+**\<fluffypony>** if we get large donations we redistribute them to active FFS proposals anyway  
+**\<meeting-bot> [anonimal]** fluffypony: Ok, would you like to add that with your wording to the README? Or should I?  
+**\<fluffypony>** anonimal: I have to pack tomorrow, and have a bunch of things to do, so if you could that would be appreciated  
+**\<meeting-bot> [anonimal]** Ok  
+**\<meeting-bot> [anonimal]** Moving on, #27  
+**\<fluffypony>** ok #27 is going to have to hold for a week or two, we're busy moving email providers on getmonero.org so I'll sort it out on the new provider  
+**\<meeting-bot> [anonimal]** Ok, I'll paste that note.  
+**\<meeting-bot> [anonimal]** Onward to #20.  
+**\<fluffypony>** 20 - I can try Coverity again, let's see if it gives me the same issue  
+**\<fluffypony>** I've not heard from them despite opening tickets etc.  
+**\<meeting-bot> [anonimal]** Links? Maybe I can comment/ping them too.  
+**\<fluffypony>** anonimal: screenshots and process I followed is in that ticket  
+**\<fluffypony>** issue I mean  
+**\<meeting-bot> [anonimal]** Ok, well, it may come down to a phone call or two.  
+**\<meeting-bot> [anonimal]** Is that something you'd be willing to do?  
+**\<meeting-bot> [anonimal]** If not, we can skip the integration and try to do it manually.  
+**\<fluffypony>** sure  
+**\<meeting-bot> [anonimal]** Ok, next. #90 is not assigned to you but I remember you said you would assign yourself.  
+**\<fluffypony>** one second just checking coverity  
+**\<meeting-bot> [anonimal]** Is #90 still of interest?  
+**\<fluffypony>** oooooh it works  
+**\<fluffypony>** they must've fixed it and just not let us know  
+**\<fluffypony>** anonimal: I'll PM you with coverity details  
+**\<meeting-bot> [anonimal]** Fantastic!  
+**\<meeting-bot> [anonimal]** Yay, great. This should be interesting.  
+**\<gingeropolous>** will I break things if I create a bridge by connecting simplewallet to the daemon over an i2p tunnel?  
+**\<fluffypony>** doubtful  
+**\<meeting-bot> [anonimal]** fluffypony: #90?  
+**\<fluffypony>** 90 will happen automagically when our GitLab mirror is up  
+**\<fluffypony>** it'll have clearnet / Tor / i2p mirrors  
+**\<meeting-bot> [anonimal]** Ok then. I've missed any discussions about that in the past, is there an ETA?  
+**\<fluffypony>** not at the moment - it's one of those "on the list" things, I lack the time to knuckle down and do it  
+**\<fluffypony>** we need a devops team :-P  
+**\<meeting-bot> [anonimal]** Indeed. Ok, I'll add a note in ticket.  
+**\<meeting-bot> [anonimal]** To whom should we assign #90 then?  
+**\<fluffypony>** me  
+**\<meeting-bot> [anonimal]** Ok, will do.  
+**\<meeting-bot> [anonimal]** Yay, hour long of fluffypony tickets finally tackled! I'm glad we finally had the time. Any other comments them?  
+**\<fluffypony>** none from my side  
+**\<meeting-bot> [anonimal]** So, since this was the "fluffypony show" meeting, for time-sake I'll sum up my part of 1. with one line:  
+**\<meeting-bot> [anonimal]** I'm not working on any tickets ATM but what will most likely be a new ticket soon as I'm working on Transports (mostly NTCP, little SSU): debugging/refactoring/c++14 refactoring where appropriate/some rewrite/some new code/documentation/improved logging  
+**\<meeting-bot> [anonimal]** So, that's that for now, I'm sure more code talk can be at the next meeting.  
+**\<meeting-bot> [anonimal]** Any additional meeting items (quickly)?  
+**\<fluffypony>** nothing more from me  
+**\<meeting-bot> [anonimal]** Re: StackExchange, what tl;dr can I give to #i2p-dev?  
+**\<meeting-bot> [anonimal]** Aside from pointing a link to the meeting log.  
+**\<meeting-bot> [anonimal]** (I've been out of the loop re: the initiative)  
+**\<xmrpromotions>** Just say that we are willing to cross promote it to XMR community and expect it to reach the commitment stage fairly fasy  
+**\<xmrpromotions>** fast  
+**\<meeting-bot> [fluffypony]** just that it's a proposal to have an i2p-specific StackExchange area  
+**\<meeting-bot> [anonimal]** So, what should we expect from them?  
+**\<xmrpromotions>** from there the I2P and XMR communities can help each other ensure both site reach beta  
+**\<xmrpromotions>** Hard for me to make an ETA on that. End result would be an I2P site similar to what Tor has now  
+**\<meeting-bot> [anonimal]** fluffypony: should we end meeting?  
+**\<meeting-bot> [anonimal]** (or has it ended?)  
+**\<meeting-bot> [fluffypony]** yes I think so  
+**\<meeting-bot> [fluffypony]** I'll take the bot down  
+**\<xmrpromotions>** We need I2P experts to appear during the proposal stage once created to ask good questions  
+**\<xmrpromotions>** early questions attract a lot more votes and rise to the top, so quality matters  
+**\<meeting-bot> [anonimal]** Ok, I'll chat in #monero-dev.  
+**\<i2p-relay> {-anonimal}** * thinking  
+**\<i2p-relay> {-anonimal}** xmrpromotions: I can commit to both pages. How many I2P 'experts' would need to commit?  
+**\<xmrpromotions>** well we need 40 good questions. each person can only ask 5  
+**\<fluffypony>** well before commitment it's just the voting section  
+**\<xmrpromotions>** Our initial 40 questions will help with SEO after launch  
+**\<fluffypony>** where we need not only good questions asked, but also good questions have to get 10 votes each  
+**\<xmrpromotions>** Yes I mean we need to create quality questions to vote on  
+**\<xmrpromotions>** If someone wants to create a list of 40 great questions that would be perfect  
+**\<i2p-relay> {-anonimal}** 40 great I2P questions, I could do that.  
+**\<fluffypony>** they still have to post them though  
+**\<xmrpromotions>** then we can divide it up and ask 5 each to make sure no silly questions gain a lot of votes early in the process  
+**\<xmrpromotions>** we can find 8 people to post 5 questions each easily  
+**\<fluffypony>** yup  
+**\<fluffypony>** yeah, then we need a bunch of people to upvote :)  
+**\<xmrpromotions>** I dont think voting will be a problem either. XMR users with no rep can be assigned to ask the questions... that will give them 5x10x5 rep (250 each)  
+**\<xmrpromotions>** which will give them more than enough for the 200 rep area 51 cutoff for the SE 100 rep account association bonus  
+**\<fluffypony>** strategyyyy  
+**\<xmrpromotions>** 5q with 10 votes each will earn 5 rep per vote  
+**\<i2p-relay> {-anonimal}** Ok, sounds great. Right now, I need to finish post-meeting wrap-up, take a break, get my brain in order and bbl.  
+**\<fluffypony>** ok cool  
+**\<xmrpromotions>** I will make a post in the getmonero forums. Maybe we can create and agree on a list of 40 questions there before we start  
+**\<xmrpromotions>** thanks everyone. have a great weekend  
+**\<fluffypony>** cheers
--- a/_posts/2016-05-22-overview-and-logs-for-the-dev-meeting-held-on-2016-05-22.md
+++ b/_posts/2016-05-22-overview-and-logs-for-the-dev-meeting-held-on-2016-05-22.md
@ -0,0 +1,129 @@
+---
+layout: post
+title: Overview and Logs for the Dev Meeting Held on 2016-05-22
+summary: Decisions on PRs still open, performance branch conversion problems, consolidating dev documentation on the GH wiki
+tags: [dev diaries, core, crypto]
+author: dEBRUYNE / fluffypony
+---
+
+*May 22nd, 2016*
+
+# Logs
+
+**\<fluffypony>** ok  
+**\<fluffypony>** das meeting  
+**\<ArticMine>** has started  
+**\<fluffypony>** heh heh  
+**\<xmrpromotions>** let the fun begin  
+**\<fluffypony>** hyc, smooth, moneromooo, dEBRUYNE, gingeropolous, luigi1112, luigi1114, anyone I've missed  
+**\<fluffypony>** hokay so  
+**\<fluffypony>** first up: for those that haven't done so, please commit to the StackExchange proposal: http://area51.stackexchange.com/proposals/98617/monero  
+**\<gingeropolous>** oooh i get pinged for dev meetings? :)  
+**\<xmrpromotions>** and earn rep: https://forum.getmonero.org/20/general-discussion/2542/stack-exchange-commitment-requirements  
+**\<fluffypony>** you're basically just committing to asking / answering a total of 10 questions over 3 months  
+**\<fluffypony>** also it would be advantageous if you have over 200 rep on another StackExchange site, as xmrpromotions said  
+**\<fluffypony>** I earned over 200 rep on bitcoin.stackexchange by answering like 4 questions, so it's not hard  
+**\<fluffypony>** ok maybe like 6 questions, but still, not hard  
+**\<fluffypony>** I think getting 200 committers in total will be easy, but having 100 committers with sufficient rep might be a little harder  
+**\<fluffypony>** ok so  
+**\<fluffypony>** PRs  
+**\<fluffypony>** over the last couple of weeks we've merged a few PRs  
+**\<fluffypony>** obviously  
+**\<fluffypony>** the biggest one being the performance branch  
+**\<fluffypony>** which was what warptangent was working on before he passed away  
+**\<fluffypony>** and which was completed by hyc and everyone else  
+**\* dEBRUYNE** pages tewinget, NoodleDoodle, ArticMine, othe  
+**\<dEBRUYNE>** probably missed someone  
+**\<fluffypony>** we are seeing some latent issues with auto-conversions, or that appear to be coming from the auto-conversion  
+**\<fluffypony>** if users hit issues with that the fastest route is for them to sync from scratch  
+**\<fluffypony>** iirc smooth has a broken conversion that we can use to analyse the issue  
+**\<fluffypony>** 810 and 775 are dangling  
+**\<fluffypony>** moneromooo: do you want those to stay open at present ?  
+**\<moneromooo>** 810 might be cancelled, not sure.  
+**\<fluffypony>** ok  
+**\<moneromooo>** 775 is ready AFAIK.,  
+**\<fluffypony>** ok will test it  
+**\<fluffypony>** 818 is in a holding pattern pending some discussion; based on what shen has been doing lately my feeling is that we leave that till after RingCT is done  
+**\<fluffypony>** on that note, RingCT seems to be pushing ahead quite nicely  
+**\<fluffypony>** moneromooo: how's it looking from your side ?  
+**\<moneromooo>** I'm not a cryptographer, so I got no clue really :P  
+**\<fluffypony>** hah hah  
+**\<moneromooo>** Once I figure out what goes where, it's just code after that.  
+**\<fluffypony>** I know you're waiting for input from shen, but is it starting to make a bit of sense ?  
+**\<moneromooo>** Though a lot of it I think  
+**\<fluffypony>** kk  
+**\<moneromooo>** Mot yet, but I've not spent a lot of time on it today (and yesterday I was out).  
+**\<fluffypony>** alright  
+**\<saddam>** moneromooo: I want to decrypt it manually so I can detect transactions sent to an integrated address of mine in the tx pool. Is there another way to do it?  
+**\<fluffypony>** then next weekend I'll be at Bitcoin in Use in Arnhem, Netherlands  
+**\<moneromooo>** How will you know it's an integrated address of yours in the first place ?  
+**\<fluffypony>** and there will be several other Monero-er-ains there as well  
+**\<fluffypony>** including some devs, most notably hyc  
+**\<xmrpromotions>** a few ppl told me they want to meet you there:)  
+**\<saddam>** oh it's the meeting, sorry. I'll wait to discuss that later moneromooo  
+**\<fluffypony>** if anyone else is going to be there please let me know, we can do a Monero supper on the Saturday or something  
+**\<fluffypony>** next up is a chat about documentation  
+**\<fluffypony>** wallet42 has raised the idea of opening up the wiki on Github  
+**\<xmrpromotions>** https://twitter.com/Falkvinge/status/731833882102910977 wants to meet you too  
+**\<fluffypony>** the advantages of this is that it keeps the documentation close to the code  
+**\<fluffypony>** and you can PR to the wiki or (I think) edit it inline  
+**\<fluffypony>** xmrpromotions: oh neat  
+**\<fluffypony>** in fact, the wiki creates a .wiki.git project that's invisible-ish  
+**\<fluffypony>** so it makes syncing to GitLab easy (setting up a GitLab mirror is on the list of things to do)  
+**\<fluffypony>** downside is that you can't edit it anonymously, although creating a GH account is trivial  
+**\<fluffypony>** and the other downside is that we have tons of scattered documentation right now  
+**\<fluffypony>** so my thinking is that the wiki is a good idea for documentation, BUT then we need to kill off all these other sources of info  
+**\<dEBRUYNE>** ^ I don't mind putting part of it together  
+**\<fluffypony>** so the Monero wikia has to be shuttered and that info moved over  
+**\<ArticMine>** There is information all over BCT  
+**\<dEBRUYNE>** we could put the guides from Moneroexamples over there too, but he doesn't necessarily have to shutdown his "source" imo  
+**\<fluffypony>** same goes for dev guides etc. on the website - we should instead spend the effort writing a small Ruby plugin for the site that pulls in info from the wiki and formats it appropriately  
+**\<fluffypony>** then the wiki becomes a primary source of info  
+**\<fluffypony>** dEBRUYNE: yeah we could do the same thing with MoneroExamples  
+**\<fluffypony>** just have a plugin that grabs it from his repos and formats it  
+**\<fluffypony>** if anyone has an issue with this speak now or forever hold your peace  
+**\<i2p-relay>** {-anonimal} Such consolidation sounds like a good idea.  
+**\<dEBRUYNE>** fluffypony: Yeah that'd be fine too  
+**\<dEBRUYNE>** as long as it consolidates the information to a central place it's fine  
+**\<fluffypony>** I'll leave the question open till the start of the Kovri meeting, if nobody has major objections raised by then I'll consider the decision in favour of the GitHub wiki  
+**\<ArticMine>** It is actually really needed We have info all over the place  
+**\<fluffypony>** (we discussed this here a few days ago as well, and everyone generally seemed in favour of it)  
+**\<fluffypony>** ArticMine: agreed  
+**\<xmrpromotions>** I like the idea. Consolidation and simplification should hopefully encourage more people to contribute to it  
+**\<fluffypony>** that's it from my side - next meeting will be on the 5th of May, same time  
+**\<fluffypony>** if anyone has anything they want to discuss, or any other points they want to bring up, now's the time  
+**\<fluffypony>** we have 20-ish minutes till the Kovri meeting  
+**\<ArticMine>** I am looking at the fee structure  
+**\<moneromooo>** Does anyone fancy hacking the pool code to check top hash ?  
+**\<moneromooo>** It shold be fairly easy.  
+**\<i2p-relay>** {-anonimal} fluffypony: s/May/June/  
+**\<dEBRUYNE>** ArticMine: Is your research going to be put in a somewhat formal paper?  
+**\<moneromooo>** er, s/hacking/amending/ for the peanut gallery.  
+**\<ArticMine>** I'll start with a post on getmonero forum to get feedback ideas  
+**\<ArticMine>** then one can develop a paper  
+**\<dEBRUYNE>** all right  
+**\<ArticMine>** Along the lined of my prior post on BCT regarding the adaptive block limit and penalty function. There are issues with respect to to many options in fees with RingCT  
+**\<dEBRUYNE>** Is anyone willing to work on adding Monero to Bitsquare? Afaik it's only a few minor tweaks in the UI code, see issue here -> https://github.com/bitsquare/bitsquare/issues/392 | I might be able to try if I got some more time, emphasis on try though  
+**\<fluffypony>** anonimal: thanks, lol  
+**\<moneromooo>** To th UI of... ?  
+**\<dEBRUYNE>** Bitsquare itself  
+**\<dEBRUYNE>** It needs an additional field for the tx key  
+**\<moneromooo>** Ah, I just saw the screenshot.  
+**\<dEBRUYNE>** It's mainly to resolve disputes, if any occur  
+**\<dEBRUYNE>** Btw fluffypony, any ETA on a new point release that includes the performance branch? Or are we awaiting any more PRs?  
+**\<gingeropolous>** ArticMine, i look forward to the adaptive fee structure thread  
+**\<luigi1112>** Oh high team  
+**\<luigi1112>** Hi team too  
+**\<gingeropolous>** hi luigi1112  
+**\<fluffypony>** dEBRUYNE: more PRs, also gives us time to see if there are issues with auto-convert  
+**\<fluffypony>** *more issues  
+**\<xmrpromotions>** hi luigi1112  
+**\<moneromooo>** What would I do if I wanted to try and repro that problem ? just pull, build, run ?  
+**\<dEBRUYNE>** fluffypony: all right  
+**\<gingeropolous>** im just curious... is 0mq gonna happen before ringCT? or ... or all at once?  
+**\<fluffypony>** moneromooo: yeah  
+**\<fluffypony>** gingeropolous: no clue  
+**\<moneromooo>** I'm certainly doing nothing about it.  
+**\<gingeropolous>** well there's months until the next hardfork... though i guess 0mq doesn't affect consensus protocols?  
+**\<dEBRUYNE>** well it was either Ring CT or 0MQ for you afaik moneromooo and I think we decided last time that Ring CT was the priority (this is just to clarify to anyone reading)  
+**\<fluffypony>** ok starting the meeting relay for the Kovri meeting
--- a/_posts/2016-06-05-logs-for-the-kovri-dev-meeting-held-on-2016-06-05.md
+++ b/_posts/2016-06-05-logs-for-the-kovri-dev-meeting-held-on-2016-06-05.md
@ -0,0 +1,241 @@
+---
+layout: post
+title: Logs for the Kovri Dev Meeting Held on 2016-06-05
+summary: I2P StackExchange update, website content, Coverity issues, GNU social
+tags: [dev diaries, i2p, crypto]
+author: dEBRUYNE / fluffypony
+---
+
+*June 5th, 2016*
+
+### Logs
+
+**\<fluffypony>** ok so I think let's move on to Kovri - anonimal, the floor is yours  
+**\<meeting-bot> [anonimal]** Thanks fluffypony, I need about 30-60 seconds.  
+**\<fluffypony>** ok whilst you're doing that, there are two committers to the Monero StackExchange proposal that are just shy of 200+ rep on the Bitcoin StackExchange  
+**\<fluffypony>** so they need some upvotes if you have rep on the BTC StackExchange  
+**\<meeting-bot> [anonimal]** https://github.com/monero-project/kovri/issues/179  
+**\<meeting-bot> [anonimal]** 17:00 (UTC)  
+**\<fluffypony>** http://bitcoin.stackexchange.com/users/35760/dontmindme  
+**\<meeting-bot> [anonimal]** 1. Follow up on I2P StackExchange  
+**\<meeting-bot> [anonimal]** 2. Follow up on fluffypony's website content review  
+**\<fluffypony>** http://bitcoin.stackexchange.com/users/35975/jun-li  
+**\<meeting-bot> [anonimal]** 3. Follow up on Coverity  
+**\<meeting-bot> [anonimal]** 4. Review assigned open tickets: status, code ideas (if applicable), etc.  
+**\<meeting-bot> [anonimal]** 5. Any additional meeting items  
+**\<meeting-bot> [anonimal]** 6. Confirm next meeting date/time  
+**\<meeting-bot> [anonimal]** Point 1. is open to all.  
+**\<fluffypony>** i2p StackExchange is doing well: http://area51.stackexchange.com/proposals/99297/i2p  
+**\<meeting-bot> [anonimal]** Where do we stand?  
+**\<fluffypony>** 29% committed  
+**\<fluffypony>** 34/100 committers with 200+ offsite rep  
+**\<fluffypony>** but considering the small number of total committers (78/100) that's pretty impressive  
+**\<moneromooo>** I will have 200 tomorrow, probably. 1% more.  
+**\<fluffypony>** I would like to encourage anyone that has committed to the i2p and Monero proposals to please try drum up 200+ rep on one of the other Stacks by asking and answering questions  
+**\<meeting-bot> [anonimal]** Good, I was about to ask what else we could do.  
+**\<meeting-bot> [anonimal]** I'll start banging.  
+**\<fluffypony>** it's REALLY easy to get that much rep, the fastest way I've found is answering questions  
+**\<fluffypony>** but pick ONE StackExchange, as the rep isn't cumulative across Stacks  
+**\<meeting-bot> [anonimal]** Ok, anything else for point 1?  
+**\<fluffypony>** yes just a small thing  
+**\<xmrpromotions>** How do you feel about reaching out to leaders in the Tor community to request support? Some may be curious about I2P and active Tor SE users will really help us with activity requirements after launch  
+**\<fluffypony>** the deep web StackExchange proposal has failed due to lack of follow-through on commitments, so the i2p one is more necessary than before  
+**\<meeting-bot> [anonimal]** Hmm, tricky.  
+**\<fluffypony>** xmrpromotions: that's certainly a possibility, but the Tor community is going through a bit of a difficult time at the moment, it may be prudent for us to wait it out  
+**\<meeting-bot> [anonimal]** How do I say this quickly,  
+**\<fluffypony>** anonimal: by typing fast? :-P  
+**\<meeting-bot> [anonimal]** I have a strong impression that Tor does not care about I2P.  
+**\<meeting-bot> [anonimal]** Nothing personal, just different technologies.  
+**\<xmrpromotions>** If you are talking about the applebaum allegation I agree the timing is not great. I plan to largely ignore that news for now since the evidence is not even public  
+**\<meeting-bot> [anonimal]** I agree with fluffypony for now.  
+**\<meeting-bot> [anonimal]** I'd like to come back to that idea though in the future.  
+**\<xmrpromotions>** Okay. I wont make any aggressive outreach efforts to the Tor community at this time  
+**\<meeting-bot> [anonimal]** Ok, anything else on 1.?  
+**\<fluffypony>** nothing from my side  
+**\<meeting-bot> [anonimal]** 2. fluffypony, last meeting we talked about website content,  
+**\<meeting-bot> [anonimal]** I sent a draft. Status?  
+**\<fluffypony>** I have a content dump from anonimal - I've started with a page to the Monero site, and hope to have it PR'd by next weekend  
+**\<fluffypony>** I go to Berlin on Tue and then back to Amsterdam on Wed, and then back to Johannesburg on Thur, so there will be plenty of bored-in-the-plane opportunities to work on it  
+**\<meeting-bot> [anonimal]** Ok, I hope to get a chance to review anything because what I sent really was a 'dump' ;)  
+**\<fluffypony>** oh yeah definitely, plus you can always PR changes to the site, we merge everything there :-P  
+**\<meeting-bot> [anonimal]** lol  
+**\<meeting-bot> [anonimal]** Ok, anything else on 2.?  
+**\<xmrpromotions>** does 2 include gnu social or just the website?  
+**\<meeting-bot> [anonimal]** Free-for-all.  
+**\<meeting-bot> [anonimal]** xmrpromotions: any updates on gnu social?  
+**\<xmrpromotions>** Well I read up on GNU Social and really like the idea (I had not heard of it before) but I am worried about the time commitment it will involve to do well  
+**\<meeting-bot> [anonimal]** Could it be done 'good enough'?  
+**\<xmrpromotions>** Any suggestions for volunteers eager to help with that sort of thing that have extra free time right now  
+**\<meeting-bot> [anonimal]** I can help when the time comes.  
+**\<xmrpromotions>** I guess it depends what good enough means. I have never used GNU software but assume it will require many contributors providing good content in order to attract many users  
+**\<meeting-bot> [anonimal]** I've ran an instance in the past (personal, not public).  
+**\<fluffypony>** dEBRUYNE: is anyone on the social media team available to assist ?  
+**\<merkaba>** what is it about? I have some free time but I am not sure what this is  
+**\<merkaba>** if I have the skills required..  
+**\<fluffypony>** merkaba: oh I have a special job for you if you want to flex your Ruby skills ;)  
+**\<merkaba>** btw I am stefioan from reddit  
+**\<merkaba>** cool  
+**\<dEBRUYNE>** fluffypony: I am running out of free time currently, so hopefully someone else could pick it up (e.g. xmrpromotions and/or merkaba)  
+**\<nobbynoob>** what exactly is needed as help in the gnu social thing?  
+**\<meeting-bot> * anonimal** was just about to ask that  
+**\<xmrpromotions>** People to provide quality content and invite users is needed the most IMHO  
+**\<xmrpromotions>** I am not an expert and had not heard of it until 2 weeks ago  
+**\<nobbynoob>** so no coding or stuff, but posting content about xmr, its development etc?  
+**\<xmrpromotions>** here is the example someone gave me: https://quitter.se/social details here: https://gnu.io/social/about/  
+**\<meeting-bot> [anonimal]** Can twitter posts be cross-posted?  
+**\<xmrpromotions>** we are talking about Kovri now but yes we could use it for Monero too  
+**\<fluffypony>** maybe not automatically, anonimal, but certainly manually  
+**\<meeting-bot> [anonimal]** "If you build it, they will come".  
+**\<meeting-bot> [anonimal]** Why not baby steps for now: get it up and running, and we'll get on it and start using it?  
+**\<fluffypony>** agreed  
+**\<meeting-bot> [anonimal]** xmrpromotions: ETA on when it can be physically online?  
+**\<fluffypony>** xmrpromotions: shout if you need me to host it on one of the Monero infrastructure servers  
+**\<meeting-bot> * anonimal** side-channels fluffypony for preparations of 3. https://scan.coverity.com/projects/monero-project-kovri?tab=overview  
+**\<xmrpromotions>** I have not made any efforts to do that yet but my impression is pretty quick. All I did since last meeting was read the basic description of it and look at a few examples of how it has been deployed  
+**\<meeting-bot> [anonimal]** Can it be up by next meeting?  
+**\<xmrpromotions>** I think that is realistic.  
+**\<xmrpromotions>** It sounds like others will be willing to help provide content.  
+**\<meeting-bot> [anonimal]** Excellent.  
+**\<meeting-bot> [anonimal]** I'll start using it once its up.  
+**\<meeting-bot> [anonimal]** Anything else on point 2.?  
+**\<fluffypony>** nein  
+**\<meeting-bot> [anonimal]** Ok moving on to 3.  
+**\<meeting-bot> [anonimal]** "No builds were successfully analyzed yet."  
+**\<meeting-bot> [anonimal]** So, it looks like more Coverity setup issues.  
+**\<xmrpromotions>** thank you. I just dont want to spread myself too thin. The Deep web SE shutting down concerned me. We need to learn from that and ensure I2P and Monero SE metrics are all continually high enough during private beta  
+**\<fluffypony>** anonimal: argh. it's like they're trying to irritate me.  
+**\<meeting-bot> [anonimal]** xmrpromotions: good point, I will work on my rep.  
+**\<meeting-bot> [anonimal]** fluffypony: seriously, I have no idea why its so problematic.  
+**\<fluffypony>** anonimal did you see the hello world example ?  
+**\<meeting-bot> [anonimal]** Directions were followed to the T.  
+**\<meeting-bot> [anonimal]** fluffypony: Maybe, a long while ago. Link?  
+**\<fluffypony>** https://github.com/daksheshvyas/MyHelloWorld/  
+**\<fluffypony>** https://travis-ci.org/daksheshvyas/MyHelloWorld/  
+**\<fluffypony>** maybe check if there's not something they do there that we haven't done  
+**\<meeting-bot> [anonimal]** I remember those.  
+**\<meeting-bot> [anonimal]** Nope, our config checks out AFAICT.  
+**\<fluffypony>** https://scan.coverity.com/faq#frequency  
+**\<fluffypony>** we're way under teh frequency limits  
+**\<meeting-bot> [anonimal]** Is yrashk still on that side? Maybe he uses coverity/travis-ci?  
+**\<fluffypony>** he's already hopped offline afaik  
+**\<fluffypony>** it's nearly 1am his time  
+**\<meeting-bot> [anonimal]** I've also done several merges to branch coverity_scan to 'trigger' it, but to no avail.  
+**\<meeting-bot> [anonimal]** fluffypony: Any ideas on solutions? They really don't make it easy to contact them for troubleshooting.  
+**\<fluffypony>** hmmm anonimal  
+**\<fluffypony>** "You'll need to manually fill in your project specifics, including build_command_prepend and build_command."  
+**\<fluffypony>** we don't have the build_command_prepend  
+**\<fluffypony>** could that be a requirement ?  
+**\<meeting-bot> [anonimal]** I highly doubt it.  
+**\<fluffypony>** nothing would surprise me at this stage :-P  
+**\<tewinget>** saw my mention, will be available in...10 min or so if anyone needs me or wants my input on something.  Otherwise, hello everyone and enjoy the meeting or whatever.  
+**\<fluffypony>** anonimal: so "branch_pattern: coverity_scan" means it'll only build changes to the branch named coverity_scan, noto the master branch  
+**\<meeting-bot> [anonimal]** Yes.  
+**\<fluffypony>** ok  
+**\<meeting-bot> [anonimal]** And last merge into coverity_scan was May 29th.  
+**\<fluffypony>** maybe we should just include a build_command_prepend  
+**\<fluffypony>** something like cd build && make clean  
+**\<meeting-bot> [anonimal]** But what would we put? exporting variables?  
+**\<fluffypony>** the example has:  
+**\<fluffypony>**     build_command_prepend: "./configure; make clean"  
+**\<fluffypony>**     build_command:   "make -j 4"  
+**\<fluffypony>** maybe add a && cd ..  
+**\<meeting-bot> [anonimal]** Which doesn't make sense if the VM is fresh before every build.  
+**\<meeting-bot> [anonimal]** The build_command is sound, it would literally be a matter of splitting that up.  
+**\<fluffypony>** anonimal: yet the example has "make clean", so maybe they don't have a fresh VM each time ?  
+**\<meeting-bot> [anonimal]** so build_command_prepend: export CC=gcc-${GCC_VERSION} CXX=g++-${GCC_VERSION} && cd build  
+**\<fluffypony>** that could work if we're 100% sure it's a fresh VM  
+**\<meeting-bot> [anonimal]** It is. You can see it in all the travis build logs.  
+**\<fluffypony>** and Coverity runs on the Travis VM right ?  
+**\<meeting-bot> [anonimal]** Apparently?  
+**\<meeting-bot> [anonimal]** So, we could keep tinkering and hope for a result or email scan-admin@coverity.com  
+**\<meeting-bot> [anonimal]** Thoughts?  
+**\<merkaba>** guys I am leaving. if I can be help on any task feel free to contact me on reddit (/u/stefioan)  
+**\<fluffypony>** merkaba: will do, thanks  
+**\<meeting-bot> [anonimal]** Thanks merkaba.  
+**\<merkaba>** you are welcome  
+**\<fluffypony>** anonimal: I think let's try including a build_command_prepend, failing that I'll have to try reach out to Coverity  
+**\<fluffypony>** seeing as how they were so helpful last time  
+**\<fluffypony>** :-P  
+**\<xmrpromotions>** thanks merkaba. lets talk more about gnu social later  
+**\<meeting-bot> [anonimal]** merkaba:  
+**\<meeting-bot> [anonimal]** Isn't diaspora written in ruby?  
+**\<meeting-bot> * anonimal** checks  
+**\<fluffypony>** anonimal: he already left unfortunately  
+**\<meeting-bot> [anonimal]** xmrpromotions: if you see them again, https://github.com/diaspora/diaspora  
+**\<meeting-bot> [anonimal]** Ok fluffypony, I'll make the change and we'll see what happens.  
+**\<meeting-bot> [anonimal]** Anything else on 3.?  
+**\<fluffypony>** nope  
+**\<meeting-bot> [anonimal]** Alright, 4. Review assigned open tickets: status, code ideas (if applicable), etc.  
+**\<meeting-bot> * anonimal** quickly pulls up  
+**\<meeting-bot> [anonimal]** Ok, 4 new tickets opened since last meeting. All by yours truly.  
+**\<meeting-bot> [anonimal]** Joyous #187 and #191.  
+**\<meeting-bot> [anonimal]** Would any of the talented Monero devs be interested in diving into Kovri?  
+**\<meeting-bot> [anonimal]** I think those two tickets would be a great intro into the project (not being sarcastic).  
+**\<fluffypony>** lol @ 191  
+**\<fluffypony>** "but that is not the real problem"  
+**\<meeting-bot> [anonimal]** lol  
+**\<xmrpromotions>** https://diasporafoundation.org/ looks interesting! Should we consider that as an alternative to GNU social?  
+**\<xmrpromotions>** In some ways it sounds better, but does a lack of Windows support hurt us significantly? https://wiki.diasporafoundation.org/Installation  
+**\<meeting-bot> [anonimal]** xmrpromotions: I personally wouldn't as its harder to maintain and I don't believe it is anonymity friendly (if we host a pod)  
+**\<meeting-bot> [anonimal]** Diaspora simply crossed my mind since that ruby dev popped in.  
+**\<meeting-bot> [anonimal]** Anyway, re: 4.,  
+**\<xmrpromotions>** okay. fair enough. I will keeped focused on gu social then  
+**\<xmrpromotions>** gnu  
+**\<meeting-bot> [anonimal]** fluffypony: I can't see who is on that side. Are any c++ devs online?  
+**\<fluffypony>** hmmm  
+**\<fluffypony>** not sure if any of them are in front of their keyboards atm, let's leave that open-ended  
+**\<fluffypony>** if anyone wants to do an FFS proposal for it that's a great option  
+**\<fluffypony>** since it's easily measurable and challenging in a fun way  
+**\<meeting-bot> [anonimal]** I'm leaning towards a proposal or two.  
+**\<meeting-bot> [anonimal]** Ok, I'll see what I can propose before the next meeting.  
+**\<meeting-bot> [anonimal]** The tickets just keep piling up, help would be nice.  
+**\<meeting-bot> [anonimal]** Actually, more than nice.  
+**\<fluffypony>** yeah we're definitely feeling a bit shy on warm bodies on both fronts, will have to shake the ol' C++ cage and see who falls out  
+**\<meeting-bot> [anonimal]** At some point we'll have to have a meeting dedicated to dev awareness.  
+**\<meeting-bot> [anonimal]** I understand. I see everyone doing their best so what else could we ask for.  
+**\<fluffypony>** yup yup  
+**\<meeting-bot> [anonimal]** Anything else on 4.?  
+**\<fluffypony>** nope  
+**\<meeting-bot> [anonimal]** fluffypony: Do you have any formal ideas on #159?  
+**\<meeting-bot> [anonimal]** s/ideas/strategies  
+**\<fluffypony>** I had a meeting with Richard Kohl from Bitcoin Wednesday and it came up, I need to think through some of his suggestions and then we can discuss it  
+**\<tewinget>** anonimal: what about C++ devs online?  
+**\<tewinget>** fluffypony: what's meeting-bot connecting to?  
+**\<fluffypony>** tewinget: irc2p  
+**\<fluffypony>** most C++ devs online want full time work, or overstate their abilities  
+**\<meeting-bot>** [anonimal] tewinget: ^  
+**\<meeting-bot>** [anonimal] Or are not really interested but want a payout.  
+**\<fluffypony>** yup  
+**\<meeting-bot> [anonimal]** But everyone isn't bad.  
+**\<meeting-bot> [anonimal]** But we also don't have enough awareness yet, but we're working on that.  
+**\<tewinget>** Hey, I'm only like 2 out of 3 there!  
+**\<fluffypony>** yesh  
+**\<fluffypony>** we'll get there  
+**\<meeting-bot>** [anonimal] tewinget have you played with Kovri yet?  
+**\<tewinget>** anonimal: I can't even remember off the top of my head what Kovri is...  
+**\* tewinget** does a quick google search  
+**\<tewinget>** oh, that.  Not yet, why?  
+**\<meeting-bot> [anonimal]** lol because that's what the meeting is for :)  
+**\<tewinget>** I just got up not long ago, haven't had time to read all the scrollback  
+**\<tewinget>** :)  
+**\<meeting-bot> [anonimal]** Alright, moving onto 5. Any additional meeting items  
+**\<meeting-bot> * anonimal** thinking  
+**\<fluffypony>** nothing off the top of my head  
+**\<meeting-bot> [anonimal]** Me neither. I'm out of energy but I feel like there was more to discuss.  
+**\<fluffypony>** we'll push stuff forward, we can discuss anything urgent in the week, else we let it fall to the next meeting  
+**\<fluffypony>** which will be the 19th, by my calendar  
+**\<meeting-bot> [anonimal]** Ok. I was hoping to talk more code but devs seem to be away.  
+**\<meeting-bot> [anonimal]** C++ nerd stuff. Boost enthusiasts.  
+**\<meeting-bot> [anonimal]** alla Monero.  
+**\<fluffypony>** let's flip it around for next meeting and do that first  
+**\<meeting-bot> [anonimal]** Anyway, next time then or during the week.  
+**\<meeting-bot> [anonimal]** Ok, sounds great.  
+**\<meeting-bot> [anonimal]** So point 6.,  
+**\<meeting-bot> [anonimal]** June 19th? 17:00 UTC?  
+**\<xmrpromotions>** Do you think many people in this group would be interested in I2P or kovri? http://area51.stackexchange.com/proposals/82234/open-source  
+**\<fluffypony>** anonimal: yup  
+**\<tewinget>** anonimal: if there's anything specific you can point to as far as C++ goes you can ping me  
+**\<fluffypony>** xmrpromotions: hard to canvas on an SE propsal  
+**\<xmrpromotions>** they could use more activity right now in public beta. If we encourage monero and i2p users to participate in their open beta maybe some of them will support us  
+**\<xmrpromotions>** they lack of ability to direct message makes it harder but some leaders use their real names  
+**\<fluffypony>** ok meeting is over, killing meeting-bot  
--- a/_posts/2016-06-05-overview-and-logs-for-the-dev-meeting-held-on-2016-06-05.md
+++ b/_posts/2016-06-05-overview-and-logs-for-the-dev-meeting-held-on-2016-06-05.md
@ -0,0 +1,277 @@
+---
+layout: post
+title: Overview and Logs for the Dev Meeting Held on 2016-06-05
+summary: introduction to C4 by Yurii Rashkovski, brief update on Ring CT and 0MQ
+tags: [dev diaries, core, crypto, 0mq]
+author: dEBRUYNE / fluffypony / Aerbax
+---
+
+*June 5th, 2016*
+
+### Overview
+
+An overview [can be found on Hello Monero](https://hellomonero.com/article/monero-bi-weekly-dev-meeting-note-highlights-2016-06-05)
+
+### Logs
+
+**\<fluffypony>** everyone ready to start? smooth / tewinget / dEBRUYNE / ArticMine / luigi1111w / luigi1112 / luigi1114 / NoodleDoodle / gingeropolous etc.  
+**\<ArticMine>** yes  
+**\<fluffypony>** hyc is excused, as he is at Pieter Hintjen's wake  
+**\* dEBRUYNE** slaps othe, moneromooo   
+**\<dEBRUYNE>** did we forget anyone? :p  
+**\<fluffypony>** don't think so  
+**\* dEBRUYNE** pages redfish  
+**\<dEBRUYNE>** Think that covers it  
+**\<fluffypony>** ok cool  
+**\<moneromooo>** Traditional Dutch greeting ?  
+**\<fluffypony>** lol  
+**\<fluffypony>** traditional Dutch greeting = "hallo"  
+**\<fluffypony>** so to start this meeting off I wanted to introduce yrashk, Yurii Rashkovskii  
+**\<fluffypony>** he's our special guest for today  
+**\<moneromooo>** o/  
+**\<fluffypony>** a little bit of background: as everyone is aware we've been looking at formally adopting C4, the Collective Code Construction Contract  
+**\<fluffypony>** which 0MQ uses  
+**\<yrashk>** hey hey  
+**\<fluffypony>** forgot to start meeting-bot, sorry  
+**\<fluffypony>** ok  
+**\<fluffypony>** so  
+**\<fluffypony>** with Pieter passing the mantel on to others one of the things that has happened is that yrashk has split some of these "soft skills" things off into something called Unprotocols  
+**\<fluffypony>** and what I wanted is for yrashk to tell us a little bit about C4 and COSS, and talk a bit about how C4 differs from the dreaded CoC - because adopting a CoC is simply not going to happen, but adopting C4 is a much better option  
+**\<fluffypony>** yrashk: the floor is yours  
+**\<yrashk>** fluffypony: thanks for the intro!  
+**\<yrashk>** yeah, actually Pieter has passed the unprotocols.org domain to me as well to play with the idea of extracting C4 and COSS (and more protocols in the future) into a separate domain from ZeroMQ and Digistan projects.  
+**\<yrashk>** as a side node, I think that action itself was very much in the spirit of C4 — it was a quick decision when I confirmed the fact that I want to volunteer, and the domain was passed over.    
+**\<yrashk>** what actually has drawn me to C4 was 1) its simplicity and 2) the rules that seemed to lead to less tension between people  
+**\<yrashk>** it's hardly possible to eliminate those, of course, but it's easy to create "hot spots" unintentionally  
+**\<yrashk>** I was thinking a lot about situations when things got heated before and when I myself got an urge to say things I later regretted  
+**\<yrashk>** and I saw that it was often over a value judgement  
+**\<yrashk>** ("do we need a feature X?" "do we implement it this or that way?" etc.)  
+**\<yrashk>** on the other hand, I had two arguments against CoC  
+**\<yrashk>** one was the Opalgate (https://github.com/opal/opal/issues/941), second one was a tad more complex... it felt like it's just a tool to punish or eject people... a guillotine. something not focused on the positive but rather on handling the negative stuff.  
+**\<fluffypony>** 100% agreed  
+**\<yrashk>** with C4, the main rules of the game were pretty simple: maintainers can't hold up your patch because of your value judgement  
+**\<yrashk>** even if it is stupid  
+**\<yrashk>** by the contract, everybody has a right to contribute  
+**\<yrashk>** the contributions must get merged in quickly (possibly after passing some sanity tests, like travis ci or a quick glance — that said, Pieter says, merge anything — you'll get a permanent record of trolls as well)  
+**\<yrashk>** so instead of having a hierarchy of contributors (maintainers' opinion being more important than others' by default), it's rather a flat space where maintainers' role is rather administrative, to enforce the process.  
+**\<yrashk>** if they (like anyone else) have a value judgment, they can express it either as another PR, or they comment on the patch after the patch got merged in.  
+**\<yrashk>** no bike shedding, no gatekeeping  
+**\<yrashk>** everything is record. anything can be easily reverted.  
+**\<yrashk>** is recorded*  
+**\<yrashk>** there's, however, an important philosophical principle behind. My current thesis (after conversing with different people) is that those who believe in individual intelligence (as opposed to aggregate group intelligence) have a harder time accepting C4.  
+**\<yrashk>** I met people who strongly believe that their experience and intelligence justify them being gatekeepers  
+**\<yrashk>** Pieter does talk about this in his books... basically arguing that individual intelligence applied to a particular work  is rather a product of luck, not a systematic thing  
+**\<yrashk>** another important aspect of C4 that helps justifying just about every incoming PR, is that they are REQUIRED to contain a problem-solution statement (http://rfc.unprotocols.org/spec:1/C4/,section  2.3.7)  
+**\<fluffypony>** 'A patch commit message MUST consist of a single short (less than 50 characters) line stating the problem ("Problem: ...") being solved, followed by a blank line and then the proposed solution ("Solution: ...").'  
+**\<yrashk>**  if a patch solves a particular problem instead of doing something that "might be helpful" or a "nice thing to do", it's easier to form your own opinion about the patch and see if any corrective measure should be taken  
+**\<yrashk>** (should I send a reverting PR if it is a total and utter BS? should I help improving this? etc.)  
+**\<yrashk>** I guess this braindump is good for starters. I'll take questions, if any?  
+**\<fluffypony>** ok so my first questions when I read C4 was about how it deals with people who are disruptive  
+**\<moneromooo>** Do you end up with a pile of crap in git, making view diffs a pain, bisect impossible, and generally having to waste time with crap ?  
+**\<fluffypony>** how does it do so in a non-guillotine manner ?  
+**\<yrashk>** (also, my short article on the subject https://blog.eventsourcing.com/productive-welcoming-vs-code-of-conduct-656b1571ddd6)  
+**\<yrashk>** fluffypony: first important thing, the way I understand it, is getting everything logged. merge disruptive people's commits. this way you get a permanent log of their behaviour.  
+**\<yrashk>** fluffypony: the rest is no different from other approaches: discuss the situation, if a correction can't happen, ban/eject  
+**\<fluffypony>** yeah I gathered the focus was on people self-correcting instead of being forced to correct  
+**\<yrashk>** moneromooo: you tell me https://github.com/zeromq/czmq/commits/master (as an example) — but basically, at least in my rationalization behind this, with great powers come great responsibilities  
+**\<yrashk>** when you treat people like adults, they tend to behave more like adults  
+**\<yrashk>** resulting in better ORs  
+**\<yrashk>** PRs*  
+**\<fluffypony>** I think the worst case scenario is someone submits a PR that intentionally introduces a backdoor, or intentionally breaks things  
+**\<yrashk>** I see this "optimistic" merge strategy as a way to treat people like adults  
+**\<fluffypony>** in which case the reverted PR is a black mark against them  
+**\<moneromooo>** You assume good faith, and a single bad faith person can throw a lot of crap in.  
+**\<yrashk>** fluffypony: exactly, a permanent record (as opposed to a rejected PR, which might be lost over time)  
+**\<fluffypony>** moneromooo: the issue is that doing it the *other* way means a bad faith person can waste everyone's time  
+**\<yrashk>** moneromooo: just like anybody can throw a lot of crap in, it can be thrown own the same way  
+**\<moneromooo>** But why would we want a permanent record of spam patches in the first place ?  
+**\<ArticMine>** So the concept is it is easy to undo / revert damage while leaving a cleat and objective trail for community accountability  
+**\<moneromooo>** yrashk: I'm worried about the history here, not the snapshot.  
+**\<yrashk>** moneromooo: because that helps identifying the bad actors at a later point ("yup, known spammer")  
+**\<moneromooo>** I imagine someone wanting to DoS us would not use the same email over and over again. They're good at sock puppets.  
+**\<yrashk>** it's a bit like a TSA thing — assume any passenger can be a terrorist and check everybody or do the intelligence work to single out bad actors.  
+**\<moneromooo>** Appeal to emotion.  
+**\<yrashk>** moneromooo: I guess it is highly dependent on the nature of the project — how many bad actors are actually interested to disrupt the project  
+**\<fluffypony>** moneromooo: consider it this way - if I'm compiling every-single-PR on every-single-platform and then testing-each-platform that's like an 2-3 hours per PR  
+**\<fluffypony>** so how easy is it to waste my time :-P  
+**\<yrashk>** that's actually a worse DoS  
+**\<moneromooo>** Do you do that ?  
+**\<yrashk>** time is the most valuable thing  
+**\<yrashk>** well, any PR review takes time  
+**\<yrashk>** and delays releases further  
+**\<fluffypony>** moneromooo: not since we've introduced that brief-code-review process, I just merge based on a visual inspection or a review by some known contributor  
+**\<fluffypony>** someone will compile it and see it's broken, and that someone doesn't have to be me  
+**\<yrashk>** C4 doesn't actually say the code should not be reviewed  
+**\<moneromooo>** I think there are a large number of possible positions between "compile every single PR and test on all platforms" and "rubber stamp everything". For instance, "have a look and reject if it doesn't pass the smell test".  
+**\<yrashk>** it's just done after the merging  
+**\<fluffypony>** moneromooo: we'll still have smell tests  
+**\<moneromooo>** That seems good to be ("I just merge based on a visual inspection or a review by some known contributor").  
+**\<moneromooo>** (and I try to review those fwiw)  
+**\<fluffypony>** also the action AFTER a failed smell test is important  
+**\<fluffypony>** ie. do we then have a long, drawn-out convo on github  
+**\<fluffypony>** or do we merge and revert, then explain to the person why that happened  
+**\<moneromooo>** As for building, you said you'd like a build bot IIRC. That'd help a lot there.  
+**\<moneromooo>** But the things I'm worried about are not held off by a build check.  
+**\<yrashk>** I use travis-ci so I can quickly see if PR breaks existing tests  
+**\<fluffypony>** yeah a build check solves a small subset of issues, 100% moneromooo  
+**\<moneromooo>** Maybe I'm paranoid, but I totally see part of the BCT jerks spamming our tree just because.  
+**\<yrashk>** do they do this right now?  
+**\<moneromooo>** Not to my knowledge.  
+**\<fluffypony>** moneromooo: it's MUCH easier to deal with that if we merge-and-revert than if we analyse and have long github discussions  
+**\<yrashk>** one of the main ideas behind C4 is to incentivize the positive contributors to get their stuff in quickly, without painless waiting and discussions  
+**\<yrashk>** I've beed in a situation where it just becomes so painful to abide by all the maintainers' wants to get something in  
+**\<fluffypony>** https://github.com/bitcoin/bitcoin/pull/5905  
+**\<fluffypony>** that PR is over a year old  
+**\<yrashk>** or when the maintainers are busy with other projects, or don't care about a particular problem enough to get my stuff in quickly  
+**\<yrashk>** without painful waiting*  
+**\<fluffypony>** and there are lots like that - full of discussion, "concept ACKs" and so on  
+**\<dEBRUYNE>** \<moneromooo> As for building, you said you'd like a build bot IIRC. That'd help a lot there. <= Zcash has a build bot afaik, might want to look into that   
+**\<fluffypony>** we use travis on Kovri  
+**\<moneromooo>** What are the problems now, beyond fluffypony's time ?  
+**\<fluffypony>** but hoping for a more OS-complete buildbot  
+**\<yrashk>** the other way to look at it — with C4, you have *all contributors* as reviewrs  
+**\<yrashk>** not just a handful of maintainers  
+**\<yrashk>** because everybody can initiate a corrective action  
+**\<fluffypony>** moneromooo: the main problem is that we don't want to become exclusionary, where only a handful of special contributors actually have successful PRs  
+**\<moneromooo>** That would not happen if there is a large enough numbers of people who can review and ack something.  
+**\<moneromooo>** And doing so would not need so muvch time from you either.  
+**\<yrashk>** yet another way to look it, if you have gatekeepers, they *would* have biases of different kind when looking at a patch, conscious or subconscious; C4 helps making project more diverse as value judgement or more subtle biases don't affect the input.  
+**\<yrashk>** (speaking of C4 vs CoC)  
+**\<moneromooo>** What is CoC ?  
+**\<yrashk>** Code of Conduct  
+**\<fluffypony>** moneromooo: Bitcoin has significant numbers of people that can review and ACK, yet there are 102 open PRs stuck in PR-review-hell  
+**\<yrashk>** CoC is about prohibiting certain types of behaviours and topics  
+**\<moneromooo>** This may be so, but I do not believe a free for all is better.  
+**\<yrashk>** in the name of attracting a more diverse  set of contributors  
+**\<moneromooo>** (or at least, not before we have that problem)  
+**\<yrashk>** while removing gatekeeping/biases from reviews gets diverse opinions in proactively  
+**\<yrashk>** at least that's the hypothesis  
+**\<fluffypony>** moneromooo: ok so consider this: what would we do if a PR was submitted from an unknown person that increases the block time to 4 minutes  
+**\<moneromooo>** Bias is a fair point, but if there are many reviewers, then that should not matter much, iunless they all have the same ones. And if they do, maybe there is a good reason.  
+**\<merkaba>** (I know you guys are in the middle of other stuff. don't mind me. If there is anything I can help with I am ruby developer)  
+**\<moneromooo>** That'd probably fork at once.  
+**\<yrashk>** moneromooo: many projects are started by very small teams that are likely to be less diverse. therefore original maintainers might have similar biases.  
+**\<fluffypony>** moneromooo: I mean, would we merge the PR, or not ?  
+**\<fluffypony>** hi merkaba, and welcome :)  
+**\<yrashk>** I think in the case of this PR (block time), first important thing to consider is "does it have a valid problem/solution statement"  
+**\<moneromooo>** I'd hope not, but you're not allowed to then magic other assumptions after I said that :)  
+**\<yrashk>** maybe there's a problem nobody thought about?  
+**\<merkaba>** fluffypony, thank you  
+**\<ArticMine>** Then the question becomes is the problem valid?  
+**\<moneromooo>** If there's a problem nobody thought about, surely a reviewer would ack it ?  
+**\<fluffypony>** moneromooo: so the only difference under C4 is that we merge-and-revert and then tell the committer that they have to at least discuss something that controversial on the forum or on reddit or in dev meetings or something  
+**\<moneromooo>** So, same result, except a spammed git history ?  
+**\<moneromooo>** I *do* use git history :/  
+**\<fluffypony>** but spammed for a reason  
+**\<fluffypony>** a revert won't affect git bisect / git blame, I don't think ?  
+**\<moneromooo>** It will affect blame I think. It will certainly affect bisect time.  
+**\<moneromooo>** Regardless, I object to it for other grounds anyway (it seeming like shooting ourslves in the foot).  
+**\<fluffypony>** I think that maybe extreme examples like "change the block time" are bad for what I'm trying to illustrate  
+**\<moneromooo>** If/when there is a problem with people's patches being held up, and this causing contributors to become dissatisfied, we can talk about it again.  
+**\<moneromooo>** But then, the solution *should* consider something not totally at the extreme of "let's merge anything".  
+**\<fluffypony>** but moneromooo, I think we can do the opposite of "possibly causing dissatisfied contributors" - I think we can be extremely welcoming to contributors  
+**\<ArticMine>** Is a middle ground possible here?  
+**\<moneromooo>** That'd seem to be a great idea. I find monero very welcoming tbh.  
+**\<fluffypony>** well the current pitch is "let's merge everything once it's been reviewed by a known contributor"  
+**\<redfish>** what is the goal of introducing a new contribution guideline? what problem is being addressed here? attracting potential contributors? treating dissatisfied contributors?  
+**\<fluffypony>** so we still have that firewall  
+**\<fluffypony>** redfish: it's about establishing protocol that will survive through to when we have 500+ contributors  
+**\<moneromooo>** Do you mean "we'd still have" ?  
+**\<fluffypony>** moneromooo: yes I do  
+**\<fluffypony>** I hate the idea of "dev worship", where a single contributor is lorded over others, or viewed as being able to cure cancer  
+**\<moneromooo>** Then I agree. I was iunder the impression that there'd be no review by a known contributor. Sorry about that :D  
+**\<fluffypony>** to the exclusion of newcomers  
+**\<yrashk>** C4 kind of helps addressing the "problem of elders"  
+**\<redfish>** a newcomer can be dissuaded by review-block, but the newcomer should really have thicker skin  
+**\<redfish>** be careful of working with a strawmen for a newcomer contributor  
+**\<moneromooo>** 17:35 \<@fluffypony> moneromooo: not since we've introduced that brief-code-review process, I just merge based on a visual inspection or a  review by some known contributor  
+**\<expez>** Code review on github is often about increasing code quality.  Most contributors aren't cpp experts.  If you just merge everything the code quality in the project will gradually decrease until changes become very hard.  Or the regular contributors will have to cleanup the area they want to change prior to doing the work the actually wanted.  This means a few bad apples will slow everyone down.  
+**\<redfish>** the attitute of "you don't want my patch? then, fuck you all" should not be encouraged  
+**\<moneromooo>** Then:  
+**\<moneromooo>** 17:53 \<@fluffypony> well the current pitch is "let's merge everything once it's been reviewed by a known contributor"  
+**\<moneromooo>** And:  
+**\<moneromooo>** 17:54 \< moneromooo> Do you mean "we'd still have" ?  
+**\<moneromooo>** 17:54 \<@fluffypony> moneromooo: yes I do  
+**\<moneromooo>** So I don't see what would change, then.  
+**\<expez>** If there's no discussion, just accept or revert, only the experts will make contributions whereas with some guidance a lot more would've been able to.  
+**\<moneromooo>** Currently: an ack by a known contributor.  
+**\<fluffypony>** expez: so by the same token every technical / scientific / medical article on Github should have declining quality until it's illegible garbage :-P  
+**\<expez>** fluffypony: I can't speak to that.  I haven't seen any articles written by acretion.  
+**\<fluffypony>** I jest - I'm not suggesting the code be written by Wikipedia contributors  
+**\<fluffypony>** but let me use a practical example  
+**\<fluffypony>** a new contributor submits a new feature, but it breaks the Windows build and also doesn't include unit tests  
+**\<fluffypony>** option 1 is that we back-and-forth on his PR until he has it "perfect" by some undefined definition of perfection  
+**\<fluffypony>** this leads to ANY contributor being frustrated, because they've put in effort and maybe they don't even have a Windows box to work on  
+**\<fluffypony>** if, instead, we merge the PR and then create an issue for the broken Windows build + issues for the lack of tests, then ANYONE can fix those  
+**\<fluffypony>** not just the original contributor  
+**\<yrashk>** I think you really nailed it here: "undefined definition of perfection"  
+**\<moneromooo>** Dude. Why do you always present the alternative as the other extreme ? This is also a problem, but we don't have it right now.  
+**\<redfish>** anyone can push commits on top of a PR branch  
+**\<fluffypony>** redfish: yes they can, but until when ?  
+**\<redfish>** until the build is fixed and the unit tests pass  
+**\<meeting-bot> [anonimal]** Kovri meeting starts now but everyone is on a roll - and I'd like to read this huge backlog :)  
+**\<fluffypony>** moneromooo: sure, but that's like saying we shouldn't adopt any sort of governance structure because we're "too small for governance"  
+**\<moneromooo>** Not really. Maybe a bit.  
+**\<yrashk>** fluffypony: I decided to adopt C4 at eventsourcing.com before it's actually needed — the later you are the harder it is to change the governance  
+**\<fluffypony>** ^^  
+**\<moneromooo>** OK, that is a fair point.  
+**\<fluffypony>** literally the only change from a contributor perspective is you have to include a Problem...Solution statement  
+**\<moneromooo>** But we could adopt a governance that's not as seemingly footgun.  
+**\<fluffypony>** nothing else changes  
+**\<moneromooo>** Not the merge it all and revert at once ?  
+**\<fluffypony>** that affects those with push rights, not contributors as a whole  
+**\<fluffypony>** and because we're small we'll probably not even follow that to the letter all the time  
+**\<fluffypony>** BUT we'll have a documented process which contributors will be able to find and understand  
+**\<ArticMine>** There is a difference between a controversial change to the social covenant and failure to build for a particular OS  
+**\<yrashk>** in fact, C4 adds a review layer of a sort for "proven" maintainers as you can't push to master directly  
+**\<fluffypony>** ArticMine: agreed  
+**\<fluffypony>** http://oss-watch.ac.uk/resources/governancemodels <- this is a good read  
+**\<yrashk>** but other maintainers have to merge your PR in  
+**\<fluffypony>** from that article:  
+**\<lpaalp1>** hello  
+**\<moneromooo>** hi  
+**\<fluffypony>** "It is never too soon to define a suitable governance model. Without one, the chances of third parties wishing to contribute are considerably reduced. This is for a number of reasons:  
+**\<fluffypony>** - potential contributors will not know how to contribute  
+**\<fluffypony>** - they will not be sure what will happen to their contribution  
+**\<fluffypony>** - the project will not look serious about engaging with third parties  
+**\<fluffypony>** - there is no visible assurance that contributions will be managed in such a way that they will remain of value to the original contributor  
+**\<fluffypony>** Since you never know when a contributor might stumble upon your project, it is important to be ready from the earliest possible date."  
+**\<moneromooo>** "the project will not look serious about engaging with third parties" sounds like bullshit.  
+**\<fluffypony>** you'd be surprised by how many people who code for a living are afraid to submit a PR, moneromooo  
+**\<moneromooo>** The rest, OK.  
+**\<fluffypony>** we have fluffy ponies and cows and all sorts, not everyone wants to be in the middle of a farmyard  
+**\<moneromooo>** That may be so, but the sentence doesn't really mention that.  
+**\<redfish>** this quote assumes strawman for a contributor  
+**\<fluffypony>** hi lpaalp1 :)  
+**\<redfish>** imho, the danger from a troll newcomer is greater than a danger from a biased old-timer  
+**\<fluffypony>** redfish: C4 provides options to deal with trolls that don't self-correct  
+**\<moneromooo>** I'm totally fine with having a CONTRIBUTING file, or HTML page somewhere, etc, fwiw.  
+**\<fluffypony>** and it does so in a way that is least disruptive to the community as a whole  
+**\<moneromooo>** Well, I do not agree with this, since the harm to history has already been done.  
+**\<moneromooo>** (assuming we're back to merge-first, rather htan wait for an ack from a well known contributor)  
+**\<fluffypony>** no we're not back to that, lol  
+**\<fluffypony>** the review-first model still stays, we're just bolting C4 on top of that  
+**\<fluffypony>** at any rate, we've gone significantly over time, and we've only had one point for discussion, lol  
+**\<moneromooo>** OK. I feel like I'm being lied to here for some reason...  
+**\<fluffypony>** I think let's bounce this around over the next two weeks  
+**\<moneromooo>** Maybe because the discussion about it months ago was merge first.  
+**\<fluffypony>** and then at the next dev meeting we can make a decision if everyone is comfortable  
+**\<fluffypony>** moneromooo: that hasn't changed, we've just added the eyeball-review bit per the discussion with smooth ages ago  
+**\<moneromooo>** OK. Thanks.  
+**\<ArticMine>** Yes this needs a lot more thought and discussion before a decision is made  
+**\<fluffypony>** yes absolutely  
+**\<fluffypony>** so before we move on to Kovri  
+**\<fluffypony>** two quick things  
+**\<fluffypony>** 1. moneromooo - can you give us a brief update on how the RingCT stuff is going  
+**\<fluffypony>** and 2. dEBRUYNE wanted to discuss 0MQ briefly  
+**\<fluffypony>** also thanks for attending yrashk - much to think about and discuss :)  
+**\<moneromooo>** Well, I'm getting to know it. I'm hacking on bits at a time, so I get to learn bits of it at a time.  
+**\<yrashk>** fluffypony: thanks for having me!  
+**\<moneromooo>** It's progressing anyway.  
+**\<dEBRUYNE>** re: 0MQ -> tewinget is going to pick that up (i.e. continue). I am drafting the FFS proposal on his behalf and hope to put it out soon (probably at latest by monday/tuesday).   
+**\<fluffypony>** moneromooo: do you need any extra help, or are you ok with things at the moment ?  
+**\<moneromooo>** Rewrite, not contunue, AFAIK.    
+**\<moneromooo>** I'm ok with it, but I'll have questions for shen, most certainly.    
+**\<fluffypony>** kk    
+**\<fluffypony>** ok so I think let's move on to Kovri - anonimal, the floor is yours    
+**\<dEBRUYNE>** \<moneromooo> Rewrite, not contunue, AFAIK. <= Correct. Rewrite is in a sense also continue right? :P    
--- a/_posts/2016-06-19-logs-for-the-Kovri-dev-meeting-held-on-2016-06-19.md
+++ b/_posts/2016-06-19-logs-for-the-Kovri-dev-meeting-held-on-2016-06-19.md
@ -0,0 +1,294 @@
+---
+layout: post
+title: Logs for the Kovri Dev Meeting Held on 2016-06-19
+summary: Brief review of what has been completed since last meeting, C++ specific discussion, closed and open issues
+tags: [dev diaries, i2p, crypto]
+author: dEBRUYNE / fluffypony
+---
+
+*June 19th, 2016*
+
+### Logs
+
+**\<fluffypony>** ok I guess we move on to Kovri - anonimal, the floor is yours  
+**\<meeting-bot> [anominal]** From agenda https://github.com/monero-project/kovri/issues/192  
+**\<meeting-bot> [anominal]** 17:00 (UTC)  
+**\<meeting-bot> [anominal]** 1. Greetings  
+**\<meeting-bot> [anominal]** 2. Brief review of what's been completed since the previous meeting  
+**\<meeting-bot> [anominal]** 3. C++ specific discussion (carried over from June 5th meeting)  
+**\<meeting-bot> [anominal]** 4. Review open tickets (assigned and/or unassigned): status, code ideas (if applicable), etc.  
+**\<meeting-bot> [anominal]** 5. Discuss any pertinent TODO's  
+**\<meeting-bot> [anominal]** 6. Any additional meeting items  
+**\<meeting-bot> [anominal]** 7. Confirm next meeting date/time  
+**\<meeting-bot> [anominal]** 1. Greetings  
+**\<meeting-bot> [anominal]** Hi  
+**\<meeting-bot> [anominal]** EinMByte: present?  
+**\<fluffypony>** there's 2x greetings?  
+**\<fluffypony>** best meeting ever  
+**\<meeting-bot> [anominal]** lol  
+**\<meeting-bot> [anominal]** Well, EinMByte is here but not present.  
+**\<fluffypony>** k  
+**\<meeting-bot> [anominal]** Moving on,  
+**\<meeting-bot> [anominal]** 2. Brief review of what's been completed since the previous meeting  
+**\<meeting-bot> [anominal]** A somewhat productive two weeks in contrasting areas. Highlights include:  
+**\<meeting-bot> [anominal]** - New --log-levels runtime feature  
+**\<meeting-bot> [anominal]** - Security fix in Garlic/ElGamal  
+**\<meeting-bot> [anominal]** - New user-agent scrubber  
+**\<meeting-bot> [anominal]** - Bump to 0.9.26  
+**\<meeting-bot> [anominal]** - Coverity coverage via travis-ci (though problematic, see #209)  
+**\<meeting-bot> [anominal]** - Design refactoring, misc. refactoring, code documentation  
+**\<meeting-bot> [anominal]** 6 closed issues  
+**\<meeting-bot> [anominal]** 2 new standing issues  
+**\<meeting-bot> [anominal]** fluffypony: have you had a chance to complete anything since previous meeting?  
+**\<fluffypony>** anonimal: like 80%-ish done with the Kovri page on the site, per the info you gave me + the docs  
+**\<fluffypony>** s/page/section  
+**\<meeting-bot> [anominal]** Great, I'm looking forward to it.  
+**\<meeting-bot> [anominal]** Do you think it will be finished before next meeting?  
+**\<fluffypony>** yes definitely  
+**\<meeting-bot> [anominal]** Yay, sounds exciting.  
+**\<meeting-bot> [anominal]** Anything else on 2.?  
+**\<meeting-bot> [anominal]** Going once... going twice...  
+**\<meeting-bot> [anominal]** 3. C++ specific discussion (carried over from June 5th meeting)  
+**\<meeting-bot> [anominal]** Well, I was hoping to merge this in with 4. and chat with EinMByte since he said he'd be here.  
+**\<fluffypony>** is this wrt the C++ standard ?  
+**\<fluffypony>** or the style guide stuff?  
+**\<meeting-bot> [anominal]** Anything C++, I imagined.  
+**\<meeting-bot> [anominal]** I was hoping to focus on C++ related to #187, but I haven't looked at #187 since it was opened.  
+**\<meeting-bot> [anominal]** Have any bitmonero devs taken an interest in Kovri yet?  
+**\<meeting-bot> [anominal]** Its quite the beast, and needs much taming.  
+**\<fluffypony>** I don't think anyone has yet  
+**\<tewinget>** anonimal: passing interest at best for me  
+**\<meeting-bot> [anominal]** Ok, good to know.  
+**\<tewinget>** I more or less know what it is, but I haven't looked into tinkering with it yet.  
+**\<moneromooo>** I think the problem is that the time I'd spend hacking on anything, I wouldn't spend on monero anymore :)  
+**\<fluffypony>** s'true  
+**\<meeting-bot> [anominal]** I totally understand.  
+**\<fluffypony>** there will be a bleed area between the two when integration happens  
+**\<meeting-bot> [anominal]** That makes, so patience and persistence seems to be the key.  
+**\<meeting-bot> [anominal]** \*makes sense  
+**\<meeting-bot> [anominal]** Well, anonymity has a certain taste too. Maybe I'm one of the few fanatics who enjoy working on it ;)  
+**\<fluffypony>** I think most of us are here because we're pro-privacy  
+**\<meeting-bot> [anominal]** Anyway, I look forward to the meeting of the minds, I like what I've seen in bitmonero dev.  
+**\<meeting-bot> [anominal]** Yes, good point.  
+**\<fluffypony>** which is awesome :)  
+**\<meeting-bot> [anominal]** Anything else on 3.? Any questions?  
+**\<meeting-bot> [anominal]** Alrighty, moving on,  
+**\<meeting-bot> [anominal]** 4. Review open tickets (assigned and/or unassigned): status, code ideas (if applicable), etc.  
+**\<meeting-bot> [anominal]** Let's see,  
+**\<fluffypony>** anonimal, also, if EinMbyte can't make the meeting maybe we must collate stuff and raise it on his behalf ?  
+**\<meeting-bot> [anominal]** How so?  
+**\<fluffypony>** like if he just adds to the agenda then we can discuss it without him needing to be here  
+**\<meeting-bot> [anominal]** Ok, well he's welcome to do that.  
+**\<meeting-bot> [anominal]** But he and I are great at bouncing ideas off each other and getting to core issues, so I wish he would be present more often.  
+**\<meeting-bot> [anominal]** I see, so we'll send him a note to add to the agenda regardless of his attending?  
+**\<fluffypony>** yes I think that would help, he lacks time at the moment  
+**\<meeting-bot> [anominal]** Ok.  
+**\<meeting-bot> * anonimal** back to 4.  
+**\<meeting-bot> [anominal]** #210 might be an easy fix, if any bitmonero devs want to take a peek.  
+**\<fluffypony>** once you go Kovri you never go...uh...something that rhymes with Kovri  
+**\<meeting-bot> [anominal]** lol  
+**\<meeting-bot> [anominal]** That's a tough one....  
+**\<fluffypony>** https://github.com/monero-project/kovri/issues/210 <- for reference  
+**\<meeting-bot> [anominal]** Remaining tickets are mostly all hard-core. I'll see what I can get into before the next meeting. Obviously the big ones would be nice if I can make the time.  
+**\<meeting-bot> [anominal]** I may pick at #191 or #187 because I get irritated with severely broken things.  
+**\<meeting-bot> [anominal]** Or who knows what, the world is full of mysterious and discovery.  
+**\<fluffypony>** lol  
+**\<meeting-bot> [anominal]** *mystery  
+**\<meeting-bot> [anominal]** lol  
+**\<fluffypony>** invent a time machine !  
+**\<meeting-bot> [anominal]** pffffffffff  
+**\<meeting-bot> [anominal]** That would be fun.  
+**\<fluffypony>** :-P  
+**\<meeting-bot> [anominal]** Does anyone here work with Debian Jessie often?  
+**\<fluffypony>** tewinget is an Arch user  
+**\<fluffypony>** moneromooo wrote his own OS from scratch I'm sure  
+**\<fluffypony>** osensei maybe  
+**\<fluffypony>** but he's not around atm  
+**\<moneromooo>** I use a pretty common one nowdays actually.  
+**\<meeting-bot> [anominal]** Ok just curious. Arch here so #210 will probably take more than a few moments.  
+**\<fluffypony>** moneromooo: Windows XP ?  
+**\<meeting-bot> [anominal]** ^ Windows 98  
+**\<moneromooo>** Good point. I guess it's not that common. I forgot about windows.  
+**\<meeting-bot> [anominal]** 95 was better at breaking.  
+**\<meeting-bot> [anominal]** Ok, well re: 4., fluffypony have you see #209?  
+**\<fluffypony>** probably  
+**\<meeting-bot> [anominal]** 50% yay because we solved the coverity/travis issue!  
+**\<fluffypony>** oh yes the Coverity thing  
+**\<fluffypony>** ok so plz update me - Travis builds are now work  
+**\<fluffypony>** *working  
+**\<fluffypony>** but Coverity isn't triggering ?  
+**\<meeting-bot> [anominal]** No, we are \*finally\* triggering, but now coverity says build is failing on their end.  
+**\<meeting-bot> [anominal]** So, travis says "we're fine", coverity says "you're not fine but neither is most of my site".  
+**\<meeting-bot> [anominal]** Because they really do have some issues there and support is... meh.  
+**\<fluffypony>** LOL  
+**\<fluffypony>** considering how long it took for their site to pick Travis up I'm not even surprised  
+**\<fluffypony>** do we wait until they've fixed it, or keep pushing  
+**\<meeting-bot> [anominal]** Seriously, and their "community" site is still offline despite "we'll be back in early 2016!".  
+**\<meeting-bot> [anominal]** It's June already...  
+**\<meeting-bot> [anominal]** Good question,  
+**\<meeting-bot> [anominal]** I can review \*why\* they think our build failed, I could even try to do it manually.  
+**\<meeting-bot> [anominal]** I may have to do it manually just to get things going \*or\*, it could be another travis/coverity issue (or just pure coverity).  
+**\<fluffypony>** maybe we must switch to manual Coverity  
+**\<fluffypony>** and just do it once every two weeks  
+**\<meeting-bot> [anominal]** Sounds fair, I'll give it shot before next meeting.  
+**\<meeting-bot> * anonimal** before I forget, opens https://github.com/monero-project/kovri/issues/assigned/fluffypony  
+**\<meeting-bot> [anominal]** fluffypony: Any updates on #27?  
+**\<meeting-bot> * anonimal** knows you've been busy, simply curious  
+**\<fluffypony>** anonimal: no - also, we're switching providers  
+**\<meeting-bot> [anominal]** Ok.  
+**\<fluffypony>** debating Zoho vs. FastMail  
+**\<fluffypony>** ProtonMail doesn't do multiple users on a domain, unfortunately  
+**\<meeting-bot> [anominal]** Hmmm...  
+**\<meeting-bot> [anominal]** Pros/Cons so far re: providers?  
+**\<fluffypony>** well they're mostly doing forwarding and SMTP, so it's pretty open  
+**\<fluffypony>** part of the decision making is cost, part is also reliability and if they feature reasonable web interfaces for those inevitable users that don't want to use a mail client  
+**\<fluffypony>** will wrap that up soon, it's on my short list  
+**\<meeting-bot> [anominal]** Ok, good to know.  
+**\<meeting-bot> [anominal]** I don't have an opionion so far. If I do I'll be sure to chip in.  
+**\<meeting-bot> [anominal]** Is xmrpromotions there? re: #105  
+**\<fluffypony>** no not online atm  
+**\<fluffypony>** I'll prod them for that when I see them next  
+**\<meeting-bot> [anominal]** K.  
+**\<meeting-bot> * anonimal** typing  
+**\<meeting-bot> [anominal]** I'll most likely take a look at bitmonero's 0MQ work too before next meeting (thinking of #53).  
+**\<meeting-bot> [anominal]** Other than that, I may just grab some low hanging fruit before next meeting and work on the mingw build and other smaller tickets.  
+**\<tewinget>** anonimal, feel free to direct any 0mq questions at ~~fluffypony~~ me  
+**\<meeting-bot> [anominal]** Thanks tewinget.  
+**\<fluffypony>** oh yeah speaking of  
+**\<tewinget>** sad that my IRC client doesn't support strikeout...hoping someone else's does  
+**\<fluffypony>** the Windows test box is borked  
+**\<fluffypony>** msys2 decided to give up the ghost  
+**\<fluffypony>** so doing a complete reinstall of it  
+**\<meeting-bot> [anominal]** Yeah, so what happened? Any idea?  
+**\<fluffypony>** no clue  
+**\<meeting-bot> [anominal]** (very strange)  
+**\<tewinget>** On a scale from 1 to I hate compiling anything on Windows: I hate compiling anything on Windows.  
+**\<tewinget>** it's a binary scale.  
+**\<meeting-bot> [anominal]** Oh windows, you never cease to disappoint me.  
+**\<meeting-bot> [anominal]** Anything else on 4.?  
+**\<meeting-bot> * anonimal** quick reviewing  
+**\<meeting-bot> [EinMByte]** Hi, I'm late sorry  
+**\<meeting-bot> [anominal]** EinMByte! Welcome back.  
+**\<fluffypony>** wb EinMByte  
+**\<fluffypony>** still 15 minutes left :)  
+**\<meeting-bot> [anominal]** With 15 minutes or so to spare, any input? (much backlog)  
+**\<meeting-bot> [EinMByte]** Something about #210 maybe: I'll provide some more information  
+**\<meeting-bot> [anominal]** EinMByte: before I forget and while you're here: what is your preferred/most-reliable public contact method?  
+**\<meeting-bot> [EinMByte]** public as in to put on a website or so, or as in where you guys can contact me  
+**\<meeting-bot> [anominal]** So we can contact you.  
+**\<meeting-bot> [anominal]** And would you be interested in leaving agenda TODO's/notes in meeting tickets in case you can't make a meeting that you'd hope to make?  
+**\<meeting-bot> [EinMByte]** Well I'll be on IRC, or else einmbyte@mail.i2p or github  
+**\<meeting-bot> [anominal]** Ok.  
+**\<meeting-bot> [EinMByte]** sure  
+**\<meeting-bot> [anominal]** fluffypony: did I word that correctly?  
+**\<meeting-bot> [anominal]** EinMByte: we're still on point 4. "reviewing tickets", etc.  
+**\<meeting-bot> [anominal]** Is there anything you wanted to add re: SSU?  
+**\<meeting-bot> * anonimal** knows you just got back to working on it  
+**\<fluffypony>** yes I think so  
+**\<meeting-bot> [EinMByte]** Well I can give you a quick status update  
+**\<meeting-bot> [anominal]** Awesome.  
+**\<meeting-bot> [EinMByte]** So SSUSession.cpp is now using the new parsing code, except for the fragments  
+**\<meeting-bot> [EinMByte]** (I have the code to parse data packets, just not using it yet)  
+**\<meeting-bot> [EinMByte]** I am slowed down right now due to a bug, with the header I suspect  
+**\<meeting-bot> [anominal]** Grrr... bugs...  
+**\<meeting-bot> [EinMByte]** (Rekey options being set etc when this shouldn't happen, I think it's all related)  
+**\<meeting-bot> [EinMByte]** Well, I'll try to fix it in the next days  
+**\<meeting-bot> [anominal]** bitmonero devs: FYI, SSU is the ugly High School girl standing in the corner of the dance hall that no one will dance with because she is awkward and is a very mean person.  
+**\<fluffypony>** lol  
+**\<meeting-bot> [anominal]** In other words, SSU has needed much love and I'm glad EinMByte has tackled the challenge.  
+**\<meeting-bot> [EinMByte]** Hah, nice comparison - although it does make me seem quite desperate :P  
+**\<meeting-bot> [anominal]** lol, oops. Sorry EinMByte, I didn't mean it that way :(  
+**\<meeting-bot> [EinMByte]** Once the parsing part is done, I'll do something similar to build the packets  
+**\<meeting-bot> [anominal]** Sounds great.  
+**\<meeting-bot> [anominal]** How about, EinMByte dances with her because he is a leader and willing to show great sympathy to those who need it most.  
+**\<meeting-bot> [EinMByte]** I'll write some tests, but don't expect full coverage just yet. I don't think that's a priority right now.  
+**\<meeting-bot> [anominal]** And turns down the more promising dancers to make SSU work well.  
+**\<meeting-bot> [EinMByte]** (I want to get the API started too)  
+**\<meeting-bot> * anonimal** sorry, I'm getting carried away  
+**\<meeting-bot> [anominal]** Ok.  
+**\<meeting-bot> [anominal]** Do you have an idea of schedule coming up?  
+**\<meeting-bot> [anominal]** (as in availability)  
+**\<meeting-bot> [EinMByte]** anonimal: You're making a lot of assumptions about my gender here :). But let's see how well that dance turns out  
+**\<meeting-bot> [anominal]** I know, again my apologies.  
+**\<meeting-bot> [EinMByte]** Yes, next week I'll be mostly available (several hours per day)  
+**\<meeting-bot> [anominal]** Ok. I'll check my IRC more frequently then.  
+**\<meeting-bot> [anominal]** Anything else on 4.?  
+**\<meeting-bot> [EinMByte]** Well as I said I'll put up more info for #210  
+**\<meeting-bot> [anominal]** Ok.  
+**\<meeting-bot> [EinMByte]** Seems like 2 tests are failing  
+**\<meeting-bot> [anominal]** Since we're out of time, I don't see much on 5. except for a couple of quirky core ones that I may get to before next meeting.  
+**\<meeting-bot> [anominal]** Any comments on 5.?  
+**\<fluffypony>** EinMByte: well you can dance with SSUzy regardless of your gender  
+**\<meeting-bot> [anominal]** SSUzy, lol.  
+**\<meeting-bot> [EinMByte]** fluffypony: or my ability to dance :p  
+**\<fluffypony>** everyone can dance, it's just a matter of how badly (or well)  
+**\<meeting-bot> [anominal]** Paraplegics?  
+**\<meeting-bot> * anonimal** doesn't do off-topic very often, quite the release.  
+**\<meeting-bot> [anominal]** Ok so if no thoughts on 5.,  
+**\<fluffypony>** LOL  
+**\<fluffypony>** nobody is going to attend the Kovri meeting in future :-P  
+**\<meeting-bot> [anominal]** LMAO  
+**\<meeting-bot> * anonimal** watches ship sailing away, burning in the distance  
+**\<meeting-bot> [EinMByte]** See you all next time in #dancing  
+**\<meeting-bot> [anominal]** Ok, last call for 5. Discuss any pertinent TODO's  
+**\<fluffypony>** I think that's it from my side  
+**\<fluffypony>** lol EinMByte  
+**\<meeting-bot> [anominal]** lol, or #dancing-dev  
+**\<meeting-bot> [EinMByte]** Well, for 5: If anyone wants to start on the API, you're welcome  
+**\<meeting-bot> [EinMByte]** This also applies to all (any?) monero people reading this  
+**\<meeting-bot> [anominal]** Good point, that's another big item to tackle.  
+**\<meeting-bot> [EinMByte]** Since you're going to be the people using the API, making up a list of requirements would be nice  
+***\<fluffypony>** kk  
+**\<meeting-bot> [anominal]** 6. Any additional meeting items  
+**\<meeting-bot> [anominal]** Just one from me, briefly,  
+**\<fluffypony>** I think we've already discussed EinMByte's dancing enough, so nothing more from me on 6  
+**\<meeting-bot> [anominal]** Forum Funding. I plan on writing up some proposals within the next month or so.  
+**\<fluffypony>** kk  
+**\<meeting-bot> [anominal]** EinMByte: if you were crowdfunded on FFS, would you be able to devote any more dev time?  
+**\<meeting-bot> [EinMByte]** I've already told fluffypony, not really  
+**\<meeting-bot> [anominal]** Ok.  
+**\<meeting-bot> [EinMByte]** If you can build me a time machine, yes  
+**\<meeting-bot> * anonimal** was planning proposals to fund my work  
+**\<meeting-bot> [anominal]** Funny, fluffypony mentioned that earlier (time machine).  
+**\<fluffypony>** lol  
+**\<meeting-bot> [anominal]** We should invest in one. The writing is on the wall.  
+**\<meeting-bot> [anominal]** Last call for 6.  
+**\<fluffypony>** new project for the Monero Research Lab to tackle  
+**\<meeting-bot> [EinMByte]** But, as I've also told fluffypony, please do fund other programmers  
+**\<meeting-bot> [anominal]** Agreed.  
+**\<meeting-bot> [EinMByte]** Apparently you first need the programmer (before getting the money) so let's go find some C++ programmers  
+**\<meeting-bot> [anominal]** fluffypony: ^ we should devote an entire meeting to that IMHO sometime within the next few months.  
+**\<fluffypony>** yeah definitely  
+**\<grimpants>** would love to see a FFS proposal for kovri/i2p dev  
+**\<fluffypony>** grimpants: we've had open-ended stuff before, the funds just sit there and no dev comes along - we need to first find someone interested that can price in their work, even if it's on a full time commitment for X long  
+**\<meeting-bot> [EinMByte]** By the way, we don't need only expert C++ programmers  
+**\<fluffypony>** and then we can raise funds accordingly  
+**\<grimpants>** i see  
+**\<grimpants>** been a while since ive check tbh  
+**\<meeting-bot> [EinMByte]** We can use people who just write documentation / tests too  
+**\<meeting-bot> [anominal]** ^ which is a great way for newcomers to learn the codebase.  
+**\<fluffypony>** this may not be an honourable line of thought, but I've been wondering if there's any fall-out from the issues Tor are facing that might lead to some new contributors looking at Kovri  
+**\<meeting-bot> [anominal]** Good concern, I think that's very plausible.  
+**\<meeting-bot> [anominal]** But the devoted C person usually scoffs at C++ and turn their nose at Java.  
+**\<fluffypony>** like hyc :-P  
+**\<meeting-bot> [anominal]** I've become spoiled with STL so, I can't vouch for C devotees on more complex apps like Kovri.  
+**\<meeting-bot> [anominal]** But bigger point:  
+**\<meeting-bot> [anominal]** The world needs more options, so if Tor starts to burn, another ship will be ready.  
+**\<meeting-bot> [anominal]** Some great minds there, so I'm not concerned about the near future.  
+**\<meeting-bot> [anominal]** But that was a hefty loss on their end with the one who shall remain nameless.  
+**\<fluffypony>** yeah, and the larger loss is how much emotional damage it did to people during the time it was kept hidden  
+**\<fluffypony>** as a community I hope we can learn from that and call people out when they're out of line  
+**\<meeting-bot> [anominal]** Yeah, everyone involved seems to have taken a loss.  
+**\<meeting-bot> [anominal]** So, regarding that in relation to ship-jumpers: I think we should continue on our track of availability, professionalism, quality, code correctness and maintainability,  
+**\<fluffypony>** 100%  
+**\<meeting-bot> [anominal]** But,  
+**\<meeting-bot> [EinMByte]** let's first get some people :)  
+**\<meeting-bot> [anominal]** devs can be strong in their ways, so being malleable is also important (but that's a given). Constant ebb and flow.  
+**\<meeting-bot> [anominal]** Anything else on 6.?  
+**\<fluffypony>** that's it from my side  
+**\<meeting-bot> [anominal]** 7. Confirm next meeting date/time  
+**\<meeting-bot> [anominal]** Same time in two weeks?  
+**\<meeting-bot> [EinMByte]** Nothing else from me  
+**\<fluffypony>** yes same time in two weeks  
+**\<meeting-bot> [anominal]** Alright. A million thanks to everyone.  
+**\<fluffypony>** taking meeting-bot down
--- a/_posts/2016-06-19-overview-and-logs-for-the-dev-meeting-held-on-2016-06-19.md
+++ b/_posts/2016-06-19-overview-and-logs-for-the-dev-meeting-held-on-2016-06-19.md
@ -0,0 +1,225 @@
+---
+layout: post
+title: Overview and Logs for the Dev Meeting Held on 2016-06-19
+summary: C4, open PRs, and brief update on Ring CT and 0MQ
+tags: [dev diaries, core, crypto, 0mq]
+author: dEBRUYNE / fluffypony
+---
+
+*June 19th, 2016*
+
+### Overview (by Aerbax)
+
+An overview [can be found on Hello Monero](https://hellomonero.com/article/monero-bi-weekly-dev-meeting-note-highlights-2016-06-19)
+
+### Logs
+
+**\<fluffypony>** ok  
+**\<fluffypony>** hello and welcome  
+**\<tewinget>** ack  
+**\<wallet42>** Sup fluffypony  
+**\<fluffypony>** so first things first  
+**\<meeting-bot>** [anonimal] EinMByte: ^ Monero meeting now, Kovri in about an hour or so (just FYI)  
+**\<fluffypony>** after the last meeting, which was mostly focused on C4, we bounced some of that around  
+**\<fluffypony>** I think the spirit of C4 is good, and will help keep Monero inclusionary towards new contributors  
+**\<fluffypony>** but moneromooo in particular disagreed with some of the specifics  
+**\<fluffypony>** or where C4 is a little vague  
+**\<fluffypony>** so what we're going to do is fork C4 from Unprotocols / yrashk into the Monero repo  
+**\<meeting-bot>** [psi] c4?  
+**\<fluffypony>** and we'll tweak it from there, keeping it in step with changes made upstream in Unprotocols  
+**\<fluffypony>** psi: the Collaborative Code Construction Contract, see last meeting's minutes for an intro and discussion  
+**\<meeting-bot>** [anonimal] Or Kovri's contributing guide.  
+**\<fluffypony>** yup  
+**\<fluffypony>** I think everyone is aware that this is security software we're dealing with  
+**\<fluffypony>** and we can't be crazy and accept things that may contain backdoors  
+**\<fluffypony>** but we also want some structure that makes contributors feel welcome, even if their contributions need some work and aren't up to a standard we'd like  
+**\<fluffypony>** somewhere inbetween being completely permissive and miring contributions in PR hell is a nice balance, and we'll figure it out  
+**\<ArticMine>** We need to balance security and making contributors welcome  
+**\<fluffypony>** yup exactly  
+**\<fluffypony>** ok so on to more fiddly code bits, less soft skills  
+**\<fluffypony>** I was hoping tewinget could update us on the 0MQ work, which is about to go up on the forum for funding  
+**\<tewinget>** ok  
+**\<moneromooo>** My point was not security, it was more about the crazy wish to keep obvious crap in.  
+**\<tewinget>** https://www.github.com/tewinget/bitmonero/tree/zmq-dev  \<-- there's the branch, gimme one min to take care of something then I can brief  
+**\<fluffypony>** ok  
+**\* fluffypony** plays hold music  
+**\* tewinget** is typing  
+**\* DaveyJones** just watches  
+**\<tewinget>** ok, so far I've got cryptonote::classes to/from json for a majority of what will need to be serialized for RPC.  I have a couple of RPC calls actually written and working via ZMQ (get_height get_transactions, and key_images_spent)  
+**\<tewinget>** that's more or less a summary of progress  
+**\<tewinget>** as far as process  
+**\<tewinget>** the idea is to try to create RPC as we want it to be, rather than trying to modify the existing structure, and then plug in backwards-compatibility later  
+**\<fluffypony>** tewinget: so using the structure that is / was on the Wikia ?  
+**\<meeting-bot>** [psi] to rehash, you are redoing monero's wire protocol to use zmq correct?  
+**\<fluffypony>** psi: no, not wire protocol, that will use ZMTP (a part of the 0MQ project) and come later  
+**\<tewinget>** psi: more or less, but a bit more than just that  
+**\<tewinget>** oh  
+**\<tewinget>** I mean, kinda wire, but not p2p yet  
+**\<tewinget>** rpc  
+**\<fluffypony>** this is redoing the communication between the node and "clients" like miners / mining pool software / wallets / etc.  
+**\<meeting-bot>** [psi] kk  
+**\<meeting-bot>** [psi] zmtp is still being drafted correct?  
+**\<fluffypony>** nope all done, afaik: http://zmtp.org  
+**\<tewinget>** \<fluffypony> tewinget: so using the structure that is / was on the Wikia ?  <-- well, yes, but also I was hoping to get some input today (not necessarily now) from anyone who would like to comment on the future of RPC  
+**\<fluffypony>** it's already on v3  
+**\<fluffypony>** ok so maybe one of the things we need to do now is move that design doc from the Wikia to the Github wiki  
+**\<fluffypony>** wallet42: are you up to doing that, or busy travelling atm ?  
+**\<tewinget>** I can say that the few commands I've done don't necessarily conform to any spec like json-rpc, but that's easy to change -- structure is currently placeholder while functionality is implemented  
+**\<tewinget>** oh, one important detail I left out  
+**\<tewinget>** I think it's best if the RPC is straight json.  This comes at a very, very minor cost in speed, but means that implementation in other languages will be far less intimidating for new contributors  
+**\<tewinget>** and I know I don't personally plan to write libMonero for every language out there...  
+**\<fluffypony>** oh I agree - the idea behind 0MQ is for a language to use 0MQ bindings and just be able to talk straight to the daemon  
+**\<tewinget>** yup, and this way for any language that has json and zmq bindings, all one needs to do is give the language a cursory understanding of cryptonote structs  
+**\<fluffypony>** if JSON is the way we want to do that that's fine, we can always modify it later to support Google's protobufs or something later on  
+**\<tewinget>** https://paste.fedoraproject.org/379294/14659488/  <-- there's an example of get_transactions  
+**\<tewinget>** it's also very nice to do ad-hoc testing via python :)  
+**\<fluffypony>** cool  
+**\<tewinget>** any thoughts, anyone?  
+**\<wallet42>** fluffypony: In about 3 weeks im back in Berlin, right now i only have like 1 day a week. But yes the wiki will get more data as I am moving myself trough the code  
+**\<wallet42>** Especially better wiki documentation of the datatypes/protocol  
+**\<wallet42>** wiki.bitcoin.it/wiki/Protocol basically  
+**\<fluffypony>** tewinget: how hard would it be to implement different schemes in future, like JSON / protobufs / ASN.1 BER ?  
+**\<fluffypony>** wallet42: ok cool, thank you  
+**\<tewinget>** fluffypony: wouldn't be too bad, I'm trying to make things pretty modular.  It wouldn't be too bad to make it a bit more generic than json  
+**\<tewinget>** it's already 90% ready for that as-is  
+**\<fluffypony>** kk  
+**\<fluffypony>** alright, tewinget anything else or can we move on to the next thing ?  
+**\<tewinget>** the ZMQ-side of things was pretty trivial tbh  
+**\<tewinget>** oh, anyone averse to having a separate listening port for publish/subscribe such as "new_block_notify" etc?  
+**\<fluffypony>** you mean a separate port for pub-sub than the IPC port ?  
+**\<tewinget>** well, there will be a port for "request thing from daemon"  
+**\<tewinget>** can't use the same port for publish/subscribe, I'm pretty sure  
+**\<fluffypony>** I don't see a problem with that  
+**\<tewinget>** without an unholy amount of added complexity that isn't worth at all  
+**\<fluffypony>** one thing you may want to do is also look at Bitcoin's 0MQ effort  
+**\<fluffypony>** I don't think wumpus is around at the moment  
+**\<fluffypony>** but they've been pecking away at 0MQ for some time  
+**\<moneromooo>** Isn't the point of 0MQ to abstract comms to allow things like that ?  
+**\<fluffypony>** moneromooo: pub-sub is a different beast to control / request  
+**\<tewinget>** 0MQ uses different socket types like Request-Reply, or Pub/Sub  
+**\<fluffypony>** normally for pub-sub you're sending a request once and then receiving "push" notifications forever  
+**\<tewinget>** and one socket can only be one type, and I don't think you can bind two sockets to the same port, as how would it route that?  
+**\<fluffypony>** Bitcoin has walletnotify and blocknotify that work in that way  
+**\<tewinget>** so using the same port for req-rep and pub-sub would require...well, no, just no  
+**\<fluffypony>** it would end up looking gross like the RPC stuff at the moment  
+**\<tewinget>** moreso, in fact  
+**\<fluffypony>** different HTTP paths for the JSON and HTTP RPCs  
+**\<tewinget>** \<fluffypony> alright, tewinget anything else or can we move on to the next thing ? <-- happy to give a few minutes for any comments from anyone, but other than that I think that's about it  
+**\<fluffypony>** cool if anything pops up over the rest of the meeting then we can see  
+**\<tewinget>** oh, and feel free to give feedback on the branch, I'll repaste the link in a sec.  Feedback here or via github is fine  
+**\<tewinget>** https://www.github.com/tewinget/bitmonero/tree/zmq-dev  
+**\<fluffypony>** ok next, moneromooo do you feel like giving an update on RingCT? looks like it's making nice headway :)  
+**\<moneromooo>** It kinda works. I'm fixing bugs now.  
+**\<fluffypony>** moneromooo: is it going to be a hard fork where all new transactions are v3 / ringCT, but they can spend pre-ringCT outs?  
+**\<moneromooo>** They  
+**\<fluffypony>** they = transactions  
+**\<othe>** coinbase will use non-ringct tho?  
+**\<fluffypony>** othe: yes afaik  
+**\<moneromooo>** They'll be v2 and can spend either pre rct outputs or rct ones.  
+**\<fluffypony>** moneromooo: ooooh, so a soft fork? :-P  
+**\<moneromooo>** Hmm. I haven't thought about the distinction tbh.  
+**\<moneromooo>** Theoretically, coinbase might not even need to be in the clear I think. Though it'd require some shen magic.  
+**\<fluffypony>** I think it'd be a hard fork, because old nodes won't understand rct outs  
+**\<fluffypony>** so we'd have to bump the block version anyway  
+**\<ArticMine>** But will non RingCT other than coninbase transactions be valid?  
+**\<moneromooo>** Oh they'd reject new txes, yes.  
+**\<yrashk>** fluffypony: I'm thinking of an unprotocol for describing diverged unprotocols  
+**\<yrashk>** So meta  
+**\<fluffypony>** moneromooo: ok then that's hard fork  
+**\<fluffypony>** lol yrashk  
+**\<yrashk>** But I'm actually serious  
+**\<yrashk>** :)  
+**\<fluffypony>** yrashk: what's that Unprotocol for creating protocols with consensus?  
+**\<tewinget>** ArticMine: I think post-fork that all non-coinbase tx will be ringCT, but I'm not sure.  
+**\<moneromooo>** ArticMine: if you mean "will non RingCT outputs other than coninbase transactions be valid?", then I'd choose no, but it could be made either way.  
+**\<yrashk>** fluffypony: COSS? There's nothing about consensus there  
+**\<fluffypony>** yrashk: yes that - but it's about creating new protocols as a group, right ?  
+**\<yrashk>** Kind of but very very lightweight  
+**\<fluffypony>** kk  
+**\<yrashk>** Which is a good thing generally  
+**\<CFP>** Greetings fellas  
+**\<fluffypony>** moneromooo: I tend to agree with you - coinbase txs is fine, but after that it should be rct only  
+**\<CFP>** Crazyflashpie stoping by to say hello  
+**\<yrashk>** fluffypony: are you interested to collaborate on the protocol divergence protocol? (PDP)  
+**\<fluffypony>** hi CFP  
+**\<CFP>** Looks like the # of nodes in China is climbing?  
+**\<fluffypony>** yrashk: let's chat after the meeting, definitely interested in discussing it, as it's relevant to us  
+**\<yrashk>** I can explain my motivations behind it  
+**\<yrashk>** Today?  
+**\<yrashk>** Ping me on telegram or here when ready  
+**\<fluffypony>** kk  
+**\<fluffypony>** ok next I just wanted to bounce through some open PRs  
+**\<fluffypony>** #818 is still open pending luigi1111w / luigi1112 coming up with those spec changes, no rush there  
+**\<ArticMine>** moneromooo I would expect non RingCT outputs other than coinbase to be invalid after a given block  
+**\<fluffypony>** #775 is ready to be merged - moneromooo, just to double check, you're fine with that, right ?  
+**\<ArticMine>** With the 6 month upgrade cycle built in  
+**\<fluffypony>** ArticMine: agreed  
+**\<luigi1112>** Yes I'll try to do that this week  
+**\<moneromooo>** Yes. It's a wee bit spammier now in the logs, but other than that it's good to go.  
+**\<fluffypony>** ok then #810, the caching thing, I'm still confused as to whether we must merge or not  
+**\<moneromooo>** Not sure. I think enough said no.  
+**\<fluffypony>** ok I'll close it, we can reopen later  
+**\<moneromooo>** But then nobody patched the pool code :)  
+**\<fluffypony>** and pools can manually pull that in if they need  
+**\<fluffypony>** then the gcc 6.1 stuff - as I understand it there are more changes than what is covered in those two PRs  
+**\<fluffypony>** so do we close the PRs and just note that "gcc 6.1 not supported yet"  
+**\<meeting-bot> [anonimal]** Noooooooo.........  
+**\<fluffypony>** or do we merge them in preparation for supporting 6.1 ?  
+**\<meeting-bot> [anonimal]** Please nooooooo....  
+**\<fluffypony>** lol anonimal  
+**\<moneromooo>** If they'll be needed anyway...  
+**\<meeting-bot> [anonimal]** This also re: #846?  
+**\<moneromooo>** One of them is a superset of the other IIRC.  
+**\<fluffypony>** anonimal: yeah, 846 and 845  
+**\<meeting-bot> [anonimal]** radfish's work builds, so is the problem more eyes/more time to review?  
+**\<fluffypony>** anonimal: it was more that I was travelling, so I don't really know which is the superset of which, and which to close / merge / bail out of entirely :-P  
+**\<meeting-bot> [anonimal]** Oh, well I can spend some time this week giving input if that helps.  
+**\<moneromooo>** 846 seems to be the superset.  
+**\<tewinget>** PR X is a superset of PR Y seems like an odd situation to be in...  
+**\<tewinget>** especially if both are open  
+**\<fluffypony>** tewinget: quite  
+**\<neosilky_>** I had to merge them to get the repo to compile as GCC 6.1 is default for Arch  
+**\<fluffypony>** kk  
+**\<meeting-bot> [anonimal]** re: that ^, I only merged #846 and builds fine.  
+**\<meeting-bot> [anonimal]** I see the issue of both PR's being open, I can comment further this week after looking at them if they are still open by then.  
+**\<neosilky_>** Yep, only needed #846. @tewinget should enable testing repo too :)  
+**\<fluffypony>** ok then I'll close 845 and merge 846  
+**\<meeting-bot> [anonimal]** Ok.  
+**\<fluffypony>** then #856 I've reviewed and will merge  
+**\<fluffypony>** #855 seems fine to me, I defer to hyc's knowledge of his own product ;)  
+**\<fluffypony>** #863 seems fine too  
+**\<fluffypony>** #862 - luigi1112 can I take your comment as a review?  
+**\<moneromooo>** Oh. Let me change it now...  
+**\<gingeropolous>** tewinget, i may try and put this in a comment on the https://www.github.com/tewinget/bitmonero/tree/zmq-dev , but is this the space wherein the daemon could have multiple rpc ports with different characteristics?  
+**\<luigi1112>** I think it's fine yeah  
+**\<moneromooo>** pushed  
+**\<fluffypony>** k  
+**\<meeting-bot> [anonimal]** Has there been any definitive decisions re: C4 since previous meeting? I know there are differing arguments.  
+**\<fluffypony>** anonimal - yes, my comments at the beginning of the meeting, will let you know when the log is up if you missed them  
+**\<tewinget>** gingeropolous: not entirely sure what you mean to ask there  
+**\<meeting-bot> [anonimal]** "we'll figure it out" <-- was that it?  
+**\<gingeropolous>** i.e., port 18081 would be full access, and 18082 could be less access.  
+**\<fluffypony>** anonimal: yes basically the next step is fork ->** adjust accordingly ->** decide to abandon or adopt the iteration  
+**\<gingeropolous>** right now if you want different permissions for remote access to the daemon, you need multiple daemons and multiple databases  
+**\<othe>** isnt an auth system with permissons better for this  
+**\<fluffypony>** gingeropolous: I'm of a mind that we need a finer distinction than "trusted daemon" and "not trusted"  
+**\<fluffypony>** we need a proper ACL  
+**\<fluffypony>** what othe said  
+**\<fluffypony>** so shelve it as a thing to do later on  
+**\<gingeropolous>** word  
+**\<fluffypony>** ok I think that's it from my side - anything else before we move to the Kovri meeting?  
+**\<tewinget>** glad someone else could answer that while I was rebooting.  Stupid computer crashes frequently, pretty sure it's hardware.  
+**\<fluffypony>** tewinget: you should buy a Mac :-P  
+**\<ArticMine>** No  
+**\<tewinget>** fluffypony: I thought we were friends...  
+**\<tewinget>** tbh if a newer Mac (not new, with that single port, but new-ish) landed on my lap I'd throw Linux on it and use it  
+**\<tewinget>** but I'd never buy one, they're way too expensive for what they are.  
+**\<othe>** actually the macbook pro are good value for money compared to other ultrabooks; anyway kovir next :p  
+**\<fluffypony>** Pro Retina is great, although I've switched my Purism Librem 13 + Qubes for anything remotely sensitive  
+**\<antanst1>** Hackintosh user here :-) It's pretty easy to install OSX if you choose hardware carefully.  
+**\<antanst1>** works pretty much perfectly.  
+**\<othe>** correct, also run a hackintosh desktop  
+**\<ArticMine>** I see the software not the hardware as the issue with Mac  
+**\<meeting-bot> * anonimal** has 8 year old hackbook pro running Arch :/  
+**\<meeting-bot> [anonimal]** Still alive, surprisingly.  
+**\<fluffypony>** nice
--- a/_posts/2016-06-20-monero-missive-for-the-week-of-2016-06-20.md
+++ b/_posts/2016-06-20-monero-missive-for-the-week-of-2016-06-20.md
@ -0,0 +1,20 @@
+---
+layout: post
+title: Monero Missives for the Week of 2016-06-20
+summary: A discussion of the rationale behind rolling hardforks and the C4 code contract
+tags: [monero missives, external]
+author: Riccardo Spagni (fluffypony)
+forum: https://forum.getmonero.org/1/news-announcements-and-editorials/2568/monday-monero-missives-33-june-20th-2016
+---
+
+<div class="text-center"><iframe style="border: none" src="//html5-player.libsyn.com/embed/episode/id/4447222/height/360/width/640/theme/legacy/autoplay/no/autonext/no/thumbnail/yes/preload/no/no_addthis/no/direction/backward/no-cache/true/" height="360" width="640" scrolling="no"  allowfullscreen webkitallowfullscreen mozallowfullscreen oallowfullscreen msallowfullscreen></iframe></div>
+
+To download the podcast directly please [use this link to the MP3](http://traffic.libsyn.com/monero/Monero_Missives_Podcast_for_the_week_of_2016-06-20.mp3), or [this link to the AAC/MP4](http://traffic.libsyn.com/monero/Monero_Missives_Podcast_for_the_week_of_2016-06-20.mp4), or [this link to the FLAC](http://traffic.libsyn.com/monero/Monero_Missives_Podcast_for_the_week_of_2016-06-20.flac).
+
+In this week's episode we discuss the rationale behind rolling hard forks and the Collective Code Construction Contract (C4). 
+
+Until next week!
+
+### Podcast Transcription
+
+*Pending*
--- a/_posts/2016-07-03-logs-for-the-Kovri-dev-meeting-held-on-2016-07-03.md
+++ b/_posts/2016-07-03-logs-for-the-Kovri-dev-meeting-held-on-2016-07-03.md
@ -0,0 +1,248 @@
+---
+layout: post
+title: Logs for the Kovri Dev Meeting Held on 2016-07-03
+summary: Brief review of what has been completed since last meeting, SSU refactoring, closed and open issues
+tags: [dev diaries, i2p, crypto]
+author: dEBRUYNE / fluffypony
+---
+
+*July 3th, 2016*
+
+### Logs
+
+**\<fluffypony>** ok I guess we move on to Kovri - anonimal, the floor is yours  
+**\* fluffypony:** ding dings  
+**\<meeting-bot> [anonimal]** Meeting Agenda: Sunday, July 3rd, 17:00 UTC  
+**\<meeting-bot> [anonimal]** 1. Greetings  
+**\<meeting-bot> [anonimal]** 2. Brief review of what's been completed since the previous meeting  
+**\<meeting-bot> [anonimal]** 3. Discuss SSU: status of #140 and https://github.com/EinMByte/kovri/pull/1 (if applicable), ideas, problems, and solutions (note: ask if @EinMByte will allow issues tracking within his repo)  
+**\<meeting-bot> [anonimal]** 4. Discuss commit message labeling, e.g., how to organize first line of commits. Touch-up on C4.  
+**\<meeting-bot> [anonimal]** 5. Review open tickets (assigned and/or unassigned): status, code ideas (if applicable), etc.  
+**\<meeting-bot> [anonimal]** 6. Discuss any pertinent TODO's  
+**\<meeting-bot> [anonimal]** 7. Any additional meeting items  
+**\<meeting-bot> [anonimal]** 8. Confirm next meeting date/time  
+**\<meeting-bot> [anonimal]** -- 1. Greetings  
+**\<meeting-bot> [anonimal]** Hi  
+**\<moneromooo>** hi  
+**\<fluffypony>** hi  
+**\<meeting-bot> [anonimal]** I know Ein is irc2p side waiting for me to move on :)  
+**\<meeting-bot> [anonimal]** 2. Brief review of what's been completed since the previous meeting  
+**\<meeting-bot> [fluffypony]** I'm on this side too  
+**\<meeting-bot> * anonimal** wishes this was automated. /pulse only does so much  
+**\<meeting-bot> [anonimal]** 28 commits (not including merges), 2 new issues open, 0 issues closed  
+**\<meeting-bot> [anonimal]** All new commits in https://github.com/einmbyte/kovri/tree/ssu  
+**\<meeting-bot> [anonimal]** I ended up diving into SSU with EinMByte this week. Much fun.  
+**\<meeting-bot> [anonimal]** Teamwork-teamwork: within the past hour, we had figured out that the HMAC digest impl was segfaulting because GetHeader->GetMAC() was not initialized, so the segfault is fixed for now.  
+**\<meeting-bot> [anonimal]** But that's just a small portion of what's been completed since previous meeting, and more issues abound. More to discuss in 3.  
+**\<meeting-bot> [anonimal]** Anyone else re: completed work since previous meeting?  
+**\<meeting-bot> [fluffypony]** I've been focused on the OTF funding stuff, so I haven't had a chance to finish the website work  
+**\<meeting-bot> [fluffypony]** pushing that out till the next meeting, unless we have to prepare more stuff for the OTF  
+**\<meeting-bot> [anonimal]** Ok. Any new issues re: OTF?  
+**\<meeting-bot> [anonimal]** Seems like they've had a few lately.  
+**\<meeting-bot> [anonimal]** i.e., did we get confirmation that they received our request?  
+**\<meeting-bot> [fluffypony]** no I think the next step is we'll receive a pass / fail on the concept note  
+**\<meeting-bot> [fluffypony]** yes we did  
+**\<meeting-bot> [_trump2016]** OTF will make kovri great again!  
+**\<meeting-bot> [anonimal]** Confirmation, good.  
+**\<meeting-bot> [anonimal]** Anyone freenode-side? Is xmrpromotions there?  
+**\<meeting-bot> [fluffypony]** so if we receive a pass we have to prepare an actual proposal  
+**\<meeting-bot> [fluffypony]** but let's see when we get there  
+**\<meeting-bot> [fluffypony]** (if)  
+**\<meeting-bot> [fluffypony]** they were on Reddit the other day, they seem to be busy at the moment  
+**\<meeting-bot> [fluffypony]** they've asked for assistance on the gnu-social thing  
+**\<meeting-bot> [anonimal]** Link? What kind of assistance? I'd be happy to help.  
+**\<meeting-bot> [fluffypony]** I'll have to find it and send it to you post-meeting  
+**\<meeting-bot> [anonimal]** Ok. Anything else on 2.?  
+**\<meeting-bot> [fluffypony]** oh found it, nevermind: https://www.reddit.com/r/Monero/comments/4qywbx/what_are_moneros_pain_points_marketing_design/d4x34p3  
+**\<meeting-bot> [fluffypony]** nein  
+**\<meeting-bot> [anonimal]** fluffypony: Thanks, I'll look into it later.  
+**\<meeting-bot> [anonimal]** Moving on,  
+**\<meeting-bot> [anonimal]** 3. Discuss SSU: status of #140 and https://github.com/EinMByte/kovri/pull/1 (if applicable), ideas, problems, and solutions (note: ask if @EinMByte will allow issues tracking within his repo)  
+**\<meeting-bot> [anonimal]** So, https://github.com/EinMByte/kovri/pull/1 has been merged  
+**\<meeting-bot> [anonimal]** EinMByte: will you allow issues tracking within your repo? It would help with this bug we're hunting.  
+**\<meeting-bot> [anonimal]** Oops, old paste, we fixed the bug,  
+**\<meeting-bot> [anonimal]** but are still dealing with related issues.  
+**\<meeting-bot> * anonimal** knows Ein is somewhere, we were chatting elsewhere during the bitmonero meeting  
+**\<meeting-bot> [EinMByte]** Hi  
+**\<meeting-bot> [anonimal]** Maybe he still thinks its the previous meeting...  
+**\<meeting-bot> [anonimal]** Hi  
+**\<meeting-bot> [EinMByte]** Yes, I will allow all contributions to my repo  
+**\<meeting-bot> [EinMByte]** Latest issue is: we are sending out broken packets  
+**\<meeting-bot> [fluffypony]** issue tracking has to be explicitly enabled for the repo, EinMByte  
+**\<meeting-bot> [EinMByte]** (but at least the segfault is fixed)  
+**\<meeting-bot> [fluffypony]** it's a setting in github somewhere  
+**\<meeting-bot> [anonimal]** ^ what fluffypony said  
+**\<meeting-bot> [anonimal]** EinMByte: are we in a committable stage for the segfault fix? So I can see where we stand?  
+**\<meeting-bot> [EinMByte]** anonimal: Already committed  
+**\<meeting-bot> [EinMByte]** fluffypony: somewhere where  
+**\<meeting-bot> [anonimal]** I imagine we're sending bogus packets in SessionRequest  
+**\<meeting-bot> [fluffypony]** I'll check  
+**\<meeting-bot> * anonimal** fetching  
+**\<meeting-bot> [EinMByte]** fluffypony: Never mind, I think I got it  
+**\<meeting-bot> [fluffypony]** if there's time, anonimal, can you please explain what SSU is for those who are observing the meeting ?  
+**\<meeting-bot> [anonimal]** Ok, latest commit makes sense.  
+**\<meeting-bot> [anonimal]** Yes,  
+**\<meeting-bot> [anonimal]** tl;dr, in plain english,  
+**\<meeting-bot> [anonimal]** it is one of two transport mechanisms closest to the IP layer:  
+**\<meeting-bot> [anonimal]** NTCP is for TCP, SSU is for UDP.  
+**\<meeting-bot> [anonimal]** SSU essentially takes care of encryption and negotiation with peers at the UDP level.  
+**\<meeting-bot> [anonimal]** Does that make sense, or should I explain more?  
+**\<meeting-bot> * anonimal** fetches link  
+**\<meeting-bot> [anonimal]** Specification here: https://geti2p.net/spec/ssu  
+**\<meeting-bot> [anonimal]** Overview here: https://geti2p.net/en/docs/transport/ssu  
+**\<meeting-bot> [EinMByte]** In case anyone is really listening: we are rewriting the SSU implementation because  
+**\<meeting-bot> [EinMByte]** 1) It doesn't allow for unit tests  
+**\<__uguu__>** i2p needs a better udp transport  
+**\<meeting-bot> [EinMByte]** 2) The design is bad, because separate concepts are not separated in code (packet parsing was done in the same functions as dealing with networking etc)  
+**\<meeting-bot> [anonimal]** X) it was an unmaintainable nightmare, like much of the codebase that we have yet to refactor.  
+**\<meeting-bot> [EinMByte]** __uguu__: It probably does, so let's hope SSU2 will be better  
+**\<meeting-bot> [EinMByte]** (I'm not sure what the satus on SSU2 is, AFAIK there's not even a spec yet)  
+**\<meeting-bot> [anonimal]** I had some ideas/problems/solutions when working on everything this week,  
+**\<meeting-bot> [anonimal]** but I need more time to flesh out tangible thought.  
+**\<meeting-bot> [anonimal]** I think we're on the right track, as we discussed earlier.  
+**\<meeting-bot> [EinMByte]** Ok, no problem. Maybe write everything down on github?  
+**\<meeting-bot> [anonimal]** Sure, I'll comment more in #140 or open an issue in your repo.  
+**\<meeting-bot> [anonimal]** Essentially, I want to take a closer look at design this week as I said I would stay away when we last spoke.  
+**\<meeting-bot> [anonimal]** e.g., what we discussed earlier about MAC buffer, etc.  
+**\<meeting-bot> [EinMByte]** Yes, in terms of design many things are currently undecided  
+**\<meeting-bot> [EinMByte]** I've mentioned before that this is more of a refactoring than a rewrite  
+**\<meeting-bot> [anonimal]** Hmm... maybe I have a different vision of end-result then.  
+**\<meeting-bot> [EinMByte]** At least for now, I do want design changes in the end  
+**\<meeting-bot> [EinMByte]** But I wanted to make it less crappy first, and then make it good  
+**\<meeting-bot> [anonimal]** I think I need to get my hands dirty and get more intimate with your new changes.  
+**\<meeting-bot> [anonimal]** I understand, as I said in #1 I completely understand and agree.  
+**\<meeting-bot> * anonimal** no complaints here  
+**\<meeting-bot> [anonimal]** So, long story short, I'd like to get more involved. Any objections EinMByte?  
+**\<meeting-bot> [EinMByte]** Of course not, I can use all help  
+**\<meeting-bot> * anonimal** could work in another branch, but I think our conflicts result in better code  
+**\<meeting-bot> [anonimal]** Ok, I'll comment more in #140, etc. as things progress.  
+**\<meeting-bot> [anonimal]** Anything else on 3.?  
+**\<meeting-bot> [EinMByte]** Not from me  
+**\<meeting-bot> * anonimal** prepares for more pasting  
+**\<meeting-bot> [anonimal]** Anyone here have more SSU questions?  
+**\<meeting-bot> * anonimal** will work on refining better responses to such questions  
+**\<meeting-bot> [fluffypony]** no that's perfect, thanks  
+**\<meeting-bot> [anonimal]** Ok, moving on  
+**\<meeting-bot> [anonimal]** 4. Discuss commit message labeling, e.g., how to organize first line of commits. Touch-up on C4.  
+**\<meeting-bot> [anonimal]** To preface, before discussing commit titles, none of this can really be enforced at the moment because there is no payout hanging over anyone's head.  
+**\<meeting-bot> [anonimal]** But our guide does ask to reference applicable ticket numbers in commit bodies - and its incredibly helpful.  
+**\<meeting-bot> [anonimal]** I'm trying to be better about doing this and I hope EinMByte would also consider doing this too.  
+**\<meeting-bot> [anonimal]** It should be noted that there is no mention in the guide or C4 about commit title.  
+**\<meeting-bot> [anonimal]** I've been using a rough system of prepending titles with class or aspect of project worked on.  
+**\<meeting-bot> [anonimal]** It does help for quick git-log searches. Again, not enforceable, but it does help IMHO.  
+**\<meeting-bot> [anonimal]** Thoughts? Objections to adding to guide?  
+**\<meeting-bot> [fluffypony]** can you give me an example of the prepending?  
+**\<meeting-bot> [anonimal]** Yes, one moment.  
+**\<meeting-bot> [EinMByte]** anonimal: I've noticed that you tend to include a longer summary  
+**\<meeting-bot> [anonimal]** fluffypony: Basically what's before the colon https://github.com/EinMByte/kovri/pull/1  
+**\<meeting-bot> [EinMByte]** I currently don't do that, but if you think it's worth it, I can start doing that  
+**\<meeting-bot> [EinMByte]** Other than that, the main thing should be that it should be reasonably clear what the commit is about  
+**\<meeting-bot> [fluffypony]** oh yeah that's cool  
+**\<meeting-bot> [EinMByte]** But we all do that already  
+**\<meeting-bot> [EinMByte]** I'm fine with stricter rules, just don't shout at me too much when I forget about them :p  
+**\<meeting-bot> [fluffypony]** I tend to do short summaries too, but I like the prepending thing  
+**\<meeting-bot> [anonimal]** EinMByte: I agree. If I were to ask of anything, it would be to references issues that commit addresses.  
+**\<meeting-bot> [anonimal]** Other than that, I personally couldn't ask you to write longer summaries. Honestly, most of what you commit I understand anyway because its well-written IMHO - but that's just me.  
+**\<meeting-bot> [anonimal]** So, as usual, I think about everyone else who isn't knee-deep in our mess.  
+**\<meeting-bot> [anonimal]** And maybe longer summaries would help?  
+**\<meeting-bot> [anonimal]** But 4. for me was more about commit title.  
+**\<meeting-bot> [EinMByte]** Ok, I'll try to reference issues more often  
+**\<meeting-bot> [fluffypony]** I don't think longer summaries are massively necessary as long as the commits show the route taken to get there, referencing issues is definitely helpful  
+**\<meeting-bot> [EinMByte]** (not in the title, though)  
+**\<meeting-bot> [anonimal]** Ok. So shall we take a vote on adding 'prepend class or project aspect into title of commit' into contributing guide?  
+**\<meeting-bot> [anonimal]** (again, at this time not enforceable - just helpful)  
+**\<meeting-bot> [fluffypony]** I'm fine with it  
+**\<meeting-bot> [anonimal]** + me = 2 yes. Anyone else?  
+**\<meeting-bot> [anonimal]** As fluffypony pointed out long ago, its not like anyone reads contributing guides anyway ;)  
+**\<meeting-bot> [fluffypony]** hah hah yeah  
+**\<meeting-bot> [EinMByte]** Sure  
+**\<meeting-bot> [fluffypony]** but at least it's there and we can encourage it  
+**\<meeting-bot> [EinMByte]** ^  
+**\<meeting-bot> [anonimal]** Ok, good point on the encouragement.  
+**\<meeting-bot> [fluffypony]** hey - we managed to get most Monero contributors to GPG sign commits, so it is doable :)  
+**\<meeting-bot> [anonimal]** Great, done.  
+**\<meeting-bot> [anonimal]** While we're on 4., this is off-the-cuff,  
+**\<meeting-bot> [anonimal]** but bitmonero is working with only 1 branch now.  
+**\<meeting-bot> [anonimal]** And, C4 kind of dictates that (IIRC).  
+**\<meeting-bot> [anonimal]** So, do we scrap branch development and work solely in master?  
+**\<meeting-bot> [fluffypony]** note that we have a use-case for moving back to the dev branch setup, because people just pull and compile  
+**\<meeting-bot> [anonimal]** I've also used arguments for two branches. I'm curious to hear EinMByte's opinion.  
+**\<meeting-bot> * anonimal** sigh, I2P lag  
+**\<meeting-bot> * anonimal** doesn't want to move on yet, running out of time though  
+**\<meeting-bot> [EinMByte]** anonimal: Not sure, I think it's good to have a stable branch  
+**\<meeting-bot> [EinMByte]** also, it doesn't hurt anyone? (I think)  
+**\<meeting-bot> [anonimal]** The argument is to instead warn users that anything that is built outside of a tagged version is... well, unpredictable.  
+**\<meeting-bot> [anonimal]** But, since we don't have any releases yet...  
+**\<meeting-bot> [EinMByte]** There's "unpredictable" and there's "possibly broken"  
+**\<meeting-bot> [EinMByte]** In my opinion those are not really the same  
+**\<meeting-bot> [anonimal]** Good point. I imagine though that broken branches would stay in forks and then, when fleshed out, could be sent to 1 branch master.  
+**\<meeting-bot> [anonimal]** But then that would require more work maintainer-side.  
+**\<meeting-bot> [anonimal]** Ay, too many options.  
+**\<meeting-bot> [anonimal]** I vote to keep two branches for now.  
+**\<meeting-bot> [anonimal]** Yea or Nay?  
+**\<meeting-bot> [EinMByte]** ok, let's keep the branches and move on :)  
+**\<meeting-bot> [anonimal]** Ok, moving on.  
+**\<meeting-bot> [anonimal]** 5. Review open tickets (assigned and/or unassigned): status, code ideas (if applicable), etc.  
+**\<meeting-bot> [anonimal]** My hands have been tied to SSU as we've discussed. I did hack a fix for the massive leak in #191.  
+**\<meeting-bot> [anonimal]** It appears to be related to LogPrint and possibly GetFormattedSessionInfo(). I need more time with it and to produce a smoother fix.  
+**\<meeting-bot> [anonimal]** But it doesn't address a few smaller leaks related to #191.  
+**\<meeting-bot> [anonimal]** So, between now and next meeting, I'm somewhat sure I'll focus on SSU, #191, and getting a windows build in working order.  
+**\<meeting-bot> [anonimal]** And in that order.  
+**\<meeting-bot> [EinMByte]** Ok  
+**\<meeting-bot> [anonimal]** *but* I also may start drafting a FFS proposal for a chunk of that time (I said I would last meeting). We'll see.  
+**\<meeting-bot> [fluffypony]** +1, FFS proposals are welcome  
+**\<meeting-bot> [anonimal]** EinMByte: do you think you'll be around sometime this coming week or the following week? Or are weekends better?  
+**\<meeting-bot> [anonimal]** fluffypony: would you please refresh my memory on the zoho/fastmail decision (my brain is scattered at the moment)?  
+**\<meeting-bot> [EinMByte]** I'll be around a few hours a day, but more actively in weekends  
+**\<meeting-bot> [fluffypony]** started the process a few days ago, we're doing Zoho  
+**\<meeting-bot> [anonimal]** EinMByte: sounds great.  
+**\<meeting-bot> [anonimal]** fluffypony: sounds great.  
+**\<meeting-bot> [anonimal]** Many great sounds!  
+**\<meeting-bot> [fluffypony]** everyone can independently forward their mails to tutanota or i2pmail, or just use the Zoho mailbox  
+**\<meeting-bot> [anonimal]** I'm looking forward to zoho's /projects, especially time-management.  
+**\<meeting-bot> [anonimal]** Kimai is a horrid *#()*@#)$@#$#@  
+**\<meeting-bot> [anonimal]** If anyone has experience using it...  
+**\<meeting-bot> [fluffypony]** never heard of it, will take a look  
+**\<meeting-bot> [fluffypony]** or not if it's horrible  
+**\<meeting-bot> * anonimal** surprised at the lack of free, personal, opensource, time-management/billable hours solutions out there  
+**\<meeting-bot> [fluffypony]** MS Project  
+**\<meeting-bot> [anonimal]** IMHO you should, it may be humorous.  
+**\<meeting-bot> [fluffypony]** :-P  
+**\<meeting-bot> [anonimal]** I can't knock their work though, I applaud what they're doing, I just wish I had more time to contribute to their project.  
+**\<meeting-bot> [fluffypony]** is it meeting.end time?  
+**\<meeting-bot> [anonimal]** Eek, one more thing.  
+**\<meeting-bot> * anonimal** one more paste coming  
+**\<meeting-bot> [anonimal]** 6. Discuss any pertinent TODO's  
+**\<meeting-bot> [anonimal]** In SSU: we're closer to resolving #119 with our new design. I've noted a few spots of missing implementation that I think will be resolved during the refactor.  
+**\<meeting-bot> [anonimal]** I had mentioned in the most recent PR my interest in more sanity tests, and EinMByte did note a few overflow checks.  
+**\<meeting-bot> [anonimal]** I think we're still discussing design though, so that would come a little later.  
+**\<meeting-bot> [anonimal]** Thoughts?  
+**\<meeting-bot> [EinMByte]** Yes, we have many places where we need more checks  
+**\<meeting-bot> [EinMByte]** at least we won't leak if we throw errors etc due smart pointer usage  
+**\<meeting-bot> [EinMByte]** Eventually I want to rely on exception for error handling, and I want to use the error information for peer profiling  
+**\<meeting-bot> [anonimal]** Ooooooooooooooo, I like that......  
+**\<meeting-bot> [anonimal]** I like that ALOT.  
+**\<meeting-bot> [anonimal]** Yes, smart pointers: something the previous project had very little interest in;  
+**\<meeting-bot> [anonimal]** despite the standard having been out for years.  
+**\<meeting-bot> [anonimal]** Anyway, I won't start bashing as we're out of time (I love a good bashing).  
+**\<meeting-bot> [anonimal]** Anything else on 6.?  
+**\<meeting-bot> [anonimal]** If not, then 7.?  
+**\<meeting-bot> [fluffypony]** nothing else from my side  
+**\<meeting-bot> [fluffypony]** next meeting same time, same place, two weeks?  
+**\<meeting-bot> [anonimal]** Works for me.  
+**\<meeting-bot> [EinMByte]** Should be fine  
+**\<meeting-bot> [fluffypony]** sehr gut  
+**\<meeting-bot> [zzz]** will we see any kovri ppl at HOPE in 3 weeks?  
+**\<meeting-bot> [fluffypony]** zzz: unfortunately not me, need to do no travelling for a little bit  
+**\<meeting-bot> [fluffypony]** got too much work to do, lol  
+**\<meeting-bot> [EinMByte]** not me either  
+**\<meeting-bot> [anonimal]** I had planned late last year but things took a completely different turn so, nope, not this time around.  
+**\<meeting-bot> [zzz]** ok, I believe echelon still has a ticket to sell, if anybody needs it  
+**\<meeting-bot> [anonimal]** Thanks zzz. That echelon, quite the organizer :)  
+**\<meeting-bot> [anonimal]** Anything else? Meeting?  
+**\<meeting-bot> [anonimal]** I want to also thank fluffypony and dEBRUYNE and anyone else for their work on getting these logs up on the site.  
+**\<meeting-bot> [fluffypony]** it's mostly dEBRUYNE, I just add spaces in at the end  
+**\<meeting-bot> [anonimal]** lol, nice.  
+**\<meeting-bot> [anonimal]** Ok, thanks everyone for the great meeting.  
+**\<meeting-bot> [fluffypony]** thanks everyone  
+**\<meeting-bot> [fluffypony]** meeting-bot going offline  
--- a/Show More
+++ b/Show More