- 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.
<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.18.104.22.168) 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.22.214.171.124) 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 (~firstname.lastname@example.org) 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.126.96.36.199) 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- (~email@example.com) 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 (~firstname.lastname@example.org) 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.188.8.131.52) 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