Overview and Logs for the Dev Meeting Held on 2017-12-03
December 03, 2017
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. 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
Post tags : Dev Diaries, Monero Core, Cryptography