monero-site/_posts/2017-12-03-overview-and-logs-for-the-dev-meeting-held-on-2017-12-03.md

---
layout: post
title: Overview and Logs for the Dev Meeting Held on 2017-12-03
summary: Discussion of open PRs and issues, Bulletproofs, Monero Research Lab, RNGs, 0MQ, and miscellaneous
tags: [dev diaries, core, crypto]
author: dEBRUYNE / fluffypony
---

# Overview  

An overview can be found on [MoneroBase](https://monerobase.com/wiki/DevMeeting_2017-12-03).  

# 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. Any additional meeting items  
**\<fluffypony>** 5. Confirm next meeting date/time  
**\<fluffypony>** so 1. Greetings  
**\<fluffypony>** hi  
**\<ArticMine>** Hi  
**\<fluffypony>** luigi1111 (if you're back) / smooth / hyc / moneromooo etc.  
**\<moneromooo>** here  
**\<gingeropolous>** etc here  
**\<fluffypony>** 2. Brief review of what's been completed since the previous meeting  
**\<fluffypony>** lots of stuff  
**\<sarang>** MRL has working Java test code for complete multi-output bulletproofs  
**\<sarang>** It's being ported over to C++  
**\<moneromooo>** (not the multi output one)  
**\<sarang>** The Java part is complete  
**\<moneromooo>** Sorry, I meant just about the port ^\_^  
**\<sarang>** Discussions are ongoing about if/how the fee structure would be modified to prevent large-output txn DoS  
**\<fluffypony>** what's wrong with per-byte fees?  
**\<sarang>** You can load a txn with tons of outputs  
**\<sarang>** but verification is linear in the # of outputs  
**\<dEBRUYNE>** fluffypony: verification is linear, whilst size is log  
**\<dEBRUYNE>** basically  
**\<sarang>** So for low fees you can force the network to verify  
**\<fluffypony>** ah ok, makes sense  
**\<sarang>** So we need to incentivize the use of aggregate BPs while basically scaling the fee to the number of outputs etc.  
**\<sarang>** But things are looking good  
**\<sarang>** Verification is still quite efficient  
**\<sarang>** and with the multi-output setup, space savings are unreal  
**\<moneromooo>** In fact, the per byte fee needs to be done first, as per kB is way too coarse for this.  
**\<sarang>** Yeah a single output BP is about 704 bytes, while a 2-output BP is something like 768 bytes  
**\<sarang>** (including commitments)  
**\<sarang>** it's just too damn good  
**\<fluffypony>** nice  
**\<dEBRUYNE>** For clarification, a single output is currently \~ 6 kB, whereas a 2-output is \~ 12 kB  
**\<* hotoatmeal** was about to ask  
**\<sarang>** So we'll continue moving forward with porting and testing  
**\<manifest>** serhack here?  
**\<dEBRUYNE>** A typical Monero transaction has 2 ins + 2 outs  
**\<serhack>** yep manifest  
**\<manifest>** i was wondering who was the m8 that was gonna work on the go-library since i started on it myself a little bit swell  
**\<fluffypony>** dEBRUYNE: this would also be a major cost-saving for pool payments  
**\<fluffypony>** manifest: we're in a meeting  
**\<sarang>** For reference, the size of an M-output BP is 32\*(2\*log(64\*M)+9) bytes (this doesn't count the amount commitments)  
**\<sarang>** add 32 bytes for each of the M amount commitments if you want to include them  
**\<sarang>** (log is base 2)  
**\<rehrar>** manifest you can hop on mattermost.getmonero.org. Serhack is also there and you guys can PM and chat so as not to disrupt the meeting. Thanks. :)  
**\<ArticMine>** I have to give some thought to the fees to deal with  the verification issue  
**\<fluffypony>** ok so beyond BP is there anything else worth noting?  
**\<sarang>** We do require a power of 2 in the # of outputs  
**\<pigeons>** So sometimes you just create an additional change output, or how do you cause always a power of 2?  
**\<sarang>** We'll need to either pad with dummy outputs or split into power-of-2 proofs  
**\<ArticMine>** Split the change into two tx  
**\<pigeons>** OK  
**\<sarang>** The dummy output doesn't need to actually represent anything  
**\<sarang>** It just needs to be there for the proof  
**\<sarang>** It can be amount 0  
**\<ArticMine>** that will work also  
**\<sarang>** Anyway, that's my 3 cents  
**\<luigi1111>** Better to split  
**\<luigi1111>** Space is cheap gp  
**\<luigi1111>** Cpu is expensive\*  
**\<ArticMine>** We will have to price cpu  
**\<moneromooo>** There's a possible optimization for "filler" outs AIUI.  
**\<luigi1111>** Probably not as good as not using them :)  
**\<sarang>** There aren't any security proofs for a non-power-of-2 proof  
**\<moneromooo>** I was led to think it was not inherent in the scheme, though ?  
**\<sarang>** It is  
**\<moneromooo>** aw...  
**\<sarang>** At least for right now  
**\<sarang>** There's a recursive step that split arrays in half  
**\<ArticMine>** The issue I see is that the penalty only prices space  
**\<sarang>** The authors of the paper are looking into a generalization, but it doesn't exist yet  
**\<luigi1111>** That's interesting  
**\<fluffypony>** ok so  
**\<fluffypony>** anything else from the last two weeks worth noting?  
**\<sarang>** suraeNoether is completing review for multisig  
**\<sarang>** He is unable to be here today  
**\<Gdhhyfjjs467>** Has a code freeze date for the next for been set yet?  
**\<fluffypony>** Gdhhyfjjs467: yeah we'll be branching towards the end of the month  
**\<fluffypony>** assuming our comfort levels are ok  
**\<rehrar>** This was discussed briefly in MRL channel with the idea that if BPs are not too far off, would it be worth delaying the next hard fork by a couple months so it can be in?  
**\<dEBRUYNE>** The plan is to include multisig right?  
**\<dEBRUYNE>** \^ fluffypony  
**\<luigi1111>** Yes  
**\<fluffypony>** no need to delay the hard fork  
**\<luigi1111>** I don't think the upcoming fork does anything useful though  
**\<luigi1111>** So there's that  
**\<fluffypony>** if BP is ready it'll go into the Sept fork  
**\<dEBRUYNE>** Should we fork if there's nothing to fork for?  
**\<luigi1111>** Who knows ^\_^  
**\<fluffypony>** luigi1111: consistency, then  
**\<fluffypony>** well, that's what we committed to with the fork schedule  
**\<fluffypony>** "even if it's just bumping the block version number"  
**\<dEBRUYNE>** Sure, but didn't we also discuss slowing things down once the ecosystem got bigger?  
**\<moneromooo>** We did not commit to an exact fork schedule.  
**\<luigi1111>** And who is this we :)  
**\<moneromooo>** I, at least, did not :P  
**\<hotoatmeal>** does the wallet release schedule track the protocol fork schedule exactly?  
**\<hotoatmeal>** or do they have different cadences  
**\<moneromooo>** The wallet needs to update for a fairly large subset of consensus changes.  
**\<pigeons>** the wallet-cli and wallet-rpc are included with the daemon release that supports the fork  
**\<moneromooo>** So it's convenient to release at the same time.  
**\<fluffypony>** dEBRUYNE: I don't think we're at a point where we can go to annual  
**\<moneromooo>** Besides, the wallet and daemon rely on the same libs.  
**\<rehrar>** Isn't ZMQ also in the new release? Or has that been there for a while now?  
**\<fluffypony>** yes ZMQ is in the new release  
**\<moneromooo>** There's some of it in, but some of it's still missing.  
**\<pigeons>** there is some support for zmq over rpc, and more is comming, like tx/block notify and some changes to the existing zmq rpc  
**\<pigeons>** \*rpc over zmq  
**\<hotoatmeal>** moneromooo: yeah, mainly thinking about when I need to spend time to get those two memwipe patches (and the third I haven't written yet) reviewed/merged  
**\<pigeons>** the notify is what the people i hear from are waiting for, and tewinget told me a few weeks ago he's got the basics worked out  
**\<rehrar>** Are we still waiting on him for stuff?  
**\<moneromooo>** There's a patch waiting on changes IIRC.  
**\<moneromooo>** (for 0mq)  
**\<rehrar>** *sigh* tewinget, can you please get this stuff done? Seriously.  
**\<moneromooo>** Especially as I think some of the large pool speedups were lost.  
**\<moneromooo>** (not 100% sure)  
**\<hotoatmeal>** is there a way to detect that the network has forked, and your client hasn't gone with it?  
**\<moneromooo>** Kinda.  
**\<hotoatmeal>** my local daemon got left behind on the last one, because I forgot to update  
**\<fluffypony>** you can make an educated guess  
**\<hotoatmeal>** cue colorful headscratching  
**\<moneromooo>** Current daemon should moan if it sees blocks with a higher version than what it knows about.  
**\<fluffypony>** and there's auto-update records that notify  
**\<moneromooo>** The block verison thing is a bit vulnerable to someone mining a bad block on purpose to make you think there's been a fork though.  
**\<fluffypony>** yeah  
**\<moneromooo>** Losing 10 monero in the process or whatever it is :)  
**\<fluffypony>** ok let's move it along, then  
**\<fluffypony>** 3. Code + ticket discussion / Q & A  
**\<fluffypony>** are there any issues that could do with some input / resolution?  
**\<moneromooo>** The handful of oldest ones.  
**\<moneromooo>** The PRNG one.  
**\<moneromooo>** ones.  
**\<moneromooo>** For multisig, I think it's pretty much ready to go in, stoffu's done a lot of careful reviewing.  
**\<fluffypony>** ok - what's the blocker on switching to the Bitcoin one?  
**\<hotoatmeal>** moneromooo: what still needs doing / deciding on your part of the memwipe ones, and how can I help there?  
**\<moneromooo>** Mainly deciding whether we want to, or not.  
**\<moneromooo>** And bitcoin has two RNGs, the one I ported, and one that's closer to what we have. so there's the possibility of entropy attrition using only the "good" one.  
**\<moneromooo>** hotoatmeal: the only thing left IIRC was switching from std::vector\<char> to std::unique\_ptr\<char[]> and I feel more confident getting it right with vector.  
**\<moneromooo>** Other than that, nothing I think.  
**\<fluffypony>** moneromooo: by "good" one you mean the ported one?  
**\<moneromooo>** That can be done later by someoine who's familiar with how the refcounting works with operators though.  
**\<moneromooo>** Yes. The one that uses getrandom, etc.  
**\<fluffypony>** ok so I think if they haven't hit entropy attrition problems over the past few years it's unlikely we will - thoughts?  
**\<moneromooo>** Let me rephrase:  
**\<moneromooo>** Bitcoin has two RNGs: a good one using HW, and a... hmmm, less good ? one similar to our keccak based one  
**\<moneromooo>** Using the keccak based one does not deplete entropy nearly as fast as using the good one. Monero can use a lot of entropy (eg, range proofs).  
**\<moneromooo>** Therefore, I'm wondering whether using the good one all the time is worse than not.  
**\<hotoatmeal>** moneromooo: ok, I'll pick up the vector vs unique\_ptr part of that later this month  
**\<moneromooo>** Thanks  
**\<fluffypony>** ok so what if we used the good one for critical stuff like privkey generation  
**\<fluffypony>** and output selection  
**\<hotoatmeal>** and if you give me some pointers, can look at whatever that refcounted operators thing is in Jan  
**\<fluffypony>** and the stream one for range proofs  
**\<moneromooo>** Well, if I knew that, I'd know the answer to my question, since they're opposites.  
**\<moneromooo>** Anyway, to go back to multisig, I tihnk it's good to go now. If you haven't yet reviewed it, and want to do so, do so now.  
**\* hotoatmeal** drops out  
**\<fluffypony>** ok  
**\<fluffypony>** 4. Any additional meeting items  
**\<moneromooo>** When do we want bulletproofs on testnet ?  
**\<dEBRUYNE>** Tomorrow!  
**\<fluffypony>** hah hah  
**\<moneromooo>** A day may be a bit short to get people to update in time.  
**\<fluffypony>** are we going to wait for the multi output stuff?  
**\<sarang>** I think we should  
**\<moneromooo>** Not sure. This is not quite finished (multiple of 2 requirement), and has a non trivial impact on fees.  
**\<sarang>** Hrmm true, the fee thing  
**\<sarang>** :/  
**\<moneromooo>** And I'd really, really like to get smaller txes double plus quick.  
**\<fluffypony>** ok so how would this work  
**\<ArticMine>** A lot of people do  
**\<sarang>** In case it's relevant, every single-output proof is still a valid multiproof  
**\<moneromooo>** That's nice.  
**\<sarang>** (provided we define the Gi and Hi in the same order)  
**\<sarang>** (not sure if my extended code addressed that, will check)  
**\<moneromooo>** So, no clear votes for or against. Except me ^\_^ so that's 100% of expressed votes :P  
**\* sarang** checks the math on that  
**\<fluffypony>** moneromooo: I asked how it would work  
**\<moneromooo>** The fork ? I imagine similar to rct. Allow bulletproofs at fork f, optionally disallow borromean at f+1.  
**\<moneromooo>** (the code currently does not do that second part)  
**\<moneromooo>** That might become a bit more complicated if we start allowing aggregated proofs at f+1.  
**\<moneromooo>** But not very much.  
**\<dEBRUYNE>** so moneromooo, you'd like to start with single output right? And then eventually switch to multioutput  
**\<moneromooo>** Yes.  
**\<rehrar>** Sorry if this was answered, but is there an ETA on multioutput port from Java?  
**\<moneromooo>** No. It doesn't appear to be a lot of work though.  
**\<fluffypony>** so then txs with more than 1 output would use borromean?  
**\<moneromooo>** No. They'd use two bulletproofs.  
**\<sarang>** yup  
**\<rehrar>** Which is still a savings.  
**\<sarang>** Still great space savings  
**\<sarang>** And no DoS issues  
**\<dEBRUYNE>** 2 bulletproofs is 1.3 kb give or take right?  
**\<fluffypony>** ok  
**\<dEBRUYNE>** And we can keep our current fee structure  
**\<sarang>** dEBRUYNE: yes  
**\<moneromooo>** Most of it, in fact. Txes are ~2.2 kB.  
**\<rehrar>** I think that's worth it. And then it can be enhanced even further with multioutput later. But the immediate savings would be appreciated.  
**\<rehrar>** And gives time for the fee dislogue  
**\<fluffypony>** and what's our confidence level like in this? like is it March-fork-worthy?  
**\<rehrar>** Dialogue\*  
**\<moneromooo>** Well, we can know better if we fork in a couple days on testnet :)  
**\<ArticMine>** I have an idea on the fee issue  
**\<rehrar>** It can be deployed to testnet asap no.  
**\<rehrar>** ?  
**\<moneromooo>** That's what I'm asking about, yes.  
**\<fluffypony>** could we fork testnet this coming weekend?  
**\<moneromooo>** Works for me. Gives time for review.  
**\<rehrar>** Exciting!  
**\<sarang>** Yes and the code should definitely be reviewed by others  
**\<endogenic>** who?  
**\<endogenic>** if you had your pick  
**\<JollyMort[m]>** could someone do me a favor and send me the log of this channel from 2017-04-18?  
**\<sarang>** Ideally andytoshi since he's a paper author  
**\<moneromooo>** If I had my pick...  
**\<sarang>** suraeNoether  
**\<fluffypony>** Satoshi  
**\<endogenic>** fluffypony: on it  
**\<sarang>** Someone who digs the maths  
**\<Gdhhyfjjs467>** So Evan duffield?  
**\<dEBRUYNE>** luigi1111 I guess  
**\<endogenic>** vtnerd hyc fyi  
**\<moneromooo>** Oh yeah, luigi1111 is a good one.  
**\<rehrar>** Let's just get all hands on deck for this?  
**\<endogenic>** ok that means you too rehrar  
**\<Gdhhyfjjs467>** Lol jk. I like andytoshi idea  
**\<sarang>** I'm sure we'll find additional optimizations... I know for a fact my implementation of scalar operations into vectors could be refactored  
**\<rehrar>** I will understand none of it, but I'll look at it and either nod approvingly or cringe based on a coin toss.  
**\<sarang>** but I didn't in Java in order to keep it clean and understandable  
**\<endogenic>** i move to instate rehrar as new RNG  
**\<moneromooo>** The slice op ? Yes, but I don't think it takes much time compared to the muls.  
**\<sarang>** Random Nod Generator?  
**\<sarang>** Well and operations involving many vector ops could run a single loop per element, instead of per operation  
**\<sarang>** but they're generally fast and it makes things clean  
**\<sarang>** I'm not a huge fan of sacrificing clarity for a tiny speedup  
**\<sarang>** I'd like to chat with moneromooo post-meeting about our basepoint selection, to ease the transition into multiproofs later  
**\<sarang>** For those who want to compare code to paper, this is the paper: http://web.stanford.edu/~buenz/pubs/bulletproofs.pdf  
**\<moneromooo>** I pushed the patch as 2883 if people want to start reviewing ^\_^  
**\<rehrar>** Can I make a Reddit post calling devs to review it?  
**\<moneromooo>** Reddit.. devs ?  
**\<dEBRUYNE>** \^ that lol  
**\<rehrar>** :P nvm then  
**\<dEBRUYNE>** The people able to review it will be watching Github  
**\<endogenic>** rehrar: answer is in the question :P  
**\<fluffypony>** oh  
**\<fluffypony>** I guess meeting ~done  
**\<fluffypony>** 5. Confirm next meeting date/time  
**\<fluffypony>** Sunday the 17th