Commit 4acbc0fe authored by luigi1111's avatar luigi1111
Browse files

Merge !1081

May meeting logs

See merge request monero-project/monero-site!1081
parents f20fabc9 2a99d847
layout: post
title: Logs for the Monero Research Lab Meeting Held on 2019-05-14
summary: Surae work, Sarang work, and miscellaneous
tags: [community, crypto, research]
author: el00ruobuob / sarang
# Logs
**\<sarang>** Agenda:
**\<sarang>** Logs of this meeting will be posted there
**\<sarang>** GREETINGS
**\<suraeNoether>** howdy!
**\<suraeNoether>** how is everyone?
**\<suraeNoether>** who had fun at MCC? \*this guy\*
**\<suraeNoether>** okay
**\<suraeNoether>** well let's beign
**\<suraeNoether>** begin\*
**\<suraeNoether>** for the roundtable portion
**\<suraeNoether>** let's start with general questions from the audience, and let's go around and see if anyone has anything to present
**\<suraeNoether>** other than sarang and i anyway
**\<sarang>** Heh, I suppose we can move to presentations
**\<suraeNoether>** yup
**\<sarang>** go ahead suraeNoether
**\<suraeNoether>** go ahead sir
**\<suraeNoether>** ahah
**\<sarang>** jinx
**\<suraeNoether>** okay
**\<suraeNoether>** well, CLSAG paper is undergoing the final round the corner. sarang and i are working on the final details today with randomrun, and i hope we can make a public version of the paper available in the next several days (unless some flaw is found)
**\<sarang>** Yeah, just need that timing data and a definite answer on the hash coeffs in the proof
**\<suraeNoether>** DLSAG paper is undergoing further review, but I believe we are putting up an IACR version of that in the coming days also
**\<sarang>** Yep, waiting on all authors to sign off
**\<suraeNoether>** MRL11 is still in progress, but now that clsag and dlsag are off my plate, it's being cranked up in terms of priority
**\<suraeNoether>** i anticipate rapid progress on that as well
**\<suraeNoether>** May 20-24, sarang and endogenic and I are doing the Monero workshop, and I believe we may be having Gao from Clemson come give us talks on starks and fully homomorphic encryption in the RLWE setting
**\<suraeNoether>** (sarang, we should do some studying before then together on that)
**\<sarang>** of course
**\<suraeNoether>** I gave a talk, sat on a panel, and gave an interview at the magical crypto conference
**\<suraeNoether>** all of those are up on youtube; the talk was about four different branches of research here at MRL
**\<suraeNoether>** other than that, i guess i'd prefer answering questions rather than talking myself into a rabbit hole
**\<suraeNoether>** nioc and i have had some conversations about how long-winded i can be so i'm going to zip it unless folks want more details :D
**\<sarang>** Any questions for suraeNoether on this work?
**\<suraeNoether>** so, for the audience members who are new
**\<suraeNoether>** DLSAG = dual-recipient output signatures = work toward the claim-or-refund primitive that can underly smart contracts and lightning network. CLSAG = compressed signatures making the rate of growth on the monterion blockchain hopefully 25% smaller and faster to verify
**\<suraeNoether>** MRL11 = traceability resistance analysis
**\<suraeNoether>** so, work is important, hard, and slow going, but doing it right is very important to us
**\<suraeNoether>** anyway, sarang, how about yourself?
**\<sarang>** Plenty to mention
**\<sarang>** I had overhauled some definitions and such in the CLSAG paper, which suraeNoether has completed more edits on
**\<sarang>** In particular, some stuff on multi-asset transactions that could be enabled by this
**\<sarang>** I'll get timing data and then we can release for review
**\<moneromooo>** "multi-asset" being akin to coloured coins ?
**\<sarang>** ya
**\<sarang>** Not saying I'm recommending such a thing for us, but it's an easy application
**\<sarang>** I've been working on some draft protocols for how a Monero coinjoin could work
**\<sarang>** Right now the initial scheme requires a certain amount of trust in a dealer, but is very efficient
**\<sarang>** This is obviously not ideal
**\<sarang>** MoJoin, I call it
**\<sarang>** FWIW it doesn't leak spend data to the dealer, only the partition of inputs-and-outputs to each player in the join
**\<sarang>** sgp\_ and I did two Breaking Monero episodes, one on input/output counts and one on block explorers
**\<sarang>** that's the main stuff for me
**\<suraeNoether>** oh, guys: we are deciding to extend early-bird pricing for a few more days
**\<suraeNoether>** i'll be advertising it
**\<suraeNoether>** but don't forget to get your ticket at before prices change, if you are still coming
**\<suraeNoether>** students are especially encouraged to attend; there will likely be partial rebates at the door for student tickets
**\<sarang>** Any particular questions for me?
**\<suraeNoether>** how many rounds of interaction in mojoin?
**\<moneromooo>** The "Gao [...] fully homomorphic" thing makes me wonder if that could not be looked at in conjunction with dealerless coinjoin :)
**\<sarang>** 3
**\<sarang>** This is minimal because of the BP MPC
**\<suraeNoether>** yeah, that's cool. moneromooo i think that's probably a safe avenue of stuff for us to talk about
**\<sarang>** Er, no... 4 rounds now, sorry
**\<sarang>** I had to make a change
**\<suraeNoether>** oh
**\<sarang>** The extra round is to avoid commitment sums being used to brute-force the partition by an observer
**\<sarang>** Making the resulting transaction identical to one not MoJoined (although the output count is something of a giveaway)
**\<moneromooo>** BTW, something I've not done in the branch is merging outputs to the same destination (originally the intent was to make Alice + Bob atomically paying Carol).
**\<moneromooo>** Would that be possible with the dealer based coinjoin ?
**\<sarang>** So A+B generate a single joint output?
**\<moneromooo>** yes.
**\<sarang>** I don't think it's possible to do the BP MPC without leaking the full mask
**\<sarang>** unless that's acceptable
**\<moneromooo>** That's fine in that case since Alice and Bob to advertise what they're paying, since each of them verifies the other does pay.
**\<sarang>** Would this assume another side channel between them that's outside of the join?
**\<sarang>** So it'd be a plug-and-play operation into a join?
**\<moneromooo>** I dunno. If you need one I guess.
**\<sarang>** Hmm
**\<sarang>** It's probably possible, under the right trust model between A+B
**\<sarang>** Of course, "probably possible" is quite the weaselworld
**\<sgp\_>** I'm here and caught up, sorry for being late
**\<sarang>** hi
**\<suraeNoether>** nbd
**\<sarang>** talking coinjoin
**\<fort3hlulz>** Whats the advantage for Monero in using a CoinJoin implementation? if its better to chat later about it Ill shutup :)
**\<suraeNoether>** no, that's a great question
**\<moneromooo>** It adds another layer of privacy. If Eve looks at one tx, she can't assume anymore than all the inputs are from hte same owner.
**\<sarang>** Yeah, it tries to break the common-ownership assumption
**\<fort3hlulz>** Ah, so its a mitigation of poisoning/EAE attacks specifically? How does it affect Tx size/blockchain bloat?
**\<sarang>** My thought about the dealer model (if it's a necessity, which is yet TBD) is that under a malicious dealer assumption, you basically revert back to the current model
**\<moneromooo>** If we're lucky, smaller txes since one single BP :)
**\<sarang>** Another quick note that hyc and I had a call with Trail of Bits, an auditor who submitted a SoW
**\<sarang>** they'll be updating their numbers, and noted that another project may be interested in helping fund RandomX
**\<sarang>** We'll have a call with those folks tomorrow
**\<hyc>** Hi, just finished my other call
**\<sarang>** yo
**\<hyc>** yeah, some good stuff from Trail of Bits
**\<fort3hlulz>** Awesome, I'm excited to learn more about CoinJoin on Monero as well as CLSAG, thanks guys! Ill get out of your hair now :)
**\<sarang>** Thanks for the question fort3hlulz
**\<sarang>** The security of coinjoins in Monero is still very much in the air
**\<hyc>** also for the benchmark freaks (like me) Huawei has offered to give me access to some servers with their newest chip, for benchmarking purposes
**\<hyc>** will be getting efficiency numbers for CN/R and RandomX on ARMv8
**\<suraeNoether>** ooooh
**\<suraeNoether>** thats... fantastic...
**\<sarang>** nice
**\<hyc>** thes guys
**\<sarang>** We'll post the ToB updated SoW when they provide it
**\<suraeNoether>** and MRL marches forward into tomorrow's yesterday of the future^tm
**\<hyc>** general availability is end of June, early access is nice
**\<hyc>** that's all for me
**\<sarang>** Does anyone else have research to present?
**\<sarang>** Or general questions at all?
**\<suraeNoether>** whats the coolest plane you've flown?
**\<luigi1113>** what kind of pie do you like?
**\<suraeNoether>** berry berry
**\<sarang>** suraeNoether: commercially, or piloting myself?
**\<suraeNoether>** with greek yogurt
**\<suraeNoether>** ^ both
**\<sarang>** Commercially, Nepal
**\<sarang>** Myself, in between buildings in downtown San Francisco and the Golden Gate
**\<sarang>** which apparently is legal
**\<suraeNoether>** not place, plane, but i'll accept your answer happily
**\<suraeNoether>** that's awesome
**\<sarang>** Oh heh, didn't see that
**\<sarang>** Commercially, B787
**\<sarang>** Myself, probably a DA40
**\<sarang>** it's got the aerodynamics of a glider
**\<sarang>** WEll
**\<sarang>** Let's move to action items
**\<sarang>** suraeNoether: ?
**\<suraeNoether>** final dlsag review today
**\<suraeNoether>** mrl11 rest of the week
**\<suraeNoether>** uhmmm... and if anything else is handed back to me like clsag
**\<sarang>** word
**\<suraeNoether>** adjective
**\<sarang>** I'll get those CLSAG timings into the paper and finalize the proof question we had
**\<sarang>** Carry on with MoJoin
**\<sarang>** etc.
**\<sarang>** Any final words before we formally adjourn?
**\<dEBRUYNE>** Perhaps a blog post from CLSAG could be written (similar to the one for Bulletproofs)
**\<suraeNoether>** just excited for lunch
**\<sarang>** "Signatures. They are smaller and faster."
**\<dEBRUYNE>** I don't think many community members would understand CLSAG from the technical paper alone :P
**\<sarang>** But yes, we could do that once we're satisfied with security
**\<sgp\_>** People need these blog posts or else no one will know
**\<suraeNoether>** dEBRUYNE: that would be good, yes.
**\<sarang>** All righty, thanks to everyone for attending
**\<sarang>** We are now formally adjourned; logs will appear shortly
layout: post
title: Overview and Logs for the Dev Meeting Held on 2019-05-19
summary: Development status, Code & ticket discussion, and miscellaneous
tags: [dev diaries, core, crypto]
author: el00ruobuob / rehrar
# Logs
**\<xmrmatterbridge> \<rehrar>** Meeting!!
**\<ferretinjapan>** rehrar, o/
**\<moneromooo>** rehrar: btw, did you get any new info from purism ?
**\<jwinterm>** \\o
**\<xmrmatterbridge> \<rehrar>** Yes. Will update. Did update in -community
**\<hyc>** time
**\<xmrmatterbridge> \<rehrar>** Hello guys. Let's start the meeting.
**\<xmrmatterbridge> \<rehrar>** 1. Greetings
**\<ErCiccione>** Hi
**\<rbrunner>** Hi
**\<vtnerd>** hi
**\<hyc>** hi
**\<jwinterm>** so long rbrunner
**\<rbrunner>** Connection problems ... back again
**\<rehrar>** Alright
**\<rehrar>** 2. What's been done since previous meeting?
**\<rehrar>** right, well, let's jump to that then. It's what we're all anxious to hear about anyways.
**\<hyc>** OK, so we have 4 SoWs from audit teams, we had an unexpected bonus from agreeing to pay for the TrailofBits audit
**\<hyc>** the vote on auditor selection is closed and tallied, Kudelski is the clear first choice
**\<hyc>** Quarkslab and X41 nearly tied for 2nd choice but QL slightly ahead
**\<hyc>** and majority voted for 3 choices, so it seems we are going to submit all 3 in CCS
**\<hyc>** randomX integration in monerod is mostly there, we have some bug with reorg handling at the moment
**\<rehrar>** What's the cost of all three, hyc?
**\<hyc>** but otherwise the patch has all the functionality we seem to need, including support for mining RPCs so pools and solo miners can work
**\<tevador>** ~$120K
**\<hyc>** rehrar, let me get back to you in a few minutes. move on to next topic till I tally
**\<hyc>** ^^ there you go
**\<rehrar>** ok
**\<rehrar>** Standard CCS concerns, since Defcon will be putting up a couple of CCS stuff too here not so far from now
**\<rehrar>** I'll contact Outreach workgroup to try to do something to get everyone on board and donating, but sure.
**\<rehrar>** Anything else on that hyc?
**\<hyc>** I would structure it in priority order, and if we don't get full funds, we just omit the last choice
**\<hyc>** I think that covers it for me, yeah
**\<rehrar>** awesome, thanks for all of your guys' work on this. It's exciting stuff.
**\<rehrar>** Anyone else have anything that's been done past couple of weeks?
**\<moneromooo>** monerod can now sync on big endian ^\_^
**\<hyc>** woohoo!
**\<rbrunner>** Wow. Is that still a thing?
**\<hyc>** IBM POWER, Fujitsu / oracle SPARC
**\<hyc>** big datacenter boxes, sure
**\<rbrunner>** Nice to have anyway!
**\<rehrar>** the improvements that really matter
**\<rehrar>** :P anyways, I can also give an update regarding Purism if desired.
**\<rehrar>** I had a meeting with Todd, the CEO a few days ago.
**\<rbrunner>** Please do
**\<rehrar>** They're still just as excited about Monero. They aren't really interested in other cryptocurrencies, because only Monero has the ideology of privacy by default, similar to them. They're still very excited about integrating Moenro into Librem Pay
**\<rehrar>** so one can theoretically pay using Monero anywhere at any merchant, and merchant settles in fiat.
**\<rehrar>** still want to ship Monero by default on all of their systems, mobile and desktop.
**\<rehrar>** They don't have any available dev kits for the Librem5 phone for the devs to mess around with, but they are going to get me emulators for their PureOS stuffs.
**\<rehrar>** And we can start playing with the GUI and stuff on there and make it adaptive, if possible, and the like
**\<rehrar>** They're willing to do a matching thing on a CCS proposal that we do
**\<rehrar>** As in, if we raise x amount of money, they'll put in x as well (up to some upper limit for them) for a dev to work on this stuff.
**\<jtgrassie>** By "ship Monero by default", do they mean ship with full-node + wallet?
**\<rehrar>** dsc\_ has expressed a willingness, but I'm not going to put words in his mouth, so you can talk to him for more info
**\<rehrar>** jtgrassie: that's for us to figure otu
**\<rehrar>** \*out
**\<rehrar>** the Librem5 phone is indeed a phone, but you will be able to connect it to a monitor and use it as a desktop also, as the OS itself will be adaptive.
**\<rbrunner>** Nice that things seem to get moving, they seem excited already for quite some time ...
**\<rehrar>** So we can choose how we want the GUI to be put on there.
**\<vtnerd>** yeah the light-wallet-server setup is probably more appropriate, but people have synced the chain to their phone
**\<rehrar>** Obviously, since there is the idea that you can do whatever you want on their phone with no abritrary restrictions, the idea that someone can theoretically run a full node on their phone should not be overlooked
**\<hyc>** are they using a micro-HDMI port, or just something like chromecast to use external monitor? just curious, not important
**\<jtgrassie>** Having purism simply accept Monero as a payment method first would be nice
**\<vtnerd>** the issue might be storage on that sucker, I dont see sd card listed ... ?
**\<moneromooo>** They do.
**\<moneromooo>** Or did, at least.
**\<rehrar>** jtgrassie: they do accept Monero
**\<jwinterm>** hyc: it looks like it will go usb-c to hdmi or display port (tbd)
**\<jtgrassie>** moneromooo: not an option at checkout
**\<jtgrassie>** rehrar: ^
**\<hyc>** jwinterm thanks
**\<rehrar>** there is "Cryptocurrencies" option
**\<jtgrassie>** Oh, my bad, Globee
**\<rehrar>** and it's done via Globee
**\<rehrar>** anyways, that's it from me. I'll ping them in this upcoming week about the emulators
**\<rehrar>** and discussion may pop up from time to time in -gui
**\<rehrar>** and maybe here
**\<rehrar>** we'll be in contact with you mooo, if things need to happen on the core side
**\<rehrar>** but PureOS is Debian-based, so I don't think anything crazy will need to happen
**\<hyc>** rehrar tell them they need a -Pro model with landscape aspect slideout qwerty keyboard
**\<rehrar>** I'll see what I can do to pass that along. :P
**\<jtgrassie>** I guess shipping the wallet by default would be nice. Easy to do.
**\<rbrunner>** Hmmm, yes, like Psion 5mx
**\<rehrar>** Yes, that's the plan. It's one of the default softwares on their phone
**\<endogenic>** hi all
**\<rehrar>** \*it'd be
**\<rehrar>** anyone else have something to report or talk about?
**\<ErCiccione>** I have a quick update. The Monero Ecosystem has a new member: go-monero-rpc-client. The repo is not transferred yet, but it has been approved: We didn't have anything in golang before, so i think it's cool to have it.
**\<rehrar>** That's pretty neat.
**\<hyc>** I wonder if the RandomX repo should be in Ecosystem
**\<rehrar>** I would think it'd be better suited for Monero Project?
**\<ErCiccione>** hyc: it would be more than welcome
**\<hyc>** I guess it's up to tevador to decide where he wants it to live
**\<rehrar>** Ecosystem is typically Monero-only things, and while RandomX is be built by Monero for Monero
**\<rehrar>** it should be agnostic in theory, no?
**\<rehrar>** as in, other coins can adopt it?
**\<hyc>** and we already have a 3rd party Arweave planning to use it
**\<rehrar>** Similar to OpenAlias in that respect.
**\<rehrar>** So my suggestion to tevador would be in the Monero Project set of repos
**\<hyc>** ok
**\<ErCiccione>** Well, was created by monero developers for Monero. I think hosting it on a Monero "place" is apropriate
**\<rehrar>** on the "new"
**\<rehrar>** Alright, any code discussion to happen as a 3 or 4 or whatever?
**\<rehrar>** If not, we can adjourn and go to markets to speculate on the rise of the market.
**\<rehrar>** unless someone had other meeting items?
**\<hyc>** anything more to say on next point release?
**\<rehrar>** ooooh yes plz
**\<hyc>** moneromooo ?
**\<moneromooo>** Waiting on pony to build binaries AFAIK.
**\<ErCiccione>** core is branched and GUI is waiting for core. Translations for GUI are being submitted, but we are having a lot less contributors than the last release
**\<sarang>** When is freeze for the Carbon Crab update?
**\<rehrar>** \*Crap
**\<sarang>** MRL is feverishly working on CLSAG
**\<endogenic>** an MRL workshop is occurring this week. any requests as to topics of discussion
**\<moneromooo>** Lightning/Bolt building blocks ^\_^
**\<sarang>** Fo sho
**\<rehrar>** so....
**\<rehrar>** we gucci?
**\<sarang>** When is the freeze?
**\<sarang>** For Carbon
**\<moneromooo>** Whenever we're done :)
**\<sarang>** Lol
**\<rehrar>** I think it's quite dependent on the audits
**\<rehrar>** no?
**\<rehrar>** if we're planning on getting them in, that is
**\<sarang>** For randomx?
**\<hyc>** freeze for October hardfork you mean?
**\<sarang>** Goal is to finish by July IIRC
**\<sarang>** Ya
**\<sarang>** If we choose to get CLSAG audited that adds time
**\<rehrar>** Monero is technically made of money
**\<rehrar>** so I don't see a huge problem
**\<endogenic>** it's people
**\<rehrar>** so, question answered then?
**\<rehrar>** regardless of how unsatisfactory
**\<sarang>** Not really, but ok
**\<endogenic>** how about, when will we know when the freeze will be?
**\<rbrunner>** In the two years I am here now I never saw a real freeze happen :)
**\<rbrunner>** Only attempts ...
**\<rbrunner>** Not that there was a real problem with this
**\<ErCiccione>** so true.. i've been begging for one for a long time
**\<hyc>** one could say the code is currently in a frozen state, since nothing can be merged until fluffy resurfaces
**\<rbrunner>** lol
**\<sarang>** What a time to be alive
**\<ErCiccione>** hyc: luigi got the power now. HE is the leader of Monero afterall
**\<ErCiccione>** at least according to wikipedia
**\<hyc>** oho
**\<rehrar>** alright, I think we're pretty much done then. :)
**\<hyc>** sounds like it
**\<hyc>** adios
**\<rehrar>** Two weeks from now? The second?
**\<rehrar>** cya guys
layout: post
title: Logs for the Monero Research Lab Meeting Held on 2019-05-20
summary: Sarang work, Surae work, and miscellaneous
tags: [community, crypto, research]
author: el00ruobuob / suraeNoether
# Logs
**\<suraeNoether>** allright everyone
**\<suraeNoether>** welcome to our weekly research meeting
**\<suraeNoether>** sarang is a bit behind this morning, but we'll begin anyhow
**\<suraeNoether>** agenda is here
**\<suraeNoether>** we'll begin with: GREETINGS!
**\<suraeNoether>** howdy everyone, I'm surae
**\<suraeNoether>** anyone else here?
**\<sarang>** Hi, sorry to be late
**\<sarang>** Preparing for travel today
**\<sarang>** How's it going, all?
**\<suraeNoether>** i feel like a roundtable requires more than two people, otherwise it may be more like a linetable amiright
**\<sarang>** Eh, no worries. Plenty to catch up on
**\<sarang>** Let's move on to roundtable anyway
**\<sarang>** May I go first, with a few tiny things?
**\<sarang>** Then plenty of CLSAG talk
**\<suraeNoether>** fire away brother
**\<sarang>** Neato
**\<sarang>** I'm working with the author of the output-flooding paper so he can get new results using correct network assumptions
**\<sarang>** I've been working on the CLSAG proofs/definitions with suraeNoether (more on that to follow)
**\<sarang>** Assisting hyc et al. with the RandomX audit logistics and planning
**\<sarang>** And a bit more (but not much more) work on the MoJoin scheme
**\<sarang>** That is all!
**\<sarang>** Any questions on those prior to suraeNoether's update?
**\<moneromooo>** I suppose the "not much more" means there's no solution yet for a values ?
**\<sarang>** Not without some trust in the dealer (or a designated player)
**\<sarang>** And now, on to suraeNoether
**\<suraeNoether>** well, I spent this week writing a new definition of unforgeability for linkable ring signature schemes for the clsag paper, and reading updates on the dlsag paper
**\<sarang>** That CLSAG definition is surprisingly subtle
**\<suraeNoether>** clsag is looking like a 15-20% reduction in rate of growth of blockchain size, 15-20% improvement in verification speed, and we are formally proving signer ambiguity in a way that I think hasn't been done yet
**\<sarang>** To sum up the earlier work, what remains on the proofs in your opinion? (I'll be reviewing its current state today on an aeroplane)
**\<suraeNoether>** the only proof that remains right now is the proof for signer ambiguity and reducing it to the DDH problem
**\<suraeNoether>** but i think it may be another weird variant like k-one-more DDH
**\<sarang>** Eh, even so
**\<suraeNoether>** our unforgeability reduces to k-one-more discrete logarithm, for example
**\<sarang>** yup
**\<suraeNoether>** there has been a back and forth between sarang, myself, and randomrun on the final proof and the utility of the colored coins section
**\<sarang>** RandomRun mentioned a possibility for shifting the auxiliary key over to the other side of the hash
**\<sarang>** key(s)
**\<sarang>** (in the case of multi-type colored transactions)
**\<suraeNoether>** oh yeah, he also noticed a way to aggregate all these dummy key images and it's possible he just made it even freaking smaller
**\<sarang>** I'm not totally convinced of this just yet
**\<suraeNoether>** i want it to be true
**\<sarang>** Heh
**\<sarang>** But essentially classifying the signing and aux keys by their linkability status is interesting
**\<suraeNoether>** oh, also, i have printed the new ringct3.0 paper that was put on IACR this morning, and i imagine that will be a big topic of conversation at this informal monero workshop sarang and I are meeting up at
**\<sarang>** Yes, it uses a Bulletproofs-style proving system
**\<sarang>** and, if correct, is an honest-to-goodness trustless ring signature transaction system
**\<sarang>** Link:
**\<suraeNoether>** at this point, we have a handful of sublinear ring signature proposals and proving systems on the table for upgrading to Monero 2.0
**\<suraeNoether>** i don't think "electric bugaloo" translates to esperanto well
**\<suraeNoether>** but that's sort of what I would like to come out of MRL over the next 6-9 months
**\<sarang>** What do we all think about the CLSAG timeline, realistically speaking?
**\<sarang>** Presumably we'd be freezing for Carbon Crab in August
**\<sarang>** If we desire to get CLSAG audited, that's additional time
**\<sarang>** I would prefer to release the paper draft as soon as we have the proofs done (and before adding in other extra goodness, like multi-type transactions)
**\<suraeNoether>** well, everything is proven except a single theorem in an appendix, so i'd be comfortable releasing a draft of it today with "DRAFT" plastered all over it, presuming you and randomrun are cool with that
**\<suraeNoether>** i think it's possible that after you read the appendix, youare of the opinon that the proof is unnecessary, but i'd rather err on the side of having it and removing it rather than excluding it
**\<sarang>** That's a great timeline
**\<suraeNoether>** either way, i can't imagine the draft will not be finished before the end of the monero workshop this week, and if we are going to get it audited, we should move on that sooner rather than later
**\<sarang>** It would be nice to get it in for Carbon Crab, but better to wait if it would mean rushing
**\<sarang>** Such an audit would likely be fairly cheap, since the base code changes are quite minimal and straightforward
**\<suraeNoether>** actually
**\<suraeNoether>** i feel like the clsag change is far-reaching, and the scope of an audit could be... well, let's talk about that
**\<sarang>** How so? There are two sides: the math, and the implementation
**\<suraeNoether>** well, consider implementing bulletproofed range proofs
**\<suraeNoether>** drop-in replacement for a little black box that sits inside our code
**\<sarang>** The basic signature functions (and their underlying crypto changes) amount to surprisingly little
**\<sarang>** and you can almost trace line-by-line the changes from MLSAG
**\<suraeNoether>** except it's not for a single small drop-in black box part of a bigger machine
**\<sarang>** It almost is
**\<suraeNoether>** it \*is\* the machine, in a certain sense
**\<sarang>** Well, that'd be up to an auditor to gauge the complexity of
**\<suraeNoether>** i'm not arguing against an audit, i'm merely wondering aloud about the scope
**\<sarang>** At any rate, once we're confident in it, I can contact some reviewers to get estimates
**\<sarang>** I'd say from the transaction model (full vs simple) onward
**\<sarang>** So, once you hit where MLSAG is directly called, the scope ends
**\<sarang>** This tests whether the security is at \_least\_ as good as MLSAG
**\<sarang>** Anyway, that's more of a future discussion TBH
**\<suraeNoether>** well, we're going to need more formal specifications for CLSAG for use in such an audit either way, and i agree it's water not yet under this bridge
**\<sarang>** Any other intriguing work to share suraeNoether ?
**\<sarang>** The workshop will certainly bring many more interesting things to the next meeting
**\<suraeNoether>** MRL11 has seen no progress since last week due to the time crunch of clsag and dlsag, but it's a really high priority for me due to the privacy of our users
**\<suraeNoether>** i'd love to put signature scheme downs and work on sims
**\<sarang>** Well, an action item is surely to get CLSAG pushed out for more review
**\<suraeNoether>** yes
**\<sarang>** I shall have to leave momentarily to head to an aeroport
**\<suraeNoether>** any questions for me or sarang?
**\<sarang>** But my action items are to get CLSAG finished up, and continue working on that output flooding data... as well as the workshop this week
**\<moneromooo>** If that new rct3.0 system uses BPs, presumably it lends itself well to multiexps, and then gets to be faster too (pro rata) ?
**\<moneromooo>** ie, still linear, but nice constants ?
**\<sarang>** Possibly
**\<sarang>** There may be issues with generators
**\<suraeNoether>** moneromooo: i'm very excited to compare rct3.0 with a super secret paper sarang and i have been reading for a week or so
**\<sarang>** At least for batching
**\<suraeNoether>** personally i like having more than one sample of similar techniques because it makes it seem like generalizing is easier
**\<suraeNoether>** anyway
**\<moneromooo>** Ah, the secret rct.3.14159 paper...
**\<suraeNoether>** fractional ring sizes are the future
**\<suraeNoether>** differentiable signatures are also the future
**\<suraeNoether>** the future of today's tomorrow... yesterday.^tm
**\<moneromooo>** One could say... differentiable signatures are integral to the future ?
**\<suraeNoether>** damn
**\<suraeNoether>** moneromooo is the best of us
**\<moneromooo>** In stupid puns at least.
**\<suraeNoether>** okay, since sarang has to take off for el aeropuerto and i, also, need to pack
**\<suraeNoether>** i say we bring today's meeting to a close
**\<suraeNoether>** i'll see some of you in person tonight and tomorrow. :P
layout: post
title: Overview and Logs for the tini2p Dev Meeting Held on 2019-05-23
summary: Current project status, Roadmap, Meta issues, and miscellaneous
tags: [dev diaries, i2p, crypto]
author: el00ruobuob / oneiric
# Logs
**tini2p** 0: Greetings
hello to the void
1: What's been done
I2NP messages + processing
NetDB initial implementation
Global housekeeping refactors
Endian util removing Boost::Endian dependency
endian util was merged here: tini2p/tini2p!7
I2NP + NetDB + housekeeping is in this open merge request: tini2p/tini2p!8
Tunnel messages + processing still need implementation, along with some of the other networking parts of NetDB (that require Tunnels)
**tini2p** will discuss more about Tunnels in the next meeting item
global housekeeping was for style + correctness, cleaning up some early spaghetti code
some housekeeping remains, so it's definitely still WIP
2: What's to come
ECIES updates following #ls2 discussion and prop. 144 updates
Experimental Tunnel impl under ECIES
Writing a proposal for Tunnel changes under ECIES, following goals of prop. 144
Use standalone ASIO to replace Boost::ASIO dependency
my initial experimental ECIES implementation diverges a bit from the current spec proposal
will be updating the code to match the most recent revisions, and discussions from #ls2 meetings
some mismatch going forward is to be expected, since there are a number of TBD sections in 144
**tini2p** the hope is to get an MVP impl working, and come together on the necessary changes for the spec
similarly, Tunnel changes under ECIES were left out of prop. 144, and I will be implementing an MVP following the spec goals of 144
after getting something working, will write up a companion spec proposal for Tunnels under ECIES
one difficulty/interesting design challenge will be I2NP fragmenting + encryption for fixed-length tunnel messages
during this next run, I will also be replacing Boost::ASIO with standalone ASIO, completely removing Boost dependencies
**tini2p** no Boost will hopefully reduce overall code size
it will also ironically increase platform portability, since the project won't be tied to any particular Boost version (since no Boost)
for tini2p's separate client library, HTTP/WebSockets will be an interesting problem to solve
hopefully by the time the client library is being implemented, Beast will also have a standalone option
the first two items (ECIES + Tunnels) will likely take a large amount of time, probably spanning the next few weeks (if not more)
**tini2p** the goal is still to have a working (able to talk to other routers via Tunnels) by alpha release (2019-07-10)
`#ls2` I2P meetings have been very productive the last few weeks, and will hopefully continue to be moving forward
short meeting today
3: Next meeting time
2019-06-06 18:00 UTC
meeting closed
layout: post
title: Logs for the Community Meeting Held on 2019-05-25
summary: Community highlights, CCS updates, Workgroup report, and miscellaneous
tags: [community, crypto]
author: el00ruobuob / rehrar
# Logs
**\<xmrmatterbridge> \<rehrar>** Let's get ready to rumble!!!
**\<xmrmatterbridge> \<rehrar>** Meeting time!!!
**\<xmrmatterbridge> \<rehrar>** More exclamation marks are always helpful.
**\<xmrmatterbridge> \<rehrar>** 1. Greetings
**\<xmrmatterbridge> \<rehrar>** Which of you lamewads are here today?
**\<ErCiccione>** Hi
**\<sarang>** Yo
**\<xmrmatterbridge> \<rehrar>** Even if it's just us three, I couldn't ask for a better group. :')
**\<ErCiccione>** \<3
**\<el00ruobuob\_[m]>** Hi
**\<xmrmatterbridge> \<rehrar>** Well, others can trickle in as they are able.
**\<xmrmatterbridge> \<rehrar>** 2. CCS Stuffs.
**\<xmrmatterbridge> \<rehrar>** Well, before that, as always, rehrar does an incredible, impeccable, unreplaceable, and astounding job with the Revuo which has a lot of community updates.
**\<xmrmatterbridge> \<rehrar>** Latest is here.
**\<xmrmatterbridge> \<rehrar>** I assume that's why community updates were removed, anyways.
**\<xmrmatterbridge> \<rehrar>** Ok, CCS Stuffs.
**\<xmrmatterbridge> \<rehrar>** So...first and foremost, we're in a bit of an awkward situation.
**\<\_Slack> \<intj440>** hello
**\<xmrmatterbridge> \<rehrar>** The proposal for RandomX audits is fully funded.
**\<el00ruobuob\_[m]>** that's good news!
**\<xmrmatterbridge> \<rehrar>** Despite many (even a perceived majority) in the community thinking a fourth audit has diminishing returns, and shouldn't be done.
**\<xmrmatterbridge> \<rehrar>** But those who donated, did so under the assumption that the randomX audit would be what their donation will be used for.
**\<sarang>** Yes
**\<sarang>** If there was a desire to reduce the number, it is too late
**\<xmrmatterbridge> \<rehrar>** Unless some people are willing to deanonymize their donation and state that they are ok with this money going to other proposals or audits in the future.
**\<xmrmatterbridge> \<rehrar>** As I recall, nioc said something like that? Or was it someone else.
**\<ErCiccione>** I saw in -pow somebody proposing to start the last 2 audits after the first 2 are completed. So to avoid reduntant resutls. That sounds like a good idea to me
**\<xmrmatterbridge> \<rehrar>** I wonder how I could add "stretch goal" functionality to the CCS.
**\<ErCiccione>** at least would make the last audit "less useless", since they could audit eventual fixes proposed by the other 2 auditors
**\<xmrmatterbridge> \<rehrar>** So we can have it "fully funded" at one point, but it can go further for more points.
**\<xmrmatterbridge> \<rehrar>** The problem is we have some incredibly generous whales who don't follow the day to day. They just assume if something has been merged, it's worth funding and there is consensus in the community.
**\<xmrmatterbridge> \<rehrar>** And so they saw it not completely filled, and they filled it.
**\<sarang>** Since we must use the funds on this, I agree with staggering
**\<sarang>** Otherwise you could get necessary fixes to that are never audited
**\<xmrmatterbridge> \<rehrar>** Do you think I should make a Reddit post outlining what happened, and give people an opportunity to "withdraw" funds?
**\<sarang>** Is this a precedent you want to set for future CCS?
**\<xmrmatterbridge> \<rehrar>** But if staggering is the correct approach, then I'm all for it.
**\<xmrmatterbridge> \<rehrar>** No. Not at all.
**\<xmrmatterbridge> \<rehrar>** But RandomX can be a notable exception.
**\<ErCiccione>** rehrar: i don't think that's a good idea, better just learn from the issue and discuss how to avoid it next time
**\<sarang>** Are you prepared to justify the exception?
**\<xmrmatterbridge> \<rehrar>** Regardless, I'll speak with Luigi to get his insight, but it's looking fairly set in stone.
**\<sarang>** And address how to avoid it in the future?
**\<xmrscott[m]>** It can, I think it's worth highlighting the precedent it \*may\* set however
**\<sarang>** Fwiw I was not in favor of 4 audits for this
**\<\_Slack> \<intj440>** I am not convinced there is a "cliff of waste" that kicks in at 3.5 audits. I would vote for maximizing bang-for-the-buck with already pledged funds
**\<sarang>** But I am also funded by CCS
**\<el00ruobuob\_[m]>** Just one thing, the proposal is talking about 3 audits, not 4. Did i miss-read?
**\<xmrmatterbridge> \<rehrar>** Well, I think we can move on for the time being. At the moment, the default is to use funds in the manner in which they were given for.
**\<el00ruobuob\_[m]>** oh yes i missread
**\<needmoney90>** A single donor made a 1000xmr donation.
**\<needmoney90>** I believe we can probably reach out to them
**\<xmrmatterbridge> \<rehrar>** Defcon CCS proposals are up for discussion. I just posted something to the Reddit right now. Please comment and/or emoji the proposals somehow.
**\<needmoney90>** That makes it easy to remove a chunk of funds from the proposal from a donor
**\<needmoney90>** There is already precedent for donors getting refunded and stuff by proving they sent txes
**\<ErCiccione>** needmoney90: removing funds from a proposal is a very serious precedent. I think a discussion with the core team would e necessary before taking it in consideration (adn fwiw, i don;t think it's a good idea)
**\<el00ruobuob\_[m]>** Well, the 1400XMR is for 3 audits, not 4. I don't understand...
**\<needmoney90>** From memory it's happened before
**\<needmoney90>** el00ruobuob\_[m]: arweave is funding trailofbits
**\<needmoney90>** So we have one extra audit
**\<needmoney90>** By funding 3 we bring the total to 4
**\<needmoney90>** The proposal covers 3 independent of arweave
**\<xmrscott[m]>** Yes, but I believe that was for a FFS that was floundering in exec if mem serves
**\<el00ruobuob\_[m]>** ok, i didn't know about this
**\<needmoney90>** ErCiccione: I believe there is already precedent for refunds from FFS proposals
**\<needmoney90>** From memory
**\<ErCiccione>** needmoney90: alright, i don't recall any, but i may be wrong.
**\<needmoney90>** Can't recall where, but it was definitely a 'prove you sent the TX and we can refund'
**\<needmoney90>** I don't think there was controversy back then
**\<needmoney90>** fluffypony: is my memory serving me correctly?
**\<needmoney90>** Being the fund steward, you probably know
**\<rehrar>** so
**\<ErCiccione>** maybe for the fireice situation?
**\<needmoney90>** Anyways, carry on. Fluffy can respond at his leisure.
**\<rehrar>** refunds are incredibly rare
**\<rehrar>** what there is precedent for is that someone gave a good amount of money toward a proposal, in this case it was the Monero Challenge
**\<rehrar>** he topped it up, and it was over 100 XMR or something like that
**\<rehrar>** but that proposal was already defunct
**\<rehrar>** he was present enough in the community, to see the thread that was made about that and made himself known, and said he was comfortable with that going to the general fund
**\<ErCiccione>** In that case i guess it makes sense