4rkal/monero-site
1
0
Fork 0
mirror of https://github.com/monero-project/monero-site.git synced 2024-12-04 23:51:11 +02:00
Code Issues Actions Packages Projects Releases Wiki Activity

Removed old site

Browse Source
This commit is contained in:
rehrar 2017-07-03 23:55:10 -06:00
parent 9fd363d88f
commit 3c3d0698c9
325 changed files with 0 additions and 22720 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
.gitignore vendored
View File

@ -1,3 +0,0 @@
ietemplates/
_site/*
.idea/

25
404/css/ie7.css
View File

@ -1,25 +0,0 @@
@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)";
}

313
404/css/main.css
View File

@ -1,313 +0,0 @@
@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;
}
}

BIN
404/images/404.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 9.5 KiB

BIN
404/images/bubble.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 9.2 KiB

BIN
404/images/cat.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 3.3 KiB

BIN
404/images/cookie.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 5.4 KiB

BIN
404/images/dog1.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 13 KiB

BIN
404/images/planet.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 1.2 MiB

BIN
404/images/sky-background.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 3.3 KiB

BIN
404/images/sky-shine.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 73 KiB

39
404/index.md
View File

@ -1,39 +0,0 @@
---
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>

56
README.md
View File

@ -1,56 +0,0 @@
# 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.

37
_config.yml
View File

@ -1,37 +0,0 @@
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"]
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"

243
_config/nginx.conf
View File

@ -1,243 +0,0 @@
# 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;
}
}

10
_data/dogtalk.yml
View File

@ -1,10 +0,0 @@
- 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!"

428
_data/donators.yml
View File

@ -1,428 +0,0 @@
- 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]

77
_data/downloads.yml
View File

@ -1,77 +0,0 @@
- platform: Windows, 64-bit
icon: windows.svg
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: windows.svg
cli_url: win32
cli_hash: da628a45adfcb8be44df06ac904711d644d608c4eb6479a5d256062a5f6d74de
version: 0.10.3.1
tag: Wolfram Warptangent
blockchain: win
- platform: Mac OS X, 64-bit
icon: apple.svg
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
icon: linux.svg
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: linux.svg
cli_url: linux32
cli_hash: abc99f3928f4083bd1a380a869253e07bee9950e0aeb6388e9493bc0f0ec3f53
gui_url: linux32
gui_hash: 092b49080c3380666845f7f39823b09f4960ea1e250b84b150856ef33ca30690
version: 0.10.3.1
tag: Wolfram Warptangent
blockchain: linux
- platform: ARMv7
icon: arm.svg
cli_url: linuxarm7
cli_hash: 8473fa20e0db4a3d3e46120cdf92c55be6a159478c511e21f7b77aa05d6c1910
version: 0.10.3.1
tag: Wolfram Warptangent
blockchain: arm
- platform: ARMv8
icon: arm.svg
cli_url: linuxarm8
cli_hash: 451f65e4846b92d54859e22a5d92124557b397b4208d8752d5289d0262573c3c
version: 0.10.3.1
tag: Wolfram Warptangent
blockchain: arm
- platform: FreeBSD, 64-bit
icon: freebsd.svg
cli_url: freebsd64
cli_hash: 4c66a76752e18ae70b5fb1c728f0d2780eb129a6c8c7d0dee7ba02e05d91efae
version: 0.10.3.1
tag: Wolfram Warptangent
blockchain: freebsd
- platform: Source Code
icon: github.svg
cli_url: https://github.com/monero-project/bitmonero
cli_hash: source
version: Bleeding edge (possibly unstable)

158
_data/merchants.yml
View File

@ -1,158 +0,0 @@
- 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/

77
_data/tags.yml
View File

@ -1,77 +0,0 @@
- 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

63
_includes/dog.html
View File

@ -1,63 +0,0 @@
<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>

77
_includes/download.php
View File

@ -1,77 +0,0 @@
<?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>

30
_includes/footer.html
View File

@ -1,30 +0,0 @@
<div class="footer">
<div class="container">
<p>
<strong style="color: #ffffff;">[ <a href="/legal/terms">{% t global.terms %}</a> | <a href="/legal/privacy">{% t global.privacy %}</a> | <a href="/legal/copyright">{% t global.copyright %}</a> ]</strong>
<strong style="color: #ffffff;">[ <a href="https://github.com/monero-project/monero-site/edit/master/{{ page.path }}">{%t global.edit %}</a> ]</strong>
<a href="https://getmonero.org/feed.xml"><i class="fa fa-2x fa-rss-square"></i></a>
<a href="mailto:dev@getmonero.org"><i class="fa fa-2x fa-envelope-square"></i></a>
</p>
</div>
</div>
<!-- JS -->
<script src="//static.getmonero.org/scripts.js"></script>
<script type="text/javascript">
$(document).ready(function(){
$('[data-toggle="tooltip"]').tooltip();
});
(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
(i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
})(window,document,'script','//www.google-analytics.com/analytics.js','ga');
ga('create', 'UA-53312765-1', 'auto');
ga('require', 'linkid', 'linkid.js');
ga('send', 'pageview');
</script>
{% include hostflag.html %}

40
_includes/head.html
View File

@ -1,40 +0,0 @@
<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="57x57" href="/apple-touch-icon-57x57.png">
<link rel="apple-touch-icon" sizes="60x60" href="/apple-touch-icon-60x60.png">
<link rel="apple-touch-icon" sizes="72x72" href="/apple-touch-icon-72x72.png">
<link rel="apple-touch-icon" sizes="76x76" href="/apple-touch-icon-76x76.png">
<link rel="apple-touch-icon" sizes="114x114" href="/apple-touch-icon-114x114.png">
<link rel="apple-touch-icon" sizes="120x120" href="/apple-touch-icon-120x120.png">
<link rel="apple-touch-icon" sizes="144x144" href="/apple-touch-icon-144x144.png">
<link rel="apple-touch-icon" sizes="152x152" href="/apple-touch-icon-152x152.png">
<link rel="apple-touch-icon" sizes="180x180" href="/apple-touch-icon-180x180.png">
<link rel="icon" type="image/png" href="/favicon-32x32.png" sizes="32x32">
<link rel="icon" type="image/png" href="/favicon-194x194.png" sizes="194x194">
<link rel="icon" type="image/png" href="/favicon-96x96.png" sizes="96x96">
<link rel="icon" type="image/png" href="/android-chrome-192x192.png" sizes="192x192">
<link rel="icon" type="image/png" href="/favicon-16x16.png" sizes="16x16">
<link rel="manifest" href="/manifest.json">
<meta name="msapplication-TileColor" content="#2d89ef">
<meta name="msapplication-TileImage" content="/mstile-144x144.png">
<meta name="theme-color" content="#ffffff">
<link href="//static.getmonero.org/style.css?1" rel="stylesheet">
<meta name="msapplication-config" content="/ietemplates/ieconfig.xml">
</head>

76
_includes/header.html
View File

@ -1,76 +0,0 @@
<!-- Static navbar -->
<div class="navbar navbar-default navbar-static-top" role="navigation">
<div class="navbar-wrapper">
<div class="navbar-header">
<input type="checkbox" id="menu-toggle">
<label for="menu-toggle" class="navbar-toggle">
<span class="sr-only">Toggle navigation</span>
<span class="icon-bar"></span>
<span class="icon-bar"></span>
<span class="icon-bar"></span>
</label>
<a class="navbar-brand" href="/"><img class="logo" src="//static.getmonero.org/images/logo.svg"></a>
<ul class="nav navbar-nav navbar-right navbar-collapse">
<li><a class="yellow" href="https://forum.getmonero.org">{% t menu.forum %}</a></li>
<li class="dropdown">
<input type="checkbox" class="dropdown-input" id="drop-1"/><label for="drop-1" class="purple">{% t menu.blog %} <span class="caret"></span></label>
<ul class="dropdown-menu" role="menu">
<li><a href="/blog">{% t menu.allblog %}</a></li>
<li><a href="/blog/tags/monero%20missives">{% t menu.missives %}</a></li>
<li><a href="/blog/tags/dev%20diaries">{% t menu.devdiaries %}</a></li>
</ul>
</li>
<li class="dropdown">
<input type="checkbox" id="drop-2"/><label for="drop-2" class="red">{% t global.getting_started %} <span class="caret"></span></label>
<ul class="dropdown-menu" role="menu">
<li><a href="/getting-started/choose">{% t menu.choose %}</a></li>
<li><a href="/getting-started/running">{% t menu.running %}</a></li>
<li><a href="/getting-started/contribute">{% t menu.contribute %}</a></li>
<li><a href="/getting-started/donate">{% t menu.donations %}</a></li>
<li class="divider"></li>
<li><a href="/downloads">{% t menu.downloads %}</a></li>
<li><a href="https://github.com/monero-project">{% t menu.github %}</a></li>
<li class="divider"></li>
<li><a href="/getting-started/accepting">{% t menu.accepting %}</a></li>
<li><a href="/getting-started/merchants">{% t menu.merchants %}</a></li>
</ul>
</li>
<li class="dropdown">
<input type="checkbox" id="drop-3"/><label for="drop-3" class="orange">{% t menu.knowledge_base %} <span class="caret"></span></label>
<ul class="dropdown-menu" role="menu">
<li><a href="/knowledge-base/about">{% t menu.about %}</a></li>
<li><a href="/knowledge-base/people">{% t menu.people %}</a></li>
<li><a href="/knowledge-base/moneropedia">{% t global.wiki %}</a></li>
<li class="divider"></li>
<li><a href="/knowledge-base/user-guides">{% t menu.userguides %}</a></li>
<li><a href="/knowledge-base/developer-guides">{% t menu.developerguides %}</a></li>
<li class="divider"></li>
<li><a href="/design-goals">{% t menu.goals %}</a></li>
<li><a href="/research-lab">{% t menu.lab %}</a></li>
<li><a href="/knowledge-base/openalias">{% t menu.openalias %}</a></li>
<li><a href="/knowledge-base/projects">{% t menu.projects %}</a></li>
</ul>
</li>
<li class="dropdown">
<input type="checkbox" id="drop-4"/><label for="drop-4" class="softyellow last">{% t menu.community %} <span class="caret"></span></label>
<ul class="dropdown-menu" role="menu">
<li><a href="https://forum.getmonero.org">{% t menu.forum %}</a></li>
<li><a href="https://www.reddit.com/r/monero/">{% t menu.reddit %}</a></li>
<li><a href="https://monero.stackexchange.com">{% t menu.stackexchange %}</a></li>
<li><a href="https://bitcointalk.org/index.php?topic=583449.0">{% t menu.bitcointalk %}</a></li>
<li class="divider"></li>
<li><a href="https://monero.slack.com/">{% t menu.slack %}</a></li>
<li><a href="https://telegram.me/bitmonero">{% t menu.telegram %}</a></li>
<li class="divider"></li>
<li class="dropdown-header">{% t menu.irc %}</li>
<li><a href="irc://chat.freenode.net/#monero">{% t menu.irc-general %}</a></li>
<li><a href="irc://chat.freenode.net/#monero-dev">{% t menu.irc-development %}</a></li>
<li><a href="irc://chat.freenode.net/#monero-otc">{% t menu.irc-trading %}</a></li>
<li><a href="irc://chat.freenode.net/#monero-markets">{% t menu.irc-markets %}</a></li>
<li><a href="irc://chat.freenode.net/#monero-pools">{% t menu.irc-mining %}</a></li>
</ul>
</li>
</ul>
</div>
</div>
</div>

1
_includes/hostflag.html
View File

@ -1 +0,0 @@
<!-- page served by server N -->

12
_includes/language_cookie.php
View File

@ -1,12 +0,0 @@
<?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, "/");
?>

41
_layouts/blog_by_tag.html
View File

@ -1,41 +0,0 @@
<!DOCTYPE html>
<html>
{% 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 %}
{% include head.html %}
<body>
{% include header.html %}
<div class="container main-content">
<div class="page-title">
<!-- Icon is based on work by Sergiu Bagrin (http://pixelkit.com) and is licensed under Creative Commons BY 3.0 -->
<img src="//static.getmonero.org/images/icon_tags.svg" class="title-icon"><h2 class="inline">{% t tags.all %}: <span class="kicks">{{ tag.name }}</span></h2>
</div>
<div>
{% if site.tags[tag.slug] %}
{% for post in site.tags[tag.slug] %}
<h3><a href="{{ post.url }}">{{ post.title }}</a></h3>
<blockquote>
{{ post.summary }}
</blockquote>
{% endfor %}
{% else %}
<h3>{% t tags.notags %}</h3>
{% endif %}
</div>
</div>
{% include footer.html %}
</body>
</html>

18
_layouts/default.html
View File

@ -1,18 +0,0 @@
<!DOCTYPE html>
<html>
{% include head.html %}
<body>
{% include header.html %}
<div class="container main-content">
{{ content }}
</div>
{% include footer.html %}
</body>
</html>

17
_layouts/error.html
View File

@ -1,17 +0,0 @@
<!DOCTYPE html>
<html>
{% include head.html %}
<body>
{% include header.html %}
{{ content }}
{% include footer.html %}
{% include dog.html %}
</body>
</html>

22
_layouts/moneropedia.html
View File

@ -1,22 +0,0 @@
<!DOCTYPE html>
<html>
{% include head.html %}
<body>
{% include header.html %}
<div class="container main-content">
<div class="page-title">
<img src="//static.getmonero.org/images/icon_wiki.svg" class="title-icon"><h2 class="inline">{{ page.entry }} - <span class="softyellow-kicks">{% t global.wiki %}</span></h2>
</div>
{{ content }}
</div>
{% include footer.html %}
</body>
</html>

10
_layouts/none.html
View File

@ -1,10 +0,0 @@
<!DOCTYPE html>
<html lang="en">
<body>
{{ content }}
</body>
</html>

42
_layouts/post.html
View File

@ -1,42 +0,0 @@
---
layout: default
---
{% 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 }}">{{ tag.name }}</a>{% if forloop.last == false %}, {% endif %}{% endcapture %}
{% assign tags_content = tags_content_temp %}
{% endif %}
{% endfor %}
{% else %}
{% assign tags_content = '' %}
{% endif %}
<article>
<header>
<div class="page-title">
<!-- Icon is based on work by Freepik (http://www.freepik.com) and is licensed under Creative Commons BY 3.0 -->
<img src="//static.getmonero.org/images/icon_blog_post.svg" class="title-icon"><h2 class="inline">{{ page.title }}</h2>
</div>
<span class="author">{% t blog.author %}: {% if page.author %}{{page.author}}{% else %}{{site.author}}{% endif%}</span>
</header>
<p>{{ content }}</p>
<footer>
<hr>
<p id="post-meta">{{ tags_content }}</p>
{% if post.forum %}
<hr>
<p id="post-comments"><h3 class="text-center"><a href="{{ post.forum }}">{% t blog.forum %}</a></h3></p>
{% endif %}
</footer>
</article>

23
_layouts/root.html
View File

@ -1,23 +0,0 @@
{% 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>

23
_layouts/static_page.html
View File

@ -1,23 +0,0 @@
<!DOCTYPE html>
<html>
{% include head.html %}
<body>
{% include header.html %}
<div class="container main-content">
<div class="page-title">
{{ page.attribution }}
<img src="//static.getmonero.org/images/{{ page.icon }}.svg" class="title-icon"><h2 class="inline">{{ page.title-pre-kick }} <span class="{{ page.kick-class }}">{{ page.title-kick }}</span> {{ page.title-post-kick }}</h2>
</div>
{{ content }}
</div>
{% include footer.html %}
</body>
</html>

164
_plugins/jekyll-live-tiles.rb
View File

@ -1,164 +0,0 @@
# 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

83
_plugins/moneropedia.rb
View File

@ -1,83 +0,0 @@
# 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"], "/knowledge-base/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-lg-4'>\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-lg-4'>\n<h4 class='text-center'>" + entry[0] + "</h4>\n"
cur_letter = entry[0]
end
replace += "<a href='/knowledge-base/moneropedia/" + link + "'>" + 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 class="moneropedia" href="/knowledge-base/moneropedia/' + entry[:file] + '" data-toggle="tooltip" data-placement="top" data-original-title="' + entry[:summary] + '">' + term.gsub('-',' ') + '</a>')
end
end
base_converter(content)
end
end
end
end

70
_plugins/plugin.rb
View File

@ -1,70 +0,0 @@
# 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)

274
_plugins/sitemap_generator.rb
View File

@ -1,274 +0,0 @@
# 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

9
_posts/00-base-00
View File

@ -1,9 +0,0 @@
---
layout: post
title: Monero Missive for the Week of
summary:
tags: [monero missives, ]
author: Riccardo Spagni (fluffypony)
forum:
---

23
_posts/2014-06-02-dev-diary-for-the-week-of-2014-06-02.md
View File

@ -1,23 +0,0 @@
---
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.

30
_posts/2014-06-02-monero-missive-for-the-week-of-2014-06-02.md
View File

@ -1,30 +0,0 @@
---
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!

21
_posts/2014-06-10-dev-diary-for-the-week-of-2014-06-10.md
View File

@ -1,21 +0,0 @@
---
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.

33
_posts/2014-06-10-monero-missive-for-the-week-of-2014-06-10.md
View File

@ -1,33 +0,0 @@
---
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!

17
_posts/2014-06-18-dev-diary-for-the-week-of-2014-06-16.md
View File

@ -1,17 +0,0 @@
---
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

29
_posts/2014-06-18-monero-missive-for-the-week-of-2014-06-16.md
View File

@ -1,29 +0,0 @@
---
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.

13
_posts/2014-07-06-dev-diary-for-the-week-of-2014-06-30.md
View File

@ -1,13 +0,0 @@
---
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

25
_posts/2014-07-06-monero-missive-for-the-week-of-2014-06-30.md
View File

@ -1,25 +0,0 @@
---
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!

17
_posts/2014-07-13-dev-diary-for-the-week-of-2014-07-07.md
View File

@ -1,17 +0,0 @@
---
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.

25
_posts/2014-07-13-monero-missive-for-the-week-of-2014-07-07.md
View File

@ -1,25 +0,0 @@
---
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!

16
_posts/2014-12-15-dev-diary-for-the-week-of-2014-12-15.md
View File

@ -1,16 +0,0 @@
---
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!

16
_posts/2014-12-15-external-projects-for-the-week-of-2014-12-15.md
View File

@ -1,16 +0,0 @@
---
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

20
_posts/2014-12-15-monero-missive-for-the-week-of-2014-12-15.md
View File

@ -1,20 +0,0 @@
---
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!

237
_posts/2015-01-05-monero-missive-2014-year-in-review.md
View File

@ -1,237 +0,0 @@
---
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

200
_posts/2015-02-23-monero-missive-for-the-week-of-2015-02-23.md
View File

@ -1,200 +0,0 @@
---
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!

141
_posts/2015-03-02-monero-missive-for-the-week-of-2015-03-02.md
View File

@ -1,141 +0,0 @@
---
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

233
_posts/2015-03-09-monero-missive-for-the-week-of-2015-03-09.md
View File

@ -1,233 +0,0 @@
---
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.

26
_posts/2015-03-16-monero-missive-for-the-week-of-2015-03-16.md
View File

@ -1,26 +0,0 @@
---
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!

24
_posts/2015-03-23-monero-missive-for-the-week-of-2015-03-23.md
View File

@ -1,24 +0,0 @@
---
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!

18
_posts/2015-03-30-monero-missive-for-the-week-of-2015-03-30.md
View File

@ -1,18 +0,0 @@
---
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!

344
_posts/2015-06-29-monero-missive-for-the-week-of-2015-06-29.md
View File

@ -1,344 +0,0 @@
---
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!

130
_posts/2015-08-31-monero-missive-for-the-week-of-2015-08-31.md
View File

@ -1,130 +0,0 @@
---
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

434
_posts/2015-09-14-monero-missive-for-the-week-of-2015-09-14.md
View File

@ -1,434 +0,0 @@
---
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

17
_posts/2015-12-26-monero-missive-for-the-week-of-2015-12-26 copy.md
View File

@ -1,17 +0,0 @@
---
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?)

69
_posts/2016-01-01-monero-0.9.0-hydrogen-helix-released.md
View File

@ -1,69 +0,0 @@
---
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

37
_posts/2016-01-15-monero-0.9.1-released.md
View File

@ -1,37 +0,0 @@
---
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

359
_posts/2016-01-31-overview-and-logs-for-the-dev-meeting-held-on-2016-01-31.md
View File

@ -1,359 +0,0 @@
---
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

159
_posts/2016-02-10-monero-missive-2015-year-in-review.md
View File

@ -1,159 +0,0 @@
---
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

284
_posts/2016-02-14-overview-and-logs-for-the-dev-meeting-held-on-2016-02-14.md
View File

@ -1,284 +0,0 @@
---
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

38
_posts/2016-03-16-monero-0.9.2-released.md
View File

@ -1,38 +0,0 @@
---
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

342
_posts/2016-03-19-overview-and-logs-for-the-dev-meeting-held-on-2016-03-19.md
View File

@ -1,342 +0,0 @@
---
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

40
_posts/2016-03-22-monero-0.9.3-released.md
View File

@ -1,40 +0,0 @@
---
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

38
_posts/2016-04-02-monero-0.9.4-released.md
View File

@ -1,38 +0,0 @@
---
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

219
_posts/2016-04-24-overview-and-logs-for-the-dev-meeting-held-on-2016-04-24.md
View File

@ -1,219 +0,0 @@
---
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

117
_posts/2016-05-08-logs-for-the-kovri-dev-meeting-held-on-2016-05-08.md
View File

@ -1,117 +0,0 @@
---
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

127
_posts/2016-05-08-overview-and-logs-for-the-dev-meeting-held-on-2016-05-08.md
View File

@ -1,127 +0,0 @@
---
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

202
_posts/2016-05-22-logs-for-the-kovri-dev-meeting-held-on-2016-05-22.md
View File

@ -1,202 +0,0 @@
---
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

129
_posts/2016-05-22-overview-and-logs-for-the-dev-meeting-held-on-2016-05-22.md
View File

@ -1,129 +0,0 @@
---
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

241
_posts/2016-06-05-logs-for-the-kovri-dev-meeting-held-on-2016-06-05.md
View File

@ -1,241 +0,0 @@
---
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

277
_posts/2016-06-05-overview-and-logs-for-the-dev-meeting-held-on-2016-06-05.md
View File

@ -1,277 +0,0 @@
---
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

294
_posts/2016-06-19-logs-for-the-Kovri-dev-meeting-held-on-2016-06-19.md
View File

@ -1,294 +0,0 @@
---
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

225
_posts/2016-06-19-overview-and-logs-for-the-dev-meeting-held-on-2016-06-19.md
View File

@ -1,225 +0,0 @@
---
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

20
_posts/2016-06-20-monero-missive-for-the-week-of-2016-06-20.md
View File

@ -1,20 +0,0 @@
---
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*

248
_posts/2016-07-03-logs-for-the-Kovri-dev-meeting-held-on-2016-07-03.md
View File

@ -1,248 +0,0 @@
---
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

132
_posts/2016-07-03-overview-and-logs-for-the-dev-meeting-held-on-2016-07-03.md
View File

@ -1,132 +0,0 @@
---
layout: post
title: Overview and Logs for the Dev Meeting Held on 2016-07-03
summary: OTF, open PRs and issues, and brief update on Ring CT
tags: [dev diaries, core, crypto, 0mq]
author: dEBRUYNE / fluffypony
---
*July 3th, 2016*
# Overview (by Aerbax)
An overview [can be found on Hello Monero](https://hellomonero.com/article/monero-bi-weekly-dev-meeting-note-highlights-2016-07-03)
# Logs
**\<fluffypony>** time for meeting to start
**\<hyc>** ok
**\<ArticMine>** Ok
**\<fluffypony>** ArticMine / othe / smooth / NoodleDoodle / moneromooo / tewinget / dEBRUYNE / gingeropolous / etc.
**\<dEBRUYNE>** somewhat here
**\<fluffypony>** ok
**\<fluffypony>** welcome to the 75th annual hunger games
**\<fluffypony>** ok so
**\<fluffypony>** first things first, small administrative update
**\<fluffypony>** we've re-applied for funding from the OTF, but for Kovri (given their previous response)
**\<fluffypony>** it's the start of the process, but who knows, maybe we have a bit of funding to work on both
**\<fluffypony>** as Monero represents an example integration
**\<fluffypony>** then the open issues are creeping up, there are a bunch I'm going to be closing as solved
**\<fluffypony>** #754 is an interesting onw
**\<fluffypony>** *one
**\<fluffypony>** https://github.com/monero-project/bitmonero/issues/754
**\<moneromooo>** We don't care now, since rct.
**\<fluffypony>** good point
**\<fluffypony>** ok so then it can be closed as wontfix
**\<moneromooo>** Well, it's fixed, by transfer_new.
**\<fluffypony>** yes
**\<fluffypony>** so
**\<fluffypony>** I'd like to reopen the discussion of deprecating transfer and replacing it with transfer_new
**\<fluffypony>** or is that pointless because rct
**\<moneromooo>** I've done that in the rct branch.
**\<fluffypony>** ok great
**\<fluffypony>** perfect
**\<fluffypony>** then binary renames are on hold until the rct PR
**\<fluffypony>** because I don't want to make that implode
**\<hyc>** what renames?
**\<moneromooo>** I don't think this would conflict much, if at all.
**\<gingeropolous>** bitmonerod --> monero and stuff like that prolly
**\<fluffypony>** hyc: https://github.com/monero-project/bitmonero/issues/80
**\<fluffypony>** this in particular: https://github.com/monero-project/bitmonero/issues/80#issuecomment-223596750
**\<hyc>** ah
**\<fluffypony>** moneromooo: do you want me to PR changes to your branch then? will save you a rebase?
**\<moneromooo>** Sure.
**\<fluffypony>** ok great
**\<moneromooo>** Would rct be merged before the wallet2_api stuff then ?
**\<fluffypony>** so that's the next thing for discussion
**\<fluffypony>** the massive wallet2 PR
**\<fluffypony>** it's rebased against master now
**\<fluffypony>** moneromooo: what are your thoughts on merging before or after ?
**\<moneromooo>** I don't really have one.
**\<moneromooo>** Maybe merge Ilya's first, since there's not going to be much review/fixes anyway.
**\<fluffypony>** ok
**\<gingeropolous>** so wallet2 a buncha stuff specifically designed for GUI?
**\<moneromooo>** wallet2_api is.
**\<fluffypony>** there's also been a fair amount of review on that PR because it's so hefty - is everyone comfortable that major issues (especially in git history) have been resolved and it can be merged?
**\<moneromooo>** Depends on how high you put the bar.
**\<fluffypony>** moneromooo: it's low - we can open issues to fix stuff after the merge
**\<moneromooo>** But assuming the GPL code is gone, I think it's ok. It can be changed later.
**\<fluffypony>** oh the GPL cmake stuff, I'll check on that
**\<fluffypony>** looks like there's a BSD licensed replacement now
**\<moneromooo>** I saw the comment, I did not look at the new code.
**\<fluffypony>** hokay
**\<fluffypony>** then there are a bunch of new PRs if anyone wants to take a glance at them
**\<fluffypony>** #878, #879, #882, #883, #884, #885
**\<fluffypony>** they're mostly small
**\<fluffypony>** I need someone to check mine (885, just a readme change) before merging plx
**\<hyc>** huh i only see up to 881
**\<hyc>** oh PRs not issues
**\<moneromooo>** I seem to have reviewed all these, except the windows packages one which I have no clue about.
**\<fluffypony>** it compiled successfully
**\<fluffypony>** couple of weird complaints about deprecations at the end
**\<fluffypony>** C:/msys64/mingw64/include/boost/type_traits/detail/template_arity_spec.hpp:13:84: note: #pragma message: NOTE: Use of this header (template_arity_spec.hpp) is deprecated
**\<fluffypony>** # pragma message("NOTE: Use of this header (template_arity_spec.hpp) is deprecated")
**\<fluffypony>**
**\<hyc>** I've been getting that on most builds now
**\<hyc>** boost 1.60
**\<fluffypony>** ah
**\<fluffypony>** boost, sigh.
**\<hyc>** not sure what there is to do about that since it's an internal header file, not one thata we explicitly include
**\<fluffypony>** http://permalink.gmane.org/gmane.comp.lib.boost.devel/264164
**\<fluffypony>** fixed in 1.61
**\<hyc>** ok
**\<fluffypony>** ok so
**\<fluffypony>** general update-y time
**\<fluffypony>** tewinget doesn't seem to be around, he can update us on 0MQ when he is
**\<fluffypony>** moneromooo: how goes ringct?
**\<moneromooo>** I'm kinda blocked today, so I didn't do much.
**\<fluffypony>** I mean in the last two weeks since the last meeting, lol
**\<moneromooo>** Both that watch only thing that nobody wants to talk about, and waiting for shen's sybil resistant upgrade.
**\<fluffypony>** kk
**\<moneromooo>** Well, last two weeks, more tests, fixes, sweep_all now uses rct, and better output selection (for the general case).
**\<hyc>** does rct let us do watch only with both deposits and withdrawals?
**\<moneromooo>** No.
**\<fluffypony>** this sorta bounces back to the MRL, so we wait for feedback
**\<fluffypony>** hyc: are you doing anything interesting at the moment?
**\<hyc>** not really. I still need to come up with a fix for txn_full on 32bit
**\<hyc>** I'm traveling most of the the rest of this month
**\<hyc>** so not much hacking time
**\<fluffypony>** cool beans
**\<fluffypony>** ok - anything else from anyone else?
**\<luigi1112>** Hi
**\<luigi1112>** :-)
**\<moneromooo>** If anyone wants to start reviewing the rct-rptest branch, I don't think it's going to change again (save new commits).
**\<moneromooo>** Like, find how to pwn it.
**\<fluffypony>** oh luigi1112 I forgot to tag you at the beginning, apologies
**\<moneromooo>** Would be a good job for Heuristic, except there's no picture of hte code...
**\<moneromooo>** Oh, some other dev related thing: luigi1112, any news on the change to signing something from a standard address ? :)
**\<luigi1112>** Nah I've been reading but don't have any time to participate atm
**\<luigi1112>** Oops :-)
**\<luigi1112>** Still soon
**\<fluffypony>** you forgot the tm
**\<fluffypony>** it's not soon if it's not tm
**\<luigi1112>** Well it should be this week or next :-)
**\<fluffypony>** ok I think that brings the meeting to a close - Kovri meeting is only in 23 minutes, so feel free to add / discuss new things and it'll be in the log
**\<hyc>** i got nothing, catch y'all next time
**\<gingah>** any new thoughts on the auto fee thing?
**\<rg>** id like to bring up the most imporant issue, fluffypony -- free XMR for me
**\<fluffypony>** gingah: auto fee?
**\<moneromooo>** The thing ArticMine was looking at - scaling fees based on... stuff.
**\<ArticMine>** Setting fees based on the blocksize
**\<ArticMine>** and the reward penalty
**\<ArticMine>** One also has to look at optimizing what transactions miners will accept vs block penalty and fees paid

127
_posts/2016-07-31-logs-for-the-Kovri-dev-meeting-held-on-2016-07-31.md
View File

@ -1,127 +0,0 @@
---
layout: post
title: Logs for the Kovri Dev Meeting Held on 2016-07-31
summary: Brief review of what has been completed since last meeting, and Kovri Logo
tags: [dev diaries, i2p, crypto]
author: dEBRUYNE / fluffypony
---
*July 31th, 2016*
# Logs
**\<anonimal>** ping fluffypony we missed you in #monero-dev
**\<anonimal>** I'll proceed with the meeting as planned but the bulk of the agenda is picking on your assigned issues.
**\<anonimal>** https://github.com/monero-project/kovri/issues/216
**\<anonimal>** Meeting Agenda: Sunday, July 31st, 17:00 UTC
**\<anonimal>** 1. Greetings
**\<anonimal>** 2. Brief review of what's been completed since the previous meeting
**\<anonimal>** 3. Discuss Kovri logo
**\<anonimal>** 4. Closing #271
**\<anonimal>** 5. Closing #226
**\<anonimal>** 6. Closing #105
**\<anonimal>** 7. Closing #46
**\<anonimal>** 8. Closing #27
**\<anonimal>** 9. Any additional meeting items
**\<anonimal>** 10. Confirm next meeting date/time
**\<anonimal>** Hi.
**\<i2p-relay> {-needmoney90}** * walks into the room and sits in the nearest available seat
**\<i2p-relay> {-needmoney90}** Just watching for today
**\<anonimal>** Is anyone freenode side? This meeting is not being relayed to #monero-dev. I'll hop onto slack to see if the relay is working.
**\<i2p-relay> {-_Slack} \<needmoney90>** It appears so
**\<i2p-relay> {-_Slack} \<needmoney90>** I2P, Slack, and IRC are all relaying
**\<anonimal>** K, thanks.
**\<anonimal>** Onto point 2.
**\<anonimal>** $ git log --no-merges --pretty=oneline --since=1.month | wc -l
**\<anonimal>** 72
**\<anonimal>** Code highlights include:
**\<anonimal>** - Mem leak fixes
**\<anonimal>** - New constant-time comparison for ed25519
**\<anonimal>** - Two new contributors: moneromooo and rakhimov
**\<anonimal>** (hopefully will see more from both devs)
**\<anonimal>** - regex fix, clang fixes
**\<anonimal>** - A whole lot of build/repo work
**\<anonimal>** - We officially build with clang
**\<anonimal>** - We officially build on OSX again
**\<anonimal>** - Two new submodules: cpp-netlib, cryptopp
**\<anonimal>** - New URI parsing implementation courtesy of cpp-netlib
**\<anonimal>** - New clang-format config (still in development)
**\<anonimal>** - Updated style guide + building instructions + docs
**\<anonimal>** - Upstream bug hunting/fixing (huge time-suck)
**\<anonimal>** - Coverity's website finally works (for me)
**\<anonimal>** - Misc fixes, enhancements
**\<anonimal>** Project highlights include:
**\<anonimal>** - Kovri End-User Documentation Proposal - #256
**\<anonimal>** - 9 new opened issues, 7 new closed issues
**\<anonimal>** - Creation of @kovri@quitter.se
**\<anonimal>** - I've also spent some time with bitmonero/monero-project
**\<anonimal>** That's all from me for 2. Anyone else?
**\<anonimal>** Ok, guess not.
**\<anonimal>** fluffypony fluffypony fluffypony fluffypony
**\<i2p-relay> {-needmoney90}** * summons fluffypony from the depths
**\<anonimal>** 2nd meeting in a row he's missed. I hope he's alive.
**\<i2p-relay> {-needmoney90}** D:
**\<anonimal>** I know this is opensource and volunteer but I'm getting a bit irritated.
**\<anonimal>** Being stood up is not very respectful.
**\<i2p-relay> {-needmoney90}** oh he isnt in this room
**\<i2p-relay> {-needmoney90}** summoning wont work from here
**\<anonimal>** lol needmoney90
**\<i2p-relay> {-needmoney90}** He isn’t even on IRC it seems
**\<i2p-relay> {-needmoney90}** hm
**\<i2p-relay> {-needmoney90}** thats strange, Im used to him being always on/ide
**\<i2p-relay> {-needmoney90}** idle
**\<anonimal>** He's on irc2p side.
**\<anonimal>** Is dEBRUYNE on freenode side? Is this meeting even being logged?
**\<i2p-relay> {-needmoney90}** Well, Slack is certainly logging it
**\<i2p-relay> {-needmoney90}** and my client possibly is
**\<i2p-relay> {-needmoney90}** havent checked logging settings
**\<Zenified>** so is my client
**\<anonimal>** Ok.
**\<anonimal>** Moving on to 3.
**\<anonimal>** "Discuss Kovri logo"
**\<anonimal>** Who did Monero's logo?
**\* anonimal:** asked in #monero-dev, no response
**\<anonimal>** Any thoughts on a logo for Kovri?
**\<anonimal>** How about a nude porn star holding a letter 'K'?
**\<i2p-relay> {-needmoney90}** I've been thinking about it
**\<i2p-relay> {-needmoney90}** and….I don’t think that will get us corporate/mainstream usage
**\<i2p-relay> {-needmoney90}** then again, maybe it will
**\<i2p-relay> {-needmoney90}** keep it on the backburner
**\<anonimal>** lol
**\* anonimal:** was joking
**\<i2p-relay> {-needmoney90}** I’ve been thinking some kind of K made of nodes (like the Ethereum Classic logo), but fading out on half
**\<i2p-relay> {-needmoney90}** though its probably too complex
**\<i2p-relay> {-needmoney90}** https://camo.githubusercontent.com/eec95efca3ae789116e4557656898ab52ca74cba/687474703a2f2f63646e2d696d616765732d312e6d656469756d2e636f6d2f6d61782f3830302f312a6e4955617a775f75334b436843583839664c674c44672e706e67
**\<anonimal>** Sounds cool.
**\<anonimal>** DaveyJones pointed this out https://99designs.de/logo-design/contests/monero-mro-cryptocurrency-logo-design-contest-382486
**\<anonimal>** needmoney90: could that url get any longer?...
**\<anonimal>** Ah, I see. Interesting idea needmoney90
**\<anonimal>** Maybe we should hold a contest and reward the winner with XMR?
**\<i2p-relay> {-needmoney90}** Sorry about the URL length, I copypasta’d without minifying
**\<anonimal>** Np.
**\<anonimal>** Where would be a good place to host a Kovri logo contest?
**\<anonimal>** (XMR friendly place)
**\<anonimal>** I'll open a ticket and we can deal with it later
**\<anonimal>** Points 4-8 are all fluffypony
**\<anonimal>** 9. Any addition meeting items
**\<i2p-relay> {-needmoney90}** None here
**\<anonimal>** EinMByte is MIA. SSU still not finished. From what I've worked on, debugging the rest to get it merged will require motivation on my part.
**\<i2p-relay> {-needmoney90}** SSU?
**\<anonimal>** No shows at meetings + no pay != motivation for me to do lifting beyond what I'm doing.
**\* anonimal:** grabs link for needmoney90
**\<anonimal>** needmoney90: #140
**\<i2p-relay> {-needmoney90}** tanks
**\<anonimal>** I'll make myself available for the next 30 minutes and then paste a link to the meeting log in #216
**\<i2p-relay> {-needmoney90}** I’m really curious where fluffy got off to..
**\<anonimal>** We were chatting about an hour before monero's meeting was supposed to start
**\<anonimal>** Maybe he simply forget. This has happened several times in the past.
**\<i2p-relay> {-needmoney90}** :(
**\<i2p-relay> {-_Slack} \<anonimal>** needmoney90: is there a way to easily export channel logs here?
**\<i2p-relay> {-_Slack} \<needmoney90>** hrmmm
**\<i2p-relay> {-_Slack} \<needmoney90>** I just exported
**\<i2p-relay> {-_Slack} \<needmoney90>** should have the logs (from all channels) in my email soon
**\<i2p-relay> {-_Slack} \<needmoney90>** barring that, someone's IRC client logs will work
**\<i2p-relay> {-_Slack} \<anonimal>** Nice. Would it be easy to fpaste a private paste of just our meeting? e.g., do they do any formatting or just lump everything into an email?
**\<i2p-relay> {-_Slack} \<needmoney90>** no idea
**\<i2p-relay> {-_Slack} \<needmoney90>** ill let you know
**\<i2p-relay> {-_Slack} \<anonimal>** Thanks. For the time being I'll just do a quick format of my logs to takeout timestamps and paste the meeting.

79
_posts/2016-07-31-overview-and-logs-for-the-dev-meeting-held-on-2016-07-31.md
View File

@ -1,79 +0,0 @@
---
layout: post
title: Overview and Logs for the Dev Meeting Held on 2016-07-31
summary: Monero Project repository, and brief update on Ring CT
tags: [dev diaries, core, crypto, 0mq]
author: dEBRUYNE / fluffypony
---
*July 31th, 2016*
# Overview
-
# Logs
**\<fluffypony>** time for meeting to start
**\<i2p-relay> {-anonimal}** Are we not having a meeting?
**\<ArticMine>** I was wondering the same thing
**\<i2p-relay> {-anonimal}** Kovri meeting at 17:00. I thought we were meeting at 16:00.
**\<i2p-relay> {-anonimal}** fluffypony: ^
**\<ArticMine>** For Monero
**\<i2p-relay> {-anonimal}** Yes
**\<i2p-relay> {-anonimal}** * disappointed
**\<luigi1112>** Maybe he died
**\<luigi1112>** We could meet without him if people have stuff to say :-)
**\<moneromooo>** Well, I have one thing to say: who wants to join the testnet and try random stuff to see if they can get it to break ?
**\<moneromooo>** Preferably corner cases.
**\<ArticMine>** How many testnet nodes are there?
**\<moneromooo>** I think three.
**\<i2p-relay> {-anonimal}** I would but I don't have a reliable VPS at the moment.
**\<ArticMine>** I can set at testnet node. What are the stiings
**\<ArticMine>** settings
**\<moneromooo>** bitmonerod --add-exclusive-node 176.9.17.19:28080 --testnet
**\<moneromooo>** And you need to have built with my rct-private-fork branch.
**\<moneromooo>** And make sure you backup your db and wallet first, as they won't be compatible with "normal" version once you run rct code.
**\<moneromooo>** https://github.com/moneromooo-monero/bitmonero/tree/rct-private-fork is the branch to use.
**\<moneromooo>** Actually, use https://github.com/moneromooo-monero/bitmonero/commit/58ea23fa144b9eaec506461f96649d0c7b4b3914
**\<moneromooo>** Latest has an incompatible comms change.
**\<ArticMine>** Great I will give this a try. Is there a test net db or sync from scratch
**\<moneromooo>** If you don't have a testnet db already, you will have to sync.
**\<i2p-relay> {-anonimal}** #903 has gotten some momentum. Is it too soon to come to an agreement?
**\<moneromooo>** Can't hurt I think.
**\<i2p-relay> {-anonimal}** So we need a name. moneromooo any thoughts?
**\<_Slack> \<needmoney90>** Bond. James Bond.
**\<moneromooo>** I've seen two names proposed already. I don't have a better idea.
**\<_Slack> \<needmoney90>** (What are we naming again?)
**\<moneromooo>** A repo, AFAICT.
**\<i2p-relay> {-anonimal}** neemoney90: #903
**\<_Slack> \<needmoney90>** Repo-y McRepoface
**\<i2p-relay> {-anonimal}** luigi1112 any thoughts?
**\<i2p-relay> {-anonimal}** ArcticMine ^
**\<_Slack> \<needmoney90>** My thoughts submitted
**\<ArticMine>** monero-organization for #903
**\<moneromooo>** That sounds good.
**\<i2p-relay> {-anonimal}** Ooo, I like that best.
**\<i2p-relay> {-anonimal}** ArcticMine will you comment in issue or I can copy/paste?
**\<ArticMine>** You can copy past, I may comment.
**\<ArticMine>** copy/paste
**\<i2p-relay> {-anonimal}** K, done. I also like monero-project/organization.
**\<ArticMine>** That is also good
**\<i2p-relay> {-anonimal}** Kovri end-user documentation proposal is in open tasks
**\<ArticMine>** Actually better than my original idea
**\<i2p-relay> {-anonimal}** https://forum.getmonero.org/7/open-tasks/2592/create-end-user-kovri-documentation
**\<i2p-relay> {-anonimal}** The problem with the forum is that its somewhat obscure and I don't get emailed notifications.
**\<i2p-relay> {-anonimal}** So obscurity = less funding. No notifications = more babysitting.
**\<i2p-relay> {-anonimal}** An org repo can help with things like this, imho.
**\<redfish>** maybe monero-project/org
**\<ArticMine>** org can be confused with .org Just a thought
**\<i2p-relay> {-anonimal}** Agreed. How about https://github.com/monero-project/community
**\<i2p-relay> {-anonimal}** Or is that too vague?
**\<ArticMine>** I thing community is too broad.
**\<i2p-relay> {-anonimal}** Kovri meeting in 3 minutes.
**\<i2p-relay> {-anonimal}** I'm hopping over to #kovri-dev
**\<i2p-relay> {-anonimal}** I wish the relay bot was online.
**\<ArticMine>** One could say organizational
**\<i2p-relay> {-anonimal}** I would say have it here but I don't know who is freenode side.
**\<i2p-relay> {-anonimal}** If anyone is interested in talking about a logo for Kovri, could you please hop over to #kovri-dev?
**\<i2p-relay> {-anonimal}** I don't know if dEBRUYNE is logging our meeting so I or slack will be taking care of it.

421
_posts/2016-08-14-overview-and-logs-for-the-dev-meeting-held-on-2016-08-14.md
View File

@ -1,421 +0,0 @@
---
layout: post
title: Overview and Logs for the Dev Meeting Held on 2016-08-14
summary: Ring CT, hardfork schedule, 0MQ
tags: [dev diaries, core, crypto, 0mq]
author: dEBRUYNE / fluffypony
---
*August 14th, 2016*
# Overview
An overview [can be found on Hello Monero](https://hellomonero.com/article/monero-bi-weekly-dev-meeting-note-highlights-2016-08-14)
# Logs
**\<wallet42>** moneromoo: rewview guidelines?
**\<moneromooo>** wallet42: well, whatever you feel comfortable with. Do you have anything in mind ?
**\<i2p-relay> {-anonimal}** Is there a meeting in a few minutes?
**\<moneromooo>** The most important is potential for exploits.
**\<moneromooo>** Yes.
**\<hyc>** awesome
**\<moneromooo>** Well, assuming the pony isn't too busy with mymonero.
**\<darkcoinspy>** get your notepads out everyone. time to take notes on the competition
**\<i2p-relay> {-anonimal}** Which competition?
**\<moneromooo>** I think he just meant dash is still around. It's another crypto (ex darkcoin).
**\<dEBRUYNE>** \<moneromooo> Well, assuming the pony isn't too busy with mymonero. <= he was online 20 min ago, fwiw :p
**\<hyc>** fixing mymonero...
**\<dEBRUYNE>** :-P
**\<alex\_\_\_>** what happened to mymonero?
**\<hyc>** its blockchain got stuck
**\<alex\_\_\_>** ah ok
**\<dEBRUYNE>** alex\_\_\_: \<\_Telegram> \<fluffypony> there were like 6 imports running which deadlocked the database
**\<hyc>** I thought we fixed db\_open to disallow more than 1 process on the DB at a time
**\<moneromooo>** Might be talking about his sql db I think.
**\<hyc>** ah
**\<hyc>** too bad. we've been working on an LMDB backend for mysql/mariadb but not much progress in a long time
**\<DaveyJones>** isnt there supposed to be a meeting? xD
**\<JjegrUseinob>** yes
**\<JjegrUseinob>** waiting on poniex
**\<JjegrUseinob>** ponies
**\<hyc>** fluffypony fluffypony fluffypony ?
**\<JjegrUseinob>** fluffypony may be drinking wine right now
**\<JjegrUseinob>** have you seen his wine rack?
**\<i2p-relay> {-anonimal}** Yes, epic.
**\<JjegrUseinob>** im about to go get a drink myself
**\<JjegrUseinob>** brb
**\<hyc>** good idea
**\<dEBRUYNE>** moneromooo, hyc: perhaps someone else can take the lead until he returns?
**\<hyc>** if we had an agenda in advance that'd work. I've got no idea what needs to be covered today
**\<moneromooo>** Well, I have just one thing to say, really: reviewers wanted (even for part of the stuff).
**\<hyc>** OK, that's a good topic. So there's now a PR for the RingCT code
**\<hyc>** which means it's presumably functionally complete and ready for heavy testing
**\<dEBRUYNE>** \<hyc> if we had an agenda in advance that'd work. I've got no idea what needs to be covered today <= let's just discuss Ring CT first and the additional open PRs
**\<DaveyJones>** paging othe, luigi1111w, luigi1112, othe, tewinget too
**\<i2p-relay> {-anonimal}** Congratulations to everyone involved on that. Its a big one.
**\<moneromooo>** Yes. I don't think I've got anything else to add, until luigi finds something else he wants to change.
**\<DaveyJones>** maybe smooth too
**\<moneromooo>** But reviewing this isn't going to be wasted anyway, even if he finds something.
**\<dEBRUYNE>** ^ NoodleDoodle, ArticMine
**\<DaveyJones>** but the agenda thing would be nice for such incidents
**\<dEBRUYNE>** moneromooo: Is there a way people can help with testing?
**\<i2p-relay> {-anonimal}** moneromooo: is there anything in particular that needs attention in terms of review?
**\<ArticMine>** RingCT is going to need heavy testing and a public testnet would be a great asset for this
**\<moneromooo>** Well, the private fork branch is out of date now, there'll be a public testnet once there's a modicum of review I expect.
**\<wallet42>** I would love to setup and pay for a public testnet with a couple nodes
**\<dEBRUYNE>** Fwiw, there's a guide to setup a private tesnet -> https://moneroexamples.github.io/private-testnet/
**\<fluffypony>** sorry just got in
**\<luigi1112>** Sounds good :-)
**\<fluffypony>** was eating
**\<moneromooo>** Hay.
**\<moneromooo>** er, I mean... hey.
**\<hyc>** LOL
**\<DaveyJones>** LOL
**\<dEBRUYNE>** People could apply the RCT PR to the code and test it on their own private testnet
**\<fluffypony>** ok so
**\<moneromooo>** It's already based on latest master. I did removed the forking setup though.
**\<fluffypony>** moneromooo: you mean the PR?
**\<moneromooo>** Yes.
**\<moneromooo>** I kinda expect (1) reviews, (2) merge, (3) testnet, (4) any fixes PR'd separately.
**\<fluffypony>** does the PR have a fork date?
**\<moneromooo>** No.
**\<wallet42>** how to activate it?
**\<dEBRUYNE>** moneromooo: I meant apply as in manually add it because it hasn't been merged yet :-P
**\<i2p-relay> {-anonimal}** Thanks for the link dEBRUYNE
**\<moneromooo>** wallet42: it will activate at the right height, once it is cchosen.
**\<i2p-relay> {-anonimal}** I have to run folks, I'll read the backlog tomorrow.
**\<moneromooo>** see ya
**\<fluffypony>** cheers anonimal
**\<luigi1112>** Yeah it shouldn't have a date
**\<fluffypony>** moneromooo: I don't understand the "right height" thing, plz explain
**\<moneromooo>** Entries in the hard fork table in src/blockchain.cpp.
**\<moneromooo>** (which do not exist yet)
**\<dEBRUYNE>** I think we should set a height that adds 1-2 months to the height after this process has completed -> **\<moneromooo>** I kinda expect (1) reviews, (2) merge, (3) testnet, (4) any fixes PR'd separately.
**\<fluffypony>** so as this stands
**\<fluffypony>** it understands v3 transactions
**\<dEBRUYNE>** Ring CT is such a big change that I think we could deviate once from the HF schedule
**\<moneromooo>** Let me explain versions and stuff about this:
**\<fluffypony>** k
**\<moneromooo>** Currently, we are on HF 2, and tx version 1 is the only one that exists.
**\<moneromooo>** At HF 3 (september on mainnet), pretty much nothing changes.
**\<moneromooo>** At HF 4 (march), rct txes (v2 txes) are allowed. At HF 5 (september in a year), v1 txes are disallowed, except for sweep\_unmixable.
**\<moneromooo>** Though the last bit (sweep\_unmixable) might be unnecessary, I'm unsure.
**\<fluffypony>** ok
**\<hyc>** sounds fine
**\<moneromooo>** Oh, and at HF 4 (when rct txes are allowed), the coinbase gets in a single out, and is stored as rct, despite not being rct.
**\<moneromooo>** So they can be spent along with rct fake outs.
**\<fluffypony>** oh neat
**\<hyc>** so that also means no quantization then?
**\<moneromooo>** Yes.
**\<dEBRUYNE>** "v1 txes are disallowed" -> does that mean everyone needs to move their coins or will a one time transaction be allowed after that?
**\<moneromooo>** An rct tx may spend pre-rct outputs.
**\<fluffypony>** dEBRUYNE: nobody needs to move anything yet
**\<fluffypony>** or ever, really
**\<hyc>** right, this doesn't affect existing outputs. only newly generated txs
**\<luigi1112>** The block reward thing is neat if it works :-)
**\<JjegrUseinob>** so what will september HF do then?
**\<dEBRUYNE>** fluffypony, hyc: thanks, was asking for clarification
**\<moneromooo>** It does. Was a pita due to breaking the tests, but it all works now :D
**\<fluffypony>** JjegrUseinob: roll over to stick to the schedule, include the next HF date so that nodes notify
**\<fluffypony>** and also include all the fixes to-date
**\<luigi1112>** Quantize the reward afaik
**\<moneromooo>** September fork just enforces the coinbase to be split into denominations.
**\<luigi1112>** (Does someone know the state of pools?)
**\<fluffypony>** moneromooo: are we going to point release with the rct PR merged or before then?
**\<ArticMine>** Does the September HF force min 4 mixin?
**\<hyc>** and that's not a significant brhavior change, right? it was always supposed to be split
**\<moneromooo>** It was suppose dto, but not enforced.
**\<luigi1112>** Rct doesn't really make a difference..it's just dead code until activated
**\<luigi1112>** So the question is are there still offending pools that need to update
**\<moneromooo>** I'm mostly bothered about having this huge chunk of stuff that creats conflicts with evreything now.
**\<fluffypony>** luigi1112: guaranteed that MinerGate is still using their custom stuff and just fudging the version
**\<hyc>** you're talking source code merge conflicts?
**\<hyc>** or something else moneromooo?
**\<moneromooo>** Like, my cold wallet tx patch is now based on rct code.
**\<moneromooo>** Yes, git conflicts.
**\<fluffypony>** I don't have a problem with RCT being merged before the point release
**\<luigi1112>** fluffypony: that's fine :-) anyone else
**\<dEBRUYNE>** \<luigi1112> (Does someone know the state of pools?) <= I can check headers
**\<fluffypony>** tewinget: what's the status on 0MQ?
**\<luigi1112>** I guess minor version and the block reward are good things to check
**\<fluffypony>** maybe we should push for that in the point release if it's nearly done
**\<luigi1112>** (Being denominated)
**\<dEBRUYNE>** Btw fluffypony, in case tewinget isn't here
**\<luigi1112>** Th at can probably be done in the interim between Sept and march?
**\<dEBRUYNE>** This is from the logs:
**\<dEBRUYNE>** **\<tewinget>** I'm a few hours of work (I hope) away from having the wallet using zmq to talk to the daemon
**\<moneromooo>** He said he was starting work on getting the wallet to talk 0MQ yesterday (he'd been using python client with the daemon).
**\<fluffypony>** ok
**\<dEBRUYNE>** luigi1112: minor\_version should be 3 right?
**\<hyc>** yes, tewinget was asking for reviews of his branch too
**\<moneromooo>** I guess I should go look ^\_^
**\<dEBRUYNE>** anyway, minergate is on "major\_version":2,"minor\_version":3
**\<dEBRUYNE>** For anyone interested, the 0MQ branch can be found here -> https://github.com/tewinget/bitmonero/tree/zmq-dev
**\<dEBRUYNE>** moneromooo, fluffypony, luigi1112: This is Minergate's coinbase transaction -> http://moneroblocks.info/tx/8a6f45c079da5e400632c29e6b8145fda593a44657881d6d91b232769511c8fc
**\<fluffypony>** ok
**\<dEBRUYNE>** Are there any additional meeting items?
**\<hyc>** quick update on 32-bit support - my blockchain\_import is still running :P
**\<fluffypony>** lol
**\<luigi1112>** dEBRUYNE: what about other pools?
**\<dEBRUYNE>** lemme check
**\<fluffypony>** re: the RCT PR, I think we should aim to finish up review and merge by next weekend - any objection, moneromooo ?
**\<moneromooo>** That'd be pretty fast.
**\<moneromooo>** If you can find enough reviewers by then :)
**\<fluffypony>** there will be more review post that
**\<fluffypony>** oh btw moneromooo
**\<fluffypony>** what are your thoughts on the testnet fork dates?
**\<moneromooo>** I should add: along with the rct stuff, that branch has random fixes that would otherwise conflict: better output selection, no signatures stored in wallet, fixes to avoid having to run rescan\_spent (I think I got them all).
**\<moneromooo>** I think a few days after all preliminary review + fixes are done. Then 1 day between 3 and 4, and a few days between 4 and 5 (where both tx versions are allowed).
**\<hyc>** moneromooo: as long as those are each in their own commits, we can still tick them off 1 by 1
**\<moneromooo>** They are, yes.
**\<fluffypony>** moneromooo: so then once merged, say next weekend, we can PR testnet fork points
**\<moneromooo>** Yes.
**\<JjegrUseinob>** i never saw clear answer to artic mine question about when min mixin of 4 will be enforced
**\<moneromooo>** No change there for now, but there should be.
**\<hyc>** can we do it this Sept HF?
**\<JjegrUseinob>** thank you moo and hyc. your hard work is appreciated
**\<dEBRUYNE>** luigi1112: All pools listed here -> https://monerohash.com/#network have "major\_version":2,"minor\_version":3
**\<fluffypony>** ok
**\<fluffypony>** I think that's about it then - code review time
**\<moneromooo>** \<hyc> can we do it this Sept HF?
**\<moneromooo>** (about bumping the network minimum mixin)
**\<hyc>** right
**\<DaveyJones>** so is there a way some chosen folks can put items into an agenda for dev-meeting... just in case fluffy or anyone else dont have time to lead the meeting
**\<moneromooo>** You can always ask something dev related if you wish.
**\<DaveyJones>** so people like debruyne could atleast try to take the host
**\<moneromooo>** It doesn't need to be made known in advance (unless it requires research)
**\<hyc>** mebbe propose agenda items on forum.getmonero.org or something
**\<ArticMine>** Having an agenda ahead of time can be helpful. It does not need to be cast in stone.
**\<JjegrUseinob>** anonimal usually has kovri meeting agenda in advance. i like that system
**\<DaveyJones>** i mean this was the first real dev meeting for a month or sth and even today we had a eating hiccup :p
**\<JjegrUseinob>** when will log from last meeting be on the website?
**\<fluffypony>** lol DaveyJones
**\<fluffypony>** JjegrUseinob: sometime next week, once dEBRUYNE has a chance
**\<JjegrUseinob>** https://getmonero.org/blog/tags/dev%20diaries
**\<JjegrUseinob>** i said last meeting
**\<JjegrUseinob>** pr was merged already
**\<JjegrUseinob>** https://github.com/monero-project/monero-site/pull/135
* hellocccc has quit (Ping timeout: 264 seconds)
**\<fluffypony>** JjegrUseinob: there are issues that have to be fixed
**\<fluffypony>** eg.
* fluffypony Missing key: menu.stackexchange
* fluffypony Liquid Exception: exit in \_layouts/default.html
**\<fluffypony>** so I've got to fix those first
**\<dEBRUYNE>** \<fluffypony> JjegrUseinob: sometime next week, once dEBRUYNE has a chance <= I'll PR the logs tomorrow
**\<fluffypony>** planning on doing it tonight
**\<dEBRUYNE>** (today's)
**\<JjegrUseinob>** ok ty
**\<dEBRUYNE>** Anyway, perhaps we should put a bit of thought into whether we want to activate Ring CT in march (and thus on a scheduled date) or activate earlier on a "random" date
**\<hyc>** not sure there's a reason to break the schedule
**\<hyc>** ?
**\<JjegrUseinob>** competition from zcash seems like a good reason IF rct is ready to activate and tested enough
**\<moneromooo>** I just realized it reads like Z(ooko)Cash.
**\<DaveyJones>** that was intented i guess :p
**\<ArticMine>** I am with staying on schedule with RingCT in March.
**\<luigi1112>** I think rushing because "competition" is I'll advised here
**\<luigi1112>** Ill
**\<grimpants>** yes
**\<hyc>** agreed
**\<ArticMine>** Very ill advised
**\<moneromooo>** The thing I'd move if we could is the september one, to a bit later, but that might break non-updaters...
**\<moneromooo>** As we need to have a binary a couple weeks before, in order for most to update in time.
**\<luigi1112>** I don't think we should enforce mix 4 here since it's not in existing code
**\<dEBRUYNE>** It's good to hear thoughts from everyone on this subject
**\<luigi1112>** It'd be a rush release
**\<ArticMine>** Then min mix 4 is scheduled for March?
**\<DaveyJones>** question is ... are non updaters an issue atm? i mean we are still small and in a small community people should be able to update once in 6 months ?
**\<luigi1112>** Mix 4 goes well with rct
**\<luigi1112>** I'm not sure it needs to be enforced until v1 is disallowed
**\<ArticMine>** So let us make it for march
**\<luigi1112>** That's not till 1 year from now by current rhoughts
**\<moneromooo>** That'd be september, for v1 to be disallowed.
**\<gingeropolous>** someone mentioned that moving the HF date up would, in general, be good for those that need truly private currency. But I also see the benefit of sticking to schedule
**\<moneromooo>** Well, stuff like the new coin selection will be active as soon as it's merged, since it's wallet behavior. So there'll be some betterment already.
**\<moneromooo>** And transfer maps to transfer\_new, too. So no more shitty dust for multi-tx.
**\<gingeropolous>** i wanted to try and get into that code for the "find set that matches" behavior... someday.
**\<JjegrUseinob>** why cant we point release those improvements soon then and have ringct fork late oct or nov?
**\<JjegrUseinob>** for march enforcement
**\<moneromooo>** It's a difficult problem to find the best set.
**\<nioc>** It had been mentioned previously that in the early stages the HF schedule could be adjusted considering the important changes that need to be implemented.
**\<moneromooo>** I don't think it's particularly important to keep to the march date, since I doubt many people will bang on testnet once a new release is out, so it'd just wait there.
**\<moneromooo>** I mean, more time would not mean more testing.
**\<gingeropolous>** \<JjegrUseinob> why cant we point release those improvements soon then and have ringct fork late oct or nov? - well, the arguments against this is that we're setting precedent for non-scheduled, at-whim, as-needed forking, and if we're trying to create a culture of "forking is ok", then the schedule has a particular... weight to it, perhaps
**\<hyc>** hardforks good, more is better :P
**\<JjegrUseinob>** i thought that monero had a social contract that largely supported flexibility this year for rct fork
**\<gingeropolous>** but im on the fence as well... I still think we're small enough of a thing that we could pull it off
**\<dEBRUYNE>** It was discussed before that if we would deviate from the schedule, we would only deviate once for RCT
**\<fluffypony>** Monero Classic is going to have weekly hard forks
**\<moneromooo>** Yes. Hardforks every two months, maybe many of them not actiually changing anything... would allow easy scheduling of changes without havinhg to wait forecer.
**\<fluffypony>** :-P
**\<fluffypony>** JjegrUseinob is right though
**\<gingeropolous>** autoupdate all the things. moo's favorite
**\<fluffypony>** we did say that we might adjust them at the beginning, and that we'd taper down to annual hard forks (or further apart) later on
**\<DaveyJones>** can we have replay attacks too? for classic
**\<fluffypony>** so if testnet is successful and everything is fine we can consider moving itup
**\<fluffypony>** \*it up
**\<JjegrUseinob>** :
**\<JjegrUseinob>** :)
**\<hyc>** ok, that sounds fine. when we're happy with the code integrity and test phase
**\<gingeropolous>** im down with that. Fork early, fork often
**\<moneromooo>** And bump mixin at this one ? Or the one after it ?
**\<DaveyJones>** monero is a flexible adolescent... we will stiffen by time :p
**\<dEBRUYNE>** \<fluffypony> so if testnet is successful and everything is fine we can consider moving itup <= I'd be fine with that too
**\<dEBRUYNE>** let's make sure miners have enough time to update and receive notification
**\<fluffypony>** moneromooo: bump mixin at Sept hardfork
**\<dEBRUYNE>** so 1-2 months after the full "process"
**\<fluffypony>** mixin will bump anyway for rct right
**\<moneromooo>** So HF 5 ? Which might not be september if we being march forward.
**\<moneromooo>** Min mixin was not touched in the rct banch.
**\<fluffypony>** oh
**\<fluffypony>** we're going to have to bump it for definite
**\<luigi1112>** Don't bumb for September imo
**\<luigi1112>** Bump
**\<luigi1112>** It's too soon
**\<hyc>** I suppose it ought to run on testnet first
**\<moneromooo>** So 4, in HF 4 (with rct enable) ?
**\<luigi1112>** This september
**\<luigi1112>** I vote for next September but I'm somewhat ambivalent vs march
**\<ArticMine>** Is there a reason for Sept 2017 vs March 2017 for enforcing mixin 4?
**\<luigi1112>** Yes, it is better with ringct
**\<luigi1112>** Which will be enforced then
**\<moneromooo>** Oh, and the size increase as a function of mixin is rather shallow. So we can go wild.
**\<hyc>** it seems to me min mixin 4 is a good thing regardless of rct. why wait
**\<luigi1112>** It adds forced "junk data" for 6 months...but not a large deal most likely
**\<moneromooo>** It's not junk, it's lovely privacy preserving data :P
**\<moneromooo>** Or we can do 3 in march, 4 in september :)
**\<ArticMine>** So an additional TX size issue for six months that is solved with RingCT
**\<moneromooo>** rct txes will be larger.
**\<moneromooo>** About 13 kB I think. A lot more constant than current.
**\<ArticMine>** But there is a tradeoff in the need to mix the inputs broken down in powers of 10
**\<moneromooo>** Ah, you mean to get a "privacy equivalence" ?
**\<ArticMine>** Yes
**\<moneromooo>** The new coin selection should help there too I think.
**\<hyc>** we should be winding up and letting the kovri mtg start
**\<hyc>** do we have any decisions on bumping mixin?
**\<moneromooo>** anonimal left, no kovri meeting.
**\<hyc>** ok
**\<moneromooo>** I guess I'll do mixin 4 for HF 5 then, unless new stuff gets said.
**\<ArticMine>** Sounds fine to me
**\<hyc>** ok
**\<moneromooo>** As an incentive for reviewers to review, my cold wallet signing patch is now based on the ringct branch, so it can't be merged without rct being merged first ^\_^
**\<JjegrUseinob>** cold wallet signing patch will be a great feature. thanks mooooo
**\<fluffypony>** ok I fixed the stuff that was breaking on the site
**\<tewinget>** fluffypony: what dEBRUYNE said.
**\<tewinget>** I totally forgot there was a dev meeting and slept right through it, woops.
**\<moneromooo>** You can still tell us how far you are, most people are still in the channel :)
**\<othe>** better than me, i thought i am in this channel...but i wasn´t
**\<tewinget>** Well, there's 5-10 daemon RPC commands yet to implement, but I'm leaving them for now because they're mining/miner related. Next thing to do (hopefully yet today) is some first pass at "libdaemonrpc" and making the wallet use it.
**\<othe>** does ur todo list include authentication too? the current way is kinda bah
**\<tewinget>** othe: yes, but that will be something to look at after the rest is sorted, I think.
**\<othe>** good
**\<moneromooo>** Oh, that reminds me.
**\<moneromooo>** The previous 0mq branch had something called net\_skeleton, which was doing some middle layer ntworking stuff, but was GPL so needed replacing.
**\<moneromooo>** Have you found a replacement ? Kovri uses cpp-netlib, and I was thinking using the same would be good if it fits, since more people would know, etc.
**\<tewinget>** I'm just using zmq...
**\<tewinget>** idk what he (oranjuice, I think?) was using net\_skeleton for.
**\<moneromooo>** Yes, that was him/her. And I dunno either :)
**\<othe>** i only know that theirs a license issue with that anyway
**\<othe>** nvm...
**\<othe>** didnt we want to replace epee with net skeleton?
**\<tewinget>** othe: good question, to which I haven't an answer.
**\<gingeropolous>** be sweet to get a graphical version of whatever was decided re: HF and rule versions today
**\<gingeropolous>** i.e., timeline
**\<gingeropolous>** cause again, the lack of harmony with all these version numbers is confusing
**\<fluffypony>** oh
**\<fluffypony>** tewinget / moneromooo
**\<fluffypony>** net\_skeleton had nothing to do with 0MQ
**\<fluffypony>** once 0MQ is in we still have to offer a JSON RPC API, right
**\<fluffypony>** and that has to be able to provide TLS and simple auth
**\<tewinget>** \<fluffypony> once 0MQ is in we still have to offer a JSON RPC API, right <-- err...about that
**\<fluffypony>** so we'd have a new helper app for JSON RPC API
**\<fluffypony>** tewinget: it's in the spec
**\<tewinget>** the zmq implementation thus far \*is* a json rpc
**\<fluffypony>** no
**\<fluffypony>** JSON RPC API is a standard
**\<tewinget>** oh, right, that
**\<fluffypony>** http://json-rpc.org
**\<tewinget>** I mean, I've got it nearly identical to that standard, so it wouldn't take much doing to change it to exactly that
**\<fluffypony>** you're just serialising data in JSON
**\<tewinget>** test\_str = {
**\<tewinget>** "request": "get\_blocks\_fast",
**\<tewinget>** "version": 1,
**\<tewinget>** "message": {
**\<tewinget>** "block\_ids": ["418015bb9ae982a1975da7d79277c2705727a56894ba0fb246adaabb1f4632e3"],
**\<tewinget>** "start\_height": 10
**\<fluffypony>** the HTTP-based JSON RPC API is familiar to integrators
**\<tewinget>** }
**\<tewinget>** }
**\<tewinget>** that's pretty close to the standard
**\<fluffypony>** so we have to provide that layer
**\<tewinget>** I'll just have to change it a little
**\<tewinget>** oh, you mean http-based
**\<fluffypony>** yes
**\<fluffypony>** that's what net\_skeleton was doing
**\<tewinget>** which spec do you mean, 1.0 or 2.0?
**\<tewinget>** because 1.0 mentions HTTP, but doesn't specify that it's necessary as part of the spec, if I'm reading it correctly. :P
**\<tewinget>** that said, HTTP makes sense I suppose, just will take a bit of doing.
**\<fluffypony>** it's transport agnostic, but every single client library supports HTTP and no other transports, lol
**\<fluffypony>** ok but back up a second
**\<fluffypony>** don't go running ahead and changing things just yet
**\<tewinget>** wasn't planning to
**\<fluffypony>** if I'm a client application talking 0MQ to the daemon I need to have some optional authentication, which 0MQ provides support for
**\<fluffypony>** I'd only use that if I'm talking remotely to the daemon
**\<tewinget>** with you so far
**\<fluffypony>** same goes for encryption - not necessary on localhost
**\<fluffypony>** so then we have this little stub applications, let's call them monero-rpc-daemon and monero-rpc-wallet
**\<fluffypony>** they have an HTTP server
**\<fluffypony>** and they talk 0MQ to the daemon
**\<tewinget>** even that's slightly overcomplicated I think
**\<tewinget>** just monero-rpc-http as one binary
**\<fluffypony>** yeah that's fine too - as long as wallet-ing is optional
**\<tewinget>** launch it with the correct bind ports and forward ports and it doesn't have to know which type of rpc daemon it's talking to
**\<tewinget>** same binary would work for both wallet rpc and daemon rpc (and others if ever there are any)
**\<fluffypony>** it can't be a dumb client though
**\<tewinget>** right, it'll have to have auth parameters as well
**\<fluffypony>** otherwise you're going dumb client -> rpc-wallet -> daemon
**\<fluffypony>** three binaries
**\<fluffypony>** ie. it has to have local wallet functionality
**\<fluffypony>** that talks to a daemon over 0MQ
**\<fluffypony>** ie. simplewallet gets separated out into cli-wallet and rpc-wallet
**\<fluffypony>** both of which use 0MQ to communicate with the daemon
**\<fluffypony>** and rpc-wallet can provide both HTTP and 0MQ interfaces, at a later stage, but definitely HTTP initially
**\<tewinget>** so you're saying you want to wrap http-speaking into the rpc-wallet binary?
**\<fluffypony>** simplewallet already talks HTTP
**\<fluffypony>** when you put it in RPC mode, I mean
**\<tewinget>** doesn't the daemon already do so as well with the current RPC?
**\<fluffypony>** yes - and we have to support that also to be backwards compatible, but that's another story
**\<tewinget>** you might hate this idea, but bear with me. I was thinking for backwards-compatibility to just leave the old RPC in place until it's completely deprecated, probably with a compile flag that disables compiling it in by default.
**\<tewinget>** not the cleanest solution, granted, but seems pragmatic imo
**\<fluffypony>** I do hate that idea, purely because I want to rip that code out :-P
**\<tewinget>** so what I was thinking is to have the zmq rpc for whatever binary needs it (wallet, daemon, etc) and then have an optional transparent bridge for http (possibly less transparent if using SSL over http is desired)
**\<tewinget>** but having said bridge layer live inside the {daemon,wallet,etc} binary is okay too, I suppose.
**\<fluffypony>** so what happens if I'm a well-designed exchange, and I have the daemon on a different machine to the wallet
**\<fluffypony>** and I want to talk HTTPS to the wallet
**\<tewinget>** HTTPS request -> wallet -> daemon? I'm not sure I understand why you ask.
**\<fluffypony>** yes precisely
**\<tewinget>** or with the bridge as a separate binary, HTTPS request -> bridge -> wallet -> daemon
**\<fluffypony>** the daemon is exposed to the Internet
**\<fluffypony>** it can be attacked
**\<fluffypony>** the wallet is sensitive, so it lives behind the DMZ
**\<tewinget>** okay...
**\<fluffypony>** your second one solves the case as long as I'm happy starting up a bunch of things
**\<fluffypony>** also you'd need rpc-wallet to provide a 0MQ interface
**\<fluffypony>** and then bridge -> wallet talks 0MQ
**\<tewinget>** I intend for it to.
**\<tewinget>** why would the wallet libs *not* have a 0mq interface? Need that anyway for GUIs and shit, right?
**\<tewinget>** err...nvm, dumb question
**\<fluffypony>** 0MQ client != 0MQ interface
**\<tewinget>** yea, I was thinking the wallet would run and a GUI would connect to it via 0mq, but the GUI can just use libwallet directly.
**\<fluffypony>** yes
**\<tewinget>** that having been said, at some point off in the future I might look into using 0mq's intra-process stuff for message passing.
**\<tewinget>** but that's a long time in the future
**\<fluffypony>** yeah
**\<tewinget>** so from a code reuse standpoint, to me it makes more sense to have a bridge binary that speaks HTTP(S) and 0mq, and to have both wallet and daemon speak 0mq.
**\<fluffypony>** yeah agreed
**\<tewinget>** hmm...even that's not necessarily true, it wouldn't be too bad to have both speak both.
**\<tewinget>** or rather have the wallet *just* speak http(s) to the wild, and use libdaemonrpc or w/e to speak 0mq to the daemon
**\<tewinget>** all of the message system I've written for the 0mq so far is transport-agnostic, so that's the good news :)
**\<tewinget>** (as it should be, but I'm just pointing it out for the sake of...well, having pointed it out, I guess)
**\<tewinget>** fluffypony: for what it's worth, libwallet will need to have the same type of messaging system as I've implemented in the daemon, and the zmq-specific stuff is tiny, so if we do decide we do want the wallet to speak 0mq it should be a (relatively) trivial change in the end.
**\<fluffypony>** kk

338
_posts/2016-08-28-logs-for-the-Kovri-dev-meeting-held-on-2016-08-28.md
View File

@ -1,338 +0,0 @@
---
layout: post
title: Logs for the Kovri Dev Meeting Held on 2016-08-28
summary: Brief review of what has been completed since last meeting, Kovri Logo, code & open tickets discussion
tags: [dev diaries, i2p, crypto]
author: dEBRUYNE / fluffypony
---
*August 28th, 2016*
# Logs
**\<fluffypony>** anonimal: all yours
**\<tewinget>** in the meantime, for those not interested (or relevant to) the kovri meeting, anyone wanna help me test the zmq wallet<->daemon interactions?
**\<meeting-bot> [anonimal]** Proposed meeting items:
**\<tewinget>** oh
**\<tewinget>** shit
**\<meeting-bot> [anonimal]** 1. Greetings
**\<meeting-bot> [anonimal]** 2. Brief review of what's been completed since the previous meeting
**\<meeting-bot> [anonimal]** 3. Code + ticket discussion / Q & A
**\<meeting-bot> [anonimal]** 4. Discuss #282
**\<meeting-bot> [anonimal]** 5. Closing #226
**\<meeting-bot> [anonimal]** 6. Closing #105
**\<meeting-bot> [anonimal]** 7. Closing #46
**\<meeting-bot> [anonimal]** 8. Closing #27
**\<meeting-bot> [anonimal]** 9. Any additional meeting items
**\<meeting-bot> [anonimal]** 10. Confirm next meeting date/time
**\<meeting-bot> [anonimal]** btw, twinget, you are \*all\* relevant to the meeting and you \*ALL\* should be interested.
**\<meeting-bot> [anonimal]** Its that kind of attitude that is preventable advancing kovri development within monero.
**\<fluffypony>>** +100
**\<meeting-bot> [anonimal]** 1. Greetings
**\<meeting-bot> [anonimal]** Hi, I'm here.
**\<meeting-bot> [fluffypony]** me three
**\<tewinget>>** anonimal (I'm not relevant in the sense that I have no context, need to learn more about it :))
**\<i2p-relay> {-solmar}>** we need all the help we can get
**\<meeting-bot> [fluffypony]** EinMByte ?
**\<ArticMine>>** I will stay for another 20 min then I have to leave.
**\<meeting-bot> [fluffypony]** tks ArticMine
**\<meeting-bot> [anonimal]** Hi ArticMine.
**\<ArticMine>>** Hi
**\<meeting-bot> [anonimal]** Hi solmar, EinMByte, fluffypony.
**\<meeting-bot> [anonimal]** 2. Brief review of what's been completed since the previous meeting
**\<meeting-bot> [anonimal]** $ git checkout master && git log --pretty=oneline --no-merges --since=2016-07-31 | wc -l
**\<meeting-bot> [anonimal]** 55
**\<meeting-bot> [anonimal]** - Lots of build work
**\<meeting-bot> [anonimal]** - Reinstate FreeBSD build
**\<meeting-bot> [anonimal]** - Reinstate Clang support
**\<meeting-bot> [anonimal]** - New config features
**\<meeting-bot> [anonimal]** - New logging features
**\<meeting-bot> [anonimal]** - Implemented SNI (part of cpp-netlib)
**\<meeting-bot> [anonimal]** I'm doing work in branch fix-305, not detailed here.
**\<meeting-bot> [anonimal]** We have a new member onbard, 'solmar'. guzzi is back with us too.
**\<meeting-bot> [anonimal]** rakhimov is becoming more active, all great.
**\<meeting-bot> [anonimal]** I hope EinMByte's travels have been well and has returned.
**\<meeting-bot> [solmar]** hey all ;)
**\<meeting-bot> [anonimal]** Did I miss anything for point 2.?
**\<fluffypony>** well
**\<fluffypony>** is it worth discussing #325 now?
**\<meeting-bot> [solmar]** the quality assurance document is note worthy but i think you got everything
**\<meeting-bot> [anonimal]** fluffypony: no not yet.
**\<fluffypony>** ok
**\<meeting-bot> [anonimal]** solmar: thanks, good point. Yes solmar and I reworked #58 and introduced it into a tangible guide.
**\<meeting-bot> [anonimal]** Anything on 2. before moving onto 3.?
**\<fluffypony>** nothing more on 2
**\<meeting-bot> [anonimal]** Before 3., did solmar want to formally introduce themself?
**\<meeting-bot> [solmar]** sure i can quickly introduce
**\<meeting-bot> [solmar]** you guys may have seen me kicking around the various monero-related channels in the past few weeks. monero has peaked great interest in me and moving forward will be quite powerful
**\<meeting-bot> [i2p-relay] {-moneromooo}** Welcome :)
**\<meeting-bot> [solmar]** i am switching focus to kovri because of how unmanned the team is but in the next week i would gladly help test ringct code on the testnet
**\<meeting-bot> [fluffypony]** +1
**\<tewinget>** s/peaked/piqued/ <-- fuck English sometimes
**\<meeting-bot> [solmar]** in the meantime i will continue to learn the kovri code to hopefully in the near future begin to make tangible contributions to the code
**\<meeting-bot> [fluffypony]** awesome, everyone should dabble in both
**\<meeting-bot> [solmar]** any interest and help with kovri is greatly appreciated
**\<meeting-bot> [solmar]** i think we can move along to 3. now thanks anominal ;)
**\<meeting-bot> [anonimal]** Alright, thanks solmar.
**\<meeting-bot> [anonimal]** 3. Code + ticket discussion / Q & A
**\<meeting-bot> [anonimal]** I'll open
**\<meeting-bot> [fluffypony]** some of the design decisions in Kovri were influenced by Monero, so no getting away from it, Monero devs ;)
**\<meeting-bot> [anonimal]** Question: WHEN WILL MONERO DEVS START TAKING KOVRI SERIOUSLY?
**\<meeting-bot> [anonimal]** 10 months in now since our november 1st meeting,
**\<meeting-bot> [i2p-relay] {-moneromooo}** Define "taking seriously" ? Send patches ?
**\<tewinget>** anonimal: I take it just as seriously as, say, RingCT, I just haven't had/taken the time to dig into either yet :)
**\<meeting-bot> [anonimal]** As a whole, if I could quantify contributions, I'd say kovri is getting ~5% attention to what bitmonero and ecosystem is getting.
**\<meeting-bot> [anonimal]** moneromooo: anything.
**\<meeting-bot> [i2p-relay] {-moneromooo}** OK, fair enough. A new codebase appearing like that is going to be not so easy to jump back and forth for coders. But I hear your point.
**\<meeting-bot> [i2p-relay] {-moneromooo}** I will try to get into kovri a bit once rct is all done.
**\<meeting-bot> [anonimal]** I understand all the arguments, and I know what sacrifices would need to be made, so I question when and if they will be made.
**\<meeting-bot> [anonimal]** Thanks moneromooo.
**\<meeting-bot> [fluffypony]** the easiest way to get hyc involved it for us to use LMDB for storage of something :-P
**\<meeting-bot> [i2p-relay] {-moneromooo}** (and feel free to remind me of it if I don't :P)
**\<meeting-bot> [i2p-relay] {-moneromooo}** Nah, use liblber for network.
**\<meeting-bot> [anonimal]** fluffypony: this goes for you too, as we'll see with the remaining agenda items.
**\<meeting-bot> [i2p-relay] {-moneromooo}** Make us fast and secure comms!
**\<tewinget>** fluffypony: in the same way as with hyc, the easiest way to get me involved is something needing refactored >\_>
**\<meeting-bot> [anonimal]** Anyone else over there have a response beside moneromooo and tewinget?
**\<meeting-bot> [anonimal]** If not, we should move onto other Q & A.
**\<meeting-bot> [fluffypony]** is this still the ticket discussion part?
**\<meeting-bot> [anonimal]** Point 3.
**\<meeting-bot> [fluffypony]** yes - but I mean ticket discussion is part of Q&A or can I bring up a ticket now?
**\<meeting-bot> [anonimal]** I have library questions I would want to debate with EinMByte but I don't think he's around.
**\<meeting-bot> [anonimal]** Sure but that's least priority at the moment.
**\<meeting-bot> [anonimal]** And should be 9.
**\<meeting-bot> [anonimal]** I'd rather move onto 4. if no one has any questions.
**\<meeting-bot> [fluffypony]** kk
**\<meeting-bot> [anonimal]** 4. Discuss #282
**\<meeting-bot> [fluffypony]** ok so
**\<meeting-bot> [i2p-relay] {-moneromooo}** There was a designer guy asking whether help was wanted. He seemed to be after paid work though.
**\<meeting-bot> [fluffypony]** with the Monero logo we used 99designs
**\<meeting-bot> [i2p-relay] {-moneromooo}** eherdesign in #monero
**\<meeting-bot> [fluffypony]** moneromooo: I looked at his stuff, it wasn't mind-blowing
**\<meeting-bot> [fluffypony]** I'd like to move to use 99designs again
**\<meeting-bot> [fluffypony]** ref: https://99designs.com/logo-design/contests/monero-mro-cryptocurrency-logo-design-contest-382486
**\<meeting-bot> [fluffypony]** I'm happy to put the $500 up for that, and then use the FFS to get it back
**\<meeting-bot> [fluffypony]** unless anyone feel we must go for a higher 99designs reward
**\<othe>** i would also sponsor that
**\<meeting-bot> [i2p-relay] {-moneromooo}** * hopes it won't be some shady looking concept
**\<meeting-bot> [i2p-relay] {-ArticMine}** It worked very well for Monero so I say yeas with the same package
**\<meeting-bot> [i2p-relay] {-ArticMine}** yes
**\<meeting-bot> [solmar]** maidsafe also appears to be having success with 99designs so i think it is a good idea
**\<meeting-bot> [fluffypony]** ok - I'll set that up now - do we have any ideas as to what we want to convey?
**\<meeting-bot> [i2p-relay] {-ArticMine}** Well I have to leave now
**\<meeting-bot> [fluffypony]** do we want it to be inspired by the Monero logo, like the MRL logo is?
**\<meeting-bot> [i2p-relay] {-moneromooo}** The essential qualities of garlic.
**\<meeting-bot> [fluffypony]** (ref: https://lab.getmonero.org/logo.png)
**\<meeting-bot> [i2p-relay] {-moneromooo}** ^ great logo
**\<groeg>** (noob here ...) A podcast I follow have a promo code för 99designs. Interesting?
**\<meeting-bot> [fluffypony]** groeg: yes plz, can you PM it to me?
**\<cjd>** you'll want to pm it to fluffypony, not to the bot
**\<cjd>** he's in this irc
**\<meeting-bot> [i2p-relay] {-moneromooo}** Actually... you could rotate the Monero logo 90% clockwise and arrange colors a bit so it looks like a K. With kind of a hidden M.
**\<groeg>** newbie using IRC, looking up how to pm ...
**\<meeting-bot> [i2p-relay] {-moneromooo}** groeg: /query NICKHERE
**\<meeting-bot> [fluffypony]** thanks groeg, got it
**\<meeting-bot> [solmar]** conveying a "veil"-ish esque style to it could be interesting, since kovri means veil in esperanto afaik
**\<meeting-bot> [i2p-relay] {-moneromooo}** 90 degrees, not %, of course -\_-
**\<meeting-bot> [fluffypony]** solmar that's pretty much what I was thinking, something along the lines of a network, but it's private
**\<meeting-bot> [fluffypony]** or something
**\<meeting-bot> [fluffypony]** doesn't have to be a "veil" in the literal sense
**\<meeting-bot> [solmar]** ya
**\<meeting-bot> [solmar]** i agree
**\<meeting-bot> [solmar]** ya exactly
**\<meeting-bot> [anonimal]** Sorry, unexpected AFK emergency, unavoidable.
**\<meeting-bot> * anonimal** reading
**\<meeting-bot> [anonimal]** moneromooo: cool idea, maybe someone can run with that.
**\<meeting-bot> [fluffypony]** anonimal: the rotated K thing?
**\<meeting-bot> [fluffypony]** I can suggest that in the 99designs description
**\<meeting-bot> [anonimal]** Yeah, but maybe not literally, just an artistic motive I guess.
**\<meeting-bot> [fluffypony]** yeah
**\<meeting-bot> [anonimal]** But also garlic is a good point as solmar pointed out.
**\<meeting-bot> [fluffypony]** isn't garlic very Tor?
**\<meeting-bot> [anonimal]** So a rotated K inside a garlic clove
**\<meeting-bot> [anonimal]** No, they're onion.
**\<meeting-bot> [fluffypony]** oh yes
**\<meeting-bot> [fluffypony]** my bad
**\<meeting-bot> [anonimal]** onion router similar to garlic routing.
**\<meeting-bot> [anonimal]** Meh, its practically the same vegetable.
**\<meeting-bot> [fluffypony]** lo
**\<meeting-bot> [fluffypony]** lol
**\<meeting-bot> [fluffypony]** we should go wild and create spinach routing
**\<meeting-bot> [anonimal]** lol
**\<meeting-bot> [anonimal]** "Kovri provides essential iron and vitamins"
**\<meeting-bot> [fluffypony]** http://paulkieschedesign.com/blog/wp-content/uploads/2011/12/shandong-logo.jpg <- perfect
**\<meeting-bot> [anonimal]** "Eat kovri today"
**\<meeting-bot> [fluffypony]** the name, not the logo
**\<meeting-bot> [fluffypony]** so for a previous April 1 we renamed Monero to DarkFlarb, so I move that for next year April 1 we rename Kovri to Shandong
**\<meeting-bot> [fluffypony]** ShanDong
**\<meeting-bot> [anonimal]** The ShanDong I2P Router project... hmm...
**\<meeting-bot> [anonimal]** fluffypony: how do we keep track of #282?
**\<meeting-bot> [fluffypony]** lol
**\<meeting-bot> [fluffypony]** anonimal: othe and I will set it up and update in-ticket
**\<meeting-bot> [anonimal]** fluffypony: thanks.
**\<meeting-bot> [anonimal]** Anything else on #282?
**\<meeting-bot> [fluffypony]** nada
**\<meeting-bot> [anonimal]** If we use a dog somewhere in there, and Shandong, we should go with a pug.
**\<groeg>** shandong = 山东 = mountain east
**\<meeting-bot> [fluffypony]** TIL
**\<meeting-bot> [anonimal]** The eastside rugged pug.
**\<groeg>** (literal meaning of the characters)
**\<meeting-bot> [fluffypony]** east mountain pugs unite
**\<meeting-bot> * anonimal** see dog flip gang symbol with fingers
**\<meeting-bot> [fluffypony]** DogeI2P
**\<meeting-bot> [anonimal]** Here we go, lol
**\<meeting-bot> [anonimal]** Ok, 5. Closing #226
**\<meeting-bot> [anonimal]** This is useful when: 1) i2p-relay is down 2) slack is not available or people aren't signed up nor want to sign up
**\<meeting-bot> [anonimal]** I've registered the channels and am idling.
**\<meeting-bot> [fluffypony]** ok so
**\<meeting-bot> [fluffypony]** are we happy running this under the core relay and not the community relay?
**\<meeting-bot> [anonimal]** By community you mean the one in #monero/#monero-dev?
**\<meeting-bot> [fluffypony]** the community one is the one that needmoney90 runs, to Slack / Telegram etc.
**\<meeting-bot> [fluffypony]** the core one is i2p-relay
**\<meeting-bot> [fluffypony]** anonimal: is there a #tahoe-lafs on OFTC?
**\<meeting-bot> [fluffypony]** because I don't want to take tahoe-lafs out the relay list, necessarily
**\<meeting-bot> [anonimal]** fluffypony: yes, with 4 people, no channel topic. Doesn't look official.
**\<meeting-bot> [fluffypony]** ok then I'll just relay it, tough for them
**\<meeting-bot> [anonimal]** They will probably enjoy it.
**\<meeting-bot> [fluffypony]** indeed
**\<meeting-bot> [fluffypony]** ok I'll do that right now
**\<meeting-bot> [anonimal]** So this would be for i2p-relay?
**\<meeting-bot> * anonimal** so many relays, so confused
**\<meeting-bot> [fluffypony]** lol
**\<meeting-bot> [i2p-relay] {-moneromooo}** What's #tahoe-lafs relation with kovri btw ?
**\<meeting-bot> [anonimal]** moneromooo: Nothing really aside from an i2p plugin available to use with tahoe-lafs, AFAIK
**\<meeting-bot> [anonimal]** fluffypony: if you're doing it right now, I'll wait.
**\<meeting-bot> [fluffypony]** moneromooo: they asked me to run a relay, as their relay has disappeared
**\<meeting-bot> [anonimal]** Damn, it's been an hour. Do we continue?
**\<meeting-bot> [fluffypony]** yes - we started late
**\<meeting-bot> [i2p-relay] {-moneromooo}** I think it's mostly up to you, the main kovri person.
**\<meeting-bot> * anonimal** didn't want to stop on necessary bitmonero business
**\<meeting-bot> [anonimal]** fluffypony: do you have to restart the relay? Is #226 resolved?
**\<meeting-bot> [fluffypony]** the bouncer is connected
**\<meeting-bot> [fluffypony]** sec
**\<theRelay__> \<fluffypony@OFTC>** testing
**\<fluffypony>** testing back
**\<meeting-bot> [fluffypony]** and from here
**\<meeting-bot> [fluffypony]** meeting-bot might be interfering with it a little, so I'll fiddle with it after I've killed meeting-bot
**\<meeting-bot> [anonimal]** It's only me and the bot on OFTC
**\<meeting-bot> [anonimal]** Is fluffypony@OFTC actually fluffypony@Freenode ?
**\<meeting-bot> [fluffypony]** no I don't know - I need to check if it's relaying between all 3, and can't do that with meeting-bot online
**\<meeting-bot> [fluffypony]** coz meeting bot is also relaying
**\<meeting-bot> [anonimal]** Ok, can we quickly review the remaining items?
**\<meeting-bot> [fluffypony]** sure
**\<meeting-bot> [anonimal]** 6. Closing #105
**\<meeting-bot> [anonimal]** Hmm, tricky.
**\<meeting-bot> [fluffypony]** sorry internet is slow
**\<meeting-bot> [fluffypony]** ok so
**\<meeting-bot> [fluffypony]** the moneroworld instance is up
**\<meeting-bot> [anonimal]** https://social.moneroworld.com went online but admin has not responded to anything in a month
**\<meeting-bot> [fluffypony]** hmmm
**\<meeting-bot> [anonimal]** There were multiple issues, probably still are, that would need to be resolved before we go officially public.
**\<meeting-bot> [fluffypony]** ok then I think leave it open
**\<meeting-bot> [anonimal]** But it's not kovri-related.
**\<meeting-bot> [anonimal]** That's what annoys me. We have a forum post open for it.
**\<meeting-bot> [anonimal]** And there's also that /bitmonero ticket open
**\<meeting-bot> * anonimal** fetches
**\<meeting-bot> [anonimal]** #903
**\<DaveyJones>** gingeropolous aint that your site?
**\<meeting-bot> [fluffypony]** anonimal: do we want a common gnu-social for the two?
**\<meeting-bot> [fluffypony]** or separate?
**\<gingeropolous>** wut?
**\<meeting-bot> [anonimal]** I thought it would be an umbrella instance, more of a 'pro-decentralization' initiative not specific to kovri or bitmonero.
**\<meeting-bot> [i2p-relay] {-moneromooo}** https://social.moneroworld.com <- your site ?
**\<gingeropolous>** oh, DaveyJones , no... i just pay for the domain name and put it on afraid.org so anyone can create subdomains for free
**\<meeting-bot> [anonimal]** I've already signed up for @kovri and @anonimal at quitter.se in case this issue was never resolved.
**\<meeting-bot> [i2p-relay] {-moneromooo}** Oh, that's nice idea.
**\<meeting-bot> [fluffypony]** ok
**\<meeting-bot> [fluffypony]** let's leave it open and prod the guy again
**\<meeting-bot> [fluffypony]** if we hear nothing by next dev meeting we re-host from scratch
**\<meeting-bot> [anonimal]** quitter.se is nice aside from the psychopath/bot with the sickle and hammer avatar that spams the feed like there is no tomorrow.
**\<meeting-bot> [anonimal]** Ok, I'll make a note.
**\<meeting-bot> [anonimal]** 7. Closing #46
**\<meeting-bot> [fluffypony]** I'm moving registrars for all critical domains, including getkovri.org
**\<meeting-bot> [fluffypony]** which is affecting that and the other one
**\<meeting-bot> [fluffypony]** (the increased attention means an increase of people poking at our infrastructure, hence the move)
**\<meeting-bot> [anonimal]** Ah, ok. How is content coming along? Did you get that rough draft finished?
**\<meeting-bot> [fluffypony]** should be done by next meeting, and I'll push the Kovri page to the Monero website in the next week so that we can open it up to the community to work on it
**\<meeting-bot> [fluffypony]** it's in a sub-section of its own
**\<meeting-bot> [fluffypony]** so it can have as much content as required
**\<meeting-bot> [EinMByte]** nice, didn't know we were getting a website
**\<meeting-bot> [anonimal]** Alright, I'll make a note.
**\<meeting-bot> [fluffypony]** EinMByte: I was going to do it in Geocities, but anonimal convinced me not to
**\<meeting-bot> [EinMByte]** (then again, I probably missed a lot)
**\<meeting-bot> [fluffypony]** snow flake mouse cursors are the bomb
**\<meeting-bot> [anonimal]** Yeah, fluffypony has yet to learn the finer points of 90's webdev.
**\<meeting-bot> [fluffypony]** fo sho
**\<meeting-bot> [anonimal]** We're working on that.
**\<meeting-bot> [fluffypony]** Backstreet Boys backgrounds everywhere
**\<meeting-bot> [anonimal]** Once we get a logo, the site should look snazzy.
**\<meeting-bot> [anonimal]** 'Kovri's back, alright!'
**\<meeting-bot> [fluffypony]** hah hah
**\<meeting-bot> [anonimal]** Ok, 8. Closing #27
**\<meeting-bot> [anonimal]** Ah, looks like we've had some activity there lately.
**\<meeting-bot> [anonimal]** Looks like two issues now. So, 1) updates on zoho? 2) should we ever have a mailing list?
**\<meeting-bot> [fluffypony]** can't proceed with Zoho till the domain move is done, but that's basically setup
**\<meeting-bot> [fluffypony]** I don't think mailing lists are necessary
**\<meeting-bot> [fluffypony]** we already have stuff scattered everywhere, another avenue will just make dissipate it more
**\<meeting-bot> [anonimal]** Agreed.
**\<meeting-bot> [EinMByte]** ever ? maybe, now ? no
**\<meeting-bot> [anonimal]** fluffypony: ETA on domain move completion (or did you already say?... /me reads)?
**\<meeting-bot> [fluffypony]** anonimal: by next meeting
**\<meeting-bot> [fluffypony]** if it's done sooner then great
**\<meeting-bot> [anonimal]** Ok, great. Once that's resolved we can resolve the HackerOne issue.
**\<meeting-bot> [anonimal]** Which will be another avenue for more attention.
**\<meeting-bot> [anonimal]** I'll make a note in #27.
**\<meeting-bot> [anonimal]** Anything else on #27?
**\<meeting-bot> [fluffypony]** nope that's it for now
**\<meeting-bot> [anonimal]** 9. Any additional meeting items
**\<meeting-bot> [anonimal]** EinMByte, how goes it?
**\<guzzi>** present fgi
**\<meeting-bot> [anonimal]** Hi guzzi.
**\<meeting-bot> [anonimal]** guzzi: anything you wanted to add to the meeting?
**\<guzzi>** glad to be a back. learning a lot.
**\<meeting-bot> [EinMByte]** anonimal: Hopefully some work on SSU soon
**\<meeting-bot> [anonimal]** EinMByte: I had thoughts and questions on library design if you're around after the meeting
**\<meeting-bot> [EinMByte]** Sure
**\<guzzi>** looking to focus more on kovri since it has the least devs and is more easy to peneatrate into development.
**\<guzzi>** still getting up to speed.
**\<meeting-bot> [anonimal]** EinMByte: nice, I look forward to the day we merge that branch.
**\<meeting-bot> [EinMByte]** guzzi: If you're looking for easy stuff to get used to the code, tests and documentation are very much needed so that might be a good idea
**\<meeting-bot> [anonimal]** guzzi: ok, if you have any questions, feel free to shout out.
**\<meeting-bot> [anonimal]** solmar: ^ what EinMByte said too if interested.
**\<guzzi>** EinMByte, thanks on it.
**\<guzzi>** i will look for todos.
**\<guzzi>** an prs on that
**\<meeting-bot> [anonimal]** fluffypony: you wanted to talk about #325?
**\<meeting-bot> [fluffypony]** oh - not necessarily, it was more to find out if it needed discussion
**\<meeting-bot> [solmar]** i'll check it out thanks ;)
**\<meeting-bot> [anonimal]** fluffypony: I think #325 is more of a 'po-tey-to' 'po-tah-to' kind of issue
**\<meeting-bot> [anonimal]** and a possible solution is 'let's call the whole thing off'.
**\<meeting-bot> [anonimal]** I'll figure itself out.
**\<meeting-bot> [anonimal]** Anything else on 9.? Any more meeting items?
**\<meeting-bot> [anonimal]** With organizational things out of the way, the next meeting can be far more codebase-orieted.
**\<meeting-bot> [anonimal]** *oriented
**\<meeting-bot> [fluffypony]** kk
**\<meeting-bot> [anonimal]** 10. Confirm next meeting date/time
**\<meeting-bot> [fluffypony]** https://99designs.com/logo-design/contests/create-beautiful-logo-kovri-privacy-enhancing-open-source-652257/entries
**\<meeting-bot> [fluffypony]** https://99designs.com/logo-design/contests/create-beautiful-logo-kovri-privacy-enhancing-open-source-652257/brief that thing
**\<meeting-bot> [anonimal]** fluffypony: nice
**\<meeting-bot> [fluffypony]** k next meeting, same time, same place, 2 weeks
**\<meeting-bot> [anonimal]** Where's the 'optional dog' button?
**\<meeting-bot> [fluffypony]** Two Weeks (tm)
**\<meeting-bot> [anonimal]** Do we have to do 2 weeks?
**\<meeting-bot> [fluffypony]** you want to do longer?
**\<meeting-bot> [fluffypony]** or shorter?
**\<meeting-bot> [anonimal]** I mean, I guess it depends on who is involved. If it's the usual, then I'd say 1 month.
**\<meeting-bot> [fluffypony]** guzzi / solmar / EinMByte - thoughts ?
**\<meeting-bot> [EinMByte]** We can discuss some of the more technical things separately
**\<guzzi>** 1 mo fine. i will be on irc for technical things. still playing catch up.
**\<meeting-bot> [fluffypony]** ok
**\<meeting-bot> [fluffypony]** then we do it in 4 weeks, same time as the meeting after next Monero dev meeting?
**\<meeting-bot> [solmar]** 1 month is fine
**\<meeting-bot> [solmar]** i'll be around as often as i can
**\<meeting-bot> [anonimal]** Same time is fine with me.
**\<meeting-bot> [fluffypony]** thankyouverymuch!
**\<meeting-bot> [anonimal]** Ok, thanks everyone.
**\<meeting-bot> [fluffypony]** can I kill meeting-bot?
**\<meeting-bot> [anonimal]** fluffypony: swift and painless if possible.
**\<meeting-bot> [anonimal]** She need not suffer.

243
_posts/2016-08-28-overview-and-logs-for-the-dev-meeting-held-on-2016-08-28.md
View File

@ -1,243 +0,0 @@
---
layout: post
title: Overview and Logs for the Dev Meeting Held on 2016-08-28
summary: Trezor and other hardware wallets for Monero, brief update on 0MQ and the official GUI, hardfork schedule
tags: [dev diaries, core, crypto, 0mq]
author: dEBRUYNE / fluffypony
---
*August 28th, 2016*
# Overview
An overview [can be found on Hello Monero](https://hellomonero.com/article/monero-bi-weekly-dev-meeting-note-highlights-2016-08-28)
# Logs
**\<hyc>** ding ding ding
**\<fluffypony>** hello meeting-bot!
**\<meeting-bot> [fluffypony]** hello from the other side!
**\<fluffypony>** ok we're on
**\<fluffypony>** ArticMine / luigi1111w / othe / smooth / hyc / moneromooo / tewinget / redfish / NoodleDoodle / anyoen I forgot
**\<moneromooo>** There's an article about fraud in crypto on the bytecoin blog. Chutzpah, got to admit.
**\<fluffypony>** welcome to the annual "Devs who Drink whilst Developing" meeting
**\<fluffypony>** moneromooo: brave of them
**\<hyc>** lol. I'm on cider today
**\<fluffypony>** ok so
**\<fluffypony>** in today's news
**\<fluffypony>** nothing happened with the Monero price
**\<fluffypony>** and so we focus on dev
**\<hyc>** lol
**\<fluffypony>** let's start with a quick check of open PRs
**\<fluffypony>** except for RingCT which we'll get to
**\<fluffypony>** redfish: how goes the CMake stuff?
**\<NoodleDoodle>** I alive today.
**\<moneromooo>** hey :)
**\<fluffypony>** and a warm welcome to our special guest, NoodleDoodle
**\<fluffypony>** :-P
**\<fluffypony>** whilst we wait for the redfishes
**\<fluffypony>** NoodleDoodle: do you want to talk about Trezor at all?
**\<fluffypony>** ok good chat
**\<hyc>** heh
**\<fluffypony>** :-P
**\<NoodleDoodle>** Sure :P
**\<fluffypony>** yay, take it away
**\<hyc>** redfish doesn't appear to be answering either
**\<NoodleDoodle>** I'm about 1296 behind in commits. Rebasing is pretty much out of the question. Have to manually merge then release.
**\<fluffypony>** NoodleDoodle: do you want any help with that?
**\<NoodleDoodle>** The trezor firmware itself should be easier, except it's split into 5 or 6 repos
**\<fluffypony>** ok cool
**\<NoodleDoodle>** I should be able to do it.
**\<fluffypony>** NoodleDoodle: do you want us to host it on the monero-project Github in its own repo, obvs giving you collab access, to make it more "formal" and part of the core project?
**\<tewinget>** late, but here
**\<NoodleDoodle>** Sure, anything. I actually started on keepkey awhile back as well, although it's not as complete as trezor.
**\<fluffypony>** ok cool
**\<fluffypony>** I've been fiddling with Ledger Blue, as I have the Blue and the Nano S
**\<fluffypony>** I have a feeling they'll be a cinch after Trezor / Keepkey
**\<fluffypony>** and, hopefully, we can PR it in to be part of the default firmware on these devices
**\<fluffypony>** if they'll have us
**\<fluffypony>** ok so next up
**\<fluffypony>** hyc has a small PR to ease up our LMDB speed after you're caught up with the network
**\<fluffypony>** which should lead to an even more robust blockchain DB, not that I've had anything resembling a corruption in ages
**\<fluffypony>** and I kill daemons like I'm playing Doom
**\<fluffypony>** tewinget, would you like to update us on 0MQ plx?
**\<tewinget>** sure
**\<tewinget>** so far, all of the daemon RPC calls pertaining to the wallet are good to go, as well as several others
**\<tewinget>** the wallet is good to go for using the new daemon rpc library
**\<tewinget>** oh, the new daemon rpc has a library, rather than just calling out to networking things directly. >\*\*\_>\*\*
**\<tewinget>** (I only got ~1 hr sleep, minor rambling will happen)
**\<fluffypony>** tewinget: do you think it's PR-able now, and then subsequent updates to follow, or is it still too fast-and-loose to be used in "production"?
**\<tewinget>** let's see...next things I need to do are basically polish: make command line flags / parametrize port bind options, and so on. Documentation (both code and RPC spec)
**\<tewinget>** well, as of right now because of how cryptocurrencies work, if it cocks up it'll just...fail? As in, not in a destructive, send all coins to the void way, but in a boring "the tx failed to go to the daemon" or w/e way
**\<tewinget>** that said, I should probably put a bit more time into polish with command line flags and such first, as it currently has hard-coded binding and so on, and I need to doc the API
**\<fluffypony>** ok because that brings us on to the next topic
**\<hyc>** the PR I've submitted actually only changes the default db mode at startup. we didn't quite figure out how to adjust it after sync finished
**\<tewinget>** afaik (as in, if I've done it right) it's JSON-RPC compliant as well, apart from the http layer
**\<fluffypony>** and tewinget maybe you can think about it in this context
**\<fluffypony>** the RingCT PR is now post-review, at least by me, with multiple others having reviewed parts of it
**\<fluffypony>** so it's merge time
**\<fluffypony>** we haven't set fork heights yet
**\<moneromooo>** Wait till I signed commits first.
**\<fluffypony>** moneromooo: yes
**\<fluffypony>** but basically the idea is to run through the testnet forks next week
**\<fluffypony>** which means testnet will do the equivalent of September *and* March 2017 forks
**\<fluffypony>** in one week
**\<fluffypony>** testnet will then have RingCT live
**\<fluffypony>** and we'll be able to focus on efficiency improvements, further testing, and so on
**\<fluffypony>** in the meantime, it will let us code freeze sometime into September
**\<fluffypony>** a little later than we'd have liked, but a necessity to get RingCT in to this freeze instead of only in March
**\<fluffypony>** now here's the nice thing
**\<fluffypony>** old daemons only know about the fork in September, and will only start nagging about that one
**\<fluffypony>** so we can set the subsequent fork to something earlier than March
**\<fluffypony>** but we'd have to make that decision by the next dev meeting pretty much at the latest
**\<fluffypony>** which means
**\<fluffypony>** next week Tue / Wed or so we'll push out binaries for 0.10-beta
**\<fluffypony>** 0.10 will be called Wolfram Warptangent, in honour of the Monero contributor that passed away
**\<tewinget>** well the 6-month window is a "no earlier than", but at the same time since it's basically just miners doing the voting, idk how doing it earlier pans out.
**\* tewinget** approves the name.
**\<ArticMine>** Does that include the GUI?
**\<fluffypony>** ArticMine: no, this is core only
**\<tewinget>** ArticMine: We can tag a release with GUI at any time, no forking and such
**\<tewinget>** same with ZMQ
**\<fluffypony>** but it includes the GUI lib changes that are needed
**\<fluffypony>** so anyone compiling the GUI will have working beta bins to play with
**\<fluffypony>** so I'd please like commitments from as many people as possible to participate in testnet next week
**\* moneromooo** commits fluffypony
**\<fluffypony>** lol
**\* tewinget** rejects the unsigned commit
**\* iDunk** sees travis ci build fail
**\<fluffypony>** git commit -S -am "loony bin"
**\<moneromooo>** OK. I'll put in a Pedersen commitment to... something.
**\<moneromooo>** When do we set the forks then ?
**\<tewinget>** at dinner?
**\* fluffypony** giggles
**\<moneromooo>** For v3, ok. v4 (rct) on monday lunchtime.
**\<fluffypony>** moneromooo: for testnet?
**\<moneromooo>** Obviously :P
**\<moneromooo>** And v5 (rct only) on tuesday.
**\<fluffypony>** you mean Monday tomorrow, or Monday next week?
**\<moneromooo>** Fine ?
**\<moneromooo>** Tomorrow.
**\<fluffypony>** hmmm
**\<moneromooo>** Too fast ?
**\<fluffypony>** yes actually good idea - the actual fork process has been tested on private testnet, and in the previous fork
**\<fluffypony>** so we push bins out after the fork
**\<fluffypony>** then people can play without needing to fiddle
**\<gingeropolous>** and this is still a no-vote fork?
**\<moneromooo>** Yes. Screw votes, they were coded by an idiot.
**\<fluffypony>** LOL!
**\<fluffypony>** gingeropolous: yeah - we can re-address that in the next 6-12 months, but at the moment it's move-it-or-lose-it
**\<gingeropolous>** yeah absolutely
**\<fluffypony>** also the schedule is pretty widely known, except for ShapeShift who we'll email and then they'll claim they have no knowledge of the update
**\<tewinget>** gingeropolous: plus it's technically never a no-vote fork, as if the miners get pissed off and don't want it, well, they just won't. >\*\*\_>\*\*
**\<gingeropolous>** lol fluffypony
**\<fluffypony>** ok so moneromooo, your fork points are fine
**\<moneromooo>** So will you merge the PR then build off that, or build off my branch ?
**\<moneromooo>** (for the test builds)
**\<fluffypony>** no, merge
**\<moneromooo>** OK
**\<fluffypony>** people must be able to build head on their boxes if they want
**\<moneromooo>** (oh, the supreme importance of punctuation)
**\* gingeropolous** hides
**\<fluffypony>** lol
**\<fluffypony>** ok
**\<fluffypony>** I think that's it from my side
**\<fluffypony>** does anyone have any questions or thoughts or anything?
**\<gingeropolous>** im still not super clear on the fork schedule.... but it could be sleep dep
**\<gingeropolous>** for mainnet
**\<fluffypony>** for mainnet it's still the September v3 fork, as expected
**\<fluffypony>** if we want we can have the v4 and v5 forks at any point after that, even though March would be the "expected" date
**\<hyc>** iDunk: build log shows no errors, just too slow to build
**\<tewinget>** I have a few questions, but I'll wait for others' for a few minutes first.
**\<hyc>** testnet sched sounds good
**\<hyc>** 0.10-beta sounds fine
**\<iDunk>** hyc: was a joke
**\<hyc>** iDunk: but it's unfortunately true :P
**\<fluffypony>** so even though we wouldn't normally push a fork forward, we have to consider the influx of new users, and maybe we feel that the added privacy is essential enough to do v4 end of Oct, v5 in Dec
**\<fluffypony>** something like that
**\<gingeropolous>** gotcha.
**\<fluffypony>** so we start 2017 with RingCT as the only way to transact
**\<gingeropolous>** is there a place where the fork plan /etc is laid out?
**\<gingeropolous>** maybe the readme of the github is a good home
**\<fluffypony>** gingeropolous: this one, or generally?
**\<gingeropolous>** generally
**\<gingeropolous>** and this one
**\<fluffypony>** generally, the Monero Forum post + all other posts that talk about the mandatory hard forks
**\<tewinget>** gingeropolous: plans are probably in /usr/share/doc, not in /etc
**\<fluffypony>** I agree that the Readme shoudl include it
**\<hyc>** seems to me like we have a lot of profiling and tuning to do before ringCT will play for real
**\<hyc>** october might be too soon
**\<gingeropolous>** its gonna be a helluva fall
**\<fluffypony>** this one is dev meeting specific, we'll have a summary post after that and solicit feedback from the non-dev community
**\<fluffypony>** hyc: we do have new contributors, so we might be able to get through the tuning stuff faster
**\<hyc>** cool
**\<fluffypony>** I'm no fan of pushing it too hard, because it means I have to get MyMonero working with RingCT, but it's doable
**\<gingeropolous>** yeah, I know there's the forum posts.. but considering fork early, fork often is kind of our thing, it should / could be ... more prominent
**\<gingeropolous>** ah screw it. time to by moneroforks.whatever
**\<fluffypony>** gingeropolous: do you want to PR a change to the readme?
**\<fluffypony>** it'll take you from troll-dev status to readme-dev
**\<fluffypony>** :-P
**\<gingeropolous>** :)
**\<fluffypony>** ok tewinget
**\<fluffypony>** before we run out of time
**\<fluffypony>** ask away
**\<tewinget>** ok
**\<tewinget>** so for one thing, I haven't seen a GUI progress update today, figured I'd ask if we have a tentative timeline?
**\<fluffypony>** othe: any thoughts?
**\<fluffypony>** ^^
**\<othe>** sorry was busy drinking
**\<othe>** yeah so ilya is traveling but back next week, we hope to fix all small reamaining issues till the week after
**\<fluffypony>** ok
**\<othe>** and then we can release a beta
**\<tewinget>** awesome
**\<othe>** together with a new tagged rls
**\<fluffypony>** othe is there any way he can stop submitting huge PRs
**\<othe>** and then whats following is mostly advanced settings and stuff like that
**\<fluffypony>** it's killing it for other potential contributors
**\<othe>** yeah i can tell him
**\<tewinget>** if there's desire for it and nobody else takes up the task, I may sign up to do a plugin system (unless that's already in place?)
**\<fluffypony>** he needs to PR on a feature / fix by feature basis
**\<othe>** oh thats not in the place but something that would be cool to have tewinget
**\<hyc>** yeah, narrow scope PRs
**\<fluffypony>** yeah definitely, hyc
**\<moneromooo>** And move the twitter stuff in there, just to be sure.
**\<fluffypony>** OH!
**\<fluffypony>** before I forget
**\<fluffypony>** the big thing I wanted to discuss
**\<fluffypony>** https://github.com/monero-project/bitmonero/issues/80
**\<fluffypony>** that's going to happen before the bins are pushed
**\<fluffypony>** so if anyone has any final thoughts on that, you'd best comment on the issue, else suck it up later :-P
**\<fluffypony>** I'd also like us to start refactoring the parts that have CryptoNote in the name to be Monero instead
**\<tewinget>** something something \`sed\`
**\<fluffypony>** as RingCT + several thousand commits puts us quite far beyond the reference protocol
**\<moneromooo>** Renaming things for the fun of it ? I'd rather not.
**\<moneromooo>** (in the code, I mean. I'm ok with the binaries thing)
**\<tewinget>** btw fluffypony, I \*think\* that the zmq-dev branch is PR-ready, but I'm not comfortable making that call without some testing, so if anyone would like to give it a go (testnet and mainnet are affected identically, so testnet is 100% fine for, well, testing)
**\<ArticMine>** It simple reflects the reality of how much the code has changed from the original Cryptonote implementation
**\<tewinget>** as I said before, I'd like to polish it up a bit first, but that's not a blocking issue for PR-ing
**\<fluffypony>** tewinget: if you're of the opinion it can go into a mid-Sept code freeze / release then sure, else leave it till after the release because it's not HF worthy
**\<fluffypony>** your call
**\<tewinget>** I'm reluctantly okay with doing merges on my end before a PR, so it can wait, just figured I'd give the option. Testing would still be great though...I need to sync the testnet chain on my VPS but then I'll badger you for some testnet moneyz
**\<tewinget>** I'll need to discuss with someone(s) how "blocknotify" should work, and perhaps about doing something similar for miners (call it templatenotify if you like)
**\<fluffypony>** oh that could be interesting
**\<fluffypony>** the templatenotify I mean
**\<hyc>** yeah templatenotify would make an immediate difference for miners
**\<tewinget>** yea, I'm thinking a configurable parameter that is like "if there is 20% more value to be had via tx fees by changing the block template, notify the miner to update its block template with the new transactions included"
**\<tewinget>** plus the obvious implications of changing when a new block is learned about
**\<hyc>** right
**\<tewinget>** but that can be done with the blocknotify that the wallet wants anyway
**\<gingeropolous>** ooh we talkin dynamic fees?
**\<tewinget>** at any rate, that's a design discussion for another time.
**\<fluffypony>** tewinget: I'd prefer earlier PRs
**\<fluffypony>** I mean
**\<tewinget>** fluffypony: yes, yes, I meant for after that PR
**\<fluffypony>** if it's properly borked by mid-September we can revert 0MQ for release
**\<meeting-bot> [anonimal]** 17:06
**\<fluffypony>** tewinget: so what I'm saying is PR soon, plx
**\<fluffypony>** anonimal apologies
**\<fluffypony>** is there anything else or can we call it?
**\<hyc>** think that's good for today
**\<tewinget>** I'd say go nuts for your kovri meeting, we're not going anywhere
**\<fluffypony>** yay, nuts
**\<tewinget>** so if something else comes up, address it after that meeting
**\<fluffypony>** kk

376
_posts/2016-09-11-logs-for-the-Kovri-dev-meeting-held-on-2016-09-11.md
View File

@ -1,376 +0,0 @@
---
layout: post
title: Logs for the Kovri Dev Meeting Held on 2016-09-11
summary: Kovri Logo, code & open tickets discussion
tags: [dev diaries, i2p, crypto]
author: dEBRUYNE / fluffypony
---
*September 11th, 2016*
# Logs
**\<fluffypony>** anonimal: all yours :)
**\<meeting-bot> [anonimal]** 1. Community input for kovri logo https://99designs.com/logo-design/contests/create-beautiful-logo-kovri-privacy-enhancing-open-source-652257/entries
**\<meeting-bot> [anonimal]** 2. Greetings
**\<meeting-bot> [anonimal]** 3. Brief review of what's been completed since the previous meeting
**\<meeting-bot> [anonimal]** 4. Code + ticket discussion / Q & A
**\<meeting-bot> [anonimal]** 5. Any additional meeting items
**\<meeting-bot> [anonimal]** 6. Confirm next meeting date/time
**\<meeting-bot> [anonimal]** Everyone quick, before you leave, give your opinion on the logo!
**\<meeting-bot> [anonimal]** fluffypony: I think we narrowed it down to #239 and #146
**\<meeting-bot> [anonimal]** Maybe others are of interest?
**\<MalMen>** well, I am checking the bitcoin rcp and they use wordwordword, I think i like word_word_word better
**\<fluffypony>** https://99designs.com/logo-design/contests/create-beautiful-logo-kovri-privacy-enhancing-open-source-652257/entries/146
**\<fluffypony>** https://99designs.com/logo-design/contests/create-beautiful-logo-kovri-privacy-enhancing-open-source-652257/entries/239
**\<hyc>** the onion/garlic thing ... I guess it's descriptive, but I can't take it seriously
**\<lurker>** 146
**\<fluffypony>** hyc: it's coz of Garlic Routing
**\<Elli0t>** 88
**\<MalMen>** for example "getthis" would bedificuld to understund with no "get\_this", but i like "getThis" too, I think I got that from javascript
**\<hyc>** yes, I see that, but ...
**\<fluffypony>** MalMen: can you take it to PM with tewinget, or wait till after the Kovri meeting?
**\<tewinget>** MalMen: if you want to discuss that, PM me, otherwise try to wait until the Kovri meeting concludes.
**\<meeting-bot> [anonimal]** MalMen, we are in the kovri meeting. Please wait for monero chat until afterward.
**\<tewinget>** dammit fluffypony
**\<fluffypony>** lol
**\<MalMen>** lo
**\<MalMen>** please continue :D
**\<hyc>** I think the stylized Ks are more preofessional
**\<Kermit_>** As a designer 146 it also brand recognition with xmr
**\<fluffypony>** #146 is more in the spirit of the Monero logo, I'll definitely agree with that
**\<fluffypony>** and yeah, the brand recognition aspect is +1
**\<i2p-relay> {-guzzi}** #239
**\<tooquick_4u>** #146
**\<meeting-bot> [i2p-relay] {-moneromooo}** I kinda like https://images-contests.99static.com/wYofliD7HjSVmkBoYhGS4CyMeNc=/188x0:1464x1276/500x500/top/smart/99designs-contests-attachments/75/75384/attachment\_75384769, the variants of https://images-contests.99static.com/Gs4VClupDwKJEGKvaX7I40TLckg=/0x0:1156x1156/500x500/top/smart/99designs-contests-
**\<meeting-bot>** attachments/75/75381/attachment\_75381142
**\<tewinget>** wait, isn't 99designs basically spec-work?
**\<meeting-bot> [i2p-relay] {-ArticMine}** Kovri logo Do we want a variant of the Monero logo or something entirely different?
**\<meeting-bot> [anonimal]** But why get washed in with more corporatism? We're at a juncture to break some molds here.
**\<fluffypony>** tewinget: yes
**\<tewinget>** eww
**\<DaveyJones>** on the other hand 239 is catchy... ppl may recognize that... while 146 goes in and goes out of mind
**\* fluffypony** ponders
**\<tewinget>** that said, 146 is nice.
**\<hyc>** I kinda like 254 / 253 but they're so abstract I dunno what they represent
**\<fluffypony>** anonimal: I don't think it's "corporate" per se
**\<fluffypony>** "professional" sure
**\<blackink>** my vote is 236
**\<blackink>** i mean 239
**\<meeting-bot> [anonimal]** moneromooo: can you tiny that url? weechat sucks
**\<hyc>** 239 - ok, that's still understated, I could respect that
**\<fluffypony>** my concern is that if we're too playful it eventually ends up like this: https://upload.wikimedia.org/wikipedia/commons/thumb/8/84/Itoopie.svg/2000px-Itoopie.svg.png
**\<fluffypony>** :-P
**\<pero>** i like the font squarepoint is using
**\<meeting-bot> [anonimal]** hyc: 254/253, the person was probably drinking pepsi at the time.
**\<pero>** in 25x and 99
**\<tewinget>** 24{7,8} aren't half bad.
**\<hyc>** lol. 219 has that Monero tie-in with the garlic
**\<pero>** i like #239 but the kerning is awful from a typography perspective
**\<meeting-bot> [guzzi]** why the halloween colors anyway?
**\<fluffypony>** bear in mind, too, that we can change it later on
**\<meeting-bot> [i2p-relay] {-moneromooo}** anonimal: https://paste.fedoraproject.org/426683/14736136/
**\<meeting-bot> [anonimal]** moneromooo: thanks
**\<fluffypony>** guzzi: the orange? coz of the Monero logo's colours, I'd guess
**\<ferretinjapan>** 246 is a nice mix of both 146 and 239 imo
**\<meeting-bot> [anonimal]** fluffypony: how much *can* we change after we pick one?
**\<fluffypony>** anonimal: we can always pay them more to make more changes
**\<fluffypony>** we also made changes to the Monero logo after delivery
**\<fluffypony>** to fix the kerning
**\<meeting-bot> [guzzi]** got it
**\<meeting-bot> [i2p-relay] {-moneromooo}** Not sure what numbers these map to, no numbers in the URLs
**\<dEBRUYNE>** I like 239 btw
**\<nioc>** if between 239 and 146 then 239
**\<pero>** wouldnt logo selection work better (more efficiently) by filtering out the ones no one likes
**\<dEBRUYNE>** moneromooo: your first link is #239
**\<meeting-bot> [anonimal]** moneromooo: the garlic one was top choice #239, the other one I don't know
**\<pero>** and then having an in depth look at a smaller selection
**\<fluffypony>** pero: no this is much more fun, the entire dev meeting will be "but I like this logo" :-P
**\<meeting-bot> [i2p-relay] {-moneromooo}** THanks :)
**\<hyc>** in that 223 series, is that a Tau, for Tor?
**\<meeting-bot> [anonimal]** moneromooo: I like the mask idea but the artist took the easy way out and just plastered it next to text.
**\<MalMen>** between 146 and 239 for me
**\<hyc>** 236-237 I have to exclude, there's a Circle-K convenience store chain in California that looks like that
**\<ferretinjapan>** why not make it 146 and just go a different color, it would still feel monero-ish
**\<Flyfree10>** is this where the meeting for Monero is?
**\<MalMen>** 239 is nice because it bring the "onion" that is easly recognised by tor users
**\<lurker>** i think keep it simple whilst linking to monero and its a winner 239 is good but if at anypoint the logo is just to be used it is not always instantly recognisable whereas the 146 is
**\<moneromooo>** Flyfree10: finished
**\<Flyfree10>** how did it go?
**\<meeting-bot> [anonimal]** hyc: re: tau, that's a bold stretch, I think only you and a few others would have pointed that out
**\<meeting-bot> [anonimal]** e.g., artist probably wasn't thinking on that level
**\<moneromooo>** Hmm. Wordy I guess. There will be logs from dEBRUYNE, most likely.
**\<hyc>** I'm gonna go with 239
**\<tewinget>** Flyfree10: Kovri meeting in-progress, wait a bit and Monero dev meeting minutes will be on reddit I'm sure.
**\<hyc>** if you think the typography needs to be touched up, cool, but overall it looks classy and it still has the garlic without being over the top
**\<fluffypony>** ok
**\<meeting-bot> [anonimal]** Alright, I'm seeing a lot of #239 (also my top pick)
**\<meeting-bot> [i2p-relay] {-moneromooo}** People are going to be confused between garlic/onion, I'm sure.
**\<meeting-bot> [anonimal]** They should be, they are very similar in terms of routing
**\<fluffypony>** they are, moneromooo, but I don't think they'll be confused enough to care
**\<fluffypony>** it's not like people make privacy decisions based on routing models :-P
**\<ferretinjapan>** yeah i think the garlic just looks confusing.
**\<meeting-bot> [anonimal]** So should we do a vote of "anything \*not* 239"?
**\<hyc>** yeah. it's close enough. several of the others leave me wondering WTH they are.
**\<\_Slack> <xmr\_eric>** The one option I'm not seeing is a direct copy of the Monero (M). I did a quick mockup: https://i.imgur.com/8wIh8Hb.png
**\<meeting-bot> [anonimal]** Strong opinions on \*not* 239?
**\<meeting-bot> [i2p-relay] {-moneromooo}** Well... "I use kovri, that's a privacy program for that onion type thing"
**\<meeting-bot> [anonimal]** How can we improve #239?
**\<fluffypony>** otoh I don't think I've ever heard a non-technical person talk about onion routing, moneromooo
**\<medusa_>** personally i also like 245, the green symbols strong roots
**\<pero>** 239 needs a different font and some kerning
**\<MalMen>** we can allways tell "we use garlic instead of union to keep vampires away from the network"
**\<fluffypony>** xmr\_eric: there were a bunch of those, like hundreds of them, we rejected them in favour of #239
**\<meeting-bot> [i2p-relay] {-ArticMine}** 239 Possible confusion with Tor. Could be dicey from a trademark perspective
**\<\_Slack> <xmr\_eric>** cool
**\<meeting-bot> [EinMByte]** #239 looks nice
**\<meeting-bot> [EinMByte]** Don't think there would be trademark issues
**\<meeting-bot> [anonimal]** medusa_ I like the logo but not so much the colour.
**\<pero>** if you took the word kovri from 254 and stuck it into 239 it would look significantly better
**\<fluffypony>** ArticMine: I don't know if there's much risk there, since they're just terms that describe the routing (and Tor don't own a trademark on the routing term afaik)
**\<fluffypony>** definitely if we were claiming something like that in text
**\<meeting-bot> [anonimal]** pero: good point
**\<MalMen>** anonimal at the begining I didnt like the colors of monero too, but grown on me
**\<hyc>** yeh that's why I don't like 246. the tuft at the top of the logo reminds me too much of the tor onion
**\<ferretinjapan>** 239 isnt horrible, but it definitely doesn't feel like it has a connection to Monero
**\<ferretinjapan>** other than the color, it doesn't really feel like it's closely bound to the Monero project.
**\<lurker>** agree ferretinjapan
**\<meeting-bot> [i2p-relay] {-ArticMine}** There are common law trademarks by "use in commerce" in both cases
**\<ferretinjapan>** If that's intentional then awesome, but otherwise, people may not even connect monero and kovri together as being sister projects.
**\<meeting-bot> [i2p-relay] {-moneromooo}** Then... we could superimpose: 239 with added arms on top of the monero M, trying to hide it :D
**\<pero>** i think my the minimal pacmans from 88 and 81 arent bad either
**\<fluffypony>** anonimal: what are your thoughts on the "connection to Monero" thing - do we want it to be more tightly coupled or not?
**\<hyc>** then xmr\_eric's would be fine
**\<meeting-bot> [anonimal]** fluffypony ferretinjapan lurker: if the artists can somehow come up with a better idea other than slapping a big K in the style of monero onto the garlic, then I'm open to new ideas
**\<meeting-bot> [guzzi]** fluffypony i agree if there needs to be aconnection to monero that is important to discussion on 239
**\<hyc>** or at least a starting point. maybe turn the circle background into the garlic
**\<pero>** 139 and 138 too
**\<meeting-bot> [guzzi]** anonimal, aggreed on the K statement.
**\<pero>** 138 is a more subtle variant of 239
**\<meeting-bot> [anonimal]** Realistically, at kovri's future apex, it will still be an independent router; so I'm not sure why there's so much concern about "connection"
**\<hyc>** hm, yeah, so subtle I didn't notice it before ;)
**\<ferretinjapan>** a fusing of the two whould be nice
**\* tewinget** (tentatively) casts his vote for 247, or some iteration upon it.
**\<fluffypony>** anonimal: I guess because it's like Apache projects, that all fold into the Apache structure / governance etc.
**\<meeting-bot> [EinMByte]** the color by itself should be a sufficient connection
**\<meeting-bot> [anonimal]** #247 looks so terribly awkward
**\<ferretinjapan>** that's why I liked #246, but maybe it's a bit too plain
**\<hyc>** 138 reminds me more of saturn's rings than a garlic
**\<meeting-bot> [anonimal]** #246: the flaming egg
**\<hyc>** I'm still going with 239, final answer.
**\<fluffypony>** lol
**\<ferretinjapan>** or the tennisball with fuzz on top :)
**\<meeting-bot> [i2p-relay] {-ArticMine}** Possibly 251 No onion / garlic
**\<MalMen>** well, If it was to be something completly distinct from monero I would vote 249
**\<meeting-bot> [anonimal]** Let's decide on 1 and see how we can improve it.
**\<tewinget>** I think maybe since there are so many opinions we shelf this for now, make a shortlist of 10 or so, and discuss among just those at a later time.
**\<meeting-bot> [anonimal]** I'm voting #239
**\<meeting-bot> [guzzi]** we ef have two camps here. use a letter like Monero logo or -- somethinge else00
**\<fluffypony>** we have 8 days to make a decision, tewinget
**\<hyc>** shrink them down to 16x16 favicons, most of them will look like garbage
**\<fluffypony>** tbh I kinda like #239 too
**\<fluffypony>** and I think the colour is indeed enough of a connection
**\<meeting-bot> [EinMByte]** #239 should do
**\<tewinget>** fluffypony: that later time could be an hour from now, I just figured maybe get to the rest of the Kovri meeting, then circle back.
**\<fluffypony>** also we can ALWAYS change it later
**\<pero>** hyc except for 135 and 134
**\<fluffypony>** not like we have a branding department to report to
**\<pero>** i think tus\_99 definitely has the best handle on the design
**\<hyc>** ok, 135 isn't bad.
**\<pero>** and squarepoint the best typography
**\<fluffypony>** anonimal: as the CEO of Kovri (kidding) you get to decide, I think you've heard enough opinions, and we'll defer to you
**\<meeting-bot> [anonimal]** fluffypony: thank you
**\<meeting-bot> [anonimal]** #239 it is \*but* we should work out font and see if artist can improve the idea.
**\<fluffypony>** absolutely
**\<fluffypony>** I'll finalise the 99designs competition in the next couple of days, and give the artist final direction
**\<meeting-bot> [anonimal]** Who here had thoughts about kerning, etc.?
**\<meeting-bot> [anonimal]** (backlog too big to read)
**\<pero>** that was i
**\<fluffypony>** pero did
**\<meeting-bot> [anonimal]** pero could you give specifics so fluffypony can relay to artist?
**\<pero>** sure i'll pm him something in a little bit
**\<meeting-bot> [anonimal]** Thanks pero
**\<meeting-bot> [anonimal]** fluffypony: will we ever have a one-on-one with tus_99?
**\<fluffypony>** I don't think so
**\<meeting-bot> [anonimal]** As in, ever speak directly with him?
**\<meeting-bot> [anonimal]** Oh
**\<fluffypony>** I think we send him direction and then he's like "ok here" and that's it
**\<fluffypony>** but we will have the source
**\<meeting-bot> [anonimal]** Odd world we live in.
**\<fluffypony>** and we can modify it from there
**\<meeting-bot> [anonimal]** Ok great
**\<meeting-bot> [anonimal]** So, resolved with #239?
**\<meeting-bot> [i2p-relay] {-ArticMine}** I have to leave now
**\<meeting-bot> [anonimal]** Thanks ArticMine
**\<meeting-bot> [EinMByte]** anonimal: Yes, let's move on
**\<fluffypony>** indeed
**\<fluffypony>** rubber stamp of approval and all that
**\<meeting-bot> [anonimal]** Sold, to #239!
**\<meeting-bot> [anonimal]** Alright next
**\<meeting-bot> [anonimal]** 2. Greetings
**\<meeting-bot> [anonimal]** 3. Brief review of what's been completed since the previous meeting
**\<meeting-bot> [anonimal]** Hi
**\<meeting-bot> [anonimal]** (lol)
**\<fluffypony>** lol
**\<meeting-bot> [EinMByte]** Hi
**\<meeting-bot> [guzzi]** hi
**\<fluffypony>** EinMByte thanks for taking the time to join the meeting, I know you're busy
**\<meeting-bot> [anonimal]** git log --pretty=oneline --since=2weeks --no-merges | wc -l
**\<meeting-bot> [anonimal]** 30
**\<meeting-bot> [anonimal]** Fixes, features, improvements.
**\<meeting-bot> [anonimal]** Highlights include:
**\<meeting-bot> [anonimal]** - The infamous transports "5 - 6 = 18446744073709551615" diffie-hellman keypair supplier bug, now fixed
**\<meeting-bot> [anonimal]** - AddressBook fixes/enhancements
**\<meeting-bot> [anonimal]** - HTTP fixes/enhancements
**\<meeting-bot> [anonimal]** - Clearnet / in-net download impl
**\<meeting-bot> [anonimal]** - Coverity resolutions
**\<meeting-bot> [anonimal]** - More in log
**\<meeting-bot> [anonimal]** Please pipe-in if I missed something we should note
**\<meeting-bot> [anonimal]** Oh yes, more NTCP fixes thanks to EinMByte
**\<meeting-bot> [anonimal]** And more on the way (not yet merged)
**\<meeting-bot> [anonimal]** Anything else on 3.?
**\<fluffypony>** i'd like to point out that the Kovri instance that runs i2p-relay
**\<fluffypony>** no longer suffers from memory leaks (although they were only occasional before)
**\<fluffypony>** thank you for fixing :)
**\<meeting-bot> [EinMByte]** There's a few more leaks that need fixing
**\<fluffypony>** (that server has 128gb of RAM, so a memory leak is kinda humorous)
**\<meeting-bot> [anonimal]** Hard to pin down. One would think they would have checked that 5 - 6 != 0
**\<meeting-bot> [anonimal]** s/they/the mathematical magician/
**\<meeting-bot> [EinMByte]** fluffypony: Please tell us when you see inbound NTCP happening :)
**\<meeting-bot> [anonimal]** EinMByte that'll probably never happen until we fix it, lol
**\<fluffypony>** will do lol
**\<meeting-bot> [EinMByte]** If we even need to fix it
**\<meeting-bot> [anonimal]** Something needs fixed somewhere
**\<meeting-bot> [EinMByte]** Probably, yes
**\<meeting-bot> [anonimal]** 4. Code + ticket discussion / Q & A
**\<meeting-bot> [anonimal]** So latest hot topic was release planning for 33C3
**\<meeting-bot> [EinMByte]** Is that done? Wiki still looks empty
**\<meeting-bot> [anonimal]** I'd rather not repeat the tons of work EinMByte and I have done this week. If anyone is interested they can start idling #kovri-dev
**\<fluffypony>** whoop whoop
**\<meeting-bot> [anonimal]** No, wiki not done
**\<meeting-bot> [anonimal]** I've sorted out open issues,
**\<meeting-bot> [anonimal]** will open a few more directly related to first release,
**\<meeting-bot> [anonimal]** will do more roadmap work once release cycle is codified,
**\<fluffypony>** and now that we're closer to logo I can get back on the website / email bandwagon
**\<meeting-bot> [anonimal]** we sill need a solid answer on CI
**\<fluffypony>** anonimal: which CI question?
**\<meeting-bot> [anonimal]** Mr. build bot, the devops guy who was supposed to be at the monero meeting today
**\<pigeons>** hello
**\<meeting-bot> [anonimal]** Maybe I missed the discussion, I don't know
**\<DaveyJones>** pigeons it is :D
**\<meeting-bot> [anonimal]** Hi pigeons
**\<fluffypony>** oh
**\<fluffypony>** lol
**\<fluffypony>** anonimal sorry, it was at the beginning of the Monero meeting
**\<meeting-bot> [anonimal]** My fault then, I came in late
**\<meeting-bot> [anonimal]** When are we throwing out travis?
**\<pigeons>** Hi. Im just getting everything started, but feel free to chat with me anytime and ill show you what were doing and yuo can tellme about the needs
**\<fluffypony>** anonimal: we'll probably break the chassis on Monero first
**\<fluffypony>** and setup IRC hooks etc.
**\<fluffypony>** and then adding Kovri will be a snap
**\<meeting-bot> [anonimal]** Awesome and awesome, thanks pigeons and fluffypony
**\<pigeons>** luckiy buildbot irc hooks are vey automactice and easy
**\<fluffypony>** hashtag excite
**\<meeting-bot> [anonimal]** Ok great, so we'll keep in touch then overtime.
**\<pigeons>** cool.
**\<meeting-bot> [anonimal]** Next issue, fluffypony did you want me to bring-up/add something to the agenda?
**\<meeting-bot> [anonimal]** fluffypony: was it for website or email or both?
**\<fluffypony>** anonimal: both
**\<fluffypony>** can't think of anything else
**\<fluffypony>** re: 33C3 I'll be putting a post up on the forum in the next little while so everyone knows what's potting
**\<meeting-bot>** anonimal checking issues
**\<meeting-bot> [anonimal]** Ok, they've been milestone'd
**\<fluffypony>** awesomesauce
**\<fluffypony>** when shall we three meeting again? (to quote Macbeth)
**\<meeting-bot> [anonimal]** Alright, open issues should be organized enough / milestone'd where appropriate
**\<meeting-bot> [anonimal]** Anything else on 4.?
**\<meeting-bot> [anonimal]** (4. Code + ticket discussion / Q & A)
**\<fluffypony>** nothing from my side
**\<meeting-bot> [EinMByte]** So what I'm currently working (of the milestoned issues): #191, #312, #342
**\<meeting-bot>** [guzzi] i will keep working on coverety isues
**\<meeting-bot> [EinMByte]** Will do #213 later
**\<meeting-bot> [EinMByte]** For the memory leaks (and other memory problems): the ntcp branch has a couple of fixes
**\<meeting-bot> [EinMByte]** Currently working on a (partial) fix of #342
**\<meeting-bot> [anonimal]** You're not assigned to #342, I can add you unless you wanted to add yourself
**\<meeting-bot> [EinMByte]** I'll assign
**\<meeting-bot> [anonimal]** https://github.com/monero-project/kovri/issues?q=is%3Aopen+is%3Aissue+milestone%3A0.1.0-alpha+assignee%3AEinMByte
**\<meeting-bot> [anonimal]** Ok
**\<meeting-bot> [EinMByte]** So to be clear, the backtrace you posted 4 hours ago is what I fixed
**\<meeting-bot> [EinMByte]** (but not yet pushed because unforseen issues)
**\<meeting-bot> [anonimal]** I posted two. I imagine you're talking about the NTCP one
**\<meeting-bot> [EinMByte]** Yes
**\<meeting-bot> [EinMByte]** Won't touch the client issue for now
**\<meeting-bot> [anonimal]** Yay client
**\<meeting-bot> [anonimal]** https://github.com/monero-project/kovri/issues?q=is%3Aopen+is%3Aissue+milestone%3A0.1.0-alpha+assignee%3Aanonimal
**\<meeting-bot> [anonimal]** That covers a small fraction of what I'll end up fixing / working on
**\<meeting-bot> [EinMByte]** For #187 (NTCP core issues), the main thing left to fix is the inbound NTCP
**\<meeting-bot> [anonimal]** I just don't assign myself in case someone else wants to grab something
**\<meeting-bot> [anonimal]** EinMByte: yeah, running tcpdump against kovri --log-to-console 0 --v6 1 --enable-ssu 0
**\<meeting-bot>** \* anonimal pasting
**\<meeting-bot> [EinMByte]** Yes, and I'd ask everyone else wanting to help out to do the same
**\<meeting-bot> [anonimal]** 19:42:20.974119 IP6 2001:0:9d38:6ab8:2c92:2e09:b8ee:e2d.59823 > me.11552: Flags [S], seq 1067814148, win 8192, options [mss 1220,nop,wscale 8,nop,nop,sackOK], length 0
**\<meeting-bot> [anonimal]** 19:42:28.017709 IP6 2001:0:9d38:6ab8:2c92:2e09:b8ee:e2d.59823 > me.11552: Flags [S], seq 1067814148, win 8192, options [mss 1220,nop,nop,sackOK], length 0
**\<meeting-bot> [EinMByte]** guzzi: Try this if you get bored with coverity issues
**\<meeting-bot> [anonimal]** Let's take mroe NTCP chat outside of the meeting since this is being logged
**\<meeting-bot> [EinMByte]** (--v6 not necessary, just see if you get inbound traffic, and paste logs when you do)
**\<meeting-bot> [anonimal]** \*more
**\<meeting-bot> [anonimal]** Yes, I know, just happens to be the instance that is running
**\<meeting-bot> [EinMByte]** ok
**\<meeting-bot> [anonimal]** guzzi any questions about tickets, etc.?
**\<meeting-bot> [anonimal]** I'll be around after meeting, moving on.
**\<meeting-bot> [anonimal]** 5. Any additional meeting items
**\<meeting-bot> [guzzi]** no you have given me good tips lately
**\<meeting-bot> [guzzi]** i appreciate it.
**\<meeting-bot> [anonimal]** Ok good, glad to help.
**\<fluffypony>** that's it from me
**\<meeting-bot> [anonimal]** Glad to have you onboard.
**\<meeting-bot> [anonimal]** Nothing from me on 5.
**\<meeting-bot> [anonimal]** Last call for 5.
**\<fluffypony>** going once, going twice, sold!
**\<meeting-bot> [anonimal]** 6. Confirm next meeting date/time
**\<meeting-bot> [EinMByte]** What about the website, though?
**\<meeting-bot>** * anonimal backtracks to 5.
**\<meeting-bot> [EinMByte]** (or did I just miss that)
**\<meeting-bot> [anonimal]** fluffypony: do you have any details yet?
**\<fluffypony>** EinMByte: I said that now that we're wrapping up the logo I can get back on the bandwagon with that
**\<meeting-bot> [anonimal]** And it \*will\* be online by first release fluffypony, yes?
**\<fluffypony>** absolutely
**\<meeting-bot> [EinMByte]** Well, it was supposed to be done by today
**\<meeting-bot> [anonimal]** lol, EinMByte cracking the whip
**\<meeting-bot> [EinMByte]** So, what's the real deadline?
**\<fluffypony>** oh - there must've been a miscommunication; when we decided on the logo finalists I said I was shelving it till we'd completed the logo decision
**\<meeting-bot> [anonimal]** I think deadline should be at the very least a week before 33C3.
**\<fluffypony>** anonimal: long before then
**\<fluffypony>** we're keeping it simple initially, remember
**\<meeting-bot> [anonimal]** As long as it works and doesn't look terrible, I'm happy.
**\<meeting-bot> [anonimal]** Should we make a concrete date for website like we are for kovri release?
**\<fluffypony>** let's see where we get before the next meeting and re-address it then
**\<meeting-bot> [EinMByte]** ok
**\<meeting-bot> [EinMByte]** Let's put that on the roadmap
**\<meeting-bot> [anonimal]** One thing for 5.,
**\<meeting-bot> [anonimal]** questioning if we should move build instructions to wiki
**\<meeting-bot> [anonimal]** (github wiki)
**\<meeting-bot> [anonimal]** A) easier, doesn't pollute git log B) makes us reliant on github
**\<meeting-bot> [anonimal]** A good, B bad.
**\<meeting-bot> [anonimal]** Any thoughts? or we can move this to next meeting
**\<fluffypony>** I think that's a bad idea
**\<fluffypony>** if someone clones the repo they should have everything they need right there
**\<meeting-bot> [anonimal]** But if they don't have network connectivity, kovri is useless
**\<meeting-bot> [EinMByte]** I tend to agree with fluffypony
**\<meeting-bot> [anonimal]** And if they can clone from github, they have access to the website
**\<fluffypony>** anonimal: what if Github blocks Tor access after they've cloned it?
**\<meeting-bot> [anonimal]** And if they have access to either, they can read build instructions.
**\<fluffypony>** not everyone will be able to checkout an old commit to get build instructions
**\<meeting-bot> [EinMByte]** There could be a tutorial of some sort in the wiki
**\<meeting-bot> [EinMByte]** But basic build instructions should be in the repo
**\<meeting-bot> [anonimal]** Alright, no arguments from me, just questioning
**\<meeting-bot> [anonimal]** Anything else on 5.?
**\<meeting-bot> [anonimal]** We're out of time
**\<meeting-bot> [anonimal]** 6. Confirm next meeting date/time
**\<meeting-bot> [anonimal]** 2 weeks from now, works best I think.
**\<fluffypony>** 2 weeks from now plz
**\<meeting-bot> [anonimal]** Ok, sept. 25th, same time
**\<fluffypony>** ok
**\<meeting-bot> [EinMByte]** ok
**\<meeting-bot> [anonimal]** Thanks everyone. Thanks #monero-dev for the logo input too
**\<meeting-bot> [guzzi]** ok

305
_posts/2016-09-11-overview-and-logs-for-the-dev-meeting-held-on-2016-09-11.md
View File

@ -1,305 +0,0 @@
---
layout: post
title: Overview and Logs for the Dev Meeting Held on 2016-09-11
summary: brief update on 0MQ, RingCT, the hardfork schedule, and a new contributor, pigeons (sysops/devops)
tags: [dev diaries, core, crypto, 0mq]
author: dEBRUYNE / fluffypony
---
*September 11th, 2016*
# Logs
**\<fluffypony>** Hi all
**\<fluffypony>** I'm on my phone
**\<ArticMine>** Hi all
**\<tooquick_4u>** hello
**\<DaveyJones>** NoodleDoodle, TheKoziTwo,
**\<DaveyJones>** anyone else?
**\<pigeons>** hola
**\<DaveyJones>** luigi1112, listening or cruising ;)
**\<DaveyJones>** jwinterm
**\<fluffypony>** lol
**\<fluffypony>** hyc and moneromooo are around afaik
**\<tewinget>** fluffypony: if you wanna just give a list of things to cover, one of us can conduct the meeting. (assuming you don't wanna have to type a shitload on your phone)
**\<fluffypony>** Well I think let's start with 0MQ, tewinget
**\<fluffypony>** Then you can talk and I don't have to
**\<fluffypony>** :-P
**\<tewinget>** well, I wanted to have more news, but I'm having to do a full distro upgrade to get a newer boost on this craptop, and the internet is slow as balls...so I don't really have much in the way of updates. Soon™. Need to merge RingCT stuff into my zmq branch, then make the new RingCT-related RPC calls (as well as updating any others as needed), then should be golden for basic implementation.
**\<tewinget>** will try to get most of that done today or tomorrow.
**\<fluffypony>** This is daemon only right now right?
**\<tewinget>** daemon RPC, and a lib to use it that libwallet will call into.
**\<fluffypony>** ok - and then next thing after daemon is buttoned up is a wallet 0MQ endpoint right?
**\<tewinget>** but yes, for right now I'm working on the daemon's RPC. Once that's in a good spot I can move onto wallet RPC. Oh, and I think since the last dev meeting I redid the formatting of the RPC commands to get JSON-RPC 2.0 compliant.
**\<fluffypony>** Ok so tewinget let me ask about the backwards-compatible stub
**\<fluffypony>** Coz obviously we still need a stub for those that insist on touching the daemon using old RPC
**\<fluffypony>** Is that just a matter of refactoring it out of the daemon?
**\<tewinget>** well...so \*my* plan was to leave the old RPC in place until we decide "yea, that's for sure deprecated and gonna be removed now"
**\<fluffypony>** That's fine - I meant as a later exercise
**\<fluffypony>** Just trying to gauge the amount of effort it's going to take
**\<tewinget>** hmm, well, a wrapper around the old RPC to hook into the new wouldn't be *too* hard...
**\<tewinget>** just tedious
**\<fluffypony>** I know it's tedious
**\<fluffypony>** What if we made it generic
**\<fluffypony>** Like it translated the RPC call directly
**\<fluffypony>** If it fails pass the error back
**\<fluffypony>** Oh wait that won't work
**\<fluffypony>** The 0MQ calls are different
**\<tewinget>** not hugely different, but different in some cases, yes. with good reason...
**\<fluffypony>** Ok so tedious because it requires everything implemented as a 0MQ client, got it
**\<fluffypony>** As a practical matter
**\<fluffypony>** We need to consider something like cppnetlib for TLS and auth
**\<tewinget>** I'm trying to make switching costs as low as possible, but I can't make it nonzero.
**\<fluffypony>** And implement that as a matter of some urgency, since the entire net_skeleton thing was a colossal waste of time
**\<fluffypony>** Ok tks tewinget - anything else from your side?
**\<tewinget>** yea, I might make TLS and auth a priority ahead of wallet RPC (since it will need auth anyway)
**\<tewinget>** other than that, not really.
**\<tewinget>** carry on.
**\<moneromooo>** "I can't make it nonzero" <-- excellent!
**\<fluffypony>** Hokay
**\<fluffypony>** LOL
**\<fluffypony>** Nice catch
**\<hyc>** lol
**\<fluffypony>** breaking: Monero contributor works for free!
**\<hyc>** just tuning in, was teaking my ARM code
**\<tewinget>** god dammit.
**\<fluffypony>** Instant delivery!
**\<tewinget>** well, moneromooo, I can't
**\<tewinget>** because it has to use ZERO MQ
**\<fluffypony>** Hah hah
**\<tewinget>** #SavedIt
**\<hyc>** :P
**\<fluffypony>** #dadjokes
**\<fluffypony>** At any rate
**\<fluffypony>** I'd like to introduce pigeons
**\<fluffypony>** He's recently started doing some stuff with me
**\<fluffypony>** and he's kindly going to help us redo our sysops / devops
**\<fluffypony>** For all projects, including Kovri
**\<hyc>** nice
**\<pigeons>** Hi guys. :)
**\<moneromooo>** Hi
**\<hyc>** hey there
**\<fluffypony>** pigeons: tell us a bit about yourself or whatever
**\<fluffypony>** "Long walks on the beach" and all that
**\<hyc>** I guess the population explosion kinda demanded more ops
**\<moneromooo>** I see what a sysop is, but not a devop.
**\<pigeons>** I like pina coladas and getting lost in te rain. Ive been syadmin type stuff forever.
**\<ArticMine>** Hi pigeons
**\<fluffypony>** moneromooo: devops is like CI and build boxes and that
**\<pigeons>** devops is the new term for brogrammers who use docker and jenkins CI etc
**\<moneromooo>** Oh nice :)
**\<fluffypony>** Hah hah
**\<hyc>** I think a devop is a developer with rootpw on all production machines. sysaop's worst nightmare :P
**\<fluffypony>** Devops-as-a-Service
**\<fluffypony>** lol
**\<pigeons>** but yeah im gonna try and get buildbot ci going the system chromium and some others use
**\<pigeons>** get builds and tests for arm, windows, mac, freebsd, linux 32 64
**\<fluffypony>** Also the immediate aim is to be able to push nightlies to the site
**\<hyc>** nice
**\<iDunk>** #1047 did this
**\<iDunk>** oops
**\<i2p-relay> {-guzzi}** hi pigeons
**\<fluffypony>** So the broader community can test without waiting for fluffypony to build
**\<pigeons>** eventually look at gitian style reproducible builds
**\<hyc>** ARM is gonna be 3 distinct builds, ARMv6, ARMv7, ARMv8
**\<hyc>** rapidly proliferating...
**\<pigeons>** ok cool
**\<fluffypony>** hyc: I think we'll have to drop ARMv6 for performance concerns
**\<fluffypony>** If not now then soon
**\<hyc>** ok, fair enough
**\<fluffypony>** Also on that note
**\<hyc>** yeah, the perf/watt just isn't there on ARMv6
**\<fluffypony>** Am I correct in saying that QEMU is about the only way we're going to get arm7/8 build boxes?
**\<fluffypony>** Or does anyone know of hosted native arm boxes?
**\<hyc>** there's an ARM VPS provider out there
**\<pigeons>** yeah what are they called again, there is one
**\<tewinget>** someone recommended one to me just the other day, oddly enough...can't remember the name.
**\<fluffypony>** lol
**\<bitjedi>** awww. i still use my pi zero nodes
**\<bitjedi>** which are arm v6
**\<fluffypony>** bitjedi: they'll choke on RingCT
**\<iDunk>** scaleway.com ?
**\<hyc>** scaleways?
**\<hyc>** yeah
**\<bitjedi>** are u sure it's cpu and not io?
**\<fluffypony>** Awesome
**\<fluffypony>** Isn't scaleways native and not virtualised?
**\<fluffypony>** I seem to vaguely recall
**\<tewinget>** I think it was Scaleway
**\<hyc>** hm, they claim bare metal, yeah
**\<pigeons>** theres one ovhi or somone in scandanavia
**\<fluffypony>** Ok
**\<fluffypony>** Also the implication is that anyone relying on the Mac / 32-bit test boxes should expect an impending change
**\<fluffypony>** I think anonimal primarily uses them
**\<fluffypony>** Also we'll hopefully be able to provide broader access to test hardware in future
**\<i2p-relay> {-anonimal}** * has yet to use 32-bit boxes
**\<fluffypony>** Ok then FreeBSD
**\<fluffypony>** Has anyone tried the WIP boost 1.60 port on BSD?
**\<hyc>** haven't touched BSD in years
**\<i2p-relay> {-anonimal}** Last I checked, build failed hard on freebsd for monero.
**\<i2p-relay> {-anonimal}** Works with kovri.
**\<fluffypony>** xmj is our resident BSD expert and even he hasn't touched boost 1.60
**\<fluffypony>** If anyone wants to volunteer to play with that great
**\<fluffypony>** We also need to start thinking about packaging
**\<fluffypony>** lol relevant PR is relevant
**\<fluffypony>** hyc how do you guys handle packaging for like Debian / Ubuntu?
**\<hyc>** eh, OpenLDAP Project is source-code only, distros do their own packaging
**\<fluffypony>** Coz my concern with farming it out is that we end up with old versions on old distros
**\<i2p-relay> {-anonimal}** fluffypony: I was planning to work with the monero bsd build (only freebsd though) once we get kovri releases going
**\<hyc>** yes, that's a pervasive problem with distros
**\<fluffypony>** Tks anonimal - I'll also fiddle
**\<fluffypony>** When I have time, so never :-P
**\<fluffypony>** Ok next thing
**\<fluffypony>** moneromooo: want to talk about the rct serialisation changes?
**\<fluffypony>** And the impact on testnet
**\<moneromooo>** It's finished. It's on github ready to merge. And it will need reorganizing on testnet, yes.
**\<moneromooo>** So, I guess someone with hash power will have to pop N blocks till before v4, and mine.
**\<moneromooo>** After a few daysm it'll reorg for everyone :)
**\<moneromooo>** And we'll get to test deep reogs.
**\<hyc>** so anyone mining testnet right now should stop
**\<moneromooo>** Unless you want to test stuff.
**\<iDunk>** i exported the raw blockchain up to 800499. that's before v3, right?
**\<tewinget>** well that's not entirely necessary >\*\*\_>\*\*
**\<moneromooo>** Yes.
**\<iDunk>** and v4 is... ?
**\<iDunk>** 802000 or so iirc ?
**\<moneromooo>** 801220
**\<jjiia>** XMR up or down
**\<iDunk>** ah, k
**\<fluffypony>** I think my miner is off atm
**\<fluffypony>** it had that hiccup and I never fixed it coz stuff
**\<moneromooo>** rct soon!
**\<fluffypony>** ok so moneromooo
**\<ArticMine>** It had to be done
**\<MalMen>** are you guys forking the testnet ?
**\<fluffypony>** when it loads the blockchain on the new code
**\<MalMen>** im gonnad do a testnet classic
**\<fluffypony>** it *should* freak out
**\<i2p-relay> {-anonimal}** Is this the meeting where we can discusses CI for CD?
**\<fluffypony>** and rollback?
**\<fluffypony>** anonimal: CD? like compact discs?
**\<i2p-relay> {-anonimal}** Laser-only releases
**\<moneromooo>** It'll probably moan a bit, but not overly.
**\<fluffypony>** :-P
**\<fluffypony>** ok but what I mean is
**\<fluffypony>** when we load a blockchain off disk we don't re-verify
**\<MalMen>** the dev meeting is still going on or to late ?
**\<fluffypony>** so will we have to manually pop blocks?
**\<dEBRUYNE>** still going on MalMen
**\<moneromooo>** Yes.
**\<fluffypony>** ok so I'll merge tomorrow afternoon, gives us a day for review
**\<moneromooo>** Just the miner. Others will just reorg when the miner passes the old chain's diff.
**\<moneromooo>** (hopefully)
**\<fluffypony>** and then I'll do some block-popping tomorrow night
**\<fluffypony>** and hopefully deep reorgs
**\<moneromooo>** luigi1112: btw, you'll want to read the latest get_transaction_hash and comment. It's still 3 parts.
**\<fluffypony>** ok
**\<fluffypony>** then the next thing is our hard fork date and the next release
**\<fluffypony>** we're planning on finalising final bits and releasing 0.10 shortly
**\<fluffypony>** but obviously RingCT (ie. v4 blocks) is not ready for even a final inclusion in this code freeze
**\<fluffypony>** given that we're still making changes
**\<fluffypony>** so I'd like some input from contributors and those present as to how to handle the v4 fork, since we have a couple of options
**\<fluffypony>** either:
**\<fluffypony>** 1. we leave v4 till March 2016
**\<iDunk>** 2017
**\<fluffypony>** tks 2017
**\<fluffypony>** 2. we change the "complain about a fork" date to like end-of-November, with an aim to forking to v4 end of December
**\<fluffypony>** so coded freeze beginning of December
**\<fluffypony>** (this would make RCT transactions potentially available on mainnet from Jan 1)
**\<fluffypony>** but obviously there's the risk of breakage
**\<hyc>** maybe December is too soon, how about January?
**\<fluffypony>** so if we had to do Jan, then when do we do v5?
**\<fluffypony>** March is too close to Jan for v5, imho
**\<ArticMine>** fluffypony My preference is 2, but my biggest concern is the amount of time left for finalization of development and testing
**\<dEBRUYNE>** We don't necessarily have to decide the exact dates now, but I think option 2 would be best
**\<fluffypony>** ok so what if we did 2, but then pushed the v5 fork to September next year
**\<hyc>** if we have v4 in January then June/July would be OK
**\<fluffypony>** that way RCT is available on mainnet early on, but if anything breaks we have 9 months to fix it
**\<fluffypony>** hyc: I don't want to go too far away from our schedule
**\<hyc>** ok
**\<dEBRUYNE>** \<hyc> if we have v4 in January then June/July would be OK <= Fine with that too
**\<DaveyJones>** sounds reasonable to me
**\<dEBRUYNE>** Like I said, we can always decide on the exact dates later
**\<fluffypony>** like this is major enough to warrant a change, but we should aim for a singular change
**\<hyc>** so march/september is the cadence we're aiming for?
**\<ArticMine>** Yes I like the idea of advancing V4 fork but keeping the v5 fork on schedule
**\<tewinget>** I agree, singular deviation from the schedule is preferable.
**\<hyc>** ok
**\<fluffypony>** hyc: yep
**\<dEBRUYNE>** fluffypony: most people will use Ring CT transactions anyway
**\<fluffypony>** so we bring v4 a bit forward, and leave v5 as scheduled
**\<lurker>** yes
**\<fluffypony>** dEBRUYNE: we can always make it the non-default, like we did with transfer_new
**\<hyc>** sounds good
**\<dEBRUYNE>** yeah agree
**\<ArticMine>** agree
**\<fluffypony>** ok so we'll move the freak-out to early December, and actual fork block height will be decided at that code freeze
**\<fluffypony>** but likely late Dec / early Jan or so
**\<fluffypony>** and v5 stays for September 2017
**\<fluffypony>** consensus: reached!
**\<DaveyJones>** \o/
**\<fluffypony>** (it's so easy when you're tiny and only like 5 people have to agree, lol)
**\<fluffypony>** I think that's about it from my side, there's something else but I completely can't remember
**\<fluffypony>** is there anything else that anyone wants to bring up?
**\<ferretinjapan>** I dunno multisig for bitcoin was a bitch...
**\<hyc>** current freeze, release date?
**\<tewinget>** since Ilya's not here...
**\<i2p-relay> {-anonimal}** I moved kovri logo decision agenda to the beginning of kovri meeting in 10'ish minutes so we can catch everyone before they leave
**\<ferretinjapan>** that only had 8 guys
**\<fluffypony>** ferretinjapan: lol
**\<lurker>** a quick update on multisig preferably
**\<moneromooo>** Do you want to wait for the fee change before binaries ?
**\<fluffypony>** lurker: https://shnoe.wordpress.com/2016/03/22/ring-multisignature/
**\<fluffypony>** it's whitepaper-only right now
**\<kintaji>** fluffpony - the GUI wallet. Languages and regional variations.
**\<fluffypony>** oh
**\<Kermit_>** Hi guys can I ask about public wallet build release dates
**\<fluffypony>** yes moneromooo thanks for reminding me
**\<fluffypony>** tag->release->binaries will be in the coming week, hopefully
**\<fluffypony>** there are two things still remaining
**\<fluffypony>** 1. fee changes (lower min-fee, bind it to the inverse of the block median as suggested by ArticMine)
**\<fluffypony>** 2. ideally, if anyone is up for it, we seriously need our DNSSEC check expanded to *actually* check from the root cert down, at the moment it's relying on the DNS server to send back a "secure" flag, which is breaking it on lots of routers
**\<MalMen>** tewinget can you point me to the list of 0qm commands that you have already?
**\<fluffypony>** and we rely on DNSSEC for MoneroSeeds and MoneroPulse
**\<MalMen>** I have some sugestion
**\<ArticMine>** moneromooo is coding the fee changes
**\<fluffypony>** there's some time pressure on that, but it's not a huge piece of work, so if anyone is up for it then that would be appreciated
**\<fluffypony>** if not it'll have to hold off till the next release
**\<moneromooo>** Yes, I started looking at it this afternoon. Not a simple change, since it'll require a new RPC, and access to median block size calc in misc places.
**\<fluffypony>** ok
**\<dEBRUYNE>** fluffypony: would it be feasible to provide trezor binaries?
**\<fluffypony>** dEBRUYNE: I haven't actually looked at it properly, and NoodleDoodle isn't around to give his opinion
**\<dEBRUYNE>** I see, he's still working on the Ring CT bit, so probably better to wait until that is finished to provide them
**\<fluffypony>** kintaji: re: languages / variants, I think we'll hold off on that a bit as there are large parts of the GUI that are non-functional right now
**\<fluffypony>** Kermit_: do you mean the GUI wallet, or the next tagged release?
**\<Kermit_>** Yes gui
**\<kintaji>** fluffypony - Okay. Just to say there are some oddities with the current flag page. Can expand at a later time.
**\<fluffypony>** Kermit_: not certain yet - I'll look at building beta binaries in the next week or so
**\<Kermit_>** Thanks
**\<fluffypony>** kintaji: yeah maybe best thing to do is drop it out the wizard initially
**\<fluffypony>** and add it back in later on
**\<tewinget>** MalMen: have a look at https://www.github.com/tewinget/bitmonero/tree/zmq-dev, file src/rpc/daemon_messages.h. I need to do a bit of write-up, but that's a good place to start.
**\<kintaji>** fluffypony - yep. sounds like a good idea.
**\<fluffypony>** ok anything else or can we start the Kovri meeting?
**\<hyc>** any other volunteers to test ARMv8 builds?
**\<fluffypony>** oooh I will hyc
**\<pero>** yea i can
**\<hyc>** cool, I'll have atarball ready later tonight
**\<MalMen>** tewinget you are writing your rcp calls with up letters right ?
**\<pero>** fluffy i have centos 64bit on my rpi3 fyi
**\<fluffypony>** hyc: is an R8 ARM processor an armv8?
**\<fluffypony>** coz if so then I have a bunch of C.H.I.Ps lying around that I can test on
**\<hyc>** I don't know what R8 is. what box is that?
**\<tewinget>** MalMen: the class names are CamelCase, but the methods (currently) are "word_word_word". No reason that can't change, of course.
**\<MalMen>** ahhhh, nice
**\<fluffypony>** AllWinner R8
**\<MalMen>** I was in mind that you where using WordWordWord
**\<hyc>** ok I see it
**\<MalMen>** would sugest wordWordWord
**\<fluffypony>** "Allwinner R8 is SoC designed based on A13 featuring one core Cortex-A8 ARM CPU with Cedar Engine VPU and Mali 400 GPU"
**\<hyc>** nope . Cortex-A8 is ARMv7
**\<fluffypony>** ah ok
**\<fluffypony>** well that sucks
**\<fluffypony>** hi meeting-bot!
**\<tewinget>** MalMen: the method names (as in, the method field in the RPC call on the wire) are "word_word_word" to conform with the previous RPC, but I have no particular attachment to that format.
**\<MalMen>** well, I am checking the bitcoin rcp and they use wordwordword, I think i like word_word_word better

100
_posts/2016-09-19-monero-0.10.0-released.md
View File

@ -1,100 +0,0 @@
---
layout: post
title: Monero 0.10.0 "Wolfram Warptangent" Released
summary: A major release of Monero, Wolfram Warptangent, with RingCT, major performance fixes, and more
tags: [releases]
author: Riccardo Spagni (fluffypony)
---
*September 19th, 2016*
## Overview
This is the next major release of Monero. It adds an initial release of RingCT, which is already live on testnet. The RingCT whitepaper [can be found here](https://lab.getmonero.org/pubs/MRL-0005.pdf). Note that the v4 hard fork has been moved to the beginning of January, 2017, although the v5 hard fork remains set at September, 2017. This is to enable early availability of RingCT transactions on the Monero network, although they will not be enforced as the only possible transaction type until the v5 hard fork.
One of the largest pieces of work were the BlockchainDB performance improvements. This was largely done by warptangent, an early Monero contributor who passed away in March, 2016. His work was completed by Howard "hyc" Chu, and we have named this release after him. We are deeply grateful for all the effort he put in to making Monero what it is today.
Some highlights of this release are:
- major performance improvements, especially on spinning disks
- major space saving gains for the blockchain, despite the performance improvements
- renamed binaries to follow a more logical, consistent convention
- RingCT...obviously:)
- added libunwind support for better crash reporting
- added a key image export and import function for full watch-only wallet functionality
- added support for ARMv8 processors
- added a do\_not\_relay flag for transactions sent to the daemon
- added a sweep\_all command and RPC call for the wallet
- significant fixes and improvements to threading
- add a get\_transfers RPC call
- added transfer tracking to the wallet (lost forever if the wallet cache is deleted)
- added a filter\_by\_height option to get_transfers
- added a --max-concurrency flag for the wallet
- major improvements to ARM performance, especially on newer 64-bit chips
- huge overhaul of cmake and the readme
- added a wallet API for the GUI
- added a fee multiplier and reduced fees
- made monero-wallet-cli more robust when handling corrupt caches
- prompt twice for a wallet password to avoid password issues
- improved daemon 'status' details, including time to the next fork
- more bug fixes than you can shake a stick at
- temporary patch (via a predefined user-agent) for the CSRF attack against monero-wallet-cli's RPC API, as disclosed by Henry Hoggard
## Updating: Blockchain Conversion
Due to the space savings and performance gains it is again 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.
Alternatively, you can use ```blockchain_export``` from your previous install to export your current blockchain, then delete the lmdb folder in your working directory, and finally use ```monero-blockchain-import``` from 0.10.0 to reimport it.
## Contributors for this Release
This release was the direct result of 28 people who worked, largely unpaid and altruistically, to put out 725 commits containing 15 332 new lines of code. We'd like to thank them very much for their time and effort. In no particular order they are:
- redfish
- luigi1111
- moneromooo
- rckngOpossum
- Howard Chu
- Riccardo Spagni
- smooth
- iDunk
- jw
- Casey Marshall
- warptangent
- Jacob Torrey
- Thomas Winget
- guzzi_jones
- Shen Noether
- arb0r
- tobiasw2
- osensei
- Quanah Gibson-Mount
- eiabea
- Ilya Kitaev
- awfulcrawler
- anonimal
- Mike C
- mWo12
- NanoAkron
- dEBRUYNE
- blashyrkh
## Official Download Links
- [Windows, 64-bit](https://downloads.getmonero.org/monero.win.x64.v0-10-0-0.zip)
- [Windows, 32-bit](https://downloads.getmonero.org/monero.win.x86.v0-10-0-0.zip)
- [macOS, 64-bit](https://downloads.getmonero.org/monero.mac.x64.v0-10-0-0.tar.bz2)
- [Linux, 64-bit](https://downloads.getmonero.org/monero.linux.x64.v0-10-0-0.tar.bz2)
- [Linux, 32-bit](https://downloads.getmonero.org/monero.linux.x86.v0-10-0-0.tar.bz2)
- [Linux, ARMv7](https://downloads.getmonero.org/monero.linux.arm7.v0-10-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-10-0-0.zip, 33453727a8a49e07605dfee4b16aeb78816238a0e5c07dbaf19840f56f8d2cd4
- monero.win.x86.v0-10-0-0.zip, b0b7898050e6de2bc2aa443fa783cf275683513c0d3714e66fe00e2c75378af6
- monero.mac.x64.v0-10-0-0.tar.bz2, 204babf52d76e513d1f16527be4b3fb30d3ffbdd7528bf3997e4c1b5b301c9a8
- monero.linux.x64.v0-10-0-0.tar.bz2, 6fe4cdb98d6ea7d2eded79841f70cb64edb840fcb2c84b904a1114424cffc5b1
- monero.linux.x86.v0-10-0-0.tar.bz2, 89c9d2904c0de308eb31695af70084008c5880a2c0628de2fee8e47dd23967ea
- monero.linux.arm7.v0-10-0-0.tar.bz2, cced4cad630e6b5e7131b9d079c3d176dfea79915b9080bdba199508c69e377b

41
_posts/2016-09-21-a-statement-on-the-mwr-labs-disclosure.md
View File

@ -1,41 +0,0 @@
---
layout: post
title: A Statement on the MWR Labs Disclosure
summary: Clarifying some misconceptions and statements
tags: [core, rpc]
author: Riccardo Spagni (fluffypony)
---
## Statement
There seem to be some misconceptions and even outrightly false statements being made around the unauthenticated RPC "bug" that was ["discovered" by MWR Labs](https://labs.mwrinfosecurity.com/advisories/csrf-vulnerability-allows-for-remote-compromise-of-monero-wallets/), and we'd like to make certain facts of the matter clear.
First off, it's important to remember that Monero is an unfunded open-source project, and the project only moves as fast as the unpaid volunteers that put their time and effort in. The Monero Core team act as stewards of the project, but we cannot represent every possible developer or contributor, and we certainly can't represent every user. Thus, this statement is from our position and ours alone.
MWR Labs did indeed contact us and responsibly disclose the CSRF attack. This was not an unknown issue to the community - see, for instance, this StackExchange comment: http://monero.stackexchange.com/a/777/47, and this was also highlighted by Juliano Rizzo from Coinspect in 2014.
In truth, RPC authentication has taken something of a back seat, as we have been working on replacing the RPC layer with 0MQ, which has support for both encryption and authentication. The RPC interface will live on in an independent stub, and will gain authentication and TLS support when someone is willing and able to work on that. In addition, the official Monero GUI doesn't use the RPC layer, and directly implements the libwallet_api for all its wallet functions.
The unauthenticated RPC has proven useful, though, as it is the only way for exchanges, mining pools, and integrators to integrate Monero. Exchanges, pools, and integrators are not at risk with this CSRF attack, as it is unthinkable that a custodial service would host a hot wallet on a computer that has a browser - these are extremely sensitive systems and the hot wallet would be hosted in an extremely well-defended environment, with most of the funds in an off-site cold wallet, lest all the deposited funds get stolen.
Thus, libraries such as MoneroNJS and Monero NodeJS cannot be said to be "vulnerable" to this, because they are libraries that are used by integrators and not by any software that would run on a machine with a browser in the background. No automated system that has a hot wallet should ever run in such an insecure environment, and developers are keenly aware of this. Statements from MWR Labs claiming that those libraries are vulnerable are technically true, in a sense, but that observation is like saying that all Monero wallets are at risk if you use "password" as your password and also post your wallet file on Dropbox and share the link on Reddit - technically true, but a largely useless observation.
Similarly, MWR Lab's claims of certain wallets being vulnerable is equally useless. MoneroGui.Net, for instance, has a huge note on the README highlighting that the project is discontinued. The same goes for bitmonero-qt and MiniNodo, both of which are unmaintained. All of these wallets wouldn't even work with the current version of Monero, so they're technically vulnerable, but it's not even possible for anyone to use them.
The only two wallets in MWR Lab's list that are actually vulnerable, and are actually in use, are bigreddmachine's Google Chrome wallet, and jwinterm's lightWallet2. In response to the disclosure, we added a quick patch to provide a way for both of these wallets to prevent the attack. They, in turn, patched their clients accordingly.
We did not enable the functionality by default for several reasons:
1. If we'd provided a flag to disable the functionality it would create a false sense of security if one of the actively developed wallets decided to just pass that flag as a quick "fix".
2. It would have broken all the mining pools, and since the mining pool software is largely fragmented and not centrally maintained there is a great chance that pool operators would have struggled to add support of their own accord (unless we added a disable flag, which just leads to point number 1)
3. It would have broken all integrators and merchants, and they would have to code in a subsystem that is going to fall away within a few months once we've had a chance to re-address the RPC authentication matter.
It is important to note that this is not a flaw in Monero, or in the implementation, or in the cryptography. This is not even something that you could encounter simply by using monero-wallet-cli. You would have to be actively using monero-wallet-cli in RPC mode, on a particularly vulnerable machine, and then click on a malicious link on a website using a browser on that same computer.
Not only is this patched, but the two actively-developed clients that were actually affected by it have been patched, and this was all done in a way that is not disruptive to existing server-side software.
More importantly, ***since monero-wallet-cli does not enable RPC mode by default, there is nothing that is vulnerable in it unless the user actively enables a setting that allows for someone to remotely control the wallet***.
We trust that MWR Labs will note this in their advisory, and adjust it accordingly.
*- The Monero Core Team*

447
_posts/2016-10-02-logs-for-the-Kovri-dev-meeting-held-on-2016-10-02.md
View File

@ -1,447 +0,0 @@
---
layout: post
title: Logs for the Kovri Dev Meeting Held on 2016-10-02
summary: Brief review of what has been completed since last meeting, Salti (a Firefox extension similiar to the Tor Browser Bundle), Kovri Logo, code & open tickets discussion, Kovri API discussion, Kovri and Monero integration
tags: [dev diaries, i2p, crypto]
author: dEBRUYNE / fluffypony
---
*October 2nd, 2016*
# Overview
An overview [can be found on Hello Monero](https://hellomonero.com/article/monero-and-kovri-dev-meeting-note-highlights-2016-10-02)
# Logs
**\<fluffypony>** anonimal: all yours :)
**\<meeting-bot> [anonimal]** 1. Greetings
**\<meeting-bot> [anonimal]** 2. Brief review of what's been completed since the previous meeting
**\<meeting-bot> [anonimal]** 3. ∫alti https://github.com/EinMByte/salti
**\<meeting-bot> [anonimal]** 4. "Kovri Garlic Router Project" + logo
**\<meeting-bot> [anonimal]** 5. #46
**\<meeting-bot> [anonimal]** 6. #337 https://geti2p.net/en/docs/naming
**\<meeting-bot> [anonimal]** 7. API discussion with `#monero-dev` (#350 #351)
**\<meeting-bot> [anonimal]** 8. Code + ticket discussion / Q & A
**\<meeting-bot> [anonimal]** 9. Any additional meeting items
**\<meeting-bot> [anonimal]** 10. Confirm next meeting date/time
**\<meeting-bot> [anonimal]** 1. Greetings
**\<meeting-bot> [i2p-relay] {-moneromooo}** UDP meeting
**\<meeting-bot> [anonimal]** Hi
**\<meeting-bot> [EinMByte]** Hi
**\<meeting-bot> [anonimal]** 2. Brief review of what's been completed since the previous meeting
**\<meeting-bot> [anonimal]** Areas of work done or completed since last meeting 3 weeks ago:
**\<meeting-bot> [anonimal]** - Transports improvements/fixes and EinMByte's SSU branch was merged!
**\<meeting-bot> [anonimal]** - Client/app improvements/fixes and client-crypto related (client signing type, https ciphers, etc.)
**\<meeting-bot> [anonimal]** - Almost all Coverity issues resolved, still a handful left
**\<meeting-bot> [anonimal]** - Fixes/enhancements and more
**\<meeting-bot> [anonimal]** - pero's fantastic work with the logo
**\<meeting-bot> [anonimal]** Oh, .ny new open issues - that's a good thing though, right? ;)
**\<fluffypony>** lol
**\<meeting-bot> [anonimal]** Anything else did I miss for 2. or move onto 3.?
**\<meeting-bot> [EinMByte]** No, go ahead. I have only limited time so let's be productive
**\<fluffypony>** 3 plz
**\<meeting-bot> * anonimal** having hard time keeping track of all the work that passes over several weeks; its usually a very broad range of areas
**\<meeting-bot> [anonimal]** 3. ∫alti https://github.com/EinMByte/salti
**\<meeting-bot> [anonimal]** So, EinMByte and I are starting preliminary work on a firefox extension that will tremendously help Kovri and I2P
**\<meeting-bot> [anonimal]** I just want to mention this here in case there are any interested webdevs
**\<meeting-bot> [anonimal]** Anything you want to add EinMByte?
**\<fluffypony>** Salti is basically like the Kovri GUI :-P
**\<meeting-bot> [EinMByte]** fluffypony: No it isn't
**\<meeting-bot> [EinMByte]** The kovri GUI is called qtoopie
**\<meeting-bot> [anonimal]** EinMByte: no, the GUI does not exist yet.
**\<meeting-bot> [anonimal]** qtoopie is an i2pcontrol client.
**\<meeting-bot> [EinMByte]** Salti is a firefox add-on similar to Tor browser bundle
**\<fluffypony>** lol
**\<meeting-bot> [EinMByte]** anonimal: Yes (but see also the relevant zzz.i2p thread from long ago)
**\* fluffypony** was making a joke
**\<meeting-bot> * anonimal** doesn't have time to search zzz.i2p, link appreciated
**\<meeting-bot> [anonimal]** Any webdevs present?
**\<meeting-bot> * EinMByte** doesn't have time to find zzz.i2p topic
**\<patthehuman>** i could technically be a webdev
**\<patthehuman>** im c/c++ swift/obj-c nodejs/MEAN stack
**\<meeting-bot> [anonimal]** Hi patthehuman. Have you done any work with firefox add-ons?
**\<patthehuman>** no, however, i dont think it would be very difficult
**\<meeting-bot> [EinMByte]** We won't be needing very complex stuff by the way, just using the webextensions API
**\<patthehuman>** would it be chrome and firefox..?
**\<meeting-bot> [anonimal]** patthehuman: webext I believe could support both? but we're aiming for firefox.
**\<meeting-bot> [EinMByte]** (we'll be setting a few settings and intercepting a few requests)
**\<meeting-bot> [EinMByte]** patthehuman: yes
**\<patthehuman>** mk
**\<meeting-bot> [anonimal]** patthehuman: we can give more details after the meeting if you idle #kovri-dev
**\<meeting-bot> [EinMByte]** (although initially firefox, but the API should be mostly the same)
**\<patthehuman>** ok
**\<meeting-bot> [anonimal]** Anything else on 3.?
**\<patthehuman>** ill stick around, interested in hearing full scale
**\<meeting-bot> [EinMByte]** Let's move to 4
**\<meeting-bot> [anonimal]** 4. "Kovri Garlic Router Project" + logo
**\<meeting-bot> [anonimal]** pero: you there?
**\<pero>** yep
**\<pero>** want me to take over?
**\<meeting-bot> [anonimal]** What do you have for us today?
**\<meeting-bot> [anonimal]** Let's spend very little time with the visual aspect, we have bigger issues to tackle with kovri
**\<meeting-bot> [anonimal]** Just a run down so everyone knows where we are
**\<meeting-bot> [anonimal]** And links if possible
**\<pero>** http://imgur.com/a/ptOHb
**\<pero>** after a 'long' process we're down to 3 fonts
**\<pero>** the idea is to pick the font with the best looking letters that comprise the word kovri
**\<meeting-bot> [anonimal]** And what about https://i.imgur.com/UDsSuTg.png
**\<pero>** and/or eliminate some concepts
**\<meeting-bot> [anonimal]** I guess Coral is out of the question
**\<patthehuman>** lato second from bottom
**\<pero>** yea coral was cut
**\<pero>** work sans is largely similar and coral seemed inferior on some letters as well as less versatile at smaller font sizes iirc
**\<meeting-bot> [EinMByte]** I'd also drop open sans
**\<pero>** in the 'a' system
**\<pero>** exo 2 is the logo font - but it doesn't work as well for text
**\<pero>** so i chose open sans to complement it
**\<meeting-bot> [EinMByte]** Sorry, I mean the exp 2 / open sans combination
**\<pero>** a5 features exo2 as subtext so you can see how that would look like
**\<meeting-bot> [EinMByte]** But overall, the differences are really minor. Just trying to reduce the search space
**\<pero>** i personally think not going with A or B would be a mistake
**\<pero>** their K is really nice and adds a subtle touch of personality
**\<meeting-bot> [anonimal]** pero: its unfair because I can't accurately compare c4 because of orange subtext
**\<pero>** hmm
**\<meeting-bot> [anonimal]** I prefer work sans because the k contracts with the orange curve in the garlic
**\<meeting-bot> [anonimal]** So is our next step font?
**\<pero>** http://imgur.com/a/DOcyy
**\<meeting-bot> [anonimal]** Is subtext really that thick with work sans? Eww
**\* fluffypony** isn't wild about the orange subtext
**\<pero>** yea the orange subtext sucks imo
**\<meeting-bot> [EinMByte]** Ok, let's handle this another time
**\<meeting-bot> [EinMByte]** (or use a random number generator)
**\<pero>** no it could be thinner
**\<meeting-bot> [EinMByte]** Let's go with column b then
**\<meeting-bot> [anonimal]** lol no way on the random gen
**\<fluffypony>** lol random number gen could be fun
**\<pero>** imgur is also 'optimizing' the png
**\<fluffypony>** "best of 3?"
**\<pero>** keep in mind ^^^
**\<endogenic>** just my two cents - you probably want the text to be relatively heavier than the logo so it jumps out because it's not an english or otherwise generally known word, and so the logo imo should be visually secondary when composed with the name. think about readability, especially if the user doesn't have 20/20 vision or is in a hurry
**\<endogenic>** the actual face itself is not a huge issue imo
**\<meeting-bot> [anonimal]** pero: let's narrow down our options to rows 2, 4, and 6
**\<meeting-bot> [anonimal]** Can you throw those onto a page?
**\<pero>** there probably will be instances where the 'router project' text is unnecessary
**\<fluffypony>** I think rows 3 and 4 won't work because, as endogenic pointed out, kovri is not an English word
**\<fluffypony>** looks like kavri
**\<pero>** and just the logo and kovri would suffice
**\<meeting-bot> [anonimal]** Are we all talking about https://i.imgur.com/Ge1FZTp.png ?
**\<pero>** ideally as a brand it should be able to stand out on its own
**\<meeting-bot> [EinMByte]** Yes, the garlic as an "o" could be confusing
**\<fluffypony>** anonimal no, I'm looking at http://imgur.com/a/DOcyy
**\<meeting-bot> [anonimal]** Same thing
**\<endogenic>** pero: for that reason consider favoring options with tighter kerning
**\<fluffypony>** oh
**\<fluffypony>** lol
**\<meeting-bot> [anonimal]** Who in their right mind things that garlic is an 'A'?
**\<pero>** another thing to add
**\<meeting-bot> [EinMByte]** So let's narrow it down to 2 and 6
**\<meeting-bot> [i2p-relay] {-ArticMine}** 2 in Open Sans is the most readable
**\<pero>** the garlic wasn't designed with this use in mind
**\<pero>** the garlic could be optimized down the road
**\<meeting-bot> [EinMByte]** anonimal: Remember that the spectator potentially doesn't know "kovri"
**\<pero>** ideally after a font has been chosen
**\<pero>** to more resemble an o and to slide seamlessly into the font
**\<meeting-bot> [EinMByte]** At least it might add additional confusion, which is bad
**\<endogenic>** EinMByte: exactly. the question is how it could be confirmed it's not an A
**\<meeting-bot> [anonimal]** Ok, all in favor of exo2
**\<pero>** i'm however not qualified to do that
**\<meeting-bot> [anonimal]** Any votes for exo2/open sans?
**\<meeting-bot> [i2p-relay] {-ArticMine}** Yes
**\<meeting-bot> [EinMByte]** exo2 is fine for me, but I also agree that the "Garlic Routing Project" text should be optional
**\<meeting-bot> [i2p-relay] {-ArticMine}** exo2 is fine
**\<meeting-bot> [EinMByte]** (So on the website, for example, we should have the text. But potentially not everywhere)
**\<meeting-bot> [EinMByte]** Any objections against exo2?
**\<meeting-bot> [anonimal]** I count 2 votes for exo2/open sans.
**\<meeting-bot> [anonimal]** Any votes for Lato?
**\<pero>** i vote lato
**\<meeting-bot> [EinMByte]** Any votes for work sans?
**\<endogenic>** i also like lato
**\<fluffypony>** lato from my side
**\<meeting-bot> [EinMByte]** Ok, let's eliminate work sans.
**\<meeting-bot> [anonimal]** 3 votes for Lato.
**\<meeting-bot> [anonimal]** Any votes for Work Sans?
**\<meeting-bot> [anonimal]** 0 votes for Work Sans
**\<meeting-bot> [anonimal]** I haven't voted
**\<meeting-bot> * anonimal** looks
**\<patthehuman>** i vote for Lato
**\<meeting-bot> [EinMByte]** Are we going to decide on the logo today or not? If so, we should hurry (if we want to discuss API still)
**\<meeting-bot> [anonimal]** pero: why does a6 look so fat?
**\<pero>** shouldn't be that difficult to throw up exo2 versions of lato variants in the future
**\<pero>** in case that's still up for debatable
**\<meeting-bot> [anonimal]** EinMByte that's up to moneromooo because I really don't think anyone else there is interested in API chat (afaict)
**\<pero>** because it is fat :P
**\<patthehuman>** yb
**\<meeting-bot> [i2p-relay] {-ArticMine}** I have to leave
**\<patthehuman> im interested in api cha
**\<endogenic>** maybe we should have a #monero-design? :)
**\<meeting-bot> [anonimal]** EinMByte if we don't decide soon, website doesn't get done
**\<pero>** i went with a heavier weight for that variant arbitrarily
**\<meeting-bot> [i2p-relay] {-moneromooo}** I have no particular wish about that, don't mind me.
**\<fluffypony>** let's move ahead
**\<fluffypony>** the logo already took up the entire last meeting
**\<meeting-bot> [anonimal]** 3 minutes
**\<meeting-bot> [anonimal]** Let me vote please!
**\<meeting-bot> [EinMByte]** We should at least plan when to discuss the API, so let's decide quickly on the logo :)
**\<patthehuman>** LATO
**\<meeting-bot> [anonimal]** pero: why should I choose exo2
**\<pero>** its advantage seems to be technological look
**\<meeting-bot> [EinMByte]** anonimal: Please decide, we're moving too slowly here
**\<pero>** a secondary adv is that we can pair with open sans which is extremely versatile
**\<meeting-bot> [anonimal]** EinMByte, we have 30 minutes, please be patient.
**\<pero>** can be used at extremely small sizes for things like massive tables of data
**\<pero>** whereas using open sans to complement a lato branding scheme wouldn't make much sense
**\<meeting-bot> [anonimal]** pero: how about this: can you whip up another sample for after the meeting but *only* exo2 and lato and doing various sizes that you think are appropriate?
**\<pero>** i think that makes the most sense as a next step
**\<meeting-bot> [anonimal]** We can probably come to a final conclusion post-meeting or sometime this week.
**\<meeting-bot> [anonimal]** Ok, thanks pero.
**\<meeting-bot> [anonimal]** Moving on,
**\<meeting-bot> [anonimal]** 5. #46
**\<meeting-bot> [anonimal]** fluffypony: ^
**\<meeting-bot> [EinMByte]** fluffypony...
**\<pero>** did you skip over the 'garlic router' discussion?
**\<fluffypony>** ok - got a first draft to push up, but need to finish fixing the forum first
**\<meeting-bot> [anonimal]** pero: just go with it for now but also do without subtext too please
**\<meeting-bot> [EinMByte]** ETA?
**\<patthehuman>** whats wrong with the forum?
**\<pero>** ok
**\<fluffypony>** EinMByte: no clue
**\<fluffypony>** patthehuman: PHP7 broke a bunch of stuff
**\<meeting-bot> [anonimal]** patthehuman: fluffypony is fixing it
**\<patthehuman> ok
**\<fluffypony>** some of it was non-obvious until we had a new dep and composer wrecked everything
**\<patthehuman>** ill be around if you need help
**\<meeting-bot> [EinMByte]** Let's not discuss the monero forum here
**\<patthehuman>** php7 wrecked a lot of my shit at work so ive been down this path
**\<patthehuman>** sure
**\<meeting-bot> [anonimal]** fluffypony: should EinMByte and I not ask for ETA for website?
**\<fluffypony>** anonimal: I'll push my changes once the forum is back up, since all static objects are served off that repo anyway
**\<meeting-bot> [anonimal]** Worst case scenario, we release with just a repo and wiki.
**\<meeting-bot> [anonimal]** Ok, moving on
**\<meeting-bot> [anonimal]** 6. #337 https://geti2p.net/en/docs/naming
**\<meeting-bot> [anonimal]** What happens is that any addresses that are saved with an addresshelper are simply inserted into ./addressbook but not user_hosts.txt (or similar)
**\<meeting-bot> [anonimal]** There are also various other issues, let me pull up the ticket
**\<meeting-bot> [anonimal]** "For this ticket, we should discuss if we're to have separate subscription files because we currently only use hosts.txt. Also, if we hand edit the file, it will be overridden upon next fetch from a any publisher.
**\<meeting-bot> [anonimal]** With a little design work, we can easily implement other files that won't be overridden. There's also the question of whether we want to have separate files for separate publishers."
**\<meeting-bot> [EinMByte]** Easiest would be to add an additional file that's user-configurable, but maybe it's nicer to just update incrementally
**\<meeting-bot> [anonimal]** hosts.txt is updated every 12 hours. I think we should have user-configurable too.
**\<meeting-bot> [EinMByte]** (although that prings additonal problems)
**\<meeting-bot> [EinMByte]** \*brings additional
**\<meeting-bot> [Zenified]** >prings?
**\<meeting-bot> [EinMByte]** So lets have "hosts.txt" and several other files for the different subscriptions?
**\<meeting-bot> [anonimal]** Yes, that was the idea. I guess the question was how many:
**\<meeting-bot> [EinMByte]** one for each subscription
**\<meeting-bot> [EinMByte]** If there's conflicts, they would ideally be reported to the user
**\<meeting-bot> [anonimal]** That'll be tricky if each publisher calls their subscription hosts.txt, we can rename/adjust as needed or concatenate it into on user_hosts.txt
**\<meeting-bot> [anonimal]** \*a user_hosts.txt
**\<meeting-bot> [anonimal]** And duplicates would be wasteful
**\<meeting-bot> [anonimal]** (this whole I2P naming scheme is annoying)
**\<meeting-bot> [EinMByte]** We should rename the files locally
**\<meeting-bot> [anonimal]** You mean expect the user to call it whatever they want?
**\<meeting-bot> [EinMByte]** The only hosts.txt file would be the one that the user can change?
**\<meeting-bot> [anonimal]** No, hosts.txt would always be static and provided upstream, always overridden every 12 hours
**\<meeting-bot> [EinMByte]** No, when downloading a subscription, put it in a dedicated file?
**\<meeting-bot> [anonimal]** I'm not sure what you're getting at
**\<meeting-bot> [EinMByte]** Ok, so you want "user_hosts.txt" to be a wile with custom hosts?
**\<meeting-bot> [EinMByte]** \*file
**\<meeting-bot> [EinMByte]** That would also work, sure.
**\<meeting-bot> [anonimal]** We only need 2: one that's always clobbered every 12 hours, and one that's never clobbered
**\<meeting-bot> [anonimal]** The one that's never clobbered needs a name. It's "custom" and "private" though.
**\<meeting-bot> [anonimal]** Also, should every address added with i2paddresshelper \*also\* be inserted into said custom file.
**\<meeting-bot> [EinMByte]** Yes, but we want multiple subscriptions right?
**\<meeting-bot> [anonimal]** I don't even think java i2p does that, but I think it should be done.
**\<meeting-bot> [EinMByte]** But not all publishers provide the same set of hosts
**\<meeting-bot> [EinMByte]** Hence, the need for several hosts.txt files that care clobbered every 12 hours
**\<meeting-bot> [EinMByte]** \*are
**\<meeting-bot> [anonimal]** Ok, we'll just have to name subscriptions by uri.host()
**\<meeting-bot> [EinMByte]** Yes, I guess so
**\<meeting-bot> [anonimal]** and make a private_hosts.txt that is *never* clobbered
**\<meeting-bot> [anonimal]** That actually makes the most sense now, imho.
**\<meeting-bot> [EinMByte]** Yes, that or have an actual database of hosts rather than a bunch of files
**\<meeting-bot> [anonimal]** We can deal with duplicates and effiency later unless it becomes a massively huge issue.
**\<meeting-bot> [anonimal]** Yeah, a *real* Db
**\<meeting-bot> [anonimal]** While we're at it we can consider that for ./NetDb
**\<meeting-bot> [EinMByte]** But if we get a real database, it should also be used for profiles etc
**\<meeting-bot> [anonimal]** Didn't i2pcpp do something like that?
**\<meeting-bot> [EinMByte]** Yes, it used sqlite
**\<meeting-bot> [anonimal]** Why was that not continued/exploited?
**\<meeting-bot> [anonimal]** Was it not 'efficient' enough for the magician?
**\<meeting-bot> [EinMByte]** For the same reason that i2pcpp was not continued
**\<fluffypony>** you can always use LMDB
**\<meeting-bot> [EinMByte]** i2pd isn't based on i2pcpp at all
**\<meeting-bot> [anonimal]** I know, but he obviously looked at it.
**\<meeting-bot> [anonimal]** I don't like how one can't use network filesystems with LMDB
**\<meeting-bot> [EinMByte]** Yes, but decided not add the dependency or so
**\<meeting-bot> [EinMByte]** So let's create an issue for using an actual database?
**\<meeting-bot> [anonimal]** EinMByte then I think we should research sqlite or LMDB or some other option for a longterm database solution. Sound reasonable?
**\<meeting-bot> [EinMByte]** Yes
**\<meeting-bot> [anonimal]** Ok, anything else on addressbook?
**\<fluffypony>** I think it's all been addressed
**\<meeting-bot> [EinMByte]** Can you create the issue? If so, let's move on to 7
**\<meeting-bot> [anonimal]** Done, #385
**\<meeting-bot> [anonimal]** 7. API discussion with #monero-dev (#350 #351)
**\<meeting-bot> [EinMByte]** Monero developers here?
**\<meeting-bot> [i2p-relay] {-moneromooo}** Yes
**\<meeting-bot> [EinMByte]** What I mainly want is a clear set of requirements for the API
**\<meeting-bot> [i2p-relay] {-moneromooo}** Oh I see. Oh. Hmm.
**\<fluffypony>** yes
**\<meeting-bot> [i2p-relay] {-moneromooo}** Well, I'm not very much acquainted with the way CN P2P works in the first place...
**\<meeting-bot> [EinMByte]** e.g. do you want to use streaming, I2NP directly, datagrams...?
**\<meeting-bot> [i2p-relay] {-moneromooo}** It's all TCP, with a simple HTTP server at hte moment.
**\<meeting-bot> [Zenified]** LMDB is the the real deal
**\<meeting-bot> [i2p-relay] {-moneromooo}** Doesn't mean it has to stay that way though.
**\<meeting-bot> [EinMByte]** So you need connections? Probably streaming then
**\<meeting-bot> [anonimal]** Question: how is monero-core currently talking with monerod?
**\<meeting-bot> [EinMByte]** The main question to ask is whether you need 1) reliability 2) connections
**\<meeting-bot> [i2p-relay] {-moneromooo}** fluffypony: did you intend to replace the P2P stuff with 0MQ ?
**\<meeting-bot> [anonimal]** EinMByte I thought we discussed not doing network-based API
**\<meeting-bot> [i2p-relay] {-moneromooo}** anonimal: JSON RPC AFAIK.
**\<fluffypony>** anonimal: JSON RPC API, but we're replacing that with 0MQ
**\<fluffypony>** but Kovri will serve the p2p layer
**\<fluffypony>** not the RPC layer
**\<fluffypony>** moneromooo: yes with ZMTP
**\<fluffypony>** http://zmtp.org
**\<fluffypony>** maybe we bundle the ZMTP change and Kovri integration together ?
**\<meeting-bot> [EinMByte]** anonimal: No, but we need to know what aspects of the API are most important
**\<meeting-bot> [EinMByte]** e.g. do we need to focus on making I2NP accessible, or on making streaming accessible
**\<meeting-bot> [EinMByte]** Or does monero want to be able to create tunnels, etc.
**\<meeting-bot> [anonimal]** I think monero wants something as simple as a SOCKS proxy
**\<meeting-bot> [i2p-relay] {-moneromooo}** We need to be able to find peers without knowing their address in advance.
**\<meeting-bot> [anonimal]** If connection isn't made, tough luck and try again later
**\<meeting-bot> [anonimal]** Oh, nevermind then
**\<meeting-bot> [i2p-relay] {-moneromooo}** At the moment, this is done by bootstrapping from a seed server.
**\<fluffypony>** moneromooo: DNS seeds
**\<meeting-bot> [EinMByte]** So 0MQ would be TCP-based, so would use streaming
**\<fluffypony>** yeah so we can do the same
**\<meeting-bot> [i2p-relay] {-moneromooo}** That... might be DNS ? I'm not sure.
**\<fluffypony>** we get seed nodes from DNS seeds with hardcoded fallbacks
**\<fluffypony>** and then we connect to their .i2p address on the appropriate port
**\<meeting-bot> [i2p-relay] {-moneromooo}** And all the DNSSEC or DNScrypt that fluffypony knows about.
**\<fluffypony>** and request peers
**\<fluffypony>** and we get a list of .i2p addresses and ports
**\<meeting-bot> [EinMByte]** Do you want to create a tunnel and then connect to that, or do you want to have a C++ API to also send messages?
**\<meeting-bot> [anonimal]** Has monero-side drawn up any diagrams for these ideas?
**\<fluffypony>** anonimal: that's how it currently works, not ideas
**\<meeting-bot> [i2p-relay] {-moneromooo}** Is there a concept of "multicast", where we could send a query to "whomever it may concern" ?
**\<meeting-bot> [anonimal]** fluffypony: you currently get a list of .i2p address and ports?
**\<fluffypony>** EinMByte: we can do either
**\<meeting-bot> [EinMByte]** moneromooo: No, don't think so
**\<fluffypony>** anonimal: we currently get ipv4 addresses, but we'd perform exactly the same function to get i2p-based peers
**\<meeting-bot> [EinMByte]** moneromooo: But I can think about multicast in future I2P and even get a proposal going, but it would take years before we actually get it
**\<meeting-bot> [i2p-relay] {-moneromooo}** The intent, in this case, would be to request replies from peers that run monero.
**\<meeting-bot> [i2p-relay] {-moneromooo}** (without having to rely on centralized seeds)
**\<meeting-bot> [EinMByte]** So for DNS, you could use repliable datagrams or streaming.
**\<meeting-bot> [anonimal]** EinMByte moneromooo: multicast is mentioned in future work https://geti2p.net/en/docs/how/garlic-routing
**\<fluffypony>** DNS seed nodes work, I really don't think we need to replace that
**\<fluffypony>** but what we would do on first sync is get both ipv4 *and* i2p peers
**\<meeting-bot> [EinMByte]** anonimal: Yes, but there's no decent proposal right now. I also need to check out the LS2 proposal, it somewhat relates
**\<meeting-bot> [EinMByte]** fluffypony: Ok, assuming you can store I2P addresses in DNS records
**\<meeting-bot> [anonimal]** moneromooo: proposals also sit there for years so I wouldn't expect anything to happen anytime soon
**\<fluffypony>** after that a node maintains its own white / black / gray lists, and gets a peerlist every time it connects to a new peer
**\<fluffypony>** EinMByte: TXT records :)
**\<meeting-bot> [EinMByte]** fluffypony: Ok.
**\<meeting-bot> [i2p-relay] {-moneromooo}** It's something that seems fairly self contained anyway, so could be changed at a later date.
**\<meeting-bot> [EinMByte]** So you need to decide between 1) use I2P direcly with a C++ API 2) create tunnels using a C++ API and then connect to them with SOCKS or so
**\<meeting-bot> [i2p-relay] {-moneromooo}** I don't know the difference between these options.
**\<meeting-bot> [anonimal]** I don't think they need to care about creating tunnels
**\<meeting-bot> [EinMByte]** In any case kovri wants to provide the API to do 1
**\<fluffypony>** yes - and I'd probably lean towards the C++ API
**\<meeting-bot> [anonimal]** They need to know if they can get through or not, that's a given though.
**\<meeting-bot> [EinMByte]** So it looks like monero would be using esentially use the streaming API?
**\<meeting-bot> [i2p-relay] {-moneromooo}** I'd imagine something that looks like a socket API, just using I2P addresses instead of IP:port :)
**\<meeting-bot> [EinMByte]** s/use//
**\<meeting-bot> [i2p-relay] {-moneromooo}** By streaming, do you mean TCP ?
**\<meeting-bot> [EinMByte]** But maybe for DNS you'd also want repliable datagrams
**\<meeting-bot> [anonimal]** I can't answer for them until one of them sits down and reads the spec
**\<meeting-bot> [EinMByte]** moneromooo: streaming is something that looks a lot like TCP but over I2P
**\<meeting-bot> [i2p-relay] {-moneromooo}** Then that's what we'd use in a straight port, modulo the seed stuff.
**\<meeting-bot> [EinMByte]** Most applications use streaming one way or another
**\<meeting-bot> [EinMByte]** I don't know your architecture, but it may be simpler to create a tunnel if you want to route everything to I2P
**\<meeting-bot> [EinMByte]** \*through
**\<meeting-bot> [anonimal]** fluffypony moneromooo: what were the arugments against using SOCKS proxy?
**\<meeting-bot> [i2p-relay] {-moneromooo}** By creating a tunnel, do you mean selecting the hoops directly ?
**\<fluffypony>** no arguments - we have no idea what you'd recommend :)
**\<meeting-bot> [anonimal]** EinMByte: KISS
**\<meeting-bot> [EinMByte]** moneromooo: using tunnel in the client-like context here, like a local SOCKS proxy which delivers to a dedicated I2P endpoint
**\<meeting-bot> [anonimal]** monero: we have to meet half-way somehow. I'll try to dig into more monero if you guys can dig into more kovri.
**\<meeting-bot> [EinMByte]** SOCKS seems overly complicaed
**\<meeting-bot> [EinMByte]** \*complicated
**\<meeting-bot> [anonimal]** IMHO, we should be more on a level playing field at least term wise by now.
**\<fluffypony>** anonimal: we'll implement whatever you guys recommend
**\<meeting-bot> [EinMByte]** If you need many connections, you can't use the "create a local SOCKS proxy" or so
**\<meeting-bot> [anonimal]** EinMByte: how so? In terms of providing useful feedback and control, yes.
**\<meeting-bot> [i2p-relay] {-moneromooo}** We need several, yes. They're fairly long term. Some will go down, and will be replaced.
**\<meeting-bot> [EinMByte]** Then it would be a lot easier to create tunnels (which use e.g. the streaming protocol) using the C++ API
**\<meeting-bot> [i2p-relay] {-moneromooo}** Both directions, btw. No client/server.
**\<meeting-bot> [EinMByte]** Streaming is both ways, sure
**\<meeting-bot> [EinMByte]** datagrams can also be (if repliable)
**\<meeting-bot> [anonimal]** Ok, so easiest for us is C++ API but is ZMTP worth the extra work?
**\<meeting-bot> [EinMByte]** anonimal: I don't think ZMTP matters to us.
**\<meeting-bot> [i2p-relay] {-moneromooo}** I'd imagine ZMTP is a layer above, and kovri would be oblivious to it.
**\<meeting-bot> [anonimal]** Good.
**\<meeting-bot> [anonimal]** So streaming or datagrams or both?
**\<meeting-bot> [EinMByte]** Question is whether using ZMTP would actually be useful when used above I2P, but I'll leave that to monero devs
**\<meeting-bot> [i2p-relay] {-moneromooo}** Both, please :)
**\<meeting-bot> [EinMByte]** But let's focus on streaming
**\<meeting-bot> [EinMByte]** (since most I2P applications currently use streaming)
**\<meeting-bot> [i2p-relay] {-moneromooo}** But streaming first, yes. We can hardcode peer ids to start with.
**\<fluffypony>** I guess parts of ZMTP would be useless (eg. end-to-end encryption)
**\<meeting-bot> [anonimal]** Ok, C++ API for streaming. That's entirely on us then, for starters.
**\<meeting-bot> [anonimal]** Is this written in stone now EinMByte moneromooo fluffypony?
**\<meeting-bot> [EinMByte]** Let's say it is and move to 8
**\<meeting-bot> [i2p-relay] {-moneromooo}** To the extent I know of how CN uses the network... -_- :D
**\<fluffypony>** yes
**\<meeting-bot> [anonimal]** Yay, big decision step done.
**\<yardman>** whats set in stone?
**\<meeting-bot> [anonimal]** Anything else on 7.?
**\<meeting-bot> [anonimal]** I have one question:
**\<fluffypony>** nope
**\<fluffypony>** yardman: using the i2p C++ API for streaming
**\<meeting-bot> [anonimal]** What homework can we all do so our next API meeting is more productive?
**\<meeting-bot> [anonimal]** kovri c++ API
**\<meeting-bot> [EinMByte]** Design it
**\<meeting-bot> [i2p-relay] {-moneromooo}** Well, I have that feeling that the next month or two will be spent on rct performance from my side...
**\<fluffypony>** anonimal: we haven't really focused on our current p2p layer because of the ZMTP plan
**\<meeting-bot> [anonimal]** moneromooo: you mentioned I should look at networking code?
**\<yardman>** thanks
**\<meeting-bot> [i2p-relay] {-moneromooo}** I didn't, I think. I mentioned I should :D
**\<meeting-bot> [anonimal]** Oh, lol ok
**\<meeting-bot> [i2p-relay] {-moneromooo}** IIRC that p2p code is also kinda new and unfinished.
**\<fluffypony>** so I don't know if we should waste much time on analysis of it, or rather look at i2p as a ZMTP transport
**\<fluffypony>** which could be a VERY nice generalised solution
**\<fluffypony>** that isn't Monero-specific
**\<meeting-bot> [anonimal]** Ok, I'll add API for first thing next meeting.
**\<meeting-bot> [anonimal]** Anything else for 7.?
**\<fluffypony>** nope
**\<meeting-bot> [EinMByte]** Nope, 8 please (need to leave soon)
**\<meeting-bot> [anonimal]** 8. Code + ticket discussion / Q & A
**\<meeting-bot> [anonimal]** We're in overtime, I have nothing to say at the moment really.
**\<meeting-bot> [anonimal]** fluffypony I think there's an assigned ticket you can easily close
**\<meeting-bot> [EinMByte]** Me neither, let's discuss when appropriate
**\<meeting-bot> [anonimal]** (the codedocs one)
**\<meeting-bot> [EinMByte]** Will see how much time I get to do v6 peer testing
**\<fluffypony>** ok will do
**\<meeting-bot> [anonimal]** I'll get to more assigned tickets as well.
**\<meeting-bot> [anonimal]** Ok, moving on.
**\<meeting-bot> [EinMByte]** Also not sure if #187 should still be open
**\<meeting-bot> [anonimal]** 9. Any additional meeting items
**\<meeting-bot> [anonimal]** EinMByte, ok I'll take a look after the meeting.
**\<meeting-bot> [EinMByte]** Ok, no additional meeting items from me
**\<meeting-bot> [anonimal]** Nor I. fluffypony?
**\<meeting-bot> [anonimal]** moneromooo?
**\<fluffypony>** nope
**\<meeting-bot> [anonimal]** #monero-dev?
**\<meeting-bot> [i2p-relay] {-moneromooo}** No
**\<meeting-bot> [anonimal]** 10. Confirm next meeting date/time
**\<meeting-bot> [anonimal]** Next week or two weeks?
**\<meeting-bot> [EinMByte]** 2
**\<meeting-bot> [EinMByte]** (if we want the API on the list of topics)
**\<fluffypony>** 2 weeks
**\<fluffypony>** Oct 16
**\<meeting-bot> [anonimal]** Same for #monero-dev?
**\<meeting-bot> [anonimal]** I'd like to coincide
**\<meeting-bot> [anonimal]** fluffypony: ^
**\<fluffypony>** yes
**\<meeting-bot> [anonimal]** Ok, 2 weeks works for me.
**\<meeting-bot> [anonimal]** THANKS EVERYONE!
**\<fluffypony>** shutting meeting bot down

229
_posts/2016-10-02-overview-and-logs-for-the-dev-meeting-held-on-2016-10-02.md
View File

@ -1,229 +0,0 @@
---
layout: post
title: Overview and Logs for the Dev Meeting Held on 2016-10-02
summary: Review and discussion of Open PRs, brief update on Ring CT, the official GUI, and Trezor for Monero
tags: [dev diaries, core, crypto, 0mq]
author: dEBRUYNE / fluffypony
---
*October 2nd, 2016*
# Overview
An overview [can be found on Hello Monero](https://hellomonero.com/article/monero-and-kovri-dev-meeting-note-highlights-2016-10-02)
# Logs
**\<fluffypony>** Hi all
**\<fluffypony>** starting meeting bot
**\<moneromooo>** I'm none of them.
**\<dEBRUYNE>** I am here
**\<fluffypony>** moneromooo: I know you're here :)
**\<fluffypony>** ok meeting bot is up
**\<dnaleor>** watching
**\<fluffypony>** so
**\<meeting-bot> [anonimal]** #kovri-dev too?
**\<fluffypony>** kovri-dev is roped in too
**\<othe>** k
**\<meeting-bot> [i2p-relay] {-moneromooo}** o
**\<fluffypony>** this is our first post-0.10.0 meeting
**\<fluffypony>** the 0.10.0 release went fairly smoothly
**\<fluffypony>** apart from the boost oddities
**\<fluffypony>** on the Boost serialisation stuff
**\<fluffypony>** it's not really feasible to do a point release just for that just yet - in a few weeks I'll have local build infrastructure that will make releases a lot easier on me
**\<fluffypony>** since I can secure local machines far more easily than Internet-facing machines at a DC
**\<fluffypony>** in the interim, if anyone is struggling with it the easiest thing for them to do is recover their wallet from the seed / keys
**\<moneromooo>** And keep the old cache if they have tx keys they want to keep.
**\<fluffypony>** ^^
**\<fluffypony>** I'd also like to welcome all the new contributors
**\<fluffypony>** even if it's just correcting a spelling error, all contributions are valuable
**\<fluffypony>** and very much appreciated
**\<fluffypony>** one thing I would like to encourage with the new contributors is to submit your GPG key via PR
**\<fluffypony>** and side-channel it to myself or moneromooo or someone so we can independently verify the correct key goes in
**\<fluffypony>** they live in utils/gpg_keys/
**\<meeting-bot> [anonimal]** and if moneromooo says "ok" in your PR, that's a GOOD thing!
**\<fluffypony>** and then once you've done that you can GPG sign your commits with -S
**\<fluffypony>** eg. git commit -S -am "meaningful commit message"
**\<moneromooo>** Only if it's at the start.
**\<patthehuman>** Is there anything that needs to be made for iOS
**\<fluffypony>** lol anonimal
**\<fluffypony>** patthehuman: it's an open-source project, so if you want to build something for iOS then please do
**\<fluffypony>** no need to ask permission or anyway
**\<fluffypony>** I'd be interested to see if we could package a full node for iOS (without the wallet, lest it get removed from the app store)
**\<patthehuman>** sure, i guess i'm wondering more along the lines of what needs to be built
**\<patthehuman>** can you outline how that would work?
**\<fluffypony>** and then an old iPhone or iPod Touch would work as a full node on wifi
**\<fluffypony>** well we have native ARMv8 builds
**\<fluffypony>** and interacting with the daemon over RPC isn't hard
**\<ArticMine>** Why not just go with Cydia on jailbroken iOS?
**\<fluffypony>** but I have no idea if an iOS app would let you arbitrarily launch a process
**\<endogenic>** ArticMine: too few jailbreak their devices, no?
**\<fluffypony>** ArticMine: absolutely - would be nice to be able to launch it as an app tho
**\<patthehuman>** generally apps get removed from the app store if they are simple "remotes"
**\<endogenic>** fluffypony: iOS does not allow you to spawn processes... no NSTask etc equivalent
**\<fluffypony>** ah
**\<TedTheFicus>** ArcticMine: I think Cydia is a good plan B. Not many non tech people are going to have jail broken phones
**\<patthehuman>** right, they have a list of closed API's that will get you banned
**\<fluffypony>** does Objective-C let you also run native C / C++ code?
**\<endogenic>** fluffypony: yep as long as you can compile for an ARM target
**\<endogenic>** compile it*
**\<MK__>** ArticMine : A good idea and a lot of IOS devices have Jailbreak , Remember that XMR are used in the DNM as well
**\<fluffypony>** yeah we have ARMv8 support across the board
**\<endogenic>** Objective-C is a strict superset of C, so any C is good, and C++ can be compiled too
**\<ArticMine>** Net applications Android 69.18% IOS 25.02% market share
**\<fluffypony>** anyway we're getting side-tracked a little - patthehuman feel free to play around with it, if you feel like it
**\<patthehuman>** sure
**\<fluffypony>** so
**\<fluffypony>** ringCT is live in testnet, and more testing would be appreciated
**\<fluffypony>** mWo12's testnet block explorer is helpful
**\<fluffypony>** but performance testing is also immensely useful
**\<fluffypony>** see what cracks under pressure
**\<fluffypony>** we have a short window until the January hard fork, so we need to hammer testnet as much as possible
**\<trustedsetup>** is there a testnet faucet somewhere? or is mining or irc begging for testnet xmr recommended?
**\<fluffypony>** just ask me and I'll send testnet XMR your way
**\<patthehuman>** are there any automation processes that can hammer on testnet?
**\<patthehuman>** i have access to a lot of r510 servers that i could potentially mirror some script to hammer on it
**\<fluffypony>** patthehuman: you could pretty much just write a bash script to send to yourself once a second
**\<fluffypony>** and cycle it that way
**\<patthehuman>** cool
**\<fluffypony>** and then see how your testnet node(s) handle catch ups, and if they keep up with testnet when blocks are bigger
**\<fluffypony>** we also have our new buildbots ticking along nicely
**\<fluffypony>** so we'll be killing off Travis at some point in the coming weeks
**\<fluffypony>** build bot output has been relegated to #monero-bots
**\<fluffypony>** and that channel is relayed to irc2p
**\<meeting-bot> [anonimal]** Thanks pigeons
**\<meeting-bot> [anonimal]** monero-build.i2p is also online
**\<fluffypony>** yeah pigeons has done great work
**\<fluffypony>** at the moment we're building for a ton of platforms
**\<fluffypony>** including macOS 10.9, 10.10, 10.11
**\<fluffypony>** so we should pick up PRs that break compilation more rapidly
**\<fluffypony>** how we handle testing is a bit harder
**\<fluffypony>** especially since some of the tests take several hours to run
**\<fluffypony>** my current leaning is towards nightly builds + tests
**\<fluffypony>** (of master)
**\<fluffypony>** that way we'll catch tests that are broken by any merged PRs
**\<moneromooo>** Daily core_tests would be useful.
**\<fluffypony>** performance_tests would also be useful
**\<fluffypony>** that way we can track anything that has a huge impact on performance
**\<moneromooo>** As long as the outcome can be seen without too many hoops (ie, javacrsipt)
**\<fluffypony>** moneromooo: we'll probably just grab the output, parse it, and shove it in a database
**\<fluffypony>** then we can create a profiler for the site without too many issues
**\<fluffypony>** on the PR side
**\<fluffypony>** has anyone looked at 1082?
**\<patthehuman>** no my apologies for being new but can you elaborate on what 1082 is
**\<fluffypony>** or actually moneromooo: can you give everyone a brief overview of what 1082 does
**\<fluffypony>** oh sorry patthehuman - PR = pull request
**\<fluffypony>** so PR 1082 = https://github.com/monero-project/monero/pull/1082
**\<patthehuman>** yeah im familiar with PR's (worst part of my work day lol)
**\<moneromooo>** Ah, as the comment says, really.
**\<moneromooo>** It just tries to avoid the case where someone sends money just after receiving it.
**\<moneromooo>** That's a common enough case.
**\<fluffypony>** "25% of the outputs are selected from the last 5 days (if possible), in order to avoid the common case of sending recently received outputs again. 25% and 5 days are subject to review later, since it's just a wallet level change."
**\<trustedsetup>** where did the 25% come from? 25% seems somewhat arbitrary. did MRL have input on this number?
**\<moneromooo>** They're aribtrary.
**\<fluffypony>** trustedsetup: the MRL is of the opinion that we're never going to find a "perfect" distribution, and that distribution should be re-evaluated regularly
**\<luigi1112>** Will look at it
**\<fluffypony>** 25% would only be a single output at minimum mixin
**\<trustedsetup>** ok thanks
**\<moneromooo>** It's actually 25%, except if that gives 0, in which case it uses 1.
**\<fluffypony>** moneromooo: and it's 25% including the "real" output, right?
**\<moneromooo>** Yes.
**\<moneromooo>** See line 2744 in wallet2.cpp
**\<fluffypony>** kk
**\<fluffypony>** as to the other open PRs
**\<fluffypony>** most of them are not merged yet due to their being unreviewed
**\<fluffypony>** I try give PRs a little while before reviewing them myself, otherwise I end up being the only reviewer, which is bad for security obvs
**\<fluffypony>** bear in mind that a review is *not* in-depth line-by-line analysis
**\<patthehuman>** pr is just a quick overview
**\<moneromooo>** I'd hope the review does look at all lines.
**\<fluffypony>** yup
**\<fluffypony>** it's a sanity check, and a check for obvious screw-ups, and a check for snuck-in backdoors
**\<fluffypony>** moneromooo: the key there was in-depth, not line-by-line ;)
**\<moneromooo>** OK, that's fine.
**\<fluffypony>** medusa_: are you around?
**\<fluffypony>** ok in the absence of medusa_ being around, dEBRUYNE have you been following Ilya's progress on medusa_'s issues?
**\<dEBRUYNE>** Yeah, he has fixed all issues opened by medusa_ as far as I know
**\<fluffypony>** ok great
**\<medusa_>** yes im here
**\<dEBRUYNE>** Except -> https://github.com/monero-project/monero-core/issues/29
**\<dEBRUYNE>** but that's more of a feature, which should be implemented later
**\<fluffypony>** oh cool - medusa_ how are you finding it now that most of the issues have been fixed?
**\<dEBRUYNE>** could*
**\<TedTheFicus>** MK_ + Others who are wondering, the monero-core project that is being discussed now is the GUI
**\<medusa_>** i think we need more feedback regarding the performance difference between gui wallet creation time and CLI wallet creation time
**\<medusa_>** and i dont know of any major bugs that would be dangerous
**\<fluffypony>** medusa_: there's a PR that's supposed to fix that
**\<fluffypony>** I haven't merged it yet, but it's gone through review
**\<dEBRUYNE>** Ilya merged jacquee's PR as well
**\<dEBRUYNE>** he noticed a significant improvement
**\<medusa_>** so my opinion is merge all to monero-core project master, test there again and if its good we build the bins
**\<dEBRUYNE>** ^ +1
**\<dEBRUYNE>** Beta binaries will also bring more testers, who possibly could notice something we might have overlooked
**\<fluffypony>** ok
**\<TedTheFicus>** Im down to test once the Betas are out
**\<fluffypony>** we'll need a point release of 0.10 to go with it
**\<fluffypony>** so we should at least get through the current group of pending PRs before we do that
**\<medusa_>** but we must communicate its for testing, since the seed is nowhere displayed after creation we dont want people to lose money
**\<moneromooo>** It creates a keys file, right ?
**\<fluffypony>** medusa_: well that's a pretty big issue :-P
**\<medusa_>** yes
**\<fluffypony>** ah ok
**\<fluffypony>** so monero-wallet-cli could be shipped with it for recovery
**\<TedTheFicus>** Good idea
**\<moneromooo>** Well, you do need the daemon anyway, don't you.
**\<medusa_>** yes
**\<dEBRUYNE>** \<fluffypony> so monero-wallet-cli could be shipped with it for recovery <= It's able to recover seeds
**\<dEBRUYNE>** It's just that only in the wizard the seed is shown once
**\<dEBRUYNE>** oh wait, you mean restore with the .keys file?
**\<fluffypony>** yes I meant recovery as in "recover my seed from the .keys file"
**\<ArticMine>** Recovery from seed is the issue with the GUI?
**\<dEBRUYNE>** ah gotcha
**\<dEBRUYNE>** No ArticMine, there isn't a window yet to see your seed
**\<dEBRUYNE>** after the initial wizard
**\<fluffypony>** ArticMine: no - it just doesn't display the seed again after the wizard
**\<fluffypony>** and given how many MyMonero support emails I get where people didn't write down their seed...
**\<dEBRUYNE>** Should be fairly trivial to add though
**\<fluffypony>** ok so that's about it from my side - tewinget isn't around to give us a 0MQ update
**\<fluffypony>** hyc I don't think has started tinkering with the walletDB stuff
**\<fluffypony>** also the forum - I know, I'm working on it, moved all broken deps into monero-project repos to better manage them and am fixing the last few niggly issues
**\<dEBRUYNE>** fluffypony: re: GUI, preferably we would have a tab that displays viewkey/seed/spendkey, the tab could be named Private Keys or something, with a big fat warning label :P
**\<dEBRUYNE>** Like I said, should be fairly trivial to add
**\<fluffypony>** dEBRUYNE: good idea - open an issue for it and let Ilya do it asap :)
**\<fluffypony>** ok so we have 7 minutes before the Kovri meeting, any other things to discuss?
**\<dEBRUYNE>** fluffypony: will do
**\<dEBRUYNE>** NoodleDoodle isn't here right?
**\<moneromooo>** Who wants to volunteer to review some patches from time to time ? :)
**\<dEBRUYNE>** moneromooo: Similiarly, would you be able to glance over / review the trezor XMR code?
**\<moneromooo>** Where is it ?
**\<fluffypony>** on NoodleDoodle's computer
**\<dEBRUYNE>** https://github.com/NoodleDoodleNoodleDoodleNoodleDoodleNoo
**\<dEBRUYNE>** ^ moneromooo
**\<dEBRUYNE>** he has some commits in his monero repository and in trezor-xmr
**\<fluffypony>** :-P
**\<i2p-relay> {-anonimal}** moneromooo: I review many of them but I don't spend enough time with the codebase to ack/nack
**\<moneromooo>** anonimal, thanks :)
**\<moneromooo>** dEBRUYNE: Do you know which one of the three repos is the right one ?
**\<moneromooo>** xmr, common, mcu. xmr seems likely to be one at least.
**\<dEBRUYNE>** oh trezor-xmr
**\<dEBRUYNE>** and monero
**\<dEBRUYNE>** So his commits here -> https://github.com/NoodleDoodleNoodleDoodleNoodleDoodleNoo/monero/commits/master?author=NoodleDoodleNoodleDoodleNoodleDoodleNoo
**\<moneromooo>** OK, I'll keep that in mind then.
**\<dEBRUYNE>** & here -> https://github.com/NoodleDoodleNoodleDoodleNoodleDoodleNoo/trezor-xmr
**\<medusa_>** i can not review the code, but i can test specific pull requests if you guys explain me what you changed
**\<dEBRUYNE>** trezor-mcu / trezor-common has no commits from NoodleDoodle moneromooo
**\<moneromooo>** medusa_: 1082 and 1121 could do with some testing if you feel like it.
**\<moneromooo>** And 1140 :)
**\<moneromooo>** 1082 changes the way fake outs are selected
**\<cryptotekk>** wow in this pace i see GUI by tonight lol
**\<moneromooo>** 1121 replaces the sweep_unmixable code to be more stable and, well, better
**\<moneromooo>** 1141 adds cold wallet signing
**\<medusa_>** oh i can test 1141
**\<medusa_>** i still have the setip from the --offline thing
**\<moneromooo>** 1140, sorry. Off by one...
**\<fluffypony>** oh no off by one bug!
**\<medusa_>** will have a look, thanks
**\<moneromooo>** Mac, Linux, and Plan9.
**\<cryptotekk>** android please
**\<liberte>** lol
**\<fluffypony>** hokay
**\<fluffypony>** that's the end of that

302
_posts/2016-10-16-logs-for-the-Kovri-dev-meeting-held-on-2016-10-16.md
View File

@ -1,302 +0,0 @@
---
layout: post
title: Logs for the Kovri Dev Meeting Held on 2016-10-16
summary: Brief review of what has been completed since last meeting, Kovri API discussion, Kovri Logo, and code & open tickets discussion
tags: [dev diaries, i2p, crypto]
author: dEBRUYNE / fluffypony
---
*October 16th, 2016*
# Logs
**\<i2p-relay> {-anonimal}** 17:00!
**\<moneromooo>** Go go go!
**\<ArticMine>** Let's start
**\<i2p-relay> {-anonimal}** I can't copy/paste as quickly as usual so here's in bits:
**\<i2p-relay> {-anonimal}** 1. Greetings
**\<i2p-relay> {-anonimal}** 2. Brief review of what's been completed since the previous meeting
**\<i2p-relay> {-anonimal}** 3. libclient API discussion (#351)
**\<i2p-relay> {-anonimal}** 4. logo
**\<i2p-relay> {-anonimal}** 5. Code + ticket discussion / Q & A
**\<i2p-relay> {-anonimal}** 6. Any additional meeting items
**\<i2p-relay> {-anonimal}** 7. Confirm next meeting date/time
**\<i2p-relay> {-EinMByte}** Hi
**\<i2p-relay> {-anonimal}** Hello
**\<i2p-relay> {-anonimal}** 2. Brief review of what's been completed since the previous meeting
**\<i2p-relay> {-anonimal}** Very little on the codebase work this period because I've been busy with getting the full-time prop ready/funded and working on the documentation prop:
**\<i2p-relay> {-anonimal}** - Tons of work on #256 (see my monero-site fork for details)
**\<i2p-relay> {-anonimal}** - Minor AES-NI impl fixes/refactor
**\<i2p-relay> {-anonimal}** - Client fix to allow saving privates when behind a transproxy
**\<i2p-relay> {-anonimal}** - Bump dependency versions in submodules
**\<i2p-relay> {-anonimal}** (the issue is probably *when client doesn't have everything it wants when router expects inbound peers*)
**\<i2p-relay> {-anonimal}** - REMOVED TRAVIS-CI! YAY! We now have all-platform build support thanks to pigeons
**\<i2p-relay> {-anonimal}** - Minor things and some doc fixes
**\<i2p-relay> {-anonimal}** - New contributor dadude (welcome, dadude)
**\<i2p-relay> {-anonimal}** One more note:
**\<i2p-relay> {-anonimal}** My full-time funding proposal was fully funded in a record ~2-3 days https://forum.getmonero.org/9/work-in-progress/86967/anonimal-s-kovri-full-time-development-funding-thread
**\<i2p-relay> {-anonimal}** Absolutely unbelievable and I'm so thankful and proud to be a part of this community. The latest reddit thread I think is here https://www.reddit.com/r/Monero/comments/579t3a/kovri_dev_funded_congrats_everyone/
**\<i2p-relay> {-anonimal}** Huge note: this doesn't mean we don't need more contributors, so please let's continue to get the word out there about kovri and get more people on board so we can grow stronger.
**\<i2p-relay> {-anonimal}** Anything else on 2.?
**\<_Slack>** Action: anonimal sees dadude typing
**\<_Slack> {dadude}** thank you. And congrats on that anonimal! that's actually pretty amazing.
**\<imans>** reading...
**\<i2p-relay> {-anonimal}** Thanks dadude, its really the community to thank; such a great crowd.
**\<i2p-relay> {-EinMByte}** Good to see you're funded now, anonimal
**\<_Slack> {dadude}** yep! and 'by word out there about kovri' you mean in monero community or just more people in general?
**\<i2p-relay> {-EinMByte}** That gives me a good excuse to do little development :)
**\<i2p-relay> {-anonimal}** s/saving privates/saving private keys/ \<-- lol, oops
**\<i2p-relay> {-anonimal}** Thanks EinMByte. If an FFS would help you put more time in, I'll be the first to donate (or will try to be unless someone else beats me to it).
**\<i2p-relay> {-anonimal}** dadude: all humans on the planet if possible (preferably with internet availability)
**\<_Slack> {dadude}** got it :slightly_smiling_face:
**\<i2p-relay> {-anonimal}** Anything else on 2. or dare we dive into API chat?
**\<sdgsdug9sd>** whats the expected date for release of i2p?
**\<i2p-relay> {-anonimal}** sdgsdug9sd: checkout our roadmap
**\<sdgsdug9sd>** link?
**\<i2p-relay> {-anonimal}** github.com/monero-project/kovri/wiki \<--something like that, whatever wiki url is
**\<i2p-relay> {-anonimal}** We set a date of nov. 1st for first pre-alpha release. I'd rather push the date to the 0.1.1 release and move 0.1.1 to next year.
**\<_Slack> {dadude}** https://github.com/monero-project/kovri/wiki/Roadmap
**\<ArticMine>** https://github.com/monero-project/kovri/wiki/Roadmap
**\<i2p-relay> {-anonimal}** (like I said, barely any codebase work in 2 weeks)
**\<i2p-relay> {-anonimal}** Ok, let's move to 3. and we can add other items/open questions to 6.
**\<i2p-relay> {-anonimal}** 3. libclient API discussion (#351)
**\<i2p-relay> {-anonimal}** moneromooo: did you get a chance to research my question(s)?
**\* moneromooo** suddenly appears very busy with somehting else
**\<moneromooo>** ... no. Sorry...
**\<moneromooo>** Many bugs...
**\<sdgsdug9sd>** lol is this real? i hardly believe those target dates
**\<imans>** seems codebase is very weak at this time. Needs of lot of testing I think
**\<i2p-relay> {-anonimal}** Guys, we're on API discussion now, we'll chat more later in the meeting.
**\<imans>** okay
**\<i2p-relay> {-anonimal}** moneromooo: I'll try to rephrase then
**\<moneromooo>** There is talk of switching the P2P API to zmtp too (I know nothing about it).
**\<moneromooo>** Should still be mostly streaming thoug.h
**\<i2p-relay> {-anonimal}** moneromooo: I'm betting most of my questions can be answered with more research on my end
**\<moneromooo>** OK, I think maybe ask questions here, and I will try to answer with what I can.
**\<i2p-relay> {-anonimal}** moneromooo: where can I get a good tl;dr of how monero handles timeouts?
**\<moneromooo>** From what I can tell, it uses boost's asio system for this.
**\<moneromooo>** Then you get a callback with a "cancelled" state IIRC.
**\<i2p-relay> {-anonimal}** by 'handle' I mean internally (if something needs to get to blockchain but doesn't quickly enough)
**\<moneromooo>** (from boost)
**\<i2p-relay> {-anonimal}** That's too obvious moneromooo :) I mean purely internally
**\<moneromooo>** to blockchain ? I'm talking avbout the P2P comms here.
**\<moneromooo>** Hmm, well, I don't know more about timeouts, sorry.
**\<i2p-relay> {-anonimal}** I'll try to rephrase again, if a node's internet connection is unreliabe, is behaviour undefined?
**\<imans>** it will not get a proper sync simple
**\<moneromooo>** Hopefully not. Connections to a peer are dropped if "weird" stuff is received, but to what extent this is pervasive, I'm not sure.
**\<moneromooo>** There's a query/reply system, with a handful of possible messages IIRC.
**\* pero** will brb 5min - knows he's next up on agenda
**\<moneromooo>** This seems rather high level though.
**\<i2p-relay> {-anonimal}** \* is thinking ahead, wants to know how a node will deal with dropped tunnels on a noticeable scale
**\<i2p-relay> {-EinMByte}** anonimal: backup tunnels like java i2p could work
**\<moneromooo>** Well, it should be resistant to that. If it's not, we'll have to make it.
**\<moneromooo>** I2P can keep a tunnel for a few minutes reliably enough, right ?
**\<i2p-relay> {-anonimal}** EinMByte: good point.
**\<i2p-relay> {-EinMByte}** But AFAIK, we still aren't sure that monero actually needs connections?
**\<i2p-relay> {-anonimal}** moneromooo: technically, any tunnel and blow at any moment IIRC
**\<i2p-relay> {-anonimal}** s/and/can/
**\<moneromooo>** At any moment is fine, but monero would need to be at least one of high enough duration to reveive a chunk of blokcs when syncing.
**\<i2p-relay> {-anonimal}** If Joe shuts off his router unexpectedly, we have to wait to build a new tunnel from the pool (IIRC)
**\<i2p-relay> {-anonimal}** How big are those chunks usually?
**\<moneromooo>** Again, this is fine. As long as we can get a minute of comms at one point.
**\<moneromooo>** Currently, 200 times the size of a block, which is... hmm... from 250 bytes to 60 kB.
**\<moneromooo>** That 200 can be changed when running with kovri if needed.
**\<i2p-relay> {-anonimal}** moneromooo: ok, scenario question: what if we *can* get a reliable connection but syncing has to wait for it but will be notified "try again in X minutes". Will that break monero?
**\<i2p-relay> {-EinMByte}** with streaming it doesn't really matter
**\<i2p-relay> {-EinMByte}** datagrams are limited in size, though
**\<ArticMine>** but does this set a limit on the blocksize in Monero?
**\<moneromooo>** I think that, for now, that connection will be dropped, and another attempted. But that doesn't seem too hard to change.
**\<moneromooo>** ArticMine: no, the 200 is the number of blocks. Though if one block is 100 MB in the future... I guess it needs to be downloaded without interruption.
**\<i2p-relay> {-EinMByte}** dropping and re-attempting sounds like a good strategy
**\<moneromooo>** The re-attempt would be to another random peer.
**\<i2p-relay> {-anonimal}** \* eek
**\<moneromooo>** (currently anyway)
**\<i2p-relay> {-anonimal}** Ok, well what I'm poking at I think is for more in the future (and based on passing thoughts this week).
**\<i2p-relay> {-anonimal}** \* was not prepared for API chat this week because of point 2.
**\<i2p-relay> {-anonimal}** EinMByte: any other questions/thoughts?
**\<i2p-relay> {-anonimal}** ^ moneromooo
**\<moneromooo>** Not from me.
**\<i2p-relay> {-EinMByte}** Just that I don't think disconnections would be that much of an issue
**\<i2p-relay> {-anonimal}** I have been envisioning more of the API on our end though, but purely in my head.
**\<i2p-relay> {-EinMByte}** but let's move on
**\<ArticMine>** I have to leave now.
**\<i2p-relay> {-anonimal}** * one more thing
**\<i2p-relay> {-anonimal}** Actually, nevermind because I don't want to put dadude on the spot and it's probably unrelated
**\<_Slack> {dadude>}** well if I left the node on and the connection is bad, I wouldn't want it to stop, as bad as mightbe. I'll probably be thinking that its syncing. So what about an timed retry till the network gets back on? If it is very bad, then you can set up an option like --retry x-times
**\<i2p-relay> {-anonimal}** dadude if you have API questions as related to torrenting, now's the chance
**\<_Slack> {dadude>}** Oh, I
**\<i2p-relay> {-anonimal}** (no rush, there are plenty more meetings to be had)
**\<_Slack> {dadude>}** I'll read up on how vuze does it and get back to you guys if I have any questions
**\<i2p-relay> {-anonimal}** dadude: good point, I'm sure the API will cover that
**\<i2p-relay> {-anonimal}** dadude: we can explain how vuze does it after the meeting if you'd like
**\<moneromooo>** A torrent based syncing process was suggested before. It'd be quite a departure from what we have now, but would be a good thing I guess.
**\<i2p-relay> {-anonimal}** Ok, nothing else on 3.?
**\<_Slack> {dadude>}** thanks. unrelated: How does relay handle edits to a post here on slack
**\<i2p-relay> {-anonimal}** dadude: let's save that until later in the meeting
**\<moneromooo>** (for initial sync anyway)
**\<_Slack> {dadude>}** Oh I wasn't talking about to sync the blockchain, I was talking about torrenting inside the i2p netowkr
**\<i2p-relay> {-anonimal}** moneromooo: is there a post or link re: that proposal?
**\<moneromooo>** It was mentioned in one of the MRL papers IIRC. No details, but I can find you the one.
**\<i2p-relay> {-anonimal}** Thank you moneromooo.
**\<i2p-relay> {-anonimal}** * would navigate but you know MRL better than I
**\<i2p-relay> {-anonimal}** Ok, moving on
**\<i2p-relay> {-anonimal}** 4. logo
**\<i2p-relay> {-anonimal}** pero: all you if you're here!
**\<pero>** yes hi
**\<pero>** ok so we're down to 2 fonts
**\<i2p-relay> {-anonimal}** Let's decide now then
**\<pero>** each came with 6-8 weights and i've cut that down to 2 for exo2 and 3 for lato
**\<pero>** https://a.pomf.cat/gyzaxi.png
**\<pero>** 1b and 1c are the same weight with different kerning
**\<pero>** the 'garlic-integrated' variants are interesting but will require rework of the garlic
**\<pero>** for record keeping purposes this is v8
**\<i2p-relay> {-anonimal}** Ok, we're throwing out the garlic as 'o' idea because: 1. doesn't look like garlic 2. doesn't look like an 'o' 3. not intended for that purpose
**\<i2p-relay> {-anonimal}** Any objections?
**\<moneromooo>** My subjective opinion is that the "garlic as dot in the i" is too small to not feel weird.
**\<i2p-relay> {-anonimal}** \* agreeing with moneromooo, it looks like a flame
**\<pero>** yes i agree - is viable but needs rework
**\<imans>** instead put garlic for o kovri
**\<moneromooo>** I thought the flame thing was intended :P
**\<i2p-relay> {-anonimal}** imans: see my comment above
**\<_Slack> {dadude}** just a small question. wait, so are we 1. pushing kovri as a 'project' on its own (apart from geti2p.net) or 2. just an alternative router to the java i2p one. Because if it is 2, shouldn't it way only 'garlic router'? and not add the project?
**\<imans>** okay
**\<i2p-relay> {-anonimal}** dadude: 1.
**\<pero>** imans - the problem with that is that the garlic wasn't intended for such usage
**\<pero>** and makes the text imbalanced
**\<i2p-relay> {-anonimal}** Alright, everyone pick their favorite font now please (we need to decide on logo today, final decision this week - not waiting until next meeting)
**\<imans>** fine. pero
**\<pero>** e.g., the space between the upper portion of the K and the black part of the garlic is smaller than the whitespace on the right side
**\<pero>** and the small lines at the bottom and top of garlic aren't optimal
**\<imans>** I see it there
**\<imans>** My choice is the 6th one
**\<imans>** for font
**\<moneromooo>** I'd pick one of the ones on the right, just because they're fatter, and so easier to read.
**\<imans>** and bold
**\<i2p-relay> {-EinMByte}** I'd go for lato
**\<i2p-relay> {-EinMByte}** (b1?)
**\<pero>** yea i'm in the lato camp as well
**\<i2p-relay> {-anonimal}** pero: I like lato, X coord 1, Y coord b
**\<imans>** seems everyone picks up the second
**\<i2p-relay> {-anonimal}** Ok, 3 votes for b1, 1 vore for 'the 6th one' (I have no idea what that is)
**\<_Slack> {dadude}** yep b1
**\<pero>** i'm either b2 or b3
**\<pero>** 6th one was b3
**\<i2p-relay> {-anonimal}** Alright, 4 votes b1, 2 for b3, 1 for b2
**\<moneromooo>** If I had to choose one, I'd say bottom right, but there's really not much difference and I might pick another one tomorrow :)
**\<i2p-relay> {-anonimal}** b1 one is the winner, any objections?
**\<i2p-relay> {-anonimal}** lol
**\<pero>** well that's for b3 now ;p
**\<pero>** 3
**\<moneromooo>** Ignore me :)
**\<i2p-relay> {-anonimal}** \* looks different depending on mood
**\<i2p-relay> {-EinMByte}** 3/3, let's toss a coin
**\<i2p-relay> {-anonimal}** pero: also, let's try steching that subtext all the way to the left
**\<i2p-relay> {-anonimal}** to the end of the garlic
**\<i2p-relay> {-anonimal}** Does that effect your decision?
**\<pero>** yea that variant was included before - it was just a time saving consideration to not include it
**\<i2p-relay> {-anonimal}** \* wonders how to coin toss over IRC
**\<moneromooo>** There were some with that system on one of the previous images. It looked odd. Maybe instead scale the garlic up to go tho the bottonm of the subtext.
**\<pero>** as a rule of thumb you want heavier type for the logo
**\<pero>** moneromooo that looked even weirder :)
**\<moneromooo>** So there's no hole, but it doesn't also feel like the subtext is running away from the main text.
**\<i2p-relay> {-anonimal}** b2 b3 looks overpowering compared to that logo IMHO
**\<moneromooo>** Hmm, ok.
**\<i2p-relay> {-anonimal}** We have 7 minutes to decide, I'd like to save room for other topics.
**\<i2p-relay> {-anonimal}** 6 minutes now
**\<imans>** I stick with the last one on the right
**\<pero>** i think you should be focusing on the largest variant
**\<pero>** and the variant with only the garlic on the left
**\<pero>** when deciding
**\<endogenic>** lol you valuable guys/gals are spending too much time on it imo and may end up getting sucked down a depth first search rather than seeing the whole picture. this is just my humble opinion but it's better to find a designer to own it (and prevent design by committee)
**\<pero>** don't worry about the others
**\<endogenic>** but i might regret having opened my mouth :P
**\<pero>** endogenic - this is how the 'design process' works
**\<i2p-relay> {-anonimal}** pero: 5 minutes, why?
**\<moneromooo>** They all look so similar anyway.
**\<pero>** this is 'client feedback'
**\<i2p-relay> {-anonimal}** I like the balance of b1
**\<pero>** you don't just present a finished logo to a client and say 'here, take this'
**\<i2p-relay> {-anonimal}** b2 b3 are too strong
**\<imans>** okay
**\<i2p-relay> {-EinMByte}** I though we were going to toin coss
**\<endogenic>** http://www.logodesignlove.com/next-logo-paul-rand
**\<i2p-relay> {-EinMByte}** \*thought
**\<moneromooo>** I vote for toin coss.
**\<i2p-relay> {-anonimal}** Who has the coin?
**\<endogenic>** but i'm not disagreeing that market research is important
**\<endogenic>** talking to users is basically #1 next to building
**\<i2p-relay> {-anonimal}** And is that coin CSPRNG, lol
**\<i2p-relay> {-EinMByte}** Let's do this right and use a bit commitment scheme
**\<i2p-relay> {-anonimal}** 3 minutes
**\<i2p-relay> {-EinMByte}** (unfortunately we don't have secure timestamping available for the commitment scheme)
**\<pero>** yea ok pay someone 100k and after 6 months they'll narrow it down to 1 almost scientifically
**\<i2p-relay> {-anonimal}** 2 minutes
**\<moneromooo>** OK, so, if the number of letters in "anonimal" is even, b1, if it's odd then b3. OK ?
**\<pero>** i'm in the not b1 camp
**\<i2p-relay> {-anonimal}** \* bribes moneromooo behind closed doors
**\<pero>** mostly because it looks close to just regular text
**\<i2p-relay> {-anonimal}** I think b2 b3 are ugly, I don't want to see this everytime I look at the readme
**\<i2p-relay> {-anonimal}** \* don't forget the devs
**\<moneromooo>** A graphical README ?
**\<i2p-relay> {-anonimal}** 1 minute to flip coin
**\<pero>** just bigger and with tighter kerning
**\<i2p-relay> {-anonimal}** \* will pull executive order if someone can't flip a coin
**\<i2p-relay> {-iDunk}** we can pick anything as long as it's b1 :)
**\<moneromooo>** SOLD!
**\<i2p-relay> {-anonimal}** pero: will b2 look better when subtext is streched across to the left
**\<i2p-relay> {-anonimal}** \* trusted pero so far, no reason to stop trusting
**\<i2p-relay> {-iDunk}** btw, i'm also for b3
**\<pero>** well i'd show you but i'm in wayland atm with no screenshot support
**\<i2p-relay> {-anonimal}** I'd like EinMByte to be the tie-breaker if he's up for it
**\<i2p-relay> {-EinMByte}** With iDunk's vote, let's say the choice is b3
**\<pero>** but no it doesn't look any better than it does now
**\<i2p-relay> {-anonimal}** b3 it is!
**\<i2p-relay> {-anonimal}** Congrats to b3
**\<i2p-relay> {-iDunk}** \* hides from anonimal
**\<i2p-relay> {-anonimal}** \* says eww but oh well
**\<i2p-relay> {-anonimal}** lol iDunk
**\<moneromooo>** eww well
**\<i2p-relay> {-anonimal}** \* looking forward to a kovri PR from iDunk some day
**\<i2p-relay> {-iDunk}** :D
**\<i2p-relay> {-anonimal}** Moving on,
**\<imans>** congrats
**\<i2p-relay> {-anonimal}** 5. Code + ticket discussion / Q & A
**\<imans>** ask
**\<i2p-relay> {-anonimal}** 8 minutes left, I want to actually move to 6.
**\<i2p-relay> {-anonimal}** Any objections?
**\<imans>** no
**\<i2p-relay> {-EinMByte}** No objections
**\<i2p-relay> {-anonimal}** 6. Any additional meeting items
**\<i2p-relay> {-anonimal}** {-imans} seems codebase is very weak at this time. Needs of lot of testing I think
**\<i2p-relay> {-anonimal}** imans: have you spent time with this codebase?
**\<imans>** Just trying to install
**\<imans>** My ubuntu is hanging. I have to try another time.
**\<i2p-relay> {-EinMByte}** \* afk
**\<i2p-relay> {-anonimal}** Ok, so you haven't then.
**\<i2p-relay> {-anonimal}** {-sdgsdug9sd} lol is this real? i hardly believe those target dates
**\<imans>** yes
**\<i2p-relay> {-iDunk}** i installed it yesterday and it seemed to run just fine until a few hours ago
**\<moneromooo>** That's for "kovri runs and does things", not "monero uses kovri", fwiw.
**\<i2p-relay> {-anonimal}** sdgsdug9sd: then you probably wouldn't believe that what we forked from actually had a release and you should be thankful we've not repeated that same mistake
**\<moneromooo>** What was the mistake ?
**\<i2p-relay> {-anonimal}** sdgsdug9sd: also, see pre-alpha https://en.wikipedia.org/wiki/Pre-alpha
**\<i2p-relay> {-anonimal}** moneromooo: calling that router a year ago "releaseable"
**\<moneromooo>** Ah...
**\<i2p-relay> {-iDunk}** i got disconnected from irc, couldn't connect any more, tried to exit from kovri but had to kill it
**\<i2p-relay> {-iDunk}** restarted and it runs fine again
**\<i2p-relay> {-anonimal}** 2 minutes. Any questions/comments/new items?
**\<i2p-relay> {-anonimal}** imans sdgsdug9sd: ^
**\<imans>** I will ask more in next meeting. I need to brainstorm myself
**\<moneromooo>** anonimal: https://lab.getmonero.org/pubs/MRL-0004.pdf -- the torrent suggestion was not about initial sync actually, but about sending new txes.
**\<moneromooo>** (I had misremembered)
**\<i2p-relay> {-anonimal}** I'm available for tech support after the meeting
**\<i2p-relay> {-anonimal}** 2 weeks, same time?
**\<i2p-relay> {-anonimal}** moneromooo: ah, ok, thanks I'll give it a read
**\<i2p-relay> {-anonimal}** imans: if you need help just ask in #kovri or #kovri-dev after the meeting
**\<i2p-relay> {-anonimal}** 7. Confirm next meeting date/time
**\<i2p-relay> {-anonimal}** \* moving on
**\<i2p-relay> {-anonimal}** No objections? 2 weeks same time then.
**\<imans>** Okay anonimal. I'm in another stuff I will get in technical touch tomorrow
**\<i2p-relay> {-iDunk}** yep
**\<imans>** so, the date and time is?
**\<i2p-relay> {-anonimal}** Thank you everybody. Thank you dEBRUYNE for logging these meetings :)

369
_posts/2016-10-16-overview-and-logs-for-the-dev-meeting-held-on-2016-10-16.md
View File

@ -1,369 +0,0 @@
---
layout: post
title: Overview and Logs for the Dev Meeting Held on 2016-10-16
summary: Review and discussion of Open PRs, contribution guidelines, and official GUI
tags: [dev diaries, core, crypto, 0mq]
author: dEBRUYNE / fluffypony
---
*October 16th, 2016*
# Overview
An overview [can be found on Hello Monero](https://hellomonero.com/article/monero-dev-meeting-note-highlights-2016-10-16).
# Logs
**\<moneromooo>** So, fluffypony asked if I could talk. I have no relay bot, so #kovri-dev will have to be here to listen.
**\<moneromooo>** He suggested I talk about guidelines for submitting patches. So we'll see if everyone mostly agrees.
**\<+hyc>** cool
**\<moneromooo>** I would like to encourage people to make clean changes, which mean:
**\<moneromooo>** - try to keep patches self contained where appropriate
**\<moneromooo>** - no random whitespace changes interspersed with other changes
**\<moneromooo>** - sensible commit message (ie, no "update wallet.cpp")
**\<moneromooo>** - properly rebased patches (ie, if you authored three patches in a PR, don't send 20 patches from someone else at the same time, so "git rebase master" first)
**\<+hyc>** that all makes sense
**\<moneromooo>** If you make a buggy patch and then fix it in a second patch, squash those (see git rebase -i, but that starts being a bit complex)
**\<moneromooo>** Does anyone disagree ?
**\<_Slack> \<nanoakron>** Nope
**\<Jaquee_>** nope
**\<tompole>** nope
**\<+hyc>** no disagreement here. that's standard stuff.
**\<_Slack> \<nanoakron>** Can I ask a little more about what you mean by ‘self contained'
**\<moneromooo>** (We'll make an exception for tewinget who's got a massive non rebased patchset for 0mq though)
**\<+hyc>** sure, patches of such large scope are going to have their exceptions
**\<moneromooo>** I mean, if you've got two changes, make them two patches. I like small patches, one per "logical change".
**\<_Slack> \<nanoakron>** Makes sense. Single-issue patches.
**\<moneromooo>** It's easier to review, to debug, to revert it necessary.
**\<+hyc>** but usually PRs should be one issue per patch, one patch per issue
**\<moneromooo>** Yes. However, when in the middle of a large thing, you sometimes see something that needs fixing and would otherwise conflict. That can go (as a separate patch) in that PR, depends on the circumstances.
**\<moneromooo>** especially for those PRs that can take weeks to be merged.
**\<+hyc>** sure
**\<_Slack> \<nanoakron>** OK
**\<moneromooo>** But yes, 1/1 in general.
**\<moneromooo>** So, nobody seems to disagree, I'll write a little thingie about this for the repo. Thanks.
**\<moneromooo>** So, I guess... anyone has anything to say about progress, or other dev related stuff ? :)
**\<Fireice>** I've got a question to the devs - do you think Monero is mature enough for applications improving usability? I'm an independent software dev, and I'm thinking of committing about 6 months of full-time work on Monero. First application that I'm thinking of is a lightweight Windows GUI wallet for Monero.
**\<moneromooo>** Another one, yay! :)
**\<moneromooo>** First, read up on what lightweight may involve for monero.
**\<_Slack> \<nanoakron>** Do we have a common wiki or other info page for devs to describe things like prefixes e.g. m_ and others
**\<TedTheFicus>** Yes, this is needed
**\<_Slack> \<nanoakron>** stuff
**\<moneromooo>** And mature enough is pretty subjective. It can be used, for sure.
**\<Fireice>** lol, bazaar project usually have a lot of traffic
**\<moneromooo>** There is none. Some people use m_ for class data members.
**\<hiall>** hi all
**\<_Slack> \<nanoakron>** What would you think about standardising that aspect of development? Variable/class/etc. nomenclature?
**\<moneromooo>** Fireice: also, ask athan (or ethan), he's got a wallte in development which you might want to have a look at.
**\<hiall>** when is meeting starting?
**\<dEBRUYNE>** it already started
**\<+hyc>** nanoakron: that sounds like a lot of busywork
**\<hiall>** where is it?
**\<moneromooo>** Well, my opinion on that is to follow the existing, but I'm not super bothered about it. I certaonly don't subscribe to the minutiae crap. But I know many disagree :)
**\<Fireice>** ok will do, how do i get hold of him?
**\<_Slack> \<nanoakron>** Fireice: Take a look at how the existing GUI wallet is coming along at https://github.com/monero-project/monero-core - maybe integration into an existing service such as open bazaar would be cool
**\<moneromooo>** Fireice: he's around on IRC pretty often.
**\<_Slack> \<nanoakron>** hyc: I know :( But standards can be good too
**\<moneromooo>** integration would need th plugin system first. That is yet to be design.
**\<moneromooo>** designed.
**\<dEBRUYNE>** Fireice: His contact details are on Github too: https://github.com/athanclark
**\<imans>** There is no instruction for windows compilation in the github
**\<endogenic>** I tend to agree with nanoakron in the sense that changes to the API, especially w/o corresponding documentation updates, makes integration pretty darn tough and not necessarily viable for third parties
**\<moneromooo>** Well, that's true. It's not API stable, that's certain.
**\<dEBRUYNE>** imans: https://monero.stackexchange.com/questions/2346/compiling-gui-from-source-differences-by-os
**\<+hyc>** not at the binary level, and not even at the RPC level
**\<moneromooo>** The RPC is *mostly* backward compatible though.
**\<endogenic>** Fireice: that may be your answer then :)
**\<imans>** ty dEBRUYNE
**\<_Slack> \<nanoakron>** @hyc or @moneromooo on a similar note, is there a list of all available functions? E.g. call tools::simplewallet::is_it_true() to clean true/false user inputs
**\<+hyc>** I think it's OK to establish guidelines now for future development
**\<Fireice>** ty for your help, do you know if the qt wallet targets win and linux systems or just linux?
**\<+hyc>** but it's too early to make hard rules
**\<hiall>** is this the meeting?
**\<pero>** conference, dev conference
**\<moneromooo>** A list of all available functions, beyond the source ?
**\<jaquee>** Fireice: the official targets linux, osx and windows
**\<dEBRUYNE>** Fireice: The official GUI will be available for Linux, os x, and windows
**\<moneromooo>** That sounds like it'd go stale pretty fast.
**\<moneromooo>** But no, there is none.
**\<endogenic>** perhaps the API documentation stuff should wait until the 0mq changes have been made?
**\<+hyc>** at least that, yes
**\<+hyc>** (endogenic)
**\<_Slack> \<nanoakron>** @moneromooo yes. I don’t think you’re going to find key functions going stale that fast, so long as you require people who update or add functions to make corresponding changes to the documentation before their PR gets accepted.
**\<moneromooo>** I think tewinget is doing doc as he codes.
**\<imans>** IMO third party integrations must be made simple and easy to plug with any kind of party or platform
**\<moneromooo>** I'm not sure holding PRs for documentation is best, but I'm a bit on the fence tbh.
**\<moneromooo>** What do people think ?
**\<+hyc>** sounds like a Would Be Nice when there is a larger developer base
**\<+hyc>** and the dev base is certainly growing now
**\<_Slack> \<nanoakron>** Documentation is boring bullshit but necessary to make it easier for new devs to get involved. We don’t want to get into a situation like a certain other coin where only an inner cabal actually knows the code without deep reading
**\<TedTheFicus>** If documentation is going to make it easier to attract API + other users than I think we need it up to date always
**\<endogenic>** moneromooo: documentation should be done by particularly able people IMHO
**\<gingeropolous>** so, not accepting a pull request because of poor documentation?
**\<xmrcoma>** tewinget practice of documenting while coding is a best practice
**\<endogenic>** and it can degrade in quality if an owner or class of developer is not designated
**\<imans>** I do agree with that. good documentation can seemlessly help new devs get involved easily
**\<_Slack> \<nanoakron>** @gingeropoulos I mean something like ‘I’ve written this new function to calculate X but haven’t given any documentation’ and then 2 months later someone new comes along, never realised that function existed because there was no documentation, and then just trying to rewrite their own version.
**\<moneromooo>** But how would you find it in the doc, if you don't find it in the source ?
**\<_Slack> \<nanoakron>** What we need is a common documentation site and to pay someone to do about a week’s work to pore over the code and fully document every function
**\<+hyc>** exactly
**\<+hyc>** new devs must search, regardless.
**\<moneromooo>** (not saying it's a bad idea here, mind)
**\<gingeropolous>** nanoakron, i think thats what tewinget was up to at one point :)
**\<+hyc>** on the other hand, I like tools like doxygen, document as you code is always a good approach
**\<_Slack> \<nanoakron>** Would be easier to search a wiki for ‘check hard fork version’ and get a bunch of matching functions from which you can pick
**\<moneromooo>** I do: git grep check.*hard.*fork :)
**\<moneromooo>** But ok, fair enough.
**\<moneromooo>** I think encouraging doc is good, ust not sure it should be enforced, at least for now.
**\<_Slack> \<nanoakron>** But again, it’s a bit chicken and egg - good documentation begets good documentation. It’s getting over that original hurdle to actually make it happen
**\<gingeropolous>** yeah I think its a "Would Be Nice" thing, and during a PR review, it would be noted - like "hey, you should totally comment this up"
**\<gingeropolous>** and then if the dev doesn't comment it up, then its a judgement call over how important the feature is
**\<_Slack> \<nanoakron>** I agree moneromooo, we can’t enforce without a good standard or common place to record the documentation
**\<endogenic>** nanoakron: +1
**\<+hyc>** I'm cool with mandating Doxygen comments, moving forward.
**\<moneromooo>** I agree than modifying a function with a doxygen doc thing should also change to doc thing to match. That's a NAK offense :)
**\<endogenic>** another thing to consider is that git commit messages are a kind of documentation. maybe we need to codify the standards in a public official place
**\<moneromooo>** So I'll add language to encourage documenting stuff.
**\<_Slack> \<nanoakron>** Starting off a forum funding goal for someone to pull together all the function, variable and class lists would be worthwhile
**\<+hyc>** nanoakron: I disagree.
**\<_Slack> \<nanoakron>** Could you also add language telling us how to do the documentation - I’ve never used doxygen
**\<+hyc>** lots of effort to maintain a moving target.
**\<moneromooo>** I just copy/paste an existing one and adapt.
**\<TedTheFicus>** Yes, I'd contribute funding to that
**\<+hyc>** but that's the sort of thing doxygen already takes care of
**\<moneromooo>** And I agree with hyc here. An inventory now would be wasted, mostly.
**\<+hyc>** so if we start using it now, then over time it will build itself
**\<_Slack> \<nanoakron>** The target won’t move though. Let me choose a random example. Do you really think cryptonote_core::blockchain::pop_block_from_blockchain is going to be deprecated any time soon?
**\<_Slack> \<nanoakron>** Someone had to write the domesday book...
**\<imans>** But, this is going to be a big sub project if you document everything. You need lot of time and effort
**\<moneromooo>** Unlikely. I would look suspiciously at a patch using it though :P
**\<_Slack> \<nanoakron>** In which case the person patching could just fix up the doc at the same time :slightly_smiling_face:
**\<+hyc>** indeed, most of the existing functions only have legitimate use internally, not by 3rd parties
**\<imans>** If you add use cases it would be very much helpful
**\<moneromooo>** But hey, if you want to do that, feel free. Maybe it will turn out to be a great idea in retrospect.
**\<endogenic>** what are the problems for which we need to provide documentation at this moment? if we categorize the instances of those problems we might find that it can work quite well to have task- or case-based documentation as a distinct project from going through the source and applying doxygen comments to everything for a whole-API reference
**\<_Slack> \<nanoakron>** Do we have anywhere common where I can read about doxygen or using doxygen wrt monero now?
**\<moneromooo>** Well, applying doxygen comments is, by itself, pointless (even worse, as it makes it harder to read the API). Semantics in the doxygen comments are what's good, and that needs understanding of the code.
**\<imans>** An errata list is good which will help people to trace out the errors they meet
**\<+hyc>** what errata list? the github issues list?
**\<imans>** Also, a stackexchange like documentation system which will enable users to post their comments and also raise issues they face.
**\<imans>** Yes, hyc similar to that
**\<moneromooo>** endogenic: I think nanoakron originally wanted a map from "I want to do that" to "use this". I think.
**\<_Slack> \<nanoakron>** @moneromooo yes
**\<_Slack> \<nanoakron>** @imans Not entirely sure how that would be different from the existing github
**\<imans>** It will not be different. But it aids new comers and users to interact more closely
**\<_Slack> \<nanoakron>** @imans ...
**\<endogenic>** imans: thought we already have a SE?
**\<imans>** I mean it for API + third party integrations
**\<endogenic>** why not just create a new category?
**\<+hyc>** yes, at a certain point, new devs are just going to have to learn to use the tools that already exist
**\<imans>** yes, the same I say
**\<+hyc>** otherwise we spin our wheels adding infrastructure instead of functionality
**\<_Slack> \<nanoakron>** @hyc That’s absolutely fine…so long as those tools themselves are well documented :slightly_smiling_face:
**\<gingeropolous>** well the github wiki was requested for (i think) something related to this purpose, and it hasn't received any attention
**\<_Slack> \<nanoakron>** afk 10 mins
**\<moneromooo>** That sounds like a good idea. Start with a "list of useful functions someone may need" in that wiki. See how it goes.
**\<moneromooo>** And it doesn't seem like a huge waste of time.
**\<gingeropolous>** yeah, i mean if a random dev stumbles into monero, presumably they goto the github for code, so that wiki is probably where they'll go first
**\<+hyc>** I've never seen it... :P
**\<moneromooo>** I've only seen it because I was given alink to it :D
**\<gingeropolous>** hehehe. at the minimu, I can dump the rpc documentation thats on getmonero.org into it via the power of copy and paste
**\<+hyc>** sounds like a good start
**\<+hyc>** most 3rd party integrations should be RPC anyway
**\<gingeropolous>** so i missed the beginning. is this the general topic of "where's the docs?"
**\<imans>** If development work for API is finished and you want it to take to third parties. Create illustrations about integration for every industry you want to focus or you think monero should be a partner with. Attach it to the wiki
**\<moneromooo>** And that's going to totally change soon.
**\<gingeropolous>** right.
**\<moneromooo>** Anyway, any other arguments/ideas about documentation ?
**\<gingeropolous>** well the 2 will co-exist for a while, right?
**\<moneromooo>** Yes.
**\<imans>** I think documentation is not the main focus for this meeting? What is aimed to discuss today?
**\<moneromooo>** Whatever development related stuff people want to talk about.
**\<pero>** the documentary i think
**\<imans>** nice
**\<moneromooo>** hyc: have you had some more thoughts about how to make a lmdb based wallet data file ?
**\<medusa_>** i have nothing to say about documentation, but i want to encourage everybody to build and try the gui :-)
**\<dEBRUYNE>** **\<moneromooo>** Whatever development related stuff people want to talk about. \<= jaquee and I can give a few GUI updates soon^tm
**\<+hyc>** I've been thinking about how to integrate encryption, yes
**\<+hyc>** but no new code written yet
**\<pero>** soon is a little ambiguous - closer to 10min or 10weeks?
**\<dEBRUYNE>** pero: whenever the current topic of the meeting is finished :P
**\<moneromooo>** Well, let's have dEBRUYNE and jaquee then.
**\<dEBRUYNE>** So right now
**\<dEBRUYNE>** Ok so, fluffypony is in the process of building beta binaries
**\<dEBRUYNE>** Building went fine, but there is a little issue on windows with hardware acceleration, i.e., the GUI won't run if that is disabled
**\<dEBRUYNE>** However, we suspect that on "normal" systems it won't be an issue, because it's enabled by default there
**\<moneromooo>** Mesa might help ?
**\<dEBRUYNE>** luigi and Articmine are going to test this tomorrow when Fluffypony returns
**\<moneromooo>** Cool, thanks all :)
**\<+hyc>** sheesh, it's a wallet nota videogame. what acceleration does it want...
**\<xmrcoma>** lets waive a magic want that will cause all windows users worldwide to swtich to linux overnight. issue solved
**\<moneromooo>** It's using OpenGL for its widget set apparently.
**\<dEBRUYNE>** It's fairly trivial to enable too on windows systems
**\<moneromooo>** Got had by this when I tried it a few days back.
**\<dEBRUYNE>** Fluffypony ran into the issue because he was building on a windows server
**\<@ArticMine>** Basically Windows computers with really ancient graphics and certain virtual machine implementations of Windows have this hardware acceleration issue
**\<eyejay>** a clear deal breaker. it's ded
**\<jaquee>** exactly. so it's not a really big issue imo
**\<+hyc>** QT is requiring this dependency?
**\<@ArticMine>** Windows server is the other case since it uses very minimal graphics by design
**\<jaquee>** yes some QT widgets requires it
**\<@ArticMine>** Yes the dependency is from QT on Windows
**\<moneromooo>** http://stackoverflow.com/questions/18794201/using-qt-without-opengl seems to imply Qt can be built without opengl.
**\<+hyc>** nuts... I mean, OpenGL isn't even intended for 2D graphics. It's 3D gaming stuff.
**\<gingeropolous>** based on my statistical analysis of the clouds I'm sure 95% of people requiring windows GUI are running windows 10 because they upgrade because it told them to
**\<gingeropolous>** that said, the remaining 5% will be the loudest
**\<medusa_>** i bet its that truning thing when refreshing
**\<moneromooo>** AFAICT, 2D acceleration in new GPUs is a bit shit, and using 3D with orthonormal projection is actually faster.
**\<imans>** isn't it designed to support all windows version?
**\<@ArticMine>** Windows 10 is not an issue unless some very special customization's are made
**\<iDunk>** but all windows versions are not designed to support it
**\<imans>** Haha, iDunk clever
**\<iDunk>** ;)
**\<imans>** Enable switches or options to turn on/off opengl support and its related stuff in the wallet.
**\<dEBRUYNE>** I think realistically speaking, only a negligible percentage of users will run into the issue
**\<@ArticMine>** Well XP will support it on most later XP computers
**\<dEBRUYNE>** And they can turn it on fairly easy
**\<dEBRUYNE>** (in the rare case it's disabled by default)
**\<moneromooo>** Anything else about the GUI ?
**\<pero>** i was hoping the default file path -related issues on linux would be fixed before any binaries got into the wild - the github issues are still open so i take it that hasn't happened?
**\<dEBRUYNE>** **\<moneromooo>** Anything else about the GUI ? \<= I think jaquee wanted to tell a bit on what he is working on and what he'll be working on in the future
**\<jaquee>** yes
**\<moneromooo>** jaquee: please do :)
**\<imans>** Well, I would also like to add another option. Add an option to sync from the local blockchain or simply act as a light wallet. This will help the gui to both work as light or core wallet.
**\<moneromooo>** (14 minutes till kovri meeting)
**\<imans>** okay, waiting
**\<TedTheFicus>** Yes, that is a good idea
**\<jaquee>** i'm currently working on the wallet selector issue
**\<jaquee>** open wallet form file... switch wallet etc
**\<imans>** good to hear
**\<jaquee>** and i will also fix the default path on linux
**\<imans>** fine.
**\<jaquee>** hower i won't be finished today
**\<pero>** o/
**\<jaquee>** so it has ot wait until next release
**\<imans>** It won't be an issue
**\<xmrcoma>** no neeed to finish today jaquee. thanks for your hard work. From a strategic point of view GUI release before Oct 28 (zcash release) would be helpful
**\<jaquee>** if the windows binaries gets built tomorrow
**\<jaquee>** and after that i'm gonna work on whatever the commuity feels most prioritized
**\<moneromooo>** That's cool, thanks jaquee.
**\<jaquee>** like the plugin system or better integration with daemon
**\<TedTheFicus>** Can anyone in the know comment on (xmrcomas) statement?
**\<moneromooo>** If we're going to have binaries flying around, I think things like validation, avoiding user being dumb, etc, are a good thing to focus on.
**\<jaquee>** yes. we could improve the ux with better validation
**\<moneromooo>** About what ? Wanting binaries before 28 ?
**\<imans>** Create use cases
**\<medusa_>** yes personally i think all the dangerous stuff is fixed, at least im not aware of any
**\<endogenic>** i was also concerned to see that someone attempting to run a macos binary of the gui wallet the other day got a crash about a dynamic library not having been able to be loaded -- and i believe we found out that it was boost which wasn't installed -- for the gui release, will there be an installer for mac os to take care of such dependencies?
**\<medusa_>** the mian thing is that the "open from keys file" usecase is missing and windows suers chan not easily switch wallets
**\<moneromooo>** Niece. Thanks for testing medusa_ :)
**\<moneromooo>** Probably just build boost statically.
**\<jaquee>** endogenic: I think that's a build issue. Won't affect the binaries afaik
**\<+hyc>** shouldn't we be building this with statically linked libboost?
**\<endogenic>** jaquee: ok, excellent
**\<hiall>** when official gui wallet out?
**\<gingeropolous>** about 2 weeks
**\<moneromooo>** Anything else you want to add, jaquee ?
**\<jaquee>** nope
**\<TedTheFicus>** There is no date, it was just discussed now and testing is being done.
**\<moneromooo>** Anyone else want to talk about dev stuff for 6 minutes ?
**\<dEBRUYNE>** hiall: Read the backlogs :P
**\<_Slack> \<nanoakron>** Thanks @jaquee for all the GUI work. Two other issues I wanted to raise during this meeting were (a) killing dead issues on github and (b) formalising the log levels. WRT log levels, I don’t mind going through the code and changing all log outputs to the correct level if we can agree what those should be, in advance of a better programmer changing the logging subsystem itself. Please see and comment on https://github.com/monero-project/monero
**\<tompole>** Can someone confirm that the languages page has been scrubbed from the GUI?
**\<endogenic>** i do want to mention i don't think any normal user would install boost on their own -- and the crash itself wouldn't be acceptable as a graceful failure fmpov as a product guy
**\<moneromooo>** I'd leave any level change till after the log system change, let's not waste work.
**\<hiall>** so GUI release this month? :O
**\<_Slack> \<nanoakron>** @moneromooo OK makes sense
**\<moneromooo>** tompole: it's here as of today, just with only en_US IIRC.
**\<dEBRUYNE>** \<tompole>** Can someone confirm that the languages page has been scrubbed from the GUI? **\<= Yeah, translations aren't done yet
**\<jaquee>** tompole: yes we've removed all languages except english for now until translations are finsihed
**\<sdgsdug9sd>** if the issues with hardware acceleration get fixed in time, the gui should come out before oct 28 right?
**\<_Slack> \<nanoakron>** Still inviting comments on the discussion though
**\<tompole>** Okay cool, thanks.
**\<dEBRUYNE>** I'll put the strings on transifex next week
**\<dEBRUYNE>** Such that the community can help translating
**\<dEBRUYNE>** then we can enable them again
**\<moneromooo>** As for killing closed bugs, that'll happen, once the pony gets a minute. He has logs with issues list.
**\<imans>** I just started to compile one for my ubuntu 15.10
**\<endogenic>** i'm curious to know how qt was chosen as the gui lib, if anyone can comment
**\<moneromooo>** For people wanting to read the kovri meeting a 3 minutes, that'll be on #kovri-dev
**\<+hyc>** qt is multi-platform, seems a reasonable choice
**\<_Slack> \<nanoakron>** Thanks all. See you around!
**\<moneromooo>** The other main one is GTK. Or.. custom :D
**\<moneromooo>** WxWidgets maybe.
**\<i2p-relay>** {-anonimal} #kovri-dev topics today will be API and resolving the logo.
**\<+hyc>** gtk is atrocious. yeah mebbe wxwidgets
**\<moneromooo>** Java :o
**\<_Slack> \<dadude>** libgui?
**\<hiall>** so there is a possibility that we see gui before end of october?
**\<sdgsdug9sd>** expected date for release of the gui?
**\<_Slack> \<dadude>** libui sorry https://github.com/andlabs/libui
**\<gingeropolous>** there's always a possibility
**\<moneromooo>** Oh my. Maybe in november.
**\<TedTheFicus>** It is possible yes. Have a look on GitHub under project MonerCore to gauge the status
**\<moneromooo>** December, otherwise.
**\<medusa_>** next year guys
**\<sdgsdug9sd>** lol
**\<tompole>** 2018
**\<@ArticMine>** hiall A possibility Yes; Promises: No
**\<gingeropolous>** now the probability of that possibility is a different story
**\<xmrcoma>** 2018 sounds like fud. I say 2017 at the latest
**\<TedTheFicus>** Thanks for all your hard work everyone!
**\<moneromooo>** For people wanting to read the kovri meeting 1 a minute, that'll be on #kovri-dev
**\<moneromooo>** Thanks all
**\<tompole>** Monero doesn't need to be concerned with tending to deadlines that relate to other projects.
**\<gingeropolous>** ONWARD MONERO!
**\<kali_>** Thanks guys!
**\<+hyc>** bye all
**\<@ArticMine>** I am going there now.
**\<medusa_>** thaks people, good luck and rock on
**\<sdgsdug9sd>** on a serious note though, can someone just tell whats the anticipated date for gui release?
**\<gingeropolous>** no
**\<kkhugs>** @moneromoo thanks for that address verification wallet API pr
**\<sdgsdug9sd>** why?
**\<gingeropolous>** because development
**\<notyomomma>** monero should be concerned with the needs of the user - which is the gui. I think the questions on timing are relevant
**\<_Slack> \<xmr_eric>** lol
**\<xmrcoma>** gui will be done when it is done. not 1 day before or after
**\<moneromooo>** sdgsdug9sd: apparently tomorrow
**\<xmrcoma>** soon. tm
**\<moneromooo>** (or so I read above)
**\<gingeropolous>** well, its been 2.5 years
**\<pero>** before the documentary
**\<pero>** i think everyone can commit to that?
**\<dEBRUYNE>** Like I said above, luigi & ArticMine will test on windows systems tomorrow
**\<moneromooo>** it's a bit rickety still though
**\<dEBRUYNE>** if there is no issue there, I see no reason to not put the beta release out
**\<endogenic>** exciting
**\<dEBRUYNE>** there can be a subsequent release when the linux path issue, wallet choosing issue, are fixed
**\<xmrcoma>** I saw forget windows. just release for linux and make everyone convert:)
**\<sdgsdug9sd>** hmmm, not sure im getting this clear. so, its expected to be released tomorrow but no later than oct 28?
**\<xmrcoma>** f miscrosoft
**\<moneromooo>** Unless tomorrow forgets to end, I guess.
**\<xmrcoma>** sdg 2017 at the latest
**\<pero>** the reason behind the prioritizing the file paths is that we'll see an influx of 'noobs' asking if this or that directory can be safely deleted
**\<xmrcoma>** but maybe tomorrow:)
**\<gingeropolous>** moneromooo, lulz
**\<dEBRUYNE>** No testing is tomorrow, if that is fine the bins can be put out
**\<dEBRUYNE>** but that isn't necesarily tomorrow too
**\<dEBRUYNE>** :P
**\<hiall>** gui testing tomorrow?
**\<moneromooo>** Oh, multi day testing. Fair enough. Ignore me.
**\<ontario>** noob question here , when the gui is released can we mine directly to gui wallet?
**\<moneromooo>** Later, yes. Not yet.
**\<sdgsdug9sd>** alrighty, what about kovri release? shouldnt it be december 2016?
**\<dEBRUYNE>** moneromooo: you could put your GUI wallet address in the daemon though
**\<xmrcoma>** can someone comment on this? https://www.youtube.com/watch?v=dQw4w9WgXcQ
**\<moneromooo>** dEBRUYNE: what do you mean ?
**\<_Slack> \<dadude>** rickrooool!
**\<dEBRUYNE>** moneromooo: just start_mining in the daemon
**\<_Slack> \<dadude>** it ends in XcQ
**\<dEBRUYNE>** and then your GUI address
**\<dEBRUYNE>** you need a daemon running to use the GUi anyway
**\<moneromooo>** Hmm, yes. That was not the question though I think.
**\<dEBRUYNE>** But that's more of a way around :P I think the guy meant mining directly in the GUI
**\<moneromooo>** Oh, *to*, actually you're right.
**\<tompole>** You mean you still need a terminal window open in order for the GUI to work?

236
_posts/2016-10-30-logs-for-the-Kovri-dev-meeting-held-on-2016-10-30.md
View File

@ -1,236 +0,0 @@
---
layout: post
title: Logs for the Kovri Dev Meeting Held on 2016-10-30
summary: Brief review of what has been completed since last meeting, Kovri Logo, Salti, and code & open tickets discussion
tags: [dev diaries, i2p, crypto]
author: dEBRUYNE / fluffypony
---
*October 30th, 2016*
# Logs
**\<fluffypony>** alright anonimal, the floor is yours
**\<meeting-bot> [anonimal]** Proposed meeting items:
**\<meeting-bot> [anonimal]** 1. Greetings
**\<meeting-bot> [anonimal]** 2. Brief review of what's been completed since the previous meeting
**\<meeting-bot> [anonimal]** 3. @fluffypony's request for finished logo
**\<meeting-bot> [anonimal]** 4. ∫alti as Monero project
**\<meeting-bot> [anonimal]** 5. [libqtoopie](https://github.com/EinMByte/qtoopie/issues/1)
**\<meeting-bot> [anonimal]** 6. Preparing for pre-alpha release
**\<meeting-bot> [anonimal]** 7. Code + ticket discussion / Q & A
**\<meeting-bot> [anonimal]** 8. Any additional meeting items
**\<meeting-bot> [anonimal]** 9. Confirm next meeting date/time
**\<meeting-bot> [anonimal]** Hi
**\<meeting-bot> [EinMByte]** Hi
**\<meeting-bot> [i2p-relay] {-moneromooo}** Hi
**\<meeting-bot> [i2p-relay] {-pero}** hi
**\<meeting-bot> [olark]** Greetings.
**\<boomlol23>** hi
**\<fluffypony>** ola
**\<meeting-bot> [i2p-relay] {-ArticMine}** hi
**\<maoam>** hi
**\<meeting-bot> [anonimal]** 2. Brief review of what's been completed since the previous meeting
**\<meeting-bot> [anonimal]** Lots of refactoring, some fixes.
**\<meeting-bot> [anonimal]** New contributor olark/olarks!
**\<meeting-bot> [anonimal]** Welcome olark!
**\<meeting-bot> [olark]** o/
**\<fluffypony>** welcome olark
**\<meeting-bot> [anonimal]** Anything else on 2.?
**\<meeting-bot> [anonimal]** (olark has been doing great work + tackling a huge learning curve. very cool)
**\<fluffypony>** olark
**\<meeting-bot> [olark]** lots of refactoring ;)
**\<fluffypony>** maybe you can give us a brief background on you
**\<meeting-bot> [i2p-relay] {-Slack} \<nanoakron>** How’s the documentation looking to make that learning curve more shallow for future developers?
**\<meeting-bot> [anonimal]** (e.g., favourite book, long walks on the beach, etc.)
**\<meeting-bot> [anonimal]** nanoakron: moneropedia. We can talk more about that at the end of the meeting too.
**\<meeting-bot> [olark]** Have been programming for the last 3-4 years on and off. Just getting back into C++ have followed Monero and Kovri for the last year or so and figured I should stop procrastinating and help move things forward.
**\<fluffypony>** olark: http://i.imgur.com/9AQYqBr.png
**\<meeting-bot> [olark]** Also long time i2p user, so I know what's up.
**\<meeting-bot> [anonimal]** lol, badge of honor.
**\<meeting-bot> [anonimal]** Alright, well we're glad to have more hands on deck.
**\<meeting-bot> [anonimal]** Anything else before moving onto 3.?
**\<meeting-bot> [olark]** Haha thanks fluffypony
**\<meeting-bot> [anonimal]** 3. fluffypony's request for finished logo
**\<meeting-bot> [anonimal]** fluffypony: ^
**\<fluffypony>** yes
**\<fluffypony>** ok this logo has taken WAY too much time
**\<fluffypony>** I know that logos are kinda-permanent, but it's holding other stuff up
**\<boomlol23>** why are all msgs going through meetingbot..
**\<fluffypony>** boomlol23: because we're spread out over multiple networks
**\<meeting-bot> [anonimal]** fluffypony: what's the best solution for now?
**\<boomlol23>** ok
**\<fluffypony>** I'd like to have the logo by the end of the meeting
**\<fluffypony>** if colours are an issue let's just stick with the original colours
**\<fluffypony>** we can ALWAYS change it later
**\<meeting-bot> [EinMByte]** Wait, we still haven't decided on the logo?
**\<fluffypony>** EinMByte: we have
**\<fluffypony>** but then there were font and kerning and colour changes
**\<ontario>** new monero logo?
**\<meeting-bot> [anonimal]** ontario: kovri logo
**\<fluffypony>** ontario: no Kovri logo, we're in the Kovri meeting now
**\<ontario>** k sry
**\<meeting-bot> [anonimal]** Ok, can pero send you the finished work then?
**\<fluffypony>** np :)
**\<fluffypony>** yes please
**\<sornros>** may I ask if I understood correctly that the i2p code will be rewritten in c++?
**\<meeting-bot> \* anonimal** has to move onto next item....
**\<fluffypony>** either uploading somewhere or ric@getmonero.org
**\<pero>** i thought i 'submitted' the final one last weekend - i'd like to make one tiny half pixel change if i can
**\<meeting-bot> [anonimal]** sornros: we can answer more after the meeting
**\<fluffypony>** sornros: it already is being - https://github.com/monero-project/kovri
**\<pero>** i'll email it to both fluffypony and anonimal shortly
**\<meeting-bot> [anonimal]** Anything else on 3.?
**\<sornros>** thanks
**\<pero>** with the monero colors
**\<fluffypony>** no that's anonimal, tks
**\<pero>** http://imgur.com/a/xCaZV fyi
**\<fluffypony>** that's it
**\<meeting-bot> [anonimal]** 4. ∫alti as Monero project
**\<fluffypony>** pero: ok perfect - if you can send it to me after the pixel change
**\<meeting-bot> [EinMByte]** sure
**\<pero>** half-pixel :P
**\<meeting-bot> [anonimal]** EinMByte: I had some thoughts unless you wanted to dive into anything first
**\<sornros>** thats a nice logo, I like the font too
**\<meeting-bot> [EinMByte]** anonimal: No go ahead
**\<meeting-bot> [anonimal]** We've moved on sornros.
**\<meeting-bot> [anonimal]** EinMByte: since I haven't spent any time researching webextensions, can we *for sure* do what we want to achieve with XUL/XPCOM?
**\<meeting-bot> [anonimal]** I'm thinking we consider brushing aside the deprecation issue for now and someone can pick it up in the future?
**\<PowerFlower>** hi sorry for being late -_- I hope its not too late. Simple question: Will be the GUI released before the next XMR core release in ?Januaray?
**\<meeting-bot> [EinMByte]** It depends what exactly we want to achieve
**\<meeting-bot> [anonimal]** If we *can* do that now, we could move it into monero-project and it will gain more attention.
**\<fluffypony>** PowerFlower: this is the Kovri meeting, you'll have to hold that question for later
**\<PowerFlower>** okay :)
**\<meeting-bot> [anonimal]** EinMByte: well, the easy stuff for starters re: profile. We can do that, right?
**\<meeting-bot> [EinMByte]** anonimal: If we accept that the user will have to use the plugin with a separate profile, then we can do everything we need with webextensions I guess
**\<meeting-bot> [EinMByte]** Can we create the profile using webextensions? Probably not
**\<meeting-bot> [EinMByte]** Then again, people are apparently smart enough to run TBB, so if necessary we can create a script to create the firefox profile
**\<meeting-bot> [anonimal]** I think that was what we were going for
**\<meeting-bot> [EinMByte]** Problem with XUL is that 1) it's deprecated so development will only get worse for us 2) harder to port to other browsers (contrary to webextensions)
**\<meeting-bot> [EinMByte]** It seems like a bad idea to start creating a plugin with deprecated technology
**\<meeting-bot> [anonimal]** Where's the definite deprecation date though?
**\<meeting-bot> [EinMByte]** There is none (very vague, IIRC)
**\<meeting-bot> [EinMByte]** It's also not clear if e.g. it will be deprecated for firebird
**\<meeting-bot> [EinMByte]** (in fact, does anyone know if firebird itself is (going to be) deprecated?)
**\<meeting-bot> \* anonimal** doesn't know
**\<meeting-bot> [anonimal]** So, we are in a good position to influence webext development: they are still taking feature requests, etc. If we get *something* going now, there is a far better likely hood of a webdev coming along to contribute than if we have a mostly empty repo.
**\<meeting-bot> [anonimal]** And I can't find a date for deprecation, should we really base a great idea on what-if's?
**\<meeting-bot> [EinMByte]** Yes, I agree. My spare time does not though
**\<meeting-bot> [anonimal]** I know, nor mine, but I've semi-frequently seen people popping in and out of #monero-dev wanting to contribute to non-c++ projects.
**\<meeting-bot> [EinMByte]** Well, we know for sure it will be deprecated. Just not when. That sounds bad to me, so better try and do it with webext imho
**\<meeting-bot> [anonimal]** Ok, so maybe what we should do now then is write a definite roadmap/readme that will give others a better understanding of wth we are talking about.
**\<meeting-bot> [i2p-relay] {-ArticMine}** I have to leave
**\<meeting-bot> [anonimal]** s/definite/definitive/
**\<meeting-bot> [anonimal]** EinMByte: I think we can easily do that for now. Then, once we are more certain about our webext strategy, bring up this topic at another meeting?
**\<meeting-bot> [anonimal]** If roadmap is too much, at least improve our readme.
**\<meeting-bot> [EinMByte]** anonimal: That's probably a good idea.
**\<meeting-bot> [EinMByte]** Sure.
**\<meeting-bot> [EinMByte]** I agree that we should first see if we can actually do what we want to do, so for example: can we change all of the necessary settings
**\<meeting-bot> [anonimal]** Ok, sounds great. Anything else on 4.?
**\<maoam>** a short readme would be nice
**\<realsony>** EinMbyte may i ask for your GIT repository name i couldn't find it
**\<meeting-bot> [EinMByte]** realsony: EinMByte/salti
**\<meeting-bot> [anonimal]** 5. [libqtoopie](https://github.com/EinMByte/qtoopie/issues/1)
**\<realsony>** ty
**\<meeting-bot> [anonimal]** EinMByte: did you get a chance to review #1?
**\<meeting-bot> [EinMByte]** I read it
**\<meeting-bot> [EinMByte]** Not sure if I can agree with converting it to a library
**\<meeting-bot> [EinMByte]** It should be the other way around, IMHO
**\<meeting-bot> [EinMByte]** qtoopie is based on I2PControl, with the idea of making it router-agnostic
**\<meeting-bot> [anonimal]** As it, you don't think it's possible or don't think it *should* be done or don't want it to be done?
**\<meeting-bot> [anonimal]** So what part would you rather see as the lib?
**\<meeting-bot> [anonimal]** If monero's gui needs it's own i2pcontrol then that's fine; I'm just trying to avoid repetition.
**\<meeting-bot> [EinMByte]** It depends on what we want: if we want to build a router-agnostic GUI, I think I2PControl is the best option. In that case we could simply bundle qtoopie + kovri router and release this as an easy-to-use router package
**\<meeting-bot> [EinMByte]** If we want to build a GUI specifically for kovri, then we can rely on the (currently not existing) kovri API (libcore/libclient)
**\<meeting-bot> [EinMByte]** But in that case too, it would not really make sense for it to be a library. Instead, it would be comparable to what kovri-app currently is, except that it would be a GUI rather than CLI
**\<meeting-bot> [anonimal]** re: API, that's what the monero gui will be using, but where could we eliminate redundancy if the API and i2pcontrol would also do some of the more basic things that i2pcontrol provides?
**\<fluffypony>** I2PControl would be able to control Kovri + Java i2p etc. right?
**\<meeting-bot> [EinMByte]** My original idea for qtoopie is that it would fork for all exiting I2P routers that support I2PControl.
**\<fluffypony>** oh I missed the "based on"
**\<fluffypony>** ok makes sense
**\<meeting-bot> [EinMByte]** So the redundancy is not eliminated at the level of the kovri implementation, but instead at all implementations (no need for a specific GUI)
**\<meeting-bot> [anonimal]** EinMByte: Ok, that I understand. But there's really no way to create libqtoopie so the monero gui can use it *now* (even in it's current state)?
**\<meeting-bot> [anonimal]** Why create extra monero gui code and i2pcontrol impl when that's already done?
**\<meeting-bot> [anonimal]** This doesn't change the functionality of qtoopie. I'm just basing this off what you said when I brought up the lib idea a while ago.
**\<meeting-bot> [EinMByte]** Sure, monero can use qtoopie directly
**\<meeting-bot> [anonimal]** If it's more work than not, and adversely effects qtoopie, then I understand.
**\<meeting-bot> [EinMByte]** at least in the sense "you can display the windows defined in the qtoopie project"
**\<meeting-bot> [EinMByte]** I guess that would classify as a library.
**\<meeting-bot> [EinMByte]** The question is why you would want to bundle it like that
**\<meeting-bot> [EinMByte]** (you could also just provide the executable with the monero executables, and then open this from the monero GUI, there would be little difference to the end use)
**\<meeting-bot> [anonimal]** To save redundant code so people don't have to install qtoopie to use qtoopie; and so it's integrated with the monero gui.
**\<fluffypony>** can't we have our own controls in the GUI
**\<fluffypony>** with bindings to libqtoopie functions ?
**\<meeting-bot> [anonimal]** fluffypony: own controls to API, sure.
**\<meeting-bot> [anonimal]** fluffypony: libqtoopie, EinMByte would know; I imagined yes.
**\<meeting-bot> [EinMByte]** By the way, for reference on i2pcontrol: http://zzz.i2p/topics/2030-proposal-bundle-i2pcontrol, http://zzz.i2p/topics/1942-i2pcontrol-for-generic-user-interfaces
**\<meeting-bot> [EinMByte]** If you want to have your own controls, there's not much point in using all of qtoopie
**\<meeting-bot> [EinMByte]** then you just need to use i2pcontrol
**\<meeting-bot> [EinMByte]** (which is very simple to implement; or you could use the part of qtoopie that deals with this)
**\<meeting-bot> [anonimal]** EinMByte I think you're missing the point but I'm probably not explaining my intentions well.
**\<meeting-bot> [anonimal]** So, libqtoopie: not needed. qtoopie: agnostic but will not be in library form.
**\<meeting-bot> [anonimal]** We will create our own controls that use the API
**\<meeting-bot> [EinMByte]** qtoopie is an end-user program, hence why I'd say "not in library form"
**\<meeting-bot> [anonimal]** I know EinMByte, I'm just trying to save time and code.
**\<meeting-bot> [EinMByte]** We could take some of the code in qtoopie and put it in a library "libi2pcontrol-client"
**\<meeting-bot> [EinMByte]** This library could then be used by e.g. monero
**\<meeting-bot> [anonimal]** i2pcontrol is insanely overrated, seriously overrated in relation to as much time as we're talking about it.
**\<meeting-bot> [EinMByte]** But this is assuming that monero would be using i2pcontrol at all
**\<meeting-bot> [anonimal]** I don't see the point if there are API's in place.
**\<meeting-bot> [anonimal]** And i2pcontrol is limited in its own right.
**\<meeting-bot> [EinMByte]** Yes, i2pcontrol has severe limitations
**\<meeting-bot> [anonimal]** So, unless that entire spec is worked on, I have nothing more to say on the subject for now.
**\<meeting-bot> [EinMByte]** (even the proposed version 2)
**\<meeting-bot> [anonimal]** Ok, so we'll learn from the mistakes of others and try not to make our own.
**\<meeting-bot> [anonimal]** fluffypony: does that makes sense? anyone need a tl;dr?
**\<fluffypony>** yes it does
**\<fluffypony>** tl;dr for the log
**\<meeting-bot> [anonimal]** tl;dr qtoopie is great. We won't be using qtoopie in lib or bundled form because of severe limitations in i2pcontrol. We will be using GUI controls via the kovri API(s).
**\<meeting-bot> [EinMByte]** What is important to understand is that I2PControl is intended to create high-level control programs
**\<meeting-bot> [EinMByte]** It isn't designed to deal with lower-level configuration that monero might need
**\<meeting-bot> [anonimal]** Anything else on 5.?
**\<meeting-bot> [EinMByte]** One of the main limitations, in case anyone is wondering, is that i2pcontrol has to serialize everything and send it over the network
**\<meeting-bot> [EinMByte]** There's no possiblity of handlers or anything like that too
**\<meeting-bot> [EinMByte]** (you have to continuously request updates)
**\<meeting-bot> [anonimal]** yes.
**\<meeting-bot> [anonimal]** Ok, 8 minutes
**\<meeting-bot> [anonimal]** 6. Preparing for pre-alpha release
**\<meeting-bot> [EinMByte]** For a simple GUI, that's probably good enough but it doesn't work when you want to integrate kovri with something like monero
**\<meeting-bot> [anonimal]** Yay! Nov. 1st pre-alpha will not happen, nooo way. I've been busy this month with non-code work; only recently with more code.
**\<meeting-bot> [anonimal]** EinMByte has been very busy too.
**\<meeting-bot> [EinMByte]** :|
**\<fluffypony>** no problemo - let's get it right instead of getting it rushed :)
**\<meeting-bot> [anonimal]** EinMByte: realistically, I think we should push the date to Dec. 1st or later.
**\<meeting-bot> [anonimal]** It's never going to perfect in my eyes, but...
**\<meeting-bot> [EinMByte]** Sure
**\<meeting-bot> [EinMByte]** dont' expect more activity from me though
**\<meeting-bot> [anonimal]** You mean ever or temporary?
**\<meeting-bot> \* anonimal** hopes temporary
**\<meeting-bot> [EinMByte]** I mean before december the first
**\<meeting-bot> [anonimal]** Ok. I'll set a tentative date for dec. 1st; no later than 33c3.
**\<meeting-bot> [anonimal]** (which is not dec. 1st of course)
**\<meeting-bot> [anonimal]** I'll have to adjust the milestone date on github and roadmap etc.
**\<meeting-bot> [anonimal]** Any other thoughts on 6.?
**\<meeting-bot> [anonimal]** This coming month should be far more productive code-wise than in october.
**\<meeting-bot> [anonimal]** We'll see what we can knock-out before december.
**\<meeting-bot> [anonimal]** 2 minutes to spare
**\<meeting-bot> [anonimal]** Skipping 7. Code + ticket discussion / Q & A unless anyone wants to say something?
**\<meeting-bot> [anonimal]** 8. Any additional meeting items
**\<fluffypony>** nope that's it from my side
**\<fluffypony>** glad to see the refactoring efforts
**\<fluffypony>** will make stuff easier to work on later on
**\<meeting-bot> [iDunk]** head works now, thanks anonimal
**\<PowerFlower>** oberservers can now ask questions?
**\<meeting-bot> [anonimal]** fluffypony: yes indeedy
**\<meeting-bot> [anonimal]** iDunk: you're welcome, thanks for the notice and for actively testing :)
**\<meeting-bot> [iDunk]** np :)
**\<meeting-bot> [anonimal]** PowerFlower: kovri questions, yes
**\<fluffypony>** ok let's close up the Kovri meeting and then PowerFlower can ask their Monero question :-P
**\<meeting-bot> [anonimal]** Oh, those kinds of questions.
**\<meeting-bot> [anonimal]** Ok, 9. Confirm next meeting date/time
**\<meeting-bot> [anonimal]** Same time, two weeks?
**\<meeting-bot> [olark]** Sounds good.
**\<fluffypony>** yes
**\<meeting-bot> [anonimal]** Alright, thank you EinMByte and everyone else here for making the meeting.
**\<fluffypony>** meeting bot going down to switch back to the Monero stuf
**\<meeting-bot> [anonimal]** Thanks fluffypony

265
_posts/2016-10-30-overview-and-logs-for-the-dev-meeting-held-on-2016-10-30.md
View File

@ -1,265 +0,0 @@
---
layout: post
title: Overview and Logs for the Dev Meeting Held on 2016-10-30
summary: Fluffy blocks, crypto libs
tags: [dev diaries, core, crypto, 0mq]
author: dEBRUYNE / fluffypony
---
*October 30th, 2016*
# Overview
An overview [can be found on Hello Monero](https://hellomonero.com/article/monerokovri-dev-meeting-note-highlights-2016-10-30).
# Logs
**\<Jaquee>** it takes quite long time to open/close wallets with this mempool size. Could the mempool be saved in wallet cache?
**\<Jaquee>** or is that a bad idea?
**\<Jaquee>** doesnt really affect closing wallets. my bad. but opening takes longer than normal i think?
**\<realsony>** test
**\<moneromooo>** You can test that easily by logging something before and after loading.
**\<moneromooo>** It's in src/cryptonote_core/tx_pool.cpp
**\<hyc>** is it mtg time yet?
**\<moneromooo>** Yes
**\<pero>** romero dev conference
**\<Jaquee>** all right. the gui def takes longer time top open because of mempool. And it also waits for mempool to be synced before closing.
**\<hyc>** why is that different from CLI behavior?
**\<Jaquee>** not sure yet
**\<Jaquee>** opening seems the same
**\<pero>** mooo you're a whitespace nazi
**\<Slack> \<nanoakron>** Is there a way that git PRs could be run through a common parser on the server-side to standardise any whitespace?
**\<moneromooo>** Not really, since it'll invariably try to reformat irrelevant stuff.
**\<moneromooo>** That said, if it could run on the diffs, it might work.
**\<Slack> \<nanoakron>** And WRT mempool size - would fluffy blocks as standard across the network (e.g. if included in HF4) make things better?
**\<revler1082>** i don't think so, it just helps with not sending txs again when a block is found, the mempool size is unaffected
**\<moneromooo>** So... if the pony isn't here... anyone wants to say something dev related ?
**\<Slack> \<nanoakron>** OK yes I see. But it should allow us to avoid some of the issues that bitcoin is having - if all mempools are synched and a miner wants to eat all the transactions into a single megablock, it would propagate much more quickly than without
**\<Slack> \<nanoakron>** I’m a tinkerer rather than a dev :slightly_smiling_face:
**\<revler1082>** yea so the bigger the blocks (assuming mempools are aligned), the greater the savings
**\<Slack> \<nanoakron>** Which would be an extra cool reason for making fluffy blocks compulsory in a hard fork
**\<revler1082>** hmm, I saw monero-moo's latest comments on the fluffy-block stuff, so I was going to go through those, but I don't have much else.
**\<revler1082>** if you guys would like me to change anything, etc, feel free to ask/comment
**\<Slack> \<nanoakron>** My only ‘dev issue’ is with the growing number of dead issues on github
**\<Slack> \<nanoakron>** We should probably only be at 60 or so live issues
**\<moneromooo>** I think at this point, it's testing. Especially that one about the array of txes noit in the pool but not requested again.
**\<realsony>** may i as what a dead issue is?
**\<realsony>** ask
**\<Slack> \<nanoakron>** One that’s been solved
**\<realsony>** ty
**\<dEBRUYNE>** monero-core has a lot of those too fwiw
**\<dEBRUYNE>** I can give you a list for monero-core fluffypony
**\<hyc>** typically I would not close an issue until the fix is in a tagged release
**\<hyc>** (at least, on other projects.)
**\<pero>** ^ +1
**\<Slack> \<nanoakron>** Or where the codebase has evolved onwards but the original person who has raised the issue has not tested to see if it’s still active
**\<pero>** or at the very least merged
**\<Slack> \<nanoakron>** @hyc can I ask - completely separate issue, have you considered offering your skills to port Bitcoin Unlimited to LMDB? They’ve got $500k in the bank...
**\<hyc>** I hadn't heard anything about that nanoakron
**\<Slack> \<nanoakron>** @hyc ask around - I’m sure their users would want to offer an even better reason to switch their node software away from core
**\<ArticMine>** Bitcoin unlimited will be insecure once the emission runs out
**\<Slack> \<nanoakron>** And I think the entire ecosystem will benefit
**\<Slack> \<nanoakron>** As for dead issues - there are still ones hanging around from before 0.10.0 which either haven’t been updated by their issuers or have been addressed
**\<hyc>** would definitely be a good idea to go thru and close any that havve been fixed
**\<revler1082>** @moneromooo i had left a comment in the code about whether I was double verifying since all the transactions were already in the pool, anything on that?
**\<revler1082>** could speed things up a bit
**\<moneromooo>** I'll have a look soon. String to grep for ?
**\<revler1082>** "Do I need to do this" lol
**\<moneromooo>** ok
**\<Slack> \<nanoakron>** lol
**\<Slack> \<malmen>** How is 0qm work?
**\<moneromooo>** proxmr: you'll know in ~30 min when anonimal's around for the kovri meeting.
**\<moneromooo>** tewinget: around ?
**\<Slack> \<nanoakron>** So the big themes I see in current development are: ZMQ, GUI, final touches to RingCT (?), changing the crypto library, changing the logging system and fluffy blocks. Any others?
**\<Slack> \<malmen>** What is fluffy blocks? I am missing something here
**\<iDunk>** dynamic fees
**\<revler1082>** @mailmen just a compact block implementation for monero
**\<moneromooo>** It's just sending txes from a block only if a peer doens't have them already.
**\<Slack> \<malmen>** Hmmmm, so, instead of sending all tx the block will contain only the reference of the tx that is in another block?
**\<Slack> \<nanoakron>** No, reference to the local mempool
**\<Slack> \<malmen>** Ahh
**\<revler1082>** no, it just sends the tx hashes, and since most nodes have the transactions in the mempool, it just gets the full tx from there
**\<Slack> \<nanoakron>** And if it’s not in there then you receive the missing Tx
**\<revler1082>** if it's missing any, it'll ask for those
**\<Slack> \<malmen>** Nice
**\<Slack> \<nanoakron>** Really nice :slightly_smiling_face:
**\<Slack> \<malmen>** It is implemented in any place already or we will be the first ones to have it?
**\<Slack> \<nanoakron>** Bitcoin has it
**\<revler1082>** yep, multiple implementations, xthin/compact blocks
**\<Slack> \<nanoakron>** but because they’re a dirty mix of hard and soft forked rules, and have a stupid mempool policy preventing network-wide synchronisation, they won’t see as much benefit as we will
**\<revler1082>** there's some way to save even more space based on some of the stuff you guys shared with me, where you send just some prefix of the tx_hash since there's unlikely to be collisions, but I think sacrificing some space to keep things simple is ok
**\<Slack> \<malmen>** Hmmm, nice... And about the way the db save the blocks, I was thinking in the other day
**\<Slack> \<nanoakron>** @revler1082 you should contact the original devs of XThin and ask them about those issues :slightly_smiling_face:
**\<moneromooo>** I don't know how the bitcoin ones work, but given what you wrote, I'd send the index of the tx you don't have. Possibly differential encoded.
**\<Slack> \<nanoakron>** @hyc is your db guy
**\<Slack> \<malmen>** Instead of the block on the the database save the full tx, can it be save the reference to other block with tx? It will use more disk io and cpu, but can save space
**\<revler1082>** thanks @moneromooo that's a good one
**\<moneromooo>** I'm guessing there might be a good reason why they don't do that though.
**\<Slack> \<nanoakron>** Well that’s an interesting point - if you’re pulling in other transactions to build your ring signature, do you do that from the mempool or from historic data stored in the local db? I’m not sure myself
**\<ArticMine>** The idea if I understand this is to save bandwidth
**\<revler1082>** @ArticMine correct
**\<revler1082>** not much difference now, but when monero takes over the world, savings should increase
**\<ArticMine>** You pull from the historic data not the mempool
**\<Slack> \<nanoakron>** So not many dev issues today which is good. Just really revler and moneromooo co-reviewing fluffy block code, and maybe closing old issues?
**\<moneromooo>** We can't close old issues. We can just make lists and wait for fluffypony to have time :)
**\<Slack> \<nanoakron>** True
**\<revler1082>** What's the crypto-lib replacement? I could maybe help with that, I mean my crypto skills are le garbage, but I can change function calls, lol
**\<Slack> \<nanoakron>** Would you think about the logging system in that case? The crypto currently works well enough
**\<moneromooo>** The main problem is choosing the best one. And that needs people who know them. The pony does I think.
**\<revler1082>** logging or crypto? or both?
**\<Slack> \<nanoakron>** Moneromooo, do you have any thoughts on where revler can best help after fluffy blocks are finished?
**\<moneromooo>** We'll need some crypto lib with a good PRNG, to replace the keccak construction we use now.
**\<Slack> \<nanoakron>** https://github.com/monero-project/monero/issues/1271
**\<Slack> \<nanoakron>** That’s what we’re referencing here revler - already some good discussion to review there
**\<moneromooo>** Wherever revler1082 is comfortable, really. If the previous bit changed was network stuff, then maybe more of it ?
**\<Slack> \<nanoakron>** What do you think the issues are with current network code?
**\<moneromooo>** fluffypony wanted to switch the P2P protocol to... er... something... name escapes me.
**\<Slack> \<nanoakron>** ;)
**\<moneromooo>** ZMTP.
**\<Slack> \<nanoakron>** ooh…sounds fancy. How about maybe helping with ZMQ??
**\<iDunk>** jesus
**\<moneromooo>** It's based on epee, from the CN people.
**\<Slack> \<nanoakron>** @iDunk you rang?
**\<revler1082>** all sounds good, i'll look into it and help where I can
**\<moneromooo>** The P2P code is really hard to understand, though that is subjective, mayube others like it more.
**\<iDunk>** yeah, I'm on the verge of really saying something
**\<moneromooo>** There are a few bugs, mainly that it leaks sockets.
**\<revler1082>** if i ever get my spaces and tabs passed @moneromooo
**\<Slack> \<nanoakron>** hehe
**\<Slack> \<nanoakron>** What’s up iDunk?
**\<moneromooo>** Well, it boils down to "don't change what you don't change".
**\<iDunk>** nanoakron: take it easy, man
**\<moneromooo>** But I agree I may be a bit too sold on clean diffs without extraneous stuff.
**\<moneromooo>** Those things are easy to fix though.
**\<revler1082>** lol, @moneromooo just messin, I want to kick myself when I push and see those in the diff, like mother ..
**\<Slack> \<nanoakron>** Revler wants to help with network related stuff and I’m just saying what’s in the codebase that is being worked on
**\<moneromooo>** And maybe helping with 0MQ, I guess it'll need some testing and fixing once tewinget's done with it to a point where it can be merged.
**\<fluffypony>** yes ZMTP
**\<moneromooo>** pony!
**\<Slack> \<nanoakron>** Woo!
**\<fluffypony>** apologies
**\<fluffypony>** had the meeting down for 7pm not 6pm
**\<Slack> \<nanoakron>** Do you guys change your clocks today down there in SA?
**\<Slack> \<nanoakron>** Ours went back last night. It’s now dark at 5pm. Misery.
**\<fluffypony>** no, we don't do DST
**\<fluffypony>** OH that's why
**\<fluffypony>** everything is confusing
**\<DaveyJones>** thought sth like this :p
**\<fluffypony>** re: closing issues
**\<fluffypony>** I'm happy to close them from lists
**\<fluffypony>** and I don't think we need to wait for them to be in a tagged release per se
**\<Slack> \<nanoakron>** Cool
**\<fluffypony>** have we discussed the compact blocks thing ?
**\<fluffypony>** I see there's some backlog on it
**\<Slack> \<nanoakron>** Briefly
**\<pero>** what prevents dupes then?
**\<pero>** might be better to tag issues with 'fixed in next release' or something and keep them open?
**\<revler1082>** all the verification is the asme, it's just saving from re-sending txs?
**\<fluffypony>** pero: dupe issues?
**\<revler1082>** oh
**\<pero>** yea
**\<fluffypony>** lol
**\<fluffypony>** revler1082: I was also confused
**\<pero>** sorry =/
**\<fluffypony>** np
**\<fluffypony>** pero raises a good point
**\<fluffypony>** I can flag them instead
**\<moneromooo>** If people don't search the bugs list, they'll file a dupe whether it's closed or open, no ?
**\<Slack> \<nanoakron>** Take https://github.com/monero-project/monero/issues/1256 as an example
**\<Slack> \<nanoakron>** May be a dupe, may not be...
**\<moneromooo>** I'm fine with bugs being opened when in doubt.
**\<Slack> \<nanoakron>** @moneromooo - yes they will
**\<dEBRUYNE>** \<fluffypony> everything is confusing <= Oh I didn't notice too
**\<pero>** but they likely won't experience the issue if it's in a release
**\<dEBRUYNE>** That link I posted on reddit says 17:00 Europe time lol
**\<fluffypony>** lol
**\<fluffypony>** ok so re: compact blocks
**\<revler1082>** got some fixes and ideas from @moneromooo that i'm gonna try
**\<fluffypony>** do we put it in a fork wrapper so that it only activates in Jan? or are we using the versionbits and making it available from now?
**\<revler1082>** only big thing is do we want backwards compatibility and a little messier code, or alter existing stuff/cleaner?
**\<Slack> \<nanoakron>** The good thing about hard forks is that we don’t need backwards compatibility
**\<moneromooo>** I'd rather have it in testnet first.
**\<Slack> \<nanoakron>** Yes
**\<revler1082>** definitely
**\<fluffypony>** ok let's finish the compact blocks discussion
**\<fluffypony>** PowerFlower: pleasure :)
**\<moneromooo>** I'd like to know what the changes are going to be with sodium/NaCl/cryptocpp/whatever. I don't know them, so I don't have useful input.
**\<Jaquee>** PowerFlower: Thank you. bye
**\<moneromooo>** Compact blocks: pretty good, not much to change, will need lots of testing though.
**\<revler1082>** yep
**\<fluffypony>** re: backwards compatibility, I don't think we need to support an environment where compact blocks isn't supported - a node that doesn't want to use it can just never claim to already have txs
**\<dEBRUYNE>** revler1082: Have you tested it on a personal private testnet?
**\<revler1082>** yea, and on mainnet with the backwards stuff
**\<dEBRUYNE>** oh cool
**\<fluffypony>** since we have a testnet reorg coming up we can use the opportunity to test wrapping it in a fork
**\<moneromooo>** We need to have both block types in the code at the same time though.
**\<moneromooo>** So if we do, conditional use isn't much more.
**\<moneromooo>** BTW, syncing from scratch uses a different set of messages, right ?
**\<revler1082>** yes i believe so
**\<moneromooo>** A possible optimization would be to always include txes with too low fee, since these would have been mined by the local host.
**\<realsony>** So men i read everything, didnt understand 97% :) convinces me that XMR has the best alt dev team :)
**\<moneromooo>** But that's really not needed now.
**\<revler1082>** yea, there's a few tweaks we can make, i like your send tx index instead of hash for missing
**\<moneromooo>** Yes, it sounds like a no brainer, so I'm suspicious that bitcoin is not doing it for non obvious reasons...
**\<moneromooo>** fluffypony: do you know why they use siphash hashes and not indices in the block ?
**\<moneromooo>** (since you linked to that doc, I think you might know :P)
**\<fluffypony>** moneromooo: I have no idea
**\<ontario>** noob suggestion: for the next meeting how about disabling other chat unless dev when the meeting bot started?
**\<fluffypony>** btcdrak might have an idea
**\<fluffypony>** ontario: if the room goes +m then only people with +v can speak, and then it becomes a closed meeting
**\<fluffypony>** better for it to stay open, we can handle the occasional interruption
**\<btcdrak>** yeah that's what to do
**\<ontario>** lol sry dont know much about irc things
**\<fluffypony>** btcdrak: moneromooo had a question about compact blocks, and why it uses siphash hashes instead of indices
**\<moneromooo>** (note, I know very little about bitcoin, so it could be tx indices don't make sense in bitcoin)
**\<btcdrak>** moneromooo: ask in #bitcoin-core-dev
**\<moneromooo>** OK, I will, thanks.
**\<i2p-relay> {-anonimal}** moneromooo: re: crypto, https://cryptopp.com/ has a list of all supported schemes. I know monero will have to keep supercop/ref10 impl but most others look covered (though I can't say *all* because I haven't yet looked at all monero crypto yet)
**\<fluffypony>** my thinking is that we can offload the sensitive stuff to TweetNaCl (ie. crypto_ops), as it's currently using SUPERCOP ref10
**\<fluffypony>** then we offload everything else to cryptocpp, including random
**\<fluffypony>** and then *if* we're seeing performance bottlenecking in something specific, we can use ASM implementations *only* in the places it's bottlenecking
**\<moneromooo>** Since we use part of... libsodium ? Does this not do everything we need ?
**\<fluffypony>** moneromooo: the libsodium source isn't even complete, so we'd have to make changes anyway
**\<fluffypony>** libsodium isn't as full-featured as cryptocpp anyway
**\<fluffypony>** and not as audited as TweetNaCl
**\<moneromooo>** Anything else to talk about ?
**\<fluffypony>** well
**\<i2p-relay> {-anonimal}** So there won't be a one-size-fits-all crypto solution, eh?
**\<fluffypony>** btw moneromooo
**\<fluffypony>** https://en.wikipedia.org/wiki/NaCl_(software)
**\<fluffypony>** so TweetNaCl implements all of those
**\<fluffypony>** as does libsodium
**\<fluffypony>** that libsodium can do a handful of extra things is neither here nor there
**\<fluffypony>** https://en.wikipedia.org/wiki/Comparison_of_cryptography_libraries
**\<moneromooo>** I'm curious to know why they made many versions of hte same thing.
**\<fluffypony>** the advantage is that cryptocpp can do a TON of stuff, it's FIPS 140 validates, and it uses the Boost license
**\<moneromooo>** That sounds like a recipe for pita.
**\<fluffypony>** moneromooo: of NaCl?
**\<moneromooo>** Yes.
**\<fluffypony>** they only made NaCl, and then they made TweetNaCl specifically to be extremely simple and auditable (so that it could be formally verified)
**\<fluffypony>** NaCl was forked and thus begat libsodium
**\<fluffypony>** so the original NaCl reference implementation has been replaced by libsodium, effectively
**\<moneromooo>** crypto++ is the same as cryptopp ?
**\<fluffypony>** yes
**\<fluffypony>** also has AES-NI support, which is great
**\<fluffypony>** doesn't have ARMv8 crypto support yet
**\<fluffypony>** "Unix (OpenBSD, Linux, OS X, etc.), Win32, Win64, Android, iOS, ARM"
**\<Slack> \<nanoakron>** Not may Cortex-A53 ARMv8 systems in the wild seem to have hardware crypto so far…apparently they need to pay for an extra license to enable it
**\<Slack> \<nanoakron>** Pine64 may do, but I’ve not bought one yet
**\<pero>** pine64 does
**\<moneromooo>** So if we were to switch to cryptopp, would be still keep the existing low level crypto code, or just use for new stuff ?
**\<moneromooo>** Though I guess we have a readily available test suite actually :)
**\<i2p-relay> {-anonimal}** fluffypony: I believe there is limited(?) armv8 support, or do you mean specifically aes-ni?
**\<i2p-relay> {-anonimal}** \* going off of memory, would need to confirm
**\<fluffypony>** anonimal: it's not NB right now
**\<fluffypony>** moneromooo: we'd switch
**\<fluffypony>** even if it's piecemeal
**\<Slack> \<nanoakron>** Sorry to ask about stuff that’s already been covered - what’s the final decision for integrating fluffy blocks? Implement as-is on testnet, then with version flags for 0.10.0, then with forking code for January, then finally abandon backwards compatible code at HF 5?
**\<Slack> \<nanoakron>** So that all nodes at HF5 will use compact blocks (of whatever improved flavour comes along in the interim)
**\<pigeons>** its not "forking code" though right?
**\<fluffypony>** no it's not
**\<Slack> \<nanoakron>** So it could in fact be made compulsory at HF 4 without backwards compatible code?
**\<fluffypony>** and I mistakenly forgot that we need to keep both block formats anyway for sync up
**\<fluffypony>** so not worth putting it in an HF wrapper
**\<Slack> \<nanoakron>** Unless we checkpoint at the next HF...
**\<moneromooo>** Not for 4. Seriously...

Some files were not shown because too many files have changed in this diff Show More