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

Merge pull request #2 from monero-project/master

Browse Source 
Update to current
This commit is contained in:
jw 2017-01-07 06:26:20 -08:00 committed by GitHub
commit f90dc67df4
118 changed files with 10636 additions and 297 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
README.md
View File

@ -31,6 +31,14 @@ Deploying this website requires Jekyll (3.0+) and the following ruby gems: build
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-2016, The Monero Project

18
_data/donators.yml
View File

@ -12,7 +12,7 @@
- level: 9
name: ajiekceu4
amount: 10666
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
@ -105,6 +105,7 @@
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
@ -231,6 +232,11 @@
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
@ -276,6 +282,11 @@
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
@ -410,3 +421,8 @@
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]

54
_data/downloads.yml
View File

@ -1,51 +1,59 @@
- platform: Windows, 64-bit
icon: windows.svg
url: win64
hash: 303840d7fb997b2f1efc280fd19ba84003ecff85
version: 0.9.1.0
tag: Hydrogen Helix
hash: 727a53dd154b61fd653f81da27788077fdf519301c81d3c1eb033c1ff2bf97c6
version: 0.10.1.0
tag: Wolfram Warptangent
blockchain: win
- platform: Windows, 32-bit
icon: windows.svg
url: win32
hash: none
version: 0.9.1.0
tag: Hydrogen Helix
hash: ce77137b33bcaeb59273cb73b86e426e35e6209fb52a7e74fd9432a5a3018041
version: 0.10.1.0
tag: Wolfram Warptangent
blockchain: win
- platform: Mac OS X, 64-bit
icon: apple.svg
url: mac64
hash: d6c776878fd3d47f149fc9be4e76cf2d03d5a725
version: 0.9.1.0
tag: Hydrogen Helix
hash: 447cebae257864b3706a8622f495bfd9fae780a6b277e1e31ac83bef7bc855c6
version: 0.10.1.0
tag: Wolfram Warptangent
blockchain: mac
- platform: Linux, 64-bit
icon: linux.svg
url: linux64
hash: 4149de91c10b56ff091070acca80d233fbd5a797
version: 0.9.1.0
tag: Hydrogen Helix
hash: bf09eea27c957e7e2bdd62dac250888b301d4d25abe18d4a5b930fa7477708c7
version: 0.10.1.0
tag: Wolfram Warptangent
blockchain: linux
- platform: Linux, 32-bit
icon: linux.svg
url: linux32
hash: 9a18d274970df85d6bc926dc99407959c680c36f19017996be9c758f6c02cf06
version: 0.10.1.0
tag: Wolfram Warptangent
blockchain: linux
- platform: ARMv7
icon: arm.svg
url: arm
hash: 57221605997a3cd815f2a9689486abbdb124263fff047ca61068900eb7cb1839
version: 0.10.1.0
tag: Wolfram Warptangent
blockchain: arm
- platform: FreeBSD, 64-bit
icon: freebsd.svg
url: freebsd64
hash: 9fd0005b697e146a26a0bf9e3cd0c89b978f7fbd
version: 0.8.8.6
tag: Release
hash: 3858d4786b65a37e981b142e9c0f256ac66662314794d05f595c4c30cb5b6ddb
version: 0.10.1.0
tag: Wolfram Warptangent
blockchain: freebsd
- platform: Raspberry Pi / ARM
icon: arm.svg
url: arm
hash: none
version: 0.9.1.0
tag: Hydrogen Helix
blockchain: arm
- platform: Source Code
icon: github.svg
url: https://github.com/monero-project/bitmonero

62
_data/merchants.yml
View File

@ -2,26 +2,58 @@
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/
- 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: Moneroworld Blockchain Explorer
url: http://explore.moneroworld.com/
- category: Payment Gateways
merchants:
- 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: pymonero (Python)
url: https://github.com/Monero-Monitor/pymonero
- name: moneronjs (NodeJS)
url: https://github.com/netmonk/moneronjs
- name: MoneroApi.Net (.NET)
@ -30,8 +62,12 @@
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
@ -42,22 +78,44 @@
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: 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: CryptoEscrow Escrow Service
url: http://www.cryptoescrow.eu
- 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: Web Developer - Stefanos
url: http://www.stefanosioannou.com/web-development-monero-accepted
- name: XMR.link OpenAlias Registry
url: https://www.xmr.link/
- name: XMR.to Monero to Bitcoin Payment Service
url: https://xmr.to
- 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/
- category: Entertainment
merchants:
- name: Crypto Kingdom
@ -65,4 +123,6 @@
- name: MoneroDice
url: https://monerodice.net
- name: SafeDice
url: https://safedice.com
url: https://safedice.com
- name: Crypto Games
url: https://www.crypto-games.net/

5
_data/tags.yml
View File

@ -22,7 +22,7 @@
- slug: i2p
name: i2p
- slug: i2p
- slug: i8n
name: Internationalisation
- slug: rpc
@ -72,3 +72,6 @@
- slug: 0mq
name: ZeroMQ
- slug: releases
name: Monero Software Releases

3
_includes/footer.html
View File

@ -2,6 +2,7 @@
<div class="container">
<p>
<strong style="color: #ffffff;">[ <a href="/legal/terms">{% t global.terms %}</a> | <a href="/legal/privacy">{% t global.privacy %}</a> | <a href="/legal/copyright">{% t global.copyright %}</a> ]</strong>
<strong style="color: #ffffff;">[ <a href="https://github.com/monero-project/monero-site/edit/master/{{ page.path }}">{%t global.edit %}</a> ]</strong>
<a href="https://getmonero.org/feed.xml"><i class="fa fa-2x fa-rss-square"></i></a>
<a href="mailto:dev@getmonero.org"><i class="fa fa-2x fa-envelope-square"></i></a>
</p>
@ -13,7 +14,7 @@
<script src="//static.getmonero.org/scripts.js"></script>
<script type="text/javascript">
$(document).ready(function(){
$('[data-toggle="tooltip"]').tooltip();
$('[data-toggle="tooltip"]').tooltip();
});
(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){

8
_includes/header.html
View File

@ -25,6 +25,7 @@
<ul class="dropdown-menu" role="menu">
<li><a href="/getting-started/choose">{% t menu.choose %}</a></li>
<li><a href="/getting-started/running">{% t menu.running %}</a></li>
<li><a href="/getting-started/contribute">{% t menu.contribute %}</a></li>
<li><a href="/getting-started/donate">{% t menu.donations %}</a></li>
<li class="divider"></li>
<li><a href="/downloads">{% t menu.downloads %}</a></li>
@ -54,8 +55,13 @@
<ul class="dropdown-menu" role="menu">
<li><a href="https://forum.getmonero.org">{% t menu.forum %}</a></li>
<li><a href="https://www.reddit.com/r/monero/">{% t menu.reddit %}</a></li>
<li><a href="https://monero.stackexchange.com">{% t menu.stackexchange %}</a></li>
<li><a href="https://bitcointalk.org/index.php?topic=583449.0">{% t menu.bitcointalk %}</a></li>
<li class="divider"></li>
<li><a href="https://monero.slack.com/">{% t menu.slack %}</a></li>
<li><a href="https://rocket.xmrnation.com/">{% t menu.rocketchat %}</a></li>
<li><a href="https://telegram.me/bitmonero">{% t menu.telegram %}</a></li>
<li class="divider"></li>
<li class="dropdown-header">{% t menu.irc %}</li>
<li><a href="irc://chat.freenode.net/#monero">{% t menu.irc-general %}</a></li>
<li><a href="irc://chat.freenode.net/#monero-dev">{% t menu.irc-development %}</a></li>
@ -67,4 +73,4 @@
</ul>
</div>
</div>
</div>
</div>

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

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

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

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

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

@ -10,7 +10,44 @@ author: gingeropolous
# Summary
Work-in-progress by gingeropolous
## Review
Lots of stuff done in the past 2 weeks:
- v2 block tests
- flattened CMake issues (DNSSEC will work again)
- the possibilities of inconstent database state and the mempool transactions "have been clobbered"
Amongst other stuff not mentioned, but copying here from moneromoos milestone work:
- fixes for the wallet creating txes over max size the daemon will accept
- more work on tests (including tests for the MRL-0004 changes)
- going through all the V1/V2 stuff to catch what I saw was wrong
- fix for txes not expiring from pool due to other nodes coming online regularly
- better handling of pending/failed txes in simplewallet
- new command/RPC to flush txes from the txpool
- preventing two daemons from using the same data dir concurrently
- more intelligent handling against duplicate outs
## RingCT
Shen is almost done with reference code, volunteers needed to actually implement. warptangent takes on the db stuff.
https://github.com/ShenNoether/MiniNero/tree/master/brief
When RingCT gets merged, will be a good time to merge other database formats. DB format changes - build a converter that "upgrades" format changes. It's left open, but hyc agrees to tackle it later.
## Dev Branch
This has become the bastard child of Monero development apparently. Lines 82 - 167 encompass discussion on this topic. The goal is "to merge back to the dev branch" Ultimately the decision is to hack at it for a bit and reevalauate in next meeting.
> <moneromooo> What I'll do it hack at it to make it work better, really. All that's needed is time without the problem of a release coming too quick.
Godspeed moneromooo.
## Hardforks
The next fork (RingCT) will be the last time any modifications of the hardfork schedule are permitted.
# Logs

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

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

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

@ -0,0 +1,342 @@
---
layout: post
title: Overview and Logs for the Dev Meeting Held on 2016-03-19
summary: Open PRs, GUI commits, app/add-on infrastructure, versioning
tags: [dev diaries, core, crypto]
author: dEBRUYNE / fluffypony
---
*March 19th, 2016*
# Logs
**\<dEBRUYNE>** dev meeting in 5 min, FYI
**\<hyc>** dingdong
**\<gingeropolous>** hello
**\<dEBRUYNE>** fluffypony, smooth, othe, ArticMine, luigiw, NoodleDoodle, tewinget, moneromooo
**\<floofypony>** there we go
**\<dEBRUYNE>** did I forget anyone?
**\<tewinget>** oh, hello
**\<luigi>** is warptangent around?
**\<ArticMine>** Hello
**\<hyc>** he's been fighting a flu last we heard
**\<moneromooo>** hi
**\<NoodleDoodle>** Hello. I'm here but I'm fighting the apocalypse.
**\<NoodleDoodle>** of flus.
**\<luigi>** keep doing it
**\<luigi>** wait you're alive that's good to hear
**\<dEBRUYNE>** fluffypony seems ded
**\<fluffypony>** sorry
**\<fluffypony>** was eating
**\<fluffypony>** welcome everyone
**\<fluffypony>** so as you know we pushed out 0.9.2
**\<fluffypony>** however, there are some nagging issues from the ReadTXN work
**\<fluffypony>** hyc has nailed a major one as of a few hours ago
**\<fluffypony>** so we'll probably do a point release on Monday or so
**\<fluffypony>** also that means that the way we use LMDB has changed a bit
**\<fluffypony>** hyc can you tell us briefly how we should wrapping access to LMDB, both read and write operations?
**\<hyc>** Are you talking about the CRITICAL\_REGION stuff?
**\<fluffypony>** yes, and the cursors vs. txns stuff
**\<hyc>** ok, the critical\_region stuff actually is not a change at all.
**\<hyc>** basically, when you're setting up to do a write, you need exclusive access to the DB
**\<hyc>** this appears to have been a long-standing bug, unrelated to the readtxn changes
**\<hyc>** so as for reads - there is now a long-lived read txn per thread
**\<hyc>** and a set of read cursors to go with each
**\<hyc>** the TXN\_PREFIX\_RDONLY macro sets that up in a particular function, grabbing the thread-local-storage for it
**\<hyc>** and RCURSOR(dbname) sets up a read cursor for a particular DB
**\<hyc>** these are analogous to the CURSOR(dbname) macro for getting a write cursor to a DB
**\<hyc>** the point of all this is to avoid a bunch of malloc/free/seek when accessing a DB
**\<hyc>** the old code was allocating a readtxn and cursors inside each function
**\<hyc>** likewise for writes
**\<hyc>** by reusing the same cursors acros a set oof functions we get a pretty good performance gain
**\<hyc>** ok?
**\<fluffypony>** neat
**\<fluffypony>** also on the topic of stuff-hyc-did-lately
**\<fluffypony>** if anyone missed it, we now have a win environment guide up on forum.getmonero.org
**\<dEBRUYNE>** ^ https//forum.getmonero.org/5/support//building-monero-v0-9-2-on-winMonero
**\<fluffypony>** so that should get us all on the same page with testing etc.
**\<hyc>** and one success story replied to it already ;)
**\<fluffypony>** we've also dropped support for BDB as the default database, and switched to LMDB as the default
**\<fluffypony>** including on -bit and ARM
**\<fluffypony>** BDB will remain supported for the moment, primarily as a mechanism for contributors to understand how to build out DB support
**\<fluffypony>** krongle)
**\<fluffypony>** shew we have the entire xmr.to team here today, that's awesome
**\<binaryFate>** fluffypony good memory P
**\<fluffypony>** we shared a podcast together, binaryFate -P
**\<krongle>** yes - impressive nick-name recollection
**\<fluffypony>** hah hah
**\<fluffypony>** while we have you guys here, are you guys doing anything cool you want to talk about?
**\<binaryFate>** we're doing many cool things, but nothing we can talk about at this stage
**\<fluffypony>** hah hah
**\<fluffypony>** it does lead to an interesting point of conversation
**\<binaryFate>** seriously considering btc -> xmr direction
**\<fluffypony>** plugins
**\<iam6yearsold>** If NobleSir or xmr.to team could talk more about xmr.to integration at MiniNero that would be great.... also are 2 way conversions coming to xmr.to soon?
**\<fluffypony>** iam6yearsold Shen's offline at the moment, I'll ask him to update the Reddit thread with some info )
**\<fluffypony>** re plugins, we've spoken briefly about options for the GUI
**\<dEBRUYNE>** iam6yearsold There is a bit of info here -> https//imgur.com/a/HZL7k
**\<binaryFate>** iam6yearsold for MiniNero integration you'd have to see with NobleSir. The API doc is at http//xmrto-api.readthedocs.org/en/latest/
**\<fluffypony>** but I guess we could have "plugins", of a sort, that add functionality
**\<fluffypony>** like xmr.to or shapeshift integration right in wallet2 / wallet2\_api
**\<dEBRUYNE>** I think we should be fairly strict on which plugins to allow
**\<binaryFate>** fluffypony we wanted to discuss that plugin integration soon in fact )
**\<arnuschky>** we're quite interested to all secondary questions related to plugins
**\<fluffypony>** I guess the major question becomes
**\<arnuschky>** so plugin repository/db, packaging, distribution etc
**\<fluffypony>** do we allow "permissionless" plugin development, or do we just have a central repo that we git submodule in?
**\<ArticMine>** The main question I see with plugins is trust
**\<fluffypony>** ArticMine exactly
**\<arnuschky>** yes. It puts quite a bit responsibility on the dev team
**\<gingeropolous>** well no ones going to trust anything that doesn;t come from core
**\<tewinget>** \<fluffypony> we shared a podcast together, binaryFate -P <-- wasn't I there for that?
**\<fluffypony>** considering the recent Google Chrome Bitcoin stealing malware I think that premissionless plugins are dangerous
**\<gingeropolous>** as we've seen with 3rd party GUIs
**\<luigi>** you obviously can't stop permissionless dev, you can discourage users from trusting it I guess
**\<hyc>** we can start signing binaries, ohjoy
**\<dEBRUYNE>** I would prefer the latter
**\<fluffypony>** luigi I mean permissionless within core
**\<luigi>** oh
**\<luigi>** I think no
**\<arnuschky>** it's related to how plugins are written. If it's binary blobs, it's a) hard to build, distribute etc, and b) hard to examine
**\<binaryFate>** fluffypony I'd see both possible all together. Unpermissioned scale and central repo for a selected subset would ease experience and trust for user
**\<arnuschky>** so if plugins are interpreted (eg python), things become a whole lot easier
**\<iam6yearsold>** for the record I hated the twittter plugin idea I saw a while back
**\<ArticMine>** My take permissionless has to be allowed. The end user has to be made aware who is signing and if to trust the plugin
**\<fluffypony>** well the Electrum model works well
**\<moneromooo>** I agree with ArticMine
**\<arnuschky>** (inspection in case of central repo, but also self-distribution by plugin devs)
**\<fluffypony>** ThomasV will merge basically any plugin, as long as it's not malicious
**\<fluffypony>** and plugins are part of the core code, effectively just in a subfolder
**\<fluffypony>** I think it's a testament to Electrum that they haven't had a malicious plugin ever
**\<arnuschky>** how do they deal with the upgrade/maintenance workload? Or do they just disable broken plugins?
**\<dEBRUYNE>** Is there a way to make a subfolder in the subfolder? i.e. (1) signed and approved by core-team, (2) optional
**\<fluffypony>** arnuschky yeah they just disable broken plugins, and eventually they get deprecated out
**\<ArticMine>** We should allow self distribution with appropriate warning
**\<fluffypony>** ArticMine anyone can compile their own build, which would be the same thing
**\<arnuschky>** are you planning for compiled plugins or interpreted ones? that's quite a differens IMHO
**\<fluffypony>** arnuschky so
**\<arnuschky>** self-distribution is a mess for compiled ones...
**\<fluffypony>** I was thinking we have a repo, say it's called monero-plugins
**\<arnuschky>** audit as well
**\<fluffypony>** and then anyone can PR to that repo
**\<fluffypony>** and that repo is pulled into the main Monero source as a git submodule
**\<fluffypony>** there are two advantages to this
**\<fluffypony>** 1. as it gets bigger and harder to deal with, we can step back and other known members of the community can manage that repo
**\<fluffypony>** 2. if we come up with a standard set of functionality hooks, then other projects can pull that same repo in
**\<fluffypony>** eg. jwinterm's lightwallet
**\<fluffypony>** also it means that the compiled Monero binaries have those plugins baked in, and you can't add extra plugins post-compile
**\<fluffypony>** so no need to deal with interpreted code and securing that on disk and in memory
**\<hyc>** baked in means no dynamic loading?
**\<tewinget>** \<fluffypony> so no need to deal with interpreted code and securing that on disk <-- if securing an interpreted plugin on disk became an issue, securing the binary would be an issue anyway, so I don't know of that bit matters
**\<binaryFate>** Sounds all good to us. If distribution is done through official channels it's great.
**\<fluffypony>** hyc yes
**\<fluffypony>** no dynamic loading
**\<hyc>** cool
**\<fluffypony>** tewinget I mean we can't secure it in the path from random-site-on-the-web down to random-download-folder and eventually into secure-disk-location
**\<arnuschky>** fluffypony that would be really great.
**\<fluffypony>** ok - I think next steps would be to consider some of the hooks we need to provide to add functionality
**\<fluffypony>** we can use the Monero wikia as a collaboration area for that
**\<ArticMine>** It is a good balance for plugins
**\<fluffypony>** and then we'll just update the Monero Slack
**\<arnuschky>** well securing the plugins can always happen by signature - no matter if interpreted or binary
**\<fluffypony>** I'm kidding, we don't have a Slack
**\<fluffypony>** we're not that cool
**\<aerbax>** Would these plugins allow for interpreted languages like Lua or Python?
**\<arnuschky>** :)
**\<fluffypony>** aerbax I don't see why not, individual CMake files in each plugin folder that allow it to produce a library fix everything
**\<binaryFate>** We could financially support development of plugin architecture if xmr.to is the first instanciation of those plugins.
**\<fluffypony>** if it spits out a .so / .a / .dll with the right hooks then it's fine
**\<tewinget>** fluffypony> tewinget I mean we can't secure it in the path from random-site-on-the-web down to random-download-folder and eventually into secure-disk-location <-- and yet, we provide binary downloads...so "random site on the web" could be managed the same as said binary downloads
**\<tewinget>** just like any random site on the web can offer binaries for download and we can't secure that either
**\<tewinget>** caveat emptor has to come into play at some point, I think
**\<fluffypony>** the binaries present a single attack surface, and there's GPG-signed hashes
**\<fluffypony>** if we have to do GPG-signed hashes for a bunch of .py files I think I'll go mad -P
**\<tewinget>** I'm not saying I think it should be one way or another, I'm merely pointing out flaws in your argument P
**\<fluffypony>** fair enough
**\<fluffypony>** binaryFate I think the stumbling block will be that somebody needs to champion this and run with it, and I won't be able to lead it due to travelling in a week
**\<ArticMine>** As long as people can compile their own version with non permissioned plugins this can work
**\<luigi>** they can always do that
**\<fluffypony>** yep
**\<fluffypony>** and in fact that would be the testing model
**\<luigi>** we're not apple )
**\<fluffypony>** fork the repo, and build a binary to test your new plugin
**\<iam6yearsold>** asking noobs to compile will limit adoption
**\<ArticMine>** luigi Exactly
**\<fluffypony>** iam6yearsold why would noobs be writing their own plugins?
**\<gingeropolous>** for security
**\<dEBRUYNE>** lol gingeropolous
**\<fluffypony>** lol
**\<arnuschky>** fluffypony championing the first plugin or the whole infrastructure?
**\<tewinget>** What about a curated repo of plugins (as suggested) but with those plugins written in python/lua? Someone modifying the python/lua on a target's disk is the same as someone modifying the binary anyway, and python/lua plugins would be far easier to develop and audit I think
**\<fluffypony>** arnuschky championing the design, I guess
**\<arnuschky>** tewinget I would prefer that.
**\<iam6yearsold>** how about 1 version with binaries and gpg sig and no plugins? caveat emptor for the rest
**\<arnuschky>** mostly due to auditing, and there's no build/distribution mess attached
**\<fluffypony>** I would prefer we remain language agnostic
**\<fluffypony>** iam6yearsold that's what we already have
**\<tewinget>** fluffypony language-agnostic is fine, but...well, how do you imagine that will work out?
**\<iam6yearsold>** thanks pony. I like the current situation then
**\<fluffypony>** tewinget read up
**\<arnuschky>** ah even language agnostic. I thought up to now it's supposed to be a C++ only API
**\<tewinget>** as in, how do we become language-agnostic so that we can remain so?
**\<fluffypony>** [] \<aerbax> Would these plugins allow for interpreted languages like Lua or Python?
**\<fluffypony>** [] \<fluffypony> aerbax I don't see why not, individual CMake files in each plugin folder that allow it to produce a library fix everything
**\<fluffypony>** ^^
**\* smooth** is here
**\<fluffypony>** also what if a plugin wants to call a function in the core crypto library, for instance?
**\<arnuschky>** design-wise, that's sounds like a nightmare, no?
**\<moneromooo>** Oh, so linked directly ? I kinda assumed it was gointg to be RPC based.
**\<fluffypony>** ok well I think we're getting into an implementation discussion that's outside of the scope of this meeting
**\<arnuschky>** I mean, if you don't have a small and defined API, every bigger change in the wallet will break plugins
**\<arnuschky>** true )
**\<fluffypony>** after the dev meeting we can continue this conversation if you guys want
**\<fluffypony>** but let's first circle back around
**\<luigi>** this deserves some kind of design thread like ringct imo
**\<moneromooo>** Oh, link ?
**\<fluffypony>** moneromooo: "this deserves"
**\<fluffypony>** so nothing yet
**\<moneromooo>** "like ringct"
**\<fluffypony>** oh
**\<fluffypony>** I see what you were asking
**\<luigi>** oh
**\<moneromooo>** Oh
**\<fluffypony>** OH
**\<luigi>** "like ringct is supposed to get"
**\<moneromooo>** Fair enough.
**\<fluffypony>** so basically this is all luigi's fault
**\<luigi>** warp was gonna go it!@
**\<gingeropolous>** its true. i mis-called out luigi on that one
**\<fluffypony>** warptangent is off sick at the moment
**\<luigi>** yes
**\<luigi>** so I blame that
**\<fluffypony>** I blame Canada
**\<fluffypony>** ok back on track
**\<fluffypony>** since the last meeting the bulk of the PRs have been bug fixes
**\<fluffypony>** and changes to the way we access the DB as discussed at the beginning
**\<fluffypony>** we also had a huge discussion about how to handle mixins below the minimum in the RPC call
**\<fluffypony>** which was then implemented in #715
**\<fluffypony>** I'm also going to try to personally spend some time on the text that users see, things like the level 0 logging output and the CLI flag help
**\<luigi>** oh I was gonna do that
**\<luigi>** but then I didn't
**\<fluffypony>** luigi we can do it together
**\<luigi>** awwww
**\<fluffypony>** I can show you the world, shining shimmering splendid
**\<gingeropolous>** take you wonder by wonder
**\<fluffypony>** lol
**\<fluffypony>** also #728 was a little contentious
**\<fluffypony>** so we created a company called Mixinstream that has hired all the contributors
**\<palexander>** heh heh
**\<fluffypony>** and gingeropolous has launched Monero Classic
**\<gingeropolous>** ( sorry )
**\<fluffypony>** -P
**\<fluffypony>** ok so #728 is Ilya's work as part of the GUI effort
**\<dEBRUYNE>** Can I launch unlimited?
**\<fluffypony>** he was struggling with wallet2, and decided to break it out into something more logical and usable
**\<fluffypony>** (to him at any rate)
**\<ArticMine>** What makes it contentious?
**\<fluffypony>** ArticMine I'll get to that now
**\<fluffypony>** he's unintuitively called it wallet2\_api, which is a little confusing
**\<fluffypony>** but basically a lot of it is a wallet2\_api call which then does little additional logic, and mainly just passes stuff back to wallet2
**\<fluffypony>** and there's a lot of DRY-violating code because of it
**\<fluffypony>** obviously there was some push back, not to prevent merging it
**\<fluffypony>** but more to understand the thought process
**\<moneromooo>** Define DRY ?
**\<iam6yearsold>** DRY violating scares the shit out of me
**\<gingeropolous>** https//en.wikipedia.org/wiki/Don%t\_repeat\_yourself
**\<gingeropolous>** maybe
**\<fluffypony>** yes
**\<fluffypony>** iam6yearsold DRY violations are just where you have a piece of code in two places
**\<fluffypony>** so any changes have to happen in both
**\<fluffypony>** we can treat the DRY-violating code as a temporary issue, though
**\<iam6yearsold>** two places = more opportunity for error
**\<fluffypony>** as we're going to wait until Ilya is done with it
**\<ArticMine>** Which makes maintenance much harder
**\<fluffypony>** and then we'll either drop wallet2 and replace it with the new wallet API
**\<fluffypony>** (ie. replace the simplewallet calls as well)
**\<fluffypony>** or if it's just a pointless layer we'll have to go the opposite route
**\<fluffypony>** and change his Qt callers to use wallet2
**\<fluffypony>** as it stands it's kinda undecided and we'll have to see how Ilya goes
**\<ArticMine>** Is Ilya aware of the concern?
**\<fluffypony>** ArticMine yes, we had some discussion on the PR, and othe has also spoken to him afaik
**\<fluffypony>** he was responsive on the PR comments, but this isn't Bitcoin
**\<fluffypony>** we don't ACK NACK utACK for years before merging somethingm
**\<fluffypony>** aintnobodygottimeforthat.gif
**\<luigi>** utNACK
**\<fluffypony>** luigi #networknerd
**\<moneromooo>** utACK was not a typo ?
**\<luigi>** no
**\<luigi>** means untested
**\<luigi>** conceptACK or similar
**\<fluffypony>** yeah
**\<fluffypony>** moneromooo https//lists.linuxfoundation.org/pipermail/bitcoin-dev/-December/71.html
**\<fluffypony>** if you're interested
**\<hyc>** crap
**\<fluffypony>** LOL
**\<fluffypony>** PasteGate 2.0
**\<gingeropolous>** internets
**\<othe>** ur pasting skills suck
**\<dEBRUYNE>** Hahah
**\<fluffypony>** othe pasting is a scam
**\<hyc>** that's how I write all my patches
**\<fluffypony>** I just copy-and-paste code from StackExchange
**\<gingeropolous>** thats my job
**\<fluffypony>** heh
**\<fluffypony>** ok so anyone who can reproduce the 0.9.2 segfault please try latest master
**\<fluffypony>** and if you're still segfaulting let us know
**\<fluffypony>** else we're going to do a point release on Monday
**\<fluffypony>** 0.9.3, I guess?
**\<luigi>** hrm
**\<fluffypony>** or 0.9.2.1
**\<luigi>** we're gonna run out of numbers at this rate
**\<fluffypony>** yeah we are
**\<luigi>** oh wait
**\<hyc>** 0921
**\<luigi>** we have 0.10
**\<luigi>** nevermind
**\<iam6yearsold>** will there be multiple devs in IRC at time of hard fork this week just in case? I see a few pools still on old cold and probably a few users too
**\<fluffypony>** yes we just do a Bitcoin
**\<moneromooo>** No chance, there's an infinity of those.
**\<fluffypony>** 0.11
**\<fluffypony>** iam6yearsold yes, and we've reached out to as many of them as we can
**\<luigi>** is 0.10 supposed to be for next hard fork?
**\<fluffypony>** luigi fork that
**\<fluffypony>** when warptangent is back we'll see how it goes on ringCT
**\<fluffypony>** and make a more concrete decision as to the timing of the next fork
**\<dEBRUYNE>** iam6yearsold The hardfork will approximately take place at 13:00 UTC, so both US and Europe will probably be awake
**\<dEBRUYNE>** and Asia of course
**\<luigi>** everyone will be awake
**\<fluffypony>** even me
**\<dEBRUYNE>** hawaii will probably be asleep
**\<dEBRUYNE>** -P
**\<fluffypony>** heh
**\<dEBRUYNE>** fwiw!
**\<luigi>** wat
**\<Wolf\`>** lol
**\<smooth>** we should also consider what else we should go in the next major version besides ringct (doesn't need to be discussed now)
**\<dEBRUYNE>** uh I meant UTC btw
**\<dEBRUYNE>** you muricans with AM/PM
**\<Wolf\`>** who got drunk and posted about a party in #monero-dev
**\<luigi>** oh
**\<luigi>** then america won't be up
**\<moneromooo>** The db reorg seems like a good candidate.
**\<luigi>** oh well
**\<fluffypony>** smooth agreed
**\<dEBRUYNE>** east coast will right?
**\<luigi>** sure ish
**\<dEBRUYNE>** You better set your alarm luigi
**\<dEBRUYNE>** :-P
**\<fluffypony>** Surae is also going to be picking up MRL-6 in the summer
**\<fluffypony>** he has some ideas about how to complete that
**\<dEBRUYNE>** MRL-6 is multisig?
**\<iam6yearsold>** I will party hard if fork happens with no drama
**\<fluffypony>** dEBRUYNE: no
**\<fluffypony>** https//github.com/monero-project/research-lab/tree/master/publications/MRL-%-%Difficulty%Adjustment%Algorithms%in%Cryptocurrency%Protocols
**\<dEBRUYNE>** oh cool, thanks
**\<moneromooo>** How do get cmake to tell you the commands it's running ?
**\<luigi>** we have diff, we have db stuff, we have fee stuff
**\<fluffypony**> moneromooo: I normally make VERBOSE=1
**\<moneromooo>** Thanks, I was trying V=1
**\<luigi>** I like my V=2
**\<fluffypony>** ok - any last things to add
**\<fluffypony>** or can we call it?
**\<luigi>** call it

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

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

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

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

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

@ -0,0 +1,219 @@
---
layout: post
title: Overview and Logs for the Dev Meeting Held on 2016-04-24
summary: A review and discussion of open PRs, moving forward with Ring CT
tags: [dev diaries, core, crypto]
author: dEBRUYNE / fluffypony
---
*April 24th, 2016*
# Logs
**\<hyc>** hey what's on our agenda for today anyway
**\<hyc>** slideshow from fluffypony's trip to Asia?
**\<dEBRUYNE>** we could do that :D
**\<dEBRUYNE>** hyc: More seriously, I suppose some Ring CT stuff + something about the performance branch
**\<fluffypony>** lol
**\<dEBRUYNE>** hyc: Plus I think there are still some PRs open for review
**\<hyc>** sounds good. looking at NobleSir's DB schema, doesn't seem like there's much new needed on the DB side of things
**\<dEBRUYNE>** hyc, fluffypony: I could make a list of which PRs are still open for review if you want?
**\<hyc>** 13 open right now
**\<dEBRUYNE>** all right
**\<hyc>** moneromooo already reviewed PR#806
**\<dEBRUYNE>** Oh yeah this is easier to spot -> https://github.com/monero-project/bitmonero/pulls
**\<dEBRUYNE>** :-P
**\<hyc>** yep
**\<dEBRUYNE>** smooth and moneromooo had a little chat about 818 & 819 earlier today
**\<hyc>** I've browsed thru them but frankly don't know enough about how things work to know their implications
**\<moneromooo>** I felt like that abour your/warp's DB perf branch :P
**\<hyc>** ;)
**\<hyc>** looking at git history I'd guess tewinget or NoodleDoodle would have breezed thru them
**\<fluffypony>** hokay
**\<fluffypony>** t -1 hour
**\<dEBRUYNE>** t -5 min
**\<ArticMine>** hello
**\<JonathanD_>** hi
**\<hyc>** hola
**\<smooth>** bonjour
**\<xmrpromotions>** bonjour
**\<fluffypony>** Comment allez-vous ?
**\<fluffypony>** la réunion d'aujourd'hui aura lieu en français
**\<bigreddmachine>** laissez les bon temps rouler
**\<fluffypony>** lol
**\<xmrpromotions>** Konnichiwa
**\<fluffypony>** ok so
**\<fluffypony>** welcome to the dev meeting
**\<fluffypony>** after a brief intermission we're back on every 2 weeks
**\<luigi1112>** I'm here but not really
**\<fluffypony>** I've been trying to keep up whilst travelling, but there's some backlog I didn't read
**\<fluffypony>** I think before we discuss #805 and the performance PR, let's just touch base on the smaller ones
**\<fluffypony>** #810, #814, #818, all seem to have been reviewed and are ready for merge
**\<moneromooo>** smooth had reservations about 810.
**\<moneromooo>** Or hyc. Or both.
**\<fluffypony>** smooth / hyc: any new thoughts beyond the one comment on the PR?
**\<hyc>** both I think, but I don't remember smooth's comments
**\<moneromooo>** I think it was just extra complexity htat might not be worth it.
**\<hyc>** my point - the current pool code calls getblocktemplate 1/second but doesn't do anything with the response if the height is the same as before
**\<hyc>** the pool code ought to just call getblockcount in that case, which executes in 0ms
**\<dEBRUYNE>** smooth commented on #810 -> https://github.com/monero-project/bitmonero/pull/810
**\* DaveyJones**: quotes deBRUYNE from yesterday : dEBRUYNE pages othe, NoodleDoodle, smooth, tewinget, binaryFate
**\<fluffypony>** so then the pool code is bad, right ?
**\<hyc>** yeah, in my perspective anyway
**\<xmrpromotions>** No comment on the code for https://github.com/monero-project/bitmonero/pull/794 but is there some way we can reach out to the family of warptangent to let them know we are very greatful for his contributions?
**\<smooth>** i added a comment to 810
**\<dEBRUYNE>** ^ His dad commented in the thread
**\<fluffypony>** xmrpromotions: they're already speaking to us, and we've let them know
**\<dEBRUYNE>** but let's stick to -dev decisions for now
**\<smooth>** 818 i think needs review by a cryptographer before we release that feature
**\<fluffypony>** agreed
**\<smooth>** hyc> the pool code ought to just call getblockcount in that case <= this is incorrect as we discussed before, but not relevant to 810
**\<moneromooo>** getinfo returns top hash.
**\<moneromooo>** And seems fairly lightweight.
**\<smooth>** it should check the top block hash, not height, but in any case even calling getblocktemplate 1/second isn't obvious to me would be a performance issue at all
**\<moneromooo>** Maybe PCFiL can test. He reported high CPU use when there were like 15 txes in the pool, and calming down at ~3.
**\<moneromooo>** Or I could test it actually, just curl that URI.
**\<smooth>** maybe we should look at why it takes so long then. when happens when there are 500?
**\<hyc>** fair enough, re: getinfo. still, it seems like this cache should be unnecessary
**\<fluffypony>** we can pack a bunch of transactions into testnet's mempool to see
**\<smooth>** next topic?
**\<hyc>** sounds like a good plan. perf optimizations should always have before/after metrics.
**\<fluffypony>** 811 / 812 / 813, any thoughts or objections on them ?
**\<hyc>** 811 seems pretty straightforward
**\<hyc>** tho moneromooo mentioned that the test in question never actually gets run
**\<hyc>** anyway, compiling unit tests is broken without it, so 811 needs to go in
**\<fluffypony>** ok
**\<fluffypony>** 812 seems fine too
**\<smooth>** those all look fine, noting that the net code is a complete black box to me so i can't really have an opinion there
**\<fluffypony>** ok - has anyone tested 815?
**\<moneromooo>** Well, I did :)
**\<fluffypony>** lol
**\<fluffypony>** 816 is also pretty straightforward
**\<fluffypony>** I'll review 817 later when I'm merging
**\<fluffypony>** and 819 is obvious
**\<moneromooo>** 818 won't apply once 816 is merged (duplicate -8 new error code), I'll update once this is done.
**\<hyc>** yeah 816 looks fine
**\<fluffypony>** I wouldn't bother yet - wait until there's been an MRL review on 818, moneromooo
**\<moneromooo>** OK
**\<fluffypony>** 810 I'll hold off on and let it bounce around, final decision at the next meeting if not before
**\<fluffypony>** ok so 806, the PR that fixes issue 805 - any final thoughts on it or can I merge?
**\<hyc>** works for me ;)
**\<moneromooo>** Seems fine. I didn' try it though.
**\<hyc>** it will make starting up a new wallet less painful for new users
**\<fluffypony>** oh and then unwind, I forgot about that - moneromooo you commented today that you're going to do some more work on that, do you want to merge and then submit further PRs for improvement, or work off that PR?
**\<moneromooo>** Leave it out for now.
**\<fluffypony>** k
**\<fluffypony>** so then performance
**\<fluffypony>** are we going to merge it, or leave it for 0.10.0 ?
**\<hyc>** conclusion - migrating DB schema in-place is much slower than just export/reimport from scratch
**\<fluffypony>** hyc: yeah I know, the conversion tool was always horrendously slow by comparison
**\<smooth>** im not sure that invalidates it
**\<fluffypony>** but in-place migration has its place
**\<fluffypony>** eg. when running as a service
**\<smooth>** easy of use matters, and if advanced users want to do it faster they can use th etools
**\<fluffypony>** agreed
**\<smooth>** sync from scratch is an option too, if they dont care about bandwidth
**\<fluffypony>** I guess the overriding factor here is that we suck at communicating with the end users that are running nodes
**\<fluffypony>** the fork taught me that, at any rate, so we have to assume people won't be reading release notes
**\<hyc>** ok. but are they going to notice that their newly restarted server isn't talking to anyone on the network for 1+ hour?
**\<fluffypony>** I don't think they'll care if it's an unattended server
**\<fluffypony>** we do need a way to universally respond to RPC calls with an error that explains that it's busy and this is the conversion % or something
**\<hyc>** ok
**\<gingeropolous>** i guess the use case to consider is shapeshift
**\<fluffypony>** yeah
**\<moneromooo>** RPC calls that care about this do return busy.
**\<moneromooo>** If not, file a bug with details.
**\<fluffypony>** moneromooo: a conversion will lock almost everything out, though ?
**\<fluffypony>** except I guess blindly broadcasting transactions
**\<moneromooo>** Oh, nevermind.
**\<smooth>** even then it probably has to verify them
**\<fluffypony>** yeah so I think the entire RPC interface has to error with a status
**\<moneromooo>** I'm guessing the RPC server will not be up yet if it's converting the db.
**\<hyc>** yeah, the conversion is firing up from db open
**\<hyc>** I don't think anything else is up yet
**\<fluffypony>** ah point
**\<smooth>** whats the problem with refusing to start until they do something with their db?
**\<smooth>** i mean error out at startup, no conversion
**\<smooth>** you can either delete/rename it (and therefore resync) or convert it
**\<fluffypony>** smooth: because in background mode / windows service mode you won't know that it's dying
**\<smooth>** you'll know its not working, there must be some way to indicate a reason
**\<fluffypony>** so practically: I have Bitcoin and Monero on a Windows node
**\<smooth>** maybe leave a message file behind and the cli can report the message
**\<moneromooo>** system("xmessage \"help\"")
**\<fluffypony>** and at some point the Bitcoin DB got corrupted (multiple times)
**\<fluffypony>** I have the service set to restart on fail, and eventually restart the whole machine
**\<fluffypony>** so it was restarting the machine every 15 minutes, and since I was only using the Monero node on it I had no idea
**\<gingeropolous>** right, so the overarching question is monero's philosophy on un-managed nodes
**\<gingeropolous>** (perhaps)
**\<hyc>** if truly no one is monitoring, then the daemon can do its conversion in however many hours it takes and no one will be bothered
**\<hyc>** if anyone is doing a health check they're gonig to wonder why it's not responding
**\<hyc>** Aside from that I'd feel more comfortable if someone besides me has tested the current branch with migration happening
**\<fluffypony>** I will
**\<hyc>** we know the perf code itself, not counting the migrate bit, is working fine
**\<fluffypony>** hyc: if I start it up with a current blockchain it'll just convert, right?
**\<hyc>** yep
**\<fluffypony>** ok I'll give it a spin on a few devices
**\<fluffypony>** so then I guess the final question is whether this goes into 0.9.x or 0.10.0 ?
**\<othe>** perf code itself i run on multiple nodes, from 32 bit arm to 64bit x86 - works absolutely flaweless here
**\<gingeropolous>** peanut gallery here - makes more sense to call it 0.9.x . big number change seems appropriate for consensus mechanism changes (i.e., ringct)
**\<bigreddmachine>** yeah i agree with gingeropolous in general... iterate the version on huge changes, subversion on consensus changes, and point on small changes that don't break consensus.
**\<fluffypony>** gingeropolous: I don't disagree, I'm also leaning towards it being a point release
**\<ArticMine>** Also if there is down time for the nodes during conversion a more gradual approach in 0.9.x is preferable
**\<bigreddmachine>** that maintains the idea that all 0.9.x are compatible, and not compatible for 0.10.x
**\<fluffypony>** well with a 0.9.x release everyone won't update at once
**\<hyc>** well, they're compatible on the wire, at least
**\<bigreddmachine>** and that's what matters in the long run... say 2-3 years from now there are lots of companies with various implementations and such, like in Bitcoin. a switch to 0.10.x indicates to them "get your stuff together or be left behind"
**\<fluffypony>** yeah
**\<bigreddmachine>** so might as well use that precedence earlier rather than later.
**\<fluffypony>** ok I think that's it from my side - does anyone have anything they want to ask / add / discuss ?
**\<smooth>** i think anything with a conversion process like that should be branded as a major/semi-major upgrade, especially since you can't easily downgrade
**\<dEBRUYNE>** perhaps a bit about ring CT? Though hyc kind of already said something about that before the discussion
**\<dEBRUYNE>** more specifically -> \<hyc> sounds good. looking at NobleSir's DB schema, doesn't seem like there's much new needed on the DB side of things
**\<fluffypony>** smooth: can definitely make that clear in the release
**\<dEBRUYNE>** oh and fluffypony, perhaps a bit about the 0MQ stuff as well?
**\<fluffypony>** hyc is better suited to update us on RingCT
**\<smooth>** 0mq is kind of a big issue i think, maybe leave for the next meeting
**\<xmrpromotions>** Is omq the only/primary reason why work is still being done on master instead of dev branch?
**\<smooth>** thats part of the whole issue of how the repo is organized and the workflow
**\<fluffypony>** yeah I think that's a discussion we can have at the next meeting
**\<hyc>** sorry I've got very little intelligent to say about ringct
**\<hyc>** i've compiled the code and run the test successfully
**\<hyc>** but I don't really think i'm in position to merge it, don't understand the pieces
**\<moneromooo>** I'm better acquainted with monero in general, though less with the db side.
**\<moneromooo>** And IANAC.
**\<fluffypony>** you are not a cat ?
**\<fluffypony>** obviously, you're a moo!
**\<moneromooo>** That is true.
**\<moneromooo>** Maybe we can get riddick on the job.
**\<fluffypony>** that's riddick-ulous
**\<moneromooo>** OK then. No cats.
**\<moneromooo>** Thing is, I'm wary of starting a large piece of work these days, as I don't have as much free time as I used to.
**\<dEBRUYNE_>** hyc, moneromooo: Perhaps the two of you could collaborate with NobleSir on it
**\<bigreddmachine>** Once the meeting is adjourned, can i hijack everyone/someone's attention for 2 mins to ask a question? it's not an official dev question, but still related i guess.
**\<othe>** just throw it out
**\<xmrpromotions>** can I ask about multi sig? Am I right that ring ct will be a prerequisit for it? I ask because it sounds like it will be needed for bitsquare (at least to be used as intended)
**\<othe>** no ringct is no prerequesite for multisig
**\<othe>** and no bitshares doesnt need it
**\<othe>** bitsquare
**\<fluffypony>** lol bitshares
**\<smooth>** notsquares
**\<othe>** all they need is some gui changes like payment id support or alternatively its enough to use integrated addresses instead
**\<othe>** and then they need support for the spendkey stuff to proof a payment, thats it
**\<moneromooo>** Multisig happens as a byproduct of ringct withou much extra work though AIUI.
**\<fluffypony>** yeah
**\<xmrpromotions>** ok thank you. maybe I read about dev priorities and misinterpreted a comment about ringct coming before multi sig
**\<bigreddmachine>** Can I get someone's opinion on something? The "incoming\_transfers" simplewallet method with "all" as the type returns a list of all transfers with in XMR coming into the wallet, including change from outgoing txs. For the wallet i've been working on, I have introduced a way to track outgoing transactions locally and store them using IndexedDB, since there’s not a good way to do that over rpc. I’d like
**\<bigreddmachine>** to present users with a "pseudo-ledger" so-to-speak that showed incoming txs and outgoing txs, and should add up to the balance for a wallet. Would it be correct/good/valid for me to check the returns from "incoming\_transfers" to see if any tx\_ids match those from the outgoing transfers database, and if they do match, don't display them? That would result in the displayed "incoming transfers" to only be
**\<bigreddmachine>** transfers from another source.
**\<moneromooo>** incoming\_transfers shows the raw outputs. So you need to subtract those coming back from the ones leaving with the same txid.
**\<moneromooo>** But I'll add RPC for the others in the near future.
**\<binaryFate>** moneromooo can you be more explicit, what do you intend to add?
**\<bigreddmachine>** Well, the data i record in the database is only the amount that leaves the wallet (it is ignorant of the fact that there is change leaving and coming back). Although, come to think of it, it also is ignorant of the fee paid... hmm, okay, i'll need to think on this more
**\<moneromooo>** RPC for getting the same info that show\_transfers displays.
**\<binaryFate>** ok
**\<bigreddmachine>** ^that would solve all my issues and i'd love you forever. in a manly way.
**\<dEBRUYNE_>** othe: afaik Bitsquare needs it if you want XMR/fiat markets
**\<othe>** altcoins are the fiat markets in bitsquares atm i think
**\<bigreddmachine>** dEBRUYNE_: that's correct. but based on the interview on daily decrypt, i don't think he plans to have fiat markets other than BTC anytime soon. he kind of alluded to that.
**\<bigreddmachine>** he said in the interview that if you wanted to trade an altcoin for fiat, you'd have to go through bitcoin because that's what has the best liquidity and what multisig is implemented in the market
**\<othe>** correct

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

@ -0,0 +1,117 @@
---
layout: post
title: Logs for the Kovri Dev Meeting Held on 2016-05-08
summary: Mac / BSD support moving forward
tags: [dev diaries, i2p, crypto]
author: dEBRUYNE / fluffypony
---
*May 8th, 2016*
# Logs
**\<anonimal>** Hi fluffypony
**\<fluffypony>** hiiii
**\<fluffypony>** was just about to check if you're around :)
**\<anonimal>** Hi everyone, I think meeting-bot is still online
**\<fluffypony>** yes it is
**\<fluffypony>** coming through loud and clear on this side
**\* anonimal** reading backlog
**\<anonimal>** Hi moneromoo.
**\<anonimal>** Hi psi, uncrustify configs? Can you explain?
**\<psi>** uncrustify is a code styler for c/c++
**\<fluffypony>** I've never heard of it, plz tell me more psi?
**\<psi>** it auto formats the code
**\* psi** gets relevant links
**\<psi>** https://github.com/uncrustify/uncrustify
**\<anonimal>** I know that psi, but why for *.conf?
**\<psi>** i don;t understand?
**\<psi>** what about *.conf?
**\<fluffypony>** oh anonimal
**\<fluffypony>** not for *.conf
**\<fluffypony>** he means conf file for uncrustify matching our coding style
**\<psi>** damn lag
**\* psi** waits to catch up
**\<psi>** fluffypony: right
**\* anonimal** back
**\<fluffypony>** wb
**\<anonimal>** To answer the question, no I don't have an uncrustify config for kovri.
**\<anonimal>** Just a simple .vimrc.
**\<anonimal>** I can take a look at creating a config after #174 is resolved.
**\<anonimal>** fluffypony: I saw your comment in #56, what system are you runnning?
**\<fluffypony>** anonimal: Ubuntu 14.04
**\<fluffypony>** and there's no Boost 1.59 / 1.60 available
**\<fluffypony>** but that little hack worked
**\<anonimal>** 1.54 should work though
**\* anonimal** triple checks
**\<fluffypony>** I can't use 1.54
**\<fluffypony>** incompatible with Monero
**\<psi>** monero needs .56 or higher ?
**\<fluffypony>** .55 or higher
**\<psi>** kk
**\<fluffypony>** so basically .59 or higher if you want both
**\<anonimal>** I need about 5-15 minutes to build on bsd and osx so I can open the new linkage error tickets I talked about in #174
**\<fluffypony>** kk
**\<psi>** :\
**\* anonimal** the only time I have is now and a bit later but the meeting is now so I want to throw it into the topic
**\* anonimal** still compiling, should be done in 5 or so
**\<anonimal>** #monero-dev, FYI, our meetings have always been more organized, on-point, and I've almost always been prepared.
**\<anonimal>** This one caught me off guard.
**\<anonimal>** (last minute suggestion by fluffypony)
**\<anonimal>** Sorry for the wait.
**\<fluffypony>** don't stress, ours are always by the seat of our pants
**\* anonimal** opening tickets
**\<anonimal>** Hmf, I need to work with the bsd a bit more before posting.
**\<anonimal>** Anyway, https://github.com/monero-project/kovri/issues/175
**\<anonimal>** I'm only sitting with this again since I left off < 24 hours or so ago so,
**\<anonimal>** I haven't drawn any conclusions yet.
**\<anonimal>** Has anyone seen this before? #monero-dev?
**\* fluffypony** clicks
**\<fluffypony>** moneromooo: seen anything like that before ?
**\<fluffypony>** "Undefined symbols for architecture x86_64"
**\<anonimal>** The usual 'Undefined symbols for architecture x86_64' has been an osx complaint on this machine in the past.
**\<moneromooo>** Not as such. I've seen plenty of really annoying linking issues though.
**\<fluffypony>** this is gcc on OS X tho, right ?
**\<anonimal>** fluffypony: Yes.
**\<fluffypony>** maybe we're chasing our tails on that
**\<anonimal>** I don't have time to deal with clang. If we want multi-distro builds, I need to streamline our process.
**\<anonimal>** for macosx, clang won't build because it doesn't like the things I did for the reseed rewrite and,
**\<anonimal>** I don't have time to keep-up with llvm development.
**\<anonimal>** So, thoughts?
**\<fluffypony>** rewrite everything in C :-P
**\<anonimal>** lol
**\<fluffypony>** ok my suggestion is that we eschew OS X / BSD compatibility for the moment
**\<fluffypony>** until we can fix Clang support
**\<anonimal>** Thanks moneromoo. I'm glad this isn't just a kovri thing.
**\<fluffypony>** rather than trying to fudge it
**\<anonimal>** Well that's the problem, this won't be the only issue.
**\<fluffypony>** yeah I know
**\<anonimal>** And I'll end up wasting time juggling compilers instead of working on other things.
**\<fluffypony>** I mean that can be a later piece of work
**\<fluffypony>** let's focus on getting it working on one Linux and Windows, where we're running gcc and it's fine
**\<anonimal>** fluffypony: what part will be the later piece of work?
**\<fluffypony>** anonimal: fixing Clang incompatibilities
**\<moneromooo>** I don't use OSX btw, so kinda ignore what I said above.
**\<anonimal>** Ok sounds great, I'll focus on linux/win building.
**\<anonimal>** Should we remove osx/bsd build instructions from BUILDING.md?
**\<anonimal>** Or I'll just open the bsd ticket and maybe someone will see it?
**\<fluffypony>** yeah, I think let's make a note that it's broken on OS X / BSD for the moment, and that contributors are welcome to fix
**\<fluffypony>** kk
**\<anonimal>** Ok, I'll add the note.
**\<anonimal>** Any other questions/comments on #175?
**\<fluffypony>** no not yet
**\<fluffypony>** I mean no not atm, lol
**\<anonimal>** Ok, I'll add a note in #174 about what we discussed.
**\<anonimal>** And part 1) in #174, apparently there is an env variable I can set to get it to work.
**\<anonimal>** Not the first travis issue I've had to deal with.
**\<anonimal>** Oh well, they are growing quite nicely IMHO.
**\<fluffypony>** travis issues are growing quite nicely ?
**\<anonimal>** lol, yes, and I meant their project as a whole.
**\<fluffypony>** lol
**\<anonimal>** Ok, hour is up. Anything else pressing?
**\<fluffypony>** I don't think so - this was kinda an interim meeting because Kovri's was last week
**\<fluffypony>** so this brings them into line
**\<fluffypony>** next one on May 22nd, same time
**\<anonimal>** Ok, I'll mark the calendar.
**\<anonimal>** Thanks everyone.
**\<fluffypony>** thank you

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

@ -0,0 +1,127 @@
---
layout: post
title: Overview and Logs for the Dev Meeting Held on 2016-05-08
summary: Clarification on ringCT next steps, 0MQ, discussion of open PRs
tags: [dev diaries, core, crypto]
author: dEBRUYNE / fluffypony
---
*May 8th, 2016*
# Logs
**\<fluffypony>** hyc, moneromooo, smooth, luigi1111w, luigi1112, luigi1114, ArticMine, NoodleDoodle, tewinget: meeting starting
**\<hyc>** hey
**\<fluffypony>** and othe
**\<fluffypony>** just waiting for the relay to come up
**\<fluffypony>** there we go
**\<luigi1112>** Not here
**\<fluffypony>** hello, and welcome to the 75th annual hunger games
**\<bigreddmachine>** crap, luigi1112's not here.
**\<fluffypony>** luigi1112 is literally a ghost
**\<fluffypony>** ok so we have a couple of PRs hanging around
**\<bigreddmachine>** is that why there are always 2-3 of him?
**\<fluffypony>** bigreddmachine: exactly :)
**\<luigi1112>** Hoooooo can say
**\<fluffypony>** I've reviewed #831 and it's ready for merge
**\<fluffypony>** same with 827
**\<fluffypony>** has anyone had further thoughts on 818 or are we ok with merging that functionality in its current form ?
**\<fluffypony>** bearing in mind that this will haunt us basically forever
**\<fluffypony>** and we pretty much can't change it ever again
**\<fluffypony>** no pressure or anything
**\<fluffypony>** (just kidding, we can definitely version it)
**\* fluffypony** waaaaaits
**\<hyc>** I haven't looked at 818, it's a crypto question still
**\<fluffypony>** yeah I think shen looked at it
**\<fluffypony>** ok we'll put a peg on that pending input from moneromooo and smooth
**\<ArticMine>** What are shen's thoughts on 818?
**\<MRL-Relay>** {-shen} I took a glance at it, but if desired I can look deeper
**\<MRL-Relay>** {-shen} at glance looked ok
**\<fluffypony>** shen: I think take a closer look if you can, given how we \*are\* stuck with it forever we may as well try get it right off the bat
**\<MRL-Relay>** {-shen} ok I will budget some time today or tomorrow
**\<fluffypony>** ok cool
**\<fluffypony>** then with the performance branch (794) we found an issue with the initial migration, messed up a global index on some txos
**\<luigi1112>** Is that the sig thing?
**\<fluffypony>** this appears to be fixed with the new / faster migration
**\<fluffypony>** luigi1112: yes
**\<luigi1112>** Ok
**\<fluffypony>** luigi1112: also I think if you have a second do you want to glance at the output format, maybe we need to give it a version prefix and a suffix of some sort
**\<fluffypony>** ok so performance is ready for merge, unless anyone has an objection
**\<hyc>** sounds good to me
**\<fluffypony>** then 810, I'm still unclear as to whether we're dropping that idea or we're merging it
**\<hyc>** given the increased locking requirements I'm against it.
**\<fluffypony>** ok
**\<hyc>** and as said before, I think fixing the pool code to use cheaper queries is better
**\<fluffypony>** I'm onboard with that
**\<fluffypony>** so now that we're getting the performance branch out the way
**\<fluffypony>** the next two major things on the radar are 0MQ and ringct
**\<fluffypony>** at the moment we have that stall in the dev branch, not sure whether it's time to nuke it and start the new one
**\<fluffypony>** I'll wait for input from moneromooo on that
**\<fluffypony>** and then ringct - hyc, did you say you were going to do some of that? I can't even remember
**\<hyc>** I looked into it but no, moneromooo should take lead
**\<fluffypony>** ok
**\<fluffypony>** shen
**\<hyc>** I can do whatever DB additions are needed
**\<fluffypony>** what's the status of your implementation code ?
**\<dEBRUYNE>** perhaps hyc can assist with the DB stuff
**\<dEBRUYNE>** oh he was quicker than me already
**\<MRL-Relay>** {-shen} Should be ready for test net at least
**\<fluffypony>** ok
**\<fluffypony>** it's time for a testnet fork anyway, so we can work towards that
**\<fluffypony>** basically everything else requires moneromooo and smooth, so we can put a peg in them till next meeting
**\<fluffypony>** speaking of which
**\<fluffypony>** next one on the 22nd
**\<dEBRUYNE>** perhaps they will show up within the next 30 minutes :-P Just page them 3 times!
**\<fluffypony>** hah hah
**\<dEBRUYNE>** Btw fluffypony, will the performance branch be used for a new point release?
**\<fluffypony>** dEBRUYNE: yes
**\<dEBRUYNE>** All right
**\<dEBRUYNE>** Btw, if moneromooo and smooth show up later tonight and have a chat about 0MQ we could just add that to the dev logs
**\<fluffypony>** ok
**\<bigreddmachine>** q: for the next point release... will it include arm7 binaries? 0.9.4 does not
**\<fluffypony>** it should
**\<bigreddmachine>** okay. unreleated, probably for hyc... you mentioned that simplewallet now only needs to sync ~30 MB instead of 3 GB with the new improvements. What was the savings? was there just a lot of data being shared that was unnecessary?
**\<luigi1112>** fluffypony: I'll think about that
**\<hyc>** bigreddmachine: sync of irrelevant blocks, only needed to use hashes
**\<bigreddmachine**> kk, thats what i figured
**\<bigreddmachine>** now just syncing block headers?
**\<hyc>** up to a given refresh height it only syncs hashes
**\<fluffypony>** moneromooo: we can carry on chatting about the bits you missed after the kovri meeting, if that's ok ?
**\<moneromooo>** Sure.
**\<fluffypony>** ok back to the Monero side
**\<fluffypony>** moneromooo: have you had a chance to read the meeting backlog ?
**\<moneromooo>** I did.
**\<fluffypony>** ok - thoughts on 0MQ / dev branch?
**\<fluffypony>** if you have the dev branch on your fork we can nuke it and reset
**\<moneromooo>** I think you can nuke the dev branch.
**\<moneromooo>** As for 0mq... whenever I get to start it, it's going to be a largeish amount of work at once I think.
**\<fluffypony>** ok
**\<moneromooo>** I happen to be not super motivated to code these days, after day job spent debugging stuff.
**\<fluffypony>** sometimes you gotta take a break and work on fun stuff
**\<dEBRUYNE>** perhaps Ring CT qualifies as fun stuff, perhaps not :-P
**\<moneromooo>** What's more important btw, 0mq or ringct ?
**\<fluffypony>** I would think ringct
**\<dEBRUYNE>** I'd say Ring CT too
**\<dEBRUYNE>** Iirc ring CT needs to be some time on testnet too anyway
**\<moneromooo>** And we can ask the "did nobody test this ?" peanut gallery in to test it :D
**\<fluffypony>** awesome
**\<moneromooo>** One other thing I wanted to do, which is interesting from a user's point of view, is to allow the wallet to see/decode pool txes.
**\<moneromooo>** That's probably not too much work.
**\<dEBRUYNE>** lol moneromooo
**\<dEBRUYNE>** Btw moneromooo, in case you hadn't read it yet hyc can assist you with the DB stuff
**\<dEBRUYNE>** More specifically -> \<hyc> I can do whatever DB additions are needed
**\<moneromooo>** I saw that. It's good so I don't break it all.
**\<dEBRUYNE>** Btw fluffypony, I forgot to ask earlier. Not sure if he is here, but any plans to opensource NoodleDoodle's trezor code soon^tm?
**\<fluffypony>** you'd have to ask NoodleDoodle that
**\<dEBRUYNE>** all right, perhaps he responds :-P
**\<moneromooo>** Oh: about reviewing the signature patch, IIRC smooth said that code was only used for the debug commands, so the CN people might not have make it so resistant to misuse or something. So might be worth looking at its internals (I expect it uses the same building blocks as ring signatures, but I don't really know).
**\<dEBRUYNE>** Also, regarding #810, a pool op commented the following: "Adding this to the current HEAD 8b0d22a reduces CPU by an order of magnitude on a pool wallet: 80% usage on a core down to 8%. Seems like a significant performance win to me." Since there is a mixed feeling about the PR itself I figured perhaps just close it and send the pool ops a mail that they could possibly apply the code/patch to their own code if they want to do so. I could
**\<dEBRUYNE>** gather email addresses and setup a standardized mail.
**\<dEBRUYNE>** ^ fluffypony
**\<moneromooo>** Changing the pool code to call getinfo and check top hash would also drop CPU usage a lot.
**\<fluffypony>** shen, see above ^^
**\<fluffypony>** (before the pool code stuff)
**\<MRL-Relay>** {-shen} ok
**\<MRL-Relay>** {-shen} good point
**\<dEBRUYNE>** moneromooo: I see, well then it's more up to the pool ops instead of the contributors/developers imo
**\<moneromooo>** Up to whoever gets his butt in gear to do it, as usual :D

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

@ -0,0 +1,202 @@
---
layout: post
title: Logs for the Kovri Dev Meeting Held on 2016-05-22
summary: GNU Social status, Kovri website, i2p StackExchange, Coverity for Kovri
tags: [dev diaries, i2p, crypto]
author: dEBRUYNE / fluffypony
---
*May 22nd, 2016*
# Logs
**\<fluffypony>** ok starting the meeting relay for the Kovri meeting
**\<meeting-bot> [anonimal]** Hello.
**\<fluffypony>** anonimal: all yours :)
**\<i2p-relay> {-anonimal}** From https://github.com/monero-project/kovri/issues/177
**\<i2p-relay> {-anonimal}** Proposed meeting items:
**\<i2p-relay> {-anonimal}** 17:00 (UTC)
**\<i2p-relay> {-anonimal}** 1. Review assigned open tickets: status, code ideas (if applicable), etc.
**\<i2p-relay> {-anonimal}** 2. Any additional meeting items
**\<i2p-relay> {-anonimal}** 3. Confirm next meeting date/time
**\<i2p-relay> {-anonimal}** Starting with 1., as discussed in private with fluffypony, let's tackle https://github.com/monero-project/kovri/issues/assigned/fluffypony
**\<fluffypony>** hokay - should we do them one at a time ?
**\<meeting-bot> [anonimal]** Sure, #105.
**\<fluffypony>** sec, just opening it up
**\<meeting-bot> [anonimal]** I'm more curious about status updates and if we'll pursue some of these ideas.
**\<fluffypony>** ok 107
**\<fluffypony>** I asked dEBRUYNE and the rest of the social media guys about that in January last
**\<fluffypony>** dEBRUYNE: have you guys looked at that at all ?
**\<dEBRUYNE>** I think xmrpromotions was handling that
**\<meeting-bot> [anonimal]** JFTR: s/107/105/
**\<dEBRUYNE>** I honestly cannot remember you asking me :-P
**\* fluffypony** has the IRC logs to prove it :-P
**\<dEBRUYNE>** regardless, I think xmrpromotions was handling most of that :-P
**\<fluffypony>** ok - xmrpromotions, did you have a chance to look at GNU Social ?
**\<ArticMine>** I am looking at GNU social right now
**\<xmrpromotions>** I am sorry but I have not
**\<meeting-bot> [anonimal]** Can I ask everone, candidly, what they think of the idea?
**\<meeting-bot> [anonimal]** Is it something worth pursuing?
**\<ArticMine>** My initial instinct is yes
**\<fluffypony>** tbh I had hardly heard about GNU Social till you brought it up
**\<xmrpromotions>** Are there more details I can read about it? https://github.com/monero-project/kovri/issues/105
**\<fluffypony>** but I think in terms of providing a more freedom-friendly social presence it's advantageous
**\<fluffypony>** plus if we can spend the energy maintaining a Facebook page we can definitely justify this... :-P
**\<ArticMine>** Way better than a Facebook page
**\<ArticMine>** There are many who dislike the corporate centralization of Facebook in social media
**\<meeting-bot> [anonimal]** xmrpromotions: A great example of a working instance is https://quitter.se/
**\<__uguu__>** facebook is currently actively banning users that talk about the censorship too so...
**\<meeting-bot> [anonimal]** xmrpromortions: For technical details, https://gnu.io/social/
**\<meeting-bot> [anonimal]** lol, sorry, not auto-completion here
**\<meeting-bot> [anonimal]** Yes, recent news items re: censorship just get crazier and crazier.
**\<xmrpromotions>** Thank you I will read the details and be ready to comment later. It is too early for me to commit to anything quite yet
**\<meeting-bot> [anonimal]** And the social monopolies are finally showing their true colors.
**\<meeting-bot> [anonimal]** Ok, so #105 is on hold pending xmrpromotions' review?
**\<fluffypony>** yup
**\<meeting-bot> [anonimal]** Ok, next ticket.
**\<fluffypony>** ok
**\<meeting-bot> [anonimal]** #46
**\<meeting-bot> [anonimal]** The Kovri website.
**\<fluffypony>** #46 - does anyone have any strong opinions on whether it should be a page on the Monero website, or a separate site that matches the Monero site's look and feel (maybe with different colours), or a completely unrelated site ?
**\<fluffypony>** anonimal: and your input on this would be appreciated too
**\<fluffypony>** I think the relay is wonky
**\<meeting-bot> [anonimal]** What's the time-cost in terms of managing two sites?
**\<meeting-bot> [anonimal]** Yes, missed almost everything it looks like.
**\<fluffypony>** anonimal: it's mostly just the initial work, after that I mostly go hands-off and let the community run with the content
**\<meeting-bot> [anonimal]** Can anyone read this?
**\<meeting-bot> [anonimal]** Ok, so could we start small with a page on the website, or maybe subdomain/ and if things get bigger move onto another site?
**\<fluffypony>** that would be my recommendation
**\<fluffypony>** we start with a sub-section on the Monero site
**\<fluffypony>** and forward the kovri site through to it
**\<fluffypony>** if we feel the need later on we can create a separate site on its own
**\<meeting-bot> [anonimal]** Ok, sounds good to me. Anyone else?
**\<xmrpromotions>** Of the three options mentioned a separate site that matches the Monero site's look and feel may help draw a wider audience than a page on the Monero site while at the same time anyone who visits the Kovri page knows that Monero is associated with it
**\<xmrpromotions>** It seems like a judgement call to me. Either plan sounds reasonable
**\<fluffypony>** restarting meeting bot
**\<fluffypony>** in fact, if you want to write up some content for me I'll do it on the plane on Tuesday
**\<fluffypony>** in fact, I can probably take most of it from the readme
**\<fluffypony>** in fact, if I say in fact again I'll summon the in-fact-bot
**\<meeting-bot> [anonimal]** Ok, ideas for content? I can blabber but ideas are welcome.
**\<meeting-bot> [anonimal]** ping in-fact-bot
**\<xmrpromotions>** Any thoughts on creating a stackexchange proposal for I2P? Tor has a page now https://area51.stackexchange.com/proposals/56447/tor and we should be able to reach the commitment stage quickly with the same supporters behind the Monero proposal?
**\<fluffypony>** xmrpromotions: we'd have to run it past zzz, at the very least
**\<meeting-bot> [fluffypony]** zzz ^^
**\<xmrpromotions>** sorry for off topic idea. I can table it for later if appropriate
**\<fluffypony> no I think it's an excellent idea, if the i2p community at large is interested then now is definitely the time
**\<meeting-bot> [anonimal]** From what I've seen, alot of great ideas come and go through #i2p-dev but it always comes down to resources.
**\<meeting-bot> [anonimal]** I think we'd all love that but someone will have to take the initiative.
**\<xmrpromotions>** I will take the initiative on that
**\<meeting-bot> [anonimal]** AFAICT all i2p-related dev (including Kovri) is in a bit of a dry spell so, priorities.
**\<meeting-bot> [anonimal]** I like the idea though.
**\<fluffypony>** anonimal: the advantage is that we can basically get everyone who's committed to the Monero proposal to also back an i2p proposal
**\<fluffypony>** but now is the time to do so
**\<fluffypony>** whilst everyone's excited
**\<meeting-bot> [anonimal]** Ok, so what's the next step?
**\<xmrpromotions>** If the I2P communty supports it. As fluffypony said now is the time as the synergy will help both I2P and Monero proposals pass faster for REP related reasons
**\<fluffypony>** so basically next step on the website is let's get a bit of content and I'll put it together on the plane on Tuesday
**\<fluffypony>** next step on the StackExchange proposal is to wait for feedback from zzz
**\<xmrpromotions>** sounds good. I wont act until I hear confirmation that zzz is ready to proceed
**\<meeting-bot> [anonimal]** I dropped a line in #i2p-dev.
**\<meeting-bot> [anonimal]** We'll see who bites.
**\<meeting-bot> [anonimal]** Ok, so #46: 1) create content 2) On Tuesday, fluffypony will put something together 3) ETA after that?
**\<fluffypony>** ok next ticket ?
**\<fluffypony>** oh
**\<fluffypony>** once it's pushed to the repo it goes live
**\<fluffypony>** there's no ETA beyond that
**\<fluffypony>** or no steps beyond pulling it and rebuilding the Jekyll site
**\<meeting-bot> [anonimal]** Ok great, I'll paste a note in ticket.
**\<meeting-bot> [anonimal]** Moving on, #43.
**\<fluffypony>** ok - can we just use the Monero addresses, or do we want separate addresses?
**\<meeting-bot> [anonimal]** I'm fine with Monero addresses.
**\<fluffypony>** ok then they're avialable here, anonimal: http://donate.getmonero.org
**\<fluffypony>** *available
**\<meeting-bot> [anonimal]** Ok. Also, I can apply for FFS when needed or include my address somewhere or we can simply put a note in README to donate to either. Sound fair?
**\<meeting-bot> [anonimal]** Or no?
**\<othe>** ffs is prolly more efficient
**\<fluffypony>** FFS is better than direct donations
**\<fluffypony>** and it's generally more trustworthy because you raise funds for a specific piece of work, and then get paid out on milestones
**\<meeting-bot> [anonimal]** Ok, we should put a note in README directing to FFS and donation page or just FFS?
**\<fluffypony>** the readme just needs the donation page
**\<fluffypony>** if we get large donations we redistribute them to active FFS proposals anyway
**\<meeting-bot> [anonimal]** fluffypony: Ok, would you like to add that with your wording to the README? Or should I?
**\<fluffypony>** anonimal: I have to pack tomorrow, and have a bunch of things to do, so if you could that would be appreciated
**\<meeting-bot> [anonimal]** Ok
**\<meeting-bot> [anonimal]** Moving on, #27
**\<fluffypony>** ok #27 is going to have to hold for a week or two, we're busy moving email providers on getmonero.org so I'll sort it out on the new provider
**\<meeting-bot> [anonimal]** Ok, I'll paste that note.
**\<meeting-bot> [anonimal]** Onward to #20.
**\<fluffypony>** 20 - I can try Coverity again, let's see if it gives me the same issue
**\<fluffypony>** I've not heard from them despite opening tickets etc.
**\<meeting-bot> [anonimal]** Links? Maybe I can comment/ping them too.
**\<fluffypony>** anonimal: screenshots and process I followed is in that ticket
**\<fluffypony>** issue I mean
**\<meeting-bot> [anonimal]** Ok, well, it may come down to a phone call or two.
**\<meeting-bot> [anonimal]** Is that something you'd be willing to do?
**\<meeting-bot> [anonimal]** If not, we can skip the integration and try to do it manually.
**\<fluffypony>** sure
**\<meeting-bot> [anonimal]** Ok, next. #90 is not assigned to you but I remember you said you would assign yourself.
**\<fluffypony>** one second just checking coverity
**\<meeting-bot> [anonimal]** Is #90 still of interest?
**\<fluffypony>** oooooh it works
**\<fluffypony>** they must've fixed it and just not let us know
**\<fluffypony>** anonimal: I'll PM you with coverity details
**\<meeting-bot> [anonimal]** Fantastic!
**\<meeting-bot> [anonimal]** Yay, great. This should be interesting.
**\<gingeropolous>** will I break things if I create a bridge by connecting simplewallet to the daemon over an i2p tunnel?
**\<fluffypony>** doubtful
**\<meeting-bot> [anonimal]** fluffypony: #90?
**\<fluffypony>** 90 will happen automagically when our GitLab mirror is up
**\<fluffypony>** it'll have clearnet / Tor / i2p mirrors
**\<meeting-bot> [anonimal]** Ok then. I've missed any discussions about that in the past, is there an ETA?
**\<fluffypony>** not at the moment - it's one of those "on the list" things, I lack the time to knuckle down and do it
**\<fluffypony>** we need a devops team :-P
**\<meeting-bot> [anonimal]** Indeed. Ok, I'll add a note in ticket.
**\<meeting-bot> [anonimal]** To whom should we assign #90 then?
**\<fluffypony>** me
**\<meeting-bot> [anonimal]** Ok, will do.
**\<meeting-bot> [anonimal]** Yay, hour long of fluffypony tickets finally tackled! I'm glad we finally had the time. Any other comments them?
**\<fluffypony>** none from my side
**\<meeting-bot> [anonimal]** So, since this was the "fluffypony show" meeting, for time-sake I'll sum up my part of 1. with one line:
**\<meeting-bot> [anonimal]** I'm not working on any tickets ATM but what will most likely be a new ticket soon as I'm working on Transports (mostly NTCP, little SSU): debugging/refactoring/c++14 refactoring where appropriate/some rewrite/some new code/documentation/improved logging
**\<meeting-bot> [anonimal]** So, that's that for now, I'm sure more code talk can be at the next meeting.
**\<meeting-bot> [anonimal]** Any additional meeting items (quickly)?
**\<fluffypony>** nothing more from me
**\<meeting-bot> [anonimal]** Re: StackExchange, what tl;dr can I give to #i2p-dev?
**\<meeting-bot> [anonimal]** Aside from pointing a link to the meeting log.
**\<meeting-bot> [anonimal]** (I've been out of the loop re: the initiative)
**\<xmrpromotions>** Just say that we are willing to cross promote it to XMR community and expect it to reach the commitment stage fairly fasy
**\<xmrpromotions>** fast
**\<meeting-bot> [fluffypony]** just that it's a proposal to have an i2p-specific StackExchange area
**\<meeting-bot> [anonimal]** So, what should we expect from them?
**\<xmrpromotions>** from there the I2P and XMR communities can help each other ensure both site reach beta
**\<xmrpromotions>** Hard for me to make an ETA on that. End result would be an I2P site similar to what Tor has now
**\<meeting-bot> [anonimal]** fluffypony: should we end meeting?
**\<meeting-bot> [anonimal]** (or has it ended?)
**\<meeting-bot> [fluffypony]** yes I think so
**\<meeting-bot> [fluffypony]** I'll take the bot down
**\<xmrpromotions>** We need I2P experts to appear during the proposal stage once created to ask good questions
**\<xmrpromotions>** early questions attract a lot more votes and rise to the top, so quality matters
**\<meeting-bot> [anonimal]** Ok, I'll chat in #monero-dev.
**\<i2p-relay> {-anonimal}** * thinking
**\<i2p-relay> {-anonimal}** xmrpromotions: I can commit to both pages. How many I2P 'experts' would need to commit?
**\<xmrpromotions>** well we need 40 good questions. each person can only ask 5
**\<fluffypony>** well before commitment it's just the voting section
**\<xmrpromotions>** Our initial 40 questions will help with SEO after launch
**\<fluffypony>** where we need not only good questions asked, but also good questions have to get 10 votes each
**\<xmrpromotions>** Yes I mean we need to create quality questions to vote on
**\<xmrpromotions>** If someone wants to create a list of 40 great questions that would be perfect
**\<i2p-relay> {-anonimal}** 40 great I2P questions, I could do that.
**\<fluffypony>** they still have to post them though
**\<xmrpromotions>** then we can divide it up and ask 5 each to make sure no silly questions gain a lot of votes early in the process
**\<xmrpromotions>** we can find 8 people to post 5 questions each easily
**\<fluffypony>** yup
**\<fluffypony>** yeah, then we need a bunch of people to upvote :)
**\<xmrpromotions>** I dont think voting will be a problem either. XMR users with no rep can be assigned to ask the questions... that will give them 5x10x5 rep (250 each)
**\<xmrpromotions>** which will give them more than enough for the 200 rep area 51 cutoff for the SE 100 rep account association bonus
**\<fluffypony>** strategyyyy
**\<xmrpromotions>** 5q with 10 votes each will earn 5 rep per vote
**\<i2p-relay> {-anonimal}** Ok, sounds great. Right now, I need to finish post-meeting wrap-up, take a break, get my brain in order and bbl.
**\<fluffypony>** ok cool
**\<xmrpromotions>** I will make a post in the getmonero forums. Maybe we can create and agree on a list of 40 questions there before we start
**\<xmrpromotions>** thanks everyone. have a great weekend
**\<fluffypony>** cheers

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

@ -0,0 +1,129 @@
---
layout: post
title: Overview and Logs for the Dev Meeting Held on 2016-05-22
summary: Decisions on PRs still open, performance branch conversion problems, consolidating dev documentation on the GH wiki
tags: [dev diaries, core, crypto]
author: dEBRUYNE / fluffypony
---
*May 22nd, 2016*
# Logs
**\<fluffypony>** ok
**\<fluffypony>** das meeting
**\<ArticMine>** has started
**\<fluffypony>** heh heh
**\<xmrpromotions>** let the fun begin
**\<fluffypony>** hyc, smooth, moneromooo, dEBRUYNE, gingeropolous, luigi1112, luigi1114, anyone I've missed
**\<fluffypony>** hokay so
**\<fluffypony>** first up: for those that haven't done so, please commit to the StackExchange proposal: http://area51.stackexchange.com/proposals/98617/monero
**\<gingeropolous>** oooh i get pinged for dev meetings? :)
**\<xmrpromotions>** and earn rep: https://forum.getmonero.org/20/general-discussion/2542/stack-exchange-commitment-requirements
**\<fluffypony>** you're basically just committing to asking / answering a total of 10 questions over 3 months
**\<fluffypony>** also it would be advantageous if you have over 200 rep on another StackExchange site, as xmrpromotions said
**\<fluffypony>** I earned over 200 rep on bitcoin.stackexchange by answering like 4 questions, so it's not hard
**\<fluffypony>** ok maybe like 6 questions, but still, not hard
**\<fluffypony>** I think getting 200 committers in total will be easy, but having 100 committers with sufficient rep might be a little harder
**\<fluffypony>** ok so
**\<fluffypony>** PRs
**\<fluffypony>** over the last couple of weeks we've merged a few PRs
**\<fluffypony>** obviously
**\<fluffypony>** the biggest one being the performance branch
**\<fluffypony>** which was what warptangent was working on before he passed away
**\<fluffypony>** and which was completed by hyc and everyone else
**\* dEBRUYNE** pages tewinget, NoodleDoodle, ArticMine, othe
**\<dEBRUYNE>** probably missed someone
**\<fluffypony>** we are seeing some latent issues with auto-conversions, or that appear to be coming from the auto-conversion
**\<fluffypony>** if users hit issues with that the fastest route is for them to sync from scratch
**\<fluffypony>** iirc smooth has a broken conversion that we can use to analyse the issue
**\<fluffypony>** 810 and 775 are dangling
**\<fluffypony>** moneromooo: do you want those to stay open at present ?
**\<moneromooo>** 810 might be cancelled, not sure.
**\<fluffypony>** ok
**\<moneromooo>** 775 is ready AFAIK.,
**\<fluffypony>** ok will test it
**\<fluffypony>** 818 is in a holding pattern pending some discussion; based on what shen has been doing lately my feeling is that we leave that till after RingCT is done
**\<fluffypony>** on that note, RingCT seems to be pushing ahead quite nicely
**\<fluffypony>** moneromooo: how's it looking from your side ?
**\<moneromooo>** I'm not a cryptographer, so I got no clue really :P
**\<fluffypony>** hah hah
**\<moneromooo>** Once I figure out what goes where, it's just code after that.
**\<fluffypony>** I know you're waiting for input from shen, but is it starting to make a bit of sense ?
**\<moneromooo>** Though a lot of it I think
**\<fluffypony>** kk
**\<moneromooo>** Mot yet, but I've not spent a lot of time on it today (and yesterday I was out).
**\<fluffypony>** alright
**\<saddam>** moneromooo: I want to decrypt it manually so I can detect transactions sent to an integrated address of mine in the tx pool. Is there another way to do it?
**\<fluffypony>** then next weekend I'll be at Bitcoin in Use in Arnhem, Netherlands
**\<moneromooo>** How will you know it's an integrated address of yours in the first place ?
**\<fluffypony>** and there will be several other Monero-er-ains there as well
**\<fluffypony>** including some devs, most notably hyc
**\<xmrpromotions>** a few ppl told me they want to meet you there:)
**\<saddam>** oh it's the meeting, sorry. I'll wait to discuss that later moneromooo
**\<fluffypony>** if anyone else is going to be there please let me know, we can do a Monero supper on the Saturday or something
**\<fluffypony>** next up is a chat about documentation
**\<fluffypony>** wallet42 has raised the idea of opening up the wiki on Github
**\<xmrpromotions>** https://twitter.com/Falkvinge/status/731833882102910977 wants to meet you too
**\<fluffypony>** the advantages of this is that it keeps the documentation close to the code
**\<fluffypony>** and you can PR to the wiki or (I think) edit it inline
**\<fluffypony>** xmrpromotions: oh neat
**\<fluffypony>** in fact, the wiki creates a .wiki.git project that's invisible-ish
**\<fluffypony>** so it makes syncing to GitLab easy (setting up a GitLab mirror is on the list of things to do)
**\<fluffypony>** downside is that you can't edit it anonymously, although creating a GH account is trivial
**\<fluffypony>** and the other downside is that we have tons of scattered documentation right now
**\<fluffypony>** so my thinking is that the wiki is a good idea for documentation, BUT then we need to kill off all these other sources of info
**\<dEBRUYNE>** ^ I don't mind putting part of it together
**\<fluffypony>** so the Monero wikia has to be shuttered and that info moved over
**\<ArticMine>** There is information all over BCT
**\<dEBRUYNE>** we could put the guides from Moneroexamples over there too, but he doesn't necessarily have to shutdown his "source" imo
**\<fluffypony>** same goes for dev guides etc. on the website - we should instead spend the effort writing a small Ruby plugin for the site that pulls in info from the wiki and formats it appropriately
**\<fluffypony>** then the wiki becomes a primary source of info
**\<fluffypony>** dEBRUYNE: yeah we could do the same thing with MoneroExamples
**\<fluffypony>** just have a plugin that grabs it from his repos and formats it
**\<fluffypony>** if anyone has an issue with this speak now or forever hold your peace
**\<i2p-relay>** {-anonimal} Such consolidation sounds like a good idea.
**\<dEBRUYNE>** fluffypony: Yeah that'd be fine too
**\<dEBRUYNE>** as long as it consolidates the information to a central place it's fine
**\<fluffypony>** I'll leave the question open till the start of the Kovri meeting, if nobody has major objections raised by then I'll consider the decision in favour of the GitHub wiki
**\<ArticMine>** It is actually really needed We have info all over the place
**\<fluffypony>** (we discussed this here a few days ago as well, and everyone generally seemed in favour of it)
**\<fluffypony>** ArticMine: agreed
**\<xmrpromotions>** I like the idea. Consolidation and simplification should hopefully encourage more people to contribute to it
**\<fluffypony>** that's it from my side - next meeting will be on the 5th of May, same time
**\<fluffypony>** if anyone has anything they want to discuss, or any other points they want to bring up, now's the time
**\<fluffypony>** we have 20-ish minutes till the Kovri meeting
**\<ArticMine>** I am looking at the fee structure
**\<moneromooo>** Does anyone fancy hacking the pool code to check top hash ?
**\<moneromooo>** It shold be fairly easy.
**\<i2p-relay>** {-anonimal} fluffypony: s/May/June/
**\<dEBRUYNE>** ArticMine: Is your research going to be put in a somewhat formal paper?
**\<moneromooo>** er, s/hacking/amending/ for the peanut gallery.
**\<ArticMine>** I'll start with a post on getmonero forum to get feedback ideas
**\<ArticMine>** then one can develop a paper
**\<dEBRUYNE>** all right
**\<ArticMine>** Along the lined of my prior post on BCT regarding the adaptive block limit and penalty function. There are issues with respect to to many options in fees with RingCT
**\<dEBRUYNE>** Is anyone willing to work on adding Monero to Bitsquare? Afaik it's only a few minor tweaks in the UI code, see issue here -> https://github.com/bitsquare/bitsquare/issues/392 | I might be able to try if I got some more time, emphasis on try though
**\<fluffypony>** anonimal: thanks, lol
**\<moneromooo>** To th UI of... ?
**\<dEBRUYNE>** Bitsquare itself
**\<dEBRUYNE>** It needs an additional field for the tx key
**\<moneromooo>** Ah, I just saw the screenshot.
**\<dEBRUYNE>** It's mainly to resolve disputes, if any occur
**\<dEBRUYNE>** Btw fluffypony, any ETA on a new point release that includes the performance branch? Or are we awaiting any more PRs?
**\<gingeropolous>** ArticMine, i look forward to the adaptive fee structure thread
**\<luigi1112>** Oh high team
**\<luigi1112>** Hi team too
**\<gingeropolous>** hi luigi1112
**\<fluffypony>** dEBRUYNE: more PRs, also gives us time to see if there are issues with auto-convert
**\<fluffypony>** *more issues
**\<xmrpromotions>** hi luigi1112
**\<moneromooo>** What would I do if I wanted to try and repro that problem ? just pull, build, run ?
**\<dEBRUYNE>** fluffypony: all right
**\<gingeropolous>** im just curious... is 0mq gonna happen before ringCT? or ... or all at once?
**\<fluffypony>** moneromooo: yeah
**\<fluffypony>** gingeropolous: no clue
**\<moneromooo>** I'm certainly doing nothing about it.
**\<gingeropolous>** well there's months until the next hardfork... though i guess 0mq doesn't affect consensus protocols?
**\<dEBRUYNE>** well it was either Ring CT or 0MQ for you afaik moneromooo and I think we decided last time that Ring CT was the priority (this is just to clarify to anyone reading)
**\<fluffypony>** ok starting the meeting relay for the Kovri meeting

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

@ -0,0 +1,241 @@
---
layout: post
title: Logs for the Kovri Dev Meeting Held on 2016-06-05
summary: I2P StackExchange update, website content, Coverity issues, GNU social
tags: [dev diaries, i2p, crypto]
author: dEBRUYNE / fluffypony
---
*June 5th, 2016*
# Logs
**\<fluffypony>** ok so I think let's move on to Kovri - anonimal, the floor is yours
**\<meeting-bot> [anonimal]** Thanks fluffypony, I need about 30-60 seconds.
**\<fluffypony>** ok whilst you're doing that, there are two committers to the Monero StackExchange proposal that are just shy of 200+ rep on the Bitcoin StackExchange
**\<fluffypony>** so they need some upvotes if you have rep on the BTC StackExchange
**\<meeting-bot> [anonimal]** https://github.com/monero-project/kovri/issues/179
**\<meeting-bot> [anonimal]** 17:00 (UTC)
**\<fluffypony>** http://bitcoin.stackexchange.com/users/35760/dontmindme
**\<meeting-bot> [anonimal]** 1. Follow up on I2P StackExchange
**\<meeting-bot> [anonimal]** 2. Follow up on fluffypony's website content review
**\<fluffypony>** http://bitcoin.stackexchange.com/users/35975/jun-li
**\<meeting-bot> [anonimal]** 3. Follow up on Coverity
**\<meeting-bot> [anonimal]** 4. Review assigned open tickets: status, code ideas (if applicable), etc.
**\<meeting-bot> [anonimal]** 5. Any additional meeting items
**\<meeting-bot> [anonimal]** 6. Confirm next meeting date/time
**\<meeting-bot> [anonimal]** Point 1. is open to all.
**\<fluffypony>** i2p StackExchange is doing well: http://area51.stackexchange.com/proposals/99297/i2p
**\<meeting-bot> [anonimal]** Where do we stand?
**\<fluffypony>** 29% committed
**\<fluffypony>** 34/100 committers with 200+ offsite rep
**\<fluffypony>** but considering the small number of total committers (78/100) that's pretty impressive
**\<moneromooo>** I will have 200 tomorrow, probably. 1% more.
**\<fluffypony>** I would like to encourage anyone that has committed to the i2p and Monero proposals to please try drum up 200+ rep on one of the other Stacks by asking and answering questions
**\<meeting-bot> [anonimal]** Good, I was about to ask what else we could do.
**\<meeting-bot> [anonimal]** I'll start banging.
**\<fluffypony>** it's REALLY easy to get that much rep, the fastest way I've found is answering questions
**\<fluffypony>** but pick ONE StackExchange, as the rep isn't cumulative across Stacks
**\<meeting-bot> [anonimal]** Ok, anything else for point 1?
**\<fluffypony>** yes just a small thing
**\<xmrpromotions>** How do you feel about reaching out to leaders in the Tor community to request support? Some may be curious about I2P and active Tor SE users will really help us with activity requirements after launch
**\<fluffypony>** the deep web StackExchange proposal has failed due to lack of follow-through on commitments, so the i2p one is more necessary than before
**\<meeting-bot> [anonimal]** Hmm, tricky.
**\<fluffypony>** xmrpromotions: that's certainly a possibility, but the Tor community is going through a bit of a difficult time at the moment, it may be prudent for us to wait it out
**\<meeting-bot> [anonimal]** How do I say this quickly,
**\<fluffypony>** anonimal: by typing fast? :-P
**\<meeting-bot> [anonimal]** I have a strong impression that Tor does not care about I2P.
**\<meeting-bot> [anonimal]** Nothing personal, just different technologies.
**\<xmrpromotions>** If you are talking about the applebaum allegation I agree the timing is not great. I plan to largely ignore that news for now since the evidence is not even public
**\<meeting-bot> [anonimal]** I agree with fluffypony for now.
**\<meeting-bot> [anonimal]** I'd like to come back to that idea though in the future.
**\<xmrpromotions>** Okay. I wont make any aggressive outreach efforts to the Tor community at this time
**\<meeting-bot> [anonimal]** Ok, anything else on 1.?
**\<fluffypony>** nothing from my side
**\<meeting-bot> [anonimal]** 2. fluffypony, last meeting we talked about website content,
**\<meeting-bot> [anonimal]** I sent a draft. Status?
**\<fluffypony>** I have a content dump from anonimal - I've started with a page to the Monero site, and hope to have it PR'd by next weekend
**\<fluffypony>** I go to Berlin on Tue and then back to Amsterdam on Wed, and then back to Johannesburg on Thur, so there will be plenty of bored-in-the-plane opportunities to work on it
**\<meeting-bot> [anonimal]** Ok, I hope to get a chance to review anything because what I sent really was a 'dump' ;)
**\<fluffypony>** oh yeah definitely, plus you can always PR changes to the site, we merge everything there :-P
**\<meeting-bot> [anonimal]** lol
**\<meeting-bot> [anonimal]** Ok, anything else on 2.?
**\<xmrpromotions>** does 2 include gnu social or just the website?
**\<meeting-bot> [anonimal]** Free-for-all.
**\<meeting-bot> [anonimal]** xmrpromotions: any updates on gnu social?
**\<xmrpromotions>** Well I read up on GNU Social and really like the idea (I had not heard of it before) but I am worried about the time commitment it will involve to do well
**\<meeting-bot> [anonimal]** Could it be done 'good enough'?
**\<xmrpromotions>** Any suggestions for volunteers eager to help with that sort of thing that have extra free time right now
**\<meeting-bot> [anonimal]** I can help when the time comes.
**\<xmrpromotions>** I guess it depends what good enough means. I have never used GNU software but assume it will require many contributors providing good content in order to attract many users
**\<meeting-bot> [anonimal]** I've ran an instance in the past (personal, not public).
**\<fluffypony>** dEBRUYNE: is anyone on the social media team available to assist ?
**\<merkaba>** what is it about? I have some free time but I am not sure what this is
**\<merkaba>** if I have the skills required..
**\<fluffypony>** merkaba: oh I have a special job for you if you want to flex your Ruby skills ;)
**\<merkaba>** btw I am stefioan from reddit
**\<merkaba>** cool
**\<dEBRUYNE>** fluffypony: I am running out of free time currently, so hopefully someone else could pick it up (e.g. xmrpromotions and/or merkaba)
**\<nobbynoob>** what exactly is needed as help in the gnu social thing?
**\<meeting-bot> * anonimal** was just about to ask that
**\<xmrpromotions>** People to provide quality content and invite users is needed the most IMHO
**\<xmrpromotions>** I am not an expert and had not heard of it until 2 weeks ago
**\<nobbynoob>** so no coding or stuff, but posting content about xmr, its development etc?
**\<xmrpromotions>** here is the example someone gave me: https://quitter.se/social details here: https://gnu.io/social/about/
**\<meeting-bot> [anonimal]** Can twitter posts be cross-posted?
**\<xmrpromotions>** we are talking about Kovri now but yes we could use it for Monero too
**\<fluffypony>** maybe not automatically, anonimal, but certainly manually
**\<meeting-bot> [anonimal]** "If you build it, they will come".
**\<meeting-bot> [anonimal]** Why not baby steps for now: get it up and running, and we'll get on it and start using it?
**\<fluffypony>** agreed
**\<meeting-bot> [anonimal]** xmrpromotions: ETA on when it can be physically online?
**\<fluffypony>** xmrpromotions: shout if you need me to host it on one of the Monero infrastructure servers
**\<meeting-bot> * anonimal** side-channels fluffypony for preparations of 3. https://scan.coverity.com/projects/monero-project-kovri?tab=overview
**\<xmrpromotions>** I have not made any efforts to do that yet but my impression is pretty quick. All I did since last meeting was read the basic description of it and look at a few examples of how it has been deployed
**\<meeting-bot> [anonimal]** Can it be up by next meeting?
**\<xmrpromotions>** I think that is realistic.
**\<xmrpromotions>** It sounds like others will be willing to help provide content.
**\<meeting-bot> [anonimal]** Excellent.
**\<meeting-bot> [anonimal]** I'll start using it once its up.
**\<meeting-bot> [anonimal]** Anything else on point 2.?
**\<fluffypony>** nein
**\<meeting-bot> [anonimal]** Ok moving on to 3.
**\<meeting-bot> [anonimal]** "No builds were successfully analyzed yet."
**\<meeting-bot> [anonimal]** So, it looks like more Coverity setup issues.
**\<xmrpromotions>** thank you. I just dont want to spread myself too thin. The Deep web SE shutting down concerned me. We need to learn from that and ensure I2P and Monero SE metrics are all continually high enough during private beta
**\<fluffypony>** anonimal: argh. it's like they're trying to irritate me.
**\<meeting-bot> [anonimal]** xmrpromotions: good point, I will work on my rep.
**\<meeting-bot> [anonimal]** fluffypony: seriously, I have no idea why its so problematic.
**\<fluffypony>** anonimal did you see the hello world example ?
**\<meeting-bot> [anonimal]** Directions were followed to the T.
**\<meeting-bot> [anonimal]** fluffypony: Maybe, a long while ago. Link?
**\<fluffypony>** https://github.com/daksheshvyas/MyHelloWorld/
**\<fluffypony>** https://travis-ci.org/daksheshvyas/MyHelloWorld/
**\<fluffypony>** maybe check if there's not something they do there that we haven't done
**\<meeting-bot> [anonimal]** I remember those.
**\<meeting-bot> [anonimal]** Nope, our config checks out AFAICT.
**\<fluffypony>** https://scan.coverity.com/faq#frequency
**\<fluffypony>** we're way under teh frequency limits
**\<meeting-bot> [anonimal]** Is yrashk still on that side? Maybe he uses coverity/travis-ci?
**\<fluffypony>** he's already hopped offline afaik
**\<fluffypony>** it's nearly 1am his time
**\<meeting-bot> [anonimal]** I've also done several merges to branch coverity_scan to 'trigger' it, but to no avail.
**\<meeting-bot> [anonimal]** fluffypony: Any ideas on solutions? They really don't make it easy to contact them for troubleshooting.
**\<fluffypony>** hmmm anonimal
**\<fluffypony>** "You'll need to manually fill in your project specifics, including build_command_prepend and build_command."
**\<fluffypony>** we don't have the build_command_prepend
**\<fluffypony>** could that be a requirement ?
**\<meeting-bot> [anonimal]** I highly doubt it.
**\<fluffypony>** nothing would surprise me at this stage :-P
**\<tewinget>** saw my mention, will be available in...10 min or so if anyone needs me or wants my input on something. Otherwise, hello everyone and enjoy the meeting or whatever.
**\<fluffypony>** anonimal: so "branch_pattern: coverity_scan" means it'll only build changes to the branch named coverity_scan, noto the master branch
**\<meeting-bot> [anonimal]** Yes.
**\<fluffypony>** ok
**\<meeting-bot> [anonimal]** And last merge into coverity_scan was May 29th.
**\<fluffypony>** maybe we should just include a build_command_prepend
**\<fluffypony>** something like cd build && make clean
**\<meeting-bot> [anonimal]** But what would we put? exporting variables?
**\<fluffypony>** the example has:
**\<fluffypony>** build_command_prepend: "./configure; make clean"
**\<fluffypony>** build_command: "make -j 4"
**\<fluffypony>** maybe add a && cd ..
**\<meeting-bot> [anonimal]** Which doesn't make sense if the VM is fresh before every build.
**\<meeting-bot> [anonimal]** The build_command is sound, it would literally be a matter of splitting that up.
**\<fluffypony>** anonimal: yet the example has "make clean", so maybe they don't have a fresh VM each time ?
**\<meeting-bot> [anonimal]** so build_command_prepend: export CC=gcc-${GCC_VERSION} CXX=g++-${GCC_VERSION} && cd build
**\<fluffypony>** that could work if we're 100% sure it's a fresh VM
**\<meeting-bot> [anonimal]** It is. You can see it in all the travis build logs.
**\<fluffypony>** and Coverity runs on the Travis VM right ?
**\<meeting-bot> [anonimal]** Apparently?
**\<meeting-bot> [anonimal]** So, we could keep tinkering and hope for a result or email scan-admin@coverity.com
**\<meeting-bot> [anonimal]** Thoughts?
**\<merkaba>** guys I am leaving. if I can be help on any task feel free to contact me on reddit (/u/stefioan)
**\<fluffypony>** merkaba: will do, thanks
**\<meeting-bot> [anonimal]** Thanks merkaba.
**\<merkaba>** you are welcome
**\<fluffypony>** anonimal: I think let's try including a build_command_prepend, failing that I'll have to try reach out to Coverity
**\<fluffypony>** seeing as how they were so helpful last time
**\<fluffypony>** :-P
**\<xmrpromotions>** thanks merkaba. lets talk more about gnu social later
**\<meeting-bot> [anonimal]** merkaba:
**\<meeting-bot> [anonimal]** Isn't diaspora written in ruby?
**\<meeting-bot> * anonimal** checks
**\<fluffypony>** anonimal: he already left unfortunately
**\<meeting-bot> [anonimal]** xmrpromotions: if you see them again, https://github.com/diaspora/diaspora
**\<meeting-bot> [anonimal]** Ok fluffypony, I'll make the change and we'll see what happens.
**\<meeting-bot> [anonimal]** Anything else on 3.?
**\<fluffypony>** nope
**\<meeting-bot> [anonimal]** Alright, 4. Review assigned open tickets: status, code ideas (if applicable), etc.
**\<meeting-bot> * anonimal** quickly pulls up
**\<meeting-bot> [anonimal]** Ok, 4 new tickets opened since last meeting. All by yours truly.
**\<meeting-bot> [anonimal]** Joyous #187 and #191.
**\<meeting-bot> [anonimal]** Would any of the talented Monero devs be interested in diving into Kovri?
**\<meeting-bot> [anonimal]** I think those two tickets would be a great intro into the project (not being sarcastic).
**\<fluffypony>** lol @ 191
**\<fluffypony>** "but that is not the real problem"
**\<meeting-bot> [anonimal]** lol
**\<xmrpromotions>** https://diasporafoundation.org/ looks interesting! Should we consider that as an alternative to GNU social?
**\<xmrpromotions>** In some ways it sounds better, but does a lack of Windows support hurt us significantly? https://wiki.diasporafoundation.org/Installation
**\<meeting-bot> [anonimal]** xmrpromotions: I personally wouldn't as its harder to maintain and I don't believe it is anonymity friendly (if we host a pod)
**\<meeting-bot> [anonimal]** Diaspora simply crossed my mind since that ruby dev popped in.
**\<meeting-bot> [anonimal]** Anyway, re: 4.,
**\<xmrpromotions>** okay. fair enough. I will keeped focused on gu social then
**\<xmrpromotions>** gnu
**\<meeting-bot> [anonimal]** fluffypony: I can't see who is on that side. Are any c++ devs online?
**\<fluffypony>** hmmm
**\<fluffypony>** not sure if any of them are in front of their keyboards atm, let's leave that open-ended
**\<fluffypony>** if anyone wants to do an FFS proposal for it that's a great option
**\<fluffypony>** since it's easily measurable and challenging in a fun way
**\<meeting-bot> [anonimal]** I'm leaning towards a proposal or two.
**\<meeting-bot> [anonimal]** Ok, I'll see what I can propose before the next meeting.
**\<meeting-bot> [anonimal]** The tickets just keep piling up, help would be nice.
**\<meeting-bot> [anonimal]** Actually, more than nice.
**\<fluffypony>** yeah we're definitely feeling a bit shy on warm bodies on both fronts, will have to shake the ol' C++ cage and see who falls out
**\<meeting-bot> [anonimal]** At some point we'll have to have a meeting dedicated to dev awareness.
**\<meeting-bot> [anonimal]** I understand. I see everyone doing their best so what else could we ask for.
**\<fluffypony>** yup yup
**\<meeting-bot> [anonimal]** Anything else on 4.?
**\<fluffypony>** nope
**\<meeting-bot> [anonimal]** fluffypony: Do you have any formal ideas on #159?
**\<meeting-bot> [anonimal]** s/ideas/strategies
**\<fluffypony>** I had a meeting with Richard Kohl from Bitcoin Wednesday and it came up, I need to think through some of his suggestions and then we can discuss it
**\<tewinget>** anonimal: what about C++ devs online?
**\<tewinget>** fluffypony: what's meeting-bot connecting to?
**\<fluffypony>** tewinget: irc2p
**\<fluffypony>** most C++ devs online want full time work, or overstate their abilities
**\<meeting-bot>** [anonimal] tewinget: ^
**\<meeting-bot>** [anonimal] Or are not really interested but want a payout.
**\<fluffypony>** yup
**\<meeting-bot> [anonimal]** But everyone isn't bad.
**\<meeting-bot> [anonimal]** But we also don't have enough awareness yet, but we're working on that.
**\<tewinget>** Hey, I'm only like 2 out of 3 there!
**\<fluffypony>** yesh
**\<fluffypony>** we'll get there
**\<meeting-bot>** [anonimal] tewinget have you played with Kovri yet?
**\<tewinget>** anonimal: I can't even remember off the top of my head what Kovri is...
**\* tewinget** does a quick google search
**\<tewinget>** oh, that. Not yet, why?
**\<meeting-bot> [anonimal]** lol because that's what the meeting is for :)
**\<tewinget>** I just got up not long ago, haven't had time to read all the scrollback
**\<tewinget>** :)
**\<meeting-bot> [anonimal]** Alright, moving onto 5. Any additional meeting items
**\<meeting-bot> * anonimal** thinking
**\<fluffypony>** nothing off the top of my head
**\<meeting-bot> [anonimal]** Me neither. I'm out of energy but I feel like there was more to discuss.
**\<fluffypony>** we'll push stuff forward, we can discuss anything urgent in the week, else we let it fall to the next meeting
**\<fluffypony>** which will be the 19th, by my calendar
**\<meeting-bot> [anonimal]** Ok. I was hoping to talk more code but devs seem to be away.
**\<meeting-bot> [anonimal]** C++ nerd stuff. Boost enthusiasts.
**\<meeting-bot> [anonimal]** alla Monero.
**\<fluffypony>** let's flip it around for next meeting and do that first
**\<meeting-bot> [anonimal]** Anyway, next time then or during the week.
**\<meeting-bot> [anonimal]** Ok, sounds great.
**\<meeting-bot> [anonimal]** So point 6.,
**\<meeting-bot> [anonimal]** June 19th? 17:00 UTC?
**\<xmrpromotions>** Do you think many people in this group would be interested in I2P or kovri? http://area51.stackexchange.com/proposals/82234/open-source
**\<fluffypony>** anonimal: yup
**\<tewinget>** anonimal: if there's anything specific you can point to as far as C++ goes you can ping me
**\<fluffypony>** xmrpromotions: hard to canvas on an SE propsal
**\<xmrpromotions>** they could use more activity right now in public beta. If we encourage monero and i2p users to participate in their open beta maybe some of them will support us
**\<xmrpromotions>** they lack of ability to direct message makes it harder but some leaders use their real names
**\<fluffypony>** ok meeting is over, killing meeting-bot

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

@ -0,0 +1,277 @@
---
layout: post
title: Overview and Logs for the Dev Meeting Held on 2016-06-05
summary: introduction to C4 by Yurii Rashkovski, brief update on Ring CT and 0MQ
tags: [dev diaries, core, crypto, 0mq]
author: dEBRUYNE / fluffypony / Aerbax
---
*June 5th, 2016*
# Overview
An overview [can be found on Hello Monero](https://hellomonero.com/article/monero-bi-weekly-dev-meeting-note-highlights-2016-06-05)
# Logs
**\<fluffypony>** everyone ready to start? smooth / tewinget / dEBRUYNE / ArticMine / luigi1111w / luigi1112 / luigi1114 / NoodleDoodle / gingeropolous etc.
**\<ArticMine>** yes
**\<fluffypony>** hyc is excused, as he is at Pieter Hintjen's wake
**\* dEBRUYNE** slaps othe, moneromooo
**\<dEBRUYNE>** did we forget anyone? :p
**\<fluffypony>** don't think so
**\* dEBRUYNE** pages redfish
**\<dEBRUYNE>** Think that covers it
**\<fluffypony>** ok cool
**\<moneromooo>** Traditional Dutch greeting ?
**\<fluffypony>** lol
**\<fluffypony>** traditional Dutch greeting = "hallo"
**\<fluffypony>** so to start this meeting off I wanted to introduce yrashk, Yurii Rashkovskii
**\<fluffypony>** he's our special guest for today
**\<moneromooo>** o/
**\<fluffypony>** a little bit of background: as everyone is aware we've been looking at formally adopting C4, the Collective Code Construction Contract
**\<fluffypony>** which 0MQ uses
**\<yrashk>** hey hey
**\<fluffypony>** forgot to start meeting-bot, sorry
**\<fluffypony>** ok
**\<fluffypony>** so
**\<fluffypony>** with Pieter passing the mantel on to others one of the things that has happened is that yrashk has split some of these "soft skills" things off into something called Unprotocols
**\<fluffypony>** and what I wanted is for yrashk to tell us a little bit about C4 and COSS, and talk a bit about how C4 differs from the dreaded CoC - because adopting a CoC is simply not going to happen, but adopting C4 is a much better option
**\<fluffypony>** yrashk: the floor is yours
**\<yrashk>** fluffypony: thanks for the intro!
**\<yrashk>** yeah, actually Pieter has passed the unprotocols.org domain to me as well to play with the idea of extracting C4 and COSS (and more protocols in the future) into a separate domain from ZeroMQ and Digistan projects.
**\<yrashk>** as a side node, I think that action itself was very much in the spirit of C4 — it was a quick decision when I confirmed the fact that I want to volunteer, and the domain was passed over.
**\<yrashk>** what actually has drawn me to C4 was 1) its simplicity and 2) the rules that seemed to lead to less tension between people
**\<yrashk>** it's hardly possible to eliminate those, of course, but it's easy to create "hot spots" unintentionally
**\<yrashk>** I was thinking a lot about situations when things got heated before and when I myself got an urge to say things I later regretted
**\<yrashk>** and I saw that it was often over a value judgement
**\<yrashk>** ("do we need a feature X?" "do we implement it this or that way?" etc.)
**\<yrashk>** on the other hand, I had two arguments against CoC
**\<yrashk>** one was the Opalgate (https://github.com/opal/opal/issues/941), second one was a tad more complex... it felt like it's just a tool to punish or eject people... a guillotine. something not focused on the positive but rather on handling the negative stuff.
**\<fluffypony>** 100% agreed
**\<yrashk>** with C4, the main rules of the game were pretty simple: maintainers can't hold up your patch because of your value judgement
**\<yrashk>** even if it is stupid
**\<yrashk>** by the contract, everybody has a right to contribute
**\<yrashk>** the contributions must get merged in quickly (possibly after passing some sanity tests, like travis ci or a quick glance — that said, Pieter says, merge anything — you'll get a permanent record of trolls as well)
**\<yrashk>** so instead of having a hierarchy of contributors (maintainers' opinion being more important than others' by default), it's rather a flat space where maintainers' role is rather administrative, to enforce the process.
**\<yrashk>** if they (like anyone else) have a value judgment, they can express it either as another PR, or they comment on the patch after the patch got merged in.
**\<yrashk>** no bike shedding, no gatekeeping
**\<yrashk>** everything is record. anything can be easily reverted.
**\<yrashk>** is recorded*
**\<yrashk>** there's, however, an important philosophical principle behind. My current thesis (after conversing with different people) is that those who believe in individual intelligence (as opposed to aggregate group intelligence) have a harder time accepting C4.
**\<yrashk>** I met people who strongly believe that their experience and intelligence justify them being gatekeepers
**\<yrashk>** Pieter does talk about this in his books... basically arguing that individual intelligence applied to a particular work is rather a product of luck, not a systematic thing
**\<yrashk>** another important aspect of C4 that helps justifying just about every incoming PR, is that they are REQUIRED to contain a problem-solution statement (http://rfc.unprotocols.org/spec:1/C4/,section 2.3.7)
**\<fluffypony>** 'A patch commit message MUST consist of a single short (less than 50 characters) line stating the problem ("Problem: ...") being solved, followed by a blank line and then the proposed solution ("Solution: ...").'
**\<yrashk>** if a patch solves a particular problem instead of doing something that "might be helpful" or a "nice thing to do", it's easier to form your own opinion about the patch and see if any corrective measure should be taken
**\<yrashk>** (should I send a reverting PR if it is a total and utter BS? should I help improving this? etc.)
**\<yrashk>** I guess this braindump is good for starters. I'll take questions, if any?
**\<fluffypony>** ok so my first questions when I read C4 was about how it deals with people who are disruptive
**\<moneromooo>** Do you end up with a pile of crap in git, making view diffs a pain, bisect impossible, and generally having to waste time with crap ?
**\<fluffypony>** how does it do so in a non-guillotine manner ?
**\<yrashk>** (also, my short article on the subject https://blog.eventsourcing.com/productive-welcoming-vs-code-of-conduct-656b1571ddd6)
**\<yrashk>** fluffypony: first important thing, the way I understand it, is getting everything logged. merge disruptive people's commits. this way you get a permanent log of their behaviour.
**\<yrashk>** fluffypony: the rest is no different from other approaches: discuss the situation, if a correction can't happen, ban/eject
**\<fluffypony>** yeah I gathered the focus was on people self-correcting instead of being forced to correct
**\<yrashk>** moneromooo: you tell me https://github.com/zeromq/czmq/commits/master (as an example) — but basically, at least in my rationalization behind this, with great powers come great responsibilities
**\<yrashk>** when you treat people like adults, they tend to behave more like adults
**\<yrashk>** resulting in better ORs
**\<yrashk>** PRs*
**\<fluffypony>** I think the worst case scenario is someone submits a PR that intentionally introduces a backdoor, or intentionally breaks things
**\<yrashk>** I see this "optimistic" merge strategy as a way to treat people like adults
**\<fluffypony>** in which case the reverted PR is a black mark against them
**\<moneromooo>** You assume good faith, and a single bad faith person can throw a lot of crap in.
**\<yrashk>** fluffypony: exactly, a permanent record (as opposed to a rejected PR, which might be lost over time)
**\<fluffypony>** moneromooo: the issue is that doing it the *other* way means a bad faith person can waste everyone's time
**\<yrashk>** moneromooo: just like anybody can throw a lot of crap in, it can be thrown own the same way
**\<moneromooo>** But why would we want a permanent record of spam patches in the first place ?
**\<ArticMine>** So the concept is it is easy to undo / revert damage while leaving a cleat and objective trail for community accountability
**\<moneromooo>** yrashk: I'm worried about the history here, not the snapshot.
**\<yrashk>** moneromooo: because that helps identifying the bad actors at a later point ("yup, known spammer")
**\<moneromooo>** I imagine someone wanting to DoS us would not use the same email over and over again. They're good at sock puppets.
**\<yrashk>** it's a bit like a TSA thing — assume any passenger can be a terrorist and check everybody or do the intelligence work to single out bad actors.
**\<moneromooo>** Appeal to emotion.
**\<yrashk>** moneromooo: I guess it is highly dependent on the nature of the project — how many bad actors are actually interested to disrupt the project
**\<fluffypony>** moneromooo: consider it this way - if I'm compiling every-single-PR on every-single-platform and then testing-each-platform that's like an 2-3 hours per PR
**\<fluffypony>** so how easy is it to waste my time :-P
**\<yrashk>** that's actually a worse DoS
**\<moneromooo>** Do you do that ?
**\<yrashk>** time is the most valuable thing
**\<yrashk>** well, any PR review takes time
**\<yrashk>** and delays releases further
**\<fluffypony>** moneromooo: not since we've introduced that brief-code-review process, I just merge based on a visual inspection or a review by some known contributor
**\<fluffypony>** someone will compile it and see it's broken, and that someone doesn't have to be me
**\<yrashk>** C4 doesn't actually say the code should not be reviewed
**\<moneromooo>** I think there are a large number of possible positions between "compile every single PR and test on all platforms" and "rubber stamp everything". For instance, "have a look and reject if it doesn't pass the smell test".
**\<yrashk>** it's just done after the merging
**\<fluffypony>** moneromooo: we'll still have smell tests
**\<moneromooo>** That seems good to be ("I just merge based on a visual inspection or a review by some known contributor").
**\<moneromooo>** (and I try to review those fwiw)
**\<fluffypony>** also the action AFTER a failed smell test is important
**\<fluffypony>** ie. do we then have a long, drawn-out convo on github
**\<fluffypony>** or do we merge and revert, then explain to the person why that happened
**\<moneromooo>** As for building, you said you'd like a build bot IIRC. That'd help a lot there.
**\<moneromooo>** But the things I'm worried about are not held off by a build check.
**\<yrashk>** I use travis-ci so I can quickly see if PR breaks existing tests
**\<fluffypony>** yeah a build check solves a small subset of issues, 100% moneromooo
**\<moneromooo>** Maybe I'm paranoid, but I totally see part of the BCT jerks spamming our tree just because.
**\<yrashk>** do they do this right now?
**\<moneromooo>** Not to my knowledge.
**\<fluffypony>** moneromooo: it's MUCH easier to deal with that if we merge-and-revert than if we analyse and have long github discussions
**\<yrashk>** one of the main ideas behind C4 is to incentivize the positive contributors to get their stuff in quickly, without painless waiting and discussions
**\<yrashk>** I've beed in a situation where it just becomes so painful to abide by all the maintainers' wants to get something in
**\<fluffypony>** https://github.com/bitcoin/bitcoin/pull/5905
**\<fluffypony>** that PR is over a year old
**\<yrashk>** or when the maintainers are busy with other projects, or don't care about a particular problem enough to get my stuff in quickly
**\<yrashk>** without painful waiting*
**\<fluffypony>** and there are lots like that - full of discussion, "concept ACKs" and so on
**\<dEBRUYNE>** \<moneromooo> As for building, you said you'd like a build bot IIRC. That'd help a lot there. <= Zcash has a build bot afaik, might want to look into that
**\<fluffypony>** we use travis on Kovri
**\<moneromooo>** What are the problems now, beyond fluffypony's time ?
**\<fluffypony>** but hoping for a more OS-complete buildbot
**\<yrashk>** the other way to look at it — with C4, you have *all contributors* as reviewrs
**\<yrashk>** not just a handful of maintainers
**\<yrashk>** because everybody can initiate a corrective action
**\<fluffypony>** moneromooo: the main problem is that we don't want to become exclusionary, where only a handful of special contributors actually have successful PRs
**\<moneromooo>** That would not happen if there is a large enough numbers of people who can review and ack something.
**\<moneromooo>** And doing so would not need so muvch time from you either.
**\<yrashk>** yet another way to look it, if you have gatekeepers, they *would* have biases of different kind when looking at a patch, conscious or subconscious; C4 helps making project more diverse as value judgement or more subtle biases don't affect the input.
**\<yrashk>** (speaking of C4 vs CoC)
**\<moneromooo>** What is CoC ?
**\<yrashk>** Code of Conduct
**\<fluffypony>** moneromooo: Bitcoin has significant numbers of people that can review and ACK, yet there are 102 open PRs stuck in PR-review-hell
**\<yrashk>** CoC is about prohibiting certain types of behaviours and topics
**\<moneromooo>** This may be so, but I do not believe a free for all is better.
**\<yrashk>** in the name of attracting a more diverse set of contributors
**\<moneromooo>** (or at least, not before we have that problem)
**\<yrashk>** while removing gatekeeping/biases from reviews gets diverse opinions in proactively
**\<yrashk>** at least that's the hypothesis
**\<fluffypony>** moneromooo: ok so consider this: what would we do if a PR was submitted from an unknown person that increases the block time to 4 minutes
**\<moneromooo>** Bias is a fair point, but if there are many reviewers, then that should not matter much, iunless they all have the same ones. And if they do, maybe there is a good reason.
**\<merkaba>** (I know you guys are in the middle of other stuff. don't mind me. If there is anything I can help with I am ruby developer)
**\<moneromooo>** That'd probably fork at once.
**\<yrashk>** moneromooo: many projects are started by very small teams that are likely to be less diverse. therefore original maintainers might have similar biases.
**\<fluffypony>** moneromooo: I mean, would we merge the PR, or not ?
**\<fluffypony>** hi merkaba, and welcome :)
**\<yrashk>** I think in the case of this PR (block time), first important thing to consider is "does it have a valid problem/solution statement"
**\<moneromooo>** I'd hope not, but you're not allowed to then magic other assumptions after I said that :)
**\<yrashk>** maybe there's a problem nobody thought about?
**\<merkaba>** fluffypony, thank you
**\<ArticMine>** Then the question becomes is the problem valid?
**\<moneromooo>** If there's a problem nobody thought about, surely a reviewer would ack it ?
**\<fluffypony>** moneromooo: so the only difference under C4 is that we merge-and-revert and then tell the committer that they have to at least discuss something that controversial on the forum or on reddit or in dev meetings or something
**\<moneromooo>** So, same result, except a spammed git history ?
**\<moneromooo>** I *do* use git history :/
**\<fluffypony>** but spammed for a reason
**\<fluffypony>** a revert won't affect git bisect / git blame, I don't think ?
**\<moneromooo>** It will affect blame I think. It will certainly affect bisect time.
**\<moneromooo>** Regardless, I object to it for other grounds anyway (it seeming like shooting ourslves in the foot).
**\<fluffypony>** I think that maybe extreme examples like "change the block time" are bad for what I'm trying to illustrate
**\<moneromooo>** If/when there is a problem with people's patches being held up, and this causing contributors to become dissatisfied, we can talk about it again.
**\<moneromooo>** But then, the solution *should* consider something not totally at the extreme of "let's merge anything".
**\<fluffypony>** but moneromooo, I think we can do the opposite of "possibly causing dissatisfied contributors" - I think we can be extremely welcoming to contributors
**\<ArticMine>** Is a middle ground possible here?
**\<moneromooo>** That'd seem to be a great idea. I find monero very welcoming tbh.
**\<fluffypony>** well the current pitch is "let's merge everything once it's been reviewed by a known contributor"
**\<redfish>** what is the goal of introducing a new contribution guideline? what problem is being addressed here? attracting potential contributors? treating dissatisfied contributors?
**\<fluffypony>** so we still have that firewall
**\<fluffypony>** redfish: it's about establishing protocol that will survive through to when we have 500+ contributors
**\<moneromooo>** Do you mean "we'd still have" ?
**\<fluffypony>** moneromooo: yes I do
**\<fluffypony>** I hate the idea of "dev worship", where a single contributor is lorded over others, or viewed as being able to cure cancer
**\<moneromooo>** Then I agree. I was iunder the impression that there'd be no review by a known contributor. Sorry about that :D
**\<fluffypony>** to the exclusion of newcomers
**\<yrashk>** C4 kind of helps addressing the "problem of elders"
**\<redfish>** a newcomer can be dissuaded by review-block, but the newcomer should really have thicker skin
**\<redfish>** be careful of working with a strawmen for a newcomer contributor
**\<moneromooo>** 17:35 \<@fluffypony> moneromooo: not since we've introduced that brief-code-review process, I just merge based on a visual inspection or a review by some known contributor
**\<expez>** Code review on github is often about increasing code quality. Most contributors aren't cpp experts. If you just merge everything the code quality in the project will gradually decrease until changes become very hard. Or the regular contributors will have to cleanup the area they want to change prior to doing the work the actually wanted. This means a few bad apples will slow everyone down.
**\<redfish>** the attitute of "you don't want my patch? then, fuck you all" should not be encouraged
**\<moneromooo>** Then:
**\<moneromooo>** 17:53 \<@fluffypony> well the current pitch is "let's merge everything once it's been reviewed by a known contributor"
**\<moneromooo>** And:
**\<moneromooo>** 17:54 \< moneromooo> Do you mean "we'd still have" ?
**\<moneromooo>** 17:54 \<@fluffypony> moneromooo: yes I do
**\<moneromooo>** So I don't see what would change, then.
**\<expez>** If there's no discussion, just accept or revert, only the experts will make contributions whereas with some guidance a lot more would've been able to.
**\<moneromooo>** Currently: an ack by a known contributor.
**\<fluffypony>** expez: so by the same token every technical / scientific / medical article on Github should have declining quality until it's illegible garbage :-P
**\<expez>** fluffypony: I can't speak to that. I haven't seen any articles written by acretion.
**\<fluffypony>** I jest - I'm not suggesting the code be written by Wikipedia contributors
**\<fluffypony>** but let me use a practical example
**\<fluffypony>** a new contributor submits a new feature, but it breaks the Windows build and also doesn't include unit tests
**\<fluffypony>** option 1 is that we back-and-forth on his PR until he has it "perfect" by some undefined definition of perfection
**\<fluffypony>** this leads to ANY contributor being frustrated, because they've put in effort and maybe they don't even have a Windows box to work on
**\<fluffypony>** if, instead, we merge the PR and then create an issue for the broken Windows build + issues for the lack of tests, then ANYONE can fix those
**\<fluffypony>** not just the original contributor
**\<yrashk>** I think you really nailed it here: "undefined definition of perfection"
**\<moneromooo>** Dude. Why do you always present the alternative as the other extreme ? This is also a problem, but we don't have it right now.
**\<redfish>** anyone can push commits on top of a PR branch
**\<fluffypony>** redfish: yes they can, but until when ?
**\<redfish>** until the build is fixed and the unit tests pass
**\<meeting-bot> [anonimal]** Kovri meeting starts now but everyone is on a roll - and I'd like to read this huge backlog :)
**\<fluffypony>** moneromooo: sure, but that's like saying we shouldn't adopt any sort of governance structure because we're "too small for governance"
**\<moneromooo>** Not really. Maybe a bit.
**\<yrashk>** fluffypony: I decided to adopt C4 at eventsourcing.com before it's actually needed — the later you are the harder it is to change the governance
**\<fluffypony>** ^^
**\<moneromooo>** OK, that is a fair point.
**\<fluffypony>** literally the only change from a contributor perspective is you have to include a Problem...Solution statement
**\<moneromooo>** But we could adopt a governance that's not as seemingly footgun.
**\<fluffypony>** nothing else changes
**\<moneromooo>** Not the merge it all and revert at once ?
**\<fluffypony>** that affects those with push rights, not contributors as a whole
**\<fluffypony>** and because we're small we'll probably not even follow that to the letter all the time
**\<fluffypony>** BUT we'll have a documented process which contributors will be able to find and understand
**\<ArticMine>** There is a difference between a controversial change to the social covenant and failure to build for a particular OS
**\<yrashk>** in fact, C4 adds a review layer of a sort for "proven" maintainers as you can't push to master directly
**\<fluffypony>** ArticMine: agreed
**\<fluffypony>** http://oss-watch.ac.uk/resources/governancemodels <- this is a good read
**\<yrashk>** but other maintainers have to merge your PR in
**\<fluffypony>** from that article:
**\<lpaalp1>** hello
**\<moneromooo>** hi
**\<fluffypony>** "It is never too soon to define a suitable governance model. Without one, the chances of third parties wishing to contribute are considerably reduced. This is for a number of reasons:
**\<fluffypony>** - potential contributors will not know how to contribute
**\<fluffypony>** - they will not be sure what will happen to their contribution
**\<fluffypony>** - the project will not look serious about engaging with third parties
**\<fluffypony>** - there is no visible assurance that contributions will be managed in such a way that they will remain of value to the original contributor
**\<fluffypony>** Since you never know when a contributor might stumble upon your project, it is important to be ready from the earliest possible date."
**\<moneromooo>** "the project will not look serious about engaging with third parties" sounds like bullshit.
**\<fluffypony>** you'd be surprised by how many people who code for a living are afraid to submit a PR, moneromooo
**\<moneromooo>** The rest, OK.
**\<fluffypony>** we have fluffy ponies and cows and all sorts, not everyone wants to be in the middle of a farmyard
**\<moneromooo>** That may be so, but the sentence doesn't really mention that.
**\<redfish>** this quote assumes strawman for a contributor
**\<fluffypony>** hi lpaalp1 :)
**\<redfish>** imho, the danger from a troll newcomer is greater than a danger from a biased old-timer
**\<fluffypony>** redfish: C4 provides options to deal with trolls that don't self-correct
**\<moneromooo>** I'm totally fine with having a CONTRIBUTING file, or HTML page somewhere, etc, fwiw.
**\<fluffypony>** and it does so in a way that is least disruptive to the community as a whole
**\<moneromooo>** Well, I do not agree with this, since the harm to history has already been done.
**\<moneromooo>** (assuming we're back to merge-first, rather htan wait for an ack from a well known contributor)
**\<fluffypony>** no we're not back to that, lol
**\<fluffypony>** the review-first model still stays, we're just bolting C4 on top of that
**\<fluffypony>** at any rate, we've gone significantly over time, and we've only had one point for discussion, lol
**\<moneromooo>** OK. I feel like I'm being lied to here for some reason...
**\<fluffypony>** I think let's bounce this around over the next two weeks
**\<moneromooo>** Maybe because the discussion about it months ago was merge first.
**\<fluffypony>** and then at the next dev meeting we can make a decision if everyone is comfortable
**\<fluffypony>** moneromooo: that hasn't changed, we've just added the eyeball-review bit per the discussion with smooth ages ago
**\<moneromooo>** OK. Thanks.
**\<ArticMine>** Yes this needs a lot more thought and discussion before a decision is made
**\<fluffypony>** yes absolutely
**\<fluffypony>** so before we move on to Kovri
**\<fluffypony>** two quick things
**\<fluffypony>** 1. moneromooo - can you give us a brief update on how the RingCT stuff is going
**\<fluffypony>** and 2. dEBRUYNE wanted to discuss 0MQ briefly
**\<fluffypony>** also thanks for attending yrashk - much to think about and discuss :)
**\<moneromooo>** Well, I'm getting to know it. I'm hacking on bits at a time, so I get to learn bits of it at a time.
**\<yrashk>** fluffypony: thanks for having me!
**\<moneromooo>** It's progressing anyway.
**\<dEBRUYNE>** re: 0MQ -> tewinget is going to pick that up (i.e. continue). I am drafting the FFS proposal on his behalf and hope to put it out soon (probably at latest by monday/tuesday).
**\<fluffypony>** moneromooo: do you need any extra help, or are you ok with things at the moment ?
**\<moneromooo>** Rewrite, not contunue, AFAIK.
**\<moneromooo>** I'm ok with it, but I'll have questions for shen, most certainly.
**\<fluffypony>** kk
**\<fluffypony>** ok so I think let's move on to Kovri - anonimal, the floor is yours
**\<dEBRUYNE>** \<moneromooo> Rewrite, not contunue, AFAIK. <= Correct. Rewrite is in a sense also continue right? :P

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

@ -0,0 +1,294 @@
---
layout: post
title: Logs for the Kovri Dev Meeting Held on 2016-06-19
summary: Brief review of what has been completed since last meeting, C++ specific discussion, closed and open issues
tags: [dev diaries, i2p, crypto]
author: dEBRUYNE / fluffypony
---
*June 19th, 2016*
# Logs
**\<fluffypony>** ok I guess we move on to Kovri - anonimal, the floor is yours
**\<meeting-bot> [anominal]** From agenda https://github.com/monero-project/kovri/issues/192
**\<meeting-bot> [anominal]** 17:00 (UTC)
**\<meeting-bot> [anominal]** 1. Greetings
**\<meeting-bot> [anominal]** 2. Brief review of what's been completed since the previous meeting
**\<meeting-bot> [anominal]** 3. C++ specific discussion (carried over from June 5th meeting)
**\<meeting-bot> [anominal]** 4. Review open tickets (assigned and/or unassigned): status, code ideas (if applicable), etc.
**\<meeting-bot> [anominal]** 5. Discuss any pertinent TODO's
**\<meeting-bot> [anominal]** 6. Any additional meeting items
**\<meeting-bot> [anominal]** 7. Confirm next meeting date/time
**\<meeting-bot> [anominal]** 1. Greetings
**\<meeting-bot> [anominal]** Hi
**\<meeting-bot> [anominal]** EinMByte: present?
**\<fluffypony>** there's 2x greetings?
**\<fluffypony>** best meeting ever
**\<meeting-bot> [anominal]** lol
**\<meeting-bot> [anominal]** Well, EinMByte is here but not present.
**\<fluffypony>** k
**\<meeting-bot> [anominal]** Moving on,
**\<meeting-bot> [anominal]** 2. Brief review of what's been completed since the previous meeting
**\<meeting-bot> [anominal]** A somewhat productive two weeks in contrasting areas. Highlights include:
**\<meeting-bot> [anominal]** - New --log-levels runtime feature
**\<meeting-bot> [anominal]** - Security fix in Garlic/ElGamal
**\<meeting-bot> [anominal]** - New user-agent scrubber
**\<meeting-bot> [anominal]** - Bump to 0.9.26
**\<meeting-bot> [anominal]** - Coverity coverage via travis-ci (though problematic, see #209)
**\<meeting-bot> [anominal]** - Design refactoring, misc. refactoring, code documentation
**\<meeting-bot> [anominal]** 6 closed issues
**\<meeting-bot> [anominal]** 2 new standing issues
**\<meeting-bot> [anominal]** fluffypony: have you had a chance to complete anything since previous meeting?
**\<fluffypony>** anonimal: like 80%-ish done with the Kovri page on the site, per the info you gave me + the docs
**\<fluffypony>** s/page/section
**\<meeting-bot> [anominal]** Great, I'm looking forward to it.
**\<meeting-bot> [anominal]** Do you think it will be finished before next meeting?
**\<fluffypony>** yes definitely
**\<meeting-bot> [anominal]** Yay, sounds exciting.
**\<meeting-bot> [anominal]** Anything else on 2.?
**\<meeting-bot> [anominal]** Going once... going twice...
**\<meeting-bot> [anominal]** 3. C++ specific discussion (carried over from June 5th meeting)
**\<meeting-bot> [anominal]** Well, I was hoping to merge this in with 4. and chat with EinMByte since he said he'd be here.
**\<fluffypony>** is this wrt the C++ standard ?
**\<fluffypony>** or the style guide stuff?
**\<meeting-bot> [anominal]** Anything C++, I imagined.
**\<meeting-bot> [anominal]** I was hoping to focus on C++ related to #187, but I haven't looked at #187 since it was opened.
**\<meeting-bot> [anominal]** Have any bitmonero devs taken an interest in Kovri yet?
**\<meeting-bot> [anominal]** Its quite the beast, and needs much taming.
**\<fluffypony>** I don't think anyone has yet
**\<tewinget>** anonimal: passing interest at best for me
**\<meeting-bot> [anominal]** Ok, good to know.
**\<tewinget>** I more or less know what it is, but I haven't looked into tinkering with it yet.
**\<moneromooo>** I think the problem is that the time I'd spend hacking on anything, I wouldn't spend on monero anymore :)
**\<fluffypony>** s'true
**\<meeting-bot> [anominal]** I totally understand.
**\<fluffypony>** there will be a bleed area between the two when integration happens
**\<meeting-bot> [anominal]** That makes, so patience and persistence seems to be the key.
**\<meeting-bot> [anominal]** \*makes sense
**\<meeting-bot> [anominal]** Well, anonymity has a certain taste too. Maybe I'm one of the few fanatics who enjoy working on it ;)
**\<fluffypony>** I think most of us are here because we're pro-privacy
**\<meeting-bot> [anominal]** Anyway, I look forward to the meeting of the minds, I like what I've seen in bitmonero dev.
**\<meeting-bot> [anominal]** Yes, good point.
**\<fluffypony>** which is awesome :)
**\<meeting-bot> [anominal]** Anything else on 3.? Any questions?
**\<meeting-bot> [anominal]** Alrighty, moving on,
**\<meeting-bot> [anominal]** 4. Review open tickets (assigned and/or unassigned): status, code ideas (if applicable), etc.
**\<meeting-bot> [anominal]** Let's see,
**\<fluffypony>** anonimal, also, if EinMbyte can't make the meeting maybe we must collate stuff and raise it on his behalf ?
**\<meeting-bot> [anominal]** How so?
**\<fluffypony>** like if he just adds to the agenda then we can discuss it without him needing to be here
**\<meeting-bot> [anominal]** Ok, well he's welcome to do that.
**\<meeting-bot> [anominal]** But he and I are great at bouncing ideas off each other and getting to core issues, so I wish he would be present more often.
**\<meeting-bot> [anominal]** I see, so we'll send him a note to add to the agenda regardless of his attending?
**\<fluffypony>** yes I think that would help, he lacks time at the moment
**\<meeting-bot> [anominal]** Ok.
**\<meeting-bot> * anonimal** back to 4.
**\<meeting-bot> [anominal]** #210 might be an easy fix, if any bitmonero devs want to take a peek.
**\<fluffypony>** once you go Kovri you never go...uh...something that rhymes with Kovri
**\<meeting-bot> [anominal]** lol
**\<meeting-bot> [anominal]** That's a tough one....
**\<fluffypony>** https://github.com/monero-project/kovri/issues/210 <- for reference
**\<meeting-bot> [anominal]** Remaining tickets are mostly all hard-core. I'll see what I can get into before the next meeting. Obviously the big ones would be nice if I can make the time.
**\<meeting-bot> [anominal]** I may pick at #191 or #187 because I get irritated with severely broken things.
**\<meeting-bot> [anominal]** Or who knows what, the world is full of mysterious and discovery.
**\<fluffypony>** lol
**\<meeting-bot> [anominal]** *mystery
**\<meeting-bot> [anominal]** lol
**\<fluffypony>** invent a time machine !
**\<meeting-bot> [anominal]** pffffffffff
**\<meeting-bot> [anominal]** That would be fun.
**\<fluffypony>** :-P
**\<meeting-bot> [anominal]** Does anyone here work with Debian Jessie often?
**\<fluffypony>** tewinget is an Arch user
**\<fluffypony>** moneromooo wrote his own OS from scratch I'm sure
**\<fluffypony>** osensei maybe
**\<fluffypony>** but he's not around atm
**\<moneromooo>** I use a pretty common one nowdays actually.
**\<meeting-bot> [anominal]** Ok just curious. Arch here so #210 will probably take more than a few moments.
**\<fluffypony>** moneromooo: Windows XP ?
**\<meeting-bot> [anominal]** ^ Windows 98
**\<moneromooo>** Good point. I guess it's not that common. I forgot about windows.
**\<meeting-bot> [anominal]** 95 was better at breaking.
**\<meeting-bot> [anominal]** Ok, well re: 4., fluffypony have you see #209?
**\<fluffypony>** probably
**\<meeting-bot> [anominal]** 50% yay because we solved the coverity/travis issue!
**\<fluffypony>** oh yes the Coverity thing
**\<fluffypony>** ok so plz update me - Travis builds are now work
**\<fluffypony>** *working
**\<fluffypony>** but Coverity isn't triggering ?
**\<meeting-bot> [anominal]** No, we are \*finally\* triggering, but now coverity says build is failing on their end.
**\<meeting-bot> [anominal]** So, travis says "we're fine", coverity says "you're not fine but neither is most of my site".
**\<meeting-bot> [anominal]** Because they really do have some issues there and support is... meh.
**\<fluffypony>** LOL
**\<fluffypony>** considering how long it took for their site to pick Travis up I'm not even surprised
**\<fluffypony>** do we wait until they've fixed it, or keep pushing
**\<meeting-bot> [anominal]** Seriously, and their "community" site is still offline despite "we'll be back in early 2016!".
**\<meeting-bot> [anominal]** It's June already...
**\<meeting-bot> [anominal]** Good question,
**\<meeting-bot> [anominal]** I can review \*why\* they think our build failed, I could even try to do it manually.
**\<meeting-bot> [anominal]** I may have to do it manually just to get things going \*or\*, it could be another travis/coverity issue (or just pure coverity).
**\<fluffypony>** maybe we must switch to manual Coverity
**\<fluffypony>** and just do it once every two weeks
**\<meeting-bot> [anominal]** Sounds fair, I'll give it shot before next meeting.
**\<meeting-bot> * anonimal** before I forget, opens https://github.com/monero-project/kovri/issues/assigned/fluffypony
**\<meeting-bot> [anominal]** fluffypony: Any updates on #27?
**\<meeting-bot> * anonimal** knows you've been busy, simply curious
**\<fluffypony>** anonimal: no - also, we're switching providers
**\<meeting-bot> [anominal]** Ok.
**\<fluffypony>** debating Zoho vs. FastMail
**\<fluffypony>** ProtonMail doesn't do multiple users on a domain, unfortunately
**\<meeting-bot> [anominal]** Hmmm...
**\<meeting-bot> [anominal]** Pros/Cons so far re: providers?
**\<fluffypony>** well they're mostly doing forwarding and SMTP, so it's pretty open
**\<fluffypony>** part of the decision making is cost, part is also reliability and if they feature reasonable web interfaces for those inevitable users that don't want to use a mail client
**\<fluffypony>** will wrap that up soon, it's on my short list
**\<meeting-bot> [anominal]** Ok, good to know.
**\<meeting-bot> [anominal]** I don't have an opionion so far. If I do I'll be sure to chip in.
**\<meeting-bot> [anominal]** Is xmrpromotions there? re: #105
**\<fluffypony>** no not online atm
**\<fluffypony>** I'll prod them for that when I see them next
**\<meeting-bot> [anominal]** K.
**\<meeting-bot> * anonimal** typing
**\<meeting-bot> [anominal]** I'll most likely take a look at bitmonero's 0MQ work too before next meeting (thinking of #53).
**\<meeting-bot> [anominal]** Other than that, I may just grab some low hanging fruit before next meeting and work on the mingw build and other smaller tickets.
**\<tewinget>** anonimal, feel free to direct any 0mq questions at ~~fluffypony~~ me
**\<meeting-bot> [anominal]** Thanks tewinget.
**\<fluffypony>** oh yeah speaking of
**\<tewinget>** sad that my IRC client doesn't support strikeout...hoping someone else's does
**\<fluffypony>** the Windows test box is borked
**\<fluffypony>** msys2 decided to give up the ghost
**\<fluffypony>** so doing a complete reinstall of it
**\<meeting-bot> [anominal]** Yeah, so what happened? Any idea?
**\<fluffypony>** no clue
**\<meeting-bot> [anominal]** (very strange)
**\<tewinget>** On a scale from 1 to I hate compiling anything on Windows: I hate compiling anything on Windows.
**\<tewinget>** it's a binary scale.
**\<meeting-bot> [anominal]** Oh windows, you never cease to disappoint me.
**\<meeting-bot> [anominal]** Anything else on 4.?
**\<meeting-bot> * anonimal** quick reviewing
**\<meeting-bot> [EinMByte]** Hi, I'm late sorry
**\<meeting-bot> [anominal]** EinMByte! Welcome back.
**\<fluffypony>** wb EinMByte
**\<fluffypony>** still 15 minutes left :)
**\<meeting-bot> [anominal]** With 15 minutes or so to spare, any input? (much backlog)
**\<meeting-bot> [EinMByte]** Something about #210 maybe: I'll provide some more information
**\<meeting-bot> [anominal]** EinMByte: before I forget and while you're here: what is your preferred/most-reliable public contact method?
**\<meeting-bot> [EinMByte]** public as in to put on a website or so, or as in where you guys can contact me
**\<meeting-bot> [anominal]** So we can contact you.
**\<meeting-bot> [anominal]** And would you be interested in leaving agenda TODO's/notes in meeting tickets in case you can't make a meeting that you'd hope to make?
**\<meeting-bot> [EinMByte]** Well I'll be on IRC, or else einmbyte@mail.i2p or github
**\<meeting-bot> [anominal]** Ok.
**\<meeting-bot> [EinMByte]** sure
**\<meeting-bot> [anominal]** fluffypony: did I word that correctly?
**\<meeting-bot> [anominal]** EinMByte: we're still on point 4. "reviewing tickets", etc.
**\<meeting-bot> [anominal]** Is there anything you wanted to add re: SSU?
**\<meeting-bot> * anonimal** knows you just got back to working on it
**\<fluffypony>** yes I think so
**\<meeting-bot> [EinMByte]** Well I can give you a quick status update
**\<meeting-bot> [anominal]** Awesome.
**\<meeting-bot> [EinMByte]** So SSUSession.cpp is now using the new parsing code, except for the fragments
**\<meeting-bot> [EinMByte]** (I have the code to parse data packets, just not using it yet)
**\<meeting-bot> [EinMByte]** I am slowed down right now due to a bug, with the header I suspect
**\<meeting-bot> [anominal]** Grrr... bugs...
**\<meeting-bot> [EinMByte]** (Rekey options being set etc when this shouldn't happen, I think it's all related)
**\<meeting-bot> [EinMByte]** Well, I'll try to fix it in the next days
**\<meeting-bot> [anominal]** bitmonero devs: FYI, SSU is the ugly High School girl standing in the corner of the dance hall that no one will dance with because she is awkward and is a very mean person.
**\<fluffypony>** lol
**\<meeting-bot> [anominal]** In other words, SSU has needed much love and I'm glad EinMByte has tackled the challenge.
**\<meeting-bot> [EinMByte]** Hah, nice comparison - although it does make me seem quite desperate :P
**\<meeting-bot> [anominal]** lol, oops. Sorry EinMByte, I didn't mean it that way :(
**\<meeting-bot> [EinMByte]** Once the parsing part is done, I'll do something similar to build the packets
**\<meeting-bot> [anominal]** Sounds great.
**\<meeting-bot> [anominal]** How about, EinMByte dances with her because he is a leader and willing to show great sympathy to those who need it most.
**\<meeting-bot> [EinMByte]** I'll write some tests, but don't expect full coverage just yet. I don't think that's a priority right now.
**\<meeting-bot> [anominal]** And turns down the more promising dancers to make SSU work well.
**\<meeting-bot> [EinMByte]** (I want to get the API started too)
**\<meeting-bot> * anonimal** sorry, I'm getting carried away
**\<meeting-bot> [anominal]** Ok.
**\<meeting-bot> [anominal]** Do you have an idea of schedule coming up?
**\<meeting-bot> [anominal]** (as in availability)
**\<meeting-bot> [EinMByte]** anonimal: You're making a lot of assumptions about my gender here :). But let's see how well that dance turns out
**\<meeting-bot> [anominal]** I know, again my apologies.
**\<meeting-bot> [EinMByte]** Yes, next week I'll be mostly available (several hours per day)
**\<meeting-bot> [anominal]** Ok. I'll check my IRC more frequently then.
**\<meeting-bot> [anominal]** Anything else on 4.?
**\<meeting-bot> [EinMByte]** Well as I said I'll put up more info for #210
**\<meeting-bot> [anominal]** Ok.
**\<meeting-bot> [EinMByte]** Seems like 2 tests are failing
**\<meeting-bot> [anominal]** Since we're out of time, I don't see much on 5. except for a couple of quirky core ones that I may get to before next meeting.
**\<meeting-bot> [anominal]** Any comments on 5.?
**\<fluffypony>** EinMByte: well you can dance with SSUzy regardless of your gender
**\<meeting-bot> [anominal]** SSUzy, lol.
**\<meeting-bot> [EinMByte]** fluffypony: or my ability to dance :p
**\<fluffypony>** everyone can dance, it's just a matter of how badly (or well)
**\<meeting-bot> [anominal]** Paraplegics?
**\<meeting-bot> * anonimal** doesn't do off-topic very often, quite the release.
**\<meeting-bot> [anominal]** Ok so if no thoughts on 5.,
**\<fluffypony>** LOL
**\<fluffypony>** nobody is going to attend the Kovri meeting in future :-P
**\<meeting-bot> [anominal]** LMAO
**\<meeting-bot> * anonimal** watches ship sailing away, burning in the distance
**\<meeting-bot> [EinMByte]** See you all next time in #dancing
**\<meeting-bot> [anominal]** Ok, last call for 5. Discuss any pertinent TODO's
**\<fluffypony>** I think that's it from my side
**\<fluffypony>** lol EinMByte
**\<meeting-bot> [anominal]** lol, or #dancing-dev
**\<meeting-bot> [EinMByte]** Well, for 5: If anyone wants to start on the API, you're welcome
**\<meeting-bot> [EinMByte]** This also applies to all (any?) monero people reading this
**\<meeting-bot> [anominal]** Good point, that's another big item to tackle.
**\<meeting-bot> [EinMByte]** Since you're going to be the people using the API, making up a list of requirements would be nice
***\<fluffypony>** kk
**\<meeting-bot> [anominal]** 6. Any additional meeting items
**\<meeting-bot> [anominal]** Just one from me, briefly,
**\<fluffypony>** I think we've already discussed EinMByte's dancing enough, so nothing more from me on 6
**\<meeting-bot> [anominal]** Forum Funding. I plan on writing up some proposals within the next month or so.
**\<fluffypony>** kk
**\<meeting-bot> [anominal]** EinMByte: if you were crowdfunded on FFS, would you be able to devote any more dev time?
**\<meeting-bot> [EinMByte]** I've already told fluffypony, not really
**\<meeting-bot> [anominal]** Ok.
**\<meeting-bot> [EinMByte]** If you can build me a time machine, yes
**\<meeting-bot> * anonimal** was planning proposals to fund my work
**\<meeting-bot> [anominal]** Funny, fluffypony mentioned that earlier (time machine).
**\<fluffypony>** lol
**\<meeting-bot> [anominal]** We should invest in one. The writing is on the wall.
**\<meeting-bot> [anominal]** Last call for 6.
**\<fluffypony>** new project for the Monero Research Lab to tackle
**\<meeting-bot> [EinMByte]** But, as I've also told fluffypony, please do fund other programmers
**\<meeting-bot> [anominal]** Agreed.
**\<meeting-bot> [EinMByte]** Apparently you first need the programmer (before getting the money) so let's go find some C++ programmers
**\<meeting-bot> [anominal]** fluffypony: ^ we should devote an entire meeting to that IMHO sometime within the next few months.
**\<fluffypony>** yeah definitely
**\<grimpants>** would love to see a FFS proposal for kovri/i2p dev
**\<fluffypony>** grimpants: we've had open-ended stuff before, the funds just sit there and no dev comes along - we need to first find someone interested that can price in their work, even if it's on a full time commitment for X long
**\<meeting-bot> [EinMByte]** By the way, we don't need only expert C++ programmers
**\<fluffypony>** and then we can raise funds accordingly
**\<grimpants>** i see
**\<grimpants>** been a while since ive check tbh
**\<meeting-bot> [EinMByte]** We can use people who just write documentation / tests too
**\<meeting-bot> [anominal]** ^ which is a great way for newcomers to learn the codebase.
**\<fluffypony>** this may not be an honourable line of thought, but I've been wondering if there's any fall-out from the issues Tor are facing that might lead to some new contributors looking at Kovri
**\<meeting-bot> [anominal]** Good concern, I think that's very plausible.
**\<meeting-bot> [anominal]** But the devoted C person usually scoffs at C++ and turn their nose at Java.
**\<fluffypony>** like hyc :-P
**\<meeting-bot> [anominal]** I've become spoiled with STL so, I can't vouch for C devotees on more complex apps like Kovri.
**\<meeting-bot> [anominal]** But bigger point:
**\<meeting-bot> [anominal]** The world needs more options, so if Tor starts to burn, another ship will be ready.
**\<meeting-bot> [anominal]** Some great minds there, so I'm not concerned about the near future.
**\<meeting-bot> [anominal]** But that was a hefty loss on their end with the one who shall remain nameless.
**\<fluffypony>** yeah, and the larger loss is how much emotional damage it did to people during the time it was kept hidden
**\<fluffypony>** as a community I hope we can learn from that and call people out when they're out of line
**\<meeting-bot> [anominal]** Yeah, everyone involved seems to have taken a loss.
**\<meeting-bot> [anominal]** So, regarding that in relation to ship-jumpers: I think we should continue on our track of availability, professionalism, quality, code correctness and maintainability,
**\<fluffypony>** 100%
**\<meeting-bot> [anominal]** But,
**\<meeting-bot> [EinMByte]** let's first get some people :)
**\<meeting-bot> [anominal]** devs can be strong in their ways, so being malleable is also important (but that's a given). Constant ebb and flow.
**\<meeting-bot> [anominal]** Anything else on 6.?
**\<fluffypony>** that's it from my side
**\<meeting-bot> [anominal]** 7. Confirm next meeting date/time
**\<meeting-bot> [anominal]** Same time in two weeks?
**\<meeting-bot> [EinMByte]** Nothing else from me
**\<fluffypony>** yes same time in two weeks
**\<meeting-bot> [anominal]** Alright. A million thanks to everyone.
**\<fluffypony>** taking meeting-bot down

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

@ -0,0 +1,225 @@
---
layout: post
title: Overview and Logs for the Dev Meeting Held on 2016-06-19
summary: C4, open PRs, and brief update on Ring CT and 0MQ
tags: [dev diaries, core, crypto, 0mq]
author: dEBRUYNE / fluffypony
---
*June 19th, 2016*
# Overview (by Aerbax)
An overview [can be found on Hello Monero](https://hellomonero.com/article/monero-bi-weekly-dev-meeting-note-highlights-2016-06-19)
# Logs
**\<fluffypony>** ok
**\<fluffypony>** hello and welcome
**\<tewinget>** ack
**\<wallet42>** Sup fluffypony
**\<fluffypony>** so first things first
**\<meeting-bot>** [anonimal] EinMByte: ^ Monero meeting now, Kovri in about an hour or so (just FYI)
**\<fluffypony>** after the last meeting, which was mostly focused on C4, we bounced some of that around
**\<fluffypony>** I think the spirit of C4 is good, and will help keep Monero inclusionary towards new contributors
**\<fluffypony>** but moneromooo in particular disagreed with some of the specifics
**\<fluffypony>** or where C4 is a little vague
**\<fluffypony>** so what we're going to do is fork C4 from Unprotocols / yrashk into the Monero repo
**\<meeting-bot>** [psi] c4?
**\<fluffypony>** and we'll tweak it from there, keeping it in step with changes made upstream in Unprotocols
**\<fluffypony>** psi: the Collaborative Code Construction Contract, see last meeting's minutes for an intro and discussion
**\<meeting-bot>** [anonimal] Or Kovri's contributing guide.
**\<fluffypony>** yup
**\<fluffypony>** I think everyone is aware that this is security software we're dealing with
**\<fluffypony>** and we can't be crazy and accept things that may contain backdoors
**\<fluffypony>** but we also want some structure that makes contributors feel welcome, even if their contributions need some work and aren't up to a standard we'd like
**\<fluffypony>** somewhere inbetween being completely permissive and miring contributions in PR hell is a nice balance, and we'll figure it out
**\<ArticMine>** We need to balance security and making contributors welcome
**\<fluffypony>** yup exactly
**\<fluffypony>** ok so on to more fiddly code bits, less soft skills
**\<fluffypony>** I was hoping tewinget could update us on the 0MQ work, which is about to go up on the forum for funding
**\<tewinget>** ok
**\<moneromooo>** My point was not security, it was more about the crazy wish to keep obvious crap in.
**\<tewinget>** https://www.github.com/tewinget/bitmonero/tree/zmq-dev \<-- there's the branch, gimme one min to take care of something then I can brief
**\<fluffypony>** ok
**\* fluffypony** plays hold music
**\* tewinget** is typing
**\* DaveyJones** just watches
**\<tewinget>** ok, so far I've got cryptonote::classes to/from json for a majority of what will need to be serialized for RPC. I have a couple of RPC calls actually written and working via ZMQ (get_height get_transactions, and key_images_spent)
**\<tewinget>** that's more or less a summary of progress
**\<tewinget>** as far as process
**\<tewinget>** the idea is to try to create RPC as we want it to be, rather than trying to modify the existing structure, and then plug in backwards-compatibility later
**\<fluffypony>** tewinget: so using the structure that is / was on the Wikia ?
**\<meeting-bot>** [psi] to rehash, you are redoing monero's wire protocol to use zmq correct?
**\<fluffypony>** psi: no, not wire protocol, that will use ZMTP (a part of the 0MQ project) and come later
**\<tewinget>** psi: more or less, but a bit more than just that
**\<tewinget>** oh
**\<tewinget>** I mean, kinda wire, but not p2p yet
**\<tewinget>** rpc
**\<fluffypony>** this is redoing the communication between the node and "clients" like miners / mining pool software / wallets / etc.
**\<meeting-bot>** [psi] kk
**\<meeting-bot>** [psi] zmtp is still being drafted correct?
**\<fluffypony>** nope all done, afaik: http://zmtp.org
**\<tewinget>** \<fluffypony> tewinget: so using the structure that is / was on the Wikia ? <-- well, yes, but also I was hoping to get some input today (not necessarily now) from anyone who would like to comment on the future of RPC
**\<fluffypony>** it's already on v3
**\<fluffypony>** ok so maybe one of the things we need to do now is move that design doc from the Wikia to the Github wiki
**\<fluffypony>** wallet42: are you up to doing that, or busy travelling atm ?
**\<tewinget>** I can say that the few commands I've done don't necessarily conform to any spec like json-rpc, but that's easy to change -- structure is currently placeholder while functionality is implemented
**\<tewinget>** oh, one important detail I left out
**\<tewinget>** I think it's best if the RPC is straight json. This comes at a very, very minor cost in speed, but means that implementation in other languages will be far less intimidating for new contributors
**\<tewinget>** and I know I don't personally plan to write libMonero for every language out there...
**\<fluffypony>** oh I agree - the idea behind 0MQ is for a language to use 0MQ bindings and just be able to talk straight to the daemon
**\<tewinget>** yup, and this way for any language that has json and zmq bindings, all one needs to do is give the language a cursory understanding of cryptonote structs
**\<fluffypony>** if JSON is the way we want to do that that's fine, we can always modify it later to support Google's protobufs or something later on
**\<tewinget>** https://paste.fedoraproject.org/379294/14659488/ <-- there's an example of get_transactions
**\<tewinget>** it's also very nice to do ad-hoc testing via python :)
**\<fluffypony>** cool
**\<tewinget>** any thoughts, anyone?
**\<wallet42>** fluffypony: In about 3 weeks im back in Berlin, right now i only have like 1 day a week. But yes the wiki will get more data as I am moving myself trough the code
**\<wallet42>** Especially better wiki documentation of the datatypes/protocol
**\<wallet42>** wiki.bitcoin.it/wiki/Protocol basically
**\<fluffypony>** tewinget: how hard would it be to implement different schemes in future, like JSON / protobufs / ASN.1 BER ?
**\<fluffypony>** wallet42: ok cool, thank you
**\<tewinget>** fluffypony: wouldn't be too bad, I'm trying to make things pretty modular. It wouldn't be too bad to make it a bit more generic than json
**\<tewinget>** it's already 90% ready for that as-is
**\<fluffypony>** kk
**\<fluffypony>** alright, tewinget anything else or can we move on to the next thing ?
**\<tewinget>** the ZMQ-side of things was pretty trivial tbh
**\<tewinget>** oh, anyone averse to having a separate listening port for publish/subscribe such as "new_block_notify" etc?
**\<fluffypony>** you mean a separate port for pub-sub than the IPC port ?
**\<tewinget>** well, there will be a port for "request thing from daemon"
**\<tewinget>** can't use the same port for publish/subscribe, I'm pretty sure
**\<fluffypony>** I don't see a problem with that
**\<tewinget>** without an unholy amount of added complexity that isn't worth at all
**\<fluffypony>** one thing you may want to do is also look at Bitcoin's 0MQ effort
**\<fluffypony>** I don't think wumpus is around at the moment
**\<fluffypony>** but they've been pecking away at 0MQ for some time
**\<moneromooo>** Isn't the point of 0MQ to abstract comms to allow things like that ?
**\<fluffypony>** moneromooo: pub-sub is a different beast to control / request
**\<tewinget>** 0MQ uses different socket types like Request-Reply, or Pub/Sub
**\<fluffypony>** normally for pub-sub you're sending a request once and then receiving "push" notifications forever
**\<tewinget>** and one socket can only be one type, and I don't think you can bind two sockets to the same port, as how would it route that?
**\<fluffypony>** Bitcoin has walletnotify and blocknotify that work in that way
**\<tewinget>** so using the same port for req-rep and pub-sub would require...well, no, just no
**\<fluffypony>** it would end up looking gross like the RPC stuff at the moment
**\<tewinget>** moreso, in fact
**\<fluffypony>** different HTTP paths for the JSON and HTTP RPCs
**\<tewinget>** \<fluffypony> alright, tewinget anything else or can we move on to the next thing ? <-- happy to give a few minutes for any comments from anyone, but other than that I think that's about it
**\<fluffypony>** cool if anything pops up over the rest of the meeting then we can see
**\<tewinget>** oh, and feel free to give feedback on the branch, I'll repaste the link in a sec. Feedback here or via github is fine
**\<tewinget>** https://www.github.com/tewinget/bitmonero/tree/zmq-dev
**\<fluffypony>** ok next, moneromooo do you feel like giving an update on RingCT? looks like it's making nice headway :)
**\<moneromooo>** It kinda works. I'm fixing bugs now.
**\<fluffypony>** moneromooo: is it going to be a hard fork where all new transactions are v3 / ringCT, but they can spend pre-ringCT outs?
**\<moneromooo>** They
**\<fluffypony>** they = transactions
**\<othe>** coinbase will use non-ringct tho?
**\<fluffypony>** othe: yes afaik
**\<moneromooo>** They'll be v2 and can spend either pre rct outputs or rct ones.
**\<fluffypony>** moneromooo: ooooh, so a soft fork? :-P
**\<moneromooo>** Hmm. I haven't thought about the distinction tbh.
**\<moneromooo>** Theoretically, coinbase might not even need to be in the clear I think. Though it'd require some shen magic.
**\<fluffypony>** I think it'd be a hard fork, because old nodes won't understand rct outs
**\<fluffypony>** so we'd have to bump the block version anyway
**\<ArticMine>** But will non RingCT other than coninbase transactions be valid?
**\<moneromooo>** Oh they'd reject new txes, yes.
**\<yrashk>** fluffypony: I'm thinking of an unprotocol for describing diverged unprotocols
**\<yrashk>** So meta
**\<fluffypony>** moneromooo: ok then that's hard fork
**\<fluffypony>** lol yrashk
**\<yrashk>** But I'm actually serious
**\<yrashk>** :)
**\<fluffypony>** yrashk: what's that Unprotocol for creating protocols with consensus?
**\<tewinget>** ArticMine: I think post-fork that all non-coinbase tx will be ringCT, but I'm not sure.
**\<moneromooo>** ArticMine: if you mean "will non RingCT outputs other than coninbase transactions be valid?", then I'd choose no, but it could be made either way.
**\<yrashk>** fluffypony: COSS? There's nothing about consensus there
**\<fluffypony>** yrashk: yes that - but it's about creating new protocols as a group, right ?
**\<yrashk>** Kind of but very very lightweight
**\<fluffypony>** kk
**\<yrashk>** Which is a good thing generally
**\<CFP>** Greetings fellas
**\<fluffypony>** moneromooo: I tend to agree with you - coinbase txs is fine, but after that it should be rct only
**\<CFP>** Crazyflashpie stoping by to say hello
**\<yrashk>** fluffypony: are you interested to collaborate on the protocol divergence protocol? (PDP)
**\<fluffypony>** hi CFP
**\<CFP>** Looks like the # of nodes in China is climbing?
**\<fluffypony>** yrashk: let's chat after the meeting, definitely interested in discussing it, as it's relevant to us
**\<yrashk>** I can explain my motivations behind it
**\<yrashk>** Today?
**\<yrashk>** Ping me on telegram or here when ready
**\<fluffypony>** kk
**\<fluffypony>** ok next I just wanted to bounce through some open PRs
**\<fluffypony>** #818 is still open pending luigi1111w / luigi1112 coming up with those spec changes, no rush there
**\<ArticMine>** moneromooo I would expect non RingCT outputs other than coinbase to be invalid after a given block
**\<fluffypony>** #775 is ready to be merged - moneromooo, just to double check, you're fine with that, right ?
**\<ArticMine>** With the 6 month upgrade cycle built in
**\<fluffypony>** ArticMine: agreed
**\<luigi1112>** Yes I'll try to do that this week
**\<moneromooo>** Yes. It's a wee bit spammier now in the logs, but other than that it's good to go.
**\<fluffypony>** ok then #810, the caching thing, I'm still confused as to whether we must merge or not
**\<moneromooo>** Not sure. I think enough said no.
**\<fluffypony>** ok I'll close it, we can reopen later
**\<moneromooo>** But then nobody patched the pool code :)
**\<fluffypony>** and pools can manually pull that in if they need
**\<fluffypony>** then the gcc 6.1 stuff - as I understand it there are more changes than what is covered in those two PRs
**\<fluffypony>** so do we close the PRs and just note that "gcc 6.1 not supported yet"
**\<meeting-bot> [anonimal]** Noooooooo.........
**\<fluffypony>** or do we merge them in preparation for supporting 6.1 ?
**\<meeting-bot> [anonimal]** Please nooooooo....
**\<fluffypony>** lol anonimal
**\<moneromooo>** If they'll be needed anyway...
**\<meeting-bot> [anonimal]** This also re: #846?
**\<moneromooo>** One of them is a superset of the other IIRC.
**\<fluffypony>** anonimal: yeah, 846 and 845
**\<meeting-bot> [anonimal]** radfish's work builds, so is the problem more eyes/more time to review?
**\<fluffypony>** anonimal: it was more that I was travelling, so I don't really know which is the superset of which, and which to close / merge / bail out of entirely :-P
**\<meeting-bot> [anonimal]** Oh, well I can spend some time this week giving input if that helps.
**\<moneromooo>** 846 seems to be the superset.
**\<tewinget>** PR X is a superset of PR Y seems like an odd situation to be in...
**\<tewinget>** especially if both are open
**\<fluffypony>** tewinget: quite
**\<neosilky_>** I had to merge them to get the repo to compile as GCC 6.1 is default for Arch
**\<fluffypony>** kk
**\<meeting-bot> [anonimal]** re: that ^, I only merged #846 and builds fine.
**\<meeting-bot> [anonimal]** I see the issue of both PR's being open, I can comment further this week after looking at them if they are still open by then.
**\<neosilky_>** Yep, only needed #846. @tewinget should enable testing repo too :)
**\<fluffypony>** ok then I'll close 845 and merge 846
**\<meeting-bot> [anonimal]** Ok.
**\<fluffypony>** then #856 I've reviewed and will merge
**\<fluffypony>** #855 seems fine to me, I defer to hyc's knowledge of his own product ;)
**\<fluffypony>** #863 seems fine too
**\<fluffypony>** #862 - luigi1112 can I take your comment as a review?
**\<moneromooo>** Oh. Let me change it now...
**\<gingeropolous>** tewinget, i may try and put this in a comment on the https://www.github.com/tewinget/bitmonero/tree/zmq-dev , but is this the space wherein the daemon could have multiple rpc ports with different characteristics?
**\<luigi1112>** I think it's fine yeah
**\<moneromooo>** pushed
**\<fluffypony>** k
**\<meeting-bot> [anonimal]** Has there been any definitive decisions re: C4 since previous meeting? I know there are differing arguments.
**\<fluffypony>** anonimal - yes, my comments at the beginning of the meeting, will let you know when the log is up if you missed them
**\<tewinget>** gingeropolous: not entirely sure what you mean to ask there
**\<meeting-bot> [anonimal]** "we'll figure it out" <-- was that it?
**\<gingeropolous>** i.e., port 18081 would be full access, and 18082 could be less access.
**\<fluffypony>** anonimal: yes basically the next step is fork ->** adjust accordingly ->** decide to abandon or adopt the iteration
**\<gingeropolous>** right now if you want different permissions for remote access to the daemon, you need multiple daemons and multiple databases
**\<othe>** isnt an auth system with permissons better for this
**\<fluffypony>** gingeropolous: I'm of a mind that we need a finer distinction than "trusted daemon" and "not trusted"
**\<fluffypony>** we need a proper ACL
**\<fluffypony>** what othe said
**\<fluffypony>** so shelve it as a thing to do later on
**\<gingeropolous>** word
**\<fluffypony>** ok I think that's it from my side - anything else before we move to the Kovri meeting?
**\<tewinget>** glad someone else could answer that while I was rebooting. Stupid computer crashes frequently, pretty sure it's hardware.
**\<fluffypony>** tewinget: you should buy a Mac :-P
**\<ArticMine>** No
**\<tewinget>** fluffypony: I thought we were friends...
**\<tewinget>** tbh if a newer Mac (not new, with that single port, but new-ish) landed on my lap I'd throw Linux on it and use it
**\<tewinget>** but I'd never buy one, they're way too expensive for what they are.
**\<othe>** actually the macbook pro are good value for money compared to other ultrabooks; anyway kovir next :p
**\<fluffypony>** Pro Retina is great, although I've switched my Purism Librem 13 + Qubes for anything remotely sensitive
**\<antanst1>** Hackintosh user here :-) It's pretty easy to install OSX if you choose hardware carefully.
**\<antanst1>** works pretty much perfectly.
**\<othe>** correct, also run a hackintosh desktop
**\<ArticMine>** I see the software not the hardware as the issue with Mac
**\<meeting-bot> * anonimal** has 8 year old hackbook pro running Arch :/
**\<meeting-bot> [anonimal]** Still alive, surprisingly.
**\<fluffypony>** nice

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

@ -0,0 +1,20 @@
---
layout: post
title: Monero Missives for the Week of 2016-06-20
summary: A discussion of the rationale behind rolling hardforks and the C4 code contract
tags: [monero missives, external]
author: Riccardo Spagni (fluffypony)
forum: https://forum.getmonero.org/1/news-announcements-and-editorials/2568/monday-monero-missives-33-june-20th-2016
---
<div class="text-center"><iframe style="border: none" src="//html5-player.libsyn.com/embed/episode/id/4447222/height/360/width/640/theme/legacy/autoplay/no/autonext/no/thumbnail/yes/preload/no/no_addthis/no/direction/backward/no-cache/true/" height="360" width="640" scrolling="no" allowfullscreen webkitallowfullscreen mozallowfullscreen oallowfullscreen msallowfullscreen></iframe></div>
To download the podcast directly please [use this link to the MP3](http://traffic.libsyn.com/monero/Monero_Missives_Podcast_for_the_week_of_2016-06-20.mp3), or [this link to the AAC/MP4](http://traffic.libsyn.com/monero/Monero_Missives_Podcast_for_the_week_of_2016-06-20.mp4), or [this link to the FLAC](http://traffic.libsyn.com/monero/Monero_Missives_Podcast_for_the_week_of_2016-06-20.flac).
In this week's episode we discuss the rationale behind rolling hard forks and the Collective Code Construction Contract (C4).
Until next week!
# Podcast Transcription
*Pending*

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

@ -0,0 +1,248 @@
---
layout: post
title: Logs for the Kovri Dev Meeting Held on 2016-07-03
summary: Brief review of what has been completed since last meeting, SSU refactoring, closed and open issues
tags: [dev diaries, i2p, crypto]
author: dEBRUYNE / fluffypony
---
*July 3th, 2016*
# Logs
**\<fluffypony>** ok I guess we move on to Kovri - anonimal, the floor is yours
**\* fluffypony:** ding dings
**\<meeting-bot> [anonimal]** Meeting Agenda: Sunday, July 3rd, 17:00 UTC
**\<meeting-bot> [anonimal]** 1. Greetings
**\<meeting-bot> [anonimal]** 2. Brief review of what's been completed since the previous meeting
**\<meeting-bot> [anonimal]** 3. Discuss SSU: status of #140 and https://github.com/EinMByte/kovri/pull/1 (if applicable), ideas, problems, and solutions (note: ask if @EinMByte will allow issues tracking within his repo)
**\<meeting-bot> [anonimal]** 4. Discuss commit message labeling, e.g., how to organize first line of commits. Touch-up on C4.
**\<meeting-bot> [anonimal]** 5. Review open tickets (assigned and/or unassigned): status, code ideas (if applicable), etc.
**\<meeting-bot> [anonimal]** 6. Discuss any pertinent TODO's
**\<meeting-bot> [anonimal]** 7. Any additional meeting items
**\<meeting-bot> [anonimal]** 8. Confirm next meeting date/time
**\<meeting-bot> [anonimal]** -- 1. Greetings
**\<meeting-bot> [anonimal]** Hi
**\<moneromooo>** hi
**\<fluffypony>** hi
**\<meeting-bot> [anonimal]** I know Ein is irc2p side waiting for me to move on :)
**\<meeting-bot> [anonimal]** 2. Brief review of what's been completed since the previous meeting
**\<meeting-bot> [fluffypony]** I'm on this side too
**\<meeting-bot> * anonimal** wishes this was automated. /pulse only does so much
**\<meeting-bot> [anonimal]** 28 commits (not including merges), 2 new issues open, 0 issues closed
**\<meeting-bot> [anonimal]** All new commits in https://github.com/einmbyte/kovri/tree/ssu
**\<meeting-bot> [anonimal]** I ended up diving into SSU with EinMByte this week. Much fun.
**\<meeting-bot> [anonimal]** Teamwork-teamwork: within the past hour, we had figured out that the HMAC digest impl was segfaulting because GetHeader->GetMAC() was not initialized, so the segfault is fixed for now.
**\<meeting-bot> [anonimal]** But that's just a small portion of what's been completed since previous meeting, and more issues abound. More to discuss in 3.
**\<meeting-bot> [anonimal]** Anyone else re: completed work since previous meeting?
**\<meeting-bot> [fluffypony]** I've been focused on the OTF funding stuff, so I haven't had a chance to finish the website work
**\<meeting-bot> [fluffypony]** pushing that out till the next meeting, unless we have to prepare more stuff for the OTF
**\<meeting-bot> [anonimal]** Ok. Any new issues re: OTF?
**\<meeting-bot> [anonimal]** Seems like they've had a few lately.
**\<meeting-bot> [anonimal]** i.e., did we get confirmation that they received our request?
**\<meeting-bot> [fluffypony]** no I think the next step is we'll receive a pass / fail on the concept note
**\<meeting-bot> [fluffypony]** yes we did
**\<meeting-bot> [_trump2016]** OTF will make kovri great again!
**\<meeting-bot> [anonimal]** Confirmation, good.
**\<meeting-bot> [anonimal]** Anyone freenode-side? Is xmrpromotions there?
**\<meeting-bot> [fluffypony]** so if we receive a pass we have to prepare an actual proposal
**\<meeting-bot> [fluffypony]** but let's see when we get there
**\<meeting-bot> [fluffypony]** (if)
**\<meeting-bot> [fluffypony]** they were on Reddit the other day, they seem to be busy at the moment
**\<meeting-bot> [fluffypony]** they've asked for assistance on the gnu-social thing
**\<meeting-bot> [anonimal]** Link? What kind of assistance? I'd be happy to help.
**\<meeting-bot> [fluffypony]** I'll have to find it and send it to you post-meeting
**\<meeting-bot> [anonimal]** Ok. Anything else on 2.?
**\<meeting-bot> [fluffypony]** oh found it, nevermind: https://www.reddit.com/r/Monero/comments/4qywbx/what_are_moneros_pain_points_marketing_design/d4x34p3
**\<meeting-bot> [fluffypony]** nein
**\<meeting-bot> [anonimal]** fluffypony: Thanks, I'll look into it later.
**\<meeting-bot> [anonimal]** Moving on,
**\<meeting-bot> [anonimal]** 3. Discuss SSU: status of #140 and https://github.com/EinMByte/kovri/pull/1 (if applicable), ideas, problems, and solutions (note: ask if @EinMByte will allow issues tracking within his repo)
**\<meeting-bot> [anonimal]** So, https://github.com/EinMByte/kovri/pull/1 has been merged
**\<meeting-bot> [anonimal]** EinMByte: will you allow issues tracking within your repo? It would help with this bug we're hunting.
**\<meeting-bot> [anonimal]** Oops, old paste, we fixed the bug,
**\<meeting-bot> [anonimal]** but are still dealing with related issues.
**\<meeting-bot> * anonimal** knows Ein is somewhere, we were chatting elsewhere during the bitmonero meeting
**\<meeting-bot> [EinMByte]** Hi
**\<meeting-bot> [anonimal]** Maybe he still thinks its the previous meeting...
**\<meeting-bot> [anonimal]** Hi
**\<meeting-bot> [EinMByte]** Yes, I will allow all contributions to my repo
**\<meeting-bot> [EinMByte]** Latest issue is: we are sending out broken packets
**\<meeting-bot> [fluffypony]** issue tracking has to be explicitly enabled for the repo, EinMByte
**\<meeting-bot> [EinMByte]** (but at least the segfault is fixed)
**\<meeting-bot> [fluffypony]** it's a setting in github somewhere
**\<meeting-bot> [anonimal]** ^ what fluffypony said
**\<meeting-bot> [anonimal]** EinMByte: are we in a committable stage for the segfault fix? So I can see where we stand?
**\<meeting-bot> [EinMByte]** anonimal: Already committed
**\<meeting-bot> [EinMByte]** fluffypony: somewhere where
**\<meeting-bot> [anonimal]** I imagine we're sending bogus packets in SessionRequest
**\<meeting-bot> [fluffypony]** I'll check
**\<meeting-bot> * anonimal** fetching
**\<meeting-bot> [EinMByte]** fluffypony: Never mind, I think I got it
**\<meeting-bot> [fluffypony]** if there's time, anonimal, can you please explain what SSU is for those who are observing the meeting ?
**\<meeting-bot> [anonimal]** Ok, latest commit makes sense.
**\<meeting-bot> [anonimal]** Yes,
**\<meeting-bot> [anonimal]** tl;dr, in plain english,
**\<meeting-bot> [anonimal]** it is one of two transport mechanisms closest to the IP layer:
**\<meeting-bot> [anonimal]** NTCP is for TCP, SSU is for UDP.
**\<meeting-bot> [anonimal]** SSU essentially takes care of encryption and negotiation with peers at the UDP level.
**\<meeting-bot> [anonimal]** Does that make sense, or should I explain more?
**\<meeting-bot> * anonimal** fetches link
**\<meeting-bot> [anonimal]** Specification here: https://geti2p.net/spec/ssu
**\<meeting-bot> [anonimal]** Overview here: https://geti2p.net/en/docs/transport/ssu
**\<meeting-bot> [EinMByte]** In case anyone is really listening: we are rewriting the SSU implementation because
**\<meeting-bot> [EinMByte]** 1) It doesn't allow for unit tests
**\<__uguu__>** i2p needs a better udp transport
**\<meeting-bot> [EinMByte]** 2) The design is bad, because separate concepts are not separated in code (packet parsing was done in the same functions as dealing with networking etc)
**\<meeting-bot> [anonimal]** X) it was an unmaintainable nightmare, like much of the codebase that we have yet to refactor.
**\<meeting-bot> [EinMByte]** __uguu__: It probably does, so let's hope SSU2 will be better
**\<meeting-bot> [EinMByte]** (I'm not sure what the satus on SSU2 is, AFAIK there's not even a spec yet)
**\<meeting-bot> [anonimal]** I had some ideas/problems/solutions when working on everything this week,
**\<meeting-bot> [anonimal]** but I need more time to flesh out tangible thought.
**\<meeting-bot> [anonimal]** I think we're on the right track, as we discussed earlier.
**\<meeting-bot> [EinMByte]** Ok, no problem. Maybe write everything down on github?
**\<meeting-bot> [anonimal]** Sure, I'll comment more in #140 or open an issue in your repo.
**\<meeting-bot> [anonimal]** Essentially, I want to take a closer look at design this week as I said I would stay away when we last spoke.
**\<meeting-bot> [anonimal]** e.g., what we discussed earlier about MAC buffer, etc.
**\<meeting-bot> [EinMByte]** Yes, in terms of design many things are currently undecided
**\<meeting-bot> [EinMByte]** I've mentioned before that this is more of a refactoring than a rewrite
**\<meeting-bot> [anonimal]** Hmm... maybe I have a different vision of end-result then.
**\<meeting-bot> [EinMByte]** At least for now, I do want design changes in the end
**\<meeting-bot> [EinMByte]** But I wanted to make it less crappy first, and then make it good
**\<meeting-bot> [anonimal]** I think I need to get my hands dirty and get more intimate with your new changes.
**\<meeting-bot> [anonimal]** I understand, as I said in #1 I completely understand and agree.
**\<meeting-bot> * anonimal** no complaints here
**\<meeting-bot> [anonimal]** So, long story short, I'd like to get more involved. Any objections EinMByte?
**\<meeting-bot> [EinMByte]** Of course not, I can use all help
**\<meeting-bot> * anonimal** could work in another branch, but I think our conflicts result in better code
**\<meeting-bot> [anonimal]** Ok, I'll comment more in #140, etc. as things progress.
**\<meeting-bot> [anonimal]** Anything else on 3.?
**\<meeting-bot> [EinMByte]** Not from me
**\<meeting-bot> * anonimal** prepares for more pasting
**\<meeting-bot> [anonimal]** Anyone here have more SSU questions?
**\<meeting-bot> * anonimal** will work on refining better responses to such questions
**\<meeting-bot> [fluffypony]** no that's perfect, thanks
**\<meeting-bot> [anonimal]** Ok, moving on
**\<meeting-bot> [anonimal]** 4. Discuss commit message labeling, e.g., how to organize first line of commits. Touch-up on C4.
**\<meeting-bot> [anonimal]** To preface, before discussing commit titles, none of this can really be enforced at the moment because there is no payout hanging over anyone's head.
**\<meeting-bot> [anonimal]** But our guide does ask to reference applicable ticket numbers in commit bodies - and its incredibly helpful.
**\<meeting-bot> [anonimal]** I'm trying to be better about doing this and I hope EinMByte would also consider doing this too.
**\<meeting-bot> [anonimal]** It should be noted that there is no mention in the guide or C4 about commit title.
**\<meeting-bot> [anonimal]** I've been using a rough system of prepending titles with class or aspect of project worked on.
**\<meeting-bot> [anonimal]** It does help for quick git-log searches. Again, not enforceable, but it does help IMHO.
**\<meeting-bot> [anonimal]** Thoughts? Objections to adding to guide?
**\<meeting-bot> [fluffypony]** can you give me an example of the prepending?
**\<meeting-bot> [anonimal]** Yes, one moment.
**\<meeting-bot> [EinMByte]** anonimal: I've noticed that you tend to include a longer summary
**\<meeting-bot> [anonimal]** fluffypony: Basically what's before the colon https://github.com/EinMByte/kovri/pull/1
**\<meeting-bot> [EinMByte]** I currently don't do that, but if you think it's worth it, I can start doing that
**\<meeting-bot> [EinMByte]** Other than that, the main thing should be that it should be reasonably clear what the commit is about
**\<meeting-bot> [fluffypony]** oh yeah that's cool
**\<meeting-bot> [EinMByte]** But we all do that already
**\<meeting-bot> [EinMByte]** I'm fine with stricter rules, just don't shout at me too much when I forget about them :p
**\<meeting-bot> [fluffypony]** I tend to do short summaries too, but I like the prepending thing
**\<meeting-bot> [anonimal]** EinMByte: I agree. If I were to ask of anything, it would be to references issues that commit addresses.
**\<meeting-bot> [anonimal]** Other than that, I personally couldn't ask you to write longer summaries. Honestly, most of what you commit I understand anyway because its well-written IMHO - but that's just me.
**\<meeting-bot> [anonimal]** So, as usual, I think about everyone else who isn't knee-deep in our mess.
**\<meeting-bot> [anonimal]** And maybe longer summaries would help?
**\<meeting-bot> [anonimal]** But 4. for me was more about commit title.
**\<meeting-bot> [EinMByte]** Ok, I'll try to reference issues more often
**\<meeting-bot> [fluffypony]** I don't think longer summaries are massively necessary as long as the commits show the route taken to get there, referencing issues is definitely helpful
**\<meeting-bot> [EinMByte]** (not in the title, though)
**\<meeting-bot> [anonimal]** Ok. So shall we take a vote on adding 'prepend class or project aspect into title of commit' into contributing guide?
**\<meeting-bot> [anonimal]** (again, at this time not enforceable - just helpful)
**\<meeting-bot> [fluffypony]** I'm fine with it
**\<meeting-bot> [anonimal]** + me = 2 yes. Anyone else?
**\<meeting-bot> [anonimal]** As fluffypony pointed out long ago, its not like anyone reads contributing guides anyway ;)
**\<meeting-bot> [fluffypony]** hah hah yeah
**\<meeting-bot> [EinMByte]** Sure
**\<meeting-bot> [fluffypony]** but at least it's there and we can encourage it
**\<meeting-bot> [EinMByte]** ^
**\<meeting-bot> [anonimal]** Ok, good point on the encouragement.
**\<meeting-bot> [fluffypony]** hey - we managed to get most Monero contributors to GPG sign commits, so it is doable :)
**\<meeting-bot> [anonimal]** Great, done.
**\<meeting-bot> [anonimal]** While we're on 4., this is off-the-cuff,
**\<meeting-bot> [anonimal]** but bitmonero is working with only 1 branch now.
**\<meeting-bot> [anonimal]** And, C4 kind of dictates that (IIRC).
**\<meeting-bot> [anonimal]** So, do we scrap branch development and work solely in master?
**\<meeting-bot> [fluffypony]** note that we have a use-case for moving back to the dev branch setup, because people just pull and compile
**\<meeting-bot> [anonimal]** I've also used arguments for two branches. I'm curious to hear EinMByte's opinion.
**\<meeting-bot> * anonimal** sigh, I2P lag
**\<meeting-bot> * anonimal** doesn't want to move on yet, running out of time though
**\<meeting-bot> [EinMByte]** anonimal: Not sure, I think it's good to have a stable branch
**\<meeting-bot> [EinMByte]** also, it doesn't hurt anyone? (I think)
**\<meeting-bot> [anonimal]** The argument is to instead warn users that anything that is built outside of a tagged version is... well, unpredictable.
**\<meeting-bot> [anonimal]** But, since we don't have any releases yet...
**\<meeting-bot> [EinMByte]** There's "unpredictable" and there's "possibly broken"
**\<meeting-bot> [EinMByte]** In my opinion those are not really the same
**\<meeting-bot> [anonimal]** Good point. I imagine though that broken branches would stay in forks and then, when fleshed out, could be sent to 1 branch master.
**\<meeting-bot> [anonimal]** But then that would require more work maintainer-side.
**\<meeting-bot> [anonimal]** Ay, too many options.
**\<meeting-bot> [anonimal]** I vote to keep two branches for now.
**\<meeting-bot> [anonimal]** Yea or Nay?
**\<meeting-bot> [EinMByte]** ok, let's keep the branches and move on :)
**\<meeting-bot> [anonimal]** Ok, moving on.
**\<meeting-bot> [anonimal]** 5. Review open tickets (assigned and/or unassigned): status, code ideas (if applicable), etc.
**\<meeting-bot> [anonimal]** My hands have been tied to SSU as we've discussed. I did hack a fix for the massive leak in #191.
**\<meeting-bot> [anonimal]** It appears to be related to LogPrint and possibly GetFormattedSessionInfo(). I need more time with it and to produce a smoother fix.
**\<meeting-bot> [anonimal]** But it doesn't address a few smaller leaks related to #191.
**\<meeting-bot> [anonimal]** So, between now and next meeting, I'm somewhat sure I'll focus on SSU, #191, and getting a windows build in working order.
**\<meeting-bot> [anonimal]** And in that order.
**\<meeting-bot> [EinMByte]** Ok
**\<meeting-bot> [anonimal]** *but* I also may start drafting a FFS proposal for a chunk of that time (I said I would last meeting). We'll see.
**\<meeting-bot> [fluffypony]** +1, FFS proposals are welcome
**\<meeting-bot> [anonimal]** EinMByte: do you think you'll be around sometime this coming week or the following week? Or are weekends better?
**\<meeting-bot> [anonimal]** fluffypony: would you please refresh my memory on the zoho/fastmail decision (my brain is scattered at the moment)?
**\<meeting-bot> [EinMByte]** I'll be around a few hours a day, but more actively in weekends
**\<meeting-bot> [fluffypony]** started the process a few days ago, we're doing Zoho
**\<meeting-bot> [anonimal]** EinMByte: sounds great.
**\<meeting-bot> [anonimal]** fluffypony: sounds great.
**\<meeting-bot> [anonimal]** Many great sounds!
**\<meeting-bot> [fluffypony]** everyone can independently forward their mails to tutanota or i2pmail, or just use the Zoho mailbox
**\<meeting-bot> [anonimal]** I'm looking forward to zoho's /projects, especially time-management.
**\<meeting-bot> [anonimal]** Kimai is a horrid *#()*@#)$@#$#@
**\<meeting-bot> [anonimal]** If anyone has experience using it...
**\<meeting-bot> [fluffypony]** never heard of it, will take a look
**\<meeting-bot> [fluffypony]** or not if it's horrible
**\<meeting-bot> * anonimal** surprised at the lack of free, personal, opensource, time-management/billable hours solutions out there
**\<meeting-bot> [fluffypony]** MS Project
**\<meeting-bot> [anonimal]** IMHO you should, it may be humorous.
**\<meeting-bot> [fluffypony]** :-P
**\<meeting-bot> [anonimal]** I can't knock their work though, I applaud what they're doing, I just wish I had more time to contribute to their project.
**\<meeting-bot> [fluffypony]** is it meeting.end time?
**\<meeting-bot> [anonimal]** Eek, one more thing.
**\<meeting-bot> * anonimal** one more paste coming
**\<meeting-bot> [anonimal]** 6. Discuss any pertinent TODO's
**\<meeting-bot> [anonimal]** In SSU: we're closer to resolving #119 with our new design. I've noted a few spots of missing implementation that I think will be resolved during the refactor.
**\<meeting-bot> [anonimal]** I had mentioned in the most recent PR my interest in more sanity tests, and EinMByte did note a few overflow checks.
**\<meeting-bot> [anonimal]** I think we're still discussing design though, so that would come a little later.
**\<meeting-bot> [anonimal]** Thoughts?
**\<meeting-bot> [EinMByte]** Yes, we have many places where we need more checks
**\<meeting-bot> [EinMByte]** at least we won't leak if we throw errors etc due smart pointer usage
**\<meeting-bot> [EinMByte]** Eventually I want to rely on exception for error handling, and I want to use the error information for peer profiling
**\<meeting-bot> [anonimal]** Ooooooooooooooo, I like that......
**\<meeting-bot> [anonimal]** I like that ALOT.
**\<meeting-bot> [anonimal]** Yes, smart pointers: something the previous project had very little interest in;
**\<meeting-bot> [anonimal]** despite the standard having been out for years.
**\<meeting-bot> [anonimal]** Anyway, I won't start bashing as we're out of time (I love a good bashing).
**\<meeting-bot> [anonimal]** Anything else on 6.?
**\<meeting-bot> [anonimal]** If not, then 7.?
**\<meeting-bot> [fluffypony]** nothing else from my side
**\<meeting-bot> [fluffypony]** next meeting same time, same place, two weeks?
**\<meeting-bot> [anonimal]** Works for me.
**\<meeting-bot> [EinMByte]** Should be fine
**\<meeting-bot> [fluffypony]** sehr gut
**\<meeting-bot> [zzz]** will we see any kovri ppl at HOPE in 3 weeks?
**\<meeting-bot> [fluffypony]** zzz: unfortunately not me, need to do no travelling for a little bit
**\<meeting-bot> [fluffypony]** got too much work to do, lol
**\<meeting-bot> [EinMByte]** not me either
**\<meeting-bot> [anonimal]** I had planned late last year but things took a completely different turn so, nope, not this time around.
**\<meeting-bot> [zzz]** ok, I believe echelon still has a ticket to sell, if anybody needs it
**\<meeting-bot> [anonimal]** Thanks zzz. That echelon, quite the organizer :)
**\<meeting-bot> [anonimal]** Anything else? Meeting?
**\<meeting-bot> [anonimal]** I want to also thank fluffypony and dEBRUYNE and anyone else for their work on getting these logs up on the site.
**\<meeting-bot> [fluffypony]** it's mostly dEBRUYNE, I just add spaces in at the end
**\<meeting-bot> [anonimal]** lol, nice.
**\<meeting-bot> [anonimal]** Ok, thanks everyone for the great meeting.
**\<meeting-bot> [fluffypony]** thanks everyone
**\<meeting-bot> [fluffypony]** meeting-bot going offline

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

@ -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*

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

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

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

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

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

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

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

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

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

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

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

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

247
_posts/2016-11-13-logs-for-the-Kovri-dev-meeting-held-on-2016-11-13.md Normal file
View File

@ -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
**\<i2p-relay> {-anonimal}** Proposed meeting items:
**\<i2p-relay> {-anonimal}** 1. Greetings
**\<i2p-relay> {-anonimal}** 2. Brief review of what's been completed since the previous meeting
**\<i2p-relay> {-anonimal}** 5. Code + ticket discussion / Q & A
**\<i2p-relay> {-anonimal}** 3. Preparing for alpha release
**\<i2p-relay> {-anonimal}** 4. Moving meeting agenda issues from monero-project/kovri to monero-project/meta
**\<i2p-relay> {-anonimal}** 6. Any additional meeting items
**\<i2p-relay> {-anonimal}** Hi
**\<i2p-relay> {-anonimal}** 7. Confirm next meeting date/time
**\<i2p-relay> {-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
**\<i2p-relay> {-anonimal}** 2. Brief review of what's been completed since the previous meeting
**\<i2p-relay> {-anonimal}** The general focus of the past two weeks has been "escaping comfort zone" work:
**\<i2p-relay> {-anonimal}** i.e., pursuing a few long-standing issues that I've avoided because they weren't fun:
**\<i2p-relay> {-anonimal}** Build:
**\<i2p-relay> {-anonimal}** - Builds builds builds! All builds are now in the GREEN!
**\<i2p-relay> {-anonimal}** - ARMv7/8 and Win32/64 builds are now online! Static builds online!
**\<i2p-relay> {-anonimal}** - Win32/64 run-time is now available after patching an upstream issue
**\<i2p-relay> {-anonimal}** - ARMv7 has a non-Kovri runtime issue, ARMv8 box still needs testing
**\<i2p-relay> {-anonimal}** - Much build-related work with pigeons, partly noted in monero-project/meta
**\<i2p-relay> {-anonimal}** - Setup kovri per-platform IRC clients for testing, say hi to them in #kovri-dev
**\<i2p-relay> {-anonimal}** Code:
**\<i2p-relay> {-anonimal}** - Resolved all Coverity defects (details in #263)!
**\<i2p-relay> {-anonimal}** - Bug fixes in addressbook + shutdown, https on windows
**\<i2p-relay> {-anonimal}** - Design and planning: global refactoring, study, and testing
**\<i2p-relay> {-anonimal}** - SSU Server testing (nothing merge-able at the moment)
**\<i2p-relay> {-anonimal}** - Debugging, attending to open milestone issues
**\<i2p-relay> {-anonimal}** - Mentoring: working with other contributors to "Make Kovri Great Again"
**\<i2p-relay> {-anonimal}** - guzzi doing his civic duty while also working on http proxy (WIP)
**\<i2p-relay> {-anonimal}** - olark providing great netdb/socks proxy documentation and refactoring
**\<i2p-relay> {-anonimal}** Misc:
**\<i2p-relay> {-anonimal}** - 7z/installer research for platform-agnostic bundling of data-dir with static binary
**\<i2p-relay> {-anonimal}** - README/Doc updates, misc. project maintenance
**\<i2p-relay> {-anonimal}** - Too many other things to mention here or things that I've simply forgotten
**\<i2p-relay> {-anonimal}** Note: confirmed earlier: run-time is online on ARMv8!
**\<i2p-relay> {-anonimal}** Anything else on point 2.?
**\<i2p-relay> {-olark}** Sums up the past 2 weeks well.
**\<i2p-relay> {-anonimal}** Side-note, JFTR: slack relay is not working and fluffypony isn't running meeting relay to #monero-dev
**\<i2p-relay> {-anonimal}** Ok, moving on,
**\<i2p-relay> {-anonimal}** 3. Preparing for alpha release
**\<guzzi>** Here fyi
**\<i2p-relay> {-anonimal}** Oh good, hi guzzi (I PM'd you earlier)
**\<guzzi>** Ok
**\<i2p-relay> {-anonimal}** So, 3. looking at https://github.com/monero-project/kovri/issues?q=is%3Aopen+is%3Aissue+milestone%3A0.1.0-alpha
**\<i2p-relay> {-anonimal}** A few of these can be moved to next milestone (they aren't urgent),
**\<i2p-relay> {-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.
**\<i2p-relay> {-anonimal}** Really there are only a few key issues that *must* be resolved for an alpha release and they are, IMHO:
**\<i2p-relay> {-anonimal}** #375 and #119 <-- at an absolute bare minimum
**\<i2p-relay> {-anonimal}** because they *really* can get in the way.
**\<i2p-relay> {-anonimal}** But that's a bare-minimum not-ideal scenario and I know we can get more done by then.
**\<i2p-relay> {-anonimal}** Any thoughts?
**\<i2p-relay> {-olark}** Yeah those are the big ones. I'll go over the addressbook and add/remove the destinations that don't work.
**\<guzzi>** 119 looks easy for u. I dont disagree
**\<guzzi>** Sorry i meant 375
**\<i2p-relay> {-anonimal}** Well, it looks straightforward, we'll see what it really looks like when the time comes :)
**\<i2p-relay> {-anonimal}** olark: re: destinations, which issue # is this?
**\<i2p-relay> {-olark}** Keep it a small list.
**\<i2p-relay> {-olark}** Some are just dead.
**\<i2p-relay> {-olark}** So we have a small list of eepsites that do work and may be useful for a new user.
**\<i2p-relay> {-olark}** Not in the milestone I believe.
**\<guzzi>** Agree on the eepsite list actually containing valid sites
**\<guzzi>** 119 looks like a critical fix for sure.
**\<i2p-relay> {-olark}** re: subscription file
**\<i2p-relay> {-olark}** Not high priority but maybe something nice to have for the first release.
**\<i2p-relay> {-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?
**\<i2p-relay> {-olark}** Just some of them never connect ever.
**\<i2p-relay> {-olark}** I'll go over them again in the coming days.
**\<i2p-relay> {-anonimal}** Ok, sounds good.
**\<i2p-relay> {-anonimal}** guzzi: well, I wouldn't say critical because it doesn't effect all routers and it certainly hasn't effect the OSX instances
**\<guzzi>** Ok understood
**\<i2p-relay> {-anonimal}** And there's always the option to disable ssu at run-time, but yes I think it should be resolved.
**\<i2p-relay> {-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
**\<i2p-relay> {-anonimal}** ;)
**\* guzzi** open my mouth
**\<i2p-relay> {-olark}** Semi-Secure UDP
**\<guzzi>** Thanks
**\<i2p-relay> {-anonimal}** guzzi: checkout the new Moneropedia entries I made that are now live on the website
**\<i2p-relay> {-anonimal}** guzzi: link is in README.md
**\<i2p-relay> {-anonimal}** (on current HEAD)
**\<guzzi>** Awesome
**\* guzzi** Todo tonight
**\<i2p-relay> {-anonimal}** So, re: release,
**\<i2p-relay> {-anonimal}** Let's keep hacking away for the next two weeks and see where we stand.
**\<i2p-relay> {-anonimal}** Any objections?
**\<guzzi>** Ok i will read your pm when i get back
**\<i2p-relay> {-olark}** Keep on hacking away ;)
**\<guzzi>** On phone now
**\<i2p-relay> {-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.
**\<guzzi>** I agree boss.
**\<i2p-relay> {-anonimal}** lol guzzi
**\<i2p-relay> {-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.
**\<i2p-relay> {-anonimal}** But I'll have to be flexible for now because there are many moving parts.
**\<i2p-relay> {-anonimal}** Anything else on point 3.?
**\<guzzi>** No
**\<i2p-relay> {-anonimal}** olark: ?
**\<i2p-relay> {-olark}** We can keep moving along.
**\<i2p-relay> {-anonimal}** 4. Moving meeting agenda issues from monero-project/kovri to monero-project/meta
**\<i2p-relay> {-anonimal}** So, as this meeting has proven, no one else in Monero looks at the meeting agendas I prepare for every meeting :)
**\<i2p-relay> {-anonimal}** With the creation of monero-project/meta, I think it would be better to not clutter the kovri repo with meeting agendas.
**\<guzzi>** Agree 100%
**\<i2p-relay> {-anonimal}** I would hope that more monero people get inolved with meeting agenda preparation and start using the meta repo too.
**\<i2p-relay> {-anonimal}** I'd like to move agendas to meta from now on. guzzi is on board. Anyone else?
**\<i2p-relay> {-olark}** Sounds good to me.
**\<i2p-relay> {-anonimal}** Alright, I'll start doing that.
**\<i2p-relay> {-anonimal}** Moving on,
**\<i2p-relay> {-anonimal}** 5. Code + ticket discussion / Q & A
**\<i2p-relay> {-iDunk}** i built kovri on win64 successfully but the build failed on linking for win32
**\<i2p-relay> {-anonimal}** We've basically covered this in point 3, but I did add some new notes to #187
**\<i2p-relay> {-iDunk-kovri-win64}** hiii
**\<i2p-relay> {-anonimal}** For #187 not sure if EinMByte is around.
**\<i2p-relay> {-anonimal}** Yay, hi iDunk-kovri-win64 :)
**\<i2p-relay> {-iDunk-kovri-win64}** :)
**\<guzzi>** Do we care about 32
**\<i2p-relay> {-anonimal}** iDunk: can you paste error after the meeting?
**\<i2p-relay> {-iDunk}** will do
**\<i2p-relay> {-anonimal}** iDunk guzzi: our win32 build is working with buildbot https://build.getmonero.org/waterfall
**\<guzzi>** Ok so it is isolated
**\<i2p-relay> {-anonimal}** Yep, most likely, we'll see.
**\<i2p-relay> {-anonimal}** Anyone have any questions/comments on open/closed issues?
**\<guzzi>** Nice work idunk thank you
**\<guzzi>** None here. You know where i am at
**\<i2p-relay> {-iDunk}** np
**\<i2p-relay> {-anonimal}** lol, sipping up a pina colada I imagine
**\<guzzi>** Lol yes.
**\<i2p-relay> {-anonimal}** olark: any questions/comments on open/closed issues?
**\<guzzi>** I also had meant you know where i am at code wise
**\<i2p-relay> {-olark}** All good ;D
**\<i2p-relay> {-anonimal}** Oh, haha!
**\<i2p-relay> {-anonimal}** * glances over issues
**\<i2p-relay> {-olark}** re: APIs
**\<i2p-relay> {-olark}** How is that coming along?
**\<i2p-relay> {-olark}** #351 and #350
**\<i2p-relay> {-anonimal}** Once more client/router work is completed, they will be easier to implement.
**\<i2p-relay> {-anonimal}** So that first, API second.
**\<i2p-relay> {-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 ;)
**\<i2p-relay> {-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.
**\<i2p-relay> {-anonimal}** (because he has strong opinions on the matter and he has great experience)
**\<i2p-relay> {-olark}** Yeah his input is very valuable.
**\<i2p-relay> {-olark}** Well known in the i2p community.
**\<_Slack> \<nanoakron>** Lol
**\<i2p-relay> {-anonimal}** I'll continue to comment in those tickets as other work progresses.
**\<i2p-relay> {-anonimal}** I always keep the APIs in mind when doing other work,
**\<i2p-relay> {-anonimal}** which always leads to more work that needs to be resolved before returning to APIs
**\<i2p-relay> {-olark}** Yep
**\<i2p-relay> {-anonimal}** (etc. etc.)
**\<i2p-relay> {-anonimal}** Ok, anything else on this point?
**\<i2p-relay> {-anonimal}** If not we can talk more about it later this week.
**\<i2p-relay> {-olark}** That is all on my side.
**\<i2p-relay> {-olark}** Ok.
**\<guzzi>** None here
**\<i2p-relay> {-anonimal}** 6. Any additional meeting items
**\<i2p-relay> {-anonimal}** Nothing from me. We have a clear plan, we're executing the plan as planned.
**\<guzzi>** None here. You will be busy. I will try to correspond efficiently s possible the next two weeks
**\<_Slack> \<nanoakron>** Slight general question about i2p - if I'm running kovri in the future, would a malicious agency be able to detect that?
**\<i2p-relay> {-olark}** ISPs can figure out you are using i2p.
**\<i2p-relay> {-anonimal}** nanoakron: that depends on the agency
**\<moneromooo>** A malicious one.
**\* moneromooo** runs
**\<_Slack> \<nanoakron>** Lol
**\<i2p-relay> {-anonimal}** nanoakron: good question, I think that was one of the SE questions I bookmarked to answer
**\<_Slack> \<nanoakron>** Are there any loose thoughts on the step beyond kovri? Steganographic encoding within normal router traffic?
**\<i2p-relay> {-anonimal}** Now that moneropedia is merged, I'll answer them.
**\<i2p-relay> {-olark}** I would like to explore better ways to obscure i2p traffic in with regular clearnet traffic, but that is for future research.
**\<_Slack> \<nanoakron>** Of course
**\<i2p-relay> {-olark}** SSU is pretty resistant to DPI and kovri already takes some countermeasure to hide the fact i2p is being used.
**\<i2p-relay> {-anonimal}** Stego obfuscation within encryption? That makes as much sense as encrypting the encryption more than it is already encrypted.
**\<i2p-relay> {-olark}** But there are lots of avenues to explore.
**\<i2p-relay> {-olark}** Packet size I believe is the biggest giveaway among others.
**\<i2p-relay> {-anonimal}** nanoakron: do you have any research on that?
**\<i2p-relay> {-anonimal}** (proving any effectiveness?)
**\<_Slack> \<nanoakron>** Sadly not :(
**\<_Slack> \<nanoakron>** It's just something I heard being discussed between two more technical people where I work a while ago.
**\<i2p-relay> {-anonimal}** nanoakron: it would probably me more effective to simply add another layer of encryption (but that isn't really necessary)
**\<_Slack> \<nanoakron>** Stego to hide bitcoin
**\<i2p-relay> {-anonimal}** (but maybe I'm not understanding your point exactly)
**\<i2p-relay> {-anonimal}** Oh, well that makes sense.
**\<i2p-relay> {-anonimal}** They're not dealing with layered encryption like we do.
**\<_Slack> \<nanoakron>** At the router level
**\<i2p-relay> {-anonimal}** (afaik)
**\<i2p-relay> {-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> \<nanoakron>** 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> \<nanoakron>** Of course!
**\<i2p-relay> {-anonimal}** nanoakron: and olark pointed out important overlay-network facts
**\<_Slack> \<nanoakron>** Yep
**\<i2p-relay> {-anonimal}** North Korea? Can't they basically do whatever they want whenever they want to on any network level?
**\<i2p-relay> {-olark}** North Korea has no internet infrastructure aside from government use afaik.
**\<_Slack> \<nanoakron>** That would be the worst case scenario. For example if our governments decided to ban all non-fiat currencies.
**\<i2p-relay> {-olark}** But if it is any indication, I2P can be run in China.
**\<i2p-relay> {-anonimal}** Doesn't their "internet" exist entirely in a class C subnet?
**\<_Slack> \<nanoakron>** Anyway, I'm just spitballing
**\<i2p-relay> {-olark}** It is important to keep those things in mind though.
**\<i2p-relay> {-anonimal}** Spitball all you want, we have 7 minutes left :)
**\<_Slack> \<nanoakron>** ;)
**\<guzzi>** Lol. True
**\<_Slack> \<nanoakron>** Something for the monero research lab
**\<guzzi>** We should at least worry about packet sizes.
**\<guzzi>** In the future
**\<guzzi>** We are going to add user agent options
**\<_Slack> \<nanoakron>** Deterministic packet sizes to prevent fingerprinting and sniffing
**\<_Slack> \<nanoakron>** ?
**\<i2p-relay> {-olark}** Blending in with SSL traffic is the ideal scenario.
**\<_Slack> \<nanoakron>** Ah yes
**\<_Slack> \<nanoakron>** Will my little Odroid C2 node (ARMv8) be able to run kovri alongside monero in its final embodiment?
**\<i2p-relay> {-anonimal}** NTCP2 is addresses TCP packet length obfuscation.
**\<i2p-relay> {-anonimal}** olark: blending in with SSL, I don't see how that would be ideal, what do you mean?
**\<i2p-relay> {-olark}** To fly under the radar more.
**\<i2p-relay> {-anonimal}** nanoakron: I'm running kovri on ARMv8 linaro right now
**\<_Slack> \<nanoakron>** Neat
**\<i2p-relay> {-olark}** If I am a mouse my best bet is to sneak in with all the other rats into the kitchen right? ;)
**\<i2p-relay> {-olark}** Hoping no one realizes I am a mouse.
**\<i2p-relay> {-anonimal}** olark: they'll tend to shutdown SSL connections before detecting NTCP/UDP signatures, I'm pretty sure of that.
**\<_Slack> \<nanoakron>** Yes, not true stego but mimickry.
**\<guzzi>** Agree.
**\<guzzi>** Any other doomsday senerios?
**\<_Slack> \<nanoakron>** Lol
**\<guzzi>** 1 min?
**\<i2p-relay> {-anonimal}** Btw: a TLS transport is still an open draft proposal from 2009 https://geti2p.net/spec/proposals
**\<i2p-relay> {-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.
**\<i2p-relay> {-anonimal}** Moving on,
**\<i2p-relay> {-anonimal}** 7. Confirm next meeting date/time
**\<i2p-relay> {-anonimal}** moneromooo: will next meeting be 18:00 for #monero-dev?
**\<i2p-relay> {-olark}** Hmmm
**\<i2p-relay> {-anonimal}** Or 17:00?
**\<i2p-relay> {-fluffypony}** oh
**\<i2p-relay> {-fluffypony}** sorry anonimal
**\<i2p-relay> {-anonimal}** Thanks for understanding fluffypony.
**\<i2p-relay> {-fluffypony}** my apologies
**\<i2p-relay> {-fluffypony}** I must've misunderstood the timing discussion
**\<i2p-relay> {-anonimal}** fluffypony: apologies accepted! Are #monero-dev meetings now at 17:00 or 18:00
**\<i2p-relay> {-anonimal}** (fluffypony: we're idling on 7. Confirm next meeting date/time)
**\<i2p-relay> {-fluffypony}** anonimal: let's update after the Monero meeting
**\<i2p-relay> {-anonimal}** Alright, I'll start with 17:00
**\<i2p-relay> {-anonimal}** Meeting in two weeks.
**\<i2p-relay> {-anonimal}** Thanks everyone!
**\<i2p-relay> {-olark}** Good talk everyone :D

327
_posts/2016-11-13-overview-and-logs-for-the-dev-meeting-held-on-2016-11-13.md Normal file
View File

@ -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
**\<Softich>** allright boys, get it started :P
**\<@fluffypony>** and tewinget
**\<medusa_>** Jaquee ping too
**\<pigeons>** hi
**\<@fluffypony>** ok so let's start with an infrastructure update
**\<Jaquee>** hi!
**\<@fluffypony>** pigeons: how goes it
**\<pigeons>** good
**\<@fluffypony>** pigeons: do you want to tell people about the new repo we're using for issues?
**\<pigeons>** github.com/monero-project/meta
**\<Softich>** https://github.com/monero-project/meta
**\<_Slack> \<nanoakron>** Please explain?
**\<Softich>** for the lazy
**\<pigeons>** for stuff realted to build machines, build infrastructure, etc
**\<pigeons>** anonimal has been using it some to get things setup for kovri needs
**\<pigeons>** so feel free
**\<luigi1112>** I got some emails about issues
**\<luigi1112>** 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> \<nanoakron>** Roger
**\<pigeons>** there is also an empty repo there now, i'll check in some build infrastructure settings there and vm templates
**\<i2p-relay> {-anonimal}** pigeons: can I PM you on Irc2p or are you AFK from that instance?
**\<pigeons>** yes i'm online there
**\<i2p-relay> {-anonimal}** \* has to leave soon
**\<@fluffypony>** ok so
**\<_Slack> \<nanoakron>** Ha
**\<_Slack> \<nanoakron>** 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> \<nanoakron>** 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
**\<iDunk>** i also do
**\<_Slack> \<nanoakron>** Could you make some details public, maybe in the readme?
**\<_Slack> \<nanoakron>** I mean instructions
**\<iDunk>** what details?
**\<@fluffypony>** @NanoAkron for running testnet and mainnet?
**\<_Slack> \<nanoakron>** Yes please
**\<@fluffypony>** ./monerod --testnet
**\<@fluffypony>** ./monerod
**\<iDunk>** start moderod normally for mainnet
**\<@fluffypony>** in two different windows
**\<_Slack> \<nanoakron>** And they're happy to play together?
**\<iDunk>** and monerod --testnet for testnet
**\<medusa_>** yes very happy
**\<pero>** needs annotated screenshots imho
**\<luigi1112>** they play separately
**\<medusa_>** like 2 small pupies
**\<_Slack> \<nanoakron>** Ok cool.
**\<_Slack> \<nanoakron>** Will get that up and running when I'm home next week.
**\<iDunk>** you also need to start monero-wallet-cli --testnet
**\<iDunk>** for a testnet wallet
**\<_Slack> \<nanoakron>** 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
**\<iDunk>** it is not necessary
**\<luigi1112>** not next like jan
**\<luigi1112>** and it doesn't need a fork?
**\<gingeropolous>** right. it doesn't need a fork.
**\<@fluffypony>** the fork would only have been done to avoid old nodes showing weird error messages
**\<iDunk>** client that support fluffy blocks talk fluffy
**\<@fluffypony>** but honestly it's not a big deal
**\<iDunk>** and those that don't, don't afaik
**\<_Slack> \<nanoakron>** 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.
**\<iDunk>** there is no block size reduction
**\<dEBRUYNE>** \<pero> #58 is not fixed \<= apologies, should be reopened then
**\<_Slack> \<nanoakron>** 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.
**\<iDunk>** nonaoakron: i am nitz
**\<iDunk>** not*
**\<iDunk>** 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> \<nanoakron>** Yes ok I wasn't precise enough
**\<iDunk>** :)
**\<+moneromooo>** hi
**\<_Slack> \<nanoakron>** It reduces block transmission and reduplication, reducing overall network traffic and 'burstiness'
**\<@fluffypony>** yes
**\<_Slack> \<nanoakron>** Thereby improving obfuscation efforts ;)
**\<@fluffypony>** ok
**\<_Slack> \<nanoakron>** And kovri
**\<_Slack> \<nanoakron>** Should also benefit
**\<+moneromooo>** Can we leave that till after we're done with the meeting though ?
**\<_Slack> \<nanoakron>** Due to packet size reduction and traffic reduction. Good reasons to make it compulsory at some point in the future.
**\<gingeropolous>** ^^
**\<_Slack> \<nanoakron>** Ok will leave it now.
**\<@fluffypony>** @NanoAkron it *is* compulsory
**\<@fluffypony>** ok so
**\<_Slack> \<nanoakron>** Ja
**\<@fluffypony>** Jaquee / medusa_ could you give us a GUI update, based on the stuff that's been done in the past 2 weeks ?
**\<Jaquee>** yeah
**\<Jaquee>** We've made great progress last couple of weeks. A lot of great contributions and inputs from new people. Great to see!
**\<Jaquee>** All critical issues i know of are fixed and we have a very good looking, working gui with all basic functionality in place.
**\<Jaquee>** I believe next step is building binaries to make it possible for more people to test it
**\<@fluffypony>** ok
**\<Jaquee>** 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
**\<Softich>** nice, can you give us an ETA for the download? :)
**\<Jaquee>** sounds good
**\<@fluffypony>** so it will take a couple of days to wrap up a point release too
**\<Jaquee>** ok. makes sense
**\<_Slack> \<nanoakron>** Can I ask about translations/localisation?
**\<Jaquee>** yes
**\<@fluffypony>** sure
**\<Jaquee>** i haven't worked on those parts very much though. but i can try to answer your questions.
**\<_Slack> \<nanoakron>** 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?
**\<Jaquee>** i think dEBRUYNE is planning to publish the translation files somewhere.
**\<dEBRUYNE>** 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
**\<dEBRUYNE>** And it's a bit of a pita to get the strings out
**\<_Slack> \<nanoakron>** Makes more sense to test right now anyway
**\<maitscha>** today I tried to update german translations, but there seems to be a bug choosing the language (at least under macos)
**\<Jaquee>** maitscha: i'm not sure if translations are fully implemented yet
**\<medusa_>** yes we took them out basically
**\<_Slack> \<nanoakron>** Some wizard could probably whip up a way to pull translations from another coin... ;)
**\<medusa_>** to get it as stable a spossible for now
**\<maitscha>** ok, I think the translation stuff needs some fixes to get it working. should we open a ticket?
**\<Jaquee>** maitscha: yes please
**\<Jaquee>** speaking of issues...
**\<Jaquee>** 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
**\<Jaquee>** ok. and collaborator = write access right?
**\<@fluffypony>** yes
**\<@fluffypony>** so it's too much of a security risk to hand out
**\<Jaquee>** 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
**\<medusa_>** personally i think we should increase the circel of caloborators by at least 1
**\<@fluffypony>** medusa_: the entire Core Team have access
**\<medusa_>** it seemed to me it is hard to keep track, at least this week
**\<medusa_>** also for core?
**\<@fluffypony>** the issue is that the people that can manage issues != the people that can be responsible for merging code
**\<Jaquee>** 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)
**\<medusa_>** 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
**\<medusa_>** haha
**\<Jaquee>** fluffypony: lol ok
**\<_Slack> \<nanoakron>** I think it would be reasonable to give mooo merge access as a paid major contributor who has demonstrated talents
**\<_Slack> \<nanoakron>** 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
**\<medusa_>** yes but sometimes if we are active that causes issues
**\<Jaquee>** makes sense. there were a lot of code conflicts last week that could have been avoided
**\<medusa_>** or can cause issues
**\<@fluffypony>** medusa_: merging stuff rapidly is a bad idea, we need eyes on code
**\<Jaquee>** \*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)
**\<medusa_>** 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
**\<medusa_>** normally it also wroks well
**\<+moneromooo>** No worries, it's less work than making them in the first place usually :)
**\<medusa_>** this week was pretty extreme in all forms
**\<@fluffypony>** medusa_: the QML stuff is pretty rough in terms of merge conflicts too
**\<endogenic>** 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> \<nanoakron>** 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
**\<gingeropolous>** is dev branch happening?
**\<@fluffypony>** gingeropolous: no not atm
**\<Jaquee>** ok. security first. i'm sure it works ok most of the time. 2 last weeks was extreme.
**\<@fluffypony>** indeed
**\<Jaquee>** but we could keep this in mind and evaluate further on?
**\<medusa_>** yes you stay on watch ;-)
**\<Jaquee>** :D
**\<@fluffypony>** Jaquee: yes absolutely
**\<gingeropolous>** would the dev branch approach be a way to get around the merge "bottleneck" ? i assume its still complicated b/c of zeromq..
**\<gingeropolous>** or are u talking about core. (i will shut up now)
**\<_Slack> \<nanoakron>** What's the plan if something horrible happens to you FP, like going on holiday for a month without internet access?
**\<proxmr>** Hello guys
**\<@fluffypony>** gingeropolous: no, you still can't have fine-grained collaborators on a per-branch basis
**\<endogenic>** nanoakron: dead pony switch?
**\<_Slack> \<nanoakron>** Lol. Yeah :) (also :( )
**\<endogenic>** yeah
**\<endogenic>** :’(
**\<Jaquee>** but you can have branch specific permissions right?
**\<Jaquee>** not sure if it would help though.
**\<maitscha>** "protected branches"
**\<@fluffypony>** Jaquee: you can, and it might be worth fiddling with later on
**\<Jaquee>** all right
**\<Jaquee>** imo we can leave this subject for now.
**\<Jaquee>** any more questions regarding the gui?
**\<asdef>** irc logs anywhere? for people who came too late
**\<proxmr>** Is the gui coming in 2 days ?
**\<maitscha>** Jaquee: how can I start the GUI under MacOS and get the console output?
**\<@fluffypony>** proxmr: no, that's not how software development works
**\<Jaquee>** maitscha: one sec
**\<maitscha>** Jaquee: that would help debugging ...
**\<Jaquee>** maitscha: build/release/bin/monero-core.app/Contents/MacOS/monero-core
**\<asdef>** any screenshots already existing? so we can see an be happy?
**\<Jaquee>** in monero-core dir
**\<proxmr>** Sorry, some guy just told me on some forum, so i came to check. i appologize
**\<maitscha>** ah ok
**\<iDunk>** maitscha: doesn't it give outout when started from the command line like on linux?
**\<medusa_>** asdef: check reddit
**\<_Slack> \<nanoakron>** No worries.
**\<maitscha>** I always started it with the finder
**\<dEBRUYNE>** Please don't interrupt the dev meeting
**\<Jaquee>** iDunk: yes. but it's not that easy to find the binary
**\<Jaquee>** it's in the .app package
**\<iDunk>** ok
**\<maitscha>** Jaquee: works, thanks
**\<Jaquee>** yw
**\<Jaquee>** all right.
**\<Jaquee>** more gui related?
**\<_Slack> \<nanoakron>** None here
**\<maitscha>** there are at least 2 people who would like to make a style guide
**\<_Slack> \<nanoakron>** That's a good idea
**\<maitscha>** should this be coordinated?
**\<medusa_>** i think the best place to discuss specific stuff is either on github or here in the channel
**\<Jaquee>** yes. that would be good. not sure how. but i can ask them to get in contact with each other to start
**\<vertp>** 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.
**\<maitscha>** or at least a place where people can post design/ux-related improvements?
**\<@fluffypony>** github
**\<Guest5849>** 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>** **\<tfi_charmers>** Yes, styleguide, one was me. I’m still able to help.
**\<@fluffypony>** Guest5849: a beta, yes
**\<medusa_>** 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> \<nanoakron>** Where's the best place to coordinate a style guide? A new Git repo or a wiki?
**\<medusa_>** always considering risk reward ofc
**\<@fluffypony>** people open issues, they get fixed, eventually you hit enough milestones / new features for a new release
**\<vertp>** 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
**\<maitscha>** 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
**\<vertp>** I agree, I mean more for illya and jaquee
**\<pero>** generally an 'issue freeze' is a bad idea
**\<@fluffypony>** can't force them either ;)
**\<medusa_>** vertp: we have to always allow people opening issues. their feedback is very valuable
**\<pero>** a feature freeze is an entirely different thing and is already somewhat implemented
**\<vertp>** I agree medusa_
**\<Jaquee>** vertp: me and ilya are more or less frozen for the moment. :P
**\<@fluffypony>** yes
**\<Jaquee>** as in agreed on that current version can be released as beta
**\<_Slack> \<nanoakron>** Vertp: we just follow a simple alpha -> beta -> release methodology, keeping in mind that even point releases are beta software under constant development
**\<vertp>** Awesome, thats what I was going for Jaquee
**\<vertp>** 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
**\<vertp>** Which I think we all agree on
**\<Jaquee>** yes
**\<vertp>** great!
**\<medusa_>** yes wa try to be very pragmatic
**\<_Slack> \<nanoakron>** 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
**\<iDunk>** wat
**\<Jaquee>** 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> \<nanoakron>** Cool
**\<Jaquee>** fluffypony: sounds interesting.
**\<Jaquee>** tfi_charmers: can you sync with that other ux guy?
**\<_Slack> \<nanoakron>** Does sound interesting
**\<Jaquee>** so you don't end up working on the same issues
**\<@fluffypony>** ok - can we call this meeting done?
**\<_Slack>** **\<tfi_charmers>** @jaquee can do.
**\<Jaquee>** great
**\<Jaquee>** fluffypony: yes
**\<@fluffypony>** ok tks
**\<+moneromooo>** Just one thing before: when does someone else do the builds ?
**\<_Slack> \<nanoakron>** I was going to raise the issue of databases if hyc, fp and mooo are in the same room
**\<iDunk>** hyc is roaming belfast
**\<_Slack> \<nanoakron>** A veritable vipers nest of opinions ;)
**\<iDunk>** anyway, i'm with fluffypony and moneromooo on the db issue
**\<_Slack> \<nanoakron>** Why do we need the ability to iterate and test the database back end in production code?
**\<_Slack> \<nanoakron>** And aren't we effectively overruling our resident database expert, hyc?
• moneromooo: facepalms
**\<iDunk>** ^
**\<gingeropolous>** where's this discussion? i totally missed this one. not that I can do anything.
**\<_Slack> \<nanoakron>** It's a PR of mine
**\<_Slack> \<nanoakron>** 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> \<nanoakron>** 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.
**\<gingeropolous>** and the prebuild binaries are all LMDB, right? so its not like anything's being shipped...
**\<gingeropolous>** \*prebuilt
**\<+moneromooo>** The current ones all are, yes.
**\<dogecoinsarefun>** fluffyblocks still LMDB too right?
**\<+moneromooo>** Unrelated.
**\<dogecoinsarefun>** 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.
**\<iDunk>** agreed
**\<+moneromooo>** There was a all RAM db being worked on, though I'm not sure it still is.
**\<_Slack> \<nanoakron>** So has the compiler been smart enough to strip the selection stuff or is there still bloat and overhead that could be trimmed?
**\<_Slack> \<nanoakron>** 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> \<nanoakron>** I'll try that
**\<+moneromooo>** Now, the threshold where an improvement becomes larger than the loss of generality is pretty subjective too.
**\<_Slack> \<nanoakron>** 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?
**\<gingeropolous>** is it just for compiling performance?
**\<+moneromooo>** IIRC, I said keep the selcetion code, just remove the bdb option.
**\<_Slack> \<nanoakron>** 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> \<nanoakron>** 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> \<nanoakron>** 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> \<nanoakron>** And the final thing I wanted to ask today was whether FP could keep killing cold issues ;)
**\<_Slack> \<nanoakron>** Tis all from me

265
_posts/2016-11-27-logs-for-the-Kovri-dev-meeting-held-on-2016-11-27.md Normal file
View File

@ -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
**\<i2p-relay> {-fluffypony}** ok anonimal
**\<i2p-relay> {-fluffypony}** Kovri meeting start, all yours
**\<i2p-relay> {-meeting-bot} [anonimal]** 1. Greetings
**\<i2p-relay> {-meeting-bot} [anonimal]** 2. Brief review of what's been completed since the previous meeting
**\<i2p-relay> {-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
**\<i2p-relay> {-meeting-bot} [anonimal]** 4. Code + ticket discussion / Q & A
**\<i2p-relay> {-meeting-bot} [anonimal]** 5. Any additional meeting items
**\<i2p-relay> {-meeting-bot} [anonimal]** 6. Confirm next meeting date/time
**\<i2p-relay> {-meeting-bot} [anonimal]** Hi
**\<i2p-relay> {-meeting-bot} [anonimal]** 1.
**\<i2p-relay> {-fluffypony}** hi
**\<i2p-relay> {-guzzi}** hi
**\<i2p-relay> {-fluffypony}** asl?
**\<ArticMine>** Hi
**\<i2p-relay> {-iDunk}** hi
**\<i2p-relay> {-olark}** Greetings
**\<moneromooo>** Hi
**\<i2p-relay> {-meeting-bot} [anonimal]** Hi fluffypony guzzi olark iDunk ArticMine moneromooo
**\<i2p-relay> {-meeting-bot} [anonimal]** EinMByte is idling as are the others, afaict.
**\<i2p-relay> {-meeting-bot} [anonimal]** 2. Brief review of what's been completed since the previous meeting
**\<binaryFate>** late greetings. watching.
**\<i2p-relay> {-meeting-bot} [anonimal]** I'll keep it generic: bug fixes (many were difficult bugs) + refactoring, mentoring, and research.
**\<i2p-relay> {-meeting-bot} [anonimal]** *Poof!* done.
**\<i2p-relay> {-meeting-bot} [anonimal]** Anything else on 2? :)
**\<i2p-relay> {-fluffypony}** can I add to 2?
**\<i2p-relay> {-meeting-bot} [anonimal]** git log and github are available for details.
**\<i2p-relay> {-meeting-bot} [anonimal]** Of course fluffypony
**\<i2p-relay> {-fluffypony}** I'd like to congratulate anonimal on completing his first milestone, even if he won't admit to it yet :-P
**\<i2p-relay> {-fluffypony}** first full-time FFS "employee", first milestone :)
**\<i2p-relay> {-meeting-bot} [anonimal]** Grr! Well, thank you fluffypony.
**\<i2p-relay> {-guzzi}** and thanks for mentoring.
**\<i2p-relay> {-fluffypony}** and we didn't even need to blockchain it!
**\<i2p-relay> {-olark}** Good work. ;)
**\<i2p-relay> {-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.
**\<i2p-relay> {-fluffypony}** I think everyone here will attest to the amount of work you do
**\<i2p-relay> {-guzzi}** no doubt.
**\<i2p-relay> {-meeting-bot} [anonimal]** No problem guzzi, thank *you* for your great progress.
**\<i2p-relay> {-fluffypony}** "anonimal made me the man I am today" - fluffypony, 2016
**\<i2p-relay> {-olark}** He's called anonimal for a reason haha
**\<i2p-relay> {-fluffypony}** olark: coupled with my quote I think that's one for the history books
**\<i2p-relay> {-meeting-bot} [anonimal]** lol oh you guys, thanks for acknowledgements. I'm glad to be here with you all.
**\<i2p-relay> {-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?
**\<i2p-relay> {-guzzi}** onward
**\<i2p-relay> {-fluffypony}** let's move on
**\<i2p-relay> {-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
**\<i2p-relay> {-meeting-bot} \* anonimal** clicks
**\<i2p-relay> {-meeting-bot} [anonimal]** Ok, don't be alarmed, but it's actually not a lot if you look carefully.
**\<i2p-relay> {-meeting-bot} [anonimal]** Some of these can even be moved to next milestone if needed.
**\<i2p-relay> {-meeting-bot} [anonimal]** fluffypony: can you give a status on 33c3 and your thoughts on a release (like we spoke about earlier)?
**\<i2p-relay> {-fluffypony}** yes
**\<i2p-relay> {-fluffypony}** so our original plan was to co-host an assembly with i2p at 33C3
**\<i2p-relay> {-fluffypony}** basically hosting an i2p + Monero table
**\<i2p-relay> {-fluffypony}** and then have the Kovri alpha ready by then
**\<i2p-relay> {-fluffypony}** unfortunately this year's congress ticketing setup has been a mess
**\<i2p-relay> {-fluffypony}** through no fault of their own, this is the most popular CCC ever
**\<i2p-relay> {-fluffypony}** we tried to book 10+ tickets at all 3 of the public booking dates
**\<i2p-relay> {-fluffypony}** and got nothing
**\<i2p-relay> {-meeting-bot} [anonimal]** Wow, that's insane.
**\<i2p-relay> {-fluffypony}** I managed to get tickets for myself and othe, after the fact
**\<i2p-relay> {-fluffypony}** but it's not enough to man a table - we'd have needed 8+ community members for htat
**\<i2p-relay> {-fluffypony}** that
**\<i2p-relay> {-fluffypony}** in view of the foregoing, we're no longer obligated to hit our alpha release date
**\<i2p-relay> {-meeting-bot} [anonimal]** Ok, well that's great to hear you at least got two tickets.
**\<i2p-relay> {-fluffypony}** this doesn't mean we won't stick to it, but it means we can choose how we want to plan it
**\<i2p-relay> {-meeting-bot} [anonimal]** Ok, well here are my thoughts on the reality of the situation, I'll try to choose my words wisely:
**\<i2p-relay> {-meeting-bot} [Jake__]** Is their any news on the GUI beta binaries.
**\<i2p-relay> {-meeting-bot} [fluffypony]** Jake__: this is the Kovri meeting
**\<i2p-relay> {-meeting-bot} [fluffypony]** you can ask later
**\<i2p-relay> {-meeting-bot} [Jake__]** Nvm
**\<i2p-relay> {-meeting-bot} [Jake__]** My mistake
**\<i2p-relay> {-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.
**\<i2p-relay> {-meeting-bot} [anonimal]** I mean, sure, I can most likely get everything done in time, but is it really worth it?
**\<i2p-relay> {-fluffypony}** anonimal: that's fair
**\<i2p-relay> {-meeting-bot} [anonimal]** The packaging aspect alone will be 'fun' to deal with, *especially* come upgrade time.
**\<i2p-relay> {-fluffypony}** are we auto-upgrading ala Java i2p?
**\<i2p-relay> {-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.
**\<i2p-relay> {-meeting-bot} [anonimal]** We wouldn't if we released this month unless I dropped other higher priority issues.
**\<i2p-relay> {-meeting-bot} \* anonimal** thinking
**\<i2p-relay> {-fluffypony}** look
**\<i2p-relay> {-fluffypony}** zzz2 will attest to the fact that part of i2p's network stability is due to the auto-updater
**\<i2p-relay> {-fluffypony}** so let's not rush something out that doesn't have that
**\<moneromooo>** Do I understand code that will fetch more code and run it on the user's machine ? Unprompted ?
**\<moneromooo>** Or merely tell the user there's an update to install at their earliest convenience ?
**\<i2p-relay> {-fluffypony}** moneromooo: it's opt-out, yes
**\<moneromooo>** That;s not nice.
**\<i2p-relay> {-fluffypony}** moneromooo: you could do a decaying prompt
**\<moneromooo>** What is this ?
**\<i2p-relay> {-fluffypony}** prompt the user, if after 15 days they haven't installed it, then install it for them
**\<i2p-relay> {-meeting-bot} [anonimal]** The current UI does not provide any useful control to an end-user.
**\<moneromooo>** I suppose that's less nasty.
**\<i2p-relay> {-fluffypony}** moneromooo: there's just been a spate of bannings on the network, of old clients that aren't updated
**\<i2p-relay> {-fluffypony}** if there's data leakage on older clients it can compromise newer ones
**\<i2p-relay> {-fluffypony}** so it's not something to be taken lightly
**\<i2p-relay> {-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?
**\<i2p-relay> {-fluffypony}** end users
**\<i2p-relay> {-fluffypony}** do we even have a stable API for devs?
**\<i2p-relay> {-guzzi}** realease implies end users imo.
**\<i2p-relay> {-meeting-bot} [anonimal]** Nope, more router issues to fix first.
**\<i2p-relay> {-fluffypony}** ok so then end users :)
**\<i2p-relay> {-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.
**\<i2p-relay> {-meeting-bot} [anonimal]** I guess anything called "release" will hold a certain weight,
**\<i2p-relay> {-meeting-bot} [anonimal]** Maybe we can compromise, find a middle-ground somehow.
**\<i2p-relay> {-fluffypony}** true
**\<i2p-relay> {-meeting-bot} [anonimal]** I'd like to work with pigeons on nightly releases, that could be a start.
**\<i2p-relay> {-meeting-bot} [anonimal]** I don't think we'll have the website done in time (will we?)
**\<i2p-relay> {-meeting-bot} [anonimal]** As for "release", I can simply throw the bundle together in nightly releases.
**\<i2p-relay> {-meeting-bot} [anonimal]** I think what people really want is something that "feels" released.
**\<i2p-relay> {-meeting-bot} [anonimal]** The title means nothing really.
**\<i2p-relay> {-fluffypony}** we can couple nightlies with the Monero nightlies
**\<i2p-relay> {-meeting-bot} [anonimal]** Sounds fair.
**\<i2p-relay> {-fluffypony}** on the list of alpha issues
**\<i2p-relay> {-fluffypony}** we've made progress on the Zoho setup
**\<i2p-relay> {-fluffypony}** it's been a bit of a PITA, but pigeons has figured most of it out
**\<i2p-relay> {-fluffypony}** we'll be moving getmonero.org over in the next week or so, and then we can do Kovri emails too
**\<i2p-relay> {-meeting-bot} [anonimal]** Ok, sounds good.
**\<i2p-relay> {-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.
**\<i2p-relay> {-meeting-bot} [pigeons]** I beleive you said currently the make system doesnt have an option yet for a static build, right?
**\<i2p-relay> {-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).
**\<i2p-relay> {-meeting-bot} [MEATPLOW]** im here for the free food
**\<i2p-relay> {-meeting-bot} [anonimal]** pigeons: for kovri? No, we can build static.
**\<i2p-relay> {-meeting-bot} [fluffypony]** MEATPLOW: we have snacks and beer after the meetings
**\<i2p-relay> {-meeting-bot} [pigeons]** wow i thought thats why you told me to remove the build uploads
**\<i2p-relay> {-iDunk}** win builds are not realy static
**\<i2p-relay> {-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).
**\<i2p-relay> {-meeting-bot} [pigeons]** OK
**\<i2p-relay> {-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
**\<i2p-relay> {-iDunk}** win64 is not static at all, win32 looks static but still requires dlls from msys2
**\<i2p-relay> {-meeting-bot} [anonimal]** fluffypony: so final verdict for alpha release: focus on getting nightly releases ready in place of a single release?
**\<i2p-relay> {-fluffypony}** yes
**\<i2p-relay> {-meeting-bot} [anonimal]** (at least for this month)
**\<i2p-relay> {-fluffypony}** make pigeons work
**\<i2p-relay> {-meeting-bot} [anonimal]** lol
**\<i2p-relay> {-fluffypony}** :-P
**\<i2p-relay> {-iDunk}** :)
**\<i2p-relay> {-meeting-bot} [anonimal]** Ok, how does that sound to everyone? Yay? Nay?
**\<i2p-relay> {-iDunk}** Yay
**\<moneromooo>** Sounds good to this member of the peanut gallery
**\<i2p-relay> {-olark}** Nightly builds are a good compromise imo.
**\<i2p-relay> {-olark}** Yay
**\<i2p-relay> {-meeting-bot} [anonimal]** Awesome. guzzi, any thoughts?
**\<i2p-relay> {-guzzi}** sounds awesome
**\<i2p-relay> {-meeting-bot} [anonimal]** He may be AFK.
**\<i2p-relay> {-guzzi}** excited
**\<i2p-relay> {-meeting-bot} [anonimal]** Oh there you are, ok great.
**\<i2p-relay> {-guzzi}** this will be motivating
**\<i2p-relay> {-meeting-bot} [anonimal]** Excellent! Moving on,
**\<i2p-relay> {-meeting-bot} [anonimal]** 4. Code + ticket discussion / Q & A
**\<i2p-relay> {-meeting-bot} [anonimal]** Focusing on those milestone issues,
**\<i2p-relay> {-meeting-bot} [anonimal]** fluffypony: I've seen someone pop into #monero-dev from time to time offering webdev, did anything come of that?
**\<i2p-relay> {-fluffypony}** no, they're mostly put off when they get told they can't use Javascript
**\<i2p-relay> {-fluffypony}** :-P
**\<i2p-relay> {-meeting-bot} [anonimal]** lol
**\<i2p-relay> {-meeting-bot} [anonimal]** Ok, so once zoho is resolved then the site (server) can come online?
**\<i2p-relay> {-meeting-bot} [anonimal]** And the rest is a matter of code/content?
**\<i2p-relay> {-fluffypony}** yes
**\<i2p-relay> {-fluffypony}** well two things actually
**\<i2p-relay> {-fluffypony}** Zoho is for email
**\<i2p-relay> {-fluffypony}** the new hosting infrastructure is for site
**\<i2p-relay> {-fluffypony}** both are running parralel-ish
**\<i2p-relay> {-fluffypony}** parallel-ish
**\<i2p-relay> {-meeting-bot} [anonimal]** https://github.com/monero-project/kovri/issues/46#issuecomment-242990742
**\<i2p-relay> {-meeting-bot} [vertp]** Is there a new site going up to replace getmonero?
**\<i2p-relay> {-meeting-bot} [anonimal]** lol, time will fly.
**\<i2p-relay> {-meeting-bot} [vertp]** Oh, kovri. sorry
**\<i2p-relay> {-meeting-bot} [anonimal]** vertp: good question, fluffypony is getmonero getting work done too?
**\<i2p-relay> {-fluffypony}** no
**\<i2p-relay> {-fluffypony}** same deal
**\<i2p-relay> {-fluffypony}** every time someone says "WE MUST REDESIGN THE WEBSITE"
**\<i2p-relay> {-fluffypony}** then I go "ok, make sure to design the forum to match, and you must have non-JS fallbacks"
**\<i2p-relay> {-fluffypony}** and they slink off into the distance
**\<i2p-relay> {-meeting-bot} [pero]** website is fine imo
**\<i2p-relay> {-meeting-bot} [anonimal]** hahaha
**\<i2p-relay> {-meeting-bot} [vertp]** I think getmonero is perfectly fine as is for the record, just was wondering what "this" site was in reference to
**\<i2p-relay> {-meeting-bot} [ferretinjapan]** :)
**\<i2p-relay> {-fluffypony}** I'm going to write a garbage collector daemon called Waste
**\<i2p-relay> {-fluffypony}** and the binary will be wasted
**\<i2p-relay> {-meeting-bot} [anonimal]** muh js
**\<i2p-relay> {-meeting-bot} [pero]** it has a refreshing aura of authenticity
**\<i2p-relay> {-fluffypony}** and the website will be getwasted.org
**\<i2p-relay> {-meeting-bot} [hyc]** lol
**\<i2p-relay> {-meeting-bot} [MrWatcher]** he
**\<i2p-relay> {-meeting-bot} \* anonimal** lol, hears drum rimshot
**\<moneromooo>** So... next time someone asks about the website, I've got a ready made answer: "slink off"
**\<i2p-relay> {-fluffypony}** "slink you too, buddy!"
**\<i2p-relay> {-meeting-bot} [anonimal]** I think the rest of the issues speak for themselves. One question though,
**\<i2p-relay> {-meeting-bot} [anonimal]** Can anyone reproduce #434 on their armv7 device?
**\<i2p-relay> {-fluffypony}** the only arm device I have access to right now is the one under my sleeve device
**\<i2p-relay> {-fluffypony}** but I'll try it when I'm back home
**\<i2p-relay> {-guzzi}**
**\<i2p-relay> {-meeting-bot} [anonimal]** lol, more drum rimshots, fluffypony is on a roll.
**\<i2p-relay> {-meeting-bot} [anonimal]** guzzi olark: anything on point 4 "Code + ticket discussion / Q & A"?
**\<i2p-relay> {-olark}** All good ;)
**\<i2p-relay> {-meeting-bot} [anonimal]** guzzi is probably at the beach again.
**\<i2p-relay> {-olark}** Slurping up a margarita.
**\<i2p-relay> {-meeting-bot} [anonimal]** hah
**\<i2p-relay> {-meeting-bot} [anonimal]** Ok, moving on. 5. Any additional meeting items
**\<i2p-relay> {-fluffypony}** the glamorous life of a Kovri contributor
**\<i2p-relay> {-fluffypony}** nothing from my side
**\<i2p-relay> {-fluffypony}** * eyes his beer
**\<i2p-relay> {-meeting-bot} [_Slack] \<nanoakron>** Beer? Sacrilege for a South African…although I hear there’s a good craft scene developing.
**\<i2p-relay> {-meeting-bot} [anonimal]** Quite glamorous indeed.
**\<moneromooo>** I'll mention again that I reaaally hate software that will take it upon itself to download/run stuff.
**\<i2p-relay> {-meeting-bot} [anonimal]** Nothing additional from me.
**\<i2p-relay> {-fluffypony}** moneromooo I know, but think about the average Kovri user
**\<i2p-relay> {-fluffypony}** (in the future, not now)
**\<moneromooo>** The average kovri user may well be prompted.
**\<i2p-relay> {-meeting-bot} [taushet]** moneromooo, so no 30-day trial from McAfee with the Kovri binaries then?
**\<i2p-relay> {-fluffypony}** LOL
**\<i2p-relay> {-meeting-bot} [iDunk]** LOL
**\<i2p-relay> {-olark}** Now that fluffypony brang up using TweetNaCl in the monero meeting. Are there any boundaries for Kovri using TweetNaCl functions where possible?
**\<i2p-relay> {-fluffypony}** and a personal introductory video from McAfee himself ?
**\<i2p-relay> {-olark}** I just have recently been fascinated with TweetNaCl, Salsa20 etc that it seems Kovri could benefit from some of those functions.
**\<i2p-relay> {-olark}** A compact crypto library for a compact i2p router. Am I right? ;D
**\<i2p-relay> {-meeting-bot} [anonimal]** moneromooo: me too. I think as long as it's optional we should be ok.
**\<moneromooo>** Excellent. So opt-in :)
**\<moneromooo>** (and banned until upgraded is fine as a protection)
**\<i2p-relay> {-olark}** Just spitballing anyway.
**\<i2p-relay> {-guzzi}** all good for me on #4. i am learning a ton. as fast as I am able to.
**\<i2p-relay> {-fluffypony}** olark: yeah definitely
**\<i2p-relay> {-meeting-bot} [anonimal]** cryptopp has salsa20.
**\<i2p-relay> {-fluffypony}** I think the important thing is identifying where TweetNaCl's correctness is useful
**\<i2p-relay> {-fluffypony}** because it sacrifices performance for verifiable correctness
**\<i2p-relay> {-olark}** Right.
**\<i2p-relay> {-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.
**\<i2p-relay> {-olark}** etc
**\<i2p-relay> {-meeting-bot} [anonimal]** I'd want to review before jumping on the tweenacl train.
**\<i2p-relay> {-meeting-bot} [anonimal]** If it can't replace supercop then I don't see much of a point.
**\<i2p-relay> {-meeting-bot} [anonimal]** *If*.
**\<i2p-relay> {-olark}** Taking advantage of TweetNaCl's verifiable correctness I think is more valuable then the slight downside of mildly less effecient operations.
**\<i2p-relay> {-olark}** TweetNaCl has ed25519 signing operations.
**\<i2p-relay> {-olark}** Is the most recent paper afaik
**\<i2p-relay> {-olark}** https://tweetnacl.cr.yp.to/tweetnacl-20140917.pdf
**\<i2p-relay> {-fluffypony}** TweetNaCl is the successor to SUPERCOP in many ways
**\<i2p-relay> {-meeting-bot} [anonimal]** Release dates not being one of them if latest tweetnacl was 2014.
**\<i2p-relay> {-fluffypony}** they're not adding functions
**\<i2p-relay> {-fluffypony}** so there aren't new releases except to fix bugs
**\<i2p-relay> {-olark}** It is the original 25 NaCl functions.
**\<i2p-relay> {-fluffypony}** and given its conciseness there haven't been many of those
**\<i2p-relay> {-meeting-bot} [anonimal]** Needs more research on our end. We also use other functions from supercop.
**\<i2p-relay> {-meeting-bot} [anonimal]** 18:00, out of time, I'll be around after the meeting.
**\<i2p-relay> {-fluffypony}** kk
**\<i2p-relay> {-meeting-bot} [anonimal]** 6. Confirm next meeting date/time
**\<i2p-relay> {-fluffypony}** meeting bot going down
**\<i2p-relay> {-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.
**\<i2p-relay> {-meeting-bot} [anonimal]** Same time, two weeks?
**\<i2p-relay> {-fluffypony}** oh after 6
**\<i2p-relay> {-olark}** Sounds good.
**\<i2p-relay> {-meeting-bot} [anonimal]** fluffypony: 17:00 ok? Same time?
**\<i2p-relay> {-guzzi}** ok with me
**\<i2p-relay> {-fluffypony}** ok
**\<i2p-relay> {-fluffypony}** done and dusted
**\<i2p-relay> {-olark}** Good talk everyone :D
**\<i2p-relay> {-fluffypony}** meeting bot off

248
_posts/2016-11-27-overview-and-logs-for-the-dev-meeting-held-on-2016-11-27.md Normal file
View File

@ -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
**\<tewinget>** ugh, I wanted to stay up for the dev meeting, but I just...can't.
**\<tewinget>** I'll put an update here in a minute or two though, someone can paste it for me perhaps.
**\<fluffypony>** tks tewinget
**\<tewinget>** so the daemon and wallet talk via zmq now (yay!)
**\<tewinget>** 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.
**\<tewinget>** (parameters like bind port/address and such)
**\<tewinget>** don't have any rpc security features like user agent and what-not put in yet, that'll come with time.
**\<tewinget>** 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.
**\<moneromooo>** user-agent was a quick fix anyway. It should not be merged in 0MQ. Proper auth should be done instead.
**\<tewinget>** once I get *that* ironed out, I'll put together some simple documentation on what the rpc calls look like
**\<moneromooo>** And ty and good night :)
**\<tewinget>** my python script is a bit broken, but I updated one of the functions to work
**\<tewinget>** (because I changed it to be JSON-RPC 2.0 compliant)
**\<tewinget>** I'll pastebin that and paste a link here in a sec
**\<tewinget>** hard_fork_info() is the one that uses the jsonrpc format, others can be easily modified to comply
**\<tewinget>** err...that more or less sums things up, I think. any qvestions?
**\<tewinget>** https://paste.fedoraproject.org/490609/57957148/
**\<tewinget>** need python's zmq libs, of course, and zmq version 4ish should suffice as far as OS libs for building
**\<tewinget>** I'll stay up a few more minutes in case anyone has any questions, but I do need to go and sleep.
**\<ferretinjapan>** yo
**\<fluffypony>** welcome, welcome
**\<fluffypony>** ok so
**\<fluffypony>** since we last met
**\<Jaquee>** hi
**\<fluffypony>** there have been quite a few merge sessions
**\<fluffypony>** or merge sesh's as I like to call them
**\<fluffypony>** 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
**\<Jaquee>** lol
**\<fluffypony>** there have been some major reworks to the threading model, courtesy of vtnerd
**\<fluffypony>** who also split part of monero-wallet-cli off into monero-wallet-rpc
**\<fluffypony>** (which we had previously done on the old dev branch, as you may recall)
**\<fluffypony>** gingeropolous started pushing more code than a troll dev should, so he's kinda progressed beyond that
**\<fluffypony>** moneromooo shot down bug after bug
**\<fluffypony>** kenshi84 started working on one-time addresses without using the integrated address format we currently have
**\<fluffypony>** @NanoAkron also fixed some errant armv8 things
**\<fluffypony>** and then on the Monero Core side tons of fixes, small and large, primarily by moneromooo and Jaquee
**\<fluffypony>** abrkn also had their first PR merged to Monero Core, so welcome to a new contributor
**\<fluffypony>** xmr-eric also had a pair of PRs, so he's almost at 5 PRs which is excellent
**\<fluffypony>** as it stands right now there is a weird segfault occurring occasionally, at least on macOS
**\<fluffypony>** and possibly other operating systems
**\<fluffypony>** this is a blocker to the next tagged release
**\<ferretinjapan>** ubuntu as well^
**\<fluffypony>** also running LMDB in "fast" mode may be unsuitable for Windows - hyc, what are your thoughts on that?
**\<asok>** debian also ^
**\<hyc>** still gathering data
**\<hyc>** asked that user what happened oin his prior run, whether PC crashed etc
**\<fluffypony>** ok - so that's a possible blocker to the tagged release
**\<fluffypony>** and then in new, relevant info, Shen has begun a thorough review of the RingCT implementation
**\<fluffypony>** and already there are a couple of nigglies, some carried across from his rough implementation
**\<fluffypony>** so this means we will have to have a mandatory tagged release out before the Jan hard fork
**\<moneromooo>** yay!
**\<fluffypony>** given that there are 2-3 blockers to the tagged release, and given its nature, we will likely release it alongside the GUI
**\<fluffypony>** so that we get a fair degree of pre-fork adoption
**\<ArticMine>** That makes a lot of sense
**\<fluffypony>** in the meantime
**\<fluffypony>** pigeons is setting up links to built binaries on the buildbot infrastructure
**\<fluffypony>** and I'll set forwarders up or something for those
**\<fluffypony>** so that people will be able to grab nightlies of both Monero and Monero Core
**\<fluffypony>** this is not a small amount of work, but it should make it a LOT easier for non-developers to test
**\<fluffypony>** and we need ongoing functional testing, over and above test suite regressions
**\<fluffypony>** speaking of which; the next step on that is to run and publish performance test data on a per-PR basis
**\<fluffypony>** so we can spot performance improvements / regressions
**\<fluffypony>** last thing that I want to open the floor to
**\<fluffypony>** is issue 1271
**\<fluffypony>** https://github.com/monero-project/monero/issues/1271
**\<fluffypony>** opened by paragonie-scott
**\<fluffypony>** currently we hit /dev/urandom for a random seed, basically
**\<fluffypony>** and then use the Keccak sponge function for random numbers thereafter
**\<fluffypony>** a userland PRNG is not ideal, but this doesn't really represent an attack surface that an attacker can take advantage of right now
**\<fluffypony>** to alleviate this we need to pick a crypto lib, and slowly start using it in various parts of the application
**\<fluffypony>** refactoring out the in-source implementations we currently have for most things
**\<fluffypony>** the only two really worth considering are CryptoC++ and libsodium
**\<fluffypony>** if anonimal is around, maybe he can tell us why Kovri settled on cryptocpp
**\<i2p-relay> {-olark}** What about TweetNaCl?
**\<fluffypony>** oh yes
**\<fluffypony>** so
**\<fluffypony>** TweetNaCl is great for the core crypto bits where the most important thing is getting it verifiably right
**\<fluffypony>** TweetNaCl's simplicity lends itself towards formal verification
**\<fluffypony>** a larger library like libsodium or cryptocpp will NEVER be formally verified
**\<hyc>** I'm not convinced of the original argument. userland PRNGs are not a liability
**\<hyc>** and haveged itself was recently recommended on crypto list http://www.metzdowd.com/pipermail/cryptography/2016-November/030930.html
**\<fluffypony>** hyc: I agree, but there's also nothing wrong with just hitting /dev/urandom each time
**\<i2p-relay> {-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.
**\<fluffypony>** haveged would still be of benefit there as it affects the chain from /dev/random -> /dev/urandom
**\<moneromooo>** There's a tendency for security researchers to hype every small thing too, fwiw.
**\<hyc>** hitting /dev/urandom every time leaves an obvious footprint. I suppose it's more of an issue for closed-source s/w
**\<fluffypony>** hyc: yeah - for Monero a root user would be able to trivially trap for any obfuscation we add
**\<hyc>** IME, reverse engineering closed source, it's harder to break a PRNG n a binary with no symbols and no syscalls
**\<hyc>** but yeah, not relevant for open source
**\<ArticMine>** Yes but we are not implementing DRM here
**\<i2p-relay> {-anonimal}** * was responding to fluffypony's ping for kovri, what wasn't an endorsement or argument for/against anything for monero
**\<i2p-relay> {-anonimal}** s/what/that/
**\<fluffypony>** anonimal: sure, but it's advantageous if Kovri and Monero use the same lib
**\<hyc>** less code to maintain, yeah
**\<hyc>** bigger impact if a flaw is found
**\<fluffypony>** (for functions TweetNaCl doesn't have, or where performance greater than TweetNaCl's is required)
**\<fluffypony>** sure, but we're not protecting ourselves by using libsodium vs. cryptocpp
**\<fluffypony>** unless we know in advance that one will have an implementation flawthat the other won't
**\<endogenic>** is a C++ dep an issue going into the future with talk of porting to pure C?
**\<i2p-relay> {-anonimal}** Can someone give a tl;dr of all crypto schemes required by monero (aside from ed25519, keccak, and any PRNG concern)?
**\<fluffypony>** blake256, chacha8, groestl, skein, jh, keccak
**\<hyc>** cryptonight uses keccak, groestl,
**\<hyc>** yeah what fluffy said
**\<fluffypony>** lol
**\<moneromooo>** There's all the stuff in crypto-ops.c
**\<fluffypony>** moneromooo: that's covered by TweetNaCl
**\<fluffypony>** ie. covered by SUPERCOP
**\<hyc>** I presume we're gonna support TLS on rpc connections too?
**\<moneromooo>** Do you mean that it'd be still used if we were to change to cryptocpp ?
**\<fluffypony>** hyc: kinda - vtnerd is working on it atm
**\<fluffypony>** we're going to have easy instructions on TLS wrappers, and then authentication on the RPC layer
**\<fluffypony>** moneromooo: yes
**\<moneromooo>** Why change, then ?
**\<moneromooo>** If it's only part change, I mean.
**\<fluffypony>** \<vtnerd> 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
**\<fluffypony>** \<vtnerd> 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
**\<i2p-relay> {-anonimal}** I used that argument for kovri last year, it was quickly shot down by str4d and zzz.
**\<vtnerd>** https://github.com/varnish/hitch
**\<fluffypony>** moneromooo: to get away from the in-source implementations that are mostly obscure or not massively common
**\<vtnerd>** i2p-relay: do you recall the arguments against doing it that way?
**\<i2p-relay> {-anonimal}** Expecting users to use a guide or 3rd party is probably not a good idea.
**\<i2p-relay> {-anonimal}** vtnerd: there may be a log pasted in a closed github issue
**\<hyc>** I would just use stunnel, it's already proven and pretty simple
**\<i2p-relay> {-anonimal}** Basically what I just said.
**\<moneromooo>** It's a lot easier to do the wrong thing thogh.
**\<fluffypony>** 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
**\<moneromooo>** The same users that asked a question that I had answers with a red message when bitmonerod stopped, but they had somehow missed ? :)
**\<i2p-relay> {-anonimal}** openssl is a dependency for kovri anyway, implementing tls/ssl sockets is trivial. Are we talking more about than sockets though?
**\<vtnerd>** if SSL support is integrated public keys still have to be generated, stored, and then copied remotely ... so its still frustrating
**\<fluffypony>** moneromooo: what if it won't start when bound to an external IP, unless you pass a flag to override it?
**\<hyc>** that's life. we can write a certificate generator/mini-CA
**\<moneromooo>** Maybe. I don't know near enough about this to have a useful opinion anyway.
**\<hyc>** I already have one I wrote for OpenLDAP back in 2000 (mini-CA)
**\<vtnerd>** CA key still has to be distributed ...
**\<moneromooo>** CA key ?
**\<hyc>** CA cert, not key
**\<i2p-relay> {-anonimal}** Certs for whom?
**\<vtnerd>** its still just a public key
**\<i2p-relay> {-anonimal}** Is there an open issue for this with discussion so I catch up?
**\<pigeons>** 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
**\<hyc>** 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.
**\<pigeons>** but for monero, there is already remote daemon support so perhaps not relevant
**\<i2p-relay> {-anonimal}** Oh, personal nodes, ok thanks hyc.
**\<hyc>** and you use full cert verification in both directions, to prevent any foreign apps from connecting.
**\<fluffypony>** hmmmm
**\<vtnerd>** which can be done with SSH easily too
**\<i2p-relay> {-anonimal}** Not everyone has access to ssh nor know how to use ssh.
**\<hyc>** yeah, if you're going to keep a long running ssh tunnel alive
**\<vtnerd>** I haven't seen an easy way to "auto-configure" because the clients still need to know server pub key
**\<hyc>** node and client need a copy of the CA cert
**\<vtnerd>** I guess blindly accepting the cert is better ?
**\<fluffypony>** with TLS clients can just approve a fingerprint
**\<fluffypony>** then it's a visual comparison to a self-signed cert's fingerprint
**\<pigeons>** tofu seems acceptable to people, despite its weaknesses
**\<hyc>** ugh.
**\<pigeons>** i know
**\<hyc>** if you're going to document best practice for TLS, don't document shortcuts. that's garbage.
**\<fluffypony>** we're bikeshedding - we need to put a peg in the sand and make a decision, even if it's the wrong decision
**\<fluffypony>** I'm in favour of not building things and ripping them out later
**\<fluffypony>** but rather not having them until there is an overwhelming demand for it
**\<moneromooo>** erf
**\<hyc>** yeah, fine. no built-in TLS support for now
**\<moneromooo>** I'd be fine with that plus the --force-plaintext-bind-to-non-local-ip
**\<fluffypony>** 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
**\<vtnerd>** I already have a patch ready that forces a user to confirm if the rpc-bind-ip is not loopback
**\<fluffypony>** hyes
**\<fluffypony>** vtnerd: can we make it fail-unless-overridden-by-flag?
**\<fluffypony>** we're trying to avoid interaction on the daemon
**\<vtnerd>** the patch has both. Without the flag set it prompts the user
**\<vtnerd>** --confirm-external-bind
**\<moneromooo>** Maybe test if stdin is tty, fail if not.
**\<moneromooo>** Oh, wait, windows. Nevermind.
**\<hyc>** sounds like just fail without the flag is simpler
**\<vtnerd>** definitely. will do then
**\<vtnerd>** that is_yes patch is less useful now, but I guess it did cleanup simpler_wallet.cpp some
**\<moneromooo>** Next thing. Did shen give an idea when he might have a first pass of things that need fixing ?
**\<moneromooo>** I have time to fix, and we're pressed for time :D
**\<fluffypony>** othe: ^^
**\<fluffypony>** ok
**\<fluffypony>** we wait for othe
**\<moneromooo>** Later, then.
**\<fluffypony>** in the meantime - anyone want to bring up anything else?
**\<fluffypony>** oh - also, if anyone has any strong opinions on the crypto lib we should be using, now is a good time to mention them
**\<fluffypony>** my inclination is to cryptocpp for a few reasons
**\<fluffypony>** https://en.wikipedia.org/wiki/Comparison_of_cryptography_libraries is a good starting point if anyone wants to compare it to the others
**\<pero>** i had some discussion points wrt to the gooey if no one else has anything
**\<fluffypony>** pero: go ahead
**\<pero>** i think the navigation menu might need a 2nd level
**\<fluffypony>** medusa_ / dEBRUYNE ^^
**\<fluffypony>** slash Jaquee
**\<pero>** perhaps an advanced or something to that effect to house verify payment and sign/verify
**\<pero>** those are features that are not going to be very often
**\<pero>** especially sign/verify
**\<pero>** sign/verify needs to be renamed to 'Signatures' i think
**\<pero>** it's kind of confusing with 'verify payment'
**\<pero>** but i think if they were thrown into an Advanced top-level tab then there would be less possible confusion for most users
**\<pero>** the other thing- what's up with that qt title bar?
**\<pero>** isnt that best left for the OS to handle
**\<moneromooo>** IIRC, people slightly preferred keeping it.
**\<pero>** i dont think 'preferring' makes it the right decision
**\<hyc>** oh, as a point of curiosity - monerod runs quite happily on a phone even on 2G. using --out-peers 2.
**\<hyc>** hardly any bandwidth used.
**\<pero>** i have 2 titlebars in gnome
**\<pero>** is that the case for all OSs?
**\<iDunk>** no
**\<fluffypony>** no
**\<pero>** doesnt apple have it's buttons on the left side?
**\<moneromooo>** I have two too. But then I have a special setup.
**\<fluffypony>** then it's a bug
**\<fluffypony>** moneromooo: you *are* special
**\<fluffypony>** :-P
**\<fluffypony>** 2 minutes and then I bring up meeting bot, so let's wrap this up
**\<Jaquee>** i agree on using the os default
**\* fluffypony** hates the OS default
**\<pero>** we're also going against OS-specific consistent user experience
**\<moneromooo>** ... wat...
**\<Jaquee>** and that we need to work on the ux.
**\<pero>** against their design standards
**\<Jaquee>** yes
**\<i2p-relay> {-olark}** re: crypto libraries, imo, use TweetNaCl for what you can. Cryptopp for everything else.
**\<hyc>** agree with pero - app should leave widgets to user's window manager
**\<fluffypony>** olark: agreed
**\<hyc>** title bar included
**\<fluffypony>** we don't want it looking like it's from 1995 tho :-P
**\<hyc>** we don't want it looking different from everything else on their desktop
**\<fluffypony>** I'd prefer that the Monero Core app is consistent across platforms
**\<hyc>** it was a pretty jarring experience for me running it on windows
**\<pero>** well it's just a titlebar
**\<fluffypony>** ok let's discuss it later, meeting bot coming online
**\<Jaquee>** ok
**\<pero>** it's not going to consistent - some platforms might have it maximized
**\<pero>** like on mobile

88
_posts/2016-12-14-monero-0.10.1-released.md Normal file
View File

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

89
_posts/2016-12-22-monero-core-gui-beta-released.md Normal file
View File

@ -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` or `2nodez.moneroworld.com:18081`. 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 (`<walletname>`) 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

6
_strings_en.yml
View File

@ -13,6 +13,7 @@ global:
terms: Terms
privacy: Privacy
copyright: Copyright
edit: Edit This Page
menu:
forum: Forum
blog: Blog
@ -27,6 +28,7 @@ menu:
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
merchants: Merchants and Services Directory
accepting: Accepting Monero Payments
@ -39,6 +41,10 @@ menu:
lab: Monero Research Lab
alternative: Alternative Clients
projects: External Projects
stackexchange: StackExchange Q&A
slack: Slack Chat
rocketchat: Rocket Chat
telegram: Telegram Chat
irc: IRC on Freenode
irc-general: "#monero (General)"
irc-development: "#monero-dev (Development)"

4
blog/index.html
View File

@ -33,9 +33,9 @@ title: All Blog Posts
{% if page == paginator.page %}
<em>{{ page }}</em>
{% elsif page == 1 %}
<a href="{{ '/index.html' | prepend: site.baseurl | replace: '//', '/' }}">{{ page }}</a>
<a href="{{ '/blog' | prepend: site.baseurl | replace: '//', '/' }}">{{ page }}</a>
{% else %}
<a href="{{ site.paginate_path | prepend: site.baseurl | replace: '//', '/' | replace: ':num', page }}">{{ page }}</a>
<a href="{{ site.paginate_path | prepend: '/' | replace: '//', '/' | replace: ':num', page }}">{{ page }}</a>
{% endif %}
{% endfor %}

3
blog/tags/releases.md Normal file
View File

@ -0,0 +1,3 @@
---
layout: blog_by_tag
---

36
downloads/hashes.txt
View File

@ -1,25 +1,33 @@
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hash: SHA256
This GPG-signed message exists to confirm the SHA sums on Monero binaries.
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).
monero.win.x64.v0-9-1-0.zip: 303840d7fb997b2f1efc280fd19ba84003ecff85
monero.mac.x64.v0-9-1-0.tar.bz2: d6c776878fd3d47f149fc9be4e76cf2d03d5a725
monero.linux.x64.v0-9-1-0.tar.bz2: 4149de91c10b56ff091070acca80d233fbd5a797
monero.freebsd.x64.v0-8-6-6.tar.bz: 9fd0005b697e146a26a0bf9e3cd0c89b978f7fbd
727a53dd154b61fd653f81da27788077fdf519301c81d3c1eb033c1ff2bf97c6 monero.win.x64.v0-10-1-0.zip
ce77137b33bcaeb59273cb73b86e426e35e6209fb52a7e74fd9432a5a3018041 monero.win.x86.v0-10-1-0.zip
447cebae257864b3706a8622f495bfd9fae780a6b277e1e31ac83bef7bc855c6 monero.mac.x64.v0-10-1-0.tar.bz2
bf09eea27c957e7e2bdd62dac250888b301d4d25abe18d4a5b930fa7477708c7 monero.linux.x64.v0-10-1-0.tar.bz2
9a18d274970df85d6bc926dc99407959c680c36f19017996be9c758f6c02cf06 monero.linux.x86.v0-10-1-0.tar.bz2
57221605997a3cd815f2a9689486abbdb124263fff047ca61068900eb7cb1839 monero.linux.arm7.v0-10-1-0.tar.bz2
3858d4786b65a37e981b142e9c0f256ac66662314794d05f595c4c30cb5b6ddb monero.freebsd.x64.v0-10-1-0.tar.bz2
cb8bdf36fb56739a0fa746bec8dd51fb3479d51a3b8f0ce41a771f1d5a924bdb monero.gui.win.x64.beta.zip
907bfb4832c74de6cec7df730dfce5d9ccc1e6de09b6a4546cb9eee1f8242968 monero.gui.mac.x64.beta.tar.bz2
cecbe4b23f777442de861bc0981af0857dab043ed63be98f768cdd00825a8d09 monero.gui.linux.x64.beta.tar.bz2
daabd11b271685cedf5d6321cbde5e6b7c2691630a4355a973fc0cb99b1d2dc9 monero.gui.linux.x86.beta.tar.bz2
Riccardo "fluffypony" Spagni
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Version: GnuPG v2
iQEcBAEBAgAGBQJWmTisAAoJEFVDLfMczU/NDQMIAKKYY2/NI5LH4COMIAXRf02x
TTa+veq8job7jnyVI3C+kl2Wtws026CsUHy1TQNrU5krGs5FA77RFrozIIn4Ca7e
su3u0K14hdO8d+bfiPf3n3eh+CTa5/ihbKVf8BannwjI9tyYzjrLSl49rfftdaRP
vpCVyqbApkNzntiIyG/SypGEW9G1b9rQU4RGE0GK836zf4Pu2jz3ZD6Clbc+gGri
/PmLSYBulkcbQ/7TW8Sl0sn+Lj1WF9duVqS/sZiXdws2sT++Lj4LzmNMGDE4SMLe
eYWEu6FrgpmRzLAhqa3pWAOC12bmrINvU8W2/oAXMIPUdyTb3IDJtWhm2KGqJEo=
=3WkU
iQEcBAEBCAAGBQJYW/HGAAoJEFVDLfMczU/NmDMH/RXq15dj0FF0HEvbVrwVIkW3
z5RFkbEiYdOJAj1SjrWlx5v055QBCjI6PLQM/VICC79NPvOhvinoDpM5YAMU1PTB
jC8Oi68VYxG4B8RERzxGwkNkvVu9nlBAEqEChw/YSi0NvCUuFkY05mrtPQbM+RcB
ShtUjNBW+7f5BOEXfjreR5vm6vXT9fGQBzHLgCcv93qLUytZnx0GDPCDBDq87wxa
PhjMIrBygf55tmstiolZdkO2Xn2Nd50tzi0YElxGH26CXRkuc/L3zIz871mHff3q
qj2KnCuIsnQWB7sJ2uxP/bDVncdoKslnc6RDz4azaZSjSEKsballubXG0gOghPA=
=H+gA
-----END PGP SIGNATURE-----

8
downloads/index.md
View File

@ -11,11 +11,11 @@ attribution: "<!-- Icon is based on work by Freepik (http://www.freepik.com) and
### Monero Core
Monero Core consists of several applications, including bitmonerod (the daemon used if running a @full-node, as it maintains the connection to the Monero network) and simplewallet (a Monero @account manager application), as well as several other helper applications.
Monero Core consists of several applications, including monerod (the daemon used if running a @full-node, as it maintains the connection to the Monero network) and monero-wallet-cli (a Monero @account manager application), as well as several other helper applications.
If you are using Monero Core for the first time you can simply download an appropriate release, and run bitmonerod to get synced up to the network.
If you are using Monero Core for the first time you can simply download an appropriate release, and run monerod to get synced up to the network.
Note: the SHA 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).
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).
<div class="row">
@ -73,6 +73,6 @@ Note: the SHA hashes are listed by the downloads for convenience, but a GPG-sign
### Other Downloads
- If you'd prefer to use a blockchain bootstrap, instead of syncing up from scratch, you can [use this link for the most current bootstrap](https:////downloads.getmonero.org/blockchain.raw).
- If you'd prefer to use a blockchain bootstrap, instead of syncing up 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.
- For Monero Research Lab publications please visit the [Monero Research Lab section](/research-lab) of this site.
- High resolution and vector copies of the Monero logo [can be downloaded at this link](https://downloads.getmonero.org/resources/branding.zip).

6
getting-started/accepting.md
View File

@ -17,9 +17,9 @@ However, because Monero has @stealth-addresses there is no need to have separate
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: <span class="long-term">666c75666679706f6e7920697320746865206265737420706f6e792065766572</span>
### Checking for a Payment in simplewallet
### Checking for a Payment in monero-wallet-cli
If you want to check for a payment using simplewallet you can use the "payments" command followed by the payment ID or payment IDs you want to check. For example:
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:
{:.cli-code}
<span style="color: yellow;">[wallet 49VNLa]:</span> payments 666c75666679706f6e7920697320746865206265737420706f6e792065766572
@ -33,7 +33,7 @@ If you need to check for payments programmatically, then details follow the next
<i class="fa fa-level-up fa-rotate-90 fa-lg instruction-list"></i> Generate a random 64 character hexadecimal string for the payment
<i class="fa fa-level-up fa-rotate-90 fa-lg instruction-list"></i> Communicate the payment ID and Monero address to the individual who is making payment
<i class="fa fa-level-up fa-rotate-90 fa-lg instruction-list"></i> Check for the payment using the "payments" command in simplewallet
<i class="fa fa-level-up fa-rotate-90 fa-lg instruction-list"></i> Check for the payment using the "payments" command in monero-wallet-cli
### Checking for a Payment Programatically

23
getting-started/choose.md
View File

@ -43,28 +43,9 @@ There are also several third-party clients that interact with the official Moner
---
{:.text-center .client-list #monerox}
![](//static.getmonero.org/images/clients/monerox.svg)
MoneroX is a GUI for Monero written in .NET and available for Windows, Mac, and Linux. It is written and maintained by Jojatekok.
{:.text-center .client-list}
**Current Version:** 1.0.0
{:.text-center .client-platforms}
- [![](//static.getmonero.org/images/platforms/windows.svg)
Windows](https://github.com/Jojatekok/MoneroGui.Net/releases/download/v1.0.0/MoneroGui.Net-v1.0.0-Windows-x64.zip)
- [![](//static.getmonero.org/images/platforms/linux.svg)
Linux](https://github.com/Jojatekok/MoneroGui.Net/releases/download/v1.0.0/MoneroGui.Net-v1.0.0-Linux-x64.tar.gz)
- [![](//static.getmonero.org/images/platforms/github.svg)
Source Code](https://github.com/Jojatekok/MoneroGui.Net)
- [![](//static.getmonero.org/images/platforms/forum.svg)
Forum Thread](https://bitcointalk.org/index.php?topic=683365.00)
---
{:.text-center .client-list #lightwallet}
[![](//static.getmonero.org/images/clients/lightwallet.svg)](https://forum.getmonero.org/20/general-discussion/166/lightwallet-a-lightweight-monero-gui-account-manager)
lightWallet is a simple and slim client written in Python, and should run on most operating systems. It is written and maintained by jwinterm.
lightWallet is a simple and slim client written in Java, and should run on most operating systems. It is written and maintained by jwinterm.
{:.text-center .client-list}
**Current Version:** 0.2
@ -72,6 +53,8 @@ lightWallet is a simple and slim client written in Python, and should run on mos
{:.text-center .client-platforms}
- [![](//static.getmonero.org/images/platforms/windows.svg)
Windows](https://github.com/jwinterm/LightWallet2/releases/download/v0.2/LightWallet.exe)
- [![](//static.getmonero.org/images/platforms/java.svg)
Java (All Platforms)](https://github.com/jwinterm/LightWallet2/releases/download/v0.2/LightWallet.jar)
- [![](//static.getmonero.org/images/platforms/github.svg)
Source Code](https://github.com/jwinterm/LightWallet2)
- [![](//static.getmonero.org/images/platforms/forum.svg)

37
getting-started/contribute.md Normal file
View File

@ -0,0 +1,37 @@
---
layout: static_page
title: "Contributing To Monero"
title-pre-kick: "Contributing "
title-kick: "to "
title-post-kick: "Monero"
kick-class: "kicks"
icon: "icon_people"
attribution: "<!-- Icon is based on work by Freepik (http://www.freepik.com) and is licensed under Creative Commons BY 3.0 -->"
---
### Contributing to The Monero Project
There are lots of ways for newcomers to contribute to The Monero Project.
### Documenting
Asking questions and helping on [Stack Exchange](http://monero.stackexchange.com) and [Reddit](https://www.reddit.com/r/Monero/) is actually quite useful. Working on and improving the [Moneropedia](/knowledge-base/moneropedia/) is important as well.
### Testing / bug reports
Know how to compile some code? Then it helps for others if you test out builds or run software on various version to catch any errors that slip through. Report bugs and security issues.
### Code
If you have an IT or CS background and can code, go to [#monero-dev](irc://chat.freenode.net/#monero-dev) on freenode and ask around to see if anything needs doing. You can also simply go to the [Monero Project on GitHub](https://github.com/monero-project) and see what issues need help.
### Run a node
Secure the network and help keep Monero decentralized, it's simple to do, and only requires some bandwidth. Learn [how to set up a monero node here.](/getting-started/running) You can also run a node on a VPS, [guide on how to do that is here.](/knowledge-base/user-guides/vps_run_node)
### Mine
It is still possible to mine, even on a cpu. If you have some spare hardware, you are actively adding to it's decentralisation. Find more information on mining Monero in [this thread on Bitcointalk.](https://bitcointalk.org/index.php?topic=653467)
### Spread the word
The size of the Monero community is very very small in the grand scheme of things. Even beyond that, bitcoin itself is still a very niche thing in the wider world. Talk to the friends you know who might be interested in this kind of thing and get more people involved.
Sharings news about Monero on social media is useful as well. You can find Monero on [Facebook](https://www.facebook.com/monerocurrency), [Twitter](https://twitter.com/monerocurrency) and [Reddit.](https://www.reddit.com/r/Monero/)
### Donations
Ongoing development of the Monero Project is solely supported by [donations and sponsors.](/getting-started/donate/) At this time the project is vastly underfunded, and thus donations are greatly appreciated. You can also donate for bounties in the forum funding section, or if theres a feature you're passionate about, you could get it posted.

2
getting-started/donate/index.md
View File

@ -32,7 +32,7 @@ Sponsorships are also greatly appreciated, including those companies that give u
Current sponsors include several mining pools that contribute a portion of their fees to development. You can find a list of these pools in [the first post on the Monero thread on Bitcointalk](https://bitcointalk.org/index.php?topic=583449.0). Over and above that, our sponsors include:
{:.text-center style="letter-spacing: 30px;"}
[![MyMonero](//static.getmonero.org/images/sponsors/mymonero.png)](https://mymonero.com) [![Kitware](//static.getmonero.org/images/sponsors/kitware.png?1)](http://kitware.com) [![Dome9](//static.getmonero.org/images/sponsors/dome9.png)](http://dome9.com) [![Araxis](//static.getmonero.org/images/sponsors/araxis.png)](http://araxis.com) [![JetBrains](//static.getmonero.org/images/sponsors/jetbrains.png)](http://www.jetbrains.com/) [![Navicat](//static.getmonero.org/images/sponsors/navicat.png)](http://www.navicat.com/)
[![MyMonero](//static.getmonero.org/images/sponsors/mymonero.png)](https://mymonero.com) [![Kitware](//static.getmonero.org/images/sponsors/kitware.png?1)](http://kitware.com) [![Dome9](//static.getmonero.org/images/sponsors/dome9.png)](http://dome9.com) [![Araxis](//static.getmonero.org/images/sponsors/araxis.png)](http://araxis.com) [![JetBrains](//static.getmonero.org/images/sponsors/jetbrains.png)](http://www.jetbrains.com/) [![Navicat](//static.getmonero.org/images/sponsors/navicat.png)](http://www.navicat.com/) [![Symas](//static.getmonero.org/images/sponsors/symas.png)](http://www.symas.com/)
### The Monero Community Hall of Fame

8
getting-started/index.md
View File

@ -19,6 +19,12 @@ attribution: "<!-- Icon is based on work by Freepik (http://www.freepik.com) and
<div class="text-center" style="padding-bottom: 15px;"><a style="color: #505050;" href="/getting-started/running"><img src="//static.getmonero.org/images/icon_node.svg" class="title-icon"><h2 class="inline">How to Run a <span class="yellow-kicks">Monero Node</span></h2></a></div>
<div class="text-center" style="padding-bottom: 15px;"><a style="color: #505050;" href="/getting-started/contribute"><img src="//static.getmonero.org/images/icon_people.svg" class="title-icon"><h2 class="inline">Contributing to <span class="yellow-kicks">Monero</span></h2></a></div>
---
<div class="text-center" style="padding-bottom: 15px;"><a style="color: #505050;" href="/knowledge-base/user-guides"><img src="//static.getmonero.org/images/icon_client.svg" class="title-icon"><h2 class="inline">How do I...</h2></a></div>
<div class="text-center" style="padding-bottom: 15px;"><a style="color: #505050;" href="/getting-started/donate"><img src="//static.getmonero.org/images/icon_donations.svg" class="title-icon"><h2 class="inline">Donating and <span class="kicks">Sponsorships</span></h2></a></div>
@ -33,4 +39,4 @@ attribution: "<!-- Icon is based on work by Freepik (http://www.freepik.com) and
<div class="text-center" style="padding-bottom: 15px;"><a style="color: #505050;" href="/getting-started/merchants"><img src="//static.getmonero.org/images/icon_merchants.svg" class="title-icon"><h2 class="inline">Monero <span class="purple-kicks">Merchants and Services</span> Directory</h2></a></div>
---
---

10
getting-started/running.md
View File

@ -21,13 +21,13 @@ Monero will run on most hardware, including ARM and 32-bit systems. In order to
### Running the Node
Once you have the files downloaded and unpacked you don't need to do anything beyond running the Monero daemon.
Once you have the files downloaded and unpacked you don't need to do anything beyond running the Monero daemon (monerod).
- On Windows: locate bitmonerod.exe in Windows Explorer and double-click on it. If it opens and then closes, or crashes after starting, then you may want to start it from within Command Prompt in order to see what errors arise.
- On Windows: locate monerod.exe in Windows Explorer and double-click on it. If it opens and then closes, or crashes after starting, then you may want to start it from within Command Prompt in order to see what errors arise.
- On OS X: locate bitmonerod in Finder and double-click on it. As with Windows, if it opens and then closes, or crashes after starting, then you can start it from within Terminal.
- On OS X: locate monerod in Finder and double-click on it. As with Windows, if it opens and then closes, or crashes after starting, then you can start it from within Terminal.
- On Linux: dependent on whether you are running it on a desktop or server operating system, you will want to start bitmonerod either in a screen session or in a console window of its own.
- On Linux: dependent on whether you are running it on a desktop or server operating system, you will want to start monerod either in a screen session or in a console window of its own.
### Ensuring Your Node is Running Correctly
@ -49,4 +49,4 @@ SYNCHRONIZATION started</span>
The yellow text indicates it is receiving blocks as it synchronises up with the rest of the Monero network. The green "synchronized ok" text will appear once it has correctly synched up. Once you see this there's nothing further you need to do, you are now running a Monero node!
To exit the node at any time you can type "exit" into the daemon window and press enter, and it will shut itself down.
To exit the node at any time you can type "exit" into the daemon window and press enter, and it will shut itself down.

2
home.php
View File

@ -58,7 +58,7 @@ Title: Home
<h2 class="inline">
{% t index.how_do_i_1 %}<br><span class="softyellow-kicks">{% t index.get_started %}</span> {% t index.how_do_i_2 %}
</h2>
<p style="margin-top: 40px;">{% t index.get_started_1 %}<a href="https://mymonero.com">{% t index.mymonero %}</a>{% t index.get_started_2 %}</p>
<p style="margin-top: 40px;">{% t index.get_started_1 %} <a href="https://mymonero.com">{% t index.mymonero %}</a>{% t index.get_started_2 %}</p>
<p>{% t index.get_started_3 %}</p>
</div>
<div class="col-md-6">

6
knowledge-base/about.md
View File

@ -8,6 +8,10 @@ kick-class: "kicks"
icon: "icon_about"
attribution: "<!-- Icon is based on work by Freepik (http://www.freepik.com) and is licensed under Creative Commons BY 3.0 -->"
---
<iframe width="560" height="315" src="https://www.youtube.com/embed/TZi9xx6aiuY" frameborder="0" allowfullscreen></iframe>
<!-- Source code for this video can be found at https://github.com/savandra/Monero_Promo_Video/blob/master/README.md -->
## 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.
@ -35,7 +39,7 @@ The underlying technologies and cryptography upon which Monero is built, has bee
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 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.
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 hand of a privileged few. Participants of lesser weight are reduced to second class citizens, with little chance of ever obtaining similar returns.

788
knowledge-base/developer-guides/daemon-rpc.md Normal file
View File

@ -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: "<!-- Icon is based on work by Freepik (http://www.freepik.com) and is licensed under Creative Commons BY 3.0 -->"
---
## 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}
<span style="color: cyan;">[ monero->~ ]$</span> 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}
<span style="color: cyan;">[ monero->~ ]$</span> 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}
<span style="color: cyan;">[ monero->~ ]$</span> 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}
<span style="color: cyan;">[ monero->~ ]$</span> 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}
<span style="color: cyan;">[ monero->~ ]$</span> 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}
<span style="color: cyan;">[ monero->~ ]$</span> 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}
<span style="color: cyan;">[ monero->~ ]$</span> 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}
<span style="color: cyan;">[ monero->~ ]$</span> 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}
<span style="color: cyan;">[ monero->~ ]$</span> 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}
<span style="color: cyan;">[ monero->~ ]$</span> 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}
<span style="color: cyan;">[ monero->~ ]$</span> 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}
<span style="color: cyan;">[ monero->~ ]$</span> 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}
<span style="color: cyan;">[ monero->~ ]$</span> 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}
<span style="color: cyan;">[ monero->~ ]$</span> 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}
<span style="color: cyan;">[ monero->~ ]$</span> 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}
<span style="color: cyan;">[ monero->~ ]$</span> 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}
<span style="color: cyan;">[ monero->~ ]$</span> 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}
<span style="color: cyan;">[ monero->~ ]$</span> 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}
<span style="color: cyan;">[ monero->~ ]$</span> 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}
<span style="color: cyan;">[ monero->~ ]$</span> curl -X POST http://127.0.0.1:18081/stop_daemon -H 'Content-Type: application/json'
{
"status": "OK"
}

3
knowledge-base/developer-guides/index.md
View File

@ -11,4 +11,5 @@ attribution: "<!-- Icon is based on work by Freepik (http://www.freepik.com) and
### Work in Progress
<div class="text-center" style="padding-bottom: 15px;"><a style="color: #505050;" href="wallet-rpc"><img src="//static.getmonero.org/images/icon_client.svg" class="title-icon"><h2 class="inline">How to <span class="green-kicks">Wallet RPC documentation</span></h2></a></div>
<div class="text-center" style="padding-bottom: 15px;"><a style="color: #505050;" href="daemon-rpc"><img src="//static.getmonero.org/images/icon_client.svg" class="title-icon"><h2 class="inline"><span class="green-kicks">Daemon RPC documentation</span></h2></a></div>
<div class="text-center" style="padding-bottom: 15px;"><a style="color: #505050;" href="wallet-rpc"><img src="//static.getmonero.org/images/icon_client.svg" class="title-icon"><h2 class="inline"><span class="green-kicks">Wallet RPC documentation</span></h2></a></div>

605
knowledge-base/developer-guides/wallet-rpc.md
View File

@ -1,7 +1,7 @@
---
layout: static_page
title: "Wallet RPC documentation"
title-pre-kick: "How to "
title-pre-kick: "Developer Guide: "
title-kick: "Wallet RPC documentation "
title-post-kick: ""
kick-class: "green-kicks"
@ -9,156 +9,491 @@ icon: "icon_client"
attribution: "<!-- Icon is based on work by Freepik (http://www.freepik.com) and is licensed under Creative Commons BY 3.0 -->"
---
### This is a list of the daemon and wallet RPC calls, along with their inputs and outputs.
## Introduction
bitmonerod
This is a list of the monero-wallet-cli RPC calls, their inputs and outputs, and examples of each.
TODO
All monero-wallet-cli methods use the same JSON RPC interface. For example:
simplewallet
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'
Wallet RPC commands are in JSON format, and can be accessed like this:
Note: "atomic units" refer to the smallest fraction of 1 XMR according to the monerod implementation. **1 XMR = 1e12 atomic units.**
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'
### Index of JSON RPC Methods:
getbalance
return the wallet's balance
outputs:
balance: unsigned int
unlocked_balance: unsigned int
* [getbalance](#getbalance)
* [getaddress](#getaddress)
* [getheight](#getheight)
* [transfer](#transfer)
* [transfer_split](#transfersplit)
* [sweep_dust](#sweepdust)
* [store](#store)
* [get_payments](#getpayments)
* [get_bulk_payments](#getbulkpayments)
* [incoming_transfers](#incomingtransfers)
* [query_key](#querykey)
* [make_integrated_address](#makeintegratedaddress)
* [split_integrated_address](#splitintegratedaddress)
* [stop_wallet](#stopwallet)
getaddress
return the wallet's address
outputs:
address: string
getheight
returns the current block height
outputs:
height: string
---
transfer
send monero to a number of recipients
inputs:
destinations: array of:
amount: unsigned int
address: string
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
outputs:
tx_hash: array of:
string
## JSON RPC Methods:
transfer_split
same as transfer, but can split into more than one tx if necessary
inputs:
destinations: array of:
amount: unsigned int
address: string
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
new_algorithm: boolean
true to use the new transaction construction algorithm, defaults to false
outputs:
tx_hash: array of:
string
### getbalance
sweep_dust
send all dust outputs back to the wallet's, to make them easier to spend (and mix)
outputs:
tx_hash_list: list of:
string
Return the wallet's balance.
store
save the blockchain
Inputs: *None*.
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
Outputs:
get_bulk_payments
get a list of incoming payments using a given payment id, or a list of payments ids, from a given height
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
* *balance* - unsigned int; The total balance of the current monero-wallet-cli 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.
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
"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:
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)
"view_key": the view key
outputs:
key: string
the view key will be hex encoded
{:.cli-code}
<span style="color: cyan;">[ monero->~ ]$</span> 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
}
}
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
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
### getaddress
stop_wallet
stops the wallet, storing the current state
Return the wallet's address.
Inputs: *None*.
Outputs:
* *address* - string; The 95-character hex address string of the monero-wallet-cli in session.
Example:
{:.cli-code}
<span style="color: cyan;">[ monero->~ ]$</span> 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-cli'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}
<span style="color: cyan;">[ monero->~ ]$</span> 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:
* *tx_hash* - array of: string
* *tx_key* -
Example:
{:.cli-code}
<span style="color: cyan;">[ monero->~ ]$</span> curl -X POST http://127.0.0.1:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"transfer","params":{"destinations":[{"amount":10000000000000,"address":"427ZuEhNJQRXoyJAeEoBaNW56ScQaLXyyQWgxeRL9KgAUhVzkvfiELZV7fCPBuuB2CGuJiWFQjhnhhwiH1FsHYGQGaDsaBA"},{"amount":200000000000,"address":"49VtwYXDbbh7hq57wwkLH36x4D6XV6Tr2P93ANnBi9qFGyYZbx8SXWPUHC9V1o7N41b4c3WJ1kubkffRfPTPfMuB8QUqFD5"}],"fee":150000000000,"mixin":3,"unlock_time":0,"payment_id":"001f181e2a2e076e8451e9dd7b5fe8fbd2b204cd6a20cb3e21b9a2a42b0ce03c","get_tx_key":true}}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
"tx_hash": "&lt;29d933789db5483fa63694ed2560d3829dbf0b945fdea3c42fbfa4d381e7ac22&gt;",
"tx_key": "&lt;c228dff7aa455d770f8cf71b9d319d2055a125cfbac1ca9485aeb1a107604d0d&gt;"
}
}
### 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.
* *new_algorithm* - boolean; True to use the new transaction construction algorithm, defaults to false.
Outputs:
* *tx_hash_list* - array of: string
Example:
{:.cli-code}
<span style="color: cyan;">[ monero->~ ]$</span> curl -X POST http://127.0.0.1:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"transfer_split","params":{"destinations":[{"amount":2000000000000,"address":"427ZuEhNJQRXoyJAeEoBaNW56ScQaLXyyQWgxeRL9KgAUhVzkvfiELZV7fCPBuuB2CGuJiWFQjhnhhwiH1FsHYGQGaDsaBA"},{"amount":3000000000000,"address":"49VtwYXDbbh7hq57wwkLH36x4D6XV6Tr2P93ANnBi9qFGyYZbx8SXWPUHC9V1o7N41b4c3WJ1kubkffRfPTPfMuB8QUqFD5"}],"mixin":3,"unlock_time":0,"payment_id":"a29602cc261fecbc93c22a152a942cc791ca6112cffe201c3e809945c9da672f","get_tx_key":true,"new_algorithm":true}}' -H 'Content-Type: application/json'
{
"id": "0",
"jsonrpc": "2.0",
"result": {
"tx_hash_list": ["&lt;fb39c42cb5ff231ee9e8b381bb8734fd655b6ca28a23cbd82aa9422aa870e91b&gt;"]
}
}
### 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}
<span style="color: cyan;">[ monero->~ ]$</span> 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}
<span style="color: cyan;">[ monero->~ ]$</span> 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}
<span style="color: cyan;">[ monero->~ ]$</span> 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}
<span style="color: cyan;">[ monero->~ ]$</span> 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
}]
}
}
### 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}
<span style="color: cyan;">[ monero->~ ]$</span> 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": "&lt;c391089f5b1b02067acc15294e3629a463412af1f1ed0f354113dd4467e4f6c1&gt;",
"tx_size": 5870
},{
"amount": 300000000000,
"global_index": 794232,
"spent": false,
"tx_hash": "&lt;c391089f5b1b02067acc15294e3629a463412af1f1ed0f354113dd4467e4f6c1&gt;",
"tx_size": 5870
},{
"amount": 50000000000,
"global_index": 213659,
"spent": false,
"tx_hash": "&lt;c391089f5b1b02067acc15294e3629a463412af1f1ed0f354113dd4467e4f6c1&gt;",
"tx_size": 5870
}]
}
}
Example (Return "available" transactions):
{:.cli-code}
<span style="color: cyan;">[ monero->~ ]$</span> 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": "&lt;c391089f5b1b02067acc15294e3629a463412af1f1ed0f354113dd4467e4f6c1&gt;",
"tx_size": 5870
},{
"amount": 300000000000,
"global_index": 794232,
"spent": false,
"tx_hash": "&lt;c391089f5b1b02067acc15294e3629a463412af1f1ed0f354113dd4467e4f6c1&gt;",
"tx_size": 5870
},{
"amount": 50000000000,
"global_index": 213659,
"spent": false,
"tx_hash": "&lt;c391089f5b1b02067acc15294e3629a463412af1f1ed0f354113dd4467e4f6c1&gt;",
"tx_size": 5870
}]
}
}
Example (Return "unavailable" transaction. Note that this particular example returns 0 unavailable transactions):
{:.cli-code}
<span style="color: cyan;">[ monero->~ ]$</span> 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}
<span style="color: cyan;">[ monero->~ ]$</span> 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}
<span style="color: cyan;">[ monero->~ ]$</span> 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}
<span style="color: cyan;">[ monero->~ ]$</span> 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}
<span style="color: cyan;">[ monero->~ ]$</span> 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": "&lt;420fa29b2d9a49f5&gt;",
"standard_address": "427ZuEhNJQRXoyJAeEoBaNW56ScQaLXyyQWgxeRL9KgAUhVzkvfiELZV7fCPBuuB2CGuJiWFQjhnhhwiH1FsHYGQGaDsaBA"
}
}
### stop_wallet
Stops the wallet, storing the current state.
Inputs: *None*.
Outputs: *None*.
Example:
{:.cli-code}
<span style="color: cyan;">[ monero->~ ]$</span> 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": {
}
}

2
knowledge-base/moneropedia/account.md
View File

@ -44,7 +44,7 @@ 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 simplewallet to save
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.<br>
<span style="color: lime;">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.</span><br>

35
knowledge-base/moneropedia/address-book.md Normal file
View File

@ -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)

11
knowledge-base/moneropedia/address.md
View File

@ -7,9 +7,16 @@ summary: "either an alias, such as donate.getmonero.org, or a set of 95 characte
### 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 <span class="long-term">44AFFq5kSiGBoZ4NMDwYtN18obc8AemS33DBLWs3H7otXft3XjrpDtQGv7SqSsaBYBb98uNbr2VBBEt7f2wfn3RVGQBEP3A</span>.
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 <span class="long-term">44AFFq5kSiGBoZ4NMDwYtN18obc8AemS33DBLWs3H7otXft3XjrpDtQGv7SqSsaBYBb98uNbr2VBBEt7f2wfn3RVGQBEP3A</span>.
Because those addresses are long and complex you will often encounter an @OpenAlias address instead. For example, Monero donations can be sent to <span class="long-term">donate@getmonero.org</span> or <span class="long-term">donate.getmonero.org</span>
Because those addresses are long and complex you will often encounter an @OpenAlias address instead. For example, Monero donations can be sent to <span class="long-term">donate@getmonero.org</span> or <span class="long-term">donate.getmonero.org</span>.
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).

27
knowledge-base/moneropedia/base32-address.md Normal file
View File

@ -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`**

20
knowledge-base/moneropedia/base64-address.md Normal file
View File

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

4
knowledge-base/moneropedia/blockchain.md
View File

@ -3,8 +3,10 @@ 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. One of the unique features of Monero, as compared to other cryptocurrencies such as Bitcoin, is that transactions in the Monero blockchain do not reveal who the funds came from or went to. Each individual monero user controls who can see their transactions with a key called the '@view-key'."
{{ page.summary | capitalize }}.
{{ page.summary | capitalize }}.

23
knowledge-base/moneropedia/canonically-unique-host.md Normal file
View File

@ -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)

33
knowledge-base/moneropedia/clearnet.md Normal file
View File

@ -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)

22
knowledge-base/moneropedia/data-directory.md Normal file
View File

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

19
knowledge-base/moneropedia/destination.md Normal file
View File

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

30
knowledge-base/moneropedia/eepsite.md Normal file
View File

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

35
knowledge-base/moneropedia/encryption.md Normal file
View File

@ -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)

15
knowledge-base/moneropedia/floodfill.md Normal file
View File

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

14
knowledge-base/moneropedia/fungibility.md Normal file
View File

@ -0,0 +1,14 @@
---
layout: moneropedia
entry: "Fungibility"
terms: ["fungibility-fungible"]
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. This is also true of gold, where any 1 oz. gold bar is identical to another. Monero is also considered fungible as any 1 XMR is functionally identical to any other 1 XMR.
Fungibility is an advantage that Monero has over Bitcoin, due to the private nature of the Monero @blockchain and the public nature of the Bitcoin blockchain. With Bitcoin, any 1 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. Some users have speculated that this lack of fungibility may mean that certain businesses will be obligated to avoid accepting BTC that have been previously used for illegal purposes, though that has not happened to date.
{{ page.summary | capitalize }}.

25
knowledge-base/moneropedia/garlic-encryption.md Normal file
View File

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

45
knowledge-base/moneropedia/garlic-routing.md Normal file
View File

@ -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)
- For more technical details on Garlic Routing, read the @Java-I2P entry on [Garlic Routing](https://geti2p.net/en/docs/how/garlic-routing)

28
knowledge-base/moneropedia/i2np.md Normal file
View File

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

31
knowledge-base/moneropedia/i2p.md Normal file
View File

@ -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/).

17
knowledge-base/moneropedia/i2pcontrol.md Normal file
View File

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

15
knowledge-base/moneropedia/in-net.md Normal file
View File

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

2
knowledge-base/moneropedia/index.md
View File

@ -17,6 +17,8 @@ attribution: "<!-- Icon is based on work by Freepik (http://www.freepik.com) and
</div>
---
[[Add New Entry]](https://github.com/monero-project/monero-site/new/master/knowledge-base/moneropedia)
---
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.

15
knowledge-base/moneropedia/java-i2p.md Normal file
View File

@ -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/).

33
knowledge-base/moneropedia/jump-service.md Normal file
View File

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

62
knowledge-base/moneropedia/kovri.md Normal file
View File

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

25
knowledge-base/moneropedia/lease-set.md Normal file
View File

@ -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)

15
knowledge-base/moneropedia/lease.md Normal file
View File

@ -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)

22
knowledge-base/moneropedia/locally-unique-host.md Normal file
View File

@ -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)

33
knowledge-base/moneropedia/message.md Normal file
View File

@ -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)

7
knowledge-base/moneropedia/mnemonicseed.md
View File

@ -7,4 +7,9 @@ summary: "a 13 or 25 word phrase used to backup a Monero account, available in a
### The Basics
{{ page.summary | capitalize }}.
{{ 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.

25
knowledge-base/moneropedia/network-database.md Normal file
View File

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

34
knowledge-base/moneropedia/ntcp.md Normal file
View File

@ -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)

14
knowledge-base/moneropedia/paymentid.md
View File

@ -7,11 +7,19 @@ summary: "an optional flag that is added to identify transactions to merchants,
### The Basics
Payment ID is an **arbitrary** and **optional** transaction attachment that consists of 32 bytes (64 hexadecimal characters).
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).
It 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.
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
One can create a Payment ID quickly from the command line using OpenSSL:
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 8 -hex```
Creating an old-style Payment ID:
```# openssl rand 32 -hex```

17
knowledge-base/moneropedia/reseed.md Normal file
View File

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

19
knowledge-base/moneropedia/ringCT.md Normal file
View File

@ -0,0 +1,19 @@
---
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 a way to hide the amount sent in a Monero transaction. This feature is currently in the testnet phase and is a high development priority.
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 }}.

68
knowledge-base/moneropedia/router-info.md Normal file
View File

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

17
knowledge-base/moneropedia/smartmining.md Normal file
View File

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

10
knowledge-base/moneropedia/spendkey.md
View File

@ -2,9 +2,15 @@
layout: moneropedia
entry: "Spend Key"
terms: ["spend-key", "spend-keys"]
summary: "one of two sets of private and public cryptographic keys that each account has, with the private spend key required to spend any funds in the account"
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 }}.
{{ 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.

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