diff --git a/.gitignore b/.gitignore new file mode 100644 index 00000000..ce84d723 --- /dev/null +++ b/.gitignore @@ -0,0 +1,3 @@ +ietemplates/ +_site/* +.idea/ diff --git a/404/css/ie7.css b/404/css/ie7.css new file mode 100644 index 00000000..26cb5711 --- /dev/null +++ b/404/css/ie7.css @@ -0,0 +1,25 @@ +@charset "utf-8"; +div.not-found-text{ + top:65px; +} + +div.planet{ + z-index:-1; +} + +div.dog{ + z-index:1000; +} + +div.dog-bubble{ + filter: alpha(opacity=0); /* IE6+ */ + filter: progid:DXImageTransform.Microsoft.Alpha(opacity=0); /* IE6+ */ + -ms-filter: "progid:DXImageTransform.Microsoft.Alpha(opacity=0)"; + padding-top:35px; +} + +#dog-changer ul li a{ + filter: alpha(opacity=30); /* IE6+ */ + filter: progid:DXImageTransform.Microsoft.Alpha(opacity=30); /* IE6+ */ + -ms-filter: "progid:DXImageTransform.Microsoft.Alpha(opacity=30)"; +} \ No newline at end of file diff --git a/404/css/main.css b/404/css/main.css new file mode 100644 index 00000000..97ad013e --- /dev/null +++ b/404/css/main.css @@ -0,0 +1,313 @@ +@charset "utf-8"; + +/* === General stuff === */ + +html, body{ + height:100%; + background:#186aa9 url(/404/images/sky-background.png) top repeat-x; + overflow:hidden; + padding:0; + margin:0; + font-family:Arial, Helvetica, sans-serif; + margin-top: 5px; +} + +.footer{ + display: none; +} + +a{ + color:#3680b1; +} + +img, a img{ + border:0px none; + outline:none; +} + +/* === Main Section === */ + +#wrapper{ + width:980px; + margin:0px auto; + position:relative; + height:100%; + background:url(/404/images/sky-shine.jpg) top left no-repeat; +} + +div.top-left{ + position:absolute; + right:0px; +} + +div.not-found-text{ + position:absolute; + top:35px; + right:0px; + width:430px; +} + +h1.not-found-text{ + font-size:50px; + color:#fff; + letter-spacing:2px; + margin-bottom:20px; +} + +div.graphic{ + position:absolute; + top:80px; + left:0px; +} + +div.planet{ + position:absolute; + bottom:-720px; + margin:0px auto; + z-index:0; +} + +div.planet>img{ + width:960px; +} + +div.dog-wrapper{ + position:absolute; + top:45px; + left:440px; +} + +div.dog{ + position:absolute; + bottom:0px; + left:0px; + width:80px; + height:80px; + z-index:999; + background:url(/404/images/dog1.png) 0px 0px no-repeat; +} + +div.dog-bubble{ + font-size:18px; + line-height:1.5; + font-style:italic; + height:179px; + width:246px; + background:url(/404/images/bubble.png) top center no-repeat; + padding:20px 0px; + position:absolute; + bottom:0px; + left:30px; + z-index:999; + opacity:0; + color:#555555; + text-shadow:1px 1px 0 #ffffff; +} + +div.dog-bubble>p{ + text-align:center; + padding:0px 35px; +} + +div.bubble-options{ + opacity:0; + visibility:hidden; + display:none; +} + +/* === Responsive === */ + +/* #Small laptop screens +================================================== */ + + @media only screen and (max-width: 960px) { + #wrapper{ + width:600px; + background-image:none; + margin-top: 50px; + } + + div.planet{ + position:absolute; + bottom:-300px; + margin:0 auto 0 -280px; + z-index:0; + left:50%; + + } + + div.planet>img{ + width:560px; + } + + div.dog-wrapper{ + position:absolute; + top:30px; + left:250px; + + } + + div.graphic{ + position:absolute; + top:50px; + left:40px; + + } + + div.top-left { + position: absolute; + right: 0px; + top: -40px; + } + + div.graphic>img{ + width:60%; + } + + div.graphic{ + left: 0px; + position: absolute; + top: 20px; + } + + div.not-found-text{ + right:0px; + top:22px; + width:320px; + } + + h1.not-found-text{ + font-size:35px; + } + + } + + +/* #Tablets and small screens +================================================== */ + + @media only screen and (max-width: 767px) { + + #wrapper{ + width:400px; + background-image:none; + } + + div.graphic>img{ + width:40%; + } + + div.planet{ + position:absolute; + bottom:-170px; + margin:0 auto 0 -180px; + z-index:0; + left:50%; + + } + + div.planet>img{ + width:360px; + } + + div.dog-wrapper{ + position:absolute; + top:30px; + left:150px; + + } + + div.graphic{ + position:absolute; + top:20px; + left:0px; + + } + + div.top-left { + position: absolute; + right: 390px; + top: 170px; + } + + h1.not-found-text { + font-size: 26px; + } + + div.not-found-text { + right: -60px; + top: 33px; + width: 270px; + } + + div.top-left { + position: absolute; + right: 0; + top: -38px; + } + + } + + +/* #Mobile phones +================================================== */ + + @media only screen and (max-width: 479px){ + + #wrapper{ + width:320px; + background-image:none; + } + + h1.not-found-text { + font-size: 20px; + text-align: center; + } + + div.not-found-text { + right: 20px; + top: 210px; + } + + div.graphic>img{ + width:100%; + } + + + div.planet{ + position:absolute; + bottom:-70px; + margin:0 auto 0 -100px; + z-index:0; + left:50%; + + } + + div.planet>img{ + width:200px; + } + + div.dog-wrapper { + left: 70px; + position: absolute; + top: 26px; + } + + div.dog-bubble{ + font-size:10px; + line-height:1.5; + font-style:italic; + height:107px; + width:147px; + background:url(/404/images/bubble.png) top center no-repeat; + background-size: contain; + padding:10px 0px; + position:absolute; + bottom:0px; + left:55px; + z-index:999; + opacity:0; + color:#555555; + text-shadow:1px 1px 0 #ffffff; + } + } \ No newline at end of file diff --git a/404/images/404.png b/404/images/404.png new file mode 100644 index 00000000..621b3a8b Binary files /dev/null and b/404/images/404.png differ diff --git a/404/images/bubble.png b/404/images/bubble.png new file mode 100644 index 00000000..9faa0336 Binary files /dev/null and b/404/images/bubble.png differ diff --git a/404/images/cat.png b/404/images/cat.png new file mode 100644 index 00000000..c8d129d7 Binary files /dev/null and b/404/images/cat.png differ diff --git a/404/images/cookie.png b/404/images/cookie.png new file mode 100644 index 00000000..0488384d Binary files /dev/null and b/404/images/cookie.png differ diff --git a/404/images/dog1.png b/404/images/dog1.png new file mode 100644 index 00000000..2e8da0bc Binary files /dev/null and b/404/images/dog1.png differ diff --git a/404/images/planet.png b/404/images/planet.png new file mode 100644 index 00000000..234da2ac Binary files /dev/null and b/404/images/planet.png differ diff --git a/404/images/sky-background.png b/404/images/sky-background.png new file mode 100644 index 00000000..9b381985 Binary files /dev/null and b/404/images/sky-background.png differ diff --git a/404/images/sky-shine.jpg b/404/images/sky-shine.jpg new file mode 100644 index 00000000..0e8ac1fd Binary files /dev/null and b/404/images/sky-shine.jpg differ diff --git a/404/index.md b/404/index.md new file mode 100644 index 00000000..ffde8e51 --- /dev/null +++ b/404/index.md @@ -0,0 +1,39 @@ +--- +layout: error +title: "Error 404, Page Not Found" +--- + + + + +
+
+ 404 +
+ +
+
+

Oh no, we couldn't find anything for that link!

+
+
+ +
+
+
+
+ +
+ {% for data_talk in site.data.dogtalk %} +

+ {{ data_talk.bubble }} +

+ {% endfor %} +
+
+ + planet +
+ +
\ No newline at end of file diff --git a/README.md b/README.md new file mode 100644 index 00000000..7de991d4 --- /dev/null +++ b/README.md @@ -0,0 +1,56 @@ +# Monero + +Copyright (c) 2014-2017, The Monero Project + +## Development Resources + +Web: [getmonero.org](http://getmonero.org) +Mail: [dev@getmonero.org](mailto:dev@getmonero.org) +IRC: [#monero-dev on Freenode](irc://chat.freenode.net/#monero-dev) + +## About this Project + +This is the Monero website. Instead of using MediaWiki or similar, we are using Jekyll and hosting the source on github. All site content is in the easy-to-use Markdown format (Kramdown, specifically), so contributors don't need to have any knowledge of HTML or anything else. + +## Pages, Formats, and Rules + +If you would like to suggest changes you can do so by forking the repository, making changes directly on your fork, and then submitting them as pull requests. If you need help doing so feel free to ask for assistance in #monero-dev on Freenode. + +Pages and formats should be based off existing pages to maintain a consistent look-and-feel. The following notes apply to various parts of the site: + +- changes made to _layouts, _includes, and home.php will need to use {% t x.x %} translation tags to pull in the YAML tag from _strings_en.yml, as this is required for multi-language support later on +- with the exception of something like blog/index.html (that is required to be a .html file for Jekyll's pagination to work) all pages should be .md files +- static content (CSS/JS/images) can be found in the [monero-forum](https://github.com/monero-project/monero-forum) repo +- SVG should be used in header icons and diagrams, and FontAwesome icons can be used in text +- Moneropedia entries require nothing more than creating the .md file in knowledge-base/moneropedia/, please use the 00-base-00 file as a boilerplate +- To create a CLI screen shot, prefix the text block with {:.cli-code}, and use span elements for the colours; see getting-started/running.md, getting-started/accepting.md, and the account.md Moneropedia entry + +## Deployment + +Deploying this website requires Jekyll (3.0+) and the following ruby gems: builder, rubysl-rexml, jekyll-paginate + +Multiple language support will be added soon. + +To test changes locally before pushing to git, make sure you have ruby installed on your system, then: + +1. Make sure you have the necessary ruby gems: `gem install builder rubysl-rexml jekyll-paginate jekyll` +2. Navigate to the your local `monero-site` repository. +3. Serve the website: `jekyll serve` +4. Open a browser and go to [http://127.0.0.1:4000](http://127.0.0.1:4000). +5. A basic page list will appear. Click on the part of the site you are working on (ex: `design_goals`) and see your work! + +## License + +Copyright (c) 2014-2017, The Monero Project + +All rights reserved. + +Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: + +1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. + +2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. + +3. Neither the name of the copyright holder nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. + +THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. diff --git a/_config.yml b/_config.yml new file mode 100644 index 00000000..b0cb1ceb --- /dev/null +++ b/_config.yml @@ -0,0 +1,38 @@ +email: dev@getmonero.org +name: Monero +description: Monero is a digital currency that is secure, private, and untraceable. +keywords: "monero, xmr, bitmonero, cryptocurrency" +baseurl: "" +url: "https://getmonero.org" + +markdown: kramdown + +# Kramdown was using smart quotes, which messes up CLI examples +# TODO: smart quotes are actually quite pretty, so this is perhaps better handled via a plugin that reverts them for CLI blocks +kramdown: + smart_quotes: ["apos", "apos", "quot", "quot"] + input: GFM + +exclude: ["README.md"] +gems: [jekyll-paginate] +paginate: 10 +paginate_path: blog/page:num/ + +# Windows live tiles config +ie_tile_color: eeeeee +ie_tile_small: https://static.getmonero.org/images/live-tiles/small.png +ie_tile_medium: https://static.getmonero.org/images/live-tiles/medium.png +ie_tile_wide: https://static.getmonero.org/images/live-tiles/wide.png +ie_tile_large: https://static.getmonero.org/images/live-tiles/large.png + +# Sitemap +sitemap: + exclude: + - "/ietemplates/ieconfig.xml" + - "/ietemplates/poll1.xml" + - "/ietemplates/poll2.xml" + - "/ietemplates/poll3.xml" + - "/ietemplates/poll4.xml" + - "/ietemplates/poll5.xml" + - "/feed.xml" + - "/404/index.md" \ No newline at end of file diff --git a/_config/nginx.conf b/_config/nginx.conf new file mode 100644 index 00000000..d3452249 --- /dev/null +++ b/_config/nginx.conf @@ -0,0 +1,243 @@ +# This is included as an example of a config file that works for the site. This is important so that anyone can re-host it in the event of something going wrong with the main site. +# The main takeaways from this config file are the redirects, everything is relatively bog standard. + +server { + listen 80; + listen 443 ssl http2; + + ssl_certificate /etc/ssl/certs/ssl-cert-snakeoil.pem; + ssl_certificate_key /etc/ssl/private/ssl-cert-snakeoil.key; + + ssl_protocols TLSv1 TLSv1.1 TLSv1.2; + ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4"; + ssl_prefer_server_ciphers on; + + # Specify this vhost's domain name + server_name updates.getmonero.org downloads.getmonero.org downloads.monero.cc; + root /var/www/downloads.getmonero.org/webroot; + index index.php index.html index.htm; + + # Specify log locations for current site + access_log off; + error_log /var/log/nginx/default-site.log warn; + + # Let's not give away too much info: + error_page 403 = 404; + + # These are the restrictions I generally have on + # Disable logging for favicon + location = /favicon.ico { + log_not_found off; + access_log off; + } + + # Disable logging for robots.txt + location = /robots.txt { + allow all; + log_not_found off; + access_log off; + } + + location ~* \.(ico|css|js|gif|jpe?g|png)$ + { + expires 31536000s; + access_log off; + log_not_found off; + add_header Pragma public; + add_header Cache-Control "max-age=31536000, public"; + } + + # Deny all attempts to access hidden files such as .htaccess, .htpasswd, .DS_Store (Mac). + location ~ /\. { + deny all; + access_log off; + log_not_found off; + } + # End of general restrictions + + # Downloads! + location /win64 { + rewrite ^ /cli/monero-win-x64-v0.10.3.1.zip redirect; + } + + location /win32 { + rewrite ^ /cli/monero-win-x86-v0.10.3.1.zip redirect; + } + + location /mac64 { + rewrite ^ /cli/monero-mac-x64-v0.10.3.1.tar.bz2 redirect; + } + + location /linux64 { + rewrite ^ /cli/monero-linux-x64-v0.10.3.1.tar.bz2 redirect; + } + + location /linux32 { + rewrite ^ /cli/monero-linux-x86-v0.10.3.1.tar.bz2 redirect; + } + + location /linuxarm7 { + rewrite ^ /cli/monero-linux-armv7-v0.10.3.1.tar.bz2 redirect; + } + + location /linuxarm8 { + rewrite ^ /cli/monero-linux-armv8-v0.10.3.1.tar.bz2 redirect; + } + + location /freebsd64 { + rewrite ^ /cli/monero-freebsd-x64-v0.10.3.1.tar.bz2 redirect; + } + + location /dragonflybsd64 { + rewrite ^ /cli/monero-dragonflybsd-x64-v0.10.3.1.tar.bz2 redirect; + } + + # GUI downloads + location /gui/win64 { + rewrite ^ /gui/monero-win-x64-v0.10.3.1.zip redirect; + } + + location /gui/mac64 { + rewrite ^ /gui/monero-mac-x64-v0.10.3.1.tar.bz2 redirect; + } + + location /gui/linux64 { + rewrite ^ /gui/monero-linux-x64-v0.10.3.1.tar.bz2 redirect; + } + + location /gui/linux32 { + rewrite ^ /gui/monero-linux-x86-v0.10.3.1.tar.bz2 redirect; + } + + # Other download redirects + location /cli/win64 { + rewrite ^ /win64 permanent; + } + + location /cli/win32 { + rewrite ^ /win32 permanent; + } + + location /cli/mac64 { + rewrite ^ /mac64 permanent; + } + + location /cli/linux64 { + rewrite ^ /linux64 permanent; + } + + location /cli/linux32 { + rewrite ^ /linux32 permanent; + } + + location /cli/linuxarm7 { + rewrite ^ /linuxarm7 permanent; + } + + location /cli/linuxarm8 { + rewrite ^ /linuxarm8 permanent; + } + + location /cli/freebsd64 { + rewrite ^ /freebsd64 permanent; + } + + location /cli/dragonflybsd64 { + rewrite ^ /dragonflybsd64 permanent; + } + + location /win { + rewrite ^ /win64 permanent; + } + + location /mac { + rewrite ^ /mac64 permanent; + } + + location /linux { + rewrite ^ /linux64 permanent; + } + + location /freebsd { + rewrite ^ /freebsd64 permanent; + } + + location /dragonflybsd { + rewrite ^ /dragonflybsd64 permanent; + } + + location /arm { + rewrite ^ /linuxarm7 permanent; + } + + location /arm64 { + rewrite ^ /linuxarm8 permanent; + } + + location /arm7 { + rewrite ^ /linuxarm7 permanent; + } + + location /arm8 { + rewrite ^ /linuxarm8 permanent; + } + + location /monero.win.x64.latest.zip { + rewrite ^ /win64 permanent; + } + + location /monero.win.x32.latest.zip { + rewrite ^ /win32 permanent; + } + + location /monero.mac.x64.latest.tar.bz2 { + rewrite ^ /mac64 permanent; + } + + location /monero.linux.x64.latest.tar.bz2 { + rewrite ^ /linux64 permanent; + } + + location /monero.linux.x86.latest.tar.bz2 { + rewrite ^ /linux86 permanent; + } + + location /monero.linux.arm7.latest.tar.bz2 { + rewrite ^ /linuxarm7 permanent; + } + + location /monero.linux.arm8.latest.tar.bz2 { + rewrite ^ /linuxarm8 permanent; + } + + location /monero.freebsd.x64.latest.tar.bz2 { + rewrite ^ /freebsd64 permanent; + } + + location /monero.dragonflybsd.x64.latest.tar.bz2 { + rewrite ^ /dragonflybsd64 permanent; + } + + location / { + try_files $uri $uri/ $uri.php $uri.htm $uri.html =404; + index index.html index.htm index.php; + } + + # Block for processing PHP files + # Specifically matches URIs ending in .php + location ~ \.php$ { + try_files $uri =404; + + # Fix for server variables that behave differently under nginx/php-fpm than typically expected + fastcgi_split_path_info ^(.+\.php)(/.+)$; + # Include the standard fastcgi_params file included with nginx + include fastcgi_params; + fastcgi_param PATH_INFO $fastcgi_path_info; + fastcgi_index index.php; + # Override the SCRIPT_FILENAME variable set by fastcgi_params + fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; + # Pass to upstream PHP-FPM; This must match whatever you name your upstream connection + fastcgi_pass phpfpm; + } + +} diff --git a/_data/dogtalk.yml b/_data/dogtalk.yml new file mode 100644 index 00000000..7a1af0c0 --- /dev/null +++ b/_data/dogtalk.yml @@ -0,0 +1,10 @@ +- bubble: "The page went missing? The entire page? Oh noooo!" +- bubble: "
Barooooooooooo!" +- bubble: "
I'm the best tracker out there, I'll find it!" +- bubble: "My kingdom for a dog biscuit!
cookie" +- bubble: "
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?
IS IT TRUE??" +- bubble: "
Have you tried to Google for it?" +- bubble: "I keep day-dreaming...
cat" +- bubble: "
Uh oh...I forgot what I'm looking for!" \ No newline at end of file diff --git a/_data/donators.yml b/_data/donators.yml new file mode 100644 index 00000000..aeb350c5 --- /dev/null +++ b/_data/donators.yml @@ -0,0 +1,428 @@ +- level: 10 + name: ArticMine + amount: 20024.6 + quote: Everyone has the right to freedom of opinion and expression; this right includes freedom to hold opinions without interference and to seek, receive and impart information and ideas through any media and regardless of frontiers. + quote-author: Article 19, The Universal Declaration of Human Rights + history: [10th Dan on 2015-11-11, 9th Dan on 2015-11-11, 8th Dan on 2015-01-14, 7th Dan on 2014-12-02, 6th Dan on 2014-08-24, 5th Dan on 2014-08-01, 4th Dan on 2014-07-21] + +- level: 9 + name: pa + amount: 12500 + history: [8th Dan on 2016-01-01, 9th Dan on 2016-01-01, 7th Dan on 2015-02-25, 6th Dan on 2014-12-30, 5th Dan on 2014-09-18] + +- level: 9 + name: ajiekceu4 + amount: 11666 + history: [9th Dan on 2016-02-03, 8th Dan on 2015-11-4, 7th Dan on 2015-08-31, 6th Dan on 2015-05-11] + +- level: 8 + name: Lloydimiller4 + amount: 7800 + history: [8th Dan on 2015-09-28, 7th Dan on 2015-02-25, 6th Dan on 2015-02-16, 5th Dan on 2014-09-20, 4th Dan on 2014-08-26] + +- level: 8 + name: rpietila + amount: 8100 + quote: We hold these truths to be self-evident, that all men are created equal, that they are endowed by their Creator with certain unalienable Rights, that among these are Life, Liberty and the pursuit of Happiness.--That to secure these rights, Governments are instituted among Men, deriving their just powers from the consent of the governed, --That whenever any Form of Government becomes destructive of these ends, it is the Right of the People to alter or to abolish it, and to institute new Government---it is their right, it is their duty, to throw off such Government. + quote-author: Declaration of Independence + history: [8th Dan on 2015-02-23, 7th Dan on 2014-09-04, 6th Dan on 2014-08-23, 5th Dan on 2014-08-01, 4th Dan on 2014-07-16] + +- level: 7 + name: antw081 + amount: 3100 + history: [7th Dan on 2015-07-16, 6th Dan on 2015-02-23, 5th Dan on 2015-02-10, 4th Dan on 2014-11-25, 3rd Dan on 2014-09-05] + +- level: 7 + name: antw081 + amount: 3100 + history: [7th Dan on 2015-07-16, 6th Dan on 2015-02-23, 5th Dan on 2015-02-10, 4th Dan on 2014-11-25, 3rd Dan on 2014-09-05] + +- level: 7 + name: ajiekceu4 + amount: 7666 + history: [8th Dan on 2015-11-4, 7th Dan on 2015-08-31, 6th Dan on 2015-05-11] + +- level: 7 + name: antw081 + amount: 3100 + history: [7th Dan on 2015-07-16, 6th Dan on 2015-02-23, 5th Dan on 2015-02-10, 4th Dan on 2014-11-25, 3rd Dan on 2014-09-05] + +- level: 7 + name: smooth + amount: 2500 + quote: No State shall...coin Money; emit Bills of Credit; make any Thing but gold and silver Coin a Tender in Payment of Debts... + quote-author: Section 10 + history: [7th Dan on 2014-08-13, 6th Dan on 2014-04-29] + +- level: 6 + name: HardwarePal + amount: 1000 + quote: The right of the people to be secure in their persons, houses, papers, and effects, against unreasonable searches and seizures, shall not be violated, and no Warrants shall issue, but upon probable cause, supported by Oath or affirmation, and particularly describing the place to be searched, and the persons or things to be seized. + quote-author: IV Amendment + history: [6th Dan on 2014-07-17, 5th Dan on 2014-06-30] + +- level: 6 + name: buybitcoinscanada + amount: 1013 + history: [6th Dan on 2014-09-05, 4th Dan on 2014-08-13] + +- level: 6 + name: Medusa13 + amount: 1980.6 + history: [6th Dan on 2015-01-27, 4th Dan on 2014-11-08, 3rd Dan on 2014-08-26] + +- level: 5 + name: bassica + amount: 849.9 + history: [5th Dan on 2015-07-17, 4th Dan on 2015-05-11, 3rd Dan on 2014-11-25, 2nd Dan on 2014-09-10] + +- level: 5 + name: eizh + amount: 500 + history: [5th Dan on 2014-08-09] + +- level: 5 + name: TheKoziTwo + amount: 500 + history: [5th Dan on 2014-09-04] + +- level: 5 + name: ceger + amount: 550 + history: [5th Dan on 2014-09-20] + +- level: 5 + name: binaryFate + amount: 500 + history: [5th Dan on 2015-01-07, 4th Dan on 2014-07-31] + +- level: 5 + name: shitaifan2013/drfred + amount: 500 + history: [5th Dan on 2015-02-04, 4th Dan on 2014-08-18, 3rd Dan on 2014-07-17] + +- level: 6 + name: dnaleor + amount: 1201.1337 + history: [6th Dan 0n 2016-02-03, 5th Dan on 2015-02-23, 4th Dan on 2014-12-17, 3rd Dan on 2014-07-17, 1st Dan on 2014-05-03] + quote: Crypto may offer 'key blinding'. I did some research and it was obscure, but there may be something there. 'Group signatures' may be related. ñ Satoshi Nakamoto, 2010 + +- level: 5 + name: ajiekceu4 + amount: 666 + history: [5th Dan on 2015-2-25] + +- level: 5 + name: saddambitcoin + amount: 1400 + history: [6th Dan on 2016-02-06, 5th Dan on 2015-02-28, 4th Dan on 2014-08-18] + +- level: 5 + name: Quicken + amount: 500 + history: [5th Dan on 2015-03-27] + +- level: 5 + name: G2M (aka "kbm") + amount: 500 + history: [5th Dan on 2015-06-03, 4th Dan on 2014-05-06] + +- level: 4 + name: bobabouey2 + amount: 250 + history: [4th Dan on 2014 -07-21] + +- level: 4 + name: fluffypony + amount: 245 + history: [4th Dan on 2014-08-01] + +- level: 4 + name: exciter0 + amount: 300 + history: [4th Dan on 2014-10-14, 3rd Dan on 2014-08-20] + +- level: 4 + name: Jungian + amount: 201 + history: [4th Dan on 2014-12-17, 3rd Dan on 2014-09-18] + +- level: 4 + name: jehst + amount: 200 + history: [4th Dan on 2015-01-07] + +- level: 4 + name: GreekBitcoin + amount: 300 + history: [4th Dan on 2015-01-26, 3rd Dan on 2014-05-11] + +- level: 4 + name: RaskaRuby + amount: 450 + history: [4th Dan 2015-01-01, 3rd Dan on 2014-10-27, 2nd Dan on 2014-09-18, 1st Dan on 2014-07-27] + +- level: 4 + name: djjacket + amount: 200 + history: [4th Dan on 2015-03-27] + +- level: 4 + name: iourzzz + amount: 311 + history: [4th Dan on 2015-04-08, 3rd Dan on 2015-03-15, 2nd Dan on 2014-09-14, 1st Dan on 2014-08-01] + +- level: 4 + name: nioc + amount: 215 + history: [4th Dan on 2015-11-11, 3rd Dan on 2015-04-18, 2nd Dan on 2015-01-27, 1st Dan on 2014-09-17] + +- level: 4 + name: canth + amount: 300 + history: [4rth Dan on 2105-11-12, 3rd Dan on 2015-05-17] + +- level: 4 + name: iCEBREAKER + amount: 256 + history: [3rd Dan on 2015-11-21] + +- level: 3 + name: Quanttek + amount: 100 + history: [3rd Dan on 2014-07-15] + +- level: 3 + name: darlidada + amount: 125.55 + history: [3rd Dan on 2014-09-04, 2nd Dan on 2014-07-17, 1st Dan on 2014-06-11] + +- level: 3 + name: blaaaaacksuit + amount: 100 + history: [3rd Dan on 2014-08-09] + +- level: 3 + name: AKWAnalytics + amount: 111 + history: [3rd Dan on 2014-09-20] + +- level: 3 + name: Monero House ([CryptoKingdom](https://bitcointalk.org/index.php?topic=819073.msg9156194#msg9156194)) + amount: 150 + history: [3rd Dan on 2014-11-06] + +- level: 3 + name: Shrikez + amount: 150 + history: [3rd Dan on 2015-01-27, 2nd Dan on 2014-09-18, 1st Dan on 2014-07-11] + +- level: 3 + name: explorer + amount: 104 + history: [3rd Dan on 2015-02-05] + +- level: 3 + name: Karl Hungus + amount: 180 + history: [3rd Dan on 2016-01-01] + +- level: 3 + name: palexander + amount: 150 + history: [3rd Dan on 2015-05-13, 2nd Dan on 2015-04-03] + +- level: 2 + name: Warptangent Memorial Fund + amount: 64 + history: [2nd Dan on 2016-07-19] + +- level: 2 + name: superresistant + amount: 50 + history: [2nd Dan on 2014-07-17] + +- level: 2 + name: perl + amount: 50 + history: [2nd Dan on 2014-07-17] + +- level: 2 + name: dbasql + amount: 50 + history: [2nd Dan on 2014-07-17] + +- level: 2 + name: paratox + amount: 50 + history: [2nd Dan on 2014-08-09] + +- level: 2 + name: Arux + amount: 70.1 + history: [2nd Dan on 2015-01-31, 1st Dan on 2014-07-29] + +- level: 2 + name: papa_lazzarou + amount: 50.1 + history: [2nd Dan on 2015-02-23] + +- level: 2 + name: GingerAle + amount: 50 + history: [2nd Dan on 2015-04-22] + +- level: 2 + name: ibuyltc + amount: 50 + history: [2nd Dan on 2015-05-11, 1st Dan on 2014-08-20] + +- level: 2 + name: equipoise + amount: 53 + history: [2nd Dan on 2015-12-11, 1st Dan on 2015-01-24, 1st Kyu on 2014-07-24] + +- level: 1 + name: anonimal + amount: 45.6 + history: [1st Dan on 2016-12-06] + +- level: 1 + name: David Latapie + amount: 20 + history: [1st Dan on 2014-04-29] + +- level: 1 + name: hodlmybtc + amount: 20 + history: [1st Dan on 2014-07-01] + +- level: 1 + name: monoman + amount: 20 + history: [1st Dan on 2014-07-11] + +- level: 1 + name: Jshank + amount: 20 + history: [1st Dan on 2014-07-16] + +- level: 1 + name: dreamspark + amount: 20 + history: [1st Dan on 2014-07-17] + +- level: 1 + name: IntroVert + amount: 20 + history: [1st Dan on 2014-07-17] + +- level: 1 + name: dawie + amount: 20 + history: [1st Dan on 2014-07-17] + +- level: 1 + name: cAPSLOCK + amount: 20 + history: [1st Dan on 2014-07-17] + +- level: 1 + name: statdude + amount: 48.265 + history: [1st Dan on 2014-07-17] + +- level: 1 + name: Roy Badami + amount: 20 + history: [1st Dan on 2014-07-18] + +- level: 1 + name: whap + amount: 20.44 + history: [1st Dan on 2014-09-17] + +- level: 1 + name: SunnyIgor + amount: 26 + history: [1st Dan on 2014-09-18] + +- level: 1 + name: Chicken76 + amount: 20 + history: [1st Dan on 2014-10-10] + +- level: 1 + name: dEBRUYNE + amount: 33.5 + history: [1st Dan on 2015-01-14] + +- level: 1 + name: 5w00p + amount: 20.05 + history: [1st Dan on 2015-01-18, 1st Kyu on 2014-12-06, 2nd Kyu on 2014-09-21] + +- level: 1 + name: matrix961 + amount: 40.015 + history: [1st Dan on 2015-02-09] + +- level: 1 + name: kazuki49 + amount: 20 + history: [1st Dan on 2015-02-28, 1st Kyu on 2015-02-07] + +- level: -1 + name: nakaone + amount: 10 + history: [1st Kyu on 2014-07-15] + +- level: -1 + name: carpetbagger + amount: 10 + history: [1st Kyu on 2014-09-21] + +- level: -2 + name: celestio + amount: 5 + history: [2nd Kyu on 2014-07-16] + +- level: -2 + name: znaky + amount: 5 + history: [2nd Kyu on 2014-07-17] + +- level: -2 + name: Nekomata + amount: 7 + history: [2nd Kyu on 2014-09-20] + +- level: -2 + name: thefunkybits + amount: 5 + history: [2nd Kyu on 2015-02-23] + +- level: -3 + name: jwinterm + amount: 2 + history: [3rd Kyu on 2014-07-18] + +- level: -3 + name: myagui + amount: 2 + history: [3rd Kyu on 2014-07-17] + +- level: -3 + name: yAmAdA + amount: 2 + history: [3rd Kyu on 2014-08-11] + +- level: -4 + name: Evan Duffield (care of iCEBREAKER) + amount: 1 + history: [4th Kyu on 2014-11-20] + +- level: -4 + name: TheDashGuy (care of iCEBREAKER) + amount: 1 + history: [4th Kyu on 2016-08-19] diff --git a/_data/downloads.yml b/_data/downloads.yml new file mode 100644 index 00000000..00448387 --- /dev/null +++ b/_data/downloads.yml @@ -0,0 +1,89 @@ +- platform: Windows, 64-bit + id: windows + icon: icon-windows + cli_url: win64 + cli_hash: 2fbda6f6b1051053703e40cf77b6c6e11334509ad03a3c22d89b6bcb05615910 + gui_url: win64 + gui_hash: 0eddd423f5f0df236303d8b9225842142b331093eb69e6183f3f694238c371a7 + version: 0.10.3.1 + tag: Wolfram Warptangent + blockchain: win + +- platform: Windows, 32-bit + icon: icon-windows + cli_url: win32 + cli_hash: da628a45adfcb8be44df06ac904711d644d608c4eb6479a5d256062a5f6d74de + version: 0.10.3.1 + tag: Wolfram Warptangent + blockchain: win + +- platform: Mac OS X, 64-bit + id: mac + icon: icon-apple + cli_url: mac64 + cli_hash: fd17d55a8c9e901ff4064c39d9e14786cdd077aff9b3bb556e60d3a5e322050c + gui_url: mac64 + gui_hash: c80ca68037158216a080e59e90b0a70761cff2f317d3c9cd0eeb661e8e2a1f99 + version: 0.10.3.1 + tag: Wolfram Warptangent + blockchain: mac + +- platform: Linux, 64-bit + id: linux + icon: icon-linux + cli_url: linux64 + cli_hash: 8db80f8cc4f80d4106db807432828df730a59eac78972ea81652aa6b9bac04ad + gui_url: linux64 + gui_hash: 4915473265d58720fd8f019e536c2b7fb02648ab51a8087e84aa1e2434788452 + version: 0.10.3.1 + tag: Wolfram Warptangent + blockchain: linux + +- platform: Linux, 32-bit + icon: icon-linux + cli_url: linux32 + cli_hash: abc99f3928f4083bd1a380a869253e07bee9950e0aeb6388e9493bc0f0ec3f53 + gui_url: linux32 + gui_hash: 092b49080c3380666845f7f39823b09f4960ea1e250b84b150856ef33ca30690 + version: 0.10.3.1 + tag: Wolfram Warptangent + blockchain: linux + +- platform: ARMv7 + id: arm + icon: icon-arm + cli_url: linuxarm7 + cli_hash: 8473fa20e0db4a3d3e46120cdf92c55be6a159478c511e21f7b77aa05d6c1910 + version: 0.10.3.1 + tag: Wolfram Warptangent + blockchain: arm + +- platform: ARMv8 + icon: icon-arm + cli_url: linuxarm8 + cli_hash: 451f65e4846b92d54859e22a5d92124557b397b4208d8752d5289d0262573c3c + version: 0.10.3.1 + tag: Wolfram Warptangent + blockchain: arm + +- platform: FreeBSD, 64-bit + id: bsd + icon: icon-freebsd + cli_url: freebsd64 + cli_hash: 4c66a76752e18ae70b5fb1c728f0d2780eb129a6c8c7d0dee7ba02e05d91efae + version: 0.10.3.1 + tag: Wolfram Warptangent + blockchain: freebsd + +- platform: Source Code & Blockchain + id: source + icon: icon-github + cli_url: https://github.com/monero-project/bitmonero + cli_hash: source + version: Bleeding edge (possibly unstable) + +- platform: Mobile & Light Wallets + id: mobilelight + +- platform: Hardware Wallets + id: hardware \ No newline at end of file diff --git a/_data/events.yml b/_data/events.yml new file mode 100644 index 00000000..3cb09a44 --- /dev/null +++ b/_data/events.yml @@ -0,0 +1,5 @@ +- event: Monero Meetup (Dublin, Ireland) - June 26th, 2017 + where: J.W. Sweetman Craft Brewery, 1-2 Burgh Quay, Dublin 2, Dublin, Ireland + when: 7:00 PM - Monday, June 26, 2017 + description: The meeting will cover the history of privacy and fungibility in Bitcoin, discuss several approaches to these problems, and explain how Monero achieves its privacy in detail. Justin will discuss the next steps in development going forward and the limitations compared to other coins. Finally, there will be a Q&A session after the meeting, where he can clear up some final thoughts. + link: https://www.meetup.com/Bitcoin-Dublin/events/240152422/ \ No newline at end of file diff --git a/_data/ffs.yml b/_data/ffs.yml new file mode 100644 index 00000000..1f93b972 --- /dev/null +++ b/_data/ffs.yml @@ -0,0 +1,34 @@ +- stage: Ideas + proposals: + - name: Fake. Nothing here yet. Check WiP and Completed Proposals. + url: # + summary: This is for the best ideas ever! + author: rehrar + +- stage: Open Tasks + proposals: + - name: Fake. Nothing here yet. Check WiP and Completed Proposals. + url: # + summary: This is for the best ideas ever! + author: rehrar + +- stage: Funding Required + proposals: + - name: Monero Bounty For HackerOne + url: /forum-funding-system/proposals/monero-bounty-hackerone.html + summary: we need dedicated funds to satisfy bounty for Monero and all Monero sub-projects on hackerone.com/monero + author: anonimal + +- stage: Work in Progress + proposals: + - name: Getmonero.org Redesign + url: /forum-funding-system/proposals/getmonero-redesign.html + summary: Redesign the official getmonero.org website to make it more accessible and aesthetically pleasing. + author: rehrar + +- stage: Completed Proposals + proposals: + - name: What is Monero? is produced and open-sourced + url: /forum-funding-system/proposals/whatismonero-produced.html + summary: Make an introduction video to Monero. + author: savandra \ No newline at end of file diff --git a/_data/merchants.yml b/_data/merchants.yml new file mode 100644 index 00000000..ce3bfe73 --- /dev/null +++ b/_data/merchants.yml @@ -0,0 +1,158 @@ +- category: Exchanges + merchants: + - name: "#monero-otc (OTC)" + url: https://webchat.freenode.net?channels=%23monero-otc + - name: Bitsquare (decentralized) + url: https://bitsquare.io/ + - name: BitMEX + url: https://www.bitmex.com/app/trade/XMR7D + - name: Bittrex + url: https://www.bittrex.com/Market/Index?MarketName=BTC-XMR + - name: Bter + url: https://bter.com/ + - name: CoinCut (OTC) + url: https://www.coincut.com + - name: Cryptopia + url: https://www.cryptopia.co.nz/Exchange?market=XMR_BTC + - name: Livecoin (BTC and USD trading pairs) + url: https://www.livecoin.net + - name: LiteBit (Bankwire/GiroPay/iDeal/SOFORT) + url: https://www.litebit.eu/en/buy/monero + - name: MoneroDirect (Euro only) + url: https://monerodirect.com + - name: Poloniex + url: https://poloniex.com/exchange/btc_xmr + - name: ShapeShift (Instant) + url: https://shapeshift.io/ + - name: Tux Exchange + url: https://www.tuxexchange.com/trade?coin=XMR&market=BTC + - name: Bitfinex (XMRUSD, XMRBTC) + url: https://www.bitfinex.com/ + - name: Alfacashier + url: https://www.alfacashier.com/ + - name: Kraken (XMRUSD, XMREUR, XMRBTC) + url: https://www.kraken.com/ + - name: BIT.AC + url: https://bit.ac/ + - name: Premium investment and exchange services + url: https://www.kaiserex.com/ +- category: Block Explorers + merchants: + - name: ChainRadar + url: http://chainradar.com/xmr/blocks + - name: MoneroBlocks + url: http://moneroblocks.info + - name: MoneroExplorer + url: https://explorer.xmr.my/ + - name: MoneroHash Explorer + url: https://monerohash.com/explorer/ + - name: xmrchain.net + url: https://xmrchain.net/ +- category: Payment Gateways + merchants: + - name: Living Room of Satoshi + url: https://www.livingroomofsatoshi.com/?sc=xmr + - name: Monero Merchants + url: https://monero-merchants.com + - name: Paybee (Private Beta) + url: https://payb.ee/ +- category: Libraries and Helpers + merchants: + - name: monero-nodejs (Node.js) + url: https://github.com/PsychicCat/monero-nodejs + - name: python-monero (Python) + url: https://github.com/tippero/python-monero + - name: MoneroPy (Python) + url: https://github.com/bigreddmachine/MoneroPy + - name: moneronjs (NodeJS) + url: https://github.com/netmonk/moneronjs + - name: MoneroApi.Net (.NET) + url: https://github.com/Jojatekok/MoneroApi.Net + - name: xmr-integration (PHP) + url: https://github.com/TheKoziTwo/xmr-integration + - name: PHP-Monero (PHP) + url: https://github.com/MalMen/PHP-Monero + - name: Monero-PHP (PHP) + url: https://github.com/PsychicCat/monero-php +- category: Tools + merchants: + - name: nestorgames + url: http://www.nestorgames.com + - name: ForkGuard Network Monitoring + url: http://forkguard.com + - name: MoneroBase Price Charts and Tools + url: http://monerobase.com + - name: MoneroPric.es Price Converter + url: https://moneropric.es + - name: MoneroPrice.com Price Converter + url: http://moneroprice.com/ + - name: Offline Monero address generator + url: https://moneroaddress.org/ + - name: Monero Monitor for Chrome + url: https://chrome.google.com/webstore/detail/monero-monitor/ojekadcfnkkihlleaafggfgbggdckpgo +- category: Services + merchants: + - name: Azur Samui - Luxury Apartment and Villa Development, Koh, Samui, Thailand + url: http://www.azursamui.com + - name: California Fintech Network + url: https://www.californiafintech.org/plans/ + - name: Infield Loan Services - Atlanta, Construction Consulting, Contract review, Feasibility, Funds Escrow + url: mailto:info@loandraw.com + - name: Cryptostorm VPN + url: https://cryptostorm.is/ + - name: Esperanto lessons from Kaja + url: mailto:kiah.morante@gmail.com + - name: Farmer ALP, LLC, Arizona + url: mailto:farmeralp@gmail.com + - name: Guitar Music Theory course w/ 30% XMR discount + url: http://www.guitartheoryrevolution.info/blog/guitar-theory-revolution-store/ + - name: MyMonero Web-based Wallet + url: https://mymonero.com + - name: Pradeep Atluri, Psychiatrist, New York + url: http://dr.mindsci.com/ + - name: Simple, no non-sense hosting + url: https://rootbox.host/ + - name: Web Developer - Stefanos + url: http://www.stefanosioannou.com/web-development-monero-accepted + - name: XMR.to Monero to Bitcoin Payment Service + url: https://xmr.to + - name: algoStrategic - Internet Marketing and Web Development + url: https://algostrategic.com + - name: Emmanuel Galang, Canada Immigration and Refugee Lawyer + url: https://galanglaw.com/ + - name: Web Developer - Python with Django web framework + url: http://www.voteforrodneylewis.com + - name: FlokiNET + url: https://flokinet.is + - name: Nerdzy Lawn Care + url: http://http://www.nerdzy.net +- category: Goods + merchants: + - name: CryptoMercado - coffee and snacks + url: https://www.cryptomercado.com/ + - name: Cryptonic Physical Monero & Bitcoin coins + url: https://cryptonic.net + - name: Fine Art from Jeanine King ~ Artwork of Home/Archtecture, Pets, Potraits, Caricatures ~ International Shipping + url: http://art2unlimited.webs.com/ + - name: Digital gift cards + url: https://giftoff.com/ + - name: Mushroom cultures, mushroom growing supplies, seeds + url: https://www.vesp.co/Fungible + - name: Handcrafted goods + url: https://mychain.store/ + - name: Cellphone and laptop repair online store in Sweden + url: http://www.LagaiPhone.se + - name: InvestmentArt + url: http://investmentart.org/ + - name: Directvoltage + url: http://directvoltage.com +- category: Entertainment + merchants: + - name: Crypto Kingdom + url: http://cryptokingdom.me + - name: MoneroDice + url: https://monerodice.net + - name: SafeDice + url: https://safedice.com + - name: Crypto Games + url: https://www.crypto-games.net/ diff --git a/_data/roadmap.yml b/_data/roadmap.yml new file mode 100644 index 00000000..f16d224b --- /dev/null +++ b/_data/roadmap.yml @@ -0,0 +1,79 @@ +- year: 2014 + accomplishments: + - name: Launched on Bitcointalk + date: April 18, 2014 + status: completed + - name: Renamed from Bitmonero to Monero + date: April 23, 2014 + status: completed + - name: Recovered from a spam attack + date: September 4, 2014 + status: completed + - name: Monero Research Lab Papers 1 and 2 published + date: September 12, 2014 + status: completed + - name: Monero Research Lab Paper 3 published + date: September 25, 2014 + status: completed + - name: 0.8.8.6 released + date: December 8, 2014 + status: completed +- year: 2015 + accomplishments: + - name: Monero Research Lab Paper 4 published. + date: January 26, 2015 + status: completed +- year: 2016 + accomplishments: + - name: 0.9.0 Hydrogen Helix published + date: January 1, 2016 + status: completed + - name: Monero Research Lab Paper 5 published + date: February, 2016 + status: completed + - name: Hardfork to impose minimum ringsize 3 on all transactions + date: March, 2016 + status: completed + - name: 0.10.0 Wolfram Warptangent released + date: September 18, 2016 + status: completed + - name: Official GUI Beta 1 released + date: December, 2016 + status: completed +- year: 2017 + accomplishments: + - name: RingCT enabled. Sees quick acceptance. + date: January, 2017 + status: completed + - name: 0.10.2 released; critical vulnerability patched + date: February 22, 2017 + status: completed + - name: Hardfork for dynamic block and dynamic fee improvements + date: April, 2017 + status: completed + - name: Hardfork for increased ringsize and mandatory RingCT + date: September, 2017 + status: upcoming + - name: Fluffy blocks + date: + status: ongoing + - name: 0MQ/ZeroMQ + date: + status: ongoing + - name: GUI out of beta + date: + status: ongoing + - name: Kovri Alpha release + date: + status: ongoing + - name: Website Redesign + date: + status: ongoing +- year: 2018 + accomplishments: + - name: Research papers + date: + status: upcoming + - name: Second layer solutions for speed and scalability + date: + status: upcoming \ No newline at end of file diff --git a/_data/tags.yml b/_data/tags.yml new file mode 100644 index 00000000..d9568957 --- /dev/null +++ b/_data/tags.yml @@ -0,0 +1,77 @@ +- slug: monero missives + name: Monero Missives + +- slug: conferences + name: Conferences + +- slug: exchanges + name: Exchanges + +- slug: gui + name: Monero Core GUI + +- slug: usability + name: Usability + +- slug: dev diaries + name: Dev Diaries + +- slug: mining + name: Mining + +- slug: i2p + name: i2p + +- slug: i8n + name: Internationalisation + +- slug: rpc + name: RPC API + +- slug: docs + name: Documentation + +- slug: branding + name: Branding and Graphics + +- slug: compliance + name: Standards Compliance + +- slug: crypto + name: Cryptography + +- slug: platforms + name: Platform Support + +- slug: core + name: Monero Core + +- slug: accounts + name: Accounts (Wallets) + +- slug: external + name: External Projects + +- slug: mymonero + name: MyMonero.com + +- slug: forkguard + name: ForkGuard.com + +- slug: year in review + name: Year in Review + +- slug: funding + name: Funding and Donations + +- slug: research + name: Monero Research Lab + +- slug: blockchaindb + name: BlockchainDB + +- slug: 0mq + name: ZeroMQ + +- slug: releases + name: Monero Software Releases diff --git a/_data/team.yml b/_data/team.yml new file mode 100644 index 00000000..ae4d0e78 --- /dev/null +++ b/_data/team.yml @@ -0,0 +1,64 @@ +- area: Core + member: + - name: othe + url: + email: othe@getmonero.org + description: + - name: smooth + url: https://github.com/iamsmooth + email: smooth@getmonero.org + description: + - name: Riccardo "fluffypony" Spagni + url: https://github.com/fluffypony + email: ric@getmonero.org + description: + - name: tacotime + url: + email: tacotime@getmonero.org + description: + - name: Francisco "ArticMine" Cabañas + url: https://github.com/ArticMine + email: articmine@getmonero.org + description: + - name: luigi1111 + url: https://github.com/luigi1111 + email: luigi1111@getmonero.org + description: + - name: NoodleDoodle + url: https://github.com/NoodleDoodleNoodleDoodleNoodleDoodleNoo + email: noodledoodle@getmonero.org + description: +- area: Developers + member: + - name: moneromooo + url: https://github.com/moneromooo-monero + - name: hyc + url: https://github.com/hyc + - name: Thomas Winget + url: https://github.com/tewinget + - name: Jaqueeee + url: https://github.com/Jaqueeee + - name: mikezackles + url: https://github.com/mikezackles + - name: Paul Shapiro + url: https://github.com/paulshapiro +- area: Community + member: + - name: dEBRUYNE + url: + - name: SamsungGalaxyPlayer + url: + - name: gingeropolous + url: +- area: Special Thanks + member: + - name: warptangent + url: https://github.com/warptangent + - name: Shen Noether + url: +- area: Monero Research Lab + member: + - name: Brandon Goodell (Surae Noether) + url: + - name: Sarang Noether + url: \ No newline at end of file diff --git a/_includes/dog.html b/_includes/dog.html new file mode 100644 index 00000000..ad1f748a --- /dev/null +++ b/_includes/dog.html @@ -0,0 +1,63 @@ + \ No newline at end of file diff --git a/_includes/download.php b/_includes/download.php new file mode 100644 index 00000000..efaa7f58 --- /dev/null +++ b/_includes/download.php @@ -0,0 +1,77 @@ + +

+ {% t index.monero_for %} + + + {% t index.c_download %} + + +

+ +

+ {% t index.latest_blockchain %} + + + {% t index.c_download %} + + +

\ No newline at end of file diff --git a/_includes/footer.html b/_includes/footer.html new file mode 100644 index 00000000..0ffb92f7 --- /dev/null +++ b/_includes/footer.html @@ -0,0 +1,61 @@ + + + + + + + {% include hostflag.html %} \ No newline at end of file diff --git a/_includes/head.html b/_includes/head.html new file mode 100644 index 00000000..5e3b12e0 --- /dev/null +++ b/_includes/head.html @@ -0,0 +1,29 @@ + + + + + + {% 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 %} + + + + + + + + + + + + + + + + + + + + + + + diff --git a/_includes/header.html b/_includes/header.html new file mode 100644 index 00000000..21457780 --- /dev/null +++ b/_includes/header.html @@ -0,0 +1,162 @@ +
+ + +
+
+
+
+ + +
+ What Is Monero? + Using + Accepting + Contributing + Mining + FAQ +
+
+
+
+
+
+ Downloads +
+
+
+
+
+ + +
+ All Posts + Missives + Meeting Logs + Releases +
+
+
+
+
+ + +
+ Team + Hangouts + Events + Sponsorships + Merchants +
+
+
+
+
+ + +
+ About + Roadmap + Monero Research Lab + Moneropedia + User Guides + Developer Guides +
+
+
+
+
+
+ Forum Funding System +
+
+
+
+
+
+ The Monero Project +
+
+
+
+ +
+
+
+ +
+
+
+
+ +
+
+
\ No newline at end of file diff --git a/_includes/hostflag.html b/_includes/hostflag.html new file mode 100644 index 00000000..649c4268 --- /dev/null +++ b/_includes/hostflag.html @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/_includes/language_cookie.php b/_includes/language_cookie.php new file mode 100644 index 00000000..a7f741b9 --- /dev/null +++ b/_includes/language_cookie.php @@ -0,0 +1,12 @@ + \ No newline at end of file diff --git a/_layouts/base.html b/_layouts/base.html new file mode 100644 index 00000000..da72e2fb --- /dev/null +++ b/_layouts/base.html @@ -0,0 +1,13 @@ + + + + {% include head.html %} + + +
+ {% include header.html %} + {{content}} + {% include footer.html %} +
+ + diff --git a/_layouts/blog_by_tag.html b/_layouts/blog_by_tag.html new file mode 100644 index 00000000..1b357a77 --- /dev/null +++ b/_layouts/blog_by_tag.html @@ -0,0 +1,76 @@ +--- +layout: custom +--- + + {% assign filename = page.path | remove: '.md' | split: '/' | last %} + {% for data_tag in site.data.tags %} + {% if data_tag.slug == filename %} + {% assign tag = data_tag %} + {% endif %} + {% endfor %} + +
+
+
+ +
+
+
+
+

{% t tags.all %}: {{ tag.name }}

+
+
+
+ {% if site.tags[tag.slug] %} + {% for post in site.tags[tag.slug] %} +

{{ post.title }}

+

+ {{ post.summary }} +

+ {% endfor %} + {% else %} +

{% t tags.notags %}

+ {% endif %} +
+
+
+ + + +
+
+
+
+

Recent Posts

+
+ {% for post in site.posts limit:4 %} +
+
+

{{ post.title }}

+
+
+ {% endfor %} +
+
+
+
+

Popular Tags

+
+
+ {% for tag in site.data.tags limit:4 %} +
+
+

{{ tag.name }}

+
+
+ {% endfor %} + + +
+
+
+ +
+
+ +
diff --git a/_layouts/custom.html b/_layouts/custom.html new file mode 100644 index 00000000..e271984a --- /dev/null +++ b/_layouts/custom.html @@ -0,0 +1,7 @@ +--- +layout: default +--- + +
+ {{content}} +
\ No newline at end of file diff --git a/_layouts/default.html b/_layouts/default.html new file mode 100644 index 00000000..94ba7876 --- /dev/null +++ b/_layouts/default.html @@ -0,0 +1,5 @@ +--- +layout: base +--- +

{{page.title}}

+ {{content}} \ No newline at end of file diff --git a/_layouts/defaultnt.html b/_layouts/defaultnt.html new file mode 100644 index 00000000..a3c3b8a1 --- /dev/null +++ b/_layouts/defaultnt.html @@ -0,0 +1,17 @@ +--- +layout: base +--- +
+ +
+
+
+

Title Goes Here

+
+
+ {{content}} +
+
+
+ +
\ No newline at end of file diff --git a/_layouts/error.html b/_layouts/error.html new file mode 100644 index 00000000..6e9eff3c --- /dev/null +++ b/_layouts/error.html @@ -0,0 +1,17 @@ + + + + {% include head.html %} + + + + {% include header.html %} + + {{ content }} + + {% include footer.html %} + {% include dog.html %} + + + + diff --git a/_layouts/ffs-cp.html b/_layouts/ffs-cp.html new file mode 100644 index 00000000..8cc0b5cb --- /dev/null +++ b/_layouts/ffs-cp.html @@ -0,0 +1,30 @@ +--- +layout: base +--- +
+
+ +

Forum Funding System > Completed Proposals > {{page.title}}

+ +
+ +
+
+
+
+

{{page.title}}

+

by {{page.author}}

+
+

This project has been completed. The proposal is kept here both to celebrate the achievements of the Monero community, and for historical accuracy about what was accomplished.

+
+
+
+
+ {{content}} +
+
+
+ +
+ + \ No newline at end of file diff --git a/_layouts/ffs-fr.html b/_layouts/ffs-fr.html new file mode 100644 index 00000000..0d727ac7 --- /dev/null +++ b/_layouts/ffs-fr.html @@ -0,0 +1,48 @@ +--- +layout: base +--- + +
+
+ +

Forum Funding System > Funding Required > {{page.title}}

+ +
+ +
+
+
+
+

How to Contribute

+
+
+
+
+

In order to contribute to the cause of {{page.title}} all you have to do is the following:

+

Have a valid Monero address. If you don't have one, you can read on getting started!

+

Send the amount of XMR that you wish to contribute to the address: {{page.address}}

+

Make sure that you enter a payment ID of {{page.paymentid}} in order for us to be able to assign your contribution to this specific project!

+
+
+
+
+ + + +
+
+
+
+

{{page.title}}

+

by {{page.author}}

+
+
+
+ {{content}} +
+
+
+ +
+ + \ No newline at end of file diff --git a/_layouts/ffs-ideas.html b/_layouts/ffs-ideas.html new file mode 100644 index 00000000..94fe38a4 --- /dev/null +++ b/_layouts/ffs-ideas.html @@ -0,0 +1,27 @@ +--- +layout: base +--- +
+
+ +

Forum Funding System > Ideas > {{page.title}}

+ +
+ +
+
+
+
+

{{page.title}}

+

{{page.author}}

+
+
+
+ {{content}} +
+
+
+ +
+ + \ No newline at end of file diff --git a/_layouts/ffs-ot.html b/_layouts/ffs-ot.html new file mode 100644 index 00000000..3119bb82 --- /dev/null +++ b/_layouts/ffs-ot.html @@ -0,0 +1,28 @@ +--- +layout: base +--- +
+
+ +

Forum Funding System > Open Tasks > {{page.title}}

+ +
+ + +
+
+
+
+

{{page.title}}

+

{{page.author}}

+
+
+
+ {{content}} +
+
+
+ +
+ + \ No newline at end of file diff --git a/_layouts/ffs-wip.html b/_layouts/ffs-wip.html new file mode 100644 index 00000000..f0c6caf9 --- /dev/null +++ b/_layouts/ffs-wip.html @@ -0,0 +1,32 @@ +--- +layout: base +--- +
+ +
+ +

Forum Funding System > Work in Progress > {{page.title}}

+ +
+ + +
+
+
+
+

{{page.title}}

+

by {{page.author}}

+
+

This project has been funded and is being worked on. Keep an eye out here at the bottom of the proposal for updates.

+
+
+
+
+ {{content}} +
+
+
+ +
+ + \ No newline at end of file diff --git a/_layouts/ffs.html b/_layouts/ffs.html new file mode 100644 index 00000000..4b7b36e1 --- /dev/null +++ b/_layouts/ffs.html @@ -0,0 +1,17 @@ +--- +layout: default +--- +
+ +
+
+ Back to Ideas +
+ {{content}} +
+
+
+ +
+ + \ No newline at end of file diff --git a/_layouts/full-text.html b/_layouts/full-text.html new file mode 100644 index 00000000..f12d20c9 --- /dev/null +++ b/_layouts/full-text.html @@ -0,0 +1,14 @@ +--- +layout: default +--- +
+ +
+
+
+ {{content}} +
+
+
+ +
\ No newline at end of file diff --git a/_layouts/full.html b/_layouts/full.html new file mode 100644 index 00000000..3ea155e4 --- /dev/null +++ b/_layouts/full.html @@ -0,0 +1,14 @@ +--- +layout: default +--- +
+ +
+
+
+ {{content}} +
+
+
+ +
\ No newline at end of file diff --git a/_layouts/moneropedia.html b/_layouts/moneropedia.html new file mode 100644 index 00000000..9f5a2f66 --- /dev/null +++ b/_layouts/moneropedia.html @@ -0,0 +1,16 @@ +--- +layout: base +--- +

{{page.title}}

+
+ +
+
+

{{page.entry}}

+
+ {{content}} +
+
+
+ +
\ No newline at end of file diff --git a/_layouts/none.html b/_layouts/none.html new file mode 100644 index 00000000..a399d4e7 --- /dev/null +++ b/_layouts/none.html @@ -0,0 +1,10 @@ + + + + + + {{ content }} + + + + diff --git a/_layouts/post.html b/_layouts/post.html new file mode 100644 index 00000000..56d09299 --- /dev/null +++ b/_layouts/post.html @@ -0,0 +1,78 @@ +--- +layout: base +--- + +{% assign post = page %} +{% if post.tags.size > 0 %} + {% capture tags_content %}Post tags {% if post.tags.size == 1 %}{% else %}{% 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 }}{{ tag.name }}{% if forloop.last == false %}, {% endif %}{% endcapture %} + {% assign tags_content = tags_content_temp %} + {% endif %} + {% endfor %} +{% else %} + {% assign tags_content = '' %} +{% endif %} +
+ +
+
+ +
+
+
+

{{ page.title }}

+

{% t blog.author %}: {% if page.author %}{{page.author}}{% else %}{{site.author}}{% endif%}

+
+
+ {{content}} +
+
+

{{ tags_content }}

+
+
+ + + +
+
+
+
+

Recent Posts

+
+ {% for post in site.posts limit:4 %} +
+
+

{{ post.title }}

+
+
+ {% endfor %} +
+
+
+
+

Popular Tags

+
+
+ {% for tag in site.data.tags limit:4 %} +
+
+

{{ tag.name }}

+
+
+ {% endfor %} + + +
+
+
+ +
+
+
\ No newline at end of file diff --git a/_layouts/proposal.html b/_layouts/proposal.html new file mode 100644 index 00000000..94ba7876 --- /dev/null +++ b/_layouts/proposal.html @@ -0,0 +1,5 @@ +--- +layout: base +--- +

{{page.title}}

+ {{content}} \ No newline at end of file diff --git a/_layouts/root.html b/_layouts/root.html new file mode 100644 index 00000000..582dfba0 --- /dev/null +++ b/_layouts/root.html @@ -0,0 +1,23 @@ +{% include language_cookie.php %} + + + + {% include head.html %} + + + +
+ + {% include header.html %} + +
+ {{ content }} +
+ + {% include footer.html %} + +
+ + + + diff --git a/_layouts/static_page.html b/_layouts/static_page.html new file mode 100644 index 00000000..e224d019 --- /dev/null +++ b/_layouts/static_page.html @@ -0,0 +1,15 @@ +--- +layout: base +--- +

{{page.title}}

+
+ +
+
+
+ {{content}} +
+
+
+ +
\ No newline at end of file diff --git a/_plugins/jekyll-live-tiles.rb b/_plugins/jekyll-live-tiles.rb new file mode 100644 index 00000000..360ead60 --- /dev/null +++ b/_plugins/jekyll-live-tiles.rb @@ -0,0 +1,164 @@ +# Jekyll plugin for generating Windows 8.1 start screen live tiles +# +# Usage: place this file in the _plugins directory and set the required configuration +# attributes in the _config.yml file +# +# Uses the following attributes in _config.yml: +# ie_category: - (optional) poll only a specific category of posts +# ie_frequency: - (optional) the frequency of site polling. Options are {30,60,360,720,1440}. Default is 1440 (1 day) +# ie_tile_color: - (optional) the color of the windows 8 pinned background tile +# ie_tile_small: - location of small tile image (For more information of tile sizes visit http://msdn.microsoft.com/en-us/library/dn455106(v=vs.85).aspx) +# ie_tile_medium - location of medium tile image +# ie_tile_wide - location of wide tile image +# ie_tile_large - location of large tile image + +# +# Author: Matt Sheehan +# 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 \ No newline at end of file diff --git a/_plugins/moneropedia.rb b/_plugins/moneropedia.rb new file mode 100644 index 00000000..6a9e2e22 --- /dev/null +++ b/_plugins/moneropedia.rb @@ -0,0 +1,83 @@ +# Copyright (c) 2014-2015, The Monero Project +# +# All rights reserved. +# +# Redistribution and use in source and binary forms, with or without modification, are +# permitted provided that the following conditions are met: +# +# 1. Redistributions of source code must retain the above copyright notice, this list of +# conditions and the following disclaimer. +# +# 2. Redistributions in binary form must reproduce the above copyright notice, this list +# of conditions and the following disclaimer in the documentation and/or other +# materials provided with the distribution. +# +# 3. Neither the name of the copyright holder nor the names of its contributors may be +# used to endorse or promote products derived from this software without specific +# prior written permission. +# +# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY +# EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF +# MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL +# THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, +# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, +# PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS +# INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, +# STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF +# THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + +module Jekyll + module Converters + class Markdown < Converter + alias base_converter convert + @@moneropedia = Array.new + @@moneropedia_ordered = Hash.new + + def convert(content) + # build up index of Moneropedia summaries + if @@moneropedia.empty? + + # grab all .md files in the Moneropedia folder, ignore index.md + moneropedia_path = File.join(@config["source"], "/resources/moneropedia/*.md") + files = Dir.glob(moneropedia_path).reject{|f| f =~ Regexp.new('index.md', Regexp::EXTENDED | Regexp::IGNORECASE) } + + # step through all the files + files.each do |entry_file| + entry = { } + entry = SafeYAML.load_file(entry_file) + + if !entry.empty? + @@moneropedia.push({ :terms => entry['terms'], :summary => entry['summary'], :file => File.basename(entry_file, ".*") }) + @@moneropedia_ordered = @@moneropedia_ordered.merge({ entry['entry'] => File.basename(entry_file, ".*") }) + end + end + end + + # Jekyll.logger.warn YAML::dump(@@moneropedia_ordered) + if content.include? '@moneropedia' + # Moneropedia index, replace with a list of entries + cur_letter = 'A' + replace = "
\n

A

\n" + @@moneropedia_ordered.sort.map do |entry, link| + if cur_letter != entry[0] + replace += "
\n
\n

" + entry[0] + "

\n" + cur_letter = entry[0] + end + replace += "" + entry + "
\n" + end + replace += "
" + 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, '' + term.gsub('-',' ') + '') + end + end + + base_converter(content) + end + end + end +end \ No newline at end of file diff --git a/_plugins/plugin.rb b/_plugins/plugin.rb new file mode 100644 index 00000000..90191af5 --- /dev/null +++ b/_plugins/plugin.rb @@ -0,0 +1,70 @@ +# Just a placeholder plugin to do translated strings, gives us room and scope to get the +# jekyll-multiple-languages-plugin to work correctly + +module Jekyll + module Translated + module Strings + module Plugin + VERSION = "0.1" + end + end + end +end + +module Jekyll + class LocalizeTag < Liquid::Tag + + def initialize(tag_name, key, tokens) + super + @key = key.strip + end + + def render(context) + if "#{context[@key]}" != "" #Check for page variable + key = "#{context[@key]}" + else + key = @key + end + + site = context.registers[:site] + + stringsfile = File.join(site.source, '_strings_en.yml') + + strings_en = YAML.load_file(stringsfile) + + translation = strings_en.access(key) if key.is_a?(String) + if translation.nil? || translation.empty? + Jekyll.logger.abort_with "Missing key: #{key}" + end + + # If we have an @, pass the string through the markdown converter, so that we hit the Moneropedia plugin + if translation.include? '@' + converter = site.find_converter_instance(::Jekyll::Converters::Markdown) + translation = converter.convert(translation)[3..-6] + end + + translation + end + end + +end + +unless Hash.method_defined? :access + class Hash + def access(path) + ret = self + path.split('.').each do |p| + if p.to_i.to_s == p + ret = ret[p.to_i] + else + ret = ret[p.to_s] || ret[p.to_sym] + end + break unless ret + end + ret + end + end +end + +Liquid::Template.register_tag('t', Jekyll::LocalizeTag) +Liquid::Template.register_tag('translate', Jekyll::LocalizeTag) diff --git a/_plugins/sitemap_generator.rb b/_plugins/sitemap_generator.rb new file mode 100644 index 00000000..f9113427 --- /dev/null +++ b/_plugins/sitemap_generator.rb @@ -0,0 +1,274 @@ +# Sitemap.xml Generator is a Jekyll plugin that generates a sitemap.xml file by +# traversing all of the available posts and pages. +# +# See readme file for documenation +# +# Updated to use config file for settings by Daniel Groves +# Site: http://danielgroves.net +# +# Author: Michael Levin +# Site: http://www.kinnetica.com +# Distributed Under A Creative Commons License +# - http://creativecommons.org/licenses/by/3.0/ +require 'jekyll/document' +require 'rexml/document' + +module Jekyll + + class Jekyll::Document + attr_accessor :name + + def path_to_source + File.join(*[@name].compact) + end + + def location_on_server(my_url) + "#{my_url}#{url}" + end + end + + class Page + attr_accessor :name + + def path_to_source + File.join(*[@dir, @name].compact) + end + + def location_on_server(my_url) + location = "#{my_url}#{url}" + location.gsub(/index.html$/, "") + end + end + + # Recover from strange exception when starting server without --auto + class SitemapFile < StaticFile + def write(dest) + true + end + end + + class SitemapGenerator < Generator + priority :lowest + + # Config defaults + SITEMAP_FILE_NAME = "/sitemap.xml" + EXCLUDE = ["/atom.xml", "/feed.xml", "/feed/index.xml"] + INCLUDE_POSTS = ["/index.html"] + CHANGE_FREQUENCY_NAME = "change_frequency" + PRIORITY_NAME = "priority" + + # Valid values allowed by sitemap.xml spec for change frequencies + VALID_CHANGE_FREQUENCY_VALUES = ["always", "hourly", "daily", "weekly", + "monthly", "yearly", "never"] + + # Goes through pages and posts and generates sitemap.xml file + # + # Returns nothing + def generate(site) + # Configuration + sitemap_config = site.config['sitemap'] || {} + @config = {} + @config['filename'] = sitemap_config['filename'] || SITEMAP_FILE_NAME + @config['change_frequency_name'] = sitemap_config['change_frequency_name'] || CHANGE_FREQUENCY_NAME + @config['priority_name'] = sitemap_config['priority_name'] || PRIORITY_NAME + @config['exclude'] = sitemap_config['exclude'] || EXCLUDE + @config['include_posts'] = sitemap_config['include_posts'] || INCLUDE_POSTS + + sitemap = REXML::Document.new << REXML::XMLDecl.new("1.0", "UTF-8") + + urlset = REXML::Element.new "urlset" + urlset.add_attribute("xmlns", + "http://www.sitemaps.org/schemas/sitemap/0.9") + + @last_modified_post_date = fill_posts(site, urlset) + fill_pages(site, urlset) + + sitemap.add_element(urlset) + + # Create destination directory if it doesn't exist yet. Otherwise, we cannot write our file there. + Dir::mkdir(site.dest) if !File.directory? site.dest + + # File I/O: create sitemap.xml file and write out pretty-printed XML + filename = @config['filename'] + file = File.new(File.join(site.dest, filename), "w") + formatter = REXML::Formatters::Pretty.new(4) + formatter.compact = true + formatter.write(sitemap, file) + file.close + + # Keep the sitemap.xml file from being cleaned by Jekyll + site.static_files << Jekyll::SitemapFile.new(site, site.dest, "/", filename) + end + + # Create url elements for all the posts and find the date of the latest one + # + # Returns last_modified_date of latest post + def fill_posts(site, urlset) + + last_modified_date = nil + site.collections["posts"].docs.each do |post| + if !excluded?(site, post.name) + url = fill_url(site, post) + urlset.add_element(url) + end + + date = File.mtime(post.path) + last_modified_date = date if last_modified_date == nil or date > last_modified_date + end + + last_modified_date + end + + # Create url elements for all the normal pages and find the date of the + # index to use with the pagination pages + # + # Returns last_modified_date of index page + def fill_pages(site, urlset) + site.pages.each do |page| + if !excluded?(site, page.path_to_source) + if File.exists?(page.path) + url = fill_url(site, page) + urlset.add_element(url) + end + end + end + end + + # Fill data of each URL element: location, last modified, + # change frequency (optional), and priority. + # + # Returns url REXML::Element + def fill_url(site, page_or_post) + url = REXML::Element.new "url" + + loc = fill_location(site, page_or_post) + url.add_element(loc) + + lastmod = fill_last_modified(site, page_or_post) + url.add_element(lastmod) if lastmod + + + + if (page_or_post.data[@config['change_frequency_name']]) + change_frequency = + page_or_post.data[@config['change_frequency_name']].downcase + + if (valid_change_frequency?(change_frequency)) + changefreq = REXML::Element.new "changefreq" + changefreq.text = change_frequency + url.add_element(changefreq) + else + puts "ERROR: Invalid Change Frequency In #{page_or_post.name}" + end + end + + if (page_or_post.data[@config['priority_name']]) + priority_value = page_or_post.data[@config['priority_name']] + if valid_priority?(priority_value) + priority = REXML::Element.new "priority" + priority.text = page_or_post.data[@config['priority_name']] + url.add_element(priority) + else + puts "ERROR: Invalid Priority In #{page_or_post.name}" + end + end + + url + end + + # Get URL location of page or post + # + # Returns the location of the page or post + def fill_location(site, page_or_post) + loc = REXML::Element.new "loc" + url = site.config['url'] + site.config['baseurl'] + loc.text = page_or_post.location_on_server(url) + + loc + end + + # Fill lastmod XML element with the last modified date for the page or post. + # + # Returns lastmod REXML::Element or nil + def fill_last_modified(site, page_or_post) + lastmod = REXML::Element.new "lastmod" + date = File.mtime(page_or_post.path) + latest_date = find_latest_date(date, site, page_or_post) + + if @last_modified_post_date == nil + # This is a post + lastmod.text = latest_date.iso8601 + else + # This is a page + if posts_included?(site, page_or_post.path_to_source) + # We want to take into account the last post date + final_date = greater_date(latest_date, @last_modified_post_date) + lastmod.text = final_date.iso8601 + else + lastmod.text = latest_date.iso8601 + end + end + lastmod + end + + # Go through the page/post and any implemented layouts and get the latest + # modified date + # + # Returns formatted output of latest date of page/post and any used layouts + def find_latest_date(latest_date, site, page_or_post) + layouts = site.layouts + layout = layouts[page_or_post.data["layout"]] + while layout + date = File.mtime(layout.path) + + latest_date = date if (date > latest_date) + + layout = layouts[layout.data["layout"]] + end + + latest_date + end + + # Which of the two dates is later + # + # Returns latest of two dates + def greater_date(date1, date2) + if (date1 >= date2) + date1 + else + date2 + end + end + + # Is the page or post listed as something we want to exclude? + # + # Returns boolean + def excluded?(site, name) + @config['exclude'].include? name + end + + def posts_included?(site, name) + @config['include_posts'].include? name + end + + # Is the change frequency value provided valid according to the spec + # + # Returns boolean + def valid_change_frequency?(change_frequency) + VALID_CHANGE_FREQUENCY_VALUES.include? change_frequency + end + + # Is the priority value provided valid according to the spec + # + # Returns boolean + def valid_priority?(priority) + begin + priority_val = Float(priority) + return true if priority_val >= 0.0 and priority_val <= 1.0 + rescue ArgumentError + end + + false + end + end +end \ No newline at end of file diff --git a/_posts/00-base-00 b/_posts/00-base-00 new file mode 100644 index 00000000..96d62340 --- /dev/null +++ b/_posts/00-base-00 @@ -0,0 +1,9 @@ +--- +layout: post +title: Monero Missive for the Week of +summary: +tags: [monero missives, ] +author: Riccardo Spagni (fluffypony) +forum: +--- + diff --git a/_posts/2014-06-02-dev-diary-for-the-week-of-2014-06-02.md b/_posts/2014-06-02-dev-diary-for-the-week-of-2014-06-02.md new file mode 100644 index 00000000..27f5032c --- /dev/null +++ b/_posts/2014-06-02-dev-diary-for-the-week-of-2014-06-02.md @@ -0,0 +1,23 @@ +--- +layout: post +title: Dev Diary for the Week of 2014-06-02 +summary: Block reward penalty adjustment, faster CPU miner, missing RPC calls added +tags: [dev diaries, mining, i2p, rpc, crypto] +author: Riccardo Spagni (fluffypony) +--- + +*June 2nd, 2014* + +**RPC:** Neozaru and others have submitted pull requests to add RPC methods that were missing. + +**I2P:** libssu has been decoupled, and outstanding changes to master have been merged. + +**Core:** just a reminder that there are breaking changes to 0.8.8 to prevent a transaction dust attack on the block reward. Because of the block reward penalty, it was previously possible to constantly reduce the block reward down to nearly zero, which is what has been fixed. You can see this quite dramatically on the [Block Reward chart on monerochain.info](http://monerochain.info/charts/reward) where our average block reward plummeted by around 13% on May 25 - 27 as the fix was tested, deployed, and miners began adopting it. Please don't forget that simplewallet using the older code will not add the correct transaction fees, causing transactions to sit in the mempool for several days before being rejected. + +**Core:** initial work has begun on documenting the code and on providing architecture overviews. This will be a relatively lengthy project, but will provide us with a more useful codebase that has had more eyes on it. + +**Crypto:** we have also begun an initial foray into examining the underlying cryptographic and mathematic principles of the CryptoNote protocol, and ensuring that it has been correctly implemented in the reference code (Bytecoin - upon which Monero is based). We will reveal more details as this project progresses. + +**Crypto:** DGA has done an incredible job of optimising the PoW hashing code, and has vastly improved the speed at which it operates. This makes syncing the blockchain faster, as well as improves the speed at which miners can run and pools can verify work. + +**Mining:** Wolf has worked hard on optimising and tweaking LucasJones miner. If you are mining, it is strongly suggested you give [Wolf's fork of cpuminer-multi](https://github.com/wolf9466/cpuminer-multi) a spin. Because it takes advantage of AES-NI you may find that reducing the number of threads down to around half of the number of cores in your computer is the most efficient. \ No newline at end of file diff --git a/_posts/2014-06-02-monero-missive-for-the-week-of-2014-06-02.md b/_posts/2014-06-02-monero-missive-for-the-week-of-2014-06-02.md new file mode 100644 index 00000000..889f97d3 --- /dev/null +++ b/_posts/2014-06-02-monero-missive-for-the-week-of-2014-06-02.md @@ -0,0 +1,30 @@ +--- +layout: post +title: Monero Missive for the Week of 2014-06-02 +summary: Our first Missive! New logo, pool software completed and bounty awarded, ticker symbol changed to XMR +tags: [monero missives, branding, mining, compliance] +author: Riccardo Spagni (fluffypony) +--- + +*June 2nd, 2014* + +This is the start of a slightly more formal way of keeping everyone updated as to what we're doing in Monero. On an ongoing weekly basis we'll post an update on what has happened over the past week, as well as a dev diary highlighting work done on major efforts. If you'd like to get involved with Monero don't ask for permission - just get stuck in:) Fork the repo, make changes, submit a pull-request, and let's discuss it. + +Also an important note on updates: Our policy is to only provide announcements on projects which are either complete or near completion. We'd like to focus on providing you with the most accurate and reliable news, without generating any type of investor hype or speculation. As Monero is still a project in its infancy, and there is a great deal of work still to be done, we want to make sure you are getting an honest overview of our ongoing progress. + +**Major Updates** + +1. The big one...we have a logo! If you use Monero in any of your projects, [you can grab a branding pack here](http://downloads.getmonero.org/resources/branding.zip). You can also see it in all its glory right here: +![logo](http://downloads.getmonero.org/resources/logo-200.jpg){: .center-image } + +2. With our logo completed, we are going to be moving forward on a major overhaul and redesign of our website. We are also in the process of architecting and designing a better repository of information - which includes a forum-style that allows for both discussion, as well an open-source, crowd-funded development incubator. We will be keeping you updated on our progress in the coming weeks. In the meantime, the best place for threaded discussions are the [/r/monero subreddit](http://www.reddit.com/r/monero), and for live discussions join us on Freenode: #monero for general chat, #monero-dev for development efforts, and #monero-otc for price talk and over-the-counter trades. + +3. The pool bounty has now closed, and was awarded to zone117x and LucasJones for their excellent work on the Node CryptoNote pool. You can see the results of their hard work on [their github repo here](https://github.com/zone117x/node-cryptonote-pool) or, you know, just use pretty much any of the Monero mining pools:) + +4. In order to maintain ISO 4217 compliance, we are changing our ticker symbol from MRO to XMR effective immediately. This change primarily effects exchanges at this early stage, as we are sure that MRO will continue to be used colloquially and in general discussion. We are aware that this may cause a little confusion, but we feel it necessary to make this change early on rather than later when Monero is more widely spread. + +We'd also like to take the time to introduce you to our core team (in no particular order) - tacotime, eizh, smooth, fluffypony, othe, davidlatapie, NoodleDoodle + +Many others are involved in peripheral and related projects, including: zone117x, Neozaru, LucasJones, Wolf, Quanttek, and so many others + +Thank you for your hard work if you have been involved in Monero already, and we look forward to continuing to innovate as keep Monero the most secure, private, untraceable cryptocurrency! \ No newline at end of file diff --git a/_posts/2014-06-10-dev-diary-for-the-week-of-2014-06-10.md b/_posts/2014-06-10-dev-diary-for-the-week-of-2014-06-10.md new file mode 100644 index 00000000..128d5721 --- /dev/null +++ b/_posts/2014-06-10-dev-diary-for-the-week-of-2014-06-10.md @@ -0,0 +1,21 @@ +--- +layout: post +title: Dev Diary for the Week of 2014-06-10 +summary: New RPC calls, GPU miner launched, Doxygen code comments started +tags: [dev diaries, mining, i2p, rpc, docs] +author: Riccardo Spagni (fluffypony) +--- + +*June 10th, 2014* + +**RPC:** incoming_transfers is now available as a simplewallet RPC API call, and payment_id has been added as an optional argument to the transfer RPC API call. Neozaru also committed a large amount of additional functionality to the RPC API, including progress estimation to getinfo. + +**I2P:** no commits this week, much of the work has been around scoping and planning the RPC subsystem. + +**Core:** new seed nodes have been added, so bootstrapping on cold start should work just fine. We are going to add DNS seed node bootstrapping at a later stage. + +**Docs:** work has begun on adding Doxygen comments throughout the code. This will both help us to understand the code written by "The CryptoNote Developers" (who appear at the top of every piece of source code except for the epee library), but will also result in proper developer documentation being made available. + +**Mining:** Wolf` has continued to improve his CPU miner - the latest copy of which can be found on [his github repo](https://github.com/wolf9466/cpuminer-multi). + +**Mining:** Claymore released a CryptoNight GPU miner, which [you can find at this thread](https://bitcointalk.org/index.php?topic=638915.0). Please be advised that his miner is currently closed source, and the appropriate level of caution should be exercised. diff --git a/_posts/2014-06-10-monero-missive-for-the-week-of-2014-06-10.md b/_posts/2014-06-10-monero-missive-for-the-week-of-2014-06-10.md new file mode 100644 index 00000000..8c1eb2d2 --- /dev/null +++ b/_posts/2014-06-10-monero-missive-for-the-week-of-2014-06-10.md @@ -0,0 +1,33 @@ +--- +layout: post +title: Monero Missive for the Week of 2014-06-10 +summary: Deterministic wallets based on mnemonic seeds, fluffypony to attend the Bitcoin Supernode Conference +tags: [monero missives, conferences, exchanges, gui, usability] +author: Riccardo Spagni (fluffypony) +--- + +*June 10th, 2014* + +Hello XMR users! Welcome to our second Monero Missives. + +**Major Updates** + +1. We're happy to introduce a major new feature for Monero: deterministic wallets based on a mnemonic seed! When creating a new wallet you now get a 24 word seed that you can use to restore the wallet: +![mnemonic screenshot](http://i.imgur.com/Qk90Rp2.png){: .center-image } + Usage: This affects simplewallet, and is the default behaviour for --generate-new-wallet. If you would like to disable the deterministic seed during wallet generation, you can pass the --non-deterministic flag. To restore from a seed you can use the --restore-deterministic-wallet flag. + This provides a MAJOR benefit in that backing up your wallet *no longer requires backing up the .bin.keys file*! All you have to do is write down the 24 words and that's the only backup you need. If you're particularly brave you can even memorise the 24 words. You can also use this to create an offline cold wallet or a paper wallet: create a wallet on a computer disconnected from the Internet, write the 24 words and the address and the view key down, and then remove all the files created by the wallet. + Security notes: Please note that this key is independent of your password. By default the 24 word key is written to simplewallet.log when the wallet is created. This is the expected behaviour, the next release will both exclude this from the log and reduce the default log level. Please run --generate-new-wallet with the --set_log 0 flag, or alternatively make sure to delete the simplewallet.log file afterwards. + Technical details: The key length for this remains 256-bits and thus does not compromise user security. The view key seed is generated from a keccak1600 hash of the spend key (which is directly from the mnemonic seed), hence the deterministic nature of this. The non-deterministic method is still available as an option. + How to get it: binaries in the OP have already been updated, or you can compile from the source on github. + Moving to a deterministic wallet: unfortunately it's not possible to retroactively make an existing wallet deterministic. If you want to take advantage of the new feature, you will have to create a new wallet and move your funds in there. + +2. XMR is now on Mintpal for voting. You can find the voting link here: https://www.mintpal.com/voting#XMR - Mintpal allows 1 vote an hour from registered users who have traded before, as well as paid-for votes. + +3. Monero will be officially represented by fluffypony at the Bitcoin Supernode Conference at Malla Castle in Estonia at the end of this month. + +4. Neozaru has made great strides in his RPC-based Qt GUI wallet, and it requires some testing. If you are keen on trying it out, head over [to his comment the GUI thread](https://bitcointalk.org/index.php?topic=589561.msg7240186#msg7240186), give it a spin, and give him feedback. + + +Until next week! + +PS. If you've made it this far, there's a reward in the example wallet listed in the screenshot - first to grab it gets the prize! \ No newline at end of file diff --git a/_posts/2014-06-18-dev-diary-for-the-week-of-2014-06-16.md b/_posts/2014-06-18-dev-diary-for-the-week-of-2014-06-16.md new file mode 100644 index 00000000..038993d7 --- /dev/null +++ b/_posts/2014-06-18-dev-diary-for-the-week-of-2014-06-16.md @@ -0,0 +1,17 @@ +--- +layout: post +title: Dev Diary for the Week of 2014-06-16 +summary: New checkpoint, better mempool handling from BBR, Arch Linux support +tags: [dev diaries, usability, platforms, accounts, core] +author: Riccardo Spagni (fluffypony) +--- + +*June 18th, 2014* + +**Core:** Checkpoint added at block 80 000 + +**Core:** We've incorporated two changes from BBR - proper tx_pool handling, and a fix for the high number of orphans pool miners were experiencing. tx_pool handling is incomplete, as it is implemented by the daemon but the wallet is not, as yet, mempool aware. + +**Core:** Initial tx auto-split commit, ready for testing + +**Build:** Made changes to CMakeLists to allow for the project to build on Arch diff --git a/_posts/2014-06-18-monero-missive-for-the-week-of-2014-06-16.md b/_posts/2014-06-18-monero-missive-for-the-week-of-2014-06-16.md new file mode 100644 index 00000000..8e948e5e --- /dev/null +++ b/_posts/2014-06-18-monero-missive-for-the-week-of-2014-06-16.md @@ -0,0 +1,29 @@ +--- +layout: post +title: Monero Missive for the Week of 2014-06-16 +summary: Monero number 1 on the MintPal voting list, whitepaper annotations released and peer review started, initial transaction splitting test +tags: [monero missives, exchanges, research, usability, gui] +author: Riccardo Spagni (fluffypony) +--- + +*June 18th, 2014* + +Hello, and welcome to our third Monero Missive. + +**Major Updates** + +1. We've been stalling this week's Missive on purpose, because we were hoping it would happen...and it happened! We got to number 1 on the MintPal voting list in a week - which is quite an achievement. There was quite a stack of paid-for votes (more than normal for a cryptocurrency on the MintPal voting list), which is surprising, but it definitely helped catapult us up front. +An [interesting graph on CryptVote](http://cryptvote.com) shows the meteoric climb (XMR is the blue line):   +![](http://i.imgur.com/GfQ67Tz.jpg){: .center-image } + +2. We are immensely grateful for the work the CryptoNote developers have put into the protocol, but their whitepaper is unfortunately lacking in peer reviews. To that end, we have taken it upon ourselves to peer review the whitepaper, and to release the peer review as an annotated whitepaper. +The two primary peer reviewers are not part of the Monero core team, and are highly qualified academics in the fields of mathematics and cryptography. They are assisted by some of the Monero core team who have a similar computer science academic background. Due to the nature of the Monero project both of the primary peer reviewers have chosen to work under a pseudonym. In a later missive we'll introduce them more formally, but for the moment we wanted to release the current copy of the annotated whitepaper for everyone to take a look at. If you'd like to provide your input on the annotations, please feel free to email any comments to dev@getmonero.org +The latest annotated whitepaper can be downloaded here: http://downloads.getmonero.org/whitepaper_annotated.pdf. Please bear in mind that it is only up to page 8 in the CryptoNote whitepaper at present, so the annotation does cut short there:) + +3. We have completed initial work and testing on transaction auto-splitting (thanks to tewinget's tireless work). Now, if you have too many inputs for your transaction, simplewallet will automatically try to split your transfer up to as many as 30 transactions. It will prompt you first and let you know the total fees before just sending it, of course: +![](http://i.imgur.com/IyG3Uq0.jpg){: .center-image } +This feature requires more testing, and is NOT in the main code base yet. If you're able to build Monero, please grab it from fluffypony's repo here, and build and test: https://github.com/fluffypony/bitmonero - you won't need to build tests or change the daemon, it's just simplewallet's operation that has changed. Please do not try this with the RPC API yet, this needs the CLI at the moment. + +4. We have had a lot of people asking about the progress of the GUI wallet. We'd like to reiterate that there are a great number of core and fundamental things that need to be worked on *before* we can get lots and lots of users flocking in. Some of the core necessities that we're working on at breakneck pace are: QoS to reduce the bandwidth demand on full nodes (as everyone will be running a full node at this stage anyway), segregation of wallet functions in order to create a far more robust system for exchanges and merchants to use, [Gitian-based builds](http://gitian.org) for everyone's safety and to ensure binaries are safe (safer, really), moving blockchain storage to an embedded database, fixing the now-infamous "ABSTRACT_SERVER_SEND_QUE_MAX_COUNT" (in big red letters!) error that is quite harmless but everyone freaks out about, and so on. + +   These are issues at Monero's core that we're working on, and we need to have these in place and fixed before a GUI wallet is widely dispersed, otherwise there will be massive resource constraints placed on user's systems. We're not here to win a race against other cryptocurrencies. We're here to to continue to push out great features and stable and reliable code, in a way that will make sure Monero is around for decades and not just a flash-in-the-pan. \ No newline at end of file diff --git a/_posts/2014-07-06-dev-diary-for-the-week-of-2014-06-30.md b/_posts/2014-07-06-dev-diary-for-the-week-of-2014-06-30.md new file mode 100644 index 00000000..2982cbeb --- /dev/null +++ b/_posts/2014-07-06-dev-diary-for-the-week-of-2014-06-30.md @@ -0,0 +1,13 @@ +--- +layout: post +title: Dev Diary for the Week of 2014-06-30 +summary: Daemonize and rpcwallet both ready for testing +tags: [dev diaries, core, accounts] +author: Riccardo Spagni (fluffypony) +--- + +*July 6th, 2014* + +**Core:** daemonizing changes are ready for testing: https://github.com/mikezackles/bitmonero/tree/daemonize + +**Core:** rpcwallet is ready for testing: https://github.com/tewinget/bitmonero/tree/rpcwallet diff --git a/_posts/2014-07-06-monero-missive-for-the-week-of-2014-06-30.md b/_posts/2014-07-06-monero-missive-for-the-week-of-2014-06-30.md new file mode 100644 index 00000000..05f28b9b --- /dev/null +++ b/_posts/2014-07-06-monero-missive-for-the-week-of-2014-06-30.md @@ -0,0 +1,25 @@ +--- +layout: post +title: Monero Missive for the Week of 2014-06-30 +summary: CryptoNote whitepaper review moving to the code, transaction auto-splitting added to master +tags: [monero missives, research, usability, accounts, gui, conferences] +author: Riccardo Spagni (fluffypony) +--- + +*July 6th, 2014* + +Hello, and welcome to our fifth Monero Missive! + +**Major Updates** + +1. fluffypony had a great time discussing Monero at the Bitcoin Supernode Conference in Estonia. Many thanks to rpietila for hosting him and all attendees. + +2. Work on the academic peer review of the CryptoNote whitepaper is slowly starting to move away from an academic platform and on to the code itself, to determine whether the reference implementation correctly implements the whitepaper. Before that happens, though, a summary of the initial findings will be published. We are expecting this to be completed this coming week. + +3. Transaction auto-splitting is now in the main codebase. To explain our methodology: the main github repo will always be "active development", and may contain code that will be reverted or is not fully tested. For those that are brave and want to test and contribute to development, it is the ideal starting point. However, on an ongoing basis we are going to create tagged releases, whereby when a group of new features have been fully tested, a new release can be tagged, and binaries can be put out (along with the code on the github tag, of course). Expect this change to start taking effect within the next 4 weeks. + +4. We'd like to apologise for not finalise the GUI bounty - everyone has been a little scattered this week. We will resolve this in its entirety within the next 48 hours! + +This Missive is a little light on major updates (well, we can't have something major every week;) primarily because there has been lots of plotting and planning this week. As always: you can keep up to date with the nitty-gritty on IRC in #monero-dev on Freenode if you're interested. + +Until next week! \ No newline at end of file diff --git a/_posts/2014-07-13-dev-diary-for-the-week-of-2014-07-07.md b/_posts/2014-07-13-dev-diary-for-the-week-of-2014-07-07.md new file mode 100644 index 00000000..67f80c4a --- /dev/null +++ b/_posts/2014-07-13-dev-diary-for-the-week-of-2014-07-07.md @@ -0,0 +1,17 @@ +--- +layout: post +title: Dev Diary for the Week of 2014-07-07 +summary: Work has begun on moving to an embedded database, good progress on daemonize, moving focus from i2pcpp to i2pd +tags: [dev diaries, core, accounts, i2p, i8n, blockchaindb] +author: Riccardo Spagni (fluffypony) +--- + +*July 13th, 2014* + +**Core**: major work has begun on moving to an embedded database. The ongoing progress on this can be followed here: https://github.com/tewinget/bitmonero/tree/blockchain + +**Core / Wallet**: both the new daemonized daemon and rpcwallet are nearing a stage where they can be merged into master. The final step is to finalise the daemonizing code in rpcwallet, in such a way that it acts the same as the daemon, and we can move from there. + +**I8N**: mnemonic word list German version is in progress and about 90% complete. + +**I2P**: subsequent to discussions with the I2P team, we are going to be making a bit of a diagonal movement from libi2pcpp to i2pd. This should end up with us slightly ahead on the I2P integration project than we would've been. The major focus at the moment is getting TCP streaming (for persistent connections) to work, and that is where the largest focus is at present. diff --git a/_posts/2014-07-13-monero-missive-for-the-week-of-2014-07-07.md b/_posts/2014-07-13-monero-missive-for-the-week-of-2014-07-07.md new file mode 100644 index 00000000..107fefaf --- /dev/null +++ b/_posts/2014-07-13-monero-missive-for-the-week-of-2014-07-07.md @@ -0,0 +1,25 @@ +--- +layout: post +title: Monero Missive for the Week of 2014-07-07 +summary: GUI bounty finalised and paid, a note on donations, mnemonic multilang wordlists started +tags: [monero missives, research, usability, external, funding, i8n] +author: Riccardo Spagni (fluffypony) +--- + +*July 13th, 2014* + +Hello, and welcome to our sixth Monero Missive! + +**Major Updates** + +1. The GUI bounty is completed and all payouts have been made. You can view the [confirmation of payouts in this post](https://bitcointalk.org/index.php?topic=589561.msg7833251#msg7833251), and bounty recipients have confirmed receipt of their bounties. Just to reiterate the comments made by us in that thread: "As it stands right now, we won't be integrating any of these GUI clients into the main codebase just yet, as there is still a great deal of underlying work that must be done before we can ship a GUI wallet that just about anyone can run (unless we want to make the minimum memory requirement 8gb and the minimum Internet connection requirement 20mbps;) That having been said, we will continue to recommend the actively developed GUI wallets to anyone who prefers to use a GUI wallet, and that is the main purpose behind closing and awarding this bounty now: to have a short-list of recommended GUI wallets." The two GUI wallets we recommend using and that are being actively and continuously developed are: +- neozaru's wallet: https://github.com/Neozaru/bitmonero-qt +- Jojatekok's Monero Client .NET: https://github.com/Jojatekok/monero-client / https://bitcointalk.org/index.php?topic=683365.0 + +2. As you may be aware, there's been a great deal of discussion around dev donations. It wasn't something we thought to raise previously, as it is generally accepted that if you are making money from an open-source project (eg. mining, buying and holding for future profit, whatever) you will generally donate as that is the best way to secure an increase in your "investment". It is important to note that this is not a cryptocurrency that has a big, fat premine (or any sort of instamine / ninjamine / premine), and we are, therefore, completely reliant on the donations of our users. We really, truly appreciate all of the donations that we have received, from early pools such as the now-defunct monero.farm contributing a large portion of their earnings, to our largest donation from ceger, to the ramp-up in dev donations from a screed of pools. Thank you, you guys are the ones that are helping us cover costs and pay for contributors where necessary. + +3. The initial work has been completed on analysing the CryptoNote whitepaper, and the review that has come out of it is now available to all. This is an academic approach to analysing it, and is the first step in figuring out whether the principles it espouses are reflected in the Monero code, and (further to that) how we can improve on its deficiencies. You can grab the whitepaper review here: http://monero.cc/downloads/whitepaper_review.pdf + +4. Very early work has begun on reimplementing the mnemonic wordlists in other languages. We are currently doing a German one as a tester to see the amount of effort involved. If you are interested in producing a mnemonic wordlist (1626 words, following a small set of rules) in a language other than German or English please drop us a pm. There will be other translation work coming up (website, tooling etc.), and we will definitely be distributing donations to translators where possible (although they may be relatively small for the work involved). + +Until next week! \ No newline at end of file diff --git a/_posts/2014-12-15-dev-diary-for-the-week-of-2014-12-15.md b/_posts/2014-12-15-dev-diary-for-the-week-of-2014-12-15.md new file mode 100644 index 00000000..225b5518 --- /dev/null +++ b/_posts/2014-12-15-dev-diary-for-the-week-of-2014-12-15.md @@ -0,0 +1,16 @@ +--- +layout: post +title: Dev Diaries for the Week of 2014-12-15 +summary: Restore paths for mnemonics fixed, libunbound lookups moved to its own thread +tags: [dev diaries, core, accounts] +author: Riccardo Spagni (fluffypony) +forum: https://forum.getmonero.org/1/news-and-announcements/115/monday-monero-missives-21-december-15th-2014 +--- + +*December 15th, 2014* + +**Account:** still more fixes to the restore paths and multi-lang mnemonics, known issues with UTF-8 on Windows remain + +**Core:** libunbound lookups moved to a thread in order to trap for failing / slow DNS lookups + +Until next week! \ No newline at end of file diff --git a/_posts/2014-12-15-external-projects-for-the-week-of-2014-12-15.md b/_posts/2014-12-15-external-projects-for-the-week-of-2014-12-15.md new file mode 100644 index 00000000..7850abc7 --- /dev/null +++ b/_posts/2014-12-15-external-projects-for-the-week-of-2014-12-15.md @@ -0,0 +1,16 @@ +--- +layout: post +title: External Projects for the Week of 2014-12-15 +summary: MyMonero side-swiped in a DDoS attack on their data center, i2pd added su3 router update support +tags: [external, mymonero, i2p, forkguard] +author: Riccardo Spagni (fluffypony) +forum: https://forum.getmonero.org/1/news-and-announcements/115/monday-monero-missives-21-december-15th-2014 +--- + +*December 15th, 2014* + +**MyMonero:** due to a very broad DDoS attack at the data center in which MyMonero is hosted (not targeted at MyMonero) the service was offline on Sunday for a 12 hour stretch. We are putting some effort in place to ensure this does not happen again in future. New features added this past week: a "copy to clipboard" helper is now available on the right of your Monero address on your dashboard, as well as on the login key review screen and account details screen. In addition, clicking on a transaction in the dashboard or your transaction history screens will show additional details, such as the payment ID used. + +**ForkGuard:** added MyMonero.com and MoneroClub.com + +**I2PD:** massive progress was made this week adding support for the su3 router update format (the previous .sud / .su2 format being deprecated), which is used to deliver updates to all routers on the i2p network, including: router update alerts, plugin update alerts, reseed data, and news feed items. Details on the su3 format can be found here: https://geti2p.net/en/docs/spec/updates diff --git a/_posts/2014-12-15-monero-missive-for-the-week-of-2014-12-15.md b/_posts/2014-12-15-monero-missive-for-the-week-of-2014-12-15.md new file mode 100644 index 00000000..d6c5da4d --- /dev/null +++ b/_posts/2014-12-15-monero-missive-for-the-week-of-2014-12-15.md @@ -0,0 +1,20 @@ +--- +layout: post +title: Monero Missive for the Week of 2014-12-15 +summary: DNS timeouts causing slow startups fixed, multi-language mnemonic bugs fixed +tags: [monero missives, accounts, core] +author: Riccardo Spagni (fluffypony) +forum: +--- + +*December 15th, 2014* + +Hello, and welcome to our twenty-first Monero Monday Missive! + +**Major Updates** + +1. We're aware of the 0.8.8.6 slow startup issues on some Windows environments (over an hour for the daemon to startup for some people). We believe we've identified the problem, and will be rolling out a test fix in the next couple of days, for inclusion in 0.8.8.7 + +2. There have been a number of patches merged over the past week to fix issues with simplewallet's new multi-language mnemonics + +Until next week! \ No newline at end of file diff --git a/_posts/2015-01-05-monero-missive-2014-year-in-review.md b/_posts/2015-01-05-monero-missive-2014-year-in-review.md new file mode 100644 index 00000000..a092274b --- /dev/null +++ b/_posts/2015-01-05-monero-missive-2014-year-in-review.md @@ -0,0 +1,237 @@ +--- +layout: post +title: Monero Missive Special Edition - 2014 Year in Review +summary: A review of everything Monero accomplished from its inception through to the end of 2014 +tags: [monero missives, year in review, core, funding, accounts, usability, platforms, gui, exchanges, i2p] +author: Riccardo Spagni (fluffypony) +forum: https://forum.getmonero.org/1/news-and-announcements/134/monday-monero-missives-22-year-in-review-january-5th-2015 +--- + +*January 5th, 2015* + +Hello, and welcome to our twenty-second Monero Monday Missive! + +This is our first Missive for 2015, after a 2 week break over the end of December. We'd like to earnestly thank everyone for their support over the course of this year, and for joining us on the start of our Monero journey. We'd also like to take this opportunity to look back on the past 8 months, and see where we got to. + +**State of Monero: 2014** + +As an open-source project, Monero is built on the back of volunteers, contributors, and donations. So let's start with a financial report. + +For donations received over the year: we received 21 636.40655 XMR spread over 4343 transactions, and 8.04559 BTC spread over 25 transactions. Thus our average XMR donation is around 5 XMR, and our average BTC donation is around 0.32 BTC. As most of our costs are BTC based, XMR donations were traded into BTC where necessary (typically through OTC trades and not on-market), giving us a rough total of all receipts of 39.536205689 BTC (in XMR donations) + 8.04559 BTC (in BTC donations) = 47.581795689 BTC. + +Expenditure for the year comprised of 3 totals as some costs could not be settled in BTC or were preferably settled in XMR. Our expenditure was 190.513492 BTC + 1 891.31 XMR + US $5 732.80, which is around the 212 BTC mark. Thus the shortfall of 164.5 BTC was paid out of the Core Team's own pockets in the hopes of recovering the funds later on (ie. just in case anyone was wondering, not only do the core team not get paid at all, but we've put a significant amount of funds into Monero). + +So, what did our ~212 BTC get spent on over the year? Or, in other words, what did we accomplish? Here's a bit of a taste before we dig into the nitty-gritty: + +![Infographic](/blog/assets/2014-year-in-review/overview.jpg) + +*Core Development* + +Well, let's start by excluding a lot of development done in branches on forks, and focusing on the master branch of the git repo. We inherited the Monero project pretty much from the end of April, with [thankful_for_today's last commit on April 30th, 2014](https://github.com/monero-project/bitmonero/commit/e940386f9a8765423ab3dd9e3aabe19a68cba9f9). + +In order to see what we did with some pragmatism we took two folders, one containing the Monero source on April 30th at that last commit, and one containing the Monero source on December 31st. We removed everything in the external/ folder, except the CMakeLists.txt, so that we weren't including external libraries in our count. We then used Araxis Merge to produce a diff report between the two folders (plus Github's compare tool to give us additional information). We then subtracted the license changes we made earlier this year (208 files were affected, which means that for each we have to remove 2 lines from the "removed" count, 1 line from the "changed" count, and 28 lines from the "inserted" count). The summary is below, and whilst it obviously precludes things like where we made several changes to the same line of code, or missteps we reverted, it gives a very general indication of the effort. + +- 35 weeks of development (245 days) since Monero was inherited by the Core Team +- 594 separate commits +- 11 contributors +- 10 221 modified lines +- 12 706 new lines +- 32 lines removed + +Now may be thinking "wow, that's like 94 lines of code a day!", but it's important to remember that included in this are documentation and code comments, mnemonic word lists for several languages, as well as changes made to Bytecoin early on that we merged in. + +However, it doesn't diminish the gargantuan effort that went into the Monero core over the year, and we are truly grateful to all who have been involved. Some of the highlights of work that was committed to the Monero core master repo over the past 8 months, in chronological order, include - + +April: + +- got Monero building and running on OS X + +May: + +- removed purposely obfuscated hashing loop +- added a 'diff' daemon command to show current estimated difficulty and hash rate +- more hashing optimisations, including AES-NI support +- new wallet RPC commands: save_bc, getaddress; new daemon RPC commands: mining_status +- enabled checkpointing and checkpoint verification +- fixed the block reward penalty mechanism and dynamic block sizing +- new wallet RPC commands: incoming_transfers +- fixed exit flags, added --exit-after-cmd simplewallet flag + +June: + +- added payment IDs to simplewallet's 'transfer' RPC command +- added Doxyfile for code documentation +- refactored parts of simplewallet +- added Electrum-style mnemonics to simplewallet +- got Monero building and running on Arch Linux +- further improvements to hashing algorithm, including huge pages and AES-NI key expansion +- added tx auto-splitting and changed transaction creation semantics internally + +July: + +- new wallet RPC command: get_bulk_payments; new daemon RPC command: get_connections +- new README, license changes to BSD 3-clause + +August: + +- optional height parameter for simplewallet refresh +- fixed wallet restore from seed +- new wallet RPC command: query_key; new wallet commands: seed, viewkey +- stopped a major spam attack dead in its tracks +- highly sophisticated attack causes the network to fork for 30 minutes, urgently and immediately patched + +September: + +- blob checkpointing added (over and above normal block hash checkpointing) +- got Monero building and running on FreeBSD +- major documentation of several C classes +- new versioning system to allow for rapid identification of build commit +- started enforcing GPG signed commits and merges, initial GPG keys added +- testnet launched +- dropped support for Visual Studio, added support for mingw-w64 + msys2 +- DNS resolver (libunbound) added, initial OpenAlias support +- dynamic file-based checkpointing added +- multi-language mnemonics introduced for wallets +- new wordlists: Portuguese, and Spanish (first 4 letters unique) +- DNS checkpointing added for rapid checkpoint alert / enforcement + +October: + +- reworked log level choices +- new wordlists: English (first 3 letters unique), as well as Japanese (first 4 letters unique) +- PoW algorithm fully documented +- switched to RapidJSON for JSON parsing +- changed wallet file format (encrypted JSON) +- massive CMake overhaul begun by KitWare, the creators of CMake + +November: + +- per-kb transaction fees introduced +- CMake overhaul completed, dynamic and static builds finally working again on all platforms + +December: + +- bug fixes, bug fixes, and more bug fixes + +*The Monero Research Lab* + +Another major effort has been the Monero Research Lab, the MRL. In addition to the members of the core team, the triplets (Surae / Sarang / Shen Noether, obviously pseudonyms) spent months reviewing the CryptoNote whitepaper, publishing a synopsis of their review, and then building on that by doing extensive Monero research and finally producing several important research bulletins. From the ground-breaking chain reaction attacks in MRL-0001 to the deep dive explanation of Monero Ring Signatures in MRL-0003 (and the accompanying Python implementation) it has been 8 months of remarkable output for a group of people that at best only knew of each other very peripherally. + +The Monero Research Lab members have also engaged regularly with Bitcoin researchers, including a mutually beneficial friendship with Andrew Poelstra who is included in the group of the "MRL Friends". + +Between the whitepaper annotations, the review, and the MRL research bulletins published in 2014, 655 lines of python were released and over 25 000 words were written, all of which was the culmination of over 197 000 words spent in intense academic discussion. + +The academics in the MRL also had an opportunity to meet up with Riccardo Spagni (fluffypony) and Tom Winget (tewinget) towards the end of the year, in a weekend of epic nerdiness that included a trip to a natural history museum and getting stuck on the side of the highway with no petrol due to a faulty gauge. Don't worry, the emergency petrol fill up wasn't paid for by donations;) + +*Infrastructure* + +The Monero web infrastructure consists of 4 key components: web hosting, testing infrastructure, seeding, and download hosting. + +Our web hosting serves the Monero website, the Monero forum, the Monero Research Lab site, and so on. + +Testing infrastructure consists of a Mac Mini hosted at MacStadium, as well as a beefy testing box hosted at Hetzner in Germany, on which we have a number of VMs for the various operating systems and variants we target. Our QA lead contributor, Gazby, who has recently started will be bringing the testing infrastructure up to scratch, and adding things like Jenkins for nightly builds and Gitian for deterministic signed releases. + +Seeding infrastructure consists of several geographically separated boxes that keep the moneroseeds.se/ae.org/ch/li records updated with active seed nodes. + +Download hosting consists of several servers scattered across the globe (3x USA, 2x UK, 1x Germany), and it serves all static content including the blockchain downloads, Monero binaries, MRL publications, and so on. The Monero blockchain alone is downloaded hundreds of times in a month, with our bandwidth usage regularly exceeding 2tb a month across the download nodes. Obviously this provision is not cheap, which is why your continued assistance to this project is greatly appreciated. + +*OpenAlias* + +An important project that the Monero Core Team created and developed is OpenAlias. Monero addresses are ugly, complex, and not really human readable. But then, too, so are Bitcoin addresses. Typically most cryptocurrencies attempt to solve this by having some sort of centralised register, say they've developed "aliasing", and call it a day. For Monero, this approach simply wasn't good enough. + +To understand why it is important one must first understand "[Zooko's Triangle](http://en.wikipedia.org/wiki/Zooko's_triangle)". Zooko Wilcox-O'Hearn, the incredible brain that contributed so much to the Tahoe-LAFS distributed file system (and which was first released May 2nd, 2007), posited that any naming or aliasing system has three goals or desirable traits (and we're just going to quote Wikipedia here) - + +- Human-meaningful: The quality of meaningfulness and memorability to the users of the naming system. Domain names and nicknaming are naming systems that are highly memorable. +- Decentralized: The lack of a centralized authority for determining the meaning of a name. Instead, measures such as a Web of trust are used. +- Secure: The quality that there is one, unique and specific entity to which the name maps. For instance, domain names are unique because there is just one party able to prove that they are the owner of each domain name. + +Zooko initially concluded that it was impossible for a naming system to have all 3, and at best it could hope to have 2 of the 3. Subsequently, systems such as Namecoin and Twister proved that it was, in fact, possible to have all 3. + +Despite that, most of the aliasing / naming implementations that exist today seem to fail on the decentralised aspect (eg. requiring that a block is solved to register an alias centralises it in the hands of the large mining pools, and also limits the number of aliases that can be created a day), and almost always fail on the long-term goal of "human-meaningful". + +We say the latter because a limited aliasing system where globally unique nicknames are chosen invariably devolves to a post-land-grab scenario where so many variants of "bob" have been acquired that a user is forced to chose bob0923840129832 as his alias, which really doesn't solve the naming issue at all. In addition, it forces the cryptocurrency creator to be the one responsible for solving alias disputes, and in many cases aliases are permanent and cannot be changed if you lose your private key. + +OpenAlias is different. Not only does it "square Zooko's triangle" (still a unique and difficult to accomplish task), but it allows for the offloading of decentralisation to Namecoin or GNUnet or similar, whilst still allowing for the offloading of conflict resolution to existing systems such as ICANN's ADR (Alternative Dispute Resolution). Best of all, it leverages the fact that so many people and companies *already own their own domain names*, so there is no need for additional complexity. + +Monero has implemented OpenAlias on quite a basic level, and will be improving its support as time goes on. The OpenAlias project has also not been standing still, and has been working on several sub-projects. + +*GUI and Database* + +With the two attacks we thwarted in 2014, the GUI development had to take a bit of a backseat. On the other hand, the blockchain database implementation has progressed nicely, and is currently being rebased to the latest master and tests are being updated and created for it. + +The GUI code alone already consists of 5 213 lines of QML and over 100 lines of C++, and that is well before anything is wired up. The blockchainDB code consists of over 60 commits on the implementation alone (over and above the tons of commits to create the generic classes and implement all the functionality prior to that), with over 5 500 lines of code already part of it. It truly has been a monumental engineering task. + +*Monero Forum* + +A project guided and directed by the Core Team, although primarily written by a contributor (Eddieh), the forum grew out of an interesting need. On the one hand, Monero is still in its infancy, and the Monero sub-Reddit would likely have sufficed for quite some time. On the other hand, there was a general pressure for us to have our own forum, our own home. + +So why didn't we just use something off-the-shelf? There were several reasons. The primary reason is that most forum software (SimpleMachines, phpBB, Vanilla, etc.) is either too clunky or too old to really be workable in a modern context. And, too, it would be something we would have to live with for a long time (see: Bitcointalk, for instance). Customising existing forum software to suit our needs would not have been cheap (see: Bitcointalk again). Thus a decision was made to see if we could find someone to pursue creating something fresh for us as a peripheral exercise. + +After 6311 lines of PHP, 1226 lines of CSS, and 135 lines of JavaScript, we're proud of what we've produced. Instead of using antiquated content systems like BBCode, we have MarkDown. Instead of pages and pages of threads, we have infinite scrolling and threaded views. Instead of fundamentally flawed trust systems like "default trust" we have a synchronised copy of the Bitcoin-OTC Web of Trust, allowing users with existing WoT accounts to immediately have their trust groups accessible on the Monero Forum for trading. Instead of only meaningless sorting by date (which we have!) we have posts sorted by weight. Since weight is a product both of post age, insightful/irrelevant votes, and your trust relationship to the poster, you are already able to visit a thread and only see comments that are relevant to you, with all other comments collapsed. We are actively massaging more usefulness out of the weighting, but it is core and fundamental to the forum. + +Obviously this is a project that still has a LONG way to go to reach maturity. With that in mind, don't forget that you are key to this: if there's something about the forum you don't like, or a feature you want, or a bug you've found, put it in the Meta section of the forum (until we have a github repo that you can post issues to). + +*The Monero Missives* + +Our first Missive was put out on Monday, June 2nd, 2014, and has been instrumental in collating and bringing together various little snippets and pieces of work and threads every week. In the 30 weeks from that first one till the end of the year we put them on pause for 4 weeks during the attacks in August, and took a 2 week break at the end of the year. The remaining 24 weeks had 21 Missives in them, giving quite a bit of coverage and keeping our userbase as informed as possible. Some Missives are easy and only take us two or three hours to put together. + +Some Missives are substantially harder due to time constraints, dependencies, research (see: this Missive you're reading, for instance;) or just the sheer amount of stuff that is going on. In total, the 21 Missives we put out over the past 8 months contained nearly 16 000 words over 689 sentences! + +And just for fun, this Missive took several days to put together (not all day, every day, mind you) and unsurprisingly ends up being our largest Missive by far, at 3 450 words and 111 sentences! + +*Other Core Team Projects* + +The two other projects the Core Team released in the year are the Monero DNS seeder (xmr-seeder), and URS, a Unique Ring Signature signing tool written in Go. Both of them are active contributions to the Monero infrastructure, and continue to be useful and fundamental on a daily basis. + +**External Projects: 2014** + +The Monero Core team and core contributors obviously aren't the only ones working on Monero-related projects. Some highlights from the year include: + +*[Node CryptoNote Pool](https://github.com/zone117x/node-cryptonote-pool)* + +When Monero first started there was no open-source pool software for it. Through the collective efforts of zone117x and lucasjones, an open-source pool was developed and released. It was an incredible undertaking, given the monstrous lack of documentation and code comments in the CryptoNote source, and we owe them a debt of thanks. + +*[i2pd Development Partnership](https://github.com/PrivacySolutions/i2pd)* + +Initially this started as a partnership with the i2p team, with a view to getting i2pcpp to a workable stage. When i2pcpp stalled, and on advice from the i2p team, we form the Privacy Solutions working group between Monero, AnonCoin, members of the i2p team, and the i2pd developers. + +The focus for the past few months has been on i2pd, which has made amazing progress. Since the launch of the PrivacySolutions partnership at the end of July, a series of 692 commits has brought i2pd up to a stage where it can maintain relatively stable connections to the i2p network. + +*[ForkGuard](http://forkguard.com) and [MoneroClub](https://www.moneroclub.com)* + +Both services launched and operated by Atrides, ForkGuard provides realtime information on the current block height for pools and services that run full Monero nodes, and MoneroClub is a listing of localised Monero and fiat OTC trade offers. Atrides isn't stopping there, and for his next project he's looking to produce a Monero fork of OpenBazaar! + +*[MyMonero](https://mymonero.com)* + +Owned by Riccardo Spagni (fluffypony) and Risto Pietilä (rpietila), and operated by fluffypony, MyMonero is the first web-based client for Monero. In doing so it closes a major end-user usability gap, and goes a long way towards making Monero useful and usable. + +*[Crypto Kingdom](https://bitcointalk.org/index.php?topic=819073.0)* + +Created and started by his lordship, King Risto, Crypto Kingdom is a retro-style virtual world game where players can interact, build, create, and so on. An online playable version is in the works, and as Monero is driving the in-game resources and currency it is well on its way to becoming a fully-fledged microeconomy! + +**Looking Forward: 2015** + +We have a lot in the pipeline for 2015. A few things that we'd like to highlight that you can look forward to: + +- more MRL academic goodness, including some of the work started at our MRL mini-meetup from 2014 +- a finalised, working, tested blockchain DB implementation using LMDB +- i2p integration +- some additional blockchain DB implementations +- finalisation and release of the Monero core GUI +- the release of smart mining functionality +- the finalisation of a complete overhaul of the RPC functionality +- HTTPS and simple auth support for RPC servers +- a new, unified, well-documented RPC interface +- blocknotify and walletnotify equivalents in the daemon and wallet client +- a complete replacement of the wallet/server IPC with 0MQ +- multi-signature transactions +- open-sourcing the Monero Forum software +- the release of some OpenAlias sub-projects + +And, undoubtedly, much more both for Monero core and related external projects. + +Of course, none of this would be possible without donations from our users, and we are most appreciative and grateful to those that have donated thus far. We hope that over the next year you will continue to help and assist us - and don't forget our donation addresses are powered by OpenAlias, both XMR and BTC donation addresses are on donate.getmonero.org + +Thank you for a great 2014, and here's to a great 2015! + +Your Core Team - Riccardo "fluffypony" Spagni, smooth, othe, David Latapie, tacotime, NoodleDoodle, eizh \ No newline at end of file diff --git a/_posts/2015-02-23-monero-missive-for-the-week-of-2015-02-23.md b/_posts/2015-02-23-monero-missive-for-the-week-of-2015-02-23.md new file mode 100644 index 00000000..78ab7d94 --- /dev/null +++ b/_posts/2015-02-23-monero-missive-for-the-week-of-2015-02-23.md @@ -0,0 +1,200 @@ +--- +layout: post +title: Monero Missive for the Week of 2015-02-23 +summary: New website, moved from monero.cc to getmonero.org, MRL-0004 released, Monero design and development goals published +tags: [monero missives, research, usability] +author: Riccardo Spagni (fluffypony) +forum: https://forum.getmonero.org/1/news-and-announcements/161/monday-monero-missives-23-february-23rd-2015 +--- + +We are moving to a new Missive format, it is now in the form of a podcast! + +
+ +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! diff --git a/_posts/2015-03-02-monero-missive-for-the-week-of-2015-03-02.md b/_posts/2015-03-02-monero-missive-for-the-week-of-2015-03-02.md new file mode 100644 index 00000000..57174f77 --- /dev/null +++ b/_posts/2015-03-02-monero-missive-for-the-week-of-2015-03-02.md @@ -0,0 +1,141 @@ +--- +layout: post +title: Dev Diaries for the Week of 2015-03-02 +summary: BlockchainDB progress update, performance considerations, and rationale; RPC->0MQ communication change progress update +tags: [monero missives, dev diaries, core, blockchaindb, rpc, 0mq] +author: Riccardo Spagni (fluffypony) +forum: https://forum.getmonero.org/1/news-announcements-and-editorials/195/monday-monero-missives-24-march-2nd-2015 +--- + +
+ +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 diff --git a/_posts/2015-03-09-monero-missive-for-the-week-of-2015-03-09.md b/_posts/2015-03-09-monero-missive-for-the-week-of-2015-03-09.md new file mode 100644 index 00000000..4ef7d73c --- /dev/null +++ b/_posts/2015-03-09-monero-missive-for-the-week-of-2015-03-09.md @@ -0,0 +1,233 @@ +--- +layout: post +title: External Projects for the Week of 2015-03-09 +summary: MyMonero adds wallet importing, and an interview with the xmr.to team +tags: [monero missives, external, usability, mymonero, accounts] +author: Riccardo Spagni (fluffypony) +forum: https://forum.getmonero.org/1/news-announcements-and-editorials/206/monday-monero-missives-25-march-9th-2015 +--- + +
+ +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. \ No newline at end of file diff --git a/_posts/2015-03-16-monero-missive-for-the-week-of-2015-03-16.md b/_posts/2015-03-16-monero-missive-for-the-week-of-2015-03-16.md new file mode 100644 index 00000000..6e5cd5fb --- /dev/null +++ b/_posts/2015-03-16-monero-missive-for-the-week-of-2015-03-16.md @@ -0,0 +1,26 @@ +--- +layout: post +title: Monero Missive for the Week of 2015-03-16 +summary: Initial DB merge is about a week away, Tippero available on IRC / Twitter / Reddit, English mnemonic bug +tags: [monero missives, accounts, blockchaindb, external] +author: Riccardo Spagni (fluffypony) +forum: https://forum.getmonero.org/1/news-announcements-and-editorials/225/monday-monero-missives-26-march-16th-2015 +--- + +
+ +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! \ No newline at end of file diff --git a/_posts/2015-03-23-monero-missive-for-the-week-of-2015-03-23.md b/_posts/2015-03-23-monero-missive-for-the-week-of-2015-03-23.md new file mode 100644 index 00000000..8469ebe7 --- /dev/null +++ b/_posts/2015-03-23-monero-missive-for-the-week-of-2015-03-23.md @@ -0,0 +1,24 @@ +--- +layout: post +title: Dev Diaries for the Week of 2015-03-23 +summary: Detail on the structure of the new blockchain conversion and import utilities +tags: [monero missives, dev diaries, blockchaindb, core] +author: Riccardo Spagni (fluffypony) +forum: https://forum.getmonero.org/1/news-announcements-and-editorials/245/monday-monero-missives-27-march-23rd-2015 +--- + +
+ +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! \ No newline at end of file diff --git a/_posts/2015-03-30-monero-missive-for-the-week-of-2015-03-30.md b/_posts/2015-03-30-monero-missive-for-the-week-of-2015-03-30.md new file mode 100644 index 00000000..68c5801e --- /dev/null +++ b/_posts/2015-03-30-monero-missive-for-the-week-of-2015-03-30.md @@ -0,0 +1,18 @@ +--- +layout: post +title: External Projects for the Week of 2015-03-30 +summary: An interview with Jojatekok, creator of the MoneroX GUI +tags: [monero missives, external, gui, usability] +author: Riccardo Spagni (fluffypony) +forum: https://forum.getmonero.org/1/news-announcements-and-editorials/252/monday-monero-missives-28-march-30th-2015 +--- + +
+ +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! \ No newline at end of file diff --git a/_posts/2015-06-29-monero-missive-for-the-week-of-2015-06-29.md b/_posts/2015-06-29-monero-missive-for-the-week-of-2015-06-29.md new file mode 100644 index 00000000..076916cf --- /dev/null +++ b/_posts/2015-06-29-monero-missive-for-the-week-of-2015-06-29.md @@ -0,0 +1,344 @@ +--- +layout: post +title: Monero Missives for the Week of 2015-06-29 +summary: A warm welcome back, and a report from Riccardo's trip to Europe +tags: [monero missives, conferences] +author: Riccardo Spagni (fluffypony) +forum: https://forum.getmonero.org/1/news-announcements-and-editorials/319/monday-monero-missives-30-june-29th-2015 +--- + +
+ +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! diff --git a/_posts/2015-08-31-monero-missive-for-the-week-of-2015-08-31.md b/_posts/2015-08-31-monero-missive-for-the-week-of-2015-08-31.md new file mode 100644 index 00000000..56cf11e6 --- /dev/null +++ b/_posts/2015-08-31-monero-missive-for-the-week-of-2015-08-31.md @@ -0,0 +1,130 @@ +--- +layout: post +title: Monero Missives for the Week of 2015-08-31 +summary: Contributing to, and building, the Monero website +tags: [monero missives, usability] +author: Riccardo Spagni (fluffypony) +forum: https://forum.getmonero.org/1/news-announcements-and-editorials/2368/monday-monero-missives-31-august-31st-2015 +--- + +
+ +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 diff --git a/_posts/2015-09-14-monero-missive-for-the-week-of-2015-09-14.md b/_posts/2015-09-14-monero-missive-for-the-week-of-2015-09-14.md new file mode 100644 index 00000000..99edd495 --- /dev/null +++ b/_posts/2015-09-14-monero-missive-for-the-week-of-2015-09-14.md @@ -0,0 +1,434 @@ +--- +layout: post +title: Monero Missives for the Week of 2015-09-14 +summary: An interview with the creators of MoneroDice, a new Monero gaming site +tags: [monero missives, external] +author: Riccardo Spagni (fluffypony) +forum: https://forum.getmonero.org/1/news-announcements-and-editorials/2378/monday-monero-missives-32-september-14th-2015 +--- + +
+ +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 diff --git a/_posts/2015-12-26-monero-missive-for-the-week-of-2015-12-26 copy.md b/_posts/2015-12-26-monero-missive-for-the-week-of-2015-12-26 copy.md new file mode 100644 index 00000000..e8d8a522 --- /dev/null +++ b/_posts/2015-12-26-monero-missive-for-the-week-of-2015-12-26 copy.md @@ -0,0 +1,17 @@ +--- +layout: post +title: Monero Missives for the Week of 2015-12-26 +summary: An interview with psi, from the I2P project, and an announcement of the Monero Kovri project +tags: [monero missives, kovri] +author: Riccardo Spagni (fluffypony) +--- + +
+ +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?) \ No newline at end of file diff --git a/_posts/2016-01-01-monero-0.9.0-hydrogen-helix-released.md b/_posts/2016-01-01-monero-0.9.0-hydrogen-helix-released.md new file mode 100644 index 00000000..068f3bc1 --- /dev/null +++ b/_posts/2016-01-01-monero-0.9.0-hydrogen-helix-released.md @@ -0,0 +1,69 @@ +--- +layout: post +title: Monero 0.9.0 "Hydrogen Helix" Released +summary: A major release in Monero's history, too much to summarise! +tags: [releases] +author: Riccardo Spagni (fluffypony) +--- + +*January 1st, 2016* + +## Summary of Changes + +Too much to describe. Represents a major release in Monero's history, over a year-and-a-half in the making. Some highlights: + +- moved from in-RAM database to a backend-agnostic blockchain database +- created an LMDB blockchainDB implementation (with the help of Howard Chu, the creator of LMDB) +- created a BerkeleyDB blockchainDB implementation +- created an OS-agnostic raw blockchain format +- built tools to convert between blockchain implementations, as well as import and export them +- added ARM support +- brought back 32-bit support (WIP) +- added QoS (bandwidth control) +- added [OpenAlias](https://openalias.org) support +- fixed all (previously broken) unit tests and core tests +- implemented daemonize for proper backgrounding of the Monero daemon +- drastically increased sync speed +- included block headers in the source +- designed and implemented a stealth payment ID scheme +- designed and implemented a unified address+payment ID scheme +- implemented a hard fork mechanism +- changed the block time to 2 minutes +- implemented the [MRL-0001](https://lab.getmonero.org/pubs/MRL-0001.pdf) and [MRL-0004](https://lab.getmonero.org/pubs/MRL-0004.pdf) recommendations +- added tons of simplewallet / rpcwallet / daemon commands +- added a dust handler to simplewallet +- created a multilanguage mechanism, implemented in simplewallet +- bug fixes, bug fixes, bug fixes +- completely overhauled the CMake (with the help of Kitware, the creators of CMake) +- added a bad peer auto-banning mechanism +- refactored a ton of code, added a ton of comments +- added a core crypto implementation based on SUPERCOP ref10 +- switched to a triangular distribution for output selection +- added multiple new mnemonic wordlists, including Russian and Italian +- created a "trusted daemon" system for remote daemon use + +In total this represents 922 commits worth of work by 9 contributors. This will probably be the biggest release in Monero's history, everything from here on out can be done as faster point releases. + +## Updating: Blockchain Conversion + +It is highly recommended that you delete the contents of your Monero working directory and sync from scratch. This directory can be found in ```~/.bitmonero``` on Linux and OS X, and on Windows in ```\Users\username\AppData\Roaming\bitmonero``` or ```\ProgramData\bitmonero```. + +Syncing from scratch is EXTREMELY fast in this version, pretty much at bittorrent speeds, and will leave you with a fully verified blockchain. + +*Alternatively*: if you want to grab the bootstrap (NOTE: there is a new bootstrap format!) off the website then you can get it at https://downloads.getmonero.org/blockchain.raw - once downloaded you can import it with ```blockchain_import --input-file /path/to/your/download.raw```. If you're particularly brave you can pass the ```--verify 0``` flag to skip verification during import. + +*If you REALLY want to convert your old blockchain*: you can either use the ```blockchain_converter``` tool, or you can use ```blockchain_export``` to create a blockchain.raw, followed by ```blockchain_import``` to import it into the new LMDB format. + +## Official Download Links + +- [Windows, 64-bit](https://downloads.getmonero.org/monero.win.x64.v0-9-0-0.zip) +- [OS X, 64-bit](https://downloads.getmonero.org/monero.mac.x64.v0-9-0-0.tar.bz2) +- [Linux, 64-bit](https://downloads.getmonero.org/monero.linux.x64.v0-9-0-0.tar.bz2) + +## Download Hashes + +If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes: + +- monero.win.x64.v0-9-0-0.zip, c61284c4d5f78db2bc2072bef76f2b539293cca74bdd3fb9536a35ca54b4fd2e +- monero.linux.x64.v0-9-0-0.tar.bz2, 655875a899aded6d63f99c5dfea6a45b3e77533bb2173e63612646ec7ac97100 +- monero.mac.x64.v0-9-0-0.tar.bz2, fce5140d9cb38d62ad1b9f1b0d06feaa209433f9ec542b8d368ef9e0da431b78 diff --git a/_posts/2016-01-15-monero-0.9.1-released.md b/_posts/2016-01-15-monero-0.9.1-released.md new file mode 100644 index 00000000..e64e7ba5 --- /dev/null +++ b/_posts/2016-01-15-monero-0.9.1-released.md @@ -0,0 +1,37 @@ +--- +layout: post +title: Monero 0.9.1 Released +summary: A point release of Monero Hydrogen Helix to prevent a repeat of the block 913193 attack +tags: [releases] +author: Riccardo Spagni (fluffypony) +--- + +*January 15th, 2016* + +## Summary of Changes + +This has urgent and important bug fixes to 0.9.0 *Hydrogen Helix* + +- Bug fix for the block 913193 attack, plus checkpoints +- Restored CMake 2.9 support +- Added --password-file option to simplewallet +- Various fixes for building on ARM +- Fixed importing with verify off + +## Official Download Links + +- [Windows, 64-bit](https://downloads.getmonero.org/monero.win.x64.v0-9-1-0.zip) +- [Windows, 32-bit](https://downloads.getmonero.org/monero.win.x86.v0-9-1-0.zip) +- [OS X, 64-bit](https://downloads.getmonero.org/monero.mac.x64.v0-9-1-0.tar.bz2) +- [Linux, 64-bit](https://downloads.getmonero.org/monero.linux.x64.v0-9-1-0.tar.bz2) +- [Linux, 32-bit](https://downloads.getmonero.org/monero.linux.x86.v0-9-1-0.tar.bz2) + +## Download Hashes + +If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes: + +- monero.win.x64.v0-9-1-0.zip, 1e2650d598dd995a40591596bde75cbad7af0b42d9dadedd0b70b9a2f49bc0e8 +- monero.win.x86.v0-9-1-0.zip, 425b1c1c52dbaeeb277a25463668e1adc6699980490e5632ae0c07d36035a8ea +- monero.mac.x64.v0-9-1-0.tar.bz2, dfd2740939a8eeed0e044232b2654d9255ca894ee5d6022c1258b6268e63185f +- monero.linux.x64.v0-9-1-0.tar.bz2, 4aa6a890e49f7813e7999530415a0f7440c5b446991363f99469794d524efdad +- monero.linux.x86.v0-9-1-0.tar.bz2, d41e16bf7a9adc40201d79f89de70b7fe97f05ad82895fc3b6ed2b1192203a1d diff --git a/_posts/2016-01-31-overview-and-logs-for-the-dev-meeting-held-on-2016-01-31.md b/_posts/2016-01-31-overview-and-logs-for-the-dev-meeting-held-on-2016-01-31.md new file mode 100644 index 00000000..f677018c --- /dev/null +++ b/_posts/2016-01-31-overview-and-logs-for-the-dev-meeting-held-on-2016-01-31.md @@ -0,0 +1,359 @@ +--- +layout: post +title: Overview and Logs for the Dev Meeting Held on 2016-01-31 +summary: Dev branch, style guide, Collective Code Construction Contract +tags: [dev diaries, core, crypto] +author: gingeropolous +--- + +*January 31st, 2016* + +# Summary + +## Use of dev branch + +First thing discussed is the dev branch. Contributors have fell back into the habbit of merging stuff to master. All hacking should be done onto dev branch. + +Apparently this is because of bugs. A new point release to fix the v1/v2 stuck transaction bugs is coming. + +The thing holding up general move to development branch is that CZMQ/0MQ hasn't been bundled in source, so its a pain to compile. Everyone agrees to bundle CZMQ/0MQ into dev branch. fluffypony will get it in the source tree. + +There is more talk about minor tweaks that should or shouldn't go into the upcoming point release. + +## Style guide + +In Kovri they've been working with [a style guide](https://github.com/monero-project/kovri/blob/master/CONTRIBUTING.md#style), and fluffypony suggests implementing one in Monero. Basically, this is the way the code is formatted (human formatted). + +Its agreed to use the new style with new code, and restyle-as-you-go with old code. Restyling for the sake of restyling is though to be unnecessary. Key points: + +> we assume from this point on the code is indented like the majority of the code so far - 2 spaces, not tabs, not 4 spaces. + +> push harder on "code should go in a .cpp not .h" + +## Collective Code Construction Contract (C4) + +As used in 0MQ as [described here](http://rfc.zeromq.org/spec:22) + +The idea is to merge every PR as long as it doesn't break the build. Aim is to avoid PR-hell where everyone comments on a PR for days and weeks and it never gets merged, because its never "perfect." Merge-everything is done so that contributors establish a history, and they can be banned if they are repeat offenders. + +In general, the idea is agreed upon. However, there is concern and uncertaintly regarding the roles of the various branches and how the contract applies to which branches. The conversation bleeds into ringCT implementation and timeframe and how the c4 would affect this process. The fact that 0MQ-dev branch is currently unusable is brought up regarding how the c4 would function. It is noted that 0MQ was pushed to dev because the original contributor couldn't continue working on it. Ultimately the 0MQ situation will not happen again. + +Ultimately, this issue will be brought up at the next meeting. + +## Keep hacking around things or dump stuff for things that are easier + +This is a lot of meta-code stuff. The thing that was salient to me was the doxygen-compatible approach, which would allow newcomers to the code to become acquainted more efficiently. + +## Thanks! + +fluffypony extends his gratitude to all contributors, and everyone makes their way to the reception hall for bacon wrapped shrimp, pigs in blankets, and all other sorts of tiny foods that hover on discs. + +# Logs + +**\** who are we missing +**\** tewinget / othe / warptangent / NoodleDoodle you guys around? +**\** ^ +**\** hokay +**\** smooth? +**\** smooth and luigi1111w are around +**\** although luigi1111w is using some other nick +**\** luigi1112 I think +**\** 4 +**\** mario1114 +**\** lol +**\** about a year ago we did this using TeamSpeak +**\** I mean Mumble +**\** for you guys +**\** which was nice, but it isn't as fluid as typing because sometimes you can't hear that someone else is talking +**\** Firechat? Was cool +**\** binaryFate: no we did a couple of actual dev meetings +**\** but it's tough to sustain +**\** Oh ok +**\** I think typing is fine too. +**\** This is fine +**\** agreed +**\** plus there are people working on Monero that would prefer not to have to use a voice changer just to participate :-P +**\** ok so there are a few things on the agenda +**\** I'm sick so my voice is already changed +**\** the format seems to have been working well for kovri too +**\** the first thing I think we should discuss is the dev branch +**\** we've fallen back into the habit of merging stuff to master +**\** That's because bugs +**\** I know +**\** we're going to have to do a point release to fix the v1/v2 / stuck transactions bugs +**\** are there any bug fixes waiting in the wings, or should we do that next week? +**\** That last commit thing, which I'll have to think about a bit more. +**\** Also, possibly merging the per-tx bits in lmdb. +**\** which? +**\** tx_{unlocks,heights,outputs} +**\** ah +**\** And output_{keys,amounts,indices,txs} +**\** DB format change, I don't think that's a bug-fix +**\** Way more of htose than blocks +**\** maybe we need to consider a more generalised approach to format changes +**\** something like Laravel's migrations +**\** it'll have to be per-DB-format anyway +**\** per-DB-type I mean +**\** i've got schema changes i've been using for a couple months, for better use on hdd, but they aren't bug fixes. +**\** two sets of bug fixes not yet added though +**\** ok if they're not considered crucial for 0.9.x then we can put them into dev? +**\** warptangent: since I've been working on the same thing, I guess I should take a look at your stuff +**\** 1. berkeleydb support for importer - almost ready, some argument usage cleanup +**\** Once I re-merged then +**\** but I don't consider anything I'm looking at now as bug-fix +**\** (this is how we meeting http://i.imgur.com/OR5ZVoI.jpg) +**\** 2. finish hf fix for importer - mostly done, pending some cleanup with bdb +**\** hokay +**\** (I have a wineglass here too, sadly empty) +**\** hyc: yes, that would be good. i think i mentioned the tx changes last month to avoid as many subdbs with tx hash keys +**\** 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 +**\** any objections to the bundling? +**\** how much of a pain is it to change formats? +**\** I haven't even looked at dev. no objection from me +**\** luigi1111w: mostly just requires copying data to a new table and nuking the old one +**\** Hmm. I have a few patches to czmq, to make things build. +**\** Not super sure whether it was me being dumb or not though. +**\** ok well moneromooo, maybe post-bugfix do you want to do the merge from master to dev, and then plonk those patches on? +**\** I'll get it in the source tree the meantime, and cmake-ify all of the things +**\** 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. +**\** Great, ty +**\** great minds think alike +**\** ok next I'd like us to chat about a style guide +**\** we've been working on one in Kovri that we can possibly use for Monero +**\** https://github.com/monero-project/kovri/blob/master/CONTRIBUTING.md#style +**\** 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 +**\** 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 +**\** i have no objection to any reasonable style guide but i do object to re-styling of existing code +**\** Pages and pages of stuff ? :| +**\** I object too, if it's only restyling for the sake of it. +**\** ok so more of a restyle-as-you-go +**\** That massive reindent patch already caused me grief +**\** which is in line with our refactor-as-you-go approach +**\** Apply the style guide to new code +**\** imo the best policy is keep the style on small chages to existing code and new style on new code +**\** there is probably a gray area there +**\** 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. +**\** agreed +**\** warptangent: that's the one area where we differ from Kovri, I'd lean towards yes +**\** 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. +**\** moneromooo: style on the current project though, not different styles per file, right? +**\** Whatever code I'm modifying. +**\** It causes the least problems. +**\** 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 +**\** the majority of files are one style in the codebase, with a few that became some kind of hybrid at one point +**\** Oh OK. +**\** With that out of the way... +**\** 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 +**\** yes, seems good +**\** I would push harder on "code should go in a .cpp not .h" +**\** hyc: agreed +**\** I'll make it clearer +**\** moneromooo: did you want to raise a point, or were you saying we can move on? +**\** overall it looks sane to me +**\** I'm good. +**\** ok +**\** next point is also administrative in nature +**\** we'd like to adopt the Collective Code Construction Contract that 0MQ uses, as a guide for project administrators and for contributors +**\** http://rfc.zeromq.org/spec:22 +**\** we can discuss it more in future, but the long and the short of it +**\** is that we merge every PR as long as it doesn't break the build +**\** if it does something bad / dangerous we can have a follow up PR to revert +**\** but the aim is to avoid PR-hell where everyone comments on a PR for days and weeks and it never gets merged +**\** because it's never "perfect" +**\** so merge, create issues on Github where something is lacking (eg. new feature, little or no tests - create issues for tests) +**\** This PR-hell problem's never happened, has it ? +**\** moneromooo: not in Monero yet, but Bitcoin is chock-full of it +**\** ^ this is for dev branch, right? +**\** I think common sense is again a better thing than going the opposite extreme. +**\** gingeropolous: this is in general +**\** i haven't read the zeromq document thoroughly, but does it leave room for the common sense aspect? +**\** moneromooo: the problem is that there are lots of nuanced situations where "common sense" isn't that common :-P +**\** 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 +**\** Well, if it's nuanced, fine. +**\** warptangent: it does, yes +**\** as explained by Pieter to binaryFate and I last year +**\** if the concept of only taggest releases on master is no adopted then i would oppose going even further in the other direction +**\** *tagged +**\** smooth: yes that's a given +**\** master represents a stable, tagged release +**\** we work in dev +**\** anyone that submits a PR to master gets it closed and asked to submit it to dev +**\** 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 +**\** there needs to be a place for bug fix releases though +**\** I'm with you fluffypony. 0MQ founder/leader feedback on this approach was extremely valuable. +**\** 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. +**\** Common sense might work now, long term with a higher market cap we'll face same issues as btc +**\** Where common sense diverges and the code Base ossifies +**\** 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 +**\** smooth: it doesn't preclude it +**\** 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 +**\** What's the envisionned time scale for ringct? +**\** the idea of a historical record is good +**\** we have similar issues with OpenLDAP - you need 3 branches +**\** one for dev, one for released code, and one for release bugfixes +**\** but i would make the case then that 0MQ should be reverted since it is unusable +**\** particularly when dev and release are far apart +**\** im not actually proposing this because i know it would be a mess, but making a point for the future +**\** like now, where dev has 0MQ and release doesn't +**\** smooth: I agree - moneromooo and I will play around with it next week and make a decision +**\** Reverting isn't really possible. +**\** moneromooo: we could drop dev and re-branch +**\** But one could add ringCT to a new branch based on master. +**\** if it came to that, I mean +**\** That'd be a lot of pain. I'd rather not. Much better to hack on master and merge do dev again. +**\** ok +**\** imo something like zeromq should be developed on a separate branch somewhere, until it is actually usable +**\** s/on master/on a branch based off master/ +**\** smooth: it was usable-ish, we might have regressed some in fiddling +**\** Yes, that. +**\** anyway - let's evaluate and figure out +**\** I think I added all missing RPC so it cn be used, just not by people who want it to work without problem. +**\** **\ 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 +**\** doing all new work in dev is fine, but backporting bugfixes to release will become non-trivial as more features are added to dev +**\** hyc: I guess it depends on the importance of a bug fix +**\** It looks to me like ring CT is going to need a lot of changes to bitmonerod/CN. September looks very close. +**\** we'll see +**\** I don't think we need to create a pressure-cooker for it +**\** ok can I go on? +**\** There are trade offs here. I see problems if dev and master deviate materially +**\** 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 +**\** xmrpromotions: otoh we can backport fixes straight into master to allow for immediate testing by affected parties +**\** With bug fixes as a transition from dev to master +**\** again depends on the nature of the bugfix +**\** like warptangent's work on BDB and the importer probably aren't critical enough to go into master +**\** the importer works properly when it has the hard fork support though, and that uses the bdb support +**\** 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. +**\** My concern is master deviating materially from a quasi stable dev +**\** ArticMine: something like ringct would have to be done in both master and dev +**\** So a project based on master would need a major rewrite after a tagged release +**\** we did dual-PRs for a while +**\** we can do them again +**\** might be easier than The Grand Merge +**\** something like ringct should only be in dev imo +**\** Yes anything fundamental has to be done in parallel +**\** until it gets released of course +**\** I think let's defer further discussion of this till the next meeting +**\** agreed to both +**\** we don't have enough info on the ringct effort or on the state of the dev branch right now anyway +**\** 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? +**\** I agree and lets carefully review the zeromq rfc in the meantime +**\** 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. +**\** binaryFate: no matter what we say people clone and build master +**\** **\<- this guy +**\** it doesn't matter how much we encourage building a tagged release +**\** so we made a decision ages ago that master would be stable +**\** so that anyone pulling and building master doesn't get some hacky, broken branch +**\** Ok +**\** 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 +**\** It can be in any repo. +**\** i think not in the main repo is fine +**\** Like I was hacking on tewinget's branch for a while. +**\** yeah that's a good point +**\** +1 +**\** as long as that person is around and accepting PRs it's perfect +**\** then one big PR to dev when it's ready? +**\** If we go to a dev/master setup, how does dev get merged to master anyway ? +**\** that has worked before, yes +**\** yeah, keep main repo relatively clean +**\** a new feature can get a sort of "lead dev" +**\** moneromooo: when we release we merge from dev to master and tag master +**\** and contributers can hack on his repo +**\** So master becomes a copy of dev at that point ? +**\** yes +**\** Yes but a six month cycle could be too long +**\** thats a different issue +**\** how often to have major releases +**\** we can do major releases whenever, as long as we have major fork releases every 6 months +**\** also are releases time based or feature based +**\** kinda both ? +**\** yeah both +**\** feature-based is all that makes sense to me +**\** The merge to master may need to be more frequent than major fork releases +**\** feature based, but the rolling hard fork also pulls time based I think. +**\** yes +**\** Those Dev -> Master merges would happen with what kind of tagging? Point fix? Even more frequent? +**\** binaryFate: depends on how stable dev is +**\** so new features thus shouldn't be in dev until they are working properly/ready for release +**\** because of timed releases +**\** 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 +**\** smooth, luigi1111: yes, you're both right +**\** it works as long as the half finished feature isn't partially merged +**\** or whatever +**\** the only reason 0MQ got pushed to dev anyway was because oranjuice could no longer work on it, and it was basically done +**\** but I think let's make it the last time that happens +**\** then we avoid complication +**\** ok +**\** 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. +**\** i agree with ArticMine that we can have releases sooner than 6 months +**\** ah ok. so how the 0MQ happened is not how it will be in future +**\** Agree with moneromooo +**\** ok guys we're running overtime, so let's drop this for now, we can pick it up again later +**\** i think it is simply unnecessary to merge to master +**\** er sorry, commit unreleased stuff to master +**\** I think one of the problems with 0mq is that oranjuice kinda left +**\** any developer can handle getting the latest stuff from someone ele +**\** *somewhere else +**\** So it jsut had to be merged +**\** Let get back to this question at the next meeting +**\** ok +**\** last two things +**\** yup +**\** 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 +**\** I'd like us to decide whether we want to keep hacking around things +**\** Does epee really get in the way ? +**\** or if we want to spend the effort now dumping this stuff for things that are easier +**\** it makes 32bit builds murder. but if we can abandon 32bit, that problem disappears too +**\** epee does ? +**\** yeah +**\** moneromooo: yes it does; it made QoS an absolute nightmare to do +**\** and it's still not done properly +**\** We'd have a replace a lot of stuff. +**\** 32bit especially on windows is going to be around for a long time +**\** + TAILS +**\** And a lot of somewhat low level stuff. +**\** 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? +**\** warptangent: low to impossible at the moment +**\** I mean, we can rip and replace the logging stuff with boost::log +**\** all the console stuff can go ncurses or similar +**\** id be more in favor of specific items like that, done on feature branch +**\** and the wire protocol can go ZMTP, since we have a 0MQ dep anyway +**\** eventually we'll get to a point where we're no longer reliant on epee +**\** I agree with the bit by bit approach. +**\** that sounds manageable +**\** also then we'll actually have usable Doxygen docs +**\** the thing to bear in mind is this has virtually zero end user benefit, if not actually zero +**\** yes +**\** on the flip side, we can plug the GUI in via 0MQ instead of monero-as-a-library +**\** Well, the benefit is said to be for 32 bit users. +**\** so we have a shortcut of sorts there +**\** (in terms of users clamouring for stuff) +**\** moneromooo: and long-term viability +**\** we've had potential contributors ask for an architectural doc for the code, and get turned off when there isn't one +**\** so there's scope to slowly bring the codebase in line +**\** i dont believe there is anything about the current code that precludes a GUI. After all, BBR has one with basically the same code. +**\** huh.. contributors that are turned off so easily ... I wouldn't expect much use out of them if they stayed +**\** I was kinda thinking that too... +**\** I guess, but tbh it does make the project seem significantly less mature +**\** which I guess is fair, it's not even 2 years old +**\** less hurdles, more good +**\** it is somewhat hard to come up to speed with the code, i would agree with that +**\** alright +**\** last thing so we can wrap up +**\** 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 +**\** both on behalf of the core team, and on behalf of the community +**\** you all do an amazing job, and we've done a truckload of work in 2014 and 2015 +**\** so here's to an amazing 2016 +**\** hear hear! thank you fluffypony for herding the cats so good +**\** hear hear! +**\** thank you! +**\** Thanks for all the good work +**\** thus concludes the first meeting, next one in two weeks +**\** thanks fluffypony +**\** thanks +**\** Thanks to you fluffy (enjoy that wine)! Thanks to all of you, awesome community. +**\** Thanks fluffypony! +**\** **\ thanks all +**\** is there a buffet? +**\** Infinite_Jest: snacks will be served in The Grand Ballroom in 15 mins +**\** ok great :) but seriously thanks! +**\** thanks fluffy \ No newline at end of file diff --git a/_posts/2016-02-10-monero-missive-2015-year-in-review.md b/_posts/2016-02-10-monero-missive-2015-year-in-review.md new file mode 100644 index 00000000..afae7e6c --- /dev/null +++ b/_posts/2016-02-10-monero-missive-2015-year-in-review.md @@ -0,0 +1,159 @@ +--- +layout: post +title: Monero Missive Special Edition - 2015 Year in Review +summary: A review of everything Monero accomplished in 2015 +tags: [monero missives, year in review, core, funding, accounts, usability, platforms, gui, exchanges, i2p, 0mq, kovri, blockchaindb] +author: Riccardo Spagni (fluffypony) +forum: https://forum.getmonero.org/1/news-announcements-and-editorials/2481/monero-missive-special-edition-2015-year-in-review +--- + +*February 10th, 2016* + +Hello, and welcome to a special edition of the Monero Missives: the 2015 Year in Review! + +As you may know (or may not know:) we had an extremely busy January, which has led to this Missive taking its sweet time in being finalised. + +## State of Monero: 2015 + +The past year has been an interesting one for Monero. There was something of a reckoning as speculators realised that Monero was never going to be a pump-and-dump, rushing out a flashy GUI and ill-conceived features with no regard to the security of the network or the safety of our users. Those that stuck it out have seen steady, constant progress and steady, constant community growth. + +{:.text-center} +![Project Stats 2015 Overview](/blog/assets/2015-year-in-review/stats.jpg) + +**Governance** + +Over the course of 2015 we have considered Monero's governance model. In the context of cryptocurrencies and consensus systems, the term "governance" seems to be quite taboo. However, for anyone that has ever been involved in an open-source project, a lack of governance is as good as a death knell. An [excellent article](http://oss-watch.ac.uk/resources/governancemodels) on governance models is maintained by OSS Watch, and they point out the reason for this: + +> There are almost as many variations of open source management strategies as there are open source projects. It is therefore critical that a project clearly communicates its policies and strategies to potential users and developers of the project’s outputs. A clear governance model also allows potential contributors to understand how they should engage with the project, what is expected of them and what protections are provided to ensure that their contributions will always be available to them. In addition, it describes the quality control processes that help to assure potential users of the viability of the project. The development and communication of a clear and concise governance model is one of the most important steps a project can take towards sustainability through open development. + +Of course, we are primarily talking about the governance of the open-source project (ie. the source code in the [monero-project](https://github.com/monero-project/bitmonero) repositories and associated systems and structures). The Monero network itself cannot be governed, and as has already happened just after Monero's launch, the project can be forked and effectively taken over if the core project is no longer considered viable. If that is the case, why bother with governance at all? Over and above the reasons mentioned in the OSS Watch article, it is important to prevent a gridlock in decision making. There are going to be decisions in Monero's future that will be extremely difficult to make, and if there's no clear path as to *how* they can be made then the project is very unlikely to grow. + +When considering a governance model for Monero our main aim has been to find a balance between pure community consensus on the one hand, and the Core Team operating as "benevolent dictators for life" on the other. Neither of these governance models are desirable on their own, but there is a mixture of the two that we feel is well-suited to Monero. It is effectively the workflow we used last year when a decision had to be made on whether or not to change Monero's emission curve (ultimately it was decided against doing so); this is the workflow for decision making: + +- An idea is pitched by someone, whether via a Github issue, IRC in #monero-dev, the Monero Forum, or elsewhere, and discussion ensues. The preferred forums for discussion around an idea would be as a Github issue or a Monero Forum thread. +- If there are no major objections, or objections are responded to and the idea is refined accordingly, this will be deemed enough for "rough community consensus", or "lazy consensus". A good indicator of community consensus, in many instances, would be if it is an idea that requires funding, and the community successfully funds the effort. +- In the event of the community being unable to reach general consensus on the matter within a reasonable period of time (typically a couple of weeks to a few months, dependent upon the complexity of the idea), the matter will be referred to the Core Team. +- The Core Team will set a date for a meeting on the matter, normally to be held within a week or two. They will review all written material before the meeting. +- The meeting will be held between the members of the Core Team on IRC, openly visible to the community at large, and logs will be made available after. A maximum time limit will be set for the meeting. +- Members of the Core Team will be given an opportunity to state their views, vote (using the voting system detailed below), and discuss the matter at length, within the time limit of the meeting. +- To conclude the meeting, the members of the Core Team will tally the votes that have been cast on the matter during the discussion and forward the decision to the community. + +{:.text-center} +![Governance Process Overview](/blog/assets/2015-year-in-review/governance-process.jpg) + +The Core Team, as well as individual contributors, can participate in all related discussions, but their opinions are not absolute or perfect. Community members are encouraged to test and push arguments, regardless of who is making them, until they are satisfied that the idea or change is workable or worth the risks. + +The voting system that the Core Team uses is based on the CentOS voting system. Votes are not cast permanently, so a member can cast a vote at the beginning of the meeting and change it several times throughout. In order from disagreement to agreement, the following votes can be cast: + +- Veto vote (-1). This is generally discouraged, unless it is accompanied by substantive arguments rooted in project-relevant criteria (protecting the community, economic reasons, technical reasons) +- Reservations vote (-1 or 0). Either a neutral vote, or a negative vote, coupled with reservations and concerns that are stated with the vote. +- Stand aside vote (0). A neutral vote, which can be accompanied with some reservations, but which does not seek to block the vote. +- Supporting vote (+1). Supports the proposal / idea / change. The voter would be expected to also indicate whether or not they will personally assist in driving the effort if successful. + +In the absence of any vetoes, the votes are tallied, which gives both the result of the vote as well as an indication of the amount of support (or lack thereof). If the votes add up to a negative or positive amount then the outcome is clear. If the votes add up to 0 that is normally an indication of no support and only small reservations, in which case the matter is not blocked by the vote, but it is also not particularly supported. In this event the Core Team may choose to hold another vote, optionally at a subsequent meeting a week or two later, if the matter is such that it requires more positive support. + +Our hope is that this process will prevent Monero from falling prey to "design by committee", but also prevent "design by Wikipedia" or "design by the person with the loudest mouth / most eloquent writing". This process is currently up for discussion and comment; please feel free to provide input on it. + +**Core Team** + +Due to the formalisation of the governance of the project, and the clarification of the Core Team's role as stewards, members of the Core Team are expected to be active on an ongoing basis. If a member of the Core Team cannot be regularly active, it is expected that they will step down from their role on the Core Team; the remaining members can elect to replace them if they wish. + +With that in mind, two members are no longer going to form part of the Core Team due to time constraints: *David Latapie* and *eizh*. Both of them have been part of Monero since its inception and the formation of the Core Team. We are immensely grateful for their efforts in the past, and any efforts from them in the future. + +We have also elected two new members to the Core Team: *Franciso "ArticMine" Cabañas*, and *luigi1111*. Francisco is based in Canada, and holds a PhD in Physics and brings extensive business and non-profit experience to the table. He has actively researched and invested in cryptocurrencies since 2011, and focuses on the economic, social, regulatory, and long-term viability aspects of cryptocurrencies. luigi1111 hails from the Midwestern United States and is a sysadmin by day. He has been actively involved in several cryptocurrencies since 2013, and loves cryptography, probability, and English grammar. + +We welcome them to the Core Team, and look forward to working with them both going forward. + +**Finances** + +Our financial situation has dramatically changed with the introduction of the Forum Funding System (FFS). We still have core expenses, some of which include the servers hosting our infrastructure, our test / build hosted machines, annual domain registration for core / MoneroPulse / MoneroSeeds domains, LibSyn's hosting and syndication of our Missives podcast, CloudFlare's services, our GitHub micro plan, and so on. We are quite grateful for those that have continued to send donations to the core fund, and where possible we have also used those to kickstart Forum Funding System fundraisers. + +As mentioned in 2014's Year in Review, the founding members of the Core Team all put in a large portion of funds over the course of 2014, amounting to around 164.5 BTC, when donations were scarce. At this juncture we have not sought to recover those funds, as our focus is on building Monero up, recovering our donations at some later stage, if ever. + +Some [highlights of the FFS over the year](https://forum.getmonero.org/9/work-in-progress) include: + +- [tewinget's Documentation and Cleanup of Source Code](https://forum.getmonero.org/9/work-in-progress/2373/documentation-and-cleanup-of-source-code): raised 3600 XMR in 23 contributions; completed 3/4 milestones. +- [moneromoo's initial fundraiser for 6 months of work](https://forum.getmonero.org/22/completed-tasks/334/fund-a-developer-moneromoo-will-work-part-time-on-monero-for-260-hours-over-approx-6-months): raised over its target of 7800 XMR in 45 contributions; completed all 6 milestones. +- [moneromoo's second fundraiser for for about 10 additional months of work](https://forum.getmonero.org/9/work-in-progress/2410/a-continuation-for-all-purpose-programming-of-what-needs-to-get-done-in-monero): raised 18000 XMR in 21 contributions; completed 3/10 milestones thus far. +- [Shen Noether's translation of some of the website content into Chinese](https://forum.getmonero.org/9/work-in-progress/329/translation-of-content-on-getmonero-org-into-chinese): raised 950 XMR from a target of 600 XMR in 9 contributions; completed its milestone. +- [Shen Noether's fundraiser to complete the C++ implementation of RingCT](https://forum.getmonero.org/9/work-in-progress/2450/ring-ct-c-crypto): raised 3150 XMR in 13 contributions; has very nearly reached completion of all 7 of its milestones. +- [Wolf0's very efficient AMD miner](https://forum.getmonero.org/9/work-in-progress/2400/open-source-amd-miner-by-wolf0): raised 7750 XMR in 20 contributions; completed 6/7 milestones. +- (just sneaking a 2016 one in:) - [Ilya Kitaev's initial funding to complete the Monero Core GUI](https://forum.getmonero.org/9/work-in-progress/2476/the-official-qt-gui-project): raised just over its 14000 XMR target in a matter of hours; work has just begun. + +In total, excluding the GUI fundraiser, the FFS raised just over 48260 XMR over the course of 2015. Virtually all of the fundraisers were for direct open-source code development, and no payouts were made until a milestone had been met, and the community had reviewed the code and confirmed that the milestone had been achieved. + +We can safely say that the FFS has been a fantastic success thus far, and we hope to see more projects being funded of a development nature, as well as of a promotional and educational nature (such as community members covering their costs if they go speak at a conference). + +The FFS exists in a centralised manner today, but in the future we hope to host it in a more decentralised fashion (eg. using Tahoe-LAFS) and couple it with future systems like MoneroID and MoneroTrust. + +**Donation Addresses** + +For general housekeeping purposes we have decided to roll-over the donation addresses every so often, perhaps every year or two. Please take note of the new address details below. We have updated the donate.getmonero.org OpenAlias and other references, but pool operators and anyone else that auto-donates will need to update their systems accordingly. We will maintain the old addresses for some time, but will likely only check them sporadically and move any funds to the new addresses. + +Monero Donations: [44AFFq5kSiGBoZ4NMDwYtN18obc8AemS33DBLWs3H7otXft3XjrpDtQGv7SqSsaBYBb98uNbr2VBBEt7f2wfn3RVGQBEP3A](monero:44AFFq5kSiGBoZ4NMDwYtN18obc8AemS33DBLWs3H7otXft3XjrpDtQGv7SqSsaBYBb98uNbr2VBBEt7f2wfn3RVGQBEP3A?recipient_name=Monero%20Development&tx_description=Donation%20to%20Monero%20Core%20Team) (view key: f359631075708155cc3d92a32b75a7d02a5dcf27756707b47a2b31b21c389501) +Bitcoin Donations: [1KTexdemPdxSBcG55heUuTjDRYqbC5ZL8H](bitcoin:1KTexdemPdxSBcG55heUuTjDRYqbC5ZL8H?label=Monero%20Development&message=Donation%20to%20Monero%20Core%20Team) + +**Design and Development Goals** + +During the course of 2015 we published a set of [Design and Development Goals](https://getmonero.org/design-goals/) focused not only on pure development, but also on research goals that the Monero Research Lab are pursuing. Typically the development goals are smaller, more immediate, and easier to achieve, whereas some of the research goals might not even be feasible, and others could take many years to find a suitable solution. + +Nevertheless, over the course of 2015 we managed to complete 7 of the development goals and 2 of the research goals: + +- *LMDB embedded database implementation*: the Lightning Memory-Mapped Database is the brainchild of Howard Chu, who has become quite actively involved in the Monero Project. Our implementation of LMDB in Monero has led to a truly massive reduction in memory usage of the daemon, down to well under 100mb of real memory in use, whilst still remaining exceptionally performant. +- *Daemonize*: instead of being forced to run the Monero daemon in the foreground, this effort allows for it to fork to the background, but still be able to interact with and query the daemon. On Windows computers it can even install itself as a system service. +- *BerkeleyDB fall-back database implementation*: initially this was added as an acid test for our generic blockchain database class, but proved useful when we hit LMDB issues on 32-bit and ARM systems (subsequently resolved). +- *32-bit and ARM support*: we lost 32-bit support when the in-RAM database started requiring more than 4gb of RAM. Thankfully, our blockchainDB work, as well as the LMDB and BDB implementations, brought this back, and allowed us to add ARM support as a bonus! +- *Various synchronisation improvements*: thanks to a vastly improved synchronisation mechanism a brand new Monero node can completely sync up with the network from scratch in as little as 45 minutes. +- *ØMQ and TLS support for RPC*: currently only available in the development branch, this is part of a series of underlying changes that will make Monero far more extensible and flexible in the future, and will allow for more secure integration for merchants and other developers. +- *Stealth & serialised payment IDs*: this started off as something that had to be researched and figured out, but thanks to some clever work by luigi1111 and others this is integrated in the 0.9 codebase. +- *RingCT*: as mentioned in Academic Research section, this goal has been achieved, and the C++ code for it is nearing completion. + +In many ways Monero's long-term design goals represent a fundamental shift in focus. Monero's primary use, at this point, is as a private store of value and medium of exchange. But since Monero has a global, decentralised, censorship-resistant timestamping database, there is a world of functionality that can be bolted on top. Thus, the aim with Monero is for it to become more than just a private cryptocurrency; we want Monero to become an entire suite of easy-to-use tools and systems designed to enhance personal privacy. + +**Releases** + +During 2015 we kept our collective heads down, focusing on the gargantuan effort required to get the database implementation running smoothly and implement the MRL-0004 guidelines. This culminated in the release of Monero 0.9 *Hydrogen Helix* on the first day of 2016. A full list of the changes can be found on the release page: https://github.com/monero-project/bitmonero/releases/tag/v0.9.0 + +We'd like to extend our gratitude to the 19 contributors that invented, developed, hacked, wrote, tested, broke, fixed, and built Monero's core code over 2015: moneromooo-monero, warptangent, Thomas Winget, Riccardo Spagni, rfree, smooth, NoodleDoodle, Howard Chu, Sergey Kazenyuk, luigi1111, Shen Noether, Rostislav, Brendan Telzrow, Lex Kalinkin, sammy007, Wladimir van der Laan, David Vorick, roman, and meshpoint. + +Over the year there were 904 commits made to the main Monero repository, plus quite a few more to the development branch. Using the same methodology we applied in the previous Year in Review, this means: + +| Statistic | 2014 | 2015 | Total | +|---|---|---|---| +| Weeks of Development | 35 | 52 | 87 | +| Days of Development | 245 | 365 | 610 | +| Commits | 594 | 904 | 1498 | +| Contributors | 11 | 19 | 30 | +| Modified Lines | 10 221 | 5 342 | 15 563 | +| New Lines | 12 706 | 263 288 | 275 994 | +| Removed Lines | 32 | 514 | 546 | + + +**Academic Research** + +The Monero Research Lab also had a busy 2015. Two main efforts were completed during the year: + +- *[MRL-0004: Improving Obfuscation in the CryptoNote Protocol](https://lab.getmonero.org/pubs/MRL-0004.pdf)* - this was a major research effort that analysed the failures highlighted in [MRL-0001](https://lab.getmonero.org/pubs/MRL-0001.pdf), as well as uncovered some others, and presented a number of solutions to these. The solutions presented in MRL-0004 were incorporated in the Monero hardfork coming up in March, 2016. +- *[MRL-0005: Ring Signature Confidential Transactions for Monero](https://lab.getmonero.org/pubs/MRL-0005.pdf)* - based on [the excellent work of Bitcoin Core developer, Greg Maxwell](https://people.xiph.org/%7Egreg/confidential_values.txt), this couples Confidential Transactions with Monero's Ring Signatures, efficiently hiding transaction values on the blockchain, and thus crossing a major privacy threshold. Once implemented this will make Monero the first cryptocurrency in production and in use that cryptographically obscures transaction values, where the transaction inputs come from, and where the transaction outputs are going to. + +**Kovri** + +One of the areas that Monero has long been focusing on is disconnecting the link between a transaction and the IP address of the node that was first observed broadcasting it, as this information often reveals the IP address of the transaction originator. Severing this link is vital, and it is not merely enough to support this functionality optionally through networks like Tor; it needs to be native and an inherent part of the Monero protocol. + +With that in mind, our work with members of the I2P community has progressed from initially being involved with i2pcpp, to i2pd, and finally to an initiative from a few months ago: the Kovri I2P Router. Initially forked from a branch of i2pd, the Kovri project stands on its own in the Monero stable. It is not a mere side project, but a large fully fledged open-source project. + +Nearly 2300 commits from 37 contributors have lead to just under 30000 lines of code, and the effort is ongoing. You can follow Kovri's progress on the Github repo: [https://github.com/monero-project/kovri](https://github.com/monero-project/kovri) + +**Monero Website** + +At the beginning of 2015 we opened the Monero Forum. But we didn't stop there - the Monero website was also overhauled and released as a brand new site, powered by Jekyll, with a look-and-feel matching the Monero Forum. The website is open-source and can be found here: [https://github.com/monero-project/monero-site](https://github.com/monero-project/monero-site) + +Since its inception, the Monero website has had over 320 commits from 14 contributors. The community has been fantastic at supporting the initiative and helping shape the information on the site. As we roll out new tools to make contributing to the site even easier, we can only expect this to grow. + +**Looking Forward: 2016** + +We accomplished a great deal in 2015, with ever more to do. In 2016 we are hoping to tick more items off of our Design and Development Goals, and continue the slow and steady move towards Monero becoming a privacy suite. + +We hope you will continue with us on this journey, and we look forward to an excellent 2016! + +Your Core Team - Riccardo "fluffypony" Spagni, luigi1111, NoodleDoodle, smooth, tacotime, Franciso "ArticMine" Cabañas, othe \ No newline at end of file diff --git a/_posts/2016-02-14-overview-and-logs-for-the-dev-meeting-held-on-2016-02-14.md b/_posts/2016-02-14-overview-and-logs-for-the-dev-meeting-held-on-2016-02-14.md new file mode 100644 index 00000000..34a8969f --- /dev/null +++ b/_posts/2016-02-14-overview-and-logs-for-the-dev-meeting-held-on-2016-02-14.md @@ -0,0 +1,284 @@ +--- +layout: post +title: Overview and Logs for the Dev Meeting Held on 2016-02-14 +summary: Further dev branch discussions, 0.9.2 release date, RingCT implementation, DB migrator +tags: [dev diaries, core, crypto] +author: gingeropolous +--- + +*February 14th, 2016* + +# Summary + +## Review + +Lots of stuff done in the past 2 weeks: + +- v2 block tests +- flattened CMake issues (DNSSEC will work again) +- the possibilities of inconstent database state and the mempool transactions "have been clobbered" + +Amongst other stuff not mentioned, but copying here from moneromoos milestone work: + +- fixes for the wallet creating txes over max size the daemon will accept +- more work on tests (including tests for the MRL-0004 changes) +- going through all the V1/V2 stuff to catch what I saw was wrong +- fix for txes not expiring from pool due to other nodes coming online regularly +- better handling of pending/failed txes in simplewallet +- new command/RPC to flush txes from the txpool +- preventing two daemons from using the same data dir concurrently +- more intelligent handling against duplicate outs + +## RingCT + +Shen is almost done with reference code, volunteers needed to actually implement. warptangent takes on the db stuff. + +https://github.com/ShenNoether/MiniNero/tree/master/brief + +When RingCT gets merged, will be a good time to merge other database formats. DB format changes - build a converter that "upgrades" format changes. It's left open, but hyc agrees to tackle it later. + +## Dev Branch + +This has become the bastard child of Monero development apparently. Lines 82 - 167 encompass discussion on this topic. The goal is "to merge back to the dev branch" Ultimately the decision is to hack at it for a bit and reevalauate in next meeting. + +> 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 + +**\** welcome everyone +**\** first off, thanks for being present +**\** lots has been done in the last couple of weeks +**\** moneromooo hit another milestone on his FFS fundraiser, so good job on that +**\** he also clobbered some major issues (v2 block tests etc) +**\** here +**\** warptangent has also been a monster in the last couple of weeks +**\** flattened CMake issues that we were struggling with +**\** so that means that our static builds now do DNSSEC resolution again, even when a local DNSSEC root key is not available +**\** (which is basically on every Windows box) +**\** which means we need to evaluate our 0.9.2 release +**\** is there anything urgent that needs to go into 0.9.2, or can we push that out? +**\** (besides open PRs, I mean) +**\** I've got nothing pending +**\** with the updates to block handling, the possibilities of inconstent database state was addressed(block height and hf versions not matching) +**\** issues there were most urgent on my mind last time +**\** yeah, that and the mempool transactions were the two biggies +**\** both have been clobbered +**\** there are some bdb updates i'm finishing up, but they aren't urgent. +**\** moneromooo: anything from your side? +**\** No +**\** saberhagen reporting in +**\** hah hah +**\** !! +**\** better late than never :-P +**\** he was here two years ago. we are the ones late +**\** well apparently he was here 5 years ago :-P +**\** warptangent: 2 years? Make that 4-5 +**\** 4 years please :) +**\** hah hah +**\** :) +**\** ok so +**\** let's talk about RingCT +**\** shen is getting close-to-done on his reference implementation code +**\** but it requires some actual implementation, and some DB work, to actually integrate it +**\** I think someone needs to volunteer to chiefly run with that +**\** any takers? +**\** i'm up for db stuff +**\** ok it's mostly in here: https://github.com/ShenNoether/MiniNero/tree/master/brief +**\** there's been some discussion in the MRL as to what is actually required +**\** I'll ask Shen to make some notes +**\** next up +**\** I guess that will be a good time to merge other DB format changes too +**\** yes +**\** definitely +**\** re: DB format changes, we would need to build in a converter that "upgrades" format changes +**\** I was thinking something like Laravel's migrations would work (I think I mentioned this last time) +**\** 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 +**\** that way the code only actually needs to know how to interact with the latest format +**\** and the logic of getting there from any arbitrary previous version lives in migrations +**\** (that are specific to implementations) +**\** we can either generalise that, or just do that for LMDB and leave other implementations to handle it to their liking +**\** 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 +**\** so when you change a field, it handles the data migration and protects the database consistency if it's interrupted +**\** I don't think we'd be able to handle interruptions easily +**\** maybe dump it into a temp db and then rename? +**\** 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 +**\** so that way there's no resuming, it's restarting and wiping out any existing temp dbs +**\** oh that is far easier, sure +**\** yeah, that tells me we really just want an offline dedicated migrate tool +**\** a more integrated form of export and import +**\** hyc: I thought about that, the problem is that people are going to just upgrade ->** restart the daemon +**\** and then if it chokes and says "run this tool" they'll get frustrated +**\** also we have to automate it for the GUI too because GUI users... +**\** We don't really need to bother, there's a version field. +**\** So you could create the new dbs, then set the field to new version. +**\** If it's interrupted, it will recreate the new dbs, erasing the partial ones. +**\** as long as new dbs have unique names never used in previous ones +**\** At least for the tx/block subdb work anyway. +**\** we can append version# to the name if we want similar names +**\** yeah +**\** 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? +**\** is the problem that the migration can't run as a transaction because the amount of data being moved is too large? +**\** leave open for now, but I'll probably take it later +**\** smooth - yeah, pretty much +**\** the txn can be that large but it slows down quite a bit then +**\** for some migrations that should be okay though (depending on how much the format is being changed) +**\** 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 +**\** so that you can resume from an interruption +**\** ok +**\** next up +**\** once 0.9.2 is tagged in the next week we have to merge back to the dev branch +**\** 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) +**\** does anyone have any objections to that? +**\** When do you plan a release after 0.9.2 ? +**\** 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 +**\** if that appears to be unachievable then we'll re-address it in a couple of months time +**\** So we are looking to a freeze for Ring CT in April/May? +**\** depending on how implementation goes, yes +**\** 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. +**\** moneromooo: I know - if we need to we can push the fork date +**\** Testing? +**\** Alright then. +**\** ArticMine: you mean in terms of functional tests or automated tests? +**\** both +**\** 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? +**\** xmrpromotions: for planned forks, given how small Monero is, we could probably get away with a month or two +**\** but likely for the last time +**\** \ moneromooo: I know - if we need to we can push the fork date <= I am in favor of this as well +**\** 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 +**\** we don´t necessarily need to stick to a certain date for something that important +**\** Agree fluffypony +**\** the larger issue here is that the 0MQ stuff was pushed prematurely because OranJuice couldn't work on Monero any longer +**\** in future I don't expect stuff like that will happen +**\** Same issue with smart mining right? +**\** 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 +**\** moneromooo is probably in the best position to make a call on that +**\** meaning it may be more productive to pull what we want from it (that isn't unfinished) and merge to master than vice versa +**\** \*with master (not to master) +**\** Well, personally I'd not have a dev branch so... +**\** heh +**\** if people knew how to checkout a tag it wouldn't be a problem :) +**\** Negative reinforcement helps make that a reality :) +**\** 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 +**\** right, how much in there is usable? +**\** 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. +**\** It is usable, just rough. +**\** 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? +**\** warptangent: no smart mining, just 0mq +**\** ah +**\** i would suggest: put 0mq back on its own branch, finish it first, then merge when it is ready +**\** smooth: Isn´t 0mq the mere reason we have a dev branch currently? +**\** so basically merge nothing from dev right now +**\** there are some other bits and pieces on the dev branch +**\** tewinget's code comments, for eg. +**\** if that's the only real difference between dev and master ... +**\** I see +**\** ah +**\** fluffypony: What if contributors just worked on their own fork until it is sufficient for master? +**\** anyway im not saying which is more productive necessary but the question is worth asking rather than inertia +**\** fork/branch +**\** dEBRUYNE: that's the way it normally works +**\** the 0MQ thing was an exception +**\** It'd also mean you get to redo the merge with all the stuff I merged recently :/ +**\** oh yes +**\** And deal with that fucking white space patch AGAIN +**\** my instinct is that we've put too much effort into the dev branch already to make cherry-picking worthwhile +**\** there's a handful of merges since moneromooo's last merge to dev +**\** effort isnt really the right measure +**\** the measure is how much useful value is there +**\** well it works +**\** but there are some bugs that need to be fixed +**\** there has been a lot of work on master only in the past few months +**\** and we need to rip the net_skeleton stuff out and replace +**\** so how much effort would it be to reapply just 0mq to current master +**\** Probably a big pita. However, the original merge was also a bit crappy. +**\** last merge up to dev was Jan 3rd +**\** afaik +**\** And while I was hacking on it, thre's a fair number of changes to the 0mq stuff I made in master. +**\** Like fixes, all the missing RPC calls +**\** in dev? +**\** 0mq in master? +**\** in dev? +**\** lol +**\** Yes, in dev +**\** at least people are paying attention +**\** lol +**\** ok I say we hack at it for a bit +**\** id say be open minded about it and undertake a review +**\** and then re-evaluate +**\** \ last merge up to dev was Jan 3rd << does this also mean dev was up to date in terms of master as well? +**\** warptangent: yes that's what I mean - all of master was merged up to dev on Jan 3rd +**\** Yes. I expected we'd move to dev then. +**\** the only reason we didn't was 0.9.x fixes +**\** that might not be too bad then. +**\** moving to dev is fine (assuming its state is good enough) but that should be independent of any necessary point releases +**\** ok - let's give it to the next meeting to reevaluate +**\** this is especially the case due to the premature 0mq merge +**\** 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? +**\** perhaps do it on another day? +**\** saturday? +**\** Saturday works better for me +**\** Saturday is fine with me +**\** 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 +**\** otherwise those of us that attend both end up with every Sunday having a block out +**\** I am fine with 5 - 12 march +**\** and then go on the biweekly schedule again +**\** There is also the hardfork coming up on 20 March, so might be important to have at least 2 meetings before it +**\** ok - so we push the meeting till March 5th, and then the meeting thereafter will be March 14th +**\** 5-6 March not great for me, but that's probably not a big deal +**\** 14th is a monday fluffypony +**\** sorry 13th, thanks dEBRUYNE +**\** so March 5th Saturday and March 13th Sunday +**\** yes +**\** that is fine here +**\** can we meet earlier on March 13th? +**\** 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 +**\** I can ask to push the Kovri meeting back on that day +**\** but I know EinMByte has indicated he can't do earlier +**\** let me see what I can do in the Kovri meeting in a few minute's time +**\** It is because of the change to daylight savings time +**\** ah +**\** In the Northern hemisphere +**\** ok then the last thing, unless someone has anything to add +**\** I got a general question +**\** there are open issues that are low hanging fruit, from really long ago, like #83, #84, #92 +**\** Is 0MQ highest priority currently? Certainly with the GUI work being done currently +**\** 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 +**\** some are more suited to "after 0MQ", but there's others that are more general +**\** 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 +**\** I was going the raise the question of the 32 bit versions +**\** and 0MQ \*works\*, it just needs some bug fixing and massaging +**\** ArticMine: good point - I'd forgotten about that +**\** fluffypony: As long as it doesn´t hold up the work it´s fine +**\** hyc: are you able to put together some build instructions for win32, given the issue with builds on 32-bit msys2? +**\** I have been testing 0.9.1.0-9cc8c24 +**\** on XP and 7 +**\** sure +**\** I already had a start at that on the reddit +**\** ilya is working on the c++ interface currently, doesn´t really matter for the gui if its using zeromq or not +**\** btw hyc, you may find this of interest: https://github.com/niXman/mingw-builds +**\** othe: Thanks for clarifying that +**\** are all issues on getmonero.org sorted on github? meaning I saw some that are probably old and might be resolved. +**\** bookies: you mean for the site, or for Monero itself? +**\** https://github.com/monero-project/monero-site +**\** fluffypony: heh, ok. are we going to tell people they need to build their own compiler before they can build win32? +**\** bookies: I haven't checked - there may very well be some old ones that are sorted +**\** ty +**\** \ 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 +**\** hyc: oh - don't they provide binaries? I thought there were +**\** may have misread +**\** afaics they're just build scripts for building gcc etc +**\** ah ok +**\** alright, that's our hour - anything else before we close the meeting? +**\** Shall I merge master into dev again then ? +**\** I was going to do that, but... +**\** moneromooo: yes, please +**\** kk +**\** will someone publish the meeting minutes like last time? +**\** yes +**\** Thank you diff --git a/_posts/2016-03-16-monero-0.9.2-released.md b/_posts/2016-03-16-monero-0.9.2-released.md new file mode 100644 index 00000000..34ea9461 --- /dev/null +++ b/_posts/2016-03-16-monero-0.9.2-released.md @@ -0,0 +1,38 @@ +--- +layout: post +title: Monero 0.9.2 Released +summary: A point release of Monero Hydrogen Helix containing performance improvements and bug fixes +tags: [releases] +author: Riccardo Spagni (fluffypony) +--- + +*March 16th, 2016* + +## Summary of Changes + +This has urgent and important bug fixes to 0.9.1 *Hydrogen Helix* + +- Major performance and size improvements to the LMDB database implementation +- Urgent and important bug fixes for the upcoming hard fork +- Huge bug fixes to the database hard fork handling +- New simplewallet flag to restore from keys +- Initial work on a wallet library / API +- Updated in-source block headers + +## Official Download Links + +- [Windows, 64-bit](https://downloads.getmonero.org/monero.win.x64.v0-9-2-0.zip) +- [OS X, 64-bit](https://downloads.getmonero.org/monero.mac.x64.v0-9-2-0.tar.bz2) +- [Linux, 64-bit](https://downloads.getmonero.org/monero.linux.x64.v0-9-2-0.tar.bz2) +- [Linux, 32-bit](https://downloads.getmonero.org/monero.linux.x86.v0-9-2-0.tar.bz2) +- [Linux, ARM v7](https://downloads.getmonero.org/monero.linux.arm7.v0-9-2-0.tar.bz2) + +## Download Hashes + +If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes: + +- monero.win.x64.v0-9-2-0.zip, a64119348fbf1f74e82afde283cbaa76bdb81fcb7181f639ea7e8579ef754534 +- monero.mac.x64.v0-9-2-0.tar.bz2, efc59859944a8406b22f5a19e8987bb6c18b2ff0095b0e77a1557a7a639c0d98 +- monero.linux.x64.v0-9-2-0.tar.bz2, de9db0ca6e72fc3e19d555fd003313a93e490ca747cd58a6370ff8a916996f2a +- monero.linux.x86.v0-9-2-0.tar.bz2, ee0a32f7e3d12b1a02267593f71a6f9e13f85f43c86d0a4814f3f12c3dbaabc8 +- monero.linux.arm7.v0-9-2-0.tar.bz2, e0b9bcd7d3b8013a974f36ae0311c3a150a223032f16978bf53e03535f9b5836 diff --git a/_posts/2016-03-19-overview-and-logs-for-the-dev-meeting-held-on-2016-03-19.md b/_posts/2016-03-19-overview-and-logs-for-the-dev-meeting-held-on-2016-03-19.md new file mode 100644 index 00000000..9b856534 --- /dev/null +++ b/_posts/2016-03-19-overview-and-logs-for-the-dev-meeting-held-on-2016-03-19.md @@ -0,0 +1,342 @@ +--- +layout: post +title: Overview and Logs for the Dev Meeting Held on 2016-03-19 +summary: Open PRs, GUI commits, app/add-on infrastructure, versioning +tags: [dev diaries, core, crypto] +author: dEBRUYNE / fluffypony +--- + +*March 19th, 2016* + +# Logs + +**\** dev meeting in 5 min, FYI +**\** dingdong +**\** hello +**\** fluffypony, smooth, othe, ArticMine, luigiw, NoodleDoodle, tewinget, moneromooo +**\** there we go +**\** did I forget anyone? +**\** oh, hello +**\** is warptangent around? +**\** Hello +**\** he's been fighting a flu last we heard +**\** hi +**\** Hello. I'm here but I'm fighting the apocalypse. +**\** of flus. +**\** keep doing it +**\** wait you're alive that's good to hear +**\** fluffypony seems ded +**\** sorry +**\** was eating +**\** welcome everyone +**\** so as you know we pushed out 0.9.2 +**\** however, there are some nagging issues from the ReadTXN work +**\** hyc has nailed a major one as of a few hours ago +**\** so we'll probably do a point release on Monday or so +**\** also that means that the way we use LMDB has changed a bit +**\** hyc can you tell us briefly how we should wrapping access to LMDB, both read and write operations? +**\** Are you talking about the CRITICAL\_REGION stuff? +**\** yes, and the cursors vs. txns stuff +**\** ok, the critical\_region stuff actually is not a change at all. +**\** basically, when you're setting up to do a write, you need exclusive access to the DB +**\** this appears to have been a long-standing bug, unrelated to the readtxn changes +**\** so as for reads - there is now a long-lived read txn per thread +**\** and a set of read cursors to go with each +**\** the TXN\_PREFIX\_RDONLY macro sets that up in a particular function, grabbing the thread-local-storage for it +**\** and RCURSOR(dbname) sets up a read cursor for a particular DB +**\** these are analogous to the CURSOR(dbname) macro for getting a write cursor to a DB +**\** the point of all this is to avoid a bunch of malloc/free/seek when accessing a DB +**\** the old code was allocating a readtxn and cursors inside each function +**\** likewise for writes +**\** by reusing the same cursors acros a set oof functions we get a pretty good performance gain +**\** ok? +**\** neat +**\** also on the topic of stuff-hyc-did-lately +**\** if anyone missed it, we now have a win environment guide up on forum.getmonero.org +**\** ^ https//forum.getmonero.org/5/support//building-monero-v0-9-2-on-winMonero +**\** so that should get us all on the same page with testing etc. +**\** and one success story replied to it already ;) +**\** we've also dropped support for BDB as the default database, and switched to LMDB as the default +**\** including on -bit and ARM +**\** BDB will remain supported for the moment, primarily as a mechanism for contributors to understand how to build out DB support +**\** krongle) +**\** shew we have the entire xmr.to team here today, that's awesome +**\** fluffypony good memory P +**\** we shared a podcast together, binaryFate -P +**\** yes - impressive nick-name recollection +**\** hah hah +**\** while we have you guys here, are you guys doing anything cool you want to talk about? +**\** we're doing many cool things, but nothing we can talk about at this stage +**\** hah hah +**\** it does lead to an interesting point of conversation +**\** seriously considering btc -> xmr direction +**\** plugins +**\** 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? +**\** iam6yearsold Shen's offline at the moment, I'll ask him to update the Reddit thread with some info ) +**\** re plugins, we've spoken briefly about options for the GUI +**\** iam6yearsold There is a bit of info here -> https//imgur.com/a/HZL7k +**\** iam6yearsold for MiniNero integration you'd have to see with NobleSir. The API doc is at http//xmrto-api.readthedocs.org/en/latest/ +**\** but I guess we could have "plugins", of a sort, that add functionality +**\** like xmr.to or shapeshift integration right in wallet2 / wallet2\_api +**\** I think we should be fairly strict on which plugins to allow +**\** fluffypony we wanted to discuss that plugin integration soon in fact ) +**\** we're quite interested to all secondary questions related to plugins +**\** I guess the major question becomes +**\** so plugin repository/db, packaging, distribution etc +**\** do we allow "permissionless" plugin development, or do we just have a central repo that we git submodule in? +**\** The main question I see with plugins is trust +**\** ArticMine exactly +**\** yes. It puts quite a bit responsibility on the dev team +**\** well no ones going to trust anything that doesn;t come from core +**\** \ we shared a podcast together, binaryFate -P <-- wasn't I there for that? +**\** considering the recent Google Chrome Bitcoin stealing malware I think that premissionless plugins are dangerous +**\** as we've seen with 3rd party GUIs +**\** you obviously can't stop permissionless dev, you can discourage users from trusting it I guess +**\** we can start signing binaries, ohjoy +**\** I would prefer the latter +**\** luigi I mean permissionless within core +**\** oh +**\** I think no +**\** 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 +**\** fluffypony I'd see both possible all together. Unpermissioned scale and central repo for a selected subset would ease experience and trust for user +**\** so if plugins are interpreted (eg python), things become a whole lot easier +**\** for the record I hated the twittter plugin idea I saw a while back +**\** My take permissionless has to be allowed. The end user has to be made aware who is signing and if to trust the plugin +**\** well the Electrum model works well +**\** I agree with ArticMine +**\** (inspection in case of central repo, but also self-distribution by plugin devs) +**\** ThomasV will merge basically any plugin, as long as it's not malicious +**\** and plugins are part of the core code, effectively just in a subfolder +**\** I think it's a testament to Electrum that they haven't had a malicious plugin ever +**\** how do they deal with the upgrade/maintenance workload? Or do they just disable broken plugins? +**\** Is there a way to make a subfolder in the subfolder? i.e. (1) signed and approved by core-team, (2) optional +**\** arnuschky yeah they just disable broken plugins, and eventually they get deprecated out +**\** We should allow self distribution with appropriate warning +**\** ArticMine anyone can compile their own build, which would be the same thing +**\** are you planning for compiled plugins or interpreted ones? that's quite a differens IMHO +**\** arnuschky so +**\** self-distribution is a mess for compiled ones... +**\** I was thinking we have a repo, say it's called monero-plugins +**\** audit as well +**\** and then anyone can PR to that repo +**\** and that repo is pulled into the main Monero source as a git submodule +**\** there are two advantages to this +**\** 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 +**\** 2. if we come up with a standard set of functionality hooks, then other projects can pull that same repo in +**\** eg. jwinterm's lightwallet +**\** also it means that the compiled Monero binaries have those plugins baked in, and you can't add extra plugins post-compile +**\** so no need to deal with interpreted code and securing that on disk and in memory +**\** baked in means no dynamic loading? +**\** \ 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 +**\** Sounds all good to us. If distribution is done through official channels it's great. +**\** hyc yes +**\** no dynamic loading +**\** cool +**\** 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 +**\** fluffypony that would be really great. +**\** ok - I think next steps would be to consider some of the hooks we need to provide to add functionality +**\** we can use the Monero wikia as a collaboration area for that +**\** It is a good balance for plugins +**\** and then we'll just update the Monero Slack +**\** well securing the plugins can always happen by signature - no matter if interpreted or binary +**\** I'm kidding, we don't have a Slack +**\** we're not that cool +**\** Would these plugins allow for interpreted languages like Lua or Python? +**\** :) +**\** aerbax I don't see why not, individual CMake files in each plugin folder that allow it to produce a library fix everything +**\** We could financially support development of plugin architecture if xmr.to is the first instanciation of those plugins. +**\** if it spits out a .so / .a / .dll with the right hooks then it's fine +**\** 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 +**\** just like any random site on the web can offer binaries for download and we can't secure that either +**\** caveat emptor has to come into play at some point, I think +**\** the binaries present a single attack surface, and there's GPG-signed hashes +**\** if we have to do GPG-signed hashes for a bunch of .py files I think I'll go mad -P +**\** I'm not saying I think it should be one way or another, I'm merely pointing out flaws in your argument P +**\** fair enough +**\** 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 +**\** As long as people can compile their own version with non permissioned plugins this can work +**\** they can always do that +**\** yep +**\** and in fact that would be the testing model +**\** we're not apple ) +**\** fork the repo, and build a binary to test your new plugin +**\** asking noobs to compile will limit adoption +**\** luigi Exactly +**\** iam6yearsold why would noobs be writing their own plugins? +**\** for security +**\** lol gingeropolous +**\** lol +**\** fluffypony championing the first plugin or the whole infrastructure? +**\** 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 +**\** arnuschky championing the design, I guess +**\** tewinget I would prefer that. +**\** how about 1 version with binaries and gpg sig and no plugins? caveat emptor for the rest +**\** mostly due to auditing, and there's no build/distribution mess attached +**\** I would prefer we remain language agnostic +**\** iam6yearsold that's what we already have +**\** fluffypony language-agnostic is fine, but...well, how do you imagine that will work out? +**\** thanks pony. I like the current situation then +**\** tewinget read up +**\** ah even language agnostic. I thought up to now it's supposed to be a C++ only API +**\** as in, how do we become language-agnostic so that we can remain so? +**\** [] \ Would these plugins allow for interpreted languages like Lua or Python? +**\** [] \ aerbax I don't see why not, individual CMake files in each plugin folder that allow it to produce a library fix everything +**\** ^^ +**\* smooth** is here +**\** also what if a plugin wants to call a function in the core crypto library, for instance? +**\** design-wise, that's sounds like a nightmare, no? +**\** Oh, so linked directly ? I kinda assumed it was gointg to be RPC based. +**\** ok well I think we're getting into an implementation discussion that's outside of the scope of this meeting +**\** I mean, if you don't have a small and defined API, every bigger change in the wallet will break plugins +**\** true ) +**\** after the dev meeting we can continue this conversation if you guys want +**\** but let's first circle back around +**\** this deserves some kind of design thread like ringct imo +**\** Oh, link ? +**\** moneromooo: "this deserves" +**\** so nothing yet +**\** "like ringct" +**\** oh +**\** I see what you were asking +**\** oh +**\** Oh +**\** OH +**\** "like ringct is supposed to get" +**\** Fair enough. +**\** so basically this is all luigi's fault +**\** warp was gonna go it!@ +**\** its true. i mis-called out luigi on that one +**\** warptangent is off sick at the moment +**\** yes +**\** so I blame that +**\** I blame Canada +**\** ok back on track +**\** since the last meeting the bulk of the PRs have been bug fixes +**\** and changes to the way we access the DB as discussed at the beginning +**\** we also had a huge discussion about how to handle mixins below the minimum in the RPC call +**\** which was then implemented in #715 +**\** 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 +**\** oh I was gonna do that +**\** but then I didn't +**\** luigi we can do it together +**\** awwww +**\** I can show you the world, shining shimmering splendid +**\** take you wonder by wonder +**\** lol +**\** also #728 was a little contentious +**\** so we created a company called Mixinstream that has hired all the contributors +**\** heh heh +**\** and gingeropolous has launched Monero Classic +**\** ( sorry ) +**\** -P +**\** ok so #728 is Ilya's work as part of the GUI effort +**\** Can I launch unlimited? +**\** he was struggling with wallet2, and decided to break it out into something more logical and usable +**\** (to him at any rate) +**\** What makes it contentious? +**\** ArticMine I'll get to that now +**\** he's unintuitively called it wallet2\_api, which is a little confusing +**\** 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 +**\** and there's a lot of DRY-violating code because of it +**\** obviously there was some push back, not to prevent merging it +**\** but more to understand the thought process +**\** Define DRY ? +**\** DRY violating scares the shit out of me +**\** https//en.wikipedia.org/wiki/Don%t\_repeat\_yourself +**\** maybe +**\** yes +**\** iam6yearsold DRY violations are just where you have a piece of code in two places +**\** so any changes have to happen in both +**\** we can treat the DRY-violating code as a temporary issue, though +**\** two places = more opportunity for error +**\** as we're going to wait until Ilya is done with it +**\** Which makes maintenance much harder +**\** and then we'll either drop wallet2 and replace it with the new wallet API +**\** (ie. replace the simplewallet calls as well) +**\** or if it's just a pointless layer we'll have to go the opposite route +**\** and change his Qt callers to use wallet2 +**\** as it stands it's kinda undecided and we'll have to see how Ilya goes +**\** Is Ilya aware of the concern? +**\** ArticMine yes, we had some discussion on the PR, and othe has also spoken to him afaik +**\** he was responsive on the PR comments, but this isn't Bitcoin +**\** we don't ACK NACK utACK for years before merging somethingm +**\** aintnobodygottimeforthat.gif +**\** utNACK +**\** luigi #networknerd +**\** utACK was not a typo ? +**\** no +**\** means untested +**\** conceptACK or similar +**\** yeah +**\** moneromooo https//lists.linuxfoundation.org/pipermail/bitcoin-dev/-December/71.html +**\** if you're interested +**\** crap +**\** LOL +**\** PasteGate 2.0 +**\** internets +**\** ur pasting skills suck +**\** Hahah +**\** othe pasting is a scam +**\** that's how I write all my patches +**\** I just copy-and-paste code from StackExchange +**\** thats my job +**\** heh +**\** ok so anyone who can reproduce the 0.9.2 segfault please try latest master +**\** and if you're still segfaulting let us know +**\** else we're going to do a point release on Monday +**\** 0.9.3, I guess? +**\** hrm +**\** or 0.9.2.1 +**\** we're gonna run out of numbers at this rate +**\** yeah we are +**\** oh wait +**\** 0921 +**\** we have 0.10 +**\** nevermind +**\** 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 +**\** yes we just do a Bitcoin +**\** No chance, there's an infinity of those. +**\** 0.11 +**\** iam6yearsold yes, and we've reached out to as many of them as we can +**\** is 0.10 supposed to be for next hard fork? +**\** luigi fork that +**\** when warptangent is back we'll see how it goes on ringCT +**\** and make a more concrete decision as to the timing of the next fork +**\** iam6yearsold The hardfork will approximately take place at 13:00 UTC, so both US and Europe will probably be awake +**\** and Asia of course +**\** everyone will be awake +**\** even me +**\** hawaii will probably be asleep +**\** -P +**\** heh +**\** fwiw! +**\** wat +**\** lol +**\** we should also consider what else we should go in the next major version besides ringct (doesn't need to be discussed now) +**\** uh I meant UTC btw +**\** you muricans with AM/PM +**\** who got drunk and posted about a party in #monero-dev +**\** oh +**\** then america won't be up +**\** The db reorg seems like a good candidate. +**\** oh well +**\** smooth agreed +**\** east coast will right? +**\** sure ish +**\** You better set your alarm luigi +**\** :-P +**\** Surae is also going to be picking up MRL-6 in the summer +**\** he has some ideas about how to complete that +**\** MRL-6 is multisig? +**\** I will party hard if fork happens with no drama +**\** dEBRUYNE: no +**\** https//github.com/monero-project/research-lab/tree/master/publications/MRL-%-%Difficulty%Adjustment%Algorithms%in%Cryptocurrency%Protocols +**\** oh cool, thanks +**\** How do get cmake to tell you the commands it's running ? +**\** we have diff, we have db stuff, we have fee stuff +**\ moneromooo: I normally make VERBOSE=1 +**\** Thanks, I was trying V=1 +**\** I like my V=2 +**\** ok - any last things to add +**\** or can we call it? +**\** call it diff --git a/_posts/2016-03-22-monero-0.9.3-released.md b/_posts/2016-03-22-monero-0.9.3-released.md new file mode 100644 index 00000000..df993dd1 --- /dev/null +++ b/_posts/2016-03-22-monero-0.9.3-released.md @@ -0,0 +1,40 @@ +--- +layout: post +title: Monero 0.9.3 Released +summary: A point release of Monero Hydrogen Helix containing important bug fixes +tags: [releases] +author: Riccardo Spagni (fluffypony) +--- + +*March 22nd, 2016* + +## Summary of Changes + +This has urgent and important bug fixes to 0.9.2 *Hydrogen Helix* + +- Urgent bug fix for database corruption issues in 0.9.2 +- Official Windows 32-bit releases are back +- Updates to miniupnpc +- Sets v3 fork date for September, 2016 +- Fixes core tests and re-enables them +- Fixes a problem with --password-file not working in RPC mode + +## Official Download Links + +- [Windows, 64-bit](https://downloads.getmonero.org/monero.win.x64.v0-9-3-0.zip) +- [Windows, 32-bit](https://downloads.getmonero.org/monero.win.x86.v0-9-3-0.zip) +- [OS X, 64-bit](https://downloads.getmonero.org/monero.mac.x64.v0-9-3-0.tar.bz2) +- [Linux, 64-bit](https://downloads.getmonero.org/monero.linux.x64.v0-9-3-0.tar.bz2) +- [Linux, 32-bit](https://downloads.getmonero.org/monero.linux.x86.v0-9-3-0.tar.bz2) +- [Linux, ARM v7](https://downloads.getmonero.org/monero.linux.arm7.v0-9-3-0.tar.bz2) + +## Download Hashes + +If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes: + +- monero.win.x64.v0-9-3-0.zip, 246115b0da133e0203dc78d26bbc82e9b76a178939bff8d4541bf04a02a19854 +- monero.win.x86.v0-9-3-0.zip, 4663222a810ad854da1fc9d665e51252e61ddb1a8f69de3a31ad195386d445a2 +- monero.mac.x64.v0-9-3-0.tar.bz2, f471a420485413d5fcb1b19065a3b4e9a68c49596ddd6291787ad34121bad32c +- monero.linux.x64.v0-9-3-0.tar.bz2, 9e6747b69642389e98ca5f70cec7276f7af7156e5dce95409a8da7cccff5876e +- monero.linux.x86.v0-9-3-0.tar.bz2, 90c51c4a68f78ac2262a7b5a676f02d43ba7b9b6800b8b150d89980604c969f2 +- monero.linux.arm7.v0-9-3-0.tar.bz2, c312ba0810bf04ab2e28b61a50de2a83c1c614fd789bab4cacacb716134a7239 diff --git a/_posts/2016-04-02-monero-0.9.4-released.md b/_posts/2016-04-02-monero-0.9.4-released.md new file mode 100644 index 00000000..4d6a9919 --- /dev/null +++ b/_posts/2016-04-02-monero-0.9.4-released.md @@ -0,0 +1,38 @@ +--- +layout: post +title: Monero 0.9.4 Released +summary: A point release of Monero Hydrogen Helix containing important bug fixes +tags: [releases] +author: Riccardo Spagni (fluffypony) +--- + +*April 2nd, 2016* + +## Summary of Changes + +This has important bug fixes to 0.9.3 *Hydrogen Helix* + +- Fix remaining issues with coinbase transactions +- Removed ```connectivity_tool``` +- Switched to new Clang move diagnostics +- Added a new ```--generate-from-json``` flag to simplewallet to allow wallet creation from a JSON file +- Add a new and improved version of ```sweep_dust``` +- Various bug fixes to handle failures such as map resize failures and bad simplewallet exits + +## Official Download Links + +- [Windows, 64-bit](https://downloads.getmonero.org/monero.win.x64.v0-9-4-0.zip) +- [Windows, 32-bit](https://downloads.getmonero.org/monero.win.x86.v0-9-4-0.zip) +- [OS X, 64-bit](https://downloads.getmonero.org/monero.mac.x64.v0-9-4-0.tar.bz2) +- [Linux, 64-bit](https://downloads.getmonero.org/monero.linux.x64.v0-9-4-0.tar.bz2) +- [Linux, 32-bit](https://downloads.getmonero.org/monero.linux.x86.v0-9-4-0.tar.bz2) + +## Download Hashes + +If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes: + +- monero.win.x64.v0-9-4-0.zip, a6f171c942a2b75432573c3cea6ca3becb10769a08eaaea5cca080c92b8ee297 +- monero.win.x86.v0-9-4-0.zip, c9e4abc19c767ab570c2d0a9d504ba75d73eea26e7cf719a1260fdbb9469c250 +- monero.linux.x64.v0-9-4-0.tar.bz2, 0b3610c9b301ea14174ce700923a604909fa7cbd9335849112c9d6cfb07a1a43 +- monero.linux.x86.v0-9-4-0.tar.bz2, c070125bb885c5b887d3adce866e9bb941ed790485ef34444e62e0881fe8852a +- monero.mac.x64.v0-9-4-0.tar.bz2, ded52162d34d5a726b53ffd14ebbf02388d9b396f3f4e278a4755e5286b1aeab \ No newline at end of file diff --git a/_posts/2016-04-24-overview-and-logs-for-the-dev-meeting-held-on-2016-04-24.md b/_posts/2016-04-24-overview-and-logs-for-the-dev-meeting-held-on-2016-04-24.md new file mode 100644 index 00000000..3296068c --- /dev/null +++ b/_posts/2016-04-24-overview-and-logs-for-the-dev-meeting-held-on-2016-04-24.md @@ -0,0 +1,219 @@ +--- +layout: post +title: Overview and Logs for the Dev Meeting Held on 2016-04-24 +summary: A review and discussion of open PRs, moving forward with Ring CT +tags: [dev diaries, core, crypto] +author: dEBRUYNE / fluffypony +--- + +*April 24th, 2016* + +# Logs + +**\** hey what's on our agenda for today anyway +**\** slideshow from fluffypony's trip to Asia? +**\** we could do that :D +**\** hyc: More seriously, I suppose some Ring CT stuff + something about the performance branch +**\** lol +**\** hyc: Plus I think there are still some PRs open for review +**\** sounds good. looking at NobleSir's DB schema, doesn't seem like there's much new needed on the DB side of things +**\** hyc, fluffypony: I could make a list of which PRs are still open for review if you want? +**\** 13 open right now +**\** all right +**\** moneromooo already reviewed PR#806 +**\** Oh yeah this is easier to spot -> https://github.com/monero-project/bitmonero/pulls +**\** :-P +**\** yep +**\** smooth and moneromooo had a little chat about 818 & 819 earlier today +**\** I've browsed thru them but frankly don't know enough about how things work to know their implications +**\** I felt like that abour your/warp's DB perf branch :P +**\** ;) +**\** looking at git history I'd guess tewinget or NoodleDoodle would have breezed thru them +**\** hokay +**\** t -1 hour +**\** t -5 min +**\** hello +**\** hi +**\** hola +**\** bonjour +**\** bonjour +**\** Comment allez-vous ? +**\** la réunion d'aujourd'hui aura lieu en français +**\** laissez les bon temps rouler +**\** lol +**\** Konnichiwa +**\** ok so +**\** welcome to the dev meeting +**\** after a brief intermission we're back on every 2 weeks +**\** I'm here but not really +**\** I've been trying to keep up whilst travelling, but there's some backlog I didn't read +**\** I think before we discuss #805 and the performance PR, let's just touch base on the smaller ones +**\** #810, #814, #818, all seem to have been reviewed and are ready for merge +**\** smooth had reservations about 810. +**\** Or hyc. Or both. +**\** smooth / hyc: any new thoughts beyond the one comment on the PR? +**\** both I think, but I don't remember smooth's comments +**\** I think it was just extra complexity htat might not be worth it. +**\** 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 +**\** the pool code ought to just call getblockcount in that case, which executes in 0ms +**\** smooth commented on #810 -> https://github.com/monero-project/bitmonero/pull/810 +**\* DaveyJones**: quotes deBRUYNE from yesterday : dEBRUYNE pages othe, NoodleDoodle, smooth, tewinget, binaryFate +**\** so then the pool code is bad, right ? +**\** yeah, in my perspective anyway +**\** 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? +**\** i added a comment to 810 +**\** ^ His dad commented in the thread +**\** xmrpromotions: they're already speaking to us, and we've let them know +**\** but let's stick to -dev decisions for now +**\** 818 i think needs review by a cryptographer before we release that feature +**\** agreed +**\** hyc> the pool code ought to just call getblockcount in that case <= this is incorrect as we discussed before, but not relevant to 810 +**\** getinfo returns top hash. +**\** And seems fairly lightweight. +**\** 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 +**\** Maybe PCFiL can test. He reported high CPU use when there were like 15 txes in the pool, and calming down at ~3. +**\** Or I could test it actually, just curl that URI. +**\** maybe we should look at why it takes so long then. when happens when there are 500? +**\** fair enough, re: getinfo. still, it seems like this cache should be unnecessary +**\** we can pack a bunch of transactions into testnet's mempool to see +**\** next topic? +**\** sounds like a good plan. perf optimizations should always have before/after metrics. +**\** 811 / 812 / 813, any thoughts or objections on them ? +**\** 811 seems pretty straightforward +**\** tho moneromooo mentioned that the test in question never actually gets run +**\** anyway, compiling unit tests is broken without it, so 811 needs to go in +**\** ok +**\** 812 seems fine too +**\** 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 +**\** ok - has anyone tested 815? +**\** Well, I did :) +**\** lol +**\** 816 is also pretty straightforward +**\** I'll review 817 later when I'm merging +**\** and 819 is obvious +**\** 818 won't apply once 816 is merged (duplicate -8 new error code), I'll update once this is done. +**\** yeah 816 looks fine +**\** I wouldn't bother yet - wait until there's been an MRL review on 818, moneromooo +**\** OK +**\** 810 I'll hold off on and let it bounce around, final decision at the next meeting if not before +**\** ok so 806, the PR that fixes issue 805 - any final thoughts on it or can I merge? +**\** works for me ;) +**\** Seems fine. I didn' try it though. +**\** it will make starting up a new wallet less painful for new users +**\** 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? +**\** Leave it out for now. +**\** k +**\** so then performance +**\** are we going to merge it, or leave it for 0.10.0 ? +**\** conclusion - migrating DB schema in-place is much slower than just export/reimport from scratch +**\** hyc: yeah I know, the conversion tool was always horrendously slow by comparison +**\** im not sure that invalidates it +**\** but in-place migration has its place +**\** eg. when running as a service +**\** easy of use matters, and if advanced users want to do it faster they can use th etools +**\** agreed +**\** sync from scratch is an option too, if they dont care about bandwidth +**\** I guess the overriding factor here is that we suck at communicating with the end users that are running nodes +**\** the fork taught me that, at any rate, so we have to assume people won't be reading release notes +**\** ok. but are they going to notice that their newly restarted server isn't talking to anyone on the network for 1+ hour? +**\** I don't think they'll care if it's an unattended server +**\** 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 +**\** ok +**\** i guess the use case to consider is shapeshift +**\** yeah +**\** RPC calls that care about this do return busy. +**\** If not, file a bug with details. +**\** moneromooo: a conversion will lock almost everything out, though ? +**\** except I guess blindly broadcasting transactions +**\** Oh, nevermind. +**\** even then it probably has to verify them +**\** yeah so I think the entire RPC interface has to error with a status +**\** I'm guessing the RPC server will not be up yet if it's converting the db. +**\** yeah, the conversion is firing up from db open +**\** I don't think anything else is up yet +**\** ah point +**\** whats the problem with refusing to start until they do something with their db? +**\** i mean error out at startup, no conversion +**\** you can either delete/rename it (and therefore resync) or convert it +**\** smooth: because in background mode / windows service mode you won't know that it's dying +**\** you'll know its not working, there must be some way to indicate a reason +**\** so practically: I have Bitcoin and Monero on a Windows node +**\** maybe leave a message file behind and the cli can report the message +**\** system("xmessage \"help\"") +**\** and at some point the Bitcoin DB got corrupted (multiple times) +**\** I have the service set to restart on fail, and eventually restart the whole machine +**\** so it was restarting the machine every 15 minutes, and since I was only using the Monero node on it I had no idea +**\** right, so the overarching question is monero's philosophy on un-managed nodes +**\** (perhaps) +**\** 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 +**\** if anyone is doing a health check they're gonig to wonder why it's not responding +**\** Aside from that I'd feel more comfortable if someone besides me has tested the current branch with migration happening +**\** I will +**\** we know the perf code itself, not counting the migrate bit, is working fine +**\** hyc: if I start it up with a current blockchain it'll just convert, right? +**\** yep +**\** ok I'll give it a spin on a few devices +**\** so then I guess the final question is whether this goes into 0.9.x or 0.10.0 ? +**\** perf code itself i run on multiple nodes, from 32 bit arm to 64bit x86 - works absolutely flaweless here +**\** peanut gallery here - makes more sense to call it 0.9.x . big number change seems appropriate for consensus mechanism changes (i.e., ringct) +**\** 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. +**\** gingeropolous: I don't disagree, I'm also leaning towards it being a point release +**\** Also if there is down time for the nodes during conversion a more gradual approach in 0.9.x is preferable +**\** that maintains the idea that all 0.9.x are compatible, and not compatible for 0.10.x +**\** well with a 0.9.x release everyone won't update at once +**\** well, they're compatible on the wire, at least +**\** 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" +**\** yeah +**\** so might as well use that precedence earlier rather than later. +**\** ok I think that's it from my side - does anyone have anything they want to ask / add / discuss ? +**\** 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 +**\** perhaps a bit about ring CT? Though hyc kind of already said something about that before the discussion +**\** more specifically -> \ sounds good. looking at NobleSir's DB schema, doesn't seem like there's much new needed on the DB side of things +**\** smooth: can definitely make that clear in the release +**\** oh and fluffypony, perhaps a bit about the 0MQ stuff as well? +**\** hyc is better suited to update us on RingCT +**\** 0mq is kind of a big issue i think, maybe leave for the next meeting +**\** Is omq the only/primary reason why work is still being done on master instead of dev branch? +**\** thats part of the whole issue of how the repo is organized and the workflow +**\** yeah I think that's a discussion we can have at the next meeting +**\** sorry I've got very little intelligent to say about ringct +**\** i've compiled the code and run the test successfully +**\** but I don't really think i'm in position to merge it, don't understand the pieces +**\** I'm better acquainted with monero in general, though less with the db side. +**\** And IANAC. +**\** you are not a cat ? +**\** obviously, you're a moo! +**\** That is true. +**\** Maybe we can get riddick on the job. +**\** that's riddick-ulous +**\** OK then. No cats. +**\** 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. +**\** hyc, moneromooo: Perhaps the two of you could collaborate with NobleSir on it +**\** 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. +**\** just throw it out +**\** 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) +**\** no ringct is no prerequesite for multisig +**\** and no bitshares doesnt need it +**\** bitsquare +**\** lol bitshares +**\** notsquares +**\** all they need is some gui changes like payment id support or alternatively its enough to use integrated addresses instead +**\** and then they need support for the spendkey stuff to proof a payment, thats it +**\** Multisig happens as a byproduct of ringct withou much extra work though AIUI. +**\** yeah +**\** ok thank you. maybe I read about dev priorities and misinterpreted a comment about ringct coming before multi sig +**\** 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 +**\** 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 +**\** transfers from another source. +**\** incoming\_transfers shows the raw outputs. So you need to subtract those coming back from the ones leaving with the same txid. +**\** But I'll add RPC for the others in the near future. +**\** moneromooo can you be more explicit, what do you intend to add? +**\** 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 +**\** RPC for getting the same info that show\_transfers displays. +**\** ok +**\** ^that would solve all my issues and i'd love you forever. in a manly way. +**\** othe: afaik Bitsquare needs it if you want XMR/fiat markets +**\** altcoins are the fiat markets in bitsquares atm i think +**\** 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. +**\** 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 +**\** correct diff --git a/_posts/2016-05-08-logs-for-the-kovri-dev-meeting-held-on-2016-05-08.md b/_posts/2016-05-08-logs-for-the-kovri-dev-meeting-held-on-2016-05-08.md new file mode 100644 index 00000000..4a758fd9 --- /dev/null +++ b/_posts/2016-05-08-logs-for-the-kovri-dev-meeting-held-on-2016-05-08.md @@ -0,0 +1,117 @@ +--- +layout: post +title: Logs for the Kovri Dev Meeting Held on 2016-05-08 +summary: Mac / BSD support moving forward +tags: [dev diaries, i2p, crypto] +author: dEBRUYNE / fluffypony +--- + +*May 8th, 2016* + +# Logs + +**\** Hi fluffypony +**\** hiiii +**\** was just about to check if you're around :) +**\** Hi everyone, I think meeting-bot is still online +**\** yes it is +**\** coming through loud and clear on this side +**\* anonimal** reading backlog +**\** Hi moneromoo. +**\** Hi psi, uncrustify configs? Can you explain? +**\** uncrustify is a code styler for c/c++ +**\** I've never heard of it, plz tell me more psi? +**\** it auto formats the code +**\* psi** gets relevant links +**\** https://github.com/uncrustify/uncrustify +**\** I know that psi, but why for *.conf? +**\** i don;t understand? +**\** what about *.conf? +**\** oh anonimal +**\** not for *.conf +**\** he means conf file for uncrustify matching our coding style +**\** damn lag +**\* psi** waits to catch up +**\** fluffypony: right +**\* anonimal** back +**\** wb +**\** To answer the question, no I don't have an uncrustify config for kovri. +**\** Just a simple .vimrc. +**\** I can take a look at creating a config after #174 is resolved. +**\** fluffypony: I saw your comment in #56, what system are you runnning? +**\** anonimal: Ubuntu 14.04 +**\** and there's no Boost 1.59 / 1.60 available +**\** but that little hack worked +**\** 1.54 should work though +**\* anonimal** triple checks +**\** I can't use 1.54 +**\** incompatible with Monero +**\** monero needs .56 or higher ? +**\** .55 or higher +**\** kk +**\** so basically .59 or higher if you want both +**\** 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 +**\** kk +**\** :\ +**\* 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 +**\** #monero-dev, FYI, our meetings have always been more organized, on-point, and I've almost always been prepared. +**\** This one caught me off guard. +**\** (last minute suggestion by fluffypony) +**\** Sorry for the wait. +**\** don't stress, ours are always by the seat of our pants +**\* anonimal** opening tickets +**\** Hmf, I need to work with the bsd a bit more before posting. +**\** Anyway, https://github.com/monero-project/kovri/issues/175 +**\** I'm only sitting with this again since I left off < 24 hours or so ago so, +**\** I haven't drawn any conclusions yet. +**\** Has anyone seen this before? #monero-dev? +**\* fluffypony** clicks +**\** moneromooo: seen anything like that before ? +**\** "Undefined symbols for architecture x86_64" +**\** The usual 'Undefined symbols for architecture x86_64' has been an osx complaint on this machine in the past. +**\** Not as such. I've seen plenty of really annoying linking issues though. +**\** this is gcc on OS X tho, right ? +**\** fluffypony: Yes. +**\** maybe we're chasing our tails on that +**\** I don't have time to deal with clang. If we want multi-distro builds, I need to streamline our process. +**\** for macosx, clang won't build because it doesn't like the things I did for the reseed rewrite and, +**\** I don't have time to keep-up with llvm development. +**\** So, thoughts? +**\** rewrite everything in C :-P +**\** lol +**\** ok my suggestion is that we eschew OS X / BSD compatibility for the moment +**\** until we can fix Clang support +**\** Thanks moneromoo. I'm glad this isn't just a kovri thing. +**\** rather than trying to fudge it +**\** Well that's the problem, this won't be the only issue. +**\** yeah I know +**\** And I'll end up wasting time juggling compilers instead of working on other things. +**\** I mean that can be a later piece of work +**\** let's focus on getting it working on one Linux and Windows, where we're running gcc and it's fine +**\** fluffypony: what part will be the later piece of work? +**\** anonimal: fixing Clang incompatibilities +**\** I don't use OSX btw, so kinda ignore what I said above. +**\** Ok sounds great, I'll focus on linux/win building. +**\** Should we remove osx/bsd build instructions from BUILDING.md? +**\** Or I'll just open the bsd ticket and maybe someone will see it? +**\** 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 +**\** kk +**\** Ok, I'll add the note. +**\** Any other questions/comments on #175? +**\** no not yet +**\** I mean no not atm, lol +**\** Ok, I'll add a note in #174 about what we discussed. +**\** And part 1) in #174, apparently there is an env variable I can set to get it to work. +**\** Not the first travis issue I've had to deal with. +**\** Oh well, they are growing quite nicely IMHO. +**\** travis issues are growing quite nicely ? +**\** lol, yes, and I meant their project as a whole. +**\** lol +**\** Ok, hour is up. Anything else pressing? +**\** I don't think so - this was kinda an interim meeting because Kovri's was last week +**\** so this brings them into line +**\** next one on May 22nd, same time +**\** Ok, I'll mark the calendar. +**\** Thanks everyone. +**\** thank you \ No newline at end of file diff --git a/_posts/2016-05-08-overview-and-logs-for-the-dev-meeting-held-on-2016-05-08.md b/_posts/2016-05-08-overview-and-logs-for-the-dev-meeting-held-on-2016-05-08.md new file mode 100644 index 00000000..925899ea --- /dev/null +++ b/_posts/2016-05-08-overview-and-logs-for-the-dev-meeting-held-on-2016-05-08.md @@ -0,0 +1,127 @@ +--- +layout: post +title: Overview and Logs for the Dev Meeting Held on 2016-05-08 +summary: Clarification on ringCT next steps, 0MQ, discussion of open PRs +tags: [dev diaries, core, crypto] +author: dEBRUYNE / fluffypony +--- + +*May 8th, 2016* + +# Logs + +**\** hyc, moneromooo, smooth, luigi1111w, luigi1112, luigi1114, ArticMine, NoodleDoodle, tewinget: meeting starting +**\** hey +**\** and othe +**\** just waiting for the relay to come up +**\** there we go +**\** Not here +**\** hello, and welcome to the 75th annual hunger games +**\** crap, luigi1112's not here. +**\** luigi1112 is literally a ghost +**\** ok so we have a couple of PRs hanging around +**\** is that why there are always 2-3 of him? +**\** bigreddmachine: exactly :) +**\** Hoooooo can say +**\** I've reviewed #831 and it's ready for merge +**\** same with 827 +**\** has anyone had further thoughts on 818 or are we ok with merging that functionality in its current form ? +**\** bearing in mind that this will haunt us basically forever +**\** and we pretty much can't change it ever again +**\** no pressure or anything +**\** (just kidding, we can definitely version it) +**\* fluffypony** waaaaaits +**\** I haven't looked at 818, it's a crypto question still +**\** yeah I think shen looked at it +**\** ok we'll put a peg on that pending input from moneromooo and smooth +**\** What are shen's thoughts on 818? +**\** {-shen} I took a glance at it, but if desired I can look deeper +**\** {-shen} at glance looked ok +**\** 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 +**\** {-shen} ok I will budget some time today or tomorrow +**\** ok cool +**\** then with the performance branch (794) we found an issue with the initial migration, messed up a global index on some txos +**\** Is that the sig thing? +**\** this appears to be fixed with the new / faster migration +**\** luigi1112: yes +**\** Ok +**\** 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 +**\** ok so performance is ready for merge, unless anyone has an objection +**\** sounds good to me +**\** then 810, I'm still unclear as to whether we're dropping that idea or we're merging it +**\** given the increased locking requirements I'm against it. +**\** ok +**\** and as said before, I think fixing the pool code to use cheaper queries is better +**\** I'm onboard with that +**\** so now that we're getting the performance branch out the way +**\** the next two major things on the radar are 0MQ and ringct +**\** 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 +**\** I'll wait for input from moneromooo on that +**\** and then ringct - hyc, did you say you were going to do some of that? I can't even remember +**\** I looked into it but no, moneromooo should take lead +**\** ok +**\** shen +**\** I can do whatever DB additions are needed +**\** what's the status of your implementation code ? +**\** perhaps hyc can assist with the DB stuff +**\** oh he was quicker than me already +**\** {-shen} Should be ready for test net at least +**\** ok +**\** it's time for a testnet fork anyway, so we can work towards that +**\** basically everything else requires moneromooo and smooth, so we can put a peg in them till next meeting +**\** speaking of which +**\** next one on the 22nd +**\** perhaps they will show up within the next 30 minutes :-P Just page them 3 times! +**\** hah hah +**\** Btw fluffypony, will the performance branch be used for a new point release? +**\** dEBRUYNE: yes +**\** All right +**\** Btw, if moneromooo and smooth show up later tonight and have a chat about 0MQ we could just add that to the dev logs +**\** ok +**\** q: for the next point release... will it include arm7 binaries? 0.9.4 does not +**\** it should +**\** 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? +**\** fluffypony: I'll think about that +**\** bigreddmachine: sync of irrelevant blocks, only needed to use hashes +**\ kk, thats what i figured +**\** now just syncing block headers? +**\** up to a given refresh height it only syncs hashes +**\** moneromooo: we can carry on chatting about the bits you missed after the kovri meeting, if that's ok ? +**\** Sure. +**\** ok back to the Monero side +**\** moneromooo: have you had a chance to read the meeting backlog ? +**\** I did. +**\** ok - thoughts on 0MQ / dev branch? +**\** if you have the dev branch on your fork we can nuke it and reset +**\** I think you can nuke the dev branch. +**\** As for 0mq... whenever I get to start it, it's going to be a largeish amount of work at once I think. +**\** ok +**\** I happen to be not super motivated to code these days, after day job spent debugging stuff. +**\** sometimes you gotta take a break and work on fun stuff +**\** perhaps Ring CT qualifies as fun stuff, perhaps not :-P +**\** What's more important btw, 0mq or ringct ? +**\** I would think ringct +**\** I'd say Ring CT too +**\** Iirc ring CT needs to be some time on testnet too anyway +**\** And we can ask the "did nobody test this ?" peanut gallery in to test it :D +**\** awesome +**\** 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. +**\** That's probably not too much work. +**\** lol moneromooo +**\** Btw moneromooo, in case you hadn't read it yet hyc can assist you with the DB stuff +**\** More specifically -> \ I can do whatever DB additions are needed +**\** I saw that. It's good so I don't break it all. +**\** Btw fluffypony, I forgot to ask earlier. Not sure if he is here, but any plans to opensource NoodleDoodle's trezor code soon^tm? +**\** you'd have to ask NoodleDoodle that +**\** all right, perhaps he responds :-P +**\** 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). +**\** 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 +**\** gather email addresses and setup a standardized mail. +**\** ^ fluffypony +**\** Changing the pool code to call getinfo and check top hash would also drop CPU usage a lot. +**\** shen, see above ^^ +**\** (before the pool code stuff) +**\** {-shen} ok +**\** {-shen} good point +**\** moneromooo: I see, well then it's more up to the pool ops instead of the contributors/developers imo +**\** Up to whoever gets his butt in gear to do it, as usual :D \ No newline at end of file diff --git a/_posts/2016-05-22-logs-for-the-kovri-dev-meeting-held-on-2016-05-22.md b/_posts/2016-05-22-logs-for-the-kovri-dev-meeting-held-on-2016-05-22.md new file mode 100644 index 00000000..45d79ea2 --- /dev/null +++ b/_posts/2016-05-22-logs-for-the-kovri-dev-meeting-held-on-2016-05-22.md @@ -0,0 +1,202 @@ +--- +layout: post +title: Logs for the Kovri Dev Meeting Held on 2016-05-22 +summary: GNU Social status, Kovri website, i2p StackExchange, Coverity for Kovri +tags: [dev diaries, i2p, crypto] +author: dEBRUYNE / fluffypony +--- + +*May 22nd, 2016* + +# Logs + +**\** ok starting the meeting relay for the Kovri meeting +**\ [anonimal]** Hello. +**\** anonimal: all yours :) +**\ {-anonimal}** From https://github.com/monero-project/kovri/issues/177 +**\ {-anonimal}** Proposed meeting items: +**\ {-anonimal}** 17:00 (UTC) +**\ {-anonimal}** 1. Review assigned open tickets: status, code ideas (if applicable), etc. +**\ {-anonimal}** 2. Any additional meeting items +**\ {-anonimal}** 3. Confirm next meeting date/time +**\ {-anonimal}** Starting with 1., as discussed in private with fluffypony, let's tackle https://github.com/monero-project/kovri/issues/assigned/fluffypony +**\** hokay - should we do them one at a time ? +**\ [anonimal]** Sure, #105. +**\** sec, just opening it up +**\ [anonimal]** I'm more curious about status updates and if we'll pursue some of these ideas. +**\** ok 107 +**\** I asked dEBRUYNE and the rest of the social media guys about that in January last +**\** dEBRUYNE: have you guys looked at that at all ? +**\** I think xmrpromotions was handling that +**\ [anonimal]** JFTR: s/107/105/ +**\** I honestly cannot remember you asking me :-P +**\* fluffypony** has the IRC logs to prove it :-P +**\** regardless, I think xmrpromotions was handling most of that :-P +**\** ok - xmrpromotions, did you have a chance to look at GNU Social ? +**\** I am looking at GNU social right now +**\** I am sorry but I have not +**\ [anonimal]** Can I ask everone, candidly, what they think of the idea? +**\ [anonimal]** Is it something worth pursuing? +**\** My initial instinct is yes +**\** tbh I had hardly heard about GNU Social till you brought it up +**\** Are there more details I can read about it? https://github.com/monero-project/kovri/issues/105 +**\** but I think in terms of providing a more freedom-friendly social presence it's advantageous +**\** plus if we can spend the energy maintaining a Facebook page we can definitely justify this... :-P +**\** Way better than a Facebook page +**\** There are many who dislike the corporate centralization of Facebook in social media +**\ [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... +**\ [anonimal]** xmrpromortions: For technical details, https://gnu.io/social/ +**\ [anonimal]** lol, sorry, not auto-completion here +**\ [anonimal]** Yes, recent news items re: censorship just get crazier and crazier. +**\** 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 +**\ [anonimal]** And the social monopolies are finally showing their true colors. +**\ [anonimal]** Ok, so #105 is on hold pending xmrpromotions' review? +**\** yup +**\ [anonimal]** Ok, next ticket. +**\** ok +**\ [anonimal]** #46 +**\ [anonimal]** The Kovri website. +**\** #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 ? +**\** anonimal: and your input on this would be appreciated too +**\** I think the relay is wonky +**\ [anonimal]** What's the time-cost in terms of managing two sites? +**\ [anonimal]** Yes, missed almost everything it looks like. +**\** anonimal: it's mostly just the initial work, after that I mostly go hands-off and let the community run with the content +**\ [anonimal]** Can anyone read this? +**\ [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? +**\** that would be my recommendation +**\** we start with a sub-section on the Monero site +**\** and forward the kovri site through to it +**\** if we feel the need later on we can create a separate site on its own +**\ [anonimal]** Ok, sounds good to me. Anyone else? +**\** 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 +**\** It seems like a judgement call to me. Either plan sounds reasonable +**\** restarting meeting bot +**\** in fact, if you want to write up some content for me I'll do it on the plane on Tuesday +**\** in fact, I can probably take most of it from the readme +**\** in fact, if I say in fact again I'll summon the in-fact-bot +**\ [anonimal]** Ok, ideas for content? I can blabber but ideas are welcome. +**\ [anonimal]** ping in-fact-bot +**\** 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? +**\** xmrpromotions: we'd have to run it past zzz, at the very least +**\ [fluffypony]** zzz ^^ +**\** sorry for off topic idea. I can table it for later if appropriate +**\ no I think it's an excellent idea, if the i2p community at large is interested then now is definitely the time +**\ [anonimal]** From what I've seen, alot of great ideas come and go through #i2p-dev but it always comes down to resources. +**\ [anonimal]** I think we'd all love that but someone will have to take the initiative. +**\** I will take the initiative on that +**\ [anonimal]** AFAICT all i2p-related dev (including Kovri) is in a bit of a dry spell so, priorities. +**\ [anonimal]** I like the idea though. +**\** anonimal: the advantage is that we can basically get everyone who's committed to the Monero proposal to also back an i2p proposal +**\** but now is the time to do so +**\** whilst everyone's excited +**\ [anonimal]** Ok, so what's the next step? +**\** 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 +**\** 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 +**\** next step on the StackExchange proposal is to wait for feedback from zzz +**\** sounds good. I wont act until I hear confirmation that zzz is ready to proceed +**\ [anonimal]** I dropped a line in #i2p-dev. +**\ [anonimal]** We'll see who bites. +**\ [anonimal]** Ok, so #46: 1) create content 2) On Tuesday, fluffypony will put something together 3) ETA after that? +**\** ok next ticket ? +**\** oh +**\** once it's pushed to the repo it goes live +**\** there's no ETA beyond that +**\** or no steps beyond pulling it and rebuilding the Jekyll site +**\ [anonimal]** Ok great, I'll paste a note in ticket. +**\ [anonimal]** Moving on, #43. +**\** ok - can we just use the Monero addresses, or do we want separate addresses? +**\ [anonimal]** I'm fine with Monero addresses. +**\** ok then they're avialable here, anonimal: http://donate.getmonero.org +**\** *available +**\ [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? +**\ [anonimal]** Or no? +**\** ffs is prolly more efficient +**\** FFS is better than direct donations +**\** and it's generally more trustworthy because you raise funds for a specific piece of work, and then get paid out on milestones +**\ [anonimal]** Ok, we should put a note in README directing to FFS and donation page or just FFS? +**\** the readme just needs the donation page +**\** if we get large donations we redistribute them to active FFS proposals anyway +**\ [anonimal]** fluffypony: Ok, would you like to add that with your wording to the README? Or should I? +**\** anonimal: I have to pack tomorrow, and have a bunch of things to do, so if you could that would be appreciated +**\ [anonimal]** Ok +**\ [anonimal]** Moving on, #27 +**\** 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 +**\ [anonimal]** Ok, I'll paste that note. +**\ [anonimal]** Onward to #20. +**\** 20 - I can try Coverity again, let's see if it gives me the same issue +**\** I've not heard from them despite opening tickets etc. +**\ [anonimal]** Links? Maybe I can comment/ping them too. +**\** anonimal: screenshots and process I followed is in that ticket +**\** issue I mean +**\ [anonimal]** Ok, well, it may come down to a phone call or two. +**\ [anonimal]** Is that something you'd be willing to do? +**\ [anonimal]** If not, we can skip the integration and try to do it manually. +**\** sure +**\ [anonimal]** Ok, next. #90 is not assigned to you but I remember you said you would assign yourself. +**\** one second just checking coverity +**\ [anonimal]** Is #90 still of interest? +**\** oooooh it works +**\** they must've fixed it and just not let us know +**\** anonimal: I'll PM you with coverity details +**\ [anonimal]** Fantastic! +**\ [anonimal]** Yay, great. This should be interesting. +**\** will I break things if I create a bridge by connecting simplewallet to the daemon over an i2p tunnel? +**\** doubtful +**\ [anonimal]** fluffypony: #90? +**\** 90 will happen automagically when our GitLab mirror is up +**\** it'll have clearnet / Tor / i2p mirrors +**\ [anonimal]** Ok then. I've missed any discussions about that in the past, is there an ETA? +**\** not at the moment - it's one of those "on the list" things, I lack the time to knuckle down and do it +**\** we need a devops team :-P +**\ [anonimal]** Indeed. Ok, I'll add a note in ticket. +**\ [anonimal]** To whom should we assign #90 then? +**\** me +**\ [anonimal]** Ok, will do. +**\ [anonimal]** Yay, hour long of fluffypony tickets finally tackled! I'm glad we finally had the time. Any other comments them? +**\** none from my side +**\ [anonimal]** So, since this was the "fluffypony show" meeting, for time-sake I'll sum up my part of 1. with one line: +**\ [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 +**\ [anonimal]** So, that's that for now, I'm sure more code talk can be at the next meeting. +**\ [anonimal]** Any additional meeting items (quickly)? +**\** nothing more from me +**\ [anonimal]** Re: StackExchange, what tl;dr can I give to #i2p-dev? +**\ [anonimal]** Aside from pointing a link to the meeting log. +**\ [anonimal]** (I've been out of the loop re: the initiative) +**\** Just say that we are willing to cross promote it to XMR community and expect it to reach the commitment stage fairly fasy +**\** fast +**\ [fluffypony]** just that it's a proposal to have an i2p-specific StackExchange area +**\ [anonimal]** So, what should we expect from them? +**\** from there the I2P and XMR communities can help each other ensure both site reach beta +**\** Hard for me to make an ETA on that. End result would be an I2P site similar to what Tor has now +**\ [anonimal]** fluffypony: should we end meeting? +**\ [anonimal]** (or has it ended?) +**\ [fluffypony]** yes I think so +**\ [fluffypony]** I'll take the bot down +**\** We need I2P experts to appear during the proposal stage once created to ask good questions +**\** early questions attract a lot more votes and rise to the top, so quality matters +**\ [anonimal]** Ok, I'll chat in #monero-dev. +**\ {-anonimal}** * thinking +**\ {-anonimal}** xmrpromotions: I can commit to both pages. How many I2P 'experts' would need to commit? +**\** well we need 40 good questions. each person can only ask 5 +**\** well before commitment it's just the voting section +**\** Our initial 40 questions will help with SEO after launch +**\** where we need not only good questions asked, but also good questions have to get 10 votes each +**\** Yes I mean we need to create quality questions to vote on +**\** If someone wants to create a list of 40 great questions that would be perfect +**\ {-anonimal}** 40 great I2P questions, I could do that. +**\** they still have to post them though +**\** 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 +**\** we can find 8 people to post 5 questions each easily +**\** yup +**\** yeah, then we need a bunch of people to upvote :) +**\** 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) +**\** which will give them more than enough for the 200 rep area 51 cutoff for the SE 100 rep account association bonus +**\** strategyyyy +**\** 5q with 10 votes each will earn 5 rep per vote +**\ {-anonimal}** Ok, sounds great. Right now, I need to finish post-meeting wrap-up, take a break, get my brain in order and bbl. +**\** ok cool +**\** 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 +**\** thanks everyone. have a great weekend +**\** cheers \ No newline at end of file diff --git a/_posts/2016-05-22-overview-and-logs-for-the-dev-meeting-held-on-2016-05-22.md b/_posts/2016-05-22-overview-and-logs-for-the-dev-meeting-held-on-2016-05-22.md new file mode 100644 index 00000000..1cc7e5dc --- /dev/null +++ b/_posts/2016-05-22-overview-and-logs-for-the-dev-meeting-held-on-2016-05-22.md @@ -0,0 +1,129 @@ +--- +layout: post +title: Overview and Logs for the Dev Meeting Held on 2016-05-22 +summary: Decisions on PRs still open, performance branch conversion problems, consolidating dev documentation on the GH wiki +tags: [dev diaries, core, crypto] +author: dEBRUYNE / fluffypony +--- + +*May 22nd, 2016* + +# Logs + +**\** ok +**\** das meeting +**\** has started +**\** heh heh +**\** let the fun begin +**\** hyc, smooth, moneromooo, dEBRUYNE, gingeropolous, luigi1112, luigi1114, anyone I've missed +**\** hokay so +**\** first up: for those that haven't done so, please commit to the StackExchange proposal: http://area51.stackexchange.com/proposals/98617/monero +**\** oooh i get pinged for dev meetings? :) +**\** and earn rep: https://forum.getmonero.org/20/general-discussion/2542/stack-exchange-commitment-requirements +**\** you're basically just committing to asking / answering a total of 10 questions over 3 months +**\** also it would be advantageous if you have over 200 rep on another StackExchange site, as xmrpromotions said +**\** I earned over 200 rep on bitcoin.stackexchange by answering like 4 questions, so it's not hard +**\** ok maybe like 6 questions, but still, not hard +**\** I think getting 200 committers in total will be easy, but having 100 committers with sufficient rep might be a little harder +**\** ok so +**\** PRs +**\** over the last couple of weeks we've merged a few PRs +**\** obviously +**\** the biggest one being the performance branch +**\** which was what warptangent was working on before he passed away +**\** and which was completed by hyc and everyone else +**\* dEBRUYNE** pages tewinget, NoodleDoodle, ArticMine, othe +**\** probably missed someone +**\** we are seeing some latent issues with auto-conversions, or that appear to be coming from the auto-conversion +**\** if users hit issues with that the fastest route is for them to sync from scratch +**\** iirc smooth has a broken conversion that we can use to analyse the issue +**\** 810 and 775 are dangling +**\** moneromooo: do you want those to stay open at present ? +**\** 810 might be cancelled, not sure. +**\** ok +**\** 775 is ready AFAIK., +**\** ok will test it +**\** 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 +**\** on that note, RingCT seems to be pushing ahead quite nicely +**\** moneromooo: how's it looking from your side ? +**\** I'm not a cryptographer, so I got no clue really :P +**\** hah hah +**\** Once I figure out what goes where, it's just code after that. +**\** I know you're waiting for input from shen, but is it starting to make a bit of sense ? +**\** Though a lot of it I think +**\** kk +**\** Mot yet, but I've not spent a lot of time on it today (and yesterday I was out). +**\** alright +**\** 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? +**\** then next weekend I'll be at Bitcoin in Use in Arnhem, Netherlands +**\** How will you know it's an integrated address of yours in the first place ? +**\** and there will be several other Monero-er-ains there as well +**\** including some devs, most notably hyc +**\** a few ppl told me they want to meet you there:) +**\** oh it's the meeting, sorry. I'll wait to discuss that later moneromooo +**\** if anyone else is going to be there please let me know, we can do a Monero supper on the Saturday or something +**\** next up is a chat about documentation +**\** wallet42 has raised the idea of opening up the wiki on Github +**\** https://twitter.com/Falkvinge/status/731833882102910977 wants to meet you too +**\** the advantages of this is that it keeps the documentation close to the code +**\** and you can PR to the wiki or (I think) edit it inline +**\** xmrpromotions: oh neat +**\** in fact, the wiki creates a .wiki.git project that's invisible-ish +**\** so it makes syncing to GitLab easy (setting up a GitLab mirror is on the list of things to do) +**\** downside is that you can't edit it anonymously, although creating a GH account is trivial +**\** and the other downside is that we have tons of scattered documentation right now +**\** 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 +**\** ^ I don't mind putting part of it together +**\** so the Monero wikia has to be shuttered and that info moved over +**\** There is information all over BCT +**\** we could put the guides from Moneroexamples over there too, but he doesn't necessarily have to shutdown his "source" imo +**\** 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 +**\** then the wiki becomes a primary source of info +**\** dEBRUYNE: yeah we could do the same thing with MoneroExamples +**\** just have a plugin that grabs it from his repos and formats it +**\** if anyone has an issue with this speak now or forever hold your peace +**\** {-anonimal} Such consolidation sounds like a good idea. +**\** fluffypony: Yeah that'd be fine too +**\** as long as it consolidates the information to a central place it's fine +**\** 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 +**\** It is actually really needed We have info all over the place +**\** (we discussed this here a few days ago as well, and everyone generally seemed in favour of it) +**\** ArticMine: agreed +**\** I like the idea. Consolidation and simplification should hopefully encourage more people to contribute to it +**\** that's it from my side - next meeting will be on the 5th of May, same time +**\** if anyone has anything they want to discuss, or any other points they want to bring up, now's the time +**\** we have 20-ish minutes till the Kovri meeting +**\** I am looking at the fee structure +**\** Does anyone fancy hacking the pool code to check top hash ? +**\** It shold be fairly easy. +**\** {-anonimal} fluffypony: s/May/June/ +**\** ArticMine: Is your research going to be put in a somewhat formal paper? +**\** er, s/hacking/amending/ for the peanut gallery. +**\** I'll start with a post on getmonero forum to get feedback ideas +**\** then one can develop a paper +**\** all right +**\** 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 +**\** 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 +**\** anonimal: thanks, lol +**\** To th UI of... ? +**\** Bitsquare itself +**\** It needs an additional field for the tx key +**\** Ah, I just saw the screenshot. +**\** It's mainly to resolve disputes, if any occur +**\** Btw fluffypony, any ETA on a new point release that includes the performance branch? Or are we awaiting any more PRs? +**\** ArticMine, i look forward to the adaptive fee structure thread +**\** Oh high team +**\** Hi team too +**\** hi luigi1112 +**\** dEBRUYNE: more PRs, also gives us time to see if there are issues with auto-convert +**\** *more issues +**\** hi luigi1112 +**\** What would I do if I wanted to try and repro that problem ? just pull, build, run ? +**\** fluffypony: all right +**\** im just curious... is 0mq gonna happen before ringCT? or ... or all at once? +**\** moneromooo: yeah +**\** gingeropolous: no clue +**\** I'm certainly doing nothing about it. +**\** well there's months until the next hardfork... though i guess 0mq doesn't affect consensus protocols? +**\** 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) +**\** ok starting the meeting relay for the Kovri meeting \ No newline at end of file diff --git a/_posts/2016-06-05-logs-for-the-kovri-dev-meeting-held-on-2016-06-05.md b/_posts/2016-06-05-logs-for-the-kovri-dev-meeting-held-on-2016-06-05.md new file mode 100644 index 00000000..8c88a6d6 --- /dev/null +++ b/_posts/2016-06-05-logs-for-the-kovri-dev-meeting-held-on-2016-06-05.md @@ -0,0 +1,241 @@ +--- +layout: post +title: Logs for the Kovri Dev Meeting Held on 2016-06-05 +summary: I2P StackExchange update, website content, Coverity issues, GNU social +tags: [dev diaries, i2p, crypto] +author: dEBRUYNE / fluffypony +--- + +*June 5th, 2016* + +### Logs + +**\** ok so I think let's move on to Kovri - anonimal, the floor is yours +**\ [anonimal]** Thanks fluffypony, I need about 30-60 seconds. +**\** 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 +**\** so they need some upvotes if you have rep on the BTC StackExchange +**\ [anonimal]** https://github.com/monero-project/kovri/issues/179 +**\ [anonimal]** 17:00 (UTC) +**\** http://bitcoin.stackexchange.com/users/35760/dontmindme +**\ [anonimal]** 1. Follow up on I2P StackExchange +**\ [anonimal]** 2. Follow up on fluffypony's website content review +**\** http://bitcoin.stackexchange.com/users/35975/jun-li +**\ [anonimal]** 3. Follow up on Coverity +**\ [anonimal]** 4. Review assigned open tickets: status, code ideas (if applicable), etc. +**\ [anonimal]** 5. Any additional meeting items +**\ [anonimal]** 6. Confirm next meeting date/time +**\ [anonimal]** Point 1. is open to all. +**\** i2p StackExchange is doing well: http://area51.stackexchange.com/proposals/99297/i2p +**\ [anonimal]** Where do we stand? +**\** 29% committed +**\** 34/100 committers with 200+ offsite rep +**\** but considering the small number of total committers (78/100) that's pretty impressive +**\** I will have 200 tomorrow, probably. 1% more. +**\** 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 +**\ [anonimal]** Good, I was about to ask what else we could do. +**\ [anonimal]** I'll start banging. +**\** it's REALLY easy to get that much rep, the fastest way I've found is answering questions +**\** but pick ONE StackExchange, as the rep isn't cumulative across Stacks +**\ [anonimal]** Ok, anything else for point 1? +**\** yes just a small thing +**\** 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 +**\** the deep web StackExchange proposal has failed due to lack of follow-through on commitments, so the i2p one is more necessary than before +**\ [anonimal]** Hmm, tricky. +**\** 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 +**\ [anonimal]** How do I say this quickly, +**\** anonimal: by typing fast? :-P +**\ [anonimal]** I have a strong impression that Tor does not care about I2P. +**\ [anonimal]** Nothing personal, just different technologies. +**\** 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 +**\ [anonimal]** I agree with fluffypony for now. +**\ [anonimal]** I'd like to come back to that idea though in the future. +**\** Okay. I wont make any aggressive outreach efforts to the Tor community at this time +**\ [anonimal]** Ok, anything else on 1.? +**\** nothing from my side +**\ [anonimal]** 2. fluffypony, last meeting we talked about website content, +**\ [anonimal]** I sent a draft. Status? +**\** 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 +**\** 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 +**\ [anonimal]** Ok, I hope to get a chance to review anything because what I sent really was a 'dump' ;) +**\** oh yeah definitely, plus you can always PR changes to the site, we merge everything there :-P +**\ [anonimal]** lol +**\ [anonimal]** Ok, anything else on 2.? +**\** does 2 include gnu social or just the website? +**\ [anonimal]** Free-for-all. +**\ [anonimal]** xmrpromotions: any updates on gnu social? +**\** 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 +**\ [anonimal]** Could it be done 'good enough'? +**\** Any suggestions for volunteers eager to help with that sort of thing that have extra free time right now +**\ [anonimal]** I can help when the time comes. +**\** 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 +**\ [anonimal]** I've ran an instance in the past (personal, not public). +**\** dEBRUYNE: is anyone on the social media team available to assist ? +**\** what is it about? I have some free time but I am not sure what this is +**\** if I have the skills required.. +**\** merkaba: oh I have a special job for you if you want to flex your Ruby skills ;) +**\** btw I am stefioan from reddit +**\** cool +**\** fluffypony: I am running out of free time currently, so hopefully someone else could pick it up (e.g. xmrpromotions and/or merkaba) +**\** what exactly is needed as help in the gnu social thing? +**\ * anonimal** was just about to ask that +**\** People to provide quality content and invite users is needed the most IMHO +**\** I am not an expert and had not heard of it until 2 weeks ago +**\** so no coding or stuff, but posting content about xmr, its development etc? +**\** here is the example someone gave me: https://quitter.se/social details here: https://gnu.io/social/about/ +**\ [anonimal]** Can twitter posts be cross-posted? +**\** we are talking about Kovri now but yes we could use it for Monero too +**\** maybe not automatically, anonimal, but certainly manually +**\ [anonimal]** "If you build it, they will come". +**\ [anonimal]** Why not baby steps for now: get it up and running, and we'll get on it and start using it? +**\** agreed +**\ [anonimal]** xmrpromotions: ETA on when it can be physically online? +**\** xmrpromotions: shout if you need me to host it on one of the Monero infrastructure servers +**\ * anonimal** side-channels fluffypony for preparations of 3. https://scan.coverity.com/projects/monero-project-kovri?tab=overview +**\** 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 +**\ [anonimal]** Can it be up by next meeting? +**\** I think that is realistic. +**\** It sounds like others will be willing to help provide content. +**\ [anonimal]** Excellent. +**\ [anonimal]** I'll start using it once its up. +**\ [anonimal]** Anything else on point 2.? +**\** nein +**\ [anonimal]** Ok moving on to 3. +**\ [anonimal]** "No builds were successfully analyzed yet." +**\ [anonimal]** So, it looks like more Coverity setup issues. +**\** 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 +**\** anonimal: argh. it's like they're trying to irritate me. +**\ [anonimal]** xmrpromotions: good point, I will work on my rep. +**\ [anonimal]** fluffypony: seriously, I have no idea why its so problematic. +**\** anonimal did you see the hello world example ? +**\ [anonimal]** Directions were followed to the T. +**\ [anonimal]** fluffypony: Maybe, a long while ago. Link? +**\** https://github.com/daksheshvyas/MyHelloWorld/ +**\** https://travis-ci.org/daksheshvyas/MyHelloWorld/ +**\** maybe check if there's not something they do there that we haven't done +**\ [anonimal]** I remember those. +**\ [anonimal]** Nope, our config checks out AFAICT. +**\** https://scan.coverity.com/faq#frequency +**\** we're way under teh frequency limits +**\ [anonimal]** Is yrashk still on that side? Maybe he uses coverity/travis-ci? +**\** he's already hopped offline afaik +**\** it's nearly 1am his time +**\ [anonimal]** I've also done several merges to branch coverity_scan to 'trigger' it, but to no avail. +**\ [anonimal]** fluffypony: Any ideas on solutions? They really don't make it easy to contact them for troubleshooting. +**\** hmmm anonimal +**\** "You'll need to manually fill in your project specifics, including build_command_prepend and build_command." +**\** we don't have the build_command_prepend +**\** could that be a requirement ? +**\ [anonimal]** I highly doubt it. +**\** nothing would surprise me at this stage :-P +**\** 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. +**\** anonimal: so "branch_pattern: coverity_scan" means it'll only build changes to the branch named coverity_scan, noto the master branch +**\ [anonimal]** Yes. +**\** ok +**\ [anonimal]** And last merge into coverity_scan was May 29th. +**\** maybe we should just include a build_command_prepend +**\** something like cd build && make clean +**\ [anonimal]** But what would we put? exporting variables? +**\** the example has: +**\** build_command_prepend: "./configure; make clean" +**\** build_command: "make -j 4" +**\** maybe add a && cd .. +**\ [anonimal]** Which doesn't make sense if the VM is fresh before every build. +**\ [anonimal]** The build_command is sound, it would literally be a matter of splitting that up. +**\** anonimal: yet the example has "make clean", so maybe they don't have a fresh VM each time ? +**\ [anonimal]** so build_command_prepend: export CC=gcc-${GCC_VERSION} CXX=g++-${GCC_VERSION} && cd build +**\** that could work if we're 100% sure it's a fresh VM +**\ [anonimal]** It is. You can see it in all the travis build logs. +**\** and Coverity runs on the Travis VM right ? +**\ [anonimal]** Apparently? +**\ [anonimal]** So, we could keep tinkering and hope for a result or email scan-admin@coverity.com +**\ [anonimal]** Thoughts? +**\** guys I am leaving. if I can be help on any task feel free to contact me on reddit (/u/stefioan) +**\** merkaba: will do, thanks +**\ [anonimal]** Thanks merkaba. +**\** you are welcome +**\** anonimal: I think let's try including a build_command_prepend, failing that I'll have to try reach out to Coverity +**\** seeing as how they were so helpful last time +**\** :-P +**\** thanks merkaba. lets talk more about gnu social later +**\ [anonimal]** merkaba: +**\ [anonimal]** Isn't diaspora written in ruby? +**\ * anonimal** checks +**\** anonimal: he already left unfortunately +**\ [anonimal]** xmrpromotions: if you see them again, https://github.com/diaspora/diaspora +**\ [anonimal]** Ok fluffypony, I'll make the change and we'll see what happens. +**\ [anonimal]** Anything else on 3.? +**\** nope +**\ [anonimal]** Alright, 4. Review assigned open tickets: status, code ideas (if applicable), etc. +**\ * anonimal** quickly pulls up +**\ [anonimal]** Ok, 4 new tickets opened since last meeting. All by yours truly. +**\ [anonimal]** Joyous #187 and #191. +**\ [anonimal]** Would any of the talented Monero devs be interested in diving into Kovri? +**\ [anonimal]** I think those two tickets would be a great intro into the project (not being sarcastic). +**\** lol @ 191 +**\** "but that is not the real problem" +**\ [anonimal]** lol +**\** https://diasporafoundation.org/ looks interesting! Should we consider that as an alternative to GNU social? +**\** In some ways it sounds better, but does a lack of Windows support hurt us significantly? https://wiki.diasporafoundation.org/Installation +**\ [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) +**\ [anonimal]** Diaspora simply crossed my mind since that ruby dev popped in. +**\ [anonimal]** Anyway, re: 4., +**\** okay. fair enough. I will keeped focused on gu social then +**\** gnu +**\ [anonimal]** fluffypony: I can't see who is on that side. Are any c++ devs online? +**\** hmmm +**\** not sure if any of them are in front of their keyboards atm, let's leave that open-ended +**\** if anyone wants to do an FFS proposal for it that's a great option +**\** since it's easily measurable and challenging in a fun way +**\ [anonimal]** I'm leaning towards a proposal or two. +**\ [anonimal]** Ok, I'll see what I can propose before the next meeting. +**\ [anonimal]** The tickets just keep piling up, help would be nice. +**\ [anonimal]** Actually, more than nice. +**\** 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 +**\ [anonimal]** At some point we'll have to have a meeting dedicated to dev awareness. +**\ [anonimal]** I understand. I see everyone doing their best so what else could we ask for. +**\** yup yup +**\ [anonimal]** Anything else on 4.? +**\** nope +**\ [anonimal]** fluffypony: Do you have any formal ideas on #159? +**\ [anonimal]** s/ideas/strategies +**\** 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 +**\** anonimal: what about C++ devs online? +**\** fluffypony: what's meeting-bot connecting to? +**\** tewinget: irc2p +**\** most C++ devs online want full time work, or overstate their abilities +**\** [anonimal] tewinget: ^ +**\** [anonimal] Or are not really interested but want a payout. +**\** yup +**\ [anonimal]** But everyone isn't bad. +**\ [anonimal]** But we also don't have enough awareness yet, but we're working on that. +**\** Hey, I'm only like 2 out of 3 there! +**\** yesh +**\** we'll get there +**\** [anonimal] tewinget have you played with Kovri yet? +**\** anonimal: I can't even remember off the top of my head what Kovri is... +**\* tewinget** does a quick google search +**\** oh, that. Not yet, why? +**\ [anonimal]** lol because that's what the meeting is for :) +**\** I just got up not long ago, haven't had time to read all the scrollback +**\** :) +**\ [anonimal]** Alright, moving onto 5. Any additional meeting items +**\ * anonimal** thinking +**\** nothing off the top of my head +**\ [anonimal]** Me neither. I'm out of energy but I feel like there was more to discuss. +**\** we'll push stuff forward, we can discuss anything urgent in the week, else we let it fall to the next meeting +**\** which will be the 19th, by my calendar +**\ [anonimal]** Ok. I was hoping to talk more code but devs seem to be away. +**\ [anonimal]** C++ nerd stuff. Boost enthusiasts. +**\ [anonimal]** alla Monero. +**\** let's flip it around for next meeting and do that first +**\ [anonimal]** Anyway, next time then or during the week. +**\ [anonimal]** Ok, sounds great. +**\ [anonimal]** So point 6., +**\ [anonimal]** June 19th? 17:00 UTC? +**\** Do you think many people in this group would be interested in I2P or kovri? http://area51.stackexchange.com/proposals/82234/open-source +**\** anonimal: yup +**\** anonimal: if there's anything specific you can point to as far as C++ goes you can ping me +**\** xmrpromotions: hard to canvas on an SE propsal +**\** 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 +**\** they lack of ability to direct message makes it harder but some leaders use their real names +**\** ok meeting is over, killing meeting-bot \ No newline at end of file diff --git a/_posts/2016-06-05-overview-and-logs-for-the-dev-meeting-held-on-2016-06-05.md b/_posts/2016-06-05-overview-and-logs-for-the-dev-meeting-held-on-2016-06-05.md new file mode 100644 index 00000000..59e87aa2 --- /dev/null +++ b/_posts/2016-06-05-overview-and-logs-for-the-dev-meeting-held-on-2016-06-05.md @@ -0,0 +1,277 @@ +--- +layout: post +title: Overview and Logs for the Dev Meeting Held on 2016-06-05 +summary: introduction to C4 by Yurii Rashkovski, brief update on Ring CT and 0MQ +tags: [dev diaries, core, crypto, 0mq] +author: dEBRUYNE / fluffypony / Aerbax +--- + +*June 5th, 2016* + +### Overview + +An overview [can be found on Hello Monero](https://hellomonero.com/article/monero-bi-weekly-dev-meeting-note-highlights-2016-06-05) + +### Logs + +**\** everyone ready to start? smooth / tewinget / dEBRUYNE / ArticMine / luigi1111w / luigi1112 / luigi1114 / NoodleDoodle / gingeropolous etc. +**\** yes +**\** hyc is excused, as he is at Pieter Hintjen's wake +**\* dEBRUYNE** slaps othe, moneromooo +**\** did we forget anyone? :p +**\** don't think so +**\* dEBRUYNE** pages redfish +**\** Think that covers it +**\** ok cool +**\** Traditional Dutch greeting ? +**\** lol +**\** traditional Dutch greeting = "hallo" +**\** so to start this meeting off I wanted to introduce yrashk, Yurii Rashkovskii +**\** he's our special guest for today +**\** o/ +**\** a little bit of background: as everyone is aware we've been looking at formally adopting C4, the Collective Code Construction Contract +**\** which 0MQ uses +**\** hey hey +**\** forgot to start meeting-bot, sorry +**\** ok +**\** so +**\** 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 +**\** 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 +**\** yrashk: the floor is yours +**\** fluffypony: thanks for the intro! +**\** 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. +**\** 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. +**\** what actually has drawn me to C4 was 1) its simplicity and 2) the rules that seemed to lead to less tension between people +**\** it's hardly possible to eliminate those, of course, but it's easy to create "hot spots" unintentionally +**\** 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 +**\** and I saw that it was often over a value judgement +**\** ("do we need a feature X?" "do we implement it this or that way?" etc.) +**\** on the other hand, I had two arguments against CoC +**\** 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. +**\** 100% agreed +**\** with C4, the main rules of the game were pretty simple: maintainers can't hold up your patch because of your value judgement +**\** even if it is stupid +**\** by the contract, everybody has a right to contribute +**\** 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) +**\** 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. +**\** 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. +**\** no bike shedding, no gatekeeping +**\** everything is record. anything can be easily reverted. +**\** is recorded* +**\** 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. +**\** I met people who strongly believe that their experience and intelligence justify them being gatekeepers +**\** 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 +**\** 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) +**\** '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: ...").' +**\** 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 +**\** (should I send a reverting PR if it is a total and utter BS? should I help improving this? etc.) +**\** I guess this braindump is good for starters. I'll take questions, if any? +**\** ok so my first questions when I read C4 was about how it deals with people who are disruptive +**\** 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 ? +**\** how does it do so in a non-guillotine manner ? +**\** (also, my short article on the subject https://blog.eventsourcing.com/productive-welcoming-vs-code-of-conduct-656b1571ddd6) +**\** 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. +**\** fluffypony: the rest is no different from other approaches: discuss the situation, if a correction can't happen, ban/eject +**\** yeah I gathered the focus was on people self-correcting instead of being forced to correct +**\** 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 +**\** when you treat people like adults, they tend to behave more like adults +**\** resulting in better ORs +**\** PRs* +**\** I think the worst case scenario is someone submits a PR that intentionally introduces a backdoor, or intentionally breaks things +**\** I see this "optimistic" merge strategy as a way to treat people like adults +**\** in which case the reverted PR is a black mark against them +**\** You assume good faith, and a single bad faith person can throw a lot of crap in. +**\** fluffypony: exactly, a permanent record (as opposed to a rejected PR, which might be lost over time) +**\** moneromooo: the issue is that doing it the *other* way means a bad faith person can waste everyone's time +**\** moneromooo: just like anybody can throw a lot of crap in, it can be thrown own the same way +**\** But why would we want a permanent record of spam patches in the first place ? +**\** So the concept is it is easy to undo / revert damage while leaving a cleat and objective trail for community accountability +**\** yrashk: I'm worried about the history here, not the snapshot. +**\** moneromooo: because that helps identifying the bad actors at a later point ("yup, known spammer") +**\** I imagine someone wanting to DoS us would not use the same email over and over again. They're good at sock puppets. +**\** 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. +**\** Appeal to emotion. +**\** moneromooo: I guess it is highly dependent on the nature of the project — how many bad actors are actually interested to disrupt the project +**\** 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 +**\** so how easy is it to waste my time :-P +**\** that's actually a worse DoS +**\** Do you do that ? +**\** time is the most valuable thing +**\** well, any PR review takes time +**\** and delays releases further +**\** 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 +**\** someone will compile it and see it's broken, and that someone doesn't have to be me +**\** C4 doesn't actually say the code should not be reviewed +**\** 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". +**\** it's just done after the merging +**\** moneromooo: we'll still have smell tests +**\** That seems good to be ("I just merge based on a visual inspection or a review by some known contributor"). +**\** (and I try to review those fwiw) +**\** also the action AFTER a failed smell test is important +**\** ie. do we then have a long, drawn-out convo on github +**\** or do we merge and revert, then explain to the person why that happened +**\** As for building, you said you'd like a build bot IIRC. That'd help a lot there. +**\** But the things I'm worried about are not held off by a build check. +**\** I use travis-ci so I can quickly see if PR breaks existing tests +**\** yeah a build check solves a small subset of issues, 100% moneromooo +**\** Maybe I'm paranoid, but I totally see part of the BCT jerks spamming our tree just because. +**\** do they do this right now? +**\** Not to my knowledge. +**\** moneromooo: it's MUCH easier to deal with that if we merge-and-revert than if we analyse and have long github discussions +**\** one of the main ideas behind C4 is to incentivize the positive contributors to get their stuff in quickly, without painless waiting and discussions +**\** I've beed in a situation where it just becomes so painful to abide by all the maintainers' wants to get something in +**\** https://github.com/bitcoin/bitcoin/pull/5905 +**\** that PR is over a year old +**\** or when the maintainers are busy with other projects, or don't care about a particular problem enough to get my stuff in quickly +**\** without painful waiting* +**\** and there are lots like that - full of discussion, "concept ACKs" and so on +**\** \ 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 +**\** we use travis on Kovri +**\** What are the problems now, beyond fluffypony's time ? +**\** but hoping for a more OS-complete buildbot +**\** the other way to look at it — with C4, you have *all contributors* as reviewrs +**\** not just a handful of maintainers +**\** because everybody can initiate a corrective action +**\** moneromooo: the main problem is that we don't want to become exclusionary, where only a handful of special contributors actually have successful PRs +**\** That would not happen if there is a large enough numbers of people who can review and ack something. +**\** And doing so would not need so muvch time from you either. +**\** 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. +**\** (speaking of C4 vs CoC) +**\** What is CoC ? +**\** Code of Conduct +**\** moneromooo: Bitcoin has significant numbers of people that can review and ACK, yet there are 102 open PRs stuck in PR-review-hell +**\** CoC is about prohibiting certain types of behaviours and topics +**\** This may be so, but I do not believe a free for all is better. +**\** in the name of attracting a more diverse set of contributors +**\** (or at least, not before we have that problem) +**\** while removing gatekeeping/biases from reviews gets diverse opinions in proactively +**\** at least that's the hypothesis +**\** 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 +**\** 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. +**\** (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) +**\** That'd probably fork at once. +**\** moneromooo: many projects are started by very small teams that are likely to be less diverse. therefore original maintainers might have similar biases. +**\** moneromooo: I mean, would we merge the PR, or not ? +**\** hi merkaba, and welcome :) +**\** I think in the case of this PR (block time), first important thing to consider is "does it have a valid problem/solution statement" +**\** I'd hope not, but you're not allowed to then magic other assumptions after I said that :) +**\** maybe there's a problem nobody thought about? +**\** fluffypony, thank you +**\** Then the question becomes is the problem valid? +**\** If there's a problem nobody thought about, surely a reviewer would ack it ? +**\** 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 +**\** So, same result, except a spammed git history ? +**\** I *do* use git history :/ +**\** but spammed for a reason +**\** a revert won't affect git bisect / git blame, I don't think ? +**\** It will affect blame I think. It will certainly affect bisect time. +**\** Regardless, I object to it for other grounds anyway (it seeming like shooting ourslves in the foot). +**\** I think that maybe extreme examples like "change the block time" are bad for what I'm trying to illustrate +**\** 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. +**\** But then, the solution *should* consider something not totally at the extreme of "let's merge anything". +**\** but moneromooo, I think we can do the opposite of "possibly causing dissatisfied contributors" - I think we can be extremely welcoming to contributors +**\** Is a middle ground possible here? +**\** That'd seem to be a great idea. I find monero very welcoming tbh. +**\** well the current pitch is "let's merge everything once it's been reviewed by a known contributor" +**\** what is the goal of introducing a new contribution guideline? what problem is being addressed here? attracting potential contributors? treating dissatisfied contributors? +**\** so we still have that firewall +**\** redfish: it's about establishing protocol that will survive through to when we have 500+ contributors +**\** Do you mean "we'd still have" ? +**\** moneromooo: yes I do +**\** I hate the idea of "dev worship", where a single contributor is lorded over others, or viewed as being able to cure cancer +**\** Then I agree. I was iunder the impression that there'd be no review by a known contributor. Sorry about that :D +**\** to the exclusion of newcomers +**\** C4 kind of helps addressing the "problem of elders" +**\** a newcomer can be dissuaded by review-block, but the newcomer should really have thicker skin +**\** be careful of working with a strawmen for a newcomer contributor +**\** 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 +**\** 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. +**\** the attitute of "you don't want my patch? then, fuck you all" should not be encouraged +**\** Then: +**\** 17:53 \<@fluffypony> well the current pitch is "let's merge everything once it's been reviewed by a known contributor" +**\** And: +**\** 17:54 \< moneromooo> Do you mean "we'd still have" ? +**\** 17:54 \<@fluffypony> moneromooo: yes I do +**\** So I don't see what would change, then. +**\** 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. +**\** Currently: an ack by a known contributor. +**\** expez: so by the same token every technical / scientific / medical article on Github should have declining quality until it's illegible garbage :-P +**\** fluffypony: I can't speak to that. I haven't seen any articles written by acretion. +**\** I jest - I'm not suggesting the code be written by Wikipedia contributors +**\** but let me use a practical example +**\** a new contributor submits a new feature, but it breaks the Windows build and also doesn't include unit tests +**\** option 1 is that we back-and-forth on his PR until he has it "perfect" by some undefined definition of perfection +**\** 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 +**\** 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 +**\** not just the original contributor +**\** I think you really nailed it here: "undefined definition of perfection" +**\** 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. +**\** anyone can push commits on top of a PR branch +**\** redfish: yes they can, but until when ? +**\** until the build is fixed and the unit tests pass +**\ [anonimal]** Kovri meeting starts now but everyone is on a roll - and I'd like to read this huge backlog :) +**\** moneromooo: sure, but that's like saying we shouldn't adopt any sort of governance structure because we're "too small for governance" +**\** Not really. Maybe a bit. +**\** 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 +**\** ^^ +**\** OK, that is a fair point. +**\** literally the only change from a contributor perspective is you have to include a Problem...Solution statement +**\** But we could adopt a governance that's not as seemingly footgun. +**\** nothing else changes +**\** Not the merge it all and revert at once ? +**\** that affects those with push rights, not contributors as a whole +**\** and because we're small we'll probably not even follow that to the letter all the time +**\** BUT we'll have a documented process which contributors will be able to find and understand +**\** There is a difference between a controversial change to the social covenant and failure to build for a particular OS +**\** in fact, C4 adds a review layer of a sort for "proven" maintainers as you can't push to master directly +**\** ArticMine: agreed +**\** http://oss-watch.ac.uk/resources/governancemodels <- this is a good read +**\** but other maintainers have to merge your PR in +**\** from that article: +**\** hello +**\** hi +**\** "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: +**\** - potential contributors will not know how to contribute +**\** - they will not be sure what will happen to their contribution +**\** - the project will not look serious about engaging with third parties +**\** - there is no visible assurance that contributions will be managed in such a way that they will remain of value to the original contributor +**\** Since you never know when a contributor might stumble upon your project, it is important to be ready from the earliest possible date." +**\** "the project will not look serious about engaging with third parties" sounds like bullshit. +**\** you'd be surprised by how many people who code for a living are afraid to submit a PR, moneromooo +**\** The rest, OK. +**\** we have fluffy ponies and cows and all sorts, not everyone wants to be in the middle of a farmyard +**\** That may be so, but the sentence doesn't really mention that. +**\** this quote assumes strawman for a contributor +**\** hi lpaalp1 :) +**\** imho, the danger from a troll newcomer is greater than a danger from a biased old-timer +**\** redfish: C4 provides options to deal with trolls that don't self-correct +**\** I'm totally fine with having a CONTRIBUTING file, or HTML page somewhere, etc, fwiw. +**\** and it does so in a way that is least disruptive to the community as a whole +**\** Well, I do not agree with this, since the harm to history has already been done. +**\** (assuming we're back to merge-first, rather htan wait for an ack from a well known contributor) +**\** no we're not back to that, lol +**\** the review-first model still stays, we're just bolting C4 on top of that +**\** at any rate, we've gone significantly over time, and we've only had one point for discussion, lol +**\** OK. I feel like I'm being lied to here for some reason... +**\** I think let's bounce this around over the next two weeks +**\** Maybe because the discussion about it months ago was merge first. +**\** and then at the next dev meeting we can make a decision if everyone is comfortable +**\** moneromooo: that hasn't changed, we've just added the eyeball-review bit per the discussion with smooth ages ago +**\** OK. Thanks. +**\** Yes this needs a lot more thought and discussion before a decision is made +**\** yes absolutely +**\** so before we move on to Kovri +**\** two quick things +**\** 1. moneromooo - can you give us a brief update on how the RingCT stuff is going +**\** and 2. dEBRUYNE wanted to discuss 0MQ briefly +**\** also thanks for attending yrashk - much to think about and discuss :) +**\** 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. +**\** fluffypony: thanks for having me! +**\** It's progressing anyway. +**\** 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). +**\** moneromooo: do you need any extra help, or are you ok with things at the moment ? +**\** Rewrite, not contunue, AFAIK. +**\** I'm ok with it, but I'll have questions for shen, most certainly. +**\** kk +**\** ok so I think let's move on to Kovri - anonimal, the floor is yours +**\** \ Rewrite, not contunue, AFAIK. <= Correct. Rewrite is in a sense also continue right? :P diff --git a/_posts/2016-06-19-logs-for-the-Kovri-dev-meeting-held-on-2016-06-19.md b/_posts/2016-06-19-logs-for-the-Kovri-dev-meeting-held-on-2016-06-19.md new file mode 100644 index 00000000..13fbe913 --- /dev/null +++ b/_posts/2016-06-19-logs-for-the-Kovri-dev-meeting-held-on-2016-06-19.md @@ -0,0 +1,294 @@ +--- +layout: post +title: Logs for the Kovri Dev Meeting Held on 2016-06-19 +summary: Brief review of what has been completed since last meeting, C++ specific discussion, closed and open issues +tags: [dev diaries, i2p, crypto] +author: dEBRUYNE / fluffypony +--- + +*June 19th, 2016* + +### Logs + +**\** ok I guess we move on to Kovri - anonimal, the floor is yours +**\ [anominal]** From agenda https://github.com/monero-project/kovri/issues/192 +**\ [anominal]** 17:00 (UTC) +**\ [anominal]** 1. Greetings +**\ [anominal]** 2. Brief review of what's been completed since the previous meeting +**\ [anominal]** 3. C++ specific discussion (carried over from June 5th meeting) +**\ [anominal]** 4. Review open tickets (assigned and/or unassigned): status, code ideas (if applicable), etc. +**\ [anominal]** 5. Discuss any pertinent TODO's +**\ [anominal]** 6. Any additional meeting items +**\ [anominal]** 7. Confirm next meeting date/time +**\ [anominal]** 1. Greetings +**\ [anominal]** Hi +**\ [anominal]** EinMByte: present? +**\** there's 2x greetings? +**\** best meeting ever +**\ [anominal]** lol +**\ [anominal]** Well, EinMByte is here but not present. +**\** k +**\ [anominal]** Moving on, +**\ [anominal]** 2. Brief review of what's been completed since the previous meeting +**\ [anominal]** A somewhat productive two weeks in contrasting areas. Highlights include: +**\ [anominal]** - New --log-levels runtime feature +**\ [anominal]** - Security fix in Garlic/ElGamal +**\ [anominal]** - New user-agent scrubber +**\ [anominal]** - Bump to 0.9.26 +**\ [anominal]** - Coverity coverage via travis-ci (though problematic, see #209) +**\ [anominal]** - Design refactoring, misc. refactoring, code documentation +**\ [anominal]** 6 closed issues +**\ [anominal]** 2 new standing issues +**\ [anominal]** fluffypony: have you had a chance to complete anything since previous meeting? +**\** anonimal: like 80%-ish done with the Kovri page on the site, per the info you gave me + the docs +**\** s/page/section +**\ [anominal]** Great, I'm looking forward to it. +**\ [anominal]** Do you think it will be finished before next meeting? +**\** yes definitely +**\ [anominal]** Yay, sounds exciting. +**\ [anominal]** Anything else on 2.? +**\ [anominal]** Going once... going twice... +**\ [anominal]** 3. C++ specific discussion (carried over from June 5th meeting) +**\ [anominal]** Well, I was hoping to merge this in with 4. and chat with EinMByte since he said he'd be here. +**\** is this wrt the C++ standard ? +**\** or the style guide stuff? +**\ [anominal]** Anything C++, I imagined. +**\ [anominal]** I was hoping to focus on C++ related to #187, but I haven't looked at #187 since it was opened. +**\ [anominal]** Have any bitmonero devs taken an interest in Kovri yet? +**\ [anominal]** Its quite the beast, and needs much taming. +**\** I don't think anyone has yet +**\** anonimal: passing interest at best for me +**\ [anominal]** Ok, good to know. +**\** I more or less know what it is, but I haven't looked into tinkering with it yet. +**\** I think the problem is that the time I'd spend hacking on anything, I wouldn't spend on monero anymore :) +**\** s'true +**\ [anominal]** I totally understand. +**\** there will be a bleed area between the two when integration happens +**\ [anominal]** That makes, so patience and persistence seems to be the key. +**\ [anominal]** \*makes sense +**\ [anominal]** Well, anonymity has a certain taste too. Maybe I'm one of the few fanatics who enjoy working on it ;) +**\** I think most of us are here because we're pro-privacy +**\ [anominal]** Anyway, I look forward to the meeting of the minds, I like what I've seen in bitmonero dev. +**\ [anominal]** Yes, good point. +**\** which is awesome :) +**\ [anominal]** Anything else on 3.? Any questions? +**\ [anominal]** Alrighty, moving on, +**\ [anominal]** 4. Review open tickets (assigned and/or unassigned): status, code ideas (if applicable), etc. +**\ [anominal]** Let's see, +**\** anonimal, also, if EinMbyte can't make the meeting maybe we must collate stuff and raise it on his behalf ? +**\ [anominal]** How so? +**\** like if he just adds to the agenda then we can discuss it without him needing to be here +**\ [anominal]** Ok, well he's welcome to do that. +**\ [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. +**\ [anominal]** I see, so we'll send him a note to add to the agenda regardless of his attending? +**\** yes I think that would help, he lacks time at the moment +**\ [anominal]** Ok. +**\ * anonimal** back to 4. +**\ [anominal]** #210 might be an easy fix, if any bitmonero devs want to take a peek. +**\** once you go Kovri you never go...uh...something that rhymes with Kovri +**\ [anominal]** lol +**\ [anominal]** That's a tough one.... +**\** https://github.com/monero-project/kovri/issues/210 <- for reference +**\ [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. +**\ [anominal]** I may pick at #191 or #187 because I get irritated with severely broken things. +**\ [anominal]** Or who knows what, the world is full of mysterious and discovery. +**\** lol +**\ [anominal]** *mystery +**\ [anominal]** lol +**\** invent a time machine ! +**\ [anominal]** pffffffffff +**\ [anominal]** That would be fun. +**\** :-P +**\ [anominal]** Does anyone here work with Debian Jessie often? +**\** tewinget is an Arch user +**\** moneromooo wrote his own OS from scratch I'm sure +**\** osensei maybe +**\** but he's not around atm +**\** I use a pretty common one nowdays actually. +**\ [anominal]** Ok just curious. Arch here so #210 will probably take more than a few moments. +**\** moneromooo: Windows XP ? +**\ [anominal]** ^ Windows 98 +**\** Good point. I guess it's not that common. I forgot about windows. +**\ [anominal]** 95 was better at breaking. +**\ [anominal]** Ok, well re: 4., fluffypony have you see #209? +**\** probably +**\ [anominal]** 50% yay because we solved the coverity/travis issue! +**\** oh yes the Coverity thing +**\** ok so plz update me - Travis builds are now work +**\** *working +**\** but Coverity isn't triggering ? +**\ [anominal]** No, we are \*finally\* triggering, but now coverity says build is failing on their end. +**\ [anominal]** So, travis says "we're fine", coverity says "you're not fine but neither is most of my site". +**\ [anominal]** Because they really do have some issues there and support is... meh. +**\** LOL +**\** considering how long it took for their site to pick Travis up I'm not even surprised +**\** do we wait until they've fixed it, or keep pushing +**\ [anominal]** Seriously, and their "community" site is still offline despite "we'll be back in early 2016!". +**\ [anominal]** It's June already... +**\ [anominal]** Good question, +**\ [anominal]** I can review \*why\* they think our build failed, I could even try to do it manually. +**\ [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). +**\** maybe we must switch to manual Coverity +**\** and just do it once every two weeks +**\ [anominal]** Sounds fair, I'll give it shot before next meeting. +**\ * anonimal** before I forget, opens https://github.com/monero-project/kovri/issues/assigned/fluffypony +**\ [anominal]** fluffypony: Any updates on #27? +**\ * anonimal** knows you've been busy, simply curious +**\** anonimal: no - also, we're switching providers +**\ [anominal]** Ok. +**\** debating Zoho vs. FastMail +**\** ProtonMail doesn't do multiple users on a domain, unfortunately +**\ [anominal]** Hmmm... +**\ [anominal]** Pros/Cons so far re: providers? +**\** well they're mostly doing forwarding and SMTP, so it's pretty open +**\** 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 +**\** will wrap that up soon, it's on my short list +**\ [anominal]** Ok, good to know. +**\ [anominal]** I don't have an opionion so far. If I do I'll be sure to chip in. +**\ [anominal]** Is xmrpromotions there? re: #105 +**\** no not online atm +**\** I'll prod them for that when I see them next +**\ [anominal]** K. +**\ * anonimal** typing +**\ [anominal]** I'll most likely take a look at bitmonero's 0MQ work too before next meeting (thinking of #53). +**\ [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. +**\** anonimal, feel free to direct any 0mq questions at ~~fluffypony~~ me +**\ [anominal]** Thanks tewinget. +**\** oh yeah speaking of +**\** sad that my IRC client doesn't support strikeout...hoping someone else's does +**\** the Windows test box is borked +**\** msys2 decided to give up the ghost +**\** so doing a complete reinstall of it +**\ [anominal]** Yeah, so what happened? Any idea? +**\** no clue +**\ [anominal]** (very strange) +**\** On a scale from 1 to I hate compiling anything on Windows: I hate compiling anything on Windows. +**\** it's a binary scale. +**\ [anominal]** Oh windows, you never cease to disappoint me. +**\ [anominal]** Anything else on 4.? +**\ * anonimal** quick reviewing +**\ [EinMByte]** Hi, I'm late sorry +**\ [anominal]** EinMByte! Welcome back. +**\** wb EinMByte +**\** still 15 minutes left :) +**\ [anominal]** With 15 minutes or so to spare, any input? (much backlog) +**\ [EinMByte]** Something about #210 maybe: I'll provide some more information +**\ [anominal]** EinMByte: before I forget and while you're here: what is your preferred/most-reliable public contact method? +**\ [EinMByte]** public as in to put on a website or so, or as in where you guys can contact me +**\ [anominal]** So we can contact you. +**\ [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? +**\ [EinMByte]** Well I'll be on IRC, or else einmbyte@mail.i2p or github +**\ [anominal]** Ok. +**\ [EinMByte]** sure +**\ [anominal]** fluffypony: did I word that correctly? +**\ [anominal]** EinMByte: we're still on point 4. "reviewing tickets", etc. +**\ [anominal]** Is there anything you wanted to add re: SSU? +**\ * anonimal** knows you just got back to working on it +**\** yes I think so +**\ [EinMByte]** Well I can give you a quick status update +**\ [anominal]** Awesome. +**\ [EinMByte]** So SSUSession.cpp is now using the new parsing code, except for the fragments +**\ [EinMByte]** (I have the code to parse data packets, just not using it yet) +**\ [EinMByte]** I am slowed down right now due to a bug, with the header I suspect +**\ [anominal]** Grrr... bugs... +**\ [EinMByte]** (Rekey options being set etc when this shouldn't happen, I think it's all related) +**\ [EinMByte]** Well, I'll try to fix it in the next days +**\ [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. +**\** lol +**\ [anominal]** In other words, SSU has needed much love and I'm glad EinMByte has tackled the challenge. +**\ [EinMByte]** Hah, nice comparison - although it does make me seem quite desperate :P +**\ [anominal]** lol, oops. Sorry EinMByte, I didn't mean it that way :( +**\ [EinMByte]** Once the parsing part is done, I'll do something similar to build the packets +**\ [anominal]** Sounds great. +**\ [anominal]** How about, EinMByte dances with her because he is a leader and willing to show great sympathy to those who need it most. +**\ [EinMByte]** I'll write some tests, but don't expect full coverage just yet. I don't think that's a priority right now. +**\ [anominal]** And turns down the more promising dancers to make SSU work well. +**\ [EinMByte]** (I want to get the API started too) +**\ * anonimal** sorry, I'm getting carried away +**\ [anominal]** Ok. +**\ [anominal]** Do you have an idea of schedule coming up? +**\ [anominal]** (as in availability) +**\ [EinMByte]** anonimal: You're making a lot of assumptions about my gender here :). But let's see how well that dance turns out +**\ [anominal]** I know, again my apologies. +**\ [EinMByte]** Yes, next week I'll be mostly available (several hours per day) +**\ [anominal]** Ok. I'll check my IRC more frequently then. +**\ [anominal]** Anything else on 4.? +**\ [EinMByte]** Well as I said I'll put up more info for #210 +**\ [anominal]** Ok. +**\ [EinMByte]** Seems like 2 tests are failing +**\ [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. +**\ [anominal]** Any comments on 5.? +**\** EinMByte: well you can dance with SSUzy regardless of your gender +**\ [anominal]** SSUzy, lol. +**\ [EinMByte]** fluffypony: or my ability to dance :p +**\** everyone can dance, it's just a matter of how badly (or well) +**\ [anominal]** Paraplegics? +**\ * anonimal** doesn't do off-topic very often, quite the release. +**\ [anominal]** Ok so if no thoughts on 5., +**\** LOL +**\** nobody is going to attend the Kovri meeting in future :-P +**\ [anominal]** LMAO +**\ * anonimal** watches ship sailing away, burning in the distance +**\ [EinMByte]** See you all next time in #dancing +**\ [anominal]** Ok, last call for 5. Discuss any pertinent TODO's +**\** I think that's it from my side +**\** lol EinMByte +**\ [anominal]** lol, or #dancing-dev +**\ [EinMByte]** Well, for 5: If anyone wants to start on the API, you're welcome +**\ [EinMByte]** This also applies to all (any?) monero people reading this +**\ [anominal]** Good point, that's another big item to tackle. +**\ [EinMByte]** Since you're going to be the people using the API, making up a list of requirements would be nice +***\** kk +**\ [anominal]** 6. Any additional meeting items +**\ [anominal]** Just one from me, briefly, +**\** I think we've already discussed EinMByte's dancing enough, so nothing more from me on 6 +**\ [anominal]** Forum Funding. I plan on writing up some proposals within the next month or so. +**\** kk +**\ [anominal]** EinMByte: if you were crowdfunded on FFS, would you be able to devote any more dev time? +**\ [EinMByte]** I've already told fluffypony, not really +**\ [anominal]** Ok. +**\ [EinMByte]** If you can build me a time machine, yes +**\ * anonimal** was planning proposals to fund my work +**\ [anominal]** Funny, fluffypony mentioned that earlier (time machine). +**\** lol +**\ [anominal]** We should invest in one. The writing is on the wall. +**\ [anominal]** Last call for 6. +**\** new project for the Monero Research Lab to tackle +**\ [EinMByte]** But, as I've also told fluffypony, please do fund other programmers +**\ [anominal]** Agreed. +**\ [EinMByte]** Apparently you first need the programmer (before getting the money) so let's go find some C++ programmers +**\ [anominal]** fluffypony: ^ we should devote an entire meeting to that IMHO sometime within the next few months. +**\** yeah definitely +**\** would love to see a FFS proposal for kovri/i2p dev +**\** 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 +**\ [EinMByte]** By the way, we don't need only expert C++ programmers +**\** and then we can raise funds accordingly +**\** i see +**\** been a while since ive check tbh +**\ [EinMByte]** We can use people who just write documentation / tests too +**\ [anominal]** ^ which is a great way for newcomers to learn the codebase. +**\** 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 +**\ [anominal]** Good concern, I think that's very plausible. +**\ [anominal]** But the devoted C person usually scoffs at C++ and turn their nose at Java. +**\** like hyc :-P +**\ [anominal]** I've become spoiled with STL so, I can't vouch for C devotees on more complex apps like Kovri. +**\ [anominal]** But bigger point: +**\ [anominal]** The world needs more options, so if Tor starts to burn, another ship will be ready. +**\ [anominal]** Some great minds there, so I'm not concerned about the near future. +**\ [anominal]** But that was a hefty loss on their end with the one who shall remain nameless. +**\** yeah, and the larger loss is how much emotional damage it did to people during the time it was kept hidden +**\** as a community I hope we can learn from that and call people out when they're out of line +**\ [anominal]** Yeah, everyone involved seems to have taken a loss. +**\ [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, +**\** 100% +**\ [anominal]** But, +**\ [EinMByte]** let's first get some people :) +**\ [anominal]** devs can be strong in their ways, so being malleable is also important (but that's a given). Constant ebb and flow. +**\ [anominal]** Anything else on 6.? +**\** that's it from my side +**\ [anominal]** 7. Confirm next meeting date/time +**\ [anominal]** Same time in two weeks? +**\ [EinMByte]** Nothing else from me +**\** yes same time in two weeks +**\ [anominal]** Alright. A million thanks to everyone. +**\** taking meeting-bot down \ No newline at end of file diff --git a/_posts/2016-06-19-overview-and-logs-for-the-dev-meeting-held-on-2016-06-19.md b/_posts/2016-06-19-overview-and-logs-for-the-dev-meeting-held-on-2016-06-19.md new file mode 100644 index 00000000..2035bf85 --- /dev/null +++ b/_posts/2016-06-19-overview-and-logs-for-the-dev-meeting-held-on-2016-06-19.md @@ -0,0 +1,225 @@ +--- +layout: post +title: Overview and Logs for the Dev Meeting Held on 2016-06-19 +summary: C4, open PRs, and brief update on Ring CT and 0MQ +tags: [dev diaries, core, crypto, 0mq] +author: dEBRUYNE / fluffypony +--- + +*June 19th, 2016* + +### Overview (by Aerbax) + +An overview [can be found on Hello Monero](https://hellomonero.com/article/monero-bi-weekly-dev-meeting-note-highlights-2016-06-19) + +### Logs + +**\** ok +**\** hello and welcome +**\** ack +**\** Sup fluffypony +**\** so first things first +**\** [anonimal] EinMByte: ^ Monero meeting now, Kovri in about an hour or so (just FYI) +**\** after the last meeting, which was mostly focused on C4, we bounced some of that around +**\** I think the spirit of C4 is good, and will help keep Monero inclusionary towards new contributors +**\** but moneromooo in particular disagreed with some of the specifics +**\** or where C4 is a little vague +**\** so what we're going to do is fork C4 from Unprotocols / yrashk into the Monero repo +**\** [psi] c4? +**\** and we'll tweak it from there, keeping it in step with changes made upstream in Unprotocols +**\** psi: the Collaborative Code Construction Contract, see last meeting's minutes for an intro and discussion +**\** [anonimal] Or Kovri's contributing guide. +**\** yup +**\** I think everyone is aware that this is security software we're dealing with +**\** and we can't be crazy and accept things that may contain backdoors +**\** 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 +**\** somewhere inbetween being completely permissive and miring contributions in PR hell is a nice balance, and we'll figure it out +**\** We need to balance security and making contributors welcome +**\** yup exactly +**\** ok so on to more fiddly code bits, less soft skills +**\** I was hoping tewinget could update us on the 0MQ work, which is about to go up on the forum for funding +**\** ok +**\** My point was not security, it was more about the crazy wish to keep obvious crap in. +**\** 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 +**\** ok +**\* fluffypony** plays hold music +**\* tewinget** is typing +**\* DaveyJones** just watches +**\** 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) +**\** that's more or less a summary of progress +**\** as far as process +**\** 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 +**\** tewinget: so using the structure that is / was on the Wikia ? +**\** [psi] to rehash, you are redoing monero's wire protocol to use zmq correct? +**\** psi: no, not wire protocol, that will use ZMTP (a part of the 0MQ project) and come later +**\** psi: more or less, but a bit more than just that +**\** oh +**\** I mean, kinda wire, but not p2p yet +**\** rpc +**\** this is redoing the communication between the node and "clients" like miners / mining pool software / wallets / etc. +**\** [psi] kk +**\** [psi] zmtp is still being drafted correct? +**\** nope all done, afaik: http://zmtp.org +**\** \ 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 +**\** it's already on v3 +**\** ok so maybe one of the things we need to do now is move that design doc from the Wikia to the Github wiki +**\** wallet42: are you up to doing that, or busy travelling atm ? +**\** 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 +**\** oh, one important detail I left out +**\** 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 +**\** and I know I don't personally plan to write libMonero for every language out there... +**\** 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 +**\** 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 +**\** 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 +**\** https://paste.fedoraproject.org/379294/14659488/ <-- there's an example of get_transactions +**\** it's also very nice to do ad-hoc testing via python :) +**\** cool +**\** any thoughts, anyone? +**\** 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 +**\** Especially better wiki documentation of the datatypes/protocol +**\** wiki.bitcoin.it/wiki/Protocol basically +**\** tewinget: how hard would it be to implement different schemes in future, like JSON / protobufs / ASN.1 BER ? +**\** wallet42: ok cool, thank you +**\** 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 +**\** it's already 90% ready for that as-is +**\** kk +**\** alright, tewinget anything else or can we move on to the next thing ? +**\** the ZMQ-side of things was pretty trivial tbh +**\** oh, anyone averse to having a separate listening port for publish/subscribe such as "new_block_notify" etc? +**\** you mean a separate port for pub-sub than the IPC port ? +**\** well, there will be a port for "request thing from daemon" +**\** can't use the same port for publish/subscribe, I'm pretty sure +**\** I don't see a problem with that +**\** without an unholy amount of added complexity that isn't worth at all +**\** one thing you may want to do is also look at Bitcoin's 0MQ effort +**\** I don't think wumpus is around at the moment +**\** but they've been pecking away at 0MQ for some time +**\** Isn't the point of 0MQ to abstract comms to allow things like that ? +**\** moneromooo: pub-sub is a different beast to control / request +**\** 0MQ uses different socket types like Request-Reply, or Pub/Sub +**\** normally for pub-sub you're sending a request once and then receiving "push" notifications forever +**\** 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? +**\** Bitcoin has walletnotify and blocknotify that work in that way +**\** so using the same port for req-rep and pub-sub would require...well, no, just no +**\** it would end up looking gross like the RPC stuff at the moment +**\** moreso, in fact +**\** different HTTP paths for the JSON and HTTP RPCs +**\** \ 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 +**\** cool if anything pops up over the rest of the meeting then we can see +**\** 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 +**\** https://www.github.com/tewinget/bitmonero/tree/zmq-dev +**\** ok next, moneromooo do you feel like giving an update on RingCT? looks like it's making nice headway :) +**\** It kinda works. I'm fixing bugs now. +**\** moneromooo: is it going to be a hard fork where all new transactions are v3 / ringCT, but they can spend pre-ringCT outs? +**\** They +**\** they = transactions +**\** coinbase will use non-ringct tho? +**\** othe: yes afaik +**\** They'll be v2 and can spend either pre rct outputs or rct ones. +**\** moneromooo: ooooh, so a soft fork? :-P +**\** Hmm. I haven't thought about the distinction tbh. +**\** Theoretically, coinbase might not even need to be in the clear I think. Though it'd require some shen magic. +**\** I think it'd be a hard fork, because old nodes won't understand rct outs +**\** so we'd have to bump the block version anyway +**\** But will non RingCT other than coninbase transactions be valid? +**\** Oh they'd reject new txes, yes. +**\** fluffypony: I'm thinking of an unprotocol for describing diverged unprotocols +**\** So meta +**\** moneromooo: ok then that's hard fork +**\** lol yrashk +**\** But I'm actually serious +**\** :) +**\** yrashk: what's that Unprotocol for creating protocols with consensus? +**\** ArticMine: I think post-fork that all non-coinbase tx will be ringCT, but I'm not sure. +**\** 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. +**\** fluffypony: COSS? There's nothing about consensus there +**\** yrashk: yes that - but it's about creating new protocols as a group, right ? +**\** Kind of but very very lightweight +**\** kk +**\** Which is a good thing generally +**\** Greetings fellas +**\** moneromooo: I tend to agree with you - coinbase txs is fine, but after that it should be rct only +**\** Crazyflashpie stoping by to say hello +**\** fluffypony: are you interested to collaborate on the protocol divergence protocol? (PDP) +**\** hi CFP +**\** Looks like the # of nodes in China is climbing? +**\** yrashk: let's chat after the meeting, definitely interested in discussing it, as it's relevant to us +**\** I can explain my motivations behind it +**\** Today? +**\** Ping me on telegram or here when ready +**\** kk +**\** ok next I just wanted to bounce through some open PRs +**\** #818 is still open pending luigi1111w / luigi1112 coming up with those spec changes, no rush there +**\** moneromooo I would expect non RingCT outputs other than coinbase to be invalid after a given block +**\** #775 is ready to be merged - moneromooo, just to double check, you're fine with that, right ? +**\** With the 6 month upgrade cycle built in +**\** ArticMine: agreed +**\** Yes I'll try to do that this week +**\** Yes. It's a wee bit spammier now in the logs, but other than that it's good to go. +**\** ok then #810, the caching thing, I'm still confused as to whether we must merge or not +**\** Not sure. I think enough said no. +**\** ok I'll close it, we can reopen later +**\** But then nobody patched the pool code :) +**\** and pools can manually pull that in if they need +**\** then the gcc 6.1 stuff - as I understand it there are more changes than what is covered in those two PRs +**\** so do we close the PRs and just note that "gcc 6.1 not supported yet" +**\ [anonimal]** Noooooooo......... +**\** or do we merge them in preparation for supporting 6.1 ? +**\ [anonimal]** Please nooooooo.... +**\** lol anonimal +**\** If they'll be needed anyway... +**\ [anonimal]** This also re: #846? +**\** One of them is a superset of the other IIRC. +**\** anonimal: yeah, 846 and 845 +**\ [anonimal]** radfish's work builds, so is the problem more eyes/more time to review? +**\** 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 +**\ [anonimal]** Oh, well I can spend some time this week giving input if that helps. +**\** 846 seems to be the superset. +**\** PR X is a superset of PR Y seems like an odd situation to be in... +**\** especially if both are open +**\** tewinget: quite +**\** I had to merge them to get the repo to compile as GCC 6.1 is default for Arch +**\** kk +**\ [anonimal]** re: that ^, I only merged #846 and builds fine. +**\ [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. +**\** Yep, only needed #846. @tewinget should enable testing repo too :) +**\** ok then I'll close 845 and merge 846 +**\ [anonimal]** Ok. +**\** then #856 I've reviewed and will merge +**\** #855 seems fine to me, I defer to hyc's knowledge of his own product ;) +**\** #863 seems fine too +**\** #862 - luigi1112 can I take your comment as a review? +**\** Oh. Let me change it now... +**\** 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? +**\** I think it's fine yeah +**\** pushed +**\** k +**\ [anonimal]** Has there been any definitive decisions re: C4 since previous meeting? I know there are differing arguments. +**\** anonimal - yes, my comments at the beginning of the meeting, will let you know when the log is up if you missed them +**\** gingeropolous: not entirely sure what you mean to ask there +**\ [anonimal]** "we'll figure it out" <-- was that it? +**\** i.e., port 18081 would be full access, and 18082 could be less access. +**\** anonimal: yes basically the next step is fork ->** adjust accordingly ->** decide to abandon or adopt the iteration +**\** right now if you want different permissions for remote access to the daemon, you need multiple daemons and multiple databases +**\** isnt an auth system with permissons better for this +**\** gingeropolous: I'm of a mind that we need a finer distinction than "trusted daemon" and "not trusted" +**\** we need a proper ACL +**\** what othe said +**\** so shelve it as a thing to do later on +**\** word +**\** ok I think that's it from my side - anything else before we move to the Kovri meeting? +**\** glad someone else could answer that while I was rebooting. Stupid computer crashes frequently, pretty sure it's hardware. +**\** tewinget: you should buy a Mac :-P +**\** No +**\** fluffypony: I thought we were friends... +**\** 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 +**\** but I'd never buy one, they're way too expensive for what they are. +**\** actually the macbook pro are good value for money compared to other ultrabooks; anyway kovir next :p +**\** Pro Retina is great, although I've switched my Purism Librem 13 + Qubes for anything remotely sensitive +**\** Hackintosh user here :-) It's pretty easy to install OSX if you choose hardware carefully. +**\** works pretty much perfectly. +**\** correct, also run a hackintosh desktop +**\** I see the software not the hardware as the issue with Mac +**\ * anonimal** has 8 year old hackbook pro running Arch :/ +**\ [anonimal]** Still alive, surprisingly. +**\** nice \ No newline at end of file diff --git a/_posts/2016-06-20-monero-missive-for-the-week-of-2016-06-20.md b/_posts/2016-06-20-monero-missive-for-the-week-of-2016-06-20.md new file mode 100644 index 00000000..73f3c404 --- /dev/null +++ b/_posts/2016-06-20-monero-missive-for-the-week-of-2016-06-20.md @@ -0,0 +1,20 @@ +--- +layout: post +title: Monero Missives for the Week of 2016-06-20 +summary: A discussion of the rationale behind rolling hardforks and the C4 code contract +tags: [monero missives, external] +author: Riccardo Spagni (fluffypony) +forum: https://forum.getmonero.org/1/news-announcements-and-editorials/2568/monday-monero-missives-33-june-20th-2016 +--- + +
+ +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* diff --git a/_posts/2016-07-03-logs-for-the-Kovri-dev-meeting-held-on-2016-07-03.md b/_posts/2016-07-03-logs-for-the-Kovri-dev-meeting-held-on-2016-07-03.md new file mode 100644 index 00000000..f528dad1 --- /dev/null +++ b/_posts/2016-07-03-logs-for-the-Kovri-dev-meeting-held-on-2016-07-03.md @@ -0,0 +1,248 @@ +--- +layout: post +title: Logs for the Kovri Dev Meeting Held on 2016-07-03 +summary: Brief review of what has been completed since last meeting, SSU refactoring, closed and open issues +tags: [dev diaries, i2p, crypto] +author: dEBRUYNE / fluffypony +--- + +*July 3th, 2016* + +### Logs + +**\** ok I guess we move on to Kovri - anonimal, the floor is yours +**\* fluffypony:** ding dings +**\ [anonimal]** Meeting Agenda: Sunday, July 3rd, 17:00 UTC +**\ [anonimal]** 1. Greetings +**\ [anonimal]** 2. Brief review of what's been completed since the previous meeting +**\ [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) +**\ [anonimal]** 4. Discuss commit message labeling, e.g., how to organize first line of commits. Touch-up on C4. +**\ [anonimal]** 5. Review open tickets (assigned and/or unassigned): status, code ideas (if applicable), etc. +**\ [anonimal]** 6. Discuss any pertinent TODO's +**\ [anonimal]** 7. Any additional meeting items +**\ [anonimal]** 8. Confirm next meeting date/time +**\ [anonimal]** -- 1. Greetings +**\ [anonimal]** Hi +**\** hi +**\** hi +**\ [anonimal]** I know Ein is irc2p side waiting for me to move on :) +**\ [anonimal]** 2. Brief review of what's been completed since the previous meeting +**\ [fluffypony]** I'm on this side too +**\ * anonimal** wishes this was automated. /pulse only does so much +**\ [anonimal]** 28 commits (not including merges), 2 new issues open, 0 issues closed +**\ [anonimal]** All new commits in https://github.com/einmbyte/kovri/tree/ssu +**\ [anonimal]** I ended up diving into SSU with EinMByte this week. Much fun. +**\ [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. +**\ [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. +**\ [anonimal]** Anyone else re: completed work since previous meeting? +**\ [fluffypony]** I've been focused on the OTF funding stuff, so I haven't had a chance to finish the website work +**\ [fluffypony]** pushing that out till the next meeting, unless we have to prepare more stuff for the OTF +**\ [anonimal]** Ok. Any new issues re: OTF? +**\ [anonimal]** Seems like they've had a few lately. +**\ [anonimal]** i.e., did we get confirmation that they received our request? +**\ [fluffypony]** no I think the next step is we'll receive a pass / fail on the concept note +**\ [fluffypony]** yes we did +**\ [_trump2016]** OTF will make kovri great again! +**\ [anonimal]** Confirmation, good. +**\ [anonimal]** Anyone freenode-side? Is xmrpromotions there? +**\ [fluffypony]** so if we receive a pass we have to prepare an actual proposal +**\ [fluffypony]** but let's see when we get there +**\ [fluffypony]** (if) +**\ [fluffypony]** they were on Reddit the other day, they seem to be busy at the moment +**\ [fluffypony]** they've asked for assistance on the gnu-social thing +**\ [anonimal]** Link? What kind of assistance? I'd be happy to help. +**\ [fluffypony]** I'll have to find it and send it to you post-meeting +**\ [anonimal]** Ok. Anything else on 2.? +**\ [fluffypony]** oh found it, nevermind: https://www.reddit.com/r/Monero/comments/4qywbx/what_are_moneros_pain_points_marketing_design/d4x34p3 +**\ [fluffypony]** nein +**\ [anonimal]** fluffypony: Thanks, I'll look into it later. +**\ [anonimal]** Moving on, +**\ [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) +**\ [anonimal]** So, https://github.com/EinMByte/kovri/pull/1 has been merged +**\ [anonimal]** EinMByte: will you allow issues tracking within your repo? It would help with this bug we're hunting. +**\ [anonimal]** Oops, old paste, we fixed the bug, +**\ [anonimal]** but are still dealing with related issues. +**\ * anonimal** knows Ein is somewhere, we were chatting elsewhere during the bitmonero meeting +**\ [EinMByte]** Hi +**\ [anonimal]** Maybe he still thinks its the previous meeting... +**\ [anonimal]** Hi +**\ [EinMByte]** Yes, I will allow all contributions to my repo +**\ [EinMByte]** Latest issue is: we are sending out broken packets +**\ [fluffypony]** issue tracking has to be explicitly enabled for the repo, EinMByte +**\ [EinMByte]** (but at least the segfault is fixed) +**\ [fluffypony]** it's a setting in github somewhere +**\ [anonimal]** ^ what fluffypony said +**\ [anonimal]** EinMByte: are we in a committable stage for the segfault fix? So I can see where we stand? +**\ [EinMByte]** anonimal: Already committed +**\ [EinMByte]** fluffypony: somewhere where +**\ [anonimal]** I imagine we're sending bogus packets in SessionRequest +**\ [fluffypony]** I'll check +**\ * anonimal** fetching +**\ [EinMByte]** fluffypony: Never mind, I think I got it +**\ [fluffypony]** if there's time, anonimal, can you please explain what SSU is for those who are observing the meeting ? +**\ [anonimal]** Ok, latest commit makes sense. +**\ [anonimal]** Yes, +**\ [anonimal]** tl;dr, in plain english, +**\ [anonimal]** it is one of two transport mechanisms closest to the IP layer: +**\ [anonimal]** NTCP is for TCP, SSU is for UDP. +**\ [anonimal]** SSU essentially takes care of encryption and negotiation with peers at the UDP level. +**\ [anonimal]** Does that make sense, or should I explain more? +**\ * anonimal** fetches link +**\ [anonimal]** Specification here: https://geti2p.net/spec/ssu +**\ [anonimal]** Overview here: https://geti2p.net/en/docs/transport/ssu +**\ [EinMByte]** In case anyone is really listening: we are rewriting the SSU implementation because +**\ [EinMByte]** 1) It doesn't allow for unit tests +**\<__uguu__>** i2p needs a better udp transport +**\ [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) +**\ [anonimal]** X) it was an unmaintainable nightmare, like much of the codebase that we have yet to refactor. +**\ [EinMByte]** __uguu__: It probably does, so let's hope SSU2 will be better +**\ [EinMByte]** (I'm not sure what the satus on SSU2 is, AFAIK there's not even a spec yet) +**\ [anonimal]** I had some ideas/problems/solutions when working on everything this week, +**\ [anonimal]** but I need more time to flesh out tangible thought. +**\ [anonimal]** I think we're on the right track, as we discussed earlier. +**\ [EinMByte]** Ok, no problem. Maybe write everything down on github? +**\ [anonimal]** Sure, I'll comment more in #140 or open an issue in your repo. +**\ [anonimal]** Essentially, I want to take a closer look at design this week as I said I would stay away when we last spoke. +**\ [anonimal]** e.g., what we discussed earlier about MAC buffer, etc. +**\ [EinMByte]** Yes, in terms of design many things are currently undecided +**\ [EinMByte]** I've mentioned before that this is more of a refactoring than a rewrite +**\ [anonimal]** Hmm... maybe I have a different vision of end-result then. +**\ [EinMByte]** At least for now, I do want design changes in the end +**\ [EinMByte]** But I wanted to make it less crappy first, and then make it good +**\ [anonimal]** I think I need to get my hands dirty and get more intimate with your new changes. +**\ [anonimal]** I understand, as I said in #1 I completely understand and agree. +**\ * anonimal** no complaints here +**\ [anonimal]** So, long story short, I'd like to get more involved. Any objections EinMByte? +**\ [EinMByte]** Of course not, I can use all help +**\ * anonimal** could work in another branch, but I think our conflicts result in better code +**\ [anonimal]** Ok, I'll comment more in #140, etc. as things progress. +**\ [anonimal]** Anything else on 3.? +**\ [EinMByte]** Not from me +**\ * anonimal** prepares for more pasting +**\ [anonimal]** Anyone here have more SSU questions? +**\ * anonimal** will work on refining better responses to such questions +**\ [fluffypony]** no that's perfect, thanks +**\ [anonimal]** Ok, moving on +**\ [anonimal]** 4. Discuss commit message labeling, e.g., how to organize first line of commits. Touch-up on C4. +**\ [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. +**\ [anonimal]** But our guide does ask to reference applicable ticket numbers in commit bodies - and its incredibly helpful. +**\ [anonimal]** I'm trying to be better about doing this and I hope EinMByte would also consider doing this too. +**\ [anonimal]** It should be noted that there is no mention in the guide or C4 about commit title. +**\ [anonimal]** I've been using a rough system of prepending titles with class or aspect of project worked on. +**\ [anonimal]** It does help for quick git-log searches. Again, not enforceable, but it does help IMHO. +**\ [anonimal]** Thoughts? Objections to adding to guide? +**\ [fluffypony]** can you give me an example of the prepending? +**\ [anonimal]** Yes, one moment. +**\ [EinMByte]** anonimal: I've noticed that you tend to include a longer summary +**\ [anonimal]** fluffypony: Basically what's before the colon https://github.com/EinMByte/kovri/pull/1 +**\ [EinMByte]** I currently don't do that, but if you think it's worth it, I can start doing that +**\ [EinMByte]** Other than that, the main thing should be that it should be reasonably clear what the commit is about +**\ [fluffypony]** oh yeah that's cool +**\ [EinMByte]** But we all do that already +**\ [EinMByte]** I'm fine with stricter rules, just don't shout at me too much when I forget about them :p +**\ [fluffypony]** I tend to do short summaries too, but I like the prepending thing +**\ [anonimal]** EinMByte: I agree. If I were to ask of anything, it would be to references issues that commit addresses. +**\ [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. +**\ [anonimal]** So, as usual, I think about everyone else who isn't knee-deep in our mess. +**\ [anonimal]** And maybe longer summaries would help? +**\ [anonimal]** But 4. for me was more about commit title. +**\ [EinMByte]** Ok, I'll try to reference issues more often +**\ [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 +**\ [EinMByte]** (not in the title, though) +**\ [anonimal]** Ok. So shall we take a vote on adding 'prepend class or project aspect into title of commit' into contributing guide? +**\ [anonimal]** (again, at this time not enforceable - just helpful) +**\ [fluffypony]** I'm fine with it +**\ [anonimal]** + me = 2 yes. Anyone else? +**\ [anonimal]** As fluffypony pointed out long ago, its not like anyone reads contributing guides anyway ;) +**\ [fluffypony]** hah hah yeah +**\ [EinMByte]** Sure +**\ [fluffypony]** but at least it's there and we can encourage it +**\ [EinMByte]** ^ +**\ [anonimal]** Ok, good point on the encouragement. +**\ [fluffypony]** hey - we managed to get most Monero contributors to GPG sign commits, so it is doable :) +**\ [anonimal]** Great, done. +**\ [anonimal]** While we're on 4., this is off-the-cuff, +**\ [anonimal]** but bitmonero is working with only 1 branch now. +**\ [anonimal]** And, C4 kind of dictates that (IIRC). +**\ [anonimal]** So, do we scrap branch development and work solely in master? +**\ [fluffypony]** note that we have a use-case for moving back to the dev branch setup, because people just pull and compile +**\ [anonimal]** I've also used arguments for two branches. I'm curious to hear EinMByte's opinion. +**\ * anonimal** sigh, I2P lag +**\ * anonimal** doesn't want to move on yet, running out of time though +**\ [EinMByte]** anonimal: Not sure, I think it's good to have a stable branch +**\ [EinMByte]** also, it doesn't hurt anyone? (I think) +**\ [anonimal]** The argument is to instead warn users that anything that is built outside of a tagged version is... well, unpredictable. +**\ [anonimal]** But, since we don't have any releases yet... +**\ [EinMByte]** There's "unpredictable" and there's "possibly broken" +**\ [EinMByte]** In my opinion those are not really the same +**\ [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. +**\ [anonimal]** But then that would require more work maintainer-side. +**\ [anonimal]** Ay, too many options. +**\ [anonimal]** I vote to keep two branches for now. +**\ [anonimal]** Yea or Nay? +**\ [EinMByte]** ok, let's keep the branches and move on :) +**\ [anonimal]** Ok, moving on. +**\ [anonimal]** 5. Review open tickets (assigned and/or unassigned): status, code ideas (if applicable), etc. +**\ [anonimal]** My hands have been tied to SSU as we've discussed. I did hack a fix for the massive leak in #191. +**\ [anonimal]** It appears to be related to LogPrint and possibly GetFormattedSessionInfo(). I need more time with it and to produce a smoother fix. +**\ [anonimal]** But it doesn't address a few smaller leaks related to #191. +**\ [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. +**\ [anonimal]** And in that order. +**\ [EinMByte]** Ok +**\ [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. +**\ [fluffypony]** +1, FFS proposals are welcome +**\ [anonimal]** EinMByte: do you think you'll be around sometime this coming week or the following week? Or are weekends better? +**\ [anonimal]** fluffypony: would you please refresh my memory on the zoho/fastmail decision (my brain is scattered at the moment)? +**\ [EinMByte]** I'll be around a few hours a day, but more actively in weekends +**\ [fluffypony]** started the process a few days ago, we're doing Zoho +**\ [anonimal]** EinMByte: sounds great. +**\ [anonimal]** fluffypony: sounds great. +**\ [anonimal]** Many great sounds! +**\ [fluffypony]** everyone can independently forward their mails to tutanota or i2pmail, or just use the Zoho mailbox +**\ [anonimal]** I'm looking forward to zoho's /projects, especially time-management. +**\ [anonimal]** Kimai is a horrid *#()*@#)$@#$#@ +**\ [anonimal]** If anyone has experience using it... +**\ [fluffypony]** never heard of it, will take a look +**\ [fluffypony]** or not if it's horrible +**\ * anonimal** surprised at the lack of free, personal, opensource, time-management/billable hours solutions out there +**\ [fluffypony]** MS Project +**\ [anonimal]** IMHO you should, it may be humorous. +**\ [fluffypony]** :-P +**\ [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. +**\ [fluffypony]** is it meeting.end time? +**\ [anonimal]** Eek, one more thing. +**\ * anonimal** one more paste coming +**\ [anonimal]** 6. Discuss any pertinent TODO's +**\ [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. +**\ [anonimal]** I had mentioned in the most recent PR my interest in more sanity tests, and EinMByte did note a few overflow checks. +**\ [anonimal]** I think we're still discussing design though, so that would come a little later. +**\ [anonimal]** Thoughts? +**\ [EinMByte]** Yes, we have many places where we need more checks +**\ [EinMByte]** at least we won't leak if we throw errors etc due smart pointer usage +**\ [EinMByte]** Eventually I want to rely on exception for error handling, and I want to use the error information for peer profiling +**\ [anonimal]** Ooooooooooooooo, I like that...... +**\ [anonimal]** I like that ALOT. +**\ [anonimal]** Yes, smart pointers: something the previous project had very little interest in; +**\ [anonimal]** despite the standard having been out for years. +**\ [anonimal]** Anyway, I won't start bashing as we're out of time (I love a good bashing). +**\ [anonimal]** Anything else on 6.? +**\ [anonimal]** If not, then 7.? +**\ [fluffypony]** nothing else from my side +**\ [fluffypony]** next meeting same time, same place, two weeks? +**\ [anonimal]** Works for me. +**\ [EinMByte]** Should be fine +**\ [fluffypony]** sehr gut +**\ [zzz]** will we see any kovri ppl at HOPE in 3 weeks? +**\ [fluffypony]** zzz: unfortunately not me, need to do no travelling for a little bit +**\ [fluffypony]** got too much work to do, lol +**\ [EinMByte]** not me either +**\ [anonimal]** I had planned late last year but things took a completely different turn so, nope, not this time around. +**\ [zzz]** ok, I believe echelon still has a ticket to sell, if anybody needs it +**\ [anonimal]** Thanks zzz. That echelon, quite the organizer :) +**\ [anonimal]** Anything else? Meeting? +**\ [anonimal]** I want to also thank fluffypony and dEBRUYNE and anyone else for their work on getting these logs up on the site. +**\ [fluffypony]** it's mostly dEBRUYNE, I just add spaces in at the end +**\ [anonimal]** lol, nice. +**\ [anonimal]** Ok, thanks everyone for the great meeting. +**\ [fluffypony]** thanks everyone +**\ [fluffypony]** meeting-bot going offline diff --git a/_posts/2016-07-03-overview-and-logs-for-the-dev-meeting-held-on-2016-07-03.md b/_posts/2016-07-03-overview-and-logs-for-the-dev-meeting-held-on-2016-07-03.md new file mode 100644 index 00000000..e02b7611 --- /dev/null +++ b/_posts/2016-07-03-overview-and-logs-for-the-dev-meeting-held-on-2016-07-03.md @@ -0,0 +1,132 @@ +--- +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 + +**\** time for meeting to start +**\** ok +**\** Ok +**\** ArticMine / othe / smooth / NoodleDoodle / moneromooo / tewinget / dEBRUYNE / gingeropolous / etc. +**\** somewhat here +**\** ok +**\** welcome to the 75th annual hunger games +**\** ok so +**\** first things first, small administrative update +**\** we've re-applied for funding from the OTF, but for Kovri (given their previous response) +**\** it's the start of the process, but who knows, maybe we have a bit of funding to work on both +**\** as Monero represents an example integration +**\** then the open issues are creeping up, there are a bunch I'm going to be closing as solved +**\** #754 is an interesting onw +**\** *one +**\** https://github.com/monero-project/bitmonero/issues/754 +**\** We don't care now, since rct. +**\** good point +**\** ok so then it can be closed as wontfix +**\** Well, it's fixed, by transfer_new. +**\** yes +**\** so +**\** I'd like to reopen the discussion of deprecating transfer and replacing it with transfer_new +**\** or is that pointless because rct +**\** I've done that in the rct branch. +**\** ok great +**\** perfect +**\** then binary renames are on hold until the rct PR +**\** because I don't want to make that implode +**\** what renames? +**\** I don't think this would conflict much, if at all. +**\** bitmonerod --> monero and stuff like that prolly +**\** hyc: https://github.com/monero-project/bitmonero/issues/80 +**\** this in particular: https://github.com/monero-project/bitmonero/issues/80#issuecomment-223596750 +**\** ah +**\** moneromooo: do you want me to PR changes to your branch then? will save you a rebase? +**\** Sure. +**\** ok great +**\** Would rct be merged before the wallet2_api stuff then ? +**\** so that's the next thing for discussion +**\** the massive wallet2 PR +**\** it's rebased against master now +**\** moneromooo: what are your thoughts on merging before or after ? +**\** I don't really have one. +**\** Maybe merge Ilya's first, since there's not going to be much review/fixes anyway. +**\** ok +**\** so wallet2 a buncha stuff specifically designed for GUI? +**\** wallet2_api is. +**\** 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? +**\** Depends on how high you put the bar. +**\** moneromooo: it's low - we can open issues to fix stuff after the merge +**\** But assuming the GPL code is gone, I think it's ok. It can be changed later. +**\** oh the GPL cmake stuff, I'll check on that +**\** looks like there's a BSD licensed replacement now +**\** I saw the comment, I did not look at the new code. +**\** hokay +**\** then there are a bunch of new PRs if anyone wants to take a glance at them +**\** #878, #879, #882, #883, #884, #885 +**\** they're mostly small +**\** I need someone to check mine (885, just a readme change) before merging plx +**\** huh i only see up to 881 +**\** oh PRs not issues +**\** I seem to have reviewed all these, except the windows packages one which I have no clue about. +**\** it compiled successfully +**\** couple of weird complaints about deprecations at the end +**\** 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 +**\** # pragma message("NOTE: Use of this header (template_arity_spec.hpp) is deprecated") +**\** +**\** I've been getting that on most builds now +**\** boost 1.60 +**\** ah +**\** boost, sigh. +**\** not sure what there is to do about that since it's an internal header file, not one thata we explicitly include +**\** http://permalink.gmane.org/gmane.comp.lib.boost.devel/264164 +**\** fixed in 1.61 +**\** ok +**\** ok so +**\** general update-y time +**\** tewinget doesn't seem to be around, he can update us on 0MQ when he is +**\** moneromooo: how goes ringct? +**\** I'm kinda blocked today, so I didn't do much. +**\** I mean in the last two weeks since the last meeting, lol +**\** Both that watch only thing that nobody wants to talk about, and waiting for shen's sybil resistant upgrade. +**\** kk +**\** Well, last two weeks, more tests, fixes, sweep_all now uses rct, and better output selection (for the general case). +**\** does rct let us do watch only with both deposits and withdrawals? +**\** No. +**\** this sorta bounces back to the MRL, so we wait for feedback +**\** hyc: are you doing anything interesting at the moment? +**\** not really. I still need to come up with a fix for txn_full on 32bit +**\** I'm traveling most of the the rest of this month +**\** so not much hacking time +**\** cool beans +**\** ok - anything else from anyone else? +**\** Hi +**\** :-) +**\** If anyone wants to start reviewing the rct-rptest branch, I don't think it's going to change again (save new commits). +**\** Like, find how to pwn it. +**\** oh luigi1112 I forgot to tag you at the beginning, apologies +**\** Would be a good job for Heuristic, except there's no picture of hte code... +**\** Oh, some other dev related thing: luigi1112, any news on the change to signing something from a standard address ? :) +**\** Nah I've been reading but don't have any time to participate atm +**\** Oops :-) +**\** Still soon +**\** you forgot the tm +**\** it's not soon if it's not tm +**\** Well it should be this week or next :-) +**\** 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 +**\** i got nothing, catch y'all next time +**\** any new thoughts on the auto fee thing? +**\** id like to bring up the most imporant issue, fluffypony -- free XMR for me +**\** gingah: auto fee? +**\** The thing ArticMine was looking at - scaling fees based on... stuff. +**\** Setting fees based on the blocksize +**\** and the reward penalty +**\** One also has to look at optimizing what transactions miners will accept vs block penalty and fees paid diff --git a/_posts/2016-07-31-logs-for-the-Kovri-dev-meeting-held-on-2016-07-31.md b/_posts/2016-07-31-logs-for-the-Kovri-dev-meeting-held-on-2016-07-31.md new file mode 100644 index 00000000..dfcb6f96 --- /dev/null +++ b/_posts/2016-07-31-logs-for-the-Kovri-dev-meeting-held-on-2016-07-31.md @@ -0,0 +1,127 @@ +--- +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 + +**\** ping fluffypony we missed you in #monero-dev +**\** I'll proceed with the meeting as planned but the bulk of the agenda is picking on your assigned issues. +**\** https://github.com/monero-project/kovri/issues/216 +**\** Meeting Agenda: Sunday, July 31st, 17:00 UTC +**\** 1. Greetings +**\** 2. Brief review of what's been completed since the previous meeting +**\** 3. Discuss Kovri logo +**\** 4. Closing #271 +**\** 5. Closing #226 +**\** 6. Closing #105 +**\** 7. Closing #46 +**\** 8. Closing #27 +**\** 9. Any additional meeting items +**\** 10. Confirm next meeting date/time +**\** Hi. +**\ {-needmoney90}** * walks into the room and sits in the nearest available seat +**\ {-needmoney90}** Just watching for today +**\** 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. +**\ {-_Slack} \** It appears so +**\ {-_Slack} \** I2P, Slack, and IRC are all relaying +**\** K, thanks. +**\** Onto point 2. +**\** $ git log --no-merges --pretty=oneline --since=1.month | wc -l +**\** 72 +**\** Code highlights include: +**\** - Mem leak fixes +**\** - New constant-time comparison for ed25519 +**\** - Two new contributors: moneromooo and rakhimov +**\** (hopefully will see more from both devs) +**\** - regex fix, clang fixes +**\** - A whole lot of build/repo work +**\** - We officially build with clang +**\** - We officially build on OSX again +**\** - Two new submodules: cpp-netlib, cryptopp +**\** - New URI parsing implementation courtesy of cpp-netlib +**\** - New clang-format config (still in development) +**\** - Updated style guide + building instructions + docs +**\** - Upstream bug hunting/fixing (huge time-suck) +**\** - Coverity's website finally works (for me) +**\** - Misc fixes, enhancements +**\** Project highlights include: +**\** - Kovri End-User Documentation Proposal - #256 +**\** - 9 new opened issues, 7 new closed issues +**\** - Creation of @kovri@quitter.se +**\** - I've also spent some time with bitmonero/monero-project +**\** That's all from me for 2. Anyone else? +**\** Ok, guess not. +**\** fluffypony fluffypony fluffypony fluffypony +**\ {-needmoney90}** * summons fluffypony from the depths +**\** 2nd meeting in a row he's missed. I hope he's alive. +**\ {-needmoney90}** D: +**\** I know this is opensource and volunteer but I'm getting a bit irritated. +**\** Being stood up is not very respectful. +**\ {-needmoney90}** oh he isnt in this room +**\ {-needmoney90}** summoning wont work from here +**\** lol needmoney90 +**\ {-needmoney90}** He isn’t even on IRC it seems +**\ {-needmoney90}** hm +**\ {-needmoney90}** thats strange, Im used to him being always on/ide +**\ {-needmoney90}** idle +**\** He's on irc2p side. +**\** Is dEBRUYNE on freenode side? Is this meeting even being logged? +**\ {-needmoney90}** Well, Slack is certainly logging it +**\ {-needmoney90}** and my client possibly is +**\ {-needmoney90}** havent checked logging settings +**\** so is my client +**\** Ok. +**\** Moving on to 3. +**\** "Discuss Kovri logo" +**\** Who did Monero's logo? +**\* anonimal:** asked in #monero-dev, no response +**\** Any thoughts on a logo for Kovri? +**\** How about a nude porn star holding a letter 'K'? +**\ {-needmoney90}** I've been thinking about it +**\ {-needmoney90}** and….I don’t think that will get us corporate/mainstream usage +**\ {-needmoney90}** then again, maybe it will +**\ {-needmoney90}** keep it on the backburner +**\** lol +**\* anonimal:** was joking +**\ {-needmoney90}** I’ve been thinking some kind of K made of nodes (like the Ethereum Classic logo), but fading out on half +**\ {-needmoney90}** though its probably too complex +**\ {-needmoney90}** https://camo.githubusercontent.com/eec95efca3ae789116e4557656898ab52ca74cba/687474703a2f2f63646e2d696d616765732d312e6d656469756d2e636f6d2f6d61782f3830302f312a6e4955617a775f75334b436843583839664c674c44672e706e67 +**\** Sounds cool. +**\** DaveyJones pointed this out https://99designs.de/logo-design/contests/monero-mro-cryptocurrency-logo-design-contest-382486 +**\** needmoney90: could that url get any longer?... +**\** Ah, I see. Interesting idea needmoney90 +**\** Maybe we should hold a contest and reward the winner with XMR? +**\ {-needmoney90}** Sorry about the URL length, I copypasta’d without minifying +**\** Np. +**\** Where would be a good place to host a Kovri logo contest? +**\** (XMR friendly place) +**\** I'll open a ticket and we can deal with it later +**\** Points 4-8 are all fluffypony +**\** 9. Any addition meeting items +**\ {-needmoney90}** None here +**\** 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. +**\ {-needmoney90}** SSU? +**\** No shows at meetings + no pay != motivation for me to do lifting beyond what I'm doing. +**\* anonimal:** grabs link for needmoney90 +**\** needmoney90: #140 +**\ {-needmoney90}** tanks +**\** I'll make myself available for the next 30 minutes and then paste a link to the meeting log in #216 +**\ {-needmoney90}** I’m really curious where fluffy got off to.. +**\** We were chatting about an hour before monero's meeting was supposed to start +**\** Maybe he simply forget. This has happened several times in the past. +**\ {-needmoney90}** :( +**\ {-_Slack} \** needmoney90: is there a way to easily export channel logs here? +**\ {-_Slack} \** hrmmm +**\ {-_Slack} \** I just exported +**\ {-_Slack} \** should have the logs (from all channels) in my email soon +**\ {-_Slack} \** barring that, someone's IRC client logs will work +**\ {-_Slack} \** 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? +**\ {-_Slack} \** no idea +**\ {-_Slack} \** ill let you know +**\ {-_Slack} \** Thanks. For the time being I'll just do a quick format of my logs to takeout timestamps and paste the meeting. diff --git a/_posts/2016-07-31-overview-and-logs-for-the-dev-meeting-held-on-2016-07-31.md b/_posts/2016-07-31-overview-and-logs-for-the-dev-meeting-held-on-2016-07-31.md new file mode 100644 index 00000000..f2a32677 --- /dev/null +++ b/_posts/2016-07-31-overview-and-logs-for-the-dev-meeting-held-on-2016-07-31.md @@ -0,0 +1,79 @@ +--- +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 + +**\** time for meeting to start +**\ {-anonimal}** Are we not having a meeting? +**\** I was wondering the same thing +**\ {-anonimal}** Kovri meeting at 17:00. I thought we were meeting at 16:00. +**\ {-anonimal}** fluffypony: ^ +**\** For Monero +**\ {-anonimal}** Yes +**\ {-anonimal}** * disappointed +**\** Maybe he died +**\** We could meet without him if people have stuff to say :-) +**\** 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 ? +**\** Preferably corner cases. +**\** How many testnet nodes are there? +**\** I think three. +**\ {-anonimal}** I would but I don't have a reliable VPS at the moment. +**\** I can set at testnet node. What are the stiings +**\** settings +**\** bitmonerod --add-exclusive-node 176.9.17.19:28080 --testnet +**\** And you need to have built with my rct-private-fork branch. +**\** And make sure you backup your db and wallet first, as they won't be compatible with "normal" version once you run rct code. +**\** https://github.com/moneromooo-monero/bitmonero/tree/rct-private-fork is the branch to use. +**\** Actually, use https://github.com/moneromooo-monero/bitmonero/commit/58ea23fa144b9eaec506461f96649d0c7b4b3914 +**\** Latest has an incompatible comms change. +**\** Great I will give this a try. Is there a test net db or sync from scratch +**\** If you don't have a testnet db already, you will have to sync. +**\ {-anonimal}** #903 has gotten some momentum. Is it too soon to come to an agreement? +**\** Can't hurt I think. +**\ {-anonimal}** So we need a name. moneromooo any thoughts? +**\<_Slack> \** Bond. James Bond. +**\** I've seen two names proposed already. I don't have a better idea. +**\<_Slack> \** (What are we naming again?) +**\** A repo, AFAICT. +**\ {-anonimal}** neemoney90: #903 +**\<_Slack> \** Repo-y McRepoface +**\ {-anonimal}** luigi1112 any thoughts? +**\ {-anonimal}** ArcticMine ^ +**\<_Slack> \** My thoughts submitted +**\** monero-organization for #903 +**\** That sounds good. +**\ {-anonimal}** Ooo, I like that best. +**\ {-anonimal}** ArcticMine will you comment in issue or I can copy/paste? +**\** You can copy past, I may comment. +**\** copy/paste +**\ {-anonimal}** K, done. I also like monero-project/organization. +**\** That is also good +**\ {-anonimal}** Kovri end-user documentation proposal is in open tasks +**\** Actually better than my original idea +**\ {-anonimal}** https://forum.getmonero.org/7/open-tasks/2592/create-end-user-kovri-documentation +**\ {-anonimal}** The problem with the forum is that its somewhat obscure and I don't get emailed notifications. +**\ {-anonimal}** So obscurity = less funding. No notifications = more babysitting. +**\ {-anonimal}** An org repo can help with things like this, imho. +**\** maybe monero-project/org +**\** org can be confused with .org Just a thought +**\ {-anonimal}** Agreed. How about https://github.com/monero-project/community +**\ {-anonimal}** Or is that too vague? +**\** I thing community is too broad. +**\ {-anonimal}** Kovri meeting in 3 minutes. +**\ {-anonimal}** I'm hopping over to #kovri-dev +**\ {-anonimal}** I wish the relay bot was online. +**\** One could say organizational +**\ {-anonimal}** I would say have it here but I don't know who is freenode side. +**\ {-anonimal}** If anyone is interested in talking about a logo for Kovri, could you please hop over to #kovri-dev? +**\ {-anonimal}** I don't know if dEBRUYNE is logging our meeting so I or slack will be taking care of it. diff --git a/_posts/2016-08-14-overview-and-logs-for-the-dev-meeting-held-on-2016-08-14.md b/_posts/2016-08-14-overview-and-logs-for-the-dev-meeting-held-on-2016-08-14.md new file mode 100644 index 00000000..c8ace378 --- /dev/null +++ b/_posts/2016-08-14-overview-and-logs-for-the-dev-meeting-held-on-2016-08-14.md @@ -0,0 +1,421 @@ +--- +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 + +**\** moneromoo: rewview guidelines? +**\** wallet42: well, whatever you feel comfortable with. Do you have anything in mind ? +**\ {-anonimal}** Is there a meeting in a few minutes? +**\** The most important is potential for exploits. +**\** Yes. +**\** awesome +**\** Well, assuming the pony isn't too busy with mymonero. +**\** get your notepads out everyone. time to take notes on the competition +**\ {-anonimal}** Which competition? +**\** I think he just meant dash is still around. It's another crypto (ex darkcoin). +**\** \ Well, assuming the pony isn't too busy with mymonero. <= he was online 20 min ago, fwiw :p +**\** fixing mymonero... +**\** :-P +**\** what happened to mymonero? +**\** its blockchain got stuck +**\** ah ok +**\** alex\_\_\_: \<\_Telegram> \ there were like 6 imports running which deadlocked the database +**\** I thought we fixed db\_open to disallow more than 1 process on the DB at a time +**\** Might be talking about his sql db I think. +**\** ah +**\** too bad. we've been working on an LMDB backend for mysql/mariadb but not much progress in a long time +**\** isnt there supposed to be a meeting? xD +**\** yes +**\** waiting on poniex +**\** ponies +**\** fluffypony fluffypony fluffypony ? +**\** fluffypony may be drinking wine right now +**\** have you seen his wine rack? +**\ {-anonimal}** Yes, epic. +**\** im about to go get a drink myself +**\** brb +**\** good idea +**\** moneromooo, hyc: perhaps someone else can take the lead until he returns? +**\** if we had an agenda in advance that'd work. I've got no idea what needs to be covered today +**\** Well, I have just one thing to say, really: reviewers wanted (even for part of the stuff). +**\** OK, that's a good topic. So there's now a PR for the RingCT code +**\** which means it's presumably functionally complete and ready for heavy testing +**\** \ 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 +**\** paging othe, luigi1111w, luigi1112, othe, tewinget too +**\ {-anonimal}** Congratulations to everyone involved on that. Its a big one. +**\** Yes. I don't think I've got anything else to add, until luigi finds something else he wants to change. +**\** maybe smooth too +**\** But reviewing this isn't going to be wasted anyway, even if he finds something. +**\** ^ NoodleDoodle, ArticMine +**\** but the agenda thing would be nice for such incidents +**\** moneromooo: Is there a way people can help with testing? +**\ {-anonimal}** moneromooo: is there anything in particular that needs attention in terms of review? +**\** RingCT is going to need heavy testing and a public testnet would be a great asset for this +**\** 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. +**\** I would love to setup and pay for a public testnet with a couple nodes +**\** Fwiw, there's a guide to setup a private tesnet -> https://moneroexamples.github.io/private-testnet/ +**\** sorry just got in +**\** Sounds good :-) +**\** was eating +**\** Hay. +**\** er, I mean... hey. +**\** LOL +**\** LOL +**\** People could apply the RCT PR to the code and test it on their own private testnet +**\** ok so +**\** It's already based on latest master. I did removed the forking setup though. +**\** moneromooo: you mean the PR? +**\** Yes. +**\** I kinda expect (1) reviews, (2) merge, (3) testnet, (4) any fixes PR'd separately. +**\** does the PR have a fork date? +**\** No. +**\** how to activate it? +**\** moneromooo: I meant apply as in manually add it because it hasn't been merged yet :-P +**\ {-anonimal}** Thanks for the link dEBRUYNE +**\** wallet42: it will activate at the right height, once it is cchosen. +**\ {-anonimal}** I have to run folks, I'll read the backlog tomorrow. +**\** see ya +**\** cheers anonimal +**\** Yeah it shouldn't have a date +**\** moneromooo: I don't understand the "right height" thing, plz explain +**\** Entries in the hard fork table in src/blockchain.cpp. +**\** (which do not exist yet) +**\** I think we should set a height that adds 1-2 months to the height after this process has completed -> **\** I kinda expect (1) reviews, (2) merge, (3) testnet, (4) any fixes PR'd separately. +**\** so as this stands +**\** it understands v3 transactions +**\** Ring CT is such a big change that I think we could deviate once from the HF schedule +**\** Let me explain versions and stuff about this: +**\** k +**\** Currently, we are on HF 2, and tx version 1 is the only one that exists. +**\** At HF 3 (september on mainnet), pretty much nothing changes. +**\** 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. +**\** Though the last bit (sweep\_unmixable) might be unnecessary, I'm unsure. +**\** ok +**\** sounds fine +**\** 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. +**\** So they can be spent along with rct fake outs. +**\** oh neat +**\** so that also means no quantization then? +**\** Yes. +**\** "v1 txes are disallowed" -> does that mean everyone needs to move their coins or will a one time transaction be allowed after that? +**\** An rct tx may spend pre-rct outputs. +**\** dEBRUYNE: nobody needs to move anything yet +**\** or ever, really +**\** right, this doesn't affect existing outputs. only newly generated txs +**\** The block reward thing is neat if it works :-) +**\** so what will september HF do then? +**\** fluffypony, hyc: thanks, was asking for clarification +**\** It does. Was a pita due to breaking the tests, but it all works now :D +**\** JjegrUseinob: roll over to stick to the schedule, include the next HF date so that nodes notify +**\** and also include all the fixes to-date +**\** Quantize the reward afaik +**\** September fork just enforces the coinbase to be split into denominations. +**\** (Does someone know the state of pools?) +**\** moneromooo: are we going to point release with the rct PR merged or before then? +**\** Does the September HF force min 4 mixin? +**\** and that's not a significant brhavior change, right? it was always supposed to be split +**\** It was suppose dto, but not enforced. +**\** Rct doesn't really make a difference..it's just dead code until activated +**\** So the question is are there still offending pools that need to update +**\** I'm mostly bothered about having this huge chunk of stuff that creats conflicts with evreything now. +**\** luigi1112: guaranteed that MinerGate is still using their custom stuff and just fudging the version +**\** you're talking source code merge conflicts? +**\** or something else moneromooo? +**\** Like, my cold wallet tx patch is now based on rct code. +**\** Yes, git conflicts. +**\** I don't have a problem with RCT being merged before the point release +**\** fluffypony: that's fine :-) anyone else +**\** \ (Does someone know the state of pools?) <= I can check headers +**\** tewinget: what's the status on 0MQ? +**\** I guess minor version and the block reward are good things to check +**\** maybe we should push for that in the point release if it's nearly done +**\** (Being denominated) +**\** Btw fluffypony, in case tewinget isn't here +**\** Th at can probably be done in the interim between Sept and march? +**\** This is from the logs: +**\** **\** I'm a few hours of work (I hope) away from having the wallet using zmq to talk to the daemon +**\** He said he was starting work on getting the wallet to talk 0MQ yesterday (he'd been using python client with the daemon). +**\** ok +**\** luigi1112: minor\_version should be 3 right? +**\** yes, tewinget was asking for reviews of his branch too +**\** I guess I should go look ^\_^ +**\** anyway, minergate is on "major\_version":2,"minor\_version":3 +**\** For anyone interested, the 0MQ branch can be found here -> https://github.com/tewinget/bitmonero/tree/zmq-dev +**\** moneromooo, fluffypony, luigi1112: This is Minergate's coinbase transaction -> http://moneroblocks.info/tx/8a6f45c079da5e400632c29e6b8145fda593a44657881d6d91b232769511c8fc +**\** ok +**\** Are there any additional meeting items? +**\** quick update on 32-bit support - my blockchain\_import is still running :P +**\** lol +**\** dEBRUYNE: what about other pools? +**\** lemme check +**\** re: the RCT PR, I think we should aim to finish up review and merge by next weekend - any objection, moneromooo ? +**\** That'd be pretty fast. +**\** If you can find enough reviewers by then :) +**\** there will be more review post that +**\** oh btw moneromooo +**\** what are your thoughts on the testnet fork dates? +**\** 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). +**\** 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). +**\** moneromooo: as long as those are each in their own commits, we can still tick them off 1 by 1 +**\** They are, yes. +**\** moneromooo: so then once merged, say next weekend, we can PR testnet fork points +**\** Yes. +**\** i never saw clear answer to artic mine question about when min mixin of 4 will be enforced +**\** No change there for now, but there should be. +**\** can we do it this Sept HF? +**\** thank you moo and hyc. your hard work is appreciated +**\** luigi1112: All pools listed here -> https://monerohash.com/#network have "major\_version":2,"minor\_version":3 +**\** ok +**\** I think that's about it then - code review time +**\** \ can we do it this Sept HF? +**\** (about bumping the network minimum mixin) +**\** right +**\** 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 +**\** You can always ask something dev related if you wish. +**\** so people like debruyne could atleast try to take the host +**\** It doesn't need to be made known in advance (unless it requires research) +**\** mebbe propose agenda items on forum.getmonero.org or something +**\** Having an agenda ahead of time can be helpful. It does not need to be cast in stone. +**\** anonimal usually has kovri meeting agenda in advance. i like that system +**\** i mean this was the first real dev meeting for a month or sth and even today we had a eating hiccup :p +**\** when will log from last meeting be on the website? +**\** lol DaveyJones +**\** JjegrUseinob: sometime next week, once dEBRUYNE has a chance +**\** https://getmonero.org/blog/tags/dev%20diaries +**\** i said last meeting +**\** pr was merged already +**\** https://github.com/monero-project/monero-site/pull/135 +* hellocccc has quit (Ping timeout: 264 seconds) +**\** JjegrUseinob: there are issues that have to be fixed +**\** eg. +* fluffypony Missing key: menu.stackexchange +* fluffypony Liquid Exception: exit in \_layouts/default.html +**\** so I've got to fix those first +**\** \ JjegrUseinob: sometime next week, once dEBRUYNE has a chance <= I'll PR the logs tomorrow +**\** planning on doing it tonight +**\** (today's) +**\** ok ty +**\** 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 +**\** not sure there's a reason to break the schedule +**\** ? +**\** competition from zcash seems like a good reason IF rct is ready to activate and tested enough +**\** I just realized it reads like Z(ooko)Cash. +**\** that was intented i guess :p +**\** I am with staying on schedule with RingCT in March. +**\** I think rushing because "competition" is I'll advised here +**\** Ill +**\** yes +**\** agreed +**\** Very ill advised +**\** The thing I'd move if we could is the september one, to a bit later, but that might break non-updaters... +**\** As we need to have a binary a couple weeks before, in order for most to update in time. +**\** I don't think we should enforce mix 4 here since it's not in existing code +**\** It's good to hear thoughts from everyone on this subject +**\** It'd be a rush release +**\** Then min mix 4 is scheduled for March? +**\** 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 ? +**\** Mix 4 goes well with rct +**\** I'm not sure it needs to be enforced until v1 is disallowed +**\** So let us make it for march +**\** That's not till 1 year from now by current rhoughts +**\** That'd be september, for v1 to be disallowed. +**\** 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 +**\** 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. +**\** And transfer maps to transfer\_new, too. So no more shitty dust for multi-tx. +**\** i wanted to try and get into that code for the "find set that matches" behavior... someday. +**\** why cant we point release those improvements soon then and have ringct fork late oct or nov? +**\** for march enforcement +**\** It's a difficult problem to find the best set. +**\** 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. +**\** 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. +**\** I mean, more time would not mean more testing. +**\** \ 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 +**\** hardforks good, more is better :P +**\** i thought that monero had a social contract that largely supported flexibility this year for rct fork +**\** but im on the fence as well... I still think we're small enough of a thing that we could pull it off +**\** It was discussed before that if we would deviate from the schedule, we would only deviate once for RCT +**\** Monero Classic is going to have weekly hard forks +**\** Yes. Hardforks every two months, maybe many of them not actiually changing anything... would allow easy scheduling of changes without havinhg to wait forecer. +**\** :-P +**\** JjegrUseinob is right though +**\** autoupdate all the things. moo's favorite +**\** 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 +**\** can we have replay attacks too? for classic +**\** so if testnet is successful and everything is fine we can consider moving itup +**\** \*it up +**\** : +**\** :) +**\** ok, that sounds fine. when we're happy with the code integrity and test phase +**\** im down with that. Fork early, fork often +**\** And bump mixin at this one ? Or the one after it ? +**\** monero is a flexible adolescent... we will stiffen by time :p +**\** \ so if testnet is successful and everything is fine we can consider moving itup <= I'd be fine with that too +**\** let's make sure miners have enough time to update and receive notification +**\** moneromooo: bump mixin at Sept hardfork +**\** so 1-2 months after the full "process" +**\** mixin will bump anyway for rct right +**\** So HF 5 ? Which might not be september if we being march forward. +**\** Min mixin was not touched in the rct banch. +**\** oh +**\** we're going to have to bump it for definite +**\** Don't bumb for September imo +**\** Bump +**\** It's too soon +**\** I suppose it ought to run on testnet first +**\** So 4, in HF 4 (with rct enable) ? +**\** This september +**\** I vote for next September but I'm somewhat ambivalent vs march +**\** Is there a reason for Sept 2017 vs March 2017 for enforcing mixin 4? +**\** Yes, it is better with ringct +**\** Which will be enforced then +**\** Oh, and the size increase as a function of mixin is rather shallow. So we can go wild. +**\** it seems to me min mixin 4 is a good thing regardless of rct. why wait +**\** It adds forced "junk data" for 6 months...but not a large deal most likely +**\** It's not junk, it's lovely privacy preserving data :P +**\** Or we can do 3 in march, 4 in september :) +**\** So an additional TX size issue for six months that is solved with RingCT +**\** rct txes will be larger. +**\** About 13 kB I think. A lot more constant than current. +**\** But there is a tradeoff in the need to mix the inputs broken down in powers of 10 +**\** Ah, you mean to get a "privacy equivalence" ? +**\** Yes +**\** The new coin selection should help there too I think. +**\** we should be winding up and letting the kovri mtg start +**\** do we have any decisions on bumping mixin? +**\** anonimal left, no kovri meeting. +**\** ok +**\** I guess I'll do mixin 4 for HF 5 then, unless new stuff gets said. +**\** Sounds fine to me +**\** ok +**\** 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 ^\_^ +**\** cold wallet signing patch will be a great feature. thanks mooooo +**\** ok I fixed the stuff that was breaking on the site +**\** fluffypony: what dEBRUYNE said. +**\** I totally forgot there was a dev meeting and slept right through it, woops. +**\** You can still tell us how far you are, most people are still in the channel :) +**\** better than me, i thought i am in this channel...but i wasn´t +**\** 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. +**\** does ur todo list include authentication too? the current way is kinda bah +**\** othe: yes, but that will be something to look at after the rest is sorted, I think. +**\** good +**\** Oh, that reminds me. +**\** The previous 0mq branch had something called net\_skeleton, which was doing some middle layer ntworking stuff, but was GPL so needed replacing. +**\** 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. +**\** I'm just using zmq... +**\** idk what he (oranjuice, I think?) was using net\_skeleton for. +**\** Yes, that was him/her. And I dunno either :) +**\** i only know that theirs a license issue with that anyway +**\** nvm... +**\** didnt we want to replace epee with net skeleton? +**\** othe: good question, to which I haven't an answer. +**\** be sweet to get a graphical version of whatever was decided re: HF and rule versions today +**\** i.e., timeline +**\** cause again, the lack of harmony with all these version numbers is confusing +**\** oh +**\** tewinget / moneromooo +**\** net\_skeleton had nothing to do with 0MQ +**\** once 0MQ is in we still have to offer a JSON RPC API, right +**\** and that has to be able to provide TLS and simple auth +**\** \ once 0MQ is in we still have to offer a JSON RPC API, right <-- err...about that +**\** so we'd have a new helper app for JSON RPC API +**\** tewinget: it's in the spec +**\** the zmq implementation thus far \*is* a json rpc +**\** no +**\** JSON RPC API is a standard +**\** oh, right, that +**\** http://json-rpc.org +**\** I mean, I've got it nearly identical to that standard, so it wouldn't take much doing to change it to exactly that +**\** you're just serialising data in JSON +**\** test\_str = { +**\** "request": "get\_blocks\_fast", +**\** "version": 1, +**\** "message": { +**\** "block\_ids": ["418015bb9ae982a1975da7d79277c2705727a56894ba0fb246adaabb1f4632e3"], +**\** "start\_height": 10 +**\** the HTTP-based JSON RPC API is familiar to integrators +**\** } +**\** } +**\** that's pretty close to the standard +**\** so we have to provide that layer +**\** I'll just have to change it a little +**\** oh, you mean http-based +**\** yes +**\** that's what net\_skeleton was doing +**\** which spec do you mean, 1.0 or 2.0? +**\** 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 +**\** that said, HTTP makes sense I suppose, just will take a bit of doing. +**\** it's transport agnostic, but every single client library supports HTTP and no other transports, lol +**\** ok but back up a second +**\** don't go running ahead and changing things just yet +**\** wasn't planning to +**\** if I'm a client application talking 0MQ to the daemon I need to have some optional authentication, which 0MQ provides support for +**\** I'd only use that if I'm talking remotely to the daemon +**\** with you so far +**\** same goes for encryption - not necessary on localhost +**\** so then we have this little stub applications, let's call them monero-rpc-daemon and monero-rpc-wallet +**\** they have an HTTP server +**\** and they talk 0MQ to the daemon +**\** even that's slightly overcomplicated I think +**\** just monero-rpc-http as one binary +**\** yeah that's fine too - as long as wallet-ing is optional +**\** 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 +**\** same binary would work for both wallet rpc and daemon rpc (and others if ever there are any) +**\** it can't be a dumb client though +**\** right, it'll have to have auth parameters as well +**\** otherwise you're going dumb client -> rpc-wallet -> daemon +**\** three binaries +**\** ie. it has to have local wallet functionality +**\** that talks to a daemon over 0MQ +**\** ie. simplewallet gets separated out into cli-wallet and rpc-wallet +**\** both of which use 0MQ to communicate with the daemon +**\** and rpc-wallet can provide both HTTP and 0MQ interfaces, at a later stage, but definitely HTTP initially +**\** so you're saying you want to wrap http-speaking into the rpc-wallet binary? +**\** simplewallet already talks HTTP +**\** when you put it in RPC mode, I mean +**\** doesn't the daemon already do so as well with the current RPC? +**\** yes - and we have to support that also to be backwards compatible, but that's another story +**\** 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. +**\** not the cleanest solution, granted, but seems pragmatic imo +**\** I do hate that idea, purely because I want to rip that code out :-P +**\** 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) +**\** but having said bridge layer live inside the {daemon,wallet,etc} binary is okay too, I suppose. +**\** so what happens if I'm a well-designed exchange, and I have the daemon on a different machine to the wallet +**\** and I want to talk HTTPS to the wallet +**\** HTTPS request -> wallet -> daemon? I'm not sure I understand why you ask. +**\** yes precisely +**\** or with the bridge as a separate binary, HTTPS request -> bridge -> wallet -> daemon +**\** the daemon is exposed to the Internet +**\** it can be attacked +**\** the wallet is sensitive, so it lives behind the DMZ +**\** okay... +**\** your second one solves the case as long as I'm happy starting up a bunch of things +**\** also you'd need rpc-wallet to provide a 0MQ interface +**\** and then bridge -> wallet talks 0MQ +**\** I intend for it to. +**\** why would the wallet libs *not* have a 0mq interface? Need that anyway for GUIs and shit, right? +**\** err...nvm, dumb question +**\** 0MQ client != 0MQ interface +**\** 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. +**\** yes +**\** that having been said, at some point off in the future I might look into using 0mq's intra-process stuff for message passing. +**\** but that's a long time in the future +**\** yeah +**\** 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. +**\** yeah agreed +**\** hmm...even that's not necessarily true, it wouldn't be too bad to have both speak both. +**\** or rather have the wallet *just* speak http(s) to the wild, and use libdaemonrpc or w/e to speak 0mq to the daemon +**\** all of the message system I've written for the 0mq so far is transport-agnostic, so that's the good news :) +**\** (as it should be, but I'm just pointing it out for the sake of...well, having pointed it out, I guess) +**\** 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. +**\** kk diff --git a/_posts/2016-08-28-logs-for-the-Kovri-dev-meeting-held-on-2016-08-28.md b/_posts/2016-08-28-logs-for-the-Kovri-dev-meeting-held-on-2016-08-28.md new file mode 100644 index 00000000..de82c150 --- /dev/null +++ b/_posts/2016-08-28-logs-for-the-Kovri-dev-meeting-held-on-2016-08-28.md @@ -0,0 +1,338 @@ +--- +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 + +**\** anonimal: all yours +**\** in the meantime, for those not interested (or relevant to) the kovri meeting, anyone wanna help me test the zmq wallet<->daemon interactions? +**\ [anonimal]** Proposed meeting items: +**\** oh +**\** shit +**\ [anonimal]** 1. Greetings +**\ [anonimal]** 2. Brief review of what's been completed since the previous meeting +**\ [anonimal]** 3. Code + ticket discussion / Q & A +**\ [anonimal]** 4. Discuss #282 +**\ [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]** btw, twinget, you are \*all\* relevant to the meeting and you \*ALL\* should be interested. +**\ [anonimal]** Its that kind of attitude that is preventable advancing kovri development within monero. +**\>** +100 +**\ [anonimal]** 1. Greetings +**\ [anonimal]** Hi, I'm here. +**\ [fluffypony]** me three +**\>** anonimal (I'm not relevant in the sense that I have no context, need to learn more about it :)) +**\ {-solmar}>** we need all the help we can get +**\ [fluffypony]** EinMByte ? +**\>** I will stay for another 20 min then I have to leave. +**\ [fluffypony]** tks ArticMine +**\ [anonimal]** Hi ArticMine. +**\>** Hi +**\ [anonimal]** Hi solmar, EinMByte, fluffypony. +**\ [anonimal]** 2. Brief review of what's been completed since the previous meeting +**\ [anonimal]** $ git checkout master && git log --pretty=oneline --no-merges --since=2016-07-31 | wc -l +**\ [anonimal]** 55 +**\ [anonimal]** - Lots of build work +**\ [anonimal]** - Reinstate FreeBSD build +**\ [anonimal]** - Reinstate Clang support +**\ [anonimal]** - New config features +**\ [anonimal]** - New logging features +**\ [anonimal]** - Implemented SNI (part of cpp-netlib) +**\ [anonimal]** I'm doing work in branch fix-305, not detailed here. +**\ [anonimal]** We have a new member onbard, 'solmar'. guzzi is back with us too. +**\ [anonimal]** rakhimov is becoming more active, all great. +**\ [anonimal]** I hope EinMByte's travels have been well and has returned. +**\ [solmar]** hey all ;) +**\ [anonimal]** Did I miss anything for point 2.? +**\** well +**\** is it worth discussing #325 now? +**\ [solmar]** the quality assurance document is note worthy but i think you got everything +**\ [anonimal]** fluffypony: no not yet. +**\** ok +**\ [anonimal]** solmar: thanks, good point. Yes solmar and I reworked #58 and introduced it into a tangible guide. +**\ [anonimal]** Anything on 2. before moving onto 3.? +**\** nothing more on 2 +**\ [anonimal]** Before 3., did solmar want to formally introduce themself? +**\ [solmar]** sure i can quickly introduce +**\ [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 +**\ [i2p-relay] {-moneromooo}** Welcome :) +**\ [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 +**\ [fluffypony]** +1 +**\** s/peaked/piqued/ <-- fuck English sometimes +**\ [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 +**\ [fluffypony]** awesome, everyone should dabble in both +**\ [solmar]** any interest and help with kovri is greatly appreciated +**\ [solmar]** i think we can move along to 3. now thanks anominal ;) +**\ [anonimal]** Alright, thanks solmar. +**\ [anonimal]** 3. Code + ticket discussion / Q & A +**\ [anonimal]** I'll open +**\ [fluffypony]** some of the design decisions in Kovri were influenced by Monero, so no getting away from it, Monero devs ;) +**\ [anonimal]** Question: WHEN WILL MONERO DEVS START TAKING KOVRI SERIOUSLY? +**\ [anonimal]** 10 months in now since our november 1st meeting, +**\ [i2p-relay] {-moneromooo}** Define "taking seriously" ? Send patches ? +**\** anonimal: I take it just as seriously as, say, RingCT, I just haven't had/taken the time to dig into either yet :) +**\ [anonimal]** As a whole, if I could quantify contributions, I'd say kovri is getting ~5% attention to what bitmonero and ecosystem is getting. +**\ [anonimal]** moneromooo: anything. +**\ [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. +**\ [i2p-relay] {-moneromooo}** I will try to get into kovri a bit once rct is all done. +**\ [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. +**\ [anonimal]** Thanks moneromooo. +**\ [fluffypony]** the easiest way to get hyc involved it for us to use LMDB for storage of something :-P +**\ [i2p-relay] {-moneromooo}** (and feel free to remind me of it if I don't :P) +**\ [i2p-relay] {-moneromooo}** Nah, use liblber for network. +**\ [anonimal]** fluffypony: this goes for you too, as we'll see with the remaining agenda items. +**\ [i2p-relay] {-moneromooo}** Make us fast and secure comms! +**\** fluffypony: in the same way as with hyc, the easiest way to get me involved is something needing refactored >\_> +**\ [anonimal]** Anyone else over there have a response beside moneromooo and tewinget? +**\ [anonimal]** If not, we should move onto other Q & A. +**\ [fluffypony]** is this still the ticket discussion part? +**\ [anonimal]** Point 3. +**\ [fluffypony]** yes - but I mean ticket discussion is part of Q&A or can I bring up a ticket now? +**\ [anonimal]** I have library questions I would want to debate with EinMByte but I don't think he's around. +**\ [anonimal]** Sure but that's least priority at the moment. +**\ [anonimal]** And should be 9. +**\ [anonimal]** I'd rather move onto 4. if no one has any questions. +**\ [fluffypony]** kk +**\ [anonimal]** 4. Discuss #282 +**\ [fluffypony]** ok so +**\ [i2p-relay] {-moneromooo}** There was a designer guy asking whether help was wanted. He seemed to be after paid work though. +**\ [fluffypony]** with the Monero logo we used 99designs +**\ [i2p-relay] {-moneromooo}** eherdesign in #monero +**\ [fluffypony]** moneromooo: I looked at his stuff, it wasn't mind-blowing +**\ [fluffypony]** I'd like to move to use 99designs again +**\ [fluffypony]** ref: https://99designs.com/logo-design/contests/monero-mro-cryptocurrency-logo-design-contest-382486 +**\ [fluffypony]** I'm happy to put the $500 up for that, and then use the FFS to get it back +**\ [fluffypony]** unless anyone feel we must go for a higher 99designs reward +**\** i would also sponsor that +**\ [i2p-relay] {-moneromooo}** * hopes it won't be some shady looking concept +**\ [i2p-relay] {-ArticMine}** It worked very well for Monero so I say yeas with the same package +**\ [i2p-relay] {-ArticMine}** yes +**\ [solmar]** maidsafe also appears to be having success with 99designs so i think it is a good idea +**\ [fluffypony]** ok - I'll set that up now - do we have any ideas as to what we want to convey? +**\ [i2p-relay] {-ArticMine}** Well I have to leave now +**\ [fluffypony]** do we want it to be inspired by the Monero logo, like the MRL logo is? +**\ [i2p-relay] {-moneromooo}** The essential qualities of garlic. +**\ [fluffypony]** (ref: https://lab.getmonero.org/logo.png) +**\ [i2p-relay] {-moneromooo}** ^ great logo +**\** (noob here ...) A podcast I follow have a promo code för 99designs. Interesting? +**\ [fluffypony]** groeg: yes plz, can you PM it to me? +**\** you'll want to pm it to fluffypony, not to the bot +**\** he's in this irc +**\ [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. +**\** newbie using IRC, looking up how to pm ... +**\ [i2p-relay] {-moneromooo}** groeg: /query NICKHERE +**\ [fluffypony]** thanks groeg, got it +**\ [solmar]** conveying a "veil"-ish esque style to it could be interesting, since kovri means veil in esperanto afaik +**\ [i2p-relay] {-moneromooo}** 90 degrees, not %, of course -\_- +**\ [fluffypony]** solmar that's pretty much what I was thinking, something along the lines of a network, but it's private +**\ [fluffypony]** or something +**\ [fluffypony]** doesn't have to be a "veil" in the literal sense +**\ [solmar]** ya +**\ [solmar]** i agree +**\ [solmar]** ya exactly +**\ [anonimal]** Sorry, unexpected AFK emergency, unavoidable. +**\ * anonimal** reading +**\ [anonimal]** moneromooo: cool idea, maybe someone can run with that. +**\ [fluffypony]** anonimal: the rotated K thing? +**\ [fluffypony]** I can suggest that in the 99designs description +**\ [anonimal]** Yeah, but maybe not literally, just an artistic motive I guess. +**\ [fluffypony]** yeah +**\ [anonimal]** But also garlic is a good point as solmar pointed out. +**\ [fluffypony]** isn't garlic very Tor? +**\ [anonimal]** So a rotated K inside a garlic clove +**\ [anonimal]** No, they're onion. +**\ [fluffypony]** oh yes +**\ [fluffypony]** my bad +**\ [anonimal]** onion router similar to garlic routing. +**\ [anonimal]** Meh, its practically the same vegetable. +**\ [fluffypony]** lo +**\ [fluffypony]** lol +**\ [fluffypony]** we should go wild and create spinach routing +**\ [anonimal]** lol +**\ [anonimal]** "Kovri provides essential iron and vitamins" +**\ [fluffypony]** http://paulkieschedesign.com/blog/wp-content/uploads/2011/12/shandong-logo.jpg <- perfect +**\ [anonimal]** "Eat kovri today" +**\ [fluffypony]** the name, not the logo +**\ [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 +**\ [fluffypony]** ShanDong +**\ [anonimal]** The ShanDong I2P Router project... hmm... +**\ [anonimal]** fluffypony: how do we keep track of #282? +**\ [fluffypony]** lol +**\ [fluffypony]** anonimal: othe and I will set it up and update in-ticket +**\ [anonimal]** fluffypony: thanks. +**\ [anonimal]** Anything else on #282? +**\ [fluffypony]** nada +**\ [anonimal]** If we use a dog somewhere in there, and Shandong, we should go with a pug. +**\** shandong = 山东 = mountain east +**\ [fluffypony]** TIL +**\ [anonimal]** The eastside rugged pug. +**\** (literal meaning of the characters) +**\ [fluffypony]** east mountain pugs unite +**\ * anonimal** see dog flip gang symbol with fingers +**\ [fluffypony]** DogeI2P +**\ [anonimal]** Here we go, lol +**\ [anonimal]** Ok, 5. Closing #226 +**\ [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 +**\ [anonimal]** I've registered the channels and am idling. +**\ [fluffypony]** ok so +**\ [fluffypony]** are we happy running this under the core relay and not the community relay? +**\ [anonimal]** By community you mean the one in #monero/#monero-dev? +**\ [fluffypony]** the community one is the one that needmoney90 runs, to Slack / Telegram etc. +**\ [fluffypony]** the core one is i2p-relay +**\ [fluffypony]** anonimal: is there a #tahoe-lafs on OFTC? +**\ [fluffypony]** because I don't want to take tahoe-lafs out the relay list, necessarily +**\ [anonimal]** fluffypony: yes, with 4 people, no channel topic. Doesn't look official. +**\ [fluffypony]** ok then I'll just relay it, tough for them +**\ [anonimal]** They will probably enjoy it. +**\ [fluffypony]** indeed +**\ [fluffypony]** ok I'll do that right now +**\ [anonimal]** So this would be for i2p-relay? +**\ * anonimal** so many relays, so confused +**\ [fluffypony]** lol +**\ [i2p-relay] {-moneromooo}** What's #tahoe-lafs relation with kovri btw ? +**\ [anonimal]** moneromooo: Nothing really aside from an i2p plugin available to use with tahoe-lafs, AFAIK +**\ [anonimal]** fluffypony: if you're doing it right now, I'll wait. +**\ [fluffypony]** moneromooo: they asked me to run a relay, as their relay has disappeared +**\ [anonimal]** Damn, it's been an hour. Do we continue? +**\ [fluffypony]** yes - we started late +**\ [i2p-relay] {-moneromooo}** I think it's mostly up to you, the main kovri person. +**\ * anonimal** didn't want to stop on necessary bitmonero business +**\ [anonimal]** fluffypony: do you have to restart the relay? Is #226 resolved? +**\ [fluffypony]** the bouncer is connected +**\ [fluffypony]** sec +**\ \** testing +**\** testing back +**\ [fluffypony]** and from here +**\ [fluffypony]** meeting-bot might be interfering with it a little, so I'll fiddle with it after I've killed meeting-bot +**\ [anonimal]** It's only me and the bot on OFTC +**\ [anonimal]** Is fluffypony@OFTC actually fluffypony@Freenode ? +**\ [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 +**\ [fluffypony]** coz meeting bot is also relaying +**\ [anonimal]** Ok, can we quickly review the remaining items? +**\ [fluffypony]** sure +**\ [anonimal]** 6. Closing #105 +**\ [anonimal]** Hmm, tricky. +**\ [fluffypony]** sorry internet is slow +**\ [fluffypony]** ok so +**\ [fluffypony]** the moneroworld instance is up +**\ [anonimal]** https://social.moneroworld.com went online but admin has not responded to anything in a month +**\ [fluffypony]** hmmm +**\ [anonimal]** There were multiple issues, probably still are, that would need to be resolved before we go officially public. +**\ [fluffypony]** ok then I think leave it open +**\ [anonimal]** But it's not kovri-related. +**\ [anonimal]** That's what annoys me. We have a forum post open for it. +**\ [anonimal]** And there's also that /bitmonero ticket open +**\ * anonimal** fetches +**\ [anonimal]** #903 +**\** gingeropolous aint that your site? +**\ [fluffypony]** anonimal: do we want a common gnu-social for the two? +**\ [fluffypony]** or separate? +**\** wut? +**\ [anonimal]** I thought it would be an umbrella instance, more of a 'pro-decentralization' initiative not specific to kovri or bitmonero. +**\ [i2p-relay] {-moneromooo}** https://social.moneroworld.com <- your site ? +**\** oh, DaveyJones , no... i just pay for the domain name and put it on afraid.org so anyone can create subdomains for free +**\ [anonimal]** I've already signed up for @kovri and @anonimal at quitter.se in case this issue was never resolved. +**\ [i2p-relay] {-moneromooo}** Oh, that's nice idea. +**\ [fluffypony]** ok +**\ [fluffypony]** let's leave it open and prod the guy again +**\ [fluffypony]** if we hear nothing by next dev meeting we re-host from scratch +**\ [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. +**\ [anonimal]** Ok, I'll make a note. +**\ [anonimal]** 7. Closing #46 +**\ [fluffypony]** I'm moving registrars for all critical domains, including getkovri.org +**\ [fluffypony]** which is affecting that and the other one +**\ [fluffypony]** (the increased attention means an increase of people poking at our infrastructure, hence the move) +**\ [anonimal]** Ah, ok. How is content coming along? Did you get that rough draft finished? +**\ [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 +**\ [fluffypony]** it's in a sub-section of its own +**\ [fluffypony]** so it can have as much content as required +**\ [EinMByte]** nice, didn't know we were getting a website +**\ [anonimal]** Alright, I'll make a note. +**\ [fluffypony]** EinMByte: I was going to do it in Geocities, but anonimal convinced me not to +**\ [EinMByte]** (then again, I probably missed a lot) +**\ [fluffypony]** snow flake mouse cursors are the bomb +**\ [anonimal]** Yeah, fluffypony has yet to learn the finer points of 90's webdev. +**\ [fluffypony]** fo sho +**\ [anonimal]** We're working on that. +**\ [fluffypony]** Backstreet Boys backgrounds everywhere +**\ [anonimal]** Once we get a logo, the site should look snazzy. +**\ [anonimal]** 'Kovri's back, alright!' +**\ [fluffypony]** hah hah +**\ [anonimal]** Ok, 8. Closing #27 +**\ [anonimal]** Ah, looks like we've had some activity there lately. +**\ [anonimal]** Looks like two issues now. So, 1) updates on zoho? 2) should we ever have a mailing list? +**\ [fluffypony]** can't proceed with Zoho till the domain move is done, but that's basically setup +**\ [fluffypony]** I don't think mailing lists are necessary +**\ [fluffypony]** we already have stuff scattered everywhere, another avenue will just make dissipate it more +**\ [anonimal]** Agreed. +**\ [EinMByte]** ever ? maybe, now ? no +**\ [anonimal]** fluffypony: ETA on domain move completion (or did you already say?... /me reads)? +**\ [fluffypony]** anonimal: by next meeting +**\ [fluffypony]** if it's done sooner then great +**\ [anonimal]** Ok, great. Once that's resolved we can resolve the HackerOne issue. +**\ [anonimal]** Which will be another avenue for more attention. +**\ [anonimal]** I'll make a note in #27. +**\ [anonimal]** Anything else on #27? +**\ [fluffypony]** nope that's it for now +**\ [anonimal]** 9. Any additional meeting items +**\ [anonimal]** EinMByte, how goes it? +**\** present fgi +**\ [anonimal]** Hi guzzi. +**\ [anonimal]** guzzi: anything you wanted to add to the meeting? +**\** glad to be a back. learning a lot. +**\ [EinMByte]** anonimal: Hopefully some work on SSU soon +**\ [anonimal]** EinMByte: I had thoughts and questions on library design if you're around after the meeting +**\ [EinMByte]** Sure +**\** looking to focus more on kovri since it has the least devs and is more easy to peneatrate into development. +**\** still getting up to speed. +**\ [anonimal]** EinMByte: nice, I look forward to the day we merge that branch. +**\ [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 +**\ [anonimal]** guzzi: ok, if you have any questions, feel free to shout out. +**\ [anonimal]** solmar: ^ what EinMByte said too if interested. +**\** EinMByte, thanks on it. +**\** i will look for todos. +**\** an prs on that +**\ [anonimal]** fluffypony: you wanted to talk about #325? +**\ [fluffypony]** oh - not necessarily, it was more to find out if it needed discussion +**\ [solmar]** i'll check it out thanks ;) +**\ [anonimal]** fluffypony: I think #325 is more of a 'po-tey-to' 'po-tah-to' kind of issue +**\ [anonimal]** and a possible solution is 'let's call the whole thing off'. +**\ [anonimal]** I'll figure itself out. +**\ [anonimal]** Anything else on 9.? Any more meeting items? +**\ [anonimal]** With organizational things out of the way, the next meeting can be far more codebase-orieted. +**\ [anonimal]** *oriented +**\ [fluffypony]** kk +**\ [anonimal]** 10. Confirm next meeting date/time +**\ [fluffypony]** https://99designs.com/logo-design/contests/create-beautiful-logo-kovri-privacy-enhancing-open-source-652257/entries +**\ [fluffypony]** https://99designs.com/logo-design/contests/create-beautiful-logo-kovri-privacy-enhancing-open-source-652257/brief that thing +**\ [anonimal]** fluffypony: nice +**\ [fluffypony]** k next meeting, same time, same place, 2 weeks +**\ [anonimal]** Where's the 'optional dog' button? +**\ [fluffypony]** Two Weeks (tm) +**\ [anonimal]** Do we have to do 2 weeks? +**\ [fluffypony]** you want to do longer? +**\ [fluffypony]** or shorter? +**\ [anonimal]** I mean, I guess it depends on who is involved. If it's the usual, then I'd say 1 month. +**\ [fluffypony]** guzzi / solmar / EinMByte - thoughts ? +**\ [EinMByte]** We can discuss some of the more technical things separately +**\** 1 mo fine. i will be on irc for technical things. still playing catch up. +**\ [fluffypony]** ok +**\ [fluffypony]** then we do it in 4 weeks, same time as the meeting after next Monero dev meeting? +**\ [solmar]** 1 month is fine +**\ [solmar]** i'll be around as often as i can +**\ [anonimal]** Same time is fine with me. +**\ [fluffypony]** thankyouverymuch! +**\ [anonimal]** Ok, thanks everyone. +**\ [fluffypony]** can I kill meeting-bot? +**\ [anonimal]** fluffypony: swift and painless if possible. +**\ [anonimal]** She need not suffer. diff --git a/_posts/2016-08-28-overview-and-logs-for-the-dev-meeting-held-on-2016-08-28.md b/_posts/2016-08-28-overview-and-logs-for-the-dev-meeting-held-on-2016-08-28.md new file mode 100644 index 00000000..5559b0aa --- /dev/null +++ b/_posts/2016-08-28-overview-and-logs-for-the-dev-meeting-held-on-2016-08-28.md @@ -0,0 +1,243 @@ +--- +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 + +**\** ding ding ding +**\** hello meeting-bot! +**\ [fluffypony]** hello from the other side! +**\** ok we're on +**\** ArticMine / luigi1111w / othe / smooth / hyc / moneromooo / tewinget / redfish / NoodleDoodle / anyoen I forgot +**\** There's an article about fraud in crypto on the bytecoin blog. Chutzpah, got to admit. +**\** welcome to the annual "Devs who Drink whilst Developing" meeting +**\** moneromooo: brave of them +**\** lol. I'm on cider today +**\** ok so +**\** in today's news +**\** nothing happened with the Monero price +**\** and so we focus on dev +**\** lol +**\** let's start with a quick check of open PRs +**\** except for RingCT which we'll get to +**\** redfish: how goes the CMake stuff? +**\** I alive today. +**\** hey :) +**\** and a warm welcome to our special guest, NoodleDoodle +**\** :-P +**\** whilst we wait for the redfishes +**\** NoodleDoodle: do you want to talk about Trezor at all? +**\** ok good chat +**\** heh +**\** :-P +**\** Sure :P +**\** yay, take it away +**\** redfish doesn't appear to be answering either +**\** I'm about 1296 behind in commits. Rebasing is pretty much out of the question. Have to manually merge then release. +**\** NoodleDoodle: do you want any help with that? +**\** The trezor firmware itself should be easier, except it's split into 5 or 6 repos +**\** ok cool +**\** I should be able to do it. +**\** 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? +**\** late, but here +**\** Sure, anything. I actually started on keepkey awhile back as well, although it's not as complete as trezor. +**\** ok cool +**\** I've been fiddling with Ledger Blue, as I have the Blue and the Nano S +**\** I have a feeling they'll be a cinch after Trezor / Keepkey +**\** and, hopefully, we can PR it in to be part of the default firmware on these devices +**\** if they'll have us +**\** ok so next up +**\** hyc has a small PR to ease up our LMDB speed after you're caught up with the network +**\** which should lead to an even more robust blockchain DB, not that I've had anything resembling a corruption in ages +**\** and I kill daemons like I'm playing Doom +**\** tewinget, would you like to update us on 0MQ plx? +**\** sure +**\** so far, all of the daemon RPC calls pertaining to the wallet are good to go, as well as several others +**\** the wallet is good to go for using the new daemon rpc library +**\** oh, the new daemon rpc has a library, rather than just calling out to networking things directly. >\*\*\_>\*\* +**\** (I only got ~1 hr sleep, minor rambling will happen) +**\** 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"? +**\** 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) +**\** 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 +**\** 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 +**\** ok because that brings us on to the next topic +**\** 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 +**\** afaik (as in, if I've done it right) it's JSON-RPC compliant as well, apart from the http layer +**\** and tewinget maybe you can think about it in this context +**\** the RingCT PR is now post-review, at least by me, with multiple others having reviewed parts of it +**\** so it's merge time +**\** we haven't set fork heights yet +**\** Wait till I signed commits first. +**\** moneromooo: yes +**\** but basically the idea is to run through the testnet forks next week +**\** which means testnet will do the equivalent of September *and* March 2017 forks +**\** in one week +**\** testnet will then have RingCT live +**\** and we'll be able to focus on efficiency improvements, further testing, and so on +**\** in the meantime, it will let us code freeze sometime into September +**\** a little later than we'd have liked, but a necessity to get RingCT in to this freeze instead of only in March +**\** now here's the nice thing +**\** old daemons only know about the fork in September, and will only start nagging about that one +**\** so we can set the subsequent fork to something earlier than March +**\** but we'd have to make that decision by the next dev meeting pretty much at the latest +**\** which means +**\** next week Tue / Wed or so we'll push out binaries for 0.10-beta +**\** 0.10 will be called Wolfram Warptangent, in honour of the Monero contributor that passed away +**\** 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. +**\** Does that include the GUI? +**\** ArticMine: no, this is core only +**\** ArticMine: We can tag a release with GUI at any time, no forking and such +**\** same with ZMQ +**\** but it includes the GUI lib changes that are needed +**\** so anyone compiling the GUI will have working beta bins to play with +**\** so I'd please like commitments from as many people as possible to participate in testnet next week +**\* moneromooo** commits fluffypony +**\** lol +**\* tewinget** rejects the unsigned commit +**\* iDunk** sees travis ci build fail +**\** git commit -S -am "loony bin" +**\** OK. I'll put in a Pedersen commitment to... something. +**\** When do we set the forks then ? +**\** at dinner? +**\* fluffypony** giggles +**\** For v3, ok. v4 (rct) on monday lunchtime. +**\** moneromooo: for testnet? +**\** Obviously :P +**\** And v5 (rct only) on tuesday. +**\** you mean Monday tomorrow, or Monday next week? +**\** Fine ? +**\** Tomorrow. +**\** hmmm +**\** Too fast ? +**\** yes actually good idea - the actual fork process has been tested on private testnet, and in the previous fork +**\** so we push bins out after the fork +**\** then people can play without needing to fiddle +**\** and this is still a no-vote fork? +**\** Yes. Screw votes, they were coded by an idiot. +**\** LOL! +**\** gingeropolous: yeah - we can re-address that in the next 6-12 months, but at the moment it's move-it-or-lose-it +**\** yeah absolutely +**\** 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 +**\** 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. >\*\*\_>\*\* +**\** lol fluffypony +**\** ok so moneromooo, your fork points are fine +**\** So will you merge the PR then build off that, or build off my branch ? +**\** (for the test builds) +**\** no, merge +**\** OK +**\** people must be able to build head on their boxes if they want +**\** (oh, the supreme importance of punctuation) +**\* gingeropolous** hides +**\** lol +**\** ok +**\** I think that's it from my side +**\** does anyone have any questions or thoughts or anything? +**\** im still not super clear on the fork schedule.... but it could be sleep dep +**\** for mainnet +**\** for mainnet it's still the September v3 fork, as expected +**\** if we want we can have the v4 and v5 forks at any point after that, even though March would be the "expected" date +**\** iDunk: build log shows no errors, just too slow to build +**\** I have a few questions, but I'll wait for others' for a few minutes first. +**\** testnet sched sounds good +**\** 0.10-beta sounds fine +**\** hyc: was a joke +**\** iDunk: but it's unfortunately true :P +**\** 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 +**\** something like that +**\** gotcha. +**\** so we start 2017 with RingCT as the only way to transact +**\** is there a place where the fork plan /etc is laid out? +**\** maybe the readme of the github is a good home +**\** gingeropolous: this one, or generally? +**\** generally +**\** and this one +**\** generally, the Monero Forum post + all other posts that talk about the mandatory hard forks +**\** gingeropolous: plans are probably in /usr/share/doc, not in /etc +**\** I agree that the Readme shoudl include it +**\** seems to me like we have a lot of profiling and tuning to do before ringCT will play for real +**\** october might be too soon +**\** its gonna be a helluva fall +**\** this one is dev meeting specific, we'll have a summary post after that and solicit feedback from the non-dev community +**\** hyc: we do have new contributors, so we might be able to get through the tuning stuff faster +**\** cool +**\** I'm no fan of pushing it too hard, because it means I have to get MyMonero working with RingCT, but it's doable +**\** 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 +**\** ah screw it. time to by moneroforks.whatever +**\** gingeropolous: do you want to PR a change to the readme? +**\** it'll take you from troll-dev status to readme-dev +**\** :-P +**\** :) +**\** ok tewinget +**\** before we run out of time +**\** ask away +**\** ok +**\** so for one thing, I haven't seen a GUI progress update today, figured I'd ask if we have a tentative timeline? +**\** othe: any thoughts? +**\** ^^ +**\** sorry was busy drinking +**\** yeah so ilya is traveling but back next week, we hope to fix all small reamaining issues till the week after +**\** ok +**\** and then we can release a beta +**\** awesome +**\** together with a new tagged rls +**\** othe is there any way he can stop submitting huge PRs +**\** and then whats following is mostly advanced settings and stuff like that +**\** it's killing it for other potential contributors +**\** yeah i can tell him +**\** 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?) +**\** he needs to PR on a feature / fix by feature basis +**\** oh thats not in the place but something that would be cool to have tewinget +**\** yeah, narrow scope PRs +**\** yeah definitely, hyc +**\** And move the twitter stuff in there, just to be sure. +**\** OH! +**\** before I forget +**\** the big thing I wanted to discuss +**\** https://github.com/monero-project/bitmonero/issues/80 +**\** that's going to happen before the bins are pushed +**\** so if anyone has any final thoughts on that, you'd best comment on the issue, else suck it up later :-P +**\** I'd also like us to start refactoring the parts that have CryptoNote in the name to be Monero instead +**\** something something \`sed\` +**\** as RingCT + several thousand commits puts us quite far beyond the reference protocol +**\** Renaming things for the fun of it ? I'd rather not. +**\** (in the code, I mean. I'm ok with the binaries thing) +**\** 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) +**\** It simple reflects the reality of how much the code has changed from the original Cryptonote implementation +**\** as I said before, I'd like to polish it up a bit first, but that's not a blocking issue for PR-ing +**\** 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 +**\** your call +**\** 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 +**\** 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) +**\** oh that could be interesting +**\** the templatenotify I mean +**\** yeah templatenotify would make an immediate difference for miners +**\** 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" +**\** plus the obvious implications of changing when a new block is learned about +**\** right +**\** but that can be done with the blocknotify that the wallet wants anyway +**\** ooh we talkin dynamic fees? +**\** at any rate, that's a design discussion for another time. +**\** tewinget: I'd prefer earlier PRs +**\** I mean +**\** fluffypony: yes, yes, I meant for after that PR +**\** if it's properly borked by mid-September we can revert 0MQ for release +**\ [anonimal]** 17:06 +**\** tewinget: so what I'm saying is PR soon, plx +**\** anonimal apologies +**\** is there anything else or can we call it? +**\** think that's good for today +**\** I'd say go nuts for your kovri meeting, we're not going anywhere +**\** yay, nuts +**\** so if something else comes up, address it after that meeting +**\** kk \ No newline at end of file diff --git a/_posts/2016-09-11-logs-for-the-Kovri-dev-meeting-held-on-2016-09-11.md b/_posts/2016-09-11-logs-for-the-Kovri-dev-meeting-held-on-2016-09-11.md new file mode 100644 index 00000000..c4a67228 --- /dev/null +++ b/_posts/2016-09-11-logs-for-the-Kovri-dev-meeting-held-on-2016-09-11.md @@ -0,0 +1,376 @@ +--- +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 + +**\** anonimal: all yours :) +**\ [anonimal]** 1. Community input for kovri logo https://99designs.com/logo-design/contests/create-beautiful-logo-kovri-privacy-enhancing-open-source-652257/entries +**\ [anonimal]** 2. Greetings +**\ [anonimal]** 3. Brief review of what's been completed since the previous meeting +**\ [anonimal]** 4. Code + ticket discussion / Q & A +**\ [anonimal]** 5. Any additional meeting items +**\ [anonimal]** 6. Confirm next meeting date/time +**\ [anonimal]** Everyone quick, before you leave, give your opinion on the logo! +**\ [anonimal]** fluffypony: I think we narrowed it down to #239 and #146 +**\ [anonimal]** Maybe others are of interest? +**\** well, I am checking the bitcoin rcp and they use wordwordword, I think i like word_word_word better +**\** https://99designs.com/logo-design/contests/create-beautiful-logo-kovri-privacy-enhancing-open-source-652257/entries/146 +**\** https://99designs.com/logo-design/contests/create-beautiful-logo-kovri-privacy-enhancing-open-source-652257/entries/239 +**\** the onion/garlic thing ... I guess it's descriptive, but I can't take it seriously +**\** 146 +**\** hyc: it's coz of Garlic Routing +**\** 88 +**\** for example "getthis" would bedificuld to understund with no "get\_this", but i like "getThis" too, I think I got that from javascript +**\** yes, I see that, but ... +**\** MalMen: can you take it to PM with tewinget, or wait till after the Kovri meeting? +**\** MalMen: if you want to discuss that, PM me, otherwise try to wait until the Kovri meeting concludes. +**\ [anonimal]** MalMen, we are in the kovri meeting. Please wait for monero chat until afterward. +**\** dammit fluffypony +**\** lol +**\** lo +**\** please continue :D +**\** I think the stylized Ks are more preofessional +**\** As a designer 146 it also brand recognition with xmr +**\** #146 is more in the spirit of the Monero logo, I'll definitely agree with that +**\** and yeah, the brand recognition aspect is +1 +**\ {-guzzi}** #239 +**\** #146 +**\ [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- +**\** attachments/75/75381/attachment\_75381142 +**\** wait, isn't 99designs basically spec-work? +**\ [i2p-relay] {-ArticMine}** Kovri logo Do we want a variant of the Monero logo or something entirely different? +**\ [anonimal]** But why get washed in with more corporatism? We're at a juncture to break some molds here. +**\** tewinget: yes +**\** eww +**\** on the other hand 239 is catchy... ppl may recognize that... while 146 goes in and goes out of mind +**\* fluffypony** ponders +**\** that said, 146 is nice. +**\** I kinda like 254 / 253 but they're so abstract I dunno what they represent +**\** anonimal: I don't think it's "corporate" per se +**\** "professional" sure +**\** my vote is 236 +**\** i mean 239 +**\ [anonimal]** moneromooo: can you tiny that url? weechat sucks +**\** 239 - ok, that's still understated, I could respect that +**\** 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 +**\** :-P +**\** i like the font squarepoint is using +**\ [anonimal]** hyc: 254/253, the person was probably drinking pepsi at the time. +**\** in 25x and 99 +**\** 24{7,8} aren't half bad. +**\** lol. 219 has that Monero tie-in with the garlic +**\** i like #239 but the kerning is awful from a typography perspective +**\ [guzzi]** why the halloween colors anyway? +**\** bear in mind, too, that we can change it later on +**\ [i2p-relay] {-moneromooo}** anonimal: https://paste.fedoraproject.org/426683/14736136/ +**\ [anonimal]** moneromooo: thanks +**\** guzzi: the orange? coz of the Monero logo's colours, I'd guess +**\** 246 is a nice mix of both 146 and 239 imo +**\ [anonimal]** fluffypony: how much *can* we change after we pick one? +**\** anonimal: we can always pay them more to make more changes +**\** we also made changes to the Monero logo after delivery +**\** to fix the kerning +**\ [guzzi]** got it +**\ [i2p-relay] {-moneromooo}** Not sure what numbers these map to, no numbers in the URLs +**\** I like 239 btw +**\** if between 239 and 146 then 239 +**\** wouldnt logo selection work better (more efficiently) by filtering out the ones no one likes +**\** moneromooo: your first link is #239 +**\ [anonimal]** moneromooo: the garlic one was top choice #239, the other one I don't know +**\** and then having an in depth look at a smaller selection +**\** pero: no this is much more fun, the entire dev meeting will be "but I like this logo" :-P +**\ [i2p-relay] {-moneromooo}** THanks :) +**\** in that 223 series, is that a Tau, for Tor? +**\ [anonimal]** moneromooo: I like the mask idea but the artist took the easy way out and just plastered it next to text. +**\** between 146 and 239 for me +**\** 236-237 I have to exclude, there's a Circle-K convenience store chain in California that looks like that +**\** why not make it 146 and just go a different color, it would still feel monero-ish +**\** is this where the meeting for Monero is? +**\** 239 is nice because it bring the "onion" that is easly recognised by tor users +**\** 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 +**\** Flyfree10: finished +**\** how did it go? +**\ [anonimal]** hyc: re: tau, that's a bold stretch, I think only you and a few others would have pointed that out +**\ [anonimal]** e.g., artist probably wasn't thinking on that level +**\** Hmm. Wordy I guess. There will be logs from dEBRUYNE, most likely. +**\** I'm gonna go with 239 +**\** Flyfree10: Kovri meeting in-progress, wait a bit and Monero dev meeting minutes will be on reddit I'm sure. +**\** 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 +**\** ok +**\ [anonimal]** Alright, I'm seeing a lot of #239 (also my top pick) +**\ [i2p-relay] {-moneromooo}** People are going to be confused between garlic/onion, I'm sure. +**\ [anonimal]** They should be, they are very similar in terms of routing +**\** they are, moneromooo, but I don't think they'll be confused enough to care +**\** it's not like people make privacy decisions based on routing models :-P +**\** yeah i think the garlic just looks confusing. +**\ [anonimal]** So should we do a vote of "anything \*not* 239"? +**\** yeah. it's close enough. several of the others leave me wondering WTH they are. +**\<\_Slack> ** 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 +**\ [anonimal]** Strong opinions on \*not* 239? +**\ [i2p-relay] {-moneromooo}** Well... "I use kovri, that's a privacy program for that onion type thing" +**\ [anonimal]** How can we improve #239? +**\** otoh I don't think I've ever heard a non-technical person talk about onion routing, moneromooo +**\** personally i also like 245, the green symbols strong roots +**\** 239 needs a different font and some kerning +**\** we can allways tell "we use garlic instead of union to keep vampires away from the network" +**\** xmr\_eric: there were a bunch of those, like hundreds of them, we rejected them in favour of #239 +**\ [i2p-relay] {-ArticMine}** 239 Possible confusion with Tor. Could be dicey from a trademark perspective +**\<\_Slack> ** cool +**\ [EinMByte]** #239 looks nice +**\ [EinMByte]** Don't think there would be trademark issues +**\ [anonimal]** medusa_ I like the logo but not so much the colour. +**\** if you took the word kovri from 254 and stuck it into 239 it would look significantly better +**\** 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) +**\** definitely if we were claiming something like that in text +**\ [anonimal]** pero: good point +**\** anonimal at the begining I didnt like the colors of monero too, but grown on me +**\** 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 +**\** 239 isnt horrible, but it definitely doesn't feel like it has a connection to Monero +**\** other than the color, it doesn't really feel like it's closely bound to the Monero project. +**\** agree ferretinjapan +**\ [i2p-relay] {-ArticMine}** There are common law trademarks by "use in commerce" in both cases +**\** If that's intentional then awesome, but otherwise, people may not even connect monero and kovri together as being sister projects. +**\ [i2p-relay] {-moneromooo}** Then... we could superimpose: 239 with added arms on top of the monero M, trying to hide it :D +**\** i think my the minimal pacmans from 88 and 81 arent bad either +**\** anonimal: what are your thoughts on the "connection to Monero" thing - do we want it to be more tightly coupled or not? +**\** then xmr\_eric's would be fine +**\ [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 +**\ [guzzi]** fluffypony i agree if there needs to be aconnection to monero that is important to discussion on 239 +**\** or at least a starting point. maybe turn the circle background into the garlic +**\** 139 and 138 too +**\ [guzzi]** anonimal, aggreed on the K statement. +**\** 138 is a more subtle variant of 239 +**\ [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" +**\** hm, yeah, so subtle I didn't notice it before ;) +**\** a fusing of the two whould be nice +**\* tewinget** (tentatively) casts his vote for 247, or some iteration upon it. +**\** anonimal: I guess because it's like Apache projects, that all fold into the Apache structure / governance etc. +**\ [EinMByte]** the color by itself should be a sufficient connection +**\ [anonimal]** #247 looks so terribly awkward +**\** that's why I liked #246, but maybe it's a bit too plain +**\** 138 reminds me more of saturn's rings than a garlic +**\ [anonimal]** #246: the flaming egg +**\** I'm still going with 239, final answer. +**\** lol +**\** or the tennisball with fuzz on top :) +**\ [i2p-relay] {-ArticMine}** Possibly 251 No onion / garlic +**\** well, If it was to be something completly distinct from monero I would vote 249 +**\ [anonimal]** Let's decide on 1 and see how we can improve it. +**\** 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. +**\ [anonimal]** I'm voting #239 +**\ [guzzi]** we ef have two camps here. use a letter like Monero logo or -- somethinge else00 +**\** we have 8 days to make a decision, tewinget +**\** shrink them down to 16x16 favicons, most of them will look like garbage +**\** tbh I kinda like #239 too +**\** and I think the colour is indeed enough of a connection +**\ [EinMByte]** #239 should do +**\** 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. +**\** also we can ALWAYS change it later +**\** hyc except for 135 and 134 +**\** not like we have a branding department to report to +**\** i think tus\_99 definitely has the best handle on the design +**\** ok, 135 isn't bad. +**\** and squarepoint the best typography +**\** anonimal: as the CEO of Kovri (kidding) you get to decide, I think you've heard enough opinions, and we'll defer to you +**\ [anonimal]** fluffypony: thank you +**\ [anonimal]** #239 it is \*but* we should work out font and see if artist can improve the idea. +**\** absolutely +**\** I'll finalise the 99designs competition in the next couple of days, and give the artist final direction +**\ [anonimal]** Who here had thoughts about kerning, etc.? +**\ [anonimal]** (backlog too big to read) +**\** that was i +**\** pero did +**\ [anonimal]** pero could you give specifics so fluffypony can relay to artist? +**\** sure i'll pm him something in a little bit +**\ [anonimal]** Thanks pero +**\ [anonimal]** fluffypony: will we ever have a one-on-one with tus_99? +**\** I don't think so +**\ [anonimal]** As in, ever speak directly with him? +**\ [anonimal]** Oh +**\** I think we send him direction and then he's like "ok here" and that's it +**\** but we will have the source +**\ [anonimal]** Odd world we live in. +**\** and we can modify it from there +**\ [anonimal]** Ok great +**\ [anonimal]** So, resolved with #239? +**\ [i2p-relay] {-ArticMine}** I have to leave now +**\ [anonimal]** Thanks ArticMine +**\ [EinMByte]** anonimal: Yes, let's move on +**\** indeed +**\** rubber stamp of approval and all that +**\ [anonimal]** Sold, to #239! +**\ [anonimal]** Alright next +**\ [anonimal]** 2. Greetings +**\ [anonimal]** 3. Brief review of what's been completed since the previous meeting +**\ [anonimal]** Hi +**\ [anonimal]** (lol) +**\** lol +**\ [EinMByte]** Hi +**\ [guzzi]** hi +**\** EinMByte thanks for taking the time to join the meeting, I know you're busy +**\ [anonimal]** git log --pretty=oneline --since=2weeks --no-merges | wc -l +**\ [anonimal]** 30 +**\ [anonimal]** Fixes, features, improvements. +**\ [anonimal]** Highlights include: +**\ [anonimal]** - The infamous transports "5 - 6 = 18446744073709551615" diffie-hellman keypair supplier bug, now fixed +**\ [anonimal]** - AddressBook fixes/enhancements +**\ [anonimal]** - HTTP fixes/enhancements +**\ [anonimal]** - Clearnet / in-net download impl +**\ [anonimal]** - Coverity resolutions +**\ [anonimal]** - More in log +**\ [anonimal]** Please pipe-in if I missed something we should note +**\ [anonimal]** Oh yes, more NTCP fixes thanks to EinMByte +**\ [anonimal]** And more on the way (not yet merged) +**\ [anonimal]** Anything else on 3.? +**\** i'd like to point out that the Kovri instance that runs i2p-relay +**\** no longer suffers from memory leaks (although they were only occasional before) +**\** thank you for fixing :) +**\ [EinMByte]** There's a few more leaks that need fixing +**\** (that server has 128gb of RAM, so a memory leak is kinda humorous) +**\ [anonimal]** Hard to pin down. One would think they would have checked that 5 - 6 != 0 +**\ [anonimal]** s/they/the mathematical magician/ +**\ [EinMByte]** fluffypony: Please tell us when you see inbound NTCP happening :) +**\ [anonimal]** EinMByte that'll probably never happen until we fix it, lol +**\** will do lol +**\ [EinMByte]** If we even need to fix it +**\ [anonimal]** Something needs fixed somewhere +**\ [EinMByte]** Probably, yes +**\ [anonimal]** 4. Code + ticket discussion / Q & A +**\ [anonimal]** So latest hot topic was release planning for 33C3 +**\ [EinMByte]** Is that done? Wiki still looks empty +**\ [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 +**\** whoop whoop +**\ [anonimal]** No, wiki not done +**\ [anonimal]** I've sorted out open issues, +**\ [anonimal]** will open a few more directly related to first release, +**\ [anonimal]** will do more roadmap work once release cycle is codified, +**\** and now that we're closer to logo I can get back on the website / email bandwagon +**\ [anonimal]** we sill need a solid answer on CI +**\** anonimal: which CI question? +**\ [anonimal]** Mr. build bot, the devops guy who was supposed to be at the monero meeting today +**\** hello +**\ [anonimal]** Maybe I missed the discussion, I don't know +**\** pigeons it is :D +**\ [anonimal]** Hi pigeons +**\** oh +**\** lol +**\** anonimal sorry, it was at the beginning of the Monero meeting +**\ [anonimal]** My fault then, I came in late +**\ [anonimal]** When are we throwing out travis? +**\** 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 +**\** anonimal: we'll probably break the chassis on Monero first +**\** and setup IRC hooks etc. +**\** and then adding Kovri will be a snap +**\ [anonimal]** Awesome and awesome, thanks pigeons and fluffypony +**\** luckiy buildbot irc hooks are vey automactice and easy +**\** hashtag excite +**\ [anonimal]** Ok great, so we'll keep in touch then overtime. +**\** cool. +**\ [anonimal]** Next issue, fluffypony did you want me to bring-up/add something to the agenda? +**\ [anonimal]** fluffypony: was it for website or email or both? +**\** anonimal: both +**\** can't think of anything else +**\** re: 33C3 I'll be putting a post up on the forum in the next little while so everyone knows what's potting +**\** anonimal checking issues +**\ [anonimal]** Ok, they've been milestone'd +**\** awesomesauce +**\** when shall we three meeting again? (to quote Macbeth) +**\ [anonimal]** Alright, open issues should be organized enough / milestone'd where appropriate +**\ [anonimal]** Anything else on 4.? +**\ [anonimal]** (4. Code + ticket discussion / Q & A) +**\** nothing from my side +**\ [EinMByte]** So what I'm currently working (of the milestoned issues): #191, #312, #342 +**\** [guzzi] i will keep working on coverety isues +**\ [EinMByte]** Will do #213 later +**\ [EinMByte]** For the memory leaks (and other memory problems): the ntcp branch has a couple of fixes +**\ [EinMByte]** Currently working on a (partial) fix of #342 +**\ [anonimal]** You're not assigned to #342, I can add you unless you wanted to add yourself +**\ [EinMByte]** I'll assign +**\ [anonimal]** https://github.com/monero-project/kovri/issues?q=is%3Aopen+is%3Aissue+milestone%3A0.1.0-alpha+assignee%3AEinMByte +**\ [anonimal]** Ok +**\ [EinMByte]** So to be clear, the backtrace you posted 4 hours ago is what I fixed +**\ [EinMByte]** (but not yet pushed because unforseen issues) +**\ [anonimal]** I posted two. I imagine you're talking about the NTCP one +**\ [EinMByte]** Yes +**\ [EinMByte]** Won't touch the client issue for now +**\ [anonimal]** Yay client +**\ [anonimal]** https://github.com/monero-project/kovri/issues?q=is%3Aopen+is%3Aissue+milestone%3A0.1.0-alpha+assignee%3Aanonimal +**\ [anonimal]** That covers a small fraction of what I'll end up fixing / working on +**\ [EinMByte]** For #187 (NTCP core issues), the main thing left to fix is the inbound NTCP +**\ [anonimal]** I just don't assign myself in case someone else wants to grab something +**\ [anonimal]** EinMByte: yeah, running tcpdump against kovri --log-to-console 0 --v6 1 --enable-ssu 0 +**\** \* anonimal pasting +**\ [EinMByte]** Yes, and I'd ask everyone else wanting to help out to do the same +**\ [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 +**\ [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 +**\ [EinMByte]** guzzi: Try this if you get bored with coverity issues +**\ [anonimal]** Let's take mroe NTCP chat outside of the meeting since this is being logged +**\ [EinMByte]** (--v6 not necessary, just see if you get inbound traffic, and paste logs when you do) +**\ [anonimal]** \*more +**\ [anonimal]** Yes, I know, just happens to be the instance that is running +**\ [EinMByte]** ok +**\ [anonimal]** guzzi any questions about tickets, etc.? +**\ [anonimal]** I'll be around after meeting, moving on. +**\ [anonimal]** 5. Any additional meeting items +**\ [guzzi]** no you have given me good tips lately +**\ [guzzi]** i appreciate it. +**\ [anonimal]** Ok good, glad to help. +**\** that's it from me +**\ [anonimal]** Glad to have you onboard. +**\ [anonimal]** Nothing from me on 5. +**\ [anonimal]** Last call for 5. +**\** going once, going twice, sold! +**\ [anonimal]** 6. Confirm next meeting date/time +**\ [EinMByte]** What about the website, though? +**\** * anonimal backtracks to 5. +**\ [EinMByte]** (or did I just miss that) +**\ [anonimal]** fluffypony: do you have any details yet? +**\** EinMByte: I said that now that we're wrapping up the logo I can get back on the bandwagon with that +**\ [anonimal]** And it \*will\* be online by first release fluffypony, yes? +**\** absolutely +**\ [EinMByte]** Well, it was supposed to be done by today +**\ [anonimal]** lol, EinMByte cracking the whip +**\ [EinMByte]** So, what's the real deadline? +**\** 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 +**\ [anonimal]** I think deadline should be at the very least a week before 33C3. +**\** anonimal: long before then +**\** we're keeping it simple initially, remember +**\ [anonimal]** As long as it works and doesn't look terrible, I'm happy. +**\ [anonimal]** Should we make a concrete date for website like we are for kovri release? +**\** let's see where we get before the next meeting and re-address it then +**\ [EinMByte]** ok +**\ [EinMByte]** Let's put that on the roadmap +**\ [anonimal]** One thing for 5., +**\ [anonimal]** questioning if we should move build instructions to wiki +**\ [anonimal]** (github wiki) +**\ [anonimal]** A) easier, doesn't pollute git log B) makes us reliant on github +**\ [anonimal]** A good, B bad. +**\ [anonimal]** Any thoughts? or we can move this to next meeting +**\** I think that's a bad idea +**\** if someone clones the repo they should have everything they need right there +**\ [anonimal]** But if they don't have network connectivity, kovri is useless +**\ [EinMByte]** I tend to agree with fluffypony +**\ [anonimal]** And if they can clone from github, they have access to the website +**\** anonimal: what if Github blocks Tor access after they've cloned it? +**\ [anonimal]** And if they have access to either, they can read build instructions. +**\** not everyone will be able to checkout an old commit to get build instructions +**\ [EinMByte]** There could be a tutorial of some sort in the wiki +**\ [EinMByte]** But basic build instructions should be in the repo +**\ [anonimal]** Alright, no arguments from me, just questioning +**\ [anonimal]** Anything else on 5.? +**\ [anonimal]** We're out of time +**\ [anonimal]** 6. Confirm next meeting date/time +**\ [anonimal]** 2 weeks from now, works best I think. +**\** 2 weeks from now plz +**\ [anonimal]** Ok, sept. 25th, same time +**\** ok +**\ [EinMByte]** ok +**\ [anonimal]** Thanks everyone. Thanks #monero-dev for the logo input too +**\ [guzzi]** ok \ No newline at end of file diff --git a/_posts/2016-09-11-overview-and-logs-for-the-dev-meeting-held-on-2016-09-11.md b/_posts/2016-09-11-overview-and-logs-for-the-dev-meeting-held-on-2016-09-11.md new file mode 100644 index 00000000..d994b582 --- /dev/null +++ b/_posts/2016-09-11-overview-and-logs-for-the-dev-meeting-held-on-2016-09-11.md @@ -0,0 +1,305 @@ +--- +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 + +**\** Hi all +**\** I'm on my phone +**\** Hi all +**\** hello +**\** NoodleDoodle, TheKoziTwo, +**\** anyone else? +**\** hola +**\** luigi1112, listening or cruising ;) +**\** jwinterm +**\** lol +**\** hyc and moneromooo are around afaik +**\** 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) +**\** Well I think let's start with 0MQ, tewinget +**\** Then you can talk and I don't have to +**\** :-P +**\** 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. +**\** will try to get most of that done today or tomorrow. +**\** This is daemon only right now right? +**\** daemon RPC, and a lib to use it that libwallet will call into. +**\** ok - and then next thing after daemon is buttoned up is a wallet 0MQ endpoint right? +**\** 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. +**\** Ok so tewinget let me ask about the backwards-compatible stub +**\** Coz obviously we still need a stub for those that insist on touching the daemon using old RPC +**\** Is that just a matter of refactoring it out of the daemon? +**\** 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" +**\** That's fine - I meant as a later exercise +**\** Just trying to gauge the amount of effort it's going to take +**\** hmm, well, a wrapper around the old RPC to hook into the new wouldn't be *too* hard... +**\** just tedious +**\** I know it's tedious +**\** What if we made it generic +**\** Like it translated the RPC call directly +**\** If it fails pass the error back +**\** Oh wait that won't work +**\** The 0MQ calls are different +**\** not hugely different, but different in some cases, yes. with good reason... +**\** Ok so tedious because it requires everything implemented as a 0MQ client, got it +**\** As a practical matter +**\** We need to consider something like cppnetlib for TLS and auth +**\** I'm trying to make switching costs as low as possible, but I can't make it nonzero. +**\** And implement that as a matter of some urgency, since the entire net_skeleton thing was a colossal waste of time +**\** Ok tks tewinget - anything else from your side? +**\** yea, I might make TLS and auth a priority ahead of wallet RPC (since it will need auth anyway) +**\** other than that, not really. +**\** carry on. +**\** "I can't make it nonzero" <-- excellent! +**\** Hokay +**\** LOL +**\** Nice catch +**\** lol +**\** breaking: Monero contributor works for free! +**\** just tuning in, was teaking my ARM code +**\** god dammit. +**\** Instant delivery! +**\** well, moneromooo, I can't +**\** because it has to use ZERO MQ +**\** Hah hah +**\** #SavedIt +**\** :P +**\** #dadjokes +**\** At any rate +**\** I'd like to introduce pigeons +**\** He's recently started doing some stuff with me +**\** and he's kindly going to help us redo our sysops / devops +**\** For all projects, including Kovri +**\** nice +**\** Hi guys. :) +**\** Hi +**\** hey there +**\** pigeons: tell us a bit about yourself or whatever +**\** "Long walks on the beach" and all that +**\** I guess the population explosion kinda demanded more ops +**\** I see what a sysop is, but not a devop. +**\** I like pina coladas and getting lost in te rain. Ive been syadmin type stuff forever. +**\** Hi pigeons +**\** moneromooo: devops is like CI and build boxes and that +**\** devops is the new term for brogrammers who use docker and jenkins CI etc +**\** Oh nice :) +**\** Hah hah +**\** I think a devop is a developer with rootpw on all production machines. sysaop's worst nightmare :P +**\** Devops-as-a-Service +**\** lol +**\** but yeah im gonna try and get buildbot ci going the system chromium and some others use +**\** get builds and tests for arm, windows, mac, freebsd, linux 32 64 +**\** Also the immediate aim is to be able to push nightlies to the site +**\** nice +**\** #1047 did this +**\** oops +**\ {-guzzi}** hi pigeons +**\** So the broader community can test without waiting for fluffypony to build +**\** eventually look at gitian style reproducible builds +**\** ARM is gonna be 3 distinct builds, ARMv6, ARMv7, ARMv8 +**\** rapidly proliferating... +**\** ok cool +**\** hyc: I think we'll have to drop ARMv6 for performance concerns +**\** If not now then soon +**\** ok, fair enough +**\** Also on that note +**\** yeah, the perf/watt just isn't there on ARMv6 +**\** Am I correct in saying that QEMU is about the only way we're going to get arm7/8 build boxes? +**\** Or does anyone know of hosted native arm boxes? +**\** there's an ARM VPS provider out there +**\** yeah what are they called again, there is one +**\** someone recommended one to me just the other day, oddly enough...can't remember the name. +**\** lol +**\** awww. i still use my pi zero nodes +**\** which are arm v6 +**\** bitjedi: they'll choke on RingCT +**\** scaleway.com ? +**\** scaleways? +**\** yeah +**\** are u sure it's cpu and not io? +**\** Awesome +**\** Isn't scaleways native and not virtualised? +**\** I seem to vaguely recall +**\** I think it was Scaleway +**\** hm, they claim bare metal, yeah +**\** theres one ovhi or somone in scandanavia +**\** Ok +**\** Also the implication is that anyone relying on the Mac / 32-bit test boxes should expect an impending change +**\** I think anonimal primarily uses them +**\** Also we'll hopefully be able to provide broader access to test hardware in future +**\ {-anonimal}** * has yet to use 32-bit boxes +**\** Ok then FreeBSD +**\** Has anyone tried the WIP boost 1.60 port on BSD? +**\** haven't touched BSD in years +**\ {-anonimal}** Last I checked, build failed hard on freebsd for monero. +**\ {-anonimal}** Works with kovri. +**\** xmj is our resident BSD expert and even he hasn't touched boost 1.60 +**\** If anyone wants to volunteer to play with that great +**\** We also need to start thinking about packaging +**\** lol relevant PR is relevant +**\** hyc how do you guys handle packaging for like Debian / Ubuntu? +**\** eh, OpenLDAP Project is source-code only, distros do their own packaging +**\** Coz my concern with farming it out is that we end up with old versions on old distros +**\ {-anonimal}** fluffypony: I was planning to work with the monero bsd build (only freebsd though) once we get kovri releases going +**\** yes, that's a pervasive problem with distros +**\** Tks anonimal - I'll also fiddle +**\** When I have time, so never :-P +**\** Ok next thing +**\** moneromooo: want to talk about the rct serialisation changes? +**\** And the impact on testnet +**\** It's finished. It's on github ready to merge. And it will need reorganizing on testnet, yes. +**\** So, I guess someone with hash power will have to pop N blocks till before v4, and mine. +**\** After a few daysm it'll reorg for everyone :) +**\** And we'll get to test deep reogs. +**\** so anyone mining testnet right now should stop +**\** Unless you want to test stuff. +**\** i exported the raw blockchain up to 800499. that's before v3, right? +**\** well that's not entirely necessary >\*\*\_>\*\* +**\** Yes. +**\** and v4 is... ? +**\** 802000 or so iirc ? +**\** 801220 +**\** XMR up or down +**\** ah, k +**\** I think my miner is off atm +**\** it had that hiccup and I never fixed it coz stuff +**\** rct soon! +**\** ok so moneromooo +**\** It had to be done +**\** are you guys forking the testnet ? +**\** when it loads the blockchain on the new code +**\** im gonnad do a testnet classic +**\** it *should* freak out +**\ {-anonimal}** Is this the meeting where we can discusses CI for CD? +**\** and rollback? +**\** anonimal: CD? like compact discs? +**\ {-anonimal}** Laser-only releases +**\** It'll probably moan a bit, but not overly. +**\** :-P +**\** ok but what I mean is +**\** when we load a blockchain off disk we don't re-verify +**\** the dev meeting is still going on or to late ? +**\** so will we have to manually pop blocks? +**\** still going on MalMen +**\** Yes. +**\** ok so I'll merge tomorrow afternoon, gives us a day for review +**\** Just the miner. Others will just reorg when the miner passes the old chain's diff. +**\** (hopefully) +**\** and then I'll do some block-popping tomorrow night +**\** and hopefully deep reorgs +**\** luigi1112: btw, you'll want to read the latest get_transaction_hash and comment. It's still 3 parts. +**\** ok +**\** then the next thing is our hard fork date and the next release +**\** we're planning on finalising final bits and releasing 0.10 shortly +**\** but obviously RingCT (ie. v4 blocks) is not ready for even a final inclusion in this code freeze +**\** given that we're still making changes +**\** 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 +**\** either: +**\** 1. we leave v4 till March 2016 +**\** 2017 +**\** tks 2017 +**\** 2. we change the "complain about a fork" date to like end-of-November, with an aim to forking to v4 end of December +**\** so coded freeze beginning of December +**\** (this would make RCT transactions potentially available on mainnet from Jan 1) +**\** but obviously there's the risk of breakage +**\** maybe December is too soon, how about January? +**\** so if we had to do Jan, then when do we do v5? +**\** March is too close to Jan for v5, imho +**\** fluffypony My preference is 2, but my biggest concern is the amount of time left for finalization of development and testing +**\** We don't necessarily have to decide the exact dates now, but I think option 2 would be best +**\** ok so what if we did 2, but then pushed the v5 fork to September next year +**\** if we have v4 in January then June/July would be OK +**\** that way RCT is available on mainnet early on, but if anything breaks we have 9 months to fix it +**\** hyc: I don't want to go too far away from our schedule +**\** ok +**\** \ if we have v4 in January then June/July would be OK <= Fine with that too +**\** sounds reasonable to me +**\** Like I said, we can always decide on the exact dates later +**\** like this is major enough to warrant a change, but we should aim for a singular change +**\** so march/september is the cadence we're aiming for? +**\** Yes I like the idea of advancing V4 fork but keeping the v5 fork on schedule +**\** I agree, singular deviation from the schedule is preferable. +**\** ok +**\** hyc: yep +**\** fluffypony: most people will use Ring CT transactions anyway +**\** so we bring v4 a bit forward, and leave v5 as scheduled +**\** yes +**\** dEBRUYNE: we can always make it the non-default, like we did with transfer_new +**\** sounds good +**\** yeah agree +**\** agree +**\** ok so we'll move the freak-out to early December, and actual fork block height will be decided at that code freeze +**\** but likely late Dec / early Jan or so +**\** and v5 stays for September 2017 +**\** consensus: reached! +**\** \o/ +**\** (it's so easy when you're tiny and only like 5 people have to agree, lol) +**\** I think that's about it from my side, there's something else but I completely can't remember +**\** is there anything else that anyone wants to bring up? +**\** I dunno multisig for bitcoin was a bitch... +**\** current freeze, release date? +**\** since Ilya's not here... +**\ {-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 +**\** that only had 8 guys +**\** ferretinjapan: lol +**\** a quick update on multisig preferably +**\** Do you want to wait for the fee change before binaries ? +**\** lurker: https://shnoe.wordpress.com/2016/03/22/ring-multisignature/ +**\** it's whitepaper-only right now +**\** fluffpony - the GUI wallet. Languages and regional variations. +**\** oh +**\** Hi guys can I ask about public wallet build release dates +**\** yes moneromooo thanks for reminding me +**\** tag->release->binaries will be in the coming week, hopefully +**\** there are two things still remaining +**\** 1. fee changes (lower min-fee, bind it to the inverse of the block median as suggested by ArticMine) +**\** 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 +**\** tewinget can you point me to the list of 0qm commands that you have already? +**\** and we rely on DNSSEC for MoneroSeeds and MoneroPulse +**\** I have some sugestion +**\** moneromooo is coding the fee changes +**\** 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 +**\** if not it'll have to hold off till the next release +**\** 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. +**\** ok +**\** fluffypony: would it be feasible to provide trezor binaries? +**\** dEBRUYNE: I haven't actually looked at it properly, and NoodleDoodle isn't around to give his opinion +**\** I see, he's still working on the Ring CT bit, so probably better to wait until that is finished to provide them +**\** 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 +**\** Kermit_: do you mean the GUI wallet, or the next tagged release? +**\** Yes gui +**\** fluffypony - Okay. Just to say there are some oddities with the current flag page. Can expand at a later time. +**\** Kermit_: not certain yet - I'll look at building beta binaries in the next week or so +**\** Thanks +**\** kintaji: yeah maybe best thing to do is drop it out the wizard initially +**\** and add it back in later on +**\** 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. +**\** fluffypony - yep. sounds like a good idea. +**\** ok anything else or can we start the Kovri meeting? +**\** any other volunteers to test ARMv8 builds? +**\** oooh I will hyc +**\** yea i can +**\** cool, I'll have atarball ready later tonight +**\** tewinget you are writing your rcp calls with up letters right ? +**\** fluffy i have centos 64bit on my rpi3 fyi +**\** hyc: is an R8 ARM processor an armv8? +**\** coz if so then I have a bunch of C.H.I.Ps lying around that I can test on +**\** I don't know what R8 is. what box is that? +**\** MalMen: the class names are CamelCase, but the methods (currently) are "word_word_word". No reason that can't change, of course. +**\** ahhhh, nice +**\** AllWinner R8 +**\** I was in mind that you where using WordWordWord +**\** ok I see it +**\** would sugest wordWordWord +**\** "Allwinner R8 is SoC designed based on A13 featuring one core Cortex-A8 ARM CPU with Cedar Engine VPU and Mali 400 GPU" +**\** nope . Cortex-A8 is ARMv7 +**\** ah ok +**\** well that sucks +**\** hi meeting-bot! +**\** 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. +**\** well, I am checking the bitcoin rcp and they use wordwordword, I think i like word_word_word better \ No newline at end of file diff --git a/_posts/2016-09-19-monero-0.10.0-released.md b/_posts/2016-09-19-monero-0.10.0-released.md new file mode 100644 index 00000000..ff4481b5 --- /dev/null +++ b/_posts/2016-09-19-monero-0.10.0-released.md @@ -0,0 +1,100 @@ +--- +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 \ No newline at end of file diff --git a/_posts/2016-09-21-a-statement-on-the-mwr-labs-disclosure.md b/_posts/2016-09-21-a-statement-on-the-mwr-labs-disclosure.md new file mode 100644 index 00000000..2a586f7c --- /dev/null +++ b/_posts/2016-09-21-a-statement-on-the-mwr-labs-disclosure.md @@ -0,0 +1,41 @@ +--- +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* \ No newline at end of file diff --git a/_posts/2016-10-02-logs-for-the-Kovri-dev-meeting-held-on-2016-10-02.md b/_posts/2016-10-02-logs-for-the-Kovri-dev-meeting-held-on-2016-10-02.md new file mode 100644 index 00000000..6ed5efbb --- /dev/null +++ b/_posts/2016-10-02-logs-for-the-Kovri-dev-meeting-held-on-2016-10-02.md @@ -0,0 +1,447 @@ +--- +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 + +**\** anonimal: all yours :) +**\ [anonimal]** 1. Greetings +**\ [anonimal]** 2. Brief review of what's been completed since the previous meeting +**\ [anonimal]** 3. ∫alti https://github.com/EinMByte/salti +**\ [anonimal]** 4. "Kovri Garlic Router Project" + logo +**\ [anonimal]** 5. #46 +**\ [anonimal]** 6. #337 https://geti2p.net/en/docs/naming +**\ [anonimal]** 7. API discussion with `#monero-dev` (#350 #351) +**\ [anonimal]** 8. Code + ticket discussion / Q & A +**\ [anonimal]** 9. Any additional meeting items +**\ [anonimal]** 10. Confirm next meeting date/time +**\ [anonimal]** 1. Greetings +**\ [i2p-relay] {-moneromooo}** UDP meeting +**\ [anonimal]** Hi +**\ [EinMByte]** Hi +**\ [anonimal]** 2. Brief review of what's been completed since the previous meeting +**\ [anonimal]** Areas of work done or completed since last meeting 3 weeks ago: +**\ [anonimal]** - Transports improvements/fixes and EinMByte's SSU branch was merged! +**\ [anonimal]** - Client/app improvements/fixes and client-crypto related (client signing type, https ciphers, etc.) +**\ [anonimal]** - Almost all Coverity issues resolved, still a handful left +**\ [anonimal]** - Fixes/enhancements and more +**\ [anonimal]** - pero's fantastic work with the logo +**\ [anonimal]** Oh, .ny new open issues - that's a good thing though, right? ;) +**\** lol +**\ [anonimal]** Anything else did I miss for 2. or move onto 3.? +**\ [EinMByte]** No, go ahead. I have only limited time so let's be productive +**\** 3 plz +**\ * anonimal** having hard time keeping track of all the work that passes over several weeks; its usually a very broad range of areas +**\ [anonimal]** 3. ∫alti https://github.com/EinMByte/salti +**\ [anonimal]** So, EinMByte and I are starting preliminary work on a firefox extension that will tremendously help Kovri and I2P +**\ [anonimal]** I just want to mention this here in case there are any interested webdevs +**\ [anonimal]** Anything you want to add EinMByte? +**\** Salti is basically like the Kovri GUI :-P +**\ [EinMByte]** fluffypony: No it isn't +**\ [EinMByte]** The kovri GUI is called qtoopie +**\ [anonimal]** EinMByte: no, the GUI does not exist yet. +**\ [anonimal]** qtoopie is an i2pcontrol client. +**\ [EinMByte]** Salti is a firefox add-on similar to Tor browser bundle +**\** lol +**\ [EinMByte]** anonimal: Yes (but see also the relevant zzz.i2p thread from long ago) +**\* fluffypony** was making a joke +**\ * anonimal** doesn't have time to search zzz.i2p, link appreciated +**\ [anonimal]** Any webdevs present? +**\ * EinMByte** doesn't have time to find zzz.i2p topic +**\** i could technically be a webdev +**\** im c/c++ swift/obj-c nodejs/MEAN stack +**\ [anonimal]** Hi patthehuman. Have you done any work with firefox add-ons? +**\** no, however, i dont think it would be very difficult +**\ [EinMByte]** We won't be needing very complex stuff by the way, just using the webextensions API +**\** would it be chrome and firefox..? +**\ [anonimal]** patthehuman: webext I believe could support both? but we're aiming for firefox. +**\ [EinMByte]** (we'll be setting a few settings and intercepting a few requests) +**\ [EinMByte]** patthehuman: yes +**\** mk +**\ [anonimal]** patthehuman: we can give more details after the meeting if you idle #kovri-dev +**\ [EinMByte]** (although initially firefox, but the API should be mostly the same) +**\** ok +**\ [anonimal]** Anything else on 3.? +**\** ill stick around, interested in hearing full scale +**\ [EinMByte]** Let's move to 4 +**\ [anonimal]** 4. "Kovri Garlic Router Project" + logo +**\ [anonimal]** pero: you there? +**\** yep +**\** want me to take over? +**\ [anonimal]** What do you have for us today? +**\ [anonimal]** Let's spend very little time with the visual aspect, we have bigger issues to tackle with kovri +**\ [anonimal]** Just a run down so everyone knows where we are +**\ [anonimal]** And links if possible +**\** http://imgur.com/a/ptOHb +**\** after a 'long' process we're down to 3 fonts +**\** the idea is to pick the font with the best looking letters that comprise the word kovri +**\ [anonimal]** And what about https://i.imgur.com/UDsSuTg.png +**\** and/or eliminate some concepts +**\ [anonimal]** I guess Coral is out of the question +**\** lato second from bottom +**\** yea coral was cut +**\** work sans is largely similar and coral seemed inferior on some letters as well as less versatile at smaller font sizes iirc +**\ [EinMByte]** I'd also drop open sans +**\** in the 'a' system +**\** exo 2 is the logo font - but it doesn't work as well for text +**\** so i chose open sans to complement it +**\ [EinMByte]** Sorry, I mean the exp 2 / open sans combination +**\** a5 features exo2 as subtext so you can see how that would look like +**\ [EinMByte]** But overall, the differences are really minor. Just trying to reduce the search space +**\** i personally think not going with A or B would be a mistake +**\** their K is really nice and adds a subtle touch of personality +**\ [anonimal]** pero: its unfair because I can't accurately compare c4 because of orange subtext +**\** hmm +**\ [anonimal]** I prefer work sans because the k contracts with the orange curve in the garlic +**\ [anonimal]** So is our next step font? +**\** http://imgur.com/a/DOcyy +**\ [anonimal]** Is subtext really that thick with work sans? Eww +**\* fluffypony** isn't wild about the orange subtext +**\** yea the orange subtext sucks imo +**\ [EinMByte]** Ok, let's handle this another time +**\ [EinMByte]** (or use a random number generator) +**\** no it could be thinner +**\ [EinMByte]** Let's go with column b then +**\ [anonimal]** lol no way on the random gen +**\** lol random number gen could be fun +**\** imgur is also 'optimizing' the png +**\** "best of 3?" +**\** keep in mind ^^^ +**\** 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 +**\** the actual face itself is not a huge issue imo +**\ [anonimal]** pero: let's narrow down our options to rows 2, 4, and 6 +**\ [anonimal]** Can you throw those onto a page? +**\** there probably will be instances where the 'router project' text is unnecessary +**\** I think rows 3 and 4 won't work because, as endogenic pointed out, kovri is not an English word +**\** looks like kavri +**\** and just the logo and kovri would suffice +**\ [anonimal]** Are we all talking about https://i.imgur.com/Ge1FZTp.png ? +**\** ideally as a brand it should be able to stand out on its own +**\ [EinMByte]** Yes, the garlic as an "o" could be confusing +**\** anonimal no, I'm looking at http://imgur.com/a/DOcyy +**\ [anonimal]** Same thing +**\** pero: for that reason consider favoring options with tighter kerning +**\** oh +**\** lol +**\ [anonimal]** Who in their right mind things that garlic is an 'A'? +**\** another thing to add +**\ [EinMByte]** So let's narrow it down to 2 and 6 +**\ [i2p-relay] {-ArticMine}** 2 in Open Sans is the most readable +**\** the garlic wasn't designed with this use in mind +**\** the garlic could be optimized down the road +**\ [EinMByte]** anonimal: Remember that the spectator potentially doesn't know "kovri" +**\** ideally after a font has been chosen +**\** to more resemble an o and to slide seamlessly into the font +**\ [EinMByte]** At least it might add additional confusion, which is bad +**\** EinMByte: exactly. the question is how it could be confirmed it's not an A +**\ [anonimal]** Ok, all in favor of exo2 +**\** i'm however not qualified to do that +**\ [anonimal]** Any votes for exo2/open sans? +**\ [i2p-relay] {-ArticMine}** Yes +**\ [EinMByte]** exo2 is fine for me, but I also agree that the "Garlic Routing Project" text should be optional +**\ [i2p-relay] {-ArticMine}** exo2 is fine +**\ [EinMByte]** (So on the website, for example, we should have the text. But potentially not everywhere) +**\ [EinMByte]** Any objections against exo2? +**\ [anonimal]** I count 2 votes for exo2/open sans. +**\ [anonimal]** Any votes for Lato? +**\** i vote lato +**\ [EinMByte]** Any votes for work sans? +**\** i also like lato +**\** lato from my side +**\ [EinMByte]** Ok, let's eliminate work sans. +**\ [anonimal]** 3 votes for Lato. +**\ [anonimal]** Any votes for Work Sans? +**\ [anonimal]** 0 votes for Work Sans +**\ [anonimal]** I haven't voted +**\ * anonimal** looks +**\** i vote for Lato +**\ [EinMByte]** Are we going to decide on the logo today or not? If so, we should hurry (if we want to discuss API still) +**\ [anonimal]** pero: why does a6 look so fat? +**\** shouldn't be that difficult to throw up exo2 versions of lato variants in the future +**\** in case that's still up for debatable +**\ [anonimal]** EinMByte that's up to moneromooo because I really don't think anyone else there is interested in API chat (afaict) +**\** because it is fat :P +**\** yb +**\ [i2p-relay] {-ArticMine}** I have to leave +**\ im interested in api cha +**\** maybe we should have a #monero-design? :) +**\ [anonimal]** EinMByte if we don't decide soon, website doesn't get done +**\** i went with a heavier weight for that variant arbitrarily +**\ [i2p-relay] {-moneromooo}** I have no particular wish about that, don't mind me. +**\** let's move ahead +**\** the logo already took up the entire last meeting +**\ [anonimal]** 3 minutes +**\ [anonimal]** Let me vote please! +**\ [EinMByte]** We should at least plan when to discuss the API, so let's decide quickly on the logo :) +**\** LATO +**\ [anonimal]** pero: why should I choose exo2 +**\** its advantage seems to be technological look +**\ [EinMByte]** anonimal: Please decide, we're moving too slowly here +**\** a secondary adv is that we can pair with open sans which is extremely versatile +**\ [anonimal]** EinMByte, we have 30 minutes, please be patient. +**\** can be used at extremely small sizes for things like massive tables of data +**\** whereas using open sans to complement a lato branding scheme wouldn't make much sense +**\ [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? +**\** i think that makes the most sense as a next step +**\ [anonimal]** We can probably come to a final conclusion post-meeting or sometime this week. +**\ [anonimal]** Ok, thanks pero. +**\ [anonimal]** Moving on, +**\ [anonimal]** 5. #46 +**\ [anonimal]** fluffypony: ^ +**\ [EinMByte]** fluffypony... +**\** did you skip over the 'garlic router' discussion? +**\** ok - got a first draft to push up, but need to finish fixing the forum first +**\ [anonimal]** pero: just go with it for now but also do without subtext too please +**\ [EinMByte]** ETA? +**\** whats wrong with the forum? +**\** ok +**\** EinMByte: no clue +**\** patthehuman: PHP7 broke a bunch of stuff +**\ [anonimal]** patthehuman: fluffypony is fixing it +**\ ok +**\** some of it was non-obvious until we had a new dep and composer wrecked everything +**\** ill be around if you need help +**\ [EinMByte]** Let's not discuss the monero forum here +**\** php7 wrecked a lot of my shit at work so ive been down this path +**\** sure +**\ [anonimal]** fluffypony: should EinMByte and I not ask for ETA for website? +**\** anonimal: I'll push my changes once the forum is back up, since all static objects are served off that repo anyway +**\ [anonimal]** Worst case scenario, we release with just a repo and wiki. +**\ [anonimal]** Ok, moving on +**\ [anonimal]** 6. #337 https://geti2p.net/en/docs/naming +**\ [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) +**\ [anonimal]** There are also various other issues, let me pull up the ticket +**\ [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. +**\ [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." +**\ [EinMByte]** Easiest would be to add an additional file that's user-configurable, but maybe it's nicer to just update incrementally +**\ [anonimal]** hosts.txt is updated every 12 hours. I think we should have user-configurable too. +**\ [EinMByte]** (although that prings additonal problems) +**\ [EinMByte]** \*brings additional +**\ [Zenified]** >prings? +**\ [EinMByte]** So lets have "hosts.txt" and several other files for the different subscriptions? +**\ [anonimal]** Yes, that was the idea. I guess the question was how many: +**\ [EinMByte]** one for each subscription +**\ [EinMByte]** If there's conflicts, they would ideally be reported to the user +**\ [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 +**\ [anonimal]** \*a user_hosts.txt +**\ [anonimal]** And duplicates would be wasteful +**\ [anonimal]** (this whole I2P naming scheme is annoying) +**\ [EinMByte]** We should rename the files locally +**\ [anonimal]** You mean expect the user to call it whatever they want? +**\ [EinMByte]** The only hosts.txt file would be the one that the user can change? +**\ [anonimal]** No, hosts.txt would always be static and provided upstream, always overridden every 12 hours +**\ [EinMByte]** No, when downloading a subscription, put it in a dedicated file? +**\ [anonimal]** I'm not sure what you're getting at +**\ [EinMByte]** Ok, so you want "user_hosts.txt" to be a wile with custom hosts? +**\ [EinMByte]** \*file +**\ [EinMByte]** That would also work, sure. +**\ [anonimal]** We only need 2: one that's always clobbered every 12 hours, and one that's never clobbered +**\ [anonimal]** The one that's never clobbered needs a name. It's "custom" and "private" though. +**\ [anonimal]** Also, should every address added with i2paddresshelper \*also\* be inserted into said custom file. +**\ [EinMByte]** Yes, but we want multiple subscriptions right? +**\ [anonimal]** I don't even think java i2p does that, but I think it should be done. +**\ [EinMByte]** But not all publishers provide the same set of hosts +**\ [EinMByte]** Hence, the need for several hosts.txt files that care clobbered every 12 hours +**\ [EinMByte]** \*are +**\ [anonimal]** Ok, we'll just have to name subscriptions by uri.host() +**\ [EinMByte]** Yes, I guess so +**\ [anonimal]** and make a private_hosts.txt that is *never* clobbered +**\ [anonimal]** That actually makes the most sense now, imho. +**\ [EinMByte]** Yes, that or have an actual database of hosts rather than a bunch of files +**\ [anonimal]** We can deal with duplicates and effiency later unless it becomes a massively huge issue. +**\ [anonimal]** Yeah, a *real* Db +**\ [anonimal]** While we're at it we can consider that for ./NetDb +**\ [EinMByte]** But if we get a real database, it should also be used for profiles etc +**\ [anonimal]** Didn't i2pcpp do something like that? +**\ [EinMByte]** Yes, it used sqlite +**\ [anonimal]** Why was that not continued/exploited? +**\ [anonimal]** Was it not 'efficient' enough for the magician? +**\ [EinMByte]** For the same reason that i2pcpp was not continued +**\** you can always use LMDB +**\ [EinMByte]** i2pd isn't based on i2pcpp at all +**\ [anonimal]** I know, but he obviously looked at it. +**\ [anonimal]** I don't like how one can't use network filesystems with LMDB +**\ [EinMByte]** Yes, but decided not add the dependency or so +**\ [EinMByte]** So let's create an issue for using an actual database? +**\ [anonimal]** EinMByte then I think we should research sqlite or LMDB or some other option for a longterm database solution. Sound reasonable? +**\ [EinMByte]** Yes +**\ [anonimal]** Ok, anything else on addressbook? +**\** I think it's all been addressed +**\ [EinMByte]** Can you create the issue? If so, let's move on to 7 +**\ [anonimal]** Done, #385 +**\ [anonimal]** 7. API discussion with #monero-dev (#350 #351) +**\ [EinMByte]** Monero developers here? +**\ [i2p-relay] {-moneromooo}** Yes +**\ [EinMByte]** What I mainly want is a clear set of requirements for the API +**\ [i2p-relay] {-moneromooo}** Oh I see. Oh. Hmm. +**\** yes +**\ [i2p-relay] {-moneromooo}** Well, I'm not very much acquainted with the way CN P2P works in the first place... +**\ [EinMByte]** e.g. do you want to use streaming, I2NP directly, datagrams...? +**\ [i2p-relay] {-moneromooo}** It's all TCP, with a simple HTTP server at hte moment. +**\ [Zenified]** LMDB is the the real deal +**\ [i2p-relay] {-moneromooo}** Doesn't mean it has to stay that way though. +**\ [EinMByte]** So you need connections? Probably streaming then +**\ [anonimal]** Question: how is monero-core currently talking with monerod? +**\ [EinMByte]** The main question to ask is whether you need 1) reliability 2) connections +**\ [i2p-relay] {-moneromooo}** fluffypony: did you intend to replace the P2P stuff with 0MQ ? +**\ [anonimal]** EinMByte I thought we discussed not doing network-based API +**\ [i2p-relay] {-moneromooo}** anonimal: JSON RPC AFAIK. +**\** anonimal: JSON RPC API, but we're replacing that with 0MQ +**\** but Kovri will serve the p2p layer +**\** not the RPC layer +**\** moneromooo: yes with ZMTP +**\** http://zmtp.org +**\** maybe we bundle the ZMTP change and Kovri integration together ? +**\ [EinMByte]** anonimal: No, but we need to know what aspects of the API are most important +**\ [EinMByte]** e.g. do we need to focus on making I2NP accessible, or on making streaming accessible +**\ [EinMByte]** Or does monero want to be able to create tunnels, etc. +**\ [anonimal]** I think monero wants something as simple as a SOCKS proxy +**\ [i2p-relay] {-moneromooo}** We need to be able to find peers without knowing their address in advance. +**\ [anonimal]** If connection isn't made, tough luck and try again later +**\ [anonimal]** Oh, nevermind then +**\ [i2p-relay] {-moneromooo}** At the moment, this is done by bootstrapping from a seed server. +**\** moneromooo: DNS seeds +**\ [EinMByte]** So 0MQ would be TCP-based, so would use streaming +**\** yeah so we can do the same +**\ [i2p-relay] {-moneromooo}** That... might be DNS ? I'm not sure. +**\** we get seed nodes from DNS seeds with hardcoded fallbacks +**\** and then we connect to their .i2p address on the appropriate port +**\ [i2p-relay] {-moneromooo}** And all the DNSSEC or DNScrypt that fluffypony knows about. +**\** and request peers +**\** and we get a list of .i2p addresses and ports +**\ [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? +**\ [anonimal]** Has monero-side drawn up any diagrams for these ideas? +**\** anonimal: that's how it currently works, not ideas +**\ [i2p-relay] {-moneromooo}** Is there a concept of "multicast", where we could send a query to "whomever it may concern" ? +**\ [anonimal]** fluffypony: you currently get a list of .i2p address and ports? +**\** EinMByte: we can do either +**\ [EinMByte]** moneromooo: No, don't think so +**\** anonimal: we currently get ipv4 addresses, but we'd perform exactly the same function to get i2p-based peers +**\ [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 +**\ [i2p-relay] {-moneromooo}** The intent, in this case, would be to request replies from peers that run monero. +**\ [i2p-relay] {-moneromooo}** (without having to rely on centralized seeds) +**\ [EinMByte]** So for DNS, you could use repliable datagrams or streaming. +**\ [anonimal]** EinMByte moneromooo: multicast is mentioned in future work https://geti2p.net/en/docs/how/garlic-routing +**\** DNS seed nodes work, I really don't think we need to replace that +**\** but what we would do on first sync is get both ipv4 *and* i2p peers +**\ [EinMByte]** anonimal: Yes, but there's no decent proposal right now. I also need to check out the LS2 proposal, it somewhat relates +**\ [EinMByte]** fluffypony: Ok, assuming you can store I2P addresses in DNS records +**\ [anonimal]** moneromooo: proposals also sit there for years so I wouldn't expect anything to happen anytime soon +**\** after that a node maintains its own white / black / gray lists, and gets a peerlist every time it connects to a new peer +**\** EinMByte: TXT records :) +**\ [EinMByte]** fluffypony: Ok. +**\ [i2p-relay] {-moneromooo}** It's something that seems fairly self contained anyway, so could be changed at a later date. +**\ [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 +**\ [i2p-relay] {-moneromooo}** I don't know the difference between these options. +**\ [anonimal]** I don't think they need to care about creating tunnels +**\ [EinMByte]** In any case kovri wants to provide the API to do 1 +**\** yes - and I'd probably lean towards the C++ API +**\ [anonimal]** They need to know if they can get through or not, that's a given though. +**\ [EinMByte]** So it looks like monero would be using esentially use the streaming API? +**\ [i2p-relay] {-moneromooo}** I'd imagine something that looks like a socket API, just using I2P addresses instead of IP:port :) +**\ [EinMByte]** s/use// +**\ [i2p-relay] {-moneromooo}** By streaming, do you mean TCP ? +**\ [EinMByte]** But maybe for DNS you'd also want repliable datagrams +**\ [anonimal]** I can't answer for them until one of them sits down and reads the spec +**\ [EinMByte]** moneromooo: streaming is something that looks a lot like TCP but over I2P +**\ [i2p-relay] {-moneromooo}** Then that's what we'd use in a straight port, modulo the seed stuff. +**\ [EinMByte]** Most applications use streaming one way or another +**\ [EinMByte]** I don't know your architecture, but it may be simpler to create a tunnel if you want to route everything to I2P +**\ [EinMByte]** \*through +**\ [anonimal]** fluffypony moneromooo: what were the arugments against using SOCKS proxy? +**\ [i2p-relay] {-moneromooo}** By creating a tunnel, do you mean selecting the hoops directly ? +**\** no arguments - we have no idea what you'd recommend :) +**\ [anonimal]** EinMByte: KISS +**\ [EinMByte]** moneromooo: using tunnel in the client-like context here, like a local SOCKS proxy which delivers to a dedicated I2P endpoint +**\ [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. +**\ [EinMByte]** SOCKS seems overly complicaed +**\ [EinMByte]** \*complicated +**\ [anonimal]** IMHO, we should be more on a level playing field at least term wise by now. +**\** anonimal: we'll implement whatever you guys recommend +**\ [EinMByte]** If you need many connections, you can't use the "create a local SOCKS proxy" or so +**\ [anonimal]** EinMByte: how so? In terms of providing useful feedback and control, yes. +**\ [i2p-relay] {-moneromooo}** We need several, yes. They're fairly long term. Some will go down, and will be replaced. +**\ [EinMByte]** Then it would be a lot easier to create tunnels (which use e.g. the streaming protocol) using the C++ API +**\ [i2p-relay] {-moneromooo}** Both directions, btw. No client/server. +**\ [EinMByte]** Streaming is both ways, sure +**\ [EinMByte]** datagrams can also be (if repliable) +**\ [anonimal]** Ok, so easiest for us is C++ API but is ZMTP worth the extra work? +**\ [EinMByte]** anonimal: I don't think ZMTP matters to us. +**\ [i2p-relay] {-moneromooo}** I'd imagine ZMTP is a layer above, and kovri would be oblivious to it. +**\ [anonimal]** Good. +**\ [anonimal]** So streaming or datagrams or both? +**\ [EinMByte]** Question is whether using ZMTP would actually be useful when used above I2P, but I'll leave that to monero devs +**\ [i2p-relay] {-moneromooo}** Both, please :) +**\ [EinMByte]** But let's focus on streaming +**\ [EinMByte]** (since most I2P applications currently use streaming) +**\ [i2p-relay] {-moneromooo}** But streaming first, yes. We can hardcode peer ids to start with. +**\** I guess parts of ZMTP would be useless (eg. end-to-end encryption) +**\ [anonimal]** Ok, C++ API for streaming. That's entirely on us then, for starters. +**\ [anonimal]** Is this written in stone now EinMByte moneromooo fluffypony? +**\ [EinMByte]** Let's say it is and move to 8 +**\ [i2p-relay] {-moneromooo}** To the extent I know of how CN uses the network... -_- :D +**\** yes +**\ [anonimal]** Yay, big decision step done. +**\** whats set in stone? +**\ [anonimal]** Anything else on 7.? +**\ [anonimal]** I have one question: +**\** nope +**\** yardman: using the i2p C++ API for streaming +**\ [anonimal]** What homework can we all do so our next API meeting is more productive? +**\ [anonimal]** kovri c++ API +**\ [EinMByte]** Design it +**\ [i2p-relay] {-moneromooo}** Well, I have that feeling that the next month or two will be spent on rct performance from my side... +**\** anonimal: we haven't really focused on our current p2p layer because of the ZMTP plan +**\ [anonimal]** moneromooo: you mentioned I should look at networking code? +**\** thanks +**\ [i2p-relay] {-moneromooo}** I didn't, I think. I mentioned I should :D +**\ [anonimal]** Oh, lol ok +**\ [i2p-relay] {-moneromooo}** IIRC that p2p code is also kinda new and unfinished. +**\** so I don't know if we should waste much time on analysis of it, or rather look at i2p as a ZMTP transport +**\** which could be a VERY nice generalised solution +**\** that isn't Monero-specific +**\ [anonimal]** Ok, I'll add API for first thing next meeting. +**\ [anonimal]** Anything else for 7.? +**\** nope +**\ [EinMByte]** Nope, 8 please (need to leave soon) +**\ [anonimal]** 8. Code + ticket discussion / Q & A +**\ [anonimal]** We're in overtime, I have nothing to say at the moment really. +**\ [anonimal]** fluffypony I think there's an assigned ticket you can easily close +**\ [EinMByte]** Me neither, let's discuss when appropriate +**\ [anonimal]** (the codedocs one) +**\ [EinMByte]** Will see how much time I get to do v6 peer testing +**\** ok will do +**\ [anonimal]** I'll get to more assigned tickets as well. +**\ [anonimal]** Ok, moving on. +**\ [EinMByte]** Also not sure if #187 should still be open +**\ [anonimal]** 9. Any additional meeting items +**\ [anonimal]** EinMByte, ok I'll take a look after the meeting. +**\ [EinMByte]** Ok, no additional meeting items from me +**\ [anonimal]** Nor I. fluffypony? +**\ [anonimal]** moneromooo? +**\** nope +**\ [anonimal]** #monero-dev? +**\ [i2p-relay] {-moneromooo}** No +**\ [anonimal]** 10. Confirm next meeting date/time +**\ [anonimal]** Next week or two weeks? +**\ [EinMByte]** 2 +**\ [EinMByte]** (if we want the API on the list of topics) +**\** 2 weeks +**\** Oct 16 +**\ [anonimal]** Same for #monero-dev? +**\ [anonimal]** I'd like to coincide +**\ [anonimal]** fluffypony: ^ +**\** yes +**\ [anonimal]** Ok, 2 weeks works for me. +**\ [anonimal]** THANKS EVERYONE! +**\** shutting meeting bot down \ No newline at end of file diff --git a/_posts/2016-10-02-overview-and-logs-for-the-dev-meeting-held-on-2016-10-02.md b/_posts/2016-10-02-overview-and-logs-for-the-dev-meeting-held-on-2016-10-02.md new file mode 100644 index 00000000..f53364cd --- /dev/null +++ b/_posts/2016-10-02-overview-and-logs-for-the-dev-meeting-held-on-2016-10-02.md @@ -0,0 +1,229 @@ +--- +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 + +**\** Hi all +**\** starting meeting bot +**\** I'm none of them. +**\** I am here +**\** moneromooo: I know you're here :) +**\** ok meeting bot is up +**\** watching +**\** so +**\ [anonimal]** #kovri-dev too? +**\** kovri-dev is roped in too +**\** k +**\ [i2p-relay] {-moneromooo}** o +**\** this is our first post-0.10.0 meeting +**\** the 0.10.0 release went fairly smoothly +**\** apart from the boost oddities +**\** on the Boost serialisation stuff +**\** 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 +**\** since I can secure local machines far more easily than Internet-facing machines at a DC +**\** in the interim, if anyone is struggling with it the easiest thing for them to do is recover their wallet from the seed / keys +**\** And keep the old cache if they have tx keys they want to keep. +**\** ^^ +**\** I'd also like to welcome all the new contributors +**\** even if it's just correcting a spelling error, all contributions are valuable +**\** and very much appreciated +**\** one thing I would like to encourage with the new contributors is to submit your GPG key via PR +**\** and side-channel it to myself or moneromooo or someone so we can independently verify the correct key goes in +**\** they live in utils/gpg_keys/ +**\ [anonimal]** and if moneromooo says "ok" in your PR, that's a GOOD thing! +**\** and then once you've done that you can GPG sign your commits with -S +**\** eg. git commit -S -am "meaningful commit message" +**\** Only if it's at the start. +**\** Is there anything that needs to be made for iOS +**\** lol anonimal +**\** patthehuman: it's an open-source project, so if you want to build something for iOS then please do +**\** no need to ask permission or anyway +**\** 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) +**\** sure, i guess i'm wondering more along the lines of what needs to be built +**\** can you outline how that would work? +**\** and then an old iPhone or iPod Touch would work as a full node on wifi +**\** well we have native ARMv8 builds +**\** and interacting with the daemon over RPC isn't hard +**\** Why not just go with Cydia on jailbroken iOS? +**\** but I have no idea if an iOS app would let you arbitrarily launch a process +**\** ArticMine: too few jailbreak their devices, no? +**\** ArticMine: absolutely - would be nice to be able to launch it as an app tho +**\** generally apps get removed from the app store if they are simple "remotes" +**\** fluffypony: iOS does not allow you to spawn processes... no NSTask etc equivalent +**\** ah +**\** ArcticMine: I think Cydia is a good plan B. Not many non tech people are going to have jail broken phones +**\** right, they have a list of closed API's that will get you banned +**\** does Objective-C let you also run native C / C++ code? +**\** fluffypony: yep as long as you can compile for an ARM target +**\** compile it* +**\** ArticMine : A good idea and a lot of IOS devices have Jailbreak , Remember that XMR are used in the DNM as well +**\** yeah we have ARMv8 support across the board +**\** Objective-C is a strict superset of C, so any C is good, and C++ can be compiled too +**\** Net applications Android 69.18% IOS 25.02% market share +**\** anyway we're getting side-tracked a little - patthehuman feel free to play around with it, if you feel like it +**\** sure +**\** so +**\** ringCT is live in testnet, and more testing would be appreciated +**\** mWo12's testnet block explorer is helpful +**\** but performance testing is also immensely useful +**\** see what cracks under pressure +**\** we have a short window until the January hard fork, so we need to hammer testnet as much as possible +**\** is there a testnet faucet somewhere? or is mining or irc begging for testnet xmr recommended? +**\** just ask me and I'll send testnet XMR your way +**\** are there any automation processes that can hammer on testnet? +**\** i have access to a lot of r510 servers that i could potentially mirror some script to hammer on it +**\** patthehuman: you could pretty much just write a bash script to send to yourself once a second +**\** and cycle it that way +**\** cool +**\** and then see how your testnet node(s) handle catch ups, and if they keep up with testnet when blocks are bigger +**\** we also have our new buildbots ticking along nicely +**\** so we'll be killing off Travis at some point in the coming weeks +**\** build bot output has been relegated to #monero-bots +**\** and that channel is relayed to irc2p +**\ [anonimal]** Thanks pigeons +**\ [anonimal]** monero-build.i2p is also online +**\** yeah pigeons has done great work +**\** at the moment we're building for a ton of platforms +**\** including macOS 10.9, 10.10, 10.11 +**\** so we should pick up PRs that break compilation more rapidly +**\** how we handle testing is a bit harder +**\** especially since some of the tests take several hours to run +**\** my current leaning is towards nightly builds + tests +**\** (of master) +**\** that way we'll catch tests that are broken by any merged PRs +**\** Daily core_tests would be useful. +**\** performance_tests would also be useful +**\** that way we can track anything that has a huge impact on performance +**\** As long as the outcome can be seen without too many hoops (ie, javacrsipt) +**\** moneromooo: we'll probably just grab the output, parse it, and shove it in a database +**\** then we can create a profiler for the site without too many issues +**\** on the PR side +**\** has anyone looked at 1082? +**\** no my apologies for being new but can you elaborate on what 1082 is +**\** or actually moneromooo: can you give everyone a brief overview of what 1082 does +**\** oh sorry patthehuman - PR = pull request +**\** so PR 1082 = https://github.com/monero-project/monero/pull/1082 +**\** yeah im familiar with PR's (worst part of my work day lol) +**\** Ah, as the comment says, really. +**\** It just tries to avoid the case where someone sends money just after receiving it. +**\** That's a common enough case. +**\** "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." +**\** where did the 25% come from? 25% seems somewhat arbitrary. did MRL have input on this number? +**\** They're aribtrary. +**\** 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 +**\** Will look at it +**\** 25% would only be a single output at minimum mixin +**\** ok thanks +**\** It's actually 25%, except if that gives 0, in which case it uses 1. +**\** moneromooo: and it's 25% including the "real" output, right? +**\** Yes. +**\** See line 2744 in wallet2.cpp +**\** kk +**\** as to the other open PRs +**\** most of them are not merged yet due to their being unreviewed +**\** 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 +**\** bear in mind that a review is *not* in-depth line-by-line analysis +**\** pr is just a quick overview +**\** I'd hope the review does look at all lines. +**\** yup +**\** it's a sanity check, and a check for obvious screw-ups, and a check for snuck-in backdoors +**\** moneromooo: the key there was in-depth, not line-by-line ;) +**\** OK, that's fine. +**\** medusa_: are you around? +**\** ok in the absence of medusa_ being around, dEBRUYNE have you been following Ilya's progress on medusa_'s issues? +**\** Yeah, he has fixed all issues opened by medusa_ as far as I know +**\** ok great +**\** yes im here +**\** Except -> https://github.com/monero-project/monero-core/issues/29 +**\** but that's more of a feature, which should be implemented later +**\** oh cool - medusa_ how are you finding it now that most of the issues have been fixed? +**\** could* +**\** MK_ + Others who are wondering, the monero-core project that is being discussed now is the GUI +**\** i think we need more feedback regarding the performance difference between gui wallet creation time and CLI wallet creation time +**\** and i dont know of any major bugs that would be dangerous +**\** medusa_: there's a PR that's supposed to fix that +**\** I haven't merged it yet, but it's gone through review +**\** Ilya merged jacquee's PR as well +**\** he noticed a significant improvement +**\** so my opinion is merge all to monero-core project master, test there again and if its good we build the bins +**\** ^ +1 +**\** Beta binaries will also bring more testers, who possibly could notice something we might have overlooked +**\** ok +**\** Im down to test once the Betas are out +**\** we'll need a point release of 0.10 to go with it +**\** so we should at least get through the current group of pending PRs before we do that +**\** but we must communicate its for testing, since the seed is nowhere displayed after creation we dont want people to lose money +**\** It creates a keys file, right ? +**\** medusa_: well that's a pretty big issue :-P +**\** yes +**\** ah ok +**\** so monero-wallet-cli could be shipped with it for recovery +**\** Good idea +**\** Well, you do need the daemon anyway, don't you. +**\** yes +**\** \ so monero-wallet-cli could be shipped with it for recovery <= It's able to recover seeds +**\** It's just that only in the wizard the seed is shown once +**\** oh wait, you mean restore with the .keys file? +**\** yes I meant recovery as in "recover my seed from the .keys file" +**\** Recovery from seed is the issue with the GUI? +**\** ah gotcha +**\** No ArticMine, there isn't a window yet to see your seed +**\** after the initial wizard +**\** ArticMine: no - it just doesn't display the seed again after the wizard +**\** and given how many MyMonero support emails I get where people didn't write down their seed... +**\** Should be fairly trivial to add though +**\** ok so that's about it from my side - tewinget isn't around to give us a 0MQ update +**\** hyc I don't think has started tinkering with the walletDB stuff +**\** 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 +**\** 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 +**\** Like I said, should be fairly trivial to add +**\** dEBRUYNE: good idea - open an issue for it and let Ilya do it asap :) +**\** ok so we have 7 minutes before the Kovri meeting, any other things to discuss? +**\** fluffypony: will do +**\** NoodleDoodle isn't here right? +**\** Who wants to volunteer to review some patches from time to time ? :) +**\** moneromooo: Similiarly, would you be able to glance over / review the trezor XMR code? +**\** Where is it ? +**\** on NoodleDoodle's computer +**\** https://github.com/NoodleDoodleNoodleDoodleNoodleDoodleNoo +**\** ^ moneromooo +**\** he has some commits in his monero repository and in trezor-xmr +**\** :-P +**\ {-anonimal}** moneromooo: I review many of them but I don't spend enough time with the codebase to ack/nack +**\** anonimal, thanks :) +**\** dEBRUYNE: Do you know which one of the three repos is the right one ? +**\** xmr, common, mcu. xmr seems likely to be one at least. +**\** oh trezor-xmr +**\** and monero +**\** So his commits here -> https://github.com/NoodleDoodleNoodleDoodleNoodleDoodleNoo/monero/commits/master?author=NoodleDoodleNoodleDoodleNoodleDoodleNoo +**\** OK, I'll keep that in mind then. +**\** & here -> https://github.com/NoodleDoodleNoodleDoodleNoodleDoodleNoo/trezor-xmr +**\** i can not review the code, but i can test specific pull requests if you guys explain me what you changed +**\** trezor-mcu / trezor-common has no commits from NoodleDoodle moneromooo +**\** medusa_: 1082 and 1121 could do with some testing if you feel like it. +**\** And 1140 :) +**\** 1082 changes the way fake outs are selected +**\** wow in this pace i see GUI by tonight lol +**\** 1121 replaces the sweep_unmixable code to be more stable and, well, better +**\** 1141 adds cold wallet signing +**\** oh i can test 1141 +**\** i still have the setip from the --offline thing +**\** 1140, sorry. Off by one... +**\** oh no off by one bug! +**\** will have a look, thanks +**\** Mac, Linux, and Plan9. +**\** android please +**\** lol +**\** hokay +**\** that's the end of that diff --git a/_posts/2016-10-16-logs-for-the-Kovri-dev-meeting-held-on-2016-10-16.md b/_posts/2016-10-16-logs-for-the-Kovri-dev-meeting-held-on-2016-10-16.md new file mode 100644 index 00000000..76e4b319 --- /dev/null +++ b/_posts/2016-10-16-logs-for-the-Kovri-dev-meeting-held-on-2016-10-16.md @@ -0,0 +1,302 @@ +--- +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 + +**\ {-anonimal}** 17:00! +**\** Go go go! +**\** Let's start +**\ {-anonimal}** I can't copy/paste as quickly as usual so here's in bits: +**\ {-anonimal}** 1. Greetings +**\ {-anonimal}** 2. Brief review of what's been completed since the previous meeting +**\ {-anonimal}** 3. libclient API discussion (#351) +**\ {-anonimal}** 4. logo +**\ {-anonimal}** 5. Code + ticket discussion / Q & A +**\ {-anonimal}** 6. Any additional meeting items +**\ {-anonimal}** 7. Confirm next meeting date/time +**\ {-EinMByte}** Hi +**\ {-anonimal}** Hello +**\ {-anonimal}** 2. Brief review of what's been completed since the previous meeting +**\ {-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: +**\ {-anonimal}** - Tons of work on #256 (see my monero-site fork for details) +**\ {-anonimal}** - Minor AES-NI impl fixes/refactor +**\ {-anonimal}** - Client fix to allow saving privates when behind a transproxy +**\ {-anonimal}** - Bump dependency versions in submodules +**\ {-anonimal}** (the issue is probably *when client doesn't have everything it wants when router expects inbound peers*) +**\ {-anonimal}** - REMOVED TRAVIS-CI! YAY! We now have all-platform build support thanks to pigeons +**\ {-anonimal}** - Minor things and some doc fixes +**\ {-anonimal}** - New contributor dadude (welcome, dadude) +**\ {-anonimal}** One more note: +**\ {-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 +**\ {-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/ +**\ {-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. +**\ {-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. +**\** reading... +**\ {-anonimal}** Thanks dadude, its really the community to thank; such a great crowd. +**\ {-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? +**\ {-EinMByte}** That gives me a good excuse to do little development :) +**\ {-anonimal}** s/saving privates/saving private keys/ \<-- lol, oops +**\ {-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). +**\ {-anonimal}** dadude: all humans on the planet if possible (preferably with internet availability) +**\<_Slack> {dadude}** got it :slightly_smiling_face: +**\ {-anonimal}** Anything else on 2. or dare we dive into API chat? +**\** whats the expected date for release of i2p? +**\ {-anonimal}** sdgsdug9sd: checkout our roadmap +**\** link? +**\ {-anonimal}** github.com/monero-project/kovri/wiki \<--something like that, whatever wiki url is +**\ {-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 +**\** https://github.com/monero-project/kovri/wiki/Roadmap +**\ {-anonimal}** (like I said, barely any codebase work in 2 weeks) +**\ {-anonimal}** Ok, let's move to 3. and we can add other items/open questions to 6. +**\ {-anonimal}** 3. libclient API discussion (#351) +**\ {-anonimal}** moneromooo: did you get a chance to research my question(s)? +**\* moneromooo** suddenly appears very busy with somehting else +**\** ... no. Sorry... +**\** Many bugs... +**\** lol is this real? i hardly believe those target dates +**\** seems codebase is very weak at this time. Needs of lot of testing I think +**\ {-anonimal}** Guys, we're on API discussion now, we'll chat more later in the meeting. +**\** okay +**\ {-anonimal}** moneromooo: I'll try to rephrase then +**\** There is talk of switching the P2P API to zmtp too (I know nothing about it). +**\** Should still be mostly streaming thoug.h +**\ {-anonimal}** moneromooo: I'm betting most of my questions can be answered with more research on my end +**\** OK, I think maybe ask questions here, and I will try to answer with what I can. +**\ {-anonimal}** moneromooo: where can I get a good tl;dr of how monero handles timeouts? +**\** From what I can tell, it uses boost's asio system for this. +**\** Then you get a callback with a "cancelled" state IIRC. +**\ {-anonimal}** by 'handle' I mean internally (if something needs to get to blockchain but doesn't quickly enough) +**\** (from boost) +**\ {-anonimal}** That's too obvious moneromooo :) I mean purely internally +**\** to blockchain ? I'm talking avbout the P2P comms here. +**\** Hmm, well, I don't know more about timeouts, sorry. +**\ {-anonimal}** I'll try to rephrase again, if a node's internet connection is unreliabe, is behaviour undefined? +**\** it will not get a proper sync simple +**\** Hopefully not. Connections to a peer are dropped if "weird" stuff is received, but to what extent this is pervasive, I'm not sure. +**\** There's a query/reply system, with a handful of possible messages IIRC. +**\* pero** will brb 5min - knows he's next up on agenda +**\** This seems rather high level though. +**\ {-anonimal}** \* is thinking ahead, wants to know how a node will deal with dropped tunnels on a noticeable scale +**\ {-EinMByte}** anonimal: backup tunnels like java i2p could work +**\** Well, it should be resistant to that. If it's not, we'll have to make it. +**\** I2P can keep a tunnel for a few minutes reliably enough, right ? +**\ {-anonimal}** EinMByte: good point. +**\ {-EinMByte}** But AFAIK, we still aren't sure that monero actually needs connections? +**\ {-anonimal}** moneromooo: technically, any tunnel and blow at any moment IIRC +**\ {-anonimal}** s/and/can/ +**\** 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. +**\ {-anonimal}** If Joe shuts off his router unexpectedly, we have to wait to build a new tunnel from the pool (IIRC) +**\ {-anonimal}** How big are those chunks usually? +**\** Again, this is fine. As long as we can get a minute of comms at one point. +**\** Currently, 200 times the size of a block, which is... hmm... from 250 bytes to 60 kB. +**\** That 200 can be changed when running with kovri if needed. +**\ {-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? +**\ {-EinMByte}** with streaming it doesn't really matter +**\ {-EinMByte}** datagrams are limited in size, though +**\** but does this set a limit on the blocksize in Monero? +**\** I think that, for now, that connection will be dropped, and another attempted. But that doesn't seem too hard to change. +**\** 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. +**\ {-EinMByte}** dropping and re-attempting sounds like a good strategy +**\** The re-attempt would be to another random peer. +**\ {-anonimal}** \* eek +**\** (currently anyway) +**\ {-anonimal}** Ok, well what I'm poking at I think is for more in the future (and based on passing thoughts this week). +**\ {-anonimal}** \* was not prepared for API chat this week because of point 2. +**\ {-anonimal}** EinMByte: any other questions/thoughts? +**\ {-anonimal}** ^ moneromooo +**\** Not from me. +**\ {-EinMByte}** Just that I don't think disconnections would be that much of an issue +**\ {-anonimal}** I have been envisioning more of the API on our end though, but purely in my head. +**\ {-EinMByte}** but let's move on +**\** I have to leave now. +**\ {-anonimal}** * one more thing +**\ {-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 +**\ {-anonimal}** dadude if you have API questions as related to torrenting, now's the chance +**\<_Slack> {dadude>}** Oh, I +**\ {-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 +**\ {-anonimal}** dadude: good point, I'm sure the API will cover that +**\ {-anonimal}** dadude: we can explain how vuze does it after the meeting if you'd like +**\** 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. +**\ {-anonimal}** Ok, nothing else on 3.? +**\<_Slack> {dadude>}** thanks. unrelated: How does relay handle edits to a post here on slack +**\ {-anonimal}** dadude: let's save that until later in the meeting +**\** (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 +**\ {-anonimal}** moneromooo: is there a post or link re: that proposal? +**\** It was mentioned in one of the MRL papers IIRC. No details, but I can find you the one. +**\ {-anonimal}** Thank you moneromooo. +**\ {-anonimal}** * would navigate but you know MRL better than I +**\ {-anonimal}** Ok, moving on +**\ {-anonimal}** 4. logo +**\ {-anonimal}** pero: all you if you're here! +**\** yes hi +**\** ok so we're down to 2 fonts +**\ {-anonimal}** Let's decide now then +**\** each came with 6-8 weights and i've cut that down to 2 for exo2 and 3 for lato +**\** https://a.pomf.cat/gyzaxi.png +**\** 1b and 1c are the same weight with different kerning +**\** the 'garlic-integrated' variants are interesting but will require rework of the garlic +**\** for record keeping purposes this is v8 +**\ {-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 +**\ {-anonimal}** Any objections? +**\** My subjective opinion is that the "garlic as dot in the i" is too small to not feel weird. +**\ {-anonimal}** \* agreeing with moneromooo, it looks like a flame +**\** yes i agree - is viable but needs rework +**\** instead put garlic for o kovri +**\** I thought the flame thing was intended :P +**\ {-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? +**\** okay +**\ {-anonimal}** dadude: 1. +**\** imans - the problem with that is that the garlic wasn't intended for such usage +**\** and makes the text imbalanced +**\ {-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) +**\** fine. 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 +**\** and the small lines at the bottom and top of garlic aren't optimal +**\** I see it there +**\** My choice is the 6th one +**\** for font +**\** I'd pick one of the ones on the right, just because they're fatter, and so easier to read. +**\** and bold +**\ {-EinMByte}** I'd go for lato +**\ {-EinMByte}** (b1?) +**\** yea i'm in the lato camp as well +**\ {-anonimal}** pero: I like lato, X coord 1, Y coord b +**\** seems everyone picks up the second +**\ {-anonimal}** Ok, 3 votes for b1, 1 vore for 'the 6th one' (I have no idea what that is) +**\<_Slack> {dadude}** yep b1 +**\** i'm either b2 or b3 +**\** 6th one was b3 +**\ {-anonimal}** Alright, 4 votes b1, 2 for b3, 1 for b2 +**\** 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 :) +**\ {-anonimal}** b1 one is the winner, any objections? +**\ {-anonimal}** lol +**\** well that's for b3 now ;p +**\** 3 +**\** Ignore me :) +**\ {-anonimal}** \* looks different depending on mood +**\ {-EinMByte}** 3/3, let's toss a coin +**\ {-anonimal}** pero: also, let's try steching that subtext all the way to the left +**\ {-anonimal}** to the end of the garlic +**\ {-anonimal}** Does that effect your decision? +**\** yea that variant was included before - it was just a time saving consideration to not include it +**\ {-anonimal}** \* wonders how to coin toss over IRC +**\** 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. +**\** as a rule of thumb you want heavier type for the logo +**\** moneromooo that looked even weirder :) +**\** So there's no hole, but it doesn't also feel like the subtext is running away from the main text. +**\ {-anonimal}** b2 b3 looks overpowering compared to that logo IMHO +**\** Hmm, ok. +**\ {-anonimal}** We have 7 minutes to decide, I'd like to save room for other topics. +**\ {-anonimal}** 6 minutes now +**\** I stick with the last one on the right +**\** i think you should be focusing on the largest variant +**\** and the variant with only the garlic on the left +**\** when deciding +**\** 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) +**\** don't worry about the others +**\** but i might regret having opened my mouth :P +**\** endogenic - this is how the 'design process' works +**\ {-anonimal}** pero: 5 minutes, why? +**\** They all look so similar anyway. +**\** this is 'client feedback' +**\ {-anonimal}** I like the balance of b1 +**\** you don't just present a finished logo to a client and say 'here, take this' +**\ {-anonimal}** b2 b3 are too strong +**\** okay +**\ {-EinMByte}** I though we were going to toin coss +**\** http://www.logodesignlove.com/next-logo-paul-rand +**\ {-EinMByte}** \*thought +**\** I vote for toin coss. +**\ {-anonimal}** Who has the coin? +**\** but i'm not disagreeing that market research is important +**\** talking to users is basically #1 next to building +**\ {-anonimal}** And is that coin CSPRNG, lol +**\ {-EinMByte}** Let's do this right and use a bit commitment scheme +**\ {-anonimal}** 3 minutes +**\ {-EinMByte}** (unfortunately we don't have secure timestamping available for the commitment scheme) +**\** yea ok pay someone 100k and after 6 months they'll narrow it down to 1 almost scientifically +**\ {-anonimal}** 2 minutes +**\** OK, so, if the number of letters in "anonimal" is even, b1, if it's odd then b3. OK ? +**\** i'm in the not b1 camp +**\ {-anonimal}** \* bribes moneromooo behind closed doors +**\** mostly because it looks close to just regular text +**\ {-anonimal}** I think b2 b3 are ugly, I don't want to see this everytime I look at the readme +**\ {-anonimal}** \* don't forget the devs +**\** A graphical README ? +**\ {-anonimal}** 1 minute to flip coin +**\** just bigger and with tighter kerning +**\ {-anonimal}** \* will pull executive order if someone can't flip a coin +**\ {-iDunk}** we can pick anything as long as it's b1 :) +**\** SOLD! +**\ {-anonimal}** pero: will b2 look better when subtext is streched across to the left +**\ {-anonimal}** \* trusted pero so far, no reason to stop trusting +**\ {-iDunk}** btw, i'm also for b3 +**\** well i'd show you but i'm in wayland atm with no screenshot support +**\ {-anonimal}** I'd like EinMByte to be the tie-breaker if he's up for it +**\ {-EinMByte}** With iDunk's vote, let's say the choice is b3 +**\** but no it doesn't look any better than it does now +**\ {-anonimal}** b3 it is! +**\ {-anonimal}** Congrats to b3 +**\ {-iDunk}** \* hides from anonimal +**\ {-anonimal}** \* says eww but oh well +**\ {-anonimal}** lol iDunk +**\** eww well +**\ {-anonimal}** \* looking forward to a kovri PR from iDunk some day +**\ {-iDunk}** :D +**\ {-anonimal}** Moving on, +**\** congrats +**\ {-anonimal}** 5. Code + ticket discussion / Q & A +**\** ask +**\ {-anonimal}** 8 minutes left, I want to actually move to 6. +**\ {-anonimal}** Any objections? +**\** no +**\ {-EinMByte}** No objections +**\ {-anonimal}** 6. Any additional meeting items +**\ {-anonimal}** {-imans} seems codebase is very weak at this time. Needs of lot of testing I think +**\ {-anonimal}** imans: have you spent time with this codebase? +**\** Just trying to install +**\** My ubuntu is hanging. I have to try another time. +**\ {-EinMByte}** \* afk +**\ {-anonimal}** Ok, so you haven't then. +**\ {-anonimal}** {-sdgsdug9sd} lol is this real? i hardly believe those target dates +**\** yes +**\ {-iDunk}** i installed it yesterday and it seemed to run just fine until a few hours ago +**\** That's for "kovri runs and does things", not "monero uses kovri", fwiw. +**\ {-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 +**\** What was the mistake ? +**\ {-anonimal}** sdgsdug9sd: also, see pre-alpha https://en.wikipedia.org/wiki/Pre-alpha +**\ {-anonimal}** moneromooo: calling that router a year ago "releaseable" +**\** Ah... +**\ {-iDunk}** i got disconnected from irc, couldn't connect any more, tried to exit from kovri but had to kill it +**\ {-iDunk}** restarted and it runs fine again +**\ {-anonimal}** 2 minutes. Any questions/comments/new items? +**\ {-anonimal}** imans sdgsdug9sd: ^ +**\** I will ask more in next meeting. I need to brainstorm myself +**\** anonimal: https://lab.getmonero.org/pubs/MRL-0004.pdf -- the torrent suggestion was not about initial sync actually, but about sending new txes. +**\** (I had misremembered) +**\ {-anonimal}** I'm available for tech support after the meeting +**\ {-anonimal}** 2 weeks, same time? +**\ {-anonimal}** moneromooo: ah, ok, thanks I'll give it a read +**\ {-anonimal}** imans: if you need help just ask in #kovri or #kovri-dev after the meeting +**\ {-anonimal}** 7. Confirm next meeting date/time +**\ {-anonimal}** \* moving on +**\ {-anonimal}** No objections? 2 weeks same time then. +**\** Okay anonimal. I'm in another stuff I will get in technical touch tomorrow +**\ {-iDunk}** yep +**\** so, the date and time is? +**\ {-anonimal}** Thank you everybody. Thank you dEBRUYNE for logging these meetings :) \ No newline at end of file diff --git a/_posts/2016-10-16-overview-and-logs-for-the-dev-meeting-held-on-2016-10-16.md b/_posts/2016-10-16-overview-and-logs-for-the-dev-meeting-held-on-2016-10-16.md new file mode 100644 index 00000000..be79ae82 --- /dev/null +++ b/_posts/2016-10-16-overview-and-logs-for-the-dev-meeting-held-on-2016-10-16.md @@ -0,0 +1,369 @@ +--- +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 + +**\** So, fluffypony asked if I could talk. I have no relay bot, so #kovri-dev will have to be here to listen. +**\** He suggested I talk about guidelines for submitting patches. So we'll see if everyone mostly agrees. +**\<+hyc>** cool +**\** I would like to encourage people to make clean changes, which mean: +**\** - try to keep patches self contained where appropriate +**\** - no random whitespace changes interspersed with other changes +**\** - sensible commit message (ie, no "update wallet.cpp") +**\** - 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 +**\** 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) +**\** Does anyone disagree ? +**\<_Slack> \** Nope +**\** nope +**\** nope +**\<+hyc>** no disagreement here. that's standard stuff. +**\<_Slack> \** Can I ask a little more about what you mean by ‘self contained' +**\** (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 +**\** I mean, if you've got two changes, make them two patches. I like small patches, one per "logical change". +**\<_Slack> \** Makes sense. Single-issue patches. +**\** 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 +**\** 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. +**\** especially for those PRs that can take weeks to be merged. +**\<+hyc>** sure +**\<_Slack> \** OK +**\** But yes, 1/1 in general. +**\** So, nobody seems to disagree, I'll write a little thingie about this for the repo. Thanks. +**\** So, I guess... anyone has anything to say about progress, or other dev related stuff ? :) +**\** 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. +**\** Another one, yay! :) +**\** First, read up on what lightweight may involve for monero. +**\<_Slack> \** Do we have a common wiki or other info page for devs to describe things like prefixes e.g. m_ and others +**\** Yes, this is needed +**\<_Slack> \** stuff +**\** And mature enough is pretty subjective. It can be used, for sure. +**\** lol, bazaar project usually have a lot of traffic +**\** There is none. Some people use m_ for class data members. +**\** hi all +**\<_Slack> \** What would you think about standardising that aspect of development? Variable/class/etc. nomenclature? +**\** Fireice: also, ask athan (or ethan), he's got a wallte in development which you might want to have a look at. +**\** when is meeting starting? +**\** it already started +**\<+hyc>** nanoakron: that sounds like a lot of busywork +**\** where is it? +**\** 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 :) +**\** ok will do, how do i get hold of him? +**\<_Slack> \** 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 +**\** Fireice: he's around on IRC pretty often. +**\<_Slack> \** hyc: I know :( But standards can be good too +**\** integration would need th plugin system first. That is yet to be design. +**\** designed. +**\** Fireice: His contact details are on Github too: https://github.com/athanclark +**\** There is no instruction for windows compilation in the github +**\** 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 +**\** Well, that's true. It's not API stable, that's certain. +**\** 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 +**\** The RPC is *mostly* backward compatible though. +**\** Fireice: that may be your answer then :) +**\** ty dEBRUYNE +**\<_Slack> \** @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 +**\** 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 +**\** is this the meeting? +**\** conference, dev conference +**\** A list of all available functions, beyond the source ? +**\** Fireice: the official targets linux, osx and windows +**\** Fireice: The official GUI will be available for Linux, os x, and windows +**\** That sounds like it'd go stale pretty fast. +**\** But no, there is none. +**\** perhaps the API documentation stuff should wait until the 0mq changes have been made? +**\<+hyc>** at least that, yes +**\<+hyc>** (endogenic) +**\<_Slack> \** @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. +**\** I think tewinget is doing doc as he codes. +**\** IMO third party integrations must be made simple and easy to plug with any kind of party or platform +**\** I'm not sure holding PRs for documentation is best, but I'm a bit on the fence tbh. +**\** 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> \** 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 +**\** If documentation is going to make it easier to attract API + other users than I think we need it up to date always +**\** moneromooo: documentation should be done by particularly able people IMHO +**\** so, not accepting a pull request because of poor documentation? +**\** tewinget practice of documenting while coding is a best practice +**\** and it can degrade in quality if an owner or class of developer is not designated +**\** I do agree with that. good documentation can seemlessly help new devs get involved easily +**\<_Slack> \** @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. +**\** But how would you find it in the doc, if you don't find it in the source ? +**\<_Slack> \** 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. +**\** (not saying it's a bad idea here, mind) +**\** 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> \** Would be easier to search a wiki for ‘check hard fork version’ and get a bunch of matching functions from which you can pick +**\** I do: git grep check.*hard.*fork :) +**\** But ok, fair enough. +**\** I think encouraging doc is good, ust not sure it should be enforced, at least for now. +**\<_Slack> \** 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 +**\** 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" +**\** and then if the dev doesn't comment it up, then its a judgement call over how important the feature is +**\<_Slack> \** I agree moneromooo, we can’t enforce without a good standard or common place to record the documentation +**\** nanoakron: +1 +**\<+hyc>** I'm cool with mandating Doxygen comments, moving forward. +**\** I agree than modifying a function with a doxygen doc thing should also change to doc thing to match. That's a NAK offense :) +**\** 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 +**\** So I'll add language to encourage documenting stuff. +**\<_Slack> \** 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> \** 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. +**\** I just copy/paste an existing one and adapt. +**\** Yes, I'd contribute funding to that +**\<+hyc>** but that's the sort of thing doxygen already takes care of +**\** 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> \** 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> \** Someone had to write the domesday book... +**\** But, this is going to be a big sub project if you document everything. You need lot of time and effort +**\** Unlikely. I would look suspiciously at a patch using it though :P +**\<_Slack> \** 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 +**\** If you add use cases it would be very much helpful +**\** But hey, if you want to do that, feel free. Maybe it will turn out to be a great idea in retrospect. +**\** 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> \** Do we have anywhere common where I can read about doxygen or using doxygen wrt monero now? +**\** 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. +**\** An errata list is good which will help people to trace out the errors they meet +**\<+hyc>** what errata list? the github issues list? +**\** Also, a stackexchange like documentation system which will enable users to post their comments and also raise issues they face. +**\** Yes, hyc similar to that +**\** endogenic: I think nanoakron originally wanted a map from "I want to do that" to "use this". I think. +**\<_Slack> \** @moneromooo yes +**\<_Slack> \** @imans Not entirely sure how that would be different from the existing github +**\** It will not be different. But it aids new comers and users to interact more closely +**\<_Slack> \** @imans ... +**\** imans: thought we already have a SE? +**\** I mean it for API + third party integrations +**\** 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 +**\** yes, the same I say +**\<+hyc>** otherwise we spin our wheels adding infrastructure instead of functionality +**\<_Slack> \** @hyc That’s absolutely fine…so long as those tools themselves are well documented :slightly_smiling_face: +**\** well the github wiki was requested for (i think) something related to this purpose, and it hasn't received any attention +**\<_Slack> \** afk 10 mins +**\** That sounds like a good idea. Start with a "list of useful functions someone may need" in that wiki. See how it goes. +**\** And it doesn't seem like a huge waste of time. +**\** 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 +**\** I've only seen it because I was given alink to it :D +**\** 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 +**\** so i missed the beginning. is this the general topic of "where's the docs?" +**\** 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 +**\** And that's going to totally change soon. +**\** right. +**\** Anyway, any other arguments/ideas about documentation ? +**\** well the 2 will co-exist for a while, right? +**\** Yes. +**\** I think documentation is not the main focus for this meeting? What is aimed to discuss today? +**\** Whatever development related stuff people want to talk about. +**\** the documentary i think +**\** nice +**\** hyc: have you had some more thoughts about how to make a lmdb based wallet data file ? +**\** i have nothing to say about documentation, but i want to encourage everybody to build and try the gui :-) +**\** **\** 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 +**\** soon is a little ambiguous - closer to 10min or 10weeks? +**\** pero: whenever the current topic of the meeting is finished :P +**\** Well, let's have dEBRUYNE and jaquee then. +**\** So right now +**\** Ok so, fluffypony is in the process of building beta binaries +**\** 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 +**\** However, we suspect that on "normal" systems it won't be an issue, because it's enabled by default there +**\** Mesa might help ? +**\** luigi and Articmine are going to test this tomorrow when Fluffypony returns +**\** Cool, thanks all :) +**\<+hyc>** sheesh, it's a wallet nota videogame. what acceleration does it want... +**\** lets waive a magic want that will cause all windows users worldwide to swtich to linux overnight. issue solved +**\** It's using OpenGL for its widget set apparently. +**\** It's fairly trivial to enable too on windows systems +**\** Got had by this when I tried it a few days back. +**\** 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 +**\** a clear deal breaker. it's ded +**\** 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 +**\** yes some QT widgets requires it +**\<@ArticMine>** Yes the dependency is from QT on Windows +**\** 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. +**\** 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 +**\** that said, the remaining 5% will be the loudest +**\** i bet its that truning thing when refreshing +**\** AFAICT, 2D acceleration in new GPUs is a bit shit, and using 3D with orthonormal projection is actually faster. +**\** isn't it designed to support all windows version? +**\<@ArticMine>** Windows 10 is not an issue unless some very special customization's are made +**\** but all windows versions are not designed to support it +**\** Haha, iDunk clever +**\** ;) +**\** Enable switches or options to turn on/off opengl support and its related stuff in the wallet. +**\** 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 +**\** And they can turn it on fairly easy +**\** (in the rare case it's disabled by default) +**\** Anything else about the GUI ? +**\** 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? +**\** **\** 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 +**\** yes +**\** jaquee: please do :) +**\** 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. +**\** (14 minutes till kovri meeting) +**\** okay, waiting +**\** Yes, that is a good idea +**\** i'm currently working on the wallet selector issue +**\** open wallet form file... switch wallet etc +**\** good to hear +**\** and i will also fix the default path on linux +**\** fine. +**\** hower i won't be finished today +**\** o/ +**\** so it has ot wait until next release +**\** It won't be an issue +**\** 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 +**\** if the windows binaries gets built tomorrow +**\** and after that i'm gonna work on whatever the commuity feels most prioritized +**\** That's cool, thanks jaquee. +**\** like the plugin system or better integration with daemon +**\** Can anyone in the know comment on (xmrcomas) statement? +**\** 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. +**\** yes. we could improve the ux with better validation +**\** About what ? Wanting binaries before 28 ? +**\** Create use cases +**\** yes personally i think all the dangerous stuff is fixed, at least im not aware of any +**\** 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? +**\** the mian thing is that the "open from keys file" usecase is missing and windows suers chan not easily switch wallets +**\** Niece. Thanks for testing medusa_ :) +**\** Probably just build boost statically. +**\** 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? +**\** jaquee: ok, excellent +**\** when official gui wallet out? +**\** about 2 weeks +**\** Anything else you want to add, jaquee ? +**\** nope +**\** There is no date, it was just discussed now and testing is being done. +**\** Anyone else want to talk about dev stuff for 6 minutes ? +**\** hiall: Read the backlogs :P +**\<_Slack> \** 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 +**\** Can someone confirm that the languages page has been scrubbed from the GUI? +**\** 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 +**\** I'd leave any level change till after the log system change, let's not waste work. +**\** so GUI release this month? :O +**\<_Slack> \** @moneromooo OK makes sense +**\** tompole: it's here as of today, just with only en_US IIRC. +**\** \** Can someone confirm that the languages page has been scrubbed from the GUI? **\<= Yeah, translations aren't done yet +**\** tompole: yes we've removed all languages except english for now until translations are finsihed +**\** if the issues with hardware acceleration get fixed in time, the gui should come out before oct 28 right? +**\<_Slack> \** Still inviting comments on the discussion though +**\** Okay cool, thanks. +**\** I'll put the strings on transifex next week +**\** Such that the community can help translating +**\** then we can enable them again +**\** As for killing closed bugs, that'll happen, once the pony gets a minute. He has logs with issues list. +**\** I just started to compile one for my ubuntu 15.10 +**\** i'm curious to know how qt was chosen as the gui lib, if anyone can comment +**\** 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> \** Thanks all. See you around! +**\** The other main one is GTK. Or.. custom :D +**\** WxWidgets maybe. +**\** {-anonimal} #kovri-dev topics today will be API and resolving the logo. +**\<+hyc>** gtk is atrocious. yeah mebbe wxwidgets +**\** Java :o +**\<_Slack> \** libgui? +**\** so there is a possibility that we see gui before end of october? +**\** expected date for release of the gui? +**\<_Slack> \** libui sorry https://github.com/andlabs/libui +**\** there's always a possibility +**\** Oh my. Maybe in november. +**\** It is possible yes. Have a look on GitHub under project MonerCore to gauge the status +**\** December, otherwise. +**\** next year guys +**\** lol +**\** 2018 +**\<@ArticMine>** hiall A possibility Yes; Promises: No +**\** now the probability of that possibility is a different story +**\** 2018 sounds like fud. I say 2017 at the latest +**\** Thanks for all your hard work everyone! +**\** For people wanting to read the kovri meeting 1 a minute, that'll be on #kovri-dev +**\** Thanks all +**\** Monero doesn't need to be concerned with tending to deadlines that relate to other projects. +**\** ONWARD MONERO! +**\** Thanks guys! +**\<+hyc>** bye all +**\<@ArticMine>** I am going there now. +**\** thaks people, good luck and rock on +**\** on a serious note though, can someone just tell whats the anticipated date for gui release? +**\** no +**\** @moneromoo thanks for that address verification wallet API pr +**\** why? +**\** because development +**\** monero should be concerned with the needs of the user - which is the gui. I think the questions on timing are relevant +**\<_Slack> \** lol +**\** gui will be done when it is done. not 1 day before or after +**\** sdgsdug9sd: apparently tomorrow +**\** soon. tm +**\** (or so I read above) +**\** well, its been 2.5 years +**\** before the documentary +**\** i think everyone can commit to that? +**\** Like I said above, luigi & ArticMine will test on windows systems tomorrow +**\** it's a bit rickety still though +**\** if there is no issue there, I see no reason to not put the beta release out +**\** exciting +**\** there can be a subsequent release when the linux path issue, wallet choosing issue, are fixed +**\** I saw forget windows. just release for linux and make everyone convert:) +**\** hmmm, not sure im getting this clear. so, its expected to be released tomorrow but no later than oct 28? +**\** f miscrosoft +**\** Unless tomorrow forgets to end, I guess. +**\** sdg 2017 at the latest +**\** 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 +**\** but maybe tomorrow:) +**\** moneromooo, lulz +**\** No testing is tomorrow, if that is fine the bins can be put out +**\** but that isn't necesarily tomorrow too +**\** :P +**\** gui testing tomorrow? +**\** Oh, multi day testing. Fair enough. Ignore me. +**\** noob question here , when the gui is released can we mine directly to gui wallet? +**\** Later, yes. Not yet. +**\** alrighty, what about kovri release? shouldnt it be december 2016? +**\** moneromooo: you could put your GUI wallet address in the daemon though +**\** can someone comment on this? https://www.youtube.com/watch?v=dQw4w9WgXcQ +**\** dEBRUYNE: what do you mean ? +**\<_Slack> \** rickrooool! +**\** moneromooo: just start_mining in the daemon +**\<_Slack> \** it ends in XcQ +**\** and then your GUI address +**\** you need a daemon running to use the GUi anyway +**\** Hmm, yes. That was not the question though I think. +**\** But that's more of a way around :P I think the guy meant mining directly in the GUI +**\** Oh, *to*, actually you're right. +**\** You mean you still need a terminal window open in order for the GUI to work? + + + \ No newline at end of file diff --git a/_posts/2016-10-30-logs-for-the-Kovri-dev-meeting-held-on-2016-10-30.md b/_posts/2016-10-30-logs-for-the-Kovri-dev-meeting-held-on-2016-10-30.md new file mode 100644 index 00000000..a91a4a5f --- /dev/null +++ b/_posts/2016-10-30-logs-for-the-Kovri-dev-meeting-held-on-2016-10-30.md @@ -0,0 +1,236 @@ +--- +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 + +**\** alright anonimal, the floor is yours +**\ [anonimal]** Proposed meeting items: +**\ [anonimal]** 1. Greetings +**\ [anonimal]** 2. Brief review of what's been completed since the previous meeting +**\ [anonimal]** 3. @fluffypony's request for finished logo +**\ [anonimal]** 4. ∫alti as Monero project +**\ [anonimal]** 5. [libqtoopie](https://github.com/EinMByte/qtoopie/issues/1) +**\ [anonimal]** 6. Preparing for pre-alpha release +**\ [anonimal]** 7. Code + ticket discussion / Q & A +**\ [anonimal]** 8. Any additional meeting items +**\ [anonimal]** 9. Confirm next meeting date/time +**\ [anonimal]** Hi +**\ [EinMByte]** Hi +**\ [i2p-relay] {-moneromooo}** Hi +**\ [i2p-relay] {-pero}** hi +**\ [olark]** Greetings. +**\** hi +**\** ola +**\ [i2p-relay] {-ArticMine}** hi +**\** hi +**\ [anonimal]** 2. Brief review of what's been completed since the previous meeting +**\ [anonimal]** Lots of refactoring, some fixes. +**\ [anonimal]** New contributor olark/olarks! +**\ [anonimal]** Welcome olark! +**\ [olark]** o/ +**\** welcome olark +**\ [anonimal]** Anything else on 2.? +**\ [anonimal]** (olark has been doing great work + tackling a huge learning curve. very cool) +**\** olark +**\ [olark]** lots of refactoring ;) +**\** maybe you can give us a brief background on you +**\ [i2p-relay] {-Slack} \** How’s the documentation looking to make that learning curve more shallow for future developers? +**\ [anonimal]** (e.g., favourite book, long walks on the beach, etc.) +**\ [anonimal]** nanoakron: moneropedia. We can talk more about that at the end of the meeting too. +**\ [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. +**\** olark: http://i.imgur.com/9AQYqBr.png +**\ [olark]** Also long time i2p user, so I know what's up. +**\ [anonimal]** lol, badge of honor. +**\ [anonimal]** Alright, well we're glad to have more hands on deck. +**\ [anonimal]** Anything else before moving onto 3.? +**\ [olark]** Haha thanks fluffypony +**\ [anonimal]** 3. fluffypony's request for finished logo +**\ [anonimal]** fluffypony: ^ +**\** yes +**\** ok this logo has taken WAY too much time +**\** I know that logos are kinda-permanent, but it's holding other stuff up +**\** why are all msgs going through meetingbot.. +**\** boomlol23: because we're spread out over multiple networks +**\ [anonimal]** fluffypony: what's the best solution for now? +**\** ok +**\** I'd like to have the logo by the end of the meeting +**\** if colours are an issue let's just stick with the original colours +**\** we can ALWAYS change it later +**\ [EinMByte]** Wait, we still haven't decided on the logo? +**\** EinMByte: we have +**\** but then there were font and kerning and colour changes +**\** new monero logo? +**\ [anonimal]** ontario: kovri logo +**\** ontario: no Kovri logo, we're in the Kovri meeting now +**\** k sry +**\ [anonimal]** Ok, can pero send you the finished work then? +**\** np :) +**\** yes please +**\** may I ask if I understood correctly that the i2p code will be rewritten in c++? +**\ \* anonimal** has to move onto next item.... +**\** either uploading somewhere or ric@getmonero.org +**\** i thought i 'submitted' the final one last weekend - i'd like to make one tiny half pixel change if i can +**\ [anonimal]** sornros: we can answer more after the meeting +**\** sornros: it already is being - https://github.com/monero-project/kovri +**\** i'll email it to both fluffypony and anonimal shortly +**\ [anonimal]** Anything else on 3.? +**\** thanks +**\** with the monero colors +**\** no that's anonimal, tks +**\** http://imgur.com/a/xCaZV fyi +**\** that's it +**\ [anonimal]** 4. ∫alti as Monero project +**\** pero: ok perfect - if you can send it to me after the pixel change +**\ [EinMByte]** sure +**\** half-pixel :P +**\ [anonimal]** EinMByte: I had some thoughts unless you wanted to dive into anything first +**\** thats a nice logo, I like the font too +**\ [EinMByte]** anonimal: No go ahead +**\ [anonimal]** We've moved on sornros. +**\ [anonimal]** EinMByte: since I haven't spent any time researching webextensions, can we *for sure* do what we want to achieve with XUL/XPCOM? +**\ [anonimal]** I'm thinking we consider brushing aside the deprecation issue for now and someone can pick it up in the future? +**\** 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? +**\ [EinMByte]** It depends what exactly we want to achieve +**\ [anonimal]** If we *can* do that now, we could move it into monero-project and it will gain more attention. +**\** PowerFlower: this is the Kovri meeting, you'll have to hold that question for later +**\** okay :) +**\ [anonimal]** EinMByte: well, the easy stuff for starters re: profile. We can do that, right? +**\ [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 +**\ [EinMByte]** Can we create the profile using webextensions? Probably not +**\ [EinMByte]** Then again, people are apparently smart enough to run TBB, so if necessary we can create a script to create the firefox profile +**\ [anonimal]** I think that was what we were going for +**\ [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) +**\ [EinMByte]** It seems like a bad idea to start creating a plugin with deprecated technology +**\ [anonimal]** Where's the definite deprecation date though? +**\ [EinMByte]** There is none (very vague, IIRC) +**\ [EinMByte]** It's also not clear if e.g. it will be deprecated for firebird +**\ [EinMByte]** (in fact, does anyone know if firebird itself is (going to be) deprecated?) +**\ \* anonimal** doesn't know +**\ [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. +**\ [anonimal]** And I can't find a date for deprecation, should we really base a great idea on what-if's? +**\ [EinMByte]** Yes, I agree. My spare time does not though +**\ [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. +**\ [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 +**\ [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. +**\ [i2p-relay] {-ArticMine}** I have to leave +**\ [anonimal]** s/definite/definitive/ +**\ [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? +**\ [anonimal]** If roadmap is too much, at least improve our readme. +**\ [EinMByte]** anonimal: That's probably a good idea. +**\ [EinMByte]** Sure. +**\ [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 +**\ [anonimal]** Ok, sounds great. Anything else on 4.? +**\** a short readme would be nice +**\** EinMbyte may i ask for your GIT repository name i couldn't find it +**\ [EinMByte]** realsony: EinMByte/salti +**\ [anonimal]** 5. [libqtoopie](https://github.com/EinMByte/qtoopie/issues/1) +**\** ty +**\ [anonimal]** EinMByte: did you get a chance to review #1? +**\ [EinMByte]** I read it +**\ [EinMByte]** Not sure if I can agree with converting it to a library +**\ [EinMByte]** It should be the other way around, IMHO +**\ [EinMByte]** qtoopie is based on I2PControl, with the idea of making it router-agnostic +**\ [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? +**\ [anonimal]** So what part would you rather see as the lib? +**\ [anonimal]** If monero's gui needs it's own i2pcontrol then that's fine; I'm just trying to avoid repetition. +**\ [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 +**\ [EinMByte]** If we want to build a GUI specifically for kovri, then we can rely on the (currently not existing) kovri API (libcore/libclient) +**\ [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 +**\ [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? +**\** I2PControl would be able to control Kovri + Java i2p etc. right? +**\ [EinMByte]** My original idea for qtoopie is that it would fork for all exiting I2P routers that support I2PControl. +**\** oh I missed the "based on" +**\** ok makes sense +**\ [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) +**\ [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)? +**\ [anonimal]** Why create extra monero gui code and i2pcontrol impl when that's already done? +**\ [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. +**\ [EinMByte]** Sure, monero can use qtoopie directly +**\ [anonimal]** If it's more work than not, and adversely effects qtoopie, then I understand. +**\ [EinMByte]** at least in the sense "you can display the windows defined in the qtoopie project" +**\ [EinMByte]** I guess that would classify as a library. +**\ [EinMByte]** The question is why you would want to bundle it like that +**\ [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) +**\ [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. +**\** can't we have our own controls in the GUI +**\** with bindings to libqtoopie functions ? +**\ [anonimal]** fluffypony: own controls to API, sure. +**\ [anonimal]** fluffypony: libqtoopie, EinMByte would know; I imagined yes. +**\ [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 +**\ [EinMByte]** If you want to have your own controls, there's not much point in using all of qtoopie +**\ [EinMByte]** then you just need to use i2pcontrol +**\ [EinMByte]** (which is very simple to implement; or you could use the part of qtoopie that deals with this) +**\ [anonimal]** EinMByte I think you're missing the point but I'm probably not explaining my intentions well. +**\ [anonimal]** So, libqtoopie: not needed. qtoopie: agnostic but will not be in library form. +**\ [anonimal]** We will create our own controls that use the API +**\ [EinMByte]** qtoopie is an end-user program, hence why I'd say "not in library form" +**\ [anonimal]** I know EinMByte, I'm just trying to save time and code. +**\ [EinMByte]** We could take some of the code in qtoopie and put it in a library "libi2pcontrol-client" +**\ [EinMByte]** This library could then be used by e.g. monero +**\ [anonimal]** i2pcontrol is insanely overrated, seriously overrated in relation to as much time as we're talking about it. +**\ [EinMByte]** But this is assuming that monero would be using i2pcontrol at all +**\ [anonimal]** I don't see the point if there are API's in place. +**\ [anonimal]** And i2pcontrol is limited in its own right. +**\ [EinMByte]** Yes, i2pcontrol has severe limitations +**\ [anonimal]** So, unless that entire spec is worked on, I have nothing more to say on the subject for now. +**\ [EinMByte]** (even the proposed version 2) +**\ [anonimal]** Ok, so we'll learn from the mistakes of others and try not to make our own. +**\ [anonimal]** fluffypony: does that makes sense? anyone need a tl;dr? +**\** yes it does +**\** tl;dr for the log +**\ [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). +**\ [EinMByte]** What is important to understand is that I2PControl is intended to create high-level control programs +**\ [EinMByte]** It isn't designed to deal with lower-level configuration that monero might need +**\ [anonimal]** Anything else on 5.? +**\ [EinMByte]** One of the main limitations, in case anyone is wondering, is that i2pcontrol has to serialize everything and send it over the network +**\ [EinMByte]** There's no possiblity of handlers or anything like that too +**\ [EinMByte]** (you have to continuously request updates) +**\ [anonimal]** yes. +**\ [anonimal]** Ok, 8 minutes +**\ [anonimal]** 6. Preparing for pre-alpha release +**\ [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 +**\ [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. +**\ [anonimal]** EinMByte has been very busy too. +**\ [EinMByte]** :| +**\** no problemo - let's get it right instead of getting it rushed :) +**\ [anonimal]** EinMByte: realistically, I think we should push the date to Dec. 1st or later. +**\ [anonimal]** It's never going to perfect in my eyes, but... +**\ [EinMByte]** Sure +**\ [EinMByte]** dont' expect more activity from me though +**\ [anonimal]** You mean ever or temporary? +**\ \* anonimal** hopes temporary +**\ [EinMByte]** I mean before december the first +**\ [anonimal]** Ok. I'll set a tentative date for dec. 1st; no later than 33c3. +**\ [anonimal]** (which is not dec. 1st of course) +**\ [anonimal]** I'll have to adjust the milestone date on github and roadmap etc. +**\ [anonimal]** Any other thoughts on 6.? +**\ [anonimal]** This coming month should be far more productive code-wise than in october. +**\ [anonimal]** We'll see what we can knock-out before december. +**\ [anonimal]** 2 minutes to spare +**\ [anonimal]** Skipping 7. Code + ticket discussion / Q & A unless anyone wants to say something? +**\ [anonimal]** 8. Any additional meeting items +**\** nope that's it from my side +**\** glad to see the refactoring efforts +**\** will make stuff easier to work on later on +**\ [iDunk]** head works now, thanks anonimal +**\** oberservers can now ask questions? +**\ [anonimal]** fluffypony: yes indeedy +**\ [anonimal]** iDunk: you're welcome, thanks for the notice and for actively testing :) +**\ [iDunk]** np :) +**\ [anonimal]** PowerFlower: kovri questions, yes +**\** ok let's close up the Kovri meeting and then PowerFlower can ask their Monero question :-P +**\ [anonimal]** Oh, those kinds of questions. +**\ [anonimal]** Ok, 9. Confirm next meeting date/time +**\ [anonimal]** Same time, two weeks? +**\ [olark]** Sounds good. +**\** yes +**\ [anonimal]** Alright, thank you EinMByte and everyone else here for making the meeting. +**\** meeting bot going down to switch back to the Monero stuf +**\ [anonimal]** Thanks fluffypony diff --git a/_posts/2016-10-30-overview-and-logs-for-the-dev-meeting-held-on-2016-10-30.md b/_posts/2016-10-30-overview-and-logs-for-the-dev-meeting-held-on-2016-10-30.md new file mode 100644 index 00000000..188593b3 --- /dev/null +++ b/_posts/2016-10-30-overview-and-logs-for-the-dev-meeting-held-on-2016-10-30.md @@ -0,0 +1,265 @@ +--- +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 + +**\** it takes quite long time to open/close wallets with this mempool size. Could the mempool be saved in wallet cache? +**\** or is that a bad idea? +**\** doesnt really affect closing wallets. my bad. but opening takes longer than normal i think? +**\** test +**\** You can test that easily by logging something before and after loading. +**\** It's in src/cryptonote_core/tx_pool.cpp +**\** is it mtg time yet? +**\** Yes +**\** romero dev conference +**\** all right. the gui def takes longer time top open because of mempool. And it also waits for mempool to be synced before closing. +**\** why is that different from CLI behavior? +**\** not sure yet +**\** opening seems the same +**\** mooo you're a whitespace nazi +**\ \** Is there a way that git PRs could be run through a common parser on the server-side to standardise any whitespace? +**\** Not really, since it'll invariably try to reformat irrelevant stuff. +**\** That said, if it could run on the diffs, it might work. +**\ \** And WRT mempool size - would fluffy blocks as standard across the network (e.g. if included in HF4) make things better? +**\** i don't think so, it just helps with not sending txs again when a block is found, the mempool size is unaffected +**\** So... if the pony isn't here... anyone wants to say something dev related ? +**\ \** 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 +**\ \** I’m a tinkerer rather than a dev :slightly_smiling_face: +**\** yea so the bigger the blocks (assuming mempools are aligned), the greater the savings +**\ \** Which would be an extra cool reason for making fluffy blocks compulsory in a hard fork +**\** 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. +**\** if you guys would like me to change anything, etc, feel free to ask/comment +**\ \** My only ‘dev issue’ is with the growing number of dead issues on github +**\ \** We should probably only be at 60 or so live issues +**\** I think at this point, it's testing. Especially that one about the array of txes noit in the pool but not requested again. +**\** may i as what a dead issue is? +**\** ask +**\ \** One that’s been solved +**\** ty +**\** monero-core has a lot of those too fwiw +**\** I can give you a list for monero-core fluffypony +**\** typically I would not close an issue until the fix is in a tagged release +**\** (at least, on other projects.) +**\** ^ +1 +**\ \** 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 +**\** or at the very least merged +**\ \** @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... +**\** I hadn't heard anything about that 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 +**\** Bitcoin unlimited will be insecure once the emission runs out +**\ \** And I think the entire ecosystem will benefit +**\ \** 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 +**\** would definitely be a good idea to go thru and close any that havve been fixed +**\** @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? +**\** could speed things up a bit +**\** I'll have a look soon. String to grep for ? +**\** "Do I need to do this" lol +**\** ok +**\ \** lol +**\ \** How is 0qm work? +**\** proxmr: you'll know in ~30 min when anonimal's around for the kovri meeting. +**\** tewinget: around ? +**\ \** 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? +**\ \** What is fluffy blocks? I am missing something here +**\** dynamic fees +**\** @mailmen just a compact block implementation for monero +**\** It's just sending txes from a block only if a peer doens't have them already. +**\ \** Hmmmm, so, instead of sending all tx the block will contain only the reference of the tx that is in another block? +**\ \** No, reference to the local mempool +**\ \** Ahh +**\** 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 +**\ \** And if it’s not in there then you receive the missing Tx +**\** if it's missing any, it'll ask for those +**\ \** Nice +**\ \** Really nice :slightly_smiling_face: +**\ \** It is implemented in any place already or we will be the first ones to have it? +**\ \** Bitcoin has it +**\** yep, multiple implementations, xthin/compact blocks +**\ \** 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 +**\** 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 +**\ \** Hmmm, nice... And about the way the db save the blocks, I was thinking in the other day +**\ \** @revler1082 you should contact the original devs of XThin and ask them about those issues :slightly_smiling_face: +**\** 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. +**\ \** @hyc is your db guy +**\ \** 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 +**\** thanks @moneromooo that's a good one +**\** I'm guessing there might be a good reason why they don't do that though. +**\ \** 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 +**\** The idea if I understand this is to save bandwidth +**\** @ArticMine correct +**\** not much difference now, but when monero takes over the world, savings should increase +**\** You pull from the historic data not the mempool +**\ \** So not many dev issues today which is good. Just really revler and moneromooo co-reviewing fluffy block code, and maybe closing old issues? +**\** We can't close old issues. We can just make lists and wait for fluffypony to have time :) +**\ \** True +**\** 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 +**\ \** Would you think about the logging system in that case? The crypto currently works well enough +**\** The main problem is choosing the best one. And that needs people who know them. The pony does I think. +**\** logging or crypto? or both? +**\ \** Moneromooo, do you have any thoughts on where revler can best help after fluffy blocks are finished? +**\** We'll need some crypto lib with a good PRNG, to replace the keccak construction we use now. +**\ \** https://github.com/monero-project/monero/issues/1271 +**\ \** That’s what we’re referencing here revler - already some good discussion to review there +**\** Wherever revler1082 is comfortable, really. If the previous bit changed was network stuff, then maybe more of it ? +**\ \** What do you think the issues are with current network code? +**\** fluffypony wanted to switch the P2P protocol to... er... something... name escapes me. +**\ \** ;) +**\** ZMTP. +**\ \** ooh…sounds fancy. How about maybe helping with ZMQ?? +**\** jesus +**\** It's based on epee, from the CN people. +**\ \** @iDunk you rang? +**\** all sounds good, i'll look into it and help where I can +**\** The P2P code is really hard to understand, though that is subjective, mayube others like it more. +**\** yeah, I'm on the verge of really saying something +**\** There are a few bugs, mainly that it leaks sockets. +**\** if i ever get my spaces and tabs passed @moneromooo +**\ \** hehe +**\ \** What’s up iDunk? +**\** Well, it boils down to "don't change what you don't change". +**\** nanoakron: take it easy, man +**\** But I agree I may be a bit too sold on clean diffs without extraneous stuff. +**\** Those things are easy to fix though. +**\** lol, @moneromooo just messin, I want to kick myself when I push and see those in the diff, like mother .. +**\ \** Revler wants to help with network related stuff and I’m just saying what’s in the codebase that is being worked on +**\** 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. +**\** yes ZMTP +**\** pony! +**\ \** Woo! +**\** apologies +**\** had the meeting down for 7pm not 6pm +**\ \** Do you guys change your clocks today down there in SA? +**\ \** Ours went back last night. It’s now dark at 5pm. Misery. +**\** no, we don't do DST +**\** OH that's why +**\** everything is confusing +**\** thought sth like this :p +**\** re: closing issues +**\** I'm happy to close them from lists +**\** and I don't think we need to wait for them to be in a tagged release per se +**\ \** Cool +**\** have we discussed the compact blocks thing ? +**\** I see there's some backlog on it +**\ \** Briefly +**\** what prevents dupes then? +**\** might be better to tag issues with 'fixed in next release' or something and keep them open? +**\** all the verification is the asme, it's just saving from re-sending txs? +**\** pero: dupe issues? +**\** oh +**\** yea +**\** lol +**\** revler1082: I was also confused +**\** sorry =/ +**\** np +**\** pero raises a good point +**\** I can flag them instead +**\** If people don't search the bugs list, they'll file a dupe whether it's closed or open, no ? +**\ \** Take https://github.com/monero-project/monero/issues/1256 as an example +**\ \** May be a dupe, may not be... +**\** I'm fine with bugs being opened when in doubt. +**\ \** @moneromooo - yes they will +**\** \ everything is confusing <= Oh I didn't notice too +**\** but they likely won't experience the issue if it's in a release +**\** That link I posted on reddit says 17:00 Europe time lol +**\** lol +**\** ok so re: compact blocks +**\** got some fixes and ideas from @moneromooo that i'm gonna try +**\** 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? +**\** only big thing is do we want backwards compatibility and a little messier code, or alter existing stuff/cleaner? +**\ \** The good thing about hard forks is that we don’t need backwards compatibility +**\** I'd rather have it in testnet first. +**\ \** Yes +**\** definitely +**\** ok let's finish the compact blocks discussion +**\** PowerFlower: pleasure :) +**\** 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. +**\** PowerFlower: Thank you. bye +**\** Compact blocks: pretty good, not much to change, will need lots of testing though. +**\** yep +**\** 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 +**\** revler1082: Have you tested it on a personal private testnet? +**\** yea, and on mainnet with the backwards stuff +**\** oh cool +**\** since we have a testnet reorg coming up we can use the opportunity to test wrapping it in a fork +**\** We need to have both block types in the code at the same time though. +**\** So if we do, conditional use isn't much more. +**\** BTW, syncing from scratch uses a different set of messages, right ? +**\** yes i believe so +**\** A possible optimization would be to always include txes with too low fee, since these would have been mined by the local host. +**\** So men i read everything, didnt understand 97% :) convinces me that XMR has the best alt dev team :) +**\** But that's really not needed now. +**\** yea, there's a few tweaks we can make, i like your send tx index instead of hash for missing +**\** Yes, it sounds like a no brainer, so I'm suspicious that bitcoin is not doing it for non obvious reasons... +**\** fluffypony: do you know why they use siphash hashes and not indices in the block ? +**\** (since you linked to that doc, I think you might know :P) +**\** moneromooo: I have no idea +**\** noob suggestion: for the next meeting how about disabling other chat unless dev when the meeting bot started? +**\** btcdrak might have an idea +**\** ontario: if the room goes +m then only people with +v can speak, and then it becomes a closed meeting +**\** better for it to stay open, we can handle the occasional interruption +**\** yeah that's what to do +**\** lol sry dont know much about irc things +**\** btcdrak: moneromooo had a question about compact blocks, and why it uses siphash hashes instead of indices +**\** (note, I know very little about bitcoin, so it could be tx indices don't make sense in bitcoin) +**\** moneromooo: ask in #bitcoin-core-dev +**\** OK, I will, thanks. +**\ {-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) +**\** my thinking is that we can offload the sensitive stuff to TweetNaCl (ie. crypto_ops), as it's currently using SUPERCOP ref10 +**\** then we offload everything else to cryptocpp, including random +**\** and then *if* we're seeing performance bottlenecking in something specific, we can use ASM implementations *only* in the places it's bottlenecking +**\** Since we use part of... libsodium ? Does this not do everything we need ? +**\** moneromooo: the libsodium source isn't even complete, so we'd have to make changes anyway +**\** libsodium isn't as full-featured as cryptocpp anyway +**\** and not as audited as TweetNaCl +**\** Anything else to talk about ? +**\** well +**\ {-anonimal}** So there won't be a one-size-fits-all crypto solution, eh? +**\** btw moneromooo +**\** https://en.wikipedia.org/wiki/NaCl_(software) +**\** so TweetNaCl implements all of those +**\** as does libsodium +**\** that libsodium can do a handful of extra things is neither here nor there +**\** https://en.wikipedia.org/wiki/Comparison_of_cryptography_libraries +**\** I'm curious to know why they made many versions of hte same thing. +**\** the advantage is that cryptocpp can do a TON of stuff, it's FIPS 140 validates, and it uses the Boost license +**\** That sounds like a recipe for pita. +**\** moneromooo: of NaCl? +**\** Yes. +**\** they only made NaCl, and then they made TweetNaCl specifically to be extremely simple and auditable (so that it could be formally verified) +**\** NaCl was forked and thus begat libsodium +**\** so the original NaCl reference implementation has been replaced by libsodium, effectively +**\** crypto++ is the same as cryptopp ? +**\** yes +**\** also has AES-NI support, which is great +**\** doesn't have ARMv8 crypto support yet +**\** "Unix (OpenBSD, Linux, OS X, etc.), Win32, Win64, Android, iOS, ARM" +**\ \** 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 +**\ \** Pine64 may do, but I’ve not bought one yet +**\** pine64 does +**\** So if we were to switch to cryptopp, would be still keep the existing low level crypto code, or just use for new stuff ? +**\** Though I guess we have a readily available test suite actually :) +**\ {-anonimal}** fluffypony: I believe there is limited(?) armv8 support, or do you mean specifically aes-ni? +**\ {-anonimal}** \* going off of memory, would need to confirm +**\** anonimal: it's not NB right now +**\** moneromooo: we'd switch +**\** even if it's piecemeal +**\ \** 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? +**\ \** So that all nodes at HF5 will use compact blocks (of whatever improved flavour comes along in the interim) +**\** its not "forking code" though right? +**\** no it's not +**\ \** So it could in fact be made compulsory at HF 4 without backwards compatible code? +**\** and I mistakenly forgot that we need to keep both block formats anyway for sync up +**\** so not worth putting it in an HF wrapper +**\ \** Unless we checkpoint at the next HF... +**\** Not for 4. Seriously... \ No newline at end of file diff --git a/_posts/2016-11-13-logs-for-the-Kovri-dev-meeting-held-on-2016-11-13.md b/_posts/2016-11-13-logs-for-the-Kovri-dev-meeting-held-on-2016-11-13.md new file mode 100644 index 00000000..0e68645d --- /dev/null +++ b/_posts/2016-11-13-logs-for-the-Kovri-dev-meeting-held-on-2016-11-13.md @@ -0,0 +1,247 @@ +--- +layout: post +title: Logs for the Kovri Dev Meeting Held on 2016-11-13 +summary: Brief review of what has been completed since last meeting, prepration of Alpha release, and code & open tickets discussion +tags: [dev diaries, i2p, crypto] +author: dEBRUYNE / fluffypony +--- + +*November 13th, 2016* + +### Logs + +**\ {-anonimal}** Proposed meeting items: +**\ {-anonimal}** 1. Greetings +**\ {-anonimal}** 2. Brief review of what's been completed since the previous meeting +**\ {-anonimal}** 5. Code + ticket discussion / Q & A +**\ {-anonimal}** 3. Preparing for alpha release +**\ {-anonimal}** 4. Moving meeting agenda issues from monero-project/kovri to monero-project/meta +**\ {-anonimal}** 6. Any additional meeting items +**\ {-anonimal}** Hi +**\ {-anonimal}** 7. Confirm next meeting date/time +**\ {-anonimal}** JFTR for the log: people think the meeting is at 19:00 when it is actually at 17:00 so we may be a bit shorthanded today +**\ {-anonimal}** 2. Brief review of what's been completed since the previous meeting +**\ {-anonimal}** The general focus of the past two weeks has been "escaping comfort zone" work: +**\ {-anonimal}** i.e., pursuing a few long-standing issues that I've avoided because they weren't fun: +**\ {-anonimal}** Build: +**\ {-anonimal}** - Builds builds builds! All builds are now in the GREEN! +**\ {-anonimal}** - ARMv7/8 and Win32/64 builds are now online! Static builds online! +**\ {-anonimal}** - Win32/64 run-time is now available after patching an upstream issue +**\ {-anonimal}** - ARMv7 has a non-Kovri runtime issue, ARMv8 box still needs testing +**\ {-anonimal}** - Much build-related work with pigeons, partly noted in monero-project/meta +**\ {-anonimal}** - Setup kovri per-platform IRC clients for testing, say hi to them in #kovri-dev +**\ {-anonimal}** Code: +**\ {-anonimal}** - Resolved all Coverity defects (details in #263)! +**\ {-anonimal}** - Bug fixes in addressbook + shutdown, https on windows +**\ {-anonimal}** - Design and planning: global refactoring, study, and testing +**\ {-anonimal}** - SSU Server testing (nothing merge-able at the moment) +**\ {-anonimal}** - Debugging, attending to open milestone issues +**\ {-anonimal}** - Mentoring: working with other contributors to "Make Kovri Great Again" +**\ {-anonimal}** - guzzi doing his civic duty while also working on http proxy (WIP) +**\ {-anonimal}** - olark providing great netdb/socks proxy documentation and refactoring +**\ {-anonimal}** Misc: +**\ {-anonimal}** - 7z/installer research for platform-agnostic bundling of data-dir with static binary +**\ {-anonimal}** - README/Doc updates, misc. project maintenance +**\ {-anonimal}** - Too many other things to mention here or things that I've simply forgotten +**\ {-anonimal}** Note: confirmed earlier: run-time is online on ARMv8! +**\ {-anonimal}** Anything else on point 2.? +**\ {-olark}** Sums up the past 2 weeks well. +**\ {-anonimal}** Side-note, JFTR: slack relay is not working and fluffypony isn't running meeting relay to #monero-dev +**\ {-anonimal}** Ok, moving on, +**\ {-anonimal}** 3. Preparing for alpha release +**\** Here fyi +**\ {-anonimal}** Oh good, hi guzzi (I PM'd you earlier) +**\** Ok +**\ {-anonimal}** So, 3. looking at https://github.com/monero-project/kovri/issues?q=is%3Aopen+is%3Aissue+milestone%3A0.1.0-alpha +**\ {-anonimal}** A few of these can be moved to next milestone (they aren't urgent), +**\ {-anonimal}** If I can't resolve the rest by Dec 1st. in addition to everything else that needs attention, then maybe Dec. 14th at the latest. +**\ {-anonimal}** Really there are only a few key issues that *must* be resolved for an alpha release and they are, IMHO: +**\ {-anonimal}** #375 and #119 <-- at an absolute bare minimum +**\ {-anonimal}** because they *really* can get in the way. +**\ {-anonimal}** But that's a bare-minimum not-ideal scenario and I know we can get more done by then. +**\ {-anonimal}** Any thoughts? +**\ {-olark}** Yeah those are the big ones. I'll go over the addressbook and add/remove the destinations that don't work. +**\** 119 looks easy for u. I dont disagree +**\** Sorry i meant 375 +**\ {-anonimal}** Well, it looks straightforward, we'll see what it really looks like when the time comes :) +**\ {-anonimal}** olark: re: destinations, which issue # is this? +**\ {-olark}** Keep it a small list. +**\ {-olark}** Some are just dead. +**\ {-olark}** So we have a small list of eepsites that do work and may be useful for a new user. +**\ {-olark}** Not in the milestone I believe. +**\** Agree on the eepsite list actually containing valid sites +**\** 119 looks like a critical fix for sure. +**\ {-olark}** re: subscription file +**\ {-olark}** Not high priority but maybe something nice to have for the first release. +**\ {-anonimal}** olark: oh that, well that's very low priority but if it's an issue than ok, but how can you confirm if they are dead? Were some removed in the .27 java i2p release? +**\ {-olark}** Just some of them never connect ever. +**\ {-olark}** I'll go over them again in the coming days. +**\ {-anonimal}** Ok, sounds good. +**\ {-anonimal}** guzzi: well, I wouldn't say critical because it doesn't effect all routers and it certainly hasn't effect the OSX instances +**\** Ok understood +**\ {-anonimal}** And there's always the option to disable ssu at run-time, but yes I think it should be resolved. +**\ {-anonimal}** fluffypony hinted at *not* having a release before 33C3 but he may be trying to get out of https://github.com/monero-project/kovri/issues?q=is%3Aopen+is%3Aissue+milestone%3A0.1.0-alpha+assignee%3Afluffypony +**\* guzzi** needs to find out what ssu is before i +**\ {-anonimal}** ;) +**\* guzzi** open my mouth +**\ {-olark}** Semi-Secure UDP +**\** Thanks +**\ {-anonimal}** guzzi: checkout the new Moneropedia entries I made that are now live on the website +**\ {-anonimal}** guzzi: link is in README.md +**\ {-anonimal}** (on current HEAD) +**\** Awesome +**\* guzzi** Todo tonight +**\ {-anonimal}** So, re: release, +**\ {-anonimal}** Let's keep hacking away for the next two weeks and see where we stand. +**\ {-anonimal}** Any objections? +**\** Ok i will read your pm when i get back +**\ {-olark}** Keep on hacking away ;) +**\** On phone now +**\ {-anonimal}** The difference between a Dec. 1st alpha release and Dec. 14th alpha release IMHO will be noticeable to an end-user. Neither is useful without package resolution nor more monero input/participation; so I want to wait for a final decision until fluffypony speaks up. We can talk more this coming week. +**\** I agree boss. +**\ {-anonimal}** lol guzzi +**\ {-anonimal}** My biggest concern is that for reasons not of my doing, a release doesn't happen before 33c3, and I really hate having to change dates like this. +**\ {-anonimal}** But I'll have to be flexible for now because there are many moving parts. +**\ {-anonimal}** Anything else on point 3.? +**\** No +**\ {-anonimal}** olark: ? +**\ {-olark}** We can keep moving along. +**\ {-anonimal}** 4. Moving meeting agenda issues from monero-project/kovri to monero-project/meta +**\ {-anonimal}** So, as this meeting has proven, no one else in Monero looks at the meeting agendas I prepare for every meeting :) +**\ {-anonimal}** With the creation of monero-project/meta, I think it would be better to not clutter the kovri repo with meeting agendas. +**\** Agree 100% +**\ {-anonimal}** I would hope that more monero people get inolved with meeting agenda preparation and start using the meta repo too. +**\ {-anonimal}** I'd like to move agendas to meta from now on. guzzi is on board. Anyone else? +**\ {-olark}** Sounds good to me. +**\ {-anonimal}** Alright, I'll start doing that. +**\ {-anonimal}** Moving on, +**\ {-anonimal}** 5. Code + ticket discussion / Q & A +**\ {-iDunk}** i built kovri on win64 successfully but the build failed on linking for win32 +**\ {-anonimal}** We've basically covered this in point 3, but I did add some new notes to #187 +**\ {-iDunk-kovri-win64}** hiii +**\ {-anonimal}** For #187 not sure if EinMByte is around. +**\ {-anonimal}** Yay, hi iDunk-kovri-win64 :) +**\ {-iDunk-kovri-win64}** :) +**\** Do we care about 32 +**\ {-anonimal}** iDunk: can you paste error after the meeting? +**\ {-iDunk}** will do +**\ {-anonimal}** iDunk guzzi: our win32 build is working with buildbot https://build.getmonero.org/waterfall +**\** Ok so it is isolated +**\ {-anonimal}** Yep, most likely, we'll see. +**\ {-anonimal}** Anyone have any questions/comments on open/closed issues? +**\** Nice work idunk thank you +**\** None here. You know where i am at +**\ {-iDunk}** np +**\ {-anonimal}** lol, sipping up a pina colada I imagine +**\** Lol yes. +**\ {-anonimal}** olark: any questions/comments on open/closed issues? +**\** I also had meant you know where i am at code wise +**\ {-olark}** All good ;D +**\ {-anonimal}** Oh, haha! +**\ {-anonimal}** * glances over issues +**\ {-olark}** re: APIs +**\ {-olark}** How is that coming along? +**\ {-olark}** #351 and #350 +**\ {-anonimal}** Once more client/router work is completed, they will be easier to implement. +**\ {-anonimal}** So that first, API second. +**\ {-olark}** Ya, still got a little ways to go. Haven't written APIs in a while so could be a good place to refresh myself ;) +**\ {-anonimal}** I'm getting a better idea of how I'd like to implement but I'd like to compare notes with EinMByte when he returns before moving on anything. +**\ {-anonimal}** (because he has strong opinions on the matter and he has great experience) +**\ {-olark}** Yeah his input is very valuable. +**\ {-olark}** Well known in the i2p community. +**\<_Slack> \** Lol +**\ {-anonimal}** I'll continue to comment in those tickets as other work progresses. +**\ {-anonimal}** I always keep the APIs in mind when doing other work, +**\ {-anonimal}** which always leads to more work that needs to be resolved before returning to APIs +**\ {-olark}** Yep +**\ {-anonimal}** (etc. etc.) +**\ {-anonimal}** Ok, anything else on this point? +**\ {-anonimal}** If not we can talk more about it later this week. +**\ {-olark}** That is all on my side. +**\ {-olark}** Ok. +**\** None here +**\ {-anonimal}** 6. Any additional meeting items +**\ {-anonimal}** Nothing from me. We have a clear plan, we're executing the plan as planned. +**\** None here. You will be busy. I will try to correspond efficiently s possible the next two weeks +**\<_Slack> \** Slight general question about i2p - if I'm running kovri in the future, would a malicious agency be able to detect that? +**\ {-olark}** ISPs can figure out you are using i2p. +**\ {-anonimal}** nanoakron: that depends on the agency +**\** A malicious one. +**\* moneromooo** runs +**\<_Slack> \** Lol +**\ {-anonimal}** nanoakron: good question, I think that was one of the SE questions I bookmarked to answer +**\<_Slack> \** Are there any loose thoughts on the step beyond kovri? Steganographic encoding within normal router traffic? +**\ {-anonimal}** Now that moneropedia is merged, I'll answer them. +**\ {-olark}** I would like to explore better ways to obscure i2p traffic in with regular clearnet traffic, but that is for future research. +**\<_Slack> \** Of course +**\ {-olark}** SSU is pretty resistant to DPI and kovri already takes some countermeasure to hide the fact i2p is being used. +**\ {-anonimal}** Stego obfuscation within encryption? That makes as much sense as encrypting the encryption more than it is already encrypted. +**\ {-olark}** But there are lots of avenues to explore. +**\ {-olark}** Packet size I believe is the biggest giveaway among others. +**\ {-anonimal}** nanoakron: do you have any research on that? +**\ {-anonimal}** (proving any effectiveness?) +**\<_Slack> \** Sadly not :( +**\<_Slack> \** It's just something I heard being discussed between two more technical people where I work a while ago. +**\ {-anonimal}** nanoakron: it would probably me more effective to simply add another layer of encryption (but that isn't really necessary) +**\<_Slack> \** Stego to hide bitcoin +**\ {-anonimal}** (but maybe I'm not understanding your point exactly) +**\ {-anonimal}** Oh, well that makes sense. +**\ {-anonimal}** They're not dealing with layered encryption like we do. +**\<_Slack> \** At the router level +**\ {-anonimal}** (afaik) +**\ {-anonimal}** I'm not sure how effective that would be for us, but nanoakron if you get more info please feel free to send to #kovri-dev +**\<_Slack> \** How easy would it be for the North Korean government to shut down all i2p traffic for example. Anyway...it's highly theoretical stuff right now. +**\<_Slack> \** Of course! +**\ {-anonimal}** nanoakron: and olark pointed out important overlay-network facts +**\<_Slack> \** Yep +**\ {-anonimal}** North Korea? Can't they basically do whatever they want whenever they want to on any network level? +**\ {-olark}** North Korea has no internet infrastructure aside from government use afaik. +**\<_Slack> \** That would be the worst case scenario. For example if our governments decided to ban all non-fiat currencies. +**\ {-olark}** But if it is any indication, I2P can be run in China. +**\ {-anonimal}** Doesn't their "internet" exist entirely in a class C subnet? +**\<_Slack> \** Anyway, I'm just spitballing +**\ {-olark}** It is important to keep those things in mind though. +**\ {-anonimal}** Spitball all you want, we have 7 minutes left :) +**\<_Slack> \** ;) +**\** Lol. True +**\<_Slack> \** Something for the monero research lab +**\** We should at least worry about packet sizes. +**\** In the future +**\** We are going to add user agent options +**\<_Slack> \** Deterministic packet sizes to prevent fingerprinting and sniffing +**\<_Slack> \** ? +**\ {-olark}** Blending in with SSL traffic is the ideal scenario. +**\<_Slack> \** Ah yes +**\<_Slack> \** Will my little Odroid C2 node (ARMv8) be able to run kovri alongside monero in its final embodiment? +**\ {-anonimal}** NTCP2 is addresses TCP packet length obfuscation. +**\ {-anonimal}** olark: blending in with SSL, I don't see how that would be ideal, what do you mean? +**\ {-olark}** To fly under the radar more. +**\ {-anonimal}** nanoakron: I'm running kovri on ARMv8 linaro right now +**\<_Slack> \** Neat +**\ {-olark}** If I am a mouse my best bet is to sneak in with all the other rats into the kitchen right? ;) +**\ {-olark}** Hoping no one realizes I am a mouse. +**\ {-anonimal}** olark: they'll tend to shutdown SSL connections before detecting NTCP/UDP signatures, I'm pretty sure of that. +**\<_Slack> \** Yes, not true stego but mimickry. +**\** Agree. +**\** Any other doomsday senerios? +**\<_Slack> \** Lol +**\** 1 min? +**\ {-anonimal}** Btw: a TLS transport is still an open draft proposal from 2009 https://geti2p.net/spec/proposals +**\ {-anonimal}** TLS/SSL makes it's case but I'm not strongly in favor. We can talk more about that at the next meeting if anyone wants to, just add a note in the agenda. +**\ {-anonimal}** Moving on, +**\ {-anonimal}** 7. Confirm next meeting date/time +**\ {-anonimal}** moneromooo: will next meeting be 18:00 for #monero-dev? +**\ {-olark}** Hmmm +**\ {-anonimal}** Or 17:00? +**\ {-fluffypony}** oh +**\ {-fluffypony}** sorry anonimal +**\ {-anonimal}** Thanks for understanding fluffypony. +**\ {-fluffypony}** my apologies +**\ {-fluffypony}** I must've misunderstood the timing discussion +**\ {-anonimal}** fluffypony: apologies accepted! Are #monero-dev meetings now at 17:00 or 18:00 +**\ {-anonimal}** (fluffypony: we're idling on 7. Confirm next meeting date/time) +**\ {-fluffypony}** anonimal: let's update after the Monero meeting +**\ {-anonimal}** Alright, I'll start with 17:00 +**\ {-anonimal}** Meeting in two weeks. +**\ {-anonimal}** Thanks everyone! +**\ {-olark}** Good talk everyone :D \ No newline at end of file diff --git a/_posts/2016-11-13-overview-and-logs-for-the-dev-meeting-held-on-2016-11-13.md b/_posts/2016-11-13-overview-and-logs-for-the-dev-meeting-held-on-2016-11-13.md new file mode 100644 index 00000000..9c940ded --- /dev/null +++ b/_posts/2016-11-13-overview-and-logs-for-the-dev-meeting-held-on-2016-11-13.md @@ -0,0 +1,327 @@ +--- +layout: post +title: Overview and Logs for the Dev Meeting Held on 2016-11-13 +summary: Meta repository, Fluffy Blocks, and official GUI +tags: [dev diaries, core, crypto, 0mq] +author: dEBRUYNE / fluffypony +--- + +*November 13th, 2016* + +### Overview + +An overview [can be found on Hello Monero](https://hellomonero.com/article/monero-dev-meeting-note-highlights-2016-11-13). + +### Logs + +**\<@ArticMine>** Hi +**\<+moneromooo>** Oh hi +**\<@fluffypony>** oh and pigeons +**\** allright boys, get it started :P +**\<@fluffypony>** and tewinget +**\** Jaquee ping too +**\** hi +**\<@fluffypony>** ok so let's start with an infrastructure update +**\** hi! +**\<@fluffypony>** pigeons: how goes it +**\** good +**\<@fluffypony>** pigeons: do you want to tell people about the new repo we're using for issues? +**\** github.com/monero-project/meta +**\** https://github.com/monero-project/meta +**\<_Slack> \** Please explain? +**\** for the lazy +**\** for stuff realted to build machines, build infrastructure, etc +**\** anonimal has been using it some to get things setup for kovri needs +**\** so feel free +**\** I got some emails about issues +**\** I was like cool +**\<@fluffypony>** ok so +**\<@fluffypony>** please use /meta for organisational issues +**\<@fluffypony>** "organisational" as in something that isn't project specific +**\<_Slack> \** Roger +**\** there is also an empty repo there now, i'll check in some build infrastructure settings there and vm templates +**\ {-anonimal}** pigeons: can I PM you on Irc2p or are you AFK from that instance? +**\** yes i'm online there +**\ {-anonimal}** \* has to leave soon +**\<@fluffypony>** ok so +**\<_Slack> \** Ha +**\<_Slack> \** Ja +**\<@fluffypony>** we've had quite a few PRs merged in the last 2 weeks +**\<@fluffypony>** some big things like "fluffy blocks" that need testing and fiddling to check for edge cases +**\<_Slack> \** Can I run a testnet client in parallel with my main net one from the same box? +**\<@fluffypony>** yes I do +**\<@fluffypony>** on my laptop +**\** i also do +**\<_Slack> \** Could you make some details public, maybe in the readme? +**\<_Slack> \** I mean instructions +**\** what details? +**\<@fluffypony>** @NanoAkron for running testnet and mainnet? +**\<_Slack> \** Yes please +**\<@fluffypony>** ./monerod --testnet +**\<@fluffypony>** ./monerod +**\** start moderod normally for mainnet +**\<@fluffypony>** in two different windows +**\<_Slack> \** And they're happy to play together? +**\** and monerod --testnet for testnet +**\** yes very happy +**\** needs annotated screenshots imho +**\** they play separately +**\** like 2 small pupies +**\<_Slack> \** Ok cool. +**\<_Slack> \** Will get that up and running when I'm home next week. +**\** you also need to start monero-wallet-cli --testnet +**\** for a testnet wallet +**\<_Slack> \** Are there any decisions on making the whole network fluffy at the next hardfork? +**\<+moneromooo>** Veto. +**\<@fluffypony>** I think they're already enabled by anyone running a node that supports it +**\** it is not necessary +**\** not next like jan +**\** and it doesn't need a fork? +**\** right. it doesn't need a fork. +**\<@fluffypony>** the fork would only have been done to avoid old nodes showing weird error messages +**\** client that support fluffy blocks talk fluffy +**\<@fluffypony>** but honestly it's not a big deal +**\** and those that don't, don't afaik +**\<_Slack> \** But to make it compulsory. Reducing block sizes would also help obfuscation. +**\<+moneromooo>** It kind of is. If there's a nasty bug once close to 100% of the nodes switched, boom. +**\** there is no block size reduction +**\** \ #58 is not fixed \<= apologies, should be reopened then +**\<_Slack> \** There's no block size reduction? I think you're mistaken +**\<@fluffypony>** @NanoAkron it doesn't reduce block size, just reduces traffic +**\<+moneromooo>** He is not. +**\** nonaoakron: i am nitz +**\** not* +**\** lol +**\<@fluffypony>** ie. you have the transactions already in the mempool, so no need to re-send them +**\<@fluffypony>** but the block size stays the same +**\<+moneromooo>** Hi nitz. +**\<_Slack> \** Yes ok I wasn't precise enough +**\** :) +**\<+moneromooo>** hi +**\<_Slack> \** It reduces block transmission and reduplication, reducing overall network traffic and 'burstiness' +**\<@fluffypony>** yes +**\<_Slack> \** Thereby improving obfuscation efforts ;) +**\<@fluffypony>** ok +**\<_Slack> \** And kovri +**\<_Slack> \** Should also benefit +**\<+moneromooo>** Can we leave that till after we're done with the meeting though ? +**\<_Slack> \** Due to packet size reduction and traffic reduction. Good reasons to make it compulsory at some point in the future. +**\** ^^ +**\<_Slack> \** Ok will leave it now. +**\<@fluffypony>** @NanoAkron it *is* compulsory +**\<@fluffypony>** ok so +**\<_Slack> \** Ja +**\<@fluffypony>** Jaquee / medusa_ could you give us a GUI update, based on the stuff that's been done in the past 2 weeks ? +**\** yeah +**\** We've made great progress last couple of weeks. A lot of great contributions and inputs from new people. Great to see! +**\** All critical issues i know of are fixed and we have a very good looking, working gui with all basic functionality in place. +**\** I believe next step is building binaries to make it possible for more people to test it +**\<@fluffypony>** ok +**\** Since the 0.10 daemon isnt compatible with gui we also need to make sure we have a working monerod build to release with the gui. +**\<@fluffypony>** we'll try couple that with a new 0.10 point release +**\** nice, can you give us an ETA for the download? :) +**\** sounds good +**\<@fluffypony>** so it will take a couple of days to wrap up a point release too +**\** ok. makes sense +**\<_Slack> \** Can I ask about translations/localisation? +**\** yes +**\<@fluffypony>** sure +**\** i haven't worked on those parts very much though. but i can try to answer your questions. +**\<_Slack> \** Is there an easy way I could try to translate some stuff for you - I speak a bit of Malay. Is there a transifex or maybe a way to scan the transifex of another coin (ahem) and pull in their translations? +**\** i think dEBRUYNE is planning to publish the translation files somewhere. +**\** I've been intending to put the strings up on transifex, but I have spent the time that I had on testing in the last few weeks +**\** And it's a bit of a pita to get the strings out +**\<_Slack> \** Makes more sense to test right now anyway +**\** today I tried to update german translations, but there seems to be a bug choosing the language (at least under macos) +**\** maitscha: i'm not sure if translations are fully implemented yet +**\** yes we took them out basically +**\<_Slack> \** Some wizard could probably whip up a way to pull translations from another coin... ;) +**\** to get it as stable a spossible for now +**\** ok, I think the translation stuff needs some fixes to get it working. should we open a ticket? +**\** maitscha: yes please +**\** speaking of issues... +**\** the issue page is hard to grasp sometimes. Labels would help out alot. is that possible somehow? +**\<@fluffypony>** yes +**\<@fluffypony>** we have a small issue with that in that only collaborators can add labels +**\<@fluffypony>** and GitHub aren't adding fine-grained permissions for non-collaborators +**\** ok. and collaborator = write access right? +**\<@fluffypony>** yes +**\<@fluffypony>** so it's too much of a security risk to hand out +**\** yes. ofc +**\<@fluffypony>** my suggestion is that we have a Google Docs spreadsheet +**\<@fluffypony>** with a column for each label +**\<@fluffypony>** and then issue number -> mark the appropriate columns +**\<@fluffypony>** and I'll go and add labels +**\** personally i think we should increase the circel of caloborators by at least 1 +**\<@fluffypony>** medusa_: the entire Core Team have access +**\** it seemed to me it is hard to keep track, at least this week +**\** also for core? +**\<@fluffypony>** the issue is that the people that can manage issues != the people that can be responsible for merging code +**\** yeah. how is your work load currently fluffypony? would it make sense to have more ppl doing merges in the future? +**\<@fluffypony>** (most of the time anyway) +**\** im fine with that, just make sure those people capable can also merge to monero-core in case we have a small "merge jam" +**\<@fluffypony>** Jaquee: my work load is fine when the in-laws aren't visiting +**\** haha +**\** fluffypony: lol ok +**\<_Slack> \** I think it would be reasonable to give mooo merge access as a paid major contributor who has demonstrated talents +**\<_Slack> \** Lol FP...I know the feeling +**\<@fluffypony>** I'm trying to let PRs sit for a while so that other people review them besides me +**\** yes but sometimes if we are active that causes issues +**\** makes sense. there were a lot of code conflicts last week that could have been avoided +**\** or can cause issues +**\<@fluffypony>** medusa_: merging stuff rapidly is a bad idea, we need eyes on code +**\** \*merge conflicts +**\<+moneromooo>** I asked for PRs to stay open for a while so I have a change to see htem and review (monero repo anyway). +**\<@fluffypony>** which means small PRs, that multiple people have looked at +**\<@fluffypony>** I know it means that some PRs have to be rebased 3 times (sorry moneromooo) +**\** i agree the right balance isnt easy, im sure we get the balance again +**\<@fluffypony>** but it's better than stuff slipping in to the code +**\** normally it also wroks well +**\<+moneromooo>** No worries, it's less work than making them in the first place usually :) +**\** this week was pretty extreme in all forms +**\<@fluffypony>** medusa_: the QML stuff is pretty rough in terms of merge conflicts too +**\** maybe there can be a structure where the required reviewers are identified by the master maintainer, notified, and must sign off before the thing can be merged ? +**\<_Slack> \** I agree that issues should sit and ferment for a while, but sometimes there are hotfixes required like with fluffy blocks +**\<@fluffypony>** endogenic: too structured; has a bus factor +**\** is dev branch happening? +**\<@fluffypony>** gingeropolous: no not atm +**\** ok. security first. i'm sure it works ok most of the time. 2 last weeks was extreme. +**\<@fluffypony>** indeed +**\** but we could keep this in mind and evaluate further on? +**\** yes you stay on watch ;-) +**\** :D +**\<@fluffypony>** Jaquee: yes absolutely +**\** would the dev branch approach be a way to get around the merge "bottleneck" ? i assume its still complicated b/c of zeromq.. +**\** or are u talking about core. (i will shut up now) +**\<_Slack> \** What's the plan if something horrible happens to you FP, like going on holiday for a month without internet access? +**\** Hello guys +**\<@fluffypony>** gingeropolous: no, you still can't have fine-grained collaborators on a per-branch basis +**\** nanoakron: dead pony switch? +**\<_Slack> \** Lol. Yeah :) (also :( ) +**\** yeah +**\** :’( +**\** but you can have branch specific permissions right? +**\** not sure if it would help though. +**\** "protected branches" +**\<@fluffypony>** Jaquee: you can, and it might be worth fiddling with later on +**\** all right +**\** imo we can leave this subject for now. +**\** any more questions regarding the gui? +**\** irc logs anywhere? for people who came too late +**\** Is the gui coming in 2 days ? +**\** Jaquee: how can I start the GUI under MacOS and get the console output? +**\<@fluffypony>** proxmr: no, that's not how software development works +**\** maitscha: one sec +**\** Jaquee: that would help debugging ... +**\** maitscha: build/release/bin/monero-core.app/Contents/MacOS/monero-core +**\** any screenshots already existing? so we can see an be happy? +**\** in monero-core dir +**\** Sorry, some guy just told me on some forum, so i came to check. i appologize +**\** ah ok +**\** maitscha: doesn't it give outout when started from the command line like on linux? +**\** asdef: check reddit +**\<_Slack> \** No worries. +**\** I always started it with the finder +**\** Please don't interrupt the dev meeting +**\** iDunk: yes. but it's not that easy to find the binary +**\** it's in the .app package +**\** ok +**\** Jaquee: works, thanks +**\** yw +**\** all right. +**\** more gui related? +**\<_Slack> \** None here +**\** there are at least 2 people who would like to make a style guide +**\<_Slack> \** That's a good idea +**\** should this be coordinated? +**\** i think the best place to discuss specific stuff is either on github or here in the channel +**\** yes. that would be good. not sure how. but i can ask them to get in contact with each other to start +**\** Can we discuss an issue freeze for the beta release? I think we have all the features we need for an "MVP" and there doesnt seem to be any major outstanding bugs. +**\** or at least a place where people can post design/ux-related improvements? +**\<@fluffypony>** github +**\** Confused ... ? Quote: \<@fluffypony> so it will take a couple of days to wrap up a point release too. Does that not relate to the GUI being released? +**\<_Slack>** **\** Yes, styleguide, one was me. I’m still able to help. +**\<@fluffypony>** Guest5849: a beta, yes +**\** vertp: the features are basically freezed, we just change what we think is worth changing (and the treshold for that goes up each day) +**\<@fluffypony>** vertp: "freezing" things doesn't really work for a fluid open-source project +**\<_Slack> \** Where's the best place to coordinate a style guide? A new Git repo or a wiki? +**\** always considering risk reward ofc +**\<@fluffypony>** people open issues, they get fixed, eventually you hit enough milestones / new features for a new release +**\** I mean freeze in the sense that of course you allow new issues to be open, but the work is prioritized based on existing issues and bugs +**\<@fluffypony>** vertp: can't really force someone to work on anything +**\** vertp: you can't stop people from working on features ;) +**\<@fluffypony>** so if people want to work on new features instead of tackling bugs that's their prerogative +**\** I agree, I mean more for illya and jaquee +**\** generally an 'issue freeze' is a bad idea +**\<@fluffypony>** can't force them either ;) +**\** vertp: we have to always allow people opening issues. their feedback is very valuable +**\** a feature freeze is an entirely different thing and is already somewhat implemented +**\** I agree medusa_ +**\** vertp: me and ilya are more or less frozen for the moment. :P +**\<@fluffypony>** yes +**\** as in agreed on that current version can be released as beta +**\<_Slack> \** Vertp: we just follow a simple alpha -> beta -> release methodology, keeping in mind that even point releases are beta software under constant development +**\** Awesome, thats what I was going for Jaquee +**\** I just feel that its stable enough at this point to justify a beta without doing any additional feature dev. Thats what I meant by issue freeze +**\** Which I think we all agree on +**\** yes +**\** great! +**\** yes wa try to be very pragmatic +**\<_Slack> \** This has side tracked us slightly. Where's the best place to coordinate a style document? +• moneromooo: eyes this suspiciously +**\<@fluffypony>** Github has this new thing called Projects +**\** wat +**\** nanoakron. not sure. github best place for the moment +**\<@fluffypony>** aI want to play with it and see if it's suitable for that +**\<_Slack> \** Cool +**\** fluffypony: sounds interesting. +**\** tfi_charmers: can you sync with that other ux guy? +**\<_Slack> \** Does sound interesting +**\** so you don't end up working on the same issues +**\<@fluffypony>** ok - can we call this meeting done? +**\<_Slack>** **\** @jaquee can do. +**\** great +**\** fluffypony: yes +**\<@fluffypony>** ok tks +**\<+moneromooo>** Just one thing before: when does someone else do the builds ? +**\<_Slack> \** I was going to raise the issue of databases if hyc, fp and mooo are in the same room +**\** hyc is roaming belfast +**\<_Slack> \** A veritable vipers nest of opinions ;) +**\** anyway, i'm with fluffypony and moneromooo on the db issue +**\<_Slack> \** Why do we need the ability to iterate and test the database back end in production code? +**\<_Slack> \** And aren't we effectively overruling our resident database expert, hyc? +• moneromooo: facepalms +**\** ^ +**\** where's this discussion? i totally missed this one. not that I can do anything. +**\<_Slack> \** It's a PR of mine +**\<_Slack> \** Mooo, why the facepalm? When or where are we going to need to change the database away from LMDB in the future in such a way that we need the selection code? +**\<_Slack> \** As it stands we're shipping code thats never run, with requirements that are never used. +**\<+moneromooo>** Because being an expert in databases does not extend to having an expert opinion on whether a selection system in a particular project is best or not. +**\<+moneromooo>** And not knowing the particulars of a future db implementation does not by itself imply any groundworks should be dismantled at once. +**\** and the prebuild binaries are all LMDB, right? so its not like anything's being shipped... +**\** \*prebuilt +**\<+moneromooo>** The current ones all are, yes. +**\** fluffyblocks still LMDB too right? +**\<+moneromooo>** Unrelated. +**\** ok sorry +**\<+moneromooo>** I mean, this was an obvious appeal to authority, in a context where the authority is only tangential. +**\<+moneromooo>** I find it counterproductive to remove a useful thing, if its removal will make it a lot easier to break the ability to add another db. It's not like it's a lot of code I think. +**\** agreed +**\<+moneromooo>** There was a all RAM db being worked on, though I'm not sure it still is. +**\<_Slack> \** So has the compiler been smart enough to strip the selection stuff or is there still bloat and overhead that could be trimmed? +**\<_Slack> \** Appeal to authority is only a fallacy when the authority is not relevant to the issue at hand +**\<@ArticMine>** There was at one point the idea that Monero could use different databases in the future. +**\<+moneromooo>** You actually might make a good argument by removing it all and see whether performance figures support you bloat claim. +**\<_Slack> \** I'll try that +**\<+moneromooo>** Now, the threshold where an improvement becomes larger than the loss of generality is pretty subjective too. +**\<_Slack> \** As for the PR - would you reject it for stripping out the Berkeley DB selection in CMakeLists.txt, or is that acceptable because we're not going back to BDB? +**\** is it just for compiling performance? +**\<+moneromooo>** IIRC, I said keep the selcetion code, just remove the bdb option. +**\<_Slack> \** I'm happy to keep the selection code in the main body, but are you happy with the structure of the current PR wrt stripping BDB from CMakelists.txt? There wasn't a selector in there afaik +**\<+moneromooo>** Basically, you should be able to add another db by duplicating the lmdb bits. Anything that's shared needs to stay for this to be useful. +**\<_Slack> \** I'm happy to leave the selector alone in the main code +**\<+moneromooo>** In the details ? I'll have to go read the code to know for sure. +**\<+moneromooo>** And I'm busy debugging some cold signing stuff now, so that'll be later. +**\<_Slack> \** Understood. Please have a look at the PR and what's been stripped wrt BDB when you can. If that's still to much then I'll close and amend. By the time we get to using additional databases the CMakeLists file will have been changed many more times anyway. +**\<_Slack> \** And the final thing I wanted to ask today was whether FP could keep killing cold issues ;) +**\<_Slack> \** Tis all from me \ No newline at end of file diff --git a/_posts/2016-11-27-logs-for-the-Kovri-dev-meeting-held-on-2016-11-27.md b/_posts/2016-11-27-logs-for-the-Kovri-dev-meeting-held-on-2016-11-27.md new file mode 100644 index 00000000..02b000d9 --- /dev/null +++ b/_posts/2016-11-27-logs-for-the-Kovri-dev-meeting-held-on-2016-11-27.md @@ -0,0 +1,265 @@ +--- +layout: post +title: Logs for the Kovri Dev Meeting Held on 2016-11-27 +summary: Brief review of what has been completed since last meeting, Alpha release, and code & open tickets discussion +tags: [dev diaries, i2p, crypto] +author: dEBRUYNE / fluffypony +--- + +*November 27th, 2016* + +### Logs + +**\ {-fluffypony}** ok anonimal +**\ {-fluffypony}** Kovri meeting start, 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. Status of alpha release preparations - https://github.com/monero-project/kovri/issues?utf8=%E2%9C%93&q=is%3Aopen%20is%3Aissue%20milestone%3A0.1.0-alpha%20 +**\ {-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]** Hi +**\ {-meeting-bot} [anonimal]** 1. +**\ {-fluffypony}** hi +**\ {-guzzi}** hi +**\ {-fluffypony}** asl? +**\** Hi +**\ {-iDunk}** hi +**\ {-olark}** Greetings +**\** Hi +**\ {-meeting-bot} [anonimal]** Hi fluffypony guzzi olark iDunk ArticMine moneromooo +**\ {-meeting-bot} [anonimal]** EinMByte is idling as are the others, afaict. +**\ {-meeting-bot} [anonimal]** 2. Brief review of what's been completed since the previous meeting +**\** late greetings. watching. +**\ {-meeting-bot} [anonimal]** I'll keep it generic: bug fixes (many were difficult bugs) + refactoring, mentoring, and research. +**\ {-meeting-bot} [anonimal]** *Poof!* done. +**\ {-meeting-bot} [anonimal]** Anything else on 2? :) +**\ {-fluffypony}** can I add to 2? +**\ {-meeting-bot} [anonimal]** git log and github are available for details. +**\ {-meeting-bot} [anonimal]** Of course fluffypony +**\ {-fluffypony}** I'd like to congratulate anonimal on completing his first milestone, even if he won't admit to it yet :-P +**\ {-fluffypony}** first full-time FFS "employee", first milestone :) +**\ {-meeting-bot} [anonimal]** Grr! Well, thank you fluffypony. +**\ {-guzzi}** and thanks for mentoring. +**\ {-fluffypony}** and we didn't even need to blockchain it! +**\ {-olark}** Good work. ;) +**\ {-meeting-bot} [anonimal]** Because of the large amount of non-code work, I hadn't felt comfortable with a payout yet. I'll get to that this week. +**\ {-fluffypony}** I think everyone here will attest to the amount of work you do +**\ {-guzzi}** no doubt. +**\ {-meeting-bot} [anonimal]** No problem guzzi, thank *you* for your great progress. +**\ {-fluffypony}** "anonimal made me the man I am today" - fluffypony, 2016 +**\ {-olark}** He's called anonimal for a reason haha +**\ {-fluffypony}** olark: coupled with my quote I think that's one for the history books +**\ {-meeting-bot} [anonimal]** lol oh you guys, thanks for acknowledgements. I'm glad to be here with you all. +**\ {-meeting-bot} [anonimal]** I'd love to dwell on the work accomplished over the past two weeks but I think we can move on, any objections? +**\ {-guzzi}** onward +**\ {-fluffypony}** let's move on +**\ {-meeting-bot} [anonimal]** 3. Status of alpha release preparations - https://github.com/monero-project/kovri/issues?utf8=%E2%9C%93&q=is%3Aopen%20is%3Aissue%20milestone%3A0.1.0-alpha%20 +**\ {-meeting-bot} \* anonimal** clicks +**\ {-meeting-bot} [anonimal]** Ok, don't be alarmed, but it's actually not a lot if you look carefully. +**\ {-meeting-bot} [anonimal]** Some of these can even be moved to next milestone if needed. +**\ {-meeting-bot} [anonimal]** fluffypony: can you give a status on 33c3 and your thoughts on a release (like we spoke about earlier)? +**\ {-fluffypony}** yes +**\ {-fluffypony}** so our original plan was to co-host an assembly with i2p at 33C3 +**\ {-fluffypony}** basically hosting an i2p + Monero table +**\ {-fluffypony}** and then have the Kovri alpha ready by then +**\ {-fluffypony}** unfortunately this year's congress ticketing setup has been a mess +**\ {-fluffypony}** through no fault of their own, this is the most popular CCC ever +**\ {-fluffypony}** we tried to book 10+ tickets at all 3 of the public booking dates +**\ {-fluffypony}** and got nothing +**\ {-meeting-bot} [anonimal]** Wow, that's insane. +**\ {-fluffypony}** I managed to get tickets for myself and othe, after the fact +**\ {-fluffypony}** but it's not enough to man a table - we'd have needed 8+ community members for htat +**\ {-fluffypony}** that +**\ {-fluffypony}** in view of the foregoing, we're no longer obligated to hit our alpha release date +**\ {-meeting-bot} [anonimal]** Ok, well that's great to hear you at least got two tickets. +**\ {-fluffypony}** this doesn't mean we won't stick to it, but it means we can choose how we want to plan it +**\ {-meeting-bot} [anonimal]** Ok, well here are my thoughts on the reality of the situation, I'll try to choose my words wisely: +**\ {-meeting-bot} [Jake__]** Is their any news on the GUI beta binaries. +**\ {-meeting-bot} [fluffypony]** Jake__: this is the Kovri meeting +**\ {-meeting-bot} [fluffypony]** you can ask later +**\ {-meeting-bot} [Jake__]** Nvm +**\ {-meeting-bot} [Jake__]** My mistake +**\ {-meeting-bot} [anonimal]** even with all milestone issues resolved, the release wouldn't be a spectacular one, and frankly may have more negative consequences than positive. +**\ {-meeting-bot} [anonimal]** I mean, sure, I can most likely get everything done in time, but is it really worth it? +**\ {-fluffypony}** anonimal: that's fair +**\ {-meeting-bot} [anonimal]** The packaging aspect alone will be 'fun' to deal with, *especially* come upgrade time. +**\ {-fluffypony}** are we auto-upgrading ala Java i2p? +**\ {-meeting-bot} [anonimal]** And really, an auto-updater would be great on that front - and that's not terribly hard to do now that more work has been done elsewhere. +**\ {-meeting-bot} [anonimal]** We wouldn't if we released this month unless I dropped other higher priority issues. +**\ {-meeting-bot} \* anonimal** thinking +**\ {-fluffypony}** look +**\ {-fluffypony}** zzz2 will attest to the fact that part of i2p's network stability is due to the auto-updater +**\ {-fluffypony}** so let's not rush something out that doesn't have that +**\** Do I understand code that will fetch more code and run it on the user's machine ? Unprompted ? +**\** Or merely tell the user there's an update to install at their earliest convenience ? +**\ {-fluffypony}** moneromooo: it's opt-out, yes +**\** That;s not nice. +**\ {-fluffypony}** moneromooo: you could do a decaying prompt +**\** What is this ? +**\ {-fluffypony}** prompt the user, if after 15 days they haven't installed it, then install it for them +**\ {-meeting-bot} [anonimal]** The current UI does not provide any useful control to an end-user. +**\** I suppose that's less nasty. +**\ {-fluffypony}** moneromooo: there's just been a spate of bannings on the network, of old clients that aren't updated +**\ {-fluffypony}** if there's data leakage on older clients it can compromise newer ones +**\ {-fluffypony}** so it's not something to be taken lightly +**\ {-meeting-bot} [anonimal]** So, we could fix that first and then focus on release imho. Really who benefits from a release? Will it be developers? Will developers suddenly become more interested in kovri? Or is it purely for the end-user's benefit? +**\ {-fluffypony}** end users +**\ {-fluffypony}** do we even have a stable API for devs? +**\ {-guzzi}** realease implies end users imo. +**\ {-meeting-bot} [anonimal]** Nope, more router issues to fix first. +**\ {-fluffypony}** ok so then end users :) +**\ {-meeting-bot} [anonimal]** I agree with guzzi, but I still like the idea of feeling accomplished with a release by the end of the year. +**\ {-meeting-bot} [anonimal]** I guess anything called "release" will hold a certain weight, +**\ {-meeting-bot} [anonimal]** Maybe we can compromise, find a middle-ground somehow. +**\ {-fluffypony}** true +**\ {-meeting-bot} [anonimal]** I'd like to work with pigeons on nightly releases, that could be a start. +**\ {-meeting-bot} [anonimal]** I don't think we'll have the website done in time (will we?) +**\ {-meeting-bot} [anonimal]** As for "release", I can simply throw the bundle together in nightly releases. +**\ {-meeting-bot} [anonimal]** I think what people really want is something that "feels" released. +**\ {-meeting-bot} [anonimal]** The title means nothing really. +**\ {-fluffypony}** we can couple nightlies with the Monero nightlies +**\ {-meeting-bot} [anonimal]** Sounds fair. +**\ {-fluffypony}** on the list of alpha issues +**\ {-fluffypony}** we've made progress on the Zoho setup +**\ {-fluffypony}** it's been a bit of a PITA, but pigeons has figured most of it out +**\ {-fluffypony}** we'll be moving getmonero.org over in the next week or so, and then we can do Kovri emails too +**\ {-meeting-bot} [anonimal]** Ok, sounds good. +**\ {-meeting-bot} [anonimal]** So, nightly releases for kovri would be slightly different that monero because we have to bundle certificates and other things along with a static binary. +**\ {-meeting-bot} [pigeons]** I beleive you said currently the make system doesnt have an option yet for a static build, right? +**\ {-meeting-bot} [anonimal]** I could consider it a fair compromise if, instead of both nightly release and official alpha release, to stick focus more on ensuring reliable nightly releases (which would also give me more time to work on more important issues). +**\ {-meeting-bot} [MEATPLOW]** im here for the free food +**\ {-meeting-bot} [anonimal]** pigeons: for kovri? No, we can build static. +**\ {-meeting-bot} [fluffypony]** MEATPLOW: we have snacks and beer after the meetings +**\ {-meeting-bot} [pigeons]** wow i thought thats why you told me to remove the build uploads +**\ {-iDunk}** win builds are not realy static +**\ {-meeting-bot} [anonimal]** pigeons: no, I said we need to bundle files or else the static build is useless (people will download, run it, and it won't get to reseed). +**\ {-meeting-bot} [pigeons]** OK +**\ {-meeting-bot} [anonimal]** iDunk: if there are windows static issues then that would be another thing we could focus on for a solid nightly build +**\ {-iDunk}** win64 is not static at all, win32 looks static but still requires dlls from msys2 +**\ {-meeting-bot} [anonimal]** fluffypony: so final verdict for alpha release: focus on getting nightly releases ready in place of a single release? +**\ {-fluffypony}** yes +**\ {-meeting-bot} [anonimal]** (at least for this month) +**\ {-fluffypony}** make pigeons work +**\ {-meeting-bot} [anonimal]** lol +**\ {-fluffypony}** :-P +**\ {-iDunk}** :) +**\ {-meeting-bot} [anonimal]** Ok, how does that sound to everyone? Yay? Nay? +**\ {-iDunk}** Yay +**\** Sounds good to this member of the peanut gallery +**\ {-olark}** Nightly builds are a good compromise imo. +**\ {-olark}** Yay +**\ {-meeting-bot} [anonimal]** Awesome. guzzi, any thoughts? +**\ {-guzzi}** sounds awesome +**\ {-meeting-bot} [anonimal]** He may be AFK. +**\ {-guzzi}** excited +**\ {-meeting-bot} [anonimal]** Oh there you are, ok great. +**\ {-guzzi}** this will be motivating +**\ {-meeting-bot} [anonimal]** Excellent! Moving on, +**\ {-meeting-bot} [anonimal]** 4. Code + ticket discussion / Q & A +**\ {-meeting-bot} [anonimal]** Focusing on those milestone issues, +**\ {-meeting-bot} [anonimal]** fluffypony: I've seen someone pop into #monero-dev from time to time offering webdev, did anything come of that? +**\ {-fluffypony}** no, they're mostly put off when they get told they can't use Javascript +**\ {-fluffypony}** :-P +**\ {-meeting-bot} [anonimal]** lol +**\ {-meeting-bot} [anonimal]** Ok, so once zoho is resolved then the site (server) can come online? +**\ {-meeting-bot} [anonimal]** And the rest is a matter of code/content? +**\ {-fluffypony}** yes +**\ {-fluffypony}** well two things actually +**\ {-fluffypony}** Zoho is for email +**\ {-fluffypony}** the new hosting infrastructure is for site +**\ {-fluffypony}** both are running parralel-ish +**\ {-fluffypony}** parallel-ish +**\ {-meeting-bot} [anonimal]** https://github.com/monero-project/kovri/issues/46#issuecomment-242990742 +**\ {-meeting-bot} [vertp]** Is there a new site going up to replace getmonero? +**\ {-meeting-bot} [anonimal]** lol, time will fly. +**\ {-meeting-bot} [vertp]** Oh, kovri. sorry +**\ {-meeting-bot} [anonimal]** vertp: good question, fluffypony is getmonero getting work done too? +**\ {-fluffypony}** no +**\ {-fluffypony}** same deal +**\ {-fluffypony}** every time someone says "WE MUST REDESIGN THE WEBSITE" +**\ {-fluffypony}** then I go "ok, make sure to design the forum to match, and you must have non-JS fallbacks" +**\ {-fluffypony}** and they slink off into the distance +**\ {-meeting-bot} [pero]** website is fine imo +**\ {-meeting-bot} [anonimal]** hahaha +**\ {-meeting-bot} [vertp]** I think getmonero is perfectly fine as is for the record, just was wondering what "this" site was in reference to +**\ {-meeting-bot} [ferretinjapan]** :) +**\ {-fluffypony}** I'm going to write a garbage collector daemon called Waste +**\ {-fluffypony}** and the binary will be wasted +**\ {-meeting-bot} [anonimal]** muh js +**\ {-meeting-bot} [pero]** it has a refreshing aura of authenticity +**\ {-fluffypony}** and the website will be getwasted.org +**\ {-meeting-bot} [hyc]** lol +**\ {-meeting-bot} [MrWatcher]** he +**\ {-meeting-bot} \* anonimal** lol, hears drum rimshot +**\** So... next time someone asks about the website, I've got a ready made answer: "slink off" +**\ {-fluffypony}** "slink you too, buddy!" +**\ {-meeting-bot} [anonimal]** I think the rest of the issues speak for themselves. One question though, +**\ {-meeting-bot} [anonimal]** Can anyone reproduce #434 on their armv7 device? +**\ {-fluffypony}** the only arm device I have access to right now is the one under my sleeve device +**\ {-fluffypony}** but I'll try it when I'm back home +**\ {-guzzi}** +**\ {-meeting-bot} [anonimal]** lol, more drum rimshots, fluffypony is on a roll. +**\ {-meeting-bot} [anonimal]** guzzi olark: anything on point 4 "Code + ticket discussion / Q & A"? +**\ {-olark}** All good ;) +**\ {-meeting-bot} [anonimal]** guzzi is probably at the beach again. +**\ {-olark}** Slurping up a margarita. +**\ {-meeting-bot} [anonimal]** hah +**\ {-meeting-bot} [anonimal]** Ok, moving on. 5. Any additional meeting items +**\ {-fluffypony}** the glamorous life of a Kovri contributor +**\ {-fluffypony}** nothing from my side +**\ {-fluffypony}** * eyes his beer +**\ {-meeting-bot} [_Slack] \** Beer? Sacrilege for a South African…although I hear there’s a good craft scene developing. +**\ {-meeting-bot} [anonimal]** Quite glamorous indeed. +**\** I'll mention again that I reaaally hate software that will take it upon itself to download/run stuff. +**\ {-meeting-bot} [anonimal]** Nothing additional from me. +**\ {-fluffypony}** moneromooo I know, but think about the average Kovri user +**\ {-fluffypony}** (in the future, not now) +**\** The average kovri user may well be prompted. +**\ {-meeting-bot} [taushet]** moneromooo, so no 30-day trial from McAfee with the Kovri binaries then? +**\ {-fluffypony}** LOL +**\ {-meeting-bot} [iDunk]** LOL +**\ {-olark}** Now that fluffypony brang up using TweetNaCl in the monero meeting. Are there any boundaries for Kovri using TweetNaCl functions where possible? +**\ {-fluffypony}** and a personal introductory video from McAfee himself ? +**\ {-olark}** I just have recently been fascinated with TweetNaCl, Salsa20 etc that it seems Kovri could benefit from some of those functions. +**\ {-olark}** A compact crypto library for a compact i2p router. Am I right? ;D +**\ {-meeting-bot} [anonimal]** moneromooo: me too. I think as long as it's optional we should be ok. +**\** Excellent. So opt-in :) +**\** (and banned until upgraded is fine as a protection) +**\ {-olark}** Just spitballing anyway. +**\ {-guzzi}** all good for me on #4. i am learning a ton. as fast as I am able to. +**\ {-fluffypony}** olark: yeah definitely +**\ {-meeting-bot} [anonimal]** cryptopp has salsa20. +**\ {-fluffypony}** I think the important thing is identifying where TweetNaCl's correctness is useful +**\ {-fluffypony}** because it sacrifices performance for verifiable correctness +**\ {-olark}** Right. +**\ {-olark}** Salsa20 is faster than AES256, but ya in general because of the conciseness of the code it is not as effecient as it could be. Favouring it being easy to audit. +**\ {-olark}** etc +**\ {-meeting-bot} [anonimal]** I'd want to review before jumping on the tweenacl train. +**\ {-meeting-bot} [anonimal]** If it can't replace supercop then I don't see much of a point. +**\ {-meeting-bot} [anonimal]** *If*. +**\ {-olark}** Taking advantage of TweetNaCl's verifiable correctness I think is more valuable then the slight downside of mildly less effecient operations. +**\ {-olark}** TweetNaCl has ed25519 signing operations. +**\ {-olark}** Is the most recent paper afaik +**\ {-olark}** https://tweetnacl.cr.yp.to/tweetnacl-20140917.pdf +**\ {-fluffypony}** TweetNaCl is the successor to SUPERCOP in many ways +**\ {-meeting-bot} [anonimal]** Release dates not being one of them if latest tweetnacl was 2014. +**\ {-fluffypony}** they're not adding functions +**\ {-fluffypony}** so there aren't new releases except to fix bugs +**\ {-olark}** It is the original 25 NaCl functions. +**\ {-fluffypony}** and given its conciseness there haven't been many of those +**\ {-meeting-bot} [anonimal]** Needs more research on our end. We also use other functions from supercop. +**\ {-meeting-bot} [anonimal]** 18:00, out of time, I'll be around after the meeting. +**\ {-fluffypony}** kk +**\ {-meeting-bot} [anonimal]** 6. Confirm next meeting date/time +**\ {-fluffypony}** meeting bot going down +**\ {-olark}** I agree. TweetNaCl is definitely something to consider. Will take more consideration, but I think could be very useful for both Kovri and Monero. +**\ {-meeting-bot} [anonimal]** Same time, two weeks? +**\ {-fluffypony}** oh after 6 +**\ {-olark}** Sounds good. +**\ {-meeting-bot} [anonimal]** fluffypony: 17:00 ok? Same time? +**\ {-guzzi}** ok with me +**\ {-fluffypony}** ok +**\ {-fluffypony}** done and dusted +**\ {-olark}** Good talk everyone :D +**\ {-fluffypony}** meeting bot off \ No newline at end of file diff --git a/_posts/2016-11-27-overview-and-logs-for-the-dev-meeting-held-on-2016-11-27.md b/_posts/2016-11-27-overview-and-logs-for-the-dev-meeting-held-on-2016-11-27.md new file mode 100644 index 00000000..3bcf9f26 --- /dev/null +++ b/_posts/2016-11-27-overview-and-logs-for-the-dev-meeting-held-on-2016-11-27.md @@ -0,0 +1,248 @@ +--- +layout: post +title: Overview and Logs for the Dev Meeting Held on 2016-11-27 +summary: Brief update on next point release, Ring CT, 0MQ (and authentication), GUI, and crypto libs +tags: [dev diaries, core, crypto, 0mq] +author: dEBRUYNE / fluffypony +--- + +*November 27th, 2016* + +### Overview + +An overview [can be found on Hello Monero](https://hellomonero.com/article/monero-dev-meeting-note-highlights-and-transcript-2016-11-27). + +### Logs + +**\** ugh, I wanted to stay up for the dev meeting, but I just...can't. +**\** I'll put an update here in a minute or two though, someone can paste it for me perhaps. +**\** tks tewinget +**\** so the daemon and wallet talk via zmq now (yay!) +**\** both have the requisite command line parameters. I added new ones for the daemon since I'm leaving the old RPC in place for now, but that's specifics that can change on a whim, of course. +**\** (parameters like bind port/address and such) +**\** don't have any rpc security features like user agent and what-not put in yet, that'll come with time. +**\** modifications to wallet to use new rpc are "complete", but not working yet. needs iteration. was working on that now, but I'm fucking exhausted, hence the not staying up for the meeting. +**\** user-agent was a quick fix anyway. It should not be merged in 0MQ. Proper auth should be done instead. +**\** once I get *that* ironed out, I'll put together some simple documentation on what the rpc calls look like +**\** And ty and good night :) +**\** my python script is a bit broken, but I updated one of the functions to work +**\** (because I changed it to be JSON-RPC 2.0 compliant) +**\** I'll pastebin that and paste a link here in a sec +**\** hard_fork_info() is the one that uses the jsonrpc format, others can be easily modified to comply +**\** err...that more or less sums things up, I think. any qvestions? +**\** https://paste.fedoraproject.org/490609/57957148/ +**\** need python's zmq libs, of course, and zmq version 4ish should suffice as far as OS libs for building +**\** I'll stay up a few more minutes in case anyone has any questions, but I do need to go and sleep. +**\** yo +**\** welcome, welcome +**\** ok so +**\** since we last met +**\** hi +**\** there have been quite a few merge sessions +**\** or merge sesh's as I like to call them +**\** coz, you know, when you've been a maintainer as long as I have, you learn to give things little names otherwise you'll go mad +**\** lol +**\** there have been some major reworks to the threading model, courtesy of vtnerd +**\** who also split part of monero-wallet-cli off into monero-wallet-rpc +**\** (which we had previously done on the old dev branch, as you may recall) +**\** gingeropolous started pushing more code than a troll dev should, so he's kinda progressed beyond that +**\** moneromooo shot down bug after bug +**\** kenshi84 started working on one-time addresses without using the integrated address format we currently have +**\** @NanoAkron also fixed some errant armv8 things +**\** and then on the Monero Core side tons of fixes, small and large, primarily by moneromooo and Jaquee +**\** abrkn also had their first PR merged to Monero Core, so welcome to a new contributor +**\** xmr-eric also had a pair of PRs, so he's almost at 5 PRs which is excellent +**\** as it stands right now there is a weird segfault occurring occasionally, at least on macOS +**\** and possibly other operating systems +**\** this is a blocker to the next tagged release +**\** ubuntu as well^ +**\** also running LMDB in "fast" mode may be unsuitable for Windows - hyc, what are your thoughts on that? +**\** debian also ^ +**\** still gathering data +**\** asked that user what happened oin his prior run, whether PC crashed etc +**\** ok - so that's a possible blocker to the tagged release +**\** and then in new, relevant info, Shen has begun a thorough review of the RingCT implementation +**\** and already there are a couple of nigglies, some carried across from his rough implementation +**\** so this means we will have to have a mandatory tagged release out before the Jan hard fork +**\** yay! +**\** given that there are 2-3 blockers to the tagged release, and given its nature, we will likely release it alongside the GUI +**\** so that we get a fair degree of pre-fork adoption +**\** That makes a lot of sense +**\** in the meantime +**\** pigeons is setting up links to built binaries on the buildbot infrastructure +**\** and I'll set forwarders up or something for those +**\** so that people will be able to grab nightlies of both Monero and Monero Core +**\** this is not a small amount of work, but it should make it a LOT easier for non-developers to test +**\** and we need ongoing functional testing, over and above test suite regressions +**\** speaking of which; the next step on that is to run and publish performance test data on a per-PR basis +**\** so we can spot performance improvements / regressions +**\** last thing that I want to open the floor to +**\** is issue 1271 +**\** https://github.com/monero-project/monero/issues/1271 +**\** opened by paragonie-scott +**\** currently we hit /dev/urandom for a random seed, basically +**\** and then use the Keccak sponge function for random numbers thereafter +**\** a userland PRNG is not ideal, but this doesn't really represent an attack surface that an attacker can take advantage of right now +**\** to alleviate this we need to pick a crypto lib, and slowly start using it in various parts of the application +**\** refactoring out the in-source implementations we currently have for most things +**\** the only two really worth considering are CryptoC++ and libsodium +**\** if anonimal is around, maybe he can tell us why Kovri settled on cryptocpp +**\ {-olark}** What about TweetNaCl? +**\** oh yes +**\** so +**\** TweetNaCl is great for the core crypto bits where the most important thing is getting it verifiably right +**\** TweetNaCl's simplicity lends itself towards formal verification +**\** a larger library like libsodium or cryptocpp will NEVER be formally verified +**\** I'm not convinced of the original argument. userland PRNGs are not a liability +**\** and haveged itself was recently recommended on crypto list http://www.metzdowd.com/pipermail/cryptography/2016-November/030930.html +**\** hyc: I agree, but there's also nothing wrong with just hitting /dev/urandom each time +**\ {-anonimal}** Since there is a heavy reliance on crypto, and most of the implementation was already written with crypto++ in mind (though it is more 'abstracted' now), any swap-out of crypto would *not* be worth the benefits gained. +**\** haveged would still be of benefit there as it affects the chain from /dev/random -> /dev/urandom +**\** There's a tendency for security researchers to hype every small thing too, fwiw. +**\** hitting /dev/urandom every time leaves an obvious footprint. I suppose it's more of an issue for closed-source s/w +**\** hyc: yeah - for Monero a root user would be able to trivially trap for any obfuscation we add +**\** IME, reverse engineering closed source, it's harder to break a PRNG n a binary with no symbols and no syscalls +**\** but yeah, not relevant for open source +**\** Yes but we are not implementing DRM here +**\ {-anonimal}** * was responding to fluffypony's ping for kovri, what wasn't an endorsement or argument for/against anything for monero +**\ {-anonimal}** s/what/that/ +**\** anonimal: sure, but it's advantageous if Kovri and Monero use the same lib +**\** less code to maintain, yeah +**\** bigger impact if a flaw is found +**\** (for functions TweetNaCl doesn't have, or where performance greater than TweetNaCl's is required) +**\** sure, but we're not protecting ourselves by using libsodium vs. cryptocpp +**\** unless we know in advance that one will have an implementation flawthat the other won't +**\** is a C++ dep an issue going into the future with talk of porting to pure C? +**\ {-anonimal}** Can someone give a tl;dr of all crypto schemes required by monero (aside from ed25519, keccak, and any PRNG concern)? +**\** blake256, chacha8, groestl, skein, jh, keccak +**\** cryptonight uses keccak, groestl, +**\** yeah what fluffy said +**\** lol +**\** There's all the stuff in crypto-ops.c +**\** moneromooo: that's covered by TweetNaCl +**\** ie. covered by SUPERCOP +**\** I presume we're gonna support TLS on rpc connections too? +**\** Do you mean that it'd be still used if we were to change to cryptocpp ? +**\** hyc: kinda - vtnerd is working on it atm +**\** we're going to have easy instructions on TLS wrappers, and then authentication on the RPC layer +**\** moneromooo: yes +**\** Why change, then ? +**\** If it's only part change, I mean. +**\** \ I wanted to mention that I would recommend _not_ adding SSL support directly to the codebase. I think using SSH tunneling or a SSL proxy like hitch would be better. I can write a guide and some basic strategies if you have someone in particular that wants the rpc stream encrypted +**\** \ one of the advantages is not having to configure all of the keys, etc. I'm thinking about adding a warning that can only be suppressed with a CLI option or user-input if someone binds to a non-loopback IP +**\ {-anonimal}** I used that argument for kovri last year, it was quickly shot down by str4d and zzz. +**\** https://github.com/varnish/hitch +**\** moneromooo: to get away from the in-source implementations that are mostly obscure or not massively common +**\** i2p-relay: do you recall the arguments against doing it that way? +**\ {-anonimal}** Expecting users to use a guide or 3rd party is probably not a good idea. +**\ {-anonimal}** vtnerd: there may be a log pasted in a closed github issue +**\** I would just use stunnel, it's already proven and pretty simple +**\ {-anonimal}** Basically what I just said. +**\** It's a lot easier to do the wrong thing thogh. +**\** I think if we can detect and warn users that their behaviour is unsafe, but here's what they can do to fix it, that's enough +**\** The same users that asked a question that I had answers with a red message when bitmonerod stopped, but they had somehow missed ? :) +**\ {-anonimal}** openssl is a dependency for kovri anyway, implementing tls/ssl sockets is trivial. Are we talking more about than sockets though? +**\** if SSL support is integrated public keys still have to be generated, stored, and then copied remotely ... so its still frustrating +**\** moneromooo: what if it won't start when bound to an external IP, unless you pass a flag to override it? +**\** that's life. we can write a certificate generator/mini-CA +**\** Maybe. I don't know near enough about this to have a useful opinion anyway. +**\** I already have one I wrote for OpenLDAP back in 2000 (mini-CA) +**\** CA key still has to be distributed ... +**\** CA key ? +**\** CA cert, not key +**\ {-anonimal}** Certs for whom? +**\** its still just a public key +**\ {-anonimal}** Is there an open issue for this with discussion so I catch up? +**\** my understanding is that one reason bitcoin is removing integrated tls support from their rpc server is to discourage people from exposing that surface to the internet when they don't have the resources to give it the same review as p2p/etc interfaces +**\** on a personal node, you only care that your personal clients can connect. you generate your own CA, a server cert for your node, and a client cert for your wallets. +**\** but for monero, there is already remote daemon support so perhaps not relevant +**\ {-anonimal}** Oh, personal nodes, ok thanks hyc. +**\** and you use full cert verification in both directions, to prevent any foreign apps from connecting. +**\** hmmmm +**\** which can be done with SSH easily too +**\ {-anonimal}** Not everyone has access to ssh nor know how to use ssh. +**\** yeah, if you're going to keep a long running ssh tunnel alive +**\** I haven't seen an easy way to "auto-configure" because the clients still need to know server pub key +**\** node and client need a copy of the CA cert +**\** I guess blindly accepting the cert is better ? +**\** with TLS clients can just approve a fingerprint +**\** then it's a visual comparison to a self-signed cert's fingerprint +**\** tofu seems acceptable to people, despite its weaknesses +**\** ugh. +**\** i know +**\** if you're going to document best practice for TLS, don't document shortcuts. that's garbage. +**\** we're bikeshedding - we need to put a peg in the sand and make a decision, even if it's the wrong decision +**\** I'm in favour of not building things and ripping them out later +**\** but rather not having them until there is an overwhelming demand for it +**\** erf +**\** yeah, fine. no built-in TLS support for now +**\** I'd be fine with that plus the --force-plaintext-bind-to-non-local-ip +**\** we'll use the fail-on-start method if there are RPC bindings to non-loopback addresses, and we'll have a guide that documents hitch and stunnel +**\** I already have a patch ready that forces a user to confirm if the rpc-bind-ip is not loopback +**\** hyes +**\** vtnerd: can we make it fail-unless-overridden-by-flag? +**\** we're trying to avoid interaction on the daemon +**\** the patch has both. Without the flag set it prompts the user +**\** --confirm-external-bind +**\** Maybe test if stdin is tty, fail if not. +**\** Oh, wait, windows. Nevermind. +**\** sounds like just fail without the flag is simpler +**\** definitely. will do then +**\** that is_yes patch is less useful now, but I guess it did cleanup simpler_wallet.cpp some +**\** Next thing. Did shen give an idea when he might have a first pass of things that need fixing ? +**\** I have time to fix, and we're pressed for time :D +**\** othe: ^^ +**\** ok +**\** we wait for othe +**\** Later, then. +**\** in the meantime - anyone want to bring up anything else? +**\** oh - also, if anyone has any strong opinions on the crypto lib we should be using, now is a good time to mention them +**\** my inclination is to cryptocpp for a few reasons +**\** https://en.wikipedia.org/wiki/Comparison_of_cryptography_libraries is a good starting point if anyone wants to compare it to the others +**\** i had some discussion points wrt to the gooey if no one else has anything +**\** pero: go ahead +**\** i think the navigation menu might need a 2nd level +**\** medusa_ / dEBRUYNE ^^ +**\** slash Jaquee +**\** perhaps an advanced or something to that effect to house verify payment and sign/verify +**\** those are features that are not going to be very often +**\** especially sign/verify +**\** sign/verify needs to be renamed to 'Signatures' i think +**\** it's kind of confusing with 'verify payment' +**\** but i think if they were thrown into an Advanced top-level tab then there would be less possible confusion for most users +**\** the other thing- what's up with that qt title bar? +**\** isnt that best left for the OS to handle +**\** IIRC, people slightly preferred keeping it. +**\** i dont think 'preferring' makes it the right decision +**\** oh, as a point of curiosity - monerod runs quite happily on a phone even on 2G. using --out-peers 2. +**\** hardly any bandwidth used. +**\** i have 2 titlebars in gnome +**\** is that the case for all OSs? +**\** no +**\** no +**\** doesnt apple have it's buttons on the left side? +**\** I have two too. But then I have a special setup. +**\** then it's a bug +**\** moneromooo: you *are* special +**\** :-P +**\** 2 minutes and then I bring up meeting bot, so let's wrap this up +**\** i agree on using the os default +**\* fluffypony** hates the OS default +**\** we're also going against OS-specific consistent user experience +**\** ... wat... +**\** and that we need to work on the ux. +**\** against their design standards +**\** yes +**\ {-olark}** re: crypto libraries, imo, use TweetNaCl for what you can. Cryptopp for everything else. +**\** agree with pero - app should leave widgets to user's window manager +**\** olark: agreed +**\** title bar included +**\** we don't want it looking like it's from 1995 tho :-P +**\** we don't want it looking different from everything else on their desktop +**\** I'd prefer that the Monero Core app is consistent across platforms +**\** it was a pretty jarring experience for me running it on windows +**\** well it's just a titlebar +**\** ok let's discuss it later, meeting bot coming online +**\** ok +**\** it's not going to consistent - some platforms might have it maximized +**\** like on mobile \ No newline at end of file diff --git a/_posts/2016-12-14-monero-0.10.1-released.md b/_posts/2016-12-14-monero-0.10.1-released.md new file mode 100644 index 00000000..357b145f --- /dev/null +++ b/_posts/2016-12-14-monero-0.10.1-released.md @@ -0,0 +1,88 @@ +--- +layout: post +title: Monero 0.10.1 "Wolfram Warptangent" Released +summary: A mandatory update containing important, consensus-critical bug fixes +tags: [releases] +author: Riccardo Spagni (fluffypony) +--- + +*December 14th, 2016* + +### Overview + +This is a necessary point release of Monero v0.10 "*Wolfram Warptangent*", and is highly recommended as it includes consensus-changing fixes to the RingCT implementation and various other bug fixes. + +Some highlights of this release are: + +- major changes to support the GUI +- adds full support for "fluffy blocks", a propagation improvement similar to Compact Blocks in Bitcoin Core +- adds in a dynamic fee system +- expansion of the data stored in the wallet cache, including the GUI address book +- switch to Borromean signatures in RingCT +- add Monero payment URI support to the wallet library +- complete overhaul of the threading system +- optimise the wallet blockchain refresh mechanism +- created a contributing guide +- switched to a dynamic dust threshold system +- added a command to compute the total coinbase +- major RingCT performance improvements +- killed off the old fast_exit mechanism, which caused more issues than anything else +- improved and fixed the cold wallet transaction signing mechanism +- overhauled the sweep_unmixable implementation +- fixed FreeBSD builds + +### Contributors for this Release + +This release was the direct result of 29 people who worked, largely unpaid and altruistically, to put out 481 commits containing 10 517 new lines of code. We'd like to thank them very much for their time and effort. In no particular order they are: + +- Randi Joseph +- Gingeropolous +- Shen Noether +- Pierre Boyer +- taushet +- guzzi_jones +- Oyvind Kvanes +- J Ryan Littlefield +- lethos3 +- Will Skinner +- codehalo +- Jaquee +- Dan Miller +- moneromooo-monero +- AwfulCrawler +- Lee Clagett +- Riccardo Spagni +- zveda +- anonimal +- TedTheFicus +- luigi1111 +- Myagui +- NanoAkron +- Jkat +- iDunk5400 +- Adriaan Joubert +- Dion Ahmetaj +- Jacob Brydolf +- Ilya Kitaev + +### Official Download Links + +- [Windows, 64-bit](https://downloads.getmonero.org/monero.win.x64.v0-10-1-0.zip) +- [Windows, 32-bit](https://downloads.getmonero.org/monero.win.x86.v0-10-1-0.zip) +- [macOS, 64-bit](https://downloads.getmonero.org/monero.mac.x64.v0-10-1-0.tar.bz2) +- [Linux, 64-bit](https://downloads.getmonero.org/monero.linux.x64.v0-10-1-0.tar.bz2) +- [Linux, 32-bit](https://downloads.getmonero.org/monero.linux.x86.v0-10-1-0.tar.bz2) +- [Linux, ARMv7](https://downloads.getmonero.org/monero.linux.arm7.v0-10-1-0.tar.bz2) +- [FreeBSD, 64-bit](https://downloads.getmonero.org/monero.freebsd.x64.v0-10-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-10-1-0.zip, 727a53dd154b61fd653f81da27788077fdf519301c81d3c1eb033c1ff2bf97c6 +- monero.win.x86.v0-10-1-0.zip, ce77137b33bcaeb59273cb73b86e426e35e6209fb52a7e74fd9432a5a3018041 +- monero.mac.x64.v0-10-1-0.tar.bz2, 447cebae257864b3706a8622f495bfd9fae780a6b277e1e31ac83bef7bc855c6 +- monero.linux.x64.v0-10-1-0.tar.bz2, bf09eea27c957e7e2bdd62dac250888b301d4d25abe18d4a5b930fa7477708c7 +- monero.linux.x86.v0-10-1-0.tar.bz2, 9a18d274970df85d6bc926dc99407959c680c36f19017996be9c758f6c02cf06 +- monero.linux.arm7.v0-10-1-0.tar.bz2, 57221605997a3cd815f2a9689486abbdb124263fff047ca61068900eb7cb1839 +- monero.freebsd.x64.v0-10-1-0.tar.bz2, 3858d4786b65a37e981b142e9c0f256ac66662314794d05f595c4c30cb5b6ddb \ No newline at end of file diff --git a/_posts/2016-12-22-monero-core-gui-beta-released.md b/_posts/2016-12-22-monero-core-gui-beta-released.md new file mode 100644 index 00000000..2b14852f --- /dev/null +++ b/_posts/2016-12-22-monero-core-gui-beta-released.md @@ -0,0 +1,89 @@ +--- +layout: post +title: Monero Core GUI Beta 1 Released +summary: The first beta of the long awaited Monero Core GUI +tags: [releases] +author: Riccardo Spagni (fluffypony) +--- + +*December 22nd, 2016* + +### Overview + +The first beta of the Monero Core GUI has been released. Note that, at this time, we have not completed support for 32-bit Windows, FreeBSD, and ARMv7 Linux devices. They are all being worked on, and we hope to complete support for them by the time of the first release. + +Download links are at the bottom of this post, and please take note of the known issues and caveats listed below. + +### Known Issues + +- Due to several important updates, 0.10.1 wallet binaries will not work with with wallets created by the GUI. Please use the binaries included in the package instead. Note: you can definitely use the 0.10.1 daemon:) +- If you have been testing earlier builds you may have to delete your configs. There is [a guide describing how to do this on this StackExchange post](http://monero.stackexchange.com/questions/2866/where-are-the-monero-core-configuration-parameters-stored/2870#2870). +- Older computers may have an issue with the QT renderer, and will either crash or display a white / black window. You can change the rendering mode [as described on this StackExchange post](http://monero.stackexchange.com/questions/2928/how-to-change-the-monero-core-rendering-mode-for-older-computers/2929#2929). + +### FAQ + +- *Can I use a remote node?* This is certainly possible. In the wizard, change the daemon address from `localhost:18081` to the address of the remote node. For instance, if you want to use the remote node of moneroworld.com, change `localhost:18081` to `node.moneroworld.com:18081`. For more open node options, please check out the [MoneroWorld open node directory.](https://moneroworld.com/#nodes) Alternatively, you can specify a daemon address on the `Settings` page. + +- *What do I do if the GUI is showing `Wrong Version` at the bottom left?* If you see this message the daemon you are using is incompatible with the GUI. The daemon supplied in the binaries is compatible with the GUI. Thus, if you are seeing this message you are likely using a remote node, which is running a daemon that is incompatible with the GUI. Note that you will be able to receive funds. However, you *won't* be able to send funds. + +- *What if I get an "Can't create transaction: Wrong daemon version: internal error: histogram reports no unlocked outputs for xxxxxxxxxxxx, not even ours" error?* This means that you are using a daemon that is incompatible with the GUI. This is likely caused by using a remote node (see above). Alternatively, it could be caused by using a version 0.9.4 or 0.10.0. + +- *What if I get an "Error: failed to load wallet: input stream error" error when trying to open an existing wallet* This is due to the wallet cache (``) being incompatible. You can circumvent this error by removing your wallet cache. The GUI will then open your wallet and refresh from scratch. It is advised to properly backup your wallet files before you perform this action. Also note that deleting the wallet cache results in losing some of the transaction history, namely recipient addresses and private tx keys. Thus, if you want to use an existing wallet with the GUI, it is advisable to backup your wallet cache in case you need transaction history info in the future. + +- *What if I get an "Error opening wallet: std::bad_alloc" error?* This error is also caused by an incompatible wallet cache. See the previous question for further information. + +- *Can I open a wallet I created with the CLI?* Yes, this is possible with the wallet picker in the wizard. Use the "I want to open a wallet from file" option and select your .keys file to open the wallet created with the CLI. Alternatively, if you already have a wallet opened and want to switch to your CLI wallet, go to the `Settings` page and choose `Close wallet`. This will bring you back to the wizard, where you can choose your CLI wallet. Note that your cache may be incompatible and you may incur an error. If this happens, see the FAQ questions above. + +### Contributors for this Release + +This release was the direct result of 32 people who worked, largely unpaid and altruistically, to put out 736 commits containing 321 056 new lines of code. We'd like to thank them very much for their time and effort. In no particular order they are: + +- taushet +- HugTime +- James Cullum +- sbialy +- signo88 +- Ilya Kitaev +- redfish +- henrud +- NanoAkron +- Kenshi Takayama +- Jaquee +- Daniel Ternyak +- Riccardo "fluffypony" Spagni +- ferretinjapan +- medusa +- Guillaume Le Vaillant +- xmrdc +- dEBRUYNE +- xmr-eric +- Christoph Mayerhofer +- Howard "hyc" Chu +- githubrsys +- moneromooo +- krzysztoff7 +- Derek Zhang +- Martin Zając +- mochaccinuh +- Gingeropolous +- MoroccanMalinois +- Andreas Brekken +- Maitscha +- Clement +- Christoph Schnerch + +### Official Download Links + +- [Windows, 64-bit](https://downloads.getmonero.org/gui/monero.gui.win.x64.beta.zip) +- [macOS, 64-bit](https://downloads.getmonero.org/gui/monero.gui.mac.x64.beta.tar.bz2) +- [Linux, 64-bit](https://downloads.getmonero.org/gui/monero.gui.linux.x64.beta.tar.bz2) +- [Linux, 32-bit](https://downloads.getmonero.org/gui/monero.gui.linux.x86.beta.tar.bz2) + +### Download Hashes + +If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes: + +- monero.gui.win.x64.beta.zip, cb8bdf36fb56739a0fa746bec8dd51fb3479d51a3b8f0ce41a771f1d5a924bdb +- monero.gui.mac.x64.beta.tar.bz2, 907bfb4832c74de6cec7df730dfce5d9ccc1e6de09b6a4546cb9eee1f8242968 +- monero.gui.linux.x64.beta.tar.bz2, cecbe4b23f777442de861bc0981af0857dab043ed63be98f768cdd00825a8d09 +- monero.gui.linux.x86.beta.tar.bz2, daabd11b271685cedf5d6321cbde5e6b7c2691630a4355a973fc0cb99b1d2dc9 diff --git a/_posts/2017-02-05-logs-for-the-Kovri-dev-meeting-held-on-2017-02-05.md b/_posts/2017-02-05-logs-for-the-Kovri-dev-meeting-held-on-2017-02-05.md new file mode 100644 index 00000000..80c95427 --- /dev/null +++ b/_posts/2017-02-05-logs-for-the-Kovri-dev-meeting-held-on-2017-02-05.md @@ -0,0 +1,246 @@ +--- +layout: post +title: Logs for the Kovri Dev Meeting Held on 2017-02-05 +summary: Brief review of what has been completed since last meeting, Salti, and code & open tickets discussion +tags: [dev diaries, i2p, crypto] +author: dEBRUYNE / fluffypony +--- + +*February 5th, 2017* + +### Logs + +**\** 1. Greetings +**\** 2. Brief review of what's been completed since the previous meeting +**\** 3. Code + ticket discussion / Q & A +**\** 4. Any additional meeting items +**\** 5. Confirm next meeting date/time +**\** 1. +**\** Hello +**\ {-olark}** greetings +**\** 'Hola' as hyc would say right now +**\ [endogenic]** Hi! +**\ {-guzzi}** hi +**\ [i2p-relay] {-ArticMine}** Hi +**\** 2. Brief review of what's been completed since the previous meeting +**\** Our last meeting was on November 27th, 2016 so, nothing can be "brief" about a review. +**\** There were holidays, etc, so there was a leave of absence but development is going strong. +**\** All I can say is if anyone is really interested, we have git-log and github (kovri + meta), my fork, and https://forum.getmonero.org/9/work-in-progress/86967/anonimal-s-kovri-full-time-development-funding-thread for any TL;DR +**\** I'm also have uncommitted work, finishing up the crypto impl refactor + testing for this new exception dispatcher. +**\** JFTR: of the thousands of lines of code that we forked from, almost none of it handled exceptions. All this spaghetti code, and that guy did not even have a basic grasp of design with exception handling in mind. Literally, much of the core code is still stringed together with the hope that it won't fail. I hate it. It's always been like walking on glass, but a real fix will take time. So, I've started in +**\** that direction at least in terms of getting exceptions handled or handled better. +**\** We have two new contributors: MoroccanMalinois and Chris Barry (lazygravy), and EinMbyte and olark have returned. +**\** At this point I think a Q&A for "brief review" would be best. +**\** that summary is pretty scary +**\** lol +**\** Good scary, I hope? +**\** ;) +**\** :) +**\** it points in a good direction +**\** Good, I hope so! +**\** sounds like bytecoin code :D +**\ {-olark}** The i2pd situation was interesting to say the least :p +**\** Or more aptly titled: "why2pd". +**\ [endogenic]** Total kovri noob here. Not looked at the code yet. Is there any significant future use case for kovri libraries? Is it worth doing upfront? *sits back down* +**\** Monero. That's the biggest future use-case so far. +**\ {-olark}** I would like to see a future where kovri would be the go to i2p router for implementing into applications +**\ {-olark}** Instead of tor +**\ {-olark}** blegh +**\ {-olark}** Monero obviously first though ;) +**\** makes sense. tor was created for the gov't after all +**\ {-olark}** Yep +**\** if it will do good for cash/monero i guess those use cases will follow by time +**\** Everyone seems to be ecstatic about libkovri but I must stress that this is a sensitive network so, the lib should be used with that in mind. +**\** Tor doesn't have this issue. All that work is upon the relays. +**\ {-olark}** True +**\** Simply shutting down the router when it's most convenient has a negative impact on the network and anonymity. The API needs to take this into consideration as will any applications. +**\** I can get into details, not meeting worthy. endogenic I don't think I answered your question well enough, I hope I can do better after the meeting. +**\** Any questions about "brief review"? +**\ {-olark}** Hang around in #kovri endogenic +**\ {-olark}** Basically we are close to nightlies right? +**\** ^ #kovri-dev is more informative +**\ [i2p-relay] {Slack} [endogenic]** i’m here +**\ {-olark}** :) +**\** Yes, nightlies are technically available https://build.getmonero.org/waterfall +**\** *but* +**\** pigeons and I are working out packaging details. +**\ {-olark}** ok +**\** Right now they *all* run a hacked makeself installer. So, download -> chmod +x -> run the installer. +**\** Windows requires msys2, this is silly so I think we can do a windows installer method (I posted details in the meta repo) +**\ {-olark}** nice +**\ [EinMByte]** Hi, sorry for being late +**\ [needmultisig90]** oh its being relayed +**\ [needmultisig90]** neat +**\** needmultisig90 wants to head up the packaging front. needmultisig90: if you aren't watching the meta repo, I highly recommend that. +**\ [needmultisig90]** link pls +**\** https://github.com/monero-project/meta +**\** If you review the issues, you'll see where are on packaging. +**\** where we are +**\ [needmultisig90]** Added, will do +**\** I don't want to shortchange the work that's been done since the last meeting, any more Q&A before moving onto the next point? +**\* anonimal** thinks too +**\** Oh, yes, another new contributor alvinjoelsantos (I don't know if he's around) +**\ [i2p-relay] {Slack} [needmultisig90]** ajs is cool +**\ [i2p-relay] {Slack} [needmultisig90]** @ajs +**\ [i2p-relay] {Slack} [needmultisig90]** he appears to be online +**\** Oh, *that's* ajs, excellent. +**\ {-olark}** Good to have new blood :) +**\** ajs wanted to work on the website too, IIRC? +**\ [i2p-relay] {Slack} [needmultisig90]** he's working with me on /r/moneromarket +**\ [i2p-relay] {Slack} [needmultisig90]** I believe so +**\ [i2p-relay] {Slack} [needmultisig90]** he has a background in law +**\** "I am the law!" +**\ [i2p-relay] {Slack} [needmultisig90]** and was working with OpenBazaar on drafting up arbitration agreements IIRC +**\ [jollymort]** also on the monero stealth addresses script : ) +**\ [i2p-relay] {Slack} [needmultisig90]** he can correct me +**\** Have him take a look at /r/Kovri +**\** does the website exist? i'm happy to help add content and such +**\** bigreddmachine: we all need to tackle fluffypony because he's been coveting the website idea since we started +**\** "MY PRECIOUS!" +**\ [fluffypony]** bigreddmachine: yes +**\ [fluffypony]** I moved laptops and so now half my stuff lives on my old one +**\ [fluffypony]** I'll try consolidate and push it up this week +**\** okay, just wanted to make sure i hadn't missed something. i'll watch the repo - going under getmonero.org or as a separate repo/site? +**\** Last call for point 2. "brief review" +**\** bigreddmachine: while you're here, we did make some progress on Salti. Any news from upstream on their API? +**\ [fluffypony]** bigreddmachine: same design, new content, linked from the getmonero menu bar +**\ [EinMByte]** Progress on salti? +**\** EinMByte: yes, have you read some of the conversation in the open salti issue? +**\** anonimal: i've been tracking the open tickets but everything got held during holidays. nothing there yet, but i might make a proof of concept for chromium if there'd be interest +**\ [EinMByte]** "some of" yes, that sounds about right +**\** bigreddmachine: sounds great +**\** EinMByte: most of the collaboration was in IRC, not in issue. +**\** it would be easy enough to port to firefox + tbb once they finish webrequests.proxy +**\** bigreddmachine: will you open FFS for this? I think it's worth it. +**\** for the chromium part? or ff/tbb? +**\* anonimal** shrugs +**\** i don't feel comfortable proposing something that at the moment isn't possible and relies on mozilla dev community before it can get started... +**\** Ok +**\** Chromium PoC sounds good none-the-less. +**\** but i will FFS it once i think it's doable +**\ [i2p-relay] {-ArticMine}** I would be careful with Chrome / Chromium since unlike Firefox there is no no option to disable DRM +**\ [i2p-relay] {-ArticMine}** The DRM could be an attack vector +**\ [EinMByte]** Anything that relies on mozilla sounds bad to me +**\ [i2p-relay] {-ArticMine}** Firefox and clones are fine +**\** ArticMine - DRM isn't included in chromium afaik. chromium is only open source code. +**\** ... at least that's always been my understanding. +**\ [EinMByte]** Firefox is fine, of course, and preferably we should use Firefox (or at least that was the initial idea) +**\** anyway, we can discuss details after the meeting if there's interest. don't want to hold up anonimal +**\ [EinMByte]** but relying on mozilla to move... probably not going to happen +**\ [i2p-relay] {-ArticMine}** https://bugs.chromium.org/p/chromium/issues/detail?id=686430 +**\** no chromium is even binary blobs download at compiletime +**\ [i2p-relay] {-ArticMine}** The DRM in Chrome is currently an issue in Chromium +**\** bigreddmachine: this is technically "3. Code + ticket discussion / Q & A" so we can chrome-it-up if needed. +**\** Any other comments on Salti? +**\** okay - maybe a chromium POC would need to stay just that, a POC, and never production. +**\** Something to play with at least, I'm up for that. +**\** "Any other comments on Salti?" --> just that i'll keep trying webRequests.proxy +**\** Ok, thank you. That sounds ideal AFAICT. +**\** Onto other code + ticket discussion: +**\** Since I have no questions for myself, any Q&A? +**\** Open PR from guzzi, ETA for completion? +**\ [moroccanmalinois]** hi guys, guzzi are you interested in #399 ? i may give it a shot if you are not +**\** Oooo #399, my favourite. +**\ {-guzzi}** \* anonimal, this week on PR +**\ {-guzzi}** \* checks 399 +**\** moroccanmalinois: ironically, I highly encouraged guzzi to get started on that after we merged his PR. +**\ [olark]** I'll leave what I have to say for after. +**\ [olark]** Unless there are no questions people have about kovri +**\** moroccanmalinois: but now that he will be funded, I would ask him to contribute partly to that and help me with many other areas instead +**\ [moroccanmalinois]** @anonimal "easiest" one i find +**\ {-guzzi}** sounds like a plan. +**\** I mean, I can't speak for either of you; please do it! +**\** Ok, so moroccanmalinois is on #399 now? +**\ [moroccanmalinois]** my pleasure if guzzi is fine with it +**\ [EinMByte]** Do we still have important SSU issues open? +**\ [EinMByte]** Might take a look in the next week +**\ {-guzzi}** but converting .jar to c is a great way to learn +**\ {-guzzi}** we an decide away from the meeting. +**\** #399 is actually great for various reasons, one of which would introduce a new dev to the purpose of libkovri-client and libkovri-core +**\ [moroccanmalinois]** cool +**\** EinMByte: yes, the same ones I believe since you left though I may have resolved one or two but not closed (I don't know) +**\** guzzi: we wouldn't be converting .jar to c +**\** I'll give details after the meeting +**\** olark did you mean monero question for after the meeting or kovri question? +**\ [EinMByte]** Alright. Might do some additional refactoring, since I never completely finished that +**\ {-guzzi}** oh i see just skimmed +**\ {-olark}** Not so much a question but a new development that pertains to both kovri and monero :) +**\ {-olark}** Something I have been thinking about while I was looking at Monero's ring signatures. +**\** EinMByte: that sounds great +**\* anonimal** will look at issue tracker after meeting +**\** Ok, anymore on 3. Code + ticket discussion / Q & A ? +**\** Lots of TODO's. I'm adding them like spice to bland soup. +**\ {-olark}** I'll mention it in 4. +**\** Once I get these two branches merged, maybe someone can pick some of them up. We'll see. +**\ [i2p-relay] {-ArticMine}** I will bring up an item in 4 +**\** 30 seconds until 4. +**\ {-guzzi}** i like todos +**\** 4. Any additional meeting items +**\** Floodgates opened! +**\** Fashion, food, travel: anything goes! +**\ [i2p-relay] {-ArticMine}** Yes https://www.myhackerhouse.com/windows_drm_vs_torbrowser/ +**\ [i2p-relay] {-ArticMine}** DRM used to attack tor in Windows +**\** lol +**\ [i2p-relay] {-ArticMine}** Cost to get Windows to trust this attack 10,000 USD +**\** Thanks ArticMine, looks like a great read. +**\** bigreddmachine: ^ +**\ [i2p-relay] {-ArticMine}** Should also work against i2p +**\* anonimal** will read more after meeting +**\** fluffypony: are you gpg verifying the kovri subscription that's hosted on github? +**\** okay, so i'll go ahead and say that i won't officially ever support a chrome version of Salti then. +**\ {-olark}** I'll let ArticMine go first +**\* anonimal** wanted to ask that in monero's meeting on the topic of github security +**\** "subscription" ? +**\ [EinMByte]** By the way, if anyone needs access to the salti repo, please tell me +**\** moneromooo: https://github.com/monero-project/kovri/blob/master/pkg/client/address_book/hosts.txt +**\ [i2p-relay] {-ArticMine}** My take is that any browser / OS that supports DRM is vulnerable to an attack against anonymity / IP obfuscation +**\ [EinMByte]** As with many features like DRM, it's best that they're just enabled +**\** Thanks. +**\ [EinMByte]** \*disabled LOL +**\** lol EinMByte +**\** moneromooo: the only reason I'm signing it is because fp is pulling directly from github +**\ [i2p-relay] {-ArticMine}** So i2p on such a platform may create a very dangerous sense of false security +**\** ArticMine: much like anything Windows +**\* anonimal** now windows fan +**\** \*not +**\ [i2p-relay] {-ArticMine}** Yes +**\** olark: 10 minutes left +**\** Tick tock tick tock! +**\** fluffypony: in addition to my ping above, is there any kovri-related news related to your conference circuit? +**\ {-olark}** Salti is a good solution for now +**\ {-olark}** In the future we could have our own dedicated browser +**\ {-olark}** Not sure when that is viable though +**\ {-olark}** ok +**\ {-olark}** sorry got really bad tunnel lag +**\ {-olark}** I have been thinking about how LN or something similar would work with monero +**\ [fluffypony]** anonimal: just generally good chats +**\ [fluffypony]** Nothing mind blowing +**\ {-olark}** Once kovri gets implemented into nodes and wallets this opens the doors to some really great developments +**\ [fluffypony]** Some good talk on Tor failure modes +**\ {-olark}** Since we would have access to i2p for routing +**\ [fluffypony]** A few people at 33c3 said that i2p was a prescient choice +**\** kovri - the prescient choice for online anonymity +**\ {-olark}** It would need to be a plugin for kovri +**\* anonimal** wants Kovri's I3P technology. Trademarked, stamped, hah! +**\ [fluffypony]** Hah +**\** I3P, your cover of choice. +**\ {-olark}** Could have a client tunnel for LN functionality in wallets +**\ {-olark}** Use kademlia DHT so the other "lightning" nodes know of each other +**\ {-olark}** Would be able to route around centralized troublesome nodes +**\ [fluffypony]** Can I shut meeting-bot down, anonimal +**\ {-olark}** Fixes a lot of problems the current LN development is trying to fix +**\** fluffypony: 3 minutes left? +**\ [fluffypony]** Kk +**\ {-olark}** Don't need to build routing from scratch +**\ {-olark}** Anyway it is still way to early to really till this could be possible +**\** olark: sounds interesting. I'd need more info to have a comment. +**\** moneromooo - I'll work on the isolated testnet in a bit. I apparently need to rebuild all of my monerod's w/o libunwind, or it crashes trying to init a new blockchain. So I'll have it tested a bit later today. +**\ {-olark}** But there is good potential +**\* anonimal** swats Snipa +**\** Cool, thanks Snipa +**\** Ok, one minute left. 5. Confirm next meeting date/time +**\** Same time, two weeks from now? +**\** february 19? i can do that +**\ {-olark}** Sounds good +**\** Ok, I'll post on meta repo. +**\** Thanks everyone! \ No newline at end of file diff --git a/_posts/2017-02-05-overview-and-logs-for-the-dev-meeting-held-on-2017-02-05.md b/_posts/2017-02-05-overview-and-logs-for-the-dev-meeting-held-on-2017-02-05.md new file mode 100644 index 00000000..8fad218e --- /dev/null +++ b/_posts/2017-02-05-overview-and-logs-for-the-dev-meeting-held-on-2017-02-05.md @@ -0,0 +1,340 @@ +--- +layout: post +title: Overview and Logs for the Dev Meeting Held on 2017-02-05 +summary: Sync improvements for HDD, GUI 2nd Beta, fluffy blocks, and dynamic fee discussion +tags: [dev diaries, core, crypto,] +author: dEBRUYNE / fluffypony +--- + +*February 5th, 2017* + +### Overview + +An overview [can be found on Hello Monero](https://hellomonero.com/article/monero-dev-meeting-note-highlights-and-transcript-2017-02-05). + +### Logs + +**\** ok +**\** welcome to the 77th annual hunger games +**\** oof +**\** 1. greetings +**\** 2. Brief review of what's been completed since the previous meeting +**\** 3. Code + ticket discussion / Q & A +**\** 4. Any additional meeting items +**\** 5. Confirm next meeting date/time +**\** so let's start with 1 +**\** hi +**\** HOLA +**\** hi. I'm hyc, and I'm a monerophile +**\** Morning. +**\** ArcticMine, luigi1111, luigi1114, luigi1112, othe, hyc, smooth, jaquee, m5M400, medusa, tewinget, zone117x, dEBRUYNE, moneromooo +**\ {-olark}** greetings +**\ [xmr-eric]** hullo +**\** hey +**\** one question... is there free margeritas? +**\** Present in Q state. +**\ [endogenic]** \* hands DaveyJones a margarita +**\** DaveyJones: of course, dev meetings are 100% serious business and you need margaritas for that +**\** greetings +**\** ok let's move on to 2 +**\** when was the last meeting? +**\** 2 weeks before christmas? +**\** it's been nearly 2 months since the last dev meeting because of end-of-year and me travelling etc. +**\** does anyone want to mention stuff that's been done +**\ [EinMByte]** Hi +**\** (brb hopping out of taxi) +**\ [i2p-relay] {-anonimal}** ^ FYI, monero meeting, kovri in 55 minutes. +**\** many many commits have been merged +**\** I am here +**\** I will mention my own, using batched txns for node syncing, to reduce I/O demand +**\ [EinMByte]** anonimal: Oh right, should be keeping an eye on the meta repository too +**\** this seems to speed up syncing on HDD by 2-3x while improving stability +**\** great stuff hyc! +**\** hyc: sounds tasty +**\** (the actual goal was to eliminate the few corruptions we've see non Windows) +**\** seen on +**\** So the corruptions were fixed too? +**\** so far it appears so. +**\** I examined 3 corrupted Windows data.mdb files. they all had zero pages at the tail of the file +**\** due to not being sync'd before OS crashed +**\** the new code syncs more frequently, but in a background thread +**\** so throughput is still high because foreground doesn't have to wait for it +**\** but syncs are more often, to reduce the chance of unsync'd pages during a crash +**\** but there's no 100% guarantee there. +**\** IIRC, this fix/addition was after latest point release? Was point release before or after the previous meeting? +**\** this is for the default "fast" mode. you can still use "safe" mode for 100% guarantee, but super-slow. +**\** and this is recent, merge was only a week or so ago +**\** ok +**\** ok back, just got to sXpher's house +**\** cool. I think that's it for me. +**\** hyc: tons of commits +**\** yeah +**\** was fluffy blocks already merged in by the last meeting? +**\** I think so?... That was before point release right? +**\** I thought fluffyblocks was in 0.10.1 +**\** yes, pretty sure it was +**\** It was +**\** I think it could be enabled on mainnet now, since testnet's not shown anything wrong with it. +**\** anonimal: I can't remember +**\** moneromooo: agreed +**\** +1 +**\** moneromooo's new logging implementation, this is new. +**\** Snipa: you did test it with a private testnet with only such nodes, right ? +**\** the crazy reorgs on testnet are due to old nodes on testnet? +**\** yeah the new logging colours threw me for a loop :-P +**\** yes logging is new, GUi scope for next release is like this: +**\** extended x64 x86 linux support / cold signing / view only wallets / restore from private keys / integrated mining / better logging / daemon status button / +**\** +display unlock time and confirmation +**\** moneromooo - No, I didn't test on a private testnet, but my personal nodes all have patches enabling it on mainnet between them, and I'm not seeing any issues with it yet. +**\** All of my testnet nodes of course, have been running it as well without issues. +**\** OK, I guess my point was lost. I don't have the disk space for many blockchains to test though... +**\** If I need to go setup another one, I've got enough disk space to do so. IIRC we thought it wasn't needed because all of the active testnet nodes were using it. +**\** medusa: ok great +**\** I think for future we should have a separate line item for GUI stuff +**\** My point was that I wanted to see if it worked on a network with ONLY fluffy blocks being sent. +**\** (if there is GUI stuff I mean) +**\** But it seems everyone just mentally removes the "only" word :D +**\** Ah, sorry, I must of missed that. I can set that up still if it's wanted. I've got more than enough nodes to do so. +**\** That'd be great, yes. +**\** I thought you'd already done that actually. +**\** What I want to know is whether there is a failure mode when a node can't sync from a fluffy block, but gets the block anyway from another peer. +**\** can't we just make testnet fluffy blocks only? +**\** and then we test it there +**\** kk, I'll go figure out how to isolate a bunch of nodes this afternoon, and setup a small network to mine on. +**\** We could. +**\** testnet seems pretty robust given the amount of stuff we've done on it +**\** lol +**\** Snipa: https://github.com/moneroexamples/private-testnet +**\** I mean, I leave a couple hundred h/s there on my test pool. And have ~10-ish nodes up on it. +**\** Oh, so I can add multiple exclusive nodes? I think that was one of the questionmarks I was running into. +**\** okyes +**\** yes +**\** Good stuff, I'll go fight with that here in a bit. +**\** ok +**\** let's move on +**\** 3. Code + ticket discussion / Q & A +**\** issues on Github are starting to pile up, and I think we should get on top of that +**\** as discussed before, the lack of granularity in Github's permissions is a bit of an irritation +**\** we've discussed having a second repo with more collaborators, but I think that's going to create more confusion than anything else +**\** so my suggestion would be that we set up an issue closing bot that has collab status +**\** and then that has a list of people that can ping it to close issues +**\** that sounds cool +**\** I haven't had a chance to see if such a thing exists, but if not it isn't hard to write +**\** https://github.com/foosel/GitIssueBot +**\** that sounds great +**\** and if we set it up to do re-labelling too +**\ {-anonimal}** How to protect from troll abuse? +**\** cool. could it handle labeling too? +**\** cant close yet but perhaps can be extended +**\** by "list of people" +**\** anonimal: only specific people can ping it +**\ {-anonimal}** k +**\** a good start would be if everyone also takes care of their own issues in the meantime ( i know me included) +**\** medusa: agreed +**\** ok any Q&A items? +**\** About what ? Anything ? +**\** moneromooo: yes +**\** hi, I'm fluffypony, AMA +**\** i'm actually curious about the status of paybee +**\** ;p +**\** Then I'm annoyed at the merge commits, which can embed some arbitrary amount of dross, making things easy for an external attacker with access to github to slip pwnage. +**\** Does anyone know a good way to prevent those (with manual exceptions since tewinget already said he wouldn't rebase the massive 0MQ branch) ? +**\** pero: we can talk about it later +**\** any word from tewinget? did not read a thing from him recently, regarding 0mq +**\** A git hook looks like the obvious option, though it's still vulnerable to github. +**\** i asked him last night - sec +**\** moneromooo: you mean to merge without the merge commit? +**\** that would require a rebase by the merger? +**\** \ \ very little movement on that front - the pr hasnt been touched in 2 months \<--- I haven't commented on it in as much time, but I've worked on it. Not as much as I could/should have, of course, but... +**\** I'm not sure about that. AIUI, it's needed for the signatures. I'm not super knowledgeable about what that entails wrt amount of dross. +**\ {-anonimal}** fluffypony: you very recently finished your extended 1 month+ tour, can you fill us in with details of any notable experiences? +**\** moneromooo: it *is* needed for the signature, not everyone is signing their commits +**\** Yes, rebase would fix, but that'd need a LOT of rebases, so isn't practical. +**\** and cherry-picking would lose signature? +**\** cherry-pick -S resigns. +**\** it re-signs +**\** and we want to maintain author sigs where they exist +**\** but with picker's key, not original key? +**\* anonimal** believes so +**\** Yes, if someone else cherry-picks, then you can't preserve sig. +**\** This massive hole just annoys me, but I'm not sure how to fix it. +**\** moneromooo: me neither +**\** are you talking about the merge commits into master or like merging instead of rebasing +**\** I don't think it's a solvable problem +**\** My automated sig checking on make thing is also vulnerable to that, since it trusts anyuthing the pony signs. +**\** luigi1112: merge commits into master +**\** Well, we can ask him to rebase, that's not hard. +**\** It is for tewinget due to the amount of stuff, but that's a special case. +**\** moneromooo: rebasing will also make it hard to use Github to track PRs, surely? +**\** rebase-only I mean +**\** so you want the maintainers merge commits to go away? +**\** I meant rebasing before PR. The merger would still do a merge commit, unfortunately. +**\** No, just yours, if you PR any. I understood fluffypony's line to mean this, maybe I misunderdtood. +**\** well,we can solve this but the procedure gets more awkward: +**\** PR author rebases before merge +**\** which mean merger has to contact PR author immediately before each merge +**\** Oh, I hadn't seem luigi1112's first line. Ignore my last 2 then. +**\** Yes, that's what I ment by not practical :/ +**\** yeah that won't work +**\** :( +**\** Question: +**\** anonimal: answer +**\** :-P +**\** I guess the best we can do it some kind of subjective "rebased not too long ago so any extra dross diff is small enough". +**\** i know ... i know ... 42 +**\** Ok, two questions: is PR author out of the picture? Poof/gone? +**\** But it requires the merge to check it. +**\** anonimal: usually not, but maybe a couple days' latency. Which means the merger has all the latencies in series. +**\* anonimal** not 100% following the problem +**\** Oh, ok. +**\ {-olark}** What about hosting code on something that is under our control and not github? This would involve not using github though. +**\** moneromooo: but this is all in an effort to make sure that maintainers can't introduce extra bits in, right? +**\** I guess most of the problem is fixed by refusing any patch with irrelevant crap, with merge commits, and when they also cause more than trivial diffs in the final merge commit. +**\** olark: that's not the problem, my merge commits are GPG signed, so *I'm* the failure mode, not Github +**\ {-olark}** right +**\** So, why not close their PR and reopen a new one with their branch merged (not rebased) to maintain original sigs? +**\** Well, maintainers and anyone who could fool the maintainer into signing a large merge. +**\** If they can't keep up, then do the work for them? +**\** anonimal: I do not understand "why not close their PR and reopen a new one with their branch merged (not rebased) to maintain original sigs?" +**\** neither do I +**\** sounds to me like it would create exactly the problem we're trying to address +**\** PRs with irrelevant changes sliding in +**\** I think I don't understand the problem, so my question doesn't make sense. +**\* anonimal** is 25% here, preparing for kovri meeting +**\** moneromooo: otoh it's not like we have so many eyes on PRs that nothing at all could be snuck past us, so maybe we're trying to solve a problem that is ultimately a non-issue +**\** I think we should continue this after the meeting, probably won't solve it here. +**\** So... we're screwed alrady, might as well not care ? +**\** :-) +**\** moneromooo: yes :-P +**\** I guess it is a practical solution for now. +**\** Though, an easy win is to automatically reject any PR with a merge commit in it. +**\ {-olark}** hmm +**\** If github could be set up to reject those, that'd remove a good chunk of dross already. +**\** moneromooo: I'm happy with that - could the requester fix it by rebase + force-push ? +**\** (though still vulberable to github itself, but we said we don't care for now) +**\** do you have a recent example of a problematic PR? +**\** Yes. That's what I do when I fix a trivial thing in a PR of mine. +**\ [nanoakron]** That’s what I do with mine +**\** and yes, I usually rebase my PRs on latest master +**\** on the topic of Github, pigeons has a Gitlab mirror running on our (Monero's) hardware, so we're reasonably resilient to weirdness +**\** Not a recent one. I found one, but it's a very odd behavior on a single VM. +**\** A mirror isn't really a good protection against this I think. +**\** ok so new rule is that people submitting PRs should be asked to rebase + force-push if a merge commit exists in their PR +**\** Yes, please. I do when I see them, but I often look just at the diffs and forget commits. +**\** yeah that sounds reasonable +**\** yep +**\** But it could be automated I think. +**\** I'll look to see if there's a hook +**\** would be nice to automate things like notices on buildbot failures +**\** I just saw a java jar one. Which seemed... meh. +**\** or on first-buildbot-failure +**\ [jollymort]** i have one q: what if the price explodes again and does 10x - what to do with fees? make F0 in the dynamic fee calc 10x smaller? somehow i feel it would call for a one time 10x blocksize bump as well to keep the proportions same, otherwise we'd need huge multipliers to get to the point where increasing fee gives incentive to bump the blocks +**\** ArticMine: ^^ +**\** A price increase without a corresponding increase in blocksize? +**\ [jollymort]** yeah +**\** the ircbot for buildbot can notify when a job goes success->fail +**\ [nanoakron]** @jollymort it’s not really reasonable to ask the blockchain to care about the fiat price because that requires gameable oracles +**\** pigeons: can it notify on the PR tho? +**\** yes +**\** pigeons: ok cool - let's chat about it later / tomorrow and figure out which platforms we want to target with that +**\ [jollymort]** nanoakron i get it, but with the current set-up we decided on an arbitrary starting point +**\ [nanoakron]** You mean 60k blocks? +**\** also jollymort ... what is a reasonable time-frame to call sth a higher price to even justify changing F0 ? +**\** fwiw, there's so much constant failures that I ignore the buildot pings now (sorry) +**\** Over time the assumption is that price follows transaction demand. Over the short term ther may well be a delay. +**\ [jollymort]** good point Davey... but i can imagine a scenario where we have 3$ fees for some period +**\ [nanoakron]** @jollymort What is a $3 fee? How does the system determine that in a zero-trust manner? +**\ [jollymort]** it doesn't +**\ [jollymort]** maybe difficulty is a loose peg +**\ [nanoakron]** Fees are an economic negotiation between miners and users +**\** If the price rises very fast it could happen. There is another complication factor here namely one time changes in transaction size +**\ [jollymort]** yeah, was RCT size bump considered? +**\** maybe if sth like the average tx over a given time period sink TOO low some kind of mechanism would detect such a behaviour and see it as too expensive TX +**\** Ultimately fees are set by the blocksize penalty / demand / base reward +**\ [jollymort]** nanoakron i know that, but the minimum fee could become problematic in case of price bump +**\ [nanoakron]** The sudden increase to RCT sizes should have perhaps been considered in advance. The problem is people who panicked and refused to use RCT Tx, thereby keeping an odd mix of large and small Tx in each block, preventing proper upwards adjustment in size and downwards adjustment in fee +**\** buth my math is way to bad to give a better example :D +**\ [jollymort]** so just changing F0 would probably be ok +**\** Yes the minimuim fee could need to be adjusted +**\ [nanoakron]** @jollymort can you please model what you want to happen first and submit it as a post or code somewhere so it can be considered formally? A bit of academic rigour would be nice here +**\** We just had an effective increase in TX size ~10x + +**\** without changing F0 +**\** F0 was changed just before in anticipation +**\** ah okay +**\ [jollymort]** cool +**\ [jollymort]** anyway, i'll do some study +**\ [jollymort]** but just wanted to see your thoughts +**\** The relevant question is the change in RingCT Tx size and further optimizations +**\ [nanoakron]** I’m not averse to the idea, so long as it can be justified with a nice model of the expected behaviour and consideration of the potential attack surface +**\ [xmr-eric]** I have a question. When should the GUI come out of beta status? Because things are feeling pretty stable and the featureset seems complete to me. +**\** Since this influences blocksize and consequently fee paid +**\** It should be perpetually beta. It gets lonely around here without the reassuring lull of "where's the GUI" in the background +**\ [jollymort]** i was thinking of: increase baseline block size x5 and reduce F0 with x0.2 +**\ [jollymort]** but block size is consensus so.. +**\** Where's the LMDB wallet file ? +**\ [jollymort]** needs some justifications +**\** nanoakron like i said... maybe sth like the average tx numbers decrease drastically for a given time frame could be a trust-less way too do it... but i have no clue how to get a decent formula +**\ [nanoakron]** Hrm... +**\** as actual example... the price pumps and suddenly it is WAY to expensive to do any tx for the people +**\ [jollymort]** tx numbers can be gamed +**\** jollymort there is merit to this +**\ [nanoakron]** @hyc is it possible to auto-scan the database file if the system wants to crash? e.g. “Database corrupt after block 120842…rewinding…" +**\ [jollymort]** x5 due to RCT size increase +**\ [jollymort]** when the original 60kb was set, probably RCT was not in the works +**\ [jollymort]** so it was based on TXes of 1kb +**\** yes +**\** the issue is the relative size of the tx to minim blocksize +**\ [jollymort]** or whatever was the pre-RCT size +**\** is dev meeting over +**\** nanoakron: not in general. since we only keep 2 persistent versions of the DB. +**\ [jollymort]** ArcticMine yes, that's how i see it +**\** nanoakron: if the OS failed to sync the previous two txns, then the corruption is uncrecoverable. +**\ [nanoakron]** @hyc :( How about these pages of zeroes - if that’s a consistent failure mode can they be unwound? +**\ [nanoakron]** Oh +**\** ok guys +**\ [jollymort]** anyways, just wanted to know if anyone else thought about this; won't take any more of your time +**\** let's wrap it up +**\ [nanoakron]** That’s all it takes? +**\ [nanoakron]** 2 Tx +**\** Kovri meeting starting in 5 minutes +**\** nanoakron: yes. we could change this. +**\** fluffypony ... AMA after the kovri meeting? :D about your journey and paybee? +**\** nanoakron: use a longer delay before reusing old pages. +**\** if you got something to tell ^^ +**\ [nanoakron]** @hyc Ok. At least there’s a potential way through it. +**\ {-olark}** I opened an issue to start discussing alternatives to the ringsize increase in September 2017 that negates a lot of possible attack vectors on ring signatures and still ensure a 'true' strength of ringsize 4 at minimum for all transactions. It is here https://github.com/monero-project/monero/issues/1673 I think it requires serious consideration moving forward. I won't go too much into it and +**\ {-olark}** just let everyone read the writeup :p +**\ [nanoakron]** @olark I’d like knaccc to contribute too with his modelling of churn +**\ [xmr-eric]** I like the idea of a static ringsize +**\ [jollymort]** i like the "static" proposal +**\ [xmr-eric]** ^^ +**\ [jollymort]** and yes, also churn +**\** DaveyJones: sounds good - I've got to step out for a little bit +**\ [xmr-eric]** No thoughts on getting GUI out of beta status, everybody +**\ {-olark}** because the current situation is... undesirable to say the least +**\** What is beta status ? +**\** xmr-eric: sounds like not yet. +**\** xmr-eric: i think we need one more beta release at least. +**\** nanoakron kenshi84 blew some big holes in my churn suggestion btw, so my model isn't good yet. +**\ [nanoakron]** @knaccc Ah…well, all discussion is good +**\ [xmr-eric]** Cool +**\** knaccc: cool, is that written anywhere? +**\ [nanoakron]** @xmr-eric and if you see bugs, please bring them up on github +**\** ok anonimal the floor is yours +**\ [jollymort]** also, opened discussion on multiple PID / TX : ) https://github.com/monero-project/monero/issues/1659 +**\** hyc only in my IRC logs. Summary is that the churn only works if you're churning with pure ringct trees, doesn't work if there are non-ringCT transactions mixed in +**\** thx +**\ [i2p-relay] {-anonimal}** I have 2 minutes to prepare +**\ [jollymort]** i thought you can't mix rct+non-rct outputs anyway +**\ [i2p-relay] {-anonimal}** 17:59 1 minute! +**\** +1 lmdb wallet +**\ [nanoakron]** waits with bated breath +**\* moneromooo** congratulates nanoakron for correct spelling. +**\ [nanoakron]** :grimacing: +**\** Any objections to me typing in #monero-dev? +**\** jollymort it's when you mix with an output that is a ringct output but whose inputs are non ring-ct. that breaks churn +**\ [fluffypony]** none from fluffy-on-this-side either +**\** none +**\** no objection +**\** That wasn't sarcasm actually :D +**\ [i2p-relay] {-ArticMine}** Fine with me \ No newline at end of file diff --git a/_posts/2017-02-19-overview-and-logs-for-the-dev-meeting-held-on-2017-02-19.md b/_posts/2017-02-19-overview-and-logs-for-the-dev-meeting-held-on-2017-02-19.md new file mode 100644 index 00000000..8a6fd9e4 --- /dev/null +++ b/_posts/2017-02-19-overview-and-logs-for-the-dev-meeting-held-on-2017-02-19.md @@ -0,0 +1,204 @@ +--- +layout: post +title: Overview and Logs for the Dev Meeting Held on 2017-02-19 +summary: 0MQ, 10.2 release, and background mining +tags: [dev diaries, core, crypto, 0mq] +author: dEBRUYNE / fluffypony +--- + +*February 19th, 2017* + +### Logs + +**\** 1. Greetings +**\** 2. Brief review of what's been completed since the previous meeting +**\** 3. Code + ticket discussion / Q & A +**\** 4. Any additional meeting items +**\** 5. Confirm next meeting date/time +**\** hola +**\** so greetings +**\** hi! +**\** hi +**\** (here) +**\** also present +**\** hi +**\** I'll be sorta afk for the next 5ish minutes, but I'm around. +**\** ok +**\** 2. Brief review of what's been completed since the previous meeting +**\** so +**\** second meeting of the year +**\** and we've been pushing ahead solidly +**\** we've had a bunch of PRs by newcomers +**\** once you go solid state you never go back +**\** including tpltnt, and IPGlider has also pushed a few PRs +**\** we switched to EasyLogging++, which is a pretty big change +**\** and MoroccanMalinois made Android builds happen +**\** tdprime also pushed their first PR +**\** and then the usual rash of PRs from moneromooo, vtnerd, hyc, NanoAkron, and Jaquee +**\** (I've probably missed someone) +**\** reveler with the background mining +**\** revler +**\** yes thanks pigeons +**\** oh and pigeons had a PR too +**\** kenshi84 disposable addresses +**\** and kenshi84 +**\** ok - anything else major I missed that happened in the last two weeks before we move on to 3? +**\** All the new one time address stuff from knaccc, randomrun, kenshi, jollymort. +**\** yes subaddresses are back! +**\** And luigi. +**\** moneromooo: I was going to get to that in 3 +**\** ok, sounds like we move on to 3 +**\** since it's in the MRL repo +**\** 3. Code + ticket discussion / Q & A +**\** I wasn't following that discussion, focused on study on fees atm +**\** ok so there have been a few long-form discussions going on in various issues +**\** also the one for ring size +**\** yeah the ring size one is one I wanted to bring up +**\** I think the discussion has mostly been positive, nobody's gotten crazy out-of-hand or anything +**\** it *is* a complex topic +**\** and I think that we have enough time to figure out a good route forward +**\** does anyone have an objection to it continuing in the GitHub issue? +**\** seems like all the context is there +**\** so it should continue there +**\** I feel like it's more suitable for an issue under MRL, any thoughts of moving it there (if possible)? +**\** I haven't been following the issue too closely, but is there still some sentiment building around fixing ring size for all txs? +**\** jollymort: I think the GH issue is fine, it can kinda be anywhere, but if we're going to turn that into a publication that explores the various options and reasons for recommendations then it would develop as PRs to the research-lab repo +**\* jwinterm** goes to github +**\** I meant, keep it as a GH issue, but under another repo so it doesn't get buried under all code/bug related issues +**\** as someone not following the issue, it does kind of get lost in the noise with 164 open issues +**\** #1673? +**\** yeah it would be nice if GH let you subscribe to just a single issue +**\** I'm not opposed to moving it to the research-lab repo +**\** how would we do that tho +**\** no idea +**\** someone creates a synopsis of where the discussion is at currently in the new ticket and links back to older ticket +**\** yeah, new text +**\** with @mentions of original participants +**\** ok I'll suggest it in the thread +**\** then on the topic of discussion +**\** I'd like to encourage us to also take some Q&A / discussion items to StackExchange where we can +**\** and to redirect people who open issues to just ask a question to StackExchange +**\** hm, I would expect that SE is for "settled" questions +**\** SE is a great place for canonical information that is updated over years +**\** I'd just like to add that SE is not really a format for discussions, more for things with an actual answer existing +**\** hyc: nope, anyone can edit an accepted answer with new information +**\** like hyc said +**\** there's SE chat, though - which nobody uses +**\** jollymort: some of the questions on GitHub issues are perfect for SE +**\** sure +**\** https://github.com/monero-project/monero/issues/1751 as an example +**\** monero clone? +**\** hyc: probably, I thought that too +**\** but that's a good question for SE +**\** which also has a larger group of answer-ers than the GH repo +**\** it is already answered though, sort of http://monero.stackexchange.com/questions/2886/how-can-i-create-a-new-monero-genesis-block +**\** taushet: yes but SE has tools to close as a duplicate and redirect them to the answer +**\** and moderators can do that without us needing to +**\** fluffypony - agreed. also the 'issue' was not so much an issue with the code as much as it was a question but a user/tinkerer who could not get something to work +**\** anyway +**\** yeah exactly +**\ \** What if someone went through and opened parallel SE questions for all those types of question, redirected the original asker, then we shut the issue? +**\** sounds good +**\** @NanoAkron yes that's exactly my recommendation +**\ \** Ok I might see what I can do if I get any free time tonight +**\** then you even get SE karma or points or rep or whatever it's called +**\ \** Woo! +**\** gamification ftw! +**\** ok anything else under Q&A ? +**\** specific tickets? +**\** like 0MQ PR? +**\** yep I believe tewinget said he had to check if it was working with RingCT +**\** tewinget: ^^ +**\ \** Any thoughts about 0.10.2? +**\** @NanoAkron yes +**\** we've been discussing it +**\** because it will coincide with beta 2 of the GUI +**\ \** Oh nice +**\** as we're marrying daemon / GUI versions +**\ \** Makes good sense. Will #1746 be addressed too? +**\** do you intend to code in stuff for the next HF in 0.10.2? +**\ \** I.e. Auto starting daemon +**\** there are a few things that need to be done in the daemon / GUI before the next release +**\** sry +**\** jollymort: no +**\** we only have to finalise that by like July +**\** just got my second monitor back from a friend, was setting it up real quick. +**\** ok, thanks +**\** @NanoAkron I don't see why we can't make sure 1746 is sorted, Jaquee any thoughts ? +**\** so Snipa was kind enough to chuck a battery of tests at my zmq branch, which is great. It seems there are a couple things I need to look at, which is expected, but his tests seem rather comprehensive, so once those are passing it should be good to go. +**\** Does this keep a backward compat layr for the current JSON API ? +**\** moneromooo: currently it neither replaces nor modifies any current RPCs +**\ \** Esp since the number of rpc commands has increased +**\** moneromooo: long term yes - the current JSON API will be in its own binary, like monero-rpc-server, and that will use 0MQ to communicate with the daemon +**\** but also short-term yes because I haven't done anything to the existing RPCs +**\ \** I heard it would be passing plaintext commands/JSON and not binary. Or am I mistaken? +**\** nanoakron: that is correct, everything is marshalled via json +**\** this is so that higher-level languages have no problem using the RPC +**\** or jaxx :P +**\** as the (de)serialization takes no time at all compared to the computations/fetching +**\** pigeons: hope springs eternal +**\** this is for wallet-style client RPCs only then +**\ \** Doesn't that mean that there are now two sets of commands to maintain in sync - JSON-RPC (won't be deprecated) and JSON-over-ZMQ? +**\** JSON-RPC *will* be deprecated for the daemon +**\** we won't add new RPC commands to it +**\** JSON RPC for the wallet will continue to evolve and exist +**\** because web apps rely on it +**\** communication with the daemon will be relegated to 0MQ only +**\** !bookie no-json-rpc-added-ever-again yes no +**\ \** But in JSON format +**\** aw... +**\** (eventually) +**\** @NanoAkron yes +**\** so existing apps that interact with the daemon, eg. pool software, can continue by adding a 0MQ library +**\** and modifying any calls that have changed +**\** (which won't be many, there were just a few that seemed silly in some ways, and changed accordingly, but none of that is set in stone) +**\** anything else? +**\** or I guess we can include that in the next item on the agenda +**\** 4. Any additional meeting items +**\ \** Neigh +**\** lol +**\** we should use HAY and NEIGH instead of ACK and NACK +**\ \** Lol +**\** I'll keep updating over the next couple days, fwiw. Gotta get with Snipa to see if he can make a couple of modifications to the tests for me to make issues track-down-able, but he's afk until tomorrow. +**\** Hmm, range sig reduction... multisig... fee formula change... +**\ \** Yes +**\** Snipa: are these tests in your github? +**\** oh I have an item for brief discussion +**\** it's not just the fee, penalty needs tweaking +**\** as everyone knows, the dynamic block adjuster isn't adjusting very well since the txs became larger +**\** snipa is afk until tmrw iirc +**\** either by increasing the min. blocksize, or having a transition formula +**\** does everyone think we should leave it as-is until September, with the occasional backlog +**\** or should we have some intermediary hard fork ? +**\** We may need one +**\** If we have a fix now, would be nice to deplot it sooner +**\** deploy +**\ \** But it has to be smart enough to account for potential future changes in range proof and therefore Tx size +**\** it accounts :) +**\** september is a long time away +**\ \** As well as ring size. Txes will become much more standardised in size and non-parametrically distributed +**\** ok I think that's reasonable consensus, as soon as we have something workable we'll put it out to the community as a hard fork and see how they feel +**\ \** So medians etc may not make statistical sense +**\** you could HF at around the time when originally the ringct hf was supposed to happen +**\** nanoakron We are looking at a fall in tx size? +**\ \** Hopefully. Size would fall will range proof improvements, but distribution of sizes would flatten with ring size standardisation. Parametric statistics would no longer apply. +**\** DaveyJones: that's in March, too soon for a planned fork +**\ \** So adjusting based on moving medians would be meaningless. We'd need to deploy alternate statistical tests. +**\** Can you explain that ? +**\** ok +**\** anything else before we close the meeting ? +**\** (we can discuss specifics after the meeting) +**\ \** Even now with a mix of rct and non-rct transactions the median is meaningless because the size distribution is non parametric +**\** it's some typical size which is most important, currently at 13kB +**\** calculate two separate medians. one for rct and one for non-rct. +**\** doesn't matter if it's +/- 1kB +**\ \** It's instead bimodal +**\** sounds like we're done with the meeting side of things then +**\** I mean, if you roll out some change to TX format, you already know the next typical size it will cause +**\** last item is the next meeting time +**\** and you will need to HF anyway, so all you'd need to do is adjust one parameter for the dynamic blocksize/fee +**\** 2 weeks from now +**\** March 5th +**\** cool +**\** I will be on a plane to London, but should have wifi and should be able to attend the meeting +**\** thanks guys \ No newline at end of file diff --git a/_posts/2017-02-23-monero-0.10.2-released.md b/_posts/2017-02-23-monero-0.10.2-released.md new file mode 100644 index 00000000..72f3a2dc --- /dev/null +++ b/_posts/2017-02-23-monero-0.10.2-released.md @@ -0,0 +1,95 @@ +--- +layout: post +title: Monero 0.10.2 "Wolfram Warptangent" Released +summary: A strongly recommended update containing new features & important bug fixes +tags: [releases] +author: Riccardo Spagni (fluffypony) +--- + +*February 23rd, 2017* + +### Overview + +This is a necessary point release of Monero v0.10 "*Wolfram Warptangent*", and is a **strongly, strongly** recommended update as it includes massive efficiency improvements to the RingCT validation code and various other necessary bug fixes. + +Some highlights of this release are: + +- massive speed improvements to RingCT validation +- cache tx hashes for failed txs with bad semantics +- added an update notification / download / verification system (to be expanded to include opt-in auto-updating for unattended daemons) +- initial smart mining implementation (Linux only) +- improvements to IBD (initial block download) and sync speed +- switched to a portable serialiser so that wallet files can be used on any operating system +- added uptime to daemon status +- added support for separated mempool / peer datasets for multiple nodes on the same machine (with different p2p ports) +- added a change_password command to monero-wallet-cli +- addes support for restoring wallets from a certain date +- added mempool prioritisation of older txs +- added fixes to fluffy blocks (not enabled by default on mainnet yet) +- add HTTP digest authentication support to all RPC interfaces +- added a connection limit for incoming connections from the same IP +- switched to EasyLogging++ for logs +- added a gray peerlist house keeping system +- added support for multiple daemons using the same LMDB database +- added additional password prompting for monero-wallet-cli actions +- added additional output detail for ring output selection in monero-wallet-cli +- fixed issues with wallets dealing with large reorgs +- massive additions to libwallet_api for additional functions used by the GUI +- removed support for BerkeleyDB, as it is now deprecated +- added support for Android +- added support for DragonFlyBSD +- fixed armv8 build issues + +### Contributors for this Release + +This release was the direct result of 24 people who worked, largely unpaid and altruistically, to put out 527 commits containing 21 090 new lines of code. We'd like to thank them very much for their time and effort. In no particular order they are: + +- Alexis Enston +- luigi1111 +- Miguel Herranz +- vdo +- anonimal +- kenshi84 +- Dan Miller +- moneromooo-monero +- Ashley Perpetual +- fireice-uk +- MoroccanMalinois +- Riccardo Spagni +- Timothy D. Prime +- moneroexamples +- Jaquee +- Lee Clagett +- Chris Vickio +- Antonio Huete Jimenez +- Howard Chu +- Randi Joseph +- Dion Ahmetaj +- Bitcoin Error Log +- iDunk5400 +- NanoAkron + +### Official Download Links +- [Windows, 64-bit](https://downloads.getmonero.org/cli/monero-win-x64-v0.10.2.0.zip) +- [Windows, 32-bit](https://downloads.getmonero.org/cli/monero-win-x86-v0.10.2.0.zip) +- [macOS, 64-bit](https://downloads.getmonero.org/cli/monero-mac-x64-v0.10.2.0.tar.bz2) +- [Linux, 64-bit](https://downloads.getmonero.org/cli/monero-linux-x64-v0.10.2.0.tar.bz2) +- [Linux, 32-bit](https://downloads.getmonero.org/cli/monero-linux-x86-v0.10.2.0.tar.bz2) +- [Linux, armv7](https://downloads.getmonero.org/cli/monero-linux-armv7-v0.10.2.0.tar.bz2) +- [Linux, armv8](https://downloads.getmonero.org/cli/monero-linux-armv8-v0.10.2.0.tar.bz2) +- [FreeBSD, 64-bit](https://downloads.getmonero.org/cli/monero-freebsd-x64-v0.10.2.0.tar.bz2) +- [DragonFlyBSD, 64-bit](https://downloads.getmonero.org/cli/monero-dragonflybsd-x64-v0.10.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.10.2.0.zip, e852642c42bc9ed6a248fea0e0bb8e9e2563cdf9a4dfdd40b96226a3cadd874e +- monero-win-x86-v0.10.2.0.zip, 8ac825d89f58a07be65f4f96ddd1e22ef4fb9156d28d12381ade6e3a070b18cb +- monero-mac-x64-v0.10.2.0.tar.bz2, 685a0262b9add448a516baac3dc81d2dda559fdba000afcf6480e9b2dddf107b +- monero-linux-x64-v0.10.2.0.tar.bz2, bf27eb173a775b62716b5fd1d1921f81c8d3b91187b190a22f2a6d82811915fd +- monero-linux-x86-v0.10.2.0.tar.bz2, 5ce1475090dfc7897824de62b44771af6de395631540dee6361f0c32a82885ac +- monero-linux-armv7-v0.10.2.0.tar.bz2, 173c4f481587799b0ca8947826778eae75611ef4d6bce765df5915ffa12f91b8 +- monero-linux-armv8-v0.10.2.0.tar.bz2, 26ad255a94d76acdce4e649d19d709181918a47df10ea9d00f9c14acf7b0129f +- monero-freebsd-x64-v0.10.2.0.tar.bz2, fec177e65a07f845cbcf64b7e39de8decee9cb04bf3f603dd38cec3a363f4d90 +- monero-dragonflybsd-x64-v0.10.2.0.tar.bz2, 2026a36e21755f6fb3e5b644fd7e476659bf9f459030c43338994bf12ef9f79f \ No newline at end of file diff --git a/_posts/2017-02-24-monero-0.10.2.1-released.md b/_posts/2017-02-24-monero-0.10.2.1-released.md new file mode 100644 index 00000000..dda27687 --- /dev/null +++ b/_posts/2017-02-24-monero-0.10.2.1-released.md @@ -0,0 +1,99 @@ +--- +layout: post +title: Monero 0.10.2.1 "Wolfram Warptangent" Released +summary: A strongly recommended update to the 0.10.2.0 point release that fixes some RPC issues +tags: [releases] +author: Riccardo Spagni (fluffypony) +--- + +*February 24th, 2017* + +### Overview + +This is a necessary point release of Monero v0.10 "_Wolfram Warptangent_", and is a **strongly, strongly** recommended update as it includes massive efficiency improvements to the RingCT validation code and various other necessary bug fixes. + +Some highlights of this release are: + +- the 0.10.2.1 point release fixes two sets of RPC issues that affected the 0.10.2 point release +- massive speed improvements to RingCT validation +- cache tx hashes for failed txs with bad semantics +- added an update notification / download / verification system (to be expanded to include opt-in auto-updating for unattended daemons) +- initial smart mining implementation (Linux only) +- improvements to IBD (initial block download) and sync speed +- switched to a portable serialiser so that wallet files can be used on any operating system +- added uptime to daemon status +- added support for separated mempool / peer datasets for multiple nodes on the same machine (with different p2p ports) +- added a change_password command to monero-wallet-cli +- addes support for restoring wallets from a certain date +- added mempool prioritisation of older txs +- added fixes to fluffy blocks (not enabled by default on mainnet yet) +- add HTTP digest authentication support to all RPC interfaces +- added a connection limit for incoming connections from the same IP +- switched to EasyLogging++ for logs +- added a gray peerlist house keeping system +- added support for multiple daemons using the same LMDB database +- added additional password prompting for monero-wallet-cli actions +- added additional output detail for ring output selection in monero-wallet-cli +- fixed issues with wallets dealing with large reorgs +- massive additions to libwallet_api for additional functions used by the GUI +- removed support for BerkeleyDB, as it is now deprecated +- added support for Android +- added support for DragonFlyBSD +- fixed armv8 build issues + +### Contributors for this Release + +This release was the direct result of 24 people who worked, largely unpaid and altruistically, to put out 527 commits containing 21 090 new lines of code. We'd like to thank them very much for their time and effort. In no particular order they are: + +- Alexis Enston +- luigi1111 +- Miguel Herranz +- vdo +- anonimal +- kenshi84 +- Dan Miller +- moneromooo-monero +- Ashley Perpetual +- fireice-uk +- MoroccanMalinois +- Riccardo Spagni +- Timothy D. Prime +- moneroexamples +- Jaquee +- Lee Clagett +- Chris Vickio +- Antonio Huete Jimenez +- Howard Chu +- Randi Joseph +- Dion Ahmetaj +- Bitcoin Error Log +- iDunk5400 +- NanoAkron + +### Official Download Links + +- [Windows, 64-bit](https://downloads.getmonero.org/cli/monero-win-x64-v0.10.2.1.zip) +- [Windows, 32-bit](https://downloads.getmonero.org/cli/monero-win-x86-v0.10.2.1.zip) +- [macOS, 64-bit](https://downloads.getmonero.org/cli/monero-mac-x64-v0.10.2.1.tar.bz2) +- [Linux, 64-bit](https://downloads.getmonero.org/cli/monero-linux-x64-v0.10.2.1.tar.bz2) +- [Linux, 32-bit](https://downloads.getmonero.org/cli/monero-linux-x86-v0.10.2.1.tar.bz2) +- [Linux, armv7](https://downloads.getmonero.org/cli/monero-linux-armv7-v0.10.2.1.tar.bz2) +- [Linux, armv8](https://downloads.getmonero.org/cli/monero-linux-armv8-v0.10.2.1.tar.bz2) +- [FreeBSD, 64-bit](https://downloads.getmonero.org/cli/monero-freebsd-x64-v0.10.2.1.tar.bz2) +- [DragonFlyBSD, 64-bit](https://downloads.getmonero.org/cli/monero-dragonflybsd-x64-v0.10.2.1.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.2.1.zip, 7089ea94fdb59e2c171fb5548e5d3b560057d78a29125b8fbe8c09739e95dc2f +- monero-win-x86-v0.10.2.1.zip, 2d31be49a7003e66923cad41f59646d7241bfd4ec9c607dfd34e08b235b82e33 +- monero-mac-x64-v0.10.2.1.tar.bz2, a13299bcf11cdcaeafa0c19ef410cb27020def501345ab03a939ddcfb8a20de7 +- monero-linux-x64-v0.10.2.1.tar.bz2, 9edba6ca91c35c6c2eb6816f9342931c88648de5beb471943ea63d0b16c9a2e4 +- monero-linux-x86-v0.10.2.1.tar.bz2, 4901d2633a7bdd20504ff1b7c719ac5e9eb43a1f497103766f8333d7c18f30b5 +- monero-linux-armv7-v0.10.2.1.tar.bz2, ad6bccc0b738e5becc0191fea2c55529835df042919ef8df60033f8e84c28a9d +- monero-linux-armv8-v0.10.2.1.tar.bz2, c0ab2be3e81e7b3928f98d84c60ac2a7f42dfd581357873a42bfcbc867a4e39a +- monero-freebsd-x64-v0.10.2.1.tar.bz2, b0f0baf0947a77523a3a8c8686f645ada792fd44c6211f0c34322cfd22aab0cb +- monero-dragonflybsd-x64-v0.10.2.1.tar.bz2, 7db1f37f6c59f05bf6dec65a32d6c82339fd9386805b9f04082c37c85ef1002e + +A GPG-signed list of the hashes is at https://getmonero.org/downloads/hashes.txt and should be treated as canonical, with the signature checked against the appropriate GPG key in the source code (in /utils/gpg_keys) \ No newline at end of file diff --git a/_posts/2017-03-12-overview-and-logs-for-the-dev-meeting-held-on-2017-03-12.md b/_posts/2017-03-12-overview-and-logs-for-the-dev-meeting-held-on-2017-03-12.md new file mode 100644 index 00000000..0c205515 --- /dev/null +++ b/_posts/2017-03-12-overview-and-logs-for-the-dev-meeting-held-on-2017-03-12.md @@ -0,0 +1,335 @@ +--- +layout: post +title: Overview and Logs for the Dev Meeting Held on 2017-03-12 +summary: C++11, 0.10.2.2 release, and dynamic block size algorithm +tags: [dev diaries, core, crypto] +author: dEBRUYNE / fluffypony +--- + +*March 12th, 2017* + +### Overview + +An overview [can be found on MoneroBase](https://monerobase.com/wiki/DevMeeting_2017-03-12). + +### Logs + +**\** 1. Greetings +**\** ok cool +**\** agenda is at https://github.com/monero-project/meta/issues/51 +**\** so to start, 1. Greetings +**\** hi +**\** Hi +**\** 2. Brief review of what's been completed since the previous meeting +**\** so mostly fiddly bits as we get ready for the 0.10.2.2 tag and release +**\** but we'll discuss that more in 4 +**\** so 3. A discussion of PR 1816, & perhaps a more general discussion of C++ templating etc. +**\** relevant link: https://github.com/monero-project/monero/pull/1816 +**\** so part of the ongoing discussion happening there is "how much C++11 do we adopt" +**\** and part of the discussion I wanted to have today is "how maintainable is C++11 for us" +**\** Maybe it's a bit less about C++11 and more about making things overcomplex. +**\** yes +**\** A bit of both I guess. +**\** so if I may, I thought I'd give my largely uninformed opinion, and then I'd particularly like to hear what hyc and moneromooo and tewinget and others feel +**\** I feel that a lot of this ties into our long-term goals as developers and contributors to the Monero Project, and where we'd like to take things +**\** some of this code complexity leads to easier management later on, but requires a steep learning curve now +**\** I'm not up on the latest in C++. so when it comes to deciding what features to adopt, I'll stay out of it +**\** or requires things to be a little harder to manage now, but this leads to an easier to manage set of classes / functions / etc. later on +**\** Are you saying that the code being more complex makes easier to maintain later ? +**\** IMO though most of this stuff is complex syntax for things that have much simpler approaches already +**\** OK, I can buy that. +**\** fluffypony: "this code complexity leads to easier management later on" <-- is that true for touching part of this very code too? Seems to be the opposite +**\** but if our goal is just to "maintain" the current code base with a view to rewriting later, then obviously this is a silly exercise right now +**\** so part of this discussion really comes down to: do we, as developers, feel that we can evolve this code to a modular, manageable set of libraries and tools? or is that a pipe dream and a parallel rewrite is a better idea? +**\** I think these are separate things (or easily separatable anyway). +**\** You can do modular/manageable with simple code and complex code, and spaghetti/unminageable with simple and complex code. +**\** My question here is: Which approach is the least likely to introduce bugs? +**\** So let's do one at a time. +**\** do you guys know of Rich Hickey and his view/definition of simple vs complex, easy vs difficult? +**\* moneromooo** feels wary +**\** I think a parallel rewrite is the way to go. least chance of breaking the current code base. +**\** least intrusive overall until we have something workable on the rewrite +**\** hyc just wants to rewrite everything in C :-P +**\** well. yeah ;) +**\** is a rewrite too ambitious a goal? do we want resources to focus on that and the current codebase effectively plateaus? +**\** (bearing in mind that there are lots of bits we can re-use, such as vast portions of the crypto / blockchainDB stuff) +**\** I'd rewrite bit by bit, if you want to rewrite. +**\** good question. I tink a rewrite is low priority until the curent codebase does everything we want. i.e., multisig + kovri and whatever else +**\** is vtnerd here? last week he had the most to say about c++ technique. The main concern was who else is comfortable with review +**\** Look at 0mq, which is a rewrite of just the RPC protocol. It's been a year or something. +**\** true +**\** I and prolly many others have no grasp of the actual usage of epee in code base. What sort of workload are we talking about to replicate? +**\** ball park +**\** Shitloads :) +**\** 0MQ's kinda a bad example, moneromooo - tewinget has had stuff on his plate that has interrupted his ability to work on Monero +**\** Besides you have to have both work in the same binary if you want to fork from one to the other at some point. +**\** but in principle, yeah, this is a multi-year project +**\** ok... +**\** moneromooo: I wonder if we couldn't pull the project in as a submodule and just reference the common files in it that we need? +**\** well, if someone were on it full time it wouldn't be so bad +**\** Sure, and my default view, unless proven wrong, is that it'd DoS us. +**\** pigeons: I've pinged him, but he's not here atm +**\ {-olark}** I agree with hyc. A rewrite in C should only become feasible once the current codebase is "feature-complete" kovri, multisig, 0mq etc etc +**\** olark: the opposite might be true - the more "features" we add the harder it is to rewrite +**\** what if we approached it differently +**\ {-olark}** If what is being worked on can be ported to C without technical debt that is good too. +**\** what if we have a new project whose focus is to build libraries out +**\** so maybe it starts with a consensus library that can validate txs and blocks, and knows how to build txs and blocks +**\** that’s almost exactly what i was typing +**\** and then the main Monero project uses that +**\** sounds reasonble +**\** and eventually the project becomes a collection of files that can be dropped because they're no longer needed, and just dumb interfaces that hook into libs +**\ {-olark}** A slow transition would be ideal +**\** at that point their internal implementations can be replaced with C etc right? +**\** So the rewrite is done library by library +**\** it would be massively unrestricted, since everything is created from scratch and could even have (gasp) whitespace fixes +**\** I was thinking about refactoring the blockchainDB stuff. it should all be hidden behind an interface class. nobody outside of blockchainDB should be including db_lmdb.h or instantiating blockchainLMDB direcftly +**\** I'm not against doing it in C, and that is super portable, but by going that low-level on everything aren't we also making it harder on ourselves? +**\** hyc: I agree with that +**\** did not intend to suggest C whatsoever +**\** endogenic: too late :-P +**\** right, pure C is my personal goal. I wouldn't impose that on the project. +**\** tbh, the idea of spending shitloads of time and effort to replace with the same, in a way that hardforks every single part of the consensus seems outrageous. The only reason it doesn't is because the dangling prize (a nice, bug free C implementation which didn't fork) is not. +**\** are you saying too much risk for too little reward? or possibility of no reward? +**\** well let's be brutally honest here: we didn't write this code, and parts of it are well-written whilst others are simply *not* +**\** (didn't write it initially I mean) +**\** Too much risk for a reward that's not too easy to quantify. +**\** we’ll prolly be well served by enumerating exactly what interfaces we would need (i.e. solutions to what problems) in the process of judging risk-reward - cause there may be low hanging but high value fruit +**\** perhaps we need to consider it this way: at what point do we NEED a massive rewrite that gets rid of all the technical debt? +**\** yeah, sounds like we need an actual review. +**\** like I can't imagine there still being dredges of epee in 10 year's time +**\** look at all of the existing code, draw high level boxes around pieces that make sense. +**\** After features required for decent growth of the ecosystem are there, imo +**\** then walk away, if you zoom in on the boxes again, does the layout you would reasonably expect to see match what exists. +**\** So answer depends with you would trade those efforts against +**\** what +**\** so the assumption is that the code we have now actually works. i.e. is solid enough to continue building on top. +**\** hyc: perhaps that answer leads us to the next point in the meeting +**\** so let's open that up so that it can form part of the discussion +**\** 4. A Series of Unfortunate Events: the v0.10.2.x release failures, massive regressions, and serious issues. How do we do better in future? +**\** given how many issues we've had with 0.10.2.x, IS the code solid enough? +**\** This whole thing is assuming that a rewrite would be bug free, which is a preposterous assumption. +**\** true, most ground-up rewrites are worse than what you started with +**\** issues in 0.10.2 are due to new stuff not old ones, no? +**\** We'd have to go find a list, but I think so, mostly. +**\** moneromooo: no no, not bug free, but something with a more complete test suite, and easier to review / manage +**\** Writing more tests is completely independent of rewriting. +**\** i am writing a few applications in Swift, and I had to create a lot of C bindings to the C++ code. +**\** It would have been so much easier if the codebase was just C... +**\** ^^ for cross-language portability our public APIs should be C +**\* fluffypony** ponders +**\** the Swift framework for LMDB has been easier to get up and running +**\** not sure how we could have tested more. the batch-txn changes had been in testing for a couple months +**\** I have a suspicion that going C-only would somewhat restrict our potential contributor base +**\** Why ? +**\** with several live blockchain reorgs and no problem. had no way to suspect a race condition was lurking. +**\** Surviving in C is possible for every C++ coder, but writing proper C for cryptocurrency software, not +**\** moneromooo: I know competent C++ developers who are mediocre when working solely in C +**\** As hyc said, at least have a strong C api available +**\** sure +**\** You can do crazy sneaky things in C in terms of malicious commits, look at the contests for that it's fun. +**\** I agree with that +**\** C++ too... +**\** Reviewers able to catch that, you'd have way less of them than in C++ +**\** moneromooo not if you expect writer to write proper C++, then it's obvious if it's going low-level unnecessarily +**\** WTF. +**\** Why are half the reasons given above completely suprious ? +**\** I think we need to back away from C vs C++. the codebase is primarily C++ now. +**\** we deal with what we have. +**\** i agree. porting to C for whole codebase seems an answer in search of a problem - bound to go badly - is it an API issue? or is it a performance issue? can C by applied selectively, establishing standalone libs, while enabling us to maintain the expertise, past testing, etc of the existing codebase? +**\** moneromooo: spurious? +**\** imo the biggest problem coming into monero initially for me was “how do i integrate with this?” or “what specifically do i integrate with?” +**\** Maybe not the right word, but... I feel like half the reasons for a choice given by people above either don't apply, or also apply to the other choice. +**\** api issue +**\** Like, you don't need C to write tests. +**\** moneromooo: no I was asking if that's what you meant, you said "suprious" :) +**\** Or if you require "proper C++", then you should require "proper C" when comparing maintainability of both. +**\** Oh yes, spurious. +**\** well look, I'd like Monero to become a collection of well written, well documented libraries, with bindings in many languages +**\** yes, fine. +**\** spurious arguments really get a pony going +**\** :D +**\** so the public side of the API should be C, even if the rest of the code is C++ +**\** moneromooo yes and I was saying there is less people able to do that in C than in C++ +**\** lol endogenic +**\** do we really need integration at the object code level? wouldn't most integrations be via RPC? +**\** hyc: no, not for libraries +**\** To write underhanded code ? +**\** hyc: one problem i found was needing to use the wallet2.cpp code +**\** consider a client written in Go that just wants to use the consensus library +**\** still have that issue - Snipa did too +**\** @fluffy yes. a lot of libraries is the key +**\** yeah +**\** actually I've started writing that in C to do the LMDB version +**\** moneromooo less people to review and prevent people to write underhanded code +**\** ok so being able to hook into things at an object code level is a requirement +**\** also as an idea +**\** what if the "rewrite" / refactor / library effort happened in the source tree? +**\** hmmm. binaryFate - in that regard, C++ *is* a superset of C. so if you can't recognize underhanded code in C, you wouldn't have seen it in C++ either. +**\** Less people to review C for underhanded code, than people to review C++ for underhanded code. Assuming we require proper/nice code for both (otherwise this is a spurious argument). Maybe. It doesn't sound like a very convincing argument though. +**\** hyc for most part of the code a commiter is expected to work at a level of abstraction that is way above that of C +**\** fluffypony wdy mean +**\** I'd be fine with a part-by-part rewrite as we go, as I said above. +**\** there was a discussion of c++ and crypto on hn in the last week - wondering if anyone has seen it. if not, i'll drop a link after the meeting +**\** hyc: instead of a parallel rewrite in a separate project, it can be done in the source tree in a separate directory, and can rewrite / move files into that directory, as long as references are adjusted accordingly +**\** tks pero that would be appreciated +**\** strikes me as being hard to coordinate, but ok +**\** I'd keep them both plugged, and fork on a height. Because they're bound to behave differently in corner cases. +**\** (for the consensus changes anyway, the rest can be changed at once I guess) +**\** moneromooo: then it may as well be done in a separate project, unless there's another reason to keep it in the source tree? +**\** Yes, because people won't exit monerod-c++ and restart monerod-c at the fork height all at once. +**\** doing it in the source tree... you'd have to be working on parts of the codebase that are basically set in stone at this point, or else really keeping up with codebase, no? otherwise, wouldn't it end up like some of the other things that have been worked on in a branch that then cause merging to be hell? I don't really know what I'm talking about, but that's been what it's seemed like on a few things fro +**\** m an outside perspective at least... +**\** yeah that's what I meant about tough to coordinate +**\** But maybe I missed the point you brought fluffypony ? +**\** bigreddmachine: yes it would cause merging hell, but we merge PRs quickly enough that it shouldn't be terrible +**\** when I've done this scale of changes on past projects, it was only after a code freeze. feature freeze. +**\** moneromooo: well I was thinking about the way we did the blockchainDB +**\** we first created this generic class +**\** and then did the LMDB implementation for that +**\** which is why I wouldn't bother to start here until we have kovri etc. +**\** found it quicker than i thought i would - https://news.ycombinator.com/item?id=13807693 +**\** and THEN went back and did the in-memory implementation for that class +**\** There was no fork for this, right ? People updated mostly at the same time, but with a long tail ? +**\** yes +**\** so the in-memory interface went from being *the thing you use* to having all its functions updated to exist behind blockchainDB +**\** which was effectively a refactor effort, more than anything else +**\** I kinda like doing it like that. Though the swapping at a fork adds security. +**\** yes 100% +**\** especially for libmonero-consensus or whatever +**\** ok. that sounds good for mid to long term +**\** what do we need to do now, for 10.2 ? +**\** why the need to swap at a fork? if the new implementation isn't 100% compatible, wouldn't it break on a resync when inspecting older-than-the-fork blocks? so fork or no, if there's a bug it's a mess? +**\** bigreddmachine: a corner case can come up 6 months after deployment +**\** before I get to hyc's question +**\** That seems to assume a non adversarial system. +**\** fluffypony: so a fork lets you make sure it's compatible for everything to date, but if a corner case came up later, the old version wouldn't matter? +**\** since vtnerd is playing around with the library stuff (conceptually), any objection to him working on this? we kinda want the library stuff for the lightweight remote wallet tool (ie. open-source MyMonero-like stuff) +**\** bigreddmachine: if you don't do it at a fork height then the old version might be widely deployed +**\** yep, okay makes sense, thanks +**\ \** moneromooo I’m not seeing any INFO messages about ‘synchronised OK’ or ‘new block candidate’ etc. at log-level 1 +**\** I'm fine with that, sure. I'd ask to not rewrite too much stuff at once, though, just because it DoSes reviewers. +**\** Especially when the code is damn hard to read/review :/ +**\** heh +**\** moneromooo: ok agreed +**\** I'll also ask him to consider manageability / reviewability +**\** (by people who don't know much recent C++) +**\** I'm sure he can't review it quickly :P +**\** er, can. +**\ {-JJAbr}** all in Matlab, I suggest +**\** LOL +**\** JJAbr - I can finally review something! +**\** there's an LMDB driver for Matlab, fine with me :P +**\** For future things to discuss, I think it would be best if we could discuss them one at a time when they're not intertwined. +**\** Like, test coverage is unrelated to C or C++, rewrite or not. +**\** true +**\** Just merging them makes it harder to decide each. +**\ {-JJAbr}** I'm not joking +**\** I think we got sidetracked by C vs C++ +**\** JJAbr: when we have more libraries then that's fully feasible +**\** moneromooo: that's fair +**\ {-JJAbr}** I'm somehow visionary, write it to Matlab, generate it into C/c++ +**\** I think we should fork Rust and create our own programming language +**\ {-JJAbr}** check it with Polyspace, and it works +**\** with blackjack and hookers +**\** About tests, there's a set of functional tests that's long dead. It does transfers using wallet2 and daemon. +**\** OK, nevermind. +**\ {-JJAbr}** Visionary = see what automotive world currenty do +**\ {-JJAbr}** does +**\** so confused +**\** automotive world writes millions of lines of code just to control an engine. that's not a good model. +**\** who is working on the ethereum solidity port? :P +**\** i am +**\ {-JJAbr}** "just to control an engine" = simple? +**\** JJAbr: this is a dev meeting tho +**\** can we chat afterwards? +**\ {-JJAbr}** you don't know what youìre talking about +**\ {-JJAbr}** anyways, sorry for the disturb +**\** motion to move to next topic +**\** ok +**\ {-JJAbr}** you're talking about refactoring? do you know about what're you talking about? +**\** JJAbr: yes +**\** thanks +**\** 5. Code + ticket discussion / Q & A +**\ {-JJAbr}** ok +**\ {-JJAbr}** sorry to all +**\** so going back to hyc's question +**\** we're ready to tag 0.10.2.2 +**\** except for the race condition stuff +**\** and I think there are two PRs that I need to merge +**\** if we get the race condition stuff done tonight then we can tag and re-start builds, finalise actual release tomorrow +**\** And a fix for the fluffy block thing smooth found earlier today. +**\** isn't that odd, fluffy blocks shouldn't have been live on mainnet yet +**\** Some people have been enabling it on mainnet anyway. +**\** ok +**\** Which, in this case, is good, because we found a couple bugs without having it fully on :P +**\** note fluffypony in front of me is busy IRL +**\** sorry about that +**\** so to move on to 6. Any additional meeting items +**\ \** Hope you get to see Bruges sometime FP - lovely city +**\** does anyone have anything else to add? +**\ \** Not here +**\** I think we have a fairly good idea as to how we can move forward, and also what's required for the release +**\** cool +**\** which brings us to 7. Confirm next meeting date/time +**\ \** :) +**\** March 26th? +**\** 2 weeks from now +**\** Well, we've not talked about how to make things sturdier. +**\** well +**\** I think the current release is obviously urgent, as it fixes bugs +**\** Except when I started mentioning existing tests, but chat was spammy so got dropped. +**\** but maybe the next release we need to set some testnet time frame +**\ \** What would you like to see implemented on that front moneromooo? +**\** like freeze it, and then do 4 weeks on testnet +**\** can always tag an older commit +**\** There's also a possibility to branch when doing a release, so you can cherry-pick simple fixes. +**\** That way, simple fix releases don't also come with new features that can also be buggy. +**\** as long as the version's bumped +**\** branching it for testing is not a bad idea +**\** Also, there aren't too many people on testnet, so stuff just ends up being tested on mainnet when it's released anyway (beyond obvious stuff). +**\** nanoakron: those tests aren't run, they've been disabled for a long while, I have no idea if they even work. +**\** It was already a fairly massive effort to bring all the core tests back to life... +**\ \** Oh right +**\ \** Eek +**\** I think 0MQ RPC tests would be nice, since everything's changed there AFAICT. +**\** Why not discuss this on a release-basis prior to release rather than fixing principles? Sometimes a long freeze may be superfluous, but for instance something touching fees and block sizes could use thoroughly-discussed different conditions on testnet +**\** Something which might be helpful is a user simulator. +**\ \** Unfortunately @binaryfate the fee/block size issue, whilst it really really should be analysed and studied for a while to ensure it’s the right solution for the long run, is hindering us from growing capacity now :( +**\** But one could take a two stage approach on the fee blocksize issue +**\** A one time increase to 250000 byte min blocksize and adding the 4x fee level +**\ \** +1 +**\** moneromooo: user simulator, as in something just creating random txs and such? i'm happy to make that and run on my desktop. it's already connected to testnet +**\** Then apply jollymort's proposal from 25000 to 125000 as the second stage +**\** moneromoo: a user simulator can be written as a system of time dependent differential equations +**\** bigreddmachine: yes, something that actually tests the testnet. Snipa has one. It's best when run on a local testnet though, so as not to spam the main one too much :) +**\ \** @ArcticMine @jollymort ok :) +**\** does testnet need nodes? +**\** This allows more careful review of 2) while addressing the immediate issue also +**\ \** 250kB would make a huge difference by itself; it would reduce the min.fee 4-times and reduce the size issue +**\ \** so you could set a x4 as the default +**\ \** and it would be the same old 0.3$ +**\ \** then, the pools could use the min.fee +**\** i was working on a testnet faucet - it's basically done, just need to deploy - but i could easily add something that just sends out a tx or two every 5 minutes or something like that, just to create some volume +**\ \** and normal users the x4 fee +**\ \** so normal users never wait +**\ \** and pool payments sit in the mempool until regular users clear out +**\** Without an increase in the default fee +**\ \** What we don’t want is to be stuck in some philosophical rut like a certain other cryptocurrency…we need agreement (which I’m pretty sure we all have) that an algorithmic determination of block size is better than a human one +**\ \** we have that, but we made a unintended anomaly +**\ \** exibit: https://raw.githubusercontent.com/JollyMort/monero-research/master/Monero%20Dynamic%20Block%20Size%20and%20Dynamic%20Minimum%20Fee/Images/Fig3.1-7.png +**\ \** no wait, wrong chart +**\** an increase in tx size to ~13000 bytes from ~500 bytes +**\ \** Yes, and a binomial distribution thereof +**\ \** this one: https://raw.githubusercontent.com/JollyMort/monero-research/master/Monero%20Dynamic%20Block%20Size%20and%20Dynamic%20Minimum%20Fee/Images/Fig3.1-6.png +**\ \** the spike was introduced solely by RCT +**\** The user simulator I have isn't particularly complex. I may see about writing a more complex one in the future if it's something we need. +**\ \** the green one was pre-RCT +**\** Dunno if we need more complex for now. Yours did find bugs already :) +**\ \** with 250kB that spike would surely be less severe +**\** That is why I propose the two stage approach +**\ \** i can draw the charts if you want +**\ \** make it part of the paper, too +**\** can we formally end the meeting and take meeting bot offline? +**\** we're getting out of meeting stuff anyway +**\** Sure \ No newline at end of file diff --git a/_posts/2017-03-25-monero-0.10.3-released.md b/_posts/2017-03-25-monero-0.10.3-released.md new file mode 100644 index 00000000..c4d4691a --- /dev/null +++ b/_posts/2017-03-25-monero-0.10.3-released.md @@ -0,0 +1,88 @@ +--- +layout: post +title: Monero 0.10.3 "Wolfram Warptangent" Released +summary: A mandatory update that is ready for the April 15th hard fork +tags: [releases] +author: Riccardo Spagni (fluffypony) +--- + +*March 25th, 2017* + +### Overview + +This is a necessary point release of Monero v0.10 "_Wolfram Warptangent_", and it is a mandatory update due to the April 15th hard fork, which in turn has been necessitated by the unexpectedly high adoption rate of RingCT transactions necessitating a modification of the dynamic block size limiter algorithm. + +In addition, this is the first version that aligns CLI and GUI tags, with the CLI being tagged and released first, and the GUI tagged and released within a few days thereafter. This will mean that some point releases in future may be forced by a need on the GUI side, where the CLI may not have substantial changes, and vice versa. + +Since it has only been 30 days since the last release, this is something of a "light" update. Nonetheless, some highlights of this release are: + +- fixed a major bug that could lead to some peers, seemingly randomly, getting stuck at a block height and refusing to accept further blocks +- monero-wallet-cli (and underlying libraries) can now work in a number of units: monero, millinero, micronero, nanop, piconero +- added OpenAlias support to wallet RPC calls +- fixed hardcoded seed fallback issues when DNS seeds have failed or too few seeds are returned +- added an optional config file for wallets +- added an additional non-interactive foreground mode for the daemon +- added mnemonic wordlists for French and Dutch +- per-kb fee quantized to 8 decimal places +- added a password function to monero-wallet-cli to allow for a wallet password to be changed (and all files re-encrypted) +- added a cache on the wallet to avoid re-scanning mempool txs already scanned +- improvements to auto-update functionality, including a download-and-verify mechanism +- fixes to a number of logs shown in the daemon by default +- massive API changes to support new features in the GUI +- as always, loads of bug fixes and performance improvements + +### Contributors for this Release + +This release was the direct result of 24 people who worked, largely unpaid and altruistically, to put out 189 commits containing 5 705 new lines of code. We'd like to thank them very much for their time and effort. In no particular order they are: + +- Christoph Schnerch +- Jaquee +- NanoAkron +- Arne Brutschy +- assylias +- lethos3 +- rockhouse +- Roy Jacobs +- stoffu +- adot23 +- Riccardo "fluffypony" Spagni +- Noah Watkins +- Lee Clagett +- xmr-eric +- Howard "hyc" Chu +- Derek Zhang +- Gareth +- Gingeropolous +- darentuzi +- Akademik Prokhor Zakharov +- Guillaume Le Vaillant +- moneromooo-monero +- Miguel Herranz +- kenshi84 + +### Official Download Links +- [Windows, 64-bit](https://downloads.getmonero.org/cli/monero-win-x64-v0.10.3.0.zip) +- [Windows, 32-bit](https://downloads.getmonero.org/cli/monero-win-x86-v0.10.3.0.zip) +- [macOS, 64-bit](https://downloads.getmonero.org/cli/monero-mac-x64-v0.10.3.0.tar.bz2) +- [Linux, 64-bit](https://downloads.getmonero.org/cli/monero-linux-x64-v0.10.3.0.tar.bz2) +- [Linux, 32-bit](https://downloads.getmonero.org/cli/monero-linux-x86-v0.10.3.0.tar.bz2) +- [Linux, armv7](https://downloads.getmonero.org/cli/monero-linux-armv7-v0.10.3.0.tar.bz2) +- [Linux, armv8](https://downloads.getmonero.org/cli/monero-linux-armv8-v0.10.3.0.tar.bz2) +- [FreeBSD, 64-bit](https://downloads.getmonero.org/cli/monero-freebsd-x64-v0.10.3.0.tar.bz2) +- [DragonFlyBSD, 64-bit](https://downloads.getmonero.org/cli/monero-dragonflybsd-x64-v0.10.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.10.3.0.zip, 37a57d1be81b6119ac06d3f637b4c56fc625f3e790f3491c1bdca4d62902bf13 +- monero-win-x86-v0.10.3.0.zip, 7f95bdcf4df232f37c450523831f36ccb9fdb2e50c1b5b0a5285d50549d273be +- monero-mac-x64-v0.10.3.0.tar.bz2, 8e6170f274e69010bbe662d8828c8e4b0b4acdb0a1a3699b5b97af8c3a516a94 +- monero-linux-x64-v0.10.3.0.tar.bz2, f164112bea75dfd3eaaa905d21129820a996bbe6e5d65cb194609c672a71c3fe +- monero-linux-x86-v0.10.3.0.tar.bz2, b8bd258b828d8ea45a7c2595187c13b5e624f45ae929cb64ac89e3a030302316 +- monero-linux-armv7-v0.10.3.0.tar.bz2, 03b2f3f30c7d047142cbfcd614762f3d165d64464e3e5b1a5b0c42aba9570d6a +- monero-linux-armv8-v0.10.3.0.tar.bz2, 6b29c56ca8d71f23f13b68d48e39e35b1d7c7c212cf00f3d58b0d2d9b6435c4c +- monero-freebsd-x64-v0.10.3.0.tar.bz2, 834b56efccc5ab0985c7f870449704ba390c79104ecfc0b63935dfb4f70c6cf9 +- monero-dragonflybsd-x64-v0.10.3.0.tar.bz2, 4ab5b2a745ca5ea4cad253166ff80ff60bb4871f6c8fa81ff032cdf237f6e372 + +A GPG-signed list of the hashes is at https://getmonero.org/downloads/hashes.txt and should be treated as canonical, with the signature checked against the appropriate GPG key in the source code (in /utils/gpg_keys) \ No newline at end of file diff --git a/_posts/2017-03-26-logs-for-the-Kovri-dev-meeting-held-on-2017-03-26.md b/_posts/2017-03-26-logs-for-the-Kovri-dev-meeting-held-on-2017-03-26.md new file mode 100644 index 00000000..3b9f7fae --- /dev/null +++ b/_posts/2017-03-26-logs-for-the-Kovri-dev-meeting-held-on-2017-03-26.md @@ -0,0 +1,246 @@ +--- +layout: post +title: Logs for the Kovri Dev Meeting Held on 2017-03-26 +summary: Brief review of what has been completed since last meeting, Monero HackerOne Bounty, and code & open tickets discussion +tags: [dev diaries, i2p, crypto] +author: dEBRUYNE / fluffypony +--- + +*March 26th, 2017* + +### Logs + +**\** 1. Greetings +**\** 2. Brief review of what's been completed since the previous meeting +**\ {-vtnerd}** oh I guess there is one more thing. the backend was going to hopefully push updates to connected clients +**\** 3. Monero HackerOne Bounty https://www.reddit.com/r/Monero/comments/5zmywx/monero_bounty_for_hackerone/ +**\ {-fluffypony}** ok anonimal, all yours +**\** 3. Code + ticket discussion / Q & A +**\** 4. Any additional meeting items +**\** 5. Confirm next meeting date/time +**\** Greetings. +**\** hey! +**\** Hi +**\ {-olark}** o/ +**\** Sweet olark +**\ {-olark}** Yeah I missed the monero meeting unfortunately :/ +**\ {-olark}** I'll read the logs +**\** Really good meeting +**\** On topic please +**\** 2. Brief review of what's been completed since the previous meeting +**\** https://forum.getmonero.org/9/work-in-progress/86967/anonimal-s-kovri-full-time-development-funding-thread?page=&noscroll=1#post-90733 +**\** ^ for a summary on my part +**\** moroccanmalinois has done some great work since the previous meeting. We have a new utility binary with multiple features. He's also done work elsewhere in the codebase. +**\** :) +**\** guzzi has also contributed to the utility binary. guzzi can you link to your FFS if you're doing work summaries/reports? +**\** What does this utility binary do, in a nutshell ? +**\* anonimal** wants to say ./kovri-util -h +**\** I will add summary tonight +**\** On phone +**\** OK, I'll try to pull someday and check :P +**\** guzzi: then give us a tl;dr for point 2. please +**\** moneromooo base32, base64, routerinfo( reads a RI file) and su3file (reads an su3file) +**\** and the crypto benchmark +**\** Added benchmarks to utility +**\** guzzi: I already said that, didn't you do other things too? Like research, etc.? +**\** Starting in on instance class refactor a d todos +**\** Researched address book for possible lmdb +**\** Sgould be easy +**\** Should +**\** What should be easy? None of that looks easy... +**\** Anyway, we'll save that for later. Anything else on point 2.? +**\** Relatively easy from db perspective. Difficult from kovri perspective yes +**\** 3. Monero HackerOne Bounty https://www.reddit.com/r/Monero/comments/5zmywx/monero_bounty_for_hackerone/ +**\** fluffypony: ^ thoughts? +**\ {-fluffypony}** so my thoughts is that we should just do a general fund across all the projects +**\ {-fluffypony}** because HackerOne let's us basically apportion stuff as needed +**\ {-fluffypony}** so we don't have to give out the entire bounty for some stupid XSS attack +**\** Ok. I'll have to talk with them about setting up Monero. Do we include the GUI into /monero or create /monero-gui? We can probably wrap it into /monero if needed. Do we create /monero-site ? +**\ {-fluffypony}** anonimal: everything goes under the Monero umbrella / bounty, right? +**\ {-fluffypony}** just that each actual sub project can be represented +**\** I'm speaking purely about H1 accounts. +**\** We do whatever we want with fund management. +**\** fluffypony: it's possible but then all monero developers have access to all bug reports for all subprojects +**\** So that brings up a trust issue. I'm fine with the idea but it should be mentioned. +**\ \* fluffypony** ponders +**\** Also I'd like to have access to the account as account holder. This is something I couldn't do if we throw into one account. +**\** And whoever is the account holder for all subprojects has *that* responsibility. And if the single account is ever compromised... +**\** In other words, it's not very decentralized in terms of who controls accounts. +**\ {-fluffypony}** anonimal: doesn't really matter if it's compromised, because there's no money there? +**\** fluffypony: it's about access to reports. If we don't care about who has access to reports, then there's not much reason to use HackerOne +**\ {-fluffypony}** mooneroo: for the monero-project GitHub account the core team all have the password, because there's no easy way to share that control otherwise - could we not do the same for H1? +**\** I mean, there are features/benefits, but access to vulnerabilities is a big issue. +**\ {-fluffypony}** amongst maintainers I mean +**\** pinging mooneroo or moneromooo? +**\** We could do that I think. +**\** Well, some members of hte monero core team are pretty much inactive AIUI. So no need to get them access to this. +**\ {-fluffypony}** whoops +**\ {-fluffypony}** I meant anonimal +**\ {-fluffypony}** sorry ignore typo +**\ {-fluffypony}** anonimal: for the monero-project GitHub account the core team all have the password, because there's no easy way to share that control otherwise - could we not do the same for H1? +**\ {-fluffypony}** moneromooo: would be among maintainers +**\ {-fluffypony}** lol +**\ {-fluffypony}** the core team have passwords for stuff like this as a fallback +**\** I don't think inactive people should have access to H1. Only on a as-needed basis. Maybe when they become active again? +**\* moneromooo** misread anonimal's ping, nevermind +**\** The drop dead theory +**\ {-fluffypony}** ^^ +**\ {-fluffypony}** it's just an anti-bus factor +**\ {-fluffypony}** the main people using it would be maintainers, which are currently just me and anonimal +**\** I was given access a while back (though might have been rescinded by now). +**\** No, you have access to kovri +**\ {-fluffypony}** and I don't think there's a big issue with maintainers having visibility on other reports +**\** As does EinMByte but is he still alive? +**\** Alright, so any other big issues with merging everything into a single account? +**\** And how many subprojects do we apply this too? I can PR the VRP to all appropriate subprojects and update docs as needed. +**\ {-fluffypony}** we can always split it out later +**\ {-fluffypony}** I think the only relevant projects are: GUI, CLI, Kovri, site +**\** I imagine the site and forum could gain from this too. +**\ {-fluffypony}** forum is being deprecated, so let's leave it off +**\ {-fluffypony}** but there will be some forum functionality moving into the site (FFS in particular) +**\ {-fluffypony}** so keeping the site there is necessary +**\** Ok +**\ {-fluffypony}** anonimal: maybe an infrastructure one too, which is pigeons' domain? +**\** Nodepool code perhaps? +**\** Meh. And no real maintainer. +**\** Snipa's work +**\ {-fluffypony}** @JacobJeweler no, that's not a core project +**\ {-fluffypony}** external projects can do their own H1 stuff +**\** fluffypony: sure, as long as we can communicate that to people e.g., use the Meta repo has a point of contact + place to post VRP etc. +**\ {-fluffypony}** I think we should come up with a paragraph for the READMEs +**\** Ok. We need the VRP somewhere though. It's solid (moreso than having nothing). +**\** we lost irc2p again +**\ {-pigeons}** ok i'll file a few reports as someone else for a bounty then +**\ {-fluffypony}** works here pigeons +**\** One thing also that's probably needed: a list of "this does not count". Like all that's known already. +**\ {-pigeons}** hmm yeah, just some selective drops, oh well +**\** But this is easily a bone of contention otherwise. +**\** moneromooo: that's included in H1. We can incorporate that into one of the features they have. +**\ {-fluffypony}** moneromooo: agreed +**\ {-fluffypony}** every report is subjective +**\** (iirc) +**\** Ok, so I will contact them and move these into a single account. +**\** And do all the related things necessary. +**\** As for funding, +**\* anonimal** reads backlog for fluffypony's message +**\** "general fund across all projects" +**\** Ok, +**\** separate from the dev fund? i.e., separate address too? +**\ {-fluffypony}** this will be an FFS +**\ {-fluffypony}** just open-ended with some minimum +**\** Ok, so no separate donation address. All FFS, and funds are held like the dev fund? +**\** (or like any FFS project) +**\ {-fluffypony}** yes +**\ {-olark}** How much money should we aim to raise for H1? +**\ {-olark}** Assuming this will need to be replenished every now and then. +**\ {-fluffypony}** I have no idea - suggestions? +**\** https://forum.getmonero.org/6/ideas/87597/monero-bounty-for-hackerone suggested 500 total for all projects +**\** (500 XMR) +**\* anonimal** checks value +**\ {-fluffypony}** olark: yes but bounties are normally denominated in USD +**\ {-fluffypony}** so potentially it wouldn't need to be replenished, or hardly +**\ {-fluffypony}** unless we have lots and lots of exploits +**\** Hmmm... well, at current price, 500 seems reasonable IMHO. That could attract some serious researchers. +**\** Thoughts? +**\ {-olark}** Probably easier to outline what the rewards should be for LOW, MEDIUM, and HIGH severity of vulnerabilites and then figure out how much money should be raised. +**\** We don't have X thought: X being how many of Y. +**\** *though +**\** If we run out of the fund, we can always open a new FFS. +**\ {-olark}** 500 xmr seems like a good start anyway. +**\ {-fluffypony}** yeah let's just stick to that and see how it goes +**\** Ok +**\ {-olark}** Right. +**\** Awesome. Anything else on point 3.? +**\ {-fluffypony}** next? +**\** Do we extend 20 minutes or are we screwed because of earlier? +**\** There are two point 3s. +**\** Extend, and whoever wants to leave leaves :) +**\ {-fluffypony}** we can extend to finish up, but let's do it ASAP so I can move on to tagging and releasing +**\** lol, yes. Github turns that into 4 if I copypasta. If I get original text, it's 3. +**\** 4. Code + ticket discussion / Q & A +**\** Damn, well, I could easily spend 20-30 minutes on this point because we haven't had a meeting in so long. +**\* anonimal** grabs link instead +**\** Ok, here we are https://github.com/monero-project/kovri/issues?q=is%3Aopen+is%3Aissue+milestone%3A0.1.0-alpha +**\** A little question about the reload : what is supposed to happen if no param changed ? +**\** #187 isn't as obvious as I had hoped. I'll have to approach it differently, from the basics, and start by actually getting some unit-tests for ntcp. +**\** if the user didn't specified a port, should it get a new random one ? +**\** So that will be fun. +**\** As for #340, #369 is moot because of the other open ticket for cutting out all unnecessary sig types, +**\** #305 should actually be closed for now, +**\** guzzi is working on #96. It's not mandatory for 0.1.0-alpha release so I may move it to next milestone, +**\** #9 needs review and may not really be needed after all +**\** I can work on those unit tests for ntcp if u want +**\** No that's fine guzzi, thank you. +**\** All that leaves is #46 and #362 +**\** ajs is on #46. He's supposed to be in talks with pigeons I think. I haven't heard from ajs in a little while though. ping ajs. +**\** #362 comes at the very end once we tag. I'll throw it on AUR and away we go. +**\* anonimal** reads moroccanmalinois's lines +**\** moroccanmalinois: if no port specified in config, that would be a default option. I don't like that though. +**\** What I think we should do is add a default random port to the config somehow. +**\** Otherwise we jump through these kinds of hurdles. But doing that for binary releases... hmm... +**\ {-olark}** We could just set a random port when a new router context is initialized. +**\** moroccanmalinois: worst case scenario, if the app is still running during restart (assuming because client and core are the only things being restarted), we reuse the previous port. +**\** ok +**\ {-olark}** It currently just defaults to 0 afaik. +**\** ? +**\ {-olark}** In router context. +**\ {-olark}** m_Port +**\ {-olark}** Assuming we are talking about the same thing. +**\** Nope, you're not looking in the right area. +**\ {-olark}** k +**\** I can explain more after the meeting. moroccanmalinois can probably too because it sounds like he understands the design as well. +**\** m_Port == 0 means choose a random one. another question : i read somewhere in the java doc about a "Laptop mode", i think the pb it tries to solve is more about dynamic ips. Is it on the roadmap ? +**\** Nope, not on the roadmap but it can be. +**\** Just open a feature request. +**\** :) ok +**\** it was just brought to my attention yesterday? that there's a ticket for pr'ing the logo - i was under the impression that my involvement with that was done, but looks like there's some miscommunication and i can get around to that soon-ish +**\** Anything else on point 4.? We don't have to rush this part if needed. +**\** What/ +**\** ? +**\** Link? +**\** Learning the instance class +**\** what what +**\** Anyone apposed to creating member variables for router context and client context. +**\** And giving them proper constructors +**\** It was a todo to find out why they are this way currently +**\** guzzi: please provide line number and file +**\** pero: what's your question? +**\** there is no question +**\** guzzi: for the TODO +**\** pero: there's a question mark. What is your point? +**\** where is there a question mark +**\** After "yesterday". +**\** Looks like a typo for "". +**\** this is ticket discussion isnt it - i was chiming in on something that was ostensibly assigned to me without my knowledge +**\** anonimal: pigeons said he got a server for #46, but waiting for access to move over files +**\** pero: nothing was assigned to you +**\** ajs: ok thanks +**\** alright well i guess there's nothing to do then +**\** Instance.cc +**\** Initialize function +**\** First comment inside +**\** Sorry github mobile has no li e numbers +**\** Line +**\ {-fluffypony}** ok maybe this discussion should happen later when you're at a computer, guzzi +**\** Good idea. +**\ {-pigeons}** i'm gonna confirm some things from ya'll in a few, fqdn and git repo to pull from +**\** Anything else on 4.? +**\** I will comment in the pr later +**\** guzzi: I know what you're talking about and see what you want, let's talk more later +**\** Cool +**\** 5. Any additional meeting items +**\** No additional items from me afaict +**\** One last question : an external app that wants to use kovri (like monero GUI), should it includes only the libs ? or it can include things from src/app ? +**\** Nothing from app. I see no reason for it to include anything from app. +**\** Which means we get things out of app that we need elsewhere. I wrote TODO's. +**\** Perfect. thx +**\** Anything else on 5.? +**\** not for me +**\** k +**\** 30 seconds... +**\** 6. Confirm next meeting date/time +**\ {-fluffypony}** 2 weeks (tm) +**\** 18:00 UTC two weeks from today as usual? +**\** Ok +**\ {-fluffypony}** April 9th +**\** Thanks everyone \ No newline at end of file diff --git a/_posts/2017-03-26-overview-and-logs-for-the-dev-meeting-held-on-2017-03-26.md b/_posts/2017-03-26-overview-and-logs-for-the-dev-meeting-held-on-2017-03-26.md new file mode 100644 index 00000000..7c110456 --- /dev/null +++ b/_posts/2017-03-26-overview-and-logs-for-the-dev-meeting-held-on-2017-03-26.md @@ -0,0 +1,342 @@ +--- +layout: post +title: Overview and Logs for the Dev Meeting Held on 2017-03-26 +summary: 0.10.3.1 release, light wallets, fireice-uk's proposal, and 0MQ +tags: [dev diaries, core, crypto] +author: dEBRUYNE / fluffypony +--- + +*March 26th, 2017* + +### Overview + +An overview [can be found on MoneroBase](https://monerobase.com/wiki/DevMeeting_2017-03-26). + +### Logs + +**\** 2. Brief review of what's been completed since the previous meeting +**\** ok so since the last meeting I guess the main thing is we tagged and released 0.10.3 +**\** which we're about to deprecate +**\** lol +**\** are there any issues with 0.10.3 besides the cumulative block size thing? +**\** now's the time to point them out +**\** no idea, but I'm running a build from a couple days ago +**\** me too. no issues so far +**\** Been running on OSX since yesterday. No issue. +**\** moneromooo: any idea why the issue seems to affect so few? +**\** Smart Mining is not working for me on newest macOS +**\** Dunno. Low level processor specifics I guess, but... shrug. +**\** hundehausen: it only works on Linux +**\** not on anything else +**\** I have smart mining running on Windows right now +**\** yeah. windows + linux iirc +**\** but not osx i think +**\** lunch time +**\** I like to pretend that Windows doesn't exist +**\** :-P +**\** lol +**\** What is it ? +**\** moneromooo: you open them to let air in +**\** Ah, doors. +**\** usually lets bugs in too +**\** smaller sized doors basically +**\** drumroll +**\** lol hyc +**\** winblows sucks +**\** windows and doors in Ireland have no screens. I dunno what's with these people. +**\** anyhoo +**\** let's move on +**\** 3. Discussion of fireice-uk's proposal (as started in #1828 +**\** I'd like to move this to Funding Required +**\** and fireice-uk updated the funding costs based on current pricing +**\** obviously there are some consensus-critical aspects to it, so I think it's worth discussing +**\** Wasn't this a wallet thing ? +**\** https://github.com/monero-project/monero/issues/1828 +**\** Yes. Speedup on Intel/AMD processors, which is helpful considering RingCT has slowed sync down. +**\** it is a wallet thing (unless you want to use it somewhere else) +**\** ringCT has slowed wallet sync? +**\** moneromooo: if we replace SUPERCOP then it's consensus critical +**\** I don't see how ringct slowed down wallet sync ... ? +**\** Then no consensus issue. And if it proves good for a while, *then* it can be used in consensus. +**\** xmreric: how has ringct slowed down sync? +**\** I thought I had heard that from others +**\** the additional work comes when a output match is found +**\** so I guess wallets with thousands and thousands of ringct outputs? +**\** https://monero.stackexchange.com/questions/3718/when-syncing-moneros-blockchain-from-scratch-why-does-it-begin-fast-and-end-sl +**\** xmreric: that's daemon, not wallet +**\** 1828 is a proposal for a wallet change +**\** ok +**\** its more work on the node verifying the block, but not the wallet since its not reading it. I suppose there is some additional time for transmission/marshalling/unmarshalling, but this is smaller than any crypto +**\** The bottleneck's the daemon anyway. +**\** daemon sync time seems a lot more important than wallet sync time (in comparison) if our primary goal was to encourage more full nodes. +**\** Unless you're using a remote node, no? +**\** this complicates the build if we want a crypto/ subtree just for wallet and one just for daemon +**\** Hmm, fair point. +**\** ok so then here's a suggestion +**\** the amount of tx's/day is higher since the date around ringct was activated. So wallet sync slows down. but not really related to ringct +**\** what if we had cryptoopsbuilder run on build +**\** build won't be more more complicated - just more symbols +**\** and use the existing stuff by default, but optionally use the newer SUPERCOP / whatever +**\** my suggestion would be to use ge64* symbols for the new code +**\** BTW, is that not what you wanted to replace by... tweetnacl or whatver it was ? +**\** moneromooo: yes +**\** but only when TweetNaCl has finished formal verification +**\** And that proposal replaces it with this, or another replacement ? +**\** Alright... +**\** I'd prefer we just keep the generated code statically committed to git +**\** no idea what environment the builder might break on +**\** hyc: the builder is pretty simple (just splicing text really), but it does add a python dep to the build process +**\** yeah, let's not do that. +**\** fireice-uk: did you try running a wallet refresh without any crypto to see how much faster it was at best possible gain ? IIRC, my bottleneck is the daemon (SSD, though CoW fs). +**\** either way, in the long run I'd like to have a default "safe" crypto implementation, and an optional fast one +**\** s/without any crypto/with the actual tx scanning disabled/ +**\** moneromoo: bottleneck is the poor fetching from the daemon +**\** So changing the crypto won't do a thing right now, right ? +**\** it somehow mananges not to max anything +**\** that is the part 2 +**\** crypto is part 1 +**\** so likely this is a premature optimization for now +**\** pigeons: want to swap round the order? +**\** why not swap the orders fireice-uk? And do daemon fetching optimization +**\** not a bad idea +**\** Oh ok. There are two things that should be easy win there: store non prunable separately, and maybe fetch a bunch of them at once (wallet refresh always has pretty much N..N+dN txes). +**\** so part 2 is the actual optimization? and part 1 is... ? +**\** I wanted to do the daemon thing for a while, but looks like I won't have to :D +**\** gingeropolous: part 1 is crypto optimziation, part 2 is parallelism opt +**\** but current discussion says crypto opt will be overshadowed by daemon +**\** ok so we swap them around and do part 2 first, and then revisit how to structure part 1 after that? +**\** makes sense +**\** fireice-uk: that sound ok? +**\** Well, that's my recollection of my particular machine anyway. Might differ for others. +**\** my suggestion would be to do part 1 first - this way you can have a loot at it before merging +**\** \*look +**\** I want to have a look at 2 also before merging. +**\** lol +**\** lol. +**\** of course, but i assume 1 will require more time +**\** lol +**\** but if its has more immediate benefits, why not go with 2 first? +**\** yeah it's sounding like 1's benefits will be unmeasurable for now +**\** it makes even more sense to do part 2 first if it is less complex/faster to implement. +**\** +1 +**\** Yes, do the easy wins first, and the possibly dangerous stuff might not be needed (and will only work on x8664 anyway AIUI). +**\** ok, that's fine with me +**\** Keeping in mind you also need the full blocks to serve syncing peers. +**\** great! +**\** ok cool - I'll move the proposal to funding after the 0.10.3.1 tag +**\** so in like 3 months /s +**\** hah hah +**\** touché +**\** Since we are on a similar topic, could I bring up ZMQ? That should also speed up sync time/provide faster wallet func at some point no? +**\** nah, fluffypony doesn't run on tewinget Time™ +**\** vertp: it should provide better scalability for multiple wallets hitting the same daemon +**\** but I don't think it'll provide speed benefits beyond that +**\** so light-wallets. Is there anything new on that front tewinget. +**\** agreed +**\** well, I've been working on merging from upstream this morning +**\** I think I've *just* got it sorted +**\** yay +**\** woo! +**\** !!!! +**\** Nice +**\** let's stick to the schedule plx +**\** few things changed in core that threw wrenches in the merge >**>** +**\** sorry fluffypony :) +**\** yes, sorry. +**\** ok so +**\** 4. Remote nodes (ie. a discussion of #605) +**\** Well, I was thinking about this, and I will do a wallet mode where a full wallet (ie, phone) can connect to a view wallet (ie, home server), and update from it. That should be super fast. +**\** moneromooo: that's exactly what vtnerd is doing +**\** tewinget: I think I kinda added a new RPC... a few days ago... +**\** so would be duplication of work +**\** Oh, OK. +**\** Won't that only show incoming though? +**\** but let's back up a second +**\** so a wallet can sync from another wallet? +**\** because I think that maybe there's some value in the *idea* of 605 +**\** In my idea, yes (really, transfer output data). +**\** but the specifics aren't great +**\** for eg. +**\** But I dunno what vtnerd is doing. +**\** Lots of GUI users want this on some level or another. +**\** I'm pretty big on emphasizing away from using remote nodes as best-practice. +**\** what if an unsynced daemon, when it has a wallet client requesting outputs from a certain height, picks a random peer and asks that peer for the data +**\** But for people in developing nations, etc it's a good option to offer +**\** I know that we all want everyone to run a full node, but I imagine less than half actually will, and that percentage will only decrease over time with new, non-technical users +**\** ie. without range proofs / sigs / etc. +**\** the random peer has its rpc open? +**\** the peer could lie, but the node will eventually know that it has +**\** gingeropolous: no +**\** we don't need RPC for this, we're already talking to the peer using the p2p protocol +**\** Why would the wallet request outputs for a given height, if the daemon isn't synced to that yet ? +**\** moneromooo: restored wallet, or loading a wallet file +**\** if the daemon isnt synced it shouldnt be used by the wallet +**\** or creating a new wallet +**\** Restored wallet would not, it has no idea about where it has outputs. +**\** moneromooo: restored from seed has a hardcoded restore height +**\** It is similar to how hadoop works +**\** New wallet wouldn't either. They'd get that info from the daemon, who'd necessarily be synced up to that point. +**\** Here is the first answer it may be wrong +**\** Unless you delete your blockchain after the wallet learns abvout those. But then, your problem. +**\** moneromooo: in each of the instances we either have a block height or we have a date that we can correlate +**\** Oh, you want *all* outputs ? +**\** from that height or date, yes +**\** I like it. The attack would bre someone setting up a ton of fake nodes. +**\** basically have the daemon tunnel "remote node" functionality to a peer +**\** OK, so essentially, syncing the chain with no vcerification whatsoever. +**\** moneromooo: yes - "pre-syncing" it +**\** because the node will catch up, and then the wallet will know if outputs have been withheld +**\** I actually had an idea about this a few days ago, where you could sync to a daily set of key images and outputs. Daily, verifying nodes hash it into the blockchain. +**\** Basically a no lock read +**\** So you can sync to that, check hash, then sync the last day's chain on top. +**\** but this would leave the wallet in a state where it can't create transactions until proper sync'd? +**\** moneromooo: the problem with that model are the oracles +**\** It does require *some* trust, though. +**\** Go on ? +**\** so the tricky part is the rules to make the block invalid if the miner lies +**\** er, until the daemon is proper syncd? +**\** gingeropolous: the daemon could also tunnel requests for ring outputs or whatever +**\** the trust model is the same as using some random guy's remote node +**\** good idea. but still doesnt help users without enough disk or those on a slow connection +**\** True +**\** That's what I proposed #602 for +**\** People who do not want to run a full node +**\** i had a kind of mostly trustless idea for this +**\** people that don't want to run a full node at all have to then use something like the MyMonero apps using the MyMonero backend instead of their own +**\** or Exodus or Coinomi or whatever else exists +**\** that would poll multiple nodes for the same outputs and verify them +**\** and store those locally +**\** pero: that's even worse than a remote node +**\** fluffypony: +1 +**\* pero** sees himself out +**\** Or this and never sync tge daemon +**\** Lol +**\** What if the time connected to a remote node is limited? Just setting up the GUI it connects to a remote node, and they can use right away, while stuff is going on in the background? (Sorry, just an idea I had. Not a developer so I don't know if possible) +**\** the larger issue here is that we can't do something like SPV +**\** so we really have nothing between "run your own node" and "use a centralised service" +**\** Stuff = syncing +**\** Should we looking at people connecting to their own remote node form say a mobile device? +**\** rehrar: that's exactly what I'm suggesting, but let the daemon "tunnel" the requests through +**\** ArticMine: the model here is people who don't want to run a node at all, not at home, not on a VPS, not at all +**\** rehrar: that's what #605 does +**\** we already have a solution for people who are willing to run a node +**\** Sorry. A lot of the tech is going above my head to catch it all. :) +**\** Well, they can use paypal, and come back in 5 years. +**\** Tech talk +**\** #605 connects to a remote node while local node is syncing +**\** I agree, fluffy. I think the real issue is people not having enough knwoledge to install nodes. An installer on windows and .deb in apt would increase full nodes immensly. +**\** i like it. the pre-sync idea. using the daemon. it opens up the whole network as a source of remote nodes, which decentralizes the effort +**\** What if all this work gets done, but then this audience just uses web/mobile wallets anyways +**\** keep improving the ability for people to run their own node before making it easier for people to use a different model +**\** and because the daemon *is* running +**\** it will be synchronizing its own copy of the blockchain +**\** @xmreric that's the most likely outcome +**\** that is trickier +**\** people *are* going to use MyMonero / Exodus / Coinomi even if we have a magical remote node model that doesn't vampire the network +**\** It could even hold part of the chain and randomly ask for missing parts +**\** block data sync'd this way will need to be stored differently than from regular syncing +**\** peopl are going to use worse options than those even +**\** hyc: agreed +**\** pigeons: store on an exchange :-P +**\** I like the pre-sync as well. But until we have MyMonero/Edodus/Coinomi, people will use a remote node in an inefficient way +**\** @samsunggalaxyplayer then let's not make it easier by having a drop-down +**\** ^ +**\** why not make it easy while waiting for a better solution? +**\** remember that a lot of decisions we make today, we're stuck with for 5+ years +**\** the effort wall to hack the system to use a remote node isn't that steep anyway +**\** Jaquee: because ^^ +**\** people become reliant on quick fixes +**\** So somewhere we need the doc to say "you must have a computer with at least xx GB of disk space that you are willing to leave running 24/7" +**\* tewinget** knows this, and as such leaves most decision making to fluffypony so he can be blamed in 5 years. +**\** Ah, tewinget the Wise. +**\** in 2023 +**\** i just don't think we should be holding back on UX just because we don't have a better solution yet +**\** have a nice message, now that you have verified the blockchain, we notice you have been screwed, pick a better node next time +**\** lol +**\** Anyway, this has turned to a disparate set of confusing stuff now. +**\** Lol +**\** Jaquee: the GUI is meant to operate with a full node that you operate, it's not a lightweight GUI +**\** Do we want to encourage people connecting to a untrusted random node +**\** ArticMine: no we don't +**\** Summary: for smart syncing with fluffy's "pre-sync" approach, against anything that makes using a remote node easier +**\** For ppl who want to use a phone could it never sync? +**\** sounds like we need a monero node appliance, like the wifi router that everyone has in their house / flat +**\** I agree #602 is a short-term solution. I think it's better than telling people to go to MoneroWorld to get a random node, but if we have a better solution going forward, that's preferable +**\** Good idea +**\** yes but wifi routers tend to be 32bit +**\** Thats why i think installer for windows and adding .deb to apt repositories will have it so people can be guided through an install and proper installation can be verified +**\** And always use a random? +**\** guzzi: phone would be MyMonero + your own node / MyMonero backend OR Exodus OR Coinomi +**\** and they're not cheap +**\** Ok thanks +**\** Adoption rate will increase full node usage +**\** @JacobJeweler we're definitely working on improving that with the GUI +**\** I say make it easy for people to set up their own node to connect to. Appliance like +**\** That is horse poop +**\** with the auto-update thing +**\** perhaps there's room for an unofficial gui fork +**\** No way ppl walñnt full nodes +**\** gingeropolous: http://imgur.com/a/3mMBE +**\** in my mind the remote node thing has 2 components: 1) instant on 2) no blockchain storage. +**\** gingeropolous: pigeons is working on it +**\** right now the only way I see to make this easy is with kovri, so we can ignore firewall and port forwarding issues +**\** hyc: +1 +**\** we can address instant on with lots of things +**\** we can't address no blockchain storage. And those that don't want to store the blockchain will always use some lighter weight thing, so ... i think im rambling. +**\** Good point hyc! +**\** How about creating SD card images with the blockchain preloaded for a specific monerod release. You'd "just" have to download the image, flash it and start up monerod +**\** +1 hyc +**\** ah, like for the Pine64 or something similar +**\** pretty big downloads. they don't compress well at all. +**\** 13GB now +**\** and pine64 is to slow +**\** Does it even have native AES? +**\** pine64 isn't too slow? +**\** hyc: didn't you say you're running your full node fine on yours? +**\** pine64 yes +**\** pine64 can run a node +**\** yeah pine64 works ok as a fullnode. buy an expensive microSD +**\** alright +**\** I'll brb in like 10 min, fyi +**\** let's move on +**\** 5. Code + ticket discussion / Q & A +**\** ok. so #605 will not be merged? +**\** (we can carry on discussing this after the Kovri meeting) +**\** all right +**\** Jaquee: no not with the drop down +**\** you can release the bootleg edition +**\** lol +**\** I've gotten the impression that there should be more unit tests from reading the last dev meeting +**\** amiuhle: yes +**\** Lets be honest, most users have windows. And harddisks that can easily fit the lmdb database. If you want great adoption and more full nodes on the network (people installing and usong their local node for gui/cli). Thats where the focus on something like an installer should be at. +**\** what if we at least request tests for new PRs? +**\** Then you won't get PRs. +**\** that would help, but could be frustrating in a few components +**\** amiuhle: we don't want PRs from new contributors mired in a list of things-the-PR-must-have +**\** for instance, I added some to epee::stringtools, but those are isolated functions so its easy to setup the test env +**\** some of this stuff won't be easily detected in tests anyway. race condition with mining blocks, etc. +**\** one more thing regarding wallet2.cpp +**\** Sorry am on phone typing, slow to respond. +**\** hyc: yup. but figuring out a base framework for some areas might be helpful to get a baseline. but its decent chunk of work +**\** it is already at an unwieldy 5kloc, what's the opinion on splitting it into smaller parts? +**\** can't detect some of these with code coverage testing either. code cov can't tell you about logic you're missing. +**\** Tests can be added after the fact btw. +**\** Is there a split that makes sense ? +**\** And 5k is wieldy for any sane editor. +**\** moneomoo: takes 2gb+ to compile +**\** yeah I wouldn't worry about wallet2.cpp at the moment. +**\** mooo Im guessing vim ? +**\** 2GB+ to compile comes from all the boost headers and shit +**\** What I want is avoiding spamming the git log, as I use it a lot. +**\** ok +**\** vim works fine with 5k, but most other editors are also not shit. +**\** fireice-uk: thats partially coming from the epee headers though, but some split may help a bit +**\** Or... I assume. 5k is not much. +**\** I've done the experiment before. +**\** bbedit handles it fine +**\* anonimal** coughs +**\** splitting the file up to try to fit it under 2GB +**\** ok guys +**\** Kovri meeting +**\** made no diff. it's the headers, not the cpp source +**\** next meeting in 2 weeks, no time for Q&A, thanks for coming \ No newline at end of file diff --git a/_posts/2017-03-27-monero-0.10.3.1-released.md b/_posts/2017-03-27-monero-0.10.3.1-released.md new file mode 100644 index 00000000..63e4b054 --- /dev/null +++ b/_posts/2017-03-27-monero-0.10.3.1-released.md @@ -0,0 +1,90 @@ +--- +layout: post +title: Monero 0.10.3.1 "Wolfram Warptangent" Released +summary: A mandatory update that is ready for the April 15th hard fork +tags: [releases] +author: Riccardo Spagni (fluffypony) +--- + +*March 27th, 2017* + +### Overview + +This is a necessary point release of Monero v0.10 "_Wolfram Warptangent_", and it is a mandatory update due to the April 15th hard fork, which in turn has been necessitated by the unexpectedly high adoption rate of RingCT transactions necessitating a modification of the dynamic block size limiter algorithm. + +In addition, this is the first version that aligns CLI and GUI tags, with the CLI being tagged and released first, and the GUI tagged and released within a few days thereafter. This will mean that some point releases in future may be forced by a need on the GUI side, where the CLI may not have substantial changes, and vice versa. + +Since it has only been 30 days since the last release, this is something of a "light" update. Nonetheless, some highlights of this release are: + +- the 0.10.3.1 point release disables a portion of the server-side hash cache that was preventing a small subset of nodes from syncing +- added a feature to allow for multiple outputs to be paid to the same address (unless you have ```set merge-destinations 1```) +- fixed a major bug that could lead to some peers, seemingly randomly, getting stuck at a block height and refusing to accept further blocks +- monero-wallet-cli (and underlying libraries) can now work in a number of units: monero, millinero, micronero, nanonero, piconero +- added OpenAlias support to wallet RPC calls +- fixed hardcoded seed fallback issues when DNS seeds have failed or too few seeds are returned +- added an optional config file for wallets +- added an additional non-interactive foreground mode for the daemon +- added mnemonic wordlists for French and Dutch +- per-kb fee quantized to 8 decimal places +- added a password function to monero-wallet-cli to allow for a wallet password to be changed (and all files re-encrypted) +- added a cache on the wallet to avoid re-scanning mempool txs already scanned +- improvements to auto-update functionality, including a download-and-verify mechanism +- fixes to a number of logs shown in the daemon by default +- massive API changes to support new features in the GUI +- as always, loads of bug fixes and performance improvements + +### Contributors for this Release + +This release was the direct result of 24 people who worked, largely unpaid and altruistically, to put out 190 commits containing 5 706 new lines of code. We'd like to thank them very much for their time and effort. In no particular order they are: + +- Christoph Schnerch +- Jaquee +- NanoAkron +- Arne Brutschy +- assylias +- lethos3 +- rockhouse +- Roy Jacobs +- stoffu +- adot23 +- Riccardo "fluffypony" Spagni +- Noah Watkins +- Lee Clagett +- xmr-eric +- Howard "hyc" Chu +- Derek Zhang +- Gareth +- Gingeropolous +- darentuzi +- Akademik Prokhor Zakharov +- Guillaume Le Vaillant +- moneromooo-monero +- Miguel Herranz +- kenshi84 + +### Official Download Links +- [Windows, 64-bit](https://downloads.getmonero.org/cli/monero-win-x64-v0.10.3.1.zip) +- [Windows, 32-bit](https://downloads.getmonero.org/cli/monero-win-x86-v0.10.3.1.zip) +- [macOS, 64-bit](https://downloads.getmonero.org/cli/monero-mac-x64-v0.10.3.1.tar.bz2) +- [Linux, 64-bit](https://downloads.getmonero.org/cli/monero-linux-x64-v0.10.3.1.tar.bz2) +- [Linux, 32-bit](https://downloads.getmonero.org/cli/monero-linux-x86-v0.10.3.1.tar.bz2) +- [Linux, armv7](https://downloads.getmonero.org/cli/monero-linux-armv7-v0.10.3.1.tar.bz2) +- [Linux, armv8](https://downloads.getmonero.org/cli/monero-linux-armv8-v0.10.3.1.tar.bz2) +- [FreeBSD, 64-bit](https://downloads.getmonero.org/cli/monero-freebsd-x64-v0.10.3.1.tar.bz2) +- [DragonFlyBSD, 64-bit](https://downloads.getmonero.org/cli/monero-dragonflybsd-x64-v0.10.3.1.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.3.1.zip, 2fbda6f6b1051053703e40cf77b6c6e11334509ad03a3c22d89b6bcb05615910 +- monero-win-x86-v0.10.3.1.zip, da628a45adfcb8be44df06ac904711d644d608c4eb6479a5d256062a5f6d74de +- monero-mac-x64-v0.10.3.1.tar.bz2, fd17d55a8c9e901ff4064c39d9e14786cdd077aff9b3bb556e60d3a5e322050c +- monero-linux-x64-v0.10.3.1.tar.bz2, 8db80f8cc4f80d4106db807432828df730a59eac78972ea81652aa6b9bac04ad +- monero-linux-x86-v0.10.3.1.tar.bz2, abc99f3928f4083bd1a380a869253e07bee9950e0aeb6388e9493bc0f0ec3f53 +- monero-linux-armv7-v0.10.3.1.tar.bz2, 8473fa20e0db4a3d3e46120cdf92c55be6a159478c511e21f7b77aa05d6c1910 +- monero-linux-armv8-v0.10.3.1.tar.bz2, 451f65e4846b92d54859e22a5d92124557b397b4208d8752d5289d0262573c3c +- monero-freebsd-x64-v0.10.3.1.tar.bz2, 4c66a76752e18ae70b5fb1c728f0d2780eb129a6c8c7d0dee7ba02e05d91efae +- monero-dragonflybsd-x64-v0.10.3.1.tar.bz2, c25c0f603ca5c96cb5963aaa2905edff390b7a97f654106911ffad8639deee7c + +A GPG-signed list of the hashes is at https://getmonero.org/downloads/hashes.txt and should be treated as canonical, with the signature checked against the appropriate GPG key in the source code (in /utils/gpg_keys) \ No newline at end of file diff --git a/_posts/2017-03-29-monero-gui-beta-2-released.md b/_posts/2017-03-29-monero-gui-beta-2-released.md new file mode 100644 index 00000000..3edd66c4 --- /dev/null +++ b/_posts/2017-03-29-monero-gui-beta-2-released.md @@ -0,0 +1,95 @@ +--- +layout: post +title: Monero GUI Beta 2 Released +summary: The second beta of the Monero GUI is out! +tags: [releases] +author: Riccardo Spagni (fluffypony) +--- + +*March 29th, 2017* + +### Overview + +The second beta of the Monero GUI has been released. Due to our focus on completing the features required for the initial release we have not, as yet, completed support for 32-bit Windows, FreeBSD, DragonflyBSD, ARMv7 Linux, and ARMv8 Linux devices. Whilst these are being worked on, it may not be feasible to support some environments (like 32-bit Windows) due to performance degradation. + +Download links are at the bottom of this post, and please take note of the known issues and caveats listed below. + +To upgrade, just replace your existing GUI with this newer release. Beta 1 wallets will continue to work in beta 2, without any changes required from your side. + +### Known Issues + +- If the GUI doesn't start on Windows, or starts with a blank screen, then try launch it using the ```start-low-graphics-mode.bat``` batch file. +- The unsigned transaction format, used by cold wallets, may cause issues when moving between platforms (eg. from Linux to Windows) for signing. +- Cold transaction signing does not work with split transactions (sends that are split over multiple transactions). + +### Contributors for this Release + +This release was the direct result of 50 people who worked, largely unpaid and altruistically, to put out 1202 commits containing 345 646 new lines of code. We'd like to thank them very much for their time and effort. In no particular order they are: + +- Ilya Kitaev +- James Cullum +- luigi1111 +- Matthias Tarasiewicz +- Derek Zhang +- Howard "hyc" Chu +- medusadigital +- Andreas Brekken +- maitscha +- hundehausen +- moneroj +- xmr-eric +- signo88 +- HugTime +- marcin +- Clement +- MoroccanMalinois +- Lafudoci +- Timo Uhlmann +- Christoph Mayerhofer +- redfish +- Jaqueee +- dnaleor +- MartinUI +- Guillaume Le Vaillant +- Daniel Ternyak +- David Latapie +- henrud +- moneromooo +- Michael Campagnaro +- taushet +- schnerchi +- Jonathan Cross +- Riccardo "fluffypony" Spagni +- dEBRUYNE +- ferretinjapan +- sbialy +- Christoph Schnerch +- githubrsys +- xmrdc +- Gingeropolous +- NanoAkron +- kenshi84 +- keesieboy +- moimoij +- Shrikez1 +- MiWCryptAnalytics +- mochaccinuh +- Roy Jacobs +- pigeons + +### Official Download Links +- [Windows, 64-bit](https://downloads.getmonero.org/gui/monero-gui-win-x64-v0.10.3.1.zip) +- [macOS, 64-bit](https://downloads.getmonero.org/gui/monero-gui-mac-x64-v0.10.3.1.tar.bz2) +- [Linux, 64-bit](https://downloads.getmonero.org/gui/monero-gui-linux-x64-v0.10.3.1.tar.bz2) +- [Linux, 32-bit](https://downloads.getmonero.org/gui/monero-gui-linux-x86-v0.10.3.1.tar.bz2) + +### Download Hashes + +If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes: + +- monero-gui-linux-x64-v0.10.3.1.tar.bz2, 4915473265d58720fd8f019e536c2b7fb02648ab51a8087e84aa1e2434788452 +- monero-gui-linux-x86-v0.10.3.1.tar.bz2, 092b49080c3380666845f7f39823b09f4960ea1e250b84b150856ef33ca30690 +- monero-gui-mac-x64-v0.10.3.1.tar.bz2, c80ca68037158216a080e59e90b0a70761cff2f317d3c9cd0eeb661e8e2a1f99 +- monero-gui-win-x64-v0.10.3.1.zip, 0eddd423f5f0df236303d8b9225842142b331093eb69e6183f3f694238c371a7 + +A GPG-signed list of the hashes is at https://getmonero.org/downloads/hashes.txt and should be treated as canonical, with the signature checked against the appropriate GPG key in the source code (in /utils/gpg_keys) \ No newline at end of file diff --git a/_posts/2017-04-01-announcing-the-monero-celebrity-center.md b/_posts/2017-04-01-announcing-the-monero-celebrity-center.md new file mode 100644 index 00000000..afde2e2f --- /dev/null +++ b/_posts/2017-04-01-announcing-the-monero-celebrity-center.md @@ -0,0 +1,29 @@ +--- +layout: post +title: Announcing the Monero Celebrity Center +summary: Providing rapid assistance to the heaviest of Monero's users! +tags: [core] +author: Monero Core Team +--- + +*April 1st, 2017* + +### For Immediate Release + +The Monero Core Team is very proud to announce that we have broken ground on the construction of the Monero Celebrity Center in Los Angeles, USA! + +For some time we have known that we needed an exclusive center where Monero's more relevant could be rewarded for their contribution to Monero's growing image in popular culture. Those with the largest number of transactions are often celebrities and former clients of Mossack Fonseca who it turns out are mostly located in the Los Angeles area. We don't know precisely what they're spending Monero on, but we understand their desire for enhanced privacy for certain...purchases...that they make. + +It is for this reason that the Monero Core Team have seen to the construction of a special center that caters to these individuals - the artists, politicians, leaders of industry and sports figures who use Monero... and no one else. We are pleased to call this new campus the Monero Celebrity Center of Los Angeles. + +![Interior](/blog/assets/april-fools/2016/inside.jpg) + +Built on the banks of the Arroyo Calabasas river, the Monero Celebrity Center will be open 24 hours a day, and will house 420 full time staff to assist celebrities with their Monero purchases. + +![Exterior](/blog/assets/april-fools/2016/building.jpg) + +Now one might argue that these individuals already have benefits that many will never have. But, ask any one of them - ask yourself - can the world be lonely even for those who appear to have everything. Subject to the unusual pressures that come with prominence and responsibility, being looked upon under a microscope for good or bad - these are burdens others can't imagine. Not to mention the counter-attack such individuals are subjected to by those less-ambitious who would rather fight to maintain a "status quo" than allow another to attempt a change or improvement. We asked ourselves "How can Monero help these people and *how can they help Monero*?" + +You see, there's no shame in helping the artist. In fact, in the larger scope of societal help, we had better help the artist if we wish to advance the society at all or Monero for that matter. + +We look forward to welcoming celebrities to the Monero Celebrity Center as soon as it has been completed! \ No newline at end of file diff --git a/_posts/2017-04-09-logs-for-the-Kovri-dev-meeting-held-on-2017-04-09.md b/_posts/2017-04-09-logs-for-the-Kovri-dev-meeting-held-on-2017-04-09.md new file mode 100644 index 00000000..fb24698d --- /dev/null +++ b/_posts/2017-04-09-logs-for-the-Kovri-dev-meeting-held-on-2017-04-09.md @@ -0,0 +1,282 @@ +--- +layout: post +title: Logs for the Kovri Dev Meeting Held on 2017-04-09 +summary: Brief review of what has been completed since last meeting, Monero HackerOne Bounty, website discussion, and code & open tickets discussion +tags: [dev diaries, i2p, crypto] +author: dEBRUYNE / fluffypony +--- + +*April 9th, 2017* + +### Logs + +**\** 1. Greetings +**\** 2. Brief review of what's been completed since the previous meeting +**\** 3. Preparation for [96boards.org OpenHours showcase for Kovri / Monero](https://github.com/monero-project/meta/issues/46) +**\** 4. Status of [Monero HackerOne umbrella and bounty](https://github.com/monero-project/meta/issues/39) +**\** 5. Code + ticket discussion / Q & A +**\** 6. Any additional meeting items +**\** 7. Confirm next meeting date/time +**\** Hellloooo +**\ {-olark}** Hello party people +**\ [gingeropolous]** howdy! +**\** Hello +**\** hi +**\** Hi (observing excitedly) +**\ {-iDunk}** Hi +**\* moneromooo** greets again +**\ [endogenic]** no excitement allowed rehrar +**\** hi +**\** I'll see myself out then. +**\** 2. Brief review of what's been completed since the previous meeting +**\** For me, the past two weeks have spent focusing on 4 things: fixing the OpenBSD dynamic build, PR review/fixes/collaboration, NTCP, and RI (router info). +**\** a. Jeff at crypto++ has not been responsive lately so my CMake fix for their dynamic OpenBSD is still sitting in PR hell. +**\** b. Both moroccanmalinois and rakhimov have been PR'ing some great work +**\** c. Over time I've done bits and pieces of work on the NTCP implementation but hadn't had the chance to do a full study in java I2P's implementation until recently. +**\** Combined with more spec review (forunately, the spec is small) I've come up with 33 questions/TODOs specifically about, and for, our implementation. +**\** Once that was done, it turned out that I couldn't move forward until I worked out any potential RI issues. +**\** d. That lead me to the unmaintainable mess of our forked RI implementation, which has been neglected, so now at a minimum I'm working on a RI parser/reader/writer refactor. From there, unit-test *and then* back to NTCP so I can close that damn milestone issue >:| +**\** So, that's just on my end. Anyone else? +**\** I know guzzi is doing study for RAII refactoring. +**\** Salti's holding pattern for webextensions in FF is making progress +**\** Oooo cool +**\** How are they doing on that front? +**\** 1 of two issues i'm tracking are finished, second is still a ways off +**\** Review client context implimenting raii +**\** and no dev docs yet +**\** Looking at reload server tunnels https://github.com/monero-project/kovri/blob/master/src/client/context.cc#L321 +**\** Excellent, that all sounds good. Anything else before we move onto 3.? +**\ {-olark}** I have been slowly evaluating what will be needed to replace supercop with tweetnacl +**\** (well, I'm hoping FF will move faster but it sounds like they're at least *moving*) +**\ {-olark}** Can rip out all the ecdsa sig types at the same time to work towards the identity refactor work +**\** anonimal: yes. progress is progress. +**\** olark: ok this is for #485, sounds good. Would you be able to resolve #345 in the mean time? +**\ {-olark}** For EdDSA +**\ [fluffypony]** major thunderstorm here, so if I don't respond it's because I've been struck by lightning (or my house has) +**\** Eeek! No charred pony! +**\ {-olark}** anonimal: Sure +**\** fluffypony can you see the meeting or is internet intermittent? +**\** olark: nice! +**\** Ok, moving forward, +**\ {-olark}** I will find the time. I have been neglecting kovri :( +**\** Yes, come back soon ;) +**\** 3. Preparation for [96boards.org OpenHours showcase for Kovri / Monero](https://github.com/monero-project/meta/issues/46) +**\** Speaking of neglecting, I hope we don't let this opportunity slip by ^ +**\** Does anyone know of any effect voice masking software? Military grade (if there is such a thing). +**\** \*effective +**\ [fluffypony]** anonimal: nothing I know of, but I also don't know if that would be worthwhile or weird +**\ \* fluffypony** tries to convince anonimal to come out the pseudonymous closet +**\ {-pigeons}** yeah its annoying as hell to listen to +**\ {-pigeons}** mouthful of marbles works ok though +**\** I hear that Barry Manilow recently came out of the closet. +**\** Pennies +**\* anonimal** not that I'm a fan, nor am I in that sort of closet +**\** Well, I'm curious to hear the public's opinion on whether I should de-anon. Thoughts? +**\ [endogenic]** yes! +**\** moneromooo ^ #monero-dev +**\ [endogenic]** i will be your bodyguard +**\** lol awesome! X) +**\ [fluffypony]** anonimal: only reason I suggest it is because Kovri does need a voice, but ultimately it's your call +**\ [gingeropolous]** weren't you already on the monero missives? +**\ [fluffypony]** gingeropolous: no, that was jeff +**\** What ? What's in #monero-dev ? +**\ [endogenic]** anonimal: just think… we can hang out at meetups and such :) +**\ {-olark}** Ultimately your choice anonimal. +**\ {-olark}** Don't feel pressured to come out becuase people want you to ;) +**\** ^ seconded +**\** gingeropolous: ^ not Jeff at crypto++, Jeff a former problem contributor who, as he said, has family in U.S. intelligence. +**\ [gingeropolous]** he's satoshi. +**\** moneromooo I meant 'what's your opinion if any?' +**\* anonimal** and also threw question at #monero-dev in same line, sorry +**\ [gingeropolous]** my apologies. I obviously know whos who here. +**\** Of whether you should de-anon ? I wouldn't want to influence you to. +**\** Oh np, just clarifying since I said "Jeff" earlier. +**\** My view is that the more people actively keep their privacy, the less the massive pressure on everyone else to shed their privacy is. +**\** Hmm, good point. +**\** Not really related to this particular case, but having 99% of people not care about their privacy means that companies and everyone can just screw privacy and not get any noticeable blowback. +**\ [endogenic]** think only anonimal's in the position anonimal's in as kovri lead tho +**\** So I use Tor for random run off the mill browsing partly for that reason too. +**\ [fluffypony]** moneromooo: yes, but this is about his status as a contributor and maintainer +**\ [fluffypony]** after all, things get really boring if I'm the only one talking at conferences +**\** Well, his choice, and I don't want to interfere in it. But thanks for asking :) +**\ [endogenic]** \<3 +**\ [endogenic]** i wouldn't go that far fluffy +**\ [gingeropolous]** you could just "hire" a spokesperson to be your IRL talking head +**\ [gingeropolous]** and they *just* happen to know a *whole* lot about everything +**\ [endogenic]** rent-a-body +**\** Ok, so I'm hearing that if I de-anon I get a free(?) bodyguard and can freely promote more-so than what I can do now. I'm also hearing that no one wants to put that kind of pressure of a decision on me. +**\** I have to say though, I'm wearing more than 1 cap at any given time. Maybe one-too-many? It was a relief to finally sit down and write some code this week. It had been way too long since I've done that and I'm ALWAYS HERE working on kovri! +**\** I think gingeropolous suggested you should invent an alter ego for public appearances :) +**\ [endogenic]** you can choose when to do talks and when to reply to ppl imo +**\ [endogenic]** and i bet others will jump in to help +**\ [fluffypony]** "I'm fluffy...errrr...fluffynonimal, and I'm a Kovri developer" +**\ [endogenic]** just a question of letting us know how we can help +**\ {-pigeons}** even if you do come out, still consider the marbles for talks +**\ [gingeropolous]** well iDunk now its ruined +**\** Damn +**\** lol, I'll just show up with marbles in my mouth. +**\** I must say that, adding public-relations, I love the thought, but I do also love writing code. +**\** And people love targets, so that's always something to concern myself with. +**\** You can still do both. Choose the proportion you want +**\** "just a question of letting us know how we can help" \<-- thanks endogenic. I think what will help are 2 things: +**\** sgp good point +**\ [fluffypony]** anonimal: I think that there's probably less scope to talk about Kovri at conferences right now anyway, but it would be nice for someone to do some podcasts etc. in future +**\ [endogenic]** podcasts are a great idea. i honestly doubt most ppl who want to use something like tor even know tor needs an alternative +**\ [endogenic]** and i'd enjoy learning more about the kovri tech in that format +**\** What would help: 1. more people get more familiar with kovri technology so they can answer questions and promote too. And 2. maybe everyone present can give me a solid "yes" or "no" on if they want me to de-anon (i.e., putting aside any other thoughts and responding purely on instinctual feelings) +**\** bigreddmachine: ^ re: podcast, my decision sooner than later will effect that +**\ [gingeropolous]** just go full Mr. Robot. Loose touch with reality, veer into psychosis, and then even *you* don't know who you are. +**\** lololol gingeropolous X) +**\** I just started watching that show. 1 season in. No spoilers please! +**\** To de-anon should be personal chice in my opinion +**\** Ok I'd say we're on a tangent for point 3 but this kind of needs to be done IMHO. +**\** choice +**\** All in favor of me de-anoning: yay or nay? +**\* anonimal** don't be shy! +**\ [endogenic]** i personally agree it must be personal too. sry to be difficult. there are tradeoffs for sure +**\** Pros: can talk about it more openly, attract new talent with greater outreach, better inform community about developments. Cons: more likely to be a target, maybe you're really ugly +**\ [endogenic]** it's a kind of burden i think +**\** (just kidding on second con) +**\ [fluffypony]** anonimal: I don't know if we should vote for that, it's your call +**\** lol sgp maybe I'm missing a face entirely... +**\** fluffypony ok +**\** So resolving 3., fluffypony + pigeons, how's your schedule lately? +**\ [fluffypony]** pigeons is down my side of the world for a couple of weeks, so we can make time around that +**\** Oh neat! Should I contact Robert to schedule a definitive date now? +**\ [fluffypony]** well it depends on if you want to do me + pigeons or you + pigeons +**\** anonimal: soory, was afk. re the podcast bit, if you do decide to de-anon yourself, i'd be happy to host your coming out of the closet party! but garbling voice is doable too. +**\ [fluffypony]** or all 3 of us +**\** fluffypony: I would think either all 3 (or at minimum just you 2). bigreddmachine I'd like to hear/learn more about any garble tech available, even if it's annoying. +**\ [fluffypony]** anonimal: ok let's talk afterwards, and we can schedule it with them +**\** Ok will do +**\** bigreddmachine: I'll PM you later too +**\** Anything else on 3.? +**\** Voice garbling sounds very reversible (unless it's voice recogniation plus text to speech). +**\** TTS certainly would work. +**\* anonimal** considered TTS, maybe I should learn to type faster first +**\** (or prepared statements?) +**\** (defeats the fun of interviews/speeches/conferences?) +**\** Ok, we'll talk more later. +**\ [endogenic]** hehe seems a little creepy +**\** 4. Status of [Monero HackerOne umbrella and bounty](https://github.com/monero-project/meta/issues/39) +**\** Copy and "paste" words from movies, paste them one by one to make up sentences. Like the old words cut off from a newspaper :D +**\** lol moneromooo, not serial-killer-like in any way whatsoever... +**\** re: 4. We have hackerone.com/monero ! +**\ [fluffypony]** anonimal: has anything for 4. been written up in the style of an FFS proposal or not yet? +**\* anonimal** grabs only FFS for 4. +**\** Links is in the meta issue, one moment. +**\** https://forum.getmonero.org/6/ideas/87597/monero-bounty-for-hackerone +**\** Is that what you mean? +**\ [fluffypony]** ok - do you want me to move that to Funding Required in its current form? +**\** Eek, I should update? +**\** The prop looks unclear as-is +**\ [fluffypony]** probably worthwhile +**\** We decided on 500 to start +**\** Ok, I'll edit after the meeting or do you need me to do that now? +**\ [fluffypony]** no after is fine +**\** Ok +**\** So for 4, I still have to PR VRP's to the various repos. +**\** Also invite the appropriate people to H1. But fluffypony I think you'll want to do that? +**\ [fluffypony]** sure +**\** moneromooo is already in there. luigi is not yet though. +**\** Alright. From there we should raise the funds first and *then* start inviting hackers on H1. +**\** Any agreements/disagreements? +**\** I agree +**\** Btw, many hackers are already *on* H1, by invite I mean invite to start looking at our projects. +**\** Ok. Anything else on 4.? +**\** 5. Code + ticket discussion / Q & A +**\ [fluffypony]** nothing else from my side on 4 +**\* anonimal** takes peek +**\** re: website issue, is ajs here? +**\** present +**\** Hi! +**\** Any news the website front? +**\ {-pigeons}** No I am the holdup there +**\** Ok. ETA on resolving any holdups? +**\** shoot, i was just about to ask about that. didn't realize we had monero-project/kovri-site. how can i help? +**\** have backed up work that has been done and waiting for access to a server +**\** Btw rehrar popped in recently and said him and/or his wife would give a try a logo redesign. +**\** Hi. Yes. :D +**\ {-pigeons}** i'll try to set something up in 24 hours or so +**\** Wow, that fast? Cool. +**\ [pero]** so what happened to the logo i did +**\** pero: it was NACK'ed. This was clearly stated in github issue that I posted in the previous meeting. +**\** I'd also like to give the Kovri website a go, pending on the logo and branding. :) +**\ [pero]** why? +**\** pero: I don't have the files though if that's what you mean. +**\** fluffypony: ^ +**\ [pero]** you were sent the files +**\ [pero]** so as i see it, a contributor contributed a bunch of time and spiffied up the previous logo +**\** Not anymore. Tis' the magic of deleted emails. +**\ [pero]** the community was involved too... +**\ [pero]** then it unilaterally 'nack'd' +**\** Yes. This was all clearly stated in the github PR. +**\** Where is your logo work PR? +**\ [pero]** wow what a shitty way to waste contributor's time +**\** You PR'd nothing. Community opinion does not equal final decision. +**\** Off you go pero, the resident troll. +**\ [pero]** lol? +**\** You knew from the start that fluffypony and I would make a final decision. Do I really need to bring up logs from months ago? +**\ [pero]** the logo assets were emailed to you and pony +**\ [pero]** there was no request to pr anything +**\** rehrar bigreddmachine - I made a very basic Jekyll site.. files at: https://github.com/anonimal/kovri-site +**\ [pero]** the request was for the files to be emailed +**\ [pero]** and your 'troll' remark is uncalled for and rude? +**\ [pero]** wtf is that +**\** pero you have two options: 1. being kicked from this channel for disrupting a meeting or 2. venting into https://github.com/monero-project/kovri/pull/488 for all the world to see. +**\ [bigreddmachine]** ty ajs. will this be affected by the re-design that rehrar is doing? +**\** Well, I think ideally the redesign that is done for getmonero.org should have an influence on the Kovri website (just influence, not dictate) +**\** and the logo redesign I will propose (just a proposal) I think definitely should have a larger influence on the website +**\ [pero]** whats so hard about contacting the person that did the work? +**\** rehrar: that sounds good +**\** So before I start working on anything Kovri website related, we're going to try to get a logo to you guys before this week is over. +**\** I'll drop it on here and the Kovri repo as an issue to look over when it's done. +**\** And it is obviously open to suggestions or tweaks when we show it +**\ [bigreddmachine]** ty rehrar - but from a content standpoint, the re-design is sort-of content agnostic, right? as in, i could write a page and the formatting might change but if it's in a markdown file jekyll will just ingest it and reformat, right? +**\** for Kovri, not getmonero.org, right? +**\** Did you have any plans to re-use material from monero site (as to save time, etc.)? +**\ [bigreddmachine]** well, both i suppose, but kovri specifically +**\** bigreddmachine: site design is rudimentary and could be easily changed if need be +**\** The content is going to be restructured for getmonero.org, I'm not going to do a lot of work on copy, unless people think it's really needed. +**\ [bigreddmachine]** (sorry, i got us off topic) +**\* anonimal** whatever is easiest to maintain IMHO +**\** Pages will be shuffled around, and some things within pages will be shuffled around (all of this will be submitted in designs prior to everything being built) +**\** as for Kovri, it won't have nearly as much content yet, so I don't think it'll be a huge issue. +**\** does that answer your question? +**\** If not, the short answer is yes, it should be content agnostic, and I will work with you guys in the rare cases where it is not. +**\ [bigreddmachine]** not entirely but close enough, thanks. +**\ [bigreddmachine]** ahh, yeah that last bit helps +**\** great! +**\** Question: +**\** rehrar: IMHO, from the work of yours I've seen, since you're an actual designer/creator/implementer, I'm wondering if you, bigreddmachine, ajs and pigeons would consider being the 'website team' to get this up-and-running. I can move the repo when we're online. Does this sound fair or something of interest? +**\** It sounds like you're already doing that, I'm just wondering for my own piece of mind (e.g. do I need to re-schedule my work load for website work, etc.) +**\ [endogenic]** But not both! +**\** That sounds fine with me. Pardon me for my ignorance, but what will be bigredmachine, ajs, and pigeons roles? +**\ [bigreddmachine]** i'm happy to help with some content, as i am trying to learn about the tech anyway so documenting it is an obvious step. +**\** endogenic too, hop on the site train! +**\** if you can focus more on Kovri, I would do it. +**\** rehrar: re: bigreddmachine ajs and pigeons, let's chat after the meeting since we're out of time +**\ [bigreddmachine]** design-wise, i can give my two cents but i'd like to be hands off there. just more of a feedback guy, like "hey, this isn't intuative" or whatever +**\** I don't think any of us have a problem bugging you if we need something. +**\** I'm not able to stick around for much longer, actually. +**\** We can set up a meeting time for alter this week? +**\** \*later +**\** rehrar: just pop in anytime if you want to make an official website meeting +**\** sounds good +**\** gotta split. Seeya homes. +**\ [bigreddmachine]** i can't, but just summarize discussions on github issue and tag me +**\** bigreddmachine: that's right, you're not always irc'able. +**\ [fluffypony]** Can I take the bot down? I'm in a YouTube show mow +**\ [fluffypony]** Now +**\ [bigreddmachine]** anonimal: i try to stay off during week to stay focused on my job. +**\ [endogenic]** anonimal: oh no not me, i was just trolling about "fair or of interest" +**\ [bigreddmachine]** meow\* +**\** Ok, moving on 6. Any additional meeting items +**\** None from me. guzzi said like 2 lines. +**\ [endogenic]** I think pero could be of help on the site too as i think he has lots of exp there +**\** 7. Confirm next meeting date/tim +**\ [bigreddmachine]** just that i'll keep tracking FF proxy and looking for alternatives. +**\ [bigreddmachine]** 23 Apr? +**\** Yes, same time in two weeks. +**\ [fluffypony]** Yep +**\** Thank you everybody! \ No newline at end of file diff --git a/_posts/2017-04-09-overview-and-logs-for-the-dev-meeting-held-on-2017-04-09.md b/_posts/2017-04-09-overview-and-logs-for-the-dev-meeting-held-on-2017-04-09.md new file mode 100644 index 00000000..d15742df --- /dev/null +++ b/_posts/2017-04-09-overview-and-logs-for-the-dev-meeting-held-on-2017-04-09.md @@ -0,0 +1,277 @@ +--- +layout: post +title: Overview and Logs for the Dev Meeting Held on 2017-04-09 +summary: 0.10.3.2 release, repository naming, website redesign, decoy output selection algorithm, and static ring sizes +tags: [dev diaries, core, crypto] +author: dEBRUYNE / fluffypony +--- + +*April 9th, 2017* + +### Overview + +An overview [can be found on MoneroBase](https://monerobase.com/wiki/DevMeeting_2017-04-09). + +### Logs + +**\** ok +**\** 2. Brief review of what's been completed since the previous meeting +**\** so the main thing was the 0.10.3.1 release +**\** which has mostly been fine, no major breaking issues +**\** there are some GUI fixes that will go into 0.10.3.2, which we aim to tag and release soon +**\** before or after the fork ? +**\** which brings us to +**\** There's this bug with not merging destinations, which is overeager in not merging. +**\** 3. Code + ticket discussion / Q & A +**\** medusa: probably before, due to the thing that moneromooo just pointed out, which is a bit of an annoyance for exchanges +**\** allright thats good. i think a possible bugfix release after the fork shoudl be completely seperate too +**\** medusa: is there something you're expecting will break at the fork? :-P +**\** lets hope nothing is needed \<3 +**\** no +**\** ok shew +**\** I'm planning on merging PRs over the next couple of days +**\** are there any that are don't-merge-yet? +**\** The one I have outstanding for bin2hex +**\** Before merging the PR to name Monero GUI back to Monero Core, I thought it would be good to have a discussion here about that. But perhaps that can be saved for the end of today's meeting. +**\** Oh, I'd kinda forgot-ish about that one... +**\** #658 and #667 obviously +**\** It's currently unmergeable and I don't know if anyone looked at it recently +**\** xmr\_eric - we can discuss it now, it's part of this section anyway +**\** monermooo I will revise and push later today +**\** is he copying me +**\** rebase, damn phone +**\** vtnerd1112: I haven't since looking at it the first time, sounds good +**\** lol +**\** luigi1112: yes +**\** /nick fluffypony1112 +**\** Ok, well I'd like to hear from Jaquee. But my thoughts are that we rename Monero GUI back to Monero Core. Gingeropolous originally named it back to Monero GUI at the time, which was a decent idea, but I think in the end the central Monero software that the public is going to use should be called Core +**\** @xmr\_eric that was among the reasons for calling it Core initially +**\** I spent some time yesterday trying to find a word other than Core to differentiate ourselves from Bitcoin, like Monero Essentials or something, but none really work as well. +**\** Right. I think we should go back to that. +**\** also because I think that the current monero repo will become libmonero +**\** and then monero-cli? +**\** yeah +**\** makes sense +**\** so we end up with 3 repos? +**\** gui, cli and lib? +**\** Jaquee: yes eventually +**\** ok cool +**\** Jaquee: what are your thoughts on GUI vs. Core +**\** libwallet API is only used by gui for now. so i'm thining it could be moved to gui repo. +**\** i would prefer GUI +**\** https://github.com/monero-project/monero-core/issues/663 +**\** how about 'official' instead of 'core'? cause it'll be specified as the official 'gui', cli etc +**\** This isn't just naming the repo, this is naming the piece of software the repo produces +**\** As for names, I assume "Monero Qt" is out? That was once the standard for cryptocurrency wallets but seems to have lost favor. +**\** Essentially, it is branding +**\** if we're going to have lib and cli, and those seems like the optimal nomenclature for those, then i think the logical one for the gui is gui +**\** +1 +**\** or maybe core gui.. +**\** The public doesn't think in terms of CLI GUI +**\** People won't know what GUI means +**\** do they know what core means? +**\** i don't :P +**\** yea but core is kind of confusing since core seems to be lib +**\** pero: I was thinking more like libmonero, monero-tools, monero-core +**\** pero: i'd argue the optimal name for a gui should *not* have "gui" in the name. They aren't called FireFox GUI, Chrome GUI, Word GUI, etc +**\** just Monero +**\** No, but the point is Core is a word that people will begin to associate with that piece of software +**\** gingeropulos I agree +**\** What does Linux mean? +**\** I think core does have a bit of stench to it now +**\** at worst, monero app +**\** The application has to be the most atomic +**\** bigreddmachine: there's no lynx like version of firefox or chrome tho +**\** that I'm aware of +**\** To the public I mean +**\** The problem with naming it just Monero is that no other piece of software gets to be called Monero +**\** Which I'm ok with +**\** yes i can see reason in that argument bigreddmachine +**\** MoneroUser +**\** But it isn't good from a nomenclature standpoint +**\** "Monero Wallet"? +**\** what's monero-tools fluffypony ? the cli? +**\** pero: yes +**\** especially since they ship with the GUI +**\** ^ anyone can make their own wallet +**\** Could we maybe get on with the *dev* meeting... +**\** so that seems to make some sense +**\** ok let's table this for the next meeting, we can open a thread or discuss it further under an existing one +**\** s/thread/issue +**\** Great +**\** At least "Monero node", "Monero wallet cli", "Monero wallet gui" +**\** moneromooo, I like this bike shed. It can fit many bikes +**\** and then we'll make a decision at the next meeting +**\** sounds good +**\** Two cents: 2 repos: libmonero and monero. monero has optional cli build alongside gui. +**\** ok so 4. GetMonero.org redesign discussion +**\** rehrar wanted to show us the designs and get our input on it +**\** I don't want to take much time. Just want to get a special opinion from all the devs about the two proposed designs. +**\** If you haven't seen them already, you can find them here +**\** Design 1: http://imgur.com/a/MwyxX +**\** Design 2: http://imgur.com/a/H9i3z +**\** github link too? +**\** design 1 third draft imo +**\** The idea will be to redesign the current website and also to make an assets document that will have the HTML and CSS framework that we make so anyone can easily make more pages. +**\ {-olark}** Will these sites still be usable with javascript disabled? +**\** No JavaScript will be used. +**\** https://github.com/monero-project/monero-site/issues/245 +**\** All in Jekyll +**\** Sorry, thank you anonimal +**\** design 1 - draft 3 is the most popular on reddit. Most people are asking to add some of the community sponsored youtube vids to the homepage as well. +**\** 1 totally. Marketing addicted +**\** im pretty big on the 2nd one +**\** will these sites still be editable via github by random people, like the current site? +**\** design 2 is nice, but a little too clean +**\** gingeropolous: yes +**\** the first one is too generic and reminds me of shitty webapps/startups +**\** first one with some tweaks +**\** erm +**\** i agree, maybe some pretty-fication to #2 +**\** I think it's important to include one of the Monero introductory videos on the frontpage of whatever design is chosen. +**\** second one\* +**\ {-olark}** Ok +**\** cause it's an OSS / tech project after all +**\** vertp: I don't know if we really need multiple videos on the home page, just the intro one +**\** I think the second design is the most modular and easy to adapt to others making more pages as the site progresses after I'm done with it. +**\** i also prefer #2 +**\** As I mentioned, I still like 1.3 the best. 2 is still better than what we have right now though +**\** Since no one here will probably read that github issue, #2 looks like a tech spec but #1 can be worked with. If reddit has good response for #1 draft 3 then that direction is something to consider. +**\** endogenic / pero: I'm leaning that way too +**\** didn't realize we were doing a meeting this week; I'll be around in like an hour, have to catch a bus. +**\** fluffypony: yes, good point. shouldn't have used the plural tense. +**\** We were playing with adding some color to design 2 +**\** anonimal: otoh we can take some of the elements from design 1, draft 3 and incorporate them into design 2 - @rehrar? +**\** And I think we have a good idea of how to do it. +**\** We should have something for it soon. +**\** Yes, we'll work on that. +**\** site should be an information portal ultimately, the first design is getting the user to download an app asap imo +**\** Any particular things from that design to Port? +**\** it is not aligned with what the site's goals should be +**\** i like #2 +**\** I agree. +**\** Site's goals? It's a website. +**\** yes the goal of providing information +**\** Monero is a unique project, and having a standard site is doing Monero a disservice imo. +**\** @rehrar the world background and the different sections are nice +**\** backgrounds for different sections I mean +**\** I agree that design 2 is a bit sterilized. +**\** Old people need to be able to use this too. Old people don't like to read most of the time because fonts are too small and if they are computer illiterate they don't know how to zoom. +**\** Technical illiteracy = most of planet earth. +**\** Websites are absolutely about a main goal first. That's what good design is about. Funneling people into a path that they already want to go. Eg "What is this Monero thing?" +**\** that argument is pointless anonimal +**\** old people that are actively using the internet have learned how to deal with those issues +**\** anonimal: old people aren't going to use Monero, they'll use some L2 or L3 system on top of it +**\** pero this is a dev meeting, feel free to leave anytime. +**\** You are not a dev. +**\** else they wouldnt be using it +**\** lol +**\** so it's also got to serve the target audience +**\** Yeah, maybe we could have dev meeting and monero meeting. +**\** If the overwhelming majority thinks design 1 even after draft 3 of design 2 then I will probably go with it +**\** moneromooo: this is specifically to get dev input on the design +**\** But we're going to add some color to the design 2. +**\** I think it should be given more underlining about how to buy Monero. Where do you think to put the link? +**\** Monero just has very...Specific branding colors. XD +**\** @rehrar let's see what you come up with on design 2 and then see +**\** Aight. Will do. +**\** hrumag2: no, definitely not, that sort of funnel makes us liable +**\** ... more than "get involved" I think +**\** When I say 'old', I mean plebeian elders of planet earth. +**\** That's all from me. +**\** Any last second opinions? +**\** i have a concern with project scope/budget +**\** i think the work effort is being underestimated and it's underbudgeted +**\** Not underestimated, but underbudgeted for sure. +**\** @rehrar well we do a second FFS if needed, let's see how it goes +**\** On purpose. Part of it is my donation to the community. I believe in it. +**\** Ok. :) +**\** ok on that note +**\** let's move on to 5. Any additional meeting items +**\** only thing I want to ask is just to find out from Jaquee if he managed to get hold of Qt +**\** no, sorry. i've had a busy week +**\** Well, I had this list of bugs I think can be closed. Which should be greppable with mooo.\*bug.\*clos +**\** will take care of that issue in a couple of days +**\** np +**\** moneromooo: yep I'll be closing issues in the next few days too +**\** Thanks. +**\** anything else? +**\** I have a Q: What is the "correct" way to propose an improvement / protocol change to Monero? Bitcoin has the BIP system, whereas for Monero things are basically handled via GitHub issues in the main repo. That means that, though discussions are documented permanently, they can be difficult to find and track over time. Is Monero getting to where it is big enough and has enough contributors that maybe we s +**\** hould have a BIP-like process? +**\** bigreddmachine: easiest way is just for us to have a label on Github (for consensus-critical changes) +**\ {-olark}** I have a few things I would like to talk about regarding https://github.com/monero-project/monero/issues/1673 I should post another update soon +**\ {-olark}** I can wait +**\** fluffypony: but is that the ideal way to do it? after getting merged, closed, etc, those discussions are very tough to find. Something like BIP is a much better long-term place for those discussions +**\** bigreddmachine: I think that changes should be written up as an MRL paper +**\** I'm not asking because I have a specific proposal to make, but because it seems we don't have an ideal system that can grow well +**\** fluffypony: and submitted to MRL? +**\** yes +**\** available permanently as an MRL research bulletin, which makes recommendations to the implementors, and exists as a living document +**\** okay - then shouldn't that be the case for anything consensus changing? +**\** what got me thinking about it is that the discussions behind this month's hard fork are very tough to find. i know it's a small change, but i feel like we don't have a precedent set +**\** bigreddmachine: mostly yes, although I think some things are a little small to write up and might have to be bundled together +**\** let's give that a spin and see how it goes, we can always change the process later on +**\** what makes something "too small" though? I guess my point is that maybe we need to add guidelines to the main repo that explain all this for people to see in the future +**\** olark: do you want to discuss 1673 now? we still have 19 mins before the Kovri meeting +**\** I am happy to do that and make the PR, +**\ {-olark}** Sure +**\ {-olark}** I just wanted to talk about a couple quick things +**\** bigreddmachine: it's subjective - when we changed the block time from 1 min to 2 mins, for eg., the reasons were obvious - yes please do write it up and PR it +**\ {-olark}** What people think about having 3 static ringsizes for monero similar to how we have static fee priorities. +**\ {-olark}** This was an idea moneromooo had brought up in the issue +**\** What ringsizes are you proposing? +**\ {-olark}** To protect users from making foolish mistakes reusing irregular ringsizes +**\** I was about to write "I like it", so I now see why I do... :D +**\** olark: I like it because it removes fingerprinting / metadata leaks +**\ {-olark}** Well if September is mandatory 4 i was thinking like 4, 12, 50 or something similar the details don't matter at this moment but just what people think about having this in place. +**\** I'm fine with it, but 4 is way too small as the minimum, even per the old MRL recommendations +**\ {-olark}** The other thing was since I have been surveying the bitcoin blockchain for a while there is large bias for spent outputs in the past day +**\** to clarify - unlike fees, which *could* be changed on the user-end to something else, this will make non-standard ring sizes be against the consensus protocol? +**\ {-olark}** and how this affects the attack in MRL-001 +**\** bigreddmachine: yes +**\** We could wait to see luigi1112's final ringct sizes, then see how those vary with increasing mixin. +**\** moneromooo: agreed +**\** why only three choices? +**\** jwinterm: so that people actually use the two other than the default +**\** To avoid splitting txes in too many classes. +**\** So how about 10, 20, 50, 100? Something like that. Pending the research of course +**\** you want to get lost in the mix, remember :) +**\** So fireice\_uk is working on the rpc download changes before any crypto stuff ... ? +**\ {-olark}** The assumption in MRL-001 is that an attacker would need roughly 80% of outputs in the entire blockchain to de-anon a transaction but in reality if we use an output selection algo similar to what my survey results convey than in reality an attacker would only need 70%ish of spent outputs in the past day to reliably de-anon some transactions +**\** Oops thought that topic was done +**\** ^ with what ringsize? +**\** vtnerd1112: yes - we decided in the last meeting that he'd switch milestone orders around +**\** Oh, that ought to be done on 0MQ then. +**\ {-olark}** Smooth and myself had come to a conclusion that mixin 4 is fine but if the attack in MRL-001 is made easier with a selection algo like I am suggesting we may need to increase the mandatory ringsizes to protect against an attack like MRL-001 +**\** olark: this changes with zipf, right? +**\** ie. a great portion of the ring uses the past day's outputs +**\** Ok, pigeons told me mymonero seemed to be under lots of load. Ive got some preliminary work done that he could continue to completion +**\** Just enough to give mymonero a bump hopefully +**\** vtnerd1112: that's fine, maybe ping him and tell him that? fireice\_uk never attends dev meetings and is never on IRC +**\** Maybe that's not actually bad. +**\ {-olark}** What to increase it to is up in the air obviously. Still have more work to do +**\ {-olark}** fluffypony: Yes. Based on the survey I have done so far roughly 70% of spent outputs are from the past day. Future surveying will be going over 2011-2012 to see if there is any change in the distributions. +**\** ok I'm fine with that - olark, what are your thoughts on writing it up as an MRL paper later on once the discussion is finalised? +**\** I think current min is still 2. We could go to 4 in september, and still increase later. +**\** I think we should increase it >4 in September +**\** -olark: is there a way to see what the distribution looks like for txs not related to mining? i'd guess a lot of the quickness in spending is from pools transfering out coins to miners, but in the future this might be a much smaller proportion +**\** Are we still playing around with having a static ringsize? +**\** Pool payment txes are often with more than 2 outputs. +**\** @xmr\_eric yes +**\** Cool +**\** moneromooo: with the new range proofs etc. it might be worthwhile just making the min based on that +**\** Not a guarantee of course. Especially now -\_- +**\ {-olark}** fluffypony: Sure I can write an MRL paper once I have more of it fleshed out. +**\** can always use like a 10 output tx as a measuring bar +**\** fluffypony: sounds good +**\** ^ interesting +**\ {-olark}** xmr\_eric: The idea is having 3 static ringsizes for varying levels of paranoia similar to the different fee priorities we have. +**\** Right +**\** moneromooo: if we're just looking for a filter on pool txs, we can always use the pools' apis to get txids. my point was those txs might be 50% of all txs now, but 5% two years from now, which impacts the math. +**\** are disposable / one-time addresses happening? I didn't see it make the list of things not to pull in. +**\** That allows me to... +**\** luigi1112: is kenshi84's disposable address patch ready in the theoretical sense, you think ? ie, can I go over it again assuming the math/crypto's final ? +**\** I haven't looked at it in a while, I'll have to re-review the PR to both the MRL and normal repos +**\** ok we need to wrap up - let's discuss it further later on +**\** 6. Confirm next meeting date/time +**\** April 23 \ No newline at end of file diff --git a/_posts/2017-04-19-an-unofficial-response-to-an-empirical-analysis-of-linkability.md b/_posts/2017-04-19-an-unofficial-response-to-an-empirical-analysis-of-linkability.md new file mode 100644 index 00000000..f888ae5b --- /dev/null +++ b/_posts/2017-04-19-an-unofficial-response-to-an-empirical-analysis-of-linkability.md @@ -0,0 +1,103 @@ +--- +layout: post +title: An Unofficial Response to "An Empirical Analysis of Linkability in the Monero Blockchain" +summary: A community-drafted response to Andrew Miller, et al. +tags: [core, crypto, research] +author: Justin Ehrenhofer (SamsungGalaxyPlayer) and the Monero community +--- + +### Preface + +This release attempts to contain the opinions of the Monero community. It is possible that not every viewpoint is expressed, but this paper includes the best response to the author's ability that encapsulates all these opinions. The author opens all discussion to how certain viewpoints are represented, and the purpose of this response is solely for easier documentation by interested parties. He has done the best to include sources wherever possible, and to be as accurate as possible. For any concerns with this publication, please express them to the [author's Reddit account](https://www.reddit.com/u/SamsungGalaxyPlayer) or on [the Monero subreddit](https://www.reddit.com/r/Monero/). This version has been updated for clarity, though the core content has remained unchanged. + +The Monero contributors and community at large always appreciate any research done on Monero's technology. They heavily encourage constructive criticism of all cryptocurrencies. + +### Notable Findings + +The Monero contributors appreciate the effort that has gone into this mentioned publication and research methods. It helps quantify several realizations that had already been known to the Monero community at large for a long time (ref: [MRL-0001](https://lab.getmonero.org/pubs/MRL-0001.pdf) and [MRL-0004](https://lab.getmonero.org/pubs/MRL-0004.pdf)), including the following: + +1. 0-mixin transactions (those that only include the real input and no others) are traceable on the blockchain. [MRL-0001](https://lab.getmonero.org/pubs/MRL-0001.pdf) (published September 2014) also points this out, and Monero reacted to the concern by prohibiting 0-mixin transactions from the network in April 2016. The current minimum mixin allowed on the network is 2, which was mandated in March 2016. In September 2017, the minimum will be increased to at least 4, though there is [some discussion](https://github.com/monero-project/monero/issues/1673) going on in the community to choose the exact value. For clarification of terms used, ringsize is a newly-adopted term to replace mixin with the intentions of removing comparisons to traditional mixing services. Ringsize = mixin + 1. + +2. The prohibition of 0-mixin transactions has allowed the network to recover relatively quickly by making it harder to know which input is used. This paper helps quantify this recovery, from about 95% traceable to 20% traceable (see appendix). + +3. The proportion of transactions that have their inputs deducible has fallen substantially from 1 January 2016 to 1 Feb 2017 with 2 and 4 mixin transactions. Respectively, these fell from 82% and 72% to 41% and 23% (see appendix). Furthermore, this proportion is down to 0% with RingCT transactions, which are now [over 99% of all new transactions on the network](http://moneroblocks.info/stats). + +4. The phenomenon where the most recent input is the real one is a concern when using Monero. There is no way to prove that this input is indeed the correct one, and with recent transactions, the assertion is nearly impossible to prove and is accurate less than half of the time. As the report states, there is about a 40% chance that the most recent input in a default transaction is the real one. Ideally, this number should be closer to 20% (1 in 5). Note that this does not mean that there is a 40% chance that this transaction is traceable (see appendix). Increasing the transaction ringsize has only a marginal improvement. + +### Recommendations and Responses + +The following are the recommendations listed in the paper and responses to them: + +1. The mixing sampling distribution should be modified to closer match the real distribution. We agree with this recommendation. The discussion covering the possible ways to do this, along with all associated research, [can be seen on GitHub](https://github.com/monero-project/monero/issues/1673) . As the paper acknowledges, we made a temporary improvement to the selection algorithm to choose more recent inputs (instead of pure random selection) in December 2016. Further improvements are required, and they are planned to be ready before or at the September 2017 hardfork date. As the paper notes, this change is not consensus-critical. It can be done the day after completion without a hardfork. + +2. The Monero community should engage in further data-backed analysis of privacy claims. We agree with this recommendation. Data-backed claims are an excellent way to improve the Monero privacy and security features. As stated in the paper, the threats discussed in the paper were discussed in the community previously. Unlike the paper claims, these discussions were not "informal"; instead, they were published in our [MRL-0004](https://lab.getmonero.org/pubs/MRL-0004.pdf) research paper in January 2015. Nevertheless, several of these attack vectors explained in the Decentralized Systems Lab paper are quantified for the first time. + +3. Monero users should be warned that their prior transactions are likely vulnerable to linking analysis. We mostly disagree with this recommendation. The vulnerabilities of 0-mixin transactions were well-documented and continuously shared with the Monero community while they were still allowed. The first research paper shared in the Monero community ([MRL-0001](https://lab.getmonero.org/pubs/MRL-0001.pdf)) was published in September 2014. Furthermore, most of Monero's community growth occurred after these 0-mixin transactions were prohibited across the network. + +### Concerns + +The Monero community would like to list several concerns with this research paper. They are documented below: + +1. We believe that a large proportion of 0-mixin transactions are pool payouts. These transactions should come to no one's surprise that they are traceable, since the pools themselves publish the payment amount to each transaction hash. Thus, we believe that the claims stemming from the traceability of transactions before 0-mixin transactions were banned to be misplaced. If, for example, 50% of non-pool payouts used a positive mixin and 0% of pool payouts did, then the traceability is less for the transactions that use these mixins and greater for pool payouts. We recommend that this is acknowledged in a later iteration of the paper. Ideally, the proportion of pool payouts can be found and compared to the proportion of non-pool payouts, with different traceability proportions for each. There are several reasons why these transactions neither reduce the anonymity of the transaction itself or other users. In regards to the former, coinbase transactions (ie: new rewards given to the pool) are 0-mixin, since having mixins is useless if the input is brand new and seen for the first time. Anyone who mines understands that the source of their money is clear, and so pools received little pressure to increase the ringsize for payout transactions. In regards to other transactions, the pool payouts occur within the day, reducing the negative impact spending these transactions has on other users who may have borrowed the input for their transaction. Thus, pool payouts should include additional mixins, but excluding them has relatively minimal harm. The larger threat is the opportunity cost, where the additional mixins could provide greater levels of privacy for other users. Furthermore, all transactions are still unlinkable by the MRL definition of the word (see "Other Information" point 4) ([source](https://www.reddit.com/r/Monero/comments/65dj7u/an_empirical_analysis_of_linkability_in_the/dga1rza/?context=1)). + +2. We think further emphasis should have been placed in the paper to explain that the claims are only minimally applicable with the state of Monero transactions since March 2016, with the relevance decreasing over time. Though it is mentioned that their first analysis method has little if any current or future relevance, the claims still include these transactions. 0-mixin transactions were prohibited in March 2016, and most transaction volume for the year occurred during and after August. Nevertheless, many of these post-March transactions have inputs that can be deducible, but the traceability typically is not as severe as with 0-mixin transactions. The transactions that are most vulnerable are those in 2014 and 2015, as well as some time needed for the network to recover. + +3. Under the "ethics" section, they state that the paper was published immediately before countermeasures could be deployed. While this is understandable from the given perspective that the blockchain history is not going away anytime soon (or ever), we wish that they had given us an advance copy of the finished draft so that we could have discussed our concerns with the report itself. We wish not to censor any of the research (instead, we encourage research!); however, we hope that future care can be taken before the release of misleading assertions. + +4. Andrew Miller was named in the paper as a consultant to the Zerocoin Electric Coin Company and a board member of the ZCash Foundation. ZCash is a cryptocurrency with a focus on privacy that uses different technology than Monero. However, [he downplayed his involvement in an interview](https://cointelegraph.com/news/monero-transactions-history-can-be-revealed-and-exposed-research) about this paper. We feel author involvement in cryptocurrencies with similar interests should be fully disclosed, though he did refer people to the first page of the report. Nevertheless, we feel that Miller's disclosure of his contribution to a competing project was unsatisfactory, given the severity of the allegations in the paper. + +### Other Information + +1. The timing of the publication. This paper was released approximately an hour before the hardfork. While it is impossible to know the reason for the specific timing without an admission, we speculate that this was timed to draw as much attention to the paper as possible. More people would have been tuning in to see how the hardfork was proceeding than typical community participation traffic. Andrew Miller has responded to this criticism in a Reddit comment, saying "the timing of our release with the imminent hard fork was totally unintentional and a coincidence. No one on the team noticed there was a hardfork planned, and we'd definitely have delayed till afterward if we had." + +2. This paper was shared as "new research" about Monero. While the research is itself new and some of the analysis is the first time that some concerns have been quantified, these concerns themselves are not new. In sharing the paper, the authors often posted misleading claims that asserted these concerns were new. + +3. The Monero Core Team was given an advance draft of the report on 15 March 2017. This report at the time looked only at transactions before January 2017. All further edits to the paper were published before consulting with the Core Team. Riccardo Spagni, known to many as fluffypony or fluffyponyza, responded commending the efforts and stated at the time that the 0-mixin analysis confirmed previous work on [MRL-0004](https://lab.getmonero.org/pubs/MRL-0004.pdf). During the email exchange, Spagni suggested that the research also be published in the Monero Research Lab research, an idea Andrew Miller seemed open to at the time. Furthermore, the real release date was later than the target given to the Core Team, and the Core Team was not given a new estimated date of release. + +4. The paper refers to the traceability of transactions in the blockchain as "linkability". We encourage the authors to change the terminology to "traceability", since linkability typically refers to the ability to connect cryptocurrency wallet location to real-world locations. This will help clear up misconceptions held by many community members, since the Monero Research Lab refers to the connection of funds within the cryptocurrency as "traceability." + +5. This paper has not yet been published, is not finalized, and is not yet peer reviewed. Thus, there will most certainly be changes to this research paper before publication. We suggest that all claims and research be taken as preliminary and not concrete, since not enough people have evaluated their methods of research yet. + +### Conclusion + +We appreciate the effort that went into this research paper, but we suggest the following changes for later improvements: + +1. A re-evaluation of recommendation #3. + +2. A consideration among 0-mixin transactions for pool payouts. + +3. A clearer explanation of claims made in the paper, with separations for the history of all transactions and those used since March 2016. It is disappointing to treat the blockchain data as static when the technology has evolved significantly since Monero's launch. + +4. Future drafts to be shared with the Monero Core Team before release. Their contact information is [dev@getmonero.org](mailto:dev@getmonero.org). + +5. Be more conservative sharing the results. We understand that the authors have an incentive to share the results with others and we also want them to be shared, but we ask that they refrain from using misleading claims to gather traffic (see appendix for example). + +6. Consider cooperating with Riccardo Spagni to permanently include the research portion of this paper in our Monero Research Lab documents. + +### Appendix + +**Figure 5 from the report showing the fraction of deducible inputs. Notice the large drops following block height 1,000,000, when 0-mixin transactions were prohibited. Furthermore, these inputs likely do not include all those used in a single transaction. For instance, for a mixin 9 transaction, 5 may be deduced. This means that the inputs would be reported here as deducible, even if the transaction is not traceable.** + + + +**Table 2 from the report showing the proportion of transactions with a positive mixin that can be deduced. We want to make clear that the findings of this chart and analysis method have absoutely zero relevance to RingCT transactions.** + + + +**Table 3 from the report showing the proportion of deducible transactions where the real input is also the most recently used one in the transaction.** + + + +**Examples of statements we find misleading** + +This is a tweet from a contributor to the paper. + + + +This image is from the [CoinTelegraph interview](https://cointelegraph.com/news/monero-transactions-history-can-be-revealed-and-exposed-research). Based on the wording, you may think an attacker could determine with certainty which input is yours. However, the attacker can guess and be correct less than half of the time. Furthermore, even if the attacker guesses correctly, there is no way of proving this with certainty with data from the blockchain alone. + + + +Andrew Miller asked us to include other statements from the researchers or ZCash Foundation members that we feel is misleading. This paper is not supposed to be a comprehensive list of such statements. It is only useful in providing a few examples. + +This draft was shown to Andrew Miller before release on the website. Some of his considerations have been included in this response. diff --git a/_posts/2017-04-23-logs-for-the-Kovri-dev-meeting-held-on-2017-04-23.md b/_posts/2017-04-23-logs-for-the-Kovri-dev-meeting-held-on-2017-04-23.md new file mode 100644 index 00000000..7e2ade5d --- /dev/null +++ b/_posts/2017-04-23-logs-for-the-Kovri-dev-meeting-held-on-2017-04-23.md @@ -0,0 +1,91 @@ +--- +layout: post +title: Logs for the Kovri Dev Meeting Held on 2017-04-23 +summary: Brief review of what has been completed since last meeting, Monero HackerOne Bounty, 96boards OpenHours showcase, Github repo privilege discussion, website discussion, and code & open tickets discussion +tags: [dev diaries, i2p, crypto] +author: dEBRUYNE / fluffypony +--- + +*April 23th, 2017* + +### Logs + +**\** 1. Greetings +**\** 2. Brief review of what's been completed since the previous meeting +**\** 3. More preparation for [96boards.org OpenHours showcase for Kovri / Monero](https://github.com/monero-project/meta/issues/46) (@fluffypony @danrmiller location status, @anonimal "de-anon consideration" status) +**\** 4. Status (again) of [Monero HackerOne umbrella and bounty](https://github.com/monero-project/meta/issues/39). [hackerone.com/monero](https://hackerone.com/monero) is online but we need to resolve FFS funding before inviting researchers. VRP status for all projects + bounty status +**\** 5. Website status (@rehrar @bigreddmachine @alvinjoelsantos @danrmiller) +**\** 6. Code + ticket discussion / Q & A +**\** 7. Any additional meeting items +**\** 8. Confirm next meeting date/time +**\** Hello. It looks like fluffypony is MIA. +**\** 2. Brief review of what's been completed since the previous meeting +**\** https://github.com/monero-project/kovri/pulse/monthly \<-- #615 to #629, in particular #627 +**\** Anything else before we move onto 3.? +**\** 3. More preparation for [96boards.org OpenHours showcase for Kovri / Monero](https://github.com/monero-project/meta/issues/46) (@fluffypony @danrmiller location status, @anonimal "de-anon consideration" status) +**\** fluffypony is MIA, I think pigeons is MIA, I'm not de-anoning for the time being. +**\** Anything else on 3.? +**\** on 2 i am working on removing the global client context. +**\** Whatever your strategy is, the same strategy *should* apply to core context, just FYI. +**\* anonimal** we can talk more in 6. +**\** 4. Status (again) of [Monero HackerOne umbrella and bounty](https://github.com/monero-project/meta/issues/39). [hackerone.com/monero](https://hackerone.com/monero) is online but we need to resolve FFS funding before inviting researchers. VRP status for all projects + bounty status +**\** fluffypony needs to move this to funding required https://forum.getmonero.org/6/ideas/87597/monero-bounty-for-hackerone +**\** We can't move forward until that happens. +**\** I've submitted a VRP to monero/#1995 +**\** luigi1112: is that something you have privs to do ? +**\** (also surae's). +**\** Once #1995 is fleshed out, I'll submit to the core repo and the website with relevant adjustments (as we discussed in previous meeting(s)) +**\* anonimal** not sure if luigi is around, anything else on 4.? +**\** Before the alpha release, if i find a bug that can, for example, crash a router, should i go through the process or is it cool to just PR ? +**\** moroccanmalinois: PR. We probably won't even apply our VRP until we are in beta, btw. +**\** We should add a note if that will be the case. +**\** ok +**\** 5. Website status (@rehrar @bigreddmachine @alvinjoelsantos @danrmiller) +**\* anonimal** has nothing on 5., will await any response +**\** Alright, more no-shows AFAICT :/ +**\** 6. Code + ticket discussion / Q & A +**\** like you said move to the other contexts after client context for me. +**\** moroccanmalinois: re: #624, I received a response saying that he'll look into the issue. +**\** ok +**\** guzzijones12: you can PR the client one first before moving onto core. There may be related issues to resolve anyway. +**\** (as long as it works) +**\** yes ok. +**\** Anything else on 6.? Questions? +**\** 7. Any additional meeting items +**\** None from me. Anyone else? +**\** i am good. +**\** I am good +**\** 8. Confirm next meeting date/time +**\** Two weeks, same time. +**\** Thanks everyone. In under 20 minutes! +**\** Sorry here. +**\** Lel. I was expecting meeting at 1. +**\** tumbleweeds +**\** ;) +**\** hows the Kovri site? +**\** any news on that end? +**\** Well, I showed the design for it, which was based off of the chosen Monero design. +**\** I've been making Monero wires. +**\** The Kovri site should be easier since there's not as much info. +**\** cool - great work +**\** Because of that, I'd like to make custom pages for each Kovri page based on the same CSS framework that will be developed for Monero. +**\** The goal for both sites is to make upkeep and adding/editing pages as simple as possible. As simple as copy and pasting out of a HTML/css assets document to construct the blocks of pages. +**\** fab +**\** sounds good my man +**\** If you'd like to take a look at the wires, let me know. +**\** I'm still toying with the garlic logo when I feel inclined. :P +**\** :) +**\** got a link to the latest wires? +**\** hard to make the logo and make it look garlic with those colors. imo +**\** Sure. I'll PM them to you. +**\** sorry afk. will be around later, ping again if you think about it +**\** luigi1112: can you move this to funding required? fp said he would do it soon after the last meeting IIRC https://forum.getmonero.org/6/ideas/87597/monero-bounty-for-hackerone +**\** I probably can, not at computer right now though +**\** k +**\** moroccanmalinois: new proposal open. #630 +**\** 5. Website status: @pigeons got the site I worked on up and running on a server, but I guesss we will go with @rehrar design since it is better +**\** as far as the deanon goes, I actually like that our figurehead working on Kovri is anonymous +**\** just food for thought +**\** Perhaps I'm in the minority, but I think it's both prudent (from a rubber hose attack perspective) and aligns with the ethos of the project. +**\** @anonimal +**\** Sounds fair. \ No newline at end of file diff --git a/_posts/2017-05-07-logs-for-the-Kovri-dev-meeting-held-on-2017-05-07.md b/_posts/2017-05-07-logs-for-the-Kovri-dev-meeting-held-on-2017-05-07.md new file mode 100644 index 00000000..49e4f888 --- /dev/null +++ b/_posts/2017-05-07-logs-for-the-Kovri-dev-meeting-held-on-2017-05-07.md @@ -0,0 +1,201 @@ +--- +layout: post +title: Logs for the Kovri Dev Meeting Held on 2017-05-07 +summary: Brief review of what has been completed since last meeting, Monero HackerOne Bounty, 96boards OpenHours showcase, website discussion, and code & open tickets discussion +tags: [dev diaries, i2p, crypto] +author: dEBRUYNE / fluffypony +--- + +*May 7th, 2017* + +### Logs + +**\** 1. Greetings +**\** 2. Brief review of what's been completed since the previous meeting +**\** 3. More preparation for [96boards.org OpenHours showcase for Kovri / Monero](https://github.com/monero-project/meta/issues/46) (@fluffypony @danrmiller location status) +**\** 4. Status (again) of [Monero HackerOne umbrella and bounty](https://github.com/monero-project/meta/issues/39). [hackerone.com/monero](https://hackerone.com/monero) is online but we need to resolve FFS funding before inviting researchers. VRP status for all projects + bounty status +**\** 5. Open forum for https://github.com/monero-project/kovri/issues/630 +**\** 6. Website status (@rehrar @bigreddmachine @alvinjoelsantos @danrmiller) +**\** 7. @EinMByte ...where is he? Github repo privilege discussion +**\** 8. Code + ticket discussion / Q & A +**\** 9. Any additional meeting items +**\** 10. Confirm next meeting date/time +**\** Hello +**\** hi +**\** hey! +**\** o/ +**\** Here +**\** \o +**\ {-fluffypony}** hi! +**\** Here for a bit, then gone, then back. +**\** Yay, enough people for a party. +**\** Hello +**\** 2. Brief review of what's been completed since the previous meeting +**\** 3...2...1... KOVRI!!! +**\** hello +**\** For me, see http://forum.getmonero.org/9/work-in-progress/86967/anonimal-s-kovri-full-time-development-funding-thread?page=&noscroll=1#post-90900 +**\** moroccanmalinois can fill us in on his work. +**\** i've been playing with fuzz testing +**\ {-fluffypony}** nice +**\** I've looked through the PR's, looks like fun. +**\** it's the beginning. More tests to come +**\** Any questions/comments on point 2? +**\ {-fluffypony}** and guzzi ? +**\** guzzi is not here, ...again... +**\** He says he's doing work but I haven't seen a commit or question from him in over 7 weeks, AFAICT. +**\** I think he's trying to separate the contexts from the singleton. At least that's the end goal. +**\ {-fluffypony}** guzzi: when you read this, please make an effort to attend meetings +**\ {-fluffypony}** I know you're around at other times, but meetings are important +**\** Yes, please. +**\** Ok, anything else on 2.? +**\ {-fluffypony}** no +**\** 3. More preparation for [96boards.org OpenHours showcase for Kovri / Monero](https://github.com/monero-project/meta/issues/46) (@fluffypony @danrmiller location status) +**\** Is pigeons still in Africa? This point was moved from last meeting. +**\ {-pigeons}** i returned yesterday +**\** Are you suggesting pigeons migrate ? +**\ {-pigeons}** i saw rock doves +**\** fluffypony? How's it going? +**\ {-fluffypony}** anonimal: it's a podcast, right? +**\** https://www.96boards.org/openhours/, there are videos too. +**\ {-fluffypony}** ok well I'm ready whenever +**\ {-fluffypony}** I don't really prepare for stuff like this +**\** sorry i'm late! +**\** Ok well what time/date works for you? +**\** fluffypony ^ +**\ {-fluffypony}** anonimal: my PA would have to schedule it - probably best to get my PA to schedule myself and pigeons and them +**\ {-fluffypony}** she's good at that +**\ {-fluffypony}** it's literally her job :-P +**\ {-pigeons}** I was thinking ask hyc if he's interested, he's been playing with arm and monero i think +**\ {-fluffypony}** cool +**\ {-fluffypony}** hyc is a beautiful man +**\** +1 Ric's PA. She was great when i wanted to schedule a podcast +**\* anonimal** pinged him in #monero-dev +**\** Ok well at this point, IMHO, fluffypony I think it would be good for you to touch base / introduce yourself to sdrobertw in #OpenHours on freenode. +**\** I think I can only play the middleman for so long. +**\ {-fluffypony}** email is better for Shay, I don't think I can teach her IRC :-P +**\** Contact info? I have none. +**\ {-fluffypony}** for them? +**\ {-fluffypony}** didn't we reach out to them via email first? +**\ {-fluffypony}** \* can't remember +**\** For Shay +**\** No, not via email, all IRC. +**\ {-fluffypony}** oh lol +**\ {-fluffypony}** pa@spagni.net +**\** Alright, anything else on this point before moving on? +**\** 4. Status (again) of [Monero HackerOne umbrella and bounty](https://github.com/monero-project/meta/issues/39). [hackerone.com/monero](https://hackerone.com/monero) is online but we need to resolve FFS funding before inviting researchers. VRP status for all projects + bounty status +**\** I've sent a VRP to monero, it's been merged. I believe we're funded at ~500 XMR, which is great. +**\** Any questions? +**\** We just need to launch after submitting VRP to the GUI (and site?) +**\** Sound good? +**\** Is the bounty held in xmr or something else? +**\** Yes. Link to FFS in the meta issue. +**\** https://forum.getmonero.org/8/funding-required/87597/monero-bounty-for-hackerone It was funded to 500 XMR and then increased to 1000 XMR for further funding +**\** ty +**\** I think we can start now before funding is at 1000. +**\** (it won't mean we'll find researchers immediately anyway) +**\** Any questions/comments before moving onto next point? +**\ {-fluffypony}** yrah +**\ {-fluffypony}** agreed +**\ {-fluffypony}** we can continue to increase it as necessary +**\** Ok. Moving on, +**\** 5. Open forum for https://github.com/monero-project/kovri/issues/630 +**\** Comments needed before we move on this. +**\ {-fluffypony}** I agree with MoroccanMalinois, but I think it's manageable if we set a severity +**\ {-fluffypony}** and some caveats +**\** Maybe a strict validity domain definition would do good (ie, "we only accept vulns in the following categories"). +**\** And then expand the list as stuff matures. +**\** moneromooo - why would we restrict? +**\** To prevent known problems from being reported, or problems in stuff that is known to be unfinished. +**\ {-pigeons}** because the code has a bunch of legacy mess and is early state with low hanging fruit that is just later on the to fix when that section gets refactored +**\** Yes. So, with that said, I don't know what categories we could even have. +**\** *at this stage* +**\** moneromooo: did you have any ideas on categories for this stage? +**\** No. I've not really looked at kovri yet, despite saying I would (sorry). +**\ {-pigeons}** i2p consensus related issues +**\ {-pigeons}** if we implement like X we might cause incompatibility +**\ {-pigeons}** maybe those but again maybe those are known and will be fixed when those sections are given love +**\** Anything which can leak keymat. Good starting point. +**\** Ideally you'd start giving bounties when you know you've done what you could, and the bounty to find bugs is less than what your time is worth looking at it :) +**\** pigeons: Well, then I think that's java I2P's problem because they would then have to keep up with us. What we could do now though is start with a research-related category for general specifications? +**\** So it's a bit subjective. +**\** moneromooo: indeed, and this is border-lining on simply hiring a new dev too with the funds available. +**\** Well, the draw is that the bounty ensures results for the money. +**\** So expert time. +**\** What if we opened bounty for non-implementation research? I know this is an MRL area though. +**\** Or we could open more categories for implementation but the payout is smaller because code is Alpha? +**\** For finding bugs in the theory, definitely worth doing so (for monero anyway, I expect kovri's following established research already). +**\** (then they would risk waiting to beta to 0day to get bigger payout?) +**\** what up kids? I'm here. +**\** I think monero's research is more vetted than I2P's, even though I2P has been around longer. Simply because there are less moving parts. +**\** +1 for bounty for non-implementation research +**\** Interesting. +**\** Just my opinion. I've read the I2P papers available, I'm not blown away but it's better than nothing. +**\** And not like I'm in a position to drop everything to do purely research so... +**\** We'll add categories for bounty? One obvious one being research. Maybe crypto implementation sooner than later since that's a big one. +**\** Sound fair? +**\** From a relative outsider, it seems like a sensible start. +**\** yes. is "leaked info" too broad of a category? +**\** yes for me +**\** Yes because a leak would cover too much code that hasn't been vetted. +**\** \* could cover +**\** Ok, I'll get that going then. +**\** Moving on. 6. Website status (@rehrar @bigreddmachine @alvinjoelsantos @danrmiller) +**\ {-pigeons}** I need to talk with fluffypony about a potential dns thing +**\** aight, so just in case somebody hasn't seen the Kovri web design here it is: http://imgur.com/a/An8K8 +**\** it's the top one +**\ {-pigeons}** then the demo of ajs' site should be up +**\ {-fluffypony}** I got msgs about it +**\ {-fluffypony}** will look at it tomorrow +**\** it's based on the same framework as the getmonero.org website, so once the custom framework is made for one, it is easy to make pages for the other +**\** my update is that we're making the framework even now, and it's coming along well, I should be able to make a few experimental Kovri pages soon +**\** The question is content. +**\** I think the "It's I2P, but in C++" phrase should go; we should use our standard "A secure, private, untraceable C++ implementation of the [I2P anonymous network](https://getmonero.org/knowledge-base/moneropedia/i2p)" +**\** I will work with rehrar to write up some content, but need direction on what should be included. +**\** that's fine. Copy is not indicative. :) +**\** My past month has been packed getting ready for my phd comprehensive exam (1 step before the defense). So I haven't looked at the site yet, but talked briefly with ajs about it and plan to get more involved now that that's done. +**\** Other than that, can we move this item to the website meeting in #monero in 10 minutes? +**\** sure, that sounds alright. +**\** It looks nice (says the cow who's got no clue about design). +**\** K +**\** bigreddmachine ajs: will you be around in 10 minutes in #monero? +**\** Yes +**\** yeah, i'm also editing tonight's podcast episode so i may take a minute to reply +**\** rehrar: yes, what moneromooo said, looks nice +**\** cool. If people have ideas for content that are not on the demo site +**\** Ok, moving on. 7. @EinMByte ...where is he? Github repo privilege discussion +**\** let me know +**\** I'd like to have a simple website for alpha release :) +**\** fluffypony: so... his last commit was from Septemeber 19th, he's not responded to 99% of my pings since then... +**\** i haven't seen him since i started getting involved in Jan +**\** I speak highly of him and his work, I think he's a great contributor and wish he was around more. +**\** could be a legal issue? +**\** The problem is he's not around anymore, he has assigned issues of which I've had to assign myself since he's not around to do them. +**\** And he has repository push access. If something happened to him and his account is compromised, we could be left in an embarrassing trolling situation where someone deletes the repo. +**\** I don't want to send any wrong signals but I also think access privileges should be on an as-needed basis. +**\** i think that's fair. can always be re-established if he comes back and he can be verified +**\** in that vein, should things like Salti tracking be moved to another place? +**\** I don't know, we'll have to bring that up at the next meeting I think since we're running out of time. +**\** fluffypony: any thoughts about this? Will you remove EinMByte's github push access privileges? +**\** I think it's fair to revoke for inactivity and failure to reply to pings. Reinstate when back. +**\** okay, can we add #619 to next meeting's agenda? +**\** I'd also want to remove warptangent's key (unlikely to be back to use it) and a few others. +**\** bigreddmachine: oh, sure I guess, more research/info needed. +**\** k i'll just reply to the issue and talk about it there for now. sorry to jump into other discussion about that. +**\** No problem +**\** Since we're running out of time, 8. Code + ticket discussion / Q & A +**\** last update from me — mozilla work continues with the proxy stuff, but not ready yet. i don't have a good feel for how long +**\** Anything pressing? Questions/comments that can't be answered on github or after the meeting? +**\** Ok, thanks bigreddmachine +**\** not from me, I'll be in contact :( +**\** :) +**\** 9. Any additional meeting items +**\** none. thanks anonimal! +**\** Nothing from me, other than I need to AFK rehrar so, bigreddmachine ajs pigeons if you want to talk more about kovri-site then I'll have to read backlog +**\** aight, thanks. +**\** Now over to monero! +**\** K +**\** Thank you all if you keep the torch burning for the site, awesome. +**\** 10. Confirm next meeting date/time +**\** 2 weeks, same time? +**\** indeed +**\** Ok. Thanks everyone :) \ No newline at end of file diff --git a/_posts/2017-05-07-overview-and-logs-for-the-dev-meeting-held-on-2017-05-07.md b/_posts/2017-05-07-overview-and-logs-for-the-dev-meeting-held-on-2017-05-07.md new file mode 100644 index 00000000..93a4768b --- /dev/null +++ b/_posts/2017-05-07-overview-and-logs-for-the-dev-meeting-held-on-2017-05-07.md @@ -0,0 +1,291 @@ +--- +layout: post +title: Overview and Logs for the Dev Meeting Held on 2017-05-07 +summary: Sub / disposable addresses, smart mining GUI, 0MQ, and MyMonero-in-tree discussion +tags: [dev diaries, core, crypto] +author: dEBRUYNE / fluffypony +--- + +*May 7th, 2017* + +### Overview + +An overview [can be found on MoneroBase](https://monerobase.com/wiki/DevMeeting_2017-05-07). + +### Logs + +**\** 1. Greetings +**\** 2. Brief review of what's been completed since the previous meeting +**\** 3. Code + ticket discussion / Q & A +**\** 4. MyMonero-in-tree discussion +**\** 5. Any additional meeting items +**\** 6. Confirm next meeting date/time +**\** so let's start with 1. Greetings (aka roll call) +**\** hi +**\** hi +**\** present +**\** hello! +**\** tewinget apologises, he'll be late +**\** Sup +**\** o/ +**\** Yo +**\** hyc / luigi1111 / ArticMine / othe / smooth / anonimal / binaryFate / dEBRUYNE / dnaleor / gingeropolous / iDunk / IPGlider / Jaquee / jwinterm / kenshi84 / knaccc / luigi1112 / luigi1115 / NoodleDoodle / papalazzarou / pigeons / RedLion[m] / redlion +**\** hhelo +**\** :) +**\** also me +**\** medusa +**\** anyone I forgot +**\** o/ +**\** oh those are not present whoops +**\** lol vtnerd +**\** ok so +**\** 2. Brief review of what's been completed since the previous meeting +**\** merged a bunch PRs +**\** kenshi84's GPG key changed +**\** I've confirmed it via sidechannel +**\** we have a new sweepbelow function in the CLI, which you may find useful +**\** we also have a new heavier bias in output selection towards newer outputs +**\** moneromooo can fill us in on that +**\** Hi +**\** oi +**\** smart mining is enabled in the GUI +**\** as in the selection box +**\** Hmm, I just twiddled the settings for the recent output selection, really. To match some data in the Miller et al paper. +**\** which is pretty cool +**\** indeed +**\** also Jaquee has done some work on getting iOS back on track after it borked (visually) +**\** well iOS / mobile +**\** which brings us to +**\** 3. Code + ticket discussion / Q & A +**\** yes. and there's some new translations added to gui +**\** we have a number of open PRs +**\** when tewinget is off his bus he can update us on 0MQ +**\** which I'd REALLY like to move forward with ASAP +**\** it's been sitting in a holding pattern for ages +**\** Snipa: also if you're around maybe you can update us on the testing on that ? +**\** I'd like it to be optional, so it can be merged (and thus tested), without causing massive breakage if it does break. +**\** afaik that was the case +**\** sounds like a good idea +**\** also disposable addresses is still hanging around - I think that's pending a review from one of the luigis? +**\** AFAIK yes. Also RandomRun had an idea to make it better. +**\** I don't think there's a problem with that hanging around and being improved +**\** as long as the parallel MRL write-up is there +**\** I'd like to discuss 1998 +**\** the PR, not the year +**\** https://github.com/monero-project/monero/pull/1998 +**\** at this point in time I'm still swaying towards prevent-user-stupidity-by-default +**\** at the slight inconvenience for a power user / sysadmin who might go "omg really" and then add the flag +**\** I know vtnerd feels the same way, which is why he added it in the first place +**\** I'd be interested in strong arguments for removing the flag +**\** wouldnt a text disclaimer be enough? +**\** i don't have a strong opinion +**\** Jaquee: if you try bind externally and start it without the --confirm-external-bind flag then it refuses to start +**\** and it tells you why +**\** ok. apparently hyc started the discussion. Are you around? +**\** I know hyc doesn't like it +**\** vtnerd: has anyone else expressed disdain for it? +**\** AFAIK, just the people on that PR and the one referenced +**\** and possibly one person in IRC, but they seemed to be questioning why it was necessary (I think) +**\** its somewhat low effort to get around it, so most people just add the flag I thnk +**\** no one has privately contacted me about it for any reason if that was the question +**\** ok +**\** unless hyc comes in I move to close the PR, we can always re-open it later +**\** ok with me +**\** ok next PR for discussion is 2011 +**\** moneromooo had concerns that it was touching consensus critical issues +**\** so/issues/part of the code +**\** Yes, but it turns out it's actually bypassed when a tx comes from a block. The patch is fine. +**\** I OK'd it since. +**\** ah ok' +**\** Well, wait. +**\* fluffypony** stops...hammer time +**\** It's really uneeded (only the wallet bit was wanted). But it's not forkworthy. That said... +**\** Older wallets *might* create txes which aren't relayed by newer daemons. +**\** That's fairly unlikely, since my code targets 2/3 of max size, but the size approximation is not very precise. +**\** That said, I think it's fine to merge. +**\** hey. just popped in. reading history +**\** hi hyc ! +**\** Re: 2011, perhaps it also should be dependent on the fee priority level used +**\* fluffypony** plays elevator hold music +**\** ok, if n0b0dy else cares about that external bind thing then whatever. to me it's redundant +**\** ok +**\** since you had to explicitly request a non-localhost address already +**\** sure, but you'd be surprised how few people know that 0.0.0.0 exposes everything :-P +**\** ^ +**\** it d0esn't protect against typos/accidents. it only pisses off people who expect the computer to do as it's told +**\** hyc: view it like a weak password warning +**\** you can't just expect the computer to accept 1234 as a password +**\** yeah, ok... +**\** Well, I would... +**\** lol +**\** moneromooo is the exception to every rule :-P +**\** now on the GUI side, the only thing I wanted to bounce around is 688 +**\** tooltips are fine, but if we're going to do some sort of unified help then I would veer towards an overlay that shows once the first time you enter a screen, and can be re-called by clicking the [?] button on the taskbar +**\** https://s-media-cache-ak0.pinimg.com/originals/c1/e1/bf/c1e1bfd7fb2770f6745d95af8bf89865.jpg +**\** like that style +**\** https://s-media-cache-ak0.pinimg.com/originals/43/6e/74/436e746b35142f41d5f9bb8e765963e4.jpg +**\** http://eyeviewportal.com/filecache/b38/73d/85-cropped-w545-h409-of-1-FFFFFF-evappguiguidecontentimage002.jpg +**\** like that +**\** sounds good +**\** :+1: +**\** problem is [?] is not around if you use native title bar +**\** Jaquee: where else could we add a help button? bottom left? +**\** one suggestion i'd make for that is to make it c lear to the user they can recall it easily by doing "X" so that they don't fret about having to memorize everything before it's closed +**\** recall it -> the help screen +**\** i think ^ is good as a start +**\** Where is it on the title bar then, since it's not a WM thing ? +**\** endogenic: agreed +**\** s/Where/Why/ +**\** but some buttons could need longer desriptions +**\** like sweepunmixable and paymentid for example +**\** Jaquee: there's enough space in the help overlay, we can use a smaller font to explain them +**\** how breadwallet on ios handles it when setting up is quite good +**\** or move the help to somewhere where there's space +**\** and use an arrow +**\** yeah. we could find a place for that help button +**\** ok - any other PRs that need discussion or can we move on? there's general Q&A shortly +**\** I'd like to merge 261 on monero-site +**\** sgp: there's a website meeting after the Kovri one +**\** so we can discuss it then +**\** ok +**\** ok so +**\** 4. MyMonero-in-tree discussion +**\** so basically this is about nose-covering and making sure I'm not abusing my position as a maintainer and member of the Monero Core Team +**\** currently MyMonero has a working API (largely unspecced to be sure), two client implementations (website and app), two server implementations (the live backend and OpenMonero), with a third one coming +**\** I'd like to make sure there is general acceptance and buy-in that the API can be implemented as the general API for lightweight wallets (ie. wallet that use remote viewkey scanning) +**\** is it carved in stone now +**\** if we need to tweak it we can still do that? +**\** is the license unrestricted? +**\** and that MyMonero-written or MyMonero-derived code is generally acceptable to be merged into the source tree (ie. the open-source backend implementation that vtnerd is working on) +**\** redlion: BSD 3-clause +**\** hyc: as long as mWo12 changes it, and we match the changes in the live backend and the new backend then yse +**\** yes +**\** we can make any changes, and we WILL make changes to make it smarter +**\** If it's beneficial to monero and it works fully by itself without needing proprietary gunk, then I'm OK with it. +**\** eg. tx history comes in raw, instead of paginated +**\** so that needs to change +**\** +1 moneromooo +**\** moneromooo: yeah the new backend will use LMDB instead of mysql +**\** so it will be unencumbered in the source +**\** As long as there are no proprietary dependencies I am fine +**\** I like it even more now ;) +**\** I think it beneficial too +**\** Maybe a separate repo (similar to monero-core) might be best, but that's details. +**\** \*its +**\** it's +**\** it's +**\** can't wait to run a mymonero node myself! +**\** also the current "primary" wrapper around the DB is actually C, so theres that for you guys +**\** moneromooo: I thought about that, but it's a single daemon that *should* exist in the repo alongside the wallet RPC etc. +**\** doesn't it supersede wallet-rpc? +**\** now +**\** hyc: no +**\** wallet-rpc is good for integration, this isn't +**\** there is obviously an element of centralisation, but it’s nearly impossible to avoid +**\** also on this topic +**\** Jaquee has begun working on client integration in the CLI and GUI +**\** "client integration" ? +**\** you mean for light-wallets? +**\** that will mean that both CLI and GUI will be able to run in lightweight / remote-scanner / MyMonero mode +**\** moneromooo: as opposed to implementing the server protocol +**\** sounds good +**\** Oh, mymonero client integration ? +**\** moneromooo: let's call it something else +**\** That went pretty damn fast :D +**\** "lightweight wallet" +**\** it's not really centralization if any `monerod` acts as a server +**\** but I'm still missing why we need old wallet-rpc if this mymonero api exists +**\** it's literally my monero :) +**\** hyc: wallet-rpc is completely different +**\** so the core GUI will be able to interact with MyMonero backend too? +**\** for people that want to run VPS node but keep their viewkey ? +**\** Yes, would be nice to see what bits are needed where, and the actual API (even if roughly). +**\** it provides an API for integrators +**\** @johnalan yes +**\** so basically +**\** is this needed with the MyMonero Desktop wallet? +**\** With what as the backed / server +**\** That can be posted later though, :49 now. +**\** monerod? +**\** lightweight wallets will have 3 server options: +**\** 1. OpenMonero +**\** 2. the new in-source backend that vtnerd is working on +**\** 3. the live MyMonero backend +**\** it will also have multiple client options: +**\** afaik the main difference btw an ordinary wallet and mymomero is you tell mymonero your viewkey +**\** 1. OpenMonero's web wallet (clone of the current MyMonero web wallet) +**\** and the ordinary wallet has all your keys +**\** 2. the MyMonero applications +**\** 3. monero-wallet-cli +**\** 4. monero-wallet-rpc +**\** 5. the Monero GUI +**\** hyc: monero-wallet-rpc can still use this on the backend +**\** so it's unrelated +**\** ok +**\** ok +**\** about #2011 - you could modify it to (median)+0.6% for it to be mine-worthy, or even have the wallet check for fee setting and then it would be matched like 1: +0.6%, 2: +2.4%, 3: +12%, 4:+100% +**\** also this will mean that the GUI / CLI may end up supporting the MyMonero 13-word seed derivation by virtue of the integration effort +**\** does anyone have a fundamental issue with that ? +**\** no +**\** I mean, I do, because I don't want to be abusing my position, but it is what it is :-P +**\** didn't you deprecate 13-word? +**\** Did you not say the 13 word seed was going to be obsoleted ? +**\** jollymort: working on it +**\** no +**\** but client still needs to be able to read 'em +**\** electrum/mycelium support a few different seed lengths iirc +**\** works well +**\** also luigi was playing around with an idea for 17-word, integrating creation height in it etc +**\** moneromooo: it's import only +**\** not create +**\** https://github.com/mymonero/mymonero-app-js/issues/77 +**\** doesn't it put a huge load on mymonero when someone asks it to scan the blockchain from zero with their view key? How long does mymonero take to scan the entire blockchain? +**\** Anyway, I'm fine with that as presented. +**\** that all sounds like a win to me. people have been whining about not being able to import their 13-word seed into regular CLI wallet +**\** so monero-wallet-cli/monero GUI will not be able to create light-wallets? +**\** knaccc: yes it does - about 10 minutes +**\** yeah import only sounds lovely +**\** If we are setting the stage for a competitive market based upon FLOSS then I am fine with it +**\** I do have the ASM code working, so hopefully that will tighten up some too (altough there is something else blocking that) +**\** shuannelson: yes they will +**\** but with 25 word seed, not 13 +**\** we have 7 minutes left - so I'd like to move on to the last item +**\** awesome! +**\** we can discuss MyMonero more after the meeting +**\** @shaunnelson, I think it's just that the CLI/GUI won't create 13-word seeds, but will accept already created ones +**\** yeah sounds fine +**\** 5. Any additional meeting items +**\** 10 mins is quite a speedup vs downloading the entire blockchain, so sounds awesome. +**\** any thoughts on future of penalty/blocksize? i kind of left the research open-ended +**\** ^^ get a faster CPU and it'll be quicker ') +**\** Does anyone have a working monero-core or mymonero build on ios currently? I've been fiddling around and I can't seem to get either properly functional on the sim/device, though I may be missing something +**\** lol hyc +**\** redlion: pls come join #mymonero but yes i do :) +**\** redlion: i have. it has some nasty bugs but it's running +**\** ok thanks, I'll talk to you after this +**\** btw iOS still limits process VM size to 4GB so we won't be running monerod native on iOS any time soon +**\** @jollymort let's discuss it after the meeting, or maybe next week - there are 2 more meetings to go tonight :) +**\** and that's a large topic +**\** sure, another time +**\** thanks jaquee, are there any build instructions or a (sort of) working build posted somewhere? +**\** 6. Confirm next meeting date/time +**\** May 21 +**\** day before Consensus +**\** cool +**\** oh. this week I expect to have wolf miner fully ported to Android, with GPU support too +**\** endogenic can come to my hotel and we can do the meeting together :-P +**\** oooh +**\** anyway, I have the daemon's side of the code rebased and *nearly* ready to PR and merge. I mean, it could be merged now, but I should clean it up a little/address a few more of the comments on the existing PR first. +**\** the wallet side of things will be based on that, and won't take too long. I just thought it made sense to separate it into two PRs (and rebase while I'm at it because why not?) +**\** suweet +**\** just check the meeting logs for the bit from moneromooo about it +**\** (the wallet stuff is still "done already", but as with the daemon side there are comments/suggestions to address as I rebase it as well.) +**\** at any rate, I plan today to finish with the cleanup of the daemon side of things, close the existing PR, and open a new one for the daemon that should be mergeable. +**\** great stuff +**\** pigeons: did you see the 96boards thing? +**\** fluffypony: sorry I didn't respond right away to your pinging on the github PR, but when I said it was already rebased I meant on a different branch, as I'm leaving that branch up (and separate) until I finish rebasing. +**\** ok cool +**\** tewinget: is the 0MQ stuff deselectable if needed (so if it somehow breaks, you can run the wallet with the existing JSON comms) ? +**\** wallet/daemon +**\** moneromooo: I'll make it so when I rebase the wallet side of things. +**\** Excellent, thank you :) \ No newline at end of file diff --git a/_posts/2017-05-17-disclosure-of-a-major-bug-in-cryptonote-based-currencies.md b/_posts/2017-05-17-disclosure-of-a-major-bug-in-cryptonote-based-currencies.md new file mode 100644 index 00000000..e539d8e5 --- /dev/null +++ b/_posts/2017-05-17-disclosure-of-a-major-bug-in-cryptonote-based-currencies.md @@ -0,0 +1,49 @@ +--- +layout: post +title: Disclosure of a Major Bug in CryptoNote Based Currencies +summary: Patched in Monero and others, but still in the wild +tags: [core, crypto, research] +author: luigi1111 and Riccardo "fluffypony" Spagni +--- + +### Overview + +In Monero we've discovered and patched a critical bug that affects all CryptoNote-based cryptocurrencies, and allows for the creation of an unlimited number of coins in a way that is undetectable to an observer unless they know about the fatal flaw and can search for it. + +We patched it quite some time ago, and confirmed that the Monero blockchain had NEVER been exploited using this, but until the hard fork that we had a few weeks ago we were unsure as to whether or not the entire network had updated. + +Once we were certain that the network had updated, we notified all active and affected CryptoNote coins, including CryptoNote themselves, Bytecoin, Forknote, Boolberry, DashCoin, and DigitalNote. + +***Note that, at this time, only Monero, Aeon, Boolberry, and Forknote have updated.*** We have given the other currencies as much time as possible, but cannot hold back disclosure any longer. + +***We strongly caution against anyone using, trading, exchanging, or running services involving the following currencies affected by this issue: Bytecoin, DashCoin, DigitalNote*** + +### Timeline + +2017-02-19: A member of the Monero Research Lab discovers the exploit, triggered by a detailed discussion of the [XEdDSA signature schemes](https://whispersystems.org/docs/specifications/xeddsa/) on the [Curves mailing list](https://moderncrypto.org/mail-archive/curves/2017/000846.html) +2017-02-20: The Monero blockchain is scanned to see if this had ever been exploited; thankfully it had not and the blockchain is intact. +2017-02-21: The patch is surreptitiously snuck into the Monero codebase in [pull request #1744](https://github.com/monero-project/monero/pull/1744). It is kept secret to prevent it being used to attack other CryptoNote coins. +2017-02-22: A [point release of Monero is rushed out](https://github.com/monero-project/monero/releases/tag/v0.10.2) so that exchanges and mining pools can update, under the guise of it preventing a RingCT DoS attack (such attack did not exist, but it seemed a fair explanation). +2017-03-15: The hash of the details of the problem is committed to the Monero blockchain in tx dff7a79e44f9392e19fe5205c389d3e799f89c62d90d624219618d754b806e04 +2017-03-26: A further [point release of Monero](https://github.com/monero-project/monero/releases/tag/v0.10.3.1) is put out to prepare for a hard fork in April. +2017-04-14: The Monero network hard forks to increase the dynamic block size minimum median, but this has the added bonus of ensuring the entire network is protected. +2017-04-17: All CryptoNote coins are contacted, and told that they have until mid-May to patch their coins, before there will be a public disclosure of the issue. +2017-04-17: As noted by [Riccardo "fluffypony" Spagni on Twitter](https://twitter.com/fluffyponyza/status/854029169667309569), the hash of the message sent to the various CryptoNote currencies is committed to the Monero blockchain. + +### Problem + +The so-called "key image" as used in CryptoNote coins utilising elliptic curve ed25519 can be modified in a special way, allowing double-spends. This effectively allows someone to create an infinite amount of coins in a way that is impossible to detect without knowing about the exploit and explicitly writing code to check for it. + +### Mitigation + +Several options exist for mitigation. The simplest, least invasive is noted below. + +To mitigate, check key images for correctness by multiplying by the curve order l. Check that the result is the identity element. + +Hexadecimal values of each: + +Identity element = "0100000000000000000000000000000000000000000000000000000000000000" + +Curve order (little endian) = "edd3f55c1a631258d69cf7a2def9de1400000000000000000000000000000010" + +For each transaction key image, check ((key image * curve order) == (identity element)); reject transaction if false. diff --git a/_posts/2017-05-21-overview-and-logs-for-the-dev-meeting-held-on-2017-05-21.md b/_posts/2017-05-21-overview-and-logs-for-the-dev-meeting-held-on-2017-05-21.md new file mode 100644 index 00000000..f72f1311 --- /dev/null +++ b/_posts/2017-05-21-overview-and-logs-for-the-dev-meeting-held-on-2017-05-21.md @@ -0,0 +1,130 @@ +--- +layout: post +title: Overview and Logs for the Dev Meeting Held on 2017-05-21 +summary: Sub / disposable addresses, new website, CLI/GUI lightwallet integration +tags: [dev diaries, core, crypto] +author: dEBRUYNE / fluffypony +--- + +*May 21th, 2017* + +# Overview + +An overview [can be found on MoneroBase](https://monerobase.com/wiki/DevMeeting_2017-05-21). + +# Logs + +**\** we have to do the dev meeting really quietly so the pony can get some sleep +**\** 1. Greetings +**\** 2. Brief review of what's been completed since the previous meeting +**\** 3. Code + ticket discussion / Q & A +**\** 4. Any additional meeting items +**\** 5. Confirm next meeting date/time +**\** (no relay bot btw) +**\** So, since last time, I'm not sure what's been merged. Not much I think ? There was the key image flaw made public too. +**\** I'm working on abstracting network addresses. Mostly works, but serialization is being a massive pain. +**\** Anyone else want to say anything about what they're working on ? +**\** eventually I hope to have the amd64-51-30k speedups in wallet2.cpp (assuming fluffy approves) +**\** and improve the hex -> bin performance would be nice too (not nearly ready for a merge though) +**\** What is that short for ? +**\** oh sorry, the ASM for wallet scanning +**\** What are the 51 and 30k short for ? +**\** its already written so that it can be removed by cmake, and does not touch the consensus code _at all_ +**\** 51-bit limbs and 30k tables +**\** 30k table singular, sorry +**\** Anyone else doing something nice ? hyc, LMDB wallet code maybe ? :) +**\** Nobody else ? tewinget ? +**\** everyone is out spending bytecoins +**\** Alright. Ticket discussion. The only thing I know is people reporting sync stopping. Some of them are user error, some are corrupt db, but I think there may be something else. I'd need to see good logs for both sides though. +**\** Anyone wants to say anything about pending bugs ? +**\** Testing related... your 1982 works nicely, with no apparent issues after several days. That on a daemon with none to very light load, fwiw. +**\** Cool, thanks. +**\** About pending bugs: we're still waiting for finalization of the disposable address theory, IIRC RandomRun and knacc were discussing a change recently. +**\** knaccc: any comment about this ? +**\** I'm syncing on Windows right now, albeit with non-default settings. Will report if it gets wedged. +**\** change to which portion, disposable addresses or sub-addresses? +**\** or I guess you specifically said disposable address +**\** I don't remember. It's 1753. +**\** I did, but not on purpose :) +**\** I have a feeling it'll be a fast meeting. +**\** luigi1112: anything new about smaller range proofs ? +**\** he's out spending bytecoin too +**\** happened to me today (sync); it just hanged; killed the process and restarted monerod; continued seamlessly +**\** can re-sync with different loglvl to see if it happens again +**\** Next time, don't kill it before you've looked at the thread stack traces. +**\** Anything else someone wants to say in the meeting ? +**\** Kovri test site? :D Not super dev-y, but nobody else says anything. +**\** Kovri meeting is in 48 minutes. +**\** there is no kovri meeting today +**\** aw... then feel free. +**\** anonimal: around ? +**\** moneromooo sorry no. will update soooooon +**\** ty +**\** Hmm. +**\** next meeting will be exciting :-) +**\** Well, no test site either then. +**\** oh baby i know what that means +**\** i think +**\** Next meeting: in two weeks, same time. +**\** Done. The only good meetings are short meetings. +**\** am I doing this right +**\** ann of ann +**\** mooo, how to use stacktrace? +**\** Oh he's back now :) +**\** jollymort: gdb /path/to/monerod `pidof monerod` +**\** thread apply all bt +**\** so i can do it while it's running +**\** Yes. +**\** no need to start it in some special way? +**\** ok +**\** i'll set loglvl to max also +**\** and start sync from 0 +**\** I wouldn't. +**\** ok, so just restart and wait for it to hang? +**\** 3 and 4 are toop spammy for being much use in general usage. +**\** Yes. +**\** rehrar: free free if you have something to say/show. +**\** Anyways, Monero test site here: http://45.32.161.183/ mobile responsive now and a brand new mobile navigation. +**\** Kovri test site: http://45.32.171.42/ completely integrated into the Jekyll. The custom CSS framework was ported without issue. This bodes well for my further work on getmonero.org. +**\** Looks clean. +**\** hi. a bit late to meeting. i'm working on lightwallet integration in cli and gui +**\** or wallet2 mostly +**\** You mean mymonero ? +**\** We scrubbed it down. +**\** yeah. and openmonero +**\** should work with both backends +**\** and should be switchable from full wallet to light wallet. vtnerd. would you consider implementing input/output import in mymonero api? +**\** https://github.com/moneroexamples/openmonero/issues/21 +**\** would make it possible to switch from full wallet to light wallet without a rescan +**\** not clear how the mobile experience would go +**\** just an initial impression +**\** ? +**\** experience of what? +**\** as in how user gets wallet file on their mobile and how they pick it +**\** I don't know what you mean Jacquee +**\** you want to import an existing wallet quickly from a local DB to a mymonero backend ? +**\** and also the other direction ? +**\** that would be cool. maybe :-) +**\** yeah. if i have a full wallet on my desktop and want to use the same wallet on my mobile. I could convert my full wallet to lightwallet by sending my inputs/outputs to mymonero/openmonero backend. And then login as usual on my phone +**\** with seed +**\** without paying the 1 xmr rescan fee +**\** that was my idea +**\** so the magic happens in desktop wallet. +**\** on mobile you only login as usual +**\** yeah, but its doable but I would have to think about it a bit +**\** the backend would still want to verify correctness, so its not stomping on someone elses coins, etc +**\** but it would be doing much less work +**\** ok. yeah backend could verify with view key +**\** that's probably best +**\** yes. but it would only be looking at the set of outputs specified in the RPC call which will be much faster +**\** exactly +**\** Jaquee: ic +**\** yeah so the import out will be much easier, and you can almost do it with unspent_outs call +**\** *export I think is what normal people say +**\** yeah. i'm almost done with that +**\** i'm trying to make wallet2 fully compatible so i can switch between light wallet and using a normal node +**\** well I meant but the export from the backend side, but ok interesting that you've already started the wallet side +**\** yup, understood +**\** how monero is configured to only cpu/gpu mining? +**\** so, to summarize. if i create the mymonero wallet first i can already switch between full and light wallet mode. This import call i'm suggesting also makes it possible to switch from an old full wallet never initialized on mymonero. +**\** ok \ No newline at end of file diff --git a/_posts/2017-06-04-logs-for-the-Kovri-dev-meeting-held-on-2017-06-04.md b/_posts/2017-06-04-logs-for-the-Kovri-dev-meeting-held-on-2017-06-04.md new file mode 100644 index 00000000..ec50da5f --- /dev/null +++ b/_posts/2017-06-04-logs-for-the-Kovri-dev-meeting-held-on-2017-06-04.md @@ -0,0 +1,169 @@ +--- +layout: post +title: Logs for the Kovri Dev Meeting Held on 2017-06-04 +summary: Brief review of what has been completed since last meeting, 96boards OpenHours showcase, website discussion, and code & open tickets discussion +tags: [dev diaries, i2p, crypto] +author: dEBRUYNE / fluffypony +--- + +*June 4th, 2017* + +# Logs + +**\** 1. Greetings +**\** 2. Brief review of what's been completed since the previous meeting +**\** 3. Status of [96boards.org OpenHours showcase for Kovri / Monero](https://github.com/monero-project/meta/issues/46) +**\** 4. Code + ticket discussion / Q & A +**\** 5. Any additional meeting items +**\** 6. Confirm next meeting date/time +**\** Hi +**\** Hi +**\** Many crickets today, fluffypony moved monero meeting to next week. Maybe everyone thought kovri meeting was moved too. +**\** Hi moroccanmalinois +**\** 2. Brief review of what's been completed since the previous meeting +**\** RouterInfo, NetDb, I2NP (WIP in fork), cryptopp, HTTP, Reseed and docs work. +**\** This month had kept me AFK more than I'd like because of various life issues. This month *should* be better. +**\** Adding to 2.: rehrar website work, pigeons build work too +**\** I started a private testnet but it didn't work and then i was busy. i will get back to it this week +**\** Hi +**\** moroccanmalinois: cool, ok :) +**\** Anything else on point 2.? +**\** Besides the added stuff? +**\** I didn't get any more hackerone or VRP work done as I chose to focus on code instead. I think h1 stuff will be done soon though. +**\** rehrar: anything, just a general re-cap. +**\** Ok, moving on +**\** 3. Status of [96boards.org OpenHours showcase for Kovri / Monero](https://github.com/monero-project/meta/issues/46) +**\** Typing +**\** Redesigned the getmonero.org custom framework, have semi-started a translation campaign, made a document on how to add and edit pages and translate them, and have done intermittent testing since then, and added a few more languages upon request. +**\** Cool cool. How's the monero site coming along so we know when you can do a kovri FFS? +**\** Leaving Russia tomorrow. Will be a 40 hour process getting home and the past week was spending time with wife's family since don't know when I'll be back. But pages are being made, and I hope to have it done in less than three weeks. +**\** Ok, sounds great. Safe travels. +**\** For the Kovri FFS I would like a full list of things desired from me so I can put it in all at once. It'd be best so as not to have "oh wait this too" after funded and started. +**\** Although being flexible is important obviously. :) But minimizing that is nice. +**\** Indeed. I'll be happy to work with you on getting that part done. +**\* anonimal** will be around when you're ready +**\** Aight. Thanks. +**\** No problem. Anything else on point 2.? +**\** Nah +**\** Oh, typo to what I said earlier this meeting. I meant "Last month had kept me AFK more than I'd like...", not "this" month. Oops X) +**\** Will dEBRUYNE do editing for things like this or is that still bad IRC etiquette? +**\* anonimal** fine either way +**\** So point 3., +**\** fluffypony would need to be around. I think hyc too (if he's still onboard). +**\** The podcast is June 8th, 6pm-7pm SAST +**\** So... 4 days +**\** I'll try to touch base with everyone tomorrow. Would like to be as prepared as possible. +**\** live streamed ? +**\** Ah, good question. I don't think so. +**\* anonimal** wouldn't quote me on that though +**\** lol k +**\** I've only seen the podcasts on youtube and they weren't live. +**\** Maybe #OpenHours can answer that +**\* anonimal** checks site +**\* anonimal** asked in #OpenHours +**\** thanks +**\** Any questions/comments on point 3.? We kind of need fluffypony around since he's the official interviewee +**\** Alright, moving on, +**\** Next. :P +**\** 4. Code + ticket discussion / Q & A +**\** I don't have any questions really. Doing some much-needed I2NP refactor work and flushing out some ideas for the messaging system (or lack thereof). WIP in my fork, stash not committed yet. +**\** Anyone else? +**\** (btw, open issue re: I2NP) +**\** Mind you, it's all connected: RouterInfo, NetDb, I2NP -> NTCP transport layer. So this is all toward the alpha release. +**\** If I can skip work that doesn't lead to a release, I will do it. +**\** Until then, the rabbit hole needs fixing. +**\** Just one question : i know there are known issues with NTCP, but i didn't see any major issue with SSU. A network with only kovri nodes enabling SSU but disabling NTCP should theroetically works ? +**\** moroccanmalinois: yes, and we could technically release now. I thought it would be wise to remove as many of the log error messages (some of which really aren't errors per-se) so we don't get an influx of reports for known issues. +**\** What do you think? +**\** FYI the NTCP review lead to the RouterInfo rewrite -> NetDb work -> now I2NP work (because I'm here and it was driving me crazy). +**\** I agree. +**\** And there are/were lots of things to fix along the way anyway. +**\** Ok. I'm very open to suggestions as we proceed. +**\** moroccanmalinois: did you have any particular stumbling blocks when doing your testnet work? +**\** i need a little more time to answer this. It was easy to see that it didn't work with NTCP since 15 min after the start, routers don't have anything in their netdb +**\** Ah ok +**\** with ssu, everything looks good but the tunnel didn't work +**\** I can hop on slack more often and send a PM if you want to work out any details (if I can help in any way). +**\** Thanks but i am jumping to irc, and i won't hesitate to contact you :) +**\** Anything else on point 4.? +**\** rehrar did you say you like doing backend webdev too? +**\** moroccanmalinois: awesome, ok +**\** Not my strongest point, but I am able, yes. And all of my speaking around the Reddit and other places is getting me in touch with a large number of devs, web included. +**\** So what I can't do, I am positive I can get someone on. +**\** Cooool. I like the sound of that. +**\** I'm curious to know how far we could go with check.kovri.i2p +**\** could/should +**\** Anyway, that's distant stuff that we can talk more about later. I can't imagine a lot of code involved either. +**\** Sure thing. We'll talk bout it soon. +**\** Good Evening +**\** Once anonimal/kovri-site is moved to monero-project/kovri-site, I think I'll move the meta issue there. +**\** Hello danielesesta. +**\** Great to have you join @danielesesta read the backlog. :) +**\** Ok so moving onto 5. Any additional meeting items +**\** Ye I got one. +**\** I have been thinking of starting a Kovri campaign of sorts. Marketing for devs. Just letting other open source devs know what's out there and let them know we exist and would welcome any help for improving privacy. +**\** There's a number of different Reddits and websites for talking about your FOSS project. +**\** I'd love to put a few things together (including that over-text interview with you we had discussed) +**\** Alright, great idea. +**\** When do you want to do this? I can schedule myself accordingly. +**\** we @ daashaus we are launching now some products but i believe in mid-august - september we can start on working on a proof of concept web based product on the kovri i2p +**\** Im thinking next week. Need some time to resettle at home upon returning. +**\** with @rehrar we talked about making a medium of some sort for anonimous blogging +**\** rehrar: ok, whenever you're ready, I'll be around. +**\** Interesting. danielesesta is there a chat log or overview so I can catch up? +**\** we were talking privatly +**\** rehrar: FYI there is a meta issue about this (developer search). Could we also coordinate there too? +**\** Yes we can. +**\** we can launch something on beta pretty quickly if i add at least 3 devs for a month +**\** would be good maybe to run a design sprint of the product and get some ideas going with the team so we can put the project in the pipeline +**\** idk if you rehar and anonimal would like to join it maybe the first week of august? +**\** danielesesta ok, so what exactly did you have in mind for the product? +**\** I'd love to sure. +**\** i believe that at the moment being aninimous in the web is for an elite only, but there is a lot of people that has a very little know-how but still has a lot to contribute +**\** about telling stories and spread their words +**\** So the product would be unknown at this point? Thus the meeting in August to generate ideas? +**\** our idea was to create a medium with a simple user-friendly UI/UX blogging platform for anyone to use without a big knowledge on how to be aninimous in the web +**\** that can protect them but still deliver +**\** Ah, ok, great idea. Sorry, you did say that earlier but now I see what you mean. +**\** if you wanna help, please contact me, I am a web dev.. I'm building integrations for monero +**\** Serhack, I was going to out you in touch with Daniel. +**\** I will be making a slack channel soon for web devs. +**\** So we can discuss Monero/Kovri needs. +**\** i think that could be a great use of a i2p browser +**\** Nice, I like that idea. +**\** also a great proof of concept +**\** okay thanks rehrar +**\** and maybe for the first time we might apply some good design and cool features in the world of the blockchain +**\** :) +**\** Ok. Anonimal I've got one thing to ask you. +**\** @serhack sure PM me so we keep in touch here +**\** Oh, thank you you two for your contributions, Danielesesta and serhack +**\** Ok, so in terms of housekeeping: danielesesta or anyone, would you be willing to open a new issue at https://github.com/monero-project/meta/issues explaining your idea/proposal so we can all have a point of contact and collaboration? Or is there a better alternative? +**\* anonimal** would usually refer to the kovri repo but that's better for code issues +**\** forum :) +**\** Hmm, well, the forum doesn't email me notifications (I've tried everything) +**\** i believe we can move on our own without bothering anyone we are all people that can manage ourself efficiently i believe +**\** if we encounter any issue we can email each other directly +**\** It's more of a friendly reminder, not necessarily "let's all talk here and do all our work in the meta issue" +**\** Given that the tasks for Kovri are more varied than just web work, as discussed above, what do you think of me opening a FFS of not necessarily web work and have it be objective based, but an hourly based sort of FFS that I can do a bunch of various tasks (Reddit, Web, Outreach campaign, etc). Whatever Kovri needs basically. +**\** danielesesta: otherwise, if someone wants my input, they'll have to keep me apprised because I'm pretty busy. Just an FYI. +**\** rehrar: I would advise two separate FFS' then: one for strictly website and one for the other. +**\** But then again I'd also ask for fluffy's or luigi's or any monero-dev's input too. +**\** A general staffer sounds good but I have no idea what everyone else thinks. +**\** Ok, we're out of meeting time. Any last thoughts on additional meeting items? +**\** Ok. If they're on board with the "general staffer" as you put it, then I'd love to give it a go. There's lots of house keeping to do. :) +**\** Nope +**\** Ok. 6. Confirm next meeting date/time +**\** So, monero's is next week. +**\** But we usually two ours every two weeks. +**\** Maybe we'll have a mini-meeting next week after monero's? +**\** \*do ours +**\** Any objections to a meeting next week? +**\** no objection +**\** Ok, I'll set one for next week. +**\** Ye. Let's do it. +**\** One last thing for additional meeting items: I wanted to say hi, recognize, and thank all kovri contributors for their contributions and camaraderie. +**\* anonimal** typing +**\** A former contributor made a erroneous comment implying there were no contributors to the project. A blatant lie that I felt was disrespectful to everyone involved. +**\** Anyway, so thanks everyone. +**\** End of meeting! \ No newline at end of file diff --git a/_posts/2017-06-11-logs-for-the-Kovri-dev-meeting-held-on-2017-06-11.md b/_posts/2017-06-11-logs-for-the-Kovri-dev-meeting-held-on-2017-06-11.md new file mode 100644 index 00000000..c7b1e50d --- /dev/null +++ b/_posts/2017-06-11-logs-for-the-Kovri-dev-meeting-held-on-2017-06-11.md @@ -0,0 +1,308 @@ +--- +layout: post +title: Logs for the Kovri Dev Meeting Held on 2017-06-11 +summary: Brief review of what has been completed since last meeting, FFS for MoroccanMalinois, FFS for Rehrar , 96boards OpenHours showcase, website discussion, and code & open tickets discussion +tags: [dev diaries, i2p, crypto] +author: dEBRUYNE / fluffypony +--- + +*June 11th, 2017* + +# Logs + +**\** 1. Greetings +**\** 2. Brief review of what's been completed since the previous meeting +**\** 3. Status of [96boards.org OpenHours showcase for Kovri / Monero](https://github.com/monero-project/meta/issues/46) +**\** 4. Moving `anonimal/kovri-site` and `anonimal/kovri-docs` to `monero-project` #74 +**\** 5. Resolve FFS RFC for @moroccanmalinois +**\** 6. Code + ticket discussion / Q & A +**\** 7. Any additional meeting items +**\** 8. Confirm next meeting date/time +**\** Hi +**\** hi +**\** Hi!! +**\** hi +**\** 2. Brief review of what's been completed since the previous meeting +**\** Sorry. Slack being stupid. +**\** Hi +**\** The one last week? Is this a mini-meeting? +**\** Yes, but it should go as long as it needs +**\** I was busy dealing with more guzzi drama and dis-information, so I haven't been able to prepare for 2 +**\** This week was very busy though: +**\ {-fluffypony}** sorry I missed 1. - I'm in and out, getting changed and need to get food desperately +**\** much preparing for 96boards (which ended up being canceled), kovri-site dev / collaboration, kovri-docs created, PR review/merges +**\** rehrar doing great work, MoroccanMalinois doing great work +**\ {-fluffypony}** anonimal doing great work +**\** Everyone around doing great work. elopio pigeons and every other contributor this past week. +**\* anonimal** blushes, thank you +**\** #653 was interesting, still not sure what his issue was before he closed it. +**\** In all a very collaborative and active IRC week. Did I miss anything? +**\** Oh, yes, guzzi quit and left his FFS unfinished. MoroccanMalinois is stepping up to finish his FFS work (we'll talk more in point 5). +**\** Moving on to 3.? +**\** 3. Status of [96boards.org OpenHours showcase for Kovri / Monero](https://github.com/monero-project/meta/issues/46) +**\** I think we're rescheduled (or will be) for July 20th or 27th +**\** I'll keep everyone apprised. +**\** Details are in the meta issue. +**\** I think everyone was informed about fluff's flight delay. Did anyone not get that info / reschedule notice? +**\* anonimal** posted in the reddit thread too +**\ {-fluffypony}** yeah stupid fire +**\ {-fluffypony}** Robert indicated that next month would suit +**\** Ok +**\** Anything else on 3.? +**\** 4. Moving `anonimal/kovri-site` and `anonimal/kovri-docs` to `monero-project` #74 +**\ {-fluffypony}** I can create empty repos for that now before I leave +**\** fluffypony: what do you think about this? ^ https://github.com/monero-project/meta/issues/74 +**\ {-fluffypony}** I think that's good +**\** Sorry. Here. Checking backlog. I'm out and a guy I know decided to give me a 15 minute talk on WW2 +**\** fluffypony: alright, cool +**\** Anything else on 4.? +**\** um +**\** at the risk of asking a stupid q +**\** is there anything that needs to be done on making Kovri Ipv6 ready +**\** one example is port fowarding +**\** on ipv6 consumer routers you can’t do that +**\** as all devices have public IP +**\** johnalan: ipv6 is supported, let's talk more at point 7. +**\** ok +**\** no probs +**\** sorry +**\** 5. Resolve FFS RFC for @moroccanmalinois https://forum.getmonero.org/9/work-in-progress/87082/proposal-for-kovri-dev?page=&noscroll=1#post-91048 +**\** Just a few words before this point: I am bad at social things. I don't do politics/drama. Not a funny guy, don't feels comfortable with english, but i am happy to answer technical questions when i can. I already feel honored by the support i have received so far and whatever happens with the FFS, i am OK with it and it won't change anything to the work i am going to do or not do in the next months.So just wanted to say a big +**\** THANKS ! +**\** Woo! +**\** I've seen no negative responses to the RFC. Did anyone say anything in the reddit thread? +**\* anonimal** checks +**\ {-fluffypony}** MoroccanMalinois: your English has been excellent, you mustn't worry about that :) +**\** :) +**\** MoroccanMalinois == good guy to have +**\** (or gal) +**\** https://www.reddit.com/r/Monero/comments/6g1q8b/request_for_replacement_assistant_kovri_developer/ +**\** Nothing but positive reviews it seems. +**\** Thank u very much mooo +**\** So, everyone is in agreement? +**\* anonimal** yes +**\** yes +**\** yes +**\** delighted to have him +**\** her +**\** whatev +**\* MoroccanMalinois** blushing +**\** yes +**\** Sold! Congrats to MoroccanMalinois. You've always been aboard so saying "welcome aboard" is redundant. +**\** Welcome aboard +**\** lol +**\** On this note, I'd like to point out one thing: +**\** We spent more time vetting MoroccanMalinois as a replacement for guzzi then we did vetting guzzi to receive an FFS in the first place. +**\** palexander had some great questions. In general, how can we better vet FFS proposals? +**\** Is this possible? If so, how? +**\** I think the key is to have people contribute enough to get a feel of how it works. I don't know how much guzzi contributed at start though. +**\** one thing i'd like to mention is that if someone is getting paid, they should know something, and be able to ship at least what they say they know w/o reliance on others +**\** if that's not able to be kept then i'd say that's grounds for renegotiation or something +**\** aside from that, i think it's important to be careful with whether teaching someone becomes a codependency sort of situation +**\** not that i'm saying you wanted that at all anonimal, obviously +**\** I think moneromooo and endogenic hit that nail on the head HARD! +**\** moneromooo: to be brutally honest, guzzi contributed very little; even less AFTER he started his FFS. +**\** The value of the work was on par to the amount. +**\** He should've spent his time taking an online course or going to a community college instead of, endogenic so elegantly put it, used me as a co-dependent. +**\** Though the dependency was not mutual. +**\* anonimal** typing +**\** :) Dear community, Thanks very much +**\** For guzzi to take 4 months to complete 40 hours of work, get many free hours of tutelage from me, complain about not understanding how to program c++, attack me and discredit other contributors, quit, then continue to attack the project: I don't think anyone could've predicted this would happen. +**\* anonimal** grabs meta link for FFS sticky +**\** lol anonimal as to the last sentence you may find it can be noticed much earlier +**\ {-fluffypony}** anonimal: I've created the repos and given you access +**\ {-fluffypony}** or invited you anyway +**\ {-fluffypony}** on that note I have to take my leave, chat later +**\** Thanks fluffypony. Godspeed. +**\** endogenic: lol alright, you have a point ;) +**\** https://github.com/monero-project/meta/issues/63 +**\** So, ^ create formalized FFS process +**\ {-fluffypony}** o/ +**\** \o fp! +**\** It's already in meta. endogenic moneromooo not to prod your brain too much, but does a sentence or two come to mind that could be added/revised? +**\** gingeropolous: ^ thanks +**\** may be good to put rigorous criteria to "disappears" +**\** taking vacation at improper times, etc, imo, is akin to abandonment +**\** Ok. I'm sorry for the second disappearance. O vote aye for @moroccanmalinois +**\** obviously that's super strict and not applicable directly to a FOSS context +**\** "improper" ? +**\** but my point is that if someone just pops in every now and then to say "hey i'm still alive" but is dragging their heels then that may be a sticking point where you would have wanted to define what disappears means +**\** moneromooo: "improper" as in let's say they committed to doing something but then decided to put a vacation there +**\** Maybe there could be a rough show of hands as to whether something needs fixing, then. +**\** Good point I think. +**\** fp and I had repeatedly - repeatedly - over the course of months had asked him to show up to meetings; yet he still wouldn't do it reliably. MoroccanMalinois was better at attending meetings and no one asked him to! +**\** moneromooo: yeah i believe it has to be judged case-by-case, anyway +**\** anonimal: yep +**\** So, maybe we should add something to the regular meeting agenda? "X. contributor / FFS check-in, status"? +**\** anonimal: there are so many good people who would want to work on kovri +**\** anonimal: good idea +**\** that actually sounds like a great idea +**\** Yep +**\** And then add something to the FFS document which *enforces* something +**\** That's the tricky part I think. +**\** the contract can't enforce things per se imo +**\** but can give paper trail to agreement +**\** so imo the question is what matter needs addressing +**\** Ok, so make this more of a per-issue/per-person/per-meeting check-in resolution? +**\** its not to make it difficult or hard on the FFS contributor, just a status update. If that’s not much in a given week or two no problem +**\** Instead of a global catch-all? +**\** well it could probably be couched in general terms +**\** I think status updates are healthy accountability. They are hired by the community after all. +**\** ^^^ +**\** As long as they are done unilaterally without preference (so anonimal too and other higher ups) then it's a good thing. +**\** but it's basically to have them indicate they understand that they are working for the community, not the other way around +**\** johnalan rehrar: I believe I've been doing that for every meeting since 2015. In the eyes of a problem contributor, any response is a good response because "it's a response and that's all I need to give" +**\** ok +**\** I'm not pointing fingers at you, bud. Just saying as long as everyone is held to a similar standard, I think it's healthy and ensures something like this doesn't happen again. +**\** good point +**\* anonimal** is questioning the validity / quality of the response as it pertains to the FFS +**\** fair +**\** rehrar: I didn't think that nor am I implying that. I'm not attacking you or johnalan. This is purely information relay. +**\** Part of a formalized FFS should include updates on a regular basis, and if this minimum thing isn't kept up, it's fair to question whether or not the person has the committment to fulfill the project +**\** if they can't even be bothered to give updates, how can they be bothered to complete the assigned tasks? +**\** Indeed +**\** Even if they can't make it to a meeting, they can write something up before hand and have a proxy give it on their behalf. +**\** It's honestly a bare minimum as far as standards go, and I'm all for it. :) +**\** So how can we write this into an FFS standard? +**\** measurable goals +**\** I think that's a big of a longer conversation that should involve more people if we're talking about the FFS at large, and is outside the scope of this meeting. +**\** \*bit of a longer +**\** tbh, I'd keep it fairly generic, and keep in mind some FFSes aren't coding. +**\** if we're just talking about FFS's for Kovri, then sure, let's talk +**\** I wouldn't mind writing up a draft and presenting it to everyone. :) +**\** rehrar: https://github.com/monero-project/meta/blob/master/FFS +**\** sorry gents gotta dash (no pun intended) +**\** I'll fork and do some amends for review. +**\** I would prefer this to be applied to FFS across the Monero project, not just Kovri +**\** ^ +**\* anonimal** was just typing that +**\** This is actually pretty important for me, as I'm designing the new FFS interface for the new website. Have a meeting with Fluffy on Monday about some technical aspects, but getting this hammered down too would be very helpful. +**\** I've been hoping for this discussion for a long time now; before I even opened up my first FFS. I'm glad to see we finally have the time/space to get to this. +**\** It's possible to launch the new website without the redesigned FFS for the short term, and roll out the new one once this discussion has been hammered out. +**\** I used hammered something twice. Slap me. +**\** Lots of good input. I'll need to give this more thought too. +**\** Anything else on this point? +**\* anonimal** will add to the next meeting agenda +**\** Nah, but it may be a good thing to add the the next #monero-dev agenda also +**\** ^ fluffypony +**\** 6. Code + ticket discussion / Q & A +**\** 6 minutes left. Any questions/comments? +**\** MoroccanMalinois: I'd like to add your testnet bash script to /contrib. What do you think? +**\** I'll wait for it to work :) +**\** lol, ok +**\** Pretty sure it doesn't work related to the config +**\** External IP Detection seems completely broken +**\** Which config? +**\** But it works perfectly on mainnet +**\** I'll talk more with you about that after the meeting. +**\** Sure +**\** Anything else on 6.? +**\** 7. Any additional meeting items +**\** I have something. So I've discussed with anonimal what it would be like for me to put in a FFS as a 'general staffer' of Kovri. There's a lot of work that needs to be done that isn't coding related. Website maintenance, reddit moderation and theme design, trying to get other developers interested, etc. I'd like some feedback from others on what the thoughts of something like this are instead of FFS for each project. Basically, bei +**\** from moneromooo and others as well since there's a possibility of me doing something like this for Monero as well (I had a discussion with dEBRUYNE who supported the idea) +**\** This got cut: "Basically, bei [...] from moneromooo". +**\** sec +**\** Basically, being paid on a per hour basis 10ish/wk +**\** 10ish hours I mean +**\** Maybe doing the FFS for Monero as a whole including Kovri +**\** that's what I was thinking yes. 10 hours/wk for Monero and 10 for Kovri or something like that in one FFS +**\** I would outline the goals for each project +**\** Would this be something that would be useful? Creating content for Monero (like the reddit posts and helping people get plugged in) is something that's super fun for me and I love to do +**\** and I would love to be able to devote dedicated time for it +**\** the reddit posts could be something of a black hole +**\** and Kovri, well, it's my favorite and the reason I'm here +**\** if it were to be funded, it might be good to formalize the plan for making posts +**\** Reddit, I dunno, but website content curating would be useful, for example. +**\** rather than it being, purely for example, contacting specific people who might not know about kovri +**\** understood, content can be different +**\** and yeah, web maintenance for both projects is definitely one thing I had in mind +**\* anonimal** notes we don't have a formalized way of reporting completed work. Even I'm ad-hoc'ing it. Sidenote: I think we should give this more thought with FFS re-write work +**\** I looked at you work for https://getkovri.org/ it is rock solid +**\** rehrar knows I'm on-board with the idea. +**\** thanks so much ArticMine :) +**\** This kind of material is needed across the whole project +**\** General question: would having a single person in charge of this much be questionable in terms of de-centralization? +**\** Posting in my opinion is secondary +**\** well they could fall into the same accountability/status update stuff +**\** anonimal: +**\** ArticMine: on slow weeks with not many updates to be made, the time can be filled with more user guides and stuff, which are desperately needed. :) +**\** Anyways, a discussion for another time. There's tons of ideas. +**\** Ok, we're in over time. So I see no objections to rehrar's proposal? +**\** yeah i would be happy to see rehrar working on that stuff +**\** Is this in the FFS ideas section? +**\** I haven't made it yet, no. +**\** I'd have questions on what people think a fair price would be, but that can be for after the meeting. :) +**\** In the future I think it's better to post there first and link here because of the amount of people not on IRC. +**\** Ok. Sorry. +**\** No problem, I just hope the word gets out better that's all. We are but a small a group. +**\** I have one thing to add to this last agenda item: +**\** preannouncement?? +**\* anonimal** slams fist on table, plan foiled by endogenic +**\** lolol +**\* anonimal** typing +**\** anonimal: General question: would having a single person in charge of this much be questionable in terms of de-centralization? \<--- Not a major concern if the contend is licensed under a sharealike license CC /GNU etc +**\** Since it can always be forked +**\** One last thing: it seems like some people have been misinterpreting my language. Some people seem to think I'm attacking them when I am not. I don't know why. Maybe I'm being direct / honest / too the point / curt? +**\** I do point out ideas, and question ideas, but I don't consider that attacking. +**\** I do that to my own ideas. Even if I attack an idea, I wouldn't take it personal. +**\** I'm bringing this up because I've seen this since the beginning; but the issues were 99.9% with problem contributors who have no gone to the wayside. +**\** \*now gone to +**\ {-pigeons}** sometimes in pursuit of efficiency engineers can ignore little customs and manners that make people comfortable in communication +**\** imo honesty has the function of keeping things simple, clear, and bright - but ppl tend to follow what they feel instead of their rational understanding, which is why too-blunt yet frank criticism of a person who has some self-esteem or self-worth issues usually ends up not working out - so imo it's a question of how people are led and managed +**\ {-pigeons}** people online are from all different backgrounds, its hard to know their communication style, so a little extra care probably helps +**\** on one hand, you probably (definitely) could have been more strict with guzzi early on but didn't want to based on some shred of idealism about him +**\** what i've had to learn is that people only take what they're ready to take from a teaching +**\** i.e. ppl hear what they want +**\** so pragmatism kind of means living with that reality and operating as if not being able to rely on others - i think it causes others to have to step up and behave like adults +**\** I find two things contribute here. Text is horrible for conveying meaning, and coders are not always (there are exceptions, don't kill me) super socially adept :D +**\** but mostly the first +**\** seriously, being in person has its advantages +**\** let's all move to the Monero Corporate Headquarters +**\** endogenic: you whacked me across the face with an epiphany stick with "could have been more strict with guzzi early on but didn't want to based on some shred of idealism about him" +**\** in Beverly Hills +**\** anonimal: i keep getting whacked by the same stick and hope that i get it into my thick skull one of these days :P +**\** pigeons I think you have great points, but how does one bring extra care if care means something different to everyone? +**\** I think there is a balance here +**\** rehrar: I completely agree about text as it relates to IRC +**\** I don't think guzzi was malicious, and everyone has a different viewpoint. There are two sides to every story. We just have to be a little more careful on making sure our meanings are understood because of the text-based environment. +**\** But aside from that, what's done is done, and we can move forward with a great new contributor under FFS +**\** it'd be wise for all of us to move on from this and focus on what needs to be done to push Kovri forward +**\** learning lessons along the way about communication, of course. +**\** Indeed. +**\** I have to point out that I know how dry and straightforward I can be most of the time. I've done this to avoid any emotional misinterpretation. Maybe some people interpret this as "mean"? +**\** I think at its core, it's a bit of a fault of the FFS at large. A similar thing happened with FireIce as I recall +**\** anonimal: if only we could see your smiling face… :) +**\** defacto expectations by community and contributors that are not fulfilled in some way +**\** Nows the time for anonimal bashing! Get those sticks, bats, golf clubs, or weapons of choice! +**\** is it a smile or a grimace? :P +**\** lol +**\** that's why I'm saying. One night at the club for all of us and we'll all be on the same page. :D +**\** flash a few moneros and pick up a few honeys, BAM! comraderie +**\** anyways, end of meeting? +**\* endogenic** opens a barolo in your and the devs honor +**\** rehrar: hopefully we can improve the FFS process +**\** endogenic: yes, a smiling face would help +**\** lol anonimal just meant your face +**\** i.e. on a podcast or something - ribbing you for being anon +**\** and also wondering what effect that would have… +**\** I think we should talk more about that at another meeting. +**\** yeah i had no conscious intention to bring it up again +**\** sry +**\** Right now I'm curious for any last words about my character as it relates to communication. +**\** Not to be narcissistic, but I have to keep myself in check too. +**\** I am not qualified to comment. I was not here for the majoirty of exchanges between you and guzzi +**\** And if I'm pissing all you off, I'd like to hear about it. +**\** in regards to myself, I have no issues with you. Say it like it is, and I'll do the same and we gucci +**\** rehrar: ok. I must say that bad apples come and go, and I can't take blame for that reality. +**\** Ok, thanks everyone for the overtime +**\** time to watch fresh prince +**\** Great meeting :) Thank you all +**\** lol rehrar, I can totally imagine you watching that show X) +**\** Thanks for the great input everyone +**\** Next meeting time? +**\** Ooops! Sorry, thanks ArticMine +**\** 8. Confirm next meeting date/time +**\** Same time, two weeks from today? +**\** okay +**\** Same as monero's? +**\** After the Monero meeting \ No newline at end of file diff --git a/_posts/2017-06-11-overview-and-logs-for-the-dev-meeting-held-on-2017-06-11.md b/_posts/2017-06-11-overview-and-logs-for-the-dev-meeting-held-on-2017-06-11.md new file mode 100644 index 00000000..13578502 --- /dev/null +++ b/_posts/2017-06-11-overview-and-logs-for-the-dev-meeting-held-on-2017-06-11.md @@ -0,0 +1,208 @@ +--- +layout: post +title: Overview and Logs for the Dev Meeting Held on 2017-06-11 +summary: GUI & download page, multisig, labelbot, 0MQ, and code & open tickets discussion +tags: [dev diaries, core, crypto] +author: dEBRUYNE / fluffypony +--- + +*June 11th, 2017* + +# Overview + +An overview [can be found on MoneroBase](https://monerobase.com/wiki/DevMeeting_2017-06-11). + +# Logs + +**\** ok +**\** 2. Brief review of what's been completed since the previous meeting +**\** Abstracted peer addresses, which will make it easier to plug I2P in later. +**\** from my side I put the GUI on the download page, and reviewed and merged PRs +**\* fluffypony** browses merged PRs +**\** Mostly bugfixes I think, I was looking at it. +**\** yeah +**\** ok let's move on +**\** arm7 bug found +**\** 3. Code + ticket discussion / Q & A +**\** The new getkovri.org is live. Multi-language ready +**\** Oops sorry. Too late. +**\** lol np rehrar, bring it up in 4? +**\** It was just fine since last meeting. +**\** ok +**\** hello +**\** is meeting now? +**\** I'll do some merging today / tomorrow - are there any urgent PRs I must merge first? +**\** serhack: yes +**\** 2078 maybe. Not really super urgent though. +**\** Oh, 2073 would be nice. +**\** 2064 would be nice too. +**\** kk +**\** 1936? +**\** ok +**\** on the tickets side - pigeons how goes the ticketbot? +**\** is that due to be merged? +**\** @johnalan yes, as long as there are no conflicts by the time I get to it +**\** okey +**\** Is that the one with a "DO NOT MERGE" text on it ? +**\** lol +**\** hehehe +**\** yes yes +**\** well if it says DO NOT MERGE then I'm not going to merge it +**\** :-P +**\** for the ticketbot i am testing, need to make sure it only acts on authorized users' requests mainly is left +**\** oh and i have only tested labeling, not removing labels or closing issues +**\** ok cool, but similar API calls for those +**\** we can test it out on meta first +**\** yes +**\** ok sweet +**\** is there anyone who doesn't know what ticketbot is? +**\** I suppose I don't, though I could venture a guess. +**\** the future +**\** ostensibly +**\** I dont +**\** ok great +**\** "ok great" --- fluffy was dying to tell about it, he just needed a reason. +**\** Ticket Bot for IRC +**\** so then I have an announcement, which will rock the very foundations of this dev group +**\** introducing: TicketBot +**\** is it huge? +**\** for too long we have languished, waiting for that fluffypony guy to close issues on GitHub +**\** or label them +**\** or remove labels +**\** ^^^ +**\** but now, through the power of a bot operating deep within the Monero infrastructure, we will languish NO MORE! +**\** for from \ the power of this bot will be unleashed +**\** and a group of contributors will be ordained as having Issue Privileges and/or Label Privileges +**\** and they will be able to @mention the bot on GitHub issue comments +**\** i'm not 100% sure what it is +**\** and the bot will add or remove labels, or close issues, depending on that contributors privileges +**\** WOW +**\** thats amazing +**\** tl;dr we're providing a way around GitHub's lack of fine-grained collaborator privs +**\** was just about to say...I can't believe you can't do that within github +**\** medusa was the one that pushed for it and suggested workarounds till we figured out the bot idea +**\** so thank him +**\** The bot runs here? +**\** ArticMine: no on GitHub, not on IRC +**\** Thanks medusa :D +**\** well, for/with github, not on +**\** so you have to be authenticated to GitHub to comment on the issue anyway +**\** wow this is really the future +**\** such a thing didnt already exist? +**\** And thanks pigeons +**\** no +**\** we had to create it +**\** from scratch +**\* endogenic** opens a barolo in medusa and the devs honor +**\** ;) +**\** impressive +**\** MOST IMPRESSIVE +**\** BUT YOU ARE NOT A JEDI YET +**\* fluffypony** is inclined to say that when someone says "impressive" +**\** doesn't work with your accent +**\** Will we be selfish with him? +**\** it will depend from project to project, we'll keep the ACL small for the moment so that people don't argue about whether or not an issue should be closed +**\** I mean he'll be open source, yeah? He can help a lot of other oss projects. +**\** oh yes absolutely +**\** we just need to figure out an Esperanto name for it, but dnaleor can be in charge of that +**\** ok - so that's tickerbot, let's move on +**\** 4. Any additional meeting items +**\** Something about multisig, I think I heard someone say +**\** Kinda peripheral, but I've finished my last ffs milestone yesterday (thanks to all). +**\** Congrats and well done +**\** woo! moneromooo congrats +**\** Thanks mooo +**\** well done mooo +**\** And I'm hacking on multisig yes, from luigi1113's docs and help. Not working yet though. +**\** moneromooo: are you going to do another FFS ? +**\** @moneromooo you should +**\** ^ +1 +**\** ^ +**\** grats moo! +**\** god i hope he does +**\** Not sure. I was kinda toying with quitting my day job and working more on monero, but... can't decide to just do it +**\** waaaat +**\** see how it goes for another round of ffs +**\<4matter>** good what feels good ;) +**\** O.O +**\** it will get funded in no time +**\<4matter>** do +**\** yessss do it moneromooo +**\** oooo. i heard you should do that +**\** wow you have a day job and you work on monero? +**\** moneromooo: DO IT +**\** i heard that you should do that from a few people moneromooo +**\** Just do it! ^^ +**\** you know you can trivially get funding +**\<4matter>** meant to say: do what feels good ;) +**\** everyone will contribute +**\** i have my wallet ready to donate +**\** It will get funded +**\** ^ +**\** and my axe +**\** why wont you take my moneros already! +**\** (your other axe) +**\** Thank you for the plebiscite :D +**\** (futurama shutup and take my money meme insert here) +**\** do it dude +**\** I might. I have a nice cushion now to stay out of work for a few years if things don't work out, so... +**\** And about multisig, I'm waiting for luigi1113 to check logs and see where things are going wonky. +**\** You wouldn’t be out of work, you’d be working for yourself! +**\** But the code's all there for N/N (No N-1/N yet). +**\** great +**\** awesome +**\** thanks for your work +**\** thanks moneromooo +**\** I haven’t had time personally to contribute recently, but are there any updates from anyone on mobile wallet? +**\** moneromooo, is that code on github anywhere yet? (not that i would understand it) +**\** Yes. Let me see.. +**\** i'm curious to check it out too, will learn a ton +**\** johnalan it seems all thats left is certs, maybe fluffypony can comment :) +**\** unless you meant official gui mobile +**\** dternyak: i think he means official wallet +**\** yeah +**\** I am very excited about both +**\** https://github.com/moneromooo-monero/bitmonero/commits/mswip +**\** official - MyMonero isn't cool enough to have dev meetings +**\** but yup I meant official +**\** ^ +**\** lol i love your commit msgs +**\** Coinomi seem to be getting there too +**\** The second commit message has luigi1113's doc about it. +**\<4matter>** jaxx integration? +**\<4matter>** jkjk +**\<4matter>** lmao +**\** “More” +**\** thanks luigi1113 and moneromooo this is exciting stuff +**\** That's going to be rebased though. Don't mind this. +**\** :) +**\** so on gui/mymonero mobile - any updates? +**\** Jaquee ^^ +**\** or MoroccanMalinois maybe? +**\** I still think we need to decide on a name for the GUI. https://github.com/monero-project/monero-core/issues/674 +**\** Monero Kerna still seems fun +**\** you can call it Mary if you like, I just want it +**\** :) +**\** not a huge fan of that +**\** I know Jaquee is working on the light wallet stuffs. +**\** moneromooo: if you don't do another FFS, I'll stick my arm through these encrypted pipes, all the way to your face, and tickle your nose until you an FFS +**\** re: gui mobile. I've finally bought an android. Will try to get in running there in upcoming weeks. I'm almost finished with the lightwallet stuff (mymonero/openmonero) +**\** way to go Jaquee! +**\** :) +**\** i have more time now over summer +**\** well done Jaquee +**\** :+1: +**\** anonimal: sounds… kinky +**\** 👍 +**\** lol endogenic +**\** @anonimal is there a kovri meeting after this? +**\** ok so on that note +**\** 5. Confirm next meeting date/time +**\** what say ye to 2 weeks +**\** June 25th +**\** :+1: +**\** Sounds good +**\** aye +**\** purrrrrrfect +**\** so on pero's suggestion, I've committed to having daemon rpc server and wallet rpc client done (with all major concerns addressed), and some form of {wallet,block}notify by the end of the month. my plan is to have the daemon server rpc buttoned up by next sunday, wallet client by the following sunday, and then spend the remainder of the month further addressing comments/suggestions and working on notify things. That precise timeline is tentative +**\** , of course, but I've committed to the end of the month for the lot. \ No newline at end of file diff --git a/_strings_en.yml b/_strings_en.yml new file mode 100644 index 00000000..71551df2 --- /dev/null +++ b/_strings_en.yml @@ -0,0 +1,95 @@ +global: + date: '%Y/%m/%d' + monero: Monero + getting_started: Getting Started + copyright: Copyright + monero_project: The Monero Project + sitename: getmonero.org, The Monero Project + wiki: Moneropedia + tags: Articles By Tag + wikimeta: on Moneropedia, the open encyclopedia of Monero knowledge + tagsmeta: All Monero blog articles that are tagged + titlemeta: on the home of Monero, a digital currency that is secure, private, and untraceable + terms: Terms + privacy: Privacy + copyright: Copyright + edit: Edit This Page +menu: + forum: Forum + blog: Blog + knowledge_base: Knowledge Base + community: Community + bitcointalk: Bitcointalk Thread + reddit: Reddit + allblog: All Blog Posts + devdiaries: Dev Diaries + missives: Monero Missives + uncategorised: Uncategorized + choose: How to Choose a Monero Client + running: How to Run a Monero Node + donations: Donating and Sponsorships + contribute: Contributing to Monero + downloads: All Monero Downloads + github: GitHub + merchants: Merchants and Services Directory + accepting: Accepting Monero Payments + about: About Monero + people: The People Behind Monero + userguides: User Guides + developerguides: Developer Guides + goals: Design & Development Goals + openalias: The OpenAlias Project + lab: Monero Research Lab + alternative: Alternative Clients + projects: External Projects + stackexchange: StackExchange Q&A + slack: Slack Chat + telegram: Telegram Chat + irc: IRC on Freenode + irc-general: "#monero (General)" + irc-development: "#monero-dev (Development)" + irc-trading: "#monero-otc (OTC Trading)" + irc-markets: "#monero-markets (Markets)" + irc-mining: "#monero-pools (Mining)" +index: + page_title: "Monero - secure, private, untraceable" + what_is_1: What is + what_is_2: " ?" + what_is_orange_block: "Monero is a secure, private, untraceable currency. It is open-source and freely available to all." + what_is_text_block_1: "With Monero, you are your own bank. Only you control and are responsible for your funds, and your accounts and transactions are kept private from prying eyes." + what_is_text_block_2: "Want to find out more? An overview of Monero's main features are below. If you'd like to try Monero for yourself the" + what_is_text_block_3: "Getting Started" + what_is_text_block_4: "section is an excellent launching point." + news: News + the_latest: The Latest + private: Private + secure: Secure + untraceable: Untraceable + private_text: "Monero uses a cryptographically sound system that allows you to send and receive funds without your @transactions being publicly visible on the @blockchain (the distributed ledger of transactions). This ensures that your purchases, receipts, and other transfers remain private by default." + untraceable_text: "By taking advantage of @ring-signatures, a special property of certain types of cryptography, Monero enables untraceable transactions. This means it's ambiguous which funds have been spent, and thus extremely unlikely that a transaction could be linked to particular user." + secure_text: "Using the power of a distributed peer-to-peer @consensus network, every transaction is cryptographically secured. Individual @accounts have a 25 word @mnemonic-seed displayed when created, which can be written down to back up the @account. Account files are encrypted with a passphrase to ensure they are worthless if stolen." + how_do_i_1: "How do I " + how_do_i_2: " ?" + get_started: get started + get_started_1: "The fastest way to start using Monero is with a web @account manager such as " + mymonero: "MyMonero" + get_started_2: "." + get_started_3: "Alternatively, if you would like to run a [full Monero node](/getting-started/running) you can download the client and a kick-starter @blockchain (to bring your local client up to speed) using the download link on the right." + where_can_i: Where can I + download_1: download + download_2: " ?" + different_os: "Need it for a different operating system?" + all_downloads: View all available downloads here + c_download: Download + monero_for: Monero for + latest_blockchain: Latest @Blockchain +blog: + title_1: All + title_2: Blog + title_3: Posts + tagged: Tagged under + author: Posted by + forum: Click here to join the discussion for this entry on the Monero Forum +tags: + all: Articles by Tag + notags: There are no posts for this tag. diff --git a/blog/assets/2014-year-in-review/overview.jpg b/blog/assets/2014-year-in-review/overview.jpg new file mode 100644 index 00000000..ad532264 Binary files /dev/null and b/blog/assets/2014-year-in-review/overview.jpg differ diff --git a/blog/assets/2015-year-in-review/governance-process.jpg b/blog/assets/2015-year-in-review/governance-process.jpg new file mode 100644 index 00000000..9f4b49f1 Binary files /dev/null and b/blog/assets/2015-year-in-review/governance-process.jpg differ diff --git a/blog/assets/2015-year-in-review/stats.jpg b/blog/assets/2015-year-in-review/stats.jpg new file mode 100644 index 00000000..4f77e8ab Binary files /dev/null and b/blog/assets/2015-year-in-review/stats.jpg differ diff --git a/blog/assets/april-fools/2015/darkflarb.gif b/blog/assets/april-fools/2015/darkflarb.gif new file mode 100644 index 00000000..2de922cd Binary files /dev/null and b/blog/assets/april-fools/2015/darkflarb.gif differ diff --git a/blog/assets/april-fools/2016/building.jpg b/blog/assets/april-fools/2016/building.jpg new file mode 100644 index 00000000..1ed8e8e3 Binary files /dev/null and b/blog/assets/april-fools/2016/building.jpg differ diff --git a/blog/assets/april-fools/2016/inside.jpg b/blog/assets/april-fools/2016/inside.jpg new file mode 100644 index 00000000..dc34c832 Binary files /dev/null and b/blog/assets/april-fools/2016/inside.jpg differ diff --git a/blog/assets/linkability-response/cointelegraph.jpg b/blog/assets/linkability-response/cointelegraph.jpg new file mode 100644 index 00000000..992841e8 Binary files /dev/null and b/blog/assets/linkability-response/cointelegraph.jpg differ diff --git a/blog/assets/linkability-response/figure5.jpg b/blog/assets/linkability-response/figure5.jpg new file mode 100644 index 00000000..cc5765a8 Binary files /dev/null and b/blog/assets/linkability-response/figure5.jpg differ diff --git a/blog/assets/linkability-response/table2.jpg b/blog/assets/linkability-response/table2.jpg new file mode 100644 index 00000000..7c8db57d Binary files /dev/null and b/blog/assets/linkability-response/table2.jpg differ diff --git a/blog/assets/linkability-response/table3.jpg b/blog/assets/linkability-response/table3.jpg new file mode 100644 index 00000000..106960ad Binary files /dev/null and b/blog/assets/linkability-response/table3.jpg differ diff --git a/blog/assets/linkability-response/tweet.jpg b/blog/assets/linkability-response/tweet.jpg new file mode 100644 index 00000000..8b76d405 Binary files /dev/null and b/blog/assets/linkability-response/tweet.jpg differ diff --git a/blog/index.html b/blog/index.html new file mode 100644 index 00000000..e7835423 --- /dev/null +++ b/blog/index.html @@ -0,0 +1,43 @@ +--- +layout: full-text +title: All Blog Posts +--- + +{% for post in paginator.posts %} +

{{ post.title }}

+

+ {{ post.summary }} + {% t blog.tagged %}: + {% for tag in post.tags %} + [{{ tag }}] + {% endfor %} + +

+{% endfor %} + + +{% if paginator.total_pages > 1 %} +

+ {% if paginator.previous_page %} + « Prev + {% else %} + « Prev + {% endif %} + + {% for page in (1..paginator.total_pages) %} + {% if page == paginator.page %} + {{ page }} + {% elsif page == 1 %} + {{ page }} + {% else %} + {{ page }} + {% endif %} + {% endfor %} + + {% if paginator.next_page %} + Next » + {% else %} + Next » + {% endif %} +

+{% endif %} \ No newline at end of file diff --git a/blog/tags/0mq.md b/blog/tags/0mq.md new file mode 100644 index 00000000..320028d5 --- /dev/null +++ b/blog/tags/0mq.md @@ -0,0 +1,3 @@ +--- +layout: blog_by_tag +--- \ No newline at end of file diff --git a/blog/tags/accounts.md b/blog/tags/accounts.md new file mode 100644 index 00000000..320028d5 --- /dev/null +++ b/blog/tags/accounts.md @@ -0,0 +1,3 @@ +--- +layout: blog_by_tag +--- \ No newline at end of file diff --git a/blog/tags/blockchaindb.md b/blog/tags/blockchaindb.md new file mode 100644 index 00000000..320028d5 --- /dev/null +++ b/blog/tags/blockchaindb.md @@ -0,0 +1,3 @@ +--- +layout: blog_by_tag +--- \ No newline at end of file diff --git a/blog/tags/branding.md b/blog/tags/branding.md new file mode 100644 index 00000000..320028d5 --- /dev/null +++ b/blog/tags/branding.md @@ -0,0 +1,3 @@ +--- +layout: blog_by_tag +--- \ No newline at end of file diff --git a/blog/tags/compliance.md b/blog/tags/compliance.md new file mode 100644 index 00000000..320028d5 --- /dev/null +++ b/blog/tags/compliance.md @@ -0,0 +1,3 @@ +--- +layout: blog_by_tag +--- \ No newline at end of file diff --git a/blog/tags/conferences.md b/blog/tags/conferences.md new file mode 100644 index 00000000..320028d5 --- /dev/null +++ b/blog/tags/conferences.md @@ -0,0 +1,3 @@ +--- +layout: blog_by_tag +--- \ No newline at end of file diff --git a/blog/tags/core.md b/blog/tags/core.md new file mode 100644 index 00000000..320028d5 --- /dev/null +++ b/blog/tags/core.md @@ -0,0 +1,3 @@ +--- +layout: blog_by_tag +--- \ No newline at end of file diff --git a/blog/tags/crypto.md b/blog/tags/crypto.md new file mode 100644 index 00000000..320028d5 --- /dev/null +++ b/blog/tags/crypto.md @@ -0,0 +1,3 @@ +--- +layout: blog_by_tag +--- \ No newline at end of file diff --git a/blog/tags/dev diaries.md b/blog/tags/dev diaries.md new file mode 100644 index 00000000..320028d5 --- /dev/null +++ b/blog/tags/dev diaries.md @@ -0,0 +1,3 @@ +--- +layout: blog_by_tag +--- \ No newline at end of file diff --git a/blog/tags/docs.md b/blog/tags/docs.md new file mode 100644 index 00000000..320028d5 --- /dev/null +++ b/blog/tags/docs.md @@ -0,0 +1,3 @@ +--- +layout: blog_by_tag +--- \ No newline at end of file diff --git a/blog/tags/exchanges.md b/blog/tags/exchanges.md new file mode 100644 index 00000000..320028d5 --- /dev/null +++ b/blog/tags/exchanges.md @@ -0,0 +1,3 @@ +--- +layout: blog_by_tag +--- \ No newline at end of file diff --git a/blog/tags/external.md b/blog/tags/external.md new file mode 100644 index 00000000..320028d5 --- /dev/null +++ b/blog/tags/external.md @@ -0,0 +1,3 @@ +--- +layout: blog_by_tag +--- \ No newline at end of file diff --git a/blog/tags/forkguard.md b/blog/tags/forkguard.md new file mode 100644 index 00000000..320028d5 --- /dev/null +++ b/blog/tags/forkguard.md @@ -0,0 +1,3 @@ +--- +layout: blog_by_tag +--- \ No newline at end of file diff --git a/blog/tags/funding.md b/blog/tags/funding.md new file mode 100644 index 00000000..320028d5 --- /dev/null +++ b/blog/tags/funding.md @@ -0,0 +1,3 @@ +--- +layout: blog_by_tag +--- \ No newline at end of file diff --git a/blog/tags/gui.md b/blog/tags/gui.md new file mode 100644 index 00000000..320028d5 --- /dev/null +++ b/blog/tags/gui.md @@ -0,0 +1,3 @@ +--- +layout: blog_by_tag +--- \ No newline at end of file diff --git a/blog/tags/i2p.md b/blog/tags/i2p.md new file mode 100644 index 00000000..320028d5 --- /dev/null +++ b/blog/tags/i2p.md @@ -0,0 +1,3 @@ +--- +layout: blog_by_tag +--- \ No newline at end of file diff --git a/blog/tags/i8n.md b/blog/tags/i8n.md new file mode 100644 index 00000000..320028d5 --- /dev/null +++ b/blog/tags/i8n.md @@ -0,0 +1,3 @@ +--- +layout: blog_by_tag +--- \ No newline at end of file diff --git a/blog/tags/kovri.md b/blog/tags/kovri.md new file mode 100644 index 00000000..320028d5 --- /dev/null +++ b/blog/tags/kovri.md @@ -0,0 +1,3 @@ +--- +layout: blog_by_tag +--- \ No newline at end of file diff --git a/blog/tags/mining.md b/blog/tags/mining.md new file mode 100644 index 00000000..320028d5 --- /dev/null +++ b/blog/tags/mining.md @@ -0,0 +1,3 @@ +--- +layout: blog_by_tag +--- \ No newline at end of file diff --git a/blog/tags/monero missives.md b/blog/tags/monero missives.md new file mode 100644 index 00000000..320028d5 --- /dev/null +++ b/blog/tags/monero missives.md @@ -0,0 +1,3 @@ +--- +layout: blog_by_tag +--- \ No newline at end of file diff --git a/blog/tags/mymonero.md b/blog/tags/mymonero.md new file mode 100644 index 00000000..320028d5 --- /dev/null +++ b/blog/tags/mymonero.md @@ -0,0 +1,3 @@ +--- +layout: blog_by_tag +--- \ No newline at end of file diff --git a/blog/tags/platforms.md b/blog/tags/platforms.md new file mode 100644 index 00000000..320028d5 --- /dev/null +++ b/blog/tags/platforms.md @@ -0,0 +1,3 @@ +--- +layout: blog_by_tag +--- \ No newline at end of file diff --git a/blog/tags/releases.md b/blog/tags/releases.md new file mode 100644 index 00000000..320028d5 --- /dev/null +++ b/blog/tags/releases.md @@ -0,0 +1,3 @@ +--- +layout: blog_by_tag +--- \ No newline at end of file diff --git a/blog/tags/research.md b/blog/tags/research.md new file mode 100644 index 00000000..320028d5 --- /dev/null +++ b/blog/tags/research.md @@ -0,0 +1,3 @@ +--- +layout: blog_by_tag +--- \ No newline at end of file diff --git a/blog/tags/rpc.md b/blog/tags/rpc.md new file mode 100644 index 00000000..320028d5 --- /dev/null +++ b/blog/tags/rpc.md @@ -0,0 +1,3 @@ +--- +layout: blog_by_tag +--- \ No newline at end of file diff --git a/blog/tags/usability.md b/blog/tags/usability.md new file mode 100644 index 00000000..320028d5 --- /dev/null +++ b/blog/tags/usability.md @@ -0,0 +1,3 @@ +--- +layout: blog_by_tag +--- \ No newline at end of file diff --git a/blog/tags/year in review.md b/blog/tags/year in review.md new file mode 100644 index 00000000..320028d5 --- /dev/null +++ b/blog/tags/year in review.md @@ -0,0 +1,3 @@ +--- +layout: blog_by_tag +--- \ No newline at end of file diff --git a/community/events/index.md b/community/events/index.md new file mode 100644 index 00000000..2b3580be --- /dev/null +++ b/community/events/index.md @@ -0,0 +1,32 @@ +--- +layout: custom +title: Events +--- + +
+Monero people are always down to get together and have a good time. Check below to see Monero-related events happening in your area. +
+ +{% for toplevel in site.data.events %} + +
+
+
+
+
+

{{toplevel.event}}

+

Where

+

{{toplevel.where}}

+

When

+

{{toplevel.when}}

+

Description

+

{{toplevel.description}}

+

Link

+ {{toplevel.link}} +
+
+
+
+
+ +{%endfor%} \ No newline at end of file diff --git a/community/hangouts/index.md b/community/hangouts/index.md new file mode 100644 index 00000000..bdcb1223 --- /dev/null +++ b/community/hangouts/index.md @@ -0,0 +1,121 @@ +--- +layout: custom +title: Hangouts +--- +
+The Monero community is diverse and varied. We come from all over, but we definitely have some places we like to hang out together. You'll find most of them below. Join us! +
+ +
+ +
+
    +
  • + +
    • +
  • + +
    • +
  • + +
    • +
  • + +
    • +
+
+ +
+
+ +
+
+
+
+
+

Chat Relays

+
+
+
+

Not everyone likes to get on the IRC, and for those people we have other programs that act as relays to these channels. They've also got a few channels of their own.

+
+
+
+

Rocket

+
+
+

Slack

+
+
+

Telegram

+
+
+
+
+
+
+

IRC Channels

+
+
+
+

The Monero community utilizes a lot of IRC channels that each serve different purposes. Some to work, and some just to hang out. You'll find the more popular ones below.

+
+
+
+ #monero +

This channel is used to discuss all things Monero related.

+
+
+ #monero-community +

This channel is for the Monero community to congretate and discuss ideas.

+
+
+ #monero-dev +

The many contributors and developers come here to discuss dev-y things.

+
+
+
+
+ #monero-markets +

We use this channel to talk about the price of Monero and other coins.

+
+
+ #monero-otc +

Over the counter Monero. Come here to purchase XMR from your fellow Moneron.

+
+
+ #monero-pools +

This is the place for mining questions and discussion.

+
+
+
+
+
+ + + +
+
+
+

Stack Exchange

+
+
+

The Monero Stack Exchange is a quick and easy way to ask questions and get answers. Below you'll find some high quality question/answer pairs to some frequently asked questions.

+
+
+ Why does monero have higher transaction fees than bitcoin? + What does Monero's scaling roadmap look like? + What cryptography primitives/concepts, other than the basic ones, does Monero use? + How to extract data from local blockchain? + Hiding TCP traffic for Monero miners? +
+
+

Visit Stack Exchange

+
+
+
+ +
+
+ +
\ No newline at end of file diff --git a/community/merchants/index.md b/community/merchants/index.md new file mode 100644 index 00000000..1a52a811 --- /dev/null +++ b/community/merchants/index.md @@ -0,0 +1,25 @@ +--- +layout: custom +title: Merchants & Services +--- +
+Merchants of all kinds have come to value the financial privacy that Monero brings. Below is a list of the merchants that we know of that currently accept Monero for their goods and services. If a company no longer accepts Monero or you would like your business to be listed, please [open a GitHub issue and let us know](https://github.com/monero-project/monero-site/issues). +
+
+{% for toplevel in site.data.merchants %} +
+
+

{{toplevel.category}}

+
+ {% for merchants in toplevel.merchants %} +
+ {{merchants.name}} +
+ {% endfor %} +
+
+
+{%endfor%} + + +
\ No newline at end of file diff --git a/community/sponsorships/index.md b/community/sponsorships/index.md new file mode 100644 index 00000000..665ed691 --- /dev/null +++ b/community/sponsorships/index.md @@ -0,0 +1,101 @@ +--- +layout: custom +title: Sponsorships +--- + +
+The following businesses have supported the Monero Project in its goal to bring financial privacy to the world. We couldn't be more grateful for their contributions. If you would like to sponsor the Monero Project and be listed on this page, please send an email to dev@getmonero.org. +
+ +
+
+
+
+
+
+
+

My Monero

+ +
+
+
+
+
+
+
+
+

Araxis

+ +
+
+
+
+
+
+
+
+

Dome9 Security

+ +
+
+
+
+
+
+
+
+
+
+

Kitware

+ +
+
+
+
+ +
+
+
+
+

Fork Networking

+ +
+
+
+
+ +
+
+
+
+

JetBrains

+ +
+
+
+
+
+
+
+
+
+
+

Navicat

+ +
+
+
+
+
+
+
+
+

Symas

+ +
+
+
+
+
+
+
\ No newline at end of file diff --git a/community/team/index.md b/community/team/index.md new file mode 100644 index 00000000..cb8d0c5d --- /dev/null +++ b/community/team/index.md @@ -0,0 +1,154 @@ +--- +layout: custom +title: Monero Team +--- +
+ +
+
+
+
+ + +

Core

+
+
+ {% for toplevel in site.data.team %} + {% if toplevel.area == "Core" %} + {% for member in toplevel.member %} +
+
+
+

{{member.name}}

+
+
+

{{member.email}}

+
+ {% if member.url %} +
+ GitHub +
+ {%endif%} +
+
+ {%endfor%} + {%endif%} + {%endfor%} +
+
+ + +

Developers

+
+
+
+
+
+

The Monero Project has had well over 200 contributors over the life of the project. For a complete list, please see the GitHub contributors page. Below you'll find some individuals that have gone above and beyond for Monero.

+
+
+
+
+
+ {% for toplevel in site.data.team %} + {% if toplevel.area == "Developers" %} + {% for member in toplevel.member %} +
+
+
+

{{member.name}}

+
+ {% if member.url %} +
+ GitHub +
+ {%endif%} +
+
+ {%endfor%} + {%endif%} + {%endfor%} +
+
+ + +

Community

+
+
+ {% for toplevel in site.data.team %} + {% if toplevel.area == "Community" %} + {% for member in toplevel.member %} +
+
+
+

{{member.name}}

+
+ {% if member.url %} +
+ GitHub +
+ {%endif%} +
+
+ {%endfor%} + {%endif%} + {%endfor%} +
+
+ + +

Research Lab

+
+
+ {% for toplevel in site.data.team %} + {% if toplevel.area == "Monero Research Lab" %} + {% for member in toplevel.member %} +
+
+
+

{{member.name}}

+
+ {% if member.url %} +
+ GitHub +
+ {%endif%} +
+
+ {%endfor%} + {%endif%} + {%endfor%} +
+
+ + +

Special Thanks

+
+
+ {% for toplevel in site.data.team %} + {% if toplevel.area == "Special Thanks" %} + {% for member in toplevel.member %} +
+
+
+

{{member.name}}

+
+ {% if member.url %} +
+ GitHub +
+ {%endif%} +
+
+ {%endfor%} + {%endif%} + {%endfor%} +
+
+
+
+
+
+ + +
\ No newline at end of file diff --git a/css/custom.css b/css/custom.css new file mode 100644 index 00000000..ff9edf1b --- /dev/null +++ b/css/custom.css @@ -0,0 +1,3867 @@ +/*FONTS*/ + +@font-face { + font-family: 'Hind'; + font-weight: 500; + font-style: normal; + src: url('../fonts/Hind-500.eot'); + src: url('../fonts/Hind-500.eot?#iefix') format('embedded-opentype'), + local('Hind Medium'), + local('Hind-500'), + url('../fonts/Hind-500.woff2') format('woff2'), + url('../fonts/Hind-500.woff') format('woff'), + url('../fonts/Hind-500.ttf') format('truetype'), + url('../fonts/Hind-500.svg#Hind') format('svg'); +} + +@font-face { + font-family: 'Hind'; + font-weight: 700; + font-style: normal; + src: url('../fonts/Hind-700.eot'); + src: url('../fonts/Hind-700.eot?#iefix') format('embedded-opentype'), + local('Hind Bold'), + local('Hind-700'), + url('../fonts/Hind-700.woff2') format('woff2'), + url('../fonts/Hind-700.woff') format('woff'), + url('../fonts/Hind-700.ttf') format('truetype'), + url('../fonts/Hind-700.svg#Hind') format('svg'); +} + +@font-face { + font-family: 'Open Sans', sans-serif; + font-weight: 400; + font-style: normal; + src: url('../fonts/Open-Sans-regular.eot'); + src: url('../fonts/Open-Sans-regular.eot?#iefix') format('embedded-opentype'), + local('Open Sans'), + local('Open-Sans-regular'), + url('../fonts/Open-Sans-regular.woff2') format('woff2'), + url('../fonts/Open-Sans-regular.woff') format('woff'), + url('../fonts/Open-Sans-regular.ttf') format('truetype'), + url('../fonts/Open-Sans-regular.svg#OpenSans') format('svg'); +} + +@font-face { + font-family: 'Open Sans', sans-serif; + font-weight: 800; + font-style: normal; + src: url('../fonts/Open-Sans-800.eot'); + src: url('../fonts/Open-Sans-800.eot?#iefix') format('embedded-opentype'), + local('Open Sans Extrabold'), + local('Open-Sans-800'), + url('../fonts/Open-Sans-800.woff2') format('woff2'), + url('../fonts/Open-Sans-800.woff') format('woff'), + url('../fonts/Open-Sans-800.ttf') format('truetype'), + url('../fonts/Open-Sans-800.svg#OpenSans') format('svg'); +} + +@font-face { + font-family: 'icons'; + src: url('../fonts/icons.eot?58817762'); + src: url('../fonts/icons.eot?58817762#iefix') format('embedded-opentype'), + url('../fonts/icons.woff2?58817762') format('woff2'), + url('../fonts/icons.woff?58817762') format('woff'), + url('../fonts/icons.ttf?58817762') format('truetype'), + url('../fonts/icons.svg?58817762#icons') format('svg'); + font-weight: normal; + font-style: normal; +} + +/*FLEXBOX*/ + +.row { + box-sizing: border-box; + display: -ms-flexbox; + display: -webkit-box; + display: flex; + -ms-flex: 0 1 auto; + -webkit-box-flex: 0; + flex: 0 1 auto; + -ms-flex-direction: row; + -webkit-box-orient: horizontal; + -webkit-box-direction: normal; + flex-direction: row; + -ms-flex-wrap: wrap; + flex-wrap: wrap; +} + +.row.reverse { + -ms-flex-direction: row-reverse; + -webkit-box-orient: horizontal; + -webkit-box-direction: reverse; + flex-direction: row-reverse; +} + +.col.reverse { + -ms-flex-direction: column-reverse; + -webkit-box-orient: vertical; + -webkit-box-direction: reverse; + flex-direction: column-reverse; +} + +.col-xs, +.col-xs-1, +.col-xs-2, +.col-xs-3, +.col-xs-4, +.col-xs-5, +.col-xs-6, +.col-xs-7, +.col-xs-8, +.col-xs-9, +.col-xs-10, +.col-xs-11, +.col-xs-12 { + box-sizing: border-box; + -ms-flex: 0 0 auto; + -webkit-box-flex: 0; + flex: 0 0 auto; + /*padding-right: 1rem; + padding-left: 1rem;*/ +} + +.col-xs { + -webkit-flex-grow: 1; + -ms-flex-positive: 1; + -webkit-box-flex: 1; + flex-grow: 1; + -ms-flex-preferred-size: 0; + flex-basis: 0; + max-width: 100%; +} + +.col-xs-1 { + -ms-flex-preferred-size: 8.333%; + flex-basis: 8.333%; + max-width: 8.333%; +} + +.col-xs-2 { + -ms-flex-preferred-size: 16.667%; + flex-basis: 16.667%; + max-width: 16.667%; +} + +.col-xs-3 { + -ms-flex-preferred-size: 25%; + flex-basis: 25%; + max-width: 25%; +} + +.col-xs-4 { + -ms-flex-preferred-size: 33.333%; + flex-basis: 33.333%; + max-width: 33.333%; +} + +.col-xs-5 { + -ms-flex-preferred-size: 41.667%; + flex-basis: 41.667%; + max-width: 41.667%; +} + +.col-xs-6 { + -ms-flex-preferred-size: 50%; + flex-basis: 50%; + max-width: 50%; +} + +.col-xs-7 { + -ms-flex-preferred-size: 58.333%; + flex-basis: 58.333%; + max-width: 58.333%; +} + +.col-xs-8 { + -ms-flex-preferred-size: 66.667%; + flex-basis: 66.667%; + max-width: 66.667%; +} + +.col-xs-9 { + -ms-flex-preferred-size: 75%; + flex-basis: 75%; + max-width: 75%; +} + +.col-xs-10 { + -ms-flex-preferred-size: 83.333%; + flex-basis: 83.333%; + max-width: 83.333%; +} + +.col-xs-11 { + -ms-flex-preferred-size: 91.667%; + flex-basis: 91.667%; + max-width: 91.667%; +} + +.col-xs-12 { + -ms-flex-preferred-size: 100%; + flex-basis: 100%; + max-width: 100%; +} + +.col-xs-offset-1 { + margin-left: 8.333%; +} + +.col-xs-offset-2 { + margin-left: 16.667%; +} + +.col-xs-offset-3 { + margin-left: 25%; +} + +.col-xs-offset-4 { + margin-left: 33.333%; +} + +.col-xs-offset-5 { + margin-left: 41.667%; +} + +.col-xs-offset-6 { + margin-left: 50%; +} + +.col-xs-offset-7 { + margin-left: 58.333%; +} + +.col-xs-offset-8 { + margin-left: 66.667%; +} + +.col-xs-offset-9 { + margin-left: 75%; +} + +.col-xs-offset-10 { + margin-left: 83.333%; +} + +.col-xs-offset-11 { + margin-left: 91.667%; +} + +.start-xs { + -ms-flex-pack: start; + -webkit-box-pack: start; + justify-content: flex-start; + text-align: start; +} + +.center-xs { + -ms-flex-pack: center; + -webkit-box-pack: center; + justify-content: center; + text-align: center; +} + +.end-xs { + -ms-flex-pack: end; + -webkit-box-pack: end; + justify-content: flex-end; + text-align: right; +} + +.top-xs { + -ms-flex-align: start; + -webkit-box-align: start; + align-items: flex-start; +} + +.middle-xs { + -ms-flex-align: center; + -webkit-box-align: center; + align-items: center; +} + +.bottom-xs { + -ms-flex-align: end; + -webkit-box-align: end; + align-items: flex-end; +} + +.around-xs { + -ms-flex-pack: distribute; + justify-content: space-around; +} + +.between-xs { + -ms-flex-pack: justify; + -webkit-box-pack: justify; + justify-content: space-between; +} + +.first-xs { + -ms-flex-order: -1; + -webkit-box-ordinal-group: 0; + order: -1; +} + +.last-xs { + -ms-flex-order: 1; + -webkit-box-ordinal-group: 2; + order: 1; +} + +@media only screen and (min-width: 48em) { + .container { + width: 46rem; + } + + .col-sm, + .col-sm-1, + .col-sm-2, + .col-sm-3, + .col-sm-4, + .col-sm-5, + .col-sm-6, + .col-sm-7, + .col-sm-8, + .col-sm-9, + .col-sm-10, + .col-sm-11, + .col-sm-12 { + box-sizing: border-box; + -ms-flex: 0 0 auto; + -webkit-box-flex: 0; + flex: 0 0 auto; + /*padding-right: 1rem; + padding-left: 1rem;*/ + } + + .col-sm { + -webkit-flex-grow: 1; + -ms-flex-positive: 1; + -webkit-box-flex: 1; + flex-grow: 1; + -ms-flex-preferred-size: 0; + flex-basis: 0; + max-width: 100%; + } + + .col-sm-1 { + -ms-flex-preferred-size: 8.333%; + flex-basis: 8.333%; + max-width: 8.333%; + } + + .col-sm-2 { + -ms-flex-preferred-size: 16.667%; + flex-basis: 16.667%; + max-width: 16.667%; + } + + .col-sm-3 { + -ms-flex-preferred-size: 25%; + flex-basis: 25%; + max-width: 25%; + } + + .col-sm-4 { + -ms-flex-preferred-size: 33.333%; + flex-basis: 33.333%; + max-width: 33.333%; + } + + .col-sm-5 { + -ms-flex-preferred-size: 41.667%; + flex-basis: 41.667%; + max-width: 41.667%; + } + + .col-sm-6 { + -ms-flex-preferred-size: 50%; + flex-basis: 50%; + max-width: 50%; + } + + .col-sm-7 { + -ms-flex-preferred-size: 58.333%; + flex-basis: 58.333%; + max-width: 58.333%; + } + + .col-sm-8 { + -ms-flex-preferred-size: 66.667%; + flex-basis: 66.667%; + max-width: 66.667%; + } + + .col-sm-9 { + -ms-flex-preferred-size: 75%; + flex-basis: 75%; + max-width: 75%; + } + + .col-sm-10 { + -ms-flex-preferred-size: 83.333%; + flex-basis: 83.333%; + max-width: 83.333%; + } + + .col-sm-11 { + -ms-flex-preferred-size: 91.667%; + flex-basis: 91.667%; + max-width: 91.667%; + } + + .col-sm-12 { + -ms-flex-preferred-size: 100%; + flex-basis: 100%; + max-width: 100%; + } + + .col-sm-offset-1 { + margin-left: 8.333%; + } + + .col-sm-offset-2 { + margin-left: 16.667%; + } + + .col-sm-offset-3 { + margin-left: 25%; + } + + .col-sm-offset-4 { + margin-left: 33.333%; + } + + .col-sm-offset-5 { + margin-left: 41.667%; + } + + .col-sm-offset-6 { + margin-left: 50%; + } + + .col-sm-offset-7 { + margin-left: 58.333%; + } + + .col-sm-offset-8 { + margin-left: 66.667%; + } + + .col-sm-offset-9 { + margin-left: 75%; + } + + .col-sm-offset-10 { + margin-left: 83.333%; + } + + .col-sm-offset-11 { + margin-left: 91.667%; + } + + .start-sm { + -ms-flex-pack: start; + -webkit-box-pack: start; + justify-content: flex-start; + text-align: start; + } + + .center-sm { + -ms-flex-pack: center; + -webkit-box-pack: center; + justify-content: center; + text-align: center; + } + + .end-sm { + -ms-flex-pack: end; + -webkit-box-pack: end; + justify-content: flex-end; + text-align: right; + } + + .top-sm { + -ms-flex-align: start; + -webkit-box-align: start; + align-items: flex-start; + } + + .middle-sm { + -ms-flex-align: center; + -webkit-box-align: center; + align-items: center; + } + + .bottom-sm { + -ms-flex-align: end; + -webkit-box-align: end; + align-items: flex-end; + } + + .around-sm { + -ms-flex-pack: distribute; + justify-content: space-around; + } + + .between-sm { + -ms-flex-pack: justify; + -webkit-box-pack: justify; + justify-content: space-between; + } + + .first-sm { + -ms-flex-order: -1; + -webkit-box-ordinal-group: 0; + order: -1; + } + + .last-sm { + -ms-flex-order: 1; + -webkit-box-ordinal-group: 2; + order: 1; + } +} + +@media only screen and (min-width: 62em) { + .container { + width: 61rem; + } + + .col-md, + .col-md-1, + .col-md-2, + .col-md-3, + .col-md-4, + .col-md-5, + .col-md-6, + .col-md-7, + .col-md-8, + .col-md-9, + .col-md-10, + .col-md-11, + .col-md-12 { + box-sizing: border-box; + -ms-flex: 0 0 auto; + -webkit-box-flex: 0; + flex: 0 0 auto; + } + + .col-md { + -webkit-flex-grow: 1; + -ms-flex-positive: 1; + -webkit-box-flex: 1; + flex-grow: 1; + -ms-flex-preferred-size: 0; + flex-basis: 0; + max-width: 100%; + } + + .col-md-1 { + -ms-flex-preferred-size: 8.333%; + flex-basis: 8.333%; + max-width: 8.333%; + } + + .col-md-2 { + -ms-flex-preferred-size: 16.667%; + flex-basis: 16.667%; + max-width: 16.667%; + } + + .col-md-3 { + -ms-flex-preferred-size: 25%; + flex-basis: 25%; + max-width: 25%; + } + + .col-md-4 { + -ms-flex-preferred-size: 33.333%; + flex-basis: 33.333%; + max-width: 33.333%; + } + + .col-md-5 { + -ms-flex-preferred-size: 41.667%; + flex-basis: 41.667%; + max-width: 41.667%; + } + + .col-md-6 { + -ms-flex-preferred-size: 50%; + flex-basis: 50%; + max-width: 50%; + } + + .col-md-7 { + -ms-flex-preferred-size: 58.333%; + flex-basis: 58.333%; + max-width: 58.333%; + } + + .col-md-8 { + -ms-flex-preferred-size: 66.667%; + flex-basis: 66.667%; + max-width: 66.667%; + } + + .col-md-9 { + -ms-flex-preferred-size: 75%; + flex-basis: 75%; + max-width: 75%; + } + + .col-md-10 { + -ms-flex-preferred-size: 83.333%; + flex-basis: 83.333%; + max-width: 83.333%; + } + + .col-md-11 { + -ms-flex-preferred-size: 91.667%; + flex-basis: 91.667%; + max-width: 91.667%; + } + + .col-md-12 { + -ms-flex-preferred-size: 100%; + flex-basis: 100%; + max-width: 100%; + } + + .col-md-offset-1 { + margin-left: 8.333%; + } + + .col-md-offset-2 { + margin-left: 16.667%; + } + + .col-md-offset-3 { + margin-left: 25%; + } + + .col-md-offset-4 { + margin-left: 33.333%; + } + + .col-md-offset-5 { + margin-left: 41.667%; + } + + .col-md-offset-6 { + margin-left: 50%; + } + + .col-md-offset-7 { + margin-left: 58.333%; + } + + .col-md-offset-8 { + margin-left: 66.667%; + } + + .col-md-offset-9 { + margin-left: 75%; + } + + .col-md-offset-10 { + margin-left: 83.333%; + } + + .col-md-offset-11 { + margin-left: 91.667%; + } + + .start-md { + -ms-flex-pack: start; + -webkit-box-pack: start; + justify-content: flex-start; + text-align: start; + } + + .center-md { + -ms-flex-pack: center; + -webkit-box-pack: center; + justify-content: center; + text-align: center; + } + + .end-md { + -ms-flex-pack: end; + -webkit-box-pack: end; + justify-content: flex-end; + text-align: right; + } + + .top-md { + -ms-flex-align: start; + -webkit-box-align: start; + align-items: flex-start; + } + + .middle-md { + -ms-flex-align: center; + -webkit-box-align: center; + align-items: center; + } + + .bottom-md { + -ms-flex-align: end; + -webkit-box-align: end; + align-items: flex-end; + } + + .around-md { + -ms-flex-pack: distribute; + justify-content: space-around; + } + + .between-md { + -ms-flex-pack: justify; + -webkit-box-pack: justify; + justify-content: space-between; + } + + .first-md { + -ms-flex-order: -1; + -webkit-box-ordinal-group: 0; + order: -1; + } + + .last-md { + -ms-flex-order: 1; + -webkit-box-ordinal-group: 2; + order: 1; + } +} + +@media only screen and (min-width: 75em) { + .container { + width: 71rem; + } + + .col-lg, + .col-lg-1, + .col-lg-2, + .col-lg-3, + .col-lg-4, + .col-lg-5, + .col-lg-6, + .col-lg-7, + .col-lg-8, + .col-lg-9, + .col-lg-10, + .col-lg-11, + .col-lg-12 { + box-sizing: border-box; + -ms-flex: 0 0 auto; + -webkit-box-flex: 0; + flex: 0 0 auto; + } + + .col-lg { + -webkit-flex-grow: 1; + -ms-flex-positive: 1; + -webkit-box-flex: 1; + flex-grow: 1; + -ms-flex-preferred-size: 0; + flex-basis: 0; + max-width: 100%; + } + + .col-lg-1 { + -ms-flex-preferred-size: 8.333%; + flex-basis: 8.333%; + max-width: 8.333%; + } + + .col-lg-2 { + -ms-flex-preferred-size: 16.667%; + flex-basis: 16.667%; + max-width: 16.667%; + } + + .col-lg-3 { + -ms-flex-preferred-size: 25%; + flex-basis: 25%; + max-width: 25%; + } + + .col-lg-4 { + -ms-flex-preferred-size: 33.333%; + flex-basis: 33.333%; + max-width: 33.333%; + } + + .col-lg-5 { + -ms-flex-preferred-size: 41.667%; + flex-basis: 41.667%; + max-width: 41.667%; + } + + .col-lg-6 { + -ms-flex-preferred-size: 50%; + flex-basis: 50%; + max-width: 50%; + } + + .col-lg-7 { + -ms-flex-preferred-size: 58.333%; + flex-basis: 58.333%; + max-width: 58.333%; + } + + .col-lg-8 { + -ms-flex-preferred-size: 66.667%; + flex-basis: 66.667%; + max-width: 66.667%; + } + + .col-lg-9 { + -ms-flex-preferred-size: 75%; + flex-basis: 75%; + max-width: 75%; + } + + .col-lg-10 { + -ms-flex-preferred-size: 83.333%; + flex-basis: 83.333%; + max-width: 83.333%; + } + + .col-lg-11 { + -ms-flex-preferred-size: 91.667%; + flex-basis: 91.667%; + max-width: 91.667%; + } + + .col-lg-12 { + -ms-flex-preferred-size: 100%; + flex-basis: 100%; + max-width: 100%; + } + + .col-lg-offset-1 { + margin-left: 8.333%; + } + + .col-lg-offset-2 { + margin-left: 16.667%; + } + + .col-lg-offset-3 { + margin-left: 25%; + } + + .col-lg-offset-4 { + margin-left: 33.333%; + } + + .col-lg-offset-5 { + margin-left: 41.667%; + } + + .col-lg-offset-6 { + margin-left: 50%; + } + + .col-lg-offset-7 { + margin-left: 58.333%; + } + + .col-lg-offset-8 { + margin-left: 66.667%; + } + + .col-lg-offset-9 { + margin-left: 75%; + } + + .col-lg-offset-10 { + margin-left: 83.333%; + } + + .col-lg-offset-11 { + margin-left: 91.667%; + } + + .start-lg { + -ms-flex-pack: start; + -webkit-box-pack: start; + justify-content: flex-start; + text-align: start; + } + + .center-lg { + -ms-flex-pack: center; + -webkit-box-pack: center; + justify-content: center; + text-align: center; + } + + .end-lg { + -ms-flex-pack: end; + -webkit-box-pack: end; + justify-content: flex-end; + text-align: right; + } + + .top-lg { + -ms-flex-align: start; + -webkit-box-align: start; + align-items: flex-start; + } + + .middle-lg { + -ms-flex-align: center; + -webkit-box-align: center; + align-items: center; + } + + .bottom-lg { + -ms-flex-align: end; + -webkit-box-align: end; + align-items: flex-end; + } + + .around-lg { + -ms-flex-pack: distribute; + justify-content: space-around; + } + + .between-lg { + -ms-flex-pack: justify; + -webkit-box-pack: justify; + justify-content: space-between; + } + + .first-lg { + -ms-flex-order: -1; + -webkit-box-ordinal-group: 0; + order: -1; + } + + .last-lg { + -ms-flex-order: 1; + -webkit-box-ordinal-group: 2; + order: 1; + } +} + +/******************GENERAL**********************/ + +body { + margin: 0; + padding: 0; + font-family: 'Open Sans', sans-serif; + font-weight: 400; + color: #4c4c4c; + background-color: #edeef0; +} + +body p, body blockquote, body ul { + line-height: 1.7; + font-size: 1.0625rem; +} + +a { + color: #ff7519; + text-decoration: none; +} + +a:hover, a:focus, a:active { + text-decoration: underline; + outline: 0; +} + +a, button, input, select, textarea, label, label:checked, label:focus { + -webkit-tap-highlight-color: rgba(0,0,0,0); + -webkit-tap-highlight-color: transparent; +} + +h1, h2, h3, h4, h5, h6, p {margin: 0; padding: 0;} + +img, video {max-width: 100%;} + +video {width: 100%;} + +.container, .container-fluid { + margin-left: auto; + margin-right: auto; +} + +.container-fluid { + padding-right: 0; + padding-left: 0; +} + +.list-unstyled { + list-style: none; + padding-left: 0; +} + +.list-inline>li { + display: inline; +} + +.text-center {text-align: center;} + +.text-adapted { + max-width: 40rem; + margin-left: auto; + margin-right: auto; +} + +.info-block, .white-nav { + background-color: #ffffff; + -moz-box-shadow: 0 2px 4px rgba(50,50,93,.1); + -webkit-box-shadow: 0 2px 4px rgba(50,50,93,.1); + box-shadow: 0 2px 4px rgba(50,50,93,.1); +} + +code { + white-space: pre-wrap; + background-color: #fff1e8; + color: #2f6f9f; + padding: 0.2rem; + margin: 0 0.2rem; + border-radius: 0.2rem; + text-indent: 0; + line-height: 1.1rem; +} + +pre.highlight { + background-color: #fff1e8; + color: #2f6f9f; + padding: 0.7rem; + border-radius: 0.2rem; + text-indent: -6px; +} + +pre.highlight>code { + background-color: none; +} + +.arrow-down { + width: 0; + height: 0; + border-left: 3px solid transparent; + border-right: 3px solid transparent; + border-top: 3px solid #393939; +} + +@media only screen and (max-width: 75rem) { + +body p, body blockquote, body ul { + font-size: 16px; + font-size: 1rem; +} + +} + +@media only screen and (max-width: 62rem) { + +.page-wrapper { + padding-top: 4.5rem; +} + code { + word-break: break-all; + } + +} + +@media only screen and (max-width: 48rem) { + +body {font-size: 1rem;} + +.page-wrapper { + padding-top: 4rem; +} + +} + +/*******************HEADINGS*************************/ + +h1 { + font-family: 'Hind', 'Open Sans', sans-serif; + font-weight: 700; + font-size: 2.3rem; + line-height: 1; + margin: 2.5rem 0 2rem 0; +} + +h2 { + font-family: 'Hind', 'Open Sans', sans-serif; + font-weight: 700; + font-size: 1.75rem; + line-height: 1.3; + text-align: center; +} + +h3 { + font-family: 'Open Sans', sans-serif; + font-size: 1.5rem; + font-weight: 400; + /*margin: 2.7rem 0 1rem 0;*/ + letter-spacing: 0.05rem; + line-height: 1.3; + padding-top: 1rem; + margin-top: 1rem; + margin-bottom: 0; +} + +p, h4 { + padding-top: 1rem; +} + +h1#main-h1 { + font-family: 'Hind', 'Open Sans', sans-serif; + font-weight: 700; + font-size: 3.4375rem; + text-transform: uppercase; + margin: 0; + line-height: 1; + padding: 0; +} + + +h2#main-h2 { + font-family: 'Open Sans', sans-serif; + font-size: 1.5625rem; + font-size: 1.75rem; + font-weight: 400; + margin: 1rem 0 0 0; + letter-spacing: 0.05rem; + line-height: 1; + text-align: left; +} + +.about-main h3, .about-monero h3 { + padding-top: 0; + font-weight: 600; + line-height: 1.7; + font-size: 1.15rem; + letter-spacing: normal; +} + +.info-block h2 { + margin-top: 4rem; + margin-bottom: 1rem; + margin-bottom: 0; +} + +.info-block h2:first-child, h3:first-child, h3:first-of-type { + margin-top: 0; +} + +.events h3 { + margin-top: 1rem; +} + + +.container.description p, .container.description h3 { + padding: 0 5rem; + text-align: center; + margin-bottom: 2.5rem; +} + + +.pre-roadmap p { + margin-bottom: 2.5rem; +} + +.hangouts ul { + margin-bottom: 2.5rem; +} + +@media only screen and (max-width: 75rem) { + +h1#main-h1 { + font-size: 2.4rem; + margin: 0; + line-height: 1; +} + +h2#main-h2 { + font-size: 1.25rem; + margin: 0.5rem 0 0 0; +} + +h2, .info-block h2 { + font-size: 23px; + font-size: 1.5625rem; + margin-bottom: 0; +} + +h3 { + font-size: 19px; + font-size: 1.25rem; + padding-top: 1rem; + margin-top: 1rem; + margin-bottom: 0; +} + +} + +@media only screen and (max-width: 62rem) { + +h1 { + margin: 0.5rem 0 1rem 0; +} + +.pre-roadmap p, .container.description p { + margin-bottom: 1.5rem; + margin-top: -1rem; +} + +h1#main-h1 { + font-size: 3rem; + text-transform: uppercase; + margin: 0; +} + +h2#main-h2 { + font-size: 1.25rem; + margin: 1rem 0 0 0; +} + +h2, .info-block h2 { + font-size: 23px; + font-size: 1.5625rem; + margin-bottom: 0; +} + +h3 { + font-size: 20px; + font-size: 1.25rem; + padding-top: 1rem; + margin-top: 1rem; + margin-bottom: 0; +} + +p { + padding-top: 1rem; +} + +} + +@media only screen and (max-width: 48rem) { + +h1#main-h1 { + font-size: 3rem; +} + +h1 { + font-size: 1.8rem; + padding: 0.3rem; + margin: 0.5rem 0; +} + +.about-main h3, .about-monero h3 { + padding-top: 1rem; +} + +.container.description p { + padding: 0 2rem; +} + +.pre-roadmap p, .container.description p { + margin-bottom: 1rem; + margin-top: -0.5rem; +} + +} + +@media only screen and (max-width: 47.9rem) { + + + +} + + + +@media only screen and (max-width: 30rem) { + +h1#main-h1 { + font-size: 2.5rem; +} + +h2#main-h2 { + font-size: 1.5rem; + margin-top: 0.5rem; +} + +h2, .info-block h2 { + font-size: 1.4rem; +} +} + + +/**************************GRID**************************/ + +.info-block { + margin-bottom: 1rem; + flex: 1; + -webkit-flex: 1; + -ms-flex: 1; + padding: 4rem 2.5rem; + word-wrap: break-word; +} + +.full>.info-block.text-adapt { + padding: 4rem 15rem; +} + +.guides .info-block { + word-break:keep-all; +} + +.left.two-thirds, .left.one-third, .left.half, .left.one-fourth, .left.three-fourths { + display: flex; + display: -ms-flexbox; + display: -webkit-flex; + padding-right: 0.5rem; +} + +.right.two-thirds, .right.one-third, .right.half, .right.one-fourth, .right.three-fourths { + display: flex; + display: -ms-flexbox; + display: -webkit-flex; + padding-left: 0.5rem; +} + +.half { + display: flex; + display: -ms-flexbox; + display: -webkit-flex; +} + +.center.one-third, .center-1.one-fourth, .center-2.one-fourth { + display: flex; + display: -ms-flexbox; + display: -webkit-flex; + padding-left: 0.5rem; + padding-right: 0.5rem; +} + +@media only screen and (max-width: 75rem) { + +.info-block { + padding: 3rem 2rem; +} + +.full>.info-block.text-adapt { + padding: 4rem 10rem; +} + +} + +@media only screen and (max-width: 62rem) { + +.info-block { + padding: 2.5rem 1.8rem; +} + +.full>.info-block.text-adapt { + padding: 4rem; +} + +.center.one-fourth, .right.three-fourths, .left.three-fourths, .left.one-fourth.no-pad-sm, .right.one-fourth.no-pad-sm, .right.half, .left.half, .right.one-third, .left.two-thirds, .left.one-third, .right.two-thirds, .center.one-third { + padding-left: 0; padding-right: 0; +} + +.center-1.one-fourth {padding-left: 0.5rem; padding-right: 0;} + +.center-2.one-fourth {padding-right: 0.5rem; padding-left: 0;} + +} + +@media only screen and (max-width: 48rem) { + +.left.two-thirds, .left.one-third, .left.half, .left.one-fourth, .left.three-fourths, .right.two-thirds, .right.one-third, .center.one-third, .center-1.one-fourth, .center-2.one-fourth, .right.half, .right.one-fourth, .right.three-fourths, .full { + padding-left: 0.5rem; + padding-right: 0.5rem; +} + +.info-block { + margin-bottom: 0.5rem; +} + +.full>.info-block.text-adapt { + padding: 2.5rem 1.5rem; +} + +} + +@media only screen and (max-width: 30rem) { + +.info-block, .full>.info-block.text-adapt { + padding: 2rem 1rem; + margin-bottom: 0.5rem; +} + +} + +/*************************BUTTONS****************************/ + +.btn-fixed, .btn-auto { + background: none; + border: 1px solid #ff7519; + text-decoration: none; + text-align: center; + font-family: 'Hind', sans-serif; + font-weight: 700; + color: #ff7519; + text-transform: uppercase; + /*padding: 0.5rem 1rem 0.3rem 1rem;*/ + padding: 0 1rem; + white-space: nowrap; + cursor: pointer; + -webkit-transition: background .15s ease, transform .15s ease, box-shadow .15s ease; + -moz-transition: background .15s ease, transform .15s ease, box-shadow .15s ease; + -o-transition: background .15s ease, transform .15s ease, box-shadow .15s ease; + transition: background .15s ease, transform .15s ease, box-shadow .15s ease; + display: inline-block; + height: 2.6rem; + line-height: 2.7rem; + -moz-box-shadow: 0 1px 5px 0 rgba(0,0,0,.07), 0 7px 17px 0 rgba(0,0,0,.1); + -webkit-box-shadow: 0 1px 5px 0 rgba(0,0,0,.07), 0 7px 17px 0 rgba(0,0,0,.1); + box-shadow: 0 1px 5px 0 rgba(0,0,0,.07), 0 7px 17px 0 rgba(0,0,0,.1); +} + +.btn-fixed:hover, .btn-auto:hover { + -webkit-transform: translate(0, -1px); + -moz-transform: translate(0, -1px); + -ms-transform: translate(0, -1px); + -o-transform: translate(0, -1px); + transform: translate(0, -1px); + -moz-box-shadow: 0 7px 14px rgba(50, 50, 93, .1), 0 3px 6px rgba(0, 0, 0, .08); + -webkit-box-shadow: 0 7px 14px rgba(50, 50, 93, .1), 0 3px 6px rgba(0, 0, 0, .08); + box-shadow: 0 7px 14px rgba(50, 50, 93, .1), 0 3px 6px rgba(0, 0, 0, .08); + border: 1px solid #ff7519; +} + +.btn-fixed:active, .btn-auto:active { + transform: translate(0, 1px); + -moz-box-shadow: 0 4px 6px rgba(50, 50, 93, .11), 0 1px 3px rgba(0, 0, 0, .08); + -webkit-box-shadow: 0 4px 6px rgba(50, 50, 93, .11), 0 1px 3px rgba(0, 0, 0, .08); + box-shadow: 0 4px 6px rgba(50, 50, 93, .11), 0 1px 3px rgba(0, 0, 0, .08); + border: 1px solid #ff7519; +} + +a.btn-link:hover, a.btn-link.active, a.btn-link:focus { + text-decoration: none; + outline: 0; +} + +.btn-link span.icon-windows, .btn-link span.icon-linux, .btn-link span.icon-apple, .btn-link span.icon-blockchain { + height: 2rem; + width: 2rem; + display: inline-block; + margin-right: 0.5rem; + vertical-align: middle; +} + +.btn-link span.icon-windows { + background-image: url(../img/monero-spritesheet.png); + background-position: 0 0; +} + +a.btn-link:hover span.icon-windows, a.btn-link:focus span.icon-windows, a.btn-link.active span.icon-windows { + background-image: url(../img/monero-spritesheet.png); + background-position: -3rem 0; +} + +.btn-link span.icon-linux, span.icon-linux { + background-image: url(../img/monero-spritesheet.png); + background-position: 0 -3rem; +} + +a.btn-link:hover span.icon-linux, a.btn-link:focus span.icon-linux, a.btn-link.active span.icon-linux { + background-image: url(../img/monero-spritesheet.png); + background-position: -3rem -3rem; +} + +.btn-link span.icon-apple { + background-image: url(../img/monero-spritesheet.png); + background-position: 0 -6rem; +} + +a.btn-link:hover span.icon-apple, a.btn-link:focus span.icon-apple, a.btn-link.active span.icon-apple { + background-image: url(../img/monero-spritesheet.png); + background-position: -3rem -6rem; +} + +.btn-link span.icon-blockchain { + background-image: url(../img/monero-spritesheet.png); + background-position: 0 -9rem; +} + +a.btn-link:hover span.icon-blockchain, a.btn-link:focus span.icon-blockchain, a.btn-link.active span.icon-blockchain { + background-image: url(../img/monero-spritesheet.png); + background-position: -3rem -9rem; +} + +.btn-fixed { + width: 15rem; + display: block; +} + +.btn-fixed:hover, .btn-fixed:active, .btn-fixed:focus, .btn-auto:hover, .btn-auto:active, .btn-auto:focus { + background-color: #ff7519; + color: #fff!important; + text-decoration: none; +} + +@media only screen and (max-width: 62rem) { + +.btn-fixed, .btn-auto { + font-size: 0.875rem; +} + +} + +@media only screen and (max-width: 48rem) { + +.btn-fixed, .btn-auto { + font-size: 1rem; +} + +} + +@media only screen and (max-width: 30rem) { +.btn-link span#icon-windows, .btn-link span#icon-linux, .btn-link span#icon-apple, .btn-link span#icon-blockchain { + display: none; +} +} + +/************************NAVIGATION*************************/ + +/*DESKTOP NAVIGATION*/ + +img.monero-logo { + max-width: 100%; + height: auto; + width: 13rem; + padding: 0.8rem 0.8rem 0.8rem 3.4rem; +} + +.topnav .topnav-list a, .topnav .topnav-list label { + color: #7a7a7a; + text-decoration: none; + -webkit-transition: all ease-out .1s; + -moz-transition: all ease-out .1s; + -o-transition: all ease-out .1s; + transition: all ease-out .1s; +} + +/*.topnav .topnav-list .language-change { + position: relative; + display: block; +} + +.topnav .topnav-list .language-change,*/ .topnav .topnav-list .top-link { + padding-top: 0.8rem; + padding-bottom: 0.8rem; + padding-right: 4.5rem; + font-size: 0.9rem; +} + +/*.topnav .topnav-list .language-change:hover { + background-color: #fcfcfc; +} + +.topnav .topnav-list .language-change:hover>.dropdown-content { + opacity: 1; + visibility: visible; +} + +.topnav .topnav-list .language-change label div.arrow-down { + display: inline-block; + margin-bottom: 0.25rem; + margin-left: 0.1rem; + border-top: 3px solid #7a7a7a; + +} + +.topnav .topnav-list .language-change .dropdown-content { + position: absolute; + left: 0; + top: 99.5%; + text-align: left; + background: #fcfcfc; + width: 100%; + -webkit-box-sizing: border-box; + -moz-box-sizing: border-box; + box-sizing: border-box; + opacity: 0; + visibility: hidden; + z-index: 1; + -webkit-transition: all .3s ease; + -moz-transition: all .3s ease; + -ms-transition: all .3s ease; + -o-transition: all .3s ease; + transition: all .3s ease; + +} + +.topnav .topnav-list .language-change .dropdown-content a { + padding: 0.8rem 1rem; +} + +.topnav .topnav-list .language-change .dropdown-content a:hover, .topnav .topnav-list .language-change .dropdown-content a:focus { + text-decoration: none; +} + +.topnav .topnav-list .language-change .dropdown-content a.active { + color: #ff7519; +}*/ + + +.topnav .topnav-list a:hover, .topnav .topnav-list a:focus, .topnav .topnav-list a:active { + color: #ff7519; + text-decoration: underline; +} + +.white-nav { + margin-bottom: 1rem; + line-height: 1; +} + +.white-nav>.nav-items>.nav-item { + width: 20%; +} + +.white-nav>.nav-items>.nav-item.mob {display: none;} + +.nav-items>.nav-item>label, .nav-items>.nav-item>a { + padding: 1.5rem 2rem 1.5rem 3.5rem; + display: block; + color: #4c4c4c; + text-decoration: none; + font-family: 'Hind', sans-serif; + font-size: 1.35rem; + font-weight: 500; + -webkit-transition: all ease-out .2s; + -moz-transition: all ease-out .2s; + -o-transition: all ease-out .2s; + transition: all ease-out .2s; + position: relative; +} + +.nav-items>.nav-item .arrow-down { + -webkit-transition: all ease-out .2s; + -moz-transition: all ease-out .2s; + -o-transition: all ease-out .2s; + transition: all ease-out .2s; +} + +.nav-items>.nav-item>a:last-child { + width: initial; +} + +.desktop-nav .nav-item .arrow-down { + display: inline-block; + margin-left: 0.2rem; + margin-bottom: 0.2rem; +} + +.nav-items>.nav-item>label:hover, .nav-items>.nav-item>a:hover, .nav-items>.nav-item>a:focus, .nav-items>.nav-item>a:active { + color: #ff7519; + text-decoration: none; +} + +.nav-items>.nav-item>label:hover .arrow-down, .nav-items>.nav-item>a:hover .arrow-down, .nav-items>.nav-item>a:focus .arrow-down, .nav-items>.nav-item>a:active .arrow-down { + border-top: 3px solid #ff7519; +} + +/*DROPDOWN MENU*/ + +.white-nav .dropdown { + position: relative; +} + +.white-nav .nav-item .dropdown-content { + position: absolute; + left: 0; + top: 99.5%; + text-align: left; + background: #ffffff; + width: 100%; + -webkit-box-sizing: border-box; + -moz-box-sizing: border-box; + box-sizing: border-box; + -moz-box-shadow: 0 2px 4px rgba(50,50,93,.1); + -webkit-box-shadow: 0 2px 4px rgba(50,50,93,.1); + box-shadow: 0 2px 4px rgba(50,50,93,.1); + opacity: 0; + visibility: hidden; + z-index: 5; + -webkit-transition: all .3s ease; + -moz-transition: all .3s ease; + -ms-transition: all .3s ease; + -o-transition: all .3s ease; + transition: all .3s ease; +} + +.white-nav .nav-item:last-of-type .dropdown-content { + width: 100%; +} + +.dropdown:hover>.dropdown-content { + opacity: 1; + visibility: visible; +} + +.nav-item>.dropdown-content>a { + color: #4c4c4c; + text-decoration: none; + font-family: 'Hind', sans-serif; + font-weight: 500; + font-size: 0.99rem; + padding: 0.8rem 3.4rem 0.8rem 3.5rem; + -webkit-transition: all ease-out .2s; + -moz-transition: all ease-out .2s; + -o-transition: all ease-out .2s; + transition: all ease-out .2s; + line-height: 1.3; + white-space: nowrap; +} + +.nav-item>.dropdown-content>a:hover { + color: #ff7519; + background-color: #fcfcfc; +} + +.dropdown-content a { + display: block; +} + +.burger-check, .burger-checkdropdown { + display: none; +} + +@media only screen and (max-width: 75rem) { + +.topnav .topnav-list .top-link { + padding-right: 4.1rem; + font-size: 0.85rem; +} + +img.monero-logo { + padding-left: 3.1rem; +} + +.nav-items>.nav-item>label, .nav-item>.dropdown-content>a { + padding-left: 2.7rem; +} + +.nav-items>.nav-item>label, .nav-items>.nav-item>a { + font-size: 1.16rem; +} + +.nav-item>.dropdown-content>a { + font-size: 1rem; + padding-right: 2.7rem; +} + +.nav-items>.nav-item:first-of-type>label, .white-nav .nav-item:first-of-type .dropdown-content a { + padding-left: 3.1rem; +} + +.nav-items>.nav-item:last-of-type>label { + padding-right: 0.8rem; +} + + +} + +@media only screen and (max-width: 62rem) { + +.desktop-nav { + display: none; +} + +} + +/*MOBILE NAVIGATION*/ + +.mob-nav { + display:none; +} + +.mob.bot-nav { + display: none; +} + +@media only screen and (max-width: 62rem) { + + +img.monero-logo { + position: inherit; + width: 10rem; + padding: 0.39rem 0 0 0; +} + +.white-nav { + line-height: 0.5; + display: -ms-flexbox; + display: -webkit-box; + display: flex; + -webkit-flex-direction: column; + -ms-flex-direction: column; + flex-direction: column; + border-top: none; + border-right: none; + border-left: none; +} + +.white-nav .nav-items { + line-height: 1; +} + +.white-nav>.nav-items>.nav-item.mob {display: initial;} + +.nav-items { + display: none; +} + +.dropdown-content { + display: none; +} + +.burger { + display: block; + border: 0; + background: none; + outline: 0; + padding: 0; + cursor: pointer; + border-bottom: 2px solid #4c4c4c; + width: 1.5rem; + align-self: flex-end; +} + +.burger::-moz-focus-inner { + border: 0; + padding: 0; +} + +.burger:before { + content: ""; + display: block; + border-bottom: 2px solid #4c4c4c; + width: 100%; + margin-bottom: 5px; + transition: -webkit-transform 0.5s ease-in-out; + transition: transform 0.5s ease-in-out; + transition: transform 0.5s ease-in-out, -webkit-transform 0.5s ease-in-out; + -webkit-transition: -webkit-transform 0.5s ease-in-out; +} + +.burger:after { + content: ""; + display: block; + border-bottom: 2px solid #4c4c4c; + width: 100%; + margin-bottom: 5px; + transition: -webkit-transform 0.5s ease-in-out; + transition: transform 0.5s ease-in-out; + transition: transform 0.5s ease-in-out, -webkit-transform 0.5s ease-in-out; + -webkit-transition: -webkit-transform 0.5s ease-in-out; +} + +.burger-check:checked ~ .burger { + border-bottom: 4px solid transparent; + transition: border-bottom 0.5s ease-in-out; + -webkit-transition: border-bottom 0.5s ease-in-out; +} + +.burger-check:checked ~ .burger:before { + transform: rotate(-405deg) translateY(6px) translateX(-5px); + -webkit-transform: rotate(-405deg) translateY(6px) translateX(-5px); + transition: -webkit-transform 0.5s ease-in-out; + transition: transform 0.5s ease-in-out; + transition: transform 0.5s ease-in-out, -webkit-transform 0.5s ease-in-out; + -webkit-transition: -webkit-transform 0.5s ease-in-out; +} + +.burger-check:checked ~ .burger:after { + transform: rotate(405deg) translateY(0px) translateX(1.3px); + -webkit-transform: rotate(405deg) translateY(0px) translateX(1.3px); + transition: -webkit-transform 0.5s ease-in-out; + transition: transform 0.5s ease-in-out; + transition: transform 0.5s ease-in-out, -webkit-transform 0.5s ease-in-out; + -webkit-transition: -webkit-transform 0.5s ease-in-out; +} + +.burger-check:checked ~ .nav-items{ + display: block; +} + +#drop1:checked ~ .dropdown-content, #drop2:checked ~ .dropdown-content, #drop3:checked ~ .dropdown-content, #drop4:checked ~ .dropdown-content { + display: block; + position: inherit; + opacity: 1; + visibility: visible; + box-shadow: none; +} +.burger-check:checked + label { + position: fixed; +} + +.nav-item > label { + display: -ms-flexbox; + display: -webkit-box; + display: flex; +} + +/*.white-nav .mob-language-change label .arrow-down { + display: inline-block; + margin-left: 0.2rem; + margin-bottom: 0.2rem; + border-top: 3px solid #393939; +}*/ + + +.mob-nav { + display: -ms-flexbox; + display: -webkit-box; + display: flex; +} + +.white-nav { + -moz-box-shadow: 0 2px 2px rgba(0,0,0,.1); + -webkit-box-shadow: 0 2px 2px rgba(0,0,0,.1); + box-shadow: 0 2px 2px rgba(0,0,0,.1); +} + +.slide-in-nav { + position: absolute; + top: 0; right: 0; bottom: 0; left: 0; + display: flex; + right: 200%; + left: -100%; + display: -ms-flexbox; + display: -webkit-box; + display: flex; + top: 0; + bottom: 0; + width: 70vw; + background-color: #fff; + -moz-transition: right 0.5s, left 0.5s; + -webkit-transition: right 0.5s, left 0.5s; + transition: right 0.5s, left 0.5s; + overflow: scroll; + z-index: 10; +} + +.slide-in-nav::-webkit-scrollbar { + display: none; +} + +.mob.bot-nav { + display: block; + position: fixed; + width: 100%; + left: 0; + top: 0; + min-height: 3.5rem; + z-index: 10; +} + +label[for="mobile-burger"] { + position: fixed; + top: 1.3rem; + left: 1rem; + z-index: 11; +} + +#mobile-burger:checked ~ .slide-in-nav { + position: fixed; + -moz-box-shadow: 0 0 900px 900px rgba(0,0,0,0.5); + -webkit-box-shadow: 0 0 900px 900px rgba(0,0,0,0.5); + box-shadow: 0 0 900px 900px rgba(0,0,0,0.5); + right: 0; + left: 0; +} + +#mobile-burger:checked ~ body { + overflow: none; +} + +.slide-in { + padding-top: 3.5rem; + width: 100%; +} + +.slide-in .row label, .slide-in .row a { + border-bottom: 1px solid #d7d7d7; +} + +.mob-nav .nav-item { + position: relative; + text-transform: uppercase; + text-align: left; + font-family: 'Hind', sans-serif; + font-weight: 500; + font-size: 1.125rem; + cursor: pointer; +} + +.mob-nav .nav-item:checked, .mob-nav .nav-item:focus, .mob-nav .nav-item:active { + -webkit-tap-highlight-color: rgba(0,0,0,0); + -webkit-tap-highlight-color: transparent; +} + +.mob-nav .nav-item .arrow-down { + margin-top: 0.8rem; + margin-left: 0.2rem; +} + +.mob-nav .nav-item a, .mob-nav .nav-item label { + padding: 1rem 0 1rem 2rem; +} + +.mob-nav .nav-item>a, .mob-nav .nav-item label, .mob-nav .nav-item .dropdown-content>a, .mob-nav .nav-item .arrow-down { + -webkit-transition: all ease-out .2s; + -moz-transition: all ease-out .2s; + -o-transition: all ease-out .2s; + transition: all ease-out .2s; +} + +.mob-nav .nav-item a { + display: block; +} + +.mob-nav .nav-item a:hover .arrow-down, .mob-nav .nav-item a.active .arrow-down, .mob-nav .nav-item a:focus .arrow-down, .mob-nav .nav-item label:hover .arrow-down, .mob-nav .nav-item label:focus .arrow-down, .mob-nav .nav-item label.active .arrow-down { + border-top: 3px solid #ff7519; +} + +.mob-nav .nav-item label, .mob-nav .nav-item>a { + text-decoration: none; + color: #393939; + cursor: pointer; + height: 1.9rem; + line-height: 2.1rem; +} + +.mob-nav .nav-item>a:hover, .mob-nav .nav-item>a:focus, .mob-nav .nav-item>a:active, .mob-nav .nav-item>a.active, .mob-nav .nav-item label:hover, .mob-nav .nav-item label:focus { + color: #ff7519; +} + + +.mob-nav .nav-item .dropdown-content>a { + text-align: left; + padding: 0.8rem 0rem 0.8rem 3rem; + text-transform: none; + line-height: 1.5rem; + height: 1.5rem; + text-decoration: none; + color: #393939; + cursor: pointer; +} + + +.mob-nav .nav-item>.dropdown-content>a:hover, .mob-nav .nav-item .dropdown-content>a:focus, .mob-nav .nav-item .dropdown-content>a.active { + color: #ff7519; + background-color: #f5f5f5; +} + +#drop1:checked ~ .dropdown-content, #drop2:checked ~ .dropdown-content, #drop3:checked ~ .dropdown-content, #drop4:checked ~ .dropdown-content { + background-color: #fcfcfc; +} + +/*#langdrop:checked ~ .dropdown-content { + position: absolute; + top: 100%; + width: 100vw; + height: 100vh; + display: block; + opacity: 1; + visibility: visible; + box-shadow: none; +}*/ + +} + +@media only screen and (max-width: 48rem) { +.white-nav { + margin-bottom: 0; +} + +.burger-check:checked ~ .nav-items{ + display: block; + height: 100vh; +} + +} + +@media only screen and (max-width: 30rem) { + +img.monero-logo { + width: 9rem; + padding-top: 0.527rem; +} + +.slide-in-nav { + width: 100vw; + left: -110%; +} + +} + + + +/***************************HOME PAGE*****************************/ + +.info-block-main { + padding: 0; +} + +.main-video { + order: 0; +} + +.monero-video { + padding: 4rem 2.5rem; +} + +.monero-video video { + max-width: 100%; + width: 100%; + margin-left: auto; + margin-right: auto; + display: block; +} + + +.main-info { + padding: 4rem 2.5rem 4rem 0; +} + +.main-info p { + padding-top: 1.3rem; +} + +.main-info p#main-text { + display: block; +} + +.main-info p a.btn-auto, a.btn-primary { + background-color: #ff7519; + color: #ffffff; + border: none; + display: inline-block; +} + +.about-main .info-block .col-lg-6.why-text, .about-monero .info-block .col-lg-7.why-text { + padding: 0 2rem; +} + +.about-main .info-block-row, .about-monero .info-block-row { + margin-top: 2rem; +} + +.about-main .info-block-row.private, .about-monero .info-block-row.private { + margin-top: 1.5rem; +} + +.about-main img.main-icon.wide { + width: 100%; +} + +.info-block-row img.main-icon { + width: 50%; + margin: 0 auto; +} + +.about-monero .info-block-row img.main-icon { + width: 60%; + margin: 0 auto; +} + +.about-main .info-block-row .col-lg-8 { + padding-right: 3rem; +} + +p.main-resources { + height: 11rem; +} + +p.main-downloads { + padding-left: 1.9rem; +} + +@media only screen and (max-width: 75rem) { + +.info-block-main { + padding: 0; +} + +.main-info { + padding: 4rem 2rem 4rem 0; +} + +.monero-video { + padding: 4rem 2rem; +} + +.main-info p { + padding-top: 0.5rem; +} + +.about-main .info-block-row, .about-monero .info-block-row { + margin-top: 1.5rem; +} + + +p.main-resources { + height: 12rem; +} + +p.main-downloads { + padding-left: 0.5rem; +} + +} + +@media only screen and (max-width: 62rem) { + +.main-video { + order: 1; + margin-left: auto; + margin-right: auto; + display: block; +} + +.main-info, .main-info h2#main-h2 { + text-align: center; + padding: 0; +} + +.monero-video { + padding: 2.6rem 0 0 0; + } + +.info-block-main { + padding: 2.5rem 1.8rem; +} + +.main-info p { + padding-top: 1rem; +} + +.about-main .info-block-row, .about-monero .info-block-row { + margin-top: 3rem; +} + +.about-main .info-block-row.private, .about-monero .info-block-row.private { + margin-top: 1rem; +} + +.info-block-row img.main-icon { + width: 80%; + margin: 0 auto; +} + +.about-main .info-block-row .col-lg-8 { + padding-right: 1rem; + padding-left: 1rem; +} + +p.main-resources { + height: auto; + text-align: left; +} + +p.main-downloads { + padding-left: 0; +} + +} + +@media only screen and (max-width: 48rem) { + +.monero-video { + padding-top: 2rem; +} + +.about-main .info-block-row, .about-monero .info-block-row { + margin-top: 1.5rem; +} + +.about-main .info-block-row .col-lg-8 { + padding-right: 0; + padding-left: 0; +} + +.about-main .info-block .col-lg-6.why-text, .about-monero .info-block .col-lg-7.why-text { + padding: 0; +} + + +} + +@media only screen and (max-width: 47.9rem) { + +.info-block-row img.main-icon { + width: 40%; +} + +} + +@media only screen and (max-width: 30rem) { + +.main-info p#main-text { + display: none; +} + +.monero-video { + padding-top: 1.5rem;; +} + +.info-block-row img.main-icon { + width: 40%; +} + +} + +/****************************FOOTER***************************/ + + + +body { + height: 100%; +} + +.page-wrapper { + position: relative; + min-height: 100vh; +} + +.site-wrap { + padding-bottom: 435px; + padding-bottom: 27.1875rem; +} + +footer { + position: absolute; + bottom: 0; + width: 100%; + height: 435px; + height: 27.1875rem; + background-color: #4c4c4c; + color: #efefef; + z-index: 1; +} + +footer a.white { + color: #efefef; + text-decoration: none; + -webkit-transition: all ease-out .2s; + -moz-transition: all ease-out .2s; + -o-transition: all ease-out .2s; + transition: all ease-out .2s; + font-size: 0.9375rem; +} + +footer a.white:hover, a.white:focus { + color: #ff7519; + text-decoration: underline; +} + +.footer-wrapper { + padding: 4rem 1rem; + padding-bottom: 0.5rem; +} + +.footer-wrapper ul { + line-height: 1.7; +} + +.footer-links { + margin-bottom: 3rem; +} + +.footer-link { + padding: 0 1rem; +} + +@media only screen and (max-width: 75rem) { + +} + +@media only screen and (max-width: 62rem) { + +.page-wrapper { + position: relative; + min-height: 100vh; +} + +.site-wrap { + padding-bottom: 470px; + padding-bottom: 29.375rem; +} + +footer { + position: absolute; + bottom: 0; + width: 100%; + height: 470px; + height: 29.375rem; + background-color: #4c4c4c; + color: #efefef; + z-index: 1; +} + +} + +@media only screen and (max-width: 48rem) { + +.page-wrapper { + position: initial; + min-height: 100vh; +} + +.site-wrap { + padding-bottom: 0; +} + +footer { + position: initial; + width: 100%; + height: auto; + background-color: #4c4c4c; + color: #efefef; + z-index: 1; +} + +.footer-wrapper { + padding: 2.5rem; +} + +.footer-wrapper div.col-xs-6 { + margin-bottom: 1.5rem; + padding-right: 1rem; +} + +} + +@media only screen and (max-width: 30rem) { + +.footer-wrapper { + padding: 2rem 2rem 0 2rem; +} + +.footer-wrapper div.col-xs-6 { + -ms-flex-preferred-size: 100%; + max-width: 100%; + flex-basis: 100%; + padding-right: 0; +} + +} + +/******************MONEROPEDIA******************/ + +.moneropedia { + margin-bottom: 2rem; +} + +.moneropedia:last-child { + margin-bottom: 3rem; +} + +.moneropedia a { + line-height: 1.7; +} + + + +/*******************************GUIDE STYLING****************************/ + +.guides a{ + display: block; +} + +/******************************DOWNLOADS STYLING***********************/ + +.download-nav.info-block { + display: -ms-flexbox; + display: -webkit-box; + display: flex; +} + +.downloads .full>.info-block.download-nav { + padding: 0; +} + +.downloads .download-nav a { + display: -ms-flexbox; + display: -webkit-box; + display: flex; + padding: 1rem 1.5rem; + font-weight: bold; + -webkit-transition: all ease-out .2s; + -moz-transition: all ease-out .2s; + -o-transition: all ease-out .2s; + transition: all ease-out .2s; +} + +.download-nav a:hover { + background-color: #ff7519; + color: #fff; + text-decoration: none; +} + + +.downloads .full>.info-block { + padding: 4rem 5rem; +} + +#pick-platform { + display: none; +} + +.downloads p.hash { + word-break: break-all; +} + +.download-platforms .col-md-6 { + padding: 0 1rem; +} + +.download-platforms h2 span { + height: 2rem; + width: 2rem; + display: inline-block; + margin-right: 0.5rem; + vertical-align: middle; +} + +.download-platforms h2 span.icon-windows { + background-image: url(../img/monero-spritesheet.png); + background-position: -6rem 0; +} + +.download-platforms h2 span.icon-apple { + background-image: url(../img/monero-spritesheet.png); + background-position: -6rem -6rem; +} + +.download-platforms h2 span.icon-linux{ + background-image: url(../img/monero-spritesheet.png); + background-position: -6rem -3rem; +} + +.download-platforms h2 span.icon-arm { + background-image: url(../img/monero-spritesheet.png); + background-position: 0 -11rem; +} + +.download-platforms h2 span.icon-freebsd { + background-image: url(../img/monero-spritesheet.png); + background-position: 0 -13rem; +} + +.download-platforms h2 span.icon-github { + background-image: url(../img/monero-spritesheet.png); + background-position: 0 -15rem; +} + +.downloads a.arrow-up { + border: 1px solid #ff7519; + border-radius: 50%; + height: 3rem; + width: 3rem; + position: fixed; + bottom: 2rem; + right: 2rem; + background-color: #ffffff; + z-index: 5; +} + +.downloads a.arrow-up:hover, .downloads a.arrow-up:focus { + border: none; + background-color: #ff7519; +} + +.downloads a.arrow-up i { + border: solid #ff7519; + border-width: 0 3px 3px 0; + padding: 0.5rem; + position: absolute; + top: 1.02rem; + left: 0.88rem; + transform: rotate(-135deg); + -webkit-transform: rotate(-135deg); + -webkit-transition: all ease-out .2s; + -moz-transition: all ease-out .2s; + -o-transition: all ease-out .2s; + transition: all ease-out .2s; +} + +.downloads a.arrow-up:hover i, .downloads a.arrow-up:focus i { + border-color: #ffffff; +} + +@media only screen and (max-width: 75rem) { + +.downloads .download-nav a { + font-size: 0.92rem; +} + +.downloads .full>.info-block { + padding: 3rem 2rem; +} + +} + +@media only screen and (max-width: 62rem) { + +.downloads .download-nav a { + padding: 1rem 0.6rem; +} + +.downloads .downdropdown { + display: none; +} + +.download-platforms .col-md-6 { + padding: 0; +} + +#pick-platform { + display: block; +} + +.info-block#pick-platform { + padding: 0; +} + +.mob.dropdowndrop input { + display: none; +} + +.mob.dropdowndrop input:checked ~ ul#menu { + display: block; + transition:max-height 0.5s ease-in; +} + +.mob.dropdowndrop label{ + position: relative; + /*display: block;*/ + padding: 0 1rem 0 1rem; + font-size: 1.125rem; + font-weight: 500; + line-height: 3rem; + cursor: pointer; + color: #4c4c4c; + -webkit-transition: all ease-out .2s; + -moz-transition: all ease-out .2s; + -o-transition: all ease-out .2s; + transition: all ease-out .2s; +} + +.mob.dropdowndrop label:after{ + content: ""; + position: absolute; + display: block; + top: 50%; + right: 0; + width: 0; + height: 0; + border-top: 4px solid #4c4c4c; + border-bottom: 0 solid #4c4c4c; + border-left: 4px solid transparent; + border-right: 4px solid transparent; + transition: border-bottom .1s, border-top .1s .1s; + } + +.mob.dropdowndrop input:checked ~ label { + color: #ff7519; +} + +.mob.dropdowndrop input:hover ~ .mob.dropdowndrop label:after { + border-top: 4px solid #ff7519 !important; + border-bottom: 0 solid #ff7519 !important; + transition: border-top .1s, border-bottom .1s .1s; +} + +.mob.dropdowndrop input:checked ~ label:after{ + border-top: 0 solid #ff7519; + border-bottom: 4px solid #ff7519; + transition: border-top .1s, border-bottom .1s .1s; +} + +.mob.dropdowndrop ul#menu { + display:none; + padding:0; + overflow:hidden; + list-style-type:none; + -moz-box-shadow: 0 2px 4px rgba(50,50,93,.1); + -webkit-box-shadow: 0 2px 4px rgba(50,50,93,.1); + box-shadow: 0 2px 4px rgba(50,50,93,.1); + transition:max-height 0.5s ease-out; + min-width:100%; + text-align: left; + background: #ffffff; + width: 100%; + margin: 0; +} + +.mob.dropdowndrop ul#menu li a { + display: block; + color: #4c4c4c; + text-decoration: none; + font-family: 'Hind', sans-serif; + font-weight: 500; + font-size: 1.125rem; + padding: 0.8rem 1rem; + -webkit-transition: all ease-out .2s; + -moz-transition: all ease-out .2s; + -o-transition: all ease-out .2s; + transition: all ease-out .2s; + text-align: center; +} + +.mob.dropdowndrop ul#menu li a:hover { + color: #ff7519; + background-color: #fcfcfc; +} + +.downloads .full>.info-block { + padding: 2.5rem 1.8rem; +} + +} + + +/***************************MERCHANTS STYLING***********************************/ + +.merchants a { + color: #4c4c4c; + margin-top: 0.4rem; + margin-bottom: 0.4rem; + display: inline-block; + padding-right: 1rem; +} + +.merchants a:hover, .merchants a.active, .merchants a:focus { + color: #ff7519; +} + +@media only screen and (max-width: 48rem) { + +.merchants a { + color: #ff7519; +} + +} + + +/***************************ROADMAP STYLING*********************************/ + +.roadmap .completed { + background: #4c4c4c; + border: 1px solid #4c4c4c; + border-radius: 50px; +} + +.roadmap .ongoing { + background: #ff7519; + border: 1px solid #ff7519; + border-radius: 50%; +} + +.roadmap .upcoming { + background: #fff; + border: 1px solid black; + border-radius: 50%; +} + +.roadmap .tabPanel-content span { + width: 1.5rem; + height: 1.5rem; + text-align: center; + border-radius: 1rem; + display: block; + color: white; + margin-right: 1rem; + position: relative; + z-index: 5; +} + +.roadmap span:first-child { + margin-top: 0; +} + +.roadmap .tabPanel-content .row { + margin-bottom: 1.5rem; +} + +.pre-roadmap li { + width: 1.5rem; + height: 1.5rem; + text-align: center; + border-radius: 1rem; + margin: 0 1rem; + display: inline-block; + color: white; + position: relative; +} + +.tabPanel-widget { + position: relative; +} + +.tabPanel-widget > label { + position: absolute; + z-index: 1; +} + +.tabPanel-widget > label:focus { + outline: 0; +} + +.tabPanel-widget > label, +.tabPanel-widget > h2 { + font-size: 1.1rem; + width: 20%; + height: 2rem; + line-height: 2rem; + padding: 1rem 0; +} + +.tabPanel-widget > h2 { + position: relative; + margin: 0; + text-align: center; + background: #ffffff; + color: #ff7519; + -moz-box-shadow: 0 1px 0px rgba(50,50,93,.1); + -webkit-box-shadow: 0 1px 0px rgba(50,50,93,.1); + box-shadow: 0 1px 0px rgba(50,50,93,.1); +} + +.tabPanel-widget input, +.tabPanel-widget > label ~ label, +.tabPanel-widget > h2 ~ h2 { + position: absolute; + top: 0; +} + +.tabPanel-widget label:nth-child(1), +.tabPanel-widget h2:nth-child(3) { + left: 0; +} + +.tabPanel-widget label:nth-child(5), +.tabPanel-widget h2:nth-child(7) { + left: 20%; +} + +.tabPanel-widget label:nth-child(9), +.tabPanel-widget h2:nth-child(11) { + left: 40%; +} + +.tabPanel-widget label:nth-child(13), +.tabPanel-widget h2:nth-child(15) { + right: 20%; +} + +.tabPanel-widget label:nth-child(17), +.tabPanel-widget h2:nth-child(19) { + right: 0; +} + +.tabPanel-widget input + h2 + div.tabPanel-content { + position: absolute; + clip: rect(1px, 1px, 1px, 1px); + border:0; + height: 1px; + width: 1px; + overflow: hidden; + padding: 4rem 4.5rem; +} + +.roadmap .tabPanel-widget > div.tabPanel-content, .ffs .tabPanel-widget > div.tabPanel-content { + background-color: #ffffff; + -moz-box-shadow: 0 2px 4px rgba(50,50,93,.1); + -webkit-box-shadow: 0 2px 4px rgba(50,50,93,.1); + box-shadow: 0 2px 4px rgba(50,50,93,.1); + margin: 1rem 0; +} + +.tabPanel-widget input:checked + h2 + div.tabPanel-content { + position: static; + height: auto; + width: auto; +} + +.tabPanel-widget label:hover{ + cursor: pointer; +} + +.tabPanel-widget input[name="tabs"] { + opacity: 0; + position: absolute; +} + +.tabPanel-widget input[name="tabs"]:checked + h2 { + background: #ff7519; + color: #ffffff; +} + +.tabPanel-widget input[name="tabs"] +h2:after { + +} + +.tabPanel-widget input[name="tabs"]:checked + h2:after { + content: ''; + margin: auto; + position: absolute; + bottom: -9px; + left: 0; + right: 0; + width: 0; + height: 0; + border-left: 10px solid transparent; + border-right: 10px solid transparent; + border-top: 10px solid #ff7519; +} + +.roadmap .tabPanel-widget > div.tabPanel-content p { + padding: 0; +} + +@media only screen and (max-width: 75rem) { + +.tabPanel-widget input + h2 + div.tabPanel-content { + padding: 4rem; +} + +} + +@media only screen and (max-width: 62rem) { + +.tabPanel-widget input + h2 + div.tabPanel-content { + padding: 2.5rem; +} + +} + +@media only screen and (max-width: 48rem) { + .roadmap .mobile-roadmap { + height: 2rem; +} + + +.tabPanel-widget { + margin-left: 0.5rem; + margin-right: 0.5rem; +} + +.tabPanel-widget label, +.tabPanel-widget input[name="tabs"] { + display: none; +} + +.tabPanel-widget > div.tabPanel-content { + margin-top: 0; +} + +.tabPanel-widget > input + h2 + div.tabPanel-content { + display: block; + position: static; + height: auto; + width: auto; + padding: 2rem; +} + +.roadmap .tabPanel-widget > div.tabPanel-content { + margin: 0.5rem 0; +} + +.tabPanel-widget > div.tabPanel-content p { + padding-left: 1rem; +} + +.tabPanel-widget h2 { + width: 100%; + position: static !important; + padding: 1.5rem 0; + font-size: 1.5625rem; +} + +.tabPanel-widget input[name="tabs"]:checked + h2:after { + display: none; +} + +.tabPanel-widget input[name="tabs"]:checked + h2, .tabPanel-widget > h2 { + background: #ffffff; + color: #4c4c4c; +} + +.roadmap .tabPanel-content .row:last-of-type { + margin-bottom: 0; +} + +.pre-roadmap p { + padding-top: 0; +} + +.roadmap .tabPanel-content span, .pre-roadmap li { + width: 1rem; + height: 1rem; +} + +} + +@media only screen and (max-width: 30rem) { + +.tabPanel-widget > div.tabPanel-content p { + padding-left: 1.5rem; +} + +.tabPanel-widget h2 { + font-size: 1.4rem; +} + +.roadmap .tabPanel-widget > input + h2 + div.tabPanel-content { + padding: 2rem 1.5rem; +} + +.tabPanel-widget h2 { + padding-top: 2rem; +} + +.roadmap .tabPanel-widget div.tabPanel-content .col-xs-1 { + -ms-flex-preferred-size: 16.667%; + flex-basis: 16.667%; + max-width: 16.667%; +} + +.roadmap .tabPanel-widget div.tabPanel-content .col-xs-11 { + -ms-flex-preferred-size: 83.333%; + flex-basis: 83.333%; + max-width: 83.333%; +} + +.pre-roadmap p { + font-size: 0.9rem; +} + +} + +/***********************************TEAM PAGE***********************************/ + + +.team .tabPanel-widget input + h2 + div.tabPanel-content { + padding: 1rem 0 0 0; +} + +.team .tabPanel-widget div.tabPanel-content .half:nth-child(even) { + padding-left: 0.5rem; + padding-right: 0; +} + +.team .tabPanel-widget div.tabPanel-content .half:nth-child(odd) { + padding-right: 0.5rem; + padding-left: 0; +} + +@media only screen and (max-width: 48rem) { + + +.team .tabPanel-widget input + h2 + div.tabPanel-content { + padding: 0.5rem 0 0 0; +} + +.team .tabPanel-widget div.tabPanel-content .full { + padding: 0; +} + +.team .tabPanel-widget div.tabPanel-content .half:nth-child(even) { + padding-left: 0.25rem; + padding-right: 0; +} + +.team .tabPanel-widget div.tabPanel-content .half:nth-child(odd) { + padding-right: 0.25rem; + padding-left: 0; +} + +.team .tabPanel-widget div.tabPanel-content .full { + padding-left: 0; + padding-right: 0; +} + +.team .tabPanel-widget > div.tabPanel-content p { + padding-left: 0; +} + +} + +@media only screen and (max-width: 41rem) { + +.team .tabPanel-widget > div.tabPanel-content .half.col-xs-6 { + -ms-flex-preferred-size: 100%; + flex-basis: 100%; + max-width: 100%; +} + +.team .tabPanel-widget div.tabPanel-content .half:nth-child(even), .team .tabPanel-widget div.tabPanel-content .half:nth-child(odd) { + padding-left: 0; + padding-right: 0; +} + +} + + +/***********************************POST STYLING********************************/ + +.post .info-block { + word-break: break-word; +} + +.post .info-block p, .post .info-block h2 { + text-align: left; +} + +.post h3, .post h3:first-of-type { + margin-top: 1rem; + /*margin-bottom: 0.5rem;*/ + margin-bottom: 0; +} + +.page-numbers { + margin-top: 2.7rem; +} + +@media only screen and (max-width: 75rem) { +.page-numbers { + margin-top: 2rem; +} +} + +@media only screen and (max-width: 62rem) { +.page-numbers { + margin-top: 1.7rem; +} +} + +@media only screen and (max-width: 48rem) { + +} + +@media only screen and (max-width: 30rem) { + +} + + +/* Hangouts Styling */ + +.hangouts ul { + list-style: none; + padding: 0; +} + +.hangouts ul li { + +} + +.hangouts .social-icon { + -moz-box-shadow: 0 2px 2px 0 rgba(0,0,0,0.14), 0 3px 1px -2px rgba(0,0,0,0.12), 0 1px 5px 0 rgba(0,0,0,0.2); + -webkit-box-shadow: 0 2px 2px 0 rgba(0,0,0,0.14), 0 3px 1px -2px rgba(0,0,0,0.12), 0 1px 5px 0 rgba(0,0,0,0.2); + box-shadow: 0 2px 2px 0 rgba(0,0,0,0.14), 0 3px 1px -2px rgba(0,0,0,0.12), 0 1px 5px 0 rgba(0,0,0,0.2); + height: 2.7rem; + width: 2.7rem; + margin: 0 1rem; + border-radius: 50%; +} + +.hangouts .social-icon.twitter { + background-image: url(../img/monero-spritesheet.png); + background-position: -8rem -3rem; +} + +.hangouts .social-icon.twitter:hover { + background-image: url(../img/monero-spritesheet.png); + background-position: -11rem -3rem; +} + +.hangouts .social-icon.reddit { + background-image: url(../img/monero-spritesheet.png); + background-position: -8rem -6rem; +} + +.hangouts .social-icon.reddit:hover { + background-image: url(../img/monero-spritesheet.png); + background-position: -11rem -6rem; +} + +.hangouts .social-icon.facebook { + background-image: url(../img/monero-spritesheet.png); + background-position: -8rem 0; +} + +.hangouts .social-icon.facebook:hover { + background-image: url(../img/monero-spritesheet.png); + background-position: -11rem 0; +} + +.hangouts .social-icon.github { + background-image: url(../img/monero-spritesheet.png); + background-position: -8rem -9rem; +} + +.hangouts .social-icon.github:hover { + background-image: url(../img/monero-spritesheet.png); + background-position: -11rem -9rem; +} + +.hangouts .irc .col-md-4 { + padding: 0 0.5rem; +} + +.hangouts .irc a { + margin-bottom: 1rem; +} + +.hangouts .sequestions a { + margin: 0 0 1rem 0; + line-height: 1.7; +} + +.hangouts .sequestions a:last-child { + margin-bottom: 1.5rem; +} + +.hangouts .relays .btn-fixed { + width: 8rem; + margin-left: auto; + margin-right: auto; +} + +@media only screen and (max-width: 75rem) { + +} + +@media only screen and (max-width: 62rem) { + +.hangouts .irc .col-md-4 { + padding: 0; +} + +} + +@media only screen and (max-width: 35rem) { + +.hangouts .relays { + -webkit-flex-flow: column; + flex-flow: column; + align-items: center; +} + +.hangouts .relays .col-xs-4 { + max-width: 100%; +} + +} + +/***************************SPONSORS*****************************/ + +.sponsors img { + width: 100%; +} + +.sponsors .info-block h2, .merchants .info-block h2, .info-block.research-paper h2 { + padding-bottom: 1rem; +} + +/***************************CONTRIBUTE***************************/ + +.contribute ol { + padding-left: 1rem; + margin: 0; +} + +/**************************MONERO PROJECT***********************/ + +.monero-project p { + height: 13rem; +} + +@media only screen and (max-width: 75rem) { + +.monero-project p { + height: 12rem; +} + +} + +@media only screen and (max-width: 62rem) { +.monero-project p { + height: auto; +} + +} + + +/**************************WHAT IS MONERO*************************/ + +.monero-vid .col-md-6 { + padding: 1rem 1.5rem; +} + +/*CAROUSEL*/ + + +.carousel { + height: 38rem; + overflow: hidden; + text-align: center; + position: relative; + padding: 0; + list-style: none; + margin: 0; +} + +.carousel-controls, +.carousel-activator { + display: none; +} + +.carousel-slide { + opacity: 0; + z-index: -1; + height: 100%; + position: absolute; + padding: 0 3rem; + overflow: hidden; + -webkit-transition: opacity ease-out .3s; + -moz-transition: opacity ease-out .3s; + -o-transition: opacity ease-out .3s; + transition: opacity ease-out .3s; +} + +.carousel-activator:nth-of-type(1):checked ~ .carousel-controls:nth-of-type(1), .carousel-activator:nth-of-type(2):checked ~ .carousel-controls:nth-of-type(2), .carousel-activator:nth-of-type(3):checked ~ .carousel-controls:nth-of-type(3), .carousel-activator:nth-of-type(4):checked ~ .carousel-controls:nth-of-type(4) { + display: block; +} + + +.carousel-activator:nth-of-type(1):checked ~ .carousel-slide:nth-of-type(1), .carousel-activator:nth-of-type(2):checked ~ .carousel-slide:nth-of-type(2), .carousel-activator:nth-of-type(3):checked ~ .carousel-slide:nth-of-type(3), .carousel-activator:nth-of-type(4):checked ~ .carousel-slide:nth-of-type(4) { + z-index: 2; + opacity: 1; +} + +.carousel-control { + height: 2rem; + width: 2rem; + margin-top: -1rem; + top: 50%; + position: absolute; + display: block; + cursor: pointer; + border-width: 5px 5px 0 0; + border-style: solid; + border-color: #4c4c4c; + opacity: 0.35; + outline: 0; + z-index: 3; +} +.carousel-control:hover { + opacity: 1; +} +.carousel-control-backward { + left: 0.8rem; + -webkit-transform: rotate(-135deg); + transform: rotate(-135deg); +} +.carousel-control-forward { + right: 0.8rem; + -webkit-transform: rotate(45deg); + transform: rotate(45deg); +} + + +@-webkit-keyframes carousel-show-slide { + from { + opacity: 0; + } + to { + opacity: 1; + } +} +@keyframes carousel-show-slide { + from { + opacity: 0; + } + to { + opacity: 1; + } +} + +.carousel video { + margin-top: 1rem; +} + +.carousel h3 { + text-align: left; +} + +@supports (-ms-ime-align:auto) { + +.carousel-slide.ms { + width: 91%; +} + +@media only screen and (max-width: 75rem) { + +.carousel-slide.ms { + width: auto; +} + + +} + +} + + +@media only screen and (max-width: 75rem) { + +.carousel { + height: 33rem; +} + +} + +@media only screen and (max-width: 62rem) { + +.carousel { + height: 24rem; +} + +.about-monero .info-block-row img.main-icon { + width: 100%; +} + +} + +@media only screen and (max-width: 48rem) { +.monero-vid .col-md-6 { + padding: 1rem; +} + +.carousel-control { + height: 1.5rem; + width: 1.5rem; +} + +.about-monero .info-block-row img.main-icon { + width: 40%; +} + +} + +@media only screen and (max-width: 42rem) { + +.carousel { height: 22rem;} + +.carousel-control { + margin-top: 0; +} + +} + +@media only screen and (max-width: 37rem) { + +.carousel { height: 18rem;} + +.carousel-control { + height: 1rem; + width: 1rem; +} + +} + +@media only screen and (max-width: 34rem) { + +.carousel { height: 16rem; } + +.carousel-slide { + padding: 0 2.5rem; +} + +} + +@media only screen and (max-width: 30rem) { +.monero-vid .col-md-6 { + padding: 1rem 0; +} + +} + +@media only screen and (max-width: 26rem) { + +.carousel { + height: auto; + position: static; +} + +.carousel-activator:nth-of-type(1):checked ~ .carousel-controls:nth-of-type(1), .carousel-activator:nth-of-type(2):checked ~ .carousel-controls:nth-of-type(2), .carousel-activator:nth-of-type(3):checked ~ .carousel-controls:nth-of-type(3), .carousel-activator:nth-of-type(4):checked ~ .carousel-controls:nth-of-type(4) { + display: none; +} + +.carousel-slide { + position: static; + opacity: 1; + padding: 0; +} + +.carousel video { + margin-top: 0.5rem; +} + +} + +/*********************FORUM FUNDING SYSTEM*************************/ + +.ffs .mobile { + display: none; +} + +.ffs .tabPanel-content a { + display: block; +} + +.ideas .half:nth-child(even) { + padding-left: 0.5rem; + padding-right: 0; +} + +.ideas .half:nth-child(odd) { + padding-right: 0.5rem; + padding-left: 0; +} + +.ffs-breadcrumbs p { + padding-top: 0; + padding-bottom: 1rem; + font-size: 0.85rem; +} + +.ffs-backlink p { + text-align: left; + padding-top: 0; + padding-bottom: 1rem; + font-size: 0.85rem; + margin-top: -2rem; +} + +.ffs-backlink p:before { + content: '\003c'; +} + +.ffs-status { + color: #2f6f9f; + padding: 0.7rem; + border-radius: 0.2rem; + margin-top: 1rem; +} + +.ffs-status p { + white-space: pre-wrap; + padding: 0.2rem; + border-radius: 0.2rem; + font-size: 0.85rem; +} + +.ffs-status.complete { + background-color: #d7e8d8; +} + +.ffs-status.inprogress { + background-color: #fef2d5; +} + + +@media only screen and (max-width: 75rem) { + +} + +@media only screen and (max-width: 62rem) { + .ffs .desktop { + display: none; + } + + .ffs .mobile { + display: block; + } + + .ffs .mobile .ffs-btn-wrap { + padding: 0.5rem; + } + + .ffs .mobile a.ffs-btn { + display: block; + padding: 2.5rem 0.5rem; + color: #fff; + box-shadow: 0 1px 5px 0 rgba(0,0,0,.07), 0 7px 17px 0 rgba(0,0,0,.1); + -moz-box-shadow: 0 0 2px rgba(0,0,0,0.12), 0 2px 2px rgba(0,0,0,0.24); + -webkit-box-shadow: 0 0 2px rgba(0,0,0,0.12), 0 2px 2px rgba(0,0,0,0.24); + box-shadow: 0 0 2px rgba(0,0,0,0.12), 0 2px 2px rgba(0,0,0,0.24); + text-align: center; + transition: all .15s ease; + font-size: 1.5625rem; + font-weight: 700; + font-family: 'Hind', sans-serif; + } + + .ffs .mobile a.ffs-btn:hover { + text-decoration: none; + } + + .ffs-btn:active{ + transform: translateY(1px); + -moz-box-shadow: 0 4px 6px rgba(50, 50, 93, .11), 0 1px 3px rgba(0, 0, 0, .08); + -webkit-box-shadow: 0 4px 6px rgba(50, 50, 93, .11), 0 1px 3px rgba(0, 0, 0, .08); + box-shadow: 0 4px 6px rgba(50, 50, 93, .11), 0 1px 3px rgba(0, 0, 0, .08); + } + + .ffs .mobile a#ffs-ideas { + background-color: #74a3bc; + } + + .ffs .mobile a#ffs-opentasks { + background-color: #e98d4f; + } + + .ffs .mobile a#ffs-fundingrequired { + background-color: #d95a5a; + } + + .ffs .mobile a#ffs-workinprogress { + background-color: #f7d859; + } + + .ffs .mobile a#ffs-completedproposals { + background-color: #61a863; + } +} + +@media only screen and (max-width: 48rem) { +.ffs .mobile .info-block a { + display: block; + padding: 2rem 1rem; +} + +.container.ideas { + padding: 0 0.5rem; +} + +.ideas .half:nth-child(even) { + padding-left: 0.25rem; + padding-right: 0; +} + +.ideas .half:nth-child(odd) { + padding-right: 0.25rem; + padding-left: 0; +} + +.ffs-breadcrumbs, .ffs-backlink { + display: none; +} + +} + +@media only screen and (max-width: 41rem) { + +.ideas .half.col-xs-6 { + -ms-flex-preferred-size: 100%; + flex-basis: 100%; + max-width: 100%; +} + +.ideas .half:nth-child(even), .ideas .half:nth-child(odd) { + padding: 0; +} + +} + +@media only screen and (max-width: 30rem) { + + .ffs .mobile a.ffs-btn { + font-size: 1.25rem; + } +} + +@media only screen and (max-width: 25rem) { + + .ffs .mobile .col-xs-6 { + -ms-flex-preferred-size: 100%; + max-width: 100%; + flex-basis: 100%; + } + + .ffs .mobile .ffs-btn-wrap { + padding: 0.25rem 0.5rem; + } + + .ffs .mobile a.ffs-btn { + padding: 1.5rem 0.5rem; + } +} + +/*************************ACCORDIAN********************************/ + +.tab { + position: relative; + width: 100%; + color: #4c4c4c; + overflow: hidden; + border-top: 1px solid #d7d7d7; +} + +.tab:last-of-type { + border-bottom: 1px solid #d7d7d7; +} +input.accordian { + position: absolute; + display: none; + z-index: -1; +} +label.accordian { + position: relative; + display: block; + padding: 1rem 2rem 1rem 0; + font-weight: bold; + line-height: 1.7; + cursor: pointer; + margin-right: 0.5rem; +} + +.tab-content { + max-height: 0; + overflow: hidden; + border-radius: 3px; + -webkit-transition: max-height 0.3s; + -o-transition: max-height 0.3s; + transition: max-height 0.3s; +} + +.tab-content p { + margin: 0 1rem 1rem 1rem; +} + +input.accordian:checked ~ .tab-content { + max-height: 100rem; + overflow: visible; +} + +label.accordian::after { + margin-right: 0; + content: ""; + position: absolute; + display: block; + top: 50%; + right: 0; + width: 0; + height: 0; + border-top: 4px solid #4c4c4c; + border-bottom: 0 solid #4c4c4c; + border-left: 4px solid transparent; + border-right: 4px solid transparent; + -webkit-transition: border-bottom .1s, border-top .1s .1s; + -o-transition: border-bottom .1s, border-top .1s .1s; + transition: border-bottom .1s, border-top .1s .1s; +} + +input.accordian[type=checkbox]:checked + label::after { + transform: rotateX(180deg); +} +input.accordian[type=radio]:checked + label::after { + transform: rotateX(180deg); +} + +/*********************TOOLTIPS********************/ + +[data-tooltip] { + position: relative; + z-index: 2; + cursor: pointer; +} + +[data-tooltip]:before, +[data-tooltip]:after { + visibility: hidden; + -ms-filter: "progid:DXImageTransform.Microsoft.Alpha(Opacity=0)"; + filter: progid: DXImageTransform.Microsoft.Alpha(Opacity=0); + opacity: 0; + pointer-events: none; +} + +[data-tooltip]:before { + position: absolute; + bottom: 150%; + left: 50%; + margin-bottom: 5px; + margin-left: -80px; + padding: 7px; + width: 160px; + -webkit-border-radius: 3px; + -moz-border-radius: 3px; + border-radius: 3px; + background-color: #000; + background-color: hsla(0, 0%, 20%, 0.9); + color: #fff; + content: attr(data-tooltip); + text-align: center; + font-size: 14px; + line-height: 1.2; +} + +[data-tooltip]:after { + position: absolute; + bottom: 150%; + left: 50%; + margin-left: -5px; + width: 0; + border-top: 5px solid #000; + border-top: 5px solid hsla(0, 0%, 20%, 0.9); + border-right: 5px solid transparent; + border-left: 5px solid transparent; + content: " "; + font-size: 0; + line-height: 0; +} + +[data-tooltip]:hover:before, +[data-tooltip]:hover:after { + visibility: visible; + -ms-filter: "progid:DXImageTransform.Microsoft.Alpha(Opacity=100)"; + filter: progid: DXImageTransform.Microsoft.Alpha(Opacity=100); + opacity: 1; +} + +@media only screen and (max-width: 48rem) { + +.tab-content p { + margin: 1rem 0; +} + +} + + + + + + + + diff --git a/design-goals/index.md b/design-goals/index.md new file mode 100644 index 00000000..6ba08923 --- /dev/null +++ b/design-goals/index.md @@ -0,0 +1,18 @@ +--- +layout: default +title: "Design and Development Goals" +title-pre-kick: "Design and Development " +title-kick: "Goals" +title-post-kick: "" +kick-class: "red-kicks" +--- + +### Development Goals + +{:.goal-images} +![Development Goals](//static.getmonero.org/images/goals/development.jpg) + +### Research Goals + +{:.goal-images} +![Research Goals](//static.getmonero.org/images/goals/research.jpg) diff --git a/downloads/hashes.txt b/downloads/hashes.txt new file mode 100644 index 00000000..ed9dd72d --- /dev/null +++ b/downloads/hashes.txt @@ -0,0 +1,35 @@ +-----BEGIN PGP SIGNED MESSAGE----- +Hash: SHA256 + +This GPG-signed message exists to confirm the SHA256 sums on Monero binaries. + +Please verify the signature against the signature for fluffypony in the +source code repository (/utils/gpg_keys). + +2fbda6f6b1051053703e40cf77b6c6e11334509ad03a3c22d89b6bcb05615910 monero-win-x64-v0.10.3.1.zip +da628a45adfcb8be44df06ac904711d644d608c4eb6479a5d256062a5f6d74de monero-win-x86-v0.10.3.1.zip +fd17d55a8c9e901ff4064c39d9e14786cdd077aff9b3bb556e60d3a5e322050c monero-mac-x64-v0.10.3.1.tar.bz2 +8db80f8cc4f80d4106db807432828df730a59eac78972ea81652aa6b9bac04ad monero-linux-x64-v0.10.3.1.tar.bz2 +abc99f3928f4083bd1a380a869253e07bee9950e0aeb6388e9493bc0f0ec3f53 monero-linux-x86-v0.10.3.1.tar.bz2 +451f65e4846b92d54859e22a5d92124557b397b4208d8752d5289d0262573c3c monero-linux-armv8-v0.10.3.1.tar.bz2 +8473fa20e0db4a3d3e46120cdf92c55be6a159478c511e21f7b77aa05d6c1910 monero-linux-armv7-v0.10.3.1.tar.bz2 +4c66a76752e18ae70b5fb1c728f0d2780eb129a6c8c7d0dee7ba02e05d91efae monero-freebsd-x64-v0.10.3.1.tar.bz2 +c25c0f603ca5c96cb5963aaa2905edff390b7a97f654106911ffad8639deee7c monero-dragonflybsd-x64-v0.10.3.1.tar.bz2 + +0eddd423f5f0df236303d8b9225842142b331093eb69e6183f3f694238c371a7 monero-gui-win-x64-v0.10.3.1.zip +c80ca68037158216a080e59e90b0a70761cff2f317d3c9cd0eeb661e8e2a1f99 monero-gui-mac-x64-v0.10.3.1.tar.bz2 +4915473265d58720fd8f019e536c2b7fb02648ab51a8087e84aa1e2434788452 monero-gui-linux-x64-v0.10.3.1.tar.bz2 +092b49080c3380666845f7f39823b09f4960ea1e250b84b150856ef33ca30690 monero-gui-linux-x86-v0.10.3.1.tar.bz2 + +Riccardo "fluffypony" Spagni +-----BEGIN PGP SIGNATURE----- +Version: GnuPG v2 + +iQEcBAEBCAAGBQJY3APJAAoJEFVDLfMczU/NNN0H/RQK53LnfBk9rURbxBXRgPcD +Njv81hYc/rzGLgeQmxDf6Ug0qivaM7jFkd3aLkT3VZtid0tZWvygg6DnEg9QdSUi +xw9lndyxdeMmW3kbq4uT5n2RB+hx1T7QbXjgHX3+8KAl0G5AyVdVWGmdb/nk7Lwj +Y9XJdK6WtbENYQ65YX8Y/s6QHgT4SUM136sdnFfZVCirX8J0YJKGsMWGDaX16L6O +otNMimhnwP0zTO8bNm+Hvl4v8+hmizJRK3kxpQdI4lWJZxX4iOSzFDlqc7gYBOR+ +1RnH28fFu/XTLm6F+2JVjtHy4JIJiFV9oYDcY7tJoJtAu+4hZs/mc2wew1pVVtM= +=Ykcx +-----END PGP SIGNATURE----- \ No newline at end of file diff --git a/downloads/index.md b/downloads/index.md new file mode 100644 index 00000000..dfe991c3 --- /dev/null +++ b/downloads/index.md @@ -0,0 +1,138 @@ +--- +layout: custom +title: "Downloads" +--- + +
+ +
+ +If you need help choosing the correct application, please click [here](#) for a quick user-guide, then select the appropriate release for your operating system below. +Note: the SHA256 hashes are listed by the downloads for convenience, but a GPG-signed list of the hashes is at [getmonero.org/downloads/hashes.txt](https://getmonero.org/downloads/hashes.txt) and should be treated as canonical, with the signature checked against the appropriate GPG key in the source code (in /utils/gpg_keys). + +
+
+ +
+ +
+
+
+ + + +
+
+
+ + +
+ +{% for data_downloads in site.data.downloads %} + +
+
+

+ {% if data_downloads.icon != null %} + + {% endif %} + {{data_downloads.platform}} +

+ {% if data_downloads.version != null %} +

Current Version: {{ data_downloads.version }} {{ data_downloads.tag }}

+ {%endif%} + + + +{% if data_downloads.cli_hash == "source" %} +
+
+

+ Source Code +

+
+
+If you'd prefer to use a blockchain bootstrap, instead of syncing from scratch, you can [use this link for the most current bootstrap](https:////downloads.getmonero.org/blockchain.raw). It is typically much faster to sync from scratch, however, and it also takes a lot less RAM (import is very greedy). +
+
+{% elsif data_downloads.id == "hardware" %} +
+
+

There are currently no hardware wallets available at this time. Please check back for updates.

+
+ +{% elsif data_downloads.id == "mobilelight" %} +
+
+

The following are mobile or light wallets that are deemed safe by trusted members of the community. If there is a wallet that is not on here, you can request the community check it out. Go to our Hangouts page to see where we are.

+
+
+ + +{% elsif data_downloads.gui_hash == nil and data_downloads.cli_hash != nil %} +

+ {{ data_downloads.platform }} (Command-line Tools Only) +

+
+

SHA256 Hash:

{{ data_downloads.cli_hash }}

+
+{% elsif data_downloads.gui_hash != nil and data_downloads.cli_hash == nil %} +
+ +

+ {{ data_downloads.platform }} (GUI Beta 2) +

+
+

SHA256 Hash:

{{ data_downloads.gui_hash }}

+
+{% elsif data_downloads.gui_hash != nil and data_downloads.cli_hash != nil %} +
+
+ +

+ {{ data_downloads.platform }} (GUI Beta 2) +

+

SHA256 Hash (GUI):

{{ data_downloads.gui_hash }}

+ +
+ +
+

+ {{ data_downloads.platform }} (Command-Line Tools Only) +

+

SHA256 Hash (CLI):

{{ data_downloads.cli_hash }}

+
+
+{% endif %} +
+
+ +{% endfor %} + +
+ + +
+ + + diff --git a/feed.xml b/feed.xml new file mode 100644 index 00000000..0c0b2970 --- /dev/null +++ b/feed.xml @@ -0,0 +1,27 @@ +--- +--- + + + + {{ site.name | xml_escape }} + {% if site.description %}{{ site.description | xml_escape }}{% endif %} + {{ site.url }} + + {% for post in site.posts limit:10 %} + + {{ post.title | xml_escape }} + {% if post.author.name %} + {{ post.author.name | xml_escape }} + {% endif %} + {% if post.summary %} + {{ post.summary | xml_escape }} + {% else %} + {{ post.content | xml_escape }} + {% endif %} + {{ post.date | date: "%a, %d %b %Y %H:%M:%S %z" }} + {{ site.url }}{{ post.url }} + {{ site.url }}{{ post.url }} + + {% endfor %} + + \ No newline at end of file diff --git a/fonts/Hind-500.eot b/fonts/Hind-500.eot new file mode 100644 index 00000000..c3de46a3 Binary files /dev/null and b/fonts/Hind-500.eot differ diff --git a/fonts/Hind-500.svg b/fonts/Hind-500.svg new file mode 100644 index 00000000..872c213b --- /dev/null +++ b/fonts/Hind-500.svg @@ -0,0 +1,296 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/fonts/Hind-500.ttf b/fonts/Hind-500.ttf new file mode 100644 index 00000000..910451ad Binary files /dev/null and b/fonts/Hind-500.ttf differ diff --git a/fonts/Hind-500.woff b/fonts/Hind-500.woff new file mode 100644 index 00000000..561a686c Binary files /dev/null and b/fonts/Hind-500.woff differ diff --git a/fonts/Hind-500.woff2 b/fonts/Hind-500.woff2 new file mode 100644 index 00000000..0062d388 Binary files /dev/null and b/fonts/Hind-500.woff2 differ diff --git a/fonts/Hind-700.eot b/fonts/Hind-700.eot new file mode 100644 index 00000000..b927d845 Binary files /dev/null and b/fonts/Hind-700.eot differ diff --git a/fonts/Hind-700.svg b/fonts/Hind-700.svg new file mode 100644 index 00000000..cef84e0a --- /dev/null +++ b/fonts/Hind-700.svg @@ -0,0 +1,299 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/fonts/Hind-700.ttf b/fonts/Hind-700.ttf new file mode 100644 index 00000000..a65fdc44 Binary files /dev/null and b/fonts/Hind-700.ttf differ diff --git a/fonts/Hind-700.woff b/fonts/Hind-700.woff new file mode 100644 index 00000000..f3592da0 Binary files /dev/null and b/fonts/Hind-700.woff differ diff --git a/fonts/Hind-700.woff2 b/fonts/Hind-700.woff2 new file mode 100644 index 00000000..9db9a775 Binary files /dev/null and b/fonts/Hind-700.woff2 differ diff --git a/fonts/Open-Sans-800.eot b/fonts/Open-Sans-800.eot new file mode 100644 index 00000000..5802888e Binary files /dev/null and b/fonts/Open-Sans-800.eot differ diff --git a/fonts/Open-Sans-800.svg b/fonts/Open-Sans-800.svg new file mode 100644 index 00000000..58ab9156 --- /dev/null +++ b/fonts/Open-Sans-800.svg @@ -0,0 +1,1637 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/fonts/Open-Sans-800.ttf b/fonts/Open-Sans-800.ttf new file mode 100644 index 00000000..569e03a8 Binary files /dev/null and b/fonts/Open-Sans-800.ttf differ diff --git a/fonts/Open-Sans-800.woff b/fonts/Open-Sans-800.woff new file mode 100644 index 00000000..0829a3d1 Binary files /dev/null and b/fonts/Open-Sans-800.woff differ diff --git a/fonts/Open-Sans-800.woff2 b/fonts/Open-Sans-800.woff2 new file mode 100644 index 00000000..f69e6d54 Binary files /dev/null and b/fonts/Open-Sans-800.woff2 differ diff --git a/fonts/Open-Sans-Semibold.eot b/fonts/Open-Sans-Semibold.eot new file mode 100644 index 00000000..d8375dd0 Binary files /dev/null and b/fonts/Open-Sans-Semibold.eot differ diff --git a/fonts/Open-Sans-Semibold.svg b/fonts/Open-Sans-Semibold.svg new file mode 100644 index 00000000..eec4db8b --- /dev/null +++ b/fonts/Open-Sans-Semibold.svg @@ -0,0 +1,1830 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + \ No newline at end of file diff --git a/fonts/Open-Sans-Semibold.ttf b/fonts/Open-Sans-Semibold.ttf new file mode 100644 index 00000000..b3290843 Binary files /dev/null and b/fonts/Open-Sans-Semibold.ttf differ diff --git a/fonts/Open-Sans-Semibold.woff b/fonts/Open-Sans-Semibold.woff new file mode 100644 index 00000000..28d6adee Binary files /dev/null and b/fonts/Open-Sans-Semibold.woff differ diff --git a/fonts/Open-Sans-Semibold.woff2 b/fonts/Open-Sans-Semibold.woff2 new file mode 100644 index 00000000..3f081b70 Binary files /dev/null and b/fonts/Open-Sans-Semibold.woff2 differ diff --git a/fonts/Open-Sans-regular.eot b/fonts/Open-Sans-regular.eot new file mode 100644 index 00000000..1d98e6ea Binary files /dev/null and b/fonts/Open-Sans-regular.eot differ diff --git a/fonts/Open-Sans-regular.svg b/fonts/Open-Sans-regular.svg new file mode 100644 index 00000000..052c59ff --- /dev/null +++ b/fonts/Open-Sans-regular.svg @@ -0,0 +1,1637 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/fonts/Open-Sans-regular.ttf b/fonts/Open-Sans-regular.ttf new file mode 100644 index 00000000..0dae9c3b Binary files /dev/null and b/fonts/Open-Sans-regular.ttf differ diff --git a/fonts/Open-Sans-regular.woff b/fonts/Open-Sans-regular.woff new file mode 100644 index 00000000..ac2b2c65 Binary files /dev/null and b/fonts/Open-Sans-regular.woff differ diff --git a/fonts/Open-Sans-regular.woff2 b/fonts/Open-Sans-regular.woff2 new file mode 100644 index 00000000..402dfd77 Binary files /dev/null and b/fonts/Open-Sans-regular.woff2 differ diff --git a/fonts/icons.eot b/fonts/icons.eot new file mode 100644 index 00000000..1727e7a7 Binary files /dev/null and b/fonts/icons.eot differ diff --git a/fonts/icons.svg b/fonts/icons.svg new file mode 100644 index 00000000..e2e3bb41 --- /dev/null +++ b/fonts/icons.svg @@ -0,0 +1,28 @@ + + + +Copyright (C) 2017 by original authors @ fontello.com + + + + + + + + + + + + + + + + + + + + + + + + \ No newline at end of file diff --git a/fonts/icons.ttf b/fonts/icons.ttf new file mode 100644 index 00000000..b4ebff1d Binary files /dev/null and b/fonts/icons.ttf differ diff --git a/fonts/icons.woff b/fonts/icons.woff new file mode 100644 index 00000000..c243b19b Binary files /dev/null and b/fonts/icons.woff differ diff --git a/fonts/icons.woff2 b/fonts/icons.woff2 new file mode 100644 index 00000000..3d52579c Binary files /dev/null and b/fonts/icons.woff2 differ diff --git a/forum-funding-system/completed-proposals/index.html b/forum-funding-system/completed-proposals/index.html new file mode 100644 index 00000000..29aa9eb0 --- /dev/null +++ b/forum-funding-system/completed-proposals/index.html @@ -0,0 +1,37 @@ +--- +layout: custom +title: Completed Proposals +--- + +
+ +

Back to Forum Funding System

+ +
+ + +
+
+
+
+ {% for toplevel in site.data.ffs %} + {% if toplevel.stage == "Completed Proposals" %} + {% for proposal in toplevel.proposals%} +
+
+
+
+

{{proposal.name}}

+

Summary: {{proposal.summary}}

+

Author: {{proposal.author}}

+
+
+
+
+ {%endfor%} + {%endif%} + {%endfor%} +
+
+
+
\ No newline at end of file diff --git a/forum-funding-system/funding-required/index.html b/forum-funding-system/funding-required/index.html new file mode 100644 index 00000000..c27d7419 --- /dev/null +++ b/forum-funding-system/funding-required/index.html @@ -0,0 +1,35 @@ +--- +layout: custom +title: Funding Required +--- +
+ +

Back to Forum Funding System

+ +
+ +
+
+
+
+ {% for toplevel in site.data.ffs %} + {% if toplevel.stage == "Funding Required" %} + {% for proposal in toplevel.proposals%} +
+
+
+
+

{{proposal.name}}

+

Summary: {{proposal.summary}}

+

Author: {{proposal.author}}

+
+
+
+
+ {%endfor%} + {%endif%} + {%endfor%} +
+
+
+
\ No newline at end of file diff --git a/forum-funding-system/ideas/index.html b/forum-funding-system/ideas/index.html new file mode 100644 index 00000000..0f3ef3f0 --- /dev/null +++ b/forum-funding-system/ideas/index.html @@ -0,0 +1,41 @@ +--- +layout: custom +title: Ideas +--- + +
+ +

Back to Forum Funding System

+ +
+ + + +
+
+
+
+ {% for toplevel in site.data.ffs %} + {% if toplevel.stage == "Ideas" %} + {% for proposal in toplevel.proposals%} +
+
+
+
+

{{proposal.name}}

+

Summary: {{proposal.summary}}

+

Author: {{proposal.author}}

+
+
+
+
+ {%endfor%} + {%endif%} + {%endfor%} +
+
+
+
+ + + \ No newline at end of file diff --git a/forum-funding-system/index.md b/forum-funding-system/index.md new file mode 100644 index 00000000..92f50a79 --- /dev/null +++ b/forum-funding-system/index.md @@ -0,0 +1,155 @@ +--- +layout: custom +title: Forum Funding System +--- +
+
+
+

Monero is a decentralized community-driven project, and the Forum Funding System is a way for members to get involved and proposals to be funded. To see how it works, click here. To see how to submit your own proposal or idea, click here.

+
+
+
+
+
+ + +

Ideas

+
+ {% for toplevel in site.data.ffs %} + {% if toplevel.stage == "Ideas" %} + {% for proposal in toplevel.proposals limit:2 %} +

{{proposal.name}}

+

Summary: {{proposal.summary}}

+

Author: {{proposal.author}}

+ {%endfor%} + {%endif%} + {%endfor%} +
+

See all Ideas

+
+
+ + +

Open Tasks

+
+ {% for toplevel in site.data.ffs %} + {% if toplevel.stage == "Open Tasks" %} + {% for proposal in toplevel.proposals limit:2 %} +

{{proposal.name}}

+

Summary: {{proposal.summary}}

+

Author: {{proposal.author}}

+ {%endfor%} + {%endif%} + {%endfor%} +

See all Open Tasks

+
+
+ + +

Funding Required

+
+ {% for toplevel in site.data.ffs %} + {% if toplevel.stage == "Funding Required" %} + {% for proposal in toplevel.proposals limit:2 %} +

{{proposal.name}}

+

Summary: {{proposal.summary}}

+

Author: {{proposal.author}}

+ {%endfor%} + {%endif%} + {%endfor%} +
+

See all Funding Required

+
+
+ + +

Work in Progress

+
+ {% for toplevel in site.data.ffs %} + {% if toplevel.stage == "Work in Progress" %} + {% for proposal in toplevel.proposals limit:2 %} +

{{proposal.name}}

+

Summary: {{proposal.summary}}

+

Author: {{proposal.author}}

+ {%endfor%} + {%endif%} + {%endfor%} +
+

See all Work in Progress

+
+
+ + +

Completed Proposals

+
+ {% for toplevel in site.data.ffs %} + {% if toplevel.stage == "Completed Proposals" %} + {% for proposal in toplevel.proposals limit:2 %} +

{{proposal.name}}

+

Summary: {{proposal.summary}}

+

Author: {{proposal.author}}

+ {%endfor%} + {%endif%} + {%endfor%} +
+

See Completed Proposals

+
+
+
+
+
+
+
+
+
+
+
+
+ Ideas + +
+
+ + +
+
+ Open Tasks +
+
+ +
+
+
+
+ +
+
+ Funding Required +
+
+ + + +
+
+ Work in Progress +
+
+ +
+
+
+
+ + +
+
+ Completed Proposals +
+
+ + +
+
+
+
\ No newline at end of file diff --git a/forum-funding-system/open-tasks/index.html b/forum-funding-system/open-tasks/index.html new file mode 100644 index 00000000..73ab28d7 --- /dev/null +++ b/forum-funding-system/open-tasks/index.html @@ -0,0 +1,35 @@ +--- +layout: custom +title: Open Tasks +--- +
+ +

Back to Forum Funding System

+ +
+ +
+
+
+
+ {% for toplevel in site.data.ffs %} + {% if toplevel.stage == "Open Tasks" %} + {% for proposal in toplevel.proposals%} +
+
+
+
+

{{proposal.name}}

+

Summary: {{proposal.summary}}

+

Author: {{proposal.author}}

+
+
+
+
+ {%endfor%} + {%endif%} + {%endfor%} +
+
+
+
\ No newline at end of file diff --git a/forum-funding-system/proposals/getmonero-redesign.md b/forum-funding-system/proposals/getmonero-redesign.md new file mode 100644 index 00000000..a0fc203c --- /dev/null +++ b/forum-funding-system/proposals/getmonero-redesign.md @@ -0,0 +1,119 @@ +--- +layout: ffs-wip +title: Getmonero.org Redesign +address: 4445 +paymentid: 3xj3 +author: rehrar +--- + +At the request of myself , I am editing my proposal that fluffypony recommended I edit that was edited from the initial idea. So, without further ado: + +### What: GetMonero.org Redesign and Restructure +My project looks to give a complete site redesign to getmonero.org. As it is right now, it's not very user-friendly, doesn't look very pretty, and just doesn't look as professional as one would assume from the sophisticated technology that is Monero. That can easily be changed, with a souped up design that is modern, slick, and inviting to anyone who wants to become a part of the Monero community, while still maintaining the charm that comes with open-source projects. + +How do we plan to develop it? Upon speaking with the FluffyPony, there are three very important things that the redesign must keep in mind: + +1. JavaScript must not be used in the new site, as a good amount of the site's traffic comes from Tor. + +2. Be developed using Jekyll + +3. The forum is going to be done away with, but the FFS will remain (not my idea, it was told to me). Right now the forum isn't being used for much besides the FFS. So we need a way to put the FFS into the site proper. + +Nowadays CSS can do incredible things on its own. There are even a number of CSS frameworks that operate without Javascript. The current site uses Bootstrap, although there are other alternatives to consider. Yes, Bootstrap has some JS inclusions, but it operates just fine without them as they're really for specific things (which we shouldn't need). There are other options, such as Burma, or even no framework at all. + +Also, the site information will be restructured, with the differing pages being put into different, or even new, categories to make the information available more accessible to everybody. + +### Who: And you are...? +Heyo, you can call me Rehrar. My wife (Mrs. Rehrar) and I are web designers and developers. We really enjoy what we do, and specialize in helping small businesses get a web presence, or revamp their old websites. We really believe in XMR and what it stands for, and would love to extend our talents towards the community to help. + +Our online portfolio is in the works and we were hoping to launch before mid-March, but a huge slew of jobs came in all at once and we've been working like madmen to get them done. The fact that we can find decent work before our portfolio is up is pretty great for us. For now, here's a sample of the work that we're doing: + +[Nikki Karay, Cosplayer](http://nikkikaray.com) (a website we made for a cosplayer) + +[A Striking Image](http://floodedcallus.com) (a site that we made for a carpet cleaning business) + +[Remembering the Time](http://rememberingthetime.net) (a site we made for a personal historian) + + +### Why: Seriously, is this needed? +Yes, a site redesign is very needed. Monero has great technology, a great dev team, and a great community behind it. Some people are of the opinion that the site is fine, and that we don't need anything new or different. But more people discover and subsequently become involved in the community, the better it is for everyone, and we need to make it as easy as possible for newcomers to get find the resources they need. + +I'll be honest, if a layperson comes to this website, the first thing that comes to mind will not be 'sophisticated technology'. Some might say: "But if they dig into the reasons and technology behind it they will see...". Look, not everyone does this, and to the masses, first impressions count for a lot. We can't hide behind the way we wish the world works. Marketing is important, and a having a good website in the digital age is Marketing 101. + +Technology development and marketing are not mutually exclusive, and I think too many people forget that. And seeing as how I would be unable to help the dev team anyways, I think I can use my talents to further the community despite that. :) + +Secondly, the information on the site is currently very badly structured. A lot of things just seem like a hodgepodge of pages thrown together in a category that it more or less can squeeze. Along with the redesign, some great restructuring needs to happen. + +### Proposals & Milestones +We are willing to work for 2 XMR/hr, the following milestones are estimated hours of how long it will take to complete the project. We will ask a flat fee, so any hours above will be a donation to the community. With this in mind, I would like to propose the following milestones. + +**Milestone 1: Front Page Design and Site Restructuring (10XMR)** +Everyone has different opinions on how they think the website should look. The first step would be to decide as a community what the overall feel of the website should be. We (Mrs. Rehrar and I) would design two possible landing pages to be discussed by the community. While it is possible to make suggestions at this stage about the content that is included in the mockup, the bigger idea is the design, look, and feel. The final decision of which design to use rests with me, but I will take all suggestions and ideas into consideration. + +The next portion is the restructuring of getmonero.org to make information better structured and easier to access. I will present a tentative restructuring of the site for comment, and will make changes as necessary. + +After these decisions are made we will move to Milestone 2. + +_Notes:_ +It is possible that the community will greatly dislike both designs. If this should happen, the community can create a design themselves, or additional mockups can be made for 5 XMR each. Sorry, but because this has the potential to go on for infinity before people reach agreement, there needs to be a limit somewhere. + +**MAJOR NOTE:** +Milestone 1 is practically complete already. We just couldn't wait to present our work to the community. You can see our designs in the albums below: + +[Redesign Proposal 1 (album)](http://imgur.com/a/MwyxX) + +[Redesign Proposal 2 (album)](http://imgur.com/a/H9i3z) + + +**Milestone 2: Website Design (40XMR)** +Next, I will create mockups for the major pages of the new site to be reviewed and critiqued by the community. The designs can be tweaked and modified (although at this point any suggestions to the look and feel that are not minute in nature will not be considered) until the community reaches a reasonable agreement to move forward (same stipulations as in Milestone 1). + +In this section is also the design of the new FFS. This will be a huge endeavor from a UI/UX perspective and we will do everything we can in research and designing to make it usable, accessible, with a friendly interface. + +A lot of work is going to be put into the design process. Like, it's probably going to be 50% of the total work. The building portion is easy. We have decided to make a significant investment of time for the designs to be worked on, workshopped, approved, and, if necessary, redone so it's perfect for something as amazing as Monero. + +**Milestone 3: Development (30XMR)** +Here we go. The big stuff. We go into production mode and start building the website that is agreed upon. Not too much explanation here. We will host the in-progress site on a small Vultr server and the IP address will be publicly available so anyone can look at the progress. There will be weekly progress reports and anyone is free to make comments during the process. + +There would be two planned phases for Milestone 3: +1. Create the main site +2. Create and integrate the new FFS. + +After both phases are completed, we will switch the new site over. + +**Milestone 4: ???** +At this point the project is pretty much done. But there may be things that need to be added over time (such as when news or new technology is introduced). The source code to the site will of course be freely available and anyone with the know-how would be able to edit and add pages. + +**Total proposed XMR for the project: 100XMR** + +### Timeline +The proposed timeline for each milestone will vary. Especially because for the design process we want to give enough time for the community to be able give feedback and have a voice. With that in mind, the proposed timeline is as follows: + +**Milestone 1:** One week to create both designs and two weeks for the community to comment and the suggested changes to be made, tried, commented on again, etc.. Total: 3 weeks. + +_Note:_ +Milestone 1 is practically complete already. See above. + +**Milestone 2:** Four weeks to lovingly craft the remaining pages of the site and three weeks for the community suggestion process and resulting modifications to occur. Total: 7 weeks. + +_Note:_ +why so long here? Again, it's not just a reskin of the current form of the website. A lot of thought has to go into a potential restructuring of content to make it accessible to the most people. Some content blocks may be moved to another place on the page, or another page entirely. We've got a lot of work to do in this area. After that, the development is just making all of that idea work and planning and creativity come alive with code. No biggie! :D + +**Milestone 3:** Three weeks for Phase 1 (new website creation) and an additional three weeks for Phase 2 (FFS integration). Since we'll be working with the devs of the website backend to integrate it, I have to plan for more time as we may be in different time-zones, things may not get done same day, people are busy, etc. Total: 6 weeks. + +Total proposed timeline for the project: 16 weeks (4 months). If consensus with the designs of the first two milestones is reached very rapidly, then it can be quicker. + +### Expiration +While I don't plan to drop out of the project, all of the source code will be continuously updated on GitHub for anyone to use. In the event that the website is not up 4 months after funding (allowing some leeway for unforseen circumstances), the funds may be reappropriated as determined by the core team. + +Any questions? Comments? Concerns? Complaints? Let me know below! + +### Major Note: +Again, Milestone 1 is pretty much done. Please see the album links to view the designs (and all of their drafts): + +[Redesign Proposal 1 (album)](http://imgur.com/a/MwyxX) + +[Redesign Proposal 2 (album)](http://imgur.com/a/H9i3z) + +Thanks everyone! +Diego \ No newline at end of file diff --git a/forum-funding-system/proposals/monero-bounty-hackerone.md b/forum-funding-system/proposals/monero-bounty-hackerone.md new file mode 100644 index 00000000..d3fa4f1a --- /dev/null +++ b/forum-funding-system/proposals/monero-bounty-hackerone.md @@ -0,0 +1,28 @@ +--- +layout: ffs-fr +title: Monero Bounty For HackerOne +address: 45ttEikQEZWN1m7VxaVN9rjQkpSdmpGZ82GwUps66neQ1PqbQMno4wMY8F5jiDt2GoHzCtMwa7PDPJUJYb1GYrMP4CwAwNp +paymentid: 8d3526aed9a09a943788496751c78c8f4757e7f6f3234a547efe77f3c9c6cc4b +author: anonimal +--- + +### What: +We need dedicated funds to satisfy bounty for Monero and all Monero sub-projects on [hackerone.com/monero](https://hackerone.com/monero) + +### Who: +[me](https://forum.getmonero.org/9/work-in-progress/86967/anonimal-s-kovri-full-time-development-funding-thread) + +### Why: +Now that our VRP is in place and Monero/Kovri HackerOne account launched, we need to have funds available before inviting hackers/researchers (offering XMR/BTC as exploit bounty was agreed to long ago in #kovri-dev (and in recent meetings)). + +### The Proposal and Milestones: +No milestones, just much needed crowdfunding. As mentioned [here](https://github.com/monero-project/meta/issues/39#issuecomment-289310019): "set a 500 XMR minimum bounty" + +### Expiration: +N/A + +### Links: + +[https://hackerone.com/kovri](https://hackerone.com/kovri) + +[https://github.com/monero-project/kovri/blob/master/doc/VULNERABILITY_RESPONSE_PROCESS.md](https://github.com/monero-project/kovri/blob/master/doc/VULNERABILITY_RESPONSE_PROCESS.md) \ No newline at end of file diff --git a/forum-funding-system/proposals/whatismonero-produced.md b/forum-funding-system/proposals/whatismonero-produced.md new file mode 100644 index 00000000..b7b50da0 --- /dev/null +++ b/forum-funding-system/proposals/whatismonero-produced.md @@ -0,0 +1,27 @@ +--- +layout: ffs-cp +title: What is Monero? is produced and open-sourced. +author: savandra +--- + +Hello everyone! + +It's been a pleasure creating the first "What is Monero?" promotional video. The custom music, art, and project files have all been open sourced, and we greatly enjoyed the process. + +[Link to the Final Video](https://www.youtube.com/watch?v=TZi9xx6aiuY) + +[Link to the Github Repo](https://github.com/savandra/Monero_Promo_Video) + +We (my wife and myself) worked over 40 hours on the video over the course of creating a storyboard, illustrating artwork, animating the art, and making the music. We also coordinated with the whole community via Reddit and Slack channel to make any edits, and welcomed any feedback. + +We want to thank people who helped us with the script and edits: + +needmoney90 SamsungGalaxyPlayer bitsofic + +(I'm sorry to say we lost few names due to Slack history issue. Sorry guys!) + +We want to keep our rates as low as possible (we need to eat something!), so we're asking for $10 per hour worked. In total, that is $800 (~110 XMR) between the two of us. We already have some contributions, mainly from needmoney90 and SamsungGalaxyPlayer, for 38 XMR in total. This brings the remaining requested funding down to 72 XMR. If you enjoyed our work, and would like to see more of it in the future, please help fund this request. + +We are looking forward to making more videos for Monero in the future, including an explanatory animation on Ring Signatures. Once a proposal has been created for that, we will link to it here. + +Thank you for all the community support. If you have any questions or comments, please feel free to send me a message on either Slack/IRC (@savandra), or by email (savdeyev at gmail dot com) diff --git a/forum-funding-system/work-in-progress/index.html b/forum-funding-system/work-in-progress/index.html new file mode 100644 index 00000000..16725f2f --- /dev/null +++ b/forum-funding-system/work-in-progress/index.html @@ -0,0 +1,35 @@ +--- +layout: custom +title: Work in Progress +--- +
+ +

Back to Forum Funding System

+ +
+ +
+
+
+
+ {% for toplevel in site.data.ffs %} + {% if toplevel.stage == "Work in Progress" %} + {% for proposal in toplevel.proposals%} +
+
+
+
+

{{proposal.name}}

+

Summary: {{proposal.summary}}

+

Author: {{proposal.author}}

+
+
+
+
+ {%endfor%} + {%endif%} + {%endfor%} +
+
+
+
\ No newline at end of file diff --git a/get-started/accepting/index.md b/get-started/accepting/index.md new file mode 100644 index 00000000..023ddc2c --- /dev/null +++ b/get-started/accepting/index.md @@ -0,0 +1,91 @@ +--- +layout: custom +title: "Accepting Monero" +--- + +
+
+ +
+
+
+
+

Instructions for the Command-Line Interface

+
+
+
+ +### The Basics + +Monero works a little differently to what you may have become accustomed to from other @cryptocurrencies. In the case of a digital currency like Bitcoin and its many derivatives merchant payment systems will usually create a new recipient @address for each payment or user. + +However, because Monero has @stealth-addresses there is no need to have separate recipient addresses for each payment or user, and a single @account address can be published. Instead, when receiving payments a merchant will provide the person paying with a "payment ID". + +A @payment-ID is a hexadecimal string that is 64 characters long, and is normally randomly created by the merchant. An example of a payment ID is: `666c75666679706f6e7920697320746865206265737420706f6e792065766572` + +### Checking for a Payment in monero-wallet-cli + +If you want to check for a payment using monero-wallet-cli you can use the "payments" command followed by the payment ID or payment IDs you want to check. For example: + +``` +[wallet 49VNLa]: payments 666c75666679706f6e7920697320746865206265737420706f6e792065766572 + payment transaction height amount unlock time + 666c75666679706f6e79206973207 7ba4cd810c9b4096869849458181e98e 441942 30.00000 0 +[wallet 49VNLa]: █ +``` + +If you need to check for payments programmatically, then details follow the next section. + +### Receiving a Payment Step-by-Step + +* Generate a random 64 character hexadecimal string for the payment +* Communicate the payment ID and Monero address to the individual who is making payment +* Check for the payment using the "payments" command in monero-wallet-cli + +### Checking for a Payment Programatically + +In order to check for a payment programatically you can use the get_payments or get_bulk_payments JSON RPC API calls. + +*get_payments*: this requires a payment_id parameter with a single payment ID. + +*get_bulk_payments*: this is the preferred method, and requires two parameters, payment_ids - a JSON array of payment IDs - and an optional min_block_height - the block height to scan from. + +An example of returned data is as follows: + +``` +[ monero->~ ]$ curl -X POST http://127.0.0.1:18500/json_rpc -d '{"jsonrpc":"2.0","method":"get_bulk_payments","id":"test", "params":{"payment_ids": ["666c75666679706f6e7920697320746865206265737420706f6e792065766572"]}}' -H "Content-Type: application/json" +{ + "id": "test", + "jsonrpc": "2.0", + "result": { + "payments": [{ + "amount": 30000000000000, + "block_height": 441942, + "payment_id": "666c75666679706f6e7920697320746865206265737420706f6e792065766572", + "tx_hash": "7ba4cd810c9b4096869849458181e98e18b6474ab66415de0f4ccf7ab1162fdf", + "unlock_time": 0 + }] + } +} +``` + +It is important to note that the amounts returned are in base Monero units and not in the display units normally used in end-user applications. Also, since a transaction will typically have multiple outputs that add up to the total required for the payment, the amounts should be grouped by the tx_hash or the payment_id and added together. Additionally, as multiple outputs can have the same amount, it is imperative not to try and filter out the returned data from a single get_bulk_payments call. + +Before scanning for payments it is useful to check against the daemon RPC API (the get_info RPC call) to see if additional blocks have been received. Typically you would want to then scan only from that received block on by specifying it as the min_block_height to get_bulk_payments. + +### Programatically Scanning for Payments + +* Get the current block height from the daemon, only proceed if it has increased since our last scan +* Call the get_bulk_payments RPC API call with our last scanned height and the list of all payment IDs in our system +* Store the current block height as our last scanned height +* Remove duplicates based on transaction hashes we have already received and processed + +
+
+
+ + + +
+
+ \ No newline at end of file diff --git a/get-started/contributing/index.md b/get-started/contributing/index.md new file mode 100644 index 00000000..987efec3 --- /dev/null +++ b/get-started/contributing/index.md @@ -0,0 +1,115 @@ +--- +layout: custom +title: Contributing to Monero +--- +
+Monero is an open source, community driven project. We strive to be a welcoming community. Perhaps you want to contribute? +
+ +
+ +
+
+ +
+
+
+
+

Donating

+
+
+
+

Ongoing development of the Monero Project is solely supported by donations and sponsors. At this time the project is vastly underfunded, and thus donations are greatly appreciated.

+

If you would like to make a donation you can do so by using any of the methods below:

+
+
+
+ +
+
+ +
+
+
+
+

Donating in Monero

+

You can send XMR donations to donate.getmonero.org, or directly to our Monero donation address - 44AFFq5kSiGBoZ4NMDwYtN18obc8AemS33DBLWs3H7otXft3XjrpDtQGv7SqSsaBYBb98uNbr2VBBEt7f2wfn3RVGQBEP3A

+
+
+
+
+

Donating in Bitcoin

+

You can also send BTC donations to donate.getmonero.org, or directly to our Bitcoin address: 1KTexdemPdxSBcG55heUuTjDRYqbC5ZL8H

+
+
+
+
+

Other ways

+

To donate via credit card, wire transfer, or PayPal, please email the core team at dev@getmonero.org

+
+
+
+
+ + +
+
+
+
+

Forum Funding System

+
+
+
+

Monero utilizes a Forum Funding System (FFS) which encourages people of all backgrounds to be a part of Monero and maybe even get paid for it. Anyone can suggest an idea, ask for funding, and immediately start making the idea happen. As progress is made payments are released and Monero flourishes. You can donate directly to individual projects that you support. Take a look and don't be afraid to jump right in with an idea or a donation.

+
+ +
+
+ + + +
+
+
+

General Involvement

+
+
+ +### Join the Community +We're all over the place. Start discussions, ask questions. The more faces we see that are excited about Monero, the more morale increases and the further we push the boundaries of what a cryptocurrency can become. Check out our [Hangouts](/community/hangouts) page to see where you can find us. + +### Attend a Meetup +Talking with people online is nice and all, but sometimes it's enjoyable to chat with people in person. See the list of upcoming events here. If nothing is happening around you, it's easy to start something yourself! Just meet with local enthusiasts at a bar and chat. + +### Run a Full Node +Run monerod with port 18080 open. This will help your node distribute copies of the blockchain to other nodes on the network. + +### Mine +From the GUI and CLI, there is an option to start mining. This is a great way to protect the decentralization of the network. If you have a powerful graphics card or hope to mine for profit, see more advanced options in the [MoneroMining subreddit](https://reddit.com/r/MoneroMining). + +
+
+
+ + + +
+
+
+
+

Coding

+
+
+
+

Monero is written in C++, and is looking for coders of all skill levels (from absolute beginner to senior developer) to contribute to the project. The most important things are a desire to learn and a willingness to take direction and correction. If you want to get started, check out our GitHub respositories and check out the outstanding Issues.

+

If you code in a language other than C++, don't worry, there are libraries in other languages that you can contribute to.

+
+
+
+ + + +
+
+ +
\ No newline at end of file diff --git a/get-started/faq/index.md b/get-started/faq/index.md new file mode 100644 index 00000000..4d2717a2 --- /dev/null +++ b/get-started/faq/index.md @@ -0,0 +1,126 @@ +--- +layout: full-text +title: FAQ +--- + +
+ + + +
+ +Monero has value because people are willing to buy it. If no one is willing to buy Monero, then it will not have any value. Monero’s price increases if demand exceed supply, and it decreases is supply exceeds demand. + +
+ +
+ +
+ + + +
+ +You can buy Monero from an exchange or from an individual. Alternatively, you can try mining Monero to get coins from the block reward. +
+ +
+ +
+ + + +
+ +A mnemonic seed is a set of 25 words that can be used to restore your account anywhere. Keep these words safe and do not share them with someone else. You can use this seed to restore your account, even if your computer crashes. +
+ +
+ +
+ + + +
+ +Monero uses three different privacy technologies: ring signatures, ring confidential transactions (RingCT), and stealth addresses. These hide the sender, amount, and receiver in the transaction, respectively. All transaction on the network are private by mandate; there is no way to accidentally send a transparent transaction. This feature is exclusive to Monero. You do not need to trust anyone else with your privacy. +
+ +
+ +
+ + + +
+ +If you are running a full node locally, you need to copy the entire blockchain to your computer. This can take a long time, especially on an old hard drive or slow internet connection. If you are using a remote node, your computer still needs to request a copy of all the outputs, which can take several hours. Be patient, and if you would like to sacrifice some privacy for faster sync times, consider using a lightweight wallet instead. +
+ +
+ +
+ + + +
+ +For a lightweight wallet, you give your view key to a node, who scans the blockchain and looks for incoming transactions to your account on your behalf. This node will know when you receive money, but it will not know how much you receive, who you received it from, or who you are sending money to. For more privacy, use a normal wallet, which can be used with your own node. +
+ +
+ +
+ + + +
+ +Monero is not based on Bitcoin. It is based on the CryptoNote protocol. Bitcoin is a completely transparent system, where people can see exactly how much money is being sent from one user to another. Monero hides this information to protect user privacy in all transactions. It also has a dynamic block size and dynamic fees, among several other changes. +
+ +
+ +
+ + + +
+ +No, Monero does not have a hard block size limit. Instead, the block size can increase or decrease over time based on demand. It is capped at a certain growth rate to prevent outrageous growth. +
+ +
+ +
+ + + +
+ +A blockchain is a system that stores a copy of all transaction history on the Monero network. Every two minutes, a new block with the latest transaction information is added to the blockchain. This chain allows the network to verify the amount of money accounts have and make it resilient to attacks and centralization attempts. +
+ +
+ +
+ + + +
+ +Kovri is an I2P router written in C++. I2P is a hidden network like Tor with several technical differences. Kovri is an independent project of Monero, but it will work with Monero and several other projects. Kovri hides the transaction broadcast, so other nodes do not know who created transactions. In adversarial conditions, Kovri can be used to hide all Monero traffic through I2P, which would prevent people from knowing Monero is being used. Kovri is currently in alpha, and it is not yet fully integrated in Monero. Learn more about Kovri at the [project website.](https://getkovri.org) +
+ +
+ +
+ + + +
+ +Fungibility is a simple property of money such that there are no differences between two amounts of the same value. If two people exchanged a 10 and two 5’s, then no one would lose out. However, let’s suppose that everyone knows the 10 was previously used in a ransomware attack. Is the other person still going to make the trade? Probably not, even if the person with the 10 is not the one who wrote the ransomware. This is a problem, wince the receiver of money needs to constantly check the money they are receiving to not end up with tainted coins. Monero is fungible, which means people do not need to go through this effort. +
+ +
\ No newline at end of file diff --git a/get-started/mining/index.md b/get-started/mining/index.md new file mode 100644 index 00000000..36526ee3 --- /dev/null +++ b/get-started/mining/index.md @@ -0,0 +1,97 @@ +--- +layout: custom +title: Mining Monero +--- +
+
+

Monero is a cryptocurrency that relies on Proof-of-Work mining to secure the network. If you'd like to know why mining is necessary and other beginner's questions, see this User Guide for more information. Below you'll find some information and resources on how to get started mining Monero.

+ +

The Monero Project does not endorse any particular pool, software, or hardware, and the content below is provided for informational purposes only.

+
+ +
+
+ +
+
+
+
+

Support

+
+
+
+

One of the great benefits of mining Monero is the large community around it. There's plenty of places that you can go to, and checking out our Hangouts page may give you a couple ideas, but there are some specialized communities on reddit (/r/moneromining) and IRC (#monero-pools) that you can check out.

+
+
+
+ +
+
+
+
+
+
+
+
+

Pools

+
+
+
+

One of the common ways to mine Monero is to join a pool, although mining solo is possible and encouraged. A Monero community member has put together a list of trusted Monero pools for you to consider. Remember, join a smaller pool to spread the hashes around!

+
+
+
+
+
+
+
+

Hardware

+
+
+
+

Some people choose to invest in specalized mining hardware in order to increase their mining hashrate. A Monero community member has decided to put together a site for the benchmarks of different GPUs. Results may vary. Feel free to contribute

+
+
+
+
+
+
+
+ +
+
+
+
+

Mining Software

+
+
+
+

Depending on your hardware, there are various mining programs available for use. You might consider trying different ones and seeing how it affects you hasrate. Please note, that some miners also have developer fees.

+
+
+
+

AMD Miners

+

XMR Stak AMD

+

Wolf's AMD Miner

+
+
+

CPU Miners

+

Monero Spelunker (Windows)

+

XMR Stak CPU

+

Wolf's CPU Miner

+
+
+

NVidia Miners

+

XMR Stak NVidia

+

CC Miner

+

XMR Miner (Windows)

+
+
+
+
+ +
+
+ + +
\ No newline at end of file diff --git a/get-started/using/index.md b/get-started/using/index.md new file mode 100644 index 00000000..ab06edd3 --- /dev/null +++ b/get-started/using/index.md @@ -0,0 +1,101 @@ +--- +layout: custom +title: Using Monero +--- +
+

Using Monero is easy, and there are a variety of tools and guides available to help newcomers. This page will guide you through the basics.

+
+
+
+
+ +
+
+
+
+

1. Start Here

+
+
+
+

Monero is a cryptocurrency that allows anonymous transactions around the world. Monero stands on pillars of security, privacy, and decentralization, and the community and developers are committed to protecting these values. We suggest learning more about how Monero works and reading the What is Monero page. The source code for Monero and all our official clients are available for public view and discussion on Github.

+
+
+
+ +
+
+
+
+
+
+
+
+

2. Support

+
+
+
+

Before reading further, it is important to know that there is a large, supportive community that can assist if your run into trouble. If you have questions about anything, no matter how large or small, don't hesitate to ask. We chill in a lot of places, so see our Hangouts page to track us down. Remember, there are no stupid questions, and we are all learning together.

+
+
+
+
+
+
+
+

3. Getting a Wallet

+
+
+
+

You need somewhere to store physical cash such as your bank, your wallet, or under your mattress. Although Monero is an entirely digital asset (you cannot touch them!), you still need a place to store them. This is done in a digital wallet. You oversee securing your own funds, and there is no way to restore them if you make a mistake. Thus, take great care in selecting the right wallet for you. Some are safer and others are more convenient than others. See our downloads page for the wallets that The Monero Project has put out.

+
+
+
+
+
+
+
+ +
+
+
+
+

4. Getting Monero

+
+
+
+

Empty wallets are no fun! Let’s get some Monero in there! You can receive Monero from someone else, or purchase some on an exchange. We do not endorse specific services, but you can view the exchanges that support Monero on the Merchants page. Depending on the exchange, you can buy Monero from several currencies including USD, EUR, and Bitcoin. For price speculation and talk, join the active trading discussion at #monero-markets.

+
+
+
+ +
+
+
+
+
+
+
+
+

5. Transfering Monero

+
+
+
+

It is typically a poor idea to leave a large amount of money on an exchange. If you manage your wallet properly, it is a much safer place to store your Monero. Learn how to send and receive Monero by viewing our guide, and learn about your risk exposure.

+
+
+
+
+
+
+
+

6. Now What?

+
+
+
+

You now have Monero and know how to use it! Monero, like cash, can be used for many goods and services. For a list of some groups that accept Monero directly, see our Merchants page. Other services make it easy to pay Bitcoin addresses with the privacy of Monero.

+
+
+
+
+
+
\ No newline at end of file diff --git a/get-started/what-is-monero/index.md b/get-started/what-is-monero/index.md new file mode 100644 index 00000000..0bbf0448 --- /dev/null +++ b/get-started/what-is-monero/index.md @@ -0,0 +1,119 @@ +--- +layout: default +title: "What Is Monero?" +--- + +
+
+
+ +
+
+
+

What you need to know

+
+
+
+

Monero is the leading cryptocurrency with a focus on private and censorship-resistant transactions.

+

Almost all cryptocurrencies (including Bitcoin and Ethereum) are transparent. They reveal your entire transaction history to the world.

+

Monero uses unbreakable cryptography to ensure that no one can see how much money you have or where you spend it, even if they know your wallet address.

+
+
+ Encrypted lock +
+
+
+
+ Classified document +
+
+

Monero transactions are confidential and untraceable.

+

The source of funds in every Monero transaction is untraceable, and the transaction amounts are confidential. Always-on privacy means that every Monero user's activity enhances the privacy of all other users.

+

Because funds on the Monero blockchain are untraceable, they cannot become tainted by association with their previous owners. This means you can accept Monero without risk of the funds you've received being blocked or censored at currency exchanges or merchants.

+

Monero's Kovri project (coming soon) encrypts and routes transactions through the I2P Invisible Internet Project nodes to hide your IP address and protect you from network monitoring.

+
+ +
+
+
+

Monero is a grassroots community attracting the world's best cryptocurrency researchers and engineering talent.

+

Over 240 developers have contributed to the Monero project, including 30 core developers. Forums and chat channels are welcoming and active.

+

Monero's Research Lab, Core Development Team and Community Developers are constantly pushing the frontier of what is possible with cryptocurrency privacy and security.

+

Monero is not a corporation. It is developed by cryptography and distributed systems experts from all over the world that donate their time or are funded by community donations. This means that Monero can't be shut down by any one country and is not constrained by any particular legal jurisdiction.

+
+
+ Academic growth +
+
+
+
+ Electronic cash +
+
+

Monero is electronic cash that allows fast, inexpensive payments to and from anywhere in the world.

+

There are no multi-day holding periods and no risk of fraudulent chargebacks. It is safe from ‘capital controls’ - these are measures that restrict the flow of traditional currencies, sometimes to an extreme degree, in countries experiencing economic instability.

+
+
+
+
+
+
+
+

Monero Videos

+
+
+
+
    + + + + +
    + + +
    +
    + + +
    +
    + + +
    +
    + + +
    +
  • +

    Monero Promo

    + +
    • +
  • +

    Monero: The Essentials

    + +
    • +
  • +

    Stealth Addresses

    + +
    • +
  • +

    Ring Signatures

    + +
    • +
+
+
+
+
+ +
+
+
\ No newline at end of file diff --git a/img/academic-growth.png b/img/academic-growth.png new file mode 100644 index 00000000..e7405736 Binary files /dev/null and b/img/academic-growth.png differ diff --git a/img/araxis.png b/img/araxis.png new file mode 100644 index 00000000..d6dea0c5 Binary files /dev/null and b/img/araxis.png differ diff --git a/img/crypto-lock.png b/img/crypto-lock.png new file mode 100644 index 00000000..1f474799 Binary files /dev/null and b/img/crypto-lock.png differ diff --git a/img/dome9.png b/img/dome9.png new file mode 100644 index 00000000..d151ee44 Binary files /dev/null and b/img/dome9.png differ diff --git a/img/donate-bitcoin.png b/img/donate-bitcoin.png new file mode 100644 index 00000000..6fbfeea0 Binary files /dev/null and b/img/donate-bitcoin.png differ diff --git a/img/donate-monero.png b/img/donate-monero.png new file mode 100644 index 00000000..ceac7039 Binary files /dev/null and b/img/donate-monero.png differ diff --git a/img/favicons.svg b/img/favicons.svg new file mode 100644 index 00000000..b2154cdf --- /dev/null +++ b/img/favicons.svg @@ -0,0 +1,17 @@ + + + + + + + + + + + + diff --git a/img/forked_logo.png b/img/forked_logo.png new file mode 100644 index 00000000..da5f214d Binary files /dev/null and b/img/forked_logo.png differ diff --git a/img/fungible-monero.png b/img/fungible-monero.png new file mode 100644 index 00000000..dca2cb7c Binary files /dev/null and b/img/fungible-monero.png differ diff --git a/img/jetbrains.png b/img/jetbrains.png new file mode 100644 index 00000000..9dcf2387 Binary files /dev/null and b/img/jetbrains.png differ diff --git a/img/kitware.png b/img/kitware.png new file mode 100644 index 00000000..9b8cc6a5 Binary files /dev/null and b/img/kitware.png differ diff --git a/img/monero-cash-video-poster.png b/img/monero-cash-video-poster.png new file mode 100644 index 00000000..032293c5 Binary files /dev/null and b/img/monero-cash-video-poster.png differ diff --git a/img/monero-classified.png b/img/monero-classified.png new file mode 100644 index 00000000..6e59b82b Binary files /dev/null and b/img/monero-classified.png differ diff --git a/img/monero-community.png b/img/monero-community.png new file mode 100644 index 00000000..06b08f1b Binary files /dev/null and b/img/monero-community.png differ diff --git a/img/monero-electronic-cash.png b/img/monero-electronic-cash.png new file mode 100644 index 00000000..d0a228db Binary files /dev/null and b/img/monero-electronic-cash.png differ diff --git a/img/monero-logo.png b/img/monero-logo.png new file mode 100644 index 00000000..9aa20cb1 Binary files /dev/null and b/img/monero-logo.png differ diff --git a/img/monero-spritesheet.png b/img/monero-spritesheet.png new file mode 100644 index 00000000..0b935846 Binary files /dev/null and b/img/monero-spritesheet.png differ diff --git a/img/mymonero.png b/img/mymonero.png new file mode 100644 index 00000000..dba7a995 Binary files /dev/null and b/img/mymonero.png differ diff --git a/img/navicat.png b/img/navicat.png new file mode 100644 index 00000000..ae393c39 Binary files /dev/null and b/img/navicat.png differ diff --git a/img/private-monero.png b/img/private-monero.png new file mode 100644 index 00000000..598e4718 Binary files /dev/null and b/img/private-monero.png differ diff --git a/img/ring-signatures-poster.png b/img/ring-signatures-poster.png new file mode 100644 index 00000000..1ba88285 Binary files /dev/null and b/img/ring-signatures-poster.png differ diff --git a/img/secure-monero.png b/img/secure-monero.png new file mode 100644 index 00000000..e120881e Binary files /dev/null and b/img/secure-monero.png differ diff --git a/img/stealth-address-poster.png b/img/stealth-address-poster.png new file mode 100644 index 00000000..d461e261 Binary files /dev/null and b/img/stealth-address-poster.png differ diff --git a/img/symas.png b/img/symas.png new file mode 100644 index 00000000..facfa269 Binary files /dev/null and b/img/symas.png differ diff --git a/img/untraceable-monero.png b/img/untraceable-monero.png new file mode 100644 index 00000000..777ea034 Binary files /dev/null and b/img/untraceable-monero.png differ diff --git a/index.html b/index.html new file mode 100644 index 00000000..01913b1e --- /dev/null +++ b/index.html @@ -0,0 +1,197 @@ +--- +layout: base +Title: Home +--- + +
+
+
+
+
+
+ + +
+ +
+
+
+

Monero

+

Private Digital Currency

+

Monero is a secure, private, untraceable currency. It is open-source and freely available to all. With Monero, you are your own bank. Only + you control and are responsible for your funds; your accounts + and transactions are kept private from prying eyes.

+

Get Started

+
+
+
+
+
+ + + +
+
+
+

Why Monero is different

+
+
+
+

Monero is secure.

+

Monero can't be hacked to steal your funds, due to the power of distributed consensus, which you can read about here. This means that you are responsible for your money, and don't have to trust any entity to keep it safe for you.

+
+
+ Secure safe +
+
+
+
+ No surveillance +
+
+

Monero is private.

+

The power of the blockchain usually increases security at the cost of privacy, but with Monero's sophisticated privacy-centric technology, you get all of the security benefits of the blockchain without any of the privacy trade-offs.

+
+ +
+
+
+

Monero is untraceable.

+

By taking advantage of ring signatures, Monero makes it ambiguous which funds have been spent, and thus extremely unlikely that a transaction could be linked to particular user.

+
+
+ Untraceable Monero paths +
+
+
+
+ Monero gold +
+
+

Monero is fungible.

+

Because of the on-by-default nature of the privacy technologies, Monero is fungible, meaning one Monero will always be equal to another. This means you won't hae to worry about Monero blacklisted by exchanges or vendors.

+
+
+
+
+ + + + + + + +
+
+ +
+
+
+

Downloads

+
+
+
+

Monero for Windows

+
+
+

Monero for Mac

+
+
+
+
+

Monero for Linux

+
+
+

Latest Blockchain

+
+
+
+

Need it for a different operating system? View all available downloads here.

+
+
+
+
+ + + +
+
+
+

Latest News

+
+
+ {% for post in site.posts limit:2 %} +
+
+

{{ post.title }}

+
+
+ {% endfor %} + + +
+
+

More news

+
+
+
+
+
+ +
+
+ + + + + +
+
+ +
+
+
+
+

Moneropedia

+

Would you like to look up the meanings of the terms and concepts used in Monero? Here you will find an alphabetical list of terms and their meanings from both the Monero and Kovri projects.

+

Read Moneropedia

+
+
+
+
+ + + +
+
+
+
+

User Guides

+

Step-by-step guides to all things Monero are separated by category and cover everything from creating a wallet, recovering a wallet, and even how to edit this website.

+

Read user guides

+
+
+
+
+ + + +
+
+
+
+

FAQ

+

We've heard a lot of questions over the years and have compiled, for your convenience, a thorough and varied FAQ. Don't worry, if your questions are not on here, you can always ask the community.

+

Read answers

+
+
+
+
+ +
+
+ + +
diff --git a/language.php b/language.php new file mode 100644 index 00000000..d564327b --- /dev/null +++ b/language.php @@ -0,0 +1,85 @@ + + + + + + + + + Monero - secure, private, and untraceable + + + + + + + + + + + + + + + + + +
+
+
+ +
+
+
    +

  • More to come...

    • +
+
+
+
+ +
+
+

+ Copyright © The Monero Project, +

+
+
+ + + + + + + diff --git a/legal/copyright.md b/legal/copyright.md new file mode 100644 index 00000000..b5c06d6f --- /dev/null +++ b/legal/copyright.md @@ -0,0 +1,24 @@ +--- +layout: custom +title: Legal +--- + +### The Monero Project + +The majority of the content on this website, including the Monero logo and our Monero Missive podcast, is released under the CC BY-SA 4.0 license (the [Creative Commons Attribution-ShareAlike 4.0 International license](https://creativecommons.org/licenses/by-sa/4.0/)). This means that you can copy and redistribute the material in any medium or format, and remix, transform, and build upon the material for any purpose, even commercially. However, when doing so you must give appropriate credit, provide a link to the license, and indicate if changes were made. You may do so in any reasonable manner, but not in any way that suggests The Monero Project endorses you or your use. + +### Icons and Other Attributed Items + +Where an icon is used we have attempted to find an icon in public domain or covered by a Creative Commons license. Attribution for the icon is given in HTML comments in the page source where appropriate and possible. + +Certain logos, such as those for the operating systems and platforms we support as well as those of our sponsors, are copyrighted by their owners. The Monero Project does not own these copyrights, and use these logos either with permission or in an unambiguous and unharmful way. + +### List of Icon Authors + +This is a list of original authors of some of the icons used on this website: + +- Freepik () +- Icomoon () +- Bogdan Rosu () +- Yannick () +- Icons8 () diff --git a/legal/index.md b/legal/index.md new file mode 100644 index 00000000..f73ace7f --- /dev/null +++ b/legal/index.md @@ -0,0 +1,175 @@ +--- +layout: custom +title: Legal +--- + +
+
+

Last revised: June 22nd, 2017

+
+ +
+
+ +
+
+
+
+

Terms of Use

+
+
+
+
+This website is operated by The Monero Project, a loose collective of individuals behind Monero. By visiting and using this website you will be accepting these Terms of Use ("TOU"). Please read them carefully and if you disagree with the TOU in any way, then do not use this website. The Monero Project reserves the right to post changes to the TOU on this website at any time, and by your continuing to use the website thereafter, you agree to be bound by the new version of the TOU. If any TOU changes are not acceptable, you must stop your use of this website. In these TOU, "The Monero Project" and "we" refers to The Monero Project, and "User" or "you" refers to each visitor to this website. "Monero" refers to the digital currency that can be used by the software available on this website. + +### Sites and Services + +We do not guarantee that access to or use of this website or any services will be uninterrupted or error free, and The Monero Project shall not be liable for any feature not being accessible or for any unavailability of its website and services. The website and its features may be expanded, limited or modified at any time by The Monero Project to meet the needs of its Users, or for technical or other reasons, without advance notice or reason. We may also in our sole discretion, and at any time, discontinue providing, temporarily or permanently, any or all of the website, without notice. To access some of the content or features of the website or its services, Users may need to enhance or update the hardware or software in their computer systems. The Monero Project assumes no responsibility for any failure to access the website or any services, partially or fully, whether due to the User's system, the Internet network or any other cause. + +### Minors + +We do not provide information or services to minors, and if you are under 18 you may only use this site with the active involvement of a parent, guardian or other supervising adult. + +### No Investment Advice + +This website does not provide individual or customized legal, tax, financial, or investment services. Since each individual's situation is unique, a qualified professional should be consulted before making financial decisions. Since Monero is meant to be used as a medium of exchange, nothing on this website constitutes investment advice or a solicitation to buy, hold, invest in, own, or use Monero. + +### Content Limitations + +We make no guarantees as to the accuracy, thoroughness or quality of the information on this website, which is provided only on an "AS-IS" and "AS AVAILABLE" basis at User's sole risk. This information may be provided by third parties and The Monero Project shall not be responsible or liable for any errors, omissions or inaccuracies in the website content. The information provided at this site are neither comprehensive nor appropriate for every individual. Some of the information is relevant only in certain parts of the world, and may not be relevant to or compliant with the laws, regulations or other legal requirements of other countries. It is your responsibility to determine whether, how and to what extent your intended use of the information and services will be technically and legally possible in the areas of the world where you intend to use them. You are advised to verify any information before using it for any personal, financial or business purpose. In addition, the opinions and views expressed in any forum post on this website are solely those of the author(s) of the article and do not reflect the opinions of The Monero Project. The website content and services may be modified at any time by us, without advance notice or reason, and The Monero Project shall have no obligation to notify you of any corrections or changes to any website content. + +### Proprietary Rights and License + +This website and its content are protected by copyright, trademark and other proprietary laws. For details please refer to our [Copyright section](#copyright). + +### Third Party Content + +Any testimonials, opinions, advice, product or service offers, or other information or content made available on or through this website by third parties ("Third Party Content") are solely those of their respective providers and not of The Monero Project which does not guarantee the accuracy, completeness, reliability or usefulness of Third Party Content. It is the responsibility of the User to evaluate Third Party Content and The Monero Project shall not be liable for any damage or loss caused by Users' reliance on or other use of Third Party Content. + +### Materials Posted by Users + +By posting or submitting any material to this website, including on the forum, you will be (a) granting The Monero Project a world-wide fully paid-up non-exclusive license to allow your materials to be edited and displayed by The Monero Project on its website, and accessed by Users, for the purposes and on the terms in these TOU, (b) agreeing to indemnify and hold harmless The Monero Project and its Users from any claim or demand made by any third party due to or arising out of your materials, and (c) representing that you own or otherwise have the right to post the materials, that the materials are accurate, that use of the materials on the The Monero Project website does not violate any laws, and that the materials will not cause injury to any person. The Monero Project shall have the right to use your name in connection with your posted materials. + +### Viruses and Malware + +The Monero Project takes many precautions to ensure the files available for downloading through this website are not tampered with, and where appropriate SHA hashes are provided for end users to confirm they have downloaded the correct file. Nonetheless, The Monero Project does not guarantee that files available for downloading through this website will be free of infection or viruses or other code that may have contaminating or destructive properties. You are responsible for implementing sufficient procedures and checkpoints to satisfy your particular requirements for integrity, security and accuracy of data input and output, and for maintaining a means external to the site for the reconstruction of any lost data. It is almost always advisable to check the SHA hashes of the files you have downloaded, and if in any doubt consider [compiling Monero from the source code](https://github.com/monero-project/bitmonero). + +### Sponsors and Advertisers are Not Endorsed + +Though we seek to partner with quality companies, we are not responsible for the claims or representations made by sponsors and advertisers. The Monero Project does not review, endorse or recommend the products or services of any company mentioned on our site. We will not be liable in any way for damages of any kind resulting out of the misuse of any personal information or data submitted by you to an sponsor or advertiser. + +### Offsite Links + +As a convenience to Users, the The Monero Project website and services may provide links to other sites or resources. Because we do not review or have no control over such sites and resources, The Monero Project shall not be responsible or liable for use of or reliance on any content, products, services or information at such sites or resources. Inclusion of any links does not imply any endorsement, affiliation, approval, association or sponsorship by The Monero Project of the linked websites, resources, their operators or owners. When you select a link, you may be leaving our website. The information available on Third Parties' websites may have certain restrictions on its use or distribution which differ from these TOU. + +### Password Protected Areas + +Some areas of the The Monero Project site ("Password Protected Areas"), primarily the Monero forum, are password protected and available only to Users who are registered on the Monero forum. Registration requires Users to fully complete the account registration process. The Monero Project reserves the right to deny or revoke registration or access to Password Protected Areas for any User. The Monero Project takes reasonable measures to ensure the security of the Password Protected Areas but cannot guarantee the absolute security of information or communications in such Password Protected Areas. Users are responsible for maintaining the security of the password they set and must notify us if they believe that the security of their password or account has been breached or subject to unauthorized use. Additional account security is available through the use of GPG authentication, and all users of any Password Protected Areas are encouraged to take advantage of this layer of protection. The Monero Project will not be liable for any loss or liability incurred as a result of an unauthorized person using a User's password. + +### Prohibited Conduct + +The following activities are strictly prohibited: + +- Spamming, advertising, soliciting or political campaigning +- Personal attacks on or abuse of any members, moderators, or administrators of the forum +- Postings for any unlawful or fraudulent purpose (including links) +- Posting of personal information (for yourself or anyone else) +- Phishing +- Posting materials containing viruses or other malicious or destructive code +- Posting of offensive content including profanity, obscenity, racist or pornographic material +- Posting of any materials that are defamatory or infringe any person's rights + +### Privacy + +This website may collect personal information from some Users. Because The Monero Project respects the privacy of its Users and their personal information, it has established the [Privacy Policy](#privacy-policy) to protect your personal information. + +### Communications + +When you visit our website or send us email, our responses to your communications will be by e-mail. All agreements, notices and communications that we provide to you by email will satisfy all legal requirements that they be in writing and delivered to you. The Monero Project will have the right to disclose any email sent by a User, or any objectionable material, to comply with legal process or to protect the rights or property of The Monero Project, its customers, suppliers and Users. + +### No Monero Financial Services + +This website does not store, sell, buy, send, or receive Monero. All activities related to the ownership and transfer of Monero currency units is done on the decentralized Monero network, of which this website is not an active participant. + +### No Liability for Monero Loss + +The Monero Project will not be responsible for any damages, claims, or losses arising from the use of Monero, including the actions or inactions or events related to third parties, security problems during the use of any Monero-related software or service, technical failures during the use of any Monero-related software or service, software or data corruption problems during the use of any Monero-related software or service, or user errors during the use of any Monero-related software or service. + +### DISCLAIMER OF WARRANTIES + +THE MONERO PROJECT DISCLAIMS ALL WARRANTIES, REPRESENTATIONS AND CONDITIONS OF ANY KIND, WHETHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO THE IMPLIED WARRANTIES AND CONDITIONS OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT, WITH RESPECT TO THE USE OF THIS WEBSITE AND ITS SERVICES, OR THE ACCURACY, COMPLETENESS, TIMELINESS OR CURRENTNESS OF ITS CONTENT, IN ANY WAY AND FOR ANY PURPOSE. + +### EXCLUSION OF CONSEQUENTIAL DAMAGES + +IN NO EVENT WILL THE MONERO PROJECT BE LIABLE FOR ANY INCIDENTAL, INCIDENTAL, SPECIAL, CONSEQUENTIAL, EXEMPLARY OR INDIRECT DAMAGES ARISING OUT OF THE USE OF OR INABILITY TO USE THIS WEBSITE OR ANY OF ITS SERVICES OR CONTENT, OR LOSS OF DATA, EVEN IF THE MONERO PROJECT HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES, AND WHETHER BASED ON CONTRACT, TORT, NEGLIGENCE, PRODUCT LIABILITY, STRICT LIABILITY OR OTHERWISE. + +### EXCLUSION OF LIMITATIONS AND DISCLAIMERS + +BECAUSE SOME JURISDICTIONS DO NOT ALLOW THE DISCLAIMER OF WARRANTIES, OR THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES, IN SUCH JURISDICTIONS THE MONERO PROJECT'S LIABILITY IS LIMITED TO THE GREATEST EXTENT PERMITTED BY LAW. + +### General + +These TOU, and any applicable TOS, constitute the entire agreement between each User and The Monero Project governing the User's access to and use of the website and its services, and supersede all prior agreements regarding its subject matter. The TOU shall be governed by the laws of the Republic of South Africa without giving effect to any principles of conflicts of laws. Each User hereby attorns and agrees to the non-exclusive jurisdiction of the courts of the Western Cape, South Africa. The failure by a User or The Monero Project to exercise any right or to enforce any provision of the TOU shall not constitute a waiver of such right or provision. If any provision of the TOU is found by a court of competent jurisdiction to be invalid or unenforceable, the court shall give effect to the intentions reflected in the provision to the degree possible, and the other provisions of the TOU will remain in full force and effect. It is the express will of The Monero Project and each User that the TOU and any applicable TOS have been prepared in English. +
+
+
+
+ +
+
+ + +
+
+ +
+
+
+
+

Privacy Policy

+
+
+
+
+### What We Collect + +The Monero Project uses Google Analytics to collect usage and visitor data for this website. This is enabled via a small piece of JavaScript code, and will not run if you have JavaScript disabled. We also collect standard server logs from our webserver. + +### What We Use the Data For + +The Google Analytics data is used to provide statistics on the website and help us to improve the content and the information flow. + +Server logs are used to analyse errors and diagnose requests to dead links. A portion of the server logs are used to gather statistics on Monero downloads in order to help us better understand our user's needs. +
+
+
+
+ +
+
+ diff --git a/legal/privacy.md b/legal/privacy.md new file mode 100644 index 00000000..1909ff15 --- /dev/null +++ b/legal/privacy.md @@ -0,0 +1,24 @@ +--- +layout: static_page +title: "Privacy" +title-pre-kick: "Privacy " +title-kick: "Policy" +title-post-kick: "" +kick-class: "green-kicks" +icon: "icon_privacy" +attribution: "" +--- + +### What We Collect + +The Monero Project uses Google Analytics to collect usage and visitor data for this website. This is enabled via a small piece of JavaScript code, and will not run if you have JavaScript disabled. + +We also collect standard server logs from our webserver. We do not collect cookies anywhere on the site except when using the Monero forum (located at [forum.getmonero.org](https://forum.getmonero.org)). + +### What We Use the Data For + +The Google Analytics data is used to provide statistics on the website and help us to improve the content and the information flow. + +Server logs are used to analyse errors and diagnose requests to dead links. A portion of the server logs are used to gather statistics on Monero downloads in order to help us better understand our user's needs. + +The cookies used on the Monero forum are used to identify returning users who have opted in to have their user session active for a period of time, as well as logged in users actively using the forum. diff --git a/legal/terms.md b/legal/terms.md new file mode 100644 index 00000000..0d6a55c5 --- /dev/null +++ b/legal/terms.md @@ -0,0 +1,105 @@ +--- +layout: static_page +title: "Terms of Use" +title-pre-kick: "Terms of " +title-kick: "Use" +title-post-kick: "" +kick-class: "red-kicks" +icon: "icon_terms" +attribution: "" +--- + +### Terms of Use + +*Last revised: February 18th, 2014* + +This website is operated by The Monero Project, a loose collective of individuals behind Monero. By visiting and using this website you will be accepting these Terms of Use ("TOU"). Please read them carefully and if you disagree with the TOU in any way, then do not use this website. The Monero Project reserves the right to post changes to the TOU on this website at any time, and by your continuing to use the website thereafter, you agree to be bound by the new version of the TOU. If any TOU changes are not acceptable, you must stop your use of this website. In these TOU, "The Monero Project" and "we" refers to The Monero Project, and "User" or "you" refers to each visitor to this website. "Monero" refers to the digital currency that can be used by the software available on this website. + +#### Sites and Services + +We do not guarantee that access to or use of this website or any services will be uninterrupted or error free, and The Monero Project shall not be liable for any feature not being accessible or for any unavailability of its website and services. The website and its features may be expanded, limited or modified at any time by The Monero Project to meet the needs of its Users, or for technical or other reasons, without advance notice or reason. We may also in our sole discretion, and at any time, discontinue providing, temporarily or permanently, any or all of the website, without notice. To access some of the content or features of the website or its services, Users may need to enhance or update the hardware or software in their computer systems. The Monero Project assumes no responsibility for any failure to access the website or any services, partially or fully, whether due to the User's system, the Internet network or any other cause. + +#### Minors + +We do not provide information or services to minors, and if you are under 18 you may only use this site with the active involvement of a parent, guardian or other supervising adult. + +#### No Investment Advice + +This website does not provide individual or customized legal, tax, financial, or investment services. Since each individual's situation is unique, a qualified professional should be consulted before making financial decisions. Since Monero is meant to be used as a medium of exchange, nothing on this website constitutes investment advice or a solicitation to buy, hold, invest in, own, or use Monero. + +#### Content Limitations + +We make no guarantees as to the accuracy, thoroughness or quality of the information on this website, which is provided only on an "AS-IS" and "AS AVAILABLE" basis at User's sole risk. This information may be provided by third parties and The Monero Project shall not be responsible or liable for any errors, omissions or inaccuracies in the website content. The information provided at this site are neither comprehensive nor appropriate for every individual. Some of the information is relevant only in certain parts of the world, and may not be relevant to or compliant with the laws, regulations or other legal requirements of other countries. It is your responsibility to determine whether, how and to what extent your intended use of the information and services will be technically and legally possible in the areas of the world where you intend to use them. You are advised to verify any information before using it for any personal, financial or business purpose. In addition, the opinions and views expressed in any forum post on this website are solely those of the author(s) of the article and do not reflect the opinions of The Monero Project. The website content and services may be modified at any time by us, without advance notice or reason, and The Monero Project shall have no obligation to notify you of any corrections or changes to any website content. + +#### Proprietary Rights and License + +This website and its content are protected by copyright, trademark and other proprietary laws. For details please refer to our [Copyrights notice](/legal/copyright). + +#### Third Party Content + +Any testimonials, opinions, advice, product or service offers, or other information or content made available on or through this website by third parties ("Third Party Content") are solely those of their respective providers and not of The Monero Project which does not guarantee the accuracy, completeness, reliability or usefulness of Third Party Content. It is the responsibility of the User to evaluate Third Party Content and The Monero Project shall not be liable for any damage or loss caused by Users' reliance on or other use of Third Party Content. + +#### Materials Posted by Users + +By posting or submitting any material to this website, including on the forum, you will be (a) granting The Monero Project a world-wide fully paid-up non-exclusive license to allow your materials to be edited and displayed by The Monero Project on its website, and accessed by Users, for the purposes and on the terms in these TOU, (b) agreeing to indemnify and hold harmless The Monero Project and its Users from any claim or demand made by any third party due to or arising out of your materials, and (c) representing that you own or otherwise have the right to post the materials, that the materials are accurate, that use of the materials on the The Monero Project website does not violate any laws, and that the materials will not cause injury to any person. The Monero Project shall have the right to use your name in connection with your posted materials. + +#### Viruses and Malware + +The Monero Project takes many precautions to ensure the files available for downloading through this website are not tampered with, and where appropriate SHA hashes are provided for end users to confirm they have downloaded the correct file. Nonetheless, The Monero Project does not guarantee that files available for downloading through this website will be free of infection or viruses or other code that may have contaminating or destructive properties. You are responsible for implementing sufficient procedures and checkpoints to satisfy your particular requirements for integrity, security and accuracy of data input and output, and for maintaining a means external to the site for the reconstruction of any lost data. It is almost always advisable to check the SHA hashes of the files you have downloaded, and if in any doubt consider [compiling Monero from the source code](https://github.com/monero-project/bitmonero). + +#### Sponsors and Advertisers are Not Endorsed + +Though we seek to partner with quality companies, we are not responsible for the claims or representations made by sponsors and advertisers. The Monero Project does not review, endorse or recommend the products or services of any company mentioned on our site. We will not be liable in any way for damages of any kind resulting out of the misuse of any personal information or data submitted by you to an sponsor or advertiser. + +#### Offsite Links + +As a convenience to Users, the The Monero Project website and services may provide links to other sites or resources. Because we do not review or have no control over such sites and resources, The Monero Project shall not be responsible or liable for use of or reliance on any content, products, services or information at such sites or resources. Inclusion of any links does not imply any endorsement, affiliation, approval, association or sponsorship by The Monero Project of the linked websites, resources, their operators or owners. When you select a link, you may be leaving our website. The information available on Third Parties' websites may have certain restrictions on its use or distribution which differ from these TOU. + +#### Password Protected Areas + +Some areas of the The Monero Project site ("Password Protected Areas"), primarily the Monero forum, are password protected and available only to Users who are registered on the Monero forum. Registration requires Users to fully complete the account registration process. The Monero Project reserves the right to deny or revoke registration or access to Password Protected Areas for any User. The Monero Project takes reasonable measures to ensure the security of the Password Protected Areas but cannot guarantee the absolute security of information or communications in such Password Protected Areas. Users are responsible for maintaining the security of the password they set and must notify us if they believe that the security of their password or account has been breached or subject to unauthorized use. Additional account security is available through the use of GPG authentication, and all users of any Password Protected Areas are encouraged to take advantage of this layer of protection. The Monero Project will not be liable for any loss or liability incurred as a result of an unauthorized person using a User's password. + +#### Prohibited Conduct + +The following activities are strictly prohibited: + +- Spamming, advertising, soliciting or political campaigning +- Personal attacks on or abuse of any members, moderators, or administrators of the forum +- Postings for any unlawful or fraudulent purpose (including links) +- Posting of personal information (for yourself or anyone else) +- Phishing +- Posting materials containing viruses or other malicious or destructive code +- Posting of offensive content including profanity, obscenity, racist or pornographic material +- Posting of any materials that are defamatory or infringe any person's rights + +#### Privacy + +This website may collect personal information from some Users. Because The Monero Project respects the privacy of its Users and their personal information, it has established the [Privacy Policy](/legal/privacy) to protect your personal information. + +#### Communications + +When you visit our website or send us email, our responses to your communications will be by e-mail. All agreements, notices and communications that we provide to you by email will satisfy all legal requirements that they be in writing and delivered to you. The Monero Project will have the right to disclose any email sent by a User, or any objectionable material, to comply with legal process or to protect the rights or property of The Monero Project, its customers, suppliers and Users. + +#### No Monero Financial Services + +This website does not store, sell, buy, send, or receive Monero. All activities related to the ownership and transfer of Monero currency units is done on the decentralized Monero network, of which this website is not an active participant. + +#### No Liability for Monero Loss + +The Monero Project will not be responsible for any damages, claims, or losses arising from the use of Monero, including the actions or inactions or events related to third parties, security problems during the use of any Monero-related software or service, technical failures during the use of any Monero-related software or service, software or data corruption problems during the use of any Monero-related software or service, or user errors during the use of any Monero-related software or service. + +#### DISCLAIMER OF WARRANTIES + +THE MONERO PROJECT DISCLAIMS ALL WARRANTIES, REPRESENTATIONS AND CONDITIONS OF ANY KIND, WHETHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO THE IMPLIED WARRANTIES AND CONDITIONS OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT, WITH RESPECT TO THE USE OF THIS WEBSITE AND ITS SERVICES, OR THE ACCURACY, COMPLETENESS, TIMELINESS OR CURRENTNESS OF ITS CONTENT, IN ANY WAY AND FOR ANY PURPOSE. + +#### EXCLUSION OF CONSEQUENTIAL DAMAGES + +IN NO EVENT WILL THE MONERO PROJECT BE LIABLE FOR ANY INCIDENTAL, INCIDENTAL, SPECIAL, CONSEQUENTIAL, EXEMPLARY OR INDIRECT DAMAGES ARISING OUT OF THE USE OF OR INABILITY TO USE THIS WEBSITE OR ANY OF ITS SERVICES OR CONTENT, OR LOSS OF DATA, EVEN IF THE MONERO PROJECT HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES, AND WHETHER BASED ON CONTRACT, TORT, NEGLIGENCE, PRODUCT LIABILITY, STRICT LIABILITY OR OTHERWISE. + +#### EXCLUSION OF LIMITATIONS AND DISCLAIMERS + +BECAUSE SOME JURISDICTIONS DO NOT ALLOW THE DISCLAIMER OF WARRANTIES, OR THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES, IN SUCH JURISDICTIONS THE MONERO PROJECT'S LIABILITY IS LIMITED TO THE GREATEST EXTENT PERMITTED BY LAW. + +#### General + +These TOU, and any applicable TOS, constitute the entire agreement between each User and The Monero Project governing the User's access to and use of the website and its services, and supersede all prior agreements regarding its subject matter. The TOU shall be governed by the laws of the Republic of South Africa without giving effect to any principles of conflicts of laws. Each User hereby attorns and agrees to the non-exclusive jurisdiction of the courts of the Western Cape, South Africa. The failure by a User or The Monero Project to exercise any right or to enforce any provision of the TOU shall not constitute a waiver of such right or provision. If any provision of the TOU is found by a court of competent jurisdiction to be invalid or unenforceable, the court shall give effect to the intentions reflected in the provision to the degree possible, and the other provisions of the TOU will remain in full force and effect. It is the express will of The Monero Project and each User that the TOU and any applicable TOS have been prepared in English. diff --git a/media/Monero - Ring Signatures.m4v b/media/Monero - Ring Signatures.m4v new file mode 100644 index 00000000..7b3fab67 Binary files /dev/null and b/media/Monero - Ring Signatures.m4v differ diff --git a/media/Monero - Stealth Addresses.m4v b/media/Monero - Stealth Addresses.m4v new file mode 100644 index 00000000..bd9c9a1d Binary files /dev/null and b/media/Monero - Stealth Addresses.m4v differ diff --git a/media/Monero - The Essentials.m4v b/media/Monero - The Essentials.m4v new file mode 100644 index 00000000..2b29b580 Binary files /dev/null and b/media/Monero - The Essentials.m4v differ diff --git a/media/Monero_Promo.m4v b/media/Monero_Promo.m4v new file mode 100644 index 00000000..d208c6da Binary files /dev/null and b/media/Monero_Promo.m4v differ diff --git a/meta/android-chrome-192x192.png b/meta/android-chrome-192x192.png new file mode 100644 index 00000000..4ae0b0c5 Binary files /dev/null and b/meta/android-chrome-192x192.png differ diff --git a/meta/android-chrome-512x512.png b/meta/android-chrome-512x512.png new file mode 100644 index 00000000..82801658 Binary files /dev/null and b/meta/android-chrome-512x512.png differ diff --git a/meta/apple-touch-icon.png b/meta/apple-touch-icon.png new file mode 100644 index 00000000..e79d4a51 Binary files /dev/null and b/meta/apple-touch-icon.png differ diff --git a/meta/favicon-16x16.png b/meta/favicon-16x16.png new file mode 100644 index 00000000..ee2b8c34 Binary files /dev/null and b/meta/favicon-16x16.png differ diff --git a/meta/favicon-32x32.png b/meta/favicon-32x32.png new file mode 100644 index 00000000..7268f820 Binary files /dev/null and b/meta/favicon-32x32.png differ diff --git a/meta/favicons.png b/meta/favicons.png new file mode 100644 index 00000000..aed7c336 Binary files /dev/null and b/meta/favicons.png differ diff --git a/meta/manifest.json b/meta/manifest.json new file mode 100644 index 00000000..4fbe1818 --- /dev/null +++ b/meta/manifest.json @@ -0,0 +1,18 @@ +{ + "name": "", + "icons": [ + { + "src": "/android-chrome-192x192.png", + "sizes": "192x192", + "type": "image/png" + }, + { + "src": "/android-chrome-512x512.png", + "sizes": "512x512", + "type": "image/png" + } + ], + "theme_color": "#ffffff", + "background_color": "#ffffff", + "display": "standalone" +} \ No newline at end of file diff --git a/meta/mstile-144x144.png b/meta/mstile-144x144.png new file mode 100644 index 00000000..ac51704b Binary files /dev/null and b/meta/mstile-144x144.png differ diff --git a/meta/mstile-150x150.png b/meta/mstile-150x150.png new file mode 100644 index 00000000..95d01449 Binary files /dev/null and b/meta/mstile-150x150.png differ diff --git a/meta/mstile-310x150.png b/meta/mstile-310x150.png new file mode 100644 index 00000000..f1b3cb0b Binary files /dev/null and b/meta/mstile-310x150.png differ diff --git a/meta/mstile-310x310.png b/meta/mstile-310x310.png new file mode 100644 index 00000000..9039cc06 Binary files /dev/null and b/meta/mstile-310x310.png differ diff --git a/meta/mstile-70x70.png b/meta/mstile-70x70.png new file mode 100644 index 00000000..31d28ee9 Binary files /dev/null and b/meta/mstile-70x70.png differ diff --git a/meta/safari-pinned-tab.svg b/meta/safari-pinned-tab.svg new file mode 100644 index 00000000..42341a3f --- /dev/null +++ b/meta/safari-pinned-tab.svg @@ -0,0 +1,22 @@ + + + + +Created by potrace 1.11, written by Peter Selinger 2001-2013 + + + + + + diff --git a/resources/about.md b/resources/about.md new file mode 100644 index 00000000..e800f5b8 --- /dev/null +++ b/resources/about.md @@ -0,0 +1,65 @@ +--- +layout: static_page +title: "About Monero" +title-pre-kick: "About " +title-kick: "Monero" +title-post-kick: "" +kick-class: "kicks" +icon: "icon_about" +attribution: "" +--- + + + + +## About Monero + +To most people, financial privacy is very important. Yet in recent years, we have seen a staggering amount of big corporations, banks and governments have their records compromised, each time leaking information about their users, their practices, and their balance sheets. The unfortunate but undeniable conclusion is that there is no safe place to conduct private transactions. +There *was* no safe place to conduct private transactions. Monero provides a place where your financial activities are private. Monero is one of the leading cryptocurrencies in the post-Bitcoin world, and it is built on principles of privacy, decentralization, and scalability. +From an economic point of view, a currency needs to be fungible. Fungibility is a property of money that makes all units "equal." Without fungibility, money flows can be tracked and tainted, making it very difficult to use the digital tokens as money. + +Monero is a secure, private, untraceable currency. It is open source, freely available to all, and was fairly launched on April 18th, 2014, without premine or instamine. +The technology behind Monero has already spiked the interest of several established people in the Bitcoin development world and the cryptography community. +Monero development is completely donation-based and community-driven, with a strong focus on decentralization and scalability. +With Monero, you are your own bank. Only you control and are responsible for your funds, and your accounts and transactions are kept private from prying eyes. + +Read on to find out how Monero is helping to solve real problems and limitations of existing cryptocurrencies, and building a more private blockchain. + +## PRIVACY + +Monero seeks to provide absolute transactional privacy in an effort to create true electronic cash. With Bitcoin, as well as with the vast majority of cryptocurrencies that have been established since, any and all transactions are entirely traceable. Any casual observer can read through the Bitcoin blockchain, and for any transaction, this observer can find out the exact amount that was transacted, as well as the precise transaction origin (sender address) and destination (recipient address). + +With Monero, for any private transaction, the same observer has no means to uncover the origin, destination, or amount transacted. As such, transactions on the Monero blockchain, are private and fundamentally untraceable. +But Monero is more than a currency. Driving the official slogan - “secure, private, untraceable” - are a multitude of applications where the parties involved wish to remain private. The Monero blockchain can keep confidential contracts confidential. Since the forthcoming, blockchain-powered internet of things will place the cloud all around us, it is then increasingly important that open access tools like Monero exist to provide a secure boundary for private settlements. + +An often overlooked, but nonetheless important layer of privacy in a connected world, is that of the networking infrastructure. We have teamed up with Privacy Solutions, and development is well underway to incorporate an i2p router in Monero. In a world where ill-intentioned governments and ISPs can void an individual’s basic privacy rights on a whim, it then becomes necessary to establish a private communication platform. + +The underlying technologies and cryptography upon which Monero is built, has been (and continues to be) the subject of extensive analysis and review by numerous individuals and research groups. It has garnered favorable attention by some of the most prominent figures of the Bitcoin and cryptography world, such as Andrew Poelstra (andytoshi), Gregory Maxwell, and Nicolas Courtois. + +With Monero, transactions are private by default. However, each user has the ability to select different levels of privacy, optionally disclosing their transaction information, or even provide audit access (view only) to their full Monero account. + +## DECENTRALIZATION +While most cryptocurrencies align to theoretical principles of decentralization, the reality is that most fall short of such a claim. More often than not, it is not just one branch of a cryptocurrency system that is centralized in one form or another, it is that many branches are so. + +With Proof of Stake currencies, irregular emission and distribution models cause most of the staking power to end up in the hands of a privileged few. Participants of lesser weight are reduced to second class citizens, with little chance of ever obtaining similar returns. + +With Proof of Work currencies, of which Bitcoin remains the most significant reference, the mining process is largely concentrated in a handful of pools. This centralization of mining power, combined with a transparent blockchain, has already lead to various occurrences of transaction censorship. + +Other currencies opt for a closed development model, thus centralizing the invention process itself. These closed platforms commonly fail to meet any form of public audit or expert review. More importantly, these are platforms that will at anytime swing left and right, in order to satisfy the interests of the restricted group that holds control of development. + +Monero contrasts with these examples in various and meaningful ways. Monero is powered strictly by Proof of Work, but specifically, it employs a mining algorithm that has the potential to be efficiently tasked to billions of existing devices (any modern x86 CPU). +This very characteristic, and more so once it is coupled with @Smart Mining, has the potential to ensure that for long years to come, the process of mining new Monero coins is within reach of the common individual, not an exclusive opportunity to the owners of large mining operations. + +Furthermore, as transactions are private by default on the Monero blockchain, transaction censorship is inherently void. +The Monero development landscape, on the other hand, is very much the opposite of a closed or restricted access model. The core branch currently enjoys more than 30 contributors, pushing 1000+ commits over the past year. The project is happy to take on new contributors and any future plans, long-term direction and priorities are openly discussed with the community. Indeed, the policy that governs contribution to the Monero codebase is exhaustingly inclusive - all contributions are accepted into the development branch, where new code can be scrutinized and tested by the entire community. + +Most contributors in the Monero development landscape are quite passionate for an open source philosophy, and in this rich creative environment, new projects have sparked to life. @OpenAlias is one notable example, which has seen adoption by (amongst others) a major Bitcoin-related software product. + +## SCALEABILITY +One of the problems with cryptocurrencies is scaleability. Most cryptocurrencies are derived from the Bitcoin codebase and thus have a "block size limit." This limit has become a big issue in the Bitcoin community and led to fierce discussions. +Monero doesn't suffer from this block size debate, because it has a dynamic block size limit. This limit is automatically recalculated regularly based on a look-back window. A penalty system prevents out of control growth of the block size. +Another issue with most cryptocurrencies is the development of a fee market. This issue is somewhat linked to the block size debate: the narrative is that when you limit the block size, a fee market will eventually develop. But this claim is highly debatable. When the transaction fees are supposed to be the main incentive for miners to secure the blockchain, it is possible the current consensus model will not be sustainable. At the moment, miners still act as they are expected: they mine on the longest chain. When they don't do that, they risk losing the block reward. But when that block reward becomes small compared to the mining fees, it's possible miners will have an incentive to not mine on the longest chain and start a fork trying to "steal" high transaction fees which were included in the latest blocks. Therefore, Monero implements a "permanent block reward." The block reward will never drop below 0.3 XMR, making Monero a disinflationary currency: the inflation will be roughly 1% in 2022 and go down forever, but the nominal inflation will stay at 0.3 XMR per minute. This means that there will always be an incentive for miners to mine Monero and thus keeping the blockchain secure, with or without a fee market. + +## FUNGIBILITY +Fungibility is an important property of any functioning currency. You can try to hide your bitcoins as much as you want, if you tried to mix your non-fungible coins using a mixer, coinjoin or another type of "anonymity enhancing feature," these transactions can still be flagged as "possible suspicious activity on the blockchain," even if you are anonymous. Using non-fungible tokens as currency can eventually lead to blacklisting/whitelisting either by governments or through self-censorship. Some examples of these measures could be payment processors or exchanges refusing your tainted coins as a payment or deposit or miners refusing to include your suspicious transaction. +On the other hand, Monero transaction outputs have "plausible deniability" about their state: you can't tell if they are spent or unspent in a certain transaction or not. This leads to an opaque (non-transparent) blockchain making all coins "equal." @Fungibility is built into Monero at protocol level, making it real "digital cash." diff --git a/resources/about/index.md b/resources/about/index.md new file mode 100644 index 00000000..125e13ad --- /dev/null +++ b/resources/about/index.md @@ -0,0 +1,61 @@ +--- +layout: custom +title: "About Monero" +--- + +
+
+
+ +
+
+
+
+

A Brief History

+
+
+
+ +Monero was launched in April 2014. It was a fair, pre-announced launch of the CryptoNote reference code. There was no premine or instantmine, and no portion of the block reward goes to development. See the original Bitcointalk thread here. The founder, thankful_for_today, proposed some controversial changes that the community disagreed with. A fallout ensued, and the Monero Core Team forked the project with the community following this new Core Team. This Core Team has provided oversight since. + +Monero has made several large improvements since launch. The blockchain was migrated to a different database structure to provide greater efficiency and flexibility, minimum ring signature sizes were set so that all transactions were private by mandate, and RingCT was implemented to hide the transaction amounts. Nearly all improvements have provided improvements to security or privacy, or they have facilitated use. Monero continues to develop with goals of privacy and security first, ease of use and efficiency second. + +
+
+
+ +
+
+ +
+
+
+
+

Our Values

+
+
+ +
+ +Monero is more than just a technology. It’s also what the technology stands for. Some of the important guiding philosophies are listed below. + +### Security + +Users must be able to trust Monero with their transactions, without risk of error or attack. Monero gives the full block reward to the miners, who are the most critical members of the network who provide this security. Transactions are cryptographically secure using the latest and most resilient encryption tools available. + +### Privacy + +Monero takes privacy seriously. Monero needs to be able to protect users in a court of law and, in extreme cases, from the death penalty. This level of privacy must be completely accessible to all users, whether they are technologically competent or have no idea how Monero works. A user needs to confidently trust Monero in a way that this person does not feel pressured into changing their spending habits for risk of others finding out. + +### Decentralization + +Monero is committed to providing the maximum amount of decentralization. With Monero, you do not have to trust anyone else on the network, and it is not run by any large group. An accessible “Proof of Work” algorithm makes it easy to mine Monero on normal computers, which makes it more difficult for someone to purchase a large amount of mining power. Nodes connect to each other with I2P to lower the risks of revealing sensitive transaction information and censorship (tba). Development decisions are extremely clear and open to public discussion. Developer meeting logs are published online in their entirety and visible by all. + +
+
+
+ + + +
+
\ No newline at end of file diff --git a/resources/about2.md b/resources/about2.md new file mode 100644 index 00000000..a85c5e35 --- /dev/null +++ b/resources/about2.md @@ -0,0 +1,41 @@ +--- +layout: static_page +title: "About Monero" +title-pre-kick: "About " +title-kick: "Monero" +title-post-kick: "" +kick-class: "kicks" +icon: "icon_about" +attribution: "" +--- +## About Monero + +To most people, financial privacy is very important. Yet in recent years, we have seen a staggering amount of big corporations, banks and governments having their records compromised, at every time leaking information about their users, their practices, their balance sheets. The unfortunate but undeniable conclusion is that there is no safe place to conduct private transactions. +There was no safe place to conduct private transactions. Monero provides a place where your financial activities are private. +Monero is one of the leading cryptocurrencies in the post-Bitcoin world, and it is built on principles of privacy, decentralization, and scalability. +Read on to find out how Monero is helping to solve real problems and limitations of existing cryptocurrencies, and building a more private blockchain. + +## PRIVACY + +Monero seeks to provide absolute transactional privacy in an effort to create true electronic cash. +With Bitcoin, as well as with the vast majority of cryptocurrencies that have been established since, any and all transactions are entirely traceable. Any casual observer can read through the Bitcoin blockchain, and for any transaction, this observer can find out the exact amount that was transacted, as well as the precise transaction origin (sender address) and destination (recipient address). +With Monero, for any private transaction[1], the same observer has no means to uncover the origin, destination, or amount transacted. As such, transactions on the Monero blockchain, are private and fundamentally untraceable. +But Monero is more than a currency. Driving the official slogan: “secure, private, untraceable”, there are a multitude of applications where the parties involved wish to remain private. The Monero blockchain can keep confidential contracts, well… confidential. While the forthcoming, blockchain-powered internet of things will certainly place the cloud all around us, it is then increasingly important that open access tools exist to provide a secure boundary for private settlements. +An often overlooked, but nonetheless important layer of privacy in a connected world, is that of the networking infrastructure. We have teamed up with Privacy Solutions, and development is well underway to incorporate an i2p router in Monero. In a world where ill intentioned governments and ISPs can void an individual’s basic privacy rights on a whim, it then becomes necessary to establish a private communication platform. +The underlying technologies and cryptography upon which Monero is built, has been (and continues to be) the subject of extensive analysis and review by numerous individuals and research groups. It has garnered favorable attention by some of the most prominent figures of the Bitcoin & cryptography world, such as Andrew Poelstra (andytoshi), Gregory Maxwell & Nicolas Courtois. +[1] With Monero, transactions are private by default. However, each user has the ability to select different levels of privacy, optionally exposing the amount of a given (own) transaction, or even provide audit access (view only) to his full Monero account. + +## DECENTRALIZATION +While most cryptocurrencies align to theoretical principles of decentralization, the reality is, that most fall short of such a claim. More often than not, it is not just one branch of a cryptocurrency system that is centralized in one form or another, is that that many branches are so. +With Proof of Stake currencies, irregular emission and distribution models cause most of the staking power to end up in the hand of a privileged few. Participants of lesser weight are reduced to second class citizens, with little chance of ever obtaining similar returns. +With Proof of Work currencies, of which Bitcoin remains the most significant reference, the mining process is largely concentrated in a handful of pools. This centralization of mining power, combined with a transparent blockchain, has already lead to various occurrences of transaction censorship. +Other currencies opt for a closed development model, thus centralizing the invention process itself. These closed platforms commonly fail to meet any form of public audit or expert review. More importantly, these are platforms that will anytime swing left and right, in order to satisfy the interests of the restricted group that holds control of development. +Monero contrasts with these examples in various and meaningful ways. +Monero is powered strictly by Proof of Work, but specifically, it employs a mining algorithm that has the potential to be efficiently tasked to billions of existing devices (any modern x86 CPU). +This very characteristic, and more so once it is coupled with Smart Mining[2], has the potential to ensure that for long years to come, the process of mining new Monero coins is within reach of the common individual, and not an exclusive opportunity to the owners of large mining operations. +Further, as transactions are private by default on the Monero blockchain, transaction censorship is inherently void. +The Monero development landscape on the other hand, is very much the opposite of a closed or restricted access model. The core branch currently enjoys more than 30 contributors, pushing 1000+ commits over the past year {there has to be better stats to put in there}. The project is happy to take on new contributors and any future plans, long term direction and priorities are openly discussed with the community. Indeed, the policy that governs contribution to the Monero codebase is exhaustingly inclusive - all contributions are accepted into the development branch, where new code can be scrutinized and tested by the entire community. +Most contributors in the Monero development landscape are quite passionate for an open source philosophy, and in this rich creative environment, new projects have sparked to life. OpenAlias[3] is one notable example, which has seen adoption by (amongst others) a major Bitcoin related software product. + +[2] {Insert a neat description of Smart Mining here.} +[3] {Insert a neat description of Open Alias here.} \ No newline at end of file diff --git a/resources/developer-guides/daemon-rpc.md b/resources/developer-guides/daemon-rpc.md new file mode 100644 index 00000000..615cdc0b --- /dev/null +++ b/resources/developer-guides/daemon-rpc.md @@ -0,0 +1,788 @@ +--- +layout: static_page +title: "Daemon RPC documentation" +title-pre-kick: "Developer Guide: " +title-kick: "Daemon RPC documentation " +title-post-kick: "" +kick-class: "green-kicks" +icon: "icon_client" +attribution: "" +--- + +## Introduction + +This is a list of the monerod daemon RPC calls, their inputs and outputs, and examples of each. + +Many RPC calls use the daemon's JSON RPC interface while others use their own interfaces, as demonstrated below. + +Note: "atomic units" refer to the smallest fraction of 1 XMR according to the monerod implementation. **1 XMR = 1e12 atomic units.** + +### [JSON RPC Methods](#json-rpc-methods): + +* [getblockcount](#getblockcount) +* [on_getblockhash](#ongetblockhash) +* [getblocktemplate](#getblocktemplate) +* [submitblock](#submitblock) +* [getlastblockheader](#getlastblockheader) +* [getblockheaderbyhash](#getblockheaderbyhash) +* [getblockheaderbyheight](#getblockheaderbyheight) +* [getblock](#getblock) +* [get_connections](#getconnections) +* [get_info](#getinfo) +* [hard_fork_info](#hardforkinfo) +* [setbans](#setbans) +* [getbans](#getbans) + +### [Other RPC Methods](#other-daemon-rpc-calls): + +* [/getheight](#getheight) +* [/gettransactions](#gettransactions) +* [/is_key_image_spent](#iskeyimagespent) +* [/sendrawtransaction](#sendrawtransaction) +* [/get_transaction_pool](#gettransactionpool) +* [/stop_daemon](#stopdaemon) + + +--- + +## JSON RPC Methods + +The majority of monerod RPC calls use the daemon's `json_rpc` interface to request various bits of information. These methods all follow a similar structure, for example: + + IP=127.0.0.1 + PORT=18081 + METHOD='getblockheaderbyheight' + PARAMS='{"height":912345}' + curl \ + -X POST http://$IP:$PORT/json_rpc \ + -d '{"jsonrpc":"2.0","id":"0","method":"'$METHOD'","params":'$PARAMS'}' \ + -H 'Content-Type: application/json' + +Some methods include parameters, while others do not. Examples of each JSON RPC method follow. + +### getblockcount + +Look up how many blocks are in the longest chain known to the node. + +Inputs: *None*. + +Outputs: + +* *count* - unsigned int; Number of blocks in longest chain seen by the node. +* *status* - string; General RPC error code. "OK" means everything looks good. + +Example: + +{:.cli-code} +[ monero->~ ]$ curl -X POST http://127.0.0.1:18081/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"getblockcount"}' -H 'Content-Type: application/json' +{ + "id": "0", + "jsonrpc": "2.0", + "result": { + "count": 993163, + "status": "OK" + } +} + + +### on_getblockhash + +Look up a block's hash by its height. + +Inputs: + +* block height (int array of length 1) + +Outputs: + +* block hash (string) + +Example: + +{:.cli-code} +[ monero->~ ]$ curl -X POST http://127.0.0.1:18081/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"on_getblockhash","params":[912345]}' -H 'Content-Type: application/json' +{ + "id": "0", + "jsonrpc": "2.0", + "result": "e22cf75f39ae720e8b71b3d120a5ac03f0db50bba6379e2850975b4859190bc6" +} + + +### getblocktemplate + +Inputs: + +* *wallet_address* - string; Address of wallet to receive coinbase transactions if block is successfully mined. +* *reserve_size* - unsigned int; Reserve size. + +Outputs: + +* *blocktemplate_blob* - string; Blob on which to try to mine a new block. +* *difficulty* - unsigned int; Difficulty of next block. +* *height* - unsigned int; Height on which to mine. +* *prev_hash* - string; Hash of the most recent block on which to mine the next block. +* *reserved_offset* - unsigned int; Reserved offset. +* *status* - string; General RPC error code. "OK" means everything looks good. + +Example: + +{:.cli-code} +[ monero->~ ]$ curl -X POST http://127.0.0.1:18081/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"getblocktemplate","params":{"wallet_address":"44GBHzv6ZyQdJkjqZje6KLZ3xSyN1hBSFAnLP6EAqJtCRVzMzZmeXTC2AHKDS9aEDTRKmo6a6o9r9j86pYfhCWDkKjbtcns","reserve_size":60}' -H 'Content-Type: application/json' +{ + "id": "0", + "jsonrpc": "2.0", + "result": { + "blocktemplate_blob": "01029af88cb70568b84a11dc9406ace9e635918ca03b008f7728b9726b327c1b482a98d81ed83000000000018bd03c01ffcfcf3c0493d7cec7020278dfc296544f139394e5e045fcda1ba2cca5b69b39c9ddc90b7e0de859fdebdc80e8eda1ba01029c5d518ce3cc4de26364059eadc8220a3f52edabdaf025a9bff4eec8b6b50e3d8080dd9da417021e642d07a8c33fbe497054cfea9c760ab4068d31532ff0fbb543a7856a9b78ee80c0f9decfae01023ef3a7182cb0c260732e7828606052a0645d3686d7a03ce3da091dbb2b75e5955f01ad2af83bce0d823bf3dbbed01ab219250eb36098c62cbb6aa2976936848bae53023c00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001f12d7c87346d6b84e17680082d9b4a1d84e36dd01bd2c7f3b3893478a8d88fb3", + "difficulty": 982540729, + "height": 993231, + "prev_hash": "68b84a11dc9406ace9e635918ca03b008f7728b9726b327c1b482a98d81ed830", + "reserved_offset": 246, + "status": "OK" + } +} + +### submitblock + +Submit a mined block to the network. + +Inputs: + +* Block blob data - string + +Outputs: + +* *status* - string; Block submit status. + + +### getlastblockheader + +Block header information for the most recent block is easily retrieved with this method. No inputs are needed. + +Inputs: *None*. + +Outputs: + +* *block_header* - A structure containing block header information. + * *depth* - unsigned int; The number of blocks succeeding this block on the blockchain. A larger number means an older block. + * *difficulty* - unsigned int; The strength of the Monero network based on mining power. + * *hash* - string; The hash of this block. + * *height* - unsigned int; The number of blocks preceding this block on the blockchain. + * *major_version* - unsigned int; The major version of the monero protocol at this block height. + * *minor_version* - unsigned int; The minor version of the monero protocol at this block height. + * *nonce* - unsigned int; a cryptographic random one-time number used in mining a Monero block. + * *orphan_status* - boolean; Usually `false`. If `true`, this block is not part of the longest chain. + * *prev_hash* - string; The hash of the block immediately preceding this block in the chain. + * *reward* - unsigned int; The amount of new atomic units generated in this block and rewarded to the miner. Note: 1 XMR = 1e12 atomic units. + * *timestamp* - unsigned int; The time the block was recorded into the blockchain. +* *status* - string; General RPC error code. "OK" means everything looks good. + +In this example, the most recent block (990793 at the time) is returned: + +{:.cli-code} +[ monero->~ ]$ curl -X POST http://127.0.0.1:18081/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"getlastblockheader"}' -H 'Content-Type: application/json' +{ + "id": "0", + "jsonrpc": "2.0", + "result": { + "block_header": { + "depth": 0, + "difficulty": 746963928, + "hash": "ac0f1e226268d45c99a16202fdcb730d8f7b36ea5e5b4a565b1ba1a8fc252eb0", + "height": 990793, + "major_version": 1, + "minor_version": 1, + "nonce": 1550, + "orphan_status": false, + "prev_hash": "386575e3b0b004ed8d458dbd31bff0fe37b280339937f971e06df33f8589b75c", + "reward": 6856609225169, + "timestamp": 1457589942 + }, + "status": "OK" + } +} + + +### getblockheaderbyhash + +Block header information can be retrieved using either a block's hash or height. This method includes a block's hash as an input parameter to retrieve basic information about the block. + +Inputs: + +* *hash* - string; The block's sha256 hash. + +Outputs: + +* *block_header* - A structure containing block header information. See [getlastblockheader](#getlastblockheader). + +In this example, block 912345 is looked up by its hash: + +{:.cli-code} +[ monero->~ ]$ curl -X POST http://127.0.0.1:18081/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"getblockheaderbyhash","params":{"hash":"e22cf75f39ae720e8b71b3d120a5ac03f0db50bba6379e2850975b4859190bc6"}}' -H 'Content-Type: application/json' +{ + "id": "0", + "jsonrpc": "2.0", + "result": { + "block_header": { + "depth": 78376, + "difficulty": 815625611, + "hash": "e22cf75f39ae720e8b71b3d120a5ac03f0db50bba6379e2850975b4859190bc6", + "height": 912345, + "major_version": 1, + "minor_version": 2, + "nonce": 1646, + "orphan_status": false, + "prev_hash": "b61c58b2e0be53fad5ef9d9731a55e8a81d972b8d90ed07c04fd37ca6403ff78", + "reward": 7388968946286, + "timestamp": 1452793716 + }, + "status": "OK" + } +} + + +### getblockheaderbyheight + +Similar to `getblockheaderbyhash` above, this method includes a block's height as an input parameter to retrieve basic information about the block. + +Inputs: + +* *height* - unsigned int; The block's height. + +Outputs: + +* *block_header* - A structure containing block header information. See [getlastblockheader](#getlastblockheader). + +In this example, block 912345 is looked up by its height (notice that the returned information is the save as in the previous example): + +{:.cli-code} +[ monero->~ ]$ curl -X POST http://127.0.0.1:18081/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"getblockheaderbyheight","params":{"height":912345}}' -H 'Content-Type: application/json' +{ + "id": "0", + "jsonrpc": "2.0", + "result": { + "block_header": { + "depth": 78376, + "difficulty": 815625611, + "hash": "e22cf75f39ae720e8b71b3d120a5ac03f0db50bba6379e2850975b4859190bc6", + "height": 912345, + "major_version": 1, + "minor_version": 2, + "nonce": 1646, + "orphan_status": false, + "prev_hash": "b61c58b2e0be53fad5ef9d9731a55e8a81d972b8d90ed07c04fd37ca6403ff78", + "reward": 7388968946286, + "timestamp": 1452793716 + }, + "status": "OK" + } +} + + +### getblock + +Full block information can be retrieved by either block height or hash, like with the above block header calls. For full block information, both lookups use the same method, but with different input parameters. + +Inputs (pick one of the following): + +* *height* - unsigned int; The block's height. +* *hash* - string; The block's hash. + +Outputs: + +* *blob* - string; Hexadecimal blob of block information. +* *block_header* - A structure containing block header information. See [getlastblockheader](#getlastblockheader). +* *json* - json string; JSON formatted block details: + * *major_version* - Same as in block header. + * *minor_version* - Same as in block header. + * *timestamp* - Same as in block header. + * *prev_id* - Same as `prev_hash` in block header. + * *nonce* - Same as in block header. + * *miner_tx* - Miner transaction information + * *version* - Transaction version number. + * *unlock_time* - The block height when the coinbase transaction becomes spendable. + * *vin* - List of transaction inputs: + * *gen* - Miner txs are coinbase txs, or "gen". + * *height* - This block height, a.k.a. when the coinbase is generated. + * *vout* - List of transaction outputs. Each output contains: + * *amount* - The amount of the output, in atomic units. + * *target* - + * *key* - + * *extra* - Usually called the "transaction ID" but can be used to include any random 32 byte/64 character hex string. + * *signatures* - Contain signatures of tx signers. Coinbased txs do not have signatures. + * *tx_hashes* - List of hashes of non-coinbase transactions in the block. If there are no other transactions, this will be an empty list. +* *status* - string; General RPC error code. "OK" means everything looks good. + +**Look up by height:** + +In the following example, block 912345 is looked up by its height. Note that block 912345 does not have any non-coinbase transactions. (See the next example for a block with extra transactions): + +{:.cli-code} +[ monero->~ ]$ curl -X POST http://127.0.0.1:18081/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"getblock","params":{"height":912345}}' -H 'Content-Type: application/json' +{ + "id": "0", + "jsonrpc": "2.0", + "result": { + "blob": "...", + "block_header": { + "depth": 80694, + "difficulty": 815625611, + "hash": "e22cf75f39ae720e8b71b3d120a5ac03f0db50bba6379e2850975b4859190bc6", + "height": 912345, + "major_version": 1, + "minor_version": 2, + "nonce": 1646, + "orphan_status": false, + "prev_hash": "b61c58b2e0be53fad5ef9d9731a55e8a81d972b8d90ed07c04fd37ca6403ff78", + "reward": 7388968946286, + "timestamp": 1452793716 + }, + "json": "{\n \"major_version\": 1, \n \"minor_version\": 2, \n \"timestamp\": 1452793716, \n \"prev_id\": \"b61c58b2e0be53fad5ef9d9731a55e8a81d972b8d90ed07c04fd37ca6403ff78\", \n \"nonce\": 1646, \n \"miner_tx\": {\n \"version\": 1, \n \"unlock_time\": 912405, \n \"vin\": [ {\n \"gen\": {\n \"height\": 912345\n }\n }\n ], \n \"vout\": [ {\n \"amount\": 8968946286, \n \"target\": {\n \"key\": \"378b043c1724c92c69d923d266fe86477d3a5ddd21145062e148c64c57677008\"\n }\n }, {\n \"amount\": 80000000000, \n \"target\": {\n \"key\": \"73733cbd6e6218bda671596462a4b062f95cfe5e1dbb5b990dacb30e827d02f2\"\n }\n }, {\n \"amount\": 300000000000, \n \"target\": {\n \"key\": \"47a5dab669770da69a860acde21616a119818e1a489bb3c4b1b6b3c50547bc0c\"\n }\n }, {\n \"amount\": 7000000000000, \n \"target\": {\n \"key\": \"1f7e4762b8b755e3e3c72b8610cc87b9bc25d1f0a87c0c816ebb952e4f8aff3d\"\n }\n }\n ], \n \"extra\": [ 1, 253, 10, 119, 137, 87, 244, 243, 16, 58, 131, 138, 253, 164, 136, 195, 205, 173, 242, 105, 123, 61, 52, 173, 113, 35, 66, 130, 178, 250, 217, 16, 14, 2, 8, 0, 0, 0, 11, 223, 194, 193, 108\n ], \n \"signatures\": [ ]\n }, \n \"tx_hashes\": [ ]\n}", + "status": "OK" + } +} + +**Look up by hash:** + +In the following example, block 993056 is looked up by its hash. Note that block 993056 has 3 non-coinbase transactions: + +{:.cli-code} +[ monero->~ ]$ curl -X POST http://127.0.0.1:18081/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"getblock","params":{"hash":"510ee3c4e14330a7b96e883c323a60ebd1b5556ac1262d0bc03c24a3b785516f"}}' -H 'Content-Type: application/json' +{ + "id": "0", + "jsonrpc": "2.0", + "result": { + "blob": "...", + "block_header": { + "depth": 12, + "difficulty": 964985344, + "hash": "510ee3c4e14330a7b96e883c323a60ebd1b5556ac1262d0bc03c24a3b785516f", + "height": 993056, + "major_version": 1, + "minor_version": 2, + "nonce": 2036, + "orphan_status": false, + "prev_hash": "0ea4af6547c05c965afc8df6d31509ff3105dc7ae6b10172521d77e09711fd6d", + "reward": 6932043647005, + "timestamp": 1457720227 + }, + "json": "{\n \"major_version\": 1, \n \"minor_version\": 2, \n \"timestamp\": 1457720227, \n \"prev_id\": \"0ea4af6547c05c965afc8df6d31509ff3105dc7ae6b10172521d77e09711fd6d\", \n \"nonce\": 2036, \n \"miner_tx\": {\n \"version\": 1, \n \"unlock_time\": 993116, \n \"vin\": [ {\n \"gen\": {\n \"height\": 993056\n }\n }\n ], \n \"vout\": [ {\n \"amount\": 2043647005, \n \"target\": {\n \"key\": \"59e9d685b3484886bc7b47c133e6099ecdf212d5eaa16ce19cd58e8c3c1e590a\"\n }\n }, {\n \"amount\": 30000000000, \n \"target\": {\n \"key\": \"4c5e2f542d25513c46b9e3b7d40140a22d0ae5314bfcae492ad9f56fff8185f0\"\n }\n }, {\n \"amount\": 900000000000, \n \"target\": {\n \"key\": \"13dd8ffdac9e6a2f71e327dad65328198dc879a492d145eae72677c0703a3515\"\n }\n }, {\n \"amount\": 6000000000000, \n \"target\": {\n \"key\": \"62bda00341681dccbc066757862da593734395745bdfe1fdc89b5948c86a5d4c\"\n }\n }\n ], \n \"extra\": [ 1, 182, 145, 133, 28, 240, 87, 185, 195, 2, 163, 219, 202, 135, 158, 28, 186, 76, 196, 80, 97, 202, 85, 170, 166, 224, 60, 220, 103, 171, 158, 69, 80, 2, 8, 0, 0, 0, 12, 97, 127, 223, 22\n ], \n \"signatures\": [ ]\n }, \n \"tx_hashes\": [ \"79c6b9f00db027bde151705aafe85c495883aae2597d5cb8e1adb2e0f3ae1d07\", \"d715db73331abc3ec588ef07c7bb195786a4724b08dff431b51ffa32a4ce899b\", \"b197066426c0ed89f0b431fe171f7fd62bc95dd29943daa7cf3585cf1fdfc99d\"\n ]\n}", + "status": "OK", + "tx_hashes": ["79c6b9f00db027bde151705aafe85c495883aae2597d5cb8e1adb2e0f3ae1d07","d715db73331abc3ec588ef07c7bb195786a4724b08dff431b51ffa32a4ce899b","b197066426c0ed89f0b431fe171f7fd62bc95dd29943daa7cf3585cf1fdfc99d"] + } +} + + +### get_connections + +Retrieve information about incoming and outgoing connections to your node. + +Inputs: *None*. + +Outputs: + +* *connections* - List of all connections and their info: + * *avg_download* - unsigned int; Average bytes of data downloaded by node. + * *avg_upload* - unsigned int; Average bytes of data uploaded by node. + * *current_download* - unsigned int; Current bytes downloaded by node. + * *current_upload* - unsigned int; Current bytes uploaded by node. + * *incoming* - boolean; Is the node getting information from your node? + * *ip* - string; The node's IP address. + * *live_time* - unsigned int + * *local_ip* - boolean + * *localhost* - boolean + * *peer_id* - string; The node's ID on the network. + * *port* - stringl The port that the node is using to connect to the network. + * *recv_count* - unsigned int + * *recv_idle_time* - unsigned int + * *send_count* - unsigned int + * *send_idle_time* - unsigned int + * *state* - string + +Following is an example of `get_connections` and it's return: + +{:.cli-code} +[ monero->~ ]$ curl -X POST http://127.0.0.1:18081/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"get_connections"}' -H 'Content-Type: application/json' +{ + "id": "0", + "jsonrpc": "2.0", + "result": { + "connections": [{ + "avg_download": 0, + "avg_upload": 0, + "current_download": 0, + "current_upload": 0, + "incoming": false, + "ip": "76.173.170.133", + "live_time": 1865, + "local_ip": false, + "localhost": false, + "peer_id": "3bfe29d6b1aa7c4c", + "port": "18080", + "recv_count": 116396, + "recv_idle_time": 23, + "send_count": 176893, + "send_idle_time": 1457726610, + "state": "state_normal" + },{ + ... + }], + "status": "OK" + } +} + + +### get_info + +Retrieve general information about the state of your node and the network. + +Inputs: *None*. + +Outputs: + +* *alt_blocks_count* - unsigned int; Number of alternative blocks to main chain. +* *difficulty* - unsigned int; Network difficulty (analogous to the strength of the network) +* *grey_peerlist_size* - unsigned int; Grey Peerlist Size +* *height* - unsigned int; Current length of longest chain known to daemon. +* *incoming_connections_count* - unsigned int; Number of peers connected to and pulling from your node. +* *outgoing_connections_count* - unsigned int; Number of peers that you are connected to and getting information from. +* *status* - string; General RPC error code. "OK" means everything looks good. +* *target* - unsigned int; Current target for next proof of work. +* *target_height* - unsigned int; The height of the next block in the chain. +* *testnet* - boolean; States if the node is on the testnet (true) or mainnet (false). +* *top_block_hash* - string; Hash of the highest block in the chain. +* *tx_count* - unsigned int; Total number of non-coinbase transaction in the chain. +* *tx_pool_siz* - unsigned int; Number of transactions that have been broadcast but not included in a block. +* *white_peerlist_size* - unsigned int; White Peerlist Size + +Following is an example `get_info` call and its return: + +{:.cli-code} +[ monero->~ ]$ curl -X POST http://127.0.0.1:18081/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"get_info"}' -H 'Content-Type: application/json' +{ + "id": "0", + "jsonrpc": "2.0", + "result": { + "alt_blocks_count": 5, + "difficulty": 972165250, + "grey_peerlist_size": 2280, + "height": 993145, + "incoming_connections_count": 0, + "outgoing_connections_count": 8, + "status": "OK", + "target": 60, + "target_height": 993137, + "testnet": false, + "top_block_hash": "", + "tx_count": 564287, + "tx_pool_size": 45, + "white_peerlist_size": 529 + } +} + + +### hard_fork_info + +Look up information regarding hard fork voting and readiness. + +Inputs: *None*. + +Outputs: + +* *earliest_height* - unsigned int; Block height at which hard fork would be enabled if voted in. +* *enabled* - boolean; Tells if hard fork is enforced. +* *state* - unsigned int; Current hard fork state: 0 (There is likely a hard fork), 1 (An update is needed to fork properly), or 2 (Everything looks good). +* *status* - string; General RPC error code. "OK" means everything looks good. +* *threshold* - unsigned int; Minimum percent of votes to trigger hard fork. Default is 80. +* *version* - unsigned int; The major block version for the fork. +* *votes* - unsigned int; Number of votes towards hard fork. +* *voting* - unsigned int; Hard fork voting status. +* *window* - unsigned int; Number of blocks over which current votes are cast. Default is 10080 blocks. + +Example: + +{:.cli-code} +[ monero->~ ]$ curl -X POST http://127.0.0.1:18081/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"hard_fork_info"}' -H 'Content-Type: application/json' +{ + "id": "0", + "jsonrpc": "2.0", + "result": { + "earliest_height": 1009827, + "enabled": false, + "state": 2, + "status": "OK", + "threshold": 0, + "version": 1, + "votes": 7277, + "voting": 2, + "window": 10080 + } +} + + +### setbans + +Ban another node by IP. + +Inputs: + +* *bans* - A list of nodes to ban: + * *ip* - unsigned int; IP address to ban, in Int format. + * *ban* - boolean; Set `true` to ban. + * *seconds* - unsigned int; Number of seconds to ban node. + +Outputs: + +* *status* - string; General RPC error code. "OK" means everything looks good. + +Example: + +{:.cli-code} +[ monero->~ ]$ curl -X POST http://127.0.0.1:18081/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"setbans","params":{"bans":[{"ip":838969536,"ban":true,"seconds":30}]}}' -H 'Content-Type: application/json' +{ + "id": "0", + "jsonrpc": "2.0", + "result": { + "status": "OK" + } +} + + +### getbans + +Inputs: *None*. + +Outputs: + +* *bans* - List of banned nodes: + * *ip* - unsigned int; Banned IP address, in Int format. + * *seconds* - unsigned int; Local Unix time that IP is banned until. +* *status* - string; General RPC error code. "OK" means everything looks good. + +Example: + +{:.cli-code} +[ monero->~ ]$ curl -X POST http://127.0.0.1:18081/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"getbans"}' -H 'Content-Type: application/json' +{ + "id": "0", + "jsonrpc": "2.0", + "result": { + "bans": [{ + "ip": 838969536, + "seconds": 1457748792 + }], + "status": "OK" + } +} + + +--- + +## Other Daemon RPC Calls + +Not all daemon RPC calls use the JSON_RPC interface. This section gives examples of these calls. + +The data structure for these calls is different than the JSON RPC calls. Whereas the JSON RPC methods were called using the `/json_rpc` extension and specifying a method, these methods are called at their own extensions. For example: + + IP=127.0.0.1 + PORT=18081 + METHOD='gettransactions' + PARAMS='{"txs_hashes":["d6e48158472848e6687173a91ae6eebfa3e1d778e65252ee99d7515d63090408"]}' + curl \ + -X POST http://$IP:$PORT/$METHOD \ + -d $PARAMS \ + -H 'Content-Type: application/json' + +Note: It is recommended to use JSON RPC where such alternatives exist, rather than the following methods. For example, the recommended way to get a node's height is via the JSON RPC methods [get_info](#getinfo) or [getlastblockheader](#getlastblockheader), rather than [getheight](#getheight) below. + + +### /getheight + +Get the node's current height. + +Inputs: *None*. + +Outputs: + +* *height* - unsigned int; Current length of longest chain known to daemon. + +{:.cli-code} +[ monero->~ ]$ curl -X POST http://127.0.0.1:18081/getheight -H 'Content-Type: application/json' +{ + "height": 993488, + "status": "OK" +} + + +### /gettransactions + +Look up one or more transactions by hash. + +Inputs: + +* *txs_hashes* - string list; List of transaction hashes to look up. +* *decode_as_json* - boolean; Optional. If set `true`, the returned transaction information will be decoded rather than binary. + +Outputs: + +* *status* - General RPC error code. "OK" means everything looks good. +* *txs_as_hex* - string; Full transaction information as a hex string. +* *txs_as_json* - json string; (Optional - returned if set in inputs.) List of transaction info: + * *version* - Transaction version + * *unlock_time* - If not 0, this tells when a transaction output is spendable. + * *vin* - List of inputs into transaction: + * *key* - The public key of the previous output spent in this transaction. + * *amount* - The amount of the input, in atomic units. + * *key_offsets* - A list of integer offets to the input. + * *k_image* - The key image for the given input + * *vout* - List of outputs from transaction: + * *amount* - Amount of transaction output, in atomic units. + * *target* - Output destination information: + * *key* - The stealth public key of the receiver. Whoever owns the private key associated with this key controls this transaction output. + * *extra* - Usually called the "payment ID" but can be used to include any random 32 bytes. + * *signatures* - List of ignatures used in ring signature to hide the true origin of the transaction. +Example 1: Return transaction information in binary format. + +{:.cli-code} +[ monero->~ ]$ curl -X POST http://127.0.0.1:18081/gettransactions -d '{"txs_hashes":["d6e48158472848e6687173a91ae6eebfa3e1d778e65252ee99d7515d63090408"]}' -H 'Content-Type: application/json' +{ + "status": "OK", + "txs_as_hex": ["..."] +} + +Example 2: Decode returned transaction information in JSON format. Note: the "vout" list has been truncated in the displayed return for space considerations. + +{:.cli-code} +[ monero->~ ]$ curl -X POST http://127.0.0.1:18081/gettransactions -d '{"txs_hashes":["d6e48158472848e6687173a91ae6eebfa3e1d778e65252ee99d7515d63090408"],"decode_as_json":true}' -H 'Content-Type: application/json' +{ + "status": "OK", + "txs_as_hex": ["..."], + "txs_as_json": ["{\n \"version\": 1, \n \"unlock_time\": 0, \n \"vin\": [ {\n \"key\": {\n \"amount\": 70000000, \n \"key_offsets\": [ 35952\n ], \n \"k_image\": \"d16908468dff9438a9814fe96bdaa575f06fe8da85772b72e54926428712293d\"\n }\n }, {\n \"key\": {\n \"amount\": 400000000000000, \n \"key_offsets\": [ 6830\n ], \n \"k_image\": \"c7a7024b763df1181ae6fe821b70669735e38a68162ac02362e33acbe829b605\"\n }\n }\n ], \n \"vout\": [ {\n \"amount\": 50000, \n \"target\": {\n \"key\": \"f6be43f7be4f06adcb1d06f4a07c637c7359e009cf3e57bb32b8c9ea636509c3\"\n }\n }, {\n \"amount\": 200000, \n \"target\": {\n \"key\": \"b0a7a8e32f2b5302552bcd8d85112c62838b1f56cccd844eb9b63e0a732d0353\"\n }\n }, ... \n ], \n \"extra\": [ 1, 225, 240, 98, 34, 169, 73, 47, 237, 117, 192, 30, 192, 60, 155, 47, 4, 115, 20, 21, 11, 13, 252, 219, 129, 13, 174, 37, 36, 78, 191, 141, 109\n ], \n \"signatures\": [ \"e6a3be8003d481d2855c8127f56871de3d28a4fb52385b999eb986c831c5cc08361c126b0db24a21b6c4299b438ee2be201d44d57a371230b9cd04395ab8c400\", \"8309851abaf2cf2a7091e0cdb9c83704fa7d68838a7a8ef8c178bb55a1e93a038dd18bb4a7549dc056b7a70e037cabd80911a03f427e36f712756d4c00f38f0b\"]\n}"] +} + + +### /is_key_image_spent + +Check if outputs have been spent using the key image associated with the output. + +Inputs: + +* *key_images* - string list; List of key image hex strings to check. + +Outputs: + +* *spent_status* - unsigned int list; List of statuses for each image checked. Statuses are follows: 0 = unspent, 1 = spent in blockchain, 2 = spent in transaction pool +* *status* - string; General RPC error code. "OK" means everything looks good. + +Example: + +{:.cli-code} +[ monero->~ ]$ curl -X POST http://127.0.0.1:18081/is_key_image_spent -d '{"key_images":["8d1bd8181bf7d857bdb281e0153d84cd55a3fcaa57c3e570f4a49f935850b5e3","7319134bfc50668251f5b899c66b005805ee255c136f0e1cecbb0f3a912e09d4"]}' -H 'Content-Type: application/json' +{ + "spent_status": [1,2], + "status": "OK" +} + + +### /sendrawtransaction + +Broadcast a raw transaction to the network. + +Inputs: + +* *tx_as_hex* - string; Full transaction information as hexidecimal string. + +Outputs: + +* *status* - string; General RPC error code. "OK" means everything looks good. + +Example (No return information included here.): + +{:.cli-code} +[ monero->~ ]$ curl -X POST http://127.0.0.1:18081/sendrawtransaction -d '{"tx_as_hex":"de6a3..."}' -H 'Content-Type: application/json' + + +### /get_transaction_pool + +Show information about valid transactions seen by the node but not yet mined into a block, as well as spent key image information in the node's memory. + +Inputs: *None*. + +Outputs: + +* *spent_key_images* - List of spent output key images: + * *id_hash* - string; Key image ID hash. + * *txs_hashes* - string list; Key image transaction hashes. +* *status* - string; General RPC error code. "OK" means everything looks good. +* *transactions* - List of transactions in the mempool that have not been included in a block: + * *blob_size* - unsigned int; The size of the full transaction blob. + * *fee* - unsigned int; The amount of the mining fee included in the transaction, in atomic units. + * *id_hash* - string; The transaction ID hash. + * *kept_by_block* - boolean; We do not accept transactions that timed out before, unless set `true`. + * *last_failed_height* - unsigned int; If the transaction has previously timed out, this tells at what height that occured. + * *last_failed_id_hash* - string; Like the previous, this tells the previous transaction ID hash. + * *max_used_block_height* - unsigned int; Tells the height of the most recent block with an output used in this transaction. + * *max_used_block_hash* - string; Tells the hash of the most recent block with an output used in this transaction. + * *receive_time* - unsigned int; The Unix time that the transaction was first seen on the network by the node. + * *tx_json* - json string; JSON structure of all information in the transaction: + * *version* - Transaction version + * *unlock_time* - If not 0, this tells when a transaction output is spendable. + * *vin* - List of inputs into transaction: + * *key* - The public key of the previous output spent in this transaction. + * *amount* - The amount of the input, in atomic units. + * *key_offsets* - A list of integer offets to the input. + * *k_image* - The key image for the given input + * *vout* - List of outputs from transaction: + * *amount* - Amount of transaction output, in atomic units. + * *target* - Output destination information: + * *key* - The stealth public key of the receiver. Whoever owns the private key associated with this key controls this transaction output. + * *extra* - Usually called the "transaction ID" but can be used to include any random 32 bytes. + * *signatures* - List of ignatures used in ring signature to hide the true origin of the transaction. + +Example (Note: Some lists in the returned information have been truncated for display reasons): + +{:.cli-code} +[ monero->~ ]$ curl -X POST http://127.0.0.1:18081/get_transaction_pool -H 'Content-Type: application/json' +{ + "spent_key_images": [{ + "id_hash": "1edb9ecc39602040282d326070ad22cb473c952c0d6280c9c4c3b853fb34f3bc", + "txs_hashes": ["409911b2be02e3f0e930b326c67ab9e74675885ce23d71bb3bd28b62bc3e7803"] + },{ + "id_hash": "4adb4bb63b3397027340ca4e6c45f4ce2147dfb3a4e0fafdec18834ae594a05e", + "txs_hashes": ["946f1f4c52e3426a41959c93b60078f314813bc4bdebcf69b8ee11d593b2bd14"] + }, + ...], + "status": "OK", + "transactions": [{ + "blob_size": 25761, + "fee": 290000000000, + "id_hash": "11d4cff23e610fac6a2b89187ad61d429a5e226652693dcac5d83d506eb92b96", + "kept_by_block": false, + "last_failed_height": 0, + "last_failed_id_hash": "0000000000000000000000000000000000000000000000000000000000000000", + "max_used_block_height": 954508, + "max_used_block_id_hash": "03f96b374778bc059e47b96e2beec2e6d4d9e0ad39afeabdbcd77e1bd5a62f81", + "receive_time": 1457676127, + "tx_json": "{\n \"version\": 1, \n \"unlock_time\": 0, \n \"vin\": [ {\n \"key\": {\n \"amount\": 70000000000, \n \"key_offsets\": [ 63408, 18978, 78357, 16560\n ], \n \"k_image\": \"7319134bfc50668251f5b899c66b005805ee255c136f0e1cecbb0f3a912e09d4\"\n }\n }, ... ], \n \"vout\": [ {\n \"amount\": 80000000000, \n \"target\": {\n \"key\": \"094e6a1b187385533665f89db741149f42d95fdc50bdd2a2384bcd1dc5209c55\"\n }\n }, ... ], \n \"extra\": [ 2, 33, 0, 15, 56, 190, 21, 169, 77, 13, 182, 209, 51, 35, 54, 96, 89, 237, 96, 23, 24, 107, 240, 79, 40, 86, 64, 68, 45, 166, 119, 192, 17, 225, 23, 1, 31, 159, 145, 15, 173, 255, 165, 192, 55, 84, 127, 154, 163, 25, 85, 204, 212, 127, 147, 133, 118, 218, 166, 52, 78, 188, 131, 235, 9, 159, 105, 158\n ], \n \"signatures\": [ \"966e5a67fbdbf72d7dc0364b705121a58e0ced7e2ab45747b6b154c05a1afe04fac4aac7f64faa2dc6dd4d51b8277f11e2f2ec7729fac225088befe3b8399c0b71a4cb55b9d0e20f93d305c78cebceff1bcfcfaf225428dfcfaaec630c88720ab65bf5d3399dd1ac82ea0ecf308b3f80d9780af7742fb157692cd60515a7e2086878f082117fa80fff3d257de7d3a2e9cc8b3472ef4a5e545d90e1159523a60f38d16cece783579627124776813334bdb2a2df4171ef1fa12bf415da338ce5085c01e7a715638ef5505aebec06a0625aaa72d13839838f7d4f981673c8f05f08408e8b372f900af7227c49cfb1e1febab6c07dd42b7c26f921cf010832841205\", ... ]\n}" + }, + ...] +} + + +### /stop_daemon + +Send a command to the daemon to safely disconnect and shut down. + +Inputs: *None*. + +Outputs: + +* *status* - string; General RPC error code. "OK" means everything looks good. + +Example: + +{:.cli-code} +[ monero->~ ]$ curl -X POST http://127.0.0.1:18081/stop_daemon -H 'Content-Type: application/json' +{ + "status": "OK" +} + diff --git a/resources/developer-guides/index.md b/resources/developer-guides/index.md new file mode 100644 index 00000000..8068df6d --- /dev/null +++ b/resources/developer-guides/index.md @@ -0,0 +1,24 @@ +--- +layout: custom +title: "Developer Guides" +--- + +
+ +
+

Please note: the guides below are currently out of date, but are considered a good starting point for most calls.

+
+ +
+
+

RPC Documetation

+
+ +[Daemon RPC Documentation](daemon-rpc.html) +[Wallet RPC Documentation](wallet-rpc.html) + +More coming soon... +
+
+
+
\ No newline at end of file diff --git a/resources/developer-guides/wallet-rpc.md b/resources/developer-guides/wallet-rpc.md new file mode 100644 index 00000000..ab6c73a5 --- /dev/null +++ b/resources/developer-guides/wallet-rpc.md @@ -0,0 +1,634 @@ +--- +layout: static_page +title: "Wallet RPC documentation" +title-pre-kick: "Developer Guide: " +title-kick: "Wallet RPC documentation " +title-post-kick: "" +kick-class: "green-kicks" +icon: "icon_client" +attribution: "" +--- + +## Introduction + +This is a list of the monero-wallet-rpc calls, their inputs and outputs, and examples of each. The program monero-wallet-rpc replaced the rpc interface that was in simplewallet and then monero-wallet-cli. + +All monero-wallet-rpc methods use the same JSON RPC interface. For example: + + IP=127.0.0.1 + PORT=18082 + METHOD="make_integrated_address" + PARAMS="{\"payment_id\":\"1234567890123456789012345678900012345678901234567890123456789000\"}" + curl \ + -X POST http://$IP:$PORT/json_rpc \ + -d '{"jsonrpc":"2.0","id":"0","method":"'$METHOD'","params":'"$PARAMS"'}' \ + -H 'Content-Type: application/json' + +If the monero-wallet-rpc was executed with the `--rpc-login` argument as `username:password`, then follow this example: + + IP=127.0.0.1 + PORT=18082 + METHOD="make_integrated_address" + PARAMS="{\"payment_id\":\"1234567890123456789012345678900012345678901234567890123456789000\"}" + curl \ + -u username:password --digest \ + -X POST http://$IP:$PORT/json_rpc \ + -d '{"jsonrpc":"2.0","id":"0","method":"'$METHOD'","params":'"$PARAMS"'}' \ + -H 'Content-Type: application/json' + +Note: "atomic units" refer to the smallest fraction of 1 XMR according to the monerod implementation. **1 XMR = 1e12 atomic units.** + +### Index of JSON RPC Methods: + +* [getbalance](#getbalance) +* [getaddress](#getaddress) +* [getheight](#getheight) +* [transfer](#transfer) +* [transfer_split](#transfersplit) +* [sweep_dust](#sweepdust) +* [store](#store) +* [get_payments](#getpayments) +* [get_bulk_payments](#getbulkpayments) +* [get_transfers](#gettransfers) +* [incoming_transfers](#incomingtransfers) +* [query_key](#querykey) +* [make_integrated_address](#makeintegratedaddress) +* [split_integrated_address](#splitintegratedaddress) +* [stop_wallet](#stopwallet) + +--- + +## JSON RPC Methods: + +### getbalance + +Return the wallet's balance. + +Inputs: *None*. + +Outputs: + +* *balance* - unsigned int; The total balance of the current monero-wallet-rpc in session. +* *unlocked_balance* - unsigned int; Unlocked funds are those funds that are sufficiently deep enough in the Monero blockchain to be considered safe to spend. + +Example: + +{:.cli-code} +[ monero->~ ]$ curl -X POST http://127.0.0.1:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"getbalance"}' -H 'Content-Type: application/json' +{ + "id": "0", + "jsonrpc": "2.0", + "result": { + "balance": 140000000000, + "unlocked_balance": 50000000000 + } +} + + +### getaddress + +Return the wallet's address. + +Inputs: *None*. + +Outputs: + +* *address* - string; The 95-character hex address string of the monero-wallet-rpc in session. + +Example: + +{:.cli-code} +[ monero->~ ]$ curl -X POST http://127.0.0.1:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"getaddress"}' -H 'Content-Type: application/json' +{ + "id": "0", + "jsonrpc": "2.0", + "result": { + "address": "427ZuEhNJQRXoyJAeEoBaNW56ScQaLXyyQWgxeRL9KgAUhVzkvfiELZV7fCPBuuB2CGuJiWFQjhnhhwiH1FsHYGQGaDsaBA" + } +} + + +### getheight + +Returns the wallet's current block height. + +Inputs: *None*. + +Outputs: + +* *height* - string; The current monero-wallet-rpc's blockchain height. If the wallet has been offline for a long time, it may need to catch up with the daemon. + +Example: + +{:.cli-code} +[ monero->~ ]$ curl -X POST http://127.0.0.1:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"getheight"}' -H 'Content-Type: application/json' +{ + "id": "0", + "jsonrpc": "2.0", + "result": { + "height": 994310 + } +} + + +### transfer + +Send monero to a number of recipients. + +Inputs: + +* *destinations* - array of destinations to receive XMR: + * *amount* - unsigned int; Amount to send to each destination, in atomic units. + * *address* - string; Destination public address. +* *fee* - unsigned int; Ignored, will be automatically calculated. +* *mixin* - unsigned int; Number of outpouts from the blockchain to mix with (0 means no mixing). +* *unlock_time* - unsigned int; Number of blocks before the monero can be spent (0 to not add a lock). +* *payment_id* - string; (Optional) Random 32-byte/64-character hex string to identify a transaction. +* *get_tx_key* - boolean; (Optional) Return the transaction key after sending. +Outputs: + +* *fee* - Integer value of the fee charged for the txn. +* *tx_hash* - String for the publically searchable transaction hash +* *tx_key* - String for the transaction key if get_tx_key is true, otherwise, blank string. + +Example: + +{:.cli-code} +[ monero->~ ]$ curl -X POST http://127.0.0.1:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"transfer","params":{"destinations":[{"amount":100000000,"address":"9wNgSYy2F9qPZu7KBjvsFgZLTKE2TZgEpNFbGka9gA5zPmAXS35QzzYaLKJRkYTnzgArGNX7TvSqZC87tBLwtaC5RQgJ8rm"},{"amount":200000000,"address":"9vH5D7Fv47mbpCpdcthcjU34rqiiAYRCh1tYywmhqnEk9iwCE9yppgNCXAyVHG5qJt2kExa42TuhzQfJbmbpeGLkVbg8xit"}],"mixin":4,"get_tx_key": true}}' -H 'Content-Type: application/json' +{ + "id": "0", + "jsonrpc": "2.0", + "result": { + "fee": 48958481211, + "tx_hash": "985180f468637bc6d2f72ee054e1e34b8d5097988bb29a2e0cb763e4464db23c", + "tx_key": "8d62e5637f1fcc9a8904057d6bed6c697618507b193e956f77c31ce662b2ee07" + } +} + + +### transfer_split + +Same as transfer, but can split into more than one tx if necessary. + +Inputs: + +* *destinations* - array of destinations to receive XMR: + * *amount* - unsigned int; Amount to send to each destination, in atomic units. + * *address* - string; Destination public address. +* *fee* - unsigned int; Ignored, will be automatically calculated. +* *mixin* - unsigned int; Number of outpouts from the blockchain to mix with (0 means no mixing). +* *unlock_time* - unsigned int; Number of blocks before the monero can be spent (0 to not add a lock). +* *payment_id* - string; (Optional) Random 32-byte/64-character hex string to identify a transaction. +* *get_tx_key* - boolean; (Optional) Return the transaction key after sending. -- Ignored +* *new_algorithm* - boolean; True to use the new transaction construction algorithm, defaults to false. + +Outputs: + +* *fee_list* - array of: integer +* *tx_hash_list* - array of: string + +Example: + +{:.cli-code} +[ monero->~ ]$ curl -X POST http://127.0.0.1:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"transfer_split","params":{"destinations":[{"amount":100000000,"address":"9wNgSYy2F9qPZu7KBjvsFgZLTKE2TZgEpNFbGka9gA5zPmAXS35QzzYaLKJRkYTnzgArGNX7TvSqZC87tBwtaC5RQgJ8rm"},{"amount":200000000,"address":"9vH5D7Fv47mbpCpdcthcjU34rqiiAYRCh1tYywmhqnEk9iwCE9yppgNCXAyVHG5qJt2kExa42TuhzQfJbmbpeGLkVbg8xit"},{"amount":200000000,"address":"9vC5Q25cR1d3WzKX6dpTaLJaqZyDrtTnfadTmVuB1Wue2tyFGxUhiE4RGa74pEDJv7gSySzcd1Ao6G1nzSaqp78vLfP6MPj"},{"amount":200000000,"address":"A2MSrn49ziBPJBh8ZNEhhbfyLMou6mao4C1F5TLGUatmUnCxZArDYkcbAnVkVEopWVeak2rKDrmc8JpoS7n5dvfN9YDPBTG"},{"amount":200000000,"address":"9tEDyVQ8zgRQbDYiykTdpw5kZ6qWQWcKfExEj9eQshjpGb3sdr3UyWE2AHWzUGzJjaH9HN1DdGBdyQQ4AqGMc7rr5xYwZWW"}],"mixin":4,"get_tx_key": true, "new_algorithm": true}}' -H 'Content-Type: application/json' +{ + "id": "0", + "jsonrpc": "2.0", + "result": { + "fee_list": [97916962422], + "tx_hash_list": ["c5c389846e701c27aaf1f7ab8b9dc457b471fcea5bc9710e8020d51275afbc54"] + } +} + + +### sweep_dust + +Send all dust outputs back to the wallet's, to make them easier to spend (and mix). + +Inputs: *None*. + +Outputs: + +* *tx_hash_list* - list of: string + +Example (In this example, `sweep_dust` returns an error due to insufficient funds to sweep): + +{:.cli-code} +[ monero->~ ]$ curl -X POST http://127.0.0.1:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"sweep_dust"}' -H 'Content-Type: application/json' +{ + "error": { + "code": -4, + "message": "not enough money" + }, + "id": "0", + "jsonrpc": "2.0" +} + +### store + +Save the blockchain. + +Inputs: *None*. + +Outputs: *None*. + +Example: + +{:.cli-code} +[ monero->~ ]$ curl -X POST http://127.0.0.1:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"store"}' -H 'Content-Type: application/json' +{ + "id": "0", + "jsonrpc": "2.0", + "result": { + } +} + + +### get_payments + +Get a list of incoming payments using a given payment id. + +Inputs: + +* *payment_id* - string + +Outputs: + +* *payments* - list of: + * *payment_id* - string + * *tx_hash* - string + * *amount* - unsigned int + * *block_height* - unsigned int + * *unlock_time* - unsigned int + +Example: + +{:.cli-code} +[ monero->~ ]$ curl -X POST http://127.0.0.1:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"get_payments","params":{"payment_id":"4279257e0a20608e25dba8744949c9e1caff4fcdafc7d5362ecf14225f3d9030"}}' -H 'Content-Type: application/json' +{ + "id": "0", + "jsonrpc": "2.0", + "result": { + "payments": [{ + "amount": 10350000000000, + "block_height": 994327, + "payment_id": "4279257e0a20608e25dba8744949c9e1caff4fcdafc7d5362ecf14225f3d9030", + "tx_hash": "c391089f5b1b02067acc15294e3629a463412af1f1ed0f354113dd4467e4f6c1", + "unlock_time": 0 + }] + } +} + + +### get_bulk_payments + +Get a list of incoming payments using a given payment id, or a list of payments ids, from a given height. This method is the preferred method over `get_payments` because it has the same functionality but is more extendable. Either is fine for looking up transactions by a single payment ID. + +Inputs: + +* *payment_ids* - array of: string + * *min_block_height* - unsigned int; The block height at which to start looking for payments. + +Outputs: + +* *payments* - list of: + * *payment_id* - string + * *tx_hash* - string + * *amount* - unsigned int + * *block_height* - unsigned int + * *unlock_time* - unsigned int + +Example: + +{:.cli-code} +[ monero->~ ]$ curl -X POST http://127.0.0.1:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"get_bulk_payments","params":{"payment_ids":["4279257e0a20608e25dba8744949c9e1caff4fcdafc7d5362ecf14225f3d9030"],"min_block_height":990000}}' -H 'Content-Type: application/json' +{ + "id": "0", + "jsonrpc": "2.0", + "result": { + "payments": [{ + "amount": 10350000000000, + "block_height": 994327, + "payment_id": "4279257e0a20608e25dba8744949c9e1caff4fcdafc7d5362ecf14225f3d9030", + "tx_hash": "c391089f5b1b02067acc15294e3629a463412af1f1ed0f354113dd4467e4f6c1", + "unlock_time": 0 + }] + } +} + +### get_transfers + +Returns a list of transfers. + +Inputs: + +* *in* - boolean; +* *out* - boolean; +* *pending* - boolean; +* *failed* - boolean; +* *pool* - boolean; +* *filter_by_height* - boolean; +* *min_height* - unsigned int; +* *max_height* - unsigned int; + +Outputs: + +* *in* array of transfers: + * *txid* - string; + * *payment_id* - string; + * *height* - unsigned int; + * *timestamp* - unsigned int; + * *amount* - unsigned int; + * *fee* - unsigned int; + * *note* - string; + * *destinations* - std::list; + * *type* - string; +* *out* array of transfers +* *pending* array of transfers +* *failed* array of transfers +* *pool* array of transfers + + +Example: + +{:.cli-code} +[ monero->~ ]$ curl -X POST http://127.0.0.1:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"get_transfers","params":{"pool":true}}' -H 'Content-Type: application/json' +{ + "id": "0", + "jsonrpc": "2.0", + "result": { + "pool": [{ + "amount": 500000000000, + "fee": 0, + "height": 0, + "note": "", + "payment_id": "758d9b225fda7b7f", + "timestamp": 1488312467, + "txid": "da7301d5423efa09fabacb720002e978d114ff2db6a1546f8b820644a1b96208", + "type": "pool" + }] + } +} + + +### incoming_transfers + +Return a list of incoming transfers to the wallet. + +Inputs: + +* *transfer_type* - string; "all": all the transfers, "available": only transfers which are not yet spent, OR "unavailable": only transfers which are already spent. + +Outputs: + +* *transfers* - list of: + * *amount* - unsigned int + * *spent* - boolean + * *global_index* - unsigned int; Mostly internal use, can be ignored by most users. + * *tx_hash* - string; Several incoming transfers may share the same hash if they were in the same transaction. + * *tx_size* - unsigned int + +Example (Return "all" transaction types): + +{:.cli-code} +[ monero->~ ]$ curl -X POST http://127.0.0.1:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"incoming_transfers","params":{"transfer_type":"all"}}' -H 'Content-Type: application/json' +{ + "id": "0", + "jsonrpc": "2.0", + "result": { + "transfers": [{ + "amount": 10000000000000, + "global_index": 711506, + "spent": false, + "tx_hash": "<c391089f5b1b02067acc15294e3629a463412af1f1ed0f354113dd4467e4f6c1>", + "tx_size": 5870 + },{ + "amount": 300000000000, + "global_index": 794232, + "spent": false, + "tx_hash": "<c391089f5b1b02067acc15294e3629a463412af1f1ed0f354113dd4467e4f6c1>", + "tx_size": 5870 + },{ + "amount": 50000000000, + "global_index": 213659, + "spent": false, + "tx_hash": "<c391089f5b1b02067acc15294e3629a463412af1f1ed0f354113dd4467e4f6c1>", + "tx_size": 5870 + }] + } +} + +Example (Return "available" transactions): + +{:.cli-code} +[ monero->~ ]$ curl -X POST http://127.0.0.1:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"incoming_transfers","params":{"transfer_type":"available"}}' -H 'Content-Type: application/json' +{ + "id": "0", + "jsonrpc": "2.0", + "result": { + "transfers": [{ + "amount": 10000000000000, + "global_index": 711506, + "spent": false, + "tx_hash": "<c391089f5b1b02067acc15294e3629a463412af1f1ed0f354113dd4467e4f6c1>", + "tx_size": 5870 + },{ + "amount": 300000000000, + "global_index": 794232, + "spent": false, + "tx_hash": "<c391089f5b1b02067acc15294e3629a463412af1f1ed0f354113dd4467e4f6c1>", + "tx_size": 5870 + },{ + "amount": 50000000000, + "global_index": 213659, + "spent": false, + "tx_hash": "<c391089f5b1b02067acc15294e3629a463412af1f1ed0f354113dd4467e4f6c1>", + "tx_size": 5870 + }] + } +} + +Example (Return "unavailable" transaction. Note that this particular example returns 0 unavailable transactions): + +{:.cli-code} +[ monero->~ ]$ curl -X POST http://127.0.0.1:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"incoming_transfers","params":{"transfer_type":"unavailable"}}' -H 'Content-Type: application/json' +{ + "id": "0", + "jsonrpc": "2.0", + "result": { + } +} + + +### query_key + +Return the spend or view private key. + +Inputs: + +* *key_type* - string; Which key to retrieve: "mnemonic" - the mnemonic seed (older wallets do not have one) OR "view_key" - the view key + +Outputs: + +* *key* - string; The view key will be hex encoded, while the mnemonic will be a string of words. + +Example (Query view key): + +{:.cli-code} +[ monero->~ ]$ curl -X POST http://127.0.0.1:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"query_key","params":{"key_type":"view_key"}}' -H 'Content-Type: application/json' +{ + "id": "0", + "jsonrpc": "2.0", + "result": { + "key": "7e341d..." + } +} + +Example (Query mnemonic key): + +{:.cli-code} +[ monero->~ ]$ curl -X POST http://127.0.0.1:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"query_key","params":{"key_type":"mnemonic"}}' -H 'Content-Type: application/json' +{ + "id": "0", + "jsonrpc": "2.0", + "result": { + "key": "adapt adapt nostril ..." + } +} + + +### make_integrated_address + +Make an integrated address from the wallet address and a payment id. + +Inputs: + +* *payment_id* - string; hex encoded; can be empty, in which case a random payment id is generated + +Outputs: + +* *integrated_address* - string + +Example (Payment ID is empty, use a random ID): + +{:.cli-code} +[ monero->~ ]$ curl -X POST http://127.0.0.1:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"make_integrated_address","params":{"payment_id":""}}' -H 'Content-Type: application/json' +{ + "id": "0", + "jsonrpc": "2.0", + "result": { + "integrated_address": "4BpEv3WrufwXoyJAeEoBaNW56ScQaLXyyQWgxeRL9KgAUhVzkvfiELZV7fCPBuuB2CGuJiWFQjhnhhwiH1FsHYGQQ8H2RRJveAtUeiFs6J" + } +} + + +### split_integrated_address + +Retrieve the standard address and payment id corresponding to an integrated address. + +Inputs: + +* *integrated_address* - string + +Outputs: + +* *standard_address* - string +* *payment* - string; hex encoded + +Example: + +{:.cli-code} +[ monero->~ ]$ curl -X POST http://127.0.0.1:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"split_integrated_address","params":{"integrated_address": "4BpEv3WrufwXoyJAeEoBaNW56ScQaLXyyQWgxeRL9KgAUhVzkvfiELZV7fCPBuuB2CGuJiWFQjhnhhwiH1FsHYGQQ8H2RRJveAtUeiFs6J"}}' -H 'Content-Type: application/json' +{ + "id": "0", + "jsonrpc": "2.0", + "result": { + "payment_id": "<420fa29b2d9a49f5>", + "standard_address": "427ZuEhNJQRXoyJAeEoBaNW56ScQaLXyyQWgxeRL9KgAUhVzkvfiELZV7fCPBuuB2CGuJiWFQjhnhhwiH1FsHYGQGaDsaBA" + } +} + + +### stop_wallet + +Stops the wallet, storing the current state. + +Inputs: *None*. + +Outputs: *None*. + +Example: + +{:.cli-code} +[ monero->~ ]$ curl -X POST http://127.0.0.1:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"stop_wallet"}' -H 'Content-Type: application/json' +{ + "id": "0", + "jsonrpc": "2.0", + "result": { + } +} + + +### make_uri + +Create a payment URI using the official URI spec. + +Inputs: + +* *address* - wallet address string +* *amount* (optional) - the integer amount to receive, in **atomic** units +* *payment_id* (optional) - 16 or 64 character hexadecimal payment id string +* *recipient_name* (optional) - string name of the payment recipient +* *tx_description* (optional) - string describing the reason for the tx + +Outputs: + +* *uri* - a string containing all the payment input information as a properly formatted payment URI + +Example: + +{:.cli-code} +[ monero->~ ]$curl -X POST http://127.0.0.1:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"make_uri","params":{"address":"44AFFq5kSiGBoZ4NMDwYtN18obc8AemS33DBLWs3H7otXft3XjrpDtQGv7SqSsaBYBb98uNbr2VBBEt7f2wfn3RVGQBEP3A","amount":10,"payment_id":"0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef","tx_description":"Testing out the make_uri function.","recipient_name":"Monero Project donation address"}}' -H 'Content-Type: application/json' +{ + "id": 0, + "jsonrpc": "2.0", + "result": { + "uri": "monero:44AFFq5kSiGBoZ4NMDwYtN18obc8AemS33DBLWs3H7otXft3XjrpDtQGv7SqSsaBYBb98uNbr2VBBEt7f2wfn3RVGQBEP3A?tx_payment_id=0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef&tx_amount=0.000000000010&recipient_name=Monero%20Project%20donation%20address&tx_description=Testing%20out%20the%20make_uri%20function." + } +} + + +## parse_uri + +Parse a payment URI to get payment information. + +Inputs: + +* *uri* - a string containing all the payment input information as a properly formatted payment URI + +Outputs: + +* *uri* - JSON object containing parment information: + * *address* - wallet address string + * *amount* - the decimal amount to receive, in **coin** units (0 if not provided) + * *payment_id* - 16 or 64 character hexadecimal payment id string (empty if not provided) + * *recipient_name* - string name of the payment recipient (empty if not provided) + * *tx_description* - string describing the reason for the tx (empty if not provided) + +Example: + +{:.cli-code} +[ monero->~ ]$curl -X POST http://127.0.0.1:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"parse_uri","params":{"uri":"monero:44AFFq5kSiGBoZ4NMDwYtN18obc8AemS33DBLWs3H7otXft3XjrpDtQGv7SqSsaBYBb98uNbr2VBBEt7f2wfn3RVGQBEP3A?tx_payment_id=0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef&tx_amount=0.000000000010&recipient_name=Monero%20Project%20donation%20address&tx_description=Testing%20out%20the%20make_uri%20function."}}' -H 'Content-Type: application/json' +{ + "id": 0, + "jsonrpc": "2.0", + "result": { + "uri": { + "address": "44AFFq5kSiGBoZ4NMDwYtN18obc8AemS33DBLWs3H7otXft3XjrpDtQGv7SqSsaBYBb98uNbr2VBBEt7f2wfn3RVGQBEP3A", + "amount": 10, + "payment_id": "0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef", + "recipient_name": "Monero Project donation address", + "tx_description": "Testing out the make_uri function." + } + } +} diff --git a/resources/moneropedia/00-base-00 b/resources/moneropedia/00-base-00 new file mode 100644 index 00000000..ccfa1781 --- /dev/null +++ b/resources/moneropedia/00-base-00 @@ -0,0 +1,10 @@ +--- +layout: moneropedia +entry: "" +terms: ["", ""] +summary: "" +--- + +### The Basics + +{{ page.summary | capitalize }}. \ No newline at end of file diff --git a/resources/moneropedia/account.md b/resources/moneropedia/account.md new file mode 100644 index 00000000..29d1fa36 --- /dev/null +++ b/resources/moneropedia/account.md @@ -0,0 +1,67 @@ +--- +layout: moneropedia +entry: "Account" +terms: ["account", "accounts", "wallet", "wallets"] +summary: "similar in function to a bank account, contains all of your sent and received transactions" +--- + +### The Basics + +Those familiar with Monero's predecessors will be more familiar with the term *wallet* to describe this. In Monero we call this an account, and it is a private account owned and operated by a Monero user. + +Your account contains all of the Monero @transactions you have sent and received. Your account balance is a sum of all the Monero you've received, less the Monero you've sent. When using Monero you may notice that your account has two balances, a locked and an unlocked balance. The unlocked balance contains funds that can be spent immediately, and the locked balance contains funds that you can't spend right now. You may receive a transaction that has an @unlock-time set, or you may have sent some Monero and are waiting for the @change to come back to your wallet, both situations that could lead to those funds being locked for a time. + +A key difference between traditional electronic currency and Monero is that your account resides only under your control, normally on your computer, and cannot be accessed by anyone else if you [practice good security](#practicing-good-security). + +### Multiple Accounts + +There are no costs attached to creating a Monero account, and there are no fees charged except for individual @transaction fees that go to @miners. + +This means that individuals can easily create a Monero account for themselves as well as a joint account to share with their partner, and individual accounts for their children. Similarly, a business could create separate accounts for each division or group. Since Monero's @transaction fees are quite low, moving funds between accounts is not an expensive exercise. + +### Cryptographic Keys + +Monero relies heavily on a cryptography principle known as *public/private key cryptography* or *asymmetric cryptography*, which is thoroughly detailed in [this Wikipedia article](https://en.wikipedia.org/wiki/Public-key_cryptography). + +Your account is based on two keys, a @spend-key and a @view-key. The @spend-key is special in that it is the single key required to spend your Monero funds, whereas the @view-key allows you to reveal your @transactions to a third party, for example for auditing or accounting purposes. These keys in your account also play an important role in Monero's @transaction-privacy. + +The private keys for both of these must be protected by you in order to retain your account privacy. On the other hand, the public keys are obviously public (they are part of your Monero account address). For normal public/private key cryptography someone could send you a private message by encrypting it with either of your public keys, and you would then be the only one able to decrypt it with your private keys. + +### Backing Up Your Account + +When you have manage your own Monero Account with the private @spend-key, you are solely responsible for the security of your funds. Thankfully, Monero makes it very easy to backup your account. When creating a Monero account for the first time you will be given a unique @mnemonic-seed for your account that consists of 13 or 25 words in the language of your choosing. **This seed is the only thing you need to backup for your account**, and so it is imperative that it is written down and stored securely. Never store this seed in a form or location that would allow someone else to see it! + +{:.cli-code} +List of available languages for your wallet's seed: +0 : English +1 : Spanish +2 : Portuguese +3 : Japanese +Enter the number corresponding to the language of your choice: 0 +Generated new wallet: 4B15ZjveuttEaTmfZjLVioPVw7bfSmRLpSgB33CJbuC6BoGtZrug9TDAmhZEWD6XoFDGz55bgzisT9Dnv61sbsA6Sa47TYu +view key: 4130fa26463d9451781771a8baa5d0b8085c47c4500cefe4746bab48f1d15903 +\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\* +Your wallet has been generated. +To start synchronizing with the daemon use "refresh" command. +Use "help" command to see the list of available commands. +Always use "exit" command when closing monero-wallet-cli to save +current session's state. Otherwise, you will possibly need to synchronize +your wallet again. Your wallet key is NOT under risk anyway.
+PLEASE NOTE: the following 25 words can be used to recover access to your wallet. Please write them down and store them somewhere safe and secure. Please do not store them in your email or on file storage services outside of your immediate control.
+aunt knuckle italics moisture hawk thorn iris abort +chlorine smog uphill glass aptitude nowhere sewage plywood +dual relic fierce divers anvil nodes bubble cabin abort +\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\* +[wallet 4B15Zj]: █
+ +As the example above indicates, it is incredibly important to store these words in safe locations. If you are concerned about the risk of critical loss at your home, for instance, you may want to store a second copy of your seed with your attorney or in a safety deposit box. It is also recommended that it is stored in a way that does not make it obvious that it is your seed, so writing it into a letter or as part of other notes is advisable. + +### Practicing Good Security + +Over and above backing up your @mnemonic-seed so that you have access to your account in the event of critical data loss, it is also important to practice good security. Use a secure password when creating a local Monero account (not used on [MyMonero](https://mymonero.com) or other web-based account systems). + +Don't ever give your Monero account password to anyone, as this can be used to access the Monero on your computer without knowing your @mnemonic-seed. Similarly, make sure you have running and up-to-date antivirus, especially on Windows computers. Finally, be careful when clicking links in emails or on unknown and untrusted websites, as malware installed on your computer can sit and wait for you to access your Monero account before taking the funds from it. + +### Leaving Your Account to Next of Kin + +Providing access to your Monero account to your next of kin is just as easy as it is to backup your Monero account. Simply leave your @mnemonic-seed to them in your will, or store it somewhere safe where it will be given to them upon the execution of your will. A key advantage to this is that your next of kin won't have to wait for months for a third party to release the funds to them. diff --git a/resources/moneropedia/address-book.md b/resources/moneropedia/address-book.md new file mode 100644 index 00000000..43b159c9 --- /dev/null +++ b/resources/moneropedia/address-book.md @@ -0,0 +1,35 @@ +--- +layout: moneropedia +entry: "Address Book" +tags: ["kovri"] +terms: ["Address-Book"] +summary: "Allows you to visit I2P websites/services that have the .i2p domain" +--- + +### The Basics + +In order to browse @I2P sites or services with @Kovri, you'll need an address book. An address book will allow you to translate @I2P websites/services that use the `.i2p` [top-level domain](https://en.wikipedia.org/wiki/Top_level_domain) into an address that @I2P network will understand. + +Without an address book, you would be stuck using a @base32-address every time you visit an @I2P website/service - and that's not fun! + +### In-depth information + +Since [DNS](https://en.wikipedia.org/wiki/DNS) does not exist on the @I2P network, @Kovri also does **not** use DNS or any sort of @canonically-unique-host resolution. Instead, Kovri pairs a @locally-unique-host to a @base64-address @destination in a @subscription. Once your address book is filled with a @subscription, you can resolve your favorite `.i2p` domain site into a usable @I2P destination. + +### Creating an Address Book + +By default, your installation will come with a default public @subscription called `hosts.txt` in your @data-directory. When @Kovri starts, it loads this subscription and fetches any other subscriptions you've specified. Once loaded, your address book will be appropriately filled. For details on how to manage subscriptions, see @subscription. + +### Updating the Address Book + +Currently, there are several ways to update your address book: + +1. Use a @jump-service to insert I2P addresses into your address book +2. Use a @jump-service to copy/paste an address into your private @subscription +3. Manually add or subtract from a private @subscription + +**Note: Kovri is in heavy development. In the future there *will* be easier ways to update the address book** + +### Address Book / Naming specification + +For specification details and more, visit the [Address Book and Naming Specification](https://geti2p.net/en/docs/naming) diff --git a/resources/moneropedia/address.md b/resources/moneropedia/address.md new file mode 100644 index 00000000..ed33f15a --- /dev/null +++ b/resources/moneropedia/address.md @@ -0,0 +1,22 @@ +--- +layout: moneropedia +entry: "Address" +terms: ["address", "addresses"] +summary: "either an alias, such as donate.getmonero.org, or a set of 95 characters starting with a 4" +--- + +### The Basics + +When you send Monero to someone you only need one piece of information, and that is their Monero address. A *raw* Monero address is a set of 95 characters starting with a '4'. The Monero donation address, for instance, is 44AFFq5kSiGBoZ4NMDwYtN18obc8AemS33DBLWs3H7otXft3XjrpDtQGv7SqSsaBYBb98uNbr2VBBEt7f2wfn3RVGQBEP3A. + +Because those addresses are long and complex you will often encounter an @OpenAlias address instead. For example, Monero donations can be sent to donate@getmonero.org or donate.getmonero.org. + +If you would like to get an @OpenAlias address of your own then there is some information on the [OpenAlias page](/knowledge-base/openalias). + +### Integrated address + +An integrated address is an address combined with an encrypted 64-bit @payment-ID. A raw integrated address is 106 characters long. + +### In-depth Information + +The address is actually the concatenation, in Base58 format, of the *public* @spend-key and the *public* @view-key, prefixed with the network byte (the number 18 for Monero) and suffixed with the first four bytes of the Keccac-256 hash of the whole string (used as a checksum). diff --git a/resources/moneropedia/airgap.md b/resources/moneropedia/airgap.md new file mode 100644 index 00000000..3fa7966d --- /dev/null +++ b/resources/moneropedia/airgap.md @@ -0,0 +1,12 @@ +--- +layout: moneropedia +entry: "Airgap" +terms: ["airgap"] +summary: "An airgap is a security measure to physically seperate a computer or device from all other networks, such as the Internet." +--- + +### The Basics + +"An air gap, air wall or air gapping is a network security measure employed on one or more computers to ensure that a secure computer network is physically isolated from unsecured networks, such as the public Internet or an unsecured local area network.[2] The name arises from the technique of creating a network that is physically separated (with a conceptual air gap) from all other networks. The air gap may not be completely literal, as networks employing the use of dedicated cryptographic devices that can tunnel packets over untrusted networks while avoiding packet rate or size variation can be considered air gapped, as there is no ability for computers on opposite sides of the gap to communicate." + +Taken from https://en.wikipedia.org/wiki/Air_gap_(networking) diff --git a/resources/moneropedia/base32-address.md b/resources/moneropedia/base32-address.md new file mode 100644 index 00000000..ef38e414 --- /dev/null +++ b/resources/moneropedia/base32-address.md @@ -0,0 +1,27 @@ +--- +layout: moneropedia +entry: "Base32 address" +tags: ["kovri"] +terms: ["Base32-address", "Base32-addresses"] +summary: "Base32 encoded hash of a Base64 address" +--- + +### The Basics + +A Base32 address is a shortened, encoded version of an @I2P address. The Base32 address is the first part in a `.b32.i2p` hostname. + +Example: + +`i35yftyyb22xhcvghmev46t5knefur5v66qzekkajatwfwhyklvq.b32.i2p` + +where + +`i35yftyyb22xhcvghmev46t5knefur5v66qzekkajatwfwhyklvq` is the Base32 address. + +### In-depth Information + +Ultimately, a Base32 address is a 52 character [Base32 encoded representation](https://en.wikipedia.org/wiki/Base32) of the full SHA-256 hash of an @I2P @base64-address. + +### Notes + +**Note: `.b32` is not a sub-domain of `.i2p`** diff --git a/resources/moneropedia/base64-address.md b/resources/moneropedia/base64-address.md new file mode 100644 index 00000000..a704aaf2 --- /dev/null +++ b/resources/moneropedia/base64-address.md @@ -0,0 +1,20 @@ +--- +layout: moneropedia +entry: "Base64 address" +tags: ["kovri"] +terms: ["Base64-address", "Base64-addresses"] +summary: "Base64 encoded I2P destination" +--- + +### The Basics + +A @base64-address is a 516-character [Base64 encoded](https://en.wikipedia.org/wiki/Base64) @I2P @destination. @base64-addresses are primarily used for @address-book, @jump-service, and also internally. + +Example: + +{:.cli-code} +AQZGLAMpI9Q0l0kmMj1vpJJYK3CjLp~fE3MfvE-e7KMKjI5cPOH6EN8m794uHJ6b09qM8mb9VEv1lVLEov~usVliTSXCSHuRBOCIwIOuDNU0AbVa4BpIx~2sU4TxKhoaA3zQ6VzINoduTdR2IJhPvI5xzezp7dR21CEQGGTbenDslXeQ4iLHFA2~bzp1f7etSl9T2W9RID-KH78sRQmzWnv7dbhNodMbpO6xsf1vENf6bMRzqD5vgHEHZu2aSoNuPyYxDU1eM6--61b2xp9mt1k3ud-5WvPVg89RaU9ugU5cxaHgR927lHMCAEU2Ax~zUb3DbrvgQBOTHnJEx2Fp7pOK~PnP6ylkYKQMfLROosLDXinxOoSKP0UYCh2WgIUPwE7WzJH3PiJVF0~WZ1dZ9mg00c~gzLgmkOxe1NpFRNg6XzoARivNVB5NuWqNxr5WKWMLBGQ9YHvHO1OHhUJTowb9X90BhtHnLK2AHwO6fV-iHWxRJyDabhSMj1kuYpVUBQAEAAcAAA== + +### In-depth Information + +See @destination for details behind @base64-address diff --git a/resources/moneropedia/block.md b/resources/moneropedia/block.md new file mode 100644 index 00000000..cadae194 --- /dev/null +++ b/resources/moneropedia/block.md @@ -0,0 +1,16 @@ +--- +layout: moneropedia +entry: "Block" +terms: ["block", "blocks"] +summary: "a container of transactions, a sequence of which forms a blockchain" +--- + +### The Basics + +A block is a container of @transactions, with a new block being added to the @blockchain once every 2 minutes (see constant `DIFFICULTY_TARGET_V2` defined as 120 seconds), on average. + +Blocks also contain a special type of transaction, the @coinbase-transaction, which add newly created Monero to the network. + +Blocks are created through the process of @mining, and the @node that successfully mines the block then broadcasts it to each of the @nodes connected to it, who subsequently re-broadcast the block until the entire Monero network has received it. + +Fake or bad blocks generally cannot be created, as @nodes that receive blocks always verify the @transactions they contain against a set of consensus rules that all nodes adhere to, including validating the cryptographic @signatures on each transaction. diff --git a/resources/moneropedia/blockchain.md b/resources/moneropedia/blockchain.md new file mode 100644 index 00000000..d3d6ec5f --- /dev/null +++ b/resources/moneropedia/blockchain.md @@ -0,0 +1,13 @@ +--- +layout: moneropedia +entry: "Blockchain" +terms: ["blockchain", "blockchains"] +summary: "a distributed ledger of all transactions both past and present, without revealing who the funds came from or went to" + +--- + +### The Basics +A @blockchain is a distributed database that continuously grows with a record of all of the transactions that have occurred with a given cryptocurrency. This database is often referred to as a ledger because the data contains a large list of transctions that have taken place. In Monero, these transactions are packaged together into 'blocks' every 2 minutes (on average) and all miners and nodes on the network have copies of these blocks. + +### Monero's @Blockchain +Unlike Bitcoin and other cryptocurrencies, transactions in the Monero @blockchain do not reveal where funds came from or went to, providing anonymity and making the currency completely @fungible. Additionaly, the amounts of all transactions are hidden by @RingCT, a feature of Monero. For auditing or other transparency purposes a user can share a @view-key to prove they control certain amounts of @Moneroj. diff --git a/resources/moneropedia/canonically-unique-host.md b/resources/moneropedia/canonically-unique-host.md new file mode 100644 index 00000000..c1138992 --- /dev/null +++ b/resources/moneropedia/canonically-unique-host.md @@ -0,0 +1,23 @@ +--- +layout: moneropedia +entry: "Canonically-unique host" +tags: ["kovri"] +terms: ["Canonically-unique-host"] +summary: "A host that is canonically resolved to an address or set of addresses" +--- + +### The Basics + +A Canonically-unique host is a [FQDN](https://en.wikipedia.org/wiki/FQDN) that will canonically resolve to a designated address or set of addresses. Not to be confused with a @locally-unique-host. + +### In-depth information + +A Canonically-unique host is defined by remote authoritative sources; usually through [DNS](https://en.wikipedia.org/wiki/DNS). When resolving a peer's hostname, you will most likely use an external source for resolution unless you have the following implemented: + +- a database file similar to a [hosts file](https://en.wikipedia.org/wiki/etc/hosts) +- an internal-network resolver (which eventually pulls from external sources) + +### Notes + +- Monero primarily uses @canonically-unique-host resolution while @I2P only uses @locally-unique-host resolution. +- @I2P's and @Kovri's self-assigned top-level domain is currently `.i2p` and @Kovri intends to only process/use the `.i2p` [top-level domain](https://en.wikipedia.org/wiki/Top_level_domain) diff --git a/resources/moneropedia/change.md b/resources/moneropedia/change.md new file mode 100644 index 00000000..2db0ceb4 --- /dev/null +++ b/resources/moneropedia/change.md @@ -0,0 +1,10 @@ +--- +layout: moneropedia +entry: "Change" +terms: ["change"] +summary: "Monero sent as part of a transaction, but unique in that returns to your account instead of going to a recipient" +--- + +### The Basics + +{{ page.summary | capitalize }}. \ No newline at end of file diff --git a/resources/moneropedia/clearnet.md b/resources/moneropedia/clearnet.md new file mode 100644 index 00000000..9200e69a --- /dev/null +++ b/resources/moneropedia/clearnet.md @@ -0,0 +1,33 @@ +--- +layout: moneropedia +entry: "Clearnet" +tags: ["kovri"] +terms: ["Clearnet"] +summary: "The internet in which anonymous overlay networks are built upon" +--- + +### The Basics + +When you use the internet for things like news, email, social media, and even Monero, you are most likely using a clearnet connection. This means that *all* of your connections can be tracked, traced, and monitored by: + +- your [ISP](https://en.wikipedia.org/wiki/ISP) +- the website/service/person you're communicating with +- possibly a [Five Eyes](https://en.wikipedia.org/wiki/5_Eyes) capable entity + +and even if you use [HTTPS](https://en.wikipedia.org/wiki/HTTPS) or similar (which *encrypts* your transmission), your route is not hidden nor is it anonymous, thus; it is in the *clear*. + +### In-depth information + +Since a traditional [VPN](https://en.wikipedia.org/wiki/VPN) cannot save you from clearnet (as you are still using *clearnet* (though you are more proxied than without a VPN)), you should use an *anonymous overlay network* to avoid using clearnet directly: + +- @Kovri +- @Java-I2P +- [Tor](https://torproject.org/) + +These technologies protect you from clearnet by building an anonymous network **over** clearnet to keep your transmissions both encrypted **and** anonymous. + +Here is an accurate, [interactive diagram](https://www.eff.org/pages/tor-and-https) provided by the [EFF](https://www.eff.org/) which describes *clearnet* as it relates to **Tor**. The concept also (somewhat) applies to @Kovri and @I2P in terms of anonymity with the exception that: + +- @Kovri does not use exit nodes when connecting to an @eepsite +- Your traffic never need to leave the @I2P network +- You do not need HTTPS to use @Kovri (with the exception of @reseed) diff --git a/resources/moneropedia/coinbase.md b/resources/moneropedia/coinbase.md new file mode 100644 index 00000000..4c564e4b --- /dev/null +++ b/resources/moneropedia/coinbase.md @@ -0,0 +1,10 @@ +--- +layout: moneropedia +entry: "Coinbase Transaction" +terms: ["coinbase-transaction"] +summary: "a special type of transaction included in each block, which contains a small amount of Monero sent to the miner as a reward for their mining work" +--- + +### The Basics + +{{ page.summary | capitalize }}. \ No newline at end of file diff --git a/resources/moneropedia/consensus.md b/resources/moneropedia/consensus.md new file mode 100644 index 00000000..192e9d9e --- /dev/null +++ b/resources/moneropedia/consensus.md @@ -0,0 +1,10 @@ +--- +layout: moneropedia +entry: "Consensus" +terms: ["consensus", "consensus-network"] +summary: "consensus describes a property of distributed networks like Monero where most of the participants follow the rules, and thus reject bad participants" +--- + +### The Basics + +{{ page.summary | capitalize }}. \ No newline at end of file diff --git a/resources/moneropedia/cryptocurrency.md b/resources/moneropedia/cryptocurrency.md new file mode 100644 index 00000000..8c4343d9 --- /dev/null +++ b/resources/moneropedia/cryptocurrency.md @@ -0,0 +1,10 @@ +--- +layout: moneropedia +entry: "Cryptocurrency" +terms: ["cryptocurrency", "cryptocurrencies", "altcoin", "altcoins"] +summary: "digital currencies that do not have a central point of control, operating in a distributed peer-to-peer network" +--- + +### The Basics + +{{ page.summary | capitalize }}. \ No newline at end of file diff --git a/resources/moneropedia/data-directory.md b/resources/moneropedia/data-directory.md new file mode 100644 index 00000000..e66f6959 --- /dev/null +++ b/resources/moneropedia/data-directory.md @@ -0,0 +1,22 @@ +--- +layout: moneropedia +entry: "Data Directory" +tags: ["kovri"] +terms: ["Data-Directory"] +summary: "Where essential kovri data for runtime is stored" +--- + +### The Basics + +Depending on your OS, @Kovri currently stores all run-time data in the following directory: + +- Linux/FreeBSD: + - `$HOME/.kovri` + +- OSX: + - `$HOME/Library/Application\ Support/Kovri` + +- Windows: + - `"$APPDATA"\\Kovri` + +This includes all configuration files, @address-book, certificates, and resources. diff --git a/resources/moneropedia/destination.md b/resources/moneropedia/destination.md new file mode 100644 index 00000000..a999bebf --- /dev/null +++ b/resources/moneropedia/destination.md @@ -0,0 +1,19 @@ +--- +layout: moneropedia +entry: "Destination" +tags: ["kovri"] +terms: ["Destination", "Destinations"] +summary: "A in-net address that serves as a final endpoint (either local or remote)" +--- + +### The Basics + +A @destination is the @I2P @in-net address of the final endpoint you are trying to connect to (example: an @I2P website, service, or Monero node). This can also include a *local destination* of which *other* peers need to connect to in order to make contact for communication (similar to how, in @clearnet, your IP address is given to a website when you connect so it knows *where* to send the information back to). + +### In-depth Information + +An @I2P destination can be encoded into a @base32-address or @base64-address. Most users will only care about @base32-address or a `.i2p` hostname while, internally, @Kovri / @I2P @address-book uses @base64-addresses. Ultimately, all @destinations in @I2P are 516-byte (or longer) keys: + +`256-byte public key + 128-byte signing key + a null certificate = 516 bytes in Base64 representation` + +Note: certificates are not used now but, if they were, the keys would be longer. diff --git a/resources/moneropedia/eepsite.md b/resources/moneropedia/eepsite.md new file mode 100644 index 00000000..5fbb9545 --- /dev/null +++ b/resources/moneropedia/eepsite.md @@ -0,0 +1,30 @@ +--- +layout: moneropedia +entry: "Eepsite" +tags: ["kovri"] +terms: ["Eepsite", "Hidden-Service", "Garlic-Site", "Garlic-Service"] +summary: "A website or service hosted within the I2P network" +--- + +### The Basics + +Is it [**EEP!** *(in response to the site's content)*](https://en.wikipedia.org/wiki/Onomatopoeia), or **end-to-end protocol**, or something else entirely different? + +While the original definition of eepsite has been lost with time, its use-case remains: an eepsite is a website or service that is hosted within (and only accessible by) the @I2P network. + +### In-depth Information + +Alternate names include: + +1. *Hidden Service* + - because the site/service is *hidden* within the @I2P network and can only be visited within the network +2. *Garlic Site* + - because the website utilizes @I2P's @garlic-routing technology as a means of communicating with a client + - because the service is hosted as a website and not any other type of service +3. *Garlic Service* + - because the service utilizes @I2P's @garlic-routing technology as a means of communicating with a client + - because the service is specific to services like IRC, email, or a Monero peer (but may also include websites) + +### Notes + +To learn how to setup an Eepsite (Hidden Service, Garlic Site, Garlic Service) visit the @Kovri [user-guide](https://github.com/monero-project/kovri/blob/master/doc/USER_GUIDE.md). diff --git a/resources/moneropedia/encryption.md b/resources/moneropedia/encryption.md new file mode 100644 index 00000000..d9356c4b --- /dev/null +++ b/resources/moneropedia/encryption.md @@ -0,0 +1,35 @@ +--- +layout: moneropedia +entry: "Encryption" +tags: ["kovri"] +terms: ["encryption", "encrypted", "encrypting", "decryption", "decrypted", "decrypting"] +summary: "The process of encoding messages or information in a way that only authorized parties can decode and read" +--- + +### The Basics + +From [Encryption](https://en.wikipedia.org/wiki/Encryption): + +> +In cryptography, encryption is the process of encoding messages or information in such a way that only authorized parties can decode and read what is sent. Encryption does not of itself prevent interception, but denies the message content to the interceptor. + +### In-depth information + +From [Encryption](https://en.wikipedia.org/wiki/Encryption): + +> + In an encryption scheme, the intended communication information or message (referred to as *plaintext*), is encrypted using an encryption algorithm, generating ciphertext that can only be read if decrypted. For technical reasons, an encryption scheme usually uses a pseudo-random encryption key generated by an algorithm. It is in principle possible to decrypt the message without possessing the key, but, for a well-designed encryption scheme, large computational resources and skill are required. An authorized recipient can easily decrypt the message with the key provided by the originator to recipients, but not to unauthorized interceptors. + +> +The purpose of encryption is to ensure that only somebody who is authorized to access data (e.g. a text message or a file), will be able to read it, using the decryption key. Somebody who is not authorized can be excluded, because he or she does not have the required key, without which it is impossible to read the encrypted information. + +### Kovri + +@Kovri implements various types of encryption in *at least* 4 essential capacities: + +- @Reseed for bootstrapping +- @Garlic-routing: three layers of encryption (@garlic-encryption) are used to verify the secure delivery of @messages to the recipient/peer/@destination +- @Tunnel encryption: garlic messages are passed through a @tunnel and encrypted by the @tunnel gateway to the @tunnel endpoint +- @Transport layer encryption prevents the ability to decrypt @messages at the [media layer](https://en.wikipedia.org/wiki/OSI_model) + +For details on the types of encryption and cryptographic @signatures used in @Kovri and @I2P, visit @Java-I2P's [Cryptography](https://geti2p.net/spec/cryptography) diff --git a/resources/moneropedia/floodfill.md b/resources/moneropedia/floodfill.md new file mode 100644 index 00000000..e3fbf54f --- /dev/null +++ b/resources/moneropedia/floodfill.md @@ -0,0 +1,15 @@ +--- +layout: moneropedia +entry: "Floodfill" +tags: ["kovri"] +terms: ["Floodfill"] +summary: "An I2P router which maintains a distributed network-database" +--- + +### The Basics + +By actively managing a distributed network-database, a router with *floodfill* capability has the ability to help maintain network stability and resiliancy while also being decentralized and trust-less. + +### In-depth information + +Though floodfill itself is a simple storage system, the technical underpinnings of floodfill as it relates to @network-database and other protocols within @I2P are much more complex. Visit the [Network Database](https://geti2p.net/en/docs/how/network-database) page for details. diff --git a/resources/moneropedia/fungibility.md b/resources/moneropedia/fungibility.md new file mode 100644 index 00000000..d698978e --- /dev/null +++ b/resources/moneropedia/fungibility.md @@ -0,0 +1,16 @@ +--- +layout: moneropedia +entry: "Fungibility" +terms: ["fungibility"] +summary: "property of a currency whereby two units can be substituted in place of one another" +--- + +### The Basics + +Fungibility means that two units of a currency can be mutually substituted and the substituted currency is equal to another unit of the same size. For example, two $10 bills can be exchanged and they are functionally identical to any other $10 bills in circulation (although $10 bills have unique ID numbers and are therefore not completely fungible). Gold is probably a closer example of true fungibility, where any 1 oz. of gold of the same grade is worth the same as another 1 oz of gold. Monero is fungible due to the nature of the currency which provides no way to link transactions together nor trace the history of any perticular XMR. 1 XMR is functionally identical to any other 1 XMR. + +Fungibility is an advantage Monero has over Bitcoin and almost every other cryptocurrency, due to the privacy inherent in the Monero @blockchain and the permanently traceable nature of the Bitcoin blockchain. With Bitcoin, any BTC can be tracked by anyone back to it's creation @coinbase-transaction. Therefore, if a coin has been used for an illegal purpose in the past, this history will be contained in the @blockchain in perpetuity. This lack of fungibility means that certain businesses will be obligated to avoid accepting BTC that have been previously used for purposes which are illegal, or simply run afoul of their Terms of Service. Currently some large Bitcoin companies are blocking, suspending, or closing accounts that have received Bitcoin used in online gambling or other purposes deemed unsavory by said companies. + +Monero has been built specifically to address the problem of traceability and non-fungability inherent in other cryptocurrencies. By having completely private transactions Monero is truly fungible and there can be no blacklisting of certain XMR, while at the same time providing all the benefits of a secure, decentralized, permanent blockchain. + +{{ page.summary | capitalize }}. diff --git a/resources/moneropedia/garlic-encryption.md b/resources/moneropedia/garlic-encryption.md new file mode 100644 index 00000000..3364f521 --- /dev/null +++ b/resources/moneropedia/garlic-encryption.md @@ -0,0 +1,25 @@ +--- +layout: moneropedia +entry: "Garlic-Encryption" +tags: ["kovri"] +terms: ["Garlic-Encryption", "Layered-Encryption"] +summary: "Layered encryption as implemented in Kovri / I2P" +--- + +### The Basics + +@garlic-encryption is @I2P's implementation of @message based @layered-encryption (similar to flow-based [Onion-Routing](https://en.wikipedia.org/wiki/Onion_routing)). + +By @encrypting @messages in layers, this allows a @message to be routed through a sequence of proxies without allowing the proxies (or any intermediaries) to read the contents of the @message. @Layered-Encryption is a fundamental feature in @Kovri, @I2P, and [Tor](https://torproject.org) and is the cornerstone for securing anonymity within these overlay-networks. + +### In-depth information + +For @garlic-encryption, the primary difference between @Kovri/@I2P and Tor is: + +- @Kovri/@I2P bundles multiple @messages together to form garlic "cloves" + - any number of messages can be contained in a "clove" instead of *only* a single message +- @Kovri/@I2P uses [ElGamal](https://en.wikipedia.org/wiki/ElGamal)/[AES](https://en.wikipedia.org/wiki/Advanced_Encryption_Standard) @encryption for @messages and @transports + +### Notes + +For details, see @garlic-routing. diff --git a/resources/moneropedia/garlic-routing.md b/resources/moneropedia/garlic-routing.md new file mode 100644 index 00000000..37b0c082 --- /dev/null +++ b/resources/moneropedia/garlic-routing.md @@ -0,0 +1,45 @@ +--- +layout: moneropedia +entry: "Garlic Routing" +tags: ["kovri"] +terms: ["Garlic-Routing"] +summary: "Routing technology as implemented in Kovri" +--- + +### The Basics + +The term *@garlic-routing* has a diverse history of varying interpretations. As it currently stands, Monero defines *@garlic-routing* as the method in which @Kovri and @I2P create a @message-based anonymous overlay network of internet peers. + +The @Garlic-Encryption of @Garlic-Routing is similar to the @Layered-Encryption of [Onion Routing](https://en.wikipedia.org/wiki/Onion_routing) and effectively conceals the IP address of the sender and secures information sent from the sender to its @destination (and vice-versa). + +### History + +In written form, the term *@garlic-routing* can be seen as early as June of 2000 in Roger Dingledine's [Free Haven Master's thesis](http://www.freehaven.net/papers.html) (Section 8.1.1) as derived from the term Onion Routing. + +As recent as October of 2016, [#tor-dev](https://oftc.net/WebChat/) has offered insight into the creation of the term *@garlic-routing*: + +[Nick Mathewson](https://en.wikipedia.org/wiki/The_Tor_Project,_Inc): +>[I think that there was some attempt to come up with a plant whose structure resembled the 'leaky-pipe' topology of tor, but I don't believe we ever settled on one.] + +[Roger Dingledine](https://en.wikipedia.org/wiki/Roger_Dingledine): +>during the free haven brainstorming, there was a moment where we described a routing mechanism, and somebody said "garlic routing!", and everybody laughed. +so we for sure thought we had invented the name, at the time. + +*Note: permission to use the aforementioned quotes were granted by Nick Mathewson and Roger Dingledine* + +### In-depth Information + +In technical terms, for @Kovri and @I2P, *@garlic-routing* translates to any/all of the following: + +- @Layered-Encryption (similar to the @layered-encryption in Onion Routing) +- Bundling multiple @messages together (garlic cloves) +- ElGamal/AES @encryption + +*Note: though [Tor](https://torproject.org/) uses @layered-encryption, Tor does not use ElGamal and is not message-based.* + +**Read more in @garlic-encryption.** + +### Notes + +- In terms of Onion/Garlic Routing, another way to envision layered @encryption is by replacing the onion/garlic with a [Matryoshka doll](https://en.wikipedia.org/wiki/Matryoshka_doll) - with each outer/inner doll having a lock and public key to the next/previous doll +- For more technical details on Garlic Routing, read the @Java-I2P entry on [Garlic Routing](https://geti2p.net/en/docs/how/garlic-routing) diff --git a/resources/moneropedia/i2np.md b/resources/moneropedia/i2np.md new file mode 100644 index 00000000..d05c17aa --- /dev/null +++ b/resources/moneropedia/i2np.md @@ -0,0 +1,28 @@ +--- +layout: moneropedia +entry: "I2NP" +tags: ["kovri"] +terms: ["I2NP"] +summary: "The I2P Network Protocol: the mechanism in which I2NP messages are sent over the I2P network" +--- + +### The Basics + +From @Java-I2P: + +> +@I2NP manages the routing and mixing of messages between routers, as well as the selection of what transports to use when communicating with a peer for which there are multiple common transports supported + +### In-depth information + +From @Java-I2P: + +> +@I2NP (@I2P Network Protocol) @messages can be used for one-hop, router-to-router, point-to-point @messages. By @encrypting and wrapping @messages in other @messages, they can be sent in a secure way through multiple hops to the ultimate @destination. @I2NP does not specify nor require any particular @transport layer but does require at least one @transport in use. + +> +Whenever a @destination wants to send a message to to another @destination, it provides its local router with both the @destination structure and the raw bytes of the message to be sent. The router then determines where to send it, delivers it through outbound @tunnels, instructing the end point to pass it along to the appropriate inbound @tunnel, where it is passed along again to that @tunnel's end point and made available to the target for reception. + +### Notes + +Read more about the @I2NP [protocol](https://geti2p.net/en/docs/protocol/i2np) and [specification](https://geti2p.net/spec/i2np). diff --git a/resources/moneropedia/i2p.md b/resources/moneropedia/i2p.md new file mode 100644 index 00000000..2778db30 --- /dev/null +++ b/resources/moneropedia/i2p.md @@ -0,0 +1,31 @@ +--- +layout: moneropedia +entry: "I2P" +tags: ["kovri"] +terms: ["I2P"] +summary: "The Invisible Internet Project: an anonymizing overlay network" +--- + +### Monero + +For Monero's implementation of @I2P, see @Kovri. For a comparison of @I2P to [Tor](https://torproject.org/), read the [Comparison](https://geti2p.net/en/comparison/tor) page. + +### The Basics + +From @Java-I2P: + +>The I2P network provides strong privacy protections for communication over the Internet. Many activities that would risk your privacy on the public Internet can be conducted anonymously inside I2P. + +### In-depth information + +From @Java-I2P: + +>I2P is an anonymous overlay network - a network within a network. It is intended to protect communication from dragnet surveillance and monitoring by third parties such as ISPs. + +>I2P is used by many people who care about their privacy: activists, oppressed people, journalists and whistleblowers, as well as the average person. + +>No network can be "perfectly anonymous". The continued goal of I2P is to make attacks more and more difficult to mount. Its anonymity will get stronger as the size of the network increases and with ongoing academic review. + +### Notes + +@I2P documentation and specifications are available [here](https://geti2p.net/docs/). diff --git a/resources/moneropedia/i2pcontrol.md b/resources/moneropedia/i2pcontrol.md new file mode 100644 index 00000000..481d9eae --- /dev/null +++ b/resources/moneropedia/i2pcontrol.md @@ -0,0 +1,17 @@ +--- +layout: moneropedia +entry: "I2PControl" +tags: ["kovri"] +terms: ["I2PControl"] +summary: "An API inteface for Kovri and Java-I2P that allows simple remote control" +--- + +### The Basics + +@I2Pcontrol is [JSONRPC2](https://en.wikipedia.org/wiki/JSON-RPC) [API](https://en.wikipedia.org/wiki/Application_programming_interface) for @Kovri and @Java-I2P which allows an @I2PControl client to remote control/monitor a running instance. + +Two available @I2PControl clients are: [qtoopie](https://github.com/EinMByte/qtoopie) (C++ client) and [itoopie](https://github.com/i2p/i2p.itoopie) (Java client). Read `kovri.conf` to configure @I2PControl for @Kovri. + +### In-depth information + +Details and specification available on the [I2PControl](https://geti2p.net/en/docs/api/i2pcontrol) page. diff --git a/resources/moneropedia/in-net.md b/resources/moneropedia/in-net.md new file mode 100644 index 00000000..92404f08 --- /dev/null +++ b/resources/moneropedia/in-net.md @@ -0,0 +1,15 @@ +--- +layout: moneropedia +entry: "In-net" +tags: ["kovri"] +terms: ["In-net"] +summary: "Within the I2P network" +--- + +### The Basics + +**In-net** is a [colloquial](https://en.wikipedia.org/wiki/Colloquial) term of which describes activities, protocols, or functionality that exist *only* within the @I2P network. + +### In-depth information + +Example: *in-net download* would be defined as downloading *only* within @I2P. diff --git a/resources/moneropedia/index.md b/resources/moneropedia/index.md new file mode 100644 index 00000000..4489586c --- /dev/null +++ b/resources/moneropedia/index.md @@ -0,0 +1,21 @@ +--- +layout: full +title: "Moneropedia" +title-pre-kick: "Moneropedia - The " +title-kick: "Monero Wiki" +title-post-kick: "" +kick-class: "softyellow-kicks" +icon: "icon_wiki" +attribution: "" +--- + + +
+ +@moneropedia + +
+ +

Add New Entry

+ +If there is an entry you'd like to modify or be added, please [open an issue on this website's Github repository](https://github.com/monero-project/monero-site/issues) or submit changes via pull request. \ No newline at end of file diff --git a/resources/moneropedia/java-i2p.md b/resources/moneropedia/java-i2p.md new file mode 100644 index 00000000..e040579b --- /dev/null +++ b/resources/moneropedia/java-i2p.md @@ -0,0 +1,15 @@ +--- +layout: moneropedia +entry: "Java I2P" +tags: ["kovri"] +terms: ["Java-I2P"] +summary: "The original implementation of I2P - written in Java" +--- + +### The Basics + +The term "Java I2P" is often used to describe the original @I2P implementation currently most known and used today. There are various other @I2P implementations, including @Kovri; all of which look up to the original Java implementation. + +### Notes + +To download/learn more about the Java implementation, visit their [website](https://geti2p.net/). diff --git a/resources/moneropedia/jump-service.md b/resources/moneropedia/jump-service.md new file mode 100644 index 00000000..aa8e72ac --- /dev/null +++ b/resources/moneropedia/jump-service.md @@ -0,0 +1,33 @@ +--- +layout: moneropedia +entry: "Jump Service" +tags: ["kovri"] +terms: ["Jump-Service"] +summary: "An I2P website service that adds addresses to your address book" +--- + +### The Basics + +In your @I2P configured web browser, you can use a Jump Service to *jump* to an @I2P address that you don't have in your @address-book. Once you've *jumped* to the address, the address will be saved into your @address-book. + +### In-depth Information + +In an @I2P configured browser, visit: http://stats.i2p/i2p/lookup.html (courtesy of @Java-I2P's lead developer *zzz*) + +Then, you'll have two options: + +1. *Hostname lookup* the address you wish to visit and then manually copy/paste the result +2. *Jump* to the @I2P website by entering the @I2P hostname (**recommended**) + +### Using hostname lookup + +For example, entering `pinkpaste.i2p` into the *Hostname lookup* box (and then submitting) will return: + +{:.cli-code} +pinkpaste.i2p=m-HrPrIAsdxts0WM~P4mE8mt9P7g-QTaBvu7Gc6Nl0UX7Vwck-i~RvOPfK6W~kfdRvwhNTqevkBL2UF5l36We02Aiywu7kB2xOHRkze68h-Tg2ewvRVwokohguCD2G3wwAEz~7FVda2avYDCb9-N6TfuzxKLnmhPMvbNSjGL7ZsD2p-h207R3-2kvuMV9bfu-K~w9NI9XJhIyufvUnFYc2jnTVg8PbaR4UP57cNaOO2YIMPkbr6~yTcIu9B1sUfHK6-N~6virQDOxW4M-62rjnZkLpaCtkOsXslmCwZI--TkZ6hKi1kXZvNmJRE1rYfffYRFn38zhaqszeETX8HiIvahZhXF5fNumBziYdmLdw8hkuN1A~emU6Xz9g~a1Ixfsq1Qr~guYoOtaw-0rOFxNRS9yMehE-2LCb8c-cAg6z5OdlN4qJDl~ZHgru4d~EHp~BpAK3v7u2Gi-8l1ygVW-1CHVna~fwnbOPN3ANPwh6~~yUit0Cx1f54XiNRn6-nPBQAEAAcAAA== + +Copy/paste this host=@base64-address pairing into your **private** @subscription. + +### Directly jumping + +For example, entering `pinkpaste.i2p` into the *Jump* box (and then submitting) will automatically redirect you to the website **and** insert the @locally-unique-host into @address-book. diff --git a/resources/moneropedia/kovri.md b/resources/moneropedia/kovri.md new file mode 100644 index 00000000..6002cdd6 --- /dev/null +++ b/resources/moneropedia/kovri.md @@ -0,0 +1,62 @@ +--- +layout: moneropedia +entry: "Kovri" +tags: ["kovri"] +terms: ["Kovri"] +summary: "Monero's C++ router implementation of the I2P network" +--- + +### The Basics + +[Kovri](https://github.com/monero-project/kovri/) is a C++ implementation of the @I2P network. @Kovri is currently in heavy, active development and not yet integrated with Monero. When Kovri is integrated into your Monero @node, your transactions will be more secure than ever before. + +### In-depth information + +Kovri will protect you and Monero from: + +- @Node partitioning attacks +- Associations between a particular txid and your IP address +- Mining and/or running a node in highly adversarial environments +- Metadata leakage (e.g., @OpenAlias lookups) + +...and much more. + +Read [anonimal's FFS proposal](https://forum.getmonero.org/9/work-in-progress/86967/anonimal-s-kovri-full-time-development-funding-thread) for more details and for reasoning behind the project. Also read the FAQ and User Guide in the [Kovri repository](https://github.com/monero-project/kovri/). + +### @Kovri / @I2P Terminology + +#### Client + API + +- @Address-Book +- @Base32-address +- @Base64-address +- @Canonically-unique-host +- @Eepsite (@Hidden-Service, @Garlic-Site, @Garlic-Service) +- @I2PControl +- @Jump-Service +- @Locally-unique-host +- @Reseed +- @Subscription + +#### Core + Router + +- @Clearnet +- @Data-Directory +- @Destination +- @Encryption +- @Floodfill +- @Garlic-Encryption +- @Garlic-Routing +- @I2NP +- @In-net +- @Java-I2P +- @Layered-Encryption +- @Lease +- @LeaseSet +- @Message @Messages +- @NTCP +- @Network-Database +- @Router-Info +- @SSU +- @Transports +- @Tunnel diff --git a/resources/moneropedia/lease-set.md b/resources/moneropedia/lease-set.md new file mode 100644 index 00000000..99165a03 --- /dev/null +++ b/resources/moneropedia/lease-set.md @@ -0,0 +1,25 @@ +--- +layout: moneropedia +entry: "Lease-Set" +tags: ["kovri"] +terms: ["LeaseSet", "LeaseSets"] +summary: "Contains all currently authorized Leases for a particular I2P Destination" +--- + +### The Basics + +A Lease-Set contains a set of authorized @leases (and other related information) for a particular @destination. + +### In-depth information + +A Lease-Set contains: + +- all of the currently authorized @leases for a particular @destination +- the public key to which garlic messages can be encrypted (see @garlic-routing) +- the signing public key that can be used to revoke this particular version of the structure + +The Lease-Set is one of the two structures stored in the @network-database (the other being @router-info), and is keyed under the SHA256 of the contained @destination. + +### Notes + +For further details, read @Java-I2P's [LeaseSet](https://geti2p.net/en/docs/how/network-database#leaseSet) diff --git a/resources/moneropedia/lease.md b/resources/moneropedia/lease.md new file mode 100644 index 00000000..d3cdc545 --- /dev/null +++ b/resources/moneropedia/lease.md @@ -0,0 +1,15 @@ +--- +layout: moneropedia +entry: "Lease" +tags: ["kovri"] +terms: ["Lease", "Leases"] +summary: "Authorizes an I2P tunnel to receive messages targeting a destination" +--- + +### The Basics + +A lease defines the authorization for a particular @I2P @tunnel to receive a @messages targeting a @destination. + +### In-depth information + +For further details, read @Java-I2P's [Lease](https://geti2p.net/spec/common-structures#lease) diff --git a/resources/moneropedia/locally-unique-host.md b/resources/moneropedia/locally-unique-host.md new file mode 100644 index 00000000..3ce7f860 --- /dev/null +++ b/resources/moneropedia/locally-unique-host.md @@ -0,0 +1,22 @@ +--- +layout: moneropedia +entry: "Locally-unique host" +tags: ["kovri"] +terms: ["Locally-unique-host"] +summary: "A host defined by you and resolved only by you" +--- + +### The Basics + +A locally-unique host is a [FQDN](https://en.wikipedia.org/wiki/FQDN) defined by **you** and resolved only by you; similar to how a [hosts file](https://en.wikipedia.org/wiki/etc/hosts) is implemented. Not to be confused with @canonically-unique-host. + +### In-depth information + +You have the option to share your interpretation of how the host is resolved (e.g., `localhost` always resolves to `127.0.0.1`) but the resolution is not canonically enforced (e.g., someone else can map `localhost` to any arbitrary IP address). + +Hosts in a public subscription can be considered @canonically-unique-host's within the @I2P network but, ultimately, you are free to re-define them as you wish. + +### Notes + +- Monero primarily uses @canonically-unique-host resolution while @I2P only uses @locally-unique-host resolution. +- @I2P's and @Kovri's assigned top-level domain is currently `.i2p` and @Kovri intends to only process/use the `.i2p` [top-level domain](https://en.wikipedia.org/wiki/Top_level_domain) diff --git a/resources/moneropedia/message.md b/resources/moneropedia/message.md new file mode 100644 index 00000000..c9504d54 --- /dev/null +++ b/resources/moneropedia/message.md @@ -0,0 +1,33 @@ +--- +layout: moneropedia +entry: "Message" +tags: ["kovri"] +terms: ["Message", "Messages"] +summary: "The mechanisms in which information travels within I2P" +--- + +### The Basics + +*Messages* (which exist on top of the @transports layer), contain varying types of information that are needed for the network but, most importantly, everything you see, do, send, or receive, will come and go in the form of *messages*. + +There are 2 essential types of *messages* in @I2P: + +- @Tunnel messages +- @I2NP messages + +Essentially: *@tunnel messages* **contain** @I2NP **message fragments** which are then [reassembled](https://geti2p.net/en/docs/tunnels/implementation) at certain points within a @tunnel's path. + +### In-depth information + +@I2NP messages have a close relationship with @tunnel @messages so it is easy to get the term *messages* confused when reading @Java-I2P specifications: + +> +1. First, the tunnel gateway accumulates a number of I2NP messages and preprocesses them into tunnel messages for delivery. +2. Next, that gateway encrypts that preprocessed data, then forwards it to the first hop. +3. That peer, and subsequent tunnel participants, unwrap a layer of the encryption, verifying that it isn't a duplicate, then forward it on to the next peer. +4. Eventually, the tunnel messages arrive at the endpoint where the I2NP messages originally bundled by the gateway are reassembled and forwarded on as requested. + +### Notes + +- @I2NP @messages need to be fragmented because they are variable in size (from 0 to almost 64 KB) and @tunnel @messages are fixed-size (approximately 1 KB). +- For details and specifications, visit the [I2NP spec](https://geti2p.net/spec/i2np) and [Tunnel Message spec](https://geti2p.net/spec/tunnel-message) diff --git a/resources/moneropedia/miners.md b/resources/moneropedia/miners.md new file mode 100644 index 00000000..5fe91314 --- /dev/null +++ b/resources/moneropedia/miners.md @@ -0,0 +1,20 @@ +--- +layout: moneropedia +entry: "Mining" +terms: ["mining", "miner", "miners"] +summary: "the process of cryptographically computing a mathematical proof for a block, containing a number of transactions, which is then added to the blockchain" +--- + +### The Basics + +Mining is the distributed process of confirming transactions on the public ledger of all transactions, aka @blockchain. Monero nodes use the block chain to distinguish legitimate transactions from attempts to re-spend coins that have already been spent elsewhere. + +Monero is powered strictly by Proof of Work. It employs a mining algorithm that has the potential to be efficiently tasked to billions of existing devices (any modern x86 CPU and many GPU's). Monero uses the @CryptoNight Proof of Work (@PoW) algorithm, which is designed for use in ordinary CPUs and GPUs. + +The smart mining feature allows transparent CPU mining on the user's computer, far from the de facto centralization of mining farms and pool mining, pursuing Satoshi Nakamoto's original vision of a true P2P currency. + +As of June 2017, botnets made of hacked computers account for a not-insignificant portion of the miners on the Monero network. This is due to the profitibility of mining on CPUs via the @CryptoNight algorithm. + + + +{{ page.summary | capitalize }}. diff --git a/resources/moneropedia/mnemonicseed.md b/resources/moneropedia/mnemonicseed.md new file mode 100644 index 00000000..608f8d8b --- /dev/null +++ b/resources/moneropedia/mnemonicseed.md @@ -0,0 +1,20 @@ +--- +layout: moneropedia +entry: "Mnemonic Seed" +terms: ["mnemonic-seed", "mnemonic"] +summary: "a 13 or 25 word phrase used to backup a Monero account, available in a number of languages" +--- + +### The Basics + +{{ page.summary | capitalize }}. This 25-word phrase (13 words in the case of MyMonero) has all the information needed to view and spend funds from a Monero @account. + +### In-depth Information + +In the official wallet, the mnemonic seed comprises 25 words with the last word being used as a checksum. Those words correspond to a 256-bit integer, which is the account's *private* @spend-key. The *private* @view-key is derived by hashing the private spend key with Keccak-256, producing a second 256-bit integer. The corresponding *public* keys are then derived from the private keys. + +By storing the 25 word mnemonic key in a secure location, you have a backup of your private keys and hence all of your Moneroj. Sharing this 25 word key is the equivalent of allowing another person complete access to your funds. + +It's not a good idea to store more than you want to lose in a "hot wallet" aka a wallet which is currently or has ever been connected to the internet or loaded onto any device that has or may in the future be connected to the internet or any untrusted source! + +By creating a cold, or @paper-wallet you can safely store Moneroj. diff --git a/resources/moneropedia/network-database.md b/resources/moneropedia/network-database.md new file mode 100644 index 00000000..a5bb078c --- /dev/null +++ b/resources/moneropedia/network-database.md @@ -0,0 +1,25 @@ +--- +layout: moneropedia +entry: "Network Database" +tags: ["kovri"] +terms: ["Network-Database"] +summary: "A distributed database which contains needed router information so the network can stay intact" +--- + +### The Basics + +@network-database is a [distributed database](https://en.wikipedia.org/wiki/Distributed_database) which contains router information that peers must use so the network can stay intact. + +### In-depth information + +From @Java-I2P: + +> +@I2P's @network-database is a specialized distributed database, containing just two types of data - router contact information (@Router-Infos) and @destination contact information (@LeaseSets). Each piece of data is signed by the appropriate party and verified by anyone who uses or stores it. In addition, the data has liveliness information within it, allowing irrelevant entries to be dropped, newer entries to replace older ones, and protection against certain classes of attack. + +> +The @network-database is distributed with a simple technique called "@floodfill", where a subset of all routers, called "@floodfill routers", maintains the distributed database. + +### Notes + +Read [Network-Database](https://geti2p.net/en/docs/how/network-database) for details. diff --git a/resources/moneropedia/node.md b/resources/moneropedia/node.md new file mode 100644 index 00000000..49766ad0 --- /dev/null +++ b/resources/moneropedia/node.md @@ -0,0 +1,10 @@ +--- +layout: moneropedia +entry: "Node" +terms: ["node", "nodes", "full-node", "full-nodes"] +summary: "a device on the Internet running the Monero software, with a full copy of the Monero blockchain, actively assisting the Monero network" +--- + +### The Basics + +{{ page.summary | capitalize }}. \ No newline at end of file diff --git a/resources/moneropedia/ntcp.md b/resources/moneropedia/ntcp.md new file mode 100644 index 00000000..69f3152c --- /dev/null +++ b/resources/moneropedia/ntcp.md @@ -0,0 +1,34 @@ +--- +layout: moneropedia +entry: "NTCP" +tags: ["kovri"] +terms: ["NTCP"] +summary: "NIO-Based TCP (Non-blocking I/O based TCP): one of two Kovri transports" +--- + +### The Basics + +*NIO-Based TCP (Non-blocking I/O based TCP)* is one of two encrypted @transports for @Kovri. + +Similar to @SSU, @NTCP's *primary* purpose is to securely transmit @in-net @I2NP messages through @tunnels but, unlike @SSU, @NTCP functions solely over encrypted [TCP](https://en.wikipedia.org/wiki/Transmission_Control_Protocol). + +### In-depth information + + - Passes along individual @I2NP messages (both Standard and Time Sync) after: + - TCP has been established + - Establishment Sequence has been completed + - Uses the following @encryption: + - 2048-bit [Diffie-Hellman](https://en.wikipedia.org/wiki/Diffie-hellman) + - [AES-256](https://en.wikipedia.org/wiki/Advanced_Encryption_Standard)/[CBC](https://en.wikipedia.org/wiki/Block_cipher_modes_of_operation) + - Establishment Sequence has the following *states*: + - Pre-establishment + - Establishment + - Post-establishment or "Established" + - Uses the following from the @network-database: + - Transport name: NTCP + - Host: IP (IPv4 or IPv6) or host name (shortened IPv6 address (with "::") is allowed) + - Port: 1024 - 65535 + +### Notes + +For further details, read @Java-I2P's [NTCP](https://geti2p.net/en/docs/transport/ntcp) diff --git a/resources/moneropedia/openalias.md b/resources/moneropedia/openalias.md new file mode 100644 index 00000000..c2e54551 --- /dev/null +++ b/resources/moneropedia/openalias.md @@ -0,0 +1,20 @@ +--- +layout: moneropedia +entry: "OpenAlias" +terms: ["OpenAlias"] +summary: "a standard that allows you to use an email or domain syntax to pay someone instead of an address, eg. donate@getmonero.org or donate.getmonero.org" +--- + +### The Basics + +The Monero Core Team released a standard called OpenAlias which permits much more human-readable addresses and "squares" the Zooko's triangle. OpenAlias can be used for any cryptocurrency and is already implemented in Monero, Bitcoin (in latest Electrum versions) and HyperStake. + +OpenAlias seeks to provide a way to simplify aliasing amidst a rapidly shifting technology climate. Users are trying to cross the bridge to private and cryptographically secure infrastructure and systems, but many of them have just barely started remembering the email addresses of their friends and family. + +As part of the ongoing development of the Monero cryptocurrency project, we asked ourselves: how can we simplify payments for users unfamiliar with cryptocurrency? Monero stealth addresses are at least 95 characters long - memorising them is not an option, and asking someone to send a payment to <95-character-string> is only going to lead to confusion. + +At its most basic, OpenAlias is a TXT DNS record on a FQDN (fully qualified domain name). By combining this with DNS-related technologies we have created an aliasing standard that is extensible for developers, intuitive and familiar for users, and can interoperate with both centralised and decentralised domain systems. + +{{ page.summary | capitalize }}. + +More information can be found on the [OpenAlias page](/knowledge-base/openalias) or on the [OpenAlias website](https://openalias.org) diff --git a/resources/moneropedia/paperwallet.md b/resources/moneropedia/paperwallet.md new file mode 100644 index 00000000..95ff00ba --- /dev/null +++ b/resources/moneropedia/paperwallet.md @@ -0,0 +1,7 @@ +--- +layout: moneropedia +entry: "Paper Wallet" +terms: ["paperwallet", "paperwallets", "paper-wallet", "paper-wallets"] +summary: "A paper wallet stores the information necessary to send and receive Monero" +--- + diff --git a/resources/moneropedia/paymentid.md b/resources/moneropedia/paymentid.md new file mode 100644 index 00000000..668205c9 --- /dev/null +++ b/resources/moneropedia/paymentid.md @@ -0,0 +1,25 @@ +--- +layout: moneropedia +entry: "Payment ID" +terms: ["payment-ID", "payment-IDs"] +summary: "an optional flag that is added to identify transactions to merchants, consisting of 64 hexadecimal characters" +--- + +### The Basics + +Payment ID is an **arbitrary** and **optional** transaction attachment that consists of 32 bytes (64 hexadecimal characters) or 8 bytes (in the case of integrated addresses). + +The Payment ID is usually used to identify transactions to merchants and exchanges: Given the intrinsic privacy features built into Monero, where a single public address is usually used for incoming transactions, the Payment ID is especially useful to tie incoming payments with user accounts. + +### Compact Payment ID's and Integrated Addresses + +Since the 0.9 Hydrogen Helix version, the Payment IDs can be encrypted and embedded in a payment address. The payment ID's of this type should be 64-bits and are encrypted with a random one-time key known only to the sender and receiver. + +### Creating a Payment ID +It is recommented to use the official wallet's `integrated_address` command to automatically generate Integrated Addresses that contain Compact Payment ID's. If you want to use the command line, you can generate Payment ID's as follows: + +Creating a compact Payment ID for an Integrated Address: +```# openssl rand -hex 8``` + +Creating an old-style Payment ID: +```# openssl rand -hex 32``` diff --git a/resources/moneropedia/reseed.md b/resources/moneropedia/reseed.md new file mode 100644 index 00000000..932c3be2 --- /dev/null +++ b/resources/moneropedia/reseed.md @@ -0,0 +1,17 @@ +--- +layout: moneropedia +entry: "Reseed" +tags: ["kovri"] +terms: ["Reseed"] +summary: "The method of which Kovri uses to bootstrap into the I2P network" +--- + +### The Basics + +When you start @Kovri for the first time (or if its been offline for a long time), @Kovri will need a list of peers to connect to so it can [bootstrap](https://en.wikipedia.org/wiki/Bootstrap) into the @I2P network. @Kovri gets these peers from a special file stored on a reseed server. On this file are all the various pieces of information @Kovri needs in order to connect with @I2P peers. + +### In-depth information + +@Kovri has a list of [hard-coded](https://en.wikipedia.org/wiki/Hard-coded) reseed servers available to fetch from. These servers securely serve an [SU3](https://geti2p.net/spec/updates#su3) file (signed with a cryptographic @signature) over @clearnet with [HTTPS](https://en.wikipedia.org/wiki/HTTPS). This SU3 file contains information that's used to verify both the integrity of the file and its content. + +Aside from the technical elements needed to verify and process the file, the file's main contents consist of a series of @router-info files which @Kovri and @I2P routers use to locate and communicate with other @I2P peers. These peers are then stored into a @network-database. diff --git a/resources/moneropedia/ring-size.md b/resources/moneropedia/ring-size.md new file mode 100644 index 00000000..a1601651 --- /dev/null +++ b/resources/moneropedia/ring-size.md @@ -0,0 +1,11 @@ +--- +layout: moneropedia +entry: "Ring Size" +terms: ["ring-size"] +summary: "total number of possible signers in a ring signature" +--- + +### The Basics +Ring size refers to the total number of possible signers in a @ring-signature. If a ring size of 4 is selected for a given @transaction, this means that there are 3 foreign outputs in addition to your “real” output. A higher ring size number will typically provide more privacy than a lower number. However, reusing an odd, recognizable ring size number for transactions could possibly make transactions stand out. + +`Ring size = foreign outputs + 1 (your output)` \ No newline at end of file diff --git a/resources/moneropedia/ringCT.md b/resources/moneropedia/ringCT.md new file mode 100644 index 00000000..ad55350e --- /dev/null +++ b/resources/moneropedia/ringCT.md @@ -0,0 +1,24 @@ +--- +layout: moneropedia +entry: "Ring CT" +terms: ["ringCT", "ring-CT"] +summary: "a way to hide the amount sent in a Monero transaction" +--- + +### The Basics +RingCT, short for Ring Confidential Transactions, is how transaction amounts are hidden in Monero. + +Ring CT was implemented in block #1220516 and is currently used in over 95% of Monero transactions. After September 2017 this feature will be mandatory for all transactions on the network. + +RingCT introduces an improved version of @ring-signatures called A Multi-layered Linkable Spontaneous Anonymous Group signature, which allows for hidden amounts, origins and destinations of transactions with reasonable efficiency and verifiable, trustless coin generation. + +For more information, please read the creator Shen Noether's paper [here](https://eprint.iacr.org/2015/1098). + + +{{ page.summary | capitalize }}. + + + + + + diff --git a/resources/moneropedia/ringsignatures.md b/resources/moneropedia/ringsignatures.md new file mode 100644 index 00000000..9ff6e62d --- /dev/null +++ b/resources/moneropedia/ringsignatures.md @@ -0,0 +1,11 @@ +--- +layout: moneropedia +entry: "Ring Signature" +terms: ["ring-signature", "ring-signatures"] +summary: "a group of cryptographic signatures with at least one real participant, but no way to tell which in the group is the real one as they all appear valid" +--- + +### The Basics +A ring signature is a type of group @signature that makes use of your @account keys and a number of public keys (also known as outputs) pulled from the @blockchain using a triangular distribution method. Over the course of time, past outputs could be used multiple times to form possible signer participants. In a "ring" of possible signers, all ring members are equal and valid. There is no way an outside observer can tell which of the possible signers in a signature group belongs to your @account. So, ring signatures ensure that transaction outputs are untraceable. Moreover, there are no fungibility issues with Monero given that every transaction output has plausible deniability (e.g. the network can not tell which outputs are spent or unspent). + +To read how Monero gives you privacy by default (unlinkability), see @stealth-addresses. \ No newline at end of file diff --git a/resources/moneropedia/router-info.md b/resources/moneropedia/router-info.md new file mode 100644 index 00000000..f7c45c06 --- /dev/null +++ b/resources/moneropedia/router-info.md @@ -0,0 +1,68 @@ +--- +layout: moneropedia +entry: "Router-Info" +tags: ["kovri"] +terms: ["Router-Info", "Router-infos"] +summary: "A data structure or file which contains an I2P peer's needed network information" +--- + +### The Basics + +@Router-Info is a data structure (periodically written to a [binary file](https://en.wikipedia.org/wiki/Binary_file)) which contains all needed information to locate, identify, and communicate with an @I2P peer. @Router-Info includes IP address, router identity, other misc. technical details; is needed for @network-database and is published to @floodfill routers. + +### In-depth information + +In human-readable form, Router-Info may look like this: + +``` +Identity: [RouterIdentity: +Hash: nYZ5Qe7gQ-~QgfgJVRUG4c0JnVeVqzM~duUX1EGT1ek= +Certificate: [Certificate: type: Key certificate +Crypto type: 0 +Sig type: 7 (EdDSA_SHA512_Ed25519)] +PublicKey: [PublicKey: size: 256] +SigningPublicKey: [SigningPublicKey EdDSA_SHA512_Ed25519: size: 32] +Padding: 96 bytes] +Signature: [Signature EdDSA_SHA512_Ed25519: size: 64] +Published: Sun Oct 09 01:34:59 UTC 2016 +Options (5): + [caps] = [LfR] + [netId] = [2] + [netdb.knownLeaseSets] = [37] + [netdb.knownRouters] = [2435] + [router.version] = [0.9.26] +Addresses (4): +[RouterAddress: +Type: SSU +Cost: 4 +Options (5): + [caps] = [BC] + [host] = [2a01:e35:8b5c:b240:71a2:6750:8d4:47fa] + [key] = [nYZ5Qe7gQ-~QgfgJVRUG4c0JnVeVqzM~duUX1EGT1ek=] + [mtu] = [1472] + [port] = [22244]] +[RouterAddress: +Type: NTCP +Cost: 9 +Options (2): + [host] = [2a01:e35:8b5c:b240:71a2:6750:8d4:47fa] + [port] = [22244]] +[RouterAddress: +Type: SSU +Cost: 6 +Options (4): + [caps] = [BC] + [host] = [88.181.203.36] + [key] = [nYZ5Qe7gQ-~QgfgJVRUG4c0JnVeVqzM~duUX1EGT1ek=] + [port] = [22244]] +[RouterAddress: +Type: NTCP +Cost: 11 +Options (2): + [host] = [88.181.203.36] + [port] = [22244]]] +``` + +### Notes + +For details and specification, visit @Java-I2P [Network Database](https://geti2p.net/en/docs/how/network-database) page. diff --git a/resources/moneropedia/scalability.md b/resources/moneropedia/scalability.md new file mode 100644 index 00000000..efce0202 --- /dev/null +++ b/resources/moneropedia/scalability.md @@ -0,0 +1,10 @@ +--- +layout: moneropedia +entry: "Scalability" +terms: ["scalability"] +summary: "Growth potential of Monero, resources required, and methods of increasing efficiency" +--- + +### The Basics + +Monero has no hardcoded maximum block size, which means that unlike Bitcoin it does not have a 1 MB block size limit preventing scaling. However, a block reward penalty mechanism is built into the protocol to avoid a too excessive block size increase: The new block's size (NBS) is compared to the median size M100 of the last 100 blocks. If NBS>M100, the block reward gets reduced in quadratic dependency of how much NBS exceeds M100. E.g. if NBS is [10%, 50%, 80%, 100%] greater than M100, the nominal block reward gets reduced by [1%, 25%, 64%, 100%]. Generally, blocks greater than 2*M100 are not allowed, and blocks <= 60kB are always free of any block reward penalties. diff --git a/resources/moneropedia/signature.md b/resources/moneropedia/signature.md new file mode 100644 index 00000000..638b7c5b --- /dev/null +++ b/resources/moneropedia/signature.md @@ -0,0 +1,10 @@ +--- +layout: moneropedia +entry: "Cryptographic Signature" +terms: ["signature", "signatures"] +summary: "a cryptographic method for proving ownership of a piece of information, as well as proving that the information has not been modified after being signed" +--- + +### The Basics + +{{ page.summary | capitalize }}. \ No newline at end of file diff --git a/resources/moneropedia/smartmining.md b/resources/moneropedia/smartmining.md new file mode 100644 index 00000000..13b28d67 --- /dev/null +++ b/resources/moneropedia/smartmining.md @@ -0,0 +1,17 @@ +--- +layout: moneropedia +entry: "Smart Mining" +terms: ["smart-mining"] +summary: "a process of having a throttled miner mine when it otherwise does not cause drawbacks" +--- + +### The Basics + +Smart mining is the process of having a throttled miner mine when it otherwise does not cause drawbacks. +Drawbacks include increases heat, slower machine, depleting battery, etc. The intent of smart mining is to increase network security by allowing as many people as possible to let the smart miner on all the time. For this to work, the miner must prove unobtrusive, or it will be turned off, depriving the Monero network from a little bit of security. As such, it is likely that a smart miner will mine slower than a normal miner on the same hardware. + +Smart mining was started in 2014, but the contributor had to leave due to lack of time. View the current code [here](https://github.com/oranjuice/bitmonero/tree/smart-mining). + +When this is finished, it is hoped that the relative slowness of a smart miner (especially on low-power machines) will be offset by the large amount of people running a miner for a possible "lottery win", and thus increase the Monero network security by a non trivial amount. The increased hash rate from many different sources will help keep the Monero network decentralized. + +{{ page.summary | capitalize }}. diff --git a/resources/moneropedia/spendkey.md b/resources/moneropedia/spendkey.md new file mode 100644 index 00000000..d57544d1 --- /dev/null +++ b/resources/moneropedia/spendkey.md @@ -0,0 +1,16 @@ +--- +layout: moneropedia +entry: "Spend Key" +terms: ["spend-key", "spend-keys"] +summary: "one of the two pairs of private and public cryptographic keys that each account has, with the *private* spend key used to spend any funds in the account" +--- + +### The Basics + +{{ page.summary | capitalize }}. + +### In-depth Information + +The *private* spend key is a 256-bit integer that is used to sign Monero transactions. With the current deterministic key derivation method of the official wallet, the private spend key is also an alternate representation of the @mnemonic-seed. It can be used to derive all other account keys. + + diff --git a/resources/moneropedia/ssu.md b/resources/moneropedia/ssu.md new file mode 100644 index 00000000..665f9c44 --- /dev/null +++ b/resources/moneropedia/ssu.md @@ -0,0 +1,26 @@ +--- +layout: moneropedia +entry: "SSU" +tags: ["kovri"] +terms: ["SSU"] +summary: "Secure Semi-reliable UDP: one of two Kovri transports" +--- + +### The Basics + +*Secure Semi-reliable UDP* is one of two encrypted @transports for @Kovri. + +Similar to @NTCP, @SSU's *primary* purpose is to securely transmit @in-net @I2NP messages through @tunnels but, unlike @NTCP, @SSU functions solely over encrypted [UDP](https://en.wikipedia.org/wiki/User_Datagram_Protocol). + +### In-depth information + +- Like @NTCP, @SSU is a connection-oriented, point-to-point data transport +- Termed *semi-reliable* because @SSU will repeatedly retransmit *unacknowledged* messages (up to maximum number then dropped) +- @SSU also provides several unique services (in addition to its function as a @transport layer): + - IP detection (local inspection or with [peer testing](https://geti2p.net/en/docs/transport/ssu#peerTesting)) + - [NAT](https://en.wikipedia.org/wiki/Network_address_translation) traversal (using [introducers](https://geti2p.net/en/docs/transport/ssu#introduction)) + - [Firewall](https://en.wikipedia.org/wiki/Firewall_%28computing%29) status and, if implemented, @SSU can notify @NTCP if the external address or firewall status changes + +### Notes + +For further details, read @Java-I2P's [SSU](https://geti2p.net/en/docs/transport/ssu) diff --git a/resources/moneropedia/stealthaddress.md b/resources/moneropedia/stealthaddress.md new file mode 100644 index 00000000..b122f0ff --- /dev/null +++ b/resources/moneropedia/stealthaddress.md @@ -0,0 +1,16 @@ +--- +layout: moneropedia +entry: "Stealth Address" +terms: ["stealth-address", "stealth-addresses"] +summary: "automatic one-time addresses for every transaction" +--- + +### The Basics + +Stealth addresses are an important part of Monero's inherent privacy. They allow and require the sender to create random one-time addresses for every @transaction on behalf of the recipient. The recipient can publish just one address, yet have all of his/her incoming payments go to unique addresses on the @blockchain, where they cannot be linked back to either the recipient's published address or any other transactions' addresses. By using stealth addresses, only the sender and receiver can determine where a payment was sent. + +When you create a Monero account you’ll have a private @view-key, a private @spend-key, and a Public Address. The @spend-key is used to send payments, the @view-key is used to display incoming transactions destined for your account, and the Public Address is for receiving payments. Both the @spend-key and @view-key are used to build your monero address. You can have a “watch only” wallet that only uses the @view-key. This feature can be used for accounting or auditing purposes but is currently unreliable due to the inability to track outgoing transactions. You can decide who can see your Monero balance by sharing your @view-key. Monero is private by default and optionally semi-transparent! + +When using the Monero Wallet all this is handled by the software. Sending Monero is as easy as entering the destination address, the amount, and pressing Send. To recieve Monero, simply provide the sender your Public Address. + +To learn how Monero prevents tracking history (untraceability), see @ring-signatures. diff --git a/resources/moneropedia/subscription.md b/resources/moneropedia/subscription.md new file mode 100644 index 00000000..387f839e --- /dev/null +++ b/resources/moneropedia/subscription.md @@ -0,0 +1,46 @@ +--- +layout: moneropedia +entry: "Subscription" +tags: ["kovri"] +terms: ["Subscription"] +summary: "A file used by address book which contains I2P hosts paired with I2P destinations" +--- + +### The Basics + +A subscription is a file which contains a list of `.i2p` hosts paired with their respective @destination. Subscriptions are used by the @address-book. + +### In-depth information + +Similar to how a [hosts file](https://en.wikipedia.org/wiki/etc/hosts) can map an internet hostname to a specified address, a subscription matches a `.i2p` address to @base64-address by using the following format (no spaces allowed): `host=address` + +More specifically, a subscription pairs a @locally-unique-host to @base64-address. + +Example: + +{:.cli-code} +anonimal.i2p=AQZGLAMpI9Q0l0kmMj1vpJJYK3CjLp~fE3MfvE-e7KMKjI5cPOH6EN8m794uHJ6b09qM8mb9VEv1lVLEov~usVliTSXCSHuRBOCIwIOuDNU0AbVa4BpIx~2sU4TxKhoaA3zQ6VzINoduTdR2IJhPvI5xzezp7dR21CEQGGTbenDslXeQ4iLHFA2~bzp1f7etSl9T2W9RID-KH78sRQmzWnv7dbhNodMbpO6xsf1vENf6bMRzqD5vgHEHZu2aSoNuPyYxDU1eM6--61b2xp9mt1k3ud-5WvPVg89RaU9ugU5cxaHgR927lHMCAEU2Ax~zUb3DbrvgQBOTHnJEx2Fp7pOK~PnP6ylkYKQMfLROosLDXinxOoSKP0UYCh2WgIUPwE7WzJH3PiJVF0~WZ1dZ9mg00c~gzLgmkOxe1NpFRNg6XzoARivNVB5NuWqNxr5WKWMLBGQ9YHvHO1OHhUJTowb9X90BhtHnLK2AHwO6fV-iHWxRJyDabhSMj1kuYpVUBQAEAAcAAA== + +1. `anonimal.i2p` is the @locally-unique-host +2. `=` is the seperator +3. Everything that remains is the @base64-address + +### Subscription types + +For @Kovri, there are two types of subscription files: *public* and *private*. + +A *public* subscription: +- is used when bootstrapping to use essential services (IRC, email, monero, etc.) +- is static and is refreshed every 12 hours from Monero's @address-book server +- allows you to safely share the subscription with everyone as it is publically available (anyone who shares the same public subscription will also be able to resolve the same hostname to the same destination as you) + +A *private* subscription: +- is used exclusively by you and is not shared with others unless you explicitely choose to share the file +- default file is `private_hosts.txt` in your @data-directory + +### Updating a private subscription + +You can use a @jump-service to manually update your private subscription. The updated subscription will then be fed into the @address-book for you to use. + +### Notes +To learn how to subscribe to multiple subscriptions, see the [user-guide](https://github.com/monero-project/kovri/blob/master/doc/USER_GUIDE.md). diff --git a/resources/moneropedia/transaction.md b/resources/moneropedia/transaction.md new file mode 100644 index 00000000..0064cb50 --- /dev/null +++ b/resources/moneropedia/transaction.md @@ -0,0 +1,21 @@ +--- +layout: moneropedia +entry: "Transactions" +terms: ["transaction", "transactions"] +summary: "a cryptographically signed container that details the transfer of Monero to a recipient (or recipients)" +--- + +### The Basics + +{{ page.summary | capitalize }}. + +The parameters of a transaction contain one or more recipient addresses with corresponding amounts of funds and a `mixin_count` parameter that specifies the number of foreign outputs bound to the transaction. The more outputs that are used, a higher degree of obfuscation is possible, but that comes with a cost. Since a transaction gets larger with more outputs, the transaction fee would be higher. It is possible to form a transaction offline, which is a huge benefit for privacy. + +A transaction can be uniquely identified with the use of an optional Transaction ID, which is usually represented by a 32-byte string (64 hexadecimal characters). + +### In-depth Information +Every transaction involves two keys: a public @spend-key, and a public @view-key. The destination for an output in a transaction is actually a one-time public key computed from these two keys. + +When a wallet is scanning for incoming transactions, every transaction is scanned to see if it is for "you". This only requires your private view key and your public spend key, and this check is immutable and cannot be faked. You cannot receive transactions and identify them without a corresponding private view key. + +In order to spend the funds you have to compute a one-time private spend key for that output. This is almost always done automatically by the Monero Wallet software. diff --git a/resources/moneropedia/transports.md b/resources/moneropedia/transports.md new file mode 100644 index 00000000..59504f99 --- /dev/null +++ b/resources/moneropedia/transports.md @@ -0,0 +1,20 @@ +--- +layout: moneropedia +entry: "Transports" +tags: ["kovri"] +terms: ["Transports", "Transport"] +summary: "The two encrypted transport layers for Kovri" +--- + +### The Basics + +@I2P comes with two encrypted transport layer technologies that allow @Kovri to securely use [TCP/IP](https://en.wikipedia.org/wiki/Tcp/ip) connections. These technologies (@SSU and @NTCP) are called *@transports*. + +### In-depth information + +@SSU is encrypted [UDP](https://en.wikipedia.org/wiki/User_Datagram_Protocol) and @NTCP is encrypted [TCP](https://en.wikipedia.org/wiki/Transmission_Control_Protocol). They provide @encryption at the [transport layer](https://en.wikipedia.org/wiki/Transport_layer) so higher level @messages can be sent through @tunnels across the @I2P network. + +### Notes + +- Read about @I2P's transports on the [Transport](https://geti2p.net/en/docs/transport) page +- Read about the transports layer within the [OSI model](https://en.wikipedia.org/wiki/OSI_model) diff --git a/resources/moneropedia/tunnel.md b/resources/moneropedia/tunnel.md new file mode 100644 index 00000000..d22e2b94 --- /dev/null +++ b/resources/moneropedia/tunnel.md @@ -0,0 +1,37 @@ +--- +layout: moneropedia +entry: "Tunnel" +tags: ["kovri"] +terms: ["Tunnel", "Tunnels"] +summary: "Uni-directional virtual paths that pass messages through a defined sequence of I2P routers" +--- + +### The Basics + +When you communicate over @I2P (visit an @eepsite / use a @garlic-service), you'll first need to connect to a peer by using @transports and then build virtual *tunnels*. These virtual tunnels are temporary, uni-directional paths that pass information through a defined sequence of @I2P routers to your @destination. Tunnels are built, and then used, with layered @garlic-encryption and are a general-purpose mechanism to transport all @I2NP @messages. + +Each peer builds, at a minimum, *two* uni-directional tunnels: one for **outbound traffic**, and one for **inbound traffic**. These tunnels are classified as either **inbound tunnels** (where @messages come toward the creator of the tunnel) or **outbound tunnels** (where the tunnel creator sends @messages away from the creator of the tunnel). Thus, *four* tunnels are required for a single round-trip @message and reply to your @destination (two for your, two for your destination). + +### In-depth information + +From @Java-I2P: + +> +Within I2P, @messages are passed in one direction through a virtual tunnel of peers, using whatever means are available to pass the @message on to the next hop. Messages arrive at the tunnel's gateway, get bundled up and/or fragmented into fixed-size @tunnel @messages, and are forwarded on to the next hop in the tunnel, which processes and verifies the validity of the @message and sends it on to the next hop, and so on, until it reaches the @tunnel endpoint. That endpoint takes the messages bundled up by the gateway and forwards them as instructed - either to another router, to another tunnel on another router, or locally. + +> +Tunnels all work the same, but can be segmented into two different groups - inbound tunnels and outbound tunnels. The inbound tunnels have an untrusted gateway which passes messages down towards the tunnel creator, which serves as the tunnel endpoint. For outbound tunnels, the tunnel creator serves as the gateway, passing messages out to the remote endpoint. + +> +The tunnel's creator selects exactly which peers will participate in the tunnel, and provides each with the necessary configuration data. They may have any number of hops. It is the intent to make it hard for either participants or third parties to determine the length of a tunnel, or even for colluding participants to determine whether they are a part of the same tunnel at all (barring the situation where colluding peers are next to each other in the tunnel). + +### Notes + +From @Java-I2P: + +> +@I2P is an inherently packet switched network, even with these tunnels, allowing it to take advantage of multiple tunnels running in parallel, increasing resilience and balancing load. Even though the tunnels within I2P bear a resemblance to a circuit switched network, everything within I2P is strictly message based - tunnels are merely accounting tricks to help organize the delivery of messages. No assumptions are made regarding reliability or ordering of messages, and retransmissions are left to higher levels (e.g. I2P's client layer streaming library). + +### Documentation + +For specification and detailed documentation, visit the [Tunnel-Routing](https://geti2p.net/en/docs/how/tunnel-routing) and [Tunnel-Implementation](https://geti2p.net/en/docs/tunnels/implementation) page. diff --git a/resources/moneropedia/unlocktime.md b/resources/moneropedia/unlocktime.md new file mode 100644 index 00000000..08a35f8e --- /dev/null +++ b/resources/moneropedia/unlocktime.md @@ -0,0 +1,14 @@ +--- +layout: moneropedia +entry: "Transaction Unlock Time" +terms: ["unlock-time"] +summary: "a special transaction where the recipient can only spend the funds after a future date, as set by the sender" +--- + +### The Basics + +{{ page.summary | capitalize }}. + +Unlock time allows you to send a transaction to someone, such that they can not spend it until after a certain number of blocks, or until a certain time. + +Note that this works differently than Bitcoin's [nLockTime](https://en.bitcoin.it/wiki/NLockTime), in which the transaction is not valid until the given time. diff --git a/resources/moneropedia/viewkey.md b/resources/moneropedia/viewkey.md new file mode 100644 index 00000000..b5a3811b --- /dev/null +++ b/resources/moneropedia/viewkey.md @@ -0,0 +1,16 @@ +--- +layout: moneropedia +entry: "View Key" +terms: ["view-key", "view-keys"] +summary: "one of two sets of private and public cryptographic keys that each account has, with the private view key required to view all transactions related to the account" +--- + +### The Basics + +Monero features an opaque blockchain (with an explicit allowance system called the @view-key), in sharp contrast with transparent blockchains used by any other cryptocurrency not based on @CryptoNote. Thus, Monero is said to be "private, optionally transparent". + +Every Monero address has a private viewkey which can be shared. By sharing a viewkey a person is allowing access to view every incoming transaction for that address. However, outgoing transactions can not be reliably viewed as of June 2017. Therefore the balance of a Monero address as shown via a viewkey should not be relied upon. + + + +{{ page.summary | capitalize }}. diff --git a/resources/moneropedia/wallet.md b/resources/moneropedia/wallet.md new file mode 100644 index 00000000..ce46f39d --- /dev/null +++ b/resources/moneropedia/wallet.md @@ -0,0 +1,19 @@ +--- +layout: moneropedia +entry: "Wallet" +terms: ["wallet", "wallets"] +summary: "A wallet stores the information necessary to send and receive Monero" +--- + +### The Basics + +A Monero account, or wallet, stores the information necessary to send and receive Moneroj. In addition to sending and receiving, the Monero Wallet software keeps a private history of your transactions and allows you to cryptographically sign messages. It also includes Monero mining software and an address book. + +The term "hot wallet" describes a Monero @account which is connected to the Internet. You can send funds easily but security is much lower than a cold wallet. Never store large amounts of cryptocurrency in a hot wallet! + +A cold wallet is generated on a trusted device or computer via an @airgap. If the device is to be reused, the data storage should be securely overwritten. As soon as a cold wallet is connected to the internet, or its mnemonic phrase or @spend-key is entered on an internet-connected device, it's no longer "cold" and should be considered "hot". + +A Monero @paper-wallet can be generated by downloading the source code of https://moneroaddress.org/. Verify the signature of the code on a trusted airgapped device. Create the wallet and print or store it on the media of your choice. + +Monero accounts and paper-wallets can be stored on any media - paper, USB drive, CD/DVD, or a hardware wallet device (none available for Monero as of June 2017). + diff --git a/resources/openalias.md b/resources/openalias.md new file mode 100644 index 00000000..ccee8855 --- /dev/null +++ b/resources/openalias.md @@ -0,0 +1,20 @@ +--- +layout: static_page +title: "The OpenAlias Project" +title-pre-kick: "The " +title-kick: "OpenAlias " +title-post-kick: "Project" +kick-class: "oa-kicks" +icon: "icon_openalias" +attribution: "" +--- + +### What is OpenAlias? + +OpenAlias seeks to provide a way to simplify aliasing amidst a rapidly shifting technology climate. Users are trying to cross the bridge to private and cryptographically secure infrastructure and systems, but many of them have just barely started remembering the email addresses of their friends and family. + +As part of the ongoing development of the Monero cryptocurrency project, we asked ourselves: how can we simplify payments for users unfamiliar with cryptocurrency? Monero stealth addresses are at least 95 characters long - memorising them is not an option, and asking someone to send a payment to <95-character-string> is only going to lead to confusion. + +At its most basic, OpenAlias is a TXT DNS record on a FQDN (fully qualified domain name). By combining this with DNS-related technologies we have created an aliasing standard that is extensible for developers, intuitive and familiar for users, and can interoperate with both centralised and decentralised domain systems. + +For more info, visit [www.openalias.org](https://www.openalias.org). diff --git a/resources/people.md b/resources/people.md new file mode 100644 index 00000000..ca23a98f --- /dev/null +++ b/resources/people.md @@ -0,0 +1,42 @@ +--- +layout: static_page +title: "The People Behind Monero" +title-pre-kick: "The " +title-kick: "People Behind " +title-post-kick: "Monero" +kick-class: "kicks" +icon: "icon_people" +attribution: "" +--- + +### The Monero Core Team + +Monero is not governed by any foundation or central body, but ongoing development, maintenance, and research is primarily directed and often funded by a core team of seven individuals. + +Five members of the Core Team prefer to stay pseudonymous at this time, but two of them are more public and have revealed their real identities. For ease of reference those two members (Riccardo and Francisco) are at the top of the list below, but beyond that the list is presented in no particular order: + +- **Riccardo "fluffypony" Spagni** (*ric@getmonero.org* / [@fluffyponyza](https://twitter.com/fluffyponyza))**:** Based out of South Africa, Riccardo brings a strong business acumen and a deep understanding of cryptocurrency, software development, and cryptography to the table. He has been involved with cryptocurrency-related projects since 2012. +- **Francisco "ArticMine" Cabañas** (*articmine@getmonero.org*)**:** Based in Canada, Francisco 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. +- **smooth** (*smooth@getmonero.org*)**:** A software developer, entrepreneur, and investor, smooth has been involved in several cryptocurrency projects since 2011, including development of the first multicurrency exchange (initially supporting Bitcoin and Namecoin). By virtue of his long-standing involvement in the cryptocurrency community, he is well known and trusted by many. +- **othe** (*othe@getmonero.org*)**:** Based in Germany, othe has been interested in cryptocurrency since early 2011. Currently he works as an independent consultant for various cryptocurrency-related businesses. He is known for his previous work as a core Vertcoin developer. +- **luigi1111** (*luigi1111@getmonero.org*)**:** Hailing from the Midwest, USA, luigi1111 is a sysadmin by day. He has been actively involved in several cryptocurrencies since 2013, and loves cryptography, probability, and English grammar. +- **tacotime** (*tacotime@getmonero.org*)**:** A bioinformatics enthusiast and software developer from Toronto, tacotime has been involved in cryptocurrency since 2011. He is well known for his work on MC2, a hybrid PoS/PoW cryptocurrency, and his contributions to various Conformal projects such as btcd. +- **NoodleDoodle** (*noodledoodle@getmonero.org*)**:** A former Silicon Valley engineer, NoodleDoodle is a seasoned hardware and software developer. He started his involvement with cryptocurrencies in 2012 and currently spends his time working on "cool aerospace stuff" for a university. + +### Development Contributors + +There have been many individuals that have contributed to the Monero Project; a complete list of which can be found on our [Github Contributors page](https://github.com/monero-project/bitmonero/graphs/contributors). + +Some that have made outstanding contributions include: [moneromooo](http://github.com/moneromooo-monero/bitmonero/branches), [Thomas Winget](https://github.com/tewinget), [Howard Chu](https://github.com/hyc), [mikezackles](https://github.com/mikezackles), [oranjuice](https://github.com/oranjuice), [warptangent](https://github.com/warptangent), [rfree](https://github.com/rfree2monero), [jakoblind](https://github.com/jakoblind), [tomerkon](https://github.com/tomerkon), and [anonimal (Kovri)](https://github.com/monero-project/kovri). + +### The Monero Research Lab + +The Core Team forms an integral part of the Monero Research Lab, but the researchers, scientists, and academics that are primarily focused on Monero research are listed below. They have chosen to remain pseudonymous for the moment. They are: + +- **Surae Noether:** Lead researcher for the Monero Research Lab, Surae holds a PhD in Mathematical Sciences and brings a rich understanding of cryptography and homological algebra to the mix. +- **Sarang Noether:** Having completed his Masters in Mathematical Sciences, Sarang is currently completing his doctoral degree in Physics, while devoting time on the side to the advancement of Monero research. +- **Shen Noether (previously)** A graduate student focused on algebraic geometry. + +### Other Contributors + +There have been massive contributions to Monero from its inception from so many people, including: zone117x, LucasJones, wolf`, Professor David Andersen, wallet42, Neozaru, Gingeropolous, cAPSLOCK, and many, many others. diff --git a/resources/projects.md b/resources/projects.md new file mode 100644 index 00000000..ae743ed1 --- /dev/null +++ b/resources/projects.md @@ -0,0 +1,26 @@ +--- +layout: static_page +title: "External Projects" +title-pre-kick: "External " +title-kick: "Projects" +title-post-kick: "" +kick-class: "yellow-kicks" +icon: "icon_projects" +attribution: "" +--- + +### Crypto-Kingdom +A MMORPG with a real-world economy with monero as native currency. You can make trades, start an in-game company or develop real estate on your path to becoming a land baron. And when you're done building your empire, you can sit back, pour a beer and chat with your friends. It's Second Life, Wall Street and social networking rolled into one game. +Visit [http://cryptokingdom.me](http://cryptokingdom.me), [Bitcointalk](https://bitcointalk.org/index.php?topic=819073.0) and [Reddit](https://www.reddit.com/r/cryptokingdom) for more info. + +### Monerodice +A Monero gambling site. +Visit [http://www.monerodice.net](http://www.monerodice.net) for more info. + +### XMR.TO +A website designed to pay any BTC address using monero. +Visit [http://www.xmr.to](http://www.xmr.to) for more info. + + + + diff --git a/resources/protocol_explanation.md b/resources/protocol_explanation.md new file mode 100644 index 00000000..40807a82 --- /dev/null +++ b/resources/protocol_explanation.md @@ -0,0 +1,40 @@ +--- +layout: static_page +title: "Protocol Explanation" +title-pre-kick: "Protocol " +title-kick: "Explanation" +title-post-kick: "" +kick-class: "kicks" +icon: "icon_about" +attribution: "" +--- + +(insert that protocol image here) + +### Bob wants to spend XMR he received in his account and send it to Carol. + +#### How is the transaction made? + +A: Bob gets access to his "real input" that was send to his "stealth address" + +1. Bob needs the public key from the transaction that contains the output he received and wants to send - Bob needs to @ECDH this key with his private view key. +2. Bob also selects the exact number of the output from the transaction that contains the output he wants to send. The other output(s) in this transaction is/are change (Bob doesn't have the private key for those other outputs) Note: typically, due to @auto-denomination, Bob will have more than one output per transaction that belongs to him. +3. Bob needs the "master" private key of his account - private spend key, to be precise. +4. Points A 1,2 and 3 are used to calculate the private key for the specific output he wants to send. (the public key for the transaction can be calculated from this private key - This is correct, but the public key is also stored on the blockchain.) + +B: To protects Carol's identity, Bob will do the following to generate a "one time" public key for this transaction, making it impossible for others to link all transactions send to Carol to the same "stealth address" + +1. Bob generates a random number scalar, this one isn't clear from the graphic at all. +2. This random number is hashed into the transaction public key the transaction private key, and is scalar mult'd into the transaction public key. +3. He selects the number associated with the outputs (due to auto-denom) that Carol will receive, the other output(s) is/are change that goes back to Bob. +4. He needs the "master" public key from Carol to be able to send it to her stealth address - Carol's public view key. +5. Points B 2,3 and 4 are used to calculate the public key for the specific outputs he wants to send. + +C: to "mix" the inputs, Bob creates a ring signature + +1. He selects the actual public key (+ that output's private key) from the output he wants to send, but he also adds other public keys into the mix. +2. To prevent double spending, Bob needs to send a valid "key image" together with the public keys of the outputs (or inputs if you prefer). +3. He signs the combination of inputs and the key image with his private key, proving the key image is valid (Bob owns the private key associated with the key image) and that (somehow? I don't know how this works) one of the public keys is used to generate this key image, but as a spectator of the blockchain, we can't know which of the used outputs is "the real one that is being transferred". His private key and the other chosen public key(s) are used to create a ring signature; they'll be one signature for each input, collectively making a ring signature. The key image is an additional public key computed from the output private key (not public key) that's actually being spent. +4. This is the collection of outputs that is signed. He grabbed the "fake ones" from the blockchain. He doesn't need permission from the owners for that. This isn't quite right: those are the outputs that are doing the signing. A hash of the TX prefix is "what" is actually being signed. +5. This is the key image he signed. If Bob ever tries to send the same output again, the exact same key image will be generated and thus the double spend will be detected. +6. This "ring signature" is added to the transaction containing the public keys that are used in the transaction and proving Bob's ownership of one of those inputs. diff --git a/resources/research-lab/index.md b/resources/research-lab/index.md new file mode 100644 index 00000000..e1f1bdd7 --- /dev/null +++ b/resources/research-lab/index.md @@ -0,0 +1,167 @@ +--- +layout: custom +title: "Monero Research Lab" +--- +
+

Monero is not only committed to making a fungible currency, but also to continued research into the realm of financial privacy as it involves cryptocurrencies. Below you'll find the work of our very own Monero Research Lab, with more papers to come.

+
+ +
+
+ +
+
+
+

Monero Research Lab Papers

+
+
+ + +
+

Abstract: This research bulletin describes a plausible attack on a ring-signature based + anonymity system. We use as motivation the cryptocurrency protocol CryptoNote + 2.0 ostensibly published by Nicolas van Saberhagen in 2012. It has been + previously demonstrated that the untraceability obscuring a one-time key pair can + be dependent upon the untraceability of all of the keys used in composing that + ring signature. This allows for the possibility of chain reactions in traceability + between ring signatures, causing a critical loss in untraceability across the whole + network if parameters are poorly chosen and if an attacker owns a sufficient + percentage of the network. The signatures are still one-time, however, and any + such attack will still not necessarily violate the anonymity of users. However, such + an attack could plausibly weaken the resistance CryptoNote demonstrates against + blockchain analysis. This research bulletin has not undergone peer review, and + reflects only the results of internal investigation. +
+
+ Read Paper +

+
+
+
+ + +
+

Abstract: On 4 September 2014, an unusual and novel attack was executed against the + Monero cryptocurrency network. This attack partitioned the network into two + distinct subsets which refused to accept the legitimacy of the other subset. This + had myriad effects, not all of which are yet known. The attacker had a short + window of time during which a sort of counterfeiting could occur, for example. + This research bulletin describes deficiencies in the CryptoNote reference code + allowing for this attack, describes the solution initially put forth by Rafal Freeman + from Tigusoft.pl and subsequently by the CryptoNote team, describes the current + fix in the Monero code base, and elaborates upon exactly what the offending + blcok did to the network. This research bulletin has not undergone peer review, + and reflects only the results of internal investigation.
+
+ Read Paper

+ +
+
+
+ + +
+

Introduction: Recently, there have been some vague fears about the CryptoNote source code and + protocol floating around the internet based on the fact that it is a more complicated + protocol than, for instance, Bitcoin. The purpose of this note is to try and clear + up some misconceptions, and hopefully remove some of the mystery surrounding + Monero Ring Signatures. I will start by comparing the mathematics involved in + CryptoNote ring signatures (as described in [CN]) to the mathematics in [FS], on + which CryptoNote is based. After this, I will compare the mathematics of the ring + signature to what is actually in the CryptoNote codebase.
+
+ Read Paper

+
+
+
+ + +
+

Abstract: We identify several blockchain analysis attacks available to degrade the +untraceability of the CryptoNote 2.0 protocol. We analyze possible solutions, +discuss the relative merits and drawbakcs to those solutions, and recommend +improvements to the Monero protocol that will hopefully provide long-term +resistance of the cryptocurrency against blockchain analysis. Our recommended +improvements to Monero include a protocol-level network-wide minimum mix-in +policy of +n += 2 +foreign outputs per ring signature, a protocol-level increase of this +value to +n += 4 +after two years, and a wallet-level default value of +n += 4 +in the +interim. We also recommend a torrent-style method of sending Monero output. +We also discuss a non-uniform, age-dependent mix-in selection method to +mitigate the other forms of blockchain analysis identified herein, but we make no +formal recommendations on implementation for a variety of reasons. The +ramifications following these improvements are also discussed in some detail. +This research bulletin has not undergone peer review, and reflects only the +results of internal investigation.
+
+ Read Paper

+
+
+
+ + +
+

Abstract: This article introduces a method of hiding transaction amounts in the strongly +decentralized anonymous cryptocurrency Monero. Similar to Bitcoin, Monero is a +cryptocurrency which is distributed through a proof of work “mining” process. +The original Monero protocol was based on CryptoNote, which uses ring +signatures and one-time keys to hide the destination and origin of transactions. +Recently the technique of using a commitment scheme to hide the amount of a +transaction has been discussed and implemented by Bitcoin Core Developer +Gregory Maxwell. In this article, a new type of ring signature, A Multi-layered +Linkable Spontaneous Anonymous Group signature is described which allows for +hidden amounts, origins and destinations of transactions with reasonable +efficiency and verifiable, trustless coin generation. Some extensions of the +protocol are provided, such as Aggregate Schnorr Range Proofs, and Ring +Multisignature. The author would like to note that early drafts of this were +publicized in the Monero Community and on the bitcoin research irc channel. +Blockchain hashed drafts are available in [14] showing that this work was started +in Summer 2015, and completed in early October 2015. An eprint is also +available at +http://eprint.iacr.org/2015/1098 +.
+
+ Read Paper

+
+
+
+
+ + + +
+
+
+
+

Cryptonote Whitepapers

+
+ +
+
+ +[Cryptonote Whitepaper](https://cryptonote.org/whitepaper.pdf) + +This is the original cryptonote paper written by the cryptonote team. Reading it will give an understanding about how the cryptonote algorithm works in general. + +[Annotated Whitepaper](https://downloads.getmonero.org/whitepaper_annotated.pdf) + +The Monero Research Lab released an anotated version of the cryptonote whitepaper. This is sort of like an informal review of the claims that are made line-by-line of the whitepaper. It also explains some of the harder concepts in relatively easy to understand terms. + +[Surae Noether's Whitepaper Review](https://downloads.getmonero.org/whitepaper_review.pdf) + +This paper is a formal review of the original cryptonote paper by MRL researcher Brandon Goodell. He takes an in-depth look at the claims and mathematics presented in the cryptonote paper. + +
+
+
+ +
+
\ No newline at end of file diff --git a/resources/roadmap/index.md b/resources/roadmap/index.md new file mode 100644 index 00000000..e35ac310 --- /dev/null +++ b/resources/roadmap/index.md @@ -0,0 +1,147 @@ +--- +layout: custom +title: Roadmap +--- +
+
+
+
+
  • +

    Completed task

    +
    +
    +
  • +

    Ongoing task

    +
    +
    +
  • +

    Upcoming task

    +
    +
    +
    +
    +
    +
    +
    + + +

    2014

    +
    + {% for toplevel in site.data.roadmap %} + {% if toplevel.year == 2014 %} + {% for roadlist in toplevel.accomplishments %} +
    +
    + +
    +
    +

    {{roadlist.date}}: {{roadlist.name}}

    +
    +
    + {%endfor%} + {%endif%} + {%endfor%} +
    + + +

    2015

    +
    + {% for toplevel in site.data.roadmap %} + + {% if toplevel.year == 2015 %} + {% for roadlist in toplevel.accomplishments %} +
    +
    + +
    +
    +

    {{roadlist.date}}: {{roadlist.name}}

    +
    +
    + + {%endfor%} + {%endif%} + + {%endfor%} +
    + + +

    2016

    +
    + {% for toplevel in site.data.roadmap %} + + {% if toplevel.year == 2016 %} + {% for roadlist in toplevel.accomplishments %} +
    +
    + +
    +
    +

    {{roadlist.date}}: {{roadlist.name}}

    +
    +
    + + {%endfor%} + {%endif%} + + {%endfor%} +
    + + +

    2017

    +
    + {% for toplevel in site.data.roadmap %} + + {% if toplevel.year == 2017 %} + {% for roadlist in toplevel.accomplishments %} +
    +
    + +
    +
    + {% if roadlist.date %} +

    {{roadlist.date}}: {{roadlist.name}}

    + {%else%} +

    {{roadlist.name}}

    + {%endif%} +
    +
    + + {%endfor%} + {%endif%} + + {%endfor%} +
    + + +

    Future

    +
    + {% for toplevel in site.data.roadmap %} + + {% if toplevel.year == 2018 %} + {% for roadlist in toplevel.accomplishments %} +
    +
    + +
    +
    + {% if roadlist.date %} +

    {{roadlist.date}}: {{roadlist.name}}

    + {%else%} +

    {{roadlist.name}}

    + {%endif%} +
    +
    + + {%endfor%} + {%endif%} + + {%endfor%} +
    +
    +
    +
    +
    + + +
    \ No newline at end of file diff --git a/resources/user-guides/How-to-mine-Monero-XMR-without-a-mining-equipment.md b/resources/user-guides/How-to-mine-Monero-XMR-without-a-mining-equipment.md new file mode 100644 index 00000000..19335ffb --- /dev/null +++ b/resources/user-guides/How-to-mine-Monero-XMR-without-a-mining-equipment.md @@ -0,0 +1,48 @@ +## How to mine Monero (XMR) without a mining equipment? + +If you don’t have a profitable mining equipment, nor time or +money to invest into building it, you can still mine Monero with NiceHash. + +NiceHash is a hashing power marketplace. Sellers of hashing +power, i.e. miners, provide the hashing power for buyers (those who want to buy +a service of mining a certain coin). Hence, NiceHash can provide you a massive +hashing power in short amount of time. You won’t have to wait for years to see +if you will make a profit or not and you can control which coin, at which pool, +and for how long you want to mine. + +### **Step 1:** Create new account at NiceHash + +Visit [registration +page](https://www.nicehash.com/?p=register) and register with your e-mail address. + +### **Step 2:** Deposit some Bitcoins to your account + +You will mine Monero, but you can buy hashing power at +NiceHash only with Bitcoins. You can always withdraw unspent Bitcoins from your +account back to any Bitcoin wallet. + +Visit your [wallet +page](https://www.nicehash.com/?p=wallet) and make a deposit. Note that the minimum price for placing an order +equals 0.01 BTC. + +### **Step 3:** Find a suitable pool for mining and add it to your pool list + +Selection of the pool plays a big role in the final amount +of mined cryptocurrency. Make sure the pool you have selected can handle +massive hashing rate and loads of shares, especially from a single connection. +You can find a list of Monero pools [here](https://bitcointalk.org/index.php?topic=583449.0). + +Note that you will probably have to register an account at +selected pool as well. The pool will provide you with all the information you need. +You can save your favourite pools at [this page](https://www.nicehash.com/?p=managepools). + +### **Step 4:** Create new order and start mining + +When creating a [new order](https://www.nicehash.com/?p=orders&new), make sure you +select CryptoNight algorithm for mining Monero. If you want to first learn more +about placing an order with NiceHash, we recommend you to read this [frequently asked question](https://www.nicehash.com/?p=faq#faqb0). + +If you want to bid on +hashing power select Standard (bidding) order type and if you want a fixed +order that cannot be outbid, select Fixed order type. The status of marketplace +and approximate prices of mining can be checked at [live marketplace](https://www.nicehash.com/index.jsp?p=orders).  \ No newline at end of file diff --git a/resources/user-guides/Offline_Backup.md b/resources/user-guides/Offline_Backup.md new file mode 100644 index 00000000..4a3a929e --- /dev/null +++ b/resources/user-guides/Offline_Backup.md @@ -0,0 +1,47 @@ +--- +layout: static_page +title: "Creating an Offline Backup of your Monero Account" +title-pre-kick: "Creating an Offline Backup " +title-kick: "of your Monero " +title-post-kick: "Account" +kick-class: "purple-kicks" +icon: "icon_userguides" +attribution: "" +--- + +## Operating Systems: Various versions of Linux and Windows 7, 8 + +### Wallet Software: Simplewallet + +#### Resource for Creating Bootable Disks: [Linux](http://www.pendrivelinux.com/), [Windows](https://www.microsoft.com/en-us/download/windows-usb-dvd-download-tool) + +#### Resource for Monero Binaries: [Monero Binaries](https://getmonero.org/downloads/) + +- Take any computer you have lying around, even your normal workstation. You may find it easier to use an older computer that has no wifi or bluetooth if you're particularly paranoid + +- Create a Linux or Windows bootable disk, and make sure you have the Monero binaries on the same disk or on a second disk (for Linux make sure you have also downloaded copies of the dependencies you will need, libboost1.55 and miniupnpc for instance) + +- Disconnect the network and/or Internet cables from your computer, physically remove the wifi card or switch the wifi/bluetooth off on a laptop if possible + +- Boot into your bootable OS, install the dependencies if necessary + +- Copy the Monero binaries to to a RAM disk (/dev/shm in Linux, Windows bootable ISOs normally have a Z: drive or something) + +- Don't run the Monero daemon. Instead, using the command line, use monero-wallet-cli to create a new Monero @account + +- When prompted for a name, give it any name, it doesn't really matter + +- When prompted for a password, type in like 50 - 100 random characters. Don't worry that you don't know the password, just make it LONG + +- **CRITICAL STEP**: Write down (on paper) your 25 word @mnemonic-seed +**WARNING**: If you forget to write down this information your funds may be lost forever + +- Write down (on your phone, on paper, on another computer, wherever you want) your address and view key + +- Switch off the computer, remove the battery if there is one, and leave it physically off for a few hours + +The account you've created was created in RAM, and the digital files are now inaccessible. If some adversary manages to somehow obtain the data, they will lack the long password to open it. If you need to receive payments, you have your public address, and you have the view key if needed. If you need access to it, you have your 25 word @mnemonic-seed, and you can now write out several copies of it, including an offsite copy (e.g. a bank deposit box). + +Credit: Riccardo Spagni + +Related: [Offline Account Generator](http://moneroaddress.org/) diff --git a/resources/user-guides/create_wallet.md b/resources/user-guides/create_wallet.md new file mode 100644 index 00000000..0017f088 --- /dev/null +++ b/resources/user-guides/create_wallet.md @@ -0,0 +1,71 @@ +--- +layout: static_page +title: "Creating a Monero wallet" +title-pre-kick: "Creating a Monero wallet " +title-kick: "on Ubuntu " +title-post-kick: "" +kick-class: "purple-kicks" +icon: "icon_userguides" +attribution: "" +--- + +### Operating Systems: Ubuntu + +- Download the [official binaries](https://getmonero.org/downloads/) or compile the last source available on [Github](https://github.com/monero-project/bitmonero) + +![image1](https://github.com/luuul/monero-site/blob/master/knowledge-base/user-guides/png/create_wallet/1.png) +![image2](https://github.com/luuul/monero-site/blob/master/knowledge-base/user-guides/png/create_wallet/2.png) + +- Extract the files with the archive manager (same as Winzip on Windows). Note the path where the files "monerod" and "monero-wallet-cli" are + +![image3](https://github.com/luuul/monero-site/blob/master/knowledge-base/user-guides/png/create_wallet/3.png) +![image4](https://github.com/luuul/monero-site/blob/master/knowledge-base/user-guides/png/create_wallet/4.png) + +- You only need to do this step once : open a terminal (ctrl+alt+t) and install the required dependencies by typing : "*sudo apt-get install libboost-all-dev libssl-dev libevent-dev libdb++-dev*". When asked, press the Y key and then Enter to continue + +![image5](https://github.com/luuul/monero-site/blob/master/knowledge-base/user-guides/png/create_wallet/5.png) +![image6](https://github.com/luuul/monero-site/blob/master/knowledge-base/user-guides/png/create_wallet/6.png) + +- Open a terminal and load the path where your binaries are extracted (cf. step 2) by typing : "*cd yourPathFromStep2*" + +![image7](https://github.com/luuul/monero-site/blob/master/knowledge-base/user-guides/png/create_wallet/7.png) + +- Load monerod by typing in your terminal : "*./monerod*". Wait for the synchronisation with the network (monerod is updating the blockchain you have downloaded in step 4 or is downloading it from scratch). This can take a lot of time the first time, so be patient + +![image8](https://github.com/luuul/monero-site/blob/master/knowledge-base/user-guides/png/create_wallet/8.png) +![image9](https://github.com/luuul/monero-site/blob/master/knowledge-base/user-guides/png/create_wallet/9.png) +![image10](https://github.com/luuul/monero-site/blob/master/knowledge-base/user-guides/png/create_wallet/10.png) +![image11](https://github.com/luuul/monero-site/blob/master/knowledge-base/user-guides/png/create_wallet/11.png) + +- Once monerod is synchronised with the network, open a new terminal, change the directory (cf. step 5), and launch monero-wallet-cli by typing "*./monero-wallet-cli*" + +![image12](https://github.com/luuul/monero-site/blob/master/knowledge-base/user-guides/png/create_wallet/12.png) + +- Enter the name you want for your portfolio and follow the instructions from the terminal + +![image13](https://github.com/luuul/monero-site/blob/master/knowledge-base/user-guides/png/create_wallet/13.png) +![image14](https://github.com/luuul/monero-site/blob/master/knowledge-base/user-guides/png/create_wallet/14.png) +![image15](https://github.com/luuul/monero-site/blob/master/knowledge-base/user-guides/png/create_wallet/15.png) +![image16](https://github.com/luuul/monero-site/blob/master/knowledge-base/user-guides/png/create_wallet/16.png) + +*This is your private key. Write it down and keep it in a safe place!* + +![image17](https://github.com/luuul/monero-site/blob/master/knowledge-base/user-guides/png/create_wallet/17.png) + +*This is your view key. You need it to create a view only wallet (cf. associated user guide)* + +![image18](https://github.com/luuul/monero-site/blob/master/knowledge-base/user-guides/png/create_wallet/18.png) + +*This is the address of your wallet* + +![image19](https://github.com/luuul/monero-site/blob/master/knowledge-base/user-guides/png/create_wallet/19.png) +![image20](https://github.com/luuul/monero-site/blob/master/knowledge-base/user-guides/png/create_wallet/20.png) +![image21](https://github.com/luuul/monero-site/blob/master/knowledge-base/user-guides/png/create_wallet/21.png) +![image22](https://github.com/luuul/monero-site/blob/master/knowledge-base/user-guides/png/create_wallet/22.png) +![image23](https://github.com/luuul/monero-site/blob/master/knowledge-base/user-guides/png/create_wallet/23.png) + +- To exit monerod or monero-wallet-cli just type "*exit*" in the associated terminal + +Now to access the portfolio you have just created you will have to launch monerod, wait for it to be synchronised with the network, launch monero-wallet-cli, and type the name of your portfolio and your password. + + diff --git a/resources/user-guides/easiest_buy.md b/resources/user-guides/easiest_buy.md new file mode 100644 index 00000000..48c84896 --- /dev/null +++ b/resources/user-guides/easiest_buy.md @@ -0,0 +1,75 @@ +--- +layout: static_page +title: "Easiest way to buy Monero" +title-pre-kick: "Easiest way" +title-kick: "to buy Monero" +title-post-kick: "" +kick-class: "purple-kicks" +icon: "icon_userguides" +attribution: "" +--- + +## How to obtain monero + +This is a guide to obtain your own Monero as of 20150919. This is perhaps the easiest way to purchase and hold Monero. + +####Step 1: Buy bitcoin + +There are many ways to buy bitcoin. Perhaps the easiest way is through circle.com. Once you have purchased some bitcoin, you are ready to buy some Monero! Buying bitcoin is straightforward. Please goto circle.com and just follow the instructions there. + +####Step 2: Set up a mymonero.com account + +MyMonero.com is an online wallet for Monero, maintained by Monero Core Developer Ricardo Spagni (fluffpony). It is the easiest wallet to use. Simply go to MyMonero.com and click on the "Create an Account" button. + +![image1](https://github.com/luuul/monero-site/blob/master/knowledge-base/user-guides/png/easiest_way/01.png) + +After clicking the button, you will see your private key. This key is what gives you access to your funds. Never share this key with anyone! + +### WRITE DOWN THIS KEY IMMEDIATELY! + +![image2](https://github.com/luuul/monero-site/blob/master/knowledge-base/user-guides/png/easiest_way/02.png) + +Type in your private key in the box below, and click the button. + +On the next page, you will see your address. + +![image3](https://github.com/luuul/monero-site/blob/master/knowledge-base/user-guides/png/easiest_way/03.png) + +Copy your address to the clipboard by highlighting the whole thing and hitting ctrl+c (or edit menu, copy), or clicking the little icon next to your address. Save your address somewhere. This is how others will send Monero to you, and what you will use to deposit Monero into your account! + +#### Step 3: Buy monero and transfer the monero to your new address + +Go to www.shapeshift.io . On the righthand side, of the screen, click icon under "Receive" to select Monero. + +![image5](https://github.com/luuul/monero-site/blob/master/knowledge-base/user-guides/png/easiest_way/05.png) +![image6](https://github.com/luuul/monero-site/blob/master/knowledge-base/user-guides/png/easiest_way/06.png) + +Paste your address into the field under the Monero logo. Select the "agree to terms" button, then hit "Start" + +![image7](https://github.com/luuul/monero-site/blob/master/knowledge-base/user-guides/png/easiest_way/07.png) + +In the new screen that pops up, copy the Deposit Address into your clipboard (select and hit ctrl+c or edit-copy) + +![image8](https://github.com/luuul/monero-site/blob/master/knowledge-base/user-guides/png/easiest_way/08.png) + +Go back to your circle.com page, hit the "transfer" button, and paste the bitcoin address into the field +Enter the amount of bitcoin you would like to spend. + +![image4](https://github.com/luuul/monero-site/blob/master/knowledge-base/user-guides/png/easiest_way/04.png) +![image9](https://github.com/luuul/monero-site/blob/master/knowledge-base/user-guides/png/easiest_way/09.png) + +You will get a text message verification code. Enter code and hit send. + +![image10](https://github.com/luuul/monero-site/blob/master/knowledge-base/user-guides/png/easiest_way/10.png) + +You will see the shapeshift change to "awaiting exchange" + +![image11](https://github.com/luuul/monero-site/blob/master/knowledge-base/user-guides/png/easiest_way/11.png) + +Then it will change to COMPLETE! + +![image12](https://github.com/luuul/monero-site/blob/master/knowledge-base/user-guides/png/easiest_way/12.png) + +After a while you will see it in your Monero account + +![image13](https://github.com/luuul/monero-site/blob/master/knowledge-base/user-guides/png/easiest_way/13.png) diff --git a/resources/user-guides/howto_fix_stuck_funds.md b/resources/user-guides/howto_fix_stuck_funds.md new file mode 100644 index 00000000..b25165f4 --- /dev/null +++ b/resources/user-guides/howto_fix_stuck_funds.md @@ -0,0 +1,41 @@ +--- +layout: static_page +title: "How to fix stuck funds" +title-pre-kick: "Fix " +title-kick: "Stuck funds" +title-post-kick: "" +kick-class: "kicks" +icon: "icon_about" +attribution: "" +--- + +Sometimes, your funds will become stuck - you will have some locked funds that never become unlocked. This is how you fix it. + +- Load your wallet in monero-wallet-cli. + +- Type + +> seed + +into the command prompt. Write down your 25 word seed, if you haven't already. This is the best way to make sure you don't loose access to your funds. + +- Close monero-wallet-cli by typing + +> exit + +- Backup all of your wallet related files. These include: + +> yourwalletname.bin +> yourwalletname.bin.keys +> yourwalletname.bin.address.txt + +This can be done by copying the files to a new folder. + +Sometimes, when creating your wallet, you might have named it something without the .bin part. In that case, the wallet file will be called yourwalletname without the .bin at the end. + +- Delete yourwallet.bin + +- Load monero-wallet-cli, type in the name of the wallet you just deleted + +- Enter password. The wallet will now refresh and hopefully your locked funds will now become unlocked. + diff --git a/resources/user-guides/index.md b/resources/user-guides/index.md new file mode 100644 index 00000000..ea16a9c0 --- /dev/null +++ b/resources/user-guides/index.md @@ -0,0 +1,77 @@ +--- +layout: custom +title: "User Guides" +--- +
    +
    +
    +
    +
    +
    +
    +

    General

    +
    +
    +
    + +[Monero Tools](monero_tools.html) +[How to make an offline backup](Offline_Backup.html) +[How to run a node on VPS](vps_run_node.html) +[Securely purchasing and storing Monero](securely_purchase.html) + +
    +
    +
    +
    +
    +
    +
    +

    Wallets

    +
    +
    +
    + +[Getting started with the CLI wallet](monero-wallet-cli.html) +[How to make a view-only wallet](view_only.html) +[How to prove payment](prove-payment.html) + +
    +
    +
    +
    +
    + +
    +
    +
    +
    +
    +
    +

    Recovery

    +
    +
    +
    + +[How to fix locked up funds](howto_fix_stuck_funds.html) +[How to restore your account](restore_account.html) + +
    +
    +
    +
    +
    +
    +
    +

    Mining

    +
    +
    +
    + +User Guides for Mining coming soon. + +
    +
    +
    +
    +
    +
    diff --git a/resources/user-guides/monero-wallet-cli.md b/resources/user-guides/monero-wallet-cli.md new file mode 100644 index 00000000..58667ad1 --- /dev/null +++ b/resources/user-guides/monero-wallet-cli.md @@ -0,0 +1,155 @@ +--- +layout: static_page +title: "Monero tools" +title-pre-kick: "Monero tools " +title-kick: "for the network " +title-post-kick: "" +kick-class: "purple-kicks" +icon: "icon_userguides" +attribution: "" +--- +# monero-wallet-cli + +`monero-wallet-cli` is the wallet software that ships with the Monero tree. It is a console program, +and manages an account. While a bitcoin wallet manages both an account and the blockchain, +Monero separates these: `monerod` handles the blockchain, and `monero-wallet-cli` handles the account. + +This guide will show how to perform various operations from the `monero-wallet-cli` UI. The guide assumes you are using the most recent version of Monero and have already created an account according to the other guides. + + +## Checking your balance + +Since the blockchain handling and the wallet are separate programs, many uses of `monero-wallet-cli` +need to work with the daemon. This includes looking for incoming transactions to your address. +Once you are running both `monero-wallet-cli` and `monerod`, enter `balance`. + +Example: + +This will pull blocks from the daemon the wallet did not yet see, and update your balance +to match. This process will normally be done in the background every minute or so. To see the +balance without refreshing: + + balance + Balance: 64.526198850000, unlocked balance: 44.526198850000, including unlocked dust: 0.006198850000 + +In this example, `Balance` is your total balance. The `unlocked balance` is the amount currently available to spend. Newly received transactions require 10 confirmations on the blockchain before being unlocked. `unlocked dust` refers to very small amounts of unspent outputs that may have accumulated in your account. + +## Sending monero + +You will need the standard address you want to send to (a long string starting with '4'), and +possibly a payment ID, if the receiving party requires one. In that latter case, that party +may instead give you an integrated address, which is both of these packed into a single address. + +### Sending to a standard address: + + transfer ADDRESS AMOUNT PAYMENTID + +Replace `ADDRESS` with the address you want to send to, `AMOUNT` with how many monero you want to send, +and `PAYMENTID` with the payment ID you were given. Payment ID's are optional. If the receiving party doesn't need one, just +omit it. + +### Sending to an integrated address: + + transfer ADDRESS AMOUNT + +The payment ID is implicit in the integrated address in that case. + +### Specify the number of outputs for a transaction: + + transfer MIXIN ADDRESS AMOUNT + +Replace `MIXIN` with the number of outputs you wish to use. **If not specified, the default is 4.** It's a good idea to use the default, but you can increase the number if you want to include more outputs. The higher the number, the larger the transaction, and higher fees are needed. + + +## Receiving monero + +If you have your own Monero address, you just need to give your standard address to someone. + +You can find out your address with: + + address + +Since Monero is anonymous, you won't see the origin address the funds you receive came from. If you +want to know, for instance to credit a particular customer, you'll have to tell the sender to use +a payment ID, which is an arbitrary optional tag which gets attached to a transaction. To make life +easier, you can generate an address that already includes a random payment ID: + + integrated_address + +This will generate a random payment ID, and give you the address that includes your own account +and that payment ID. If you want to select a particular payment ID, you can do that too: + + integrated_address 12346780abcdef00 + +Payments made to an integrated address generated from your account will go to your account, +with that payment id attached, so you can tell payments apart. + + +## Proving to a third party you paid someone + +If you pay a merchant, and the merchant claims to not have received the funds, you may need +to prove to a third party you did send the funds - or even to the merchant, if it is a honest +mistake. Monero is private, so you can't just point to your transaction in the blockchain, +as you can't tell who sent it, and who received it. However, by supplying the per-transaction +private key to a party, that party can tell whether that transaction sent monero to that +particular address. Note that storing these per-transaction keys is disabled by default, and +you will have to enable it before sending, if you think you may need it: + + set store-tx-info 1 + +You can retrieve the tx key from an earlier transaction: + + get_tx_key 1234567890123456789012345678901212345678901234567890123456789012 + +Pass in the transaction ID you want the key for. Remember that a payment might have been +split in more than one transaction, so you may need several keys. You can then send that key, +or these keys, to whoever you want to provide proof of your transaction, along with the +transaction id and the address you sent to. Note that this third party, if knowing your +own address, will be able to see how much change was returned to you as well. + +If you are the third party (that is, someone wants to prove to you that they sent monero +to an address), then you can check this way: + + check_tx_key TXID TXKEY ADDRESS + +Replace `TXID`, `TXKEY` and `ADDRESS` with the transaction ID, per-transaction key, and destination +address which were supplied to you, respectively. monero-wallet-cli will check that transaction +and let you know how much monero this transaction paid to the given address. + + +## Getting a chance to confirm/cancel payments + +If you want to get a last chance confirmation when sending a payment: + + set always-confirm-transfers 1 + + +## How to find a payment to you + +If you received a payment using a particular payment ID, you can look it up: + + payments PAYMENTID + +You can give more than one payment ID too. + +More generally, you can review incoming and outgoing payments: + + show_transfers + +You can give an optional height to list only recent transactions, and request +only incoming or outgoing transactions. For example, + + show_transfers in 650000 + +will only incoming transfers after block 650000. You can also give a height +range. + +If you want to mine, you can do so from the wallet: + + start_mining 2 + +This will start mining on the daemon usin two threads. Note that this is solo mining, +and may take a while before you find a block. To stop mining: + + stop_mining + diff --git a/resources/user-guides/monero_tools.md b/resources/user-guides/monero_tools.md new file mode 100644 index 00000000..0e46c880 --- /dev/null +++ b/resources/user-guides/monero_tools.md @@ -0,0 +1,27 @@ +--- +layout: static_page +title: "Monero tools" +title-pre-kick: "Monero tools " +title-kick: "for the network " +title-post-kick: "" +kick-class: "purple-kicks" +icon: "icon_userguides" +attribution: "" +--- +# Monero tools + +These tools can be used to gain information about the Monero network or your transaction data in the blockchain. + +### [Check that a recipient has received your funds](http://xmrtests.llcoins.net/checktx.html) + +### [Tools for monero address generation](https://xmr.llcoins.net/) + +### [Monero node count](http://moneronodes.i2p.xyz/) + +### [Monero node map](https://monerohash.com/nodes-distribution.html) + +### [Monero offline wallet generator](http://moneroaddress.org/) + +### [Monero network statistics](http://moneroblocks.info/stats) + +### [Monero.how statistics](https://www.monero.how/) \ No newline at end of file diff --git a/resources/user-guides/png/create_wallet/1.png b/resources/user-guides/png/create_wallet/1.png new file mode 100644 index 00000000..44acf51b Binary files /dev/null and b/resources/user-guides/png/create_wallet/1.png differ diff --git a/resources/user-guides/png/create_wallet/10.png b/resources/user-guides/png/create_wallet/10.png new file mode 100644 index 00000000..2f248c9d Binary files /dev/null and b/resources/user-guides/png/create_wallet/10.png differ diff --git a/resources/user-guides/png/create_wallet/11.png b/resources/user-guides/png/create_wallet/11.png new file mode 100644 index 00000000..f8bb9989 Binary files /dev/null and b/resources/user-guides/png/create_wallet/11.png differ diff --git a/resources/user-guides/png/create_wallet/12.png b/resources/user-guides/png/create_wallet/12.png new file mode 100644 index 00000000..2e1f69d6 Binary files /dev/null and b/resources/user-guides/png/create_wallet/12.png differ diff --git a/resources/user-guides/png/create_wallet/13.png b/resources/user-guides/png/create_wallet/13.png new file mode 100644 index 00000000..2db5d603 Binary files /dev/null and b/resources/user-guides/png/create_wallet/13.png differ diff --git a/resources/user-guides/png/create_wallet/14.png b/resources/user-guides/png/create_wallet/14.png new file mode 100644 index 00000000..bf2906e2 Binary files /dev/null and b/resources/user-guides/png/create_wallet/14.png differ diff --git a/resources/user-guides/png/create_wallet/15.png b/resources/user-guides/png/create_wallet/15.png new file mode 100644 index 00000000..7c675edf Binary files /dev/null and b/resources/user-guides/png/create_wallet/15.png differ diff --git a/resources/user-guides/png/create_wallet/16.png b/resources/user-guides/png/create_wallet/16.png new file mode 100644 index 00000000..ab23b572 Binary files /dev/null and b/resources/user-guides/png/create_wallet/16.png differ diff --git a/resources/user-guides/png/create_wallet/17.png b/resources/user-guides/png/create_wallet/17.png new file mode 100644 index 00000000..97ea15bc Binary files /dev/null and b/resources/user-guides/png/create_wallet/17.png differ diff --git a/resources/user-guides/png/create_wallet/18.png b/resources/user-guides/png/create_wallet/18.png new file mode 100644 index 00000000..20546a9a Binary files /dev/null and b/resources/user-guides/png/create_wallet/18.png differ diff --git a/resources/user-guides/png/create_wallet/19.png b/resources/user-guides/png/create_wallet/19.png new file mode 100644 index 00000000..5a7088e2 Binary files /dev/null and b/resources/user-guides/png/create_wallet/19.png differ diff --git a/resources/user-guides/png/create_wallet/2.png b/resources/user-guides/png/create_wallet/2.png new file mode 100644 index 00000000..164aa6b6 Binary files /dev/null and b/resources/user-guides/png/create_wallet/2.png differ diff --git a/resources/user-guides/png/create_wallet/20.png b/resources/user-guides/png/create_wallet/20.png new file mode 100644 index 00000000..c5169249 Binary files /dev/null and b/resources/user-guides/png/create_wallet/20.png differ diff --git a/resources/user-guides/png/create_wallet/21.png b/resources/user-guides/png/create_wallet/21.png new file mode 100644 index 00000000..090ff767 Binary files /dev/null and b/resources/user-guides/png/create_wallet/21.png differ diff --git a/resources/user-guides/png/create_wallet/22.png b/resources/user-guides/png/create_wallet/22.png new file mode 100644 index 00000000..8c7a7669 Binary files /dev/null and b/resources/user-guides/png/create_wallet/22.png differ diff --git a/resources/user-guides/png/create_wallet/23.png b/resources/user-guides/png/create_wallet/23.png new file mode 100644 index 00000000..e2dfc0c4 Binary files /dev/null and b/resources/user-guides/png/create_wallet/23.png differ diff --git a/resources/user-guides/png/create_wallet/3.png b/resources/user-guides/png/create_wallet/3.png new file mode 100644 index 00000000..f4f4436e Binary files /dev/null and b/resources/user-guides/png/create_wallet/3.png differ diff --git a/resources/user-guides/png/create_wallet/4.png b/resources/user-guides/png/create_wallet/4.png new file mode 100644 index 00000000..36be1be0 Binary files /dev/null and b/resources/user-guides/png/create_wallet/4.png differ diff --git a/resources/user-guides/png/create_wallet/5.png b/resources/user-guides/png/create_wallet/5.png new file mode 100644 index 00000000..56c6733a Binary files /dev/null and b/resources/user-guides/png/create_wallet/5.png differ diff --git a/resources/user-guides/png/create_wallet/6.png b/resources/user-guides/png/create_wallet/6.png new file mode 100644 index 00000000..8e0d7950 Binary files /dev/null and b/resources/user-guides/png/create_wallet/6.png differ diff --git a/resources/user-guides/png/create_wallet/7.png b/resources/user-guides/png/create_wallet/7.png new file mode 100644 index 00000000..c1852782 Binary files /dev/null and b/resources/user-guides/png/create_wallet/7.png differ diff --git a/resources/user-guides/png/create_wallet/8.png b/resources/user-guides/png/create_wallet/8.png new file mode 100644 index 00000000..ce02508b Binary files /dev/null and b/resources/user-guides/png/create_wallet/8.png differ diff --git a/resources/user-guides/png/create_wallet/9.png b/resources/user-guides/png/create_wallet/9.png new file mode 100644 index 00000000..cac31479 Binary files /dev/null and b/resources/user-guides/png/create_wallet/9.png differ diff --git a/resources/user-guides/png/easiest_way/01.png b/resources/user-guides/png/easiest_way/01.png new file mode 100644 index 00000000..17c55b2d Binary files /dev/null and b/resources/user-guides/png/easiest_way/01.png differ diff --git a/resources/user-guides/png/easiest_way/02.png b/resources/user-guides/png/easiest_way/02.png new file mode 100644 index 00000000..91e1bfd1 Binary files /dev/null and b/resources/user-guides/png/easiest_way/02.png differ diff --git a/resources/user-guides/png/easiest_way/03.png b/resources/user-guides/png/easiest_way/03.png new file mode 100644 index 00000000..dded71ad Binary files /dev/null and b/resources/user-guides/png/easiest_way/03.png differ diff --git a/resources/user-guides/png/easiest_way/04.png b/resources/user-guides/png/easiest_way/04.png new file mode 100644 index 00000000..e657d431 Binary files /dev/null and b/resources/user-guides/png/easiest_way/04.png differ diff --git a/resources/user-guides/png/easiest_way/05.png b/resources/user-guides/png/easiest_way/05.png new file mode 100644 index 00000000..00d2b26a Binary files /dev/null and b/resources/user-guides/png/easiest_way/05.png differ diff --git a/resources/user-guides/png/easiest_way/06.png b/resources/user-guides/png/easiest_way/06.png new file mode 100644 index 00000000..4d55286c Binary files /dev/null and b/resources/user-guides/png/easiest_way/06.png differ diff --git a/resources/user-guides/png/easiest_way/07.png b/resources/user-guides/png/easiest_way/07.png new file mode 100644 index 00000000..715245b2 Binary files /dev/null and b/resources/user-guides/png/easiest_way/07.png differ diff --git a/resources/user-guides/png/easiest_way/08.png b/resources/user-guides/png/easiest_way/08.png new file mode 100644 index 00000000..bfc459a8 Binary files /dev/null and b/resources/user-guides/png/easiest_way/08.png differ diff --git a/resources/user-guides/png/easiest_way/09.png b/resources/user-guides/png/easiest_way/09.png new file mode 100644 index 00000000..e632bbb8 Binary files /dev/null and b/resources/user-guides/png/easiest_way/09.png differ diff --git a/resources/user-guides/png/easiest_way/10.png b/resources/user-guides/png/easiest_way/10.png new file mode 100644 index 00000000..3a933733 Binary files /dev/null and b/resources/user-guides/png/easiest_way/10.png differ diff --git a/resources/user-guides/png/easiest_way/11.png b/resources/user-guides/png/easiest_way/11.png new file mode 100644 index 00000000..eaa4a5b9 Binary files /dev/null and b/resources/user-guides/png/easiest_way/11.png differ diff --git a/resources/user-guides/png/easiest_way/12.png b/resources/user-guides/png/easiest_way/12.png new file mode 100644 index 00000000..e38159ec Binary files /dev/null and b/resources/user-guides/png/easiest_way/12.png differ diff --git a/resources/user-guides/png/easiest_way/13.png b/resources/user-guides/png/easiest_way/13.png new file mode 100644 index 00000000..ed3b707d Binary files /dev/null and b/resources/user-guides/png/easiest_way/13.png differ diff --git a/resources/user-guides/prove-payment.md b/resources/user-guides/prove-payment.md new file mode 100644 index 00000000..2623a172 --- /dev/null +++ b/resources/user-guides/prove-payment.md @@ -0,0 +1,60 @@ +--- +layout: static_page +title: "How to prove payment" +title-pre-kick: "Prove " +title-kick: "payment" +title-post-kick: "" +kick-class: "kicks" +icon: "icon_about" +attribution: "" +--- + +When you send money to a party who then disputes the payment was made, you need to be able to prove the payment was made. + +With Bitcoin, this is typically done by looking up the transaction ID, where the origin and destination addresses are +shown, along with the amount transacted. + +Monero, however, is private: that information is not available publicly on the blockchain. The steps are therefore a bit +more involved. + +To prove to Charlie that she made a payment to Bob, Alice must supply Charlie three pieces of information: + +- the transaction ID, as is done in Bitcoin +- Bob's address, as is done with Bitcoin +- the transaction's key, which is new with Monero and other Cryptonote currencies + +When Alice made the transaction, a one time key was automatically generated just for this transaction. Alice can +query it thus in monero-wallet-cli (new name for the old simplewallet): + +> get_tx_key TXID + +Alice would plug in her actual transaction ID instead of this TXID placeholder. All being well, the one time transaction key +will be displayed. + +Note that this will only work if monero-wallet-cli is set to save transaction keys. To double check: + +> set + +If it's set to 0, set it to 1: + +> set store-tx-info 1 + +Alice can now send Charlie the transaction key along with transaction ID and Bob's address. + +Note: if several transactions were made, this needs repeating for each such transaction. + + +--- + +Charlie now received those three pieces of information, and wants to check Alice is telling the truth: on an up to date +blockchain, Charlie types in monero-wallet-cli: + +> check_tx_key TXID TXKEY ADDRESS + +The information supplied by Alice plugs neatly instead of the placeholders. monero-wallet-cli will use the transaction +key to decode the transaction, and display how much this particular transaction sent to this address. Obviously, +Charlie will want to double check with Bob the address is really his - same as with Bitcoin. + +Note: if several transactions were made, this needs repeating for each such transaction. + + diff --git a/resources/user-guides/restore_account.md b/resources/user-guides/restore_account.md new file mode 100644 index 00000000..f9ead4bb --- /dev/null +++ b/resources/user-guides/restore_account.md @@ -0,0 +1,33 @@ +--- +layout: static_page +title: "Restoring your Monero Wallet" +title-pre-kick: "Restoring your " +title-kick: "Monero " +title-post-kick: "Wallet" +kick-class: "purple-kicks" +icon: "icon_userguides" +attribution: "" +--- + +## Operating Systems: Windows, Linux, Mac + +### Account Software: monero-wallet-cli + +- Retrieve your 25 word @mnemonic-seed that you saved when creating your old Monero @wallet + +- Open a command prompt and navigate to the drive and directory that contains monero-wallet-cli + +- At the command prompt type: `monero-wallet-cli --restore-deterministic-wallet` + +- Once you press enter you will be prompted for a wallet file name. Give your wallet a new name, any name will do + +- Press enter again and you will be prompted for a password. Give your wallet a new and long password + +- Press enter again you will be prompted to repeat the password + +- Press enter again and you will be prompted for the 25 word electrum style mnemonic seed that you retrieved earlier + +- You will then be prompted with "Restore from specific blockchain height (optional, default 0):" Default will start the restore process from the beginning of the Monero blockchain. If you don't know the specific blockchain height, just hit enter. (Specifying a specific blockchain height will start the restore process from that specific height. This will save a bit of time in scanning, if you know what starting blockchain height your initial funds were transacted for this specific account.) + +After you have entered the 25 word mnemonic seed and have chosen your specific blockchain height, monero-wallet-cli will generate the same public address and view key as your old wallet and begin the refresh process automatically. (Please be patient as the refresh process may take a while.) + diff --git a/resources/user-guides/securely_purchase.md b/resources/user-guides/securely_purchase.md new file mode 100644 index 00000000..6fd700ce --- /dev/null +++ b/resources/user-guides/securely_purchase.md @@ -0,0 +1,87 @@ +--- +layout: static_page +title: Securely purchasing and storing Monero +--- + + +## How to purchase Monero and securely store it. + +This is a guide to purchase and securely store Monero as of June 2017. + +#### Step 1: Buy Bitcoin + +There are many ways to buy Bitcoin. Two semi-reliable companies at this time are Xapo and Coinbase . The process will involve uploading your personal identification (State ID, Passport, etc.) and will take anywhere from 2 to 10 days (or longer). Verify their reputation on Reddit before making a large purchase. Xapo uses Wire Transfer and Coinbase uses Bank Transfer (ACH in the USA). Xapo should be faster than Coinbase. Coinbase also allows small "instant" buys via a debit card but adds a large fee for this option. Once you have purchased Bitcoin, you are ready to convert it to Monero! + +#### Step 2: Download and create a Paper Wallet on a secure and air-gapped computer. + +Download the paper wallet generator at: https://moneroaddress.org and copy it to a USB stick (Direct link: https://github.com/moneromooo-monero/monero-wallet-generator/archive/master.zip). + +Unzip and open the paper wallet generator (monero-wallet-generator.html) into a web browser on an air-gapped computer that hasn't been used before, or has had a clean installation of the OS. + +Your paper wallet will have four important items: + +Monero Public Address +The public address is used to receive funds to the wallet. You give this to anyone who will be sending funds to your wallet. + +Monero Mnemonic Seed +The mnemonic seed is a method of storing the entire wallet that is easily recognizable to humans. This is all you need to restore your wallet at a later date. + +Monero Private Spend Key +The private spend key is used to send funds from the wallet. + +Monero Private View Key +The private view key is to view transactions entering the wallet. Commonly this is used to setup a view-only only wallet which can see incoming transactions live on the blockchain as they are sent to a cold storage wallet. + +At this point you have many options. You can print the wallet on paper, save it as a PDF or text on a USB stick, burn it to CD/DVD, etc. Most likely you will want at least two or three copies, stored securely in different locations. If storing digitally, encrypt everything with a strong password. If storing on paper, do not show the wallet to anyone else who can memorize your 25 word key, or take a picture of the wallet without your permission. Sending someone a picture of the wallet is the same as giving away all of your funds. + +Whichever method you chose, be sure there's no copy of the Monero wallet left over on the device you used. You may need to securely delete the Monero wallet if you saved it to a disk, or make sure your printer does not save a copy in memory. + +*If you lose access to your Monero paper wallet the Monero will not be available to you or anyone else, ever. You wont be able to recover them! + +#### Side Note +Option to encrypt an XMR mnemonic seed: +https://xmr.llcoins.net/ +Download the html page and place it on your airgapped computer. Check the part "Encrypt/Decrypt Mnemonic Seed" and make sure you use "CN Add" with a decent password. Thanks manicminer5. + + + +#### Step 3: Convert your Bitcoin to Monero and have it sent to your Monero Paper Wallet + +Switch to your internet connected computer and go to www.shapeshift.io. Choose "Deposit Bitcoin" and "Receive Monero" (quick). + +Press Continue. + +Your Monero Address (the Monero Public Address on your Monero Paper Wallet) +Paste the Monero Public address from your paper wallet where it says "Your Monero Address". But wait, since your Monero Public Address is on an airgapped computer (right?), you can't copy and paste anything... Copy it over by hand, or get a blank USB drive and copy only the Public Address to it. + +Refund Address (Bitcoin Public Address you can receive funds at) +Enter a Bitcoin address that you control where a refund can be sent in case there's a problem with the transaction. It's very important that you enter a Bitcoin Public Address you control or can receive funds at. At Xapo and Coinbase this is called a Receive Address and it may change periodically. + +Payment ID +Leave Payment ID blank if you are sending to your own Monero wallet or Monero paper wallet. + +Agree to the Terms and hit the slider to make this a "Reusable Address". + +Press "Start Transaction". + +Deposit Address (Shapeshift.io's Public Bitcoin Address created only to receive your funds) +In the new screen that pops up, copy the Deposit Address into your clipboard (select and hit ctrl+c or edit-copy). You will send Bitcoin from Xapo/Coinbase to Shapeshift.io via this address. + +Go to your Xapo or Circle account, and find a Transfer or Send button. Paste the Bitcoin Deposit address into the Destination field and enter the amount of bitcoin you would like to have converted to Monero. It must be within the Deposit Min and Deposit Max range specified by Shapeshift.io. Press Send and authorize the transaction, if required. + +Once the send has been initiated by Xapo/Coinbase there will be a delay while the transaction enters the Bitcoin blockchain and awaits confirmation. This may be minutes or hours. You can check if the payment has been sent by looking up the Shapeshift.io Deposit address at blockchain.info. Your transaction to Shapeshift.io will show up there. + +When your Bitcoin transaction has been confirmed, Shapeshift.io will then begin exchanging Bitcoin (BTC) for Monero (XMR) at one of the exchanges and when it's complete, send the Monero to the address of your Cold Storage Paper Wallet! This can take minutes to hours. If there's an issue, contact Shapeshift.io. They have good support. + +When the Shapehift.io webpage says your transaction has been completed, you should now have Monero in your Paper Wallet! + + +#### Notes and How to Verify Funds +Because the Monero blockchain is private and untraceable, you won't be able to lookup your Monero Public Address and confirm that the funds have arrived like you might with Bitcoin. This is good for privacy, but bad for convenience. + +To securely verify the funds have arrived at your wallet, you will need to setup a View Only wallet. This is where that view-key comes in. To create a view-only wallet see the entry: @view-only + +To verify the funds are *still in* your wallet and have not been spent you need to create a Cold Wallet with your mnemonic key (all your funds) on an airgapped computer with an up-to-date copy of the Monero Blockchain. When finished you will have to securely erase the wallet or connect it to the internet and it becomes a Hot Wallet. + + + diff --git a/resources/user-guides/view_only.md b/resources/user-guides/view_only.md new file mode 100644 index 00000000..53dc6a67 --- /dev/null +++ b/resources/user-guides/view_only.md @@ -0,0 +1,23 @@ +--- +layout: static_page +title: "View Only Wallets" +title-pre-kick: "Creating a view only wallet " +title-kick: "" +title-post-kick: "" +kick-class: "" +icon: "icon_userguides" +attribution: "" +--- + +A view-only wallet can only see which incoming transactions belong to you. It can not spend any of your Monero, in fact it can't even see outgoing transactions from this wallet. This makes view-only wallets particularly interesting for + +* Developers writing libraries to validate payments +* End users validating incoming transactions to cold wallets + +### Creating A View-Only Wallet + +You can create a view-only wallet from any existing wallet. + +Open an existing wallet or create a new one using `monero-wallet-cli`. In the wallet, type `address` and `viewkey` to display the wallet's address and secret viewkey. Type `exit` to close the wallet. + +Next, create your view-only wallet by typing `monero-wallet-cli --generate-from-view-key wallet-name`. The last argument will be your new wallet's file name. You will be prompted for `Standard address` and `View key` by the wallet. Paste in your original wallet's address and secret view key. Next, enter and confirm a password for your new wallet and you're done. diff --git a/resources/user-guides/vps_run_node.md b/resources/user-guides/vps_run_node.md new file mode 100644 index 00000000..bb03191c --- /dev/null +++ b/resources/user-guides/vps_run_node.md @@ -0,0 +1,57 @@ +--- +layout: static_page +title: "Monero tools" +title-pre-kick: "Monero tools " +title-kick: "for the network " +title-post-kick: "" +kick-class: "purple-kicks" +icon: "icon_userguides" +attribution: "" +--- +# monerod + +`monerod` is the daemon software that ships with the Monero tree. It is a console program, and manages the blockchain. While a bitcoin wallet manages both an account and the blockchain, Monero separates these: `monerod` handles the blockchain, and `monero-wallet-cli` handles the account. + +This guide assumes you have already set up your VPS account and are using SSH to tunnel into the server console. + +## Linux, 64-bit (Ubuntu 16.04 LTS) + +### Make sure that port 18080 is open +`monerod` uses this port to communicate with other nodes on the Monero network. + +Example if using `ufw`: `sudo ufw allow 18080` +Example if using `iptables`: `sudo iptables -A INPUT -p tcp --dport 18080 -j ACCEPT` + +### Download the current Monero Core binaries + + wget https://downloads.getmonero.org/linux64 + +### Make a directory and extract the files. + + mkdir monero + tar -xjvf linux64 -C monero + +### Launch the daemon + + cd monero + ./monerod + +### Options: + +Show list of all options and settings: + + ./monerod --help + +Launch the daemon as a background process: + + ./monerod --detach + +Monitor the output of `monerod` if running as daemon: + + tail -f ~/.bitmonero/bitmonero.log + +Keep the VPS secure with autoupdate: + +https://help.ubuntu.com/community/AutomaticSecurityUpdates + + diff --git a/the-monero-project/index.md b/the-monero-project/index.md new file mode 100644 index 00000000..4124a455 --- /dev/null +++ b/the-monero-project/index.md @@ -0,0 +1,49 @@ +--- +layout: default +title: "The Monero Project" +--- + +
    +
    +
    +
    +
    +
    +
    +

    Kovri

    +
    +
    +
    + +The Kovri project uses end-to-end encryption so that neither the sender nor receiver of a Monero transaction need to reveal their IP address to the other side or to third-party observers (the blockchain). This is done using the same technology that powers the dark net, i2p (Invisible Internet Protocol). The project is currently in heavy, active development and is not yet integrated with Monero. + +
    +
    +

    Visit Kovri Website

    +
    +
    +
    +
    +
    +
    +
    +

    Open Alias

    +
    +
    +
    + +The OpenAlias project simplifies cryptocurrency payments by providing FQDNs (Fully Qualified Domain Names, i.e. example.openalias.org) for Monero wallet addresses in a way that ensures everyone's privacy is secure. The project is well underway and has already been implemented in many Monero wallets. + + + +
    + +
    +

    Visit OpenAlias Website

    +
    + +
    +
    +
    +
    +
    \ No newline at end of file