Main navigation

User account menu

DevMeeting 2017-12-03

Highlights[]

The MRL(Monero Research Lab) has working Java test code for multi-output bulletproofs

Currently being ported to C++ (non-multi-output)

Research is ongoing for how fee structures are impacted (a large number of outputs could form a Denial of Service)

A Single output BulletProof(BP) is 704 bytes - and a 2 output is ~768 bytes. For comparison, single and double outputs in the current version of Monero are 6k and 12k, respectively.

In testing, most BulletProof transactions average about 2.2k

BulletProofs may make the September 2018 fork.

A testnet build might be ready within a week.

A code freeze is scheduled for the end of this month (Dec 2017)

Surae Noether is completing his review of Monero's MultiSig implementation.

MultiSig is expected to be included in the freeze (so it will be in the next release).

If you're interested in the development aspect or code review for MultiSig, *now* is the time to look.

ZeroMQ(0MQ) is also expected to be in the next release. But at this point there are still some features missing.

Research continues into switching Monero's Random Number Generator(RNG) to one of Bitcoin's.

Full Log[]

<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
<iDunk> o/
<fluffypony> luigi1111 (if you're back) / smooth / hyc / moneromooo etc.
<moneromooo> here
<gingeropolous> etc here
* hotoatmeal watching
* WWW-XMRTalk-Org| (b84bd44d@gateway/web/cgi-irc/kiwiirc.com/ip.184.75.212.77) has joined
<fluffypony> 2. Brief review of what's been completed since the previous meeting
<Slack_3> <serhack> hi :slightly_smiling_face:
<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
<Slack_3> <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)
<Slack_3> <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
* Gdhhyfjjs467 (adf42c28@gateway/web/cgi-irc/kiwiirc.com/ip.173.244.44.40) has joined
<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
* WWW-XMRTalk-Org| has quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client)
<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
* amiuhle (~amiuhle@206.223.178.27) has joined
<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
<Slack_3> <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.
<Slack_3> <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
* cialu has quit (Ping timeout: 240 seconds)
<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
<Slack_3> <rehrar> Are we still waiting on him for stuff?
<moneromooo> There's a patch waiting on changes IIRC.
<moneromooo> (for 0mq)
<Slack_3> <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.
* Gdhhyfjjs467 has quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client)
<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
* Gdhhyfjjs467 (adf42c28@gateway/web/cgi-irc/kiwiirc.com/ip.173.244.44.40) has joined
<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.
<Slack_3> <rehrar> Sorry if this was answered, but is there an ETA on multioutput port from Java?
* Huskar has quit (Quit: Konversation terminated!)
<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?
* blasty- (~blasty@shadowbroke.rs) has joined
<moneromooo> No. They'd use two bulletproofs.
<sarang> yup
<Slack_3> <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.
<Slack_3> <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.
<Slack_3> <rehrar> And gives time for the fee dislogue
<fluffypony> and what's our confidence level like in this? like is it March-fork-worthy?
<Slack_3> <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
<Slack_3> <rehrar> It can be deployed to testnet asap no.
<Slack_3> <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.
<Slack_3> <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.
<Slack_3> <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
<Slack_3> <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?
* cialu (~cialu@151.41.130.127) has joined
<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
* nicksname has quit (Ping timeout: 260 seconds)
<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
* nicksname (adf43028@gateway/web/freenode/ip.173.244.48.40) has joined
<moneromooo> I pushed the patch as 2883 if people want to start reviewing ^_^
<Slack_3> <rehrar> Can I make a Reddit post calling devs to review it?
<moneromooo> Reddit.. devs ?
<dEBRUYNE> ^ that lol
<Slack_3> <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