Monero

Dev Diary for the Week of 2014-06-10

Tue, 10 Jun 2014 00:00:00 GMT

RPC: incoming_transfers is now available as a simplewallet RPC API call, and payment_id has been added as an optional argument to the transfer RPC API call. Neozaru also committed a large amount of additional functionality to the RPC API, including progress estimation to getinfo.

I2P: no commits this week, much of the work has been around scoping and planning the RPC subsystem.

Core: new seed nodes have been added, so bootstrapping on cold start should work just fine. We are going to add DNS seed node bootstrapping at a later stage.

Docs: work has begun on adding Doxygen comments throughout the code. This will both help us to understand the code written by "The CryptoNote Developers" (who appear at the top of every piece of source code except for the epee library), but will also result in proper developer documentation being made available.

Mining: Wolf` has continued to improve his CPU miner - the latest copy of which can be found on his github repo.

Mining: Claymore released a CryptoNight GPU miner, which you can find at this thread. Please be advised that his miner is currently closed source, and the appropriate level of caution should be exercised.

Dev Diary for the Week of 2014-06-02

Mon, 02 Jun 2014 00:00:00 GMT

RPC: Neozaru and others have submitted pull requests to add RPC methods that were missing.

I2P: libssu has been decoupled, and outstanding changes to master have been merged.

Core: just a reminder that there are breaking changes to 0.8.8 to prevent a transaction dust attack on the block reward. Because of the block reward penalty, it was previously possible to constantly reduce the block reward down to nearly zero, which is what has been fixed. You can see this quite dramatically on the Block Reward chart on monerochain.info where our average block reward plummeted by around 13% on May 25 - 27 as the fix was tested, deployed, and miners began adopting it. Please don't forget that simplewallet using the older code will not add the correct transaction fees, causing transactions to sit in the mempool for several days before being rejected.

Core: initial work has begun on documenting the code and on providing architecture overviews. This will be a relatively lengthy project, but will provide us with a more useful codebase that has had more eyes on it.

Crypto: we have also begun an initial foray into examining the underlying cryptographic and mathematic principles of the CryptoNote protocol, and ensuring that it has been correctly implemented in the reference code (Bytecoin - upon which Monero is based). We will reveal more details as this project progresses.

Crypto: DGA has done an incredible job of optimising the PoW hashing code, and has vastly improved the speed at which it operates. This makes syncing the blockchain faster, as well as improves the speed at which miners can run and pools can verify work.

Mining: Wolf has worked hard on optimising and tweaking LucasJones miner. If you are mining, it is strongly suggested you give Wolf's fork of cpuminer-multi a spin. Because it takes advantage of AES-NI you may find that reducing the number of threads down to around half of the number of cores in your computer is the most efficient.

Monero Missive for the Week of 2014-06-02

Mon, 02 Jun 2014 00:00:00 GMT

This is the start of a slightly more formal way of keeping everyone updated as to what we're doing in Monero. On an ongoing weekly basis we'll post an update on what has happened over the past week, as well as a dev diary highlighting work done on major efforts. If you'd like to get involved with Monero don't ask for permission - just get stuck in:) Fork the repo, make changes, submit a pull-request, and let's discuss it.

Also an important note on updates: Our policy is to only provide announcements on projects which are either complete or near completion. We'd like to focus on providing you with the most accurate and reliable news, without generating any type of investor hype or speculation. As Monero is still a project in its infancy, and there is a great deal of work still to be done, we want to make sure you are getting an honest overview of our ongoing progress.

Major Updates

The big one...we have a logo! If you use Monero in any of your projects, you can grab a branding pack here. You can also see it in all its glory right here:
{: .center-image }
With our logo completed, we are going to be moving forward on a major overhaul and redesign of our website. We are also in the process of architecting and designing a better repository of information - which includes a forum-style that allows for both discussion, as well an open-source, crowd-funded development incubator. We will be keeping you updated on our progress in the coming weeks. In the meantime, the best place for threaded discussions are the /r/monero subreddit, and for live discussions join us on Freenode: #monero for general chat, #monero-dev for development efforts, and #monero-otc for price talk and over-the-counter trades.
The pool bounty has now closed, and was awarded to zone117x and LucasJones for their excellent work on the Node CryptoNote pool. You can see the results of their hard work on their github repo here or, you know, just use pretty much any of the Monero mining pools:)
In order to maintain ISO 4217 compliance, we are changing our ticker symbol from MRO to XMR effective immediately. This change primarily effects exchanges at this early stage, as we are sure that MRO will continue to be used colloquially and in general discussion. We are aware that this may cause a little confusion, but we feel it necessary to make this change early on rather than later when Monero is more widely spread.

We'd also like to take the time to introduce you to our core team (in no particular order) - tacotime, eizh, smooth, fluffypony, othe, davidlatapie, NoodleDoodle

Many others are involved in peripheral and related projects, including: zone117x, Neozaru, LucasJones, Wolf, Quanttek, and so many others

Thank you for your hard work if you have been involved in Monero already, and we look forward to continuing to innovate as keep Monero the most secure, private, untraceable cryptocurrency!

Dev Diary for the Week of 2014-06-16

Wed, 18 Jun 2014 00:00:00 GMT

Core: Checkpoint added at block 80 000

Core: We've incorporated two changes from BBR - proper tx_pool handling, and a fix for the high number of orphans pool miners were experiencing. tx_pool handling is incomplete, as it is implemented by the daemon but the wallet is not, as yet, mempool aware.

Core: Initial tx auto-split commit, ready for testing

Build: Made changes to CMakeLists to allow for the project to build on Arch

Monero Missive for the Week of 2014-06-10

Tue, 10 Jun 2014 00:00:00 GMT

Hello XMR users! Welcome to our second Monero Missives.

Major Updates

We're happy to introduce a major new feature for Monero: deterministic wallets based on a mnemonic seed! When creating a new wallet you now get a 24 word seed that you can use to restore the wallet:
{: .center-image }
Usage: This affects simplewallet, and is the default behaviour for --generate-new-wallet. If you would like to disable the deterministic seed during wallet generation, you can pass the --non-deterministic flag. To restore from a seed you can use the --restore-deterministic-wallet flag.
This provides a MAJOR benefit in that backing up your wallet no longer requires backing up the .bin.keys file! All you have to do is write down the 24 words and that's the only backup you need. If you're particularly brave you can even memorise the 24 words. You can also use this to create an offline cold wallet or a paper wallet: create a wallet on a computer disconnected from the Internet, write the 24 words and the address and the view key down, and then remove all the files created by the wallet.
Security notes: Please note that this key is independent of your password. By default the 24 word key is written to simplewallet.log when the wallet is created. This is the expected behaviour, the next release will both exclude this from the log and reduce the default log level. Please run --generate-new-wallet with the --set_log 0 flag, or alternatively make sure to delete the simplewallet.log file afterwards.
Technical details: The key length for this remains 256-bits and thus does not compromise user security. The view key seed is generated from a keccak1600 hash of the spend key (which is directly from the mnemonic seed), hence the deterministic nature of this. The non-deterministic method is still available as an option.
How to get it: binaries in the OP have already been updated, or you can compile from the source on github.
Moving to a deterministic wallet: unfortunately it's not possible to retroactively make an existing wallet deterministic. If you want to take advantage of the new feature, you will have to create a new wallet and move your funds in there.
XMR is now on Mintpal for voting. You can find the voting link here: https://www.mintpal.com/voting#XMR - Mintpal allows 1 vote an hour from registered users who have traded before, as well as paid-for votes.
Monero will be officially represented by fluffypony at the Bitcoin Supernode Conference at Malla Castle in Estonia at the end of this month.
Neozaru has made great strides in his RPC-based Qt GUI wallet, and it requires some testing. If you are keen on trying it out, head over to his comment the GUI thread, give it a spin, and give him feedback.

Until next week!

PS. If you've made it this far, there's a reward in the example wallet listed in the screenshot - first to grab it gets the prize!

Dev Diary for the Week of 2014-06-30

Sun, 06 Jul 2014 00:00:00 GMT

Core: daemonizing changes are ready for testing: https://github.com/mikezackles/bitmonero/tree/daemonize

Core: rpcwallet is ready for testing: https://github.com/tewinget/bitmonero/tree/rpcwallet

Monero Missive for the Week of 2014-06-16

Wed, 18 Jun 2014 00:00:00 GMT

Hello, and welcome to our third Monero Missive.

Major Updates

We've been stalling this week's Missive on purpose, because we were hoping it would happen...and it happened! We got to number 1 on the MintPal voting list in a week - which is quite an achievement. There was quite a stack of paid-for votes (more than normal for a cryptocurrency on the MintPal voting list), which is surprising, but it definitely helped catapult us up front.
An interesting graph on CryptVote shows the meteoric climb (XMR is the blue line): {: .center-image }
We are immensely grateful for the work the CryptoNote developers have put into the protocol, but their whitepaper is unfortunately lacking in peer reviews. To that end, we have taken it upon ourselves to peer review the whitepaper, and to release the peer review as an annotated whitepaper.
The two primary peer reviewers are not part of the Monero core team, and are highly qualified academics in the fields of mathematics and cryptography. They are assisted by some of the Monero core team who have a similar computer science academic background. Due to the nature of the Monero project both of the primary peer reviewers have chosen to work under a pseudonym. In a later missive we'll introduce them more formally, but for the moment we wanted to release the current copy of the annotated whitepaper for everyone to take a look at. If you'd like to provide your input on the annotations, please feel free to email any comments to dev@getmonero.org
The latest annotated whitepaper can be downloaded here: http://downloads.getmonero.org/whitepaper_annotated.pdf. Please bear in mind that it is only up to page 8 in the CryptoNote whitepaper at present, so the annotation does cut short there:)
We have completed initial work and testing on transaction auto-splitting (thanks to tewinget's tireless work). Now, if you have too many inputs for your transaction, simplewallet will automatically try to split your transfer up to as many as 30 transactions. It will prompt you first and let you know the total fees before just sending it, of course:
{: .center-image }
This feature requires more testing, and is NOT in the main code base yet. If you're able to build Monero, please grab it from fluffypony's repo here, and build and test: https://github.com/fluffypony/bitmonero - you won't need to build tests or change the daemon, it's just simplewallet's operation that has changed. Please do not try this with the RPC API yet, this needs the CLI at the moment.
We have had a lot of people asking about the progress of the GUI wallet. We'd like to reiterate that there are a great number of core and fundamental things that need to be worked on before we can get lots and lots of users flocking in. Some of the core necessities that we're working on at breakneck pace are: QoS to reduce the bandwidth demand on full nodes (as everyone will be running a full node at this stage anyway), segregation of wallet functions in order to create a far more robust system for exchanges and merchants to use, Gitian-based builds for everyone's safety and to ensure binaries are safe (safer, really), moving blockchain storage to an embedded database, fixing the now-infamous "ABSTRACT_SERVER_SEND_QUE_MAX_COUNT" (in big red letters!) error that is quite harmless but everyone freaks out about, and so on.

These are issues at Monero's core that we're working on, and we need to have these in place and fixed before a GUI wallet is widely dispersed, otherwise there will be massive resource constraints placed on user's systems. We're not here to win a race against other cryptocurrencies. We're here to continue to push out great features and stable and reliable code, in a way that will make sure Monero is around for decades and not just a flash-in-the-pan.

Monero Missive for the Week of 2014-06-30

Sun, 06 Jul 2014 00:00:00 GMT

Hello, and welcome to our fifth Monero Missive!

Major Updates

fluffypony had a great time discussing Monero at the Bitcoin Supernode Conference in Estonia. Many thanks to rpietila for hosting him and all attendees.
Work on the academic peer review of the CryptoNote whitepaper is slowly starting to move away from an academic platform and on to the code itself, to determine whether the reference implementation correctly implements the whitepaper. Before that happens, though, a summary of the initial findings will be published. We are expecting this to be completed this coming week.
Transaction auto-splitting is now in the main codebase. To explain our methodology: the main github repo will always be "active development", and may contain code that will be reverted or is not fully tested. For those that are brave and want to test and contribute to development, it is the ideal starting point. However, on an ongoing basis we are going to create tagged releases, whereby when a group of new features have been fully tested, a new release can be tagged, and binaries can be put out (along with the code on the github tag, of course). Expect this change to start taking effect within the next 4 weeks.
We'd like to apologise for not finalise the GUI bounty - everyone has been a little scattered this week. We will resolve this in its entirety within the next 48 hours!

This Missive is a little light on major updates (well, we can't have something major every week;) primarily because there has been lots of plotting and planning this week. As always: you can keep up to date with the nitty-gritty on IRC in #monero-dev on Freenode if you're interested.

Until next week!

Dev Diary for the Week of 2014-07-07

Sun, 13 Jul 2014 00:00:00 GMT

Core: major work has begun on moving to an embedded database. The ongoing progress on this can be followed here: https://github.com/tewinget/bitmonero/tree/blockchain

Core / Wallet: both the new daemonized daemon and rpcwallet are nearing a stage where they can be merged into master. The final step is to finalise the daemonizing code in rpcwallet, in such a way that it acts the same as the daemon, and we can move from there.

I8N: mnemonic word list German version is in progress and about 90% complete.

I2P: subsequent to discussions with the I2P team, we are going to be making a bit of a diagonal movement from libi2pcpp to i2pd. This should end up with us slightly ahead on the I2P integration project than we would've been. The major focus at the moment is getting TCP streaming (for persistent connections) to work, and that is where the largest focus is at present.

Monero Missive for the Week of 2014-07-07

Sun, 13 Jul 2014 00:00:00 GMT

Hello, and welcome to our sixth Monero Missive!

Major Updates

The GUI bounty is completed and all payouts have been made. You can view the confirmation of payouts in this post, and bounty recipients have confirmed receipt of their bounties. Just to reiterate the comments made by us in that thread: "As it stands right now, we won't be integrating any of these GUI clients into the main codebase just yet, as there is still a great deal of underlying work that must be done before we can ship a GUI wallet that just about anyone can run (unless we want to make the minimum memory requirement 8gb and the minimum Internet connection requirement 20mbps;) That having been said, we will continue to recommend the actively developed GUI wallets to anyone who prefers to use a GUI wallet, and that is the main purpose behind closing and awarding this bounty now: to have a short-list of recommended GUI wallets." The two GUI wallets we recommend using and that are being actively and continuously developed are:

neozaru's wallet: https://github.com/Neozaru/bitmonero-qt
Jojatekok's Monero Client .NET: https://github.com/Jojatekok/monero-client / https://bitcointalk.org/index.php?topic=683365.0

As you may be aware, there's been a great deal of discussion around dev donations. It wasn't something we thought to raise previously, as it is generally accepted that if you are making money from an open-source project (eg. mining, buying and holding for future profit, whatever) you will generally donate as that is the best way to secure an increase in your "investment". It is important to note that this is not a cryptocurrency that has a big, fat premine (or any sort of instamine / ninjamine / premine), and we are, therefore, completely reliant on the donations of our users. We really, truly appreciate all of the donations that we have received, from early pools such as the now-defunct monero.farm contributing a large portion of their earnings, to our largest donation from ceger, to the ramp-up in dev donations from a screed of pools. Thank you, you guys are the ones that are helping us cover costs and pay for contributors where necessary.
The initial work has been completed on analysing the CryptoNote whitepaper, and the review that has come out of it is now available to all. This is an academic approach to analysing it, and is the first step in figuring out whether the principles it espouses are reflected in the Monero code, and (further to that) how we can improve on its deficiencies. You can grab the whitepaper review here: http://monero.cc/downloads/whitepaper_review.pdf
Very early work has begun on reimplementing the mnemonic wordlists in other languages. We are currently doing a German one as a tester to see the amount of effort involved. If you are interested in producing a mnemonic wordlist (1626 words, following a small set of rules) in a language other than German or English please drop us a pm. There will be other translation work coming up (website, tooling etc.), and we will definitely be distributing donations to translators where possible (although they may be relatively small for the work involved).

Until next week!

Dev Diaries for the Week of 2014-12-15

Mon, 15 Dec 2014 00:00:00 GMT

Account: still more fixes to the restore paths and multi-lang mnemonics, known issues with UTF-8 on Windows remain

Core: libunbound lookups moved to a thread in order to trap for failing / slow DNS lookups

Until next week!

External Projects for the Week of 2014-12-15

Mon, 15 Dec 2014 00:00:00 GMT

MyMonero: due to a very broad DDoS attack at the data center in which MyMonero is hosted (not targeted at MyMonero) the service was offline on Sunday for a 12 hour stretch. We are putting some effort in place to ensure this does not happen again in future. New features added this past week: a "copy to clipboard" helper is now available on the right of your Monero address on your dashboard, as well as on the login key review screen and account details screen. In addition, clicking on a transaction in the dashboard or your transaction history screens will show additional details, such as the payment ID used.

ForkGuard: added MyMonero.com and MoneroClub.com

I2PD: massive progress was made this week adding support for the su3 router update format (the previous .sud / .su2 format being deprecated), which is used to deliver updates to all routers on the i2p network, including: router update alerts, plugin update alerts, reseed data, and news feed items. Details on the su3 format can be found here: https://geti2p.net/en/docs/spec/updates

Monero Missive for the Week of 2014-12-15

Mon, 15 Dec 2014 00:00:00 GMT

Hello, and welcome to our twenty-first Monero Monday Missive!

Major Updates

We're aware of the 0.8.8.6 slow startup issues on some Windows environments (over an hour for the daemon to startup for some people). We believe we've identified the problem, and will be rolling out a test fix in the next couple of days, for inclusion in 0.8.8.7
There have been a number of patches merged over the past week to fix issues with simplewallet's new multi-language mnemonics

Until next week!

Monero Missive Special Edition - 2014 Year in Review

Mon, 05 Jan 2015 00:00:00 GMT

Hello, and welcome to our twenty-second Monero Monday Missive!

This is our first Missive for 2015, after a 2 week break over the end of December. We'd like to earnestly thank everyone for their support over the course of this year, and for joining us on the start of our Monero journey. We'd also like to take this opportunity to look back on the past 8 months, and see where we got to.

State of Monero: 2014

As an open-source project, Monero is built on the back of volunteers, contributors, and donations. So let's start with a financial report.

For donations received over the year: we received 21 636.40655 XMR spread over 4343 transactions, and 8.04559 BTC spread over 25 transactions. Thus our average XMR donation is around 5 XMR, and our average BTC donation is around 0.32 BTC. As most of our costs are BTC based, XMR donations were traded into BTC where necessary (typically through OTC trades and not on-market), giving us a rough total of all receipts of 39.536205689 BTC (in XMR donations) + 8.04559 BTC (in BTC donations) = 47.581795689 BTC.

Expenditure for the year comprised of 3 totals as some costs could not be settled in BTC or were preferably settled in XMR. Our expenditure was 190.513492 BTC + 1 891.31 XMR + US $5 732.80, which is around the 212 BTC mark. Thus the shortfall of 164.5 BTC was paid out of the Core Team's own pockets in the hopes of recovering the funds later on (ie. just in case anyone was wondering, not only do the core team not get paid at all, but we've put a significant amount of funds into Monero).

So, what did our ~212 BTC get spent on over the year? Or, in other words, what did we accomplish? Here's a bit of a taste before we dig into the nitty-gritty:

Core Development

Well, let's start by excluding a lot of development done in branches on forks, and focusing on the master branch of the git repo. We inherited the Monero project pretty much from the end of April, with thankful_for_today's last commit on April 30th, 2014.

In order to see what we did with some pragmatism we took two folders, one containing the Monero source on April 30th at that last commit, and one containing the Monero source on December 31st. We removed everything in the external/ folder, except the CMakeLists.txt, so that we weren't including external libraries in our count. We then used Araxis Merge to produce a diff report between the two folders (plus Github's compare tool to give us additional information). We then subtracted the license changes we made earlier this year (208 files were affected, which means that for each we have to remove 2 lines from the "removed" count, 1 line from the "changed" count, and 28 lines from the "inserted" count). The summary is below, and whilst it obviously precludes things like where we made several changes to the same line of code, or missteps we reverted, it gives a very general indication of the effort.

35 weeks of development (245 days) since Monero was inherited by the Core Team
594 separate commits
11 contributors
10 221 modified lines
12 706 new lines
32 lines removed

Now may be thinking "wow, that's like 94 lines of code a day!", but it's important to remember that included in this are documentation and code comments, mnemonic word lists for several languages, as well as changes made to Bytecoin early on that we merged in.

However, it doesn't diminish the gargantuan effort that went into the Monero core over the year, and we are truly grateful to all who have been involved. Some of the highlights of work that was committed to the Monero core master repo over the past 8 months, in chronological order, include -

April:

got Monero building and running on OS X

May:

removed purposely obfuscated hashing loop
added a 'diff' daemon command to show current estimated difficulty and hash rate
more hashing optimisations, including AES-NI support
new wallet RPC commands: save_bc, getaddress; new daemon RPC commands: mining_status
enabled checkpointing and checkpoint verification
fixed the block reward penalty mechanism and dynamic block sizing
new wallet RPC commands: incoming_transfers
fixed exit flags, added --exit-after-cmd simplewallet flag

June:

added payment IDs to simplewallet's 'transfer' RPC command
added Doxyfile for code documentation
refactored parts of simplewallet
added Electrum-style mnemonics to simplewallet
got Monero building and running on Arch Linux
further improvements to hashing algorithm, including huge pages and AES-NI key expansion
added tx auto-splitting and changed transaction creation semantics internally

July:

new wallet RPC command: get_bulk_payments; new daemon RPC command: get_connections
new README, license changes to BSD 3-clause

August:

optional height parameter for simplewallet refresh
fixed wallet restore from seed
new wallet RPC command: query_key; new wallet commands: seed, viewkey
stopped a major spam attack dead in its tracks
highly sophisticated attack causes the network to fork for 30 minutes, urgently and immediately patched

September:

blob checkpointing added (over and above normal block hash checkpointing)
got Monero building and running on FreeBSD
major documentation of several C classes
new versioning system to allow for rapid identification of build commit
started enforcing GPG signed commits and merges, initial GPG keys added
testnet launched
dropped support for Visual Studio, added support for mingw-w64 + msys2
DNS resolver (libunbound) added, initial OpenAlias support
dynamic file-based checkpointing added
multi-language mnemonics introduced for wallets
new wordlists: Portuguese, and Spanish (first 4 letters unique)
DNS checkpointing added for rapid checkpoint alert / enforcement

October:

reworked log level choices
new wordlists: English (first 3 letters unique), as well as Japanese (first 4 letters unique)
PoW algorithm fully documented
switched to RapidJSON for JSON parsing
changed wallet file format (encrypted JSON)
massive CMake overhaul begun by KitWare, the creators of CMake

November:

per-kb transaction fees introduced
CMake overhaul completed, dynamic and static builds finally working again on all platforms

December:

bug fixes, bug fixes, and more bug fixes

The Monero Research Lab

Another major effort has been the Monero Research Lab, the MRL. In addition to the members of the core team, the triplets (Surae / Sarang / Shen Noether, obviously pseudonyms) spent months reviewing the CryptoNote whitepaper, publishing a synopsis of their review, and then building on that by doing extensive Monero research and finally producing several important research bulletins. From the ground-breaking chain reaction attacks in MRL-0001 to the deep dive explanation of Monero Ring Signatures in MRL-0003 (and the accompanying Python implementation) it has been 8 months of remarkable output for a group of people that at best only knew of each other very peripherally.

The Monero Research Lab members have also engaged regularly with Bitcoin researchers, including a mutually beneficial friendship with Andrew Poelstra who is included in the group of the "MRL Friends".

Between the whitepaper annotations, the review, and the MRL research bulletins published in 2014, 655 lines of python were released and over 25 000 words were written, all of which was the culmination of over 197 000 words spent in intense academic discussion.

The academics in the MRL also had an opportunity to meet up with Riccardo Spagni (fluffypony) and Tom Winget (tewinget) towards the end of the year, in a weekend of epic nerdiness that included a trip to a natural history museum and getting stuck on the side of the highway with no petrol due to a faulty gauge. Don't worry, the emergency petrol fill up wasn't paid for by donations;)

Infrastructure

The Monero web infrastructure consists of 4 key components: web hosting, testing infrastructure, seeding, and download hosting.

Our web hosting serves the Monero website, the Monero forum, the Monero Research Lab site, and so on.

Testing infrastructure consists of a Mac Mini hosted at MacStadium, as well as a beefy testing box hosted at Hetzner in Germany, on which we have a number of VMs for the various operating systems and variants we target. Our QA lead contributor, Gazby, who has recently started will be bringing the testing infrastructure up to scratch, and adding things like Jenkins for nightly builds and Gitian for deterministic signed releases.

Seeding infrastructure consists of several geographically separated boxes that keep the moneroseeds.se/ae.org/ch/li records updated with active seed nodes.

Download hosting consists of several servers scattered across the globe (3x USA, 2x UK, 1x Germany), and it serves all static content including the blockchain downloads, Monero binaries, MRL publications, and so on. The Monero blockchain alone is downloaded hundreds of times in a month, with our bandwidth usage regularly exceeding 2tb a month across the download nodes. Obviously this provision is not cheap, which is why your continued assistance to this project is greatly appreciated.

OpenAlias

An important project that the Monero Core Team created and developed is OpenAlias. Monero addresses are ugly, complex, and not really human readable. But then, too, so are Bitcoin addresses. Typically most cryptocurrencies attempt to solve this by having some sort of centralised register, say they've developed "aliasing", and call it a day. For Monero, this approach simply wasn't good enough.

To understand why it is important one must first understand "Zooko's Triangle". Zooko Wilcox-O'Hearn, the incredible brain that contributed so much to the Tahoe-LAFS distributed file system (and which was first released May 2nd, 2007), posited that any naming or aliasing system has three goals or desirable traits (and we're just going to quote Wikipedia here) -

Human-meaningful: The quality of meaningfulness and memorability to the users of the naming system. Domain names and nicknaming are naming systems that are highly memorable.
Decentralized: The lack of a centralized authority for determining the meaning of a name. Instead, measures such as a Web of trust are used.
Secure: The quality that there is one, unique and specific entity to which the name maps. For instance, domain names are unique because there is just one party able to prove that they are the owner of each domain name.

Zooko initially concluded that it was impossible for a naming system to have all 3, and at best it could hope to have 2 of the 3. Subsequently, systems such as Namecoin and Twister proved that it was, in fact, possible to have all 3.

Despite that, most of the aliasing / naming implementations that exist today seem to fail on the decentralised aspect (eg. requiring that a block is solved to register an alias centralises it in the hands of the large mining pools, and also limits the number of aliases that can be created a day), and almost always fail on the long-term goal of "human-meaningful".

We say the latter because a limited aliasing system where globally unique nicknames are chosen invariably devolves to a post-land-grab scenario where so many variants of "bob" have been acquired that a user is forced to chose bob0923840129832 as his alias, which really doesn't solve the naming issue at all. In addition, it forces the cryptocurrency creator to be the one responsible for solving alias disputes, and in many cases aliases are permanent and cannot be changed if you lose your private key.

OpenAlias is different. Not only does it "square Zooko's triangle" (still a unique and difficult to accomplish task), but it allows for the offloading of decentralisation to Namecoin or GNUnet or similar, whilst still allowing for the offloading of conflict resolution to existing systems such as ICANN's ADR (Alternative Dispute Resolution). Best of all, it leverages the fact that so many people and companies already own their own domain names, so there is no need for additional complexity.

Monero has implemented OpenAlias on quite a basic level, and will be improving its support as time goes on. The OpenAlias project has also not been standing still, and has been working on several sub-projects.

GUI and Database

With the two attacks we thwarted in 2014, the GUI development had to take a bit of a backseat. On the other hand, the blockchain database implementation has progressed nicely, and is currently being rebased to the latest master and tests are being updated and created for it.

The GUI code alone already consists of 5 213 lines of QML and over 100 lines of C++, and that is well before anything is wired up. The blockchainDB code consists of over 60 commits on the implementation alone (over and above the tons of commits to create the generic classes and implement all the functionality prior to that), with over 5 500 lines of code already part of it. It truly has been a monumental engineering task.

Monero Forum

A project guided and directed by the Core Team, although primarily written by a contributor (Eddieh), the forum grew out of an interesting need. On the one hand, Monero is still in its infancy, and the Monero sub-Reddit would likely have sufficed for quite some time. On the other hand, there was a general pressure for us to have our own forum, our own home.

So why didn't we just use something off-the-shelf? There were several reasons. The primary reason is that most forum software (SimpleMachines, phpBB, Vanilla, etc.) is either too clunky or too old to really be workable in a modern context. And, too, it would be something we would have to live with for a long time (see: Bitcointalk, for instance). Customising existing forum software to suit our needs would not have been cheap (see: Bitcointalk again). Thus a decision was made to see if we could find someone to pursue creating something fresh for us as a peripheral exercise.

After 6311 lines of PHP, 1226 lines of CSS, and 135 lines of JavaScript, we're proud of what we've produced. Instead of using antiquated content systems like BBCode, we have MarkDown. Instead of pages and pages of threads, we have infinite scrolling and threaded views. Instead of fundamentally flawed trust systems like "default trust" we have a synchronised copy of the Bitcoin-OTC Web of Trust, allowing users with existing WoT accounts to immediately have their trust groups accessible on the Monero Forum for trading. Instead of only meaningless sorting by date (which we have!) we have posts sorted by weight. Since weight is a product both of post age, insightful/irrelevant votes, and your trust relationship to the poster, you are already able to visit a thread and only see comments that are relevant to you, with all other comments collapsed. We are actively massaging more usefulness out of the weighting, but it is core and fundamental to the forum.

Obviously this is a project that still has a LONG way to go to reach maturity. With that in mind, don't forget that you are key to this: if there's something about the forum you don't like, or a feature you want, or a bug you've found, put it in the Meta section of the forum (until we have a github repo that you can post issues to).

The Monero Missives

Our first Missive was put out on Monday, June 2nd, 2014, and has been instrumental in collating and bringing together various little snippets and pieces of work and threads every week. In the 30 weeks from that first one till the end of the year we put them on pause for 4 weeks during the attacks in August, and took a 2 week break at the end of the year. The remaining 24 weeks had 21 Missives in them, giving quite a bit of coverage and keeping our userbase as informed as possible. Some Missives are easy and only take us two or three hours to put together.

Some Missives are substantially harder due to time constraints, dependencies, research (see: this Missive you're reading, for instance;) or just the sheer amount of stuff that is going on. In total, the 21 Missives we put out over the past 8 months contained nearly 16 000 words over 689 sentences!

And just for fun, this Missive took several days to put together (not all day, every day, mind you) and unsurprisingly ends up being our largest Missive by far, at 3 450 words and 111 sentences!

Other Core Team Projects

The two other projects the Core Team released in the year are the Monero DNS seeder (xmr-seeder), and URS, a Unique Ring Signature signing tool written in Go. Both of them are active contributions to the Monero infrastructure, and continue to be useful and fundamental on a daily basis.

External Projects: 2014

The Monero Core team and core contributors obviously aren't the only ones working on Monero-related projects. Some highlights from the year include:

Node CryptoNote Pool

When Monero first started there was no open-source pool software for it. Through the collective efforts of zone117x and lucasjones, an open-source pool was developed and released. It was an incredible undertaking, given the monstrous lack of documentation and code comments in the CryptoNote source, and we owe them a debt of thanks.

i2pd Development Partnership

Initially this started as a partnership with the i2p team, with a view to getting i2pcpp to a workable stage. When i2pcpp stalled, and on advice from the i2p team, we form the Privacy Solutions working group between Monero, AnonCoin, members of the i2p team, and the i2pd developers.

The focus for the past few months has been on i2pd, which has made amazing progress. Since the launch of the PrivacySolutions partnership at the end of July, a series of 692 commits has brought i2pd up to a stage where it can maintain relatively stable connections to the i2p network.

ForkGuard and MoneroClub

Both services launched and operated by Atrides, ForkGuard provides realtime information on the current block height for pools and services that run full Monero nodes, and MoneroClub is a listing of localised Monero and fiat OTC trade offers. Atrides isn't stopping there, and for his next project he's looking to produce a Monero fork of OpenBazaar!

MyMonero

Owned by Riccardo Spagni (fluffypony) and Risto Pietilä (rpietila), and operated by fluffypony, MyMonero is the first web-based client for Monero. In doing so it closes a major end-user usability gap, and goes a long way towards making Monero useful and usable.

Crypto Kingdom

Created and started by his lordship, King Risto, Crypto Kingdom is a retro-style virtual world game where players can interact, build, create, and so on. An online playable version is in the works, and as Monero is driving the in-game resources and currency it is well on its way to becoming a fully-fledged microeconomy!

Looking Forward: 2015

We have a lot in the pipeline for 2015. A few things that we'd like to highlight that you can look forward to:

more MRL academic goodness, including some of the work started at our MRL mini-meetup from 2014
a finalised, working, tested blockchain DB implementation using LMDB
i2p integration
some additional blockchain DB implementations
finalisation and release of the Monero core GUI
the release of smart mining functionality
the finalisation of a complete overhaul of the RPC functionality
HTTPS and simple auth support for RPC servers
a new, unified, well-documented RPC interface
blocknotify and walletnotify equivalents in the daemon and wallet client
a complete replacement of the wallet/server IPC with 0MQ
multi-signature transactions
open-sourcing the Monero Forum software
the release of some OpenAlias sub-projects

And, undoubtedly, much more both for Monero core and related external projects.

Of course, none of this would be possible without donations from our users, and we are most appreciative and grateful to those that have donated thus far. We hope that over the next year you will continue to help and assist us - and don't forget our donation addresses are powered by OpenAlias, both XMR and BTC donation addresses are on donate.getmonero.org

Thank you for a great 2014, and here's to a great 2015!

Your Core Team - Riccardo "fluffypony" Spagni, smooth, othe, David Latapie, tacotime, NoodleDoodle, eizh

Monero Missive for the Week of 2015-02-23

Mon, 23 Feb 2015 00:00:00 GMT

We are moving to a new Missive format, it is now in the form of a podcast!

To download the podcast directly please use this link to the MP3.

A brief summary of the points discussed follows, and a full transcription of the podcast is below.

The release of the new website, and the move to the getmonero.org domain
The publication of MRL-0004, Improving Obfuscation in the CryptoNote Protocol
Monero's design and development goals

Dev Diaries and External Projects will resume being covered from next week. Until then!

Podcast Transcription

Riccardo "fluffypony" Spagni

Hello and good morning or evening to you wherever you are I am Riccardo, fluffypony, and with me today I have Gingeropolous...say hi!

Gingeropolous

Hello everyone!

Riccardo

And this is the start of a new type of Monero Missive, because we realized as a core team that preparing a full Monero Missive with all its bits and pieces was taking up a lot of time and soaking up a lot of effort that would have been spent elsewhere. And more importantly we also realized that a lot of people just weren't getting through the content of the Missives that we were putting out, hence this new format.

So, Gingeropolous you are reasonably well known already, why don't you tell us a little bit about you and your involvement in the Monero community.

Gingeropolous

Oh sure, I watch the Monero community on the forums and as there was no Missives coming out people were like "hey, why aren't there any Missives," and I was like all right I will go ahead and make a version of them to sort of sum up what I saw happen in the community. So that's where that whole digest came from and I guess that digest caught the eye of the actual core developers, and they contacted me like "hey, do you want to do this podcast?" And I guess my sort of role or function is to bridge the gap between those that actually know what Jason is doing and those that either don't know what Jason is doing, cause Jason is very popular.

That's correct.

So there are a couple other text that are detailed in the paper, things like association by use attacks and so on, and so one of the small things we are going to be adding is every 6 to 8 weeks, if you are using the wallet regularly...every 6 to 8 weeks if there is a certain number of blocks that are being added to the block chain, 6 to 8 weeks' worth since you last received any transfers to your Monero wallet, it is going to flash you a little warning, and it's going to encourage you to send some funds to yourself. Just send it out and back to yourself, which means you are sending it back to yourself as the recipient. And some of the changes like that, it's not hardfork changes, it is just encouraging certain behaviors. It is really just to prevent certain attacks, and the reality is a lot of these attacks are edge cases. Some of them do require a certain level of skill, prowess, money, power, whatever of an attacker, but it is just a really trim down those edge cases so that the risks, the edge case risks, are reduced even more with the Monero.

Gingeropolous

And so is there going to be like a recommendation from your wallet software, or just sort of hardcoded in there like "oh you haven't done anything in 2 months...I'm going to send half of your wallet to yourself?"

Riccardo

Well one of the reasons that we can't do that is because we can't force people to spend the money in fees, that's the first thing. So we can't have a protocol that's living on the @blockchain or living on @nodes that spends money or spends funds without the user's involvement because they control the fees. Now the nature of things is that not everyone keeps their wallet open all the time even if they are running a @full-node and that node is connected to the network. So it's not really suitable to doing stuff in an automated fashion. It is just something where thre would have to be some cognizance on the user side where they will see the warning and they will go "oh dear, I've got to send out to myself," and on the GUI side maybe we'll add a big fat button that they can just click on and off it goes. And a lot of it is to reduce things like association by usage problems and so on.

And one of the things is age-based association as well, which is something which, quite literally, the Monero Research Lab spend about 3 or 4 weeks discussing at length. Now the age-based association problem is quite simple. If, and I will use Bitcoin is an example, if Satoshi suddenly reappeared and touched some of the early blocks, some of the Bitcoins that were generated in the very early blocks, there would be this mass panic because people would be like "oh...why is he moving his Bitcoin, is a suddenly cashing out?" Now that sort of thing is a product of knowing exactly what happens within that very obvious and transparent @blockchain. Now in Monero there is kind of a similar thing that can happen and it's not quite, I mean the consequences are a little bit different.

Let's say you receive funds today...you received 100 Monero and that's an output that gets created. Now in 20 years' time you haven't touched that, and you suddenly decide to go and spend it. Now there is a temporal association problem because, over time, the 100 Monero has been chosen by, or should be chosen by, people to mix with. And in 20 years' time when you go along and actually spend it, because of the nature of how outputs are chosen to mix with it could be that your spend becomes obvious. Because, for the most part, maybe by virtue of the way outputs are chosen, the distribution of outputs, that statistically that output would not likely be selected for ring signature. And so now there can be an analysis that happens where somebody can say with reasonable certainty that of the signatures in this 100 Monero input in this transaction, they are fairly certain this 20 year old output is used to sign with it is the real one.

So this is something, this age-based association problem, is something that is really tricky to deal with, and is not something that were going to deal with on a protocol level. We are not going to prevent people or force people to mix in a certain way. Instead what we're going to be doing is we are going to be monitoring the way the way outputs are selected of a period of time, and monitoring the distribution. And we're going to sort-of get a feel for it, and get some data, and then we are going to be able to say "okay, based on that we are going to recommend this sort of distribution...Poisson distribution," or whatever it is, in order to reduce the risk of age-based or temporal associations.

So that's something that's not quite as critical as the minimum mixin thing; the minimum mixin thing is really like ground zero for fixing the CryptoNote protocol at its rawest level, and then everything else is bolting on top of that to reduce very low-risk, very edge case issues.

Gingeropolous

Gotcha.

Riccardo

So that's basically...the long and short of it is that minimum mixin is going to be implemented on a wallet level quite quickly, and the hard fork will be planned and will happen later.

Okay, so we spoke about the new website, we've spoken about MRL 4, and now we're going to kinda jump back just to something on the website. Now if you are on getmonero.org and you go to the Knowledge Base menu you will see the section called Design and Development Goals. Now design and developing goals is something will be updating from time to time, but of particular interest to people, and of particular interest to us as well because we created it, are really the things that were going to be doing in the future.

Thanks very much for the chat...and back to Fred with the weather!

External Projects for the Week of 2015-03-09

Mon, 09 Mar 2015 00:00:00 GMT

To download the podcast directly please use this link to the MP3, or this link to the AAC/MP4, or this link to the FLAC.

A brief summary of the points discussed follows, a full transcription of the podcast is below that and was kindly transcribed by goin2mars. You can donate to him for his transcription efforts: 4AzncXEK71uEtNtSKJjaX845XnJr9s7onXYNSBPTB2AGNnPbTjaN5W72qo8YgSSYsLGcr5pTBQkjnE7ADn6XbbHG2CTvvU1

In this week's podcast we cover external projects, with an interview with the xmr.to team.

MyMonero has added existing wallet import functionality. Just use your 25 word mnemonic from simplewallet when logging in, and after paying the 10 XMR once-off fee your wallet will be available in MyMonero.
An interview with two members of the xmr.to team, binaryFate and Krongle, discussing some of the system's inner workings and challenges they've faced.

Until next week!

So because of the amount of stuff that we seem to be covering in each weeks Missive podcast we obviously haven't been able to touch on external projects. A recap for everyone that doesn't know what external projects is: it's a section of the missive that deals with projects that are not entirely by the Core Team, they're by members of the community...or anyone, really, that's doing something interesting that involves Monero.

Ok, so you know MyMonero seems to be growing in popularity, and obviously one of the concerns that people have had is the ability to...you know, they want to be able to use MyMonero if MyMonero explodes, and they don't want to lose access to their funds, for want of a better term. And obviously they are still in control of their funds, they're in control of their private key, but we do recognise that there is a need for simplewallet to be able to use the MyMonero style keys.

So that's something we are working on, and that's something that's something that we're quite close to, but what were happy to announce is the availability of an import wallet function. So if you have an existing simplewallet mnemonic, 25 word mnemonic, you will now be able to import your wallet into MyMonero. However, this doesn't come free - if you've ever done a wallet restore then you'll know that it is a little bit painful, because a wallet restore takes several hours, even on a snappy machine. So for us to import wallets we have to incur a cost purely from a processing perspective, and that has to be handed over to customers.

So at this initial stage we're going to be charging 10 Monero for a wallet import. It's a once-off cost, you'll never need to pay it again, and it will run from there on out with no additional fees for importing it. Obviously as time progresses, and depending on how successful this feature is, we may look at reducing the cost or whatever depending on how it scales. And one of the other things is we do support all the mnemonic languages that Monero supports, and will continue adding support for them as they increase. The ability to go the opposite route, you know to go from MyMonero into simplewallet, should be in simplewallet shortly.

Then really the last prong of this three pronged attack that we're doing is to give people the ability to create watch-only wallets...which effectively you can kinda fake now, in a way, by importing your view key with a random spend key, but we'll have proper watch only wallet functionality soon.

Gingeropolous

Oh cool, so you just log in to check like how much you have in your account, to see if anyone has sent you anything.

Riccardo

Ja, and its not in a manner that can be exploited, because we wont have your spend key, and even if we try to change the JavaScript we still wouldn't have your spend key.

Ok so pretty much since we last did external projects there's a newcomer on the scene that's kinda exciting: xmr.to. And that's why today we have Krongle and binaryFate who are both from xmr.to, they're part of the team.

So to start off why don't you guys tell us a little bit about what xmr.to is, either of you?

Krongle

Alright, so we're a bunch of computer science researchers, in fact there's three of us - there's us the two of us and Arnuschky, who's also known. I'm the newer guy, but these other guys have been involved in crypto for a longer time, and binaryFate, I think, has been aware of the whole Monero stuff right from the beginning. He got me and Arnuschky excited about the whole space, so we've been looking to get into crypto for a while.

We've just recently started a company called CryptoSphere Systems, which is the brand that we wanna get involved with, that we wanna use. So we wanted to do something simple and quick to dip our toes in the water. So we came up with this idea, that one of the things obviously that is great and exciting about Monero is the whole anonymity, but the problem is that it's very hard to spend this stuff, whereas everyone's spending Bitcoin.

So the idea was quite a simple one...just try and enable people to spend Monero, but in Bitcoin world.

Riccardo

binaryFate, can you tell us a little bit about how xmr.to works from a user's perspective?

binaryFate

From the user perspective, it's quite simple in fact. Basically you have a friend you want to send to Bitcoin to, or you have a BitPay bill to purchase something online, you are given a Bitcoin address and you send a Bitcoin amount.

What xmr.to is doing is to be an automatic gateway to pay these bill in Bitcoin for you, and for you sending us some XMR. So in the end it boils down to the ability for the user to purchase anything with Bitcoin, while only spending Moneros.

So xmr.to gives the possibility to the end user, basically, to send Bitcoin - so to purchase any kind of goods online with Bitcoin that is now probably accepted unlike Moneros for the moment - so the user can purchase stuff with Bitcoin by only paying Monero.

Gingeropolous

I myself tried the thing out within, like, the first hour of you guys posting, I dunno if you recall. So yeah I was able to just plug in the Bitcoin address I had, and pay myself with Monero.

You know my question in these things is always, from the new user...you know, just pretend I'm some guy that watched the Superbowl and was like "oh Bitcoin" and then read about "oh Monero!" How secure is it? What are the processes of it where i can be sure that I'm actually sending Monero and it'll turn up as bitcoin somewhere? Again this is the whole trusting a third-party thing, so I dunno if you guys could elaborate.

Krongle

I think there's two different aspects to this. So one is just: do you trust any third-party, so some random person on the internet, do you trust them? I mean in a way there's not that much you can do about it...

Gingeropolous

Right, right

Krongle

...beyond just trying with a small amount, and I guess that's kind of what we've seen people doing already.

Riccardo

You know, when it comes down to it you've also gotta trust the company you're buying from anyway. So whether you're adding another layer to it...meh.

Krongle

This is the same as what everything on the internet before the community as well so you see that people have had positive experiences and the thing hits a critical mass and then you can be fairly confident that it works. you will feel the first couple of users that its just this weird black box that you don't know whats coming out the other end

Gingeropolous

Yeah just to mention that as you said its something that we witness anywhere in general because we are to trust the merchant or we are to trust bitpay to actually act as a gateway and not to keep your bitcoin so its just one layer that people i think are quite used to

yeah i think the most important thing for me to mention is that there is absolutely no trust involved for anything that is um privacy related so you spend your Monero and we dunno anything more than that.

Gingeropolus mhm

binaryFate

because Monero is not traceable back so we can really the only information that we know about you is your ip address but if you reach xmr.to through some um anonymous networks like tor i2p then there is not much that we can do even if we were some really bad guys we would like to we couldn't do anything basically which is very nice

nice to know that the effort was noticed. appreciated.

Gingeropolus i have a couple of questions about that whole process

binaryFate

yeah

Gingeropolus for one um, there are some merchant services i believe bitpay and coinbase being two of them i think they have roughly ten minute timeouts on a transaction so if you start a transaction then that amount of bitocin they want you to send is valid for only ten minutes to deal with the volatility a bit. do you wait for enough confirmations from Monero from the blockchain and if so is it within that limit would i have a problem with that?

so basically withing that fifteen minutes i have to send Monero to you. it has to get enough confirmations or you guys to mark it as safe and then you have to send the bitocin and so what toms asking is what are the chances of missing that window

binaryFate

so what we do is to give the user five minutes time window but what matters and what needs to happen within this time window is just that we actually see the transaction on the peer to peer network. if you send the transaction on time there is literally zero chance that you miss this time window. if you are just connected to the Monero network. and as soon as we actually witness the transaction on the network we stop the timer and we just wait for one confirmation before sending the bitocin. we think that for now one confirmation is way enough and we can take the risk especially because we're still dealing with very small amounts. but because we don't need the confirmation to happen in the time window but only to witness the transaction on the network its very safe for the user because you're practicality no chance to miss it

but in terms of missing the second timeout like the lock on time amount of whoever you're paying in bitocin its quite unlikely if you're snappy on your end as an end users i think that were just benefiting form the fact that the Monero confirmations clock in much faster than the bitcoin confirmations

Gingeropolus it sounds like waiting for one confirmation is plenty small time.

even if we eventually want to up that to two or three you're still within, you can get 2 or 3 Monero confirmation well before even one bitocin confirmation so no one in bitcoin world is gonna set their timeout so small because of the slow confirmations

binaryFate

if in the future this becomes an issue say bitpay suddenly decides to change this countdown to five minutes instead of fifteen what we could do on our side is to accept a zero confirmation transation which is exactly what bitpay is doing. based on some rules you judge whether the transation is highly likely to be spend and for now its really do it and see for our needs but its something we could do int he future.

Gingeropolus now if i could ask just one other question. i don't know this one that you probably might not want to answer but I'm curious how does this work on the back end. like can you give any sort of like brief synopsis of that. because I'm curious like do you take the xmr and then go and buy the bitcoin like where does the bitcoin come from in this i guess is the question.

Krongle

yeah well, uh, in a way i think its important for the user to know at least one thing this thing is that we don't buy the equivalent of bitcoin right away because that would be possibly weakening the privacy right because you could make some time correlations because poloniex could do for instance we would use poloniex to change the Moneros immediately. for the same amount that was just sent to us. that would be an issue. so we don't do that. we are not sure how in the future how we are going to change them but for now i think we do it like once a week. so yeah for now in a way .....? and we are still figuring out what the best way for us to go financially speaking but yeah whats important to know is we don't change them back right away.

and the other thing important for the end user to know is we set our maximum based on how much bitcoin we have in our funds so we will never accept an order we cant fulfill basically. if were running low on funds.

Riccardo

your risk tolerance is based on how much you got in reserve

binaryFate

yeah so were exposing ourselves to exchange fluctuations at the moment we just take on that risk and as Jeremy says we need to come up with a plan where we protect ourselves against that.

Riccardo

thanks very much for the chat guys and well see everyone next week

Gingeropolus yeah thanks for hanging out guys

Tom

cheers guys see ya

binaryFate

thinks for having us bye

Gingeropolus thank you all for joining it was quite a big crowd today, very awesome. thanks all for listening and tune in next week and here's bob with sports.

Monero Missive for the Week of 2015-03-16

Mon, 16 Mar 2015 00:00:00 GMT

To download the podcast directly please use this link to the MP3, or this link to the AAC/MP4, or this link to the FLAC.

A brief summary of the points discussed follows, a full transcription of the podcast is outstanding (can be submitted via Github Issues).

In this week's podcast we update the progress on the DB, discuss Tippero, talk about decentralising-all-the-things, and discuss the English wordlist bug.

Initial DB merge is about a week away.
Tippero has been officially made publicly available, and allows for tipping on IRC, Reddit, and Twitter! For IRC, send a message to Tippero with !help or !commands. For Reddit, message /u/tippero with !deposit for your address, and tip with +amount /u/tippero optional message in a reply. For Twitter, you can tip with +amount @recipient_person @tipperome optional message. Until Tippero lets you link your accounts across networks you can manually move funds, for eg. on IRC: /msg tippero !tip twitter:fluffyponyza 10 or /msg tippero !tip reddit:fluffyponyza 10.
Not everything needs to be in a blockchain, and not everything can be decentralised with our current level of technological advancement. The Monero core team won't crowbar decentralisation into everything unnecessarily, especially when it has potentially disastrous results.
English mnemonics that contained "incline" or "launchpad" will need to test restoring by replacing "incline" with either "incur" or "inline", and "launchpad" with either "ourselves" or "launching".

Until next week!

Dev Diaries for the Week of 2015-03-02

Mon, 02 Mar 2015 00:00:00 GMT

To download the podcast directly please use this link to the MP3.

A brief summary of the points discussed follows, and a full transcription of the podcast is below (currently being completed, and it will be updated as it progresses).

In this week's podcast we restart dev diaries, and focus on two things:

Updates on blockchainDB, including rationale, performance considerations, and future steps
Moving away from the old RPC system for talking to the daemon, to a 0MQ-based IPC system

Technical note: in order to make this Missive a little more accessible, given its technical nature, we have taken some liberties in using the term "RPC" to refer to the JSON RPC API 2.0 over HTTP system used when currently communicating with the daemon, and "IPC" to refer to a complete replacement of that subsystem with 0MQ subsystem based on their Router/Dealer pattern, using the zmq_tcp transport for compatability.

External Projects has moved to be covered next week. Until then!

Podcast Transcription

This is the sort of thinking, as a longer-term prospect, which necessitates having multiple database implementation options, because that's really one of the sticking points, or one of the pain points. So LMDB...great, vl-32 branch...awesome, the vl-32 branch will probably, and we haven't tested this yet, will probably play quite nicely with Raspberry Pi. But even beyond that we're going to, at a slightly later stage, once we've got a little time in a couple of months, we're going to be adding BerkleyDB support.

Yeah we are a little bit!

Incomplete, Work in Progress

Dev Diaries for the Week of 2015-03-23

Mon, 23 Mar 2015 00:00:00 GMT

To download the podcast directly please use this link to the MP3, or this link to the AAC/MP4, or this link to the FLAC.

A brief summary of the points discussed follows, a full transcription of the podcast is outstanding (can be submitted via Github Issues).

In this week's podcast we discuss the new blockchain utilities in preparation for their final merge.

blockchain_converter converts between database types, right now its only job is to convert from the old in-RAM system to an lmdb database. It chews memory, though, as it has to keep the blockchain in RAM as well as the lmdb driver.
blockchain_export takes the default database (set at compile time) and exports it to a blockchain.raw file. This is the file we're going to make available for download as the blockchain bootstrap in future.
blockchain_import imports from the blockchain.raw file into whatever database format (specified at runtime, the default database is specified at compile time). It allows you to import with verification off for the fastest possible speed, specify LMDB options, and specify a batching count for loading in chunks.

Until next week!

External Projects for the Week of 2015-03-30

Mon, 30 Mar 2015 00:00:00 GMT

To download the podcast directly please use this link to the MP3, or this link to the AAC/MP4, or this link to the FLAC.

A brief summary of the points discussed follows, a full transcription of the podcast is outstanding (can be submitted via Github Issues).

In this week's podcast we interview Jojatekok, the 17 year old creator of the MoneroX GUI, and discuss his switch to cross-platform support for MoneroX, as well as some of his future plans. We also spend some time musing over his youth, and wondering where ours went to!

Until next week!

Monero Missives for the Week of 2015-06-29

Mon, 29 Jun 2015 00:00:00 GMT

Yes, as some of them wondered what happened in Europe.

Gingeropolous

We saw some pictures from Brussels, I don't know where those were, with the tiny elevator.

Riccardo

Yes, it was Brussels and I was going to put more pictures up, but then between running around, being super busy and also Bitcointalk being down for like ages, I just gave up on that idea. So I'll try and put some photos up. I didn't unfortunately take much in the way of photos of the actual meetups and bitcoin friends, but that also because not everyone wants their picture taken and plastered all over Bitcointalk. Apparently I am the exception to that.

Well, it's not like them accepting Monero will make them any less of an Bitcoin embassy. By the way, it's more the restaurant that's attached to the Bitcoin embassy, not the embassy themselves

It's something like we're giving people a choice to pay with one or the other. This is advantageous for merchants but I also think that there's a lot of infrastructure that can be leveraged at the moment. If merchants are really used to accepting it or firing up Blockchain.info or running electrum or whatever for accepting Bitcoin payments, it's not such a massive leap to start accepting Monero payments. Obviously that will only improve with time as systems get build out and so one. So we'll see how that goes, but I'm not a very big believer in merchant adoption being key for adoption. I think we've seen with bitcoin already that having massive amounts of merchant adoption hasn't helped with getting Bitcoin into the hands of people.

There are some side projects where i' ve been working on for a while with some guys to try to improve that ecosystem not only for Bitcoin, but also for Monero as well. So we're helping people to get and to earn Bitcoin and Monero rather than to say to the people: "well there's a thousand places where you can spend it but sorry you need to go through this complicated process to buy it".

So that's kinda Fluffypony's trip to Europe.

Gingeropolous

The Magical Mystery Tour in a nutshell

Riccardo

Yes, unfortunately I didn't make any T-shirts for it to wear, with all the places I've gonna be performing at.

Fluffypony on tour 2015 Europe, yeah!

Gingeropolous

As a really brief recap based on what I get from this conversation it sounds like at the first meetup, you had the ZeroMQ guy there and the big takeaway was that you guys had to sit down and hash out how to gain more knowledge on managing an open source project. You brainstormed about this scheduled hard fork idea which has been a great conversation to follow on the forum if anyone hasn't tuned in to that yet. That post I recommend especially if you are interested in Monero and assuming you listening to this podcast, you want to know what it's doing and where it's going. Check out that thread, it's on forum.getmonero.org in the academic and technical section.

Gingeropolous

Privacy theater?

Riccardo

So privacy theater and decentralized theater is basically when something put on a show of being private and being decentralized. I"ll give you an example: there is a lot of conversation recently about ripple. Is it a cryptocurrency and it is decentralized? The reality is that there is a lot that you can do to sort of run your own component within the ripple network, but it's not decentralized. At best we can say ripple is distributed. But distributed and decentralized are different things. So obviously Ripple can claim to be decentralized and then they can say "look anyone can run you this or that" but that's not the same as being truly decentralized. What happens is that you end up with in that case decentralized theater where people might mistakenly expect or assume that Ripple is decentralized. The same goes for a lot of these altcoins, and altcoins are particularly bad at this, that have centralized mixing build into their wallet and then they pretend that they are somehow private. What they sometimes even do is hosting a couple of servers and use an API and a website to handle the mixing. And then they go like "see, it's hosted on more than one server" but again that's not the same as being decentralized, that's merely distributed. So there again we've got privacy theater and decentralized theater because the privacy that they are adding is not privacy to the level of being fungible.

Yeah, thanks for tuning in!

Monero Missives for the Week of 2015-08-31

Mon, 31 Aug 2015 00:00:00 GMT

To download the podcast directly please use this link to the MP3, or this link to the AAC/MP4, or this link to the FLAC.

In this week's episode we discuss the website content, and how everyone can contribute to making the Monero website a more complete and useful resource for newcomers.

Until next week!

Podcast Transcription

Riccardo "fluffypony" Spagni

Hello everyone and welcome to another Monero Missive. I am Riccardo, fluffypony, and again unsurprisingly today I have gingeropolous

Gingeropolous

Good morning everyone, this is Gingeropolous. How are you doing? But it is not morning. It could be afternoon for you, I keep forgetting that.

Riccardo

Could be evening

Gingeropolous

About Monero
Moneropedia
User Guides
Developer Guides

To download the podcast directly please use this link to the MP3, or this link to the AAC/MP4, or this link to the FLAC.

In this week's episode we feature a brand new external project: Monero Dice, and interview its founders and operators, Riccardo "fluffypony" Spagni, and rznag.

Until next week!

Sat, 26 Dec 2015 00:00:00 GMT

To download the podcast directly please use this link to the MP3, or this link to the AAC/MP4, or this link to the FLAC.

In this week's episode we interview psi, from the I2P project, and also announce the new Monero Kovri project, an open-source C++ router.

The source can be found here: https://github.com/monero-project/kovri

Until next week! (this is now a running joke...right guys?)

Monero 0.9.0 "Hydrogen Helix" Released

Fri, 01 Jan 2016 00:00:00 GMT

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 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 and MRL-0004 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

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

Monero 0.9.1 Released

Fri, 15 Jan 2016 00:00:00 GMT

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

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

Overview and Logs for the Dev Meeting Held on 2016-01-31

Sun, 31 Jan 2016 00:00:00 GMT

Summary

Use of dev branch

First thing discussed is the dev branch. Contributors have fell back into the habbit of merging stuff to master. All hacking should be done onto dev branch.

Apparently this is because of bugs. A new point release to fix the v1/v2 stuck transaction bugs is coming.

The thing holding up general move to development branch is that CZMQ/0MQ hasn't been bundled in source, so its a pain to compile. Everyone agrees to bundle CZMQ/0MQ into dev branch. fluffypony will get it in the source tree.

There is more talk about minor tweaks that should or shouldn't go into the upcoming point release.

Style guide

In Kovri they've been working with a style guide, and fluffypony suggests implementing one in Monero. Basically, this is the way the code is formatted (human formatted).

Its agreed to use the new style with new code, and restyle-as-you-go with old code. Restyling for the sake of restyling is though to be unnecessary. Key points:

we assume from this point on the code is indented like the majority of the code so far - 2 spaces, not tabs, not 4 spaces.

push harder on "code should go in a .cpp not .h"

Collective Code Construction Contract (C4)

As used in 0MQ as described here

The idea is to merge every PR as long as it doesn't break the build. Aim is to avoid PR-hell where everyone comments on a PR for days and weeks and it never gets merged, because its never "perfect." Merge-everything is done so that contributors establish a history, and they can be banned if they are repeat offenders.

In general, the idea is agreed upon. However, there is concern and uncertaintly regarding the roles of the various branches and how the contract applies to which branches. The conversation bleeds into ringCT implementation and timeframe and how the c4 would affect this process. The fact that 0MQ-dev branch is currently unusable is brought up regarding how the c4 would function. It is noted that 0MQ was pushed to dev because the original contributor couldn't continue working on it. Ultimately the 0MQ situation will not happen again.

Ultimately, this issue will be brought up at the next meeting.

Keep hacking around things or dump stuff for things that are easier

This is a lot of meta-code stuff. The thing that was salient to me was the doxygen-compatible approach, which would allow newcomers to the code to become acquainted more efficiently.

Thanks!

fluffypony extends his gratitude to all contributors, and everyone makes their way to the reception hall for bacon wrapped shrimp, pigs in blankets, and all other sorts of tiny foods that hover on discs.

Logs

<fluffypony> who are we missing
<fluffypony> tewinget / othe / warptangent / NoodleDoodle you guys around?
<warptangent> ^
<fluffypony> hokay
<dEBRUYNE> smooth?
<fluffypony> smooth and luigi1111w are around
<fluffypony> although luigi1111w is using some other nick
<fluffypony> luigi1112 I think
<luigi1114> 4
<moneromooo> mario1114
<fluffypony> lol
<fluffypony> about a year ago we did this using TeamSpeak
<fluffypony> I mean Mumble
<luigi1114> for you guys
<fluffypony> which was nice, but it isn't as fluid as typing because sometimes you can't hear that someone else is talking
<binaryFate> Firechat? Was cool
<fluffypony> binaryFate: no we did a couple of actual dev meetings
<fluffypony> but it's tough to sustain
<binaryFate> Oh ok
<xmrpromotions> I think typing is fine too.
<ArticMine> This is fine
<fluffypony> agreed
<fluffypony> plus there are people working on Monero that would prefer not to have to use a voice changer just to participate :-P
<fluffypony> ok so there are a few things on the agenda
<luigi1111> I'm sick so my voice is already changed
<warptangent> the format seems to have been working well for kovri too
<fluffypony> the first thing I think we should discuss is the dev branch
<fluffypony> we've fallen back into the habit of merging stuff to master
<moneromooo> That's because bugs
<fluffypony> I know
<fluffypony> we're going to have to do a point release to fix the v1/v2 / stuck transactions bugs
<fluffypony> are there any bug fixes waiting in the wings, or should we do that next week?
<moneromooo> That last commit thing, which I'll have to think about a bit more.
<moneromooo> Also, possibly merging the per-tx bits in lmdb.
<hyc> which?
<moneromooo> tx*{unlocks,heights,outputs}
<hyc> ah
<moneromooo> And output*{keys,amounts,indices,txs}
<hyc> DB format change, I don't think that's a bug-fix
<moneromooo> Way more of htose than blocks
<fluffypony> maybe we need to consider a more generalised approach to format changes
<fluffypony> something like Laravel's migrations
<fluffypony> it'll have to be per-DB-format anyway
<fluffypony> per-DB-type I mean
<warptangent> i've got schema changes i've been using for a couple months, for better use on hdd, but they aren't bug fixes.
<warptangent> two sets of bug fixes not yet added though
<fluffypony> ok if they're not considered crucial for 0.9.x then we can put them into dev?
<hyc> warptangent: since I've been working on the same thing, I guess I should take a look at your stuff
<warptangent> 1. berkeleydb support for importer - almost ready, some argument usage cleanup
<moneromooo> Once I re-merged then
<hyc> but I don't consider anything I'm looking at now as bug-fix
<fluffypony> (this is how we meeting https://i.imgur.com/OR5ZVoI.jpg)
<warptangent> 2. finish hf fix for importer - mostly done, pending some cleanup with bdb
<fluffypony> hokay
<hyc> (I have a wineglass here too, sadly empty)
<warptangent> hyc: yes, that would be good. i think i mentioned the tx changes last month to avoid as many subdbs with tx hash keys
<fluffypony> also I think the thing that's holding up a general move of effort to dev is that we haven't bundled CZMQ / 0MQ in source, which makes compiling a bit painful
<fluffypony> any objections to the bundling?
<luigi1111> how much of a pain is it to change formats?
<hyc> I haven't even looked at dev. no objection from me
<fluffypony> luigi1111w: mostly just requires copying data to a new table and nuking the old one
<moneromooo> Hmm. I have a few patches to czmq, to make things build.
<moneromooo> Not super sure whether it was me being dumb or not though.
<fluffypony> ok well moneromooo, maybe post-bugfix do you want to do the merge from master to dev, and then plonk those patches on?
<fluffypony> I'll get it in the source tree the meantime, and cmake-ify all of the things
<moneromooo> I'll merge yes. Then you can add zmq to the cmake stuff :P Then I'll add my patches if they're still needed.
<moneromooo> Great, ty
<fluffypony> great minds think alike
<fluffypony> ok next I'd like us to chat about a style guide
<fluffypony> we've been working on one in Kovri that we can possibly use for Monero
<fluffypony> https://github.com/monero-project/kovri/blob/master/CONTRIBUTING.md#style
<hyc> oh, I do have one outstanding - tweak to BlocchainLMDB::get_estimated_batch_size - change batch_safety_factor to get blockchain_import to succeed on 32bit
<fluffypony> not necessary to read the style guide now, just more a general sense of if everyone is comfy with a style guide, and if anyone has any particular preferences
<smooth> i have no objection to any reasonable style guide but i do object to re-styling of existing code
<moneromooo> Pages and pages of stuff ? :|
<moneromooo> I object too, if it's only restyling for the sake of it.
<fluffypony> ok so more of a restyle-as-you-go
<moneromooo> That massive reindent patch already caused me grief
<fluffypony> which is in line with our refactor-as-you-go approach
<ArticMine> Apply the style guide to new code
<smooth> imo the best policy is keep the style on small chages to existing code and new style on new code
<smooth> there is probably a gray area there
<warptangent> should we assume from this point on the code is indented like the majority of the code so far - 2 spaces, not tabs, not 4 spaces.
<hyc> agreed
<fluffypony> warptangent: that's the one area where we differ from Kovri, I'd lean towards yes
<moneromooo> I tend to keep the style of whatever I'm hacking on. And I doubt I'll read all that google style guide thing. I'd prefer we use common sense.
<warptangent> moneromooo: style on the current project though, not different styles per file, right?
<moneromooo> Whatever code I'm modifying.
<moneromooo> It causes the least problems.
<fluffypony> moneromooo: don't worry about the Google style guide, the 16 points we've put in for Kovri are more what I was referring to
<warptangent> the majority of files are one style in the codebase, with a few that became some kind of hybrid at one point
<moneromooo> Oh OK.
<moneromooo> With that out of the way...
<fluffypony> ok - everyone happy with that as a general starting point? I can dump those points in and then we can take pull requests on it if anyone wants to refine / change things
<warptangent> yes, seems good
<hyc> I would push harder on "code should go in a .cpp not .h"
<fluffypony> hyc: agreed
<fluffypony> I'll make it clearer
<fluffypony> moneromooo: did you want to raise a point, or were you saying we can move on?
<hyc> overall it looks sane to me
<moneromooo> I'm good.
<fluffypony> ok
<fluffypony> next point is also administrative in nature
<fluffypony> we'd like to adopt the Collective Code Construction Contract that 0MQ uses, as a guide for project administrators and for contributors
<fluffypony> http://rfc.zeromq.org/spec:22
<fluffypony> we can discuss it more in future, but the long and the short of it
<fluffypony> is that we merge every PR as long as it doesn't break the build
<fluffypony> if it does something bad / dangerous we can have a follow up PR to revert
<fluffypony> but the aim is to avoid PR-hell where everyone comments on a PR for days and weeks and it never gets merged
<fluffypony> because it's never "perfect"
<fluffypony> so merge, create issues on Github where something is lacking (eg. new feature, little or no tests - create issues for tests)
<moneromooo> This PR-hell problem's never happened, has it ?
<fluffypony> moneromooo: not in Monero yet, but Bitcoin is chock-full of it
<gingeropolous> ^ this is for dev branch, right?
<moneromooo> I think common sense is again a better thing than going the opposite extreme.
<fluffypony> gingeropolous: this is in general
<warptangent> i haven't read the zeromq document thoroughly, but does it leave room for the common sense aspect?
<fluffypony> moneromooo: the problem is that there are lots of nuanced situations where "common sense" isn't that common :-P
<smooth> i dont think there should be an arbitrary merge policy on master, but it is already stated by me that i dont think anything but tagged releases should go on master
<moneromooo> Well, if it's nuanced, fine.
<fluffypony> warptangent: it does, yes
<fluffypony> as explained by Pieter to binaryFate and I last year
<smooth> if the concept of only taggest releases on master is no adopted then i would oppose going even further in the other direction
<smooth> *tagged
<fluffypony> smooth: yes that's a given
<fluffypony> master represents a stable, tagged release
<fluffypony> we work in dev
<fluffypony> anyone that submits a PR to master gets it closed and asked to submit it to dev
<fluffypony> anyway what I wanted to say, is that Pieter explained that the reason that you want to merge-all-of-the-things and then revert something bad is that you have a historical record of the bad actor
<smooth> there needs to be a place for bug fix releases though
<binaryFate> I'm with you fluffypony. 0MQ founder/leader feedback on this approach was extremely valuable.
<moneromooo> There's also the potential thing about not being able to use the 0mq version in time for the next 6-month fork. It wasn't exactly usable yet last I hacked on it.
<binaryFate> Common sense might work now, long term with a higher market cap we'll face same issues as btc
<binaryFate> Where common sense diverges and the code Base ossifies
<xmrpromotions> As a non programmer smooths comment seems like the safer approach. Thank you for clarifying the master vs dev branch issue fluffy. http://rfc.zeromq.org/spec:22 sounded scary as applied to PRs sent to master before dev
<fluffypony> smooth: it doesn't preclude it
<fluffypony> moneromooo: as it stands we're probably going to push the fork date out a little to see if we have enough room to work on RingCT, so that's fine
<binaryFate> What's the envisionned time scale for ringct?
<smooth> the idea of a historical record is good
<hyc> we have similar issues with OpenLDAP - you need 3 branches
<hyc> one for dev, one for released code, and one for release bugfixes
<smooth> but i would make the case then that 0MQ should be reverted since it is unusable
<hyc> particularly when dev and release are far apart
<smooth> im not actually proposing this because i know it would be a mess, but making a point for the future
<hyc> like now, where dev has 0MQ and release doesn't
<fluffypony> smooth: I agree - moneromooo and I will play around with it next week and make a decision
<moneromooo> Reverting isn't really possible.
<fluffypony> moneromooo: we could drop dev and re-branch
<moneromooo> But one could add ringCT to a new branch based on master.
<fluffypony> if it came to that, I mean
<moneromooo> That'd be a lot of pain. I'd rather not. Much better to hack on master and merge do dev again.
<fluffypony> ok
<smooth> imo something like zeromq should be developed on a separate branch somewhere, until it is actually usable
<moneromooo> s/on master/on a branch based off master/
<fluffypony> smooth: it was usable-ish, we might have regressed some in fiddling
<moneromooo> Yes, that.
<fluffypony> anyway - let's evaluate and figure out
<moneromooo> I think I added all missing RPC so it cn be used, just not by people who want it to work without problem.
<dnaleor> <fluffypony> moneromooo: as it stands we're probably going to push the fork date out a little to see if we have enough room to work on RingCT, so that's fine <= I welcome this. Just wanted to say that imho it's important to have RingCT active in the september/october hard fork. Carry on. i'm watching
**<hyc> doing all new work in dev is fine, but backporting bugfixes to release will become non-trivial as more features are added to dev
<fluffypony> hyc: I guess it depends on the importance of a bug fix
<moneromooo> It looks to me like ring CT is going to need a lot of changes to bitmonerod/CN. September looks very close.
<fluffypony> we'll see
<fluffypony> I don't think we need to create a pressure-cooker for it
<fluffypony> ok can I go on?
<ArticMine> There are trade offs here. I see problems if dev and master deviate materially
<xmrpromotions> it seems like 3 branches as smooth mentioned would be easiest for everyone in long run even if it requires more effort now. 1.dev 3. release and bug fixes
<fluffypony> xmrpromotions: otoh we can backport fixes straight into master to allow for immediate testing by affected parties
<ArticMine> With bug fixes as a transition from dev to master
<fluffypony> again depends on the nature of the bugfix
<fluffypony> like warptangent's work on BDB and the importer probably aren't critical enough to go into master
<warptangent> the importer works properly when it has the hard fork support though, and that uses the bdb support
<moneromooo> If someone wants to rewrite that hard fork code, btw, you're welcome. I don't like it, and I'm not sure how to improve it.
<ArticMine> My concern is master deviating materially from a quasi stable dev
<fluffypony> ArticMine: something like ringct would have to be done in both master and dev
<ArticMine> So a project based on master would need a major rewrite after a tagged release
<fluffypony> we did dual-PRs for a while
<fluffypony> we can do them again
<fluffypony> might be easier than The Grand Merge
<smooth> something like ringct should only be in dev imo
<ArticMine> Yes anything fundamental has to be done in parallel
<smooth> until it gets released of course
<fluffypony> I think let's defer further discussion of this till the next meeting
<luigi1111> agreed to both
<fluffypony> we don't have enough info on the ringct effort or on the state of the dev branch right now anyway
<binaryFate> One thing I miss in discussion is what is master purpose? Do we want to encourage users to compile from it? How is master gonna diverge from tag release between them?
<ArticMine> I agree and lets carefully review the zeromq rfc in the meantime
<moneromooo> I think large things should go to their own branch (ie, ringct). Smaller things can share branches (to dev). Both end up being merged to master when ready.
<fluffypony> binaryFate: no matter what we say people clone and build master
**<gingeropolous>** **<- this guy
<fluffypony> it doesn't matter how much we encourage building a tagged release
<fluffypony> so we made a decision ages ago that master would be stable
<fluffypony> so that anyone pulling and building master doesn't get some hacky, broken branch
<binaryFate> Ok
<fluffypony> moneromooo: I don't know if we want topic branches in the main repo, but perhaps a more generalised "staging" branch, as long as anything going to that is also PRd to dev
<moneromooo> It can be in any repo.
<smooth> i think not in the main repo is fine
<moneromooo> Like I was hacking on tewinget's branch for a while.
<fluffypony> yeah that's a good point
<luigi1111> +1
<fluffypony> as long as that person is around and accepting PRs it's perfect
<warptangent> then one big PR to dev when it's ready?
<moneromooo> If we go to a dev/master setup, how does dev get merged to master anyway ?
<warptangent> that has worked before, yes
<hyc> yeah, keep main repo relatively clean
<luigi1111> a new feature can get a sort of "lead dev"
<fluffypony> moneromooo: when we release we merge from dev to master and tag master
<luigi1111> and contributers can hack on his repo
<moneromooo> So master becomes a copy of dev at that point ?
<fluffypony> yes
<ArticMine> Yes but a six month cycle could be too long
<smooth> thats a different issue
<smooth> how often to have major releases
<fluffypony> we can do major releases whenever, as long as we have major fork releases every 6 months
<smooth> also are releases time based or feature based
<luigi1111> kinda both ?
<fluffypony> yeah both
<hyc> feature-based is all that makes sense to me
<ArticMine> The merge to master may need to be more frequent than major fork releases
<moneromooo> feature based, but the rolling hard fork also pulls time based I think.
<fluffypony> yes
<binaryFate> Those Dev -> Master merges would happen with what kind of tagging? Point fix? Even more frequent?
<fluffypony> binaryFate: depends on how stable dev is
<luigi1111> so new features thus shouldn't be in dev until they are working properly/ready for release
<luigi1111> because of timed releases
<smooth> time based means that if you have 6 features in progress and one doesn't work in time, you do the release anyway, without the unfinished feture
<fluffypony> smooth, luigi1111: yes, you're both right
<luigi1111> it works as long as the half finished feature isn't partially merged
<luigi1111> or whatever
<fluffypony> the only reason 0MQ got pushed to dev anyway was because oranjuice could no longer work on it, and it was basically done
<fluffypony> but I think let's make it the last time that happens
<fluffypony> then we avoid complication
<warptangent> ok
<moneromooo> tbh I'd be tempted to not really care about people building master. If it's said clearly to use a release if you don't know what you're doing, then it's your problem.
<smooth> i agree with ArticMine that we can have releases sooner than 6 months
<gingeropolous> ah ok. so how the 0MQ happened is not how it will be in future
<binaryFate> Agree with moneromooo
<fluffypony> ok guys we're running overtime, so let's drop this for now, we can pick it up again later
<smooth> i think it is simply unnecessary to merge to master
<smooth> er sorry, commit unreleased stuff to master
<moneromooo> I think one of the problems with 0mq is that oranjuice kinda left
<smooth> any developer can handle getting the latest stuff from someone ele
**<smooth>** *somewhere else
<moneromooo> So it jsut had to be merged
<ArticMine> Let get back to this question at the next meeting
<fluffypony> ok
<fluffypony> last two things
<smooth> yup
<fluffypony> the first is that we have some major efforts coming up, besides ringCT, and things like epee, the 3 (THREE!!!) different logging systems, and a bunch of unused stuff is going to get in the way
<fluffypony> I'd like us to decide whether we want to keep hacking around things
<moneromooo> Does epee really get in the way ?
<fluffypony> or if we want to spend the effort now dumping this stuff for things that are easier
<hyc> it makes 32bit builds murder. but if we can abandon 32bit, that problem disappears too
<moneromooo> epee does ?
<hyc> yeah
<fluffypony> moneromooo: yes it does; it made QoS an absolute nightmare to do
<fluffypony> and it's still not done properly
<moneromooo> We'd have a replace a lot of stuff.
<ArticMine> 32bit especially on windows is going to be around for a long time
<dEBRUYNE> + TAILS
<moneromooo> And a lot of somewhat low level stuff.
<warptangent> the multiple logging systems situation is strange, but i don't think it's interfered with current work. is there any knowledge on rfree's likelihood of returning?
<fluffypony> warptangent: low to impossible at the moment
<fluffypony> I mean, we can rip and replace the logging stuff with boost::log
<fluffypony> all the console stuff can go ncurses or similar
<smooth> id be more in favor of specific items like that, done on feature branch
<fluffypony> and the wire protocol can go ZMTP, since we have a 0MQ dep anyway
<fluffypony> eventually we'll get to a point where we're no longer reliant on epee
<moneromooo> I agree with the bit by bit approach.
<warptangent> that sounds manageable
<fluffypony> also then we'll actually have usable Doxygen docs
<smooth> the thing to bear in mind is this has virtually zero end user benefit, if not actually zero
<fluffypony> yes
<fluffypony> on the flip side, we can plug the GUI in via 0MQ instead of monero-as-a-library
<moneromooo> Well, the benefit is said to be for 32 bit users.
<fluffypony> so we have a shortcut of sorts there
<fluffypony> (in terms of users clamouring for stuff)
<fluffypony> moneromooo: and long-term viability
<fluffypony> we've had potential contributors ask for an architectural doc for the code, and get turned off when there isn't one
<fluffypony> so there's scope to slowly bring the codebase in line
<smooth> i dont believe there is anything about the current code that precludes a GUI. After all, BBR has one with basically the same code.
<hyc> huh.. contributors that are turned off so easily ... I wouldn't expect much use out of them if they stayed
<moneromooo> I was kinda thinking that too...
<fluffypony> I guess, but tbh it does make the project seem significantly less mature
<fluffypony> which I guess is fair, it's not even 2 years old
<gingeropolous> less hurdles, more good
<smooth> it is somewhat hard to come up to speed with the code, i would agree with that
<fluffypony> alright
<fluffypony> last thing so we can wrap up
<fluffypony> I just wanted to deeply thank everyone who has contributed and who continues to contribute to Monero development, whether it is Monero's core, the website, any other peripheral projects
<fluffypony> both on behalf of the core team, and on behalf of the community
<fluffypony> you all do an amazing job, and we've done a truckload of work in 2014 and 2015
<fluffypony> so here's to an amazing 2016
<gingeropolous> hear hear! thank you fluffypony for herding the cats so good
<Bassica> hear hear!
<xmrpromotions> thank you!
<ArticMine> Thanks for all the good work
<fluffypony> thus concludes the first meeting, next one in two weeks
<warptangent> thanks fluffypony
<luigi1111> thanks
<binaryFate> Thanks to you fluffy (enjoy that wine)! Thanks to all of you, awesome community.
<dEBRUYNE> Thanks fluffypony!
<hyc> **<glug> thanks all
<Infinite_Jest> is there a buffet?
<fluffypony> Infinite_Jest: snacks will be served in The Grand Ballroom in 15 mins
<Infinite_Jest> ok great :) but seriously thanks!
**<cardboardoranges>** thanks fluffy

Monero Missive Special Edition - 2015 Year in Review

Wed, 10 Feb 2016 00:00:00 GMT

Hello, and welcome to a special edition of the Monero Missives: the 2015 Year in Review!

As you may know (or may not know:) we had an extremely busy January, which has led to this Missive taking its sweet time in being finalised.

State of Monero: 2015

The past year has been an interesting one for Monero. There was something of a reckoning as speculators realised that Monero was never going to be a pump-and-dump, rushing out a flashy GUI and ill-conceived features with no regard to the security of the network or the safety of our users. Those that stuck it out have seen steady, constant progress and steady, constant community growth.

Governance

Over the course of 2015 we have considered Monero's governance model. In the context of cryptocurrencies and consensus systems, the term "governance" seems to be quite taboo. However, for anyone that has ever been involved in an open-source project, a lack of governance is as good as a death knell. An excellent article on governance models is maintained by OSS Watch, and they point out the reason for this:

There are almost as many variations of open source management strategies as there are open source projects. It is therefore critical that a project clearly communicates its policies and strategies to potential users and developers of the project’s outputs. A clear governance model also allows potential contributors to understand how they should engage with the project, what is expected of them and what protections are provided to ensure that their contributions will always be available to them. In addition, it describes the quality control processes that help to assure potential users of the viability of the project. The development and communication of a clear and concise governance model is one of the most important steps a project can take towards sustainability through open development.

Of course, we are primarily talking about the governance of the open-source project (ie. the source code in the monero-project repositories and associated systems and structures). The Monero network itself cannot be governed, and as has already happened just after Monero's launch, the project can be forked and effectively taken over if the core project is no longer considered viable. If that is the case, why bother with governance at all? Over and above the reasons mentioned in the OSS Watch article, it is important to prevent a gridlock in decision making. There are going to be decisions in Monero's future that will be extremely difficult to make, and if there's no clear path as to how they can be made then the project is very unlikely to grow.

When considering a governance model for Monero our main aim has been to find a balance between pure community consensus on the one hand, and the Core Team operating as "benevolent dictators for life" on the other. Neither of these governance models are desirable on their own, but there is a mixture of the two that we feel is well-suited to Monero. It is effectively the workflow we used last year when a decision had to be made on whether or not to change Monero's emission curve (ultimately it was decided against doing so); this is the workflow for decision making:

An idea is pitched by someone, whether via a Github issue, IRC in #monero-dev, the Monero Forum, or elsewhere, and discussion ensues. The preferred forums for discussion around an idea would be as a Github issue or a Monero Forum thread.
If there are no major objections, or objections are responded to and the idea is refined accordingly, this will be deemed enough for "rough community consensus", or "lazy consensus". A good indicator of community consensus, in many instances, would be if it is an idea that requires funding, and the community successfully funds the effort.
In the event of the community being unable to reach general consensus on the matter within a reasonable period of time (typically a couple of weeks to a few months, dependent upon the complexity of the idea), the matter will be referred to the Core Team.
The Core Team will set a date for a meeting on the matter, normally to be held within a week or two. They will review all written material before the meeting.
The meeting will be held between the members of the Core Team on IRC, openly visible to the community at large, and logs will be made available after. A maximum time limit will be set for the meeting.
Members of the Core Team will be given an opportunity to state their views, vote (using the voting system detailed below), and discuss the matter at length, within the time limit of the meeting.
To conclude the meeting, the members of the Core Team will tally the votes that have been cast on the matter during the discussion and forward the decision to the community.

The Core Team, as well as individual contributors, can participate in all related discussions, but their opinions are not absolute or perfect. Community members are encouraged to test and push arguments, regardless of who is making them, until they are satisfied that the idea or change is workable or worth the risks.

The voting system that the Core Team uses is based on the CentOS voting system. Votes are not cast permanently, so a member can cast a vote at the beginning of the meeting and change it several times throughout. In order from disagreement to agreement, the following votes can be cast:

Veto vote (-1). This is generally discouraged, unless it is accompanied by substantive arguments rooted in project-relevant criteria (protecting the community, economic reasons, technical reasons)
Reservations vote (-1 or 0). Either a neutral vote, or a negative vote, coupled with reservations and concerns that are stated with the vote.
Stand aside vote (0). A neutral vote, which can be accompanied with some reservations, but which does not seek to block the vote.
Supporting vote (+1). Supports the proposal / idea / change. The voter would be expected to also indicate whether or not they will personally assist in driving the effort if successful.

In the absence of any vetoes, the votes are tallied, which gives both the result of the vote as well as an indication of the amount of support (or lack thereof). If the votes add up to a negative or positive amount then the outcome is clear. If the votes add up to 0 that is normally an indication of no support and only small reservations, in which case the matter is not blocked by the vote, but it is also not particularly supported. In this event the Core Team may choose to hold another vote, optionally at a subsequent meeting a week or two later, if the matter is such that it requires more positive support.

Our hope is that this process will prevent Monero from falling prey to "design by committee", but also prevent "design by Wikipedia" or "design by the person with the loudest mouth / most eloquent writing". This process is currently up for discussion and comment; please feel free to provide input on it.

Core Team

Due to the formalisation of the governance of the project, and the clarification of the Core Team's role as stewards, members of the Core Team are expected to be active on an ongoing basis. If a member of the Core Team cannot be regularly active, it is expected that they will step down from their role on the Core Team; the remaining members can elect to replace them if they wish.

With that in mind, two members are no longer going to form part of the Core Team due to time constraints: David Latapie and eizh. Both of them have been part of Monero since its inception and the formation of the Core Team. We are immensely grateful for their efforts in the past, and any efforts from them in the future.

We have also elected two new members to the Core Team: Franciso "ArticMine" Cabañas, and luigi1111. Francisco is based in Canada, and holds a PhD in Physics and brings extensive business and non-profit experience to the table. He has actively researched and invested in cryptocurrencies since 2011, and focuses on the economic, social, regulatory, and long-term viability aspects of cryptocurrencies. luigi1111 hails from the Midwestern United States and is a sysadmin by day. He has been actively involved in several cryptocurrencies since 2013, and loves cryptography, probability, and English grammar.

We welcome them to the Core Team, and look forward to working with them both going forward.

Finances

Our financial situation has dramatically changed with the introduction of the Forum Funding System (FFS). We still have core expenses, some of which include the servers hosting our infrastructure, our test / build hosted machines, annual domain registration for core / MoneroPulse / MoneroSeeds domains, LibSyn's hosting and syndication of our Missives podcast, CloudFlare's services, our GitHub micro plan, and so on. We are quite grateful for those that have continued to send donations to the core fund, and where possible we have also used those to kickstart Forum Funding System fundraisers.

As mentioned in 2014's Year in Review, the founding members of the Core Team all put in a large portion of funds over the course of 2014, amounting to around 164.5 BTC, when donations were scarce. At this juncture we have not sought to recover those funds, as our focus is on building Monero up, recovering our donations at some later stage, if ever.

Some highlights of the FFS over the year include:

tewinget's Documentation and Cleanup of Source Code: raised 3600 XMR in 23 contributions; completed 3/4 milestones.
moneromoo's initial fundraiser for 6 months of work: raised over its target of 7800 XMR in 45 contributions; completed all 6 milestones.
moneromoo's second fundraiser for about 10 additional months of work: raised 18000 XMR in 21 contributions; completed 3/10 milestones thus far.
Shen Noether's translation of some of the website content into Chinese: raised 950 XMR from a target of 600 XMR in 9 contributions; completed its milestone.
Shen Noether's fundraiser to complete the C++ implementation of RingCT: raised 3150 XMR in 13 contributions; has very nearly reached completion of all 7 of its milestones.
Wolf0's very efficient AMD miner: raised 7750 XMR in 20 contributions; completed 6/7 milestones.
(just sneaking a 2016 one in:) - Ilya Kitaev's initial funding to complete the Monero Core GUI: raised just over its 14000 XMR target in a matter of hours; work has just begun.

In total, excluding the GUI fundraiser, the FFS raised just over 48260 XMR over the course of 2015. Virtually all of the fundraisers were for direct open-source code development, and no payouts were made until a milestone had been met, and the community had reviewed the code and confirmed that the milestone had been achieved.

We can safely say that the FFS has been a fantastic success thus far, and we hope to see more projects being funded of a development nature, as well as of a promotional and educational nature (such as community members covering their costs if they go speak at a conference).

The FFS exists in a centralised manner today, but in the future we hope to host it in a more decentralised fashion (eg. using Tahoe-LAFS) and couple it with future systems like MoneroID and MoneroTrust.

Donation Addresses

For general housekeeping purposes we have decided to roll-over the donation addresses every so often, perhaps every year or two. Please take note of the new address details below. We have updated the donate.getmonero.org OpenAlias and other references, but pool operators and anyone else that auto-donates will need to update their systems accordingly. We will maintain the old addresses for some time, but will likely only check them sporadically and move any funds to the new addresses.

Monero Donations: 44AFFq5kSiGBoZ4NMDwYtN18obc8AemS33DBLWs3H7otXft3XjrpDtQGv7SqSsaBYBb98uNbr2VBBEt7f2wfn3RVGQBEP3A (view key: f359631075708155cc3d92a32b75a7d02a5dcf27756707b47a2b31b21c389501)
Bitcoin Donations: 1KTexdemPdxSBcG55heUuTjDRYqbC5ZL8H

Design and Development Goals

During the course of 2015 we published a set of Design and Development Goals focused not only on pure development, but also on research goals that the Monero Research Lab are pursuing. Typically the development goals are smaller, more immediate, and easier to achieve, whereas some of the research goals might not even be feasible, and others could take many years to find a suitable solution.

Nevertheless, over the course of 2015 we managed to complete 7 of the development goals and 2 of the research goals:

LMDB embedded database implementation: the Lightning Memory-Mapped Database is the brainchild of Howard Chu, who has become quite actively involved in the Monero Project. Our implementation of LMDB in Monero has led to a truly massive reduction in memory usage of the daemon, down to well under 100mb of real memory in use, whilst still remaining exceptionally performant.
Daemonize: instead of being forced to run the Monero daemon in the foreground, this effort allows for it to fork to the background, but still be able to interact with and query the daemon. On Windows computers it can even install itself as a system service.
BerkeleyDB fall-back database implementation: initially this was added as an acid test for our generic blockchain database class, but proved useful when we hit LMDB issues on 32-bit and ARM systems (subsequently resolved).
32-bit and ARM support: we lost 32-bit support when the in-RAM database started requiring more than 4gb of RAM. Thankfully, our blockchainDB work, as well as the LMDB and BDB implementations, brought this back, and allowed us to add ARM support as a bonus!
Various synchronisation improvements: thanks to a vastly improved synchronisation mechanism a brand new Monero node can completely sync up with the network from scratch in as little as 45 minutes.
ØMQ and TLS support for RPC: currently only available in the development branch, this is part of a series of underlying changes that will make Monero far more extensible and flexible in the future, and will allow for more secure integration for merchants and other developers.
Stealth & serialised payment IDs: this started off as something that had to be researched and figured out, but thanks to some clever work by luigi1111 and others this is integrated in the 0.9 codebase.
RingCT: as mentioned in Academic Research section, this goal has been achieved, and the C++ code for it is nearing completion.

In many ways Monero's long-term design goals represent a fundamental shift in focus. Monero's primary use, at this point, is as a private store of value and medium of exchange. But since Monero has a global, decentralised, censorship-resistant timestamping database, there is a world of functionality that can be bolted on top. Thus, the aim with Monero is for it to become more than just a private cryptocurrency; we want Monero to become an entire suite of easy-to-use tools and systems designed to enhance personal privacy.

Releases

During 2015 we kept our collective heads down, focusing on the gargantuan effort required to get the database implementation running smoothly and implement the MRL-0004 guidelines. This culminated in the release of Monero 0.9 Hydrogen Helix on the first day of 2016. A full list of the changes can be found on the release page: https://github.com/monero-project/bitmonero/releases/tag/v0.9.0

We'd like to extend our gratitude to the 19 contributors that invented, developed, hacked, wrote, tested, broke, fixed, and built Monero's core code over 2015: moneromooo-monero, warptangent, Thomas Winget, Riccardo Spagni, rfree, smooth, NoodleDoodle, Howard Chu, Sergey Kazenyuk, luigi1111, Shen Noether, Rostislav, Brendan Telzrow, Lex Kalinkin, sammy007, Wladimir van der Laan, David Vorick, roman, and meshpoint.

Over the year there were 904 commits made to the main Monero repository, plus quite a few more to the development branch. Using the same methodology we applied in the previous Year in Review, this means:

Statistic	2014	2015	Total
Weeks of Development	35	52	87
Days of Development	245	365	610
Commits	594	904	1498
Contributors	11	19	30
Modified Lines	10 221	5 342	15 563
New Lines	12 706	263 288	275 994
Removed Lines	32	514	546

Academic Research

The Monero Research Lab also had a busy 2015. Two main efforts were completed during the year:

MRL-0004: Improving Obfuscation in the CryptoNote Protocol - this was a major research effort that analysed the failures highlighted in MRL-0001, as well as uncovered some others, and presented a number of solutions to these. The solutions presented in MRL-0004 were incorporated in the Monero hardfork coming up in March, 2016.
MRL-0005: Ring Signature Confidential Transactions for Monero - based on the excellent work of Bitcoin Core developer, Greg Maxwell, this couples Confidential Transactions with Monero's Ring Signatures, efficiently hiding transaction values on the blockchain, and thus crossing a major privacy threshold. Once implemented this will make Monero the first cryptocurrency in production and in use that cryptographically obscures transaction values, where the transaction inputs come from, and where the transaction outputs are going to.

Kovri

One of the areas that Monero has long been focusing on is disconnecting the link between a transaction and the IP address of the node that was first observed broadcasting it, as this information often reveals the IP address of the transaction originator. Severing this link is vital, and it is not merely enough to support this functionality optionally through networks like Tor; it needs to be native and an inherent part of the Monero protocol.

With that in mind, our work with members of the I2P community has progressed from initially being involved with i2pcpp, to i2pd, and finally to an initiative from a few months ago: the Kovri I2P Router. Initially forked from a branch of i2pd, the Kovri project stands on its own in the Monero stable. It is not a mere side project, but a large fully fledged open-source project.

Nearly 2300 commits from 37 contributors have lead to just under 30000 lines of code, and the effort is ongoing. You can follow Kovri's progress on the Github repo: https://github.com/monero-project/kovri

Monero Website

At the beginning of 2015 we opened the Monero Forum. But we didn't stop there - the Monero website was also overhauled and released as a brand new site, powered by Jekyll, with a look-and-feel matching the Monero Forum. The website is open-source and can be found here: https://github.com/monero-project/monero-site

Since its inception, the Monero website has had over 320 commits from 14 contributors. The community has been fantastic at supporting the initiative and helping shape the information on the site. As we roll out new tools to make contributing to the site even easier, we can only expect this to grow.

Looking Forward: 2016

We accomplished a great deal in 2015, with ever more to do. In 2016 we are hoping to tick more items off of our Design and Development Goals, and continue the slow and steady move towards Monero becoming a privacy suite.

We hope you will continue with us on this journey, and we look forward to an excellent 2016!

Your Core Team - Riccardo "fluffypony" Spagni, luigi1111, NoodleDoodle, smooth, tacotime, Franciso "ArticMine" Cabañas, othe

Overview and Logs for the Dev Meeting Held on 2016-02-14

Sun, 14 Feb 2016 00:00:00 GMT

Summary

Review

Lots of stuff done in the past 2 weeks:

v2 block tests
flattened CMake issues (DNSSEC will work again)
the possibilities of inconstent database state and the mempool transactions "have been clobbered"

Amongst other stuff not mentioned, but copying here from moneromoos milestone work:

fixes for the wallet creating txes over max size the daemon will accept
more work on tests (including tests for the MRL-0004 changes)
going through all the V1/V2 stuff to catch what I saw was wrong
fix for txes not expiring from pool due to other nodes coming online regularly
better handling of pending/failed txes in simplewallet
new command/RPC to flush txes from the txpool
preventing two daemons from using the same data dir concurrently
more intelligent handling against duplicate outs

RingCT

Shen is almost done with reference code, volunteers needed to actually implement. warptangent takes on the db stuff.

https://github.com/ShenNoether/MiniNero/tree/master/brief

When RingCT gets merged, will be a good time to merge other database formats. DB format changes - build a converter that "upgrades" format changes. It's left open, but hyc agrees to tackle it later.

Dev Branch

This has become the bastard child of Monero development apparently. Lines 82 - 167 encompass discussion on this topic. The goal is "to merge back to the dev branch" Ultimately the decision is to hack at it for a bit and reevalauate in next meeting.

What I'll do it hack at it to make it work better, really. All that's needed is time without the problem of a release coming too quick.

Godspeed moneromooo.

Hardforks

The next fork (RingCT) will be the last time any modifications of the hardfork schedule are permitted.

Logs

<fluffypony> welcome everyone
<fluffypony> first off, thanks for being present
<fluffypony> lots has been done in the last couple of weeks
<fluffypony> moneromooo hit another milestone on his FFS fundraiser, so good job on that
<fluffypony> he also clobbered some major issues (v2 block tests etc)
<hyc> here
<fluffypony> warptangent has also been a monster in the last couple of weeks
<fluffypony> flattened CMake issues that we were struggling with
<fluffypony> so that means that our static builds now do DNSSEC resolution again, even when a local DNSSEC root key is not available
<fluffypony> (which is basically on every Windows box)
<fluffypony> which means we need to evaluate our 0.9.2 release
<fluffypony> is there anything urgent that needs to go into 0.9.2, or can we push that out?
<fluffypony> (besides open PRs, I mean)
<hyc> I've got nothing pending
<warptangent> with the updates to block handling, the possibilities of inconstent database state was addressed(block height and hf versions not matching)
<warptangent> issues there were most urgent on my mind last time
<fluffypony> yeah, that and the mempool transactions were the two biggies
<fluffypony> both have been clobbered
<warptangent> there are some bdb updates i'm finishing up, but they aren't urgent.
<fluffypony> moneromooo: anything from your side?
<moneromooo> No
<smooth> saberhagen reporting in
<fluffypony> hah hah
<warptangent> !!
<fluffypony> better late than never :-P
<warptangent> he was here two years ago. we are the ones late
<fluffypony> well apparently he was here 5 years ago :-P
<dEBRUYNE> warptangent: 2 years? Make that 4-5
<DaveyJones> 4 years please :)
<fluffypony> hah hah
<warptangent> :)
<fluffypony> ok so
<fluffypony> let's talk about RingCT
<fluffypony> shen is getting close-to-done on his reference implementation code
<fluffypony> but it requires some actual implementation, and some DB work, to actually integrate it
<fluffypony> I think someone needs to volunteer to chiefly run with that
<fluffypony> any takers?
<warptangent> i'm up for db stuff
<fluffypony> ok it's mostly in here: https://github.com/ShenNoether/MiniNero/tree/master/brief
<fluffypony> there's been some discussion in the MRL as to what is actually required
<fluffypony> I'll ask Shen to make some notes
<fluffypony> next up
<hyc> I guess that will be a good time to merge other DB format changes too
<fluffypony> yes
<fluffypony> definitely
<fluffypony> re: DB format changes, we would need to build in a converter that "upgrades" format changes
<fluffypony> I was thinking something like Laravel's migrations would work (I think I mentioned this last time)
<fluffypony> so if I'm on format v1 there are migrations in the code to v2, v3, v4, v5, and it just runs them in succession till I'm on current
<fluffypony> that way the code only actually needs to know how to interact with the latest format
<fluffypony> and the logic of getting there from any arbitrary previous version lives in migrations
<fluffypony> (that are specific to implementations)
<fluffypony> we can either generalise that, or just do that for LMDB and leave other implementations to handle it to their liking
<warptangent> yeah that sounds good, but it can get involved too, because migrations typically are run on full-featuerd dbs like postgres and mysql that cover a lot of abstractions
<warptangent> so when you change a field, it handles the data migration and protects the database consistency if it's interrupted
<fluffypony> I don't think we'd be able to handle interruptions easily
<fluffypony> maybe dump it into a temp db and then rename?
<warptangent> here, if we're transferring 3 subdbs into one consolidate subdb, for instance, if that gets interrupted, it will be some trouble to deal with resuming
<fluffypony> so that way there's no resuming, it's restarting and wiping out any existing temp dbs
<warptangent> oh that is far easier, sure
<hyc> yeah, that tells me we really just want an offline dedicated migrate tool
<warptangent> a more integrated form of export and import
<fluffypony> hyc: I thought about that, the problem is that people are going to just upgrade ->** restart the daemon
<fluffypony> and then if it chokes and says "run this tool" they'll get frustrated
<fluffypony> also we have to automate it for the GUI too because GUI users...
<moneromooo> We don't really need to bother, there's a version field.
<moneromooo> So you could create the new dbs, then set the field to new version.
<moneromooo> If it's interrupted, it will recreate the new dbs, erasing the partial ones.
<fluffypony> as long as new dbs have unique names never used in previous ones
<moneromooo> At least for the tx/block subdb work anyway.
<hyc> we can append version# to the name if we want similar names
<fluffypony> yeah
<fluffypony> ok - I'll create that as an issue, does anyone want to have it assigned to them, or should I just leave it open for now?
<smooth> is the problem that the migration can't run as a transaction because the amount of data being moved is too large?
<hyc> leave open for now, but I'll probably take it later
<hyc> smooth - yeah, pretty much
<hyc> the txn can be that large but it slows down quite a bit then
<smooth> for some migrations that should be okay though (depending on how much the format is being changed)
<hyc> and a single txn to update the entire blockchain - you lose all progress if it's interrupted. there might be a way to migrate incrementally
<hyc> so that you can resume from an interruption
<fluffypony> ok
<fluffypony> next up
<fluffypony> once 0.9.2 is tagged in the next week we have to merge back to the dev branch
<fluffypony> and then I'd like to lock down master - anything that is PR'd either needs to be dev branch only, or has to go to both (as a backport to 0.9.x)
<fluffypony> does anyone have any objections to that?
<moneromooo> When do you plan a release after 0.9.2 ?
<fluffypony> moneromooo: the next fork date is meant to be October / September, but we can be a little flexible about when we freeze the code for that release because we want it to include RingCT
<fluffypony> if that appears to be unachievable then we'll re-address it in a couple of months time
<ArticMine> So we are looking to a freeze for Ring CT in April/May?
<fluffypony> depending on how implementation goes, yes
<moneromooo> 0.9 took quite some time, dev is flaky and needs all the buffer overflows fixed at the very least before it can be put in any release.
<fluffypony> moneromooo: I know - if we need to we can push the fork date
<ArticMine> Testing?
<moneromooo> Alright then.
<fluffypony> ArticMine: you mean in terms of functional tests or automated tests?
<ArticMine> both
<xmrpromotions> what is the minumum time allowable between freeze date and fork date? I know the desire is 6 months but what is the margin of error?
<fluffypony> xmrpromotions: for planned forks, given how small Monero is, we could probably get away with a month or two
<fluffypony> but likely for the last time
<dEBRUYNE> <fluffypony> moneromooo: I know - if we need to we can push the fork date <= I am in favor of this as well
<fluffypony> it'll become harder and harder to do stuff like that, so if we're making an exception on a planned fork let's make it the last time
<dEBRUYNE> we don´t necessarily need to stick to a certain date for something that important
<dEBRUYNE> Agree fluffypony
<fluffypony> the larger issue here is that the 0MQ stuff was pushed prematurely because OranJuice couldn't work on Monero any longer
<fluffypony> in future I don't expect stuff like that will happen
<dEBRUYNE> Same issue with smart mining right?
<smooth> i still think we can consider dumping the dev branch. i think we need to be open minded about whether its state will hurt development rather than help it
<fluffypony> moneromooo is probably in the best position to make a call on that
<smooth> meaning it may be more productive to pull what we want from it (that isn't unfinished) and merge to master than vice versa
<smooth> *with master (not to master)
<moneromooo> Well, personally I'd not have a dev branch so...
<fluffypony> heh
<fluffypony> if people knew how to checkout a tag it wouldn't be a problem :)
<moneromooo> Negative reinforcement helps make that a reality :)
<smooth> i agree with not having a dev branch really but it doesn't address what to do with the code we want from te current dev branch
<hyc> right, how much in there is usable?
<moneromooo> What I'll do it hack at it to make it work better, really. All that's needed is time without the problem of a release coming too quick.
<moneromooo> It is usable, just rough.
<warptangent> are the main features in the dev branch 0mq and smart mining? wouldn't it be simpler to rebase those onto master instead of trying to merge with the current dev branch?
<fluffypony> warptangent: no smart mining, just 0mq
<warptangent> ah
<smooth> i would suggest: put 0mq back on its own branch, finish it first, then merge when it is ready
<dEBRUYNE> smooth: Isn´t 0mq the mere reason we have a dev branch currently?
<smooth> so basically merge nothing from dev right now
<fluffypony> there are some other bits and pieces on the dev branch
<fluffypony> tewinget's code comments, for eg.
<hyc> if that's the only real difference between dev and master ...
<dEBRUYNE> I see
<hyc> ah
<dEBRUYNE> fluffypony: What if contributors just worked on their own fork until it is sufficient for master?
<smooth> anyway im not saying which is more productive necessary but the question is worth asking rather than inertia
<dEBRUYNE> fork/branch
<fluffypony> dEBRUYNE: that's the way it normally works
<fluffypony> the 0MQ thing was an exception
<moneromooo> It'd also mean you get to redo the merge with all the stuff I merged recently :/
<fluffypony> oh yes
<moneromooo> And deal with that fucking white space patch AGAIN
<fluffypony> my instinct is that we've put too much effort into the dev branch already to make cherry-picking worthwhile
<fluffypony> there's a handful of merges since moneromooo's last merge to dev
<smooth> effort isnt really the right measure
<smooth> the measure is how much useful value is there
<fluffypony> well it works
<fluffypony> but there are some bugs that need to be fixed
<smooth> there has been a lot of work on master only in the past few months
<fluffypony> and we need to rip the net_skeleton stuff out and replace
<hyc> so how much effort would it be to reapply just 0mq to current master
<moneromooo> Probably a big pita. However, the original merge was also a bit crappy.
<fluffypony> last merge up to dev was Jan 3rd
<fluffypony> afaik
<moneromooo> And while I was hacking on it, thre's a fair number of changes to the 0mq stuff I made in master.
<moneromooo> Like fixes, all the missing RPC calls
<smooth> in dev?
<warptangent> 0mq in master?
<fluffypony> in dev?
<fluffypony> lol
<moneromooo> Yes, in dev
<smooth> at least people are paying attention
<warptangent> lol
<fluffypony> ok I say we hack at it for a bit
<smooth> id say be open minded about it and undertake a review
<fluffypony> and then re-evaluate
<warptangent> <fluffypony> last merge up to dev was Jan 3rd << does this also mean dev was up to date in terms of master as well?
<fluffypony> warptangent: yes that's what I mean - all of master was merged up to dev on Jan 3rd
<moneromooo> Yes. I expected we'd move to dev then.
<fluffypony> the only reason we didn't was 0.9.x fixes
<warptangent> that might not be too bad then.
<smooth> moving to dev is fine (assuming its state is good enough) but that should be independent of any necessary point releases
<fluffypony> ok - let's give it to the next meeting to reevaluate
<smooth> this is especially the case due to the premature 0mq merge
<fluffypony> speaking of the next meeting - the 28th I will be overseas, and March 6th I will be away, does anyone have an issue with us skipping the Feb 28th meeting altogether?
<dEBRUYNE> perhaps do it on another day?
<dEBRUYNE> saturday?
<ArticMine> Saturday works better for me
<hyc> Saturday is fine with me
<fluffypony> dEBRUYNE: can't do that whole weekend on the 28th, we can do March 5th but then we'd have to have a meeting the next week to be back in sync with Kovri dev meetings
<fluffypony> otherwise those of us that attend both end up with every Sunday having a block out
<dEBRUYNE> I am fine with 5 - 12 march
<dEBRUYNE> and then go on the biweekly schedule again
<dEBRUYNE> There is also the hardfork coming up on 20 March, so might be important to have at least 2 meetings before it
<fluffypony> ok - so we push the meeting till March 5th, and then the meeting thereafter will be March 14th
<hyc> 5-6 March not great for me, but that's probably not a big deal
<dEBRUYNE> 14th is a monday fluffypony
<fluffypony> sorry 13th, thanks dEBRUYNE
<dEBRUYNE> so March 5th Saturday and March 13th Sunday
<fluffypony> yes
<warptangent> that is fine here
<ArticMine> can we meet earlier on March 13th?
<fluffypony> ArticMine: Kovri meeting is at 6pm UTC, so if we meet earlier it means those of us that attend both have to block out a longer period of time
<fluffypony> I can ask to push the Kovri meeting back on that day
<fluffypony> but I know EinMByte has indicated he can't do earlier
<fluffypony> let me see what I can do in the Kovri meeting in a few minute's time
<ArticMine> It is because of the change to daylight savings time
<fluffypony> ah
<ArticMine> In the Northern hemisphere
<fluffypony> ok then the last thing, unless someone has anything to add
<dEBRUYNE> I got a general question
<fluffypony> there are open issues that are low hanging fruit, from really long ago, like #83, #84, #92
<dEBRUYNE> Is 0MQ highest priority currently? Certainly with the GUI work being done currently
<fluffypony> if you're feeling bored feel free to try knock those out, if we can keep the issues deck clean it makes it easier to maintain
<fluffypony> some are more suited to "after 0MQ", but there's others that are more general
<fluffypony> dEBRUYNE: not really, no, Ilya can only work part-time every week so it's not like the GUI is going to be done in a month
<ArticMine> I was going the raise the question of the 32 bit versions
<fluffypony> and 0MQ *works*, it just needs some bug fixing and massaging
<fluffypony> ArticMine: good point - I'd forgotten about that
<dEBRUYNE> fluffypony: As long as it doesn´t hold up the work it´s fine
<fluffypony> hyc: are you able to put together some build instructions for win32, given the issue with builds on 32-bit msys2?
<ArticMine> I have been testing 0.9.1.0-9cc8c24
<ArticMine> on XP and 7
<hyc> sure
<hyc> I already had a start at that on the reddit
<othe> ilya is working on the c++ interface currently, doesn´t really matter for the gui if its using zeromq or not
<fluffypony> btw hyc, you may find this of interest: https://github.com/niXman/mingw-builds
<dEBRUYNE> othe: Thanks for clarifying that
<bookies> are all issues on getmonero.org sorted on github? meaning I saw some that are probably old and might be resolved.
<fluffypony> bookies: you mean for the site, or for Monero itself?
<bookies> https://github.com/monero-project/monero-site
<hyc> fluffypony: heh, ok. are we going to tell people they need to build their own compiler before they can build win32?
<fluffypony> bookies: I haven't checked - there may very well be some old ones that are sorted
<bookies> ty
<smooth> <hyc> fluffypony: heh, ok. are we going to tell people they need to build their own compiler before they can build win32? <= if that is what is needed then that's what the instructions should include
<fluffypony> hyc: oh - don't they provide binaries? I thought there were
<fluffypony> may have misread
<hyc> afaics they're just build scripts for building gcc etc
<fluffypony> ah ok
<fluffypony> alright, that's our hour - anything else before we close the meeting?
<moneromooo> Shall I merge master into dev again then ?
<moneromooo> I was going to do that, but...
<fluffypony> moneromooo: yes, please
<moneromooo> kk
<xmrpromotions> will someone publish the meeting minutes like last time?
<fluffypony> yes
**<xmrpromotions>** Thank you

Overview for the Dev Meeting Held on 2016-03-05

Sat, 05 Mar 2016 00:00:00 GMT

Overview

Open pull requests mostly just DB stuff by warptangent and hyc, and will be merged within next couple of hours. In the last couple of weeks, unit test fixes, threading fixes, "lots of little things". Hyc had some readtxn changes. Hyc's performance changes need to wait until some kind of migration system is implemented / developed.

Fees are fine. Too soon for adjustment. Talk of "magic number automation" - fees will autoadjust one day! ArcticMine takes on researching / developing a proposal for automatically adjusting fees.

Dev Branch - the buck stops here. Moneromoo is waiting for 0.9.2 to be tagged "so that no new patches go there". So once we have 0.9.2, dev branch goes upstream (to master).

We need a library that plays well with HTTPS and support authentication and is compatible with our license.

RingCT - WarpTangent becoming familiar with what needs to be done, and RingCT development will go on newer database branch. There's some "floating point or fixed" issue that needs to be decided. Forum threads will be opened for that. Warptanget steps up to the plate to make the thread.

Changing mixin to something else is a thing that might happen, but "its a community thing, not a dev thing"

Everybody shakes hands, gives themselves pats on the back and "attaboys", and venture off into the night to go meditate on the metaphysics of mixin 0 transactions.

Logs

Logs for this dev meeting no longer exist or were lost.

Monero 0.9.2 Released

Wed, 16 Mar 2016 00:00:00 GMT

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

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

Overview and Logs for the Dev Meeting Held on 2016-03-19

Sat, 19 Mar 2016 00:00:00 GMT

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

Monero 0.9.3 Released

Tue, 22 Mar 2016 00:00:00 GMT

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

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

Monero 0.9.4 Released

Sat, 02 Apr 2016 00:00:00 GMT

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

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

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

Overview and Logs for the Dev Meeting Held on 2016-07-31

Sun, 31 Jul 2016 00:00:00 GMT

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.

Overview and Logs for the Dev Meeting Held on 2016-08-14

Sun, 14 Aug 2016 00:00:00 GMT

Overview

An overview can be found on Hello Monero

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

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

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

A Statement on the MWR Labs Disclosure

Wed, 21 Sep 2016 00:00:00 GMT

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, 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:

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

Wed, 14 Dec 2016 00:00:00 GMT

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

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

Monero Core GUI Beta 1 Released

Thu, 22 Dec 2016 00:00:00 GMT

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

FAQ

Can I use a remote node? This is certainly possible. In the wizard, change the daemon address from localhost:18081 to the address of the remote node. For instance, if you want to use the remote node of moneroworld.com, change localhost:18081 to node.moneroworld.com:18081. For more open node options, please check out the MoneroWorld open node directory. 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

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

Logs for the Kovri Dev Meeting Held on 2017-02-05

Sun, 05 Feb 2017 00:00:00 GMT

Logs

<anonimal> 1. Greetings
<anonimal> 2. Brief review of what's been completed since the previous meeting
<anonimal> 3. Code + ticket discussion / Q & A
<anonimal> 4. Any additional meeting items
<anonimal> 5. Confirm next meeting date/time
<anonimal> 1.
<anonimal> Hello
<i2p-relay> {-olark} greetings
<anonimal> 'Hola' as hyc would say right now
<Slack> [endogenic] Hi!
<i2p-relay> {-guzzi} hi
<meeting-bot> [i2p-relay] {-ArticMine} Hi
<anonimal> 2. Brief review of what's been completed since the previous meeting
<anonimal> Our last meeting was on November 27th, 2016 so, nothing can be "brief" about a review.
<anonimal> There were holidays, etc, so there was a leave of absence but development is going strong.
<anonimal> All I can say is if anyone is really interested, we have git-log and github (kovri + meta), my fork, and https://forum.getmonero.org/9/work-in-progress/86967/anonimal-s-kovri-full-time-development-funding-thread for any TL;DR
<anonimal> I'm also have uncommitted work, finishing up the crypto impl refactor + testing for this new exception dispatcher.
<anonimal> JFTR: of the thousands of lines of code that we forked from, almost none of it handled exceptions. All this spaghetti code, and that guy did not even have a basic grasp of design with exception handling in mind. Literally, much of the core code is still stringed together with the hope that it won't fail. I hate it. It's always been like walking on glass, but a real fix will take time. So, I've started in
<anonimal> that direction at least in terms of getting exceptions handled or handled better.
<anonimal> We have two new contributors: MoroccanMalinois and Chris Barry (lazygravy), and EinMbyte and olark have returned.
<anonimal> At this point I think a Q&A for "brief review" would be best.
<hyc> that summary is pretty scary
<anonimal> lol
<anonimal> Good scary, I hope?
<hyc> ;)
<anonimal> :)
<hyc> it points in a good direction
<anonimal> Good, I hope so!
<DaveyJones> sounds like bytecoin code :D
<i2p-relay> {-olark} The i2pd situation was interesting to say the least :p
<anonimal> Or more aptly titled: "why2pd".
<Slack> [endogenic] Total kovri noob here. Not looked at the code yet. Is there any significant future use case for kovri libraries? Is it worth doing upfront? sits back down
<anonimal> Monero. That's the biggest future use-case so far.
<i2p-relay> {-olark} I would like to see a future where kovri would be the go to i2p router for implementing into applications
<i2p-relay> {-olark} Instead of tor
<i2p-relay> {-olark} blegh
<i2p-relay> {-olark} Monero obviously first though ;)
<hyc> makes sense. tor was created for the gov't after all
<i2p-relay> {-olark} Yep
<DaveyJones> if it will do good for cash/monero i guess those use cases will follow by time
<anonimal> Everyone seems to be ecstatic about libkovri but I must stress that this is a sensitive network so, the lib should be used with that in mind.
<anonimal> Tor doesn't have this issue. All that work is upon the relays.
<i2p-relay> {-olark} True
<anonimal> Simply shutting down the router when it's most convenient has a negative impact on the network and anonymity. The API needs to take this into consideration as will any applications.
<anonimal> I can get into details, not meeting worthy. endogenic I don't think I answered your question well enough, I hope I can do better after the meeting.
<anonimal> Any questions about "brief review"?
<i2p-relay> {-olark} Hang around in #kovri endogenic
<i2p-relay> {-olark} Basically we are close to nightlies right?
<anonimal> ^ #kovri-dev is more informative
<meeting-bot> [i2p-relay] {Slack} [endogenic] i’m here
<i2p-relay> {-olark} :)
<anonimal> Yes, nightlies are technically available https://build.getmonero.org/waterfall
<anonimal> but
<anonimal> pigeons and I are working out packaging details.
<i2p-relay> {-olark} ok
<anonimal> Right now they all run a hacked makeself installer. So, download -> chmod +x -> run the installer.
<anonimal> Windows requires msys2, this is silly so I think we can do a windows installer method (I posted details in the meta repo)
<i2p-relay> {-olark} nice
<meeting-bot> [EinMByte] Hi, sorry for being late
<Slack> [needmultisig90] oh its being relayed
<Slack> [needmultisig90] neat
<anonimal> needmultisig90 wants to head up the packaging front. needmultisig90: if you aren't watching the meta repo, I highly recommend that.
<Slack> [needmultisig90] link pls
<anonimal> https://github.com/monero-project/meta
<anonimal> If you review the issues, you'll see where are on packaging.
<anonimal> where we are
<Slack> [needmultisig90] Added, will do
<anonimal> I don't want to shortchange the work that's been done since the last meeting, any more Q&A before moving onto the next point?
* anonimal thinks too
<anonimal> Oh, yes, another new contributor alvinjoelsantos (I don't know if he's around)
<meeting-bot> [i2p-relay] {Slack} [needmultisig90] ajs is cool
<meeting-bot> [i2p-relay] {Slack} [needmultisig90] @ajs
<meeting-bot> [i2p-relay] {Slack} [needmultisig90] he appears to be online
<anonimal> Oh, that's ajs, excellent.
<i2p-relay> {-olark} Good to have new blood :)
<anonimal> ajs wanted to work on the website too, IIRC?
<meeting-bot> [i2p-relay] {Slack} [needmultisig90] he's working with me on /r/moneromarket
<meeting-bot> [i2p-relay] {Slack} [needmultisig90] I believe so
<meeting-bot> [i2p-relay] {Slack} [needmultisig90] he has a background in law
<anonimal> "I am the law!"
<meeting-bot> [i2p-relay] {Slack} [needmultisig90] and was working with OpenBazaar on drafting up arbitration agreements IIRC
<Slack> [jollymort] also on the monero stealth addresses script : )
<meeting-bot> [i2p-relay] {Slack} [needmultisig90] he can correct me
<anonimal> Have him take a look at /r/Kovri
<bigreddmachine> does the website exist? i'm happy to help add content and such
<anonimal> bigreddmachine: we all need to tackle fluffypony because he's been coveting the website idea since we started
<anonimal> "MY PRECIOUS!"
<meeting-bot> [fluffypony] bigreddmachine: yes
<meeting-bot> [fluffypony] I moved laptops and so now half my stuff lives on my old one
<meeting-bot> [fluffypony] I'll try consolidate and push it up this week
<bigreddmachine> okay, just wanted to make sure i hadn't missed something. i'll watch the repo - going under getmonero.org or as a separate repo/site?
<anonimal> Last call for point 2. "brief review"
<anonimal> bigreddmachine: while you're here, we did make some progress on Salti. Any news from upstream on their API?
<meeting-bot> [fluffypony] bigreddmachine: same design, new content, linked from the getmonero menu bar
<meeting-bot> [EinMByte] Progress on salti?
<anonimal> EinMByte: yes, have you read some of the conversation in the open salti issue?
<bigreddmachine> anonimal: i've been tracking the open tickets but everything got held during holidays. nothing there yet, but i might make a proof of concept for chromium if there'd be interest
<meeting-bot> [EinMByte] "some of" yes, that sounds about right
<anonimal> bigreddmachine: sounds great
<anonimal> EinMByte: most of the collaboration was in IRC, not in issue.
<bigreddmachine> it would be easy enough to port to firefox + tbb once they finish webrequests.proxy
<anonimal> bigreddmachine: will you open FFS for this? I think it's worth it.
<bigreddmachine> for the chromium part? or ff/tbb?
* anonimal shrugs
<bigreddmachine> i don't feel comfortable proposing something that at the moment isn't possible and relies on mozilla dev community before it can get started...
<anonimal> Ok
<anonimal> Chromium PoC sounds good none-the-less.
<bigreddmachine> but i will FFS it once i think it's doable
<meeting-bot> [i2p-relay] {-ArticMine} I would be careful with Chrome / Chromium since unlike Firefox there is no no option to disable DRM
<meeting-bot> [i2p-relay] {-ArticMine} The DRM could be an attack vector
<meeting-bot> [EinMByte] Anything that relies on mozilla sounds bad to me
<meeting-bot> [i2p-relay] {-ArticMine} Firefox and clones are fine
<bigreddmachine> ArticMine - DRM isn't included in chromium afaik. chromium is only open source code.
<bigreddmachine> ... at least that's always been my understanding.
<meeting-bot> [EinMByte] Firefox is fine, of course, and preferably we should use Firefox (or at least that was the initial idea)
<bigreddmachine> anyway, we can discuss details after the meeting if there's interest. don't want to hold up anonimal
<meeting-bot> [EinMByte] but relying on mozilla to move... probably not going to happen
<meeting-bot> [i2p-relay] {-ArticMine} https://bugs.chromium.org/p/chromium/issues/detail?id=686430
<pigeons> no chromium is even binary blobs download at compiletime
<meeting-bot> [i2p-relay] {-ArticMine} The DRM in Chrome is currently an issue in Chromium
<anonimal> bigreddmachine: this is technically "3. Code + ticket discussion / Q & A" so we can chrome-it-up if needed.
<anonimal> Any other comments on Salti?
<bigreddmachine> okay - maybe a chromium POC would need to stay just that, a POC, and never production.
<anonimal> Something to play with at least, I'm up for that.
<bigreddmachine> "Any other comments on Salti?" --> just that i'll keep trying webRequests.proxy
<anonimal> Ok, thank you. That sounds ideal AFAICT.
<anonimal> Onto other code + ticket discussion:
<anonimal> Since I have no questions for myself, any Q&A?
<anonimal> Open PR from guzzi, ETA for completion?
<Slack> [moroccanmalinois] hi guys, guzzi are you interested in #399 ? i may give it a shot if you are not
<anonimal> Oooo #399, my favourite.
<i2p-relay> {-guzzi} * anonimal, this week on PR
<i2p-relay> {-guzzi} * checks 399
<anonimal> moroccanmalinois: ironically, I highly encouraged guzzi to get started on that after we merged his PR.
<meeting-bot> [olark] I'll leave what I have to say for after.
<meeting-bot> [olark] Unless there are no questions people have about kovri
<anonimal> moroccanmalinois: but now that he will be funded, I would ask him to contribute partly to that and help me with many other areas instead
<Slack> [moroccanmalinois] @anonimal "easiest" one i find
<i2p-relay> {-guzzi} sounds like a plan.
<anonimal> I mean, I can't speak for either of you; please do it!
<anonimal> Ok, so moroccanmalinois is on #399 now?
<Slack> [moroccanmalinois] my pleasure if guzzi is fine with it
<meeting-bot> [EinMByte] Do we still have important SSU issues open?
<meeting-bot> [EinMByte] Might take a look in the next week
<i2p-relay> {-guzzi} but converting .jar to c is a great way to learn
<i2p-relay> {-guzzi} we an decide away from the meeting.
<anonimal> #399 is actually great for various reasons, one of which would introduce a new dev to the purpose of libkovri-client and libkovri-core
<Slack> [moroccanmalinois] cool
<anonimal> EinMByte: yes, the same ones I believe since you left though I may have resolved one or two but not closed (I don't know)
<anonimal> guzzi: we wouldn't be converting .jar to c
<anonimal> I'll give details after the meeting
<anonimal> olark did you mean monero question for after the meeting or kovri question?
<meeting-bot> [EinMByte] Alright. Might do some additional refactoring, since I never completely finished that
<i2p-relay> {-guzzi} oh i see just skimmed
<i2p-relay> {-olark} Not so much a question but a new development that pertains to both kovri and monero :)
<i2p-relay> {-olark} Something I have been thinking about while I was looking at Monero's ring signatures.
<anonimal> EinMByte: that sounds great
* anonimal will look at issue tracker after meeting
<anonimal> Ok, anymore on 3. Code + ticket discussion / Q & A ?
<anonimal> Lots of TODO's. I'm adding them like spice to bland soup.
<i2p-relay> {-olark} I'll mention it in 4.
<anonimal> Once I get these two branches merged, maybe someone can pick some of them up. We'll see.
<meeting-bot> [i2p-relay] {-ArticMine} I will bring up an item in 4
<anonimal> 30 seconds until 4.
<i2p-relay> {-guzzi} i like todos
<anonimal> 4. Any additional meeting items
<anonimal> Floodgates opened!
<anonimal> Fashion, food, travel: anything goes!
<meeting-bot> [i2p-relay] {-ArticMine} Yes https://www.myhackerhouse.com/windows_drm_vs_torbrowser/
<meeting-bot> [i2p-relay] {-ArticMine} DRM used to attack tor in Windows
<anonimal> lol
<meeting-bot> [i2p-relay] {-ArticMine} Cost to get Windows to trust this attack 10,000 USD
<anonimal> Thanks ArticMine, looks like a great read.
<anonimal> bigreddmachine: ^
<meeting-bot> [i2p-relay] {-ArticMine} Should also work against i2p
* anonimal will read more after meeting
<anonimal> fluffypony: are you gpg verifying the kovri subscription that's hosted on github?
<bigreddmachine> okay, so i'll go ahead and say that i won't officially ever support a chrome version of Salti then.
<i2p-relay> {-olark} I'll let ArticMine go first
* anonimal wanted to ask that in monero's meeting on the topic of github security
<moneromooo> "subscription" ?
<meeting-bot> [EinMByte] By the way, if anyone needs access to the salti repo, please tell me
<anonimal> moneromooo: https://github.com/monero-project/kovri/blob/master/pkg/client/address_book/hosts.txt
<meeting-bot> [i2p-relay] {-ArticMine} My take is that any browser / OS that supports DRM is vulnerable to an attack against anonymity / IP obfuscation
<meeting-bot> [EinMByte] As with many features like DRM, it's best that they're just enabled
<moneromooo> Thanks.
<meeting-bot> [EinMByte] *disabled LOL
<anonimal> lol EinMByte
<anonimal> moneromooo: the only reason I'm signing it is because fp is pulling directly from github
<meeting-bot> [i2p-relay] {-ArticMine} So i2p on such a platform may create a very dangerous sense of false security
<anonimal> ArticMine: much like anything Windows
* anonimal now windows fan
<anonimal> *not
<meeting-bot> [i2p-relay] {-ArticMine} Yes
<anonimal> olark: 10 minutes left
<anonimal> Tick tock tick tock!
<anonimal> fluffypony: in addition to my ping above, is there any kovri-related news related to your conference circuit?
<i2p-relay> {-olark} Salti is a good solution for now
<i2p-relay> {-olark} In the future we could have our own dedicated browser
<i2p-relay> {-olark} Not sure when that is viable though
<i2p-relay> {-olark} ok
<i2p-relay> {-olark} sorry got really bad tunnel lag
<i2p-relay> {-olark} I have been thinking about how LN or something similar would work with monero
<meeting-bot> [fluffypony] anonimal: just generally good chats
<meeting-bot> [fluffypony] Nothing mind blowing
<i2p-relay> {-olark} Once kovri gets implemented into nodes and wallets this opens the doors to some really great developments
<meeting-bot> [fluffypony] Some good talk on Tor failure modes
<i2p-relay> {-olark} Since we would have access to i2p for routing
<meeting-bot> [fluffypony] A few people at 33c3 said that i2p was a prescient choice
<pero> kovri - the prescient choice for online anonymity
<i2p-relay> {-olark} It would need to be a plugin for kovri
* anonimal wants Kovri's I3P technology. Trademarked, stamped, hah!
<meeting-bot> [fluffypony] Hah
<anonimal> I3P, your cover of choice.
<i2p-relay> {-olark} Could have a client tunnel for LN functionality in wallets
<i2p-relay> {-olark} Use kademlia DHT so the other "lightning" nodes know of each other
<i2p-relay> {-olark} Would be able to route around centralized troublesome nodes
<meeting-bot> [fluffypony] Can I shut meeting-bot down, anonimal
<i2p-relay> {-olark} Fixes a lot of problems the current LN development is trying to fix
<anonimal> fluffypony: 3 minutes left?
<meeting-bot> [fluffypony] Kk
<i2p-relay> {-olark} Don't need to build routing from scratch
<i2p-relay> {-olark} Anyway it is still way to early to really till this could be possible
<anonimal> olark: sounds interesting. I'd need more info to have a comment.
<Snipa> moneromooo - I'll work on the isolated testnet in a bit. I apparently need to rebuild all of my monerod's w/o libunwind, or it crashes trying to init a new blockchain. So I'll have it tested a bit later today.
<i2p-relay> {-olark} But there is good potential
* anonimal swats Snipa
<moneromooo> Cool, thanks Snipa
<anonimal> Ok, one minute left. 5. Confirm next meeting date/time
<anonimal> Same time, two weeks from now?
<bigreddmachine> february 19? i can do that
<i2p-relay> {-olark} Sounds good
<anonimal> Ok, I'll post on meta repo.
<anonimal> Thanks everyone!

Overview and Logs for the Dev Meeting Held on 2017-02-05

Sun, 05 Feb 2017 00:00:00 GMT

Overview

An overview can be found on Hello Monero.

Logs

<fluffypony> ok
<fluffypony> welcome to the 77th annual hunger games
<hyc> oof
<fluffypony> 1. greetings
<fluffypony> 2. Brief review of what's been completed since the previous meeting
<fluffypony> 3. Code + ticket discussion / Q & A
<fluffypony> 4. Any additional meeting items
<fluffypony> 5. Confirm next meeting date/time
<fluffypony> so let's start with 1
<fluffypony> hi
<pero> HOLA
<hyc> hi. I'm hyc, and I'm a monerophile
<Snipa> Morning.
<DaveyJones> ArcticMine, luigi1111, luigi1114, luigi1112, othe, hyc, smooth, jaquee, m5M400, medusa, tewinget, zone117x, dEBRUYNE, moneromooo
<i2p-relay> {-olark} greetings
<Slack> [xmr-eric] hullo
<Jaquee> hey
<DaveyJones> one question... is there free margeritas?
<anonimal> Present in Q state.
<Slack> [endogenic] * hands DaveyJones a margarita
<fluffypony> DaveyJones: of course, dev meetings are 100% serious business and you need margaritas for that
<ArticMine> greetings
<fluffypony> ok let's move on to 2
<hyc> when was the last meeting?
<DaveyJones> 2 weeks before christmas?
<fluffypony> it's been nearly 2 months since the last dev meeting because of end-of-year and me travelling etc.
<fluffypony> does anyone want to mention stuff that's been done
<meeting-bot> [EinMByte] Hi
<fluffypony> (brb hopping out of taxi)
<meeting-bot> [i2p-relay] {-anonimal} ^ FYI, monero meeting, kovri in 55 minutes.
<hyc> many many commits have been merged
<dEBRUYNE> I am here
<hyc> I will mention my own, using batched txns for node syncing, to reduce I/O demand
<meeting-bot> [EinMByte] anonimal: Oh right, should be keeping an eye on the meta repository too
<hyc> this seems to speed up syncing on HDD by 2-3x while improving stability
<Jaquee> great stuff hyc!
<anonimal> hyc: sounds tasty
<hyc> (the actual goal was to eliminate the few corruptions we've see non Windows)
<hyc> seen on
<anonimal> So the corruptions were fixed too?
<hyc> so far it appears so.
<hyc> I examined 3 corrupted Windows data.mdb files. they all had zero pages at the tail of the file
<hyc> due to not being sync'd before OS crashed
<hyc> the new code syncs more frequently, but in a background thread
<hyc> so throughput is still high because foreground doesn't have to wait for it
<hyc> but syncs are more often, to reduce the chance of unsync'd pages during a crash
<hyc> but there's no 100% guarantee there.
<anonimal> IIRC, this fix/addition was after latest point release? Was point release before or after the previous meeting?
<hyc> this is for the default "fast" mode. you can still use "safe" mode for 100% guarantee, but super-slow.
<hyc> and this is recent, merge was only a week or so ago
<anonimal> ok
<fluffypony> ok back, just got to sXpher's house
<hyc> cool. I think that's it for me.
<fluffypony> hyc: tons of commits
<hyc> yeah
<fluffypony> was fluffy blocks already merged in by the last meeting?
<anonimal> I think so?... That was before point release right?
<hyc> I thought fluffyblocks was in 0.10.1
<Jaquee> yes, pretty sure it was
<iDunk> It was
<moneromooo> I think it could be enabled on mainnet now, since testnet's not shown anything wrong with it.
<fluffypony> anonimal: I can't remember
<fluffypony> moneromooo: agreed
<Jaquee> +1
<anonimal> moneromooo's new logging implementation, this is new.
<moneromooo> Snipa: you did test it with a private testnet with only such nodes, right ?
<gingeropolous> the crazy reorgs on testnet are due to old nodes on testnet?
<fluffypony> yeah the new logging colours threw me for a loop :-P
<medusa> yes logging is new, GUi scope for next release is like this:
<medusa> extended x64 x86 linux support / cold signing / view only wallets / restore from private keys / integrated mining / better logging / daemon status button /
<medusa> +display unlock time and confirmation
<Snipa> moneromooo - No, I didn't test on a private testnet, but my personal nodes all have patches enabling it on mainnet between them, and I'm not seeing any issues with it yet.
<Snipa> All of my testnet nodes of course, have been running it as well without issues.
<moneromooo> OK, I guess my point was lost. I don't have the disk space for many blockchains to test though...
<Snipa> If I need to go setup another one, I've got enough disk space to do so. IIRC we thought it wasn't needed because all of the active testnet nodes were using it.
<fluffypony> medusa: ok great
<fluffypony> I think for future we should have a separate line item for GUI stuff
<moneromooo> My point was that I wanted to see if it worked on a network with ONLY fluffy blocks being sent.
<fluffypony> (if there is GUI stuff I mean)
<moneromooo> But it seems everyone just mentally removes the "only" word :D
<Snipa> Ah, sorry, I must of missed that. I can set that up still if it's wanted. I've got more than enough nodes to do so.
<moneromooo> That'd be great, yes.
<moneromooo> I thought you'd already done that actually.
<moneromooo> What I want to know is whether there is a failure mode when a node can't sync from a fluffy block, but gets the block anyway from another peer.
<fluffypony> can't we just make testnet fluffy blocks only?
<fluffypony> and then we test it there
<Snipa> kk, I'll go figure out how to isolate a bunch of nodes this afternoon, and setup a small network to mine on.
<moneromooo> We could.
<fluffypony> testnet seems pretty robust given the amount of stuff we've done on it
<fluffypony> lol
<medusa> Snipa: https://github.com/moneroexamples/private-testnet
<Snipa> I mean, I leave a couple hundred h/s there on my test pool. And have ~10-ish nodes up on it.
<Snipa> Oh, so I can add multiple exclusive nodes? I think that was one of the questionmarks I was running into.
<fluffypony> okyes
<fluffypony> yes
<Snipa> Good stuff, I'll go fight with that here in a bit.
<fluffypony> ok
<fluffypony> let's move on
<fluffypony> 3. Code + ticket discussion / Q & A
<fluffypony> issues on Github are starting to pile up, and I think we should get on top of that
<fluffypony> as discussed before, the lack of granularity in Github's permissions is a bit of an irritation
<fluffypony> we've discussed having a second repo with more collaborators, but I think that's going to create more confusion than anything else
<fluffypony> so my suggestion would be that we set up an issue closing bot that has collab status
<fluffypony> and then that has a list of people that can ping it to close issues
<hyc> that sounds cool
<fluffypony> I haven't had a chance to see if such a thing exists, but if not it isn't hard to write
<pero> https://github.com/foosel/GitIssueBot
<medusa> that sounds great
<fluffypony> and if we set it up to do re-labelling too
<i2p-relay> {-anonimal} How to protect from troll abuse?
<Jaquee> cool. could it handle labeling too?
<pero> cant close yet but perhaps can be extended
<moneromooo> by "list of people"
<fluffypony> anonimal: only specific people can ping it
<i2p-relay> {-anonimal} k
<medusa> a good start would be if everyone also takes care of their own issues in the meantime ( i know me included)
<fluffypony> medusa: agreed
<fluffypony> ok any Q&A items?
<moneromooo> About what ? Anything ?
<fluffypony> moneromooo: yes
<fluffypony> hi, I'm fluffypony, AMA
<pero> i'm actually curious about the status of paybee
<pero> ;p
<moneromooo> Then I'm annoyed at the merge commits, which can embed some arbitrary amount of dross, making things easy for an external attacker with access to github to slip pwnage.
<moneromooo> Does anyone know a good way to prevent those (with manual exceptions since tewinget already said he wouldn't rebase the massive 0MQ branch) ?
<fluffypony> pero: we can talk about it later
<DaveyJones> any word from tewinget? did not read a thing from him recently, regarding 0mq
<moneromooo> A git hook looks like the obvious option, though it's still vulnerable to github.
<pero> i asked him last night - sec
<fluffypony> moneromooo: you mean to merge without the merge commit?
<Jaquee> that would require a rebase by the merger?
<pero> <tewinget> <pero> very little movement on that front - the pr hasnt been touched in 2 months <--- I haven't commented on it in as much time, but I've worked on it. Not as much as I could/should have, of course, but...
<moneromooo> I'm not sure about that. AIUI, it's needed for the signatures. I'm not super knowledgeable about what that entails wrt amount of dross.
<i2p-relay> {-anonimal} fluffypony: you very recently finished your extended 1 month+ tour, can you fill us in with details of any notable experiences?
<fluffypony> moneromooo: it is needed for the signature, not everyone is signing their commits
<moneromooo> Yes, rebase would fix, but that'd need a LOT of rebases, so isn't practical.
<hyc> and cherry-picking would lose signature?
<moneromooo> cherry-pick -S resigns.
<fluffypony> it re-signs
<fluffypony> and we want to maintain author sigs where they exist
<hyc> but with picker's key, not original key?
* anonimal believes so
<moneromooo> Yes, if someone else cherry-picks, then you can't preserve sig.
<moneromooo> This massive hole just annoys me, but I'm not sure how to fix it.
<fluffypony> moneromooo: me neither
<luigi1112> are you talking about the merge commits into master or like merging instead of rebasing
<fluffypony> I don't think it's a solvable problem
<moneromooo> My automated sig checking on make thing is also vulnerable to that, since it trusts anyuthing the pony signs.
<fluffypony> luigi1112: merge commits into master
<moneromooo> Well, we can ask him to rebase, that's not hard.
<moneromooo> It is for tewinget due to the amount of stuff, but that's a special case.
<fluffypony> moneromooo: rebasing will also make it hard to use Github to track PRs, surely?
<fluffypony> rebase-only I mean
<luigi1112> so you want the maintainers merge commits to go away?
<moneromooo> I meant rebasing before PR. The merger would still do a merge commit, unfortunately.
<moneromooo> No, just yours, if you PR any. I understood fluffypony's line to mean this, maybe I misunderdtood.
<hyc> well,we can solve this but the procedure gets more awkward:
<hyc> PR author rebases before merge
<hyc> which mean merger has to contact PR author immediately before each merge
<moneromooo> Oh, I hadn't seem luigi1112's first line. Ignore my last 2 then.
<moneromooo> Yes, that's what I ment by not practical :/
<fluffypony> yeah that won't work
<fluffypony> :(
<anonimal> Question:
<fluffypony> anonimal: answer
<fluffypony> :-P
<moneromooo> I guess the best we can do it some kind of subjective "rebased not too long ago so any extra dross diff is small enough".
<DaveyJones> i know ... i know ... 42
<anonimal> Ok, two questions: is PR author out of the picture? Poof/gone?
<moneromooo> But it requires the merge to check it.
<moneromooo> anonimal: usually not, but maybe a couple days' latency. Which means the merger has all the latencies in series.
* anonimal not 100% following the problem
<anonimal> Oh, ok.
<i2p-relay> {-olark} What about hosting code on something that is under our control and not github? This would involve not using github though.
<fluffypony> moneromooo: but this is all in an effort to make sure that maintainers can't introduce extra bits in, right?
<moneromooo> I guess most of the problem is fixed by refusing any patch with irrelevant crap, with merge commits, and when they also cause more than trivial diffs in the final merge commit.
<fluffypony> olark: that's not the problem, my merge commits are GPG signed, so I'm the failure mode, not Github
<i2p-relay> {-olark} right
<anonimal> So, why not close their PR and reopen a new one with their branch merged (not rebased) to maintain original sigs?
<moneromooo> Well, maintainers and anyone who could fool the maintainer into signing a large merge.
<anonimal> If they can't keep up, then do the work for them?
<moneromooo> anonimal: I do not understand "why not close their PR and reopen a new one with their branch merged (not rebased) to maintain original sigs?"
<hyc> neither do I
<hyc> sounds to me like it would create exactly the problem we're trying to address
<hyc> PRs with irrelevant changes sliding in
<anonimal> I think I don't understand the problem, so my question doesn't make sense.
* anonimal is 25% here, preparing for kovri meeting
<fluffypony> moneromooo: otoh it's not like we have so many eyes on PRs that nothing at all could be snuck past us, so maybe we're trying to solve a problem that is ultimately a non-issue
<hyc> I think we should continue this after the meeting, probably won't solve it here.
<moneromooo> So... we're screwed alrady, might as well not care ?
<luigi1112> :-)
<fluffypony> moneromooo: yes :-P
<moneromooo> I guess it is a practical solution for now.
<moneromooo> Though, an easy win is to automatically reject any PR with a merge commit in it.
<i2p-relay> {-olark} hmm
<moneromooo> If github could be set up to reject those, that'd remove a good chunk of dross already.
<fluffypony> moneromooo: I'm happy with that - could the requester fix it by rebase + force-push ?
<moneromooo> (though still vulberable to github itself, but we said we don't care for now)
<hyc> do you have a recent example of a problematic PR?
<moneromooo> Yes. That's what I do when I fix a trivial thing in a PR of mine.
<Slack> [nanoakron] That’s what I do with mine
<hyc> and yes, I usually rebase my PRs on latest master
<fluffypony> on the topic of Github, pigeons has a Gitlab mirror running on our (Monero's) hardware, so we're reasonably resilient to weirdness
<moneromooo> Not a recent one. I found one, but it's a very odd behavior on a single VM.
<moneromooo> A mirror isn't really a good protection against this I think.
<fluffypony> ok so new rule is that people submitting PRs should be asked to rebase + force-push if a merge commit exists in their PR
<moneromooo> Yes, please. I do when I see them, but I often look just at the diffs and forget commits.
<hyc> yeah that sounds reasonable
<Jaquee> yep
<moneromooo> But it could be automated I think.
<fluffypony> I'll look to see if there's a hook
<fluffypony> would be nice to automate things like notices on buildbot failures
<moneromooo> I just saw a java jar one. Which seemed... meh.
<fluffypony> or on first-buildbot-failure
<Slack> [jollymort] i have one q: what if the price explodes again and does 10x - what to do with fees? make F0 in the dynamic fee calc 10x smaller? somehow i feel it would call for a one time 10x blocksize bump as well to keep the proportions same, otherwise we'd need huge multipliers to get to the point where increasing fee gives incentive to bump the blocks
<fluffypony> ArticMine: ^^
<ArticMine> A price increase without a corresponding increase in blocksize?
<Slack> [jollymort] yeah
<pigeons> the ircbot for buildbot can notify when a job goes success->fail
<Slack> [nanoakron] @jollymort it’s not really reasonable to ask the blockchain to care about the fiat price because that requires gameable oracles
<fluffypony> pigeons: can it notify on the PR tho?
<pigeons> yes
<fluffypony> pigeons: ok cool - let's chat about it later / tomorrow and figure out which platforms we want to target with that
<Slack> [jollymort] nanoakron i get it, but with the current set-up we decided on an arbitrary starting point
<Slack> [nanoakron] You mean 60k blocks?
<DaveyJones> also jollymort ... what is a reasonable time-frame to call sth a higher price to even justify changing F0 ?
<moneromooo> fwiw, there's so much constant failures that I ignore the buildot pings now (sorry)
<ArticMine> Over time the assumption is that price follows transaction demand. Over the short term ther may well be a delay.
<Slack> [jollymort] good point Davey... but i can imagine a scenario where we have 3$ fees for some period
<Slack> [nanoakron] @jollymort What is a $3 fee? How does the system determine that in a zero-trust manner?
<Slack> [jollymort] it doesn't
<Slack> [jollymort] maybe difficulty is a loose peg
<Slack> [nanoakron] Fees are an economic negotiation between miners and users
<ArticMine> If the price rises very fast it could happen. There is another complication factor here namely one time changes in transaction size
<Slack> [jollymort] yeah, was RCT size bump considered?
<DaveyJones> maybe if sth like the average tx over a given time period sink TOO low some kind of mechanism would detect such a behaviour and see it as too expensive TX
<ArticMine> Ultimately fees are set by the blocksize penalty / demand / base reward
<Slack> [jollymort] nanoakron i know that, but the minimum fee could become problematic in case of price bump
<Slack> [nanoakron] The sudden increase to RCT sizes should have perhaps been considered in advance. The problem is people who panicked and refused to use RCT Tx, thereby keeping an odd mix of large and small Tx in each block, preventing proper upwards adjustment in size and downwards adjustment in fee
<DaveyJones> buth my math is way to bad to give a better example :D
<Slack> [jollymort] so just changing F0 would probably be ok
<ArticMine> Yes the minimuim fee could need to be adjusted
<Slack> [nanoakron] @jollymort can you please model what you want to happen first and submit it as a post or code somewhere so it can be considered formally? A bit of academic rigour would be nice here
<ArticMine> We just had an effective increase in TX size ~10x +
<DaveyJones> without changing F0
<ArticMine> F0 was changed just before in anticipation
<DaveyJones> ah okay
<Slack> [jollymort] cool
<Slack> [jollymort] anyway, i'll do some study
<Slack> [jollymort] but just wanted to see your thoughts
<ArticMine> The relevant question is the change in RingCT Tx size and further optimizations
<Slack> [nanoakron] I’m not averse to the idea, so long as it can be justified with a nice model of the expected behaviour and consideration of the potential attack surface
<Slack> [xmr-eric] I have a question. When should the GUI come out of beta status? Because things are feeling pretty stable and the featureset seems complete to me.
<ArticMine> Since this influences blocksize and consequently fee paid
<hyc> It should be perpetually beta. It gets lonely around here without the reassuring lull of "where's the GUI" in the background
<Slack> [jollymort] i was thinking of: increase baseline block size x5 and reduce F0 with x0.2
<Slack> [jollymort] but block size is consensus so..
<moneromooo> Where's the LMDB wallet file ?
<Slack> [jollymort] needs some justifications
<DaveyJones> nanoakron like i said... maybe sth like the average tx numbers decrease drastically for a given time frame could be a trust-less way too do it... but i have no clue how to get a decent formula
<Slack> [nanoakron] Hrm...
<DaveyJones> as actual example... the price pumps and suddenly it is WAY to expensive to do any tx for the people
<Slack> [jollymort] tx numbers can be gamed
<ArticMine> jollymort there is merit to this
<Slack> [nanoakron] @hyc is it possible to auto-scan the database file if the system wants to crash? e.g. “Database corrupt after block 120842…rewinding…"
<Slack> [jollymort] x5 due to RCT size increase
<Slack> [jollymort] when the original 60kb was set, probably RCT was not in the works
<Slack> [jollymort] so it was based on TXes of 1kb
<luigi1112> yes
<ArticMine> the issue is the relative size of the tx to minim blocksize
<Slack> [jollymort] or whatever was the pre-RCT size
<luigi1112> is dev meeting over
<hyc> nanoakron: not in general. since we only keep 2 persistent versions of the DB.
<Slack> [jollymort] ArcticMine yes, that's how i see it
<hyc> nanoakron: if the OS failed to sync the previous two txns, then the corruption is uncrecoverable.
<Slack> [nanoakron] @hyc :( How about these pages of zeroes - if that’s a consistent failure mode can they be unwound?
<Slack> [nanoakron] Oh
<fluffypony> ok guys
<Slack> [jollymort] anyways, just wanted to know if anyone else thought about this; won't take any more of your time
<fluffypony> let's wrap it up
<Slack> [nanoakron] That’s all it takes?
<Slack> [nanoakron] 2 Tx
<fluffypony> Kovri meeting starting in 5 minutes
<hyc> nanoakron: yes. we could change this.
<DaveyJones> fluffypony ... AMA after the kovri meeting? :D about your journey and paybee?
<hyc> nanoakron: use a longer delay before reusing old pages.
<DaveyJones> if you got something to tell ^^
<Slack> [nanoakron] @hyc Ok. At least there’s a potential way through it.
<i2p-relay> {-olark} I opened an issue to start discussing alternatives to the ringsize increase in September 2017 that negates a lot of possible attack vectors on ring signatures and still ensure a 'true' strength of ringsize 4 at minimum for all transactions. It is here https://github.com/monero-project/monero/issues/1673 I think it requires serious consideration moving forward. I won't go too much into it and
<i2p-relay> {-olark} just let everyone read the writeup :p
<Slack> [nanoakron] @olark I’d like knaccc to contribute too with his modelling of churn
<Slack> [xmr-eric] I like the idea of a static ringsize
<Slack> [jollymort] i like the "static" proposal
<Slack> [xmr-eric] ^^
<Slack> [jollymort] and yes, also churn
<fluffypony> DaveyJones: sounds good - I've got to step out for a little bit
<Slack> [xmr-eric] No thoughts on getting GUI out of beta status, everybody
<i2p-relay> {-olark} because the current situation is... undesirable to say the least
<moneromooo> What is beta status ?
<hyc> xmr-eric: sounds like not yet.
<Jaquee> xmr-eric: i think we need one more beta release at least.
<knaccc> nanoakron kenshi84 blew some big holes in my churn suggestion btw, so my model isn't good yet.
<Slack> [nanoakron] @knaccc Ah…well, all discussion is good
<Slack> [xmr-eric] Cool
<hyc> knaccc: cool, is that written anywhere?
<Slack> [nanoakron] @xmr-eric and if you see bugs, please bring them up on github
<fluffypony> ok anonimal the floor is yours
<Slack> [jollymort] also, opened discussion on multiple PID / TX : ) https://github.com/monero-project/monero/issues/1659
<knaccc> hyc only in my IRC logs. Summary is that the churn only works if you're churning with pure ringct trees, doesn't work if there are non-ringCT transactions mixed in
<hyc> thx
<meeting-bot> [i2p-relay] {-anonimal} I have 2 minutes to prepare
<Slack> [jollymort] i thought you can't mix rct+non-rct outputs anyway
<meeting-bot> [i2p-relay] {-anonimal} 17:59 1 minute!
<Jaquee> +1 lmdb wallet
<Slack> [nanoakron] waits with bated breath
* moneromooo congratulates nanoakron for correct spelling.
<Slack> [nanoakron] :grimacing:
<anonimal> Any objections to me typing in #monero-dev?
<knaccc> jollymort it's when you mix with an output that is a ringct output but whose inputs are non ring-ct. that breaks churn
<meeting-bot> [fluffypony] none from fluffy-on-this-side either
<fluffypony> none
<hyc> no objection
<moneromooo> That wasn't sarcasm actually :D
<meeting-bot> [i2p-relay] {-ArticMine} Fine with me

Overview and Logs for the Dev Meeting Held on 2017-02-19

Sun, 19 Feb 2017 00:00:00 GMT

Logs

Monero 0.10.2 "Wolfram Warptangent" Released

Thu, 23 Feb 2017 00:00:00 GMT

Overview

This is a necessary point release of Monero v0.10 "Wolfram Warptangent", and is a strongly, strongly recommended update as it includes massive efficiency improvements to the RingCT validation code and various other necessary bug fixes.

Some highlights of this release are:

massive speed improvements to RingCT validation
cache tx hashes for failed txs with bad semantics
added an update notification / download / verification system (to be expanded to include opt-in auto-updating for unattended daemons)
initial smart mining implementation (Linux only)
improvements to IBD (initial block download) and sync speed
switched to a portable serialiser so that wallet files can be used on any operating system
added uptime to daemon status
added support for separated mempool / peer datasets for multiple nodes on the same machine (with different p2p ports)
added a change_password command to monero-wallet-cli
addes support for restoring wallets from a certain date
added mempool prioritisation of older txs
added fixes to fluffy blocks (not enabled by default on mainnet yet)
add HTTP digest authentication support to all RPC interfaces
added a connection limit for incoming connections from the same IP
switched to EasyLogging++ for logs
added a gray peerlist house keeping system
added support for multiple daemons using the same LMDB database
added additional password prompting for monero-wallet-cli actions
added additional output detail for ring output selection in monero-wallet-cli
fixed issues with wallets dealing with large reorgs
massive additions to libwallet_api for additional functions used by the GUI
removed support for BerkeleyDB, as it is now deprecated
added support for Android
added support for DragonFlyBSD
fixed armv8 build issues

Contributors for this Release

This release was the direct result of 24 people who worked, largely unpaid and altruistically, to put out 527 commits containing 21 090 new lines of code. We'd like to thank them very much for their time and effort. In no particular order they are:

Alexis Enston
luigi1111
Miguel Herranz
vdo
anonimal
kenshi84
Dan Miller
moneromooo-monero
Ashley Perpetual
fireice-uk
MoroccanMalinois
Riccardo Spagni
Timothy D. Prime
moneroexamples
Jaquee
Lee Clagett
Chris Vickio
Antonio Huete Jimenez
Howard Chu
Randi Joseph
Dion Ahmetaj
Bitcoin Error Log
iDunk5400
NanoAkron

Official Download Links

Download Hashes

If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes:

monero-win-x64-v0.10.2.0.zip, e852642c42bc9ed6a248fea0e0bb8e9e2563cdf9a4dfdd40b96226a3cadd874e
monero-win-x86-v0.10.2.0.zip, 8ac825d89f58a07be65f4f96ddd1e22ef4fb9156d28d12381ade6e3a070b18cb
monero-mac-x64-v0.10.2.0.tar.bz2, 685a0262b9add448a516baac3dc81d2dda559fdba000afcf6480e9b2dddf107b
monero-linux-x64-v0.10.2.0.tar.bz2, bf27eb173a775b62716b5fd1d1921f81c8d3b91187b190a22f2a6d82811915fd
monero-linux-x86-v0.10.2.0.tar.bz2, 5ce1475090dfc7897824de62b44771af6de395631540dee6361f0c32a82885ac
monero-linux-armv7-v0.10.2.0.tar.bz2, 173c4f481587799b0ca8947826778eae75611ef4d6bce765df5915ffa12f91b8
monero-linux-armv8-v0.10.2.0.tar.bz2, 26ad255a94d76acdce4e649d19d709181918a47df10ea9d00f9c14acf7b0129f
monero-freebsd-x64-v0.10.2.0.tar.bz2, fec177e65a07f845cbcf64b7e39de8decee9cb04bf3f603dd38cec3a363f4d90
monero-dragonflybsd-x64-v0.10.2.0.tar.bz2, 2026a36e21755f6fb3e5b644fd7e476659bf9f459030c43338994bf12ef9f79f

Monero 0.10.2.1 "Wolfram Warptangent" Released

Fri, 24 Feb 2017 00:00:00 GMT

Overview

Some highlights of this release are:

the 0.10.2.1 point release fixes two sets of RPC issues that affected the 0.10.2 point release
massive speed improvements to RingCT validation
cache tx hashes for failed txs with bad semantics
added an update notification / download / verification system (to be expanded to include opt-in auto-updating for unattended daemons)
initial smart mining implementation (Linux only)
improvements to IBD (initial block download) and sync speed
switched to a portable serialiser so that wallet files can be used on any operating system
added uptime to daemon status
added support for separated mempool / peer datasets for multiple nodes on the same machine (with different p2p ports)
added a change_password command to monero-wallet-cli
addes support for restoring wallets from a certain date
added mempool prioritisation of older txs
added fixes to fluffy blocks (not enabled by default on mainnet yet)
add HTTP digest authentication support to all RPC interfaces
added a connection limit for incoming connections from the same IP
switched to EasyLogging++ for logs
added a gray peerlist house keeping system
added support for multiple daemons using the same LMDB database
added additional password prompting for monero-wallet-cli actions
added additional output detail for ring output selection in monero-wallet-cli
fixed issues with wallets dealing with large reorgs
massive additions to libwallet_api for additional functions used by the GUI
removed support for BerkeleyDB, as it is now deprecated
added support for Android
added support for DragonFlyBSD
fixed armv8 build issues

Contributors for this Release

Alexis Enston
luigi1111
Miguel Herranz
vdo
anonimal
kenshi84
Dan Miller
moneromooo-monero
Ashley Perpetual
fireice-uk
MoroccanMalinois
Riccardo Spagni
Timothy D. Prime
moneroexamples
Jaquee
Lee Clagett
Chris Vickio
Antonio Huete Jimenez
Howard Chu
Randi Joseph
Dion Ahmetaj
Bitcoin Error Log
iDunk5400
NanoAkron

Official Download Links

Download Hashes

If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes:

monero-win-x64-v0.10.2.1.zip, 7089ea94fdb59e2c171fb5548e5d3b560057d78a29125b8fbe8c09739e95dc2f
monero-win-x86-v0.10.2.1.zip, 2d31be49a7003e66923cad41f59646d7241bfd4ec9c607dfd34e08b235b82e33
monero-mac-x64-v0.10.2.1.tar.bz2, a13299bcf11cdcaeafa0c19ef410cb27020def501345ab03a939ddcfb8a20de7
monero-linux-x64-v0.10.2.1.tar.bz2, 9edba6ca91c35c6c2eb6816f9342931c88648de5beb471943ea63d0b16c9a2e4
monero-linux-x86-v0.10.2.1.tar.bz2, 4901d2633a7bdd20504ff1b7c719ac5e9eb43a1f497103766f8333d7c18f30b5
monero-linux-armv7-v0.10.2.1.tar.bz2, ad6bccc0b738e5becc0191fea2c55529835df042919ef8df60033f8e84c28a9d
monero-linux-armv8-v0.10.2.1.tar.bz2, c0ab2be3e81e7b3928f98d84c60ac2a7f42dfd581357873a42bfcbc867a4e39a
monero-freebsd-x64-v0.10.2.1.tar.bz2, b0f0baf0947a77523a3a8c8686f645ada792fd44c6211f0c34322cfd22aab0cb
monero-dragonflybsd-x64-v0.10.2.1.tar.bz2, 7db1f37f6c59f05bf6dec65a32d6c82339fd9386805b9f04082c37c85ef1002e

A GPG-signed list of the hashes is at https://getmonero.org/downloads/hashes.txt and should be treated as canonical, with the signature checked against the appropriate GPG key in the source code (in /utils/gpg_keys)

Overview and Logs for the Dev Meeting Held on 2017-03-12

Sun, 12 Mar 2017 00:00:00 GMT

Overview

An overview can be found on MoneroBase.

Logs

<fluffypony> 1. Greetings
<fluffypony> ok cool
<fluffypony> agenda is at https://github.com/monero-project/meta/issues/51
<fluffypony> so to start, 1. Greetings
<fluffypony> hi
<iDunk> Hi
<fluffypony> 2. Brief review of what's been completed since the previous meeting
<fluffypony> so mostly fiddly bits as we get ready for the 0.10.2.2 tag and release
<fluffypony> but we'll discuss that more in 4
<fluffypony> so 3. A discussion of PR 1816, & perhaps a more general discussion of C++ templating etc.
<fluffypony> relevant link: https://github.com/monero-project/monero/pull/1816
<fluffypony> so part of the ongoing discussion happening there is "how much C++11 do we adopt"
<fluffypony> and part of the discussion I wanted to have today is "how maintainable is C++11 for us"
<moneromooo> Maybe it's a bit less about C++11 and more about making things overcomplex.
<fluffypony> yes
<moneromooo> A bit of both I guess.
<fluffypony> so if I may, I thought I'd give my largely uninformed opinion, and then I'd particularly like to hear what hyc and moneromooo and tewinget and others feel
<fluffypony> I feel that a lot of this ties into our long-term goals as developers and contributors to the Monero Project, and where we'd like to take things
<fluffypony> some of this code complexity leads to easier management later on, but requires a steep learning curve now
<hyc> I'm not up on the latest in C++. so when it comes to deciding what features to adopt, I'll stay out of it
<fluffypony> or requires things to be a little harder to manage now, but this leads to an easier to manage set of classes / functions / etc. later on
<moneromooo> Are you saying that the code being more complex makes easier to maintain later ?
<hyc> IMO though most of this stuff is complex syntax for things that have much simpler approaches already
<moneromooo> OK, I can buy that.
<binaryFate> fluffypony: "this code complexity leads to easier management later on" <-- is that true for touching part of this very code too? Seems to be the opposite
<fluffypony> but if our goal is just to "maintain" the current code base with a view to rewriting later, then obviously this is a silly exercise right now
<fluffypony> so part of this discussion really comes down to: do we, as developers, feel that we can evolve this code to a modular, manageable set of libraries and tools? or is that a pipe dream and a parallel rewrite is a better idea?
<moneromooo> I think these are separate things (or easily separatable anyway).
<moneromooo> You can do modular/manageable with simple code and complex code, and spaghetti/unminageable with simple and complex code.
<ArticMine> My question here is: Which approach is the least likely to introduce bugs?
<moneromooo> So let's do one at a time.
<endogenic> do you guys know of Rich Hickey and his view/definition of simple vs complex, easy vs difficult?
* moneromooo feels wary
<hyc> I think a parallel rewrite is the way to go. least chance of breaking the current code base.
<hyc> least intrusive overall until we have something workable on the rewrite
<fluffypony> hyc just wants to rewrite everything in C :-P
<hyc> well. yeah ;)
<fluffypony> is a rewrite too ambitious a goal? do we want resources to focus on that and the current codebase effectively plateaus?
<fluffypony> (bearing in mind that there are lots of bits we can re-use, such as vast portions of the crypto / blockchainDB stuff)
<moneromooo> I'd rewrite bit by bit, if you want to rewrite.
<hyc> good question. I tink a rewrite is low priority until the curent codebase does everything we want. i.e., multisig + kovri and whatever else
<pigeons> is vtnerd here? last week he had the most to say about c++ technique. The main concern was who else is comfortable with review
<moneromooo> Look at 0mq, which is a rewrite of just the RPC protocol. It's been a year or something.
<hyc> true
<binaryFate> I and prolly many others have no grasp of the actual usage of epee in code base. What sort of workload are we talking about to replicate?
<binaryFate> ball park
<moneromooo> Shitloads :)
<fluffypony> 0MQ's kinda a bad example, moneromooo - tewinget has had stuff on his plate that has interrupted his ability to work on Monero
<moneromooo> Besides you have to have both work in the same binary if you want to fork from one to the other at some point.
<fluffypony> but in principle, yeah, this is a multi-year project
<binaryFate> ok...
<fluffypony> moneromooo: I wonder if we couldn't pull the project in as a submodule and just reference the common files in it that we need?
<hyc> well, if someone were on it full time it wouldn't be so bad
<moneromooo> Sure, and my default view, unless proven wrong, is that it'd DoS us.
<fluffypony> pigeons: I've pinged him, but he's not here atm
<i2p-relay> {-olark} I agree with hyc. A rewrite in C should only become feasible once the current codebase is "feature-complete" kovri, multisig, 0mq etc etc
<fluffypony> olark: the opposite might be true - the more "features" we add the harder it is to rewrite
<fluffypony> what if we approached it differently
<i2p-relay> {-olark} If what is being worked on can be ported to C without technical debt that is good too.
<fluffypony> what if we have a new project whose focus is to build libraries out
<fluffypony> so maybe it starts with a consensus library that can validate txs and blocks, and knows how to build txs and blocks
<endogenic> that’s almost exactly what i was typing
<fluffypony> and then the main Monero project uses that
<hyc> sounds reasonble
<fluffypony> and eventually the project becomes a collection of files that can be dropped because they're no longer needed, and just dumb interfaces that hook into libs
<i2p-relay> {-olark} A slow transition would be ideal
<endogenic> at that point their internal implementations can be replaced with C etc right?
<ArticMine> So the rewrite is done library by library
<fluffypony> it would be massively unrestricted, since everything is created from scratch and could even have (gasp) whitespace fixes
<hyc> I was thinking about refactoring the blockchainDB stuff. it should all be hidden behind an interface class. nobody outside of blockchainDB should be including db_lmdb.h or instantiating blockchainLMDB direcftly
<fluffypony> I'm not against doing it in C, and that is super portable, but by going that low-level on everything aren't we also making it harder on ourselves?
<fluffypony> hyc: I agree with that
<endogenic> did not intend to suggest C whatsoever
<fluffypony> endogenic: too late :-P
<hyc> right, pure C is my personal goal. I wouldn't impose that on the project.
<moneromooo> tbh, the idea of spending shitloads of time and effort to replace with the same, in a way that hardforks every single part of the consensus seems outrageous. The only reason it doesn't is because the dangling prize (a nice, bug free C implementation which didn't fork) is not.
<hyc> are you saying too much risk for too little reward? or possibility of no reward?
<fluffypony> well let's be brutally honest here: we didn't write this code, and parts of it are well-written whilst others are simply not
<fluffypony> (didn't write it initially I mean)
<moneromooo> Too much risk for a reward that's not too easy to quantify.
<endogenic> we’ll prolly be well served by enumerating exactly what interfaces we would need (i.e. solutions to what problems) in the process of judging risk-reward - cause there may be low hanging but high value fruit
<fluffypony> perhaps we need to consider it this way: at what point do we NEED a massive rewrite that gets rid of all the technical debt?
<hyc> yeah, sounds like we need an actual review.
<fluffypony> like I can't imagine there still being dredges of epee in 10 year's time
<hyc> look at all of the existing code, draw high level boxes around pieces that make sense.
<binaryFate> After features required for decent growth of the ecosystem are there, imo
<hyc> then walk away, if you zoom in on the boxes again, does the layout you would reasonably expect to see match what exists.
<binaryFate> So answer depends with you would trade those efforts against
<binaryFate> what
<hyc> so the assumption is that the code we have now actually works. i.e. is solid enough to continue building on top.
<fluffypony> hyc: perhaps that answer leads us to the next point in the meeting
<fluffypony> so let's open that up so that it can form part of the discussion
<fluffypony> 4. A Series of Unfortunate Events: the v0.10.2.x release failures, massive regressions, and serious issues. How do we do better in future?
<fluffypony> given how many issues we've had with 0.10.2.x, IS the code solid enough?
<moneromooo> This whole thing is assuming that a rewrite would be bug free, which is a preposterous assumption.
<hyc> true, most ground-up rewrites are worse than what you started with
<binaryFate> issues in 0.10.2 are due to new stuff not old ones, no?
<moneromooo> We'd have to go find a list, but I think so, mostly.
<fluffypony> moneromooo: no no, not bug free, but something with a more complete test suite, and easier to review / manage
<moneromooo> Writing more tests is completely independent of rewriting.
<codehalo> i am writing a few applications in Swift, and I had to create a lot of C bindings to the C++ code.
<codehalo> It would have been so much easier if the codebase was just C...
<hyc> ^^ for cross-language portability our public APIs should be C
* fluffypony ponders
<codehalo> the Swift framework for LMDB has been easier to get up and running
<hyc> not sure how we could have tested more. the batch-txn changes had been in testing for a couple months
<fluffypony> I have a suspicion that going C-only would somewhat restrict our potential contributor base
<moneromooo> Why ?
<hyc> with several live blockchain reorgs and no problem. had no way to suspect a race condition was lurking.
<binaryFate> Surviving in C is possible for every C++ coder, but writing proper C for cryptocurrency software, not
<fluffypony> moneromooo: I know competent C++ developers who are mediocre when working solely in C
<codehalo> As hyc said, at least have a strong C api available
<fluffypony> sure
<binaryFate> You can do crazy sneaky things in C in terms of malicious commits, look at the contests for that it's fun.
<fluffypony> I agree with that
<moneromooo> C++ too...
<binaryFate> Reviewers able to catch that, you'd have way less of them than in C++
<binaryFate> moneromooo not if you expect writer to write proper C++, then it's obvious if it's going low-level unnecessarily
<moneromooo> WTF.
<moneromooo> Why are half the reasons given above completely suprious ?
<hyc> I think we need to back away from C vs C++. the codebase is primarily C++ now.
<hyc> we deal with what we have.
<endogenic> i agree. porting to C for whole codebase seems an answer in search of a problem - bound to go badly - is it an API issue? or is it a performance issue? can C by applied selectively, establishing standalone libs, while enabling us to maintain the expertise, past testing, etc of the existing codebase?
<fluffypony> moneromooo: spurious?
<endogenic> imo the biggest problem coming into monero initially for me was “how do i integrate with this?” or “what specifically do i integrate with?”
<moneromooo> Maybe not the right word, but... I feel like half the reasons for a choice given by people above either don't apply, or also apply to the other choice.
<codehalo> api issue
<moneromooo> Like, you don't need C to write tests.
<fluffypony> moneromooo: no I was asking if that's what you meant, you said "suprious" :)
<moneromooo> Or if you require "proper C++", then you should require "proper C" when comparing maintainability of both.
<moneromooo> Oh yes, spurious.
<fluffypony> well look, I'd like Monero to become a collection of well written, well documented libraries, with bindings in many languages
<hyc> yes, fine.
<endogenic> spurious arguments really get a pony going
<moneromooo> :D
<fluffypony> so the public side of the API should be C, even if the rest of the code is C++
<binaryFate> moneromooo yes and I was saying there is less people able to do that in C than in C++
<fluffypony> lol endogenic
<hyc> do we really need integration at the object code level? wouldn't most integrations be via RPC?
<fluffypony> hyc: no, not for libraries
<moneromooo> To write underhanded code ?
<endogenic> hyc: one problem i found was needing to use the wallet2.cpp code
<fluffypony> consider a client written in Go that just wants to use the consensus library
<endogenic> still have that issue - Snipa did too
<codehalo> @fluffy yes. a lot of libraries is the key
<hyc> yeah
<hyc> actually I've started writing that in C to do the LMDB version
<binaryFate> moneromooo less people to review and prevent people to write underhanded code
<fluffypony> ok so being able to hook into things at an object code level is a requirement
<fluffypony> also as an idea
<fluffypony> what if the "rewrite" / refactor / library effort happened in the source tree?
<hyc> hmmm. binaryFate - in that regard, C++ is a superset of C. so if you can't recognize underhanded code in C, you wouldn't have seen it in C++ either.
<moneromooo> Less people to review C for underhanded code, than people to review C++ for underhanded code. Assuming we require proper/nice code for both (otherwise this is a spurious argument). Maybe. It doesn't sound like a very convincing argument though.
<binaryFate> hyc for most part of the code a commiter is expected to work at a level of abstraction that is way above that of C
<hyc> fluffypony wdy mean
<moneromooo> I'd be fine with a part-by-part rewrite as we go, as I said above.
<pero> there was a discussion of c++ and crypto on hn in the last week - wondering if anyone has seen it. if not, i'll drop a link after the meeting
<fluffypony> hyc: instead of a parallel rewrite in a separate project, it can be done in the source tree in a separate directory, and can rewrite / move files into that directory, as long as references are adjusted accordingly
<fluffypony> tks pero that would be appreciated
<hyc> strikes me as being hard to coordinate, but ok
<moneromooo> I'd keep them both plugged, and fork on a height. Because they're bound to behave differently in corner cases.
<moneromooo> (for the consensus changes anyway, the rest can be changed at once I guess)
<fluffypony> moneromooo: then it may as well be done in a separate project, unless there's another reason to keep it in the source tree?
<moneromooo> Yes, because people won't exit monerod-c++ and restart monerod-c at the fork height all at once.
<bigreddmachine> doing it in the source tree... you'd have to be working on parts of the codebase that are basically set in stone at this point, or else really keeping up with codebase, no? otherwise, wouldn't it end up like some of the other things that have been worked on in a branch that then cause merging to be hell? I don't really know what I'm talking about, but that's been what it's seemed like on a few things fro
<bigreddmachine> m an outside perspective at least...
<hyc> yeah that's what I meant about tough to coordinate
<moneromooo> But maybe I missed the point you brought fluffypony ?
<fluffypony> bigreddmachine: yes it would cause merging hell, but we merge PRs quickly enough that it shouldn't be terrible
<hyc> when I've done this scale of changes on past projects, it was only after a code freeze. feature freeze.
<fluffypony> moneromooo: well I was thinking about the way we did the blockchainDB
<fluffypony> we first created this generic class
<fluffypony> and then did the LMDB implementation for that
<hyc> which is why I wouldn't bother to start here until we have kovri etc.
<pero> found it quicker than i thought i would - https://news.ycombinator.com/item?id=13807693
<fluffypony> and THEN went back and did the in-memory implementation for that class
<moneromooo> There was no fork for this, right ? People updated mostly at the same time, but with a long tail ?
<fluffypony> yes
<fluffypony> so the in-memory interface went from being the thing you use to having all its functions updated to exist behind blockchainDB
<fluffypony> which was effectively a refactor effort, more than anything else
<moneromooo> I kinda like doing it like that. Though the swapping at a fork adds security.
<fluffypony> yes 100%
<fluffypony> especially for libmonero-consensus or whatever
<hyc> ok. that sounds good for mid to long term
<hyc> what do we need to do now, for 10.2 ?
<bigreddmachine> why the need to swap at a fork? if the new implementation isn't 100% compatible, wouldn't it break on a resync when inspecting older-than-the-fork blocks? so fork or no, if there's a bug it's a mess?
<fluffypony> bigreddmachine: a corner case can come up 6 months after deployment
<fluffypony> before I get to hyc's question
<moneromooo> That seems to assume a non adversarial system.
<bigreddmachine> fluffypony: so a fork lets you make sure it's compatible for everything to date, but if a corner case came up later, the old version wouldn't matter?
<fluffypony> since vtnerd is playing around with the library stuff (conceptually), any objection to him working on this? we kinda want the library stuff for the lightweight remote wallet tool (ie. open-source MyMonero-like stuff)
<fluffypony> bigreddmachine: if you don't do it at a fork height then the old version might be widely deployed
<bigreddmachine> yep, okay makes sense, thanks
<Slack> <nanoakron> moneromooo I’m not seeing any INFO messages about ‘synchronised OK’ or ‘new block candidate’ etc. at log-level 1
<moneromooo> I'm fine with that, sure. I'd ask to not rewrite too much stuff at once, though, just because it DoSes reviewers.
<moneromooo> Especially when the code is damn hard to read/review :/
<hyc> heh
<fluffypony> moneromooo: ok agreed
<fluffypony> I'll also ask him to consider manageability / reviewability
<moneromooo> (by people who don't know much recent C++)
<moneromooo> I'm sure he can't review it quickly :P
<moneromooo> er, can.
<i2p-relay> {-JJAbr} all in Matlab, I suggest
<fluffypony> LOL
<bigreddmachine> JJAbr - I can finally review something!
<hyc> there's an LMDB driver for Matlab, fine with me :P
<moneromooo> For future things to discuss, I think it would be best if we could discuss them one at a time when they're not intertwined.
<moneromooo> Like, test coverage is unrelated to C or C++, rewrite or not.
<hyc> true
<moneromooo> Just merging them makes it harder to decide each.
<i2p-relay> {-JJAbr} I'm not joking
<hyc> I think we got sidetracked by C vs C++
<fluffypony> JJAbr: when we have more libraries then that's fully feasible
<fluffypony> moneromooo: that's fair
<i2p-relay> {-JJAbr} I'm somehow visionary, write it to Matlab, generate it into C/c++
<fluffypony> I think we should fork Rust and create our own programming language
<i2p-relay> {-JJAbr} check it with Polyspace, and it works
<fluffypony> with blackjack and hookers
<moneromooo> About tests, there's a set of functional tests that's long dead. It does transfers using wallet2 and daemon.
<moneromooo> OK, nevermind.
<i2p-relay> {-JJAbr} Visionary = see what automotive world currenty do
<i2p-relay> {-JJAbr} does
<endogenic> so confused
<hyc> automotive world writes millions of lines of code just to control an engine. that's not a good model.
<pigeons> who is working on the ethereum solidity port? :P
<endogenic> i am
<i2p-relay> {-JJAbr} "just to control an engine" = simple?
<endogenic> JJAbr: this is a dev meeting tho
<endogenic> can we chat afterwards?
<i2p-relay> {-JJAbr} you don't know what youìre talking about
<i2p-relay> {-JJAbr} anyways, sorry for the disturb
<pigeons> motion to move to next topic
<fluffypony> ok
<i2p-relay> {-JJAbr} you're talking about refactoring? do you know about what're you talking about?
<endogenic> JJAbr: yes
<endogenic> thanks
<fluffypony> 5. Code + ticket discussion / Q & A
<i2p-relay> {-JJAbr} ok
<i2p-relay> {-JJAbr} sorry to all
<fluffypony> so going back to hyc's question
<fluffypony> we're ready to tag 0.10.2.2
<fluffypony> except for the race condition stuff
<fluffypony> and I think there are two PRs that I need to merge
<fluffypony> if we get the race condition stuff done tonight then we can tag and re-start builds, finalise actual release tomorrow
<moneromooo> And a fix for the fluffy block thing smooth found earlier today.
<hyc> isn't that odd, fluffy blocks shouldn't have been live on mainnet yet
<moneromooo> Some people have been enabling it on mainnet anyway.
<hyc> ok
<moneromooo> Which, in this case, is good, because we found a couple bugs without having it fully on :P
<binaryFate> note fluffypony in front of me is busy IRL
<fluffypony> sorry about that
<fluffypony> so to move on to 6. Any additional meeting items
<Slack> <nanoakron> Hope you get to see Bruges sometime FP - lovely city
<fluffypony> does anyone have anything else to add?
<Slack> <nanoakron> Not here
<fluffypony> I think we have a fairly good idea as to how we can move forward, and also what's required for the release
<hyc> cool
<fluffypony> which brings us to 7. Confirm next meeting date/time
<Slack> <nanoakron> :)
<fluffypony> March 26th?
<fluffypony> 2 weeks from now
<moneromooo> Well, we've not talked about how to make things sturdier.
<fluffypony> well
<fluffypony> I think the current release is obviously urgent, as it fixes bugs
<moneromooo> Except when I started mentioning existing tests, but chat was spammy so got dropped.
<fluffypony> but maybe the next release we need to set some testnet time frame
<Slack> <nanoakron> What would you like to see implemented on that front moneromooo?
<fluffypony> like freeze it, and then do 4 weeks on testnet
<fluffypony> can always tag an older commit
<moneromooo> There's also a possibility to branch when doing a release, so you can cherry-pick simple fixes.
<moneromooo> That way, simple fix releases don't also come with new features that can also be buggy.
<fluffypony> as long as the version's bumped
<fluffypony> branching it for testing is not a bad idea
<moneromooo> Also, there aren't too many people on testnet, so stuff just ends up being tested on mainnet when it's released anyway (beyond obvious stuff).
<moneromooo> nanoakron: those tests aren't run, they've been disabled for a long while, I have no idea if they even work.
<moneromooo> It was already a fairly massive effort to bring all the core tests back to life...
<Slack> <nanoakron> Oh right
<Slack> <nanoakron> Eek
<moneromooo> I think 0MQ RPC tests would be nice, since everything's changed there AFAICT.
<binaryFate> Why not discuss this on a release-basis prior to release rather than fixing principles? Sometimes a long freeze may be superfluous, but for instance something touching fees and block sizes could use thoroughly-discussed different conditions on testnet
<moneromooo> Something which might be helpful is a user simulator.
<Slack> <nanoakron> Unfortunately @binaryfate the fee/block size issue, whilst it really really should be analysed and studied for a while to ensure it’s the right solution for the long run, is hindering us from growing capacity now :(
<ArticMine> But one could take a two stage approach on the fee blocksize issue
<ArticMine> A one time increase to 250000 byte min blocksize and adding the 4x fee level
<Slack> <jollymort> +1
<bigreddmachine> moneromooo: user simulator, as in something just creating random txs and such? i'm happy to make that and run on my desktop. it's already connected to testnet
<ArticMine> Then apply jollymort's proposal from 25000 to 125000 as the second stage
<huskar> moneromoo: a user simulator can be written as a system of time dependent differential equations
<moneromooo> bigreddmachine: yes, something that actually tests the testnet. Snipa has one. It's best when run on a local testnet though, so as not to spam the main one too much :)
<Slack> <nanoakron> @ArcticMine @jollymort ok :)
<pero> does testnet need nodes?
<ArticMine> This allows more careful review of 2) while addressing the immediate issue also
<Slack> <jollymort> 250kB would make a huge difference by itself; it would reduce the min.fee 4-times and reduce the size issue
<Slack> <jollymort> so you could set a x4 as the default
<Slack> <jollymort> and it would be the same old 0.3$
<Slack> <jollymort> then, the pools could use the min.fee
<bigreddmachine> i was working on a testnet faucet - it's basically done, just need to deploy - but i could easily add something that just sends out a tx or two every 5 minutes or something like that, just to create some volume
<Slack> <jollymort> and normal users the x4 fee
<Slack> <jollymort> so normal users never wait
<Slack> <jollymort> and pool payments sit in the mempool until regular users clear out
<ArticMine> Without an increase in the default fee
<Slack> <nanoakron> What we don’t want is to be stuck in some philosophical rut like a certain other cryptocurrency…we need agreement (which I’m pretty sure we all have) that an algorithmic determination of block size is better than a human one
<Slack> <jollymort> we have that, but we made a unintended anomaly
<Slack> <jollymort> exibit: https://raw.githubusercontent.com/JollyMort/monero-research/master/Monero%20Dynamic%20Block%20Size%20and%20Dynamic%20Minimum%20Fee/Images/Fig3.1-7.png
<Slack> <jollymort> no wait, wrong chart
<ArticMine> an increase in tx size to ~13000 bytes from ~500 bytes
<Slack> <nanoakron> Yes, and a binomial distribution thereof
<Slack> <jollymort> this one: https://raw.githubusercontent.com/JollyMort/monero-research/master/Monero%20Dynamic%20Block%20Size%20and%20Dynamic%20Minimum%20Fee/Images/Fig3.1-6.png
<Slack> <jollymort> the spike was introduced solely by RCT
<Snipa> The user simulator I have isn't particularly complex. I may see about writing a more complex one in the future if it's something we need.
<Slack> <jollymort> the green one was pre-RCT
<moneromooo> Dunno if we need more complex for now. Yours did find bugs already :)
<Slack> <jollymort> with 250kB that spike would surely be less severe
<ArticMine> That is why I propose the two stage approach
<Slack> <jollymort> i can draw the charts if you want
<Slack> <jollymort> make it part of the paper, too
<fluffypony> can we formally end the meeting and take meeting bot offline?
<fluffypony> we're getting out of meeting stuff anyway
<ArticMine> Sure

Logs for the Kovri Dev Meeting Held on 2017-03-26

Sun, 26 Mar 2017 00:00:00 GMT

Logs

<anonimal> 1. Greetings
<anonimal> 2. Brief review of what's been completed since the previous meeting
<i2p-relay> {-vtnerd} oh I guess there is one more thing. the backend was going to hopefully push updates to connected clients
<anonimal> 3. Monero HackerOne Bounty https://www.reddit.com/r/Monero/comments/5zmywx/monero_bounty_for_hackerone/
<i2p-relay> {-fluffypony} ok anonimal, all yours
<anonimal> 3. Code + ticket discussion / Q & A
<anonimal> 4. Any additional meeting items
<anonimal> 5. Confirm next meeting date/time
<anonimal> Greetings.
<samsunggalaxyplayer> hey!
<guzzi> Hi
<i2p-relay> {-olark} o/
<guzzi> Sweet olark
<i2p-relay> {-olark} Yeah I missed the monero meeting unfortunately :/
<i2p-relay> {-olark} I'll read the logs
<guzzi> Really good meeting
<anonimal> On topic please
<anonimal> 2. Brief review of what's been completed since the previous meeting
<anonimal> https://forum.getmonero.org/9/work-in-progress/86967/anonimal-s-kovri-full-time-development-funding-thread?page=&noscroll=1#post-90733
<anonimal> ^ for a summary on my part
<anonimal> moroccanmalinois has done some great work since the previous meeting. We have a new utility binary with multiple features. He's also done work elsewhere in the codebase.
<moroccanmalinois> :)
<anonimal> guzzi has also contributed to the utility binary. guzzi can you link to your FFS if you're doing work summaries/reports?
<moneromooo> What does this utility binary do, in a nutshell ?
* anonimal wants to say ./kovri-util -h
<guzzi> I will add summary tonight
<guzzi> On phone
<moneromooo> OK, I'll try to pull someday and check :P
<anonimal> guzzi: then give us a tl;dr for point 2. please
<moroccanmalinois> moneromooo base32, base64, routerinfo( reads a RI file) and su3file (reads an su3file)
<moroccanmalinois> and the crypto benchmark
<guzzi> Added benchmarks to utility
<anonimal> guzzi: I already said that, didn't you do other things too? Like research, etc.?
<guzzi> Starting in on instance class refactor a d todos
<guzzi> Researched address book for possible lmdb
<guzzi> Sgould be easy
<guzzi> Should
<anonimal> What should be easy? None of that looks easy...
<anonimal> Anyway, we'll save that for later. Anything else on point 2.?
<guzzi> Relatively easy from db perspective. Difficult from kovri perspective yes
<anonimal> 3. Monero HackerOne Bounty https://www.reddit.com/r/Monero/comments/5zmywx/monero_bounty_for_hackerone/
<anonimal> fluffypony: ^ thoughts?
<i2p-relay> {-fluffypony} so my thoughts is that we should just do a general fund across all the projects
<i2p-relay> {-fluffypony} because HackerOne let's us basically apportion stuff as needed
<i2p-relay> {-fluffypony} so we don't have to give out the entire bounty for some stupid XSS attack
<anonimal> Ok. I'll have to talk with them about setting up Monero. Do we include the GUI into /monero or create /monero-gui? We can probably wrap it into /monero if needed. Do we create /monero-site ?
<i2p-relay> {-fluffypony} anonimal: everything goes under the Monero umbrella / bounty, right?
<i2p-relay> {-fluffypony} just that each actual sub project can be represented
<anonimal> I'm speaking purely about H1 accounts.
<anonimal> We do whatever we want with fund management.
<anonimal> fluffypony: it's possible but then all monero developers have access to all bug reports for all subprojects
<anonimal> So that brings up a trust issue. I'm fine with the idea but it should be mentioned.
<i2p-relay> * fluffypony ponders
<anonimal> Also I'd like to have access to the account as account holder. This is something I couldn't do if we throw into one account.
<anonimal> And whoever is the account holder for all subprojects has that responsibility. And if the single account is ever compromised...
<anonimal> In other words, it's not very decentralized in terms of who controls accounts.
<i2p-relay> {-fluffypony} anonimal: doesn't really matter if it's compromised, because there's no money there?
<anonimal> fluffypony: it's about access to reports. If we don't care about who has access to reports, then there's not much reason to use HackerOne
<i2p-relay> {-fluffypony} mooneroo: for the monero-project GitHub account the core team all have the password, because there's no easy way to share that control otherwise - could we not do the same for H1?
<anonimal> I mean, there are features/benefits, but access to vulnerabilities is a big issue.
<i2p-relay> {-fluffypony} amongst maintainers I mean
<anonimal> pinging mooneroo or moneromooo?
<anonimal> We could do that I think.
<moneromooo> Well, some members of hte monero core team are pretty much inactive AIUI. So no need to get them access to this.
<i2p-relay> {-fluffypony} whoops
<i2p-relay> {-fluffypony} I meant anonimal
<i2p-relay> {-fluffypony} sorry ignore typo
<i2p-relay> {-fluffypony} anonimal: for the monero-project GitHub account the core team all have the password, because there's no easy way to share that control otherwise - could we not do the same for H1?
<i2p-relay> {-fluffypony} moneromooo: would be among maintainers
<i2p-relay> {-fluffypony} lol
<i2p-relay> {-fluffypony} the core team have passwords for stuff like this as a fallback
<anonimal> I don't think inactive people should have access to H1. Only on a as-needed basis. Maybe when they become active again?
* moneromooo misread anonimal's ping, nevermind
<ArticMine> The drop dead theory
<i2p-relay> {-fluffypony} ^^
<i2p-relay> {-fluffypony} it's just an anti-bus factor
<i2p-relay> {-fluffypony} the main people using it would be maintainers, which are currently just me and anonimal
<moneromooo> I was given access a while back (though might have been rescinded by now).
<anonimal> No, you have access to kovri
<i2p-relay> {-fluffypony} and I don't think there's a big issue with maintainers having visibility on other reports
<anonimal> As does EinMByte but is he still alive?
<anonimal> Alright, so any other big issues with merging everything into a single account?
<anonimal> And how many subprojects do we apply this too? I can PR the VRP to all appropriate subprojects and update docs as needed.
<i2p-relay> {-fluffypony} we can always split it out later
<i2p-relay> {-fluffypony} I think the only relevant projects are: GUI, CLI, Kovri, site
<anonimal> I imagine the site and forum could gain from this too.
<i2p-relay> {-fluffypony} forum is being deprecated, so let's leave it off
<i2p-relay> {-fluffypony} but there will be some forum functionality moving into the site (FFS in particular)
<i2p-relay> {-fluffypony} so keeping the site there is necessary
<anonimal> Ok
<i2p-relay> {-fluffypony} anonimal: maybe an infrastructure one too, which is pigeons' domain?
<jacobjeweler> Nodepool code perhaps?
<moneromooo> Meh. And no real maintainer.
<jacobjeweler> Snipa's work
<i2p-relay> {-fluffypony} @JacobJeweler no, that's not a core project
<i2p-relay> {-fluffypony} external projects can do their own H1 stuff
<anonimal> fluffypony: sure, as long as we can communicate that to people e.g., use the Meta repo has a point of contact + place to post VRP etc.
<i2p-relay> {-fluffypony} I think we should come up with a paragraph for the READMEs
<anonimal> Ok. We need the VRP somewhere though. It's solid (moreso than having nothing).
<pigeons> we lost irc2p again
<i2p-relay> {-pigeons} ok i'll file a few reports as someone else for a bounty then
<i2p-relay> {-fluffypony} works here pigeons
<moneromooo> One thing also that's probably needed: a list of "this does not count". Like all that's known already.
<i2p-relay> {-pigeons} hmm yeah, just some selective drops, oh well
<moneromooo> But this is easily a bone of contention otherwise.
<anonimal> moneromooo: that's included in H1. We can incorporate that into one of the features they have.
<i2p-relay> {-fluffypony} moneromooo: agreed
<i2p-relay> {-fluffypony} every report is subjective
<anonimal> (iirc)
<anonimal> Ok, so I will contact them and move these into a single account.
<anonimal> And do all the related things necessary.
<anonimal> As for funding,
* anonimal reads backlog for fluffypony's message
<anonimal> "general fund across all projects"
<anonimal> Ok,
<anonimal> separate from the dev fund? i.e., separate address too?
<i2p-relay> {-fluffypony} this will be an FFS
<i2p-relay> {-fluffypony} just open-ended with some minimum
<anonimal> Ok, so no separate donation address. All FFS, and funds are held like the dev fund?
<anonimal> (or like any FFS project)
<i2p-relay> {-fluffypony} yes
<i2p-relay> {-olark} How much money should we aim to raise for H1?
<i2p-relay> {-olark} Assuming this will need to be replenished every now and then.
<i2p-relay> {-fluffypony} I have no idea - suggestions?
<anonimal> https://forum.getmonero.org/6/ideas/87597/monero-bounty-for-hackerone suggested 500 total for all projects
<anonimal> (500 XMR)
* anonimal checks value
<i2p-relay> {-fluffypony} olark: yes but bounties are normally denominated in USD
<i2p-relay> {-fluffypony} so potentially it wouldn't need to be replenished, or hardly
<i2p-relay> {-fluffypony} unless we have lots and lots of exploits
<anonimal> Hmmm... well, at current price, 500 seems reasonable IMHO. That could attract some serious researchers.
<anonimal> Thoughts?
<i2p-relay> {-olark} Probably easier to outline what the rewards should be for LOW, MEDIUM, and HIGH severity of vulnerabilites and then figure out how much money should be raised.
<anonimal> We don't have X thought: X being how many of Y.
<anonimal> *though
<anonimal> If we run out of the fund, we can always open a new FFS.
<i2p-relay> {-olark} 500 xmr seems like a good start anyway.
<i2p-relay> {-fluffypony} yeah let's just stick to that and see how it goes
<anonimal> Ok
<i2p-relay> {-olark} Right.
<anonimal> Awesome. Anything else on point 3.?
<i2p-relay> {-fluffypony} next?
<anonimal> Do we extend 20 minutes or are we screwed because of earlier?
<moneromooo> There are two point 3s.
<moneromooo> Extend, and whoever wants to leave leaves :)
<i2p-relay> {-fluffypony} we can extend to finish up, but let's do it ASAP so I can move on to tagging and releasing
<anonimal> lol, yes. Github turns that into 4 if I copypasta. If I get original text, it's 3.
<anonimal> 4. Code + ticket discussion / Q & A
<anonimal> Damn, well, I could easily spend 20-30 minutes on this point because we haven't had a meeting in so long.
* anonimal grabs link instead
<anonimal> Ok, here we are https://github.com/monero-project/kovri/issues?q=is%3Aopen+is%3Aissue+milestone%3A0.1.0-alpha
<moroccanmalinois> A little question about the reload : what is supposed to happen if no param changed ?
<anonimal> #187 isn't as obvious as I had hoped. I'll have to approach it differently, from the basics, and start by actually getting some unit-tests for ntcp.
<moroccanmalinois> if the user didn't specified a port, should it get a new random one ?
<anonimal> So that will be fun.
<anonimal> As for #340, #369 is moot because of the other open ticket for cutting out all unnecessary sig types,
<anonimal> #305 should actually be closed for now,
<anonimal> guzzi is working on #96. It's not mandatory for 0.1.0-alpha release so I may move it to next milestone,
<anonimal> #9 needs review and may not really be needed after all
<guzzi> I can work on those unit tests for ntcp if u want
<anonimal> No that's fine guzzi, thank you.
<anonimal> All that leaves is #46 and #362
<anonimal> ajs is on #46. He's supposed to be in talks with pigeons I think. I haven't heard from ajs in a little while though. ping ajs.
<anonimal> #362 comes at the very end once we tag. I'll throw it on AUR and away we go.
* anonimal reads moroccanmalinois's lines
<anonimal> moroccanmalinois: if no port specified in config, that would be a default option. I don't like that though.
<anonimal> What I think we should do is add a default random port to the config somehow.
<anonimal> Otherwise we jump through these kinds of hurdles. But doing that for binary releases... hmm...
<i2p-relay> {-olark} We could just set a random port when a new router context is initialized.
<anonimal> moroccanmalinois: worst case scenario, if the app is still running during restart (assuming because client and core are the only things being restarted), we reuse the previous port.
<moroccanmalinois> ok
<i2p-relay> {-olark} It currently just defaults to 0 afaik.
<anonimal> ?
<i2p-relay> {-olark} In router context.
<i2p-relay> {-olark} m_Port
<i2p-relay> {-olark} Assuming we are talking about the same thing.
<anonimal> Nope, you're not looking in the right area.
<i2p-relay> {-olark} k
<anonimal> I can explain more after the meeting. moroccanmalinois can probably too because it sounds like he understands the design as well.
<moroccanmalinois> m_Port == 0 means choose a random one. another question : i read somewhere in the java doc about a "Laptop mode", i think the pb it tries to solve is more about dynamic ips. Is it on the roadmap ?
<anonimal> Nope, not on the roadmap but it can be.
<anonimal> Just open a feature request.
<moroccanmalinois> :) ok
<pero> it was just brought to my attention yesterday? that there's a ticket for pr'ing the logo - i was under the impression that my involvement with that was done, but looks like there's some miscommunication and i can get around to that soon-ish
<anonimal> Anything else on point 4.? We don't have to rush this part if needed.
<anonimal> What/
<anonimal> ?
<anonimal> Link?
<guzzi> Learning the instance class
<pero> what what
<guzzi> Anyone apposed to creating member variables for router context and client context.
<guzzi> And giving them proper constructors
<guzzi> It was a todo to find out why they are this way currently
<anonimal> guzzi: please provide line number and file
<anonimal> pero: what's your question?
<pero> there is no question
<anonimal> guzzi: for the TODO
<anonimal> pero: there's a question mark. What is your point?
<pero> where is there a question mark
<moneromooo> After "yesterday".
<moneromooo> Looks like a typo for "".
<pero> this is ticket discussion isnt it - i was chiming in on something that was ostensibly assigned to me without my knowledge
<ajs> anonimal: pigeons said he got a server for #46, but waiting for access to move over files
<anonimal> pero: nothing was assigned to you
<anonimal> ajs: ok thanks
<pero> alright well i guess there's nothing to do then
<guzzi> Instance.cc
<guzzi> Initialize function
<guzzi> First comment inside
<guzzi> Sorry github mobile has no li e numbers
<guzzi> Line
<i2p-relay> {-fluffypony} ok maybe this discussion should happen later when you're at a computer, guzzi
<anonimal> Good idea.
<i2p-relay> {-pigeons} i'm gonna confirm some things from ya'll in a few, fqdn and git repo to pull from
<anonimal> Anything else on 4.?
<guzzi> I will comment in the pr later
<anonimal> guzzi: I know what you're talking about and see what you want, let's talk more later
<guzzi> Cool
<anonimal> 5. Any additional meeting items
<anonimal> No additional items from me afaict
<moroccanmalinois> One last question : an external app that wants to use kovri (like monero GUI), should it includes only the libs ? or it can include things from src/app ?
<anonimal> Nothing from app. I see no reason for it to include anything from app.
<anonimal> Which means we get things out of app that we need elsewhere. I wrote TODO's.
<moroccanmalinois> Perfect. thx
<anonimal> Anything else on 5.?
<moroccanmalinois> not for me
<anonimal> k
<anonimal> 30 seconds...
<anonimal> 6. Confirm next meeting date/time
<i2p-relay> {-fluffypony} 2 weeks (tm)
<anonimal> 18:00 UTC two weeks from today as usual?
<anonimal> Ok
<i2p-relay> {-fluffypony} April 9th
<anonimal> Thanks everyone

Monero 0.10.3 "Wolfram Warptangent" Released

Sat, 25 Mar 2017 00:00:00 GMT

Overview

This is a necessary point release of Monero v0.10 "Wolfram Warptangent", and it is a mandatory update due to the April 15th hard fork, which in turn has been necessitated by the unexpectedly high adoption rate of RingCT transactions necessitating a modification of the dynamic block size limiter algorithm.

In addition, this is the first version that aligns CLI and GUI tags, with the CLI being tagged and released first, and the GUI tagged and released within a few days thereafter. This will mean that some point releases in future may be forced by a need on the GUI side, where the CLI may not have substantial changes, and vice versa.

Since it has only been 30 days since the last release, this is something of a "light" update. Nonetheless, some highlights of this release are:

fixed a major bug that could lead to some peers, seemingly randomly, getting stuck at a block height and refusing to accept further blocks
monero-wallet-cli (and underlying libraries) can now work in a number of units: monero, millinero, micronero, nanop, piconero
added OpenAlias support to wallet RPC calls
fixed hardcoded seed fallback issues when DNS seeds have failed or too few seeds are returned
added an optional config file for wallets
added an additional non-interactive foreground mode for the daemon
added mnemonic wordlists for French and Dutch
per-kb fee quantized to 8 decimal places
added a password function to monero-wallet-cli to allow for a wallet password to be changed (and all files re-encrypted)
added a cache on the wallet to avoid re-scanning mempool txs already scanned
improvements to auto-update functionality, including a download-and-verify mechanism
fixes to a number of logs shown in the daemon by default
massive API changes to support new features in the GUI
as always, loads of bug fixes and performance improvements

Contributors for this Release

This release was the direct result of 24 people who worked, largely unpaid and altruistically, to put out 189 commits containing 5 705 new lines of code. We'd like to thank them very much for their time and effort. In no particular order they are:

Christoph Schnerch
Jaquee
NanoAkron
Arne Brutschy
assylias
lethos3
rockhouse
Roy Jacobs
stoffu
adot23
Riccardo "fluffypony" Spagni
Noah Watkins
Lee Clagett
xmr-eric
Howard "hyc" Chu
Derek Zhang
Gareth
Gingeropolous
darentuzi
Akademik Prokhor Zakharov
Guillaume Le Vaillant
moneromooo-monero
Miguel Herranz
kenshi84

Official Download Links

Download Hashes

If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes:

monero-win-x64-v0.10.3.0.zip, 37a57d1be81b6119ac06d3f637b4c56fc625f3e790f3491c1bdca4d62902bf13
monero-win-x86-v0.10.3.0.zip, 7f95bdcf4df232f37c450523831f36ccb9fdb2e50c1b5b0a5285d50549d273be
monero-mac-x64-v0.10.3.0.tar.bz2, 8e6170f274e69010bbe662d8828c8e4b0b4acdb0a1a3699b5b97af8c3a516a94
monero-linux-x64-v0.10.3.0.tar.bz2, f164112bea75dfd3eaaa905d21129820a996bbe6e5d65cb194609c672a71c3fe
monero-linux-x86-v0.10.3.0.tar.bz2, b8bd258b828d8ea45a7c2595187c13b5e624f45ae929cb64ac89e3a030302316
monero-linux-armv7-v0.10.3.0.tar.bz2, 03b2f3f30c7d047142cbfcd614762f3d165d64464e3e5b1a5b0c42aba9570d6a
monero-linux-armv8-v0.10.3.0.tar.bz2, 6b29c56ca8d71f23f13b68d48e39e35b1d7c7c212cf00f3d58b0d2d9b6435c4c
monero-freebsd-x64-v0.10.3.0.tar.bz2, 834b56efccc5ab0985c7f870449704ba390c79104ecfc0b63935dfb4f70c6cf9
monero-dragonflybsd-x64-v0.10.3.0.tar.bz2, 4ab5b2a745ca5ea4cad253166ff80ff60bb4871f6c8fa81ff032cdf237f6e372

Overview and Logs for the Dev Meeting Held on 2017-03-26

Sun, 26 Mar 2017 00:00:00 GMT

Overview

An overview can be found on MoneroBase.

Logs

<fluffypony> 2. Brief review of what's been completed since the previous meeting
<fluffypony> ok so since the last meeting I guess the main thing is we tagged and released 0.10.3
<fluffypony> which we're about to deprecate
<fluffypony> lol
<fluffypony> are there any issues with 0.10.3 besides the cumulative block size thing?
<fluffypony> now's the time to point them out
<hyc> no idea, but I'm running a build from a couple days ago
<Jaquee> me too. no issues so far
<johnalan> Been running on OSX since yesterday. No issue.
<fluffypony> moneromooo: any idea why the issue seems to affect so few?
<hundehausen> Smart Mining is not working for me on newest macOS
<moneromooo> Dunno. Low level processor specifics I guess, but... shrug.
<fluffypony> hundehausen: it only works on Linux
<fluffypony> not on anything else
<samsunggalaxyplayer> I have smart mining running on Windows right now
<Jaquee> yeah. windows + linux iirc
<Jaquee> but not osx i think
<luigi1112> lunch time
<fluffypony> I like to pretend that Windows doesn't exist
<fluffypony> :-P
<Jaquee> lol
<moneromooo> What is it ?
<fluffypony> moneromooo: you open them to let air in
<moneromooo> Ah, doors.
<hyc> usually lets bugs in too
<amiuhle> smaller sized doors basically
<gingeropolous> drumroll
<fluffypony> lol hyc
<btcltcxmrmaximal> winblows sucks
<hyc> windows and doors in Ireland have no screens. I dunno what's with these people.
<fluffypony> anyhoo
<fluffypony> let's move on
<fluffypony> 3. Discussion of fireice-uk's proposal (as started in #1828
<fluffypony> I'd like to move this to Funding Required
<fluffypony> and fireice-uk updated the funding costs based on current pricing
<fluffypony> obviously there are some consensus-critical aspects to it, so I think it's worth discussing
<moneromooo> Wasn't this a wallet thing ?
<btcltcxmrmaximal> https://github.com/monero-project/monero/issues/1828
<xmreric> Yes. Speedup on Intel/AMD processors, which is helpful considering RingCT has slowed sync down.
<fireice-uk> it is a wallet thing (unless you want to use it somewhere else)
<hyc> ringCT has slowed wallet sync?
<fluffypony> moneromooo: if we replace SUPERCOP then it's consensus critical
<vtnerd> I don't see how ringct slowed down wallet sync ... ?
<moneromooo> Then no consensus issue. And if it proves good for a while, then it can be used in consensus.
<pigeons> xmreric: how has ringct slowed down sync?
<xmreric> I thought I had heard that from others
<vtnerd> the additional work comes when a output match is found
<fluffypony> so I guess wallets with thousands and thousands of ringct outputs?
<xmreric> https://monero.stackexchange.com/questions/3718/when-syncing-moneros-blockchain-from-scratch-why-does-it-begin-fast-and-end-sl
<fluffypony> xmreric: that's daemon, not wallet
<fluffypony> 1828 is a proposal for a wallet change
<xmreric> ok
<vtnerd> its more work on the node verifying the block, but not the wallet since its not reading it. I suppose there is some additional time for transmission/marshalling/unmarshalling, but this is smaller than any crypto
<moneromooo> The bottleneck's the daemon anyway.
<btcltcxmrmaximal> daemon sync time seems a lot more important than wallet sync time (in comparison) if our primary goal was to encourage more full nodes.
<vertp> Unless you're using a remote node, no?
<hyc> this complicates the build if we want a crypto/ subtree just for wallet and one just for daemon
<moneromooo> Hmm, fair point.
<fluffypony> ok so then here's a suggestion
<Jaquee> the amount of tx's/day is higher since the date around ringct was activated. So wallet sync slows down. but not really related to ringct
<fluffypony> what if we had cryptoopsbuilder run on build
<fireice-uk> build won't be more more complicated - just more symbols
<fluffypony> and use the existing stuff by default, but optionally use the newer SUPERCOP / whatever
<fireice-uk> my suggestion would be to use ge64* symbols for the new code
<moneromooo> BTW, is that not what you wanted to replace by... tweetnacl or whatver it was ?
<fluffypony> moneromooo: yes
<fluffypony> but only when TweetNaCl has finished formal verification
<moneromooo> And that proposal replaces it with this, or another replacement ?
<moneromooo> Alright...
<hyc> I'd prefer we just keep the generated code statically committed to git
<hyc> no idea what environment the builder might break on
<fluffypony> hyc: the builder is pretty simple (just splicing text really), but it does add a python dep to the build process
<hyc> yeah, let's not do that.
<moneromooo> fireice-uk: did you try running a wallet refresh without any crypto to see how much faster it was at best possible gain ? IIRC, my bottleneck is the daemon (SSD, though CoW fs).
<fluffypony> either way, in the long run I'd like to have a default "safe" crypto implementation, and an optional fast one
<moneromooo> s/without any crypto/with the actual tx scanning disabled/
<fireice-uk> moneromoo: bottleneck is the poor fetching from the daemon
<moneromooo> So changing the crypto won't do a thing right now, right ?
<fireice-uk> it somehow mananges not to max anything
<fireice-uk> that is the part 2
<fireice-uk> crypto is part 1
<pigeons> so likely this is a premature optimization for now
<fireice-uk> pigeons: want to swap round the order?
<vertp> why not swap the orders fireice-uk? And do daemon fetching optimization
<fluffypony> not a bad idea
<moneromooo> Oh ok. There are two things that should be easy win there: store non prunable separately, and maybe fetch a bunch of them at once (wallet refresh always has pretty much N..N+dN txes).
<gingeropolous> so part 2 is the actual optimization? and part 1 is... ?
<moneromooo> I wanted to do the daemon thing for a while, but looks like I won't have to :D
<fireice-uk> gingeropolous: part 1 is crypto optimziation, part 2 is parallelism opt
<hyc> but current discussion says crypto opt will be overshadowed by daemon
<fluffypony> ok so we swap them around and do part 2 first, and then revisit how to structure part 1 after that?
<hyc> makes sense
<fluffypony> fireice-uk: that sound ok?
<moneromooo> Well, that's my recollection of my particular machine anyway. Might differ for others.
<fireice-uk> my suggestion would be to do part 1 first - this way you can have a loot at it before merging
<fireice-uk> *look
<moneromooo> I want to have a look at 2 also before merging.
<hyc> lol
<vertp> lol.
<fireice-uk> of course, but i assume 1 will require more time
<fluffypony> lol
<vertp> but if its has more immediate benefits, why not go with 2 first?
<hyc> yeah it's sounding like 1's benefits will be unmeasurable for now
<vertp> it makes even more sense to do part 2 first if it is less complex/faster to implement.
<Jaquee> +1
<moneromooo> Yes, do the easy wins first, and the possibly dangerous stuff might not be needed (and will only work on x8664 anyway AIUI).
<fireice-uk> ok, that's fine with me
<moneromooo> Keeping in mind you also need the full blocks to serve syncing peers.
<vertp> great!
<fluffypony> ok cool - I'll move the proposal to funding after the 0.10.3.1 tag
<samsunggalaxyplayer> so in like 3 months /s
<fluffypony> hah hah
<fluffypony> touché
<vertp> Since we are on a similar topic, could I bring up ZMQ? That should also speed up sync time/provide faster wallet func at some point no?
<tewinget> nah, fluffypony doesn't run on tewinget Time™
<fluffypony> vertp: it should provide better scalability for multiple wallets hitting the same daemon
<fluffypony> but I don't think it'll provide speed benefits beyond that
<vertp> so light-wallets. Is there anything new on that front tewinget.
<tewinget> agreed
<tewinget> well, I've been working on merging from upstream this morning
<tewinget> I think I've just got it sorted
<hyc> yay
<vertp> woo!
<gingeropolous> !!!!
<johnalan> Nice
<fluffypony> let's stick to the schedule plx
<tewinget> few things changed in core that threw wrenches in the merge >>
<tewinget> sorry fluffypony :)
<vertp> yes, sorry.
<fluffypony> ok so
<fluffypony> 4. Remote nodes (ie. a discussion of #605)
<moneromooo> Well, I was thinking about this, and I will do a wallet mode where a full wallet (ie, phone) can connect to a view wallet (ie, home server), and update from it. That should be super fast.
<fluffypony> moneromooo: that's exactly what vtnerd is doing
<moneromooo> tewinget: I think I kinda added a new RPC... a few days ago...
<fluffypony> so would be duplication of work
<moneromooo> Oh, OK.
<johnalan> Won't that only show incoming though?
<fluffypony> but let's back up a second
<hyc> so a wallet can sync from another wallet?
<fluffypony> because I think that maybe there's some value in the idea of 605
<moneromooo> In my idea, yes (really, transfer output data).
<fluffypony> but the specifics aren't great
<fluffypony> for eg.
<moneromooo> But I dunno what vtnerd is doing.
<xmreric> Lots of GUI users want this on some level or another.
<xmreric> I'm pretty big on emphasizing away from using remote nodes as best-practice.
<fluffypony> what if an unsynced daemon, when it has a wallet client requesting outputs from a certain height, picks a random peer and asks that peer for the data
<xmreric> But for people in developing nations, etc it's a good option to offer
<samsunggalaxyplayer> I know that we all want everyone to run a full node, but I imagine less than half actually will, and that percentage will only decrease over time with new, non-technical users
<fluffypony> ie. without range proofs / sigs / etc.
<gingeropolous> the random peer has its rpc open?
<fluffypony> the peer could lie, but the node will eventually know that it has
<fluffypony> gingeropolous: no
<fluffypony> we don't need RPC for this, we're already talking to the peer using the p2p protocol
<moneromooo> Why would the wallet request outputs for a given height, if the daemon isn't synced to that yet ?
<fluffypony> moneromooo: restored wallet, or loading a wallet file
<Jaquee> if the daemon isnt synced it shouldnt be used by the wallet
<fluffypony> or creating a new wallet
<moneromooo> Restored wallet would not, it has no idea about where it has outputs.
<fluffypony> moneromooo: restored from seed has a hardcoded restore height
<guzzi> It is similar to how hadoop works
<moneromooo> New wallet wouldn't either. They'd get that info from the daemon, who'd necessarily be synced up to that point.
<guzzi> Here is the first answer it may be wrong
<moneromooo> Unless you delete your blockchain after the wallet learns abvout those. But then, your problem.
<fluffypony> moneromooo: in each of the instances we either have a block height or we have a date that we can correlate
<moneromooo> Oh, you want all outputs ?
<fluffypony> from that height or date, yes
<guzzi> I like it. The attack would bre someone setting up a ton of fake nodes.
<fluffypony> basically have the daemon tunnel "remote node" functionality to a peer
<moneromooo> OK, so essentially, syncing the chain with no vcerification whatsoever.
<fluffypony> moneromooo: yes - "pre-syncing" it
<fluffypony> because the node will catch up, and then the wallet will know if outputs have been withheld
<moneromooo> I actually had an idea about this a few days ago, where you could sync to a daily set of key images and outputs. Daily, verifying nodes hash it into the blockchain.
<guzzi> Basically a no lock read
<moneromooo> So you can sync to that, check hash, then sync the last day's chain on top.
<gingeropolous> but this would leave the wallet in a state where it can't create transactions until proper sync'd?
<fluffypony> moneromooo: the problem with that model are the oracles
<moneromooo> It does require some trust, though.
<moneromooo> Go on ?
<pigeons> so the tricky part is the rules to make the block invalid if the miner lies
<gingeropolous> er, until the daemon is proper syncd?
<fluffypony> gingeropolous: the daemon could also tunnel requests for ring outputs or whatever
<fluffypony> the trust model is the same as using some random guy's remote node
<Jaquee> good idea. but still doesnt help users without enough disk or those on a slow connection
<guzzi> True
<samsunggalaxyplayer> That's what I proposed #602 for
<samsunggalaxyplayer> People who do not want to run a full node
<pero> i had a kind of mostly trustless idea for this
<fluffypony> people that don't want to run a full node at all have to then use something like the MyMonero apps using the MyMonero backend instead of their own
<fluffypony> or Exodus or Coinomi or whatever else exists
<pero> that would poll multiple nodes for the same outputs and verify them
<pero> and store those locally
<fluffypony> pero: that's even worse than a remote node
<pero> fluffypony: +1
* pero sees himself out
<guzzi> Or this and never sync tge daemon
<guzzi> Lol
<rehrar> What if the time connected to a remote node is limited? Just setting up the GUI it connects to a remote node, and they can use right away, while stuff is going on in the background? (Sorry, just an idea I had. Not a developer so I don't know if possible)
<fluffypony> the larger issue here is that we can't do something like SPV
<fluffypony> so we really have nothing between "run your own node" and "use a centralised service"
<rehrar> Stuff = syncing
<ArticMine> Should we looking at people connecting to their own remote node form say a mobile device?
<fluffypony> rehrar: that's exactly what I'm suggesting, but let the daemon "tunnel" the requests through
<fluffypony> ArticMine: the model here is people who don't want to run a node at all, not at home, not on a VPS, not at all
<Jaquee> rehrar: that's what #605 does
<fluffypony> we already have a solution for people who are willing to run a node
<rehrar> Sorry. A lot of the tech is going above my head to catch it all. :)
<moneromooo> Well, they can use paypal, and come back in 5 years.
<rehrar> Tech talk
<Jaquee> #605 connects to a remote node while local node is syncing
<jacobjeweler> I agree, fluffy. I think the real issue is people not having enough knwoledge to install nodes. An installer on windows and .deb in apt would increase full nodes immensly.
<gingeropolous> i like it. the pre-sync idea. using the daemon. it opens up the whole network as a source of remote nodes, which decentralizes the effort
<xmreric> What if all this work gets done, but then this audience just uses web/mobile wallets anyways
<pigeons> keep improving the ability for people to run their own node before making it easier for people to use a different model
<gingeropolous> and because the daemon is running
<gingeropolous> it will be synchronizing its own copy of the blockchain
<fluffypony> @xmreric that's the most likely outcome
<hyc> that is trickier
<fluffypony> people *are* going to use MyMonero / Exodus / Coinomi even if we have a magical remote node model that doesn't vampire the network
<guzzi> It could even hold part of the chain and randomly ask for missing parts
<hyc> block data sync'd this way will need to be stored differently than from regular syncing
<pigeons> peopl are going to use worse options than those even
<fluffypony> hyc: agreed
<fluffypony> pigeons: store on an exchange :-P
<samsunggalaxyplayer> I like the pre-sync as well. But until we have MyMonero/Edodus/Coinomi, people will use a remote node in an inefficient way
<fluffypony> @samsunggalaxyplayer then let's not make it easier by having a drop-down
<gingeropolous> ^
<Jaquee> why not make it easy while waiting for a better solution?
<fluffypony> remember that a lot of decisions we make today, we're stuck with for 5+ years
<gingeropolous> the effort wall to hack the system to use a remote node isn't that steep anyway
<fluffypony> Jaquee: because ^^
<fluffypony> people become reliant on quick fixes
<hyc> So somewhere we need the doc to say "you must have a computer with at least xx GB of disk space that you are willing to leave running 24/7"
* tewinget knows this, and as such leaves most decision making to fluffypony so he can be blamed in 5 years.
<moneromooo> Ah, tewinget the Wise.
<endogenic> in 2023
<Jaquee> i just don't think we should be holding back on UX just because we don't have a better solution yet
<pigeons> have a nice message, now that you have verified the blockchain, we notice you have been screwed, pick a better node next time
<fluffypony> lol
<moneromooo> Anyway, this has turned to a disparate set of confusing stuff now.
<guzzi> Lol
<fluffypony> Jaquee: the GUI is meant to operate with a full node that you operate, it's not a lightweight GUI
<ArticMine> Do we want to encourage people connecting to a untrusted random node
<fluffypony> ArticMine: no we don't
<samsunggalaxyplayer> Summary: for smart syncing with fluffy's "pre-sync" approach, against anything that makes using a remote node easier
<guzzi> For ppl who want to use a phone could it never sync?
<cryptocomicon> sounds like we need a monero node appliance, like the wifi router that everyone has in their house / flat
<samsunggalaxyplayer> I agree #602 is a short-term solution. I think it's better than telling people to go to MoneroWorld to get a random node, but if we have a better solution going forward, that's preferable
<johnalan> Good idea
<hyc> yes but wifi routers tend to be 32bit
<jacobjeweler> Thats why i think installer for windows and adding .deb to apt repositories will have it so people can be guided through an install and proper installation can be verified
<guzzi> And always use a random?
<fluffypony> guzzi: phone would be MyMonero + your own node / MyMonero backend OR Exodus OR Coinomi
<gingeropolous> and they're not cheap
<guzzi> Ok thanks
<jacobjeweler> Adoption rate will increase full node usage
<fluffypony> @JacobJeweler we're definitely working on improving that with the GUI
<ArticMine> I say make it easy for people to set up their own node to connect to. Appliance like
<guzzi> That is horse poop
<fluffypony> with the auto-update thing
<pero> perhaps there's room for an unofficial gui fork
<guzzi> No way ppl walñnt full nodes
<fluffypony> gingeropolous: http://imgur.com/a/3mMBE
<gingeropolous> in my mind the remote node thing has 2 components: 1) instant on 2) no blockchain storage.
<fluffypony> gingeropolous: pigeons is working on it
<hyc> right now the only way I see to make this easy is with kovri, so we can ignore firewall and port forwarding issues
<fluffypony> hyc: +1
<gingeropolous> we can address instant on with lots of things
<gingeropolous> we can't address no blockchain storage. And those that don't want to store the blockchain will always use some lighter weight thing, so ... i think im rambling.
<jacobjeweler> Good point hyc!
<amiuhle> How about creating SD card images with the blockchain preloaded for a specific monerod release. You'd "just" have to download the image, flash it and start up monerod
<johnalan> +1 hyc
<amiuhle> ah, like for the Pine64 or something similar
<hyc> pretty big downloads. they don't compress well at all.
<hyc> 13GB now
<Jaquee> and pine64 is to slow
<johnalan> Does it even have native AES?
<fluffypony> pine64 isn't too slow?
<amiuhle> hyc: didn't you say you're running your full node fine on yours?
<hyc> pine64 yes
<pero> pine64 can run a node
<hyc> yeah pine64 works ok as a fullnode. buy an expensive microSD
<fluffypony> alright
<tewinget> I'll brb in like 10 min, fyi
<fluffypony> let's move on
<fluffypony> 5. Code + ticket discussion / Q & A
<Jaquee> ok. so #605 will not be merged?
<fluffypony> (we can carry on discussing this after the Kovri meeting)
<Jaquee> all right
<fluffypony> Jaquee: no not with the drop down
<hyc> you can release the bootleg edition
<fluffypony> lol
<amiuhle> I've gotten the impression that there should be more unit tests from reading the last dev meeting
<fluffypony> amiuhle: yes
<jacobjeweler> Lets be honest, most users have windows. And harddisks that can easily fit the lmdb database. If you want great adoption and more full nodes on the network (people installing and usong their local node for gui/cli). Thats where the focus on something like an installer should be at.
<amiuhle> what if we at least request tests for new PRs?
<moneromooo> Then you won't get PRs.
<vtnerd> that would help, but could be frustrating in a few components
<fluffypony> amiuhle: we don't want PRs from new contributors mired in a list of things-the-PR-must-have
<vtnerd> for instance, I added some to epee::stringtools, but those are isolated functions so its easy to setup the test env
<hyc> some of this stuff won't be easily detected in tests anyway. race condition with mining blocks, etc.
<fireice-uk> one more thing regarding wallet2.cpp
<jacobjeweler> Sorry am on phone typing, slow to respond.
<vtnerd> hyc: yup. but figuring out a base framework for some areas might be helpful to get a baseline. but its decent chunk of work
<fireice-uk> it is already at an unwieldy 5kloc, what's the opinion on splitting it into smaller parts?
<hyc> can't detect some of these with code coverage testing either. code cov can't tell you about logic you're missing.
<moneromooo> Tests can be added after the fact btw.
<moneromooo> Is there a split that makes sense ?
<moneromooo> And 5k is wieldy for any sane editor.
<fireice-uk> moneomoo: takes 2gb+ to compile
<hyc> yeah I wouldn't worry about wallet2.cpp at the moment.
<vtnerd> mooo Im guessing vim ?
<hyc> 2GB+ to compile comes from all the boost headers and shit
<moneromooo> What I want is avoiding spamming the git log, as I use it a lot.
<fireice-uk> ok
<moneromooo> vim works fine with 5k, but most other editors are also not shit.
<vtnerd> fireice-uk: thats partially coming from the epee headers though, but some split may help a bit
<moneromooo> Or... I assume. 5k is not much.
<hyc> I've done the experiment before.
<fluffypony> bbedit handles it fine
* anonimal coughs
<hyc> splitting the file up to try to fit it under 2GB
<fluffypony> ok guys
<fluffypony> Kovri meeting
<hyc> made no diff. it's the headers, not the cpp source
<fluffypony> next meeting in 2 weeks, no time for Q&A, thanks for coming

Monero 0.10.3.1 "Wolfram Warptangent" Released

Mon, 27 Mar 2017 00:00:00 GMT

Overview

Since it has only been 30 days since the last release, this is something of a "light" update. Nonetheless, some highlights of this release are:

the 0.10.3.1 point release disables a portion of the server-side hash cache that was preventing a small subset of nodes from syncing
added a feature to allow for multiple outputs to be paid to the same address (unless you have set merge-destinations 1)
fixed a major bug that could lead to some peers, seemingly randomly, getting stuck at a block height and refusing to accept further blocks
monero-wallet-cli (and underlying libraries) can now work in a number of units: monero, millinero, micronero, nanonero, piconero
added OpenAlias support to wallet RPC calls
fixed hardcoded seed fallback issues when DNS seeds have failed or too few seeds are returned
added an optional config file for wallets
added an additional non-interactive foreground mode for the daemon
added mnemonic wordlists for French and Dutch
per-kb fee quantized to 8 decimal places
added a password function to monero-wallet-cli to allow for a wallet password to be changed (and all files re-encrypted)
added a cache on the wallet to avoid re-scanning mempool txs already scanned
improvements to auto-update functionality, including a download-and-verify mechanism
fixes to a number of logs shown in the daemon by default
massive API changes to support new features in the GUI
as always, loads of bug fixes and performance improvements

Contributors for this Release

This release was the direct result of 24 people who worked, largely unpaid and altruistically, to put out 190 commits containing 5 706 new lines of code. We'd like to thank them very much for their time and effort. In no particular order they are:

Christoph Schnerch
Jaquee
NanoAkron
Arne Brutschy
assylias
lethos3
rockhouse
Roy Jacobs
stoffu
adot23
Riccardo "fluffypony" Spagni
Noah Watkins
Lee Clagett
xmr-eric
Howard "hyc" Chu
Derek Zhang
Gareth
Gingeropolous
darentuzi
Akademik Prokhor Zakharov
Guillaume Le Vaillant
moneromooo-monero
Miguel Herranz
kenshi84

Official Download Links

Download Hashes

If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes:

monero-win-x64-v0.10.3.1.zip, 2fbda6f6b1051053703e40cf77b6c6e11334509ad03a3c22d89b6bcb05615910
monero-win-x86-v0.10.3.1.zip, da628a45adfcb8be44df06ac904711d644d608c4eb6479a5d256062a5f6d74de
monero-mac-x64-v0.10.3.1.tar.bz2, fd17d55a8c9e901ff4064c39d9e14786cdd077aff9b3bb556e60d3a5e322050c
monero-linux-x64-v0.10.3.1.tar.bz2, 8db80f8cc4f80d4106db807432828df730a59eac78972ea81652aa6b9bac04ad
monero-linux-x86-v0.10.3.1.tar.bz2, abc99f3928f4083bd1a380a869253e07bee9950e0aeb6388e9493bc0f0ec3f53
monero-linux-armv7-v0.10.3.1.tar.bz2, 8473fa20e0db4a3d3e46120cdf92c55be6a159478c511e21f7b77aa05d6c1910
monero-linux-armv8-v0.10.3.1.tar.bz2, 451f65e4846b92d54859e22a5d92124557b397b4208d8752d5289d0262573c3c
monero-freebsd-x64-v0.10.3.1.tar.bz2, 4c66a76752e18ae70b5fb1c728f0d2780eb129a6c8c7d0dee7ba02e05d91efae
monero-dragonflybsd-x64-v0.10.3.1.tar.bz2, c25c0f603ca5c96cb5963aaa2905edff390b7a97f654106911ffad8639deee7c

Monero GUI Beta 2 Released

Wed, 29 Mar 2017 00:00:00 GMT

Overview

The second beta of the Monero GUI has been released. Due to our focus on completing the features required for the initial release we have not, as yet, completed support for 32-bit Windows, FreeBSD, DragonflyBSD, ARMv7 Linux, and ARMv8 Linux devices. Whilst these are being worked on, it may not be feasible to support some environments (like 32-bit Windows) due to performance degradation.

Download links are at the bottom of this post, and please take note of the known issues and caveats listed below.

To upgrade, just replace your existing GUI with this newer release. Beta 1 wallets will continue to work in beta 2, without any changes required from your side.

Known Issues

If the GUI doesn't start on Windows, or starts with a blank screen, then try launch it using the start-low-graphics-mode.bat batch file.
The unsigned transaction format, used by cold wallets, may cause issues when moving between platforms (eg. from Linux to Windows) for signing.
Cold transaction signing does not work with split transactions (sends that are split over multiple transactions).

Contributors for this Release

This release was the direct result of 50 people who worked, largely unpaid and altruistically, to put out 1202 commits containing 345 646 new lines of code. We'd like to thank them very much for their time and effort. In no particular order they are:

Ilya Kitaev
James Cullum
luigi1111
Matthias Tarasiewicz
Derek Zhang
Howard "hyc" Chu
medusadigital
Andreas Brekken
maitscha
hundehausen
moneroj
xmr-eric
signo88
HugTime
marcin
Clement
MoroccanMalinois
Lafudoci
Timo Uhlmann
Christoph Mayerhofer
redfish
Jaqueee
dnaleor
MartinUI
Guillaume Le Vaillant
Daniel Ternyak
David Latapie
henrud
moneromooo
Michael Campagnaro
taushet
schnerchi
Jonathan Cross
Riccardo "fluffypony" Spagni
dEBRUYNE
ferretinjapan
sbialy
Christoph Schnerch
githubrsys
xmrdc
Gingeropolous
NanoAkron
kenshi84
keesieboy
moimoij
Shrikez1
MiWCryptAnalytics
mochaccinuh
Roy Jacobs
pigeons

Official Download Links

Download Hashes

If you would like to verify that you have downloaded the correct file, please use the following SHA256 hashes:

monero-gui-linux-x64-v0.10.3.1.tar.bz2, 4915473265d58720fd8f019e536c2b7fb02648ab51a8087e84aa1e2434788452
monero-gui-linux-x86-v0.10.3.1.tar.bz2, 092b49080c3380666845f7f39823b09f4960ea1e250b84b150856ef33ca30690
monero-gui-mac-x64-v0.10.3.1.tar.bz2, c80ca68037158216a080e59e90b0a70761cff2f317d3c9cd0eeb661e8e2a1f99
monero-gui-win-x64-v0.10.3.1.zip, 0eddd423f5f0df236303d8b9225842142b331093eb69e6183f3f694238c371a7

Announcing the Monero Celebrity Center

Sat, 01 Apr 2017 00:00:00 GMT

For Immediate Release

The Monero Core Team is very proud to announce that we have broken ground on the construction of the Monero Celebrity Center in Los Angeles, USA!

For some time we have known that we needed an exclusive center where Monero's more relevant could be rewarded for their contribution to Monero's growing image in popular culture. Those with the largest number of transactions are often celebrities and former clients of Mossack Fonseca who it turns out are mostly located in the Los Angeles area. We don't know precisely what they're spending Monero on, but we understand their desire for enhanced privacy for certain...purchases...that they make.

It is for this reason that the Monero Core Team have seen to the construction of a special center that caters to these individuals - the artists, politicians, leaders of industry and sports figures who use Monero... and no one else. We are pleased to call this new campus the Monero Celebrity Center of Los Angeles.

Built on the banks of the Arroyo Calabasas river, the Monero Celebrity Center will be open 24 hours a day, and will house 420 full time staff to assist celebrities with their Monero purchases.

Now one might argue that these individuals already have benefits that many will never have. But, ask any one of them - ask yourself - can the world be lonely even for those who appear to have everything. Subject to the unusual pressures that come with prominence and responsibility, being looked upon under a microscope for good or bad - these are burdens others can't imagine. Not to mention the counter-attack such individuals are subjected to by those less-ambitious who would rather fight to maintain a "status quo" than allow another to attempt a change or improvement. We asked ourselves "How can Monero help these people and how can they help Monero?"

You see, there's no shame in helping the artist. In fact, in the larger scope of societal help, we had better help the artist if we wish to advance the society at all or Monero for that matter.

We look forward to welcoming celebrities to the Monero Celebrity Center as soon as it has been completed!

Logs for the Kovri Dev Meeting Held on 2017-04-09

Sun, 09 Apr 2017 00:00:00 GMT

Logs

<anonimal> 1. Greetings
<anonimal> 2. Brief review of what's been completed since the previous meeting
<anonimal> 3. Preparation for 96boards.org OpenHours showcase for Kovri / Monero
<anonimal> 4. Status of Monero HackerOne umbrella and bounty
<anonimal> 5. Code + ticket discussion / Q & A
<anonimal> 6. Any additional meeting items
<anonimal> 7. Confirm next meeting date/time
<anonimal> Hellloooo
<i2p-relay> {-olark} Hello party people
<i2p-relay> [gingeropolous] howdy!
<guzzi> Hello
<moroccanmalinois> hi
<rehrar> Hi (observing excitedly)
<i2p-relay> {-iDunk} Hi
* moneromooo greets again
<i2p-relay> [endogenic] no excitement allowed rehrar
<bigreddmachine> hi
<rehrar> I'll see myself out then.
<anonimal> 2. Brief review of what's been completed since the previous meeting
<anonimal> For me, the past two weeks have spent focusing on 4 things: fixing the OpenBSD dynamic build, PR review/fixes/collaboration, NTCP, and RI (router info).
<anonimal> a. Jeff at crypto++ has not been responsive lately so my CMake fix for their dynamic OpenBSD is still sitting in PR hell.
<anonimal> b. Both moroccanmalinois and rakhimov have been PR'ing some great work
<anonimal> c. Over time I've done bits and pieces of work on the NTCP implementation but hadn't had the chance to do a full study in java I2P's implementation until recently.
<anonimal> Combined with more spec review (forunately, the spec is small) I've come up with 33 questions/TODOs specifically about, and for, our implementation.
<anonimal> Once that was done, it turned out that I couldn't move forward until I worked out any potential RI issues.
<anonimal> d. That lead me to the unmaintainable mess of our forked RI implementation, which has been neglected, so now at a minimum I'm working on a RI parser/reader/writer refactor. From there, unit-test and then back to NTCP so I can close that damn milestone issue >:|
<anonimal> So, that's just on my end. Anyone else?
<anonimal> I know guzzi is doing study for RAII refactoring.
<bigreddmachine> Salti's holding pattern for webextensions in FF is making progress
<anonimal> Oooo cool
<anonimal> How are they doing on that front?
<bigreddmachine> 1 of two issues i'm tracking are finished, second is still a ways off
<guzzi> Review client context implimenting raii
<bigreddmachine> and no dev docs yet
<moroccanmalinois> Looking at reload server tunnels https://github.com/monero-project/kovri/blob/master/src/client/context.cc#L321
<anonimal> Excellent, that all sounds good. Anything else before we move onto 3.?
<i2p-relay> {-olark} I have been slowly evaluating what will be needed to replace supercop with tweetnacl
<anonimal> (well, I'm hoping FF will move faster but it sounds like they're at least moving)
<i2p-relay> {-olark} Can rip out all the ecdsa sig types at the same time to work towards the identity refactor work
<bigreddmachine> anonimal: yes. progress is progress.
<anonimal> olark: ok this is for #485, sounds good. Would you be able to resolve #345 in the mean time?
<i2p-relay> {-olark} For EdDSA
<i2p-relay> [fluffypony] major thunderstorm here, so if I don't respond it's because I've been struck by lightning (or my house has)
<anonimal> Eeek! No charred pony!
<i2p-relay> {-olark} anonimal: Sure
<anonimal> fluffypony can you see the meeting or is internet intermittent?
<anonimal> olark: nice!
<anonimal> Ok, moving forward,
<i2p-relay> {-olark} I will find the time. I have been neglecting kovri :(
<anonimal> Yes, come back soon ;)
<anonimal> 3. Preparation for 96boards.org OpenHours showcase for Kovri / Monero
<anonimal> Speaking of neglecting, I hope we don't let this opportunity slip by ^
<anonimal> Does anyone know of any effect voice masking software? Military grade (if there is such a thing).
<anonimal> *effective
<i2p-relay> [fluffypony] anonimal: nothing I know of, but I also don't know if that would be worthwhile or weird
<i2p-relay> * fluffypony tries to convince anonimal to come out the pseudonymous closet
<i2p-relay> {-pigeons} yeah its annoying as hell to listen to
<i2p-relay> {-pigeons} mouthful of marbles works ok though
<anonimal> I hear that Barry Manilow recently came out of the closet.
<guzzi> Pennies
* anonimal not that I'm a fan, nor am I in that sort of closet
<anonimal> Well, I'm curious to hear the public's opinion on whether I should de-anon. Thoughts?
<i2p-relay> [endogenic] yes!
<anonimal> moneromooo ^ #monero-dev
<i2p-relay> [endogenic] i will be your bodyguard
<anonimal> lol awesome! X)
<i2p-relay> [fluffypony] anonimal: only reason I suggest it is because Kovri does need a voice, but ultimately it's your call
<i2p-relay> [gingeropolous] weren't you already on the monero missives?
<i2p-relay> [fluffypony] gingeropolous: no, that was jeff
<moneromooo> What ? What's in #monero-dev ?
<i2p-relay> [endogenic] anonimal: just think… we can hang out at meetups and such :)
<i2p-relay> {-olark} Ultimately your choice anonimal.
<i2p-relay> {-olark} Don't feel pressured to come out becuase people want you to ;)
<sgp> ^ seconded
<anonimal> gingeropolous: ^ not Jeff at crypto++, Jeff a former problem contributor who, as he said, has family in U.S. intelligence.
<i2p-relay> [gingeropolous] he's satoshi.
<anonimal> moneromooo I meant 'what's your opinion if any?'
* anonimal and also threw question at #monero-dev in same line, sorry
<i2p-relay> [gingeropolous] my apologies. I obviously know whos who here.
<moneromooo> Of whether you should de-anon ? I wouldn't want to influence you to.
<anonimal> Oh np, just clarifying since I said "Jeff" earlier.
<moneromooo> My view is that the more people actively keep their privacy, the less the massive pressure on everyone else to shed their privacy is.
<anonimal> Hmm, good point.
<moneromooo> Not really related to this particular case, but having 99% of people not care about their privacy means that companies and everyone can just screw privacy and not get any noticeable blowback.
<i2p-relay> [endogenic] think only anonimal's in the position anonimal's in as kovri lead tho
<moneromooo> So I use Tor for random run off the mill browsing partly for that reason too.
<i2p-relay> [fluffypony] moneromooo: yes, but this is about his status as a contributor and maintainer
<i2p-relay> [fluffypony] after all, things get really boring if I'm the only one talking at conferences
<moneromooo> Well, his choice, and I don't want to interfere in it. But thanks for asking :)
<i2p-relay> [endogenic] <3
<i2p-relay> [endogenic] i wouldn't go that far fluffy
<i2p-relay> [gingeropolous] you could just "hire" a spokesperson to be your IRL talking head
<i2p-relay> [gingeropolous] and they just happen to know a whole lot about everything
<i2p-relay> [endogenic] rent-a-body
<anonimal> Ok, so I'm hearing that if I de-anon I get a free(?) bodyguard and can freely promote more-so than what I can do now. I'm also hearing that no one wants to put that kind of pressure of a decision on me.
<anonimal> I have to say though, I'm wearing more than 1 cap at any given time. Maybe one-too-many? It was a relief to finally sit down and write some code this week. It had been way too long since I've done that and I'm ALWAYS HERE working on kovri!
<iDunk> I think gingeropolous suggested you should invent an alter ego for public appearances :)
<i2p-relay> [endogenic] you can choose when to do talks and when to reply to ppl imo
<i2p-relay> [endogenic] and i bet others will jump in to help
<i2p-relay> [fluffypony] "I'm fluffy...errrr...fluffynonimal, and I'm a Kovri developer"
<i2p-relay> [endogenic] just a question of letting us know how we can help
<i2p-relay> {-pigeons} even if you do come out, still consider the marbles for talks
<i2p-relay> [gingeropolous] well iDunk now its ruined
<iDunk> Damn
<anonimal> lol, I'll just show up with marbles in my mouth.
<anonimal> I must say that, adding public-relations, I love the thought, but I do also love writing code.
<anonimal> And people love targets, so that's always something to concern myself with.
<sgp> You can still do both. Choose the proportion you want
<anonimal> "just a question of letting us know how we can help" <-- thanks endogenic. I think what will help are 2 things:
<anonimal> sgp good point
<i2p-relay> [fluffypony] anonimal: I think that there's probably less scope to talk about Kovri at conferences right now anyway, but it would be nice for someone to do some podcasts etc. in future
<i2p-relay> [endogenic] podcasts are a great idea. i honestly doubt most ppl who want to use something like tor even know tor needs an alternative
<i2p-relay> [endogenic] and i'd enjoy learning more about the kovri tech in that format
<anonimal> What would help: 1. more people get more familiar with kovri technology so they can answer questions and promote too. And 2. maybe everyone present can give me a solid "yes" or "no" on if they want me to de-anon (i.e., putting aside any other thoughts and responding purely on instinctual feelings)
<anonimal> bigreddmachine: ^ re: podcast, my decision sooner than later will effect that
<i2p-relay> [gingeropolous] just go full Mr. Robot. Loose touch with reality, veer into psychosis, and then even you don't know who you are.
<anonimal> lololol gingeropolous X)
<sgp> I just started watching that show. 1 season in. No spoilers please!
<ArticMine> To de-anon should be personal chice in my opinion
<anonimal> Ok I'd say we're on a tangent for point 3 but this kind of needs to be done IMHO.
<ArticMine> choice
<anonimal> All in favor of me de-anoning: yay or nay?
* anonimal don't be shy!
<i2p-relay> [endogenic] i personally agree it must be personal too. sry to be difficult. there are tradeoffs for sure
<sgp> Pros: can talk about it more openly, attract new talent with greater outreach, better inform community about developments. Cons: more likely to be a target, maybe you're really ugly
<i2p-relay> [endogenic] it's a kind of burden i think
<sgp> (just kidding on second con)
<i2p-relay> [fluffypony] anonimal: I don't know if we should vote for that, it's your call
<anonimal> lol sgp maybe I'm missing a face entirely...
<anonimal> fluffypony ok
<anonimal> So resolving 3., fluffypony + pigeons, how's your schedule lately?
<i2p-relay> [fluffypony] pigeons is down my side of the world for a couple of weeks, so we can make time around that
<anonimal> Oh neat! Should I contact Robert to schedule a definitive date now?
<i2p-relay> [fluffypony] well it depends on if you want to do me + pigeons or you + pigeons
<bigreddmachine> anonimal: soory, was afk. re the podcast bit, if you do decide to de-anon yourself, i'd be happy to host your coming out of the closet party! but garbling voice is doable too.
<i2p-relay> [fluffypony] or all 3 of us
<anonimal> fluffypony: I would think either all 3 (or at minimum just you 2). bigreddmachine I'd like to hear/learn more about any garble tech available, even if it's annoying.
<i2p-relay> [fluffypony] anonimal: ok let's talk afterwards, and we can schedule it with them
<anonimal> Ok will do
<anonimal> bigreddmachine: I'll PM you later too
<anonimal> Anything else on 3.?
<moneromooo> Voice garbling sounds very reversible (unless it's voice recogniation plus text to speech).
<bigreddmachine> TTS certainly would work.
* anonimal considered TTS, maybe I should learn to type faster first
<anonimal> (or prepared statements?)
<anonimal> (defeats the fun of interviews/speeches/conferences?)
<anonimal> Ok, we'll talk more later.
<i2p-relay> [endogenic] hehe seems a little creepy
<anonimal> 4. Status of Monero HackerOne umbrella and bounty
<moneromooo> Copy and "paste" words from movies, paste them one by one to make up sentences. Like the old words cut off from a newspaper :D
<anonimal> lol moneromooo, not serial-killer-like in any way whatsoever...
<anonimal> re: 4. We have hackerone.com/monero !
<i2p-relay> [fluffypony] anonimal: has anything for 4. been written up in the style of an FFS proposal or not yet?
* anonimal grabs only FFS for 4.
<anonimal> Links is in the meta issue, one moment.
<anonimal> https://forum.getmonero.org/6/ideas/87597/monero-bounty-for-hackerone
<anonimal> Is that what you mean?
<i2p-relay> [fluffypony] ok - do you want me to move that to Funding Required in its current form?
<anonimal> Eek, I should update?
<anonimal> The prop looks unclear as-is
<i2p-relay> [fluffypony] probably worthwhile
<anonimal> We decided on 500 to start
<anonimal> Ok, I'll edit after the meeting or do you need me to do that now?
<i2p-relay> [fluffypony] no after is fine
<anonimal> Ok
<anonimal> So for 4, I still have to PR VRP's to the various repos.
<anonimal> Also invite the appropriate people to H1. But fluffypony I think you'll want to do that?
<i2p-relay> [fluffypony] sure
<anonimal> moneromooo is already in there. luigi is not yet though.
<anonimal> Alright. From there we should raise the funds first and then start inviting hackers on H1.
<anonimal> Any agreements/disagreements?
<sgp> I agree
<anonimal> Btw, many hackers are already on H1, by invite I mean invite to start looking at our projects.
<anonimal> Ok. Anything else on 4.?
<anonimal> 5. Code + ticket discussion / Q & A
<i2p-relay> [fluffypony] nothing else from my side on 4
* anonimal takes peek
<anonimal> re: website issue, is ajs here?
<ajs> present
<anonimal> Hi!
<anonimal> Any news the website front?
<i2p-relay> {-pigeons} No I am the holdup there
<anonimal> Ok. ETA on resolving any holdups?
<bigreddmachine> shoot, i was just about to ask about that. didn't realize we had monero-project/kovri-site. how can i help?
<ajs> have backed up work that has been done and waiting for access to a server
<anonimal> Btw rehrar popped in recently and said him and/or his wife would give a try a logo redesign.
<rehrar> Hi. Yes. :D
<i2p-relay> {-pigeons} i'll try to set something up in 24 hours or so
<anonimal> Wow, that fast? Cool.
<i2p-relay> [pero] so what happened to the logo i did
<anonimal> pero: it was NACK'ed. This was clearly stated in github issue that I posted in the previous meeting.
<rehrar> I'd also like to give the Kovri website a go, pending on the logo and branding. :)
<i2p-relay> [pero] why?
<anonimal> pero: I don't have the files though if that's what you mean.
<anonimal> fluffypony: ^
<i2p-relay> [pero] you were sent the files
<i2p-relay> [pero] so as i see it, a contributor contributed a bunch of time and spiffied up the previous logo
<anonimal> Not anymore. Tis' the magic of deleted emails.
<i2p-relay> [pero] the community was involved too...
<i2p-relay> [pero] then it unilaterally 'nack'd'
<anonimal> Yes. This was all clearly stated in the github PR.
<anonimal> Where is your logo work PR?
<i2p-relay> [pero] wow what a shitty way to waste contributor's time
<anonimal> You PR'd nothing. Community opinion does not equal final decision.
<anonimal> Off you go pero, the resident troll.
<i2p-relay> [pero] lol?
<anonimal> You knew from the start that fluffypony and I would make a final decision. Do I really need to bring up logs from months ago?
<i2p-relay> [pero] the logo assets were emailed to you and pony
<i2p-relay> [pero] there was no request to pr anything
<ajs> rehrar bigreddmachine - I made a very basic Jekyll site.. files at: https://github.com/anonimal/kovri-site
<i2p-relay> [pero] the request was for the files to be emailed
<i2p-relay> [pero] and your 'troll' remark is uncalled for and rude?
<i2p-relay> [pero] wtf is that
<anonimal> pero you have two options: 1. being kicked from this channel for disrupting a meeting or 2. venting into https://github.com/monero-project/kovri/pull/488 for all the world to see.
<i2p-relay> [bigreddmachine] ty ajs. will this be affected by the re-design that rehrar is doing?
<rehrar> Well, I think ideally the redesign that is done for getmonero.org should have an influence on the Kovri website (just influence, not dictate)
<rehrar> and the logo redesign I will propose (just a proposal) I think definitely should have a larger influence on the website
<i2p-relay> [pero] whats so hard about contacting the person that did the work?
<anonimal> rehrar: that sounds good
<rehrar> So before I start working on anything Kovri website related, we're going to try to get a logo to you guys before this week is over.
<rehrar> I'll drop it on here and the Kovri repo as an issue to look over when it's done.
<rehrar> And it is obviously open to suggestions or tweaks when we show it
<i2p-relay> [bigreddmachine] ty rehrar - but from a content standpoint, the re-design is sort-of content agnostic, right? as in, i could write a page and the formatting might change but if it's in a markdown file jekyll will just ingest it and reformat, right?
<rehrar> for Kovri, not getmonero.org, right?
<anonimal> Did you have any plans to re-use material from monero site (as to save time, etc.)?
<i2p-relay> [bigreddmachine] well, both i suppose, but kovri specifically
<ajs> bigreddmachine: site design is rudimentary and could be easily changed if need be
<rehrar> The content is going to be restructured for getmonero.org, I'm not going to do a lot of work on copy, unless people think it's really needed.
<i2p-relay> [bigreddmachine] (sorry, i got us off topic)
* anonimal whatever is easiest to maintain IMHO
<rehrar> Pages will be shuffled around, and some things within pages will be shuffled around (all of this will be submitted in designs prior to everything being built)
<rehrar> as for Kovri, it won't have nearly as much content yet, so I don't think it'll be a huge issue.
<rehrar> does that answer your question?
<rehrar> If not, the short answer is yes, it should be content agnostic, and I will work with you guys in the rare cases where it is not.
<i2p-relay> [bigreddmachine] not entirely but close enough, thanks.
<i2p-relay> [bigreddmachine] ahh, yeah that last bit helps
<rehrar> great!
<anonimal> Question:
<anonimal> rehrar: IMHO, from the work of yours I've seen, since you're an actual designer/creator/implementer, I'm wondering if you, bigreddmachine, ajs and pigeons would consider being the 'website team' to get this up-and-running. I can move the repo when we're online. Does this sound fair or something of interest?
<anonimal> It sounds like you're already doing that, I'm just wondering for my own piece of mind (e.g. do I need to re-schedule my work load for website work, etc.)
<i2p-relay> [endogenic] But not both!
<rehrar> That sounds fine with me. Pardon me for my ignorance, but what will be bigredmachine, ajs, and pigeons roles?
<i2p-relay> [bigreddmachine] i'm happy to help with some content, as i am trying to learn about the tech anyway so documenting it is an obvious step.
<anonimal> endogenic too, hop on the site train!
<rehrar> if you can focus more on Kovri, I would do it.
<anonimal> rehrar: re: bigreddmachine ajs and pigeons, let's chat after the meeting since we're out of time
<i2p-relay> [bigreddmachine] design-wise, i can give my two cents but i'd like to be hands off there. just more of a feedback guy, like "hey, this isn't intuative" or whatever
<rehrar> I don't think any of us have a problem bugging you if we need something.
<rehrar> I'm not able to stick around for much longer, actually.
<rehrar> We can set up a meeting time for alter this week?
<rehrar> *later
<anonimal> rehrar: just pop in anytime if you want to make an official website meeting
<rehrar> sounds good
<rehrar> gotta split. Seeya homes.
<i2p-relay> [bigreddmachine] i can't, but just summarize discussions on github issue and tag me
<anonimal> bigreddmachine: that's right, you're not always irc'able.
<i2p-relay> [fluffypony] Can I take the bot down? I'm in a YouTube show mow
<i2p-relay> [fluffypony] Now
<i2p-relay> [bigreddmachine] anonimal: i try to stay off during week to stay focused on my job.
<i2p-relay> [endogenic] anonimal: oh no not me, i was just trolling about "fair or of interest"
<i2p-relay> [bigreddmachine] meow*
<anonimal> Ok, moving on 6. Any additional meeting items
<anonimal> None from me. guzzi said like 2 lines.
<i2p-relay> [endogenic] I think pero could be of help on the site too as i think he has lots of exp there
<anonimal> 7. Confirm next meeting date/tim
<i2p-relay> [bigreddmachine] just that i'll keep tracking FF proxy and looking for alternatives.
<i2p-relay> [bigreddmachine] 23 Apr?
<anonimal> Yes, same time in two weeks.
<i2p-relay> [fluffypony] Yep
<anonimal> Thank you everybody!

Overview and Logs for the Dev Meeting Held on 2017-04-09

Sun, 09 Apr 2017 00:00:00 GMT

Overview

An overview can be found on MoneroBase.

Logs

<fluffypony> ok
<fluffypony> 2. Brief review of what's been completed since the previous meeting
<fluffypony> so the main thing was the 0.10.3.1 release
<fluffypony> which has mostly been fine, no major breaking issues
<fluffypony> there are some GUI fixes that will go into 0.10.3.2, which we aim to tag and release soon
<medusa> before or after the fork ?
<fluffypony> which brings us to
<moneromooo> There's this bug with not merging destinations, which is overeager in not merging.
<fluffypony> 3. Code + ticket discussion / Q & A
<fluffypony> medusa: probably before, due to the thing that moneromooo just pointed out, which is a bit of an annoyance for exchanges
<medusa> allright thats good. i think a possible bugfix release after the fork shoudl be completely seperate too
<fluffypony> medusa: is there something you're expecting will break at the fork? :-P
<medusa> lets hope nothing is needed <3
<medusa> no
<fluffypony> ok shew
<fluffypony> I'm planning on merging PRs over the next couple of days
<fluffypony> are there any that are don't-merge-yet?
<vtnerd1112> The one I have outstanding for bin2hex
<xmr_eric> Before merging the PR to name Monero GUI back to Monero Core, I thought it would be good to have a discussion here about that. But perhaps that can be saved for the end of today's meeting.
<moneromooo> Oh, I'd kinda forgot-ish about that one...
<Jaquee> #658 and #667 obviously
<vtnerd1112> It's currently unmergeable and I don't know if anyone looked at it recently
<fluffypony> xmr_eric - we can discuss it now, it's part of this section anyway
<vtnerd1112> monermooo I will revise and push later today
<luigi1112> is he copying me
<vtnerd1112> rebase, damn phone
<fluffypony> vtnerd1112: I haven't since looking at it the first time, sounds good
<endogenic> lol
<fluffypony> luigi1112: yes
<fluffypony> /nick fluffypony1112
<xmr_eric> Ok, well I'd like to hear from Jaquee. But my thoughts are that we rename Monero GUI back to Monero Core. Gingeropolous originally named it back to Monero GUI at the time, which was a decent idea, but I think in the end the central Monero software that the public is going to use should be called Core
<fluffypony> @xmr_eric that was among the reasons for calling it Core initially
<xmr_eric> I spent some time yesterday trying to find a word other than Core to differentiate ourselves from Bitcoin, like Monero Essentials or something, but none really work as well.
<xmr_eric> Right. I think we should go back to that.
<fluffypony> also because I think that the current monero repo will become libmonero
<pero> and then monero-cli?
<fluffypony> yeah
<pero> makes sense
<Jaquee> so we end up with 3 repos?
<Jaquee> gui, cli and lib?
<fluffypony> Jaquee: yes eventually
<Jaquee> ok cool
<fluffypony> Jaquee: what are your thoughts on GUI vs. Core
<Jaquee> libwallet API is only used by gui for now. so i'm thining it could be moved to gui repo.
<Jaquee> i would prefer GUI
<Jaquee> https://github.com/monero-project/monero-core/issues/663
<endogenic> how about 'official' instead of 'core'? cause it'll be specified as the official 'gui', cli etc
<xmr_eric> This isn't just naming the repo, this is naming the piece of software the repo produces
<bigreddmachine> As for names, I assume "Monero Qt" is out? That was once the standard for cryptocurrency wallets but seems to have lost favor.
<xmr_eric> Essentially, it is branding
<pero> if we're going to have lib and cli, and those seems like the optimal nomenclature for those, then i think the logical one for the gui is gui
<Jaquee> +1
<endogenic> or maybe core gui..
<xmr_eric> The public doesn't think in terms of CLI GUI
<xmr_eric> People won't know what GUI means
<Jaquee> do they know what core means?
<Jaquee> i don't :P
<pero> yea but core is kind of confusing since core seems to be lib
<fluffypony> pero: I was thinking more like libmonero, monero-tools, monero-core
<bigreddmachine> pero: i'd argue the optimal name for a gui should not have "gui" in the name. They aren't called FireFox GUI, Chrome GUI, Word GUI, etc
<gingeropolous> just Monero
<xmr_eric> No, but the point is Core is a word that people will begin to associate with that piece of software
<hrumag2> gingeropulos I agree
<xmr_eric> What does Linux mean?
<jwinterm> I think core does have a bit of stench to it now
<hyc> at worst, monero app
<hrumag2> The application has to be the most atomic
<jwinterm> bigreddmachine: there's no lynx like version of firefox or chrome tho
<jwinterm> that I'm aware of
<hrumag2> To the public I mean
<xmr_eric> The problem with naming it just Monero is that no other piece of software gets to be called Monero
<xmr_eric> Which I'm ok with
<pero> yes i can see reason in that argument bigreddmachine
<hyc> MoneroUser
<xmr_eric> But it isn't good from a nomenclature standpoint
<bigreddmachine> "Monero Wallet"?
<pero> what's monero-tools fluffypony ? the cli?
<fluffypony> pero: yes
<fluffypony> especially since they ship with the GUI
<sgp> ^ anyone can make their own wallet
<moneromooo> Could we maybe get on with the dev meeting...
<fluffypony> so that seems to make some sense
<fluffypony> ok let's table this for the next meeting, we can open a thread or discuss it further under an existing one
<fluffypony> s/thread/issue
<xmr_eric> Great
<hrumag2> At least "Monero node", "Monero wallet cli", "Monero wallet gui"
<gingeropolous> moneromooo, I like this bike shed. It can fit many bikes
<fluffypony> and then we'll make a decision at the next meeting
<Jaquee> sounds good
<anonimal> Two cents: 2 repos: libmonero and monero. monero has optional cli build alongside gui.
<fluffypony> ok so 4. GetMonero.org redesign discussion
<fluffypony> rehrar wanted to show us the designs and get our input on it
<rehrar> I don't want to take much time. Just want to get a special opinion from all the devs about the two proposed designs.
<rehrar> If you haven't seen them already, you can find them here
<rehrar> Design 1: http://imgur.com/a/MwyxX
<rehrar> Design 2: http://imgur.com/a/H9i3z
<anonimal> github link too?
<unknownids> design 1 third draft imo
<rehrar> The idea will be to redesign the current website and also to make an assets document that will have the HTML and CSS framework that we make so anyone can easily make more pages.
<i2p-relay> {-olark} Will these sites still be usable with javascript disabled?
<rehrar> No JavaScript will be used.
<anonimal> https://github.com/monero-project/monero-site/issues/245
<rehrar> All in Jekyll
<rehrar> Sorry, thank you anonimal
<vertp> design 1 - draft 3 is the most popular on reddit. Most people are asking to add some of the community sponsored youtube vids to the homepage as well.
<hrumag2> 1 totally. Marketing addicted
<pero> im pretty big on the 2nd one
<gingeropolous> will these sites still be editable via github by random people, like the current site?
<fluffypony> design 2 is nice, but a little too clean
<fluffypony> gingeropolous: yes
<pero> the first one is too generic and reminds me of shitty webapps/startups
<pero> first one with some tweaks
<pero> erm
<endogenic> i agree, maybe some pretty-fication to #2
<aerbax> I think it's important to include one of the Monero introductory videos on the frontpage of whatever design is chosen.
<pero> second one*
<i2p-relay> {-olark} Ok
<endogenic> cause it's an OSS / tech project after all
<fluffypony> vertp: I don't know if we really need multiple videos on the home page, just the intro one
<rehrar> I think the second design is the most modular and easy to adapt to others making more pages as the site progresses after I'm done with it.
<Jaquee> i also prefer #2
<sgp> As I mentioned, I still like 1.3 the best. 2 is still better than what we have right now though
<anonimal> Since no one here will probably read that github issue, #2 looks like a tech spec but #1 can be worked with. If reddit has good response for #1 draft 3 then that direction is something to consider.
<fluffypony> endogenic / pero: I'm leaning that way too
<tewinget> didn't realize we were doing a meeting this week; I'll be around in like an hour, have to catch a bus.
<vertp> fluffypony: yes, good point. shouldn't have used the plural tense.
<rehrar> We were playing with adding some color to design 2
<fluffypony> anonimal: otoh we can take some of the elements from design 1, draft 3 and incorporate them into design 2 - @rehrar?
<rehrar> And I think we have a good idea of how to do it.
<rehrar> We should have something for it soon.
<rehrar> Yes, we'll work on that.
<pero> site should be an information portal ultimately, the first design is getting the user to download an app asap imo
<rehrar> Any particular things from that design to Port?
<pero> it is not aligned with what the site's goals should be
<gingeropolous> i like #2
<rehrar> I agree.
<anonimal> Site's goals? It's a website.
<pero> yes the goal of providing information
<rehrar> Monero is a unique project, and having a standard site is doing Monero a disservice imo.
<fluffypony> @rehrar the world background and the different sections are nice
<fluffypony> backgrounds for different sections I mean
<rehrar> I agree that design 2 is a bit sterilized.
<anonimal> Old people need to be able to use this too. Old people don't like to read most of the time because fonts are too small and if they are computer illiterate they don't know how to zoom.
<anonimal> Technical illiteracy = most of planet earth.
<xmr_eric> Websites are absolutely about a main goal first. That's what good design is about. Funneling people into a path that they already want to go. Eg "What is this Monero thing?"
<pero> that argument is pointless anonimal
<pero> old people that are actively using the internet have learned how to deal with those issues
<fluffypony> anonimal: old people aren't going to use Monero, they'll use some L2 or L3 system on top of it
<anonimal> pero this is a dev meeting, feel free to leave anytime.
<anonimal> You are not a dev.
<pero> else they wouldnt be using it
<pero> lol
<fluffypony> so it's also got to serve the target audience
<moneromooo> Yeah, maybe we could have dev meeting and monero meeting.
<rehrar> If the overwhelming majority thinks design 1 even after draft 3 of design 2 then I will probably go with it
<fluffypony> moneromooo: this is specifically to get dev input on the design
<rehrar> But we're going to add some color to the design 2.
<hrumag2> I think it should be given more underlining about how to buy Monero. Where do you think to put the link?
<rehrar> Monero just has very...Specific branding colors. XD
<fluffypony> @rehrar let's see what you come up with on design 2 and then see
<rehrar> Aight. Will do.
<fluffypony> hrumag2: no, definitely not, that sort of funnel makes us liable
<hrumag2> ... more than "get involved" I think
<anonimal> When I say 'old', I mean plebeian elders of planet earth.
<rehrar> That's all from me.
<rehrar> Any last second opinions?
<pero> i have a concern with project scope/budget
<pero> i think the work effort is being underestimated and it's underbudgeted
<rehrar> Not underestimated, but underbudgeted for sure.
<fluffypony> @rehrar well we do a second FFS if needed, let's see how it goes
<rehrar> On purpose. Part of it is my donation to the community. I believe in it.
<rehrar> Ok. :)
<fluffypony> ok on that note
<fluffypony> let's move on to 5. Any additional meeting items
<fluffypony> only thing I want to ask is just to find out from Jaquee if he managed to get hold of Qt
<Jaquee> no, sorry. i've had a busy week
<moneromooo> Well, I had this list of bugs I think can be closed. Which should be greppable with mooo.*bug.*clos
<Jaquee> will take care of that issue in a couple of days
<fluffypony> np
<fluffypony> moneromooo: yep I'll be closing issues in the next few days too
<moneromooo> Thanks.
<fluffypony> anything else?
<bigreddmachine> I have a Q: What is the "correct" way to propose an improvement / protocol change to Monero? Bitcoin has the BIP system, whereas for Monero things are basically handled via GitHub issues in the main repo. That means that, though discussions are documented permanently, they can be difficult to find and track over time. Is Monero getting to where it is big enough and has enough contributors that maybe we s
<bigreddmachine> hould have a BIP-like process?
<fluffypony> bigreddmachine: easiest way is just for us to have a label on Github (for consensus-critical changes)
<i2p-relay> {-olark} I have a few things I would like to talk about regarding https://github.com/monero-project/monero/issues/1673 I should post another update soon
<i2p-relay> {-olark} I can wait
<bigreddmachine> fluffypony: but is that the ideal way to do it? after getting merged, closed, etc, those discussions are very tough to find. Something like BIP is a much better long-term place for those discussions
<fluffypony> bigreddmachine: I think that changes should be written up as an MRL paper
<bigreddmachine> I'm not asking because I have a specific proposal to make, but because it seems we don't have an ideal system that can grow well
<bigreddmachine> fluffypony: and submitted to MRL?
<fluffypony> yes
<fluffypony> available permanently as an MRL research bulletin, which makes recommendations to the implementors, and exists as a living document
<bigreddmachine> okay - then shouldn't that be the case for anything consensus changing?
<bigreddmachine> what got me thinking about it is that the discussions behind this month's hard fork are very tough to find. i know it's a small change, but i feel like we don't have a precedent set
<fluffypony> bigreddmachine: mostly yes, although I think some things are a little small to write up and might have to be bundled together
<fluffypony> let's give that a spin and see how it goes, we can always change the process later on
<bigreddmachine> what makes something "too small" though? I guess my point is that maybe we need to add guidelines to the main repo that explain all this for people to see in the future
<fluffypony> olark: do you want to discuss 1673 now? we still have 19 mins before the Kovri meeting
<bigreddmachine> I am happy to do that and make the PR,
<i2p-relay> {-olark} Sure
<i2p-relay> {-olark} I just wanted to talk about a couple quick things
<fluffypony> bigreddmachine: it's subjective - when we changed the block time from 1 min to 2 mins, for eg., the reasons were obvious - yes please do write it up and PR it
<i2p-relay> {-olark} What people think about having 3 static ringsizes for monero similar to how we have static fee priorities.
<i2p-relay> {-olark} This was an idea moneromooo had brought up in the issue
<sgp> What ringsizes are you proposing?
<i2p-relay> {-olark} To protect users from making foolish mistakes reusing irregular ringsizes
<moneromooo> I was about to write "I like it", so I now see why I do... :D
<fluffypony> olark: I like it because it removes fingerprinting / metadata leaks
<i2p-relay> {-olark} Well if September is mandatory 4 i was thinking like 4, 12, 50 or something similar the details don't matter at this moment but just what people think about having this in place.
<fluffypony> I'm fine with it, but 4 is way too small as the minimum, even per the old MRL recommendations
<i2p-relay> {-olark} The other thing was since I have been surveying the bitcoin blockchain for a while there is large bias for spent outputs in the past day
<bigreddmachine> to clarify - unlike fees, which could be changed on the user-end to something else, this will make non-standard ring sizes be against the consensus protocol?
<i2p-relay> {-olark} and how this affects the attack in MRL-001
<fluffypony> bigreddmachine: yes
<moneromooo> We could wait to see luigi1112's final ringct sizes, then see how those vary with increasing mixin.
<fluffypony> moneromooo: agreed
<jwinterm> why only three choices?
<fluffypony> jwinterm: so that people actually use the two other than the default
<moneromooo> To avoid splitting txes in too many classes.
<sgp> So how about 10, 20, 50, 100? Something like that. Pending the research of course
<fluffypony> you want to get lost in the mix, remember :)
<vtnerd1112> So fireice_uk is working on the rpc download changes before any crypto stuff ... ?
<i2p-relay> {-olark} The assumption in MRL-001 is that an attacker would need roughly 80% of outputs in the entire blockchain to de-anon a transaction but in reality if we use an output selection algo similar to what my survey results convey than in reality an attacker would only need 70%ish of spent outputs in the past day to reliably de-anon some transactions
<vtnerd1112> Oops thought that topic was done
<sgp> ^ with what ringsize?
<fluffypony> vtnerd1112: yes - we decided in the last meeting that he'd switch milestone orders around
<moneromooo> Oh, that ought to be done on 0MQ then.
<i2p-relay> {-olark} Smooth and myself had come to a conclusion that mixin 4 is fine but if the attack in MRL-001 is made easier with a selection algo like I am suggesting we may need to increase the mandatory ringsizes to protect against an attack like MRL-001
<fluffypony> olark: this changes with zipf, right?
<fluffypony> ie. a great portion of the ring uses the past day's outputs
<vtnerd1112> Ok, pigeons told me mymonero seemed to be under lots of load. Ive got some preliminary work done that he could continue to completion
<vtnerd1112> Just enough to give mymonero a bump hopefully
<fluffypony> vtnerd1112: that's fine, maybe ping him and tell him that? fireice_uk never attends dev meetings and is never on IRC
<moneromooo> Maybe that's not actually bad.
<i2p-relay> {-olark} What to increase it to is up in the air obviously. Still have more work to do
<i2p-relay> {-olark} fluffypony: Yes. Based on the survey I have done so far roughly 70% of spent outputs are from the past day. Future surveying will be going over 2011-2012 to see if there is any change in the distributions.
<fluffypony> ok I'm fine with that - olark, what are your thoughts on writing it up as an MRL paper later on once the discussion is finalised?
<moneromooo> I think current min is still 2. We could go to 4 in september, and still increase later.
<sgp> I think we should increase it >4 in September
<bigreddmachine> -olark: is there a way to see what the distribution looks like for txs not related to mining? i'd guess a lot of the quickness in spending is from pools transfering out coins to miners, but in the future this might be a much smaller proportion
<xmr_eric> Are we still playing around with having a static ringsize?
<moneromooo> Pool payment txes are often with more than 2 outputs.
<sgp> @xmr_eric yes
<xmr_eric> Cool
<fluffypony> moneromooo: with the new range proofs etc. it might be worthwhile just making the min based on that
<moneromooo> Not a guarantee of course. Especially now -_-
<i2p-relay> {-olark} fluffypony: Sure I can write an MRL paper once I have more of it fleshed out.
<fluffypony> can always use like a 10 output tx as a measuring bar
<moneromooo> fluffypony: sounds good
<gingeropolous> ^ interesting
<i2p-relay> {-olark} xmr_eric: The idea is having 3 static ringsizes for varying levels of paranoia similar to the different fee priorities we have.
<xmr_eric> Right
<bigreddmachine> moneromooo: if we're just looking for a filter on pool txs, we can always use the pools' apis to get txids. my point was those txs might be 50% of all txs now, but 5% two years from now, which impacts the math.
<gingeropolous> are disposable / one-time addresses happening? I didn't see it make the list of things not to pull in.
<moneromooo> That allows me to...
<moneromooo> luigi1112: is kenshi84's disposable address patch ready in the theoretical sense, you think ? ie, can I go over it again assuming the math/crypto's final ?
<fluffypony> I haven't looked at it in a while, I'll have to re-review the PR to both the MRL and normal repos
<fluffypony> ok we need to wrap up - let's discuss it further later on
<fluffypony> 6. Confirm next meeting date/time
<fluffypony> April 23

An Unofficial Response to "An Empirical Analysis of Linkability in the Monero Blockchain"

Wed, 19 Apr 2017 00:00:00 GMT

Preface

This release attempts to contain the opinions of the Monero community. It is possible that not every viewpoint is expressed, but this paper includes the best response to the author's ability that encapsulates all these opinions. The author opens all discussion to how certain viewpoints are represented, and the purpose of this response is solely for easier documentation by interested parties. He has done the best to include sources wherever possible, and to be as accurate as possible. For any concerns with this publication, please express them to the author's Reddit account or on the Monero subreddit. This version has been updated for clarity, though the core content has remained unchanged.

The Monero contributors and community at large always appreciate any research done on Monero's technology. They heavily encourage constructive criticism of all cryptocurrencies.

Notable Findings

The Monero contributors appreciate the effort that has gone into this mentioned publication and research methods. It helps quantify several realizations that had already been known to the Monero community at large for a long time (ref: MRL-0001 and MRL-0004), including the following:

0-mixin transactions (those that only include the real input and no others) are traceable on the blockchain. MRL-0001 (published September 2014) also points this out, and Monero reacted to the concern by prohibiting 0-mixin transactions from the network in April 2016. The current minimum mixin allowed on the network is 2, which was mandated in March 2016. In September 2017, the minimum will be increased to at least 4, though there is some discussion going on in the community to choose the exact value. For clarification of terms used, ringsize is a newly-adopted term to replace mixin with the intentions of removing comparisons to traditional mixing services. Ringsize = mixin + 1.
The prohibition of 0-mixin transactions has allowed the network to recover relatively quickly by making it harder to know which input is used. This paper helps quantify this recovery, from about 95% traceable to 20% traceable (see appendix).
The proportion of transactions that have their inputs deducible has fallen substantially from 1 January 2016 to 1 Feb 2017 with 2 and 4 mixin transactions. Respectively, these fell from 82% and 72% to 41% and 23% (see appendix). Furthermore, this proportion is down to 0% with RingCT transactions, which are now over 99% of all new transactions on the network.
The phenomenon where the most recent input is the real one is a concern when using Monero. There is no way to prove that this input is indeed the correct one, and with recent transactions, the assertion is nearly impossible to prove and is accurate less than half of the time. As the report states, there is about a 40% chance that the most recent input in a default transaction is the real one. Ideally, this number should be closer to 20% (1 in 5). Note that this does not mean that there is a 40% chance that this transaction is traceable (see appendix). Increasing the transaction ringsize has only a marginal improvement.

Recommendations and Responses

The following are the recommendations listed in the paper and responses to them:

The mixing sampling distribution should be modified to closer match the real distribution. We agree with this recommendation. The discussion covering the possible ways to do this, along with all associated research, can be seen on GitHub . As the paper acknowledges, we made a temporary improvement to the selection algorithm to choose more recent inputs (instead of pure random selection) in December 2016. Further improvements are required, and they are planned to be ready before or at the September 2017 hardfork date. As the paper notes, this change is not consensus-critical. It can be done the day after completion without a hardfork.
The Monero community should engage in further data-backed analysis of privacy claims. We agree with this recommendation. Data-backed claims are an excellent way to improve the Monero privacy and security features. As stated in the paper, the threats discussed in the paper were discussed in the community previously. Unlike the paper claims, these discussions were not "informal"; instead, they were published in our MRL-0004 research paper in January 2015. Nevertheless, several of these attack vectors explained in the Decentralized Systems Lab paper are quantified for the first time.
Monero users should be warned that their prior transactions are likely vulnerable to linking analysis. We mostly disagree with this recommendation. The vulnerabilities of 0-mixin transactions were well-documented and continuously shared with the Monero community while they were still allowed. The first research paper shared in the Monero community (MRL-0001) was published in September 2014. Furthermore, most of Monero's community growth occurred after these 0-mixin transactions were prohibited across the network.

Concerns

The Monero community would like to list several concerns with this research paper. They are documented below:

We believe that a large proportion of 0-mixin transactions are pool payouts. These transactions should come to no one's surprise that they are traceable, since the pools themselves publish the payment amount to each transaction hash. Thus, we believe that the claims stemming from the traceability of transactions before 0-mixin transactions were banned to be misplaced. If, for example, 50% of non-pool payouts used a positive mixin and 0% of pool payouts did, then the traceability is less for the transactions that use these mixins and greater for pool payouts. We recommend that this is acknowledged in a later iteration of the paper. Ideally, the proportion of pool payouts can be found and compared to the proportion of non-pool payouts, with different traceability proportions for each. There are several reasons why these transactions neither reduce the anonymity of the transaction itself or other users. In regards to the former, coinbase transactions (ie: new rewards given to the pool) are 0-mixin, since having mixins is useless if the input is brand new and seen for the first time. Anyone who mines understands that the source of their money is clear, and so pools received little pressure to increase the ringsize for payout transactions. In regards to other transactions, the pool payouts occur within the day, reducing the negative impact spending these transactions has on other users who may have borrowed the input for their transaction. Thus, pool payouts should include additional mixins, but excluding them has relatively minimal harm. The larger threat is the opportunity cost, where the additional mixins could provide greater levels of privacy for other users. Furthermore, all transactions are still unlinkable by the MRL definition of the word (see "Other Information" point 4) (source).
We think further emphasis should have been placed in the paper to explain that the claims are only minimally applicable with the state of Monero transactions since March 2016, with the relevance decreasing over time. Though it is mentioned that their first analysis method has little if any current or future relevance, the claims still include these transactions. 0-mixin transactions were prohibited in March 2016, and most transaction volume for the year occurred during and after August. Nevertheless, many of these post-March transactions have inputs that can be deducible, but the traceability typically is not as severe as with 0-mixin transactions. The transactions that are most vulnerable are those in 2014 and 2015, as well as some time needed for the network to recover.
Under the "ethics" section, they state that the paper was published immediately before countermeasures could be deployed. While this is understandable from the given perspective that the blockchain history is not going away anytime soon (or ever), we wish that they had given us an advance copy of the finished draft so that we could have discussed our concerns with the report itself. We wish not to censor any of the research (instead, we encourage research!); however, we hope that future care can be taken before the release of misleading assertions.
Andrew Miller was named in the paper as a consultant to the Zerocoin Electric Coin Company and a board member of the ZCash Foundation. ZCash is a cryptocurrency with a focus on privacy that uses different technology than Monero. However, he downplayed his involvement in an interview about this paper. We feel author involvement in cryptocurrencies with similar interests should be fully disclosed, though he did refer people to the first page of the report. Nevertheless, we feel that Miller's disclosure of his contribution to a competing project was unsatisfactory, given the severity of the allegations in the paper.

Other Information

The timing of the publication. This paper was released approximately an hour before the hardfork. While it is impossible to know the reason for the specific timing without an admission, we speculate that this was timed to draw as much attention to the paper as possible. More people would have been tuning in to see how the hardfork was proceeding than typical community participation traffic. Andrew Miller has responded to this criticism in a Reddit comment, saying "the timing of our release with the imminent hard fork was totally unintentional and a coincidence. No one on the team noticed there was a hardfork planned, and we'd definitely have delayed till afterward if we had."
This paper was shared as "new research" about Monero. While the research is itself new and some of the analysis is the first time that some concerns have been quantified, these concerns themselves are not new. In sharing the paper, the authors often posted misleading claims that asserted these concerns were new.
The Monero Core Team was given an advance draft of the report on 15 March 2017. This report at the time looked only at transactions before January 2017. All further edits to the paper were published before consulting with the Core Team. Riccardo Spagni, known to many as fluffypony or fluffyponyza, responded commending the efforts and stated at the time that the 0-mixin analysis confirmed previous work on MRL-0004. During the email exchange, Spagni suggested that the research also be published in the Monero Research Lab research, an idea Andrew Miller seemed open to at the time. Furthermore, the real release date was later than the target given to the Core Team, and the Core Team was not given a new estimated date of release.
The paper refers to the traceability of transactions in the blockchain as "linkability". We encourage the authors to change the terminology to "traceability", since linkability typically refers to the ability to connect cryptocurrency wallet location to real-world locations. This will help clear up misconceptions held by many community members, since the Monero Research Lab refers to the connection of funds within the cryptocurrency as "traceability."
This paper has not yet been published, is not finalized, and is not yet peer reviewed. Thus, there will most certainly be changes to this research paper before publication. We suggest that all claims and research be taken as preliminary and not concrete, since not enough people have evaluated their methods of research yet.

Conclusion

We appreciate the effort that went into this research paper, but we suggest the following changes for later improvements:

A re-evaluation of recommendation #3.
A consideration among 0-mixin transactions for pool payouts.
A clearer explanation of claims made in the paper, with separations for the history of all transactions and those used since March 2016. It is disappointing to treat the blockchain data as static when the technology has evolved significantly since Monero's launch.
Future drafts to be shared with the Monero Core Team before release. Their contact information is dev@getmonero.org.
Be more conservative sharing the results. We understand that the authors have an incentive to share the results with others and we also want them to be shared, but we ask that they refrain from using misleading claims to gather traffic (see appendix for example).
Consider cooperating with Riccardo Spagni to permanently include the research portion of this paper in our Monero Research Lab documents.

Appendix

Figure 5 from the report showing the fraction of deducible inputs. Notice the large drops following block height 1,000,000, when 0-mixin transactions were prohibited. Furthermore, these inputs likely do not include all those used in a single transaction. For instance, for a mixin 9 transaction, 5 may be deduced. This means that the inputs would be reported here as deducible, even if the transaction is not traceable.

Table 2 from the report showing the proportion of transactions with a positive mixin that can be deduced. We want to make clear that the findings of this chart and analysis method have absoutely zero relevance to RingCT transactions.

Table 3 from the report showing the proportion of deducible transactions where the real input is also the most recently used one in the transaction.

Examples of statements we find misleading

This is a tweet from a contributor to the paper.

This image is from the CoinTelegraph interview. Based on the wording, you may think an attacker could determine with certainty which input is yours. However, the attacker can guess and be correct less than half of the time. Furthermore, even if the attacker guesses correctly, there is no way of proving this with certainty with data from the blockchain alone.

Andrew Miller asked us to include other statements from the researchers or ZCash Foundation members that we feel is misleading. This paper is not supposed to be a comprehensive list of such statements. It is only useful in providing a few examples.

This draft was shown to Andrew Miller before release on the website. Some of his considerations have been included in this response.

Logs for the Kovri Dev Meeting Held on 2017-04-23

Sun, 23 Apr 2017 00:00:00 GMT

Logs

Logs for the Kovri Dev Meeting Held on 2017-05-07

Sun, 07 May 2017 00:00:00 GMT

Logs

<anonimal> 1. Greetings
<anonimal> 2. Brief review of what's been completed since the previous meeting
<anonimal> 3. More preparation for 96boards.org OpenHours showcase for Kovri / Monero (@fluffypony @danrmiller location status)
<anonimal> 4. Status (again) of Monero HackerOne umbrella and bounty. hackerone.com/monero is online but we need to resolve FFS funding before inviting researchers. VRP status for all projects + bounty status
<anonimal> 5. Open forum for https://github.com/monero-project/kovri/issues/630
<anonimal> 6. Website status (@rehrar @bigreddmachine @alvinjoelsantos @danrmiller)
<anonimal> 7. @EinMByte ...where is he? Github repo privilege discussion
<anonimal> 8. Code + ticket discussion / Q & A
<anonimal> 9. Any additional meeting items
<anonimal> 10. Confirm next meeting date/time
<anonimal> Hello
<moroccanmalinois> hi
<sgp> hey!
<endogenic> o/
<ajs> Here
<iDunk> \o
<i2p-relay> {-fluffypony} hi!
<rehrar> Here for a bit, then gone, then back.
<anonimal> Yay, enough people for a party.
<Heretoobserve> Hello
<anonimal> 2. Brief review of what's been completed since the previous meeting
<rehrar> 3...2...1... KOVRI!!!
<ArticMine> hello
<anonimal> For me, see http://forum.getmonero.org/9/work-in-progress/86967/anonimal-s-kovri-full-time-development-funding-thread?page=&noscroll=1#post-90900
<anonimal> moroccanmalinois can fill us in on his work.
<moroccanmalinois> i've been playing with fuzz testing
<i2p-relay> {-fluffypony} nice
<anonimal> I've looked through the PR's, looks like fun.
<moroccanmalinois> it's the beginning. More tests to come
<anonimal> Any questions/comments on point 2?
<i2p-relay> {-fluffypony} and guzzi ?
<anonimal> guzzi is not here, ...again...
<anonimal> He says he's doing work but I haven't seen a commit or question from him in over 7 weeks, AFAICT.
<anonimal> I think he's trying to separate the contexts from the singleton. At least that's the end goal.
<i2p-relay> {-fluffypony} guzzi: when you read this, please make an effort to attend meetings
<i2p-relay> {-fluffypony} I know you're around at other times, but meetings are important
<anonimal> Yes, please.
<anonimal> Ok, anything else on 2.?
<i2p-relay> {-fluffypony} no
<anonimal> 3. More preparation for 96boards.org OpenHours showcase for Kovri / Monero (@fluffypony @danrmiller location status)
<anonimal> Is pigeons still in Africa? This point was moved from last meeting.
<i2p-relay> {-pigeons} i returned yesterday
<moneromooo> Are you suggesting pigeons migrate ?
<i2p-relay> {-pigeons} i saw rock doves
<anonimal> fluffypony? How's it going?
<i2p-relay> {-fluffypony} anonimal: it's a podcast, right?
<anonimal> https://www.96boards.org/openhours/, there are videos too.
<i2p-relay> {-fluffypony} ok well I'm ready whenever
<i2p-relay> {-fluffypony} I don't really prepare for stuff like this
<bigreddmachine> sorry i'm late!
<anonimal> Ok well what time/date works for you?
<anonimal> fluffypony ^
<i2p-relay> {-fluffypony} anonimal: my PA would have to schedule it - probably best to get my PA to schedule myself and pigeons and them
<i2p-relay> {-fluffypony} she's good at that
<i2p-relay> {-fluffypony} it's literally her job :-P
<i2p-relay> {-pigeons} I was thinking ask hyc if he's interested, he's been playing with arm and monero i think
<i2p-relay> {-fluffypony} cool
<i2p-relay> {-fluffypony} hyc is a beautiful man
<bigreddmachine> +1 Ric's PA. She was great when i wanted to schedule a podcast
* anonimal pinged him in #monero-dev
<anonimal> Ok well at this point, IMHO, fluffypony I think it would be good for you to touch base / introduce yourself to sdrobertw in #OpenHours on freenode.
<anonimal> I think I can only play the middleman for so long.
<i2p-relay> {-fluffypony} email is better for Shay, I don't think I can teach her IRC :-P
<anonimal> Contact info? I have none.
<i2p-relay> {-fluffypony} for them?
<i2p-relay> {-fluffypony} didn't we reach out to them via email first?
<i2p-relay> {-fluffypony} * can't remember
<anonimal> For Shay
<anonimal> No, not via email, all IRC.
<i2p-relay> {-fluffypony} oh lol
<i2p-relay> {-fluffypony} pa@spagni.net
<anonimal> Alright, anything else on this point before moving on?
<anonimal> 4. Status (again) of Monero HackerOne umbrella and bounty. hackerone.com/monero is online but we need to resolve FFS funding before inviting researchers. VRP status for all projects + bounty status
<anonimal> I've sent a VRP to monero, it's been merged. I believe we're funded at ~500 XMR, which is great.
<anonimal> Any questions?
<anonimal> We just need to launch after submitting VRP to the GUI (and site?)
<anonimal> Sound good?
<bigreddmachine> Is the bounty held in xmr or something else?
<anonimal> Yes. Link to FFS in the meta issue.
<ArticMine> https://forum.getmonero.org/8/funding-required/87597/monero-bounty-for-hackerone It was funded to 500 XMR and then increased to 1000 XMR for further funding
<bigreddmachine> ty
<anonimal> I think we can start now before funding is at 1000.
<anonimal> (it won't mean we'll find researchers immediately anyway)
<anonimal> Any questions/comments before moving onto next point?
<i2p-relay> {-fluffypony} yrah
<i2p-relay> {-fluffypony} agreed
<i2p-relay> {-fluffypony} we can continue to increase it as necessary
<anonimal> Ok. Moving on,
<anonimal> 5. Open forum for https://github.com/monero-project/kovri/issues/630
<anonimal> Comments needed before we move on this.
<i2p-relay> {-fluffypony} I agree with MoroccanMalinois, but I think it's manageable if we set a severity
<i2p-relay> {-fluffypony} and some caveats
<moneromooo> Maybe a strict validity domain definition would do good (ie, "we only accept vulns in the following categories").
<moneromooo> And then expand the list as stuff matures.
<bigreddmachine> moneromooo - why would we restrict?
<moneromooo> To prevent known problems from being reported, or problems in stuff that is known to be unfinished.
<i2p-relay> {-pigeons} because the code has a bunch of legacy mess and is early state with low hanging fruit that is just later on the to fix when that section gets refactored
<anonimal> Yes. So, with that said, I don't know what categories we could even have.
<anonimal> at this stage
<anonimal> moneromooo: did you have any ideas on categories for this stage?
<moneromooo> No. I've not really looked at kovri yet, despite saying I would (sorry).
<i2p-relay> {-pigeons} i2p consensus related issues
<i2p-relay> {-pigeons} if we implement like X we might cause incompatibility
<i2p-relay> {-pigeons} maybe those but again maybe those are known and will be fixed when those sections are given love
<moneromooo> Anything which can leak keymat. Good starting point.
<moneromooo> Ideally you'd start giving bounties when you know you've done what you could, and the bounty to find bugs is less than what your time is worth looking at it :)
<anonimal> pigeons: Well, then I think that's java I2P's problem because they would then have to keep up with us. What we could do now though is start with a research-related category for general specifications?
<moneromooo> So it's a bit subjective.
<anonimal> moneromooo: indeed, and this is border-lining on simply hiring a new dev too with the funds available.
<moneromooo> Well, the draw is that the bounty ensures results for the money.
<moneromooo> So expert time.
<anonimal> What if we opened bounty for non-implementation research? I know this is an MRL area though.
<anonimal> Or we could open more categories for implementation but the payout is smaller because code is Alpha?
<moneromooo> For finding bugs in the theory, definitely worth doing so (for monero anyway, I expect kovri's following established research already).
<anonimal> (then they would risk waiting to beta to 0day to get bigger payout?)
<rehrar> what up kids? I'm here.
<anonimal> I think monero's research is more vetted than I2P's, even though I2P has been around longer. Simply because there are less moving parts.
<moroccanmalinois> +1 for bounty for non-implementation research
<moneromooo> Interesting.
<anonimal> Just my opinion. I've read the I2P papers available, I'm not blown away but it's better than nothing.
<anonimal> And not like I'm in a position to drop everything to do purely research so...
<anonimal> We'll add categories for bounty? One obvious one being research. Maybe crypto implementation sooner than later since that's a big one.
<anonimal> Sound fair?
<moneromooo> From a relative outsider, it seems like a sensible start.
<bigreddmachine> yes. is "leaked info" too broad of a category?
<moroccanmalinois> yes for me
<anonimal> Yes because a leak would cover too much code that hasn't been vetted.
<anonimal> * could cover
<anonimal> Ok, I'll get that going then.
<anonimal> Moving on. 6. Website status (@rehrar @bigreddmachine @alvinjoelsantos @danrmiller)
<i2p-relay> {-pigeons} I need to talk with fluffypony about a potential dns thing
<rehrar> aight, so just in case somebody hasn't seen the Kovri web design here it is: http://imgur.com/a/An8K8
<rehrar> it's the top one
<i2p-relay> {-pigeons} then the demo of ajs' site should be up
<i2p-relay> {-fluffypony} I got msgs about it
<i2p-relay> {-fluffypony} will look at it tomorrow
<rehrar> it's based on the same framework as the getmonero.org website, so once the custom framework is made for one, it is easy to make pages for the other
<rehrar> my update is that we're making the framework even now, and it's coming along well, I should be able to make a few experimental Kovri pages soon
<rehrar> The question is content.
<anonimal> I think the "It's I2P, but in C++" phrase should go; we should use our standard "A secure, private, untraceable C++ implementation of the I2P anonymous network"
<ajs> I will work with rehrar to write up some content, but need direction on what should be included.
<rehrar> that's fine. Copy is not indicative. :)
<bigreddmachine> My past month has been packed getting ready for my phd comprehensive exam (1 step before the defense). So I haven't looked at the site yet, but talked briefly with ajs about it and plan to get more involved now that that's done.
<anonimal> Other than that, can we move this item to the website meeting in #monero in 10 minutes?
<rehrar> sure, that sounds alright.
<moneromooo> It looks nice (says the cow who's got no clue about design).
<ajs> K
<anonimal> bigreddmachine ajs: will you be around in 10 minutes in #monero?
<ajs> Yes
<bigreddmachine> yeah, i'm also editing tonight's podcast episode so i may take a minute to reply
<anonimal> rehrar: yes, what moneromooo said, looks nice
<rehrar> cool. If people have ideas for content that are not on the demo site
<anonimal> Ok, moving on. 7. @EinMByte ...where is he? Github repo privilege discussion
<rehrar> let me know
<rehrar> I'd like to have a simple website for alpha release :)
<anonimal> fluffypony: so... his last commit was from Septemeber 19th, he's not responded to 99% of my pings since then...
<bigreddmachine> i haven't seen him since i started getting involved in Jan
<anonimal> I speak highly of him and his work, I think he's a great contributor and wish he was around more.
<bigreddmachine> could be a legal issue?
<anonimal> The problem is he's not around anymore, he has assigned issues of which I've had to assign myself since he's not around to do them.
<anonimal> And he has repository push access. If something happened to him and his account is compromised, we could be left in an embarrassing trolling situation where someone deletes the repo.
<anonimal> I don't want to send any wrong signals but I also think access privileges should be on an as-needed basis.
<bigreddmachine> i think that's fair. can always be re-established if he comes back and he can be verified
<bigreddmachine> in that vein, should things like Salti tracking be moved to another place?
<anonimal> I don't know, we'll have to bring that up at the next meeting I think since we're running out of time.
<anonimal> fluffypony: any thoughts about this? Will you remove EinMByte's github push access privileges?
<moneromooo> I think it's fair to revoke for inactivity and failure to reply to pings. Reinstate when back.
<bigreddmachine> okay, can we add #619 to next meeting's agenda?
<moneromooo> I'd also want to remove warptangent's key (unlikely to be back to use it) and a few others.
<anonimal> bigreddmachine: oh, sure I guess, more research/info needed.
<bigreddmachine> k i'll just reply to the issue and talk about it there for now. sorry to jump into other discussion about that.
<anonimal> No problem
<anonimal> Since we're running out of time, 8. Code + ticket discussion / Q & A
<bigreddmachine> last update from me — mozilla work continues with the proxy stuff, but not ready yet. i don't have a good feel for how long
<anonimal> Anything pressing? Questions/comments that can't be answered on github or after the meeting?
<anonimal> Ok, thanks bigreddmachine
<rehrar> not from me, I'll be in contact :(
<rehrar> :)
<anonimal> 9. Any additional meeting items
<bigreddmachine> none. thanks anonimal!
<anonimal> Nothing from me, other than I need to AFK rehrar so, bigreddmachine ajs pigeons if you want to talk more about kovri-site then I'll have to read backlog
<rehrar> aight, thanks.
<sgp> Now over to monero!
<ajs> K
<anonimal> Thank you all if you keep the torch burning for the site, awesome.
<anonimal> 10. Confirm next meeting date/time
<anonimal> 2 weeks, same time?
<rehrar> indeed
<anonimal> Ok. Thanks everyone :)

Overview and Logs for the Dev Meeting Held on 2017-05-07

Sun, 07 May 2017 00:00:00 GMT

Overview

An overview can be found on MoneroBase.

Logs

<fluffypony> 1. Greetings
<fluffypony> 2. Brief review of what's been completed since the previous meeting
<fluffypony> 3. Code + ticket discussion / Q & A
<fluffypony> 4. MyMonero-in-tree discussion
<fluffypony> 5. Any additional meeting items
<fluffypony> 6. Confirm next meeting date/time
<fluffypony> so let's start with 1. Greetings (aka roll call)
<fluffypony> hi
<johnalan> hi
<vtnerd> present
<sgp> hello!
<fluffypony> tewinget apologises, he'll be late
<ajs> Sup
<endogenic> o/
<rehrar> Yo
<fluffypony> hyc / luigi1111 / ArticMine / othe / smooth / anonimal / binaryFate / dEBRUYNE / dnaleor / gingeropolous / iDunk / IPGlider / Jaquee / jwinterm / kenshi84 / knaccc / luigi1112 / luigi1115 / NoodleDoodle / papalazzarou / pigeons / RedLion[m] / redlion
<Jaquee> hhelo
<pigeons> :)
<vtnerd> also me
<Jaquee> medusa
<fluffypony> anyone I forgot
<iDunk> o/
<vtnerd> oh those are not present whoops
<fluffypony> lol vtnerd
<fluffypony> ok so
<fluffypony> 2. Brief review of what's been completed since the previous meeting
<fluffypony> merged a bunch PRs
<fluffypony> kenshi84's GPG key changed
<fluffypony> I've confirmed it via sidechannel
<fluffypony> we have a new sweepbelow function in the CLI, which you may find useful
<fluffypony> we also have a new heavier bias in output selection towards newer outputs
<fluffypony> moneromooo can fill us in on that
<ArticMine> Hi
<othe> oi
<fluffypony> smart mining is enabled in the GUI
<fluffypony> as in the selection box
<moneromooo> Hmm, I just twiddled the settings for the recent output selection, really. To match some data in the Miller et al paper.
<fluffypony> which is pretty cool
<sgp> indeed
<fluffypony> also Jaquee has done some work on getting iOS back on track after it borked (visually)
<fluffypony> well iOS / mobile
<fluffypony> which brings us to
<fluffypony> 3. Code + ticket discussion / Q & A
<Jaquee> yes. and there's some new translations added to gui
<fluffypony> we have a number of open PRs
<fluffypony> when tewinget is off his bus he can update us on 0MQ
<fluffypony> which I'd REALLY like to move forward with ASAP
<fluffypony> it's been sitting in a holding pattern for ages
<fluffypony> Snipa: also if you're around maybe you can update us on the testing on that ?
<moneromooo> I'd like it to be optional, so it can be merged (and thus tested), without causing massive breakage if it does break.
<fluffypony> afaik that was the case
<Jaquee> sounds like a good idea
<fluffypony> also disposable addresses is still hanging around - I think that's pending a review from one of the luigis?
<moneromooo> AFAIK yes. Also RandomRun had an idea to make it better.
<fluffypony> I don't think there's a problem with that hanging around and being improved
<fluffypony> as long as the parallel MRL write-up is there
<fluffypony> I'd like to discuss 1998
<fluffypony> the PR, not the year
<fluffypony> https://github.com/monero-project/monero/pull/1998
<fluffypony> at this point in time I'm still swaying towards prevent-user-stupidity-by-default
<fluffypony> at the slight inconvenience for a power user / sysadmin who might go "omg really" and then add the flag
<fluffypony> I know vtnerd feels the same way, which is why he added it in the first place
<fluffypony> I'd be interested in strong arguments for removing the flag
<Jaquee> wouldnt a text disclaimer be enough?
<Jaquee> i don't have a strong opinion
<fluffypony> Jaquee: if you try bind externally and start it without the --confirm-external-bind flag then it refuses to start
<fluffypony> and it tells you why
<Jaquee> ok. apparently hyc started the discussion. Are you around?
<fluffypony> I know hyc doesn't like it
<fluffypony> vtnerd: has anyone else expressed disdain for it?
<vtnerd> AFAIK, just the people on that PR and the one referenced
<vtnerd> and possibly one person in IRC, but they seemed to be questioning why it was necessary (I think)
<vtnerd> its somewhat low effort to get around it, so most people just add the flag I thnk
<vtnerd> no one has privately contacted me about it for any reason if that was the question
<fluffypony> ok
<fluffypony> unless hyc comes in I move to close the PR, we can always re-open it later
<Jaquee> ok with me
<fluffypony> ok next PR for discussion is 2011
<fluffypony> moneromooo had concerns that it was touching consensus critical issues
<fluffypony> so/issues/part of the code
<moneromooo> Yes, but it turns out it's actually bypassed when a tx comes from a block. The patch is fine.
<moneromooo> I OK'd it since.
<fluffypony> ah ok'
<moneromooo> Well, wait.
* fluffypony stops...hammer time
<moneromooo> It's really uneeded (only the wallet bit was wanted). But it's not forkworthy. That said...
<moneromooo> Older wallets might create txes which aren't relayed by newer daemons.
<moneromooo> That's fairly unlikely, since my code targets 2/3 of max size, but the size approximation is not very precise.
<moneromooo> That said, I think it's fine to merge.
<hyc> hey. just popped in. reading history
<fluffypony> hi hyc !
<dEBRUYNE> Re: 2011, perhaps it also should be dependent on the fee priority level used
* fluffypony plays elevator hold music
<hyc> ok, if n0b0dy else cares about that external bind thing then whatever. to me it's redundant
<fluffypony> ok
<hyc> since you had to explicitly request a non-localhost address already
<fluffypony> sure, but you'd be surprised how few people know that 0.0.0.0 exposes everything :-P
<endogenic> ^
<hyc> it d0esn't protect against typos/accidents. it only pisses off people who expect the computer to do as it's told
<fluffypony> hyc: view it like a weak password warning
<fluffypony> you can't just expect the computer to accept 1234 as a password
<hyc> yeah, ok...
<moneromooo> Well, I would...
<fluffypony> lol
<fluffypony> moneromooo is the exception to every rule :-P
<fluffypony> now on the GUI side, the only thing I wanted to bounce around is 688
<fluffypony> tooltips are fine, but if we're going to do some sort of unified help then I would veer towards an overlay that shows once the first time you enter a screen, and can be re-called by clicking the [?] button on the taskbar
<fluffypony> https://s-media-cache-ak0.pinimg.com/originals/c1/e1/bf/c1e1bfd7fb2770f6745d95af8bf89865.jpg
<johnalan> like that style
<fluffypony> https://s-media-cache-ak0.pinimg.com/originals/43/6e/74/436e746b35142f41d5f9bb8e765963e4.jpg
<fluffypony> http://eyeviewportal.com/filecache/b38/73d/85-cropped-w545-h409-of-1-FFFFFF-evappguiguidecontentimage002.jpg
<fluffypony> like that
<hyc> sounds good
<johnalan> :+1:
<Jaquee> problem is [?] is not around if you use native title bar
<fluffypony> Jaquee: where else could we add a help button? bottom left?
<endogenic> one suggestion i'd make for that is to make it c lear to the user they can recall it easily by doing "X" so that they don't fret about having to memorize everything before it's closed
<endogenic> recall it -> the help screen
<Jaquee> i think ^ is good as a start
<moneromooo> Where is it on the title bar then, since it's not a WM thing ?
<fluffypony> endogenic: agreed
<moneromooo> s/Where/Why/
<Jaquee> but some buttons could need longer desriptions
<Jaquee> like sweepunmixable and paymentid for example
<fluffypony> Jaquee: there's enough space in the help overlay, we can use a smaller font to explain them
<redlion> how breadwallet on ios handles it when setting up is quite good
<fluffypony> or move the help to somewhere where there's space
<fluffypony> and use an arrow
<Jaquee> yeah. we could find a place for that help button
<fluffypony> ok - any other PRs that need discussion or can we move on? there's general Q&A shortly
<sgp> I'd like to merge 261 on monero-site
<fluffypony> sgp: there's a website meeting after the Kovri one
<fluffypony> so we can discuss it then
<sgp> ok
<fluffypony> ok so
<fluffypony> 4. MyMonero-in-tree discussion
<fluffypony> so basically this is about nose-covering and making sure I'm not abusing my position as a maintainer and member of the Monero Core Team
<fluffypony> currently MyMonero has a working API (largely unspecced to be sure), two client implementations (website and app), two server implementations (the live backend and OpenMonero), with a third one coming
<fluffypony> I'd like to make sure there is general acceptance and buy-in that the API can be implemented as the general API for lightweight wallets (ie. wallet that use remote viewkey scanning)
<hyc> is it carved in stone now
<hyc> if we need to tweak it we can still do that?
<redlion> is the license unrestricted?
<fluffypony> and that MyMonero-written or MyMonero-derived code is generally acceptable to be merged into the source tree (ie. the open-source backend implementation that vtnerd is working on)
<fluffypony> redlion: BSD 3-clause
<fluffypony> hyc: as long as mWo12 changes it, and we match the changes in the live backend and the new backend then yse
<fluffypony> yes
<fluffypony> we can make any changes, and we WILL make changes to make it smarter
<moneromooo> If it's beneficial to monero and it works fully by itself without needing proprietary gunk, then I'm OK with it.
<fluffypony> eg. tx history comes in raw, instead of paginated
<fluffypony> so that needs to change
<hyc> +1 moneromooo
<fluffypony> moneromooo: yeah the new backend will use LMDB instead of mysql
<fluffypony> so it will be unencumbered in the source
<ArticMine> As long as there are no proprietary dependencies I am fine
<hyc> I like it even more now ;)
<johnalan> I think it beneficial too
<moneromooo> Maybe a separate repo (similar to monero-core) might be best, but that's details.
<johnalan> *its
<moneromooo> it's
<iDunk> it's
<jollymort> can't wait to run a mymonero node myself!
<vtnerd> also the current "primary" wrapper around the DB is actually C, so theres that for you guys
<fluffypony> moneromooo: I thought about that, but it's a single daemon that should exist in the repo alongside the wallet RPC etc.
<hyc> doesn't it supersede wallet-rpc?
<fluffypony> now
<fluffypony> hyc: no
<fluffypony> wallet-rpc is good for integration, this isn't
<johnalan> there is obviously an element of centralisation, but it’s nearly impossible to avoid
<fluffypony> also on this topic
<fluffypony> Jaquee has begun working on client integration in the CLI and GUI
<moneromooo> "client integration" ?
<vtnerd> you mean for light-wallets?
<fluffypony> that will mean that both CLI and GUI will be able to run in lightweight / remote-scanner / MyMonero mode
<fluffypony> moneromooo: as opposed to implementing the server protocol
<hyc> sounds good
<moneromooo> Oh, mymonero client integration ?
<fluffypony> moneromooo: let's call it something else
<moneromooo> That went pretty damn fast :D
<fluffypony> "lightweight wallet"
<jollymort> it's not really centralization if any monerod acts as a server
<hyc> but I'm still missing why we need old wallet-rpc if this mymonero api exists
<jollymort> it's literally my monero :)
<fluffypony> hyc: wallet-rpc is completely different
<johnalan> so the core GUI will be able to interact with MyMonero backend too?
<vtnerd> for people that want to run VPS node but keep their viewkey ?
<moneromooo> Yes, would be nice to see what bits are needed where, and the actual API (even if roughly).
<fluffypony> it provides an API for integrators
<fluffypony> @johnalan yes
<fluffypony> so basically
<johnalan> is this needed with the MyMonero Desktop wallet?
<ArticMine> With what as the backed / server
<moneromooo> That can be posted later though, :49 now.
<ArticMine> monerod?
<fluffypony> lightweight wallets will have 3 server options:
<fluffypony> 1. OpenMonero
<fluffypony> 2. the new in-source backend that vtnerd is working on
<fluffypony> 3. the live MyMonero backend
<fluffypony> it will also have multiple client options:
<hyc> afaik the main difference btw an ordinary wallet and mymomero is you tell mymonero your viewkey
<fluffypony> 1. OpenMonero's web wallet (clone of the current MyMonero web wallet)
<hyc> and the ordinary wallet has all your keys
<fluffypony> 2. the MyMonero applications
<fluffypony> 3. monero-wallet-cli
<fluffypony> 4. monero-wallet-rpc
<fluffypony> 5. the Monero GUI
<fluffypony> hyc: monero-wallet-rpc can still use this on the backend
<fluffypony> so it's unrelated
<hyc> ok
<ArticMine> ok
<jollymort> about #2011 - you could modify it to (median)+0.6% for it to be mine-worthy, or even have the wallet check for fee setting and then it would be matched like 1: +0.6%, 2: +2.4%, 3: +12%, 4:+100%
<fluffypony> also this will mean that the GUI / CLI may end up supporting the MyMonero 13-word seed derivation by virtue of the integration effort
<fluffypony> does anyone have a fundamental issue with that ?
<ArticMine> no
<fluffypony> I mean, I do, because I don't want to be abusing my position, but it is what it is :-P
<jollymort> didn't you deprecate 13-word?
<moneromooo> Did you not say the 13 word seed was going to be obsoleted ?
<endogenic> jollymort: working on it
<johnalan> no
<endogenic> but client still needs to be able to read 'em
<redlion> electrum/mycelium support a few different seed lengths iirc
<redlion> works well
<jollymort> also luigi was playing around with an idea for 17-word, integrating creation height in it etc
<fluffypony> moneromooo: it's import only
<fluffypony> not create
<endogenic> https://github.com/mymonero/mymonero-app-js/issues/77
<knaccc> doesn't it put a huge load on mymonero when someone asks it to scan the blockchain from zero with their view key? How long does mymonero take to scan the entire blockchain?
<moneromooo> Anyway, I'm fine with that as presented.
<hyc> that all sounds like a win to me. people have been whining about not being able to import their 13-word seed into regular CLI wallet
<shuannelson> so monero-wallet-cli/monero GUI will not be able to create light-wallets?
<fluffypony> knaccc: yes it does - about 10 minutes
<jollymort> yeah import only sounds lovely
<ArticMine> If we are setting the stage for a competitive market based upon FLOSS then I am fine with it
<vtnerd> I do have the ASM code working, so hopefully that will tighten up some too (altough there is something else blocking that)
<fluffypony> shuannelson: yes they will
<fluffypony> but with 25 word seed, not 13
<fluffypony> we have 7 minutes left - so I'd like to move on to the last item
<shuannelson> awesome!
<fluffypony> we can discuss MyMonero more after the meeting
<redlion> @shaunnelson, I think it's just that the CLI/GUI won't create 13-word seeds, but will accept already created ones
<hyc> yeah sounds fine
<fluffypony> 5. Any additional meeting items
<knaccc> 10 mins is quite a speedup vs downloading the entire blockchain, so sounds awesome.
<jollymort> any thoughts on future of penalty/blocksize? i kind of left the research open-ended
<hyc> ^^ get a faster CPU and it'll be quicker ')
<redlion> Does anyone have a working monero-core or mymonero build on ios currently? I've been fiddling around and I can't seem to get either properly functional on the sim/device, though I may be missing something
<fluffypony> lol hyc
<endogenic> redlion: pls come join #mymonero but yes i do :)
<Jaquee> redlion: i have. it has some nasty bugs but it's running
<redlion> ok thanks, I'll talk to you after this
<hyc> btw iOS still limits process VM size to 4GB so we won't be running monerod native on iOS any time soon
<fluffypony> @jollymort let's discuss it after the meeting, or maybe next week - there are 2 more meetings to go tonight :)
<fluffypony> and that's a large topic
<jollymort> sure, another time
<redlion> thanks jaquee, are there any build instructions or a (sort of) working build posted somewhere?
<fluffypony> 6. Confirm next meeting date/time
<fluffypony> May 21
<fluffypony> day before Consensus
<hyc> cool
<hyc> oh. this week I expect to have wolf miner fully ported to Android, with GPU support too
<fluffypony> endogenic can come to my hotel and we can do the meeting together :-P
<endogenic> oooh
<tewinget> anyway, I have the daemon's side of the code rebased and nearly ready to PR and merge. I mean, it could be merged now, but I should clean it up a little/address a few more of the comments on the existing PR first.
<tewinget> the wallet side of things will be based on that, and won't take too long. I just thought it made sense to separate it into two PRs (and rebase while I'm at it because why not?)
<fluffypony> suweet
<fluffypony> just check the meeting logs for the bit from moneromooo about it
<tewinget> (the wallet stuff is still "done already", but as with the daemon side there are comments/suggestions to address as I rebase it as well.)
<tewinget> at any rate, I plan today to finish with the cleanup of the daemon side of things, close the existing PR, and open a new one for the daemon that should be mergeable.
<fluffypony> great stuff
<fluffypony> pigeons: did you see the 96boards thing?
<tewinget> fluffypony: sorry I didn't respond right away to your pinging on the github PR, but when I said it was already rebased I meant on a different branch, as I'm leaving that branch up (and separate) until I finish rebasing.
<fluffypony> ok cool
<moneromooo> tewinget: is the 0MQ stuff deselectable if needed (so if it somehow breaks, you can run the wallet with the existing JSON comms) ?
<moneromooo> wallet/daemon
<tewinget> moneromooo: I'll make it so when I rebase the wallet side of things.
<moneromooo> Excellent, thank you :)

Disclosure of a Major Bug in CryptoNote Based Currencies

Wed, 17 May 2017 00:00:00 GMT

Overview

In Monero we've discovered and patched a critical bug that affects all CryptoNote-based cryptocurrencies, and allows for the creation of an unlimited number of coins in a way that is undetectable to an observer unless they know about the fatal flaw and can search for it.

We patched it quite some time ago, and confirmed that the Monero blockchain had NEVER been exploited using this, but until the hard fork that we had a few weeks ago we were unsure as to whether or not the entire network had updated.

Once we were certain that the network had updated, we notified all active and affected CryptoNote coins, including CryptoNote themselves, Bytecoin, Forknote, Boolberry, DashCoin, and DigitalNote.

Note that, at this time, only Monero, Aeon, Boolberry, and Forknote have updated. We have given the other currencies as much time as possible, but cannot hold back disclosure any longer.

We strongly caution against anyone using, trading, exchanging, or running services involving the following currencies affected by this issue: Bytecoin, DashCoin, DigitalNote

Timeline

2017-02-19: A member of the Monero Research Lab discovers the exploit, triggered by a detailed discussion of the XEdDSA signature schemes on the Curves mailing list
2017-02-20: The Monero blockchain is scanned to see if this had ever been exploited; thankfully it had not and the blockchain is intact.
2017-02-21: The patch is surreptitiously snuck into the Monero codebase in pull request #1744. It is kept secret to prevent it being used to attack other CryptoNote coins.
2017-02-22: A point release of Monero is rushed out so that exchanges and mining pools can update, under the guise of it preventing a RingCT DoS attack (such attack did not exist, but it seemed a fair explanation).
2017-03-15: The hash of the details of the problem is committed to the Monero blockchain in tx dff7a79e44f9392e19fe5205c389d3e799f89c62d90d624219618d754b806e04
2017-03-26: A further point release of Monero is put out to prepare for a hard fork in April.
2017-04-14: The Monero network hard forks to increase the dynamic block size minimum median, but this has the added bonus of ensuring the entire network is protected.
2017-04-17: All CryptoNote coins are contacted, and told that they have until mid-May to patch their coins, before there will be a public disclosure of the issue.
2017-04-17: As noted by Riccardo "fluffypony" Spagni on Twitter, the hash of the message sent to the various CryptoNote currencies is committed to the Monero blockchain.

Problem

The so-called "key image" as used in CryptoNote coins utilising elliptic curve ed25519 can be modified in a special way, allowing double-spends. This effectively allows someone to create an infinite amount of coins in a way that is impossible to detect without knowing about the exploit and explicitly writing code to check for it.

Mitigation

Several options exist for mitigation. The simplest, least invasive is noted below.

To mitigate, check key images for correctness by multiplying by the curve order l. Check that the result is the identity element.

Hexadecimal values of each:

Identity element = "0100000000000000000000000000000000000000000000000000000000000000"

Curve order (little endian) = "edd3f55c1a631258d69cf7a2def9de1400000000000000000000000000000010"

For each transaction key image, check ((key image * curve order) == (identity element)); reject transaction if false.

Appendix: Commitment Text #1

As committed via the payment ID in Monero transaction ID dff7a79e44f9392e19fe5205c389d3e799f89c62d90d624219618d754b806e04, the text below has a sha3-256 (ie. keccak-256) hash of 21f0216fbbdc3dc590903b579282878705ed2adab7d8213328d962c76e806d84:

Problem:
The so-called "key image" as used in Cryptonote coins utilizing elliptic curve ed25519 can be modified in a special way, allowing double-spends. I leave out exact details in this draft to give some time for mitigation.

Hash (keccak-256) of details, to be released later: <4402e902f1ac8cec96a17453dcae307d21a7995a94b76e9c3eb7ca7baeffb8c8>


Mitigation:
Several options exist for mitigation; I include the simplest, least invasive here.

To mitigate, check key images for correctness by multiplying by the curve order l. Check that the result is the identity element.

I include hexadecimal values of each:
Identity element = "0100000000000000000000000000000000000000000000000000000000000000"
Curve order (little endian) = "edd3f55c1a631258d69cf7a2def9de1400000000000000000000000000000010"

For each transaction key image, check ((key image * curve order) == (identity element)); reject transaction if false.

Appendix: Commitment Text #2

As noted in the previous commitment, the text below has a sha3-256 (ie. keccak-256) hash of 4402e902f1ac8cec96a17453dcae307d21a7995a94b76e9c3eb7ca7baeffb8c8:

Dirty Details:
Adding one of the (non-idenitity) "torsion", or small subgroup, points to a key image allows up to 7 double spends to be performed per output (8 total spends). The reason this is possible is that multiplying any of these small subgroup
points by 8 returns the identity element (a kind of zero point). This means that multiplying the sum of a "normal" point and a torsion point by 8 (or a multiple of 8) will return the same point as multiplying the normal point by 8;
the small subgroup point is "factored out". This allows a signature to verify on an alternate key image *so long as* the relevant scalars are multiples of 8. Cryptonote does not use scalars that are automatically multiples of 8 (whereas
vanilla EdDSA does), but this is only a slight hurdle. An attacker need only choose the relevant scalars to be a multiple of 8 (in certain cases he cannot choose, and must instead create trial scalars until getting the desired result).

Alternate mitigations:
1. Multiply each key image by 8, then the result by 8^-1 (mod l), to get the proper key image in the correct subgroup. Reject double spends, or if the result is not the same as the input. Unwieldy.
2. Mutliply each key image by 8 before storing in the key image list/checking for double spends. Quite invasive, as it requires redoing the existing key image list.


Extra details:
Monero's (and all CryptoNote coins') elliptic curve, ed25519, has a basepoint group cofactor of 8. There are 8 subgroups in ed25519, of the following sizes:
1 ----|
2     | --- small subgroups
4     |
8 ----|
l (basepoint subgroup) ---|
2*l                       | --- large subgroups
4*l                       |
8*l (all curve points) ---|

Each small subgroup point is contained in the next larger small subgroup, and also in the corresponding large subgroup (superimpose small/large). Each large subgroup is contained in the next larger one as well. The only small subgroup
point contained in subgroup 1 and l (basepoint subgroup) is the identity element, which works as a kind of zero (no effect on point addition). Mutliplying any point by its subgroup order will return the idenitity element (same as multiplying
by 0). Mutliplying any point by 2, 4, or 8 will move it to the corresponding most exclusive subgroup (e.g., a point in 8*l subgroup multiplied by 4 would move to the 2*l subgroup, a point in the 8 subgroup multiplied by 2 would move the 4
subgroup, and so on). Adding a small subgroup (non idenitity) point to a key image in the basepoint subgroup "knocks" it out of that subgroup and into one of the larger ones. Since the order of that subgroup is not l but some multiple,
multiplying as in the proposed mitigation above does not return the identity element.

Logs

<moneromooo> fluffypony can't make the meeting, so I'll be prodding people.
<moneromooo> First thing is the release is soon, if you want to test the release branch, please feel free.
<moneromooo> https://github.com/monero-project/monero/tree/release-v0.11.0.0
<moneromooo> There are a couple patches still unmerged, but they shouldn't impact any testing.
<moneromooo> Pony will likely start building later today, or maybe tomorrow.
<moneromooo> Other than that, I guess we'll go through people to see what they're up to.
<moneromooo> Who wants to start ? hyc ?
<hyc> hm, I've mostly been doing little patches for the release
<hyc> whenever I tripped over something
<moneromooo> And safe sync mode :)
<hyc> new stuff worth mentioning - safesyncmode, salvage
<hyc> yeah - so now monerod will automatically switch to SAFE sync mode whenever it catches up to the network
<hyc> and will switch back to FAST if it falls behind
<hyc> so hopefully we won't need to use the salvage flag ...
<hyc> I think that's my highlights. next?
<moneromooo> So... knaccc ?
<hyc> (oh yeah, also cleaned up readline deadlocks etc)
<moneromooo> So knaccc may not be around, but knaccc's been doing prototyping of the Ruffing et al sig scheme. Maybe later.
<moneromooo> surae: around ?
<serhack> Hey!
<serhack> is there meeting?
<TinusMars> no idea
<moneromooo> surae also seems away, so serhack: anything you want to say about what you've done recently ?
<dEBRUYNE> serhack, TinusMars: yes
<vtnerd> @serhack yes, on going
<serhack> okay
<serhack> moneromoo: I'm going to release prestashop plugin!!
<serhack> Second milestone is completed
<hyc> congrats
<serhack> but I have to do some maintanance ;) prestashop plugin is beta
<moneromooo> This and woocommerce are among the most used plugins for that kind of thing, is that right ?
<serhack> yep
<serhack> in the future, whmcs, magento, shopify
<serhack> so let's wait for another ffs
<moneromooo> Great, and congrats for your first maintenance contract too :)
<serhack> moneromoo: you can go on
<serhack> thanks!
<hyc> (oh one more note, we've cleaned up blockchain_db code structure a bit. no more backend-specific includes in the rest of the source tree, only blockchain_db is exposed now)
<moneromooo> vtnerd: you've been cleaning up some stuff about network addresses, etc recently, want to say anything about this or other things ?
<moneromooo> Or mymonero related things.
<vtnerd> um, not sure what to report because I don't think I have any hidden patches pending core
<vtnerd> the focus of mymonero is improving the perf of that poor guy, the DB is getting killed on the current design
<vtnerd> so hopefully finally less complaints about "where is mymonero XMR?"
<hyc> is that still using mySQL?
<vtnerd> yeah for the time being
<serhack> Vtnerd: Can I ask you any question about mymonero?
<endogenic> That's one, serhack!
<vtnerd> fluffypony discussed using LMDB for the open sourced version so that a dependency was not added
<serhack> Why don't you use another db for example sqlite?
<serhack> Endogenic: oh! :)
<moneromooo> If it's going to be that kind of question, maybe leave it out for later, or #mymonero :)
<vtnerd> at this point Im dealing with a legacy made before I joined the project. so I do not know the actual rationale
<hyc> If you must use SQL you can use sqlightning on LMDB https://github.com/LMDB/sqlightning
<vtnerd> I'd probably move it to LMDB first however
<serhack> Oh okay sorry moneromoo
<hyc> but I see no value add from using SQL itself
<vtnerd> yes I have a partially written experimental hybrid mode
<vtnerd> because currently the transactions on the network are pulled from mySQL too, so theres overhead in that
<endogenic> No value from sql?
* endogenic defers flamewar
<moneromooo> endogenic: anything you want to add, apart from SQL discussion ? :)
<endogenic> :'(
<hyc> yeah give us the scoop endo
<endogenic> You get an ios app, and you get an ios app...!
<serhack> Wow! Endogenic :)
<endogenic> Switched back to js (desktop and android) to bring new features over
<vtnerd> the value of mysql is doing arbitrary queries easily, with the cost of building them
<hyc> so both android and ios are ready to go now?
<endogenic> Dun and bradstreet is having a little difficulty verifying mymonero for apple for some reason so we're waiting on that
<endogenic> Vtnerd and transactions? Or can that be done in application layer?
<vtnerd> anyway serhack, ask in mymonero as opposed to this meeting
<serhack> Oh okay
<vtnerd> I was going to pull the transactions directly from the monerod file
<endogenic> Oh you must mean for mm specifically
<vtnerd> so read it in real-time, like LMDB was designed to do
<endogenic> Sorry i mean db txs
<endogenic> Er
<vtnerd> currently mymonero mirrors the entire tx history in a MySQL DB
<hyc> I thought we weren't going to have the DB discussion right this moment but ... there's no value-add for that ;)
<vtnerd> anyway, for monero specifically it looks like I will do anonimal suggestion of making the supercop code a separate project lib, I think moneromooo thought that was a good idea too
<hyc> makes sense
<moneromooo> Hmm, I didn't follow any discussion on that PR, I was going to go there after the release is done.
<ArticMine> Are we having s meeting?
<moneromooo> We are.
<ArticMine> ok
<moneromooo> OK, seems we're done here, vtnerd and endogenic, unless you have anything else ?
<vtnerd> nope
<vtnerd> direct all complaints to #mymonero haha
<msvb-lab> Just curious, it was reported in the community meeting like a doubling of members or traffic. Has that translated to development/developer too?
<hyc> I've noticed a few new people in this channel asking how to help devel
<moneromooo> Jaquee: around ? Want to say something about the GUI and/or the light wallet changes ?
<serhack> Yep, @lessless has done a good work with api lessless.github.io
<hyc> is the GUI frozen for release now? are those binaries in that reddit thread basically final?
<lessless> thanks serhack, being my pleasure. what is the topic btw? :)
<moneromooo> I think it was a week delayed (IIRC Jaquee was going to be busy).
<serhack> Your website helped a lot some devs :)
<moneromooo> Alright, so Jaquee AFK too. msvb-lab, you wanted to say something about your hardware project ?
<Jaquee> nothing new from me since last meeting
<moneromooo> OK, thanks :)
<msvb-lab> moneromooo: Yes, I want mention to any newcomers the current debate surrounding hw wallets and the FFS proposal.
<msvb-lab> https://forum.getmonero.org/7/open-tasks/88160/monero-firmware-for-ledger-wallet/
<msvb-lab> ...is for a firmware port but:
<msvb-lab> https://forum.getmonero.org/7/open-tasks/88149/dedicated-monero-hardware-wallet/
<msvb-lab> is the main effort towards a dedicated Monero hardware wallet.
<msvb-lab> This is just a brief mention, because we've had discussion already last week on dev, this week on community.
<dEBRUYNE> <hyc> is the GUI frozen for release now? are those binaries in that reddit thread basically final? <= Jaquee said he wanted to focus on fixing bugs that were reported by people using those bins
<dEBRUYNE> So basically that + bug fixes
<msvb-lab> Anyone with opinions/suggestions please write a comment in the forum (FFS thread.)
<moneromooo> Alright. Who wants to say something next ?
<msvb-lab> moneromooo: Thanks, that's all for props 88149 and 88160.
<rehrar> I can. I have something that needs dev input.
<moneromooo> Please go ahead.
<Jaquee> dEBRUYNE hyc: code freeze was done aug 23rd afaik. (one week after monero code freeze)
<rehrar> https://drive.google.com/file/d/0B0vhnWCa9J5QYW1yc2lRNWE2NzA/view?usp=sharing
<rehrar> This is the recent Monero Revuo that will be published soon.
<rehrar> Just want to get any last opinions on the development section. Anything else major been done that I've missed?
<serhack> Great work @rehrar
<serhack> Android wallet @rehrar ?
<rehrar> Also, can someone tell me if I understood the purpose of 0MQ correctly?
<rehrar> Android wallet is September. Doesn't quite make the cut. But maybe it can be in there. Who cares, right?
<serhack> Mm. Right
<lessless> serhack I would really love that work to be carried on - there are much more calls to cover. Can it become a part of official documentation? I think that way there more chance for contributions
<rehrar> Oh, I should probably add a "What to expect in the hard fork" section.
<serhack> I think yes. But I don't know where we can post your website lessless
<dEBRUYNE> lessless: You can simply make a PR to the site repository on github
<moneromooo> So, mooo next. I fixed a few things, but mostly more work on multisig based on luigi's new directions for N-1/N. Getting a bit lost in the sea of stuff to juggle, but it's progressing.
<moneromooo> Who else wants to talk a bit about dev happenings ?
<lessless> dEBRUYNE hmm, yeah! I can do that :)
<gingeropolous> we still set for 9/21 for the fork? And its definitely 0.11.0.0 ?
<moneromooo> 9/21 ?
<moneromooo> Oh. I get it.
<gingeropolous> september 21st .. ?
<moneromooo> It's supposed to be around the 16th IIRC.
<gingeropolous> aight, well the readme is wrong then
<gingeropolous> so the version is 0.11.0.0 ?
<moneromooo> I don't think I edited that. I did not realize it was already set in te readme :)
<moneromooo> Yes.
<hyc> daemon says 12.4 days away
<gingeropolous> yeah, down in the magic table i try to maintain
<hyc> so yeah around the 16th
* moneromooo afk for a bit. If anyone else wants to say something about dev happenings, please feel free :)
<msvb-lab> Sarang got hired as mathematician, congratulations.
<msvb-lab> Any word from him (I'm curious) on plans this week or current dev work?
<knaccc> My update on RuffCT - sarang and surae are working on resolving some notation issues between the Ruffing paper and the Bootle paper, and once they resolve a few things that aren't 100% clear from the papers, we'll be able to complete the prototype very quickly and will be able to share performance benchmarks so that we can all decide what kind of ring size we can use RuffCT to achieve.
<msvb-lab> ...but he isn't here it seems.
<Jaquee> rehrar: you might want to add a text about openmonero/mymonero backend support. PR #2109
<rehrar> Thanks Jaquee, will look into it.
<hyc> hmm. might also mention rangeproof work? we had some more discussion on how to approach that this past week
<ArticMine> knaccc Any idea on the impact of RuffCT on tx size?
<hyc> knaccc you had a paste of expected sizes, can you repost the link?
<knaccc> ArticMine not yet, it looks extremely promising from a tx size perspective, but there is a problem with the implementation so preliminary figures are probably completely wrong
<knaccc> in a week hopefully we'll have proper figures
<ArticMine> great
<erciccione> @rehar if you can, would be nice to mention the increased number of languages that monero "speaks" in the community section, we got really a lot of stuff in these last months
<rehrar> Will do eric, thanks.
<hyc> hm, maybe we should keep the Sep 21 date. gives almost an extra week for people to upgrade
<hyc> (hardfork date)
<gingeropolous> and if they were going by the repo... its what they were expecting :/
<gingeropolous> but no one reads the docs, so theres that
<hyc> true
<hyc> looks like we're out of topics then
<hyc> anyone else?
<msvb-lab> Is Sarang here?
<erciccione> @rehrar if for eric you meant me, thank you :)
<msvb-lab> Let's hear from him, I'm dying to find out what's he's working on.
<hyc> seems no Sarang
<knaccc> Sarang has been looking at the Ruffing and Bootle papers
<knaccc> that's his immediate work, I think
<msvb-lab> knaccc: Okay, cool enough. Thanks.
<rehrar> Oops. Yeah. Just realized that you're erciccione, but that's ok cuz you misspelled my name just a bit ago too
<erciccione> ooops just noticed . sorry :)
<rehrar> moneromooo save us!
<iDunk> Yeah, it's a bit... romanesco :)
<serhack> :)
<gingeropolous> thought mooo was afk
<rehrar> Yeah, so instead of floundering about, perhaps we can confirm next meeting time and end?
<hyc> well, if no one has any additional meeting items, I think we just confirm next
<rehrar> ^ this guy
<hyc> Sep 17 would be right after the hardfork
<hyc> unless we decide to change the block height to match sep 21.
<rehrar> I think that's a pretty important decision to make fairly urgently, no?
<iDunk> 1403616? To keep with *16 recent tradition.
<hyc> certainly in the next few hours if we're going to freeze and tag today
<gingeropolous> well, i think i put the 9/21 there because in 2016 it was 9/21
<gingeropolous> but i dunno if its better to fork on a weekend or a weekday
<gingeropolous> what was 9/21/2016?
<hyc> wednesday
<hyc> So, saturday or following thursday this time
<rehrar> If the docs have said 21 for some time, perhaps it's best to keep it?
<iDunk> 1400000 was on target for 21 when it was set, I think.
<iDunk> But then nethash shot up and the diff struggled to keep the block target time to 120 seconds.
<hyc> so it sounds like Sep 21 was always the intended date
<hyc> and we should fix the height
<hyc> ok let's confirm Sep 17 next meeting, 17:00 UTC, and call it a day. Thanks everyone
<rehrar> Cya. :)
<rehrar> No Kovri meeting today!

Monero 0.11.0.0 "Helium Hydra" Released

Thu, 07 Sep 2017 00:00:00 GMT

Overview

This is the v0.11.0.0 major release of the Monero software, and it is a mandatory update due to the September 15th hard fork, which in turn increases the minimum ring signature size to 5 across the network, bans duplicate ring members in a ring signature, and enforces use of ringCT for all transaction outputs. This release of the software presents a number of major improvements to Monero, as well as a large set of bug fixes.

Some highlights of this release are:

major synchronisation speed-up from reducing bandwidth used
massively improved the blockchain import function
changed terminology from "mixin" to "ring size"
add a --fluffy-blocks option to relay blocks as fluffy blocks if possible
allow for password verification without loading the subsequently unencrypted wallet into RAM
reduced privacy leak risks when using untrusted remote nodes
added an Esperanto wordlist for mnemonic seed choices
decreased memory demands for the getblocks RPC call
added a "fee" command to display fee information
transfer CLI command warns if there's a tx backlog for selected fee
add average seconds per block in bc_dyn_stats
added an on_get_alt_blocks_hashes RPC call
added an Italian translation for the CLI
return the per-tx amount in the transfer_split RPC call
switched to readline for the CLI
automatically switch to SAFE db-sync-mode once daemon catches up to network
added a histogram to poolstats
major speed-up for poolstats and coinbase_tx_sum
enable support for macOS smart mining
added the ability to build a Snap package
added a Vulnerability Response Process, with bug bounties available via a dedicated HackerOne portal
added support for payment proving via key derivation instead of tx key reveal
changed output selection for ring signatures to heavily weight newer outputs
added a sweep_below function to sweep small amounts
moved the mempool to a database on disk instead of keeping it all in memory
fully enable iOS and Android full node support
enabled support for ppc64le architectures
added the ability to create and open wallets via RPC
added ability to relay transactions manually after creating them
better AC / battery power detection for Linux smart mining
getblocktemplate now indicates the expected total reward
as always, loads of bug fixes and performance improvements

Contributors for this Release

This release was the direct result of 39 people who worked, largely unpaid and altruistically, to put out 557 commits containing 60 254 new lines of code. We'd like to thank them very much for their time and effort. In no particular order they are:

moneromooo
kenshi84
Roberto Oliveira
Lee Clagett
Eugene Otto
MoroccanMalinois
Michael Shick
JollyMort
Erik de Castro Lopo
anonimal
erciccione
Guillaume Le Vaillant
rbrunner7
binaryFate
Riccardo "fluffypony" Spagni
Jaquee
Julien Klepatch
moneroexamples
Nano Akron
Antti Keränen
Jethro Grassie
xmr-eric
schnerchi
MaxXor
Andrei Muresan
Jkat
stoffu
Mike C
Gingeropolous
Jonathan Cross
m2049r
Miguel Herranz
Randi Joseph
assylias
Martin Wimpress
Ryan Mehta
Gentian
Robby Weinberg
Howard Chu

Official Download Links (Graphical Interface)

Official Download Links (Command-Line)

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.11.0.0.zip, afafa1067ed0b000685084dff1e7ab044425fc323ae8761558b02c9a36a9011c monero-win-x86-v0.11.0.0.zip, 5f0286b50e3dd19272329ab5150de2d652d1f460d3842836c21dab8c7010344b monero-mac-x64-v0.11.0.0.tar.bz2, 12617e006237e271e27ecbc34047c3804b68c48e87e5ffe524abcac466579b05 monero-linux-x64-v0.11.0.0.tar.bz2, fa7742c822f3c966aa842bf20a9920803d690d9db02033d9b397cefc7cc07ff4 monero-linux-x86-v0.11.0.0.tar.bz2, d1e503e0e5c327a7c3ba8a55a2c227f04acdca47b8396c2cd35c583919056dec monero-linux-armv7-v0.11.0.0.tar.bz2, 491e42a29f09b927c9b1311c4682ced7bc7cbb51e2a6469b74ae42ef647d59ab monero-linux-armv8-v0.11.0.0.tar.bz2, 61b4b2aa79a0653f0809c29c5846517e40033dba78779155a26a4a4cf7e0c4d8 monero-freebsd-x64-v0.11.0.0.tar.bz2, 9cabc1f22674d787009a339796994ac67d1f2c00c13e5d1fbb6f63f7df9d57b0 monero-dragonflybsd-x64-v0.11.0.0.tar.bz2, 272c101a1b72d9cde107668211941d401501bbc93f620f34cd580c9dd575d873

monero-gui-win-x64-v0.11.0.0.zip, 52edde05fdac17a99441dc7b695ebba40a08fda3d1628d5f1f4424f8ffd531d6 monero-gui-mac-x64-v0.11.0.0.tar.bz2, 5bbb85762811b763f0913706ea7f9de944b042688adb27e828937eb7884fc322 monero-gui-linux-x64-v0.11.0.0.tar.bz2, 25bdeeb9072b679eda4aca2a5dac0351393d6bd8ceed1822bf65495ab6d113bf monero-gui-linux-x86-v0.11.0.0.tar.bz2, 284b30fe84c92407117b7dcabc324c12050196e520d64ff5601a031dfbc7bb90

A Scheduled Protocol Upgrade is Planned for September 15

Wed, 13 Sep 2017 00:00:00 GMT

First and foremost, the new binaries can be found here:

https://getmonero.org/downloads/

Note that this is a scheduled and consensual protocol upgrade. Thus, unlike the BCH / BTC split, a new coin won't be created.

Approximately on the 15th of September there will be a scheduled protocol upgrade on the Monero network. While some pools have already upgraded, some pools are not updated yet or are in the process of upgrading. If they don't upgrade before the scheduled protocol upgrade, they will get booted off the network. As a result, you will miss out on revenue if you are mining on these pools. Thus, if you are mining on one of the pools that hasn't upgraded yet or hasn't scheduled an upgrade, please contact your pool owner as soon as possible and urge them to upgrade. Alternatively, you can switch to a pool that is on the correct version.

A list of pools and services and their respective statuses can be found here.

An important message for pool operators and miners

Bear in mind that running CLI v0.11.0.0 or GUI v0.11.0.0 is mandatory. Any other versions will get booted off the network. Thus, miners, please email your pools and ask them if they are running v0.11.0.0. In addition, pool operators need to ensure that payouts use a minimum ring size of 5 (mixin 4), otherwise they will get rejected by the network.

General scheduled protocol upgrade information

The scheduled protocol upgrade was introduced to enforce RingCT transactions and to bump the minimum ring size to 5 (mixin 4). Note that, after this scheduled protocol upgrade, you are still able to transform non RingCT outputs to RingCT outputs in a "one-time" transaction. Thus, you don't need to sweep a paper wallet if it contains non RingCT outputs.

Due to variance, the scheduled protocol upgrade will take place on or around the 15th of September. There is, however, no specific date as the hard fork will be triggered by a specific blockheight. The specific blockheight for the hardfork can be found here. That is:

// version 6 starts from block 1400000, which is on or around the 16th of September, 2017. Fork time finalised on 2017-08-18.

As an user you need to run either CLI v0.11.0.0 or GUI v0.11.0.0.

How do I upgrade?

CLI:

If you are using the CLI you ought to perform the following steps:

Download the new binaries from here.
Extract the new binaries to a new directory of your liking.
Copy over the wallet files from the old directory (the one that contains the v0.10.3.1 binaries).

Note that a blockchain resync is not needed. If you open monerod-v.0.11.0.0 it simply picks up where it left off.

GUI:

If you are using the GUI you ought to perform the following steps:

Download the new binaries from here.
Extract the new binaries to a new directory of your liking.
Open monero-wallet-gui^1. It should automatically load your "old" wallet and you should be set for the upcoming scheduled protocol upgrade.

(1) On Linux you ought to start the GUI with the start-gui.sh script, i.e., ./start-gui.sh.

Paper wallet:

You don't have to do anything :) However, if you want to restore a wallet after the scheduled protocol upgrade, you need to use the new binaries.

MyMonero

You don't have to do anything, as MyMonero will be properly upgraded in advance of the scheduled protocol upgrade.

Solo mining:

An overview can be found on MoneroBase.

Logs

<rehrar> Here's the agenda for today: https://github.com/monero-project/meta/issues/122
<endogenic> to get you present
<rehrar> 1. Greetings
<DaveyJones> vtnerd it's just so people that might be interested don't miss it on a lazy sunday ^ ^
<vtnerd> yeah, ok thats what I thought, so ahead of the game then
<parasew[m]> hi all!
<rehrar> heyo everyone!
<endogenic> naturally
<tewinget> I'm here-ish, but the only input I have is that the thing that's been taking up most of my time is finished now. >_>
<msvb-lab> Hello.
<serhack> hey
<serhack> Hi
<rehrar> Bit of a small crowd today, but that's fine.
<rehrar> 2. Brief review of what's been completed since the previous meeting
<rehrar> Anyone care to give an update?
<parasew[m]> haxx0r put a ruby-library online, its at https://github.com/krtschmr/monero ( i am helping also)
<surae> howdy
<rehrar> I don't see tons of activity in the repos, it could be that everyone is working on super secret projects?
<john_alan> The MRL has been busy from the updates I read
<john_alan> impressive stuff
<john_alan> Any update there?
<moneo> hey guys, I started developing a small monero client, and stumbled upon a problem: trying to manually fetch some jobs with the getjob method, I only get empty jobs as a respond
<surae> MRL put out our 2nd quarter roadmap, Sarang and I are working in person together for the next few days. we are nearing completion on multisig paper, subaddress paper
<surae> sarang has been working on a new format for the MRL bulletin
<moneo> I'm querying xmrpool.net, an implementation from Snipa
<rehrar> moneo: we're in a dev meeting right now man, you're welcome to join. It ends in about an hour.
<john_alan> @surae sounds impressive, is that ruffCT multisig?
<serhack> monero integrations are going well
<rehrar> sarang if you need help with formatting, shoot me a message. I'm down to get involved
<sarang> rehrar I'll definitely do that
<sarang> It's basically down to proper author/affiliation format
<ferretinjapan> rehrar, o/
<vtnerd> I posted this in #monero-research-lab yesterday -> https://gist.github.com/vtnerd/0337f7daf71b33d945a984171c478bca
<vtnerd> its a utility for comparing various wallet-scanning performance improvement techniques and crypto libs
<moneo> sorry rehrar, will ask later in that case.
<vtnerd> it was part for mymonero stuff, part for MRL info on using curve25519
<surae> vtnerd, you are absolutely awesome
<bigreddmachine> moneo - try #monero-pools
<rehrar> no problem moneo, thanks for understanding
<vtnerd> the most interesting result is trying to get spend-public decompression into mainline - it should improve wallet performance without any crypto lib changes
<vtnerd> amd64-51-30k (crypto lib not in mainline) improves by ~12%, I will know shortly how much ref10 (monero mainline) improves with this technique
<vtnerd> unfortunately this would require a re-arrangement of code in src/crypto, but the changes should be easy to audit
<vtnerd> (the amd64-51-30k variant requires not changes to src/crypto)
<surae> what's interesting about that, is there is a non-linear trade-off in verification time and blockchain space
<vtnerd> and thats probabyl the end of relevant material for this meeting ...
<surae> that 12% improvement might allow us some non-trivial ring size boosts
<vtnerd> well the point de-compression is separate from curve25519
<vtnerd> so we could actually do both
<surae> yeesh
<bigreddmachine> vtnerd, I thought amd64-51-30k is built into both supercop and nacl, and that Monero uses supercop?
<vtnerd> basically for every output we currently decompress (y, xbit) into ->(x,y,z,t)
<vtnerd> that only needs to be done once
<vtnerd> monero does not use supercop, its all embedded. its some re-arranged version of ref10 from supercop
<bigreddmachine> ahhh okay.
<bigreddmachine> so it selected pieces from supercop. makes sense.
<vtnerd> I have a PR which uses two amd64 variants from supercop with minimal changes (to work with position independent binaries)
<vtnerd> fluffypony created a separate repo for this to track changes to the crypto separate from our usage
<bigreddmachine> i see, thanks.
<vtnerd> so that PR needs updating to reflect that, plus this benchmark utility (with the curve25519 removed) will get rolled into that so users can determine which is faster on their machine easily
<vtnerd> oh! and curve25519 has neon implementations for arm ... so theres that too! probably just for hyc though haha
<msvb-lab> vtner: We're interested in MCU hardware implementations of dh25519 and curve25519 in case you come across any.
<msvb-lab> Fat chance though.
<rehrar> Thanks vtnerd! Anyone else have anything to report of the last couple of weeks?
<sarang> I put out my monthly report (less of a dev thing, more of a research update), and plan to post the subaddress paper today w/ surae once we have the formatting all purdy
<sarang> Also researching new developments in aggregate signatures
<surae> oh, sarang and I are experiencing trouble with the forums still
<bigreddmachine> Not something I did, but the Monerujo Android Wallet left beta. Anyone know if anyone's audited the codebase?
<sarang> Yes, true. After posting a comment to my original FFS post, it no longer works
<surae> makes it hard for funding posts, etc... and we were hoping that MRL could get a suite of e-mail addresses or something
<endogenic> hm i wonder if it's related to what just happened
<parasew[m]> surae: sarang - why not post to MRL github and then link it in /r/monero for now?
<sarang> I put the direct text into r/monero just now due to the FFS failure
<parasew[m]> the good thing about putting it into the github would be that people can subscribe and get research updates
<sarang> That's a good point
<sarang> surae ran his in r/monero in the same way
<parasew[m]> also there was a forum-update (or remake) planned, no?
<rehrar> Forum to be scrapped
<rehrar> FFS is going to be integrated into the site proper
<rehrar> you can get a preview at getmonero.org/forum-funding-system for how it's going to look
<surae> ok, we'll just keep pestering rehrar behidn the scenes
<rehrar> Serhack and I will be looking at getting that finished up hopefully in the next month
<parasew[m]> although it's technically not 'forum funding' anymore :)
<rehrar> Forum still works I think, based off the definition
<msvb-lab> Was down for a bit this week wasn't it?
<sarang> rehrar that new update looks extremely legit
<serhack> rehrar yeah!
<parasew[m]> austria monero workgroup can also help w site updates (@serhack, @rehrar)
<sarang> I just creamed my design pants looking at it =p
<serhack> great parasew[m]
<rehrar> I'll contact you parasew[m]
<serhack> I come to austria every year
<sarang> Maybe rename it something like "community funding system" to stress the group nature of it
<rehrar> Alright, can we move on to the next point? It may not take super long because of the absences, but we'll see. We'
<parasew[m]> sarang: very good idea imho, also points more to community efforts
<rehrar> Oops.
<ArticMine> I have an item https://github.com/monero-project/meta/issues/85
<ArticMine> Project licensing. This needs input from devs and the community
<parasew[m]> wow, this is a rather huge topic
<ArticMine> It is about informing So the conversation can take place in GitHub
<rehrar> Thanks ArticMine. Super important for sure.
<sarang> fluffypony brings up a good point about relicensing and the work it takes to contact contributors
<ArticMine> That is one of the issues
<moneromooo> There is no relicensing AFAIK.
<moneromooo> LMDB itself is relicensing. Not monero.
<ArticMine> But it impact Monero
<moneromooo> And monero can use the same licence as it used before.
<rehrar> Right, so the conversation has since turned into a couple different questions:
<rehrar> 1. Should Monero relicense to a dual license?
<rehrar> 2. Should Monero have dependencies that are not completely permissive
<sarang> ah ok
<rehrar> as is my understanding anyway
<moneromooo> 2 is leading.
<sarang> So the LMDB switch would not require contacting contribs?
<ArticMine> It is more complex than that, if the dependencies affect consensus code
<rehrar> ah yes. Good clarification ArticMine. Sorry about that.
<ArticMine> This is a critcal part of smooth's concerns
<ArticMine> Way to complex to deal with here
<rehrar> Right, so give it a read if you haven't already and make your opinion known. :)
<rehrar> Let's move on to: Code + ticket discussion / Q & A
<ArticMine> exactly
<rehrar> Again, with not so many people around, this may not be a huge topic of discussion, but it's there if someone wants to discuss something.
<rehrar> No? Alright. Then we can move on to the next point: Purism integration
<rehrar> This is something that's happened recently that's very exciting that I wanted to share with you all and get dev opinions on.
<rehrar> for those who don't know, https://puri.sm is a company that sells open source laptops (hardware and software) and is currently doing a crowdfunding campaign for mobile phones also
<rehrar> a member of the Reddit community contacted them asking if they would accept Monero for their goods (they accept BTC now)
<rehrar> and they were pretty enthusiastic about the idea. I followed up with them, and spoke with the founder and CEO, Todd, and had a video conference with him
<xmrmatterbridge> <sgp> Awesome!
<rehrar> he is not only interested in accepting Monero for their laptops and phones, but also integrating Monero into their Debian based operating system (PureOS) by default
<endogenic> nice
<rehrar> we spoke at length about different cryptos, and he believes that Monero aligns the closest with Purism beliefs of digital privacy rights
<parasew[m]> very nice!
<rehrar> He also says that many of his devs also push to Debian, so he had discussed with me that if they integate Monero into PureOS, they would see about trying to push into Debian as well
<ArticMine> This is excellent. The one thing to watch is that Monero as a software dependency can become stale real fast
<ArticMine> So we have to work very closely with out downstream on this
<endogenic> that's a great point
<ferretinjapan> sweet!
<rehrar> Yes, I've spoken with ArticMine about these things, and have since emailed Todd about the concerns. Waiting to hear back from him.
<rehrar> Sometime soon he is hoping to make a Purism press release about the Monero integration. I'll be helping with that, so be looking out for it.
<rehrar> It would be helpful from anyone in the community with PureOS to test the Monero GUI on it and see if there's any issues.
<rehrar> https://pureos.net/
<ArticMine> Unfortunately I have to leave early today
<sarang> This is a great development
<rehrar> Bye ArticMine! Thanks.
<bigreddmachine> rehrar, i'll try to spin up a VM with pureos this week and let you know how it goes.
<rehrar> Thanks bigreddmachine!
<rehrar> Their mobile offering is still more than half a year away (it's being crowdfunded right now)
<rehrar> but atm our GUI is (As far as I understand it) functional on mobile phones, but not optimized for it.
<rehrar> But that's for Android, right?
<rehrar> (their phones will also have PureOS)
<moneromooo> That answers why they didn't use Qubes...
<rehrar> Qubes is 'partnered' with them and guaranteed to work on their systems
<rehrar> https://www.qubes-os.org/news/2015/12/09/purism-partnership/
<unknownids> if you order from them you can choose a USB with qubes on it
<rehrar> well, one of their systems anyways
<timothy> qubes is "strange"
<timothy> it stil uses xen
<rehrar> Well, that's all from me about that. If anyone has any other things to say about it, we can discuss it after. Let's wrap up. :)
<rehrar> 5. Any additional meeting items
<rehrar> I'll leave this open for a couple of minutes.
<bigreddmachine> anyone know how many eyes have looked at monerujo? wondering if it's been audited or anything, as I've seen people start recommending it
<moneromooo> Probably an even number.
<parasew[m]> just as a final note: 2 events in december - "Monero Month" in Vienna with the preparations of ccc and monero meetup, monero vienna workgroup ( seperately discussed in #monero-ccc )
<bigreddmachine> :)
<parasew[m]> and CCC itself: we need a prototype programm for the 34C3, planned is to create a joint larger meta-assemby with bitcoin-assembly and riat-assembly.
<parasew[m]> if anyone cares to help plan, etc. also in #monero-ccc
<moneromooo> If anyone want to test the multisig stuff, feel free. It's about a half dozen PRs from the earliest one on github.
<moneromooo> Or review.
<msvb-lab> bigreddmachine: Monerujo is available on the Google Play Store, since this week I think.
<bigreddmachine> msvb-lab, yes, I know
<msvb-lab> That's probably why you're asking. I have the same curiosity in any case.
<xmrmatterbridge> <sgp> Can we have all the IRC channels relayed to Mattermost? Only a handful are
<rehrar> What other channels do you want?
<dEBRUYNE> <rehrar> But that's for Android, right? <= iOS too and we can probably make it work with other operating systems.
<rehrar> Awesome dEBRUYNE! Thanks. :)
<rehrar> Alright we need to wrap up.
<rehrar> 6. Confirm next meeting date/time
<xmrmatterbridge> <sgp> @rehrar I made a list on Taiga. Can't remember on the top of my head
<rehrar> October 15th, same time?
<rehrar> ok, thanks sgp
<rehrar> Ok. That's it guys. Thanks so much! :) Have a good weekend. No Kovri meeting (they're moving to Fridays)