Commit 177954f2 authored by luigi1111's avatar luigi1111

Merge !1094

Missing meeting logs since 6/17

See merge request monero-project/monero-site!1094
parents aa775f1e 471ccd9e
---
layout: post
title: Overview and Logs for the tini2p Dev Meeting Held on 2019-06-20
summary: Current project status, Roadmap, Meta issues, and miscellaneous
tags: [dev diaries, i2p, crypto]
author: el00ruobuob / oneiric
---
# Logs
**tini2p** Greetings
hi
apologies for the slightly late start
1: What's been done
Since last meeting, quite a bit has been done
The KDF for each section of new session messages is complete
as well as the new session message section data structures
the new session message data structure itself, and the existing session message still need completion
Elligator2 also needs impl, but I am saving that for after all the other moving parts are in place
**tini2p** also got GitLab CI working, replacing the unused BitBucket + CircleCI setups
Coveralls is still having a little issue reporting coverage (because of tini2p being header-only), so there is a little bit of work still to be done
but unit and net tests are now being run for each merge request, which is a very nice improvement
(was running them manually prior)
some cleanup of the ChaCha20Poly1305 wrappers was needed to get in-place en/decryption working
as well as some other global housekeeping, mostly focused on data blocks
**tini2p** made upstream patches to I2P 144 spec in collaboration with zzz (many thanks)
minor stuff, but important for getting ECIES working. will continue to submit patch diffs as work on ECIES and tunnels under ECIES continues
last I2P ls2 meeting was a little short, but zzz and other I2P devs are focusing elsewhere atm for the upcoming Java I2P release.
did some research into lock-free algorithms, and other thread-safe algorithms/data structures
**tini2p** atm, there are no performance bottlenecks, or thread-safety issues that I know of. however, during actual workloads (once the routers are talking over tunnels), I suspect some issues might crop up. I want to get ahead of any issues cropping up, and am investigating the alternatives
a non-trivial portion of the last two weeks has actually gone into reading papers (not all related to thread-safety), so it's work that doesn't show up directly in the code base
2: What's next
finishing up the remaining updates on ECIES (new/existing messages data structs), Elligator2 impl, ECIES session management impl
the data structs may be finished end-of-day today / tomorrow, while Elligator2 impl and ECIES session management may take up the better part of the next two weeks
depends on how long Elligator2 takes, as I want to make sure I do it right, and there is currently no canonical reference implementation
**tini2p** that said, there are validation scripts from DJB & crew (written in Sage), so I will be using those to verify my impl
the scripts will also need porting to C++, hence why the impl may take some time
Elligator2 isn't strictly needed to get the moving parts in place, so I may save it for last in the ECIES impl. It is needed for DPI protection, so it will definitely need implementation
other options were discussed (ChaCha20Poly1305 sym crypto using remote static public key as the symkey), but Elligator2 won out for various reasons
**tini2p** one of the biggest being trial decryption is more effective for deobfuscation if using ChaCha20 (if DPI boxes know/guess remote static public key), where Elligator2 produces valid Curve25519 public keys for nearly all 32-byte strings
Elligator2 is also slower than ChaCha20, so DPI decoding would also consume more resources than trial-decryption with ChaCha20
After ECIES is complete, I will begin work on tunnels under ECIES, and writing a spec once a proof-of-concept impl is in place
the spec (and PoC impl) will likely undergo many iterations, similar to the other specs involving big changes (see NTCP2 + ECIES itself)
however, the goal is still to have tini2p routers communicating with each other over tunnels by alpha release (2019-07-10)
**tini2p** this will be a rough sort of communication, since there will be no client, and the reseed setup will need to be manual, but small steps
the goal is to have integration tests that perform the e2e communication, which may also be extendable to inter-router communication across I2P implementations (Java I2P, i2pd, ire, etc)
post-alpha release, I will be working on cleaning up the implementation, continuing work on the tunnel spec, and working toward exposing an api for the client to consume
some rough thoughts on the client api: basically a reduced SAMv3 to only handle streaming (since there won't be UDP until SSU2)
SAMv3 will also require an I2CP impl (again reduced to only the streaming bits)
**tini2p** the client implementation will go into it's own repository for separation of concerns + increased modularity
so the period between alpha and beta release will be largely dedicated to client implementation
blinded LS2 may also find its way in there, but given the design goals of tini2p, it will not be priority
it is a nice-to-have though, and if enough users want it, I can be convinced to devote more attention to it
all of that is months in the future though, and my immediate focus is on finishing ECIES + tunnels
3: Questions/comments
@tini2p\_gitlab crickets
**tini2p** guess I'm back to being the only active meeting attendee
4: Next meeting time
2019-07-04 18:00 UTC
alright, meeting adjourned
see you lurkers next time
@tini2p\_gitlab taps the gavel ever-so-lightly
**tini2p** ah, looks like I forgot to mention Boost::ASIO replacement + LibreSSL-BearSSL swap. Those things are also planned to happen before alpha release
**tini2p** apparently, I was a couple hours early for this meeting time. will stick around for a bit past 18:00, if there are any questions / comments
**tini2p** yeah, so apologies for the early meet, but appears it really was just me again. will double-and-triple check the clocks for next meeting
**kinghat** i read when i remember i just dont use gitter that often.
---
layout: post
title: Overview and Logs for the Dev Meeting Held on 2019-06-30
summary: Development status, Code & ticket discussion, and miscellaneous
tags: [dev diaries, core, crypto]
author: el00ruobuob / rehrar
---
# Logs
**\<rehrar>** hey guys
**\<rehrar>** it's time for a meeting
**\<rehrar>** as always, we'll try not to drag and make this longer then it needs to be.
**\<rehrar>** 1. Greetings
**\<sarang>** Hi
**\<rbrunner>** Hi!
**\<vtnerd\_\_>** Hi
**\<kinghat>** shalom
**\<rehrar>** Alright. 2. What's been completed since last meeting.
**\<rehrar>** Anyone have an update on stuff?
**\<rehrar>** dsc\_ selsta dEBRUYNE for GUI people?
**\<rehrar>** moneromooo TheCharlatan CLI?
**\<dsc\_>** thecharlatan working on reproducible builds for GUI
**\<rehrar>** fluffypony luigi1111 smooth for Core Team?
**\<dsc\_>** I'm working on better tails integration
**\<dEBRUYNE>** GUI v0.14.1.0 is around the corner
**\<rbrunner>** Ah, that corner?
**\<dsc\_>** I've updated https://autonode.xmr.pm/ to show more remote nodes
**\<moneromooo>** I did some more work on share-rpc, seeing someone's started reviewing.
**\<moneromooo>** It would be nice if more people reviewed, and if someone did something with it
**\<sarang>** moneromooo: do you consider the CLSAG implementation branch suitable for PR/review (not to merge yet, just for review)
**\<moneromooo>** Yes.
**\<moneromooo>** It doens't have your latest changes though.
**\<sarang>** Right, and I plan to update 5707 (and its CLSAG equivalent) again soon
**\<sarang>** those are pretty minor overall
**\<moneromooo>** Then it might not be be ready.
**\<luigi1111>** I don't have an update
**\<dsc\_>** thanks for the update luigi1111
**\<rehrar>** luigi1111: you can update us on the brand of soda the core team drinks as the relax in the lounge
**\<dEBRUYNE>** With respect to a timeline for CLSAG, is October too optimistic? We must also take into account third party wallet providers, which will have to make changes too
**\<rehrar>** thanks everyone for the updates
**\<rehrar>** dEBRUYNE: this is going to be unpopular to say, as it's been discussed before, but if we're "right on the edge" with CLSAG, then why not just push the fork back a month?
**\<sarang>** dEBRUYNE: No final word from potential reviewers yet... I reached out again
**\<sarang>** So I do not have a timeline for CLSAG review
**\<rehrar>** 25% savings in ring sigs is kind of cool and nice to have.
**\<dEBRUYNE>** rehrar: So push the October fork back to November?
**\<rehrar>** if it'd give us the breathing room that would make enough people more comfortable with the timing, then yes
**\<sarang>** Why not wait until spring?
**\<rehrar>** Ah, wait no. we want RandomX in ASAP, huh?
**\<vtnerd\_\_>** This is 25% savings just for the ring sigs portion, not the entire tx, right? I don't see the reason for the push
**\<rehrar>** so pushing it back maybe isn't great
**\<sarang>** vtnerd\_\_: a 2-2 txn shrinks by 25% overall
**\<sarang>** not just sigs
**\<sarang>** (ring sigs themselves shrink by approx 50%)
**\<rehrar>** oof
**\<rbrunner>** My gut feeling tells me that RandomX and those CLSAG thing together will be a bit too much ...
**\<vtnerd\_\_>** Hmm need to read the paper then, didn't realize it dropped that much
**\<sarang>** you save 320 bytes per spent input
**\<sarang>** and about 20% on sig verification time
**\<vtnerd\_\_>** They are separate things entirely
**\<vtnerd\_\_>** They are either ready independently or not
**\<sarang>** And to clarify, there's working code already that anyone is free to review
**\<sarang>** (verification code will be tweaked a bit still)
**\<vtnerd\_\_>** Yeah the issue was a math review though ... ?
**\<sarang>** Yes, and a formal code review
**\<sarang>** But getting early internal review would be useful
**\<rehrar>** even though waiting on bulletproofs was a good idea, it was still painful to have that six months of big big transactions
**\<vtnerd\_\_>** Oh you wanted both for this too? Ok
**\<rehrar>** that we forever carry
**\<sarang>** vtnerd\_\_: it's important enough that I think both math/code review are important
**\<sarang>** esp. since MLSAG never got a formal audit
**\<vtnerd\_\_>** I mean its either that or risk an entire blow up of the coin
**\<vtnerd\_\_>** In response to rehrar
**\<dEBRUYNE>** sarang: I'd be fine with spring, that at least gives third wallet providers plenty of time to work on it
**\<luigi1111>** I think spring yes
**\<luigi1111>** for clsag
**\<rehrar>** yes, but my suggestion was pushign back a month for audits
**\<rehrar>** which lessens chance of coin blow up
**\<sarang>** Well, I can let everyone know when I hear back from our potential reviewers
**\<sarang>** OSTIF are also putting out feelers
**\<dEBRUYNE> \<rehrar>** yes, but my suggestion was pushign back a month for audits \<= Can you elaborate?
**\<dsc\_>** Has anyone heard from fluffy regarding GUI release?
**\<dsc\_>** Has he arrived home yet?
**\<rehrar>** if someone could see into the future, we can both see the outcome of the audits as well as save money by not paying for them
**\<rbrunner>** If we wait with CLSAG until spring, will there be time to build something nice on top of it until then in addition?
**\<sarang>** Also: earlier internal code review may reveal bugs that we can fix before sending code off to the reviewers
**\<sarang>** rbrunner: ?
**\<rehrar>** dEBRUYNE: it's just pushing this fall fork back one month to give some breathing room to get some CLSAG audits in
**\<rbrunner>** Like those famous atomic swaps, or whatever
**\<rehrar>** but as I said I see reasons not to do that. It was more in response to vtnerd\_\_
**\<dEBRUYNE>** dsc\_: https://www.reddit.com/r/Monero/comments/c6y542/any\_news\_on\_the\_gui\_release/esc02my/
**\<sarang>** DLSAG's key image issue makes it unsuitable for implementation just yet, IMO
**\<sarang>** CLSAG is basically ready without such (known) problems
**\<dEBRUYNE>** rehrar: Seems like a bit of a slippery slope
**\<dEBRUYNE>** Seems safer and more prudent to wait six months
**\<dEBRUYNE>** In the grand scheme of things six months isn't that much anyway
**\<rehrar>** I don't disagree, dEBRUYNE
**\<rehrar>** proving alternative viewpoints
**\<rehrar>** although how long six months is in tech and blockchain relatively is much bigger
**\<sarang>** It's pretty moot at this point anyway
**\<sarang>** Until we hear about audits
**\<rbrunner>** Well, I think that "blockchain relative time" has slowed considerably lately
**\<rehrar>** true. So maybe move on.
**\<sarang>** It's a moo point. Like a cow's opinion
**\<rehrar>** rbrunner: not with fireice and ryo nipping at our heels.
**\<sarang>** Doesn't matter
**\<rbrunner>** Lol
**\<rehrar>** Pretty soon we'll be doing coordinated, organized attacks out of fear
**\<rehrar>** alright, moving on
**\<rehrar>** 3. Code/Ticket discussion
**\<rbrunner>** I have used the Go RPC bindings: https://github.com/monero-ecosystem/go-monero-rpc-client
**\<rbrunner>** My 2 PR's to improve on that were just merged today.
**\<rbrunner>** Can confirm that the bloody thing works.
**\<dEBRUYNE>** rbrunner: Have you spent any work (or chatted with the team about it) on OB lately?
**\<rbrunner>** Yes, and the ball is definitely in their court now: https://github.com/OpenBazaar/openbazaar-go/issues/1638
**\<moneromooo>** That sounds like a lot of nice work there.
**\<rehrar>** much applause!
**\<rehrar>** Is that something Revuo worthy, you think?
**\<rehrar>** Go RPC stuffs?
**\<rbrunner>** Ah, hmmm, maybe not yet the OpenBazaar stuff, quite early yet.
**\<rbrunner>** RPC is of course ok to mention, maybe other people will use it
**\<rehrar>** Alright, if there's nothing else we can move on
**\<dEBRUYNE>** Nice work rbrunner
**\<rbrunner>** Thanks!
**\<rehrar>** I'm assuming in "Old Business" we don't need to continue discussion on Payment IDs?
**\<dsc\_>** very nice rbrunner
**\<moneromooo>** Only if there are new arguments.
**\<rehrar>** going once
**\<rehrar>** going twicee
**\<dEBRUYNE>** rbrunner: "and no support for moderation" \<= Is that even feasible at this point?
**\<rehrar>** hearing none, I think we can move on from PIDs
**\<rbrunner>** Doubtful, unfortunately.
**\<rehrar>** Ok, any other meeting items?
**\<rehrar>** Just as kind of announcement. People going to Vegas for Defcon, some of us are going a couple days early (starting monday the 5th) to hang out and chill. All are invited and welcome.
**\<dEBRUYNE>** rbrunner: I guess they could apply a similar process as bisq for moderation
**\<dEBRUYNE> \<rehrar>** I'm assuming in "Old Business" we don't need to continue discussion on Payment IDs? \<= I think the rough consensus was that we should start with a full software removal first
**\<dEBRUYNE>** (please correct me if I am wrong)
**\<rbrunner>** Don't remember exactly, isn't Bisq multisig-based as well?
**\<dEBRUYNE>** Partly (for the BTC part)
**\<rehrar>** dEBRUYNE: every core team member that spoke up (in the issue) was very against that. Smooth, ArticMine, binaryFate
**\<moneromooo>** I'll keep the parsing code with an opt-in flag in monerod I think.
**\<rbrunner>** to hang out and chill \<- is that even allowed for Monero people?
**\<dEBRUYNE>** rehrar: No?
**\<rehrar>** ohhhh wait
**\<rehrar>** never mind, I'm speaking of PID removal in general
**\<rehrar>** not long
**\<dEBRUYNE>** They were against parsing tx\_extra / temporary ban
**\<rehrar>** I got confused cuz you said "software removal 'first' "
**\<rehrar>** and thought you were hinting at the reversal later
**\<rehrar>** my bad
**\<dEBRUYNE>** Hmm no
**\<dEBRUYNE>** As far as I know, no one was against a full software removal
**\<rehrar>** cool
**\<dEBRUYNE>** There were people opposed against (i) temporary banning the tx\_extra field, (ii) permanently banning the tx\_extra field, (iii) parsing the tx\_extra field to disallow long payment IDs
**\<rehrar>** then we gucci
**\<sarang>** Define "full software removal" for clarity, plz?
**\<sarang>** As in, no GUI option to add one for outgoing?
**\<rehrar>** as I understand, Isthmus says he has some very interesting research going on about "treasures" found in th tx\_extra field
**\<rehrar>** I'd like to see that research when it happens, and we can discuss the pros and cons afterwards
**\<rbrunner>** Huh? Really?
**\<moneromooo>** In fact, I already made that code. I have shitloads of stuff that's not being PRed just because it conflicts due to merging being stalled now
**\<rbrunner>** That does not sound too good ...
**\<dEBRUYNE>** moneromooo: Do you have a list for luigi that he can merge?
**\<moneromooo>** Yes.
**\<dEBRUYNE>** Could you post it here too?
**\<moneromooo>** Sure. One moment...
**\<dEBRUYNE>** sarang: removal from both CLI and GUI
**\<sarang>** With no option to enable via flags?
**\<moneromooo>** 5647/5666, 5650/5651, 5663/5664, 5668/5669, 5675/5676, 5678/5684 (there's more)
**\<dEBRUYNE>** That was my idea kind of
**\<moneromooo>** and 5690/5694, 5681/5708.
**\<sarang>** Note that this could cause some exchanges/services to recommend specific wallets (that do continue to support) to their users
**\<sarang>** which could be good or bad, depending on the wallets
**\<dEBRUYNE>** That's a potential risk, yes
**\<dEBRUYNE>** I deem it more likely that they will simply switch though
**\<moneromooo>** I could keep the --enable-paymend-id-bad-for-privacy, and instead of enabling them, it prints "lolno".
**\<dEBRUYNE>** moneromooo: Will send luigi the list in PM as a reminder
**\<moneromooo>** Oh I did
**\<rehrar>** dEBRUYNE sarang this is all one big experiment. I'd say let's try it this way and see how the exchanges react
**\<moneromooo>** I just don;t want to annoy him too much.
**\<rehrar>** if they don't do as we hope, then we learn from that next time we have to make a decision like this
**\<rehrar>** but this is all hypothetical at this time. Let's see what happens.
**\<rbrunner>** I really doubt that the exchanges have time on their hands to work against the community, but who knows
**\<rehrar>** well, we do have LiveCoin
**\<moneromooo>** If they recommend other wallets, I won't have any regret in breaking those in next fork ^\_^
**\<rehrar>** either way
**\<rehrar>** 4. Any last meeting items?
**\<sarang>** 5707 speeds up MLSAG, and will be sped up a bit more
**\<moneromooo>** Does anyoine want to review share-rpc ? Or did I mention that already...
**\<sarang>** review will be welcome
**\<dEBRUYNE>** rehrar: Should we perhaps discuss v0.14.1.1?
**\<dEBRUYNE> \<rehrar>** dEBRUYNE sarang this is all one big experiment. I'd say let's try it this way and see how the exchanges react \<= Yes
**\<dEBRUYNE>** To be fair, it is mostly the big ones that are remaining that we need to get on board
**\<rehrar>** moneromooo: I'll put it in the REvuo volunteer opportunities (for all the good that will do)
**\<moneromooo>** AFAIK it's waiting for a freebsd patch from TheCharlatan.
**\<dEBRUYNE>** Bittrex, Bitfinex, and Binance
**\<rehrar>** moneromooo: can you PM me a link to it
**\<vtnerd\_\_>** moneromooo: I will look at it this week
**\<moneromooo>** https://github.com/monero-project/monero/pull/5357
**\<moneromooo>** Thanks
**\<rehrar>** thank you
**\<rehrar>** dEBRUYNE: what do you want to discuss regarding 0.14.1.1?
**\<rehrar>** the floor is yours
**\<dEBRUYNE>** Timeline kind of, what do the devs prefer?
**\<dEBRUYNE>** We can move a bit faster now that we have deterministic builds
**\<moneromooo>** As soon as the bsd patch is in.
**\<moneromooo>** (and the patches above)
**\<rehrar>** I may be getting confused because of the numbers, but didn't pony do builds already?
**\<rehrar>** or this is new? what's going into it?
**\<moneromooo>** The BSD patch and the patch list above.
**\<rehrar>** ah, k
**\<dEBRUYNE>** moneromooo: All right. Does this need a release v0.14 equivalent? https://github.com/monero-project/monero/pull/5705
**\<dEBRUYNE>** rehrar: new release
**\<moneromooo>** I dunno, ask TheCharlatan about this one.
**\<dEBRUYNE>** All right
**\<rehrar>** ok, anything else to discuss about this release?
**\<moneromooo>** The GUI I suppose ^\_^
**\<rehrar>** by all means, moneromooo. Take it away.
**\<moneromooo>** I don't have anything to say about it.
**\<dEBRUYNE>** GUI will follow CLI for v0.14.1.1
**\<dEBRUYNE>** First have to wait for pony to finish the v0.14.1.0 builds though
**\<moneromooo>** There are missing builds for .0 ? I didn't even realize...
**\<rehrar>** pony is traveling again
**\<rehrar>** he does that
**\<dEBRUYNE>** Yes
**\<dEBRUYNE>** Also we kind of had to retag, which has delayed the release a bit
**\<moneromooo>** Gonna run out of places to go soon.
**\<rehrar>** he's running from the community methinks.
**\<vtnerd\_\_>** Me? Lol I'm in a car on lte so I dropped service once and hit leave once stupidly
**\<dEBRUYNE>** rehrar: He provided an update yesterday
**\<dEBRUYNE>** Anyway, vtnerd\_\_ I wanted to ask you if you had already started some work on dandelion++ ?
**\<rehrar>** dEBRUYNE: link?
**\<dEBRUYNE>** https://www.reddit.com/r/Monero/comments/c6y542/any\_news\_on\_the\_gui\_release/esc02my/
**\<rehrar>** alright, if there's nothign else, I think we can call it here.
**\<rehrar>** discussion can obviously continue after the fact
**\<vtnerd\_\_>** I started to look into it. At this point my ffs pt 2 is hopefully going to make that transition easier (but it won't be a complete d++ implementation)
**\<rehrar>** Two weeks from now is the 14th of July. Same time.
---
layout: post
title: Logs for the Monero Research Lab Meeting Held on 2019-07-01
summary: Surae work, and miscellaneous
tags: [community, crypto, research]
author: el00ruobuob / suraeNoether
---
# Logs
**\<suraeNoether>** agenda here: https://github.com/monero-project/meta/issues/362
**\<rehrar>** howdy ho suraeNoether
**\<suraeNoether>** heighty hi, neighborino
**\<suraeNoether>** Good morning everyone!
**\<suraeNoether>** let's get this research meeting started
**\<suraeNoether>** Agenda is here, to refresh: https://github.com/monero-project/meta/issues/362
**\<suraeNoether>** Sarang will not be joining us today
**\<suraeNoether>** Before we get going, who all is here other than rehrar and myself?
**\<moneromooo>** I am here, in read only mode.
**\<suraeNoether>** isthmus is usually in meetings at this time, maybe he'll jump in later
**\<rehrar>** chmod moneromooo 777
**\<suraeNoether>** okay, we'll get going either way :D looks to be a short meeting
**\<rehrar>** fixed, albeit drastically
**\<suraeNoether>** So, firstly, Sarang posted his monthly research report, has been working on MLSAG speedups and some other CLSAG stuff, along with organizing for defcon
**\<suraeNoether>** I have not posted my research reports yet because I've been running around post-konferenco trying to get some stuff finished, getting back into research and simulations, and learning a lot from TheCharlatan who, through some unfortunate mishaps with passports, is still in town after the kon :P
**\<suraeNoether>** One thing I wanted to post with my reports was a post-mortem of the konferenco: total (final) attendee and sponsorship and speaker numbers, budget actuals, etc
**\<suraeNoether>** Other than that, there was a Monero coffee chat right after the Konferenco that sgp hosted. I'm not sure where the link was, but we had a lot of folks from the konferenco live, a huge portion of the MAGIC board of directors... it was a great conversation
**\<suraeNoether>** I'm anticipating making a push to my matching code either later today or tomorrow (TheCharlatan has helped me with a couple of development issues that were bogging me down)
**\<suraeNoether>** Beyond that, I can answer questions on more details, but I want to pass it off to anyone else who's done any work in the past week they want to share
**\<suraeNoether>** kennonero just asked two questions: first, when will CLSAG be merged, and second, has anything come up with the audits for CLSAG yet?
**\<suraeNoether>** in answer to the first question, based on my last conversation with sarang we are optimistically (but unlikely) shooting for the next hard fork for CLSAG, but there is a good chance it will be put off till the next hardfork... sarang is currently the middle man between MRL and the auditors, so I probably shouldn't get into further detail for fear of putting words in his mouth
**\<suraeNoether>** "middle man..." "contact person..."
**\<TheCharlatan>** lol
**\<rehrar>** there was a dev meeting yesterday
**\<rehrar>** and in it we all thought it was unlikely CLSAG makes it in this hard fork
**\<rehrar>** it's just really tight
**\<suraeNoether>** ^ there we go
**\<suraeNoether>** it is, it is
**\<moneromooo>** OTOH the Random X reviews fell into place quick, so...
**\<rehrar>** how are those going btw?
**\<suraeNoether>** yeah, i do wish sarang and I had a conversation about audits before this meeting.
**\<suraeNoether>** perhaps hyc is online and has some nontrivial info?
**\<moneromooo>** He got the X41 report, but I heard no more beyond "we got what we asked for".
**\<kennonero[m]>** suraeNoether: is there a vetting period for CLSAG security proof, or is it once the auditors are finished?
**\<dEBRUYNE>** I am more worried about third party software than the core software getting up to date for CLSAG in time
**\<rehrar>** "we got what we asked for" sounds kind of disappointed :P
**\<TheCharlatan>** yeah, some lead time for third parties should be taken into account.
**\<suraeNoether>** kennonero[m]: we haven't discussed that yet
**\<moneromooo>** Whoever wants to code their own already has the source.
**\<moneromooo>** (modulo yet another small speedup sarang wants to adD)
**\<moneromooo>** Is anyone really doing their own beyond mymonero ?
**\<suraeNoether>** if you ask me, the CLSAG scheme is not so different from MLSAG to be worried about the security (unforgeability), but it was sufficiently different that we couldn't "drop in" the security proof and a new one had to be written. but the proof doesn't have anything novel in it, and has all the same cryptographic assumptions as our present signatures...
**\<endogenic>** moneromooo: lots of ppl actually
**\<suraeNoether>** but on top of that, if we won't be able to get CLSAG into this hard fork and we have to push to the next hard fork anyway, that's still an additional 6 months of people looking at the proofs
**\<endogenic>** but otoh more are being discovered of late to have been using our lib
**\<moneromooo>** I find that hard to believe, but I'll accept that.
**\<suraeNoether>** moneromooo: one of the interesting things about isthmus' talk was the statistical evidence of a whole ecology of monero code out there that doesn't match our reference code or mymonero either
**\<endogenic>** i find it hard to accept lol
**\<moneromooo>** suraeNoether: it'll be 5 months of nothing, plus one month of looking. Instead of being one month of looking now.
**\<endogenic>** suraeNoether: i thought so too
**\<suraeNoether>** one thing i would like to bring up is the "juvenile transaction" problem that isthmus brought up in that talk too
**\<suraeNoether>** namely, it's convenient to be able to dump a bunch of transactions into the mempool all at once and walk away assured that eventually they will all be confirmed
**\<suraeNoether>** but if a transaction is in the mempool and uses an output that hasn't expired it's lock time, i feel like htat transaction should be considered invalid
**\<suraeNoether>** but then you have people who have to wait to create sequential transactions
**\<endogenic>** consensus all the things
**\<suraeNoether>** one question was "is there harm in allowing juvenile transactions to be hanging out in the mempool?"
**\<endogenic>** sounds like it
**\<suraeNoether>** a non-consensus way of helping things would make it so that such transactions \*aren't relayed until after the lock time is expired\*
**\<moneromooo>** smooth may have an opinion on that.
**\<suraeNoether>** i feel like it's a vector for the big bang attack or it will make flooding attacks way more simple or something like that
**\<moneromooo>** If it's not mined yet, it can't take others with it, so it seems much less annoying.
**\<moneromooo>** Good point. Currently the txpool is limited to... somehting like 300 MB I think. So you could make these unmineable txes with huge fees, but using an output locked for 10 years...
**\<moneromooo>** And it'd muscle out all other txes -> empty blocks.
**\<gingeropolous>** hold my beer, ima go pwn the monero network
**\<moneromooo>** Could be a separate txpool for those I guess.
**\<suraeNoether>** lolol
**\<kennonero[m]>** moneromooo: would it be logical to split the mempool into txs that can be spent now?
**\<moneromooo>** I'd have to think a lot more to decide whether it's logical I think.
**\<suraeNoether>** it's an interesting problem and there aren't obvious immediate ways to look at the trade-offs
**\<suraeNoether>** my favorite kind of problem
**\<kennonero[m]>** And maybe add a tx expiry time, so that txs cannot be in the pool for longer than a day or so
**\<moneromooo>** There is.
**\<kennonero[m]>** Sure
**\<TheCharlatan>** How about adding the locktime to the dandelion stem phase?
**\<suraeNoether>** vtnerd ^
**\<moneromooo>** What does this mean ?
**\<suraeNoether>** well, in the stem phase of dandelion++ you hang onto transactions for a random period of time before you pass it down the stem
**\<suraeNoether>** perhaps that random time could/should be >= the lock time of the transaction
**\<moneromooo>** Even easier to DoS nodes then, no ?
**\<suraeNoether>** hmmmm
**\<suraeNoether>** i suppose in the sense that it requires/requests that miners hang onto a transaction longer before removing it from the mempool, so the pool would get bigger
**\<suraeNoether>** okay, let's delay this discussion until after the meeting. too much in the weeds. :P but fun
**\<suraeNoether>** does anyone else have any research or other devleopment they want to brag about?
**\<suraeNoether>** Okay, so let's move onto action items, I guess!
**\<moneromooo>** Oh, reminds me. You or sarang said there was a "secret paper" to be presented at the Monero konferenco that would add another possible MLSAG replacement ?
**\<moneromooo>** Or was that DLSAG and I got confused?
**\<suraeNoether>** ohhohoho so that was omniring
**\<moneromooo>** OK.
**\<suraeNoether>** that was secret until about 2 weeks before the konferenco
**\<suraeNoether>** so we had two MLSAG replacement talks: lelantus and omniring. and we had 4 papers of interest: lelantus, omniring, ringct3.0, and Spartan
**\<rehrar>** can we just implement them all?
**\<rehrar>** or make a hodge podge of them like a soup and toss them in
**\<suraeNoether>** we've already excluded spartan for lack of a ZK language being proven (although the others present such a language for each example and there will eventually be some compatibility)
**\<suraeNoether>** i believe the batching for ringct3 and omniring ended up not panning out the way we had hoped, so our interest has zeroed in on lelantus (not a zerocoin joke when i started typing it, definitely a zerocoin joke by the time i was done typing it)
**\<suraeNoether>** so rehrar: maybe? shrugemoji
**\<suraeNoether>** it will be a stew of thermodynamics and money
**\<suraeNoether>** Any questions before we move onto action items?
**\<kennonero[m]>** \<suraeNoether "i believe the batching for ringc"> suraeNoether: For lelantus has there been any updates on the issue of having to send your received amount to yourself, so the original sender does not know when you spend?
**\<suraeNoether>** nope kennonero[m] that's the unfortunate trade-off with lelantus that has not yet been solved
**\<kennonero[m]>** Oh okay, thank you
**\<suraeNoether>** okay, moving onto action items
**\<suraeNoether>** My non-research things: konferenco post-mortem, research report, quarterly funding request. My research things: getting my github repo more orderly and pushing my Matching changes.
**\<suraeNoether>** oh and reviewing 5707
**\<suraeNoether>** Anyone else have any action items?
**\<rehrar>** update on RandomX when we can find it
**\<suraeNoether>** ^ i believe sarang will be on later today or tomorrow and he can bring us up to date on that. i may ask him to write a blog post describing the progress.
**\<suraeNoether>** okay, let's call this meeting adjourned, and hope we can hear from isthmus and sarang later
---
layout: post
title: Overview and Logs for the tini2p Dev Meeting Held on 2019-07-04
summary: Current project status, Roadmap, Meta issues, and miscellaneous
tags: [dev diaries, i2p, crypto]
author: el00ruobuob / oneiric
---
# Logs
**tini2p** hi all, meeting about to start in ~3min
0: Greetings
hi
agenda: tini2p/meta#17
1: What's been done
ECIES-X25519-AEAD-Ratchet updates
**tini2p** have been working with zzz on updating the proposal, and getting it closer to finalization
got my code to match up with the current version of the spec
we're at a little bit of a crossroads for how the new session handshake should happen, and how closely we should follow Noise
I'm going to code up something that follows the N, XK, and IK patterns for One-Time, Unbound, and Bound sessions respectively
that's more-or-less what's in the spec, but zzz and I haven't come to full agreement on exactly what that should look like in terms of our implementation
so I'm going to code up something to get e2e sessions working, and if we come to consensus that it should be different, I'll change my code
**tini2p** I still need to implement session management for ECIES, and Elligator2
Elligator2 is going to require some work
will talk more about that in the next agenda section
I wrote up a draft spec for tunnels under ECIES: https://gitlab.com/tini2p/meta/blob/master/docs/ecies-tunnels.md and https://geti2p.net/spec/proposals/152-ecies-tunnels
the formatting I did is a bit wonky on the I2P site (I'm new to the rst formatting)
it's very much still in the draft phase, but gives me something to implement for the upcoming alpha release
**tini2p** the goal of the spec is to gradually incorporate ECIES crypto into tunnel building and encryption, eventually phasing out ElGamal+AES
the spec doesn't make changes to the current ElGamal+AES crypto, as those hops/gateways will be treated as not knowing about the changes in the document
to ElGamal routers, ECIES hops should look like any other ElGamal router
I'm going to finish up the session management work I have for ECIES and start implementing tunnels over the next week, hopefully finishing by alpha release
also about 3/4 through with swapping in standalone-ASIO
will also be moving Catch2 to a submodule to further reduce system dependencies
**tini2p** BearSSL swap-in will be put on hold for the time being
I may crib their constant-time AES implementation, depending on how easy it is to separate from the rest of the library
all credits and licenses will remain intact, of course
other than that, no SSL is needed in core atm, so an SSL/TLS dep doesn't really make sense
it will be needed in client code (for downloading reseed files), but that is going to be a separate repo
LibreSSL or WolfSSL will likely be used there, for compatibility with standalone-ASIO
long ways away though
So some of that kind of bled over into the next section
2: What's next
**tini2p** as I said, continued dev on the few remaining pieces of ECIES session management, and the bulk of the work for Tunnels
Tunnels will be taking most of my time, and it will be a crunch to get it in by next Wednesday
I will include net tests that communicate via tunnels across local host, and may be able to hack something together for an integration test running on separate machines
the separate machine test will likely be very manual and not run in CI for the time being
oh, and CI is working now using GitLab CI!
After Tunnels and ECIES are in a working state, I will tag the first Alpha release
**tini2p** Alpha release on 2019-07-10!
(dev gods willing and kind)
this release will not include any client functionality, and the router will be in a very rough state
there is still a large amount of code cleanup, and added fuzz test suites that need to be added
after release, my focus will be on writing fuzz tests, and fixing any bugs that uncovers
I've done my best to follow safe coding practices, and write good code. This is C++, and a somewhat large codebase, though. So there are likely to be more than a few bugs
As part of the testing effort, I will also be incorporating the Elligator2 hacspec validation script: https://tools.ietf.org/html/draft-irtf-cfrg-hash-to-curve-01#appendix-C.4
**tini2p** this will be to validate whatever Elligator2 implementation I end up going with, likely https://github.com/Kleshni/Elligator-2 or adding wrappers around libSodium's implementation to handle Curve25519 and the inverse map
not sure the Ed25519 implementation will work for Curve25519 by converting the points before and after applying the inverse map and map, but maybe it does
luckily the hacspec script does Curve25519 Elligator2 map, so it can be used in a test to validate the implementation
I would be more comfortable with a reference Curve25519 implementation, but none exists...
**tini2p** the Kleshni code operates on Curve25519, and has a C implementation, so if it validates via the hacspec script for hash-to-point Elligator2 map, that may be the best way forward
there still isn't a validation script for point-to-hash, nor a reference impl, nor reference test vectors, so I'm still very cautious about implementing
many of my concerns would be soothed if those things existed
such is life
3: Questions / Comments
@tini2p\_gitlab crickets
**tini2p** right, so...
4: Next meeting time
There will be a short meeting next Thursday, 2019-07-11 18:00 UTC to discuss the success or failure of the Alpha release.
If I'm not able to have Tunnels + ECIES working by next Wednesday, I will talk about a pushed-back release date.
then there will be a regular meeting 2019-07-18 18:00 UTC, and meetings will return to every two weeks
thanks to the new faces for joining the channel!
**tini2p** feel free to interact as much or little as you please
meeting over
@tini2p\_gitlab throws the gavel in the air
---
layout: post
title: Logs for the Community Meeting Held on 2019-07-06
summary: Community highlights, CCS updates, Monero Konferenco recap, Workgroup report, and miscellaneous
tags: [community, crypto]
author: el00ruobuob / rehrar
---
# Logs
**\<sgp\_>** let us start
**\<sgp\_>** 0. Introduction
**\<sgp\_>** We would like to welcome everyone to this Monero Community Workgroup Meeting!
**\<sgp\_>** Link to agenda on GitHub: https://github.com/monero-project/meta/issues/367
**\<sgp\_>** Monero Community meetings are a discussion place for anything going on in the Monero Community, including other Monero workgroups. We use meetings to encourage the community to share ideas and provide support.
**\<sgp\_>** 1. Greetings
**\<el00ruobuob\_[m]>** Hi!
**\<rehrar>** boyo
**\<msvb-mob>** Hello.
**\<ErCiccione[m]>** hi
**\<xmrscott[m]>** Yo~
**\<sgp\_>** welcome all, special thanks to those in their second meeting
**\<sgp\_>** 2. Community highlights
**\<sgp\_>** See Monero weekly highlights at https://revuo-monero.com/
**\<sgp\_>** The Monero community workgroup hosted a coffee chat last weekend: https://www.youtube.com/watch?v=swTYc6y95Lw
**\<monerobux>** [ Monero Coffee Chat - 2019.06.29 - YouTube ] - www.youtube.com
**\<sgp\_>** I want to give a special shoutout to Monero Talk for their best interview yet in my opinion with Tone Vays: https://www.youtube.com/watch?v=sJjV4PognZQ
**\<monerobux>** [ Tone Vays is LIVE on Monero Talk! Is Monero digital cash...or useless??? - YouTube ] - www.youtube.com
**\<sgp\_>** Does anyone else have community (non-workgroup) updates to share?
**\<ErCiccione[m]>** the Monero Ecosystem project has a new member
**\<ErCiccione[m]>** https://github.com/monero-ecosystem/vanity-monero
**\<ErCiccione[m]>** very nice repo, you can use it to create personalized monero addresses
**\<ErCiccione[m]>** didn't have time to announce it yet
**\<sgp\_>** very cool
**\<rehrar>** I used it and have a shiny new XMR address
**\<rehrar>** is has "diego" in it
**\<sgp\_>** Breaking Monero Episode 99: Using vanity addresses with your name in it isn't great for opsec :p
**\<sgp\_>** Any other updates?
**\<sgp\_>** 3. CCS updates
**\<sgp\_>** This should be quick today
**\<sgp\_>** CCS proposals still needing funding:
**\<sgp\_>** NONE! (btw rehrar the page looks weird with 0 proposals)
**\<sgp\_>** CCS proposals in ideas to be discussed:
**\<sgp\_>** “Increase the Adoption of Monero at Avantpay|19 Conference” (250 XMR) https://repo.getmonero.org/monero-project/ccs-proposals/merge\_requests/81
**\<rehrar>** I'll add it again to my mountain of stuff
**\<sgp\_>** low priority :)
**\<dEBRUYNE>** I guess Surae's proposal is coming soon
**\<sgp\_>** I don't think this proposal is useful, and it seems to not have received positive feedback so far
**\<midipoet>** is that the cannabis conference one?
**\<sgp\_>** yeah
**\<rehrar>** the guy has expressed a misunderstanding
**\<rehrar>** he acknowledges the misunderstanding and agrees the proposal isn't helpful
**\<sgp\_>** I laughed when I read the part of being promised an attendance list
**\<sgp\_>** Anyway, unless there are any comments, we can move on. I opened this up in case someone had any
**\<sgp\_>** 4. Monero Konferenco recap
**\<sgp\_>** The Monero Konferenco was an important event in the history of Monero. We had two packed (>9 hr) days with talks, panels, parties, and conversations. All talks are available at https://www.youtube.com/c/monerocommunityworkgroup
**\<monerobux>** [ Monero Community Workgroup - YouTube ] - www.youtube.com
**\<sgp\_>** The Konferenco was the most watched live event in the history of Monero to my knowledge. People have watched over 66,000 hours of the livestream videos. People watched 26,000 hours of the individual videos. That’s a total of more than 92,000 hours of watched content, and it is still increasing.
**\<sgp\_>** For reference, the Moneroversary showcase has 25,819 hours of watch time. Breaking Monero episode 1 has 14,435 hours. The most popular Coffee Chat has 11,403 hours.
**\<sgp\_>** Plus, Monero Talk has 14 interviews for you to watch.
**\<sgp\_>** Thanks to everyone who attended and watched online. It was a great event, and we luckily have another great event scheduled in early August.
**\<sgp\_>** Is there anything we should improve for future years?
**\<dEBRUYNE>** May want to consider hosting one in Europe
**\<xmrscott[m]>** Perhaps a more formal photography policy
**\<dEBRUYNE>** e.g. each other year in Europe, each other year in US
**\<dEBRUYNE>** sgp\_: I think there were some remarks about the food
**\<xmrscott[m]>** (I noticed on Twitter some folk posted pics of audience's faces)
**\<dEBRUYNE>** i.e. that it was mostly sweets etc.
**\<midipoet>** i second dEBRUYNE's idea
**\<rehrar>** Mexico is the best bet imo
**\<rehrar>** easy to get into, quite safe, super cheap
**\<sgp\_>** Portugal?
**\<midipoet>** ah come one continent distribution is important
**\<el00ruobuob\_[m]>** +1 with dEBRUYNE
**\<dEBRUYNE>** Mexico is still far away from Europe though :-P
**\<selsta>** ^
**\<rehrar>** maybe two a year
**\<dEBRUYNE>** There's quite a large and vibrant Monero community in Europe
**\<rehrar>** one your side one our side
**\<rehrar>** our side needs to be in Mexico though
**\<rehrar>** all I'm saying
**\<rehrar>** some people can't come into the USA
**\<dEBRUYNE>** Ah
**\<rehrar>** because it's stupid
**\<dEBRUYNE>** You want to move the US side to Mexico?
**\<sgp\_>** could do Canada too
**\<rehrar>** sgp\_, please
**\<rehrar>** Canada doesn't have Mexican food
**\<ErCiccione[m]>** +1 for a conference in europe
**\<sgp\_>** Where in Europe would make the most sense? Berlin? Frankfurt? Europe is quite lacking in good Mexican food too :(
**\<midipoet>** Europeans are weighing in heavy here. i feel a changing of the tide
**\<el00ruobuob\_[m]>** There's good food in Paris
**\<dsc\_>** Beware you need to fill in Github/Twitter/Facebook/Instagram/Linkedin account when you want to travel to the US
**\<xmrscott[m]>** Somewhere near Riat perhaps?
**\<dEBRUYNE>** sgp\_: Preferably somewhere near a well connected airport
**\<selsta>** Riat is Vienna :P
**\<rehrar>** el00ruobuob\_[m]: not Mexican food though
**\<dsc\_>** Vienna good choice, also Berlin
**\<midipoet>** Berlin! swoon
**\<dsc\_>** and Prague is cheap.
**\<selsta>** also Prague yes
**\<el00ruobuob\_[m]>** you can find any food you want in Paris rehrar
**\<midipoet>** i could take rehrar and sgp\_ to Berghain
**\<midipoet>** blow their minds
**\<sgp\_>** dEBRUYNE: no joke I make a table of flight costs to different cities when Brandon was looking at Denver. Denver is one of the cheapest places to fly. I could do the same for European cities
**\<dEBRUYNE>** Sure
**\<rehrar>** lol
**\<dEBRUYNE>** I think something that is relatively sunny would be more atttractive for people
**\<rehrar>** oh! on a beach!
**\<rehrar>** oh wait, that's Mexico again :D
**\<midipoet>** lol
**\<sgp\_>** Helsinki obvs
**\<dEBRUYNE>** rehrar: I kind of meant somewhere around the mediterean sea
**\<dEBRUYNE>** Or portugal
**\<midipoet>** Croatia would be cool for beaches. and cheap
**\<sgp\_>** Reykjavik may be a location compromise
**\<midipoet>** portugal also
**\<msvb-mob>** Why did Zcash have their conference in Dubrovnik? Do they do every year in Europe or every other year?
**\<sgp\_>** \*Split
**\<midipoet>** in Split?
**\<msvb-mob>** sgp\_: Oh sorry, it was Split. I like your Reykjavik idea a lot.
**\<sgp\_>** Zcon1 was in Split
**\<rehrar>** so which one of you guys is putting together said theoretical Konferenco?
**\<midipoet>** i actually do have a european contact that puts on conferences
**\<midipoet>** they did that Provenance event that fluffy was at
**\<midipoet>** and they are doing Japan Blockchain week
**\<rehrar>** Brandon can license out his branding
**\<midipoet>** they live realy close to me irl